Файл: Объектно-ориентированные методы анализа и проектирования ПО.pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 15.05.2023

Просмотров: 349

Скачиваний: 3

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

- объектная декомпозиция уменьшает риск создания сложных сис­тем ПО, так как она предполагает эволюционный путь развития системы на базе относительно небольших подсистем;

- объектная модель более естественна, так как ориентирована на человеческое восприятие мира, а не на ком­пьютерную реализацию;

- ОО-модель позволяет использовать в полной мере вырази­тельные возможности объектных и объектно-ориентированных языков программирования [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].