Файл: Объектно-ориентированные методы анализа и проектирования ПО.pdf
Добавлен: 15.05.2023
Просмотров: 350
Скачиваний: 3
СОДЕРЖАНИЕ
1. Объектно-ориентированные методы анализа и проектирования ПО
1.1 Основные принципы построения объектной модели
1.2 Основные элементы объектной модели
1.3 Преимущества и недостатки объектно-ориентированного подхода к проектированию
2. Методология объектного проектирования на языке UML
2.1 Унифицированный язык моделирования UML
2.2 Диаграмма вариантов использования (use case diagram)
2.3 Диаграмма классов (use case diagram)
2.4 Диаграммы взаимодействия (interaction diagrams)
3. Средства реализации объектно-ориентированного моделирования информационных систем
3.2 Sparx Systems Enterprise Architect
- объектная декомпозиция уменьшает риск создания сложных систем ПО, так как она предполагает эволюционный путь развития системы на базе относительно небольших подсистем;
- объектная модель более естественна, так как ориентирована на человеческое восприятие мира, а не на компьютерную реализацию;
- ОО-модель позволяет использовать в полной мере выразительные возможности объектных и объектно-ориентированных языков программирования [23.22., с.112].
К недостаткам объектно-ориентированного подхода можно отнести:
- усложнение методологии. Применение ООП требует введения дополнительных способов представления информации о предметной области и методов ее анализа. Язык UML включает более 100 различных условных обозначений. Для успешного использования подобного механизма требуется наличие определенного уровня квалификации у специалистов;
- сложность реализации. Объектно-ориентированные проекты и их программная реализация на объектно-ориентированном языке требуют больших временных затрат и приводят к построению более сложной и требовательной к ресурсам программы, нежели классические методы, которые могут оказаться более эффективными для некоторых задач [23.17., с.143].
2. Методология объектного проектирования на языке UML
2.1 Унифицированный язык моделирования UML
Отдельные языки объектно-ориентированного моделирования стали появляться с середины 1970-х г., когда различные исследователи и программисты выдвигали собственные подходы к объектно-ориентированному анализу и проектированию. В период 1989-1994 гг. число наиболее известных языков моделирования возросло с 10 до 50. Однако многие разработчики испытывали серьезные затруднения при выборе языка ООП, так как ни один из них не удовлетворял всем требованиям, предъявляемым к построению моделей сложных систем.
Решающую роль в создании универсального языка моделирования UML сыграли Гарди Буч, Айвар Джекобсон, Джеймс Рамбо и созданные ими методы моделирования различных сторон сложных систем [19., с.188].
UML (Unified Modeling Language — унифицированный язык моделирования) предназначен для визуализации, специфицирования, конструирования и документирования программных систем. Первая версия — UML 1.0 вышла в январе 1997 г. [16., с.201].
UML - это язык широкого профиля, он является открытый стандартом, использующим графические обозначения для создания абстрактной модели системы, которую зазывают UML-моделью. Язык UML был создан для определения, проектирования, визуализации, документирования, в большей степени программных систем. UML не является языком программирования, но на основании моделей UML с помощью современных Case-средств возможна генерация кода [2.].
Результатом совместной работы ведущих компаний в области проектирования ИС стала спецификация UML 1.0, вышедшая в январе 1997 г. В ноябре того же года за ней последовала версия 1.1, содержавшая улучшения нотации, а также некоторые расширения семантики. Последующие релизы UML включали версии 1.3, 1.4 и 1.5 до 2003 года.
UML 1.4.2 был принят в качестве международного стандарта ISO/IEC 19501:2005. Формальная спецификация последней версии UML 2.0 опубликована в августе 2005 г. Семантика языка была значительно уточнена и расширена для поддержки методологии Model Driven Development — MDD. Последняя версия UML 2.4.1 опубликована в августе 2011 г. и принята в качестве международного стандарта ISO/IEC 19505-1, 19505-2 [2].
Основные свойства языка UML:
1) Визуализация. Некоторые особенности системы лучше всего моделировать в виде текста, другие — графически. UML — графический язык, позволяющий решить такую проблему. За каждым из графических символов UML стоит хорошо определенная семантика.
2) Специфицирование — построение точных, недвусмысленных и полных моделей.
3) Конструирование. UML не является языком визуального программирования, но модели, созданные с его помощью, могут быть непосредственно переведены на различные языки программирования (Java, С++, Visual Basic, даже на таблицы реляционной БД или устойчивые объекты объектно-ориентированной базы данных) [4., с.32].
4) Документирование. UML позволяет решить проблему документирования системной архитектуры и всех ее деталей, предлагает язык для формулирования требований к системе и определения тестов, предоставляет средства для моделирования работ на этапе планирования проекта и управления версиями. Сфера применения UML не ограничивается моделированием ПО, выразительность языка позволяет моделировать и другие бизнес-процессы, например, документооборот, осуществлять проектирование аппаратных средств [16., с.202].
Язык UML имеет сложную иерархическую структуру, показанную на рис. 1 [19, с.189].
В основе языка лежат сущности (абстракции), которые связываются между собой отношениями; диаграммы группируют представляющие интерес совокупности сущностей.
В UML имеется четыре типа сущностей (рис.1).
Язык UML
Сущности:
1. Структурные
2. Поведенческие
3. Группирующие
4. Аннотационные
Отношения:
1. Зависимостей
2. Ассоциаций
3. Обобщений
4. Реализаций
Диаграммы:
1. Классов
2. Объектов
3. Прецедентов
4. Последовательностей
5. Коопераций
6. Состояний
7. Действий
8. Компонентов
9. Развертывания
Структурные
сущности:
1. Классы
2. Интерфейсы
3. Кооперации
4.Прецеденты
5. Активные классы
6. Компоненты
7. Узлы
Поведенческие
сущности:
1. Взаимодействия
2. Автоматы
Группирующие
сущности:
1. Пакет
Аннотационные
сущности:
1. Примечания
Рис.1 Структура языка UML
Понятие "структурные сущности" является именем семи видов пиктограмм (выразительных рисунков), которые называются классами, кооперациями, интерфейсами, активными классами, прецедентами, компонентами и узлами.
Поведенческие сущности делятся на два вида диаграмм: диаграммы первого вида называются взаимодействиями, второго вида - автоматами. Группирующие сущности имеют только один вид пиктограмм (пакеты), аннотационные сущности имеют один вид пиктограмм - примечания. Диаграмма в UML - это графическое представление набора элементов в виде связанного графа с вершинами (сущностями) и ребрами (отношениями) [4., с.38].
Изображение основных сущностей языка UML представлено в таблице 2 [16., с.203].
Таблица 2 - Описание сущностей языка UML
|
Наименование |
Описание |
Обозначение на диаграммах |
|
Класс (Class) |
Совокупность объектов с общими атрибутами, операциями, отношениями и семантикой. Класс реализует один или несколько интерфейсов |
Имя: Свойства Операции |
|
Интерфейс (Interlace) |
Совокупность операций, которые определяют сервис (набор услуг), предоставляемый классом или компонентом. Интерфейс описывает видимое извне поведение элемента и редко существует сам по себе |
I Имя |
|
Кооперация (Collaboration) |
Определяет взаимодействие и представляет собой совокупность ролей и других элементов, которые, работая совместно, производят кооперативный эффект |
|
|
Прецедент (Use case) |
Описание последовательности выполняемых системой действий, которая производит результат, значимый для какого-то определенного актера |
|
|
Актер (Actor) |
Набор согласованных ролей, которые могут играть пользователи при взаимодействии с ней. На UML-диаграммах пиктограммы прецедента и актера обычно располагаются рядом |
|
|
Активный класс (Active class) |
Класс, объекты которого вовлечены в один или несколько процессов, или нитей (Threads), и поэтому могут инициировать управляющее воздействие. Активный класс во всем подобен обычному классу, за исключением того, что его объекты представляют собой элементы, деятельность которых осуществляется одновременно с деятельностью других элементов |
Имя Свойства Операции |
|
Взаимодействие Interaction |
Поведение, суть которого заключается в обмене сообщениями между объектами в рамках конкретного контекста для достижения определенной цели |
Имя операции |
|
Автомат конечный State machine |
Алгоритм поведения, определяющий последовательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ на различные события |
Имя перехода Имя состояния |
В языке UML определены четыре типа отношений, описанные в таблице 3. Перечисленные элементы являются основными типами отношений, которые можно включать в модели UML. Существуют также их вариации, например уточнение (Refinement), трассировка (Trace), включение и расширение (для зависимостей) [9., с.191].
В рамках языка UML все представления о модели сложной системы фиксируются в виде специальных графических конструкций - диаграмм. При рассмотрении статических аспектов системы используются диаграммы классов, объектов, компонент и развертывания. Для работы с динамическими частями системы применяются диаграммы использования, последовательности, сотрудничества, состояний и деятельности.
Таблица 3 - Отношения в языке UML [16, с.207]
|
Наименование |
Описание |
Обозначение на диаграммах |
|
Зависимость (Dependency) |
Семантическое отношение между двумя сущностями, при котором изменение независимой может повлиять на семантику другой, зависимой |
|
|
Ассоциация (Association) |
Структурное отношение, описывающее совокупность связей. Разновидностью ассоциации является агрегирование (Aggregation) — между целым и его частями. Мощность ассоциации определяет количество объектов, соединяемых с объектами на другом конце: * — неограниченное количество; 1..* — один или более; 1..10 — заданный диапазон; 7 — точное количество |
1 * |
|
Обобщение (Generalization) |
Отношение «специализация/обобщение», при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка) |
|
|
Реализация (Realization) |
Встречается в двух случаях: между интерфейсами и реализующими их классами или компонентами, между прецедентами и реализующими их кооперациями |
В терминах UML определены следующие виды диаграмм [4., с.41]:
1) Диаграмма вариантов использования (использования, прецедентов) – use case diagram;
2) Диаграмма классов – class diagram;
3) Диаграммы поведения – behavior diagrams;
1. Диаграммы взаимодействия – interaction diagrams;
- Диаграмма последовательности – sequence diagram;
- Диаграмма сотрудничества (кооперации) – collaboration diagram;
2. Диаграмма состояний (переходов) – statcchart diagram;
3. Диаграмма деятельности (действий) – activity diagram;
4) Диаграммы реализации – implementation diagrams;
- Диаграмма компонентов – component diagram;
- Диаграмма развертывания (размещения, топологии) – deployment diagram.
Связь между диаграммами языка UML приведена на рисунке 2 [19, с.192].
Диаграммы компонент
Диаграммы последовательностей
Диаграммы использования
Диаграммы классов
Диаграммы переходов
Блоки использования
Диаграммы сотрудничества
Рис.2 Связь между диаграммами UML
Рассмотрим наиболее часто применяемые диаграммы для построения информационных систем.
2.2 Диаграмма вариантов использования (use case diagram)
Диаграмма вариантов использования или прецедентов в UML (usе casе diаgram) - это графическая модель (составная часть модели прецедентов, позволяющей описать систему на концептуальном уровне), отражающая отношения между актерами и прецедентами.
Прецедент — это возможность моделируемой системы, благодаря чему пользователь может получить конкретный и измеримый результат. Прецедент соответствует определенному сервису системы, определяет один из вариантов использования системы и описывает типичный способ ее взаимодействия с пользователем [14.].
Вариант использования представляет собой последовательность действии (транзакций), которые исполняются системой в ответ на событие, активизируемое неким внешним объектом (действующим лицом).
Действующее лицо (аctor) — это роль, которую пользователь играет по отношению к системе. Действующие лица делятся на: пользователей системы, другие системы, время, если от него зависит запуск событий [16, с.221].
Для вариантов использования и действующих лиц в UML поддерживается несколько типов связей:
1) связь коммуникаций (аssociation rеlationship) – это связь между вариантами использования и актером (действующим лицом);
2) включение (include rеlаtionship) – применяется в случаях, когда имеется фрагмент поведения системы, которая повторяется более чем в одном варианте использования;
3) связь с расширением (еxtend rеlationship) – применяется при наличии изменений в нормальном поведении системы, вносится также в отдельный вариант использования (рис. 3) [8., с.185];
Рис. 3. Примера связей
4) связь-обобщение (gеneralization relationship) служит для указания того, что некоторый вариант использования А может быть обобщен до варианта использования В (рис. 4) [19, с.194].