Автор: Пользователь скрыл имя, 02 Ноября 2011 в 18:46, лекция
Концепции объектно-ориентированного анализа и проектирования. Эволюция и краткая характеристика основных подходов к разработке информационных моделей бизнес-систем и бизнес-процессов. Особенности проектирования, анализа и формализации корпоративных систем. Основные этапы развития языка UML и принятые стандарты. Разработчики графической нотации и специфика ее использования в процессе создания масштабируемых программных систем.
Методология объектно-ориентированного анализа и проектирования
Необходимость
анализа предметной области до начала
написания программы была осознана
при разработке масштабных проектов.
Процесс создания баз данных существенно
отличается от написания программного
кода для решения вычислительной
задачи. Так, при проектировании базы
данных возникает необходимость
в предварительной разработке концептуальной
схемы или модели, которая отражала
бы общие взаимосвязи предметной
области и особенности
Предметная область (domain) - часть реального мира, которая имеет существенное значение или непосредственное отношение к процессу функционирования программы. Другими словами, предметная область включает в себя только те объекты и взаимосвязи между ними, которые необходимы для описания требований и условий решения конкретной задачи.
Выделение
исходных или базовых компонентов
предметной области, требуемых для
решения той или иной задачи, представляет,
в общем случае, нетривиальную
проблему. Сложность данной проблемы
проявляется в неформальном характере
процедур или правил, которые можно
применять для этой цели. Более
того, эта работа должна выполняться
совместно со специалистами или
экспертами, хорошо знающими предметную
область. Например, если разрабатывается
база данных для обслуживания пассажиров
крупного аэропорта, то в проектировании
концептуальной схемы базы данных должны
принимать участие штатные
Объектно-ориентированный анализ и проектирование (ООАП, Object-Oriented Analysis/Design) -технология разработки программных систем, в основу которых положена объектно-ориентированная методология представления предметной области в виде объектов, являющихся экземплярами соответствующих классов.
Методология ООАП тесно связана с концепцией автоматизированной разработки программного обеспечения (Computer Aided Software Engineering, CASE). К первым CASE-средствам отнеслись с определенной настороженностью. Со временем появились как восторженные отзывы об их применении, так и критические оценки их возможностей. Причин для столь противоречивых мнений было несколько. Первая из них заключается в том, что ранние CASE-средства были простой надстройкой над системой управления базами данных (СУБД). Визуализация процесса разработки концептуальной схемы БД имеет немаловажное значение, тем не менее, она не решает проблем создания приложений других типов.
Вторая причина связана с графической нотацией, реализованной в CASE-средстве. Если языки программирования имеют строгий синтаксис, то попытки предложить подходящий синтаксис для визуального представления концептуальных схем БД, были восприняты далеко не однозначно. На этом фоне разработка и стандартизация унифицированного языка моделирования UML вызвала воодушевление у всего сообщества корпоративных программистов.
В рамках ООАП исторически рассматривались три графических нотации:
диаграммы "сущность-связь" (Entity-Relationship Diagrams, ERD),
диаграммы функционального моделирования (Structured Analysis and Design Technique, SADT),
диаграммы потоков данных (Data Flow Diagrams, DFD).
Диаграммы
"сущность-связь" (ERD) предназначены
для графического представления
моделей данных разрабатываемой
программной системы и
Основными понятиями данной нотации являются понятия сущности и связи. При этом под сущностью (entity) понимается произвольное множество реальных или абстрактных объектов, каждый из которых обладает одинаковыми свойствами и характеристиками. В этом случае любой рассматриваемый объект может быть экземпляром одной и только одной сущности, должен иметь уникальное имя или идентификатор, а также отличаться от других экземпляров данной сущности.
Связь (relationship) определяется как отношение или ассоциация между отдельными сущностями. Примерами связей могут являться родственные отношения, в частности "отец-сын" или производственные - "начальник-подчиненный". Другой тип связей задается отношениями "иметь в собственности" или "обладать свойством". Различные типы связей графически изображаются в форме ромба с соответствующим именем данной связи.
Графическая
модель данных строится таким образом,
чтобы связи между отдельными
сущностями отражали не только семантический
характер соответствующего отношения,
но и дополнительные аспекты обязательности
связей, а также кратность участвующих
в данных отношениях экземпляров
сущностей. Нотация диаграмм (ERD) реализована
в различных программных
Ограниченность
диаграмм ERD проявляется при конкретизации
концептуальной модели в более детальное
представление моделируемой программной
системы, которое кроме статических
связей должно содержать информацию
о поведении или
Рис. 1.2. Диаграмма "сущность-связь"
для примера сотрудников
В рамках
диаграмм функционального моделирования
было разработано несколько
Нотация IDEF0 - для документирования процессов производства и отображения информации об использовании ресурсов на каждом из этапов проектирования систем
Нотация IDEF1 - для документирования информации о производственном окружении систем
Нотация IDEF2 - для документирования поведения системы во времени
Нотация IDEF2 никогда не была полностью реализована. Нотация IDEF1 в 1985 году была расширена и переименована в IDEF1X. Методология IDEF нашла применение в правительственных и коммерческих организациях, поскольку в 1993 году появился стандарт FIPS правительства США для двух технологий IDEF0 и IDEF1X. В течение последующих лет этот стандарт продолжал активно развиваться и послужил основой для реализации в некоторых CASE-средствах, наиболее известным из которых является AllFusion Process Modeler® (новое название BPwin® ) компании Computer Associates.
Процесс
моделирования IDEF представляет собой
совокупность методов, правил и процедур,
предназначенных для построения
функциональной модели системы какой-либо
предметной области. Функциональная модель
IDEF отображает структуру процессов
функционирования системы и ее отдельных
подсистем, то есть, выполняемые ими
действия и связи между этими
действиями. Для этой цели строятся
специальные модели, которые позволяют
в наглядной форме представить
последовательность определенных действий.
Исходными строительными
Одна
из наиболее важных особенностей нотации
IDEF0 - постепенное введение все более
детальных представлений модели
системы по мере разработки отдельных
диаграмм. Построение модели IDEF0 начинается
с представления всей системы
в виде простейшей диаграммы, состоящей
из одного блока процесса и стрелок
ICOM, служащих для изображения основных
видов взаимодействия с объектами
вне системы. Поскольку исходный
процесс представляет всю систему
как единое целое, данное представление
является наиболее общим и подлежит
дальнейшей декомпозиции. Пример представления
общей модели процесса оформления кредита
в банке, разработанной с помощью
CASE-средства AllFusion Process Modeler®, изображен
на рис. 1.3.
Рис. 1.3.
Пример исходной диаграммы IDEF0 для процесса
оформления кредита в банке
В конечном
итоге модель IDEF0 представляет собой
набор иерархически взаимосвязанных
диаграмм с сопроводительной документацией,
которая разбивает исходное представление
сложной системы на отдельные
составные части. Детали каждого
основного процесса представляются
в виде более подробных процессов
на других диаграммах. В этом случае
каждая диаграмма нижнего уровня
является декомпозицией процесса из
более общей диаграммы. Поэтому
на каждом шаге декомпозиции более
общая диаграмма
Основной недостаток данной методологии связан с отсутствием явных средств для объектно-ориентированного представления моделей сложных систем. Некоторые аналитики отмечают важность знания и применения нотации IDEF0, однако отсутствие возможности реализации соответствующих графических моделей в объектно-ориентированном программном коде существенно сужают диапазон решаемых с ее помощью задач.
В основе графического моделирования информационных систем с помощью диаграмм потоков данных лежит специальная технология построения диаграмм потоков данных DFD. В разработке методологии DFD приняли участие многие аналитики, среди которых следует отметить Э. Йордона. Он автор одной из первых графических нотаций DFD.
Недостаток рассмотренных нотаций связан с отсутствием явных средств для объектно-ориентированного представления моделей сложных систем, а также сложных алгоритмов обработки данных. Поскольку на рассмотренных типах диаграмм не указываются характеристики времени выполнения отдельных процессов и передачи данных между процессами, то модели систем, реализующих синхронную обработку данных, не могут быть адекватно представлены в этих нотациях. Все эти особенности методов структурного системного анализа ограничили возможности широкого применения соответствующих нотаций и послужили основой для разработки унифицированного языка моделирования UML.
Основные этапы развития языка UML
Отдельные
языки объектно-
К середине 1990-х некоторые методы были существенно улучшены и приобрели самостоятельное значение при решении различных задач ООАП. Наиболее известными в этот период становятся:
Метод Гради Буча (Grady Booch), получивший условное название Booch или Booch'91, Booch Lite (позже - Booch'93)
Метод Джеймса Румбаха (James Rumbaugh), наименованный Object Modeling Technique - OM (позже - OMT-2)
Метод
Айвара Джекобсона (Ivar Jacobson), под названием
Object-Oriented Software Engineering - OOSE
Каждый
из этих методов был ориентирован
на поддержку отдельных этапов ООАП.
Например, метод OOSE содержал средства
представления вариантов
История развития языка UML берет начало с октября 1994 года, когда Гради Буч и Джеймс Румбах из компании Rational Software Corporation начали работу по унификации методов Booch и OMT. Несмотря на то, что сами по себе эти методы были достаточно популярны, совместная работа была направлена на изучение всех известных объектно-ориентированных методов с целью объединения их достоинств. При этом Г. Буч и Дж. Румбах сосредоточили усилия на полной унификации результатов своей работы. Проект так называемого унифицированного метода (Unified Method) версии 0.8 был подготовлен и опубликован в октябре 1995 года. Осенью того же года к ним присоединился А. Джекобсон, главный технолог компании Objectory AB (Швеция), с целью интеграции своего метода OOSE с двумя предыдущими.
В этот период поддержка разработки языка UML становится одной из целей консорциума OMG (Object Management Group), который был образован еще в 1989 году с целью разработки предложений по стандартизации объектных и компонентных технологий CORBA. В то время язык UML приобрел статус второго стратегического направления в работе OMG. Именно в OMG создается команда разработчиков под руководством Р. Соли, которая обеспечила дальнейшую работу по унификации и стандартизации языка UML. Усилия группы разработчиков, в которую входили также Г. Буч, Дж. Румбах и А. Джекобсон, привели к появлению первых документов, содержащих собственно описание языка UML версии 0.9 (июнь 1996 г.) и версии 0.91 (октябрь 1996 г.).
Тогда же некоторые компании и организации увидели в языке UML стратегический интерес для своего бизнеса. Компания Rational Software вместе с несколькими организациями, изъявившими желание выделить ресурсы для разработки строгого определения версии 1.0 языка UML, учредила консорциум партнеров UML, в который первоначально вошли такие фирмы, как Digital Equipment Corp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI и Unisys. Эти компании обеспечили поддержку последующей работы по более точному определению нотации.
Информация о работе Нотация и семантика языка Unified Modeling Language