ООА.
ООА был разработан Кодом (Coad) и Иордоном (Yourdon).
Метод разделяет разработку на три слоя. В первом слое осуществляется определение объектов, поэтому слой и называется объектным. Тут пользователи могут продемонстрировать свое понимание проблемной области, определяя соответствующие объекты из предметной области.
Второй слой называется слоем атрибутов. На этом этапе определяются атрибуты (элементы данных), связанные с объектами из предметной области.
Третий слой - сервисный слой, определяющий сервисы (или операции), предоставляемые каждым объектом.
В сущности, ООА помогает системным инженерам определить требования к системе, вместо того чтобы определять структуру программного обеспечения или его реализацию. В то же время, этот метод может помочь и в описании уже существующей системы (в том числе и ПО), ее операций и того, как другие системы должны взаимодействовать с ней.
ОМТ.
Метод ОМТ был разработан Румбахом (Rumbaugh).
Основная задача метода это создание таких наборов объектных моделей, детально описывающих архитектуру системы, пока финальный вариант модели не станет пригодным для реализации.
Подход предполагает наличие трех фаз. На фазе анализа создаются модели предметной области. В течение этой фазы создаются модели трех типов - объектные модели, динамические модели и функциональные модели. В первую очередь разрабатываются объектные модели. Для объектных моделей применяется нотация аналогичная ООА, основанная на концепции моделировании сущностей и связей (ER = Entity-Relationship modeling). Объектные модели описывают объекты, классы объектов и связи между объектами. Динамические модели описывают поведение системы с помощью расширения диаграмм состояний Харела (Harel). Функциональные модели описывают функции системы с помощью диаграмм потоков данных (DFD).
Каждая из моделей многократно уточняется и дорабатывается. На фазе проектирования (design) особое внимание уделяется структуре моделей, а на фазе разработки больше внимания уделяется языку, на котором планируется разработка. Таким образом, ОМТ покрывает не только процесс получение требований к системе, но также и процесс проектирования архитектуры решения.
Booch.
Метод Буча (Booch, 1994) был одним из первых предложенных объектно-ориентированных методов. Несмотря на то, что метод рассматривает фазу анализа, его основная сила появляется при проектировании объектно-ориентированных систем. Метод предусматривает постепенное и многократное уточнение архитектуры системы (incremental and iterative approach). Метод также вводит понятия логического и физического представлений системы.
Метод предусматривает фазу анализа проблемной области для выявления классов и объектов, а также связей между ними. Метод использует графическую нотацию для проектирования. Нотация имеет расширения для реализации классов и объектов, а также сервисов предоставляемых ими. Другой важной особенностью применяемой нотации является наличие диаграмм переходов состояний (state transition diagrams) и временных диаграмм (timing diagrams).
Objectory.
Метод Обжектори был предложен Якобсеном (Jacobsen).
Большинством своих идей метод похож на другие объектно-ориентированные методы. Фундаментальным отличием метода, как уже упоминалось выше, является использование сценариев или прецедентов (scenarios или use cases). Таким образом, функциональность системы описывается с помощью набора прецедентов для системы - моделью прецедентов.
В дальнейшем, модель прецедентов используется для получения модели объектов предметной области. Анализ полученной модели объектов предметной области позволяет классифицировать объекты предметной области трех типов: интерфейсные объекты, объекты сущностей и управляющие объекты. Далее объектная модель преобразуется в архитектурную модель, содержащую модули разрабатываемой системы.
UML.
Универсальный язык моделирования UML (OMG, 2003) создавался как попытка объединить вместе объектно-ориентированные подходы, получившие наибольшую поддержку и признание, а именно: Буч, ОМТ и Обжектори. В середине 90х годов ХХ века Буч, Румбах и Якобсен стали вместе работать в компании Rational, начав разрабатывать единый, общий и ныне широко применяемый язык моделирования. В то время максимальное внимание уделялось разработке нотации для графического моделирования, нежели чем разработке метода или процесса.
С момента своего появления UML неоднократно подвергался доработке и изменениям. Было выпущено несколько версий UML. Так, в 1997 году версия UML 1.0 стала международным стандартом, после того как была признана OMG-группой (Object Management Group), а в 1999 была анонсированная уже версия 1.3. В этой книге рассматривается уже версия UML 2.0, выпущенная в 2003 году.
В последующих разделах язык UML описывается более подробно.
3.3.3 Нотация UML.
UML предполагает разработку нескольких моделей, совокупность которых описывает разрабатываемую систему. Каждая модель относится к соответствующей фазе и имеет собственное предназначение. При этом каждая из моделей состоит из одной или нескольких UML-диаграмм, которые можно классифицировать следующим образом:.
• структурные (structure) диаграммы;.
• диаграммы поведения (behaviour);.
• диаграммы взаимодействия (interaction).
На рис. 3.24 представлены все 13 типов диаграмм, существующих в нотации UML 2 и доступных системным инженерам.
На практике многие из этих диаграмм не так часто применяются при разработке. Иногда бывает достаточно использовать лишь небольшой набор диаграмм для моделирования системы. Опыт показывает, что наиболее часто используются диаграммы прецедентов, диаграммы классов и диаграммы последовательностей. Если же требуется моделирование динамического поведения системы, то следует воспользоваться диаграммами действий и диаграммами состояний.
Рис. 3.24 Диаграммы UML.
Следует заметить, что цель данного раздела - это не подробное описание UML2, - для этого существуют другие источники, - а демонстрация того, как модели могут использоваться при разработке требований.
Давайте вернемся к примеру с банковской системы, рассмотренной ранее этой главе.
На рис. 3.25 показана UML-диаграмма классов для банковской системы (диаграмма классов является базовой в UML). На диаграмме показан набор классов, используемый для моделирования системы, - классы «Счет», «Владелец», «Текущий Счет» и «Выписанный Чек». Как видно из диаграммы, каждый класс имеет собственное имя, набор атрибутов и.
операций, а также связи с одним или более классов (в данном случае обобщения и ассоциации).
Рис. 3.25 Расширенная диаграмма классов UML для банковской системы.
Моделирование также бывает полезным, когда существуют внешние системы, или устройства, которые разрабатываемая система будет использовать. Эти системы могут быть представлены в виде классов.
Рис. 3.26 Диаграмма классов для системы транспортировки багажа.
На рис. 3.26 приведен другой пример - диаграмма классов для системы транспортировки багажа.
Диаграмма отражает пользовательские требования, которые явно относятся к проблемной области. Для системы транспортировки багажа были определены следующие классы: «Пассажир», «Служащий» и «Конвейер», а также были выделены две встроенные системы.
- «СистемаРегистрацииБагажа» и «Весы». Ассоциации между системами и классами помогают более четко определить контекст работы системы.
Переходя к области решений, необходимо задуматься о функционале и поведении системы. Следовательно, диаграмма классов должна быть уточнена и дополнена так, чтобы отобразить все эти атрибуты (классов), которые будут необходимы для последующего моделирования системных требований (см. рис. 3.27).
Рис. 3.27 Уточненная диаграмма классов.
Для описания функциональных требований к системе используется моделирование прецедентов. В качестве примера можно рассмотреть две диаграммы прецедентов - одна для системы транспортировки багажа, а другая для системы регистрации багажа.
На рис. 3.28 первая из систем представлена как система верхнего уровня.
На рис. 3.29 изображена диаграмма прецедентов для системы регистрации багажа.
На обеих диаграммах определены относительные границы систем (обозначены прямоугольником), а также различные типы заинтересованных сторон (shareholders), называемые актерами, которые находятся за границами системы. Необходимо отметить, что прецеденты представляют собой высокоуровневые цели заинтересованных сторон. Связь типа «включает» показывает, что этот прецедент является частью другого прецедента (включается), т.е. таким образом показывается иерархическая декомпозиция прецедентов.
Рис. 3.28 Диаграмма прецедентов для системы транспортировки багажа.
UML также дает проектировщикам возможность моделировать функциональность системы и ее поведение. Диаграмма последовательности показывает взаимодействие и совместную работу объектов, и таким образом позволяет моделировать сложное поведение системы с помощью сообщений, которыми обмениваются объекты друг с другом в процессе взаимодействия. На рис. 3.30 приведен пример диаграммы последовательности. В верхней части диаграммы прямоугольниками изображены объекты, каждый имеет вертикальную линию, обозначающую время. Сообщения изображаются в порядке их появления с помощью стрелок между линиями времени объектов. Одна диаграмма последовательности может ссылаться на другую с помощью специального символа - прямоугольника с названием другой диаграммы последовательности и пометкой ref (“reference”). Это обозначает, что часть взаимодействия между объектами в этом промежутке времени изображена на другой диаграмме. В нашем случае - это «ВзвешиваниеБагажа» и «МаркировкаБагажа».
Рис. 3.30 Пример диаграммы последовательности.
С помощь вынесения описания части взаимодействия в отдельные диаграммы достигается возможность повторного их использования в модели.
3.3.4 Формальные методы.
Формальные методы обеспечивают более строгое представление, основанное на математике, и, таким образом, могут быть использованы для математического обоснования полноты спецификаций и правильности их исполнения. Применение формальных методов дает возможность строгой проверки позволяющей избавиться от ошибок определенных видов. Использование таких методов необходимо для определенных классов систем, например для атомной энергетики, разработки оружия, систем управления воздушным транспортом.
Z (Spivey, 1989), VDM (Jones, 1896), LOTOS (Bjorner, 1987) и B (Abrial, 1996) являются наиболее распространенными формальными методами для формального описания функциональности. LOTOS (Language of Temporal Ordering Specification - язык для определения временной последовательности), VDM (Vienna Definition Language - язык венского определения) и Z стандартизированы ISO. Языки B и LOTOS исполняемые, B также может быть переведен в программный код.
Формальные методы применяются для критических систем, там, где потенциальные человеческие или финансовые потери могут быть очень значительны и стоимость применение точных математических методов, таким образом, вполне оправдана.
Формальные методы постепенно приобретают большую значимость. Если бы рамки применения формальных методов были шире, чтобы охватить большее количество аспектов системного проектирования, они бы стали более полезны и, следовательно, популярны.
Z-метод для формального моделирования.
Z - это нотация для моделирования основанная на логике предикатов первого порядка и теории множеств. Нотация позволяет представлять данные в виде множеств, отображений, кортежей, связей, последовательностей и декартовых произведений. Также существуют функции и символы операций для обработки данных этих типов.
Z-спецификации представляют собой маленькие, легко читающиеся элементы, называемые «схемами». Схема состоит из части объявления переменных и части предиката. В разделе объявления переменных содержится список объявленных переменных, в разделе предиката всегда содержится только один предикат. Наименование схемы вводит синтаксическую эквивалентность между именем и схемой. На рис. 3.31 изображена Zсхема.
Рис. 3.31 Z-схема.
Спецификации Z представляют собой набор схем, где схемы представляют собой описания сущностей и связей между ними. Схемы, таким образом, обеспечивают среду для разработки спецификаций системы и их постепенного развития и уточнения.
На рис. 3.32 показана Z-схема для операции «выдача» (книги) в библиотеке, где общее поведение библиотеки как системы могло бы быть представлено с помощью схемы под названием «библиотека». Условное обозначение А Библиотека называется «дельта схема» и обозначает, что схема «выдача» вызывает изменение состояния в Библиотеке.
Рис. 3.32 Пример схемы.
Схема на рисунке 3.32 разделяет вход и выход, и состояние до и после. Эти операции обозначаются следующим образом:.
• ? - обозначает входящую переменную для операции;.
• ! - обозначает переменную на выходе операции.
Состояние после операции обозначается штрихом, например, учет, для отделения его от состояния до операции.
3.4 Заключение.
В главе были рассмотрены вопросы моделирования, в основном применительно к области решений. Были рассмотрены различные техники и методы, начиная с тех, которые уже прошли проверку временем, заканчивая теми, которые появились совсем недавно. Тем не менее, все рассмотренные методы и техники находят очень широкое практическое применение.
Материал представленный в данной главе обеспечивает основу для рассмотрения моделирования пользовательских и системных требованиях в последующих главах книги.