Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Краткая характеристика проектируемой системы).pdf

Для создания моделей анализа и проектирования объектно-ориентированных программ системы используют язык визуального моделирования. В качестве стандартного языка 3 поколения был принят Unifed Modeling Language (UML).

UML - стандартный язык для написания моделей анализа, проектирования и реализации объектно-ориентированных программных систем. UML может использоваться для визуализации, спецификации, конструирования и документирования результатов программных проектов. UML - это не визуальный язык программирования, но его модели прямо транслируются в текст на языках программирования ( JAVA,C++, Visual Basic, ADA 95 и т.д.).

Словарь UML реализуют три разновидности строительных блоков: предметы, отношения и диаграммы.

Предметы – это абстракции, которые являются основными элементами в модели, отношения связывают эти предметы, диаграммы группируют коллекции предметов.

В UML имеются 4 разновидности предметов:

1. Структурные предметы.

2. Предметы поведения.

3. Группирующие предметы.

4. Поясняющие предметы

Эти предметы являются базовыми объектно-ориентированными строительными блоками. Они используются для написания моделей.

Структурные предметы являются существительными в UML - моделях. Они представляют статические части модели - понятийные или физические элементы.

Перечисли восемь разновидностей структурных предметов:

1. Класс

2. Интерфейс

3. Кооперация (сотрудничество)

4. Актер

5. Элемент Use Case (прецедент)

6. Активный класс

7. Компонент

8. Узел

Предметы поведения – динамические части UML-моделей. Они являются глаголами моделей, представлением поведения во времени и пространстве. Существуют две основные разновидности предметов поведения: взаимодействие и конечный автомат. Эти 2 элемента являются базисными предметами поведения, которые могут включаться в UML- модели. Семантически эти элементы ассоциируются с различными структурными элементами (прежде всего с классами, кооперациями и объектами).

Группирующие предметы - организационные части UML-моделей. Это ящики, по которым может быть разложена модель. Предусмотрена только одна разновидность группирующего предмета - это пакет.

Поясняющие предметы – разъясняющие части UML- моделей. Они являются замечаниями, которые можно применить для описания, объяснения и комментирования любого элемента модели.

Предусмотрена только одна разновидность поясняющего предмета- это примечание.

2.2 Отношения в UML

В UML имеются четыре разновидности отношений:

1. Зависимость

2. Ассоциация

3.Обобщение

4. Реализация

Зависимость – семантическое отношение между двумя предметами, в котором изменение в одном предмете может влиять на семантику другого предмета (рисунок 3).

Рис. 3. – Обозначение зависимости.

Ассоциация – структурное отношение, которое описывает набор связей, являющихся соединением между объектами. Агрегация – это специальная разновидность ассоциации, представляющая структурное отношение между целым и его частями (рисунок 4).

Рис. 4. – Обозначение ассоциации.

Обобщение – отношение специализации/обобщения, в котором объекты специализированного элемента (потомка, ребенка) могут заменять объекты обобщенного элемента (предка, родителя). Иначе говоря, потомок разделяет структуру и поведение родителя (рисунок 5).

Рис. 5. – Обозначение обобщения.

Реализация – семантическое отношение между классификаторами, где один классификатор определяет контракт, который другой классификатор обязуется выполнять (к классификаторам относятся классы, интерфейсы, компоненты, элементы UseCase, кооперации). Отношения реализации применяют в двух случаях между интерфейсами и классами (или компонентами) реализующими их между элементами UseCase и кооперациями, которые реализуют их (рисунок 6).

Рис. 6. – Обозначение реализации.

2.3 Диаграммы в UML

Диаграмма – графическое представление множества элементов, наиболее часто изображается как связный граф из вершин (предметов) и дуг (отношении). Диаграммы рисуются для визуализации системы с разных точек зрения, затем они отображаются в систему. Обычно диаграмма дает неполное представление элементов, которые составляют систему. Хотя один и тот же элемент может появляться во всех диаграммах, на практике он появляется только в некоторых диаграммах. Теоретически диаграмма может содержать любую комбинацию предметов и отношений, на практике ограничиваются малым количеством комбинаций, которые соответствуют пяти представлениям архитектуры ПС. По этой причине UML включает девять видов диаграмм:

1.диаграммы классов;

2.диаграмма объектов

3.диаграммы Use Case (диаграммы прецедентов);

4.диаграммы последовательности;

5.диаграммы сотрудничества (кооперации);

6.диаграммы схем состояний;

7.диаграммы деятельности;

8.компонентные диаграммы;

9.диаграммы размещения (развертывания).

Диаграмма классов показывает набор классов, интерфейсов, сотрудничеств и их отношений.

Диаграмма объектов показывает набор объектов и их отношения.

Диаграмма Use Case показывает набор элементов Use Case, актеров и их отношений.

Диаграмма сотрудничества (диаграмма кооперации) - это диаграмма взаимодействия, которая выделяет структурную организацию объектов, посылающих и принимающих сообщения. Диаграммы последовательности и диаграммы сотрудничества изоморфны, что означает, что одну диаграмму можно трансформировать в другую диаграмму.

Диаграмма схем состояний показывает конечный автомат, представляет состояния, переходы, события и действия. Диаграммы схем состояний обеспечивают динамическое представление системы. Они особенно важны при моделировании поведения интерфейса, класса или кооперации. Эта диаграммы выделяют такое поведение объекта, которое управляется событиями, что особенно полезно при моделировании реактивных систем.

Диаграмма деятельности — специальная разновидность диаграммы схем состояний, которая показывает поток от действия к действию внутри системы. Диаграммы деятельности обеспечивают динамическое представление системы. Они особенно важны при моделировании функциональности системы и выделяют поток управления между объектами. Диаграмма деятельности для разрабатываемой системы изображена в приложении В.

Компонентная диаграмма показывает организацию набора компонентов и зависимости между компонентами. Компонентные диаграммы обеспечивают статическое представление реализации системы. Они связаны с диаграммами классов в том смысле, что в компонент обычно отображается один или несколько классов, интерфейсов или коопераций.

Диаграмма размещения (диаграмма развёртывания) показывает конфигурацию обрабатывающих узлов периода выполнения, а также компоненты, живущие в них. Диаграмма размещения обеспечивают статическое представление размещения системы. Они связаны с компонентами диаграммы в том смысле, что узел обычно включает один или несколько компонентов.

2.4 Формирование UML диаграммы классов

Диаграммой классов (Class diagram) называют диаграмму, на которой показано множество классов, интерфейсов, коопераций и отношений между ними. Ее изображают в виде множества вершин и дуг.

Диаграммы классов при моделировании объектно-ориентированных систем встречаются чаще других. На таких диаграммах показывается множество классов, интерфейсов, коопераций и отношений между ними.

Диаграмма классов используются для моделирования статического вида системы с точки зрения проектирования. Сюда по большей части относится моделирование словаря системы, коопераций и схем. Кроме того, диаграммы классов составляют основу еще двух диаграмм - компонентов и развертывания.

Диаграммы классов важны не только для визуализации, специфицирования и документирования структурных моделей, но также для прямого и обратного проектирования исполняемых систем.

Диаграммы классов обычно содержат следующие сущности:

1.классы;

2.интерфейсы;

3.кооперации;

4.отношения зависимости, обобщения и ассоциации.

Подобно всем остальным диаграммам, они могут включать в себя примечания и ограничения.

Также в диаграммах классов могут присутствовать пакеты или подсистемы, применяемые для группирования элементов модели в более крупные блоки. Иногда в эти диаграммы помещают, особенно если требуется визуализировать их тип (возможно, динамический).

Диаграмма классов для разрабатываемой системы изображена в приложении А.

2.5 USE CASE диаграмма

Основная цель создания хоть какой программной системы - создание такового программного продукта, который помогает юзеру делать свои ежедневные задачки. Для создания таких программ сперва определяются требования, которым должна удовлетворять система. Но если дать юзерам написать эти требования на бумаге, то нередко можно получить перечень функций, по которому тяжело судить, будет ли будущая система делать свое предназначение и сумеет ли она облегчить юзеру выполнение его работы вообщем. Неясно какие из выполняемых функций более важны и для кого.

Для того, чтоб более точно осознать как должна работать система, все почаще употребляется описание функциональности системы через варианты использования (Use Case либо прецеденты). Варианты использования это - описание последовательности действий, которые может производить система в ответ на наружные воздействия юзеров либо других программных систем. Варианты использования отражают функциональность системы исходя из убеждений получения важного результата для юзера, потому они поточнее позволяют ранжировать функции по значимости получаемого результата.

Варианты использования предусмотрены сначала для определения многофункциональных требований к системе и управляют всем процессом разработки. Все главные виды деятельности, такие как анализ, проектирование, тестирование производятся на базе вариантов использования. Во время анализа и проектирования варианты использования позволяют осознать как результаты, которые желает получить юзер, оказывают влияние на архитектуру системы и как должны себя вести составляющие системы, для того чтоб воплотить подходящую для юзера функциональность.

В процессе тестирования, описанные ранее варианты использования, позволяют проще оценить точность реализации требований юзеров и позволяют провести пошаговую проверку этих требований.

Стратегия использования прецедентов при определении требований определяет необходимость дополнительно к вопросу "что юзеры ожидают от системы?" задавать вопрос "что система должна сделать для определенного юзера?". Таковой подход позволяет находить функции, которые необходимы многим юзерам, и исключать те способности, которые не могут посодействовать юзерам делать свои ежедневные задачки.

Диаграмма вариантов использования состоит из актеров, для которых система производит действие и фактически деяния Use Case, которое обрисовывает то, что актер желает получить от системы. Актер обозначается значком человечка, а Use Case - овалом. Дополнительно в диаграммы могут быть добавлены комменты. Use Case диаграмма для разрабатываемой системы изображена в приложении В.

2.6 Дополнительные диаграммы, отображающие особенности программы

Основная цель создания хоть какой программной системы - создание такового программного продукта, который помогает юзеру делать свои ежедневные задачки. Для создания таких программ сперва определяются требования, которым должна удовлетворять система. Но если дать юзерам написать эти требования на бумаге, то нередко можно получить перечень функций, по которому тяжело судить, будет ли будущая система делать свое предназначение и сумеет ли она облегчить юзеру выполнение его работы вообщем. Неясно какие из выполняемых функций более важны и для кого.