Моделирование объектно-ориентированных программного обеспечения с использованием uml

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

На этапе анализа ставятся две задачи: уточнить требуемое поведение разрабатываемого ПО и разработать концептуальную модель его предметной области с точки зрения поставленных задач.

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

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

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

Диаграммы использования.

Этот тип диаграмм определяет поведение системы с точки зрения пользователя и используется для выяснения требований к разрабатываемой системе. В русской литературе эта диаграмма часто называется диаграммой прецедентов или диаграммой вариантов использования.

В состав этих диаграмм входят элементы (эллипсы), актеры (человечки) и отношения (зависимости, обобщения и реализации).

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

Это может быть, либо пользователь, либо другое ПО, либо какое-то техническое средство.

Прецедент – описание последовательности действий, которые выполняются системой и производят для отдельного актера видимый результат. Один актер может использовать несколько элементов use-caseи наоборот, один элемент имеет несколько актеров.

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

Между элементами в диаграммах вариантов использования определены отношения обобщения специализации и две разновидности отношения зависимости, а именно включение и расширение. Если имеем включение, то над стрелкой пишется в угловых скобках [include], а если расширение, то над пунктирной линией пишетсяextend.

В случае включения стрелка направлена на включаемый элемент, а в случае расширения стрелка направлена на базовый элемент (рисунки 5,6,7).

Обобщение отношения (рисунок 5) фиксирует, что потомок наследует поведение родителя, кроме того, потомок может дополнить или переопределить поведение родителя. Элемент-потомок может замещать элемент-родитель в любом месте диаграммы.

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

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

На рисунке 8 приведен пример диаграммы use-caseс использованием отношений включения и расширения (показана диаграмма вариантов для банковской системы).

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

Элемент use-caseописывает, что должна делать система, но не определяет, как она должна это делать, при моделировании это позволяет отделить внешнее представление системы от ее внутреннего представления. Поведение элементаuse-caseописывается потоком событий, начальное описание выполняется в текстовой форме (понятной для пользователя), в потоке событий при таком описании выделяют основной и альтернативные потоки поведения, как и когда стартует и заканчивается элемент, когда элемент взаимодействует с актером, какими данными обмениваются актер и ассистент.

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

Каждая последовательность называется сценарием, сценарии называются для элементов почти тем же, чем являются объекты для классов. Говорят, что сценарии – экземпляр элемента use-case.

На рисунке 10 приведен пример диаграммы use-caseдля системы решения определенного класса задач. В этом примере действующее лицо у системы одно – пользователь (актер), который обращается к системе, либо для решения новой задачи, либо для просмотра результатов ранее решенной задачи, которые должны сохраняться в БД. Вариант выполнения заказа на самом деле включает несколько вариантов, которые различаются способом определения данных: ввод или чтение из базы, а также тем, сохраняются ли данные в базе помимо основных вариантов использования, система должна предусматривать дополнительные варианты использования для удаления лишних данных и результатов из базы.

Взять у Сережи. (проебано в героях)

Диаграммы классов.

ДК являются центральным звеном объектно ориентированных методов разработки ПО. Поэтому все существующие методы используют ДК в одной из известных нотаций. Однако в основном диаграммы классов в этих методах рименяют на этапе проектирования. В отличии от них UMLпредлагает использовать 3 уровня ДК в зависимости от степени их детализации.

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

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

3 уровень – это уровень реализации. На котором диаграммы непосредственно показывают особенности проектирования конкретных классов.

Фактически это 3 разные модели. Связь между которыми не всегда однозначна. Так если концептуальная (контекстная) модель определяет некоторые понятия предметной области как класс, то это не означает , что да реализации этого понятия будет использован отдельный класс. Однако во всех 3 моделях нас интересует тип объекта , то есть класса и их статические отношения, что позволяет использовать во всех 3 моделях единую систему обозначений (нотацию).

Каждая из перечисленных 3 моделей используется на конкретном этапе разработки ПО.

1. модель на этапе анализа

2. модель на этапе проектирования

3. на этапе реализации.

Основным понятием модели ставится в соответствие классы.

Рисунок № 1!

Различают на этапе анализа 2 основных вида отношений между классами. Ассоциация и обобщение.

Ассоциация означает наличие связи между экземплярами класса. Пример (стдент ассо-тся универ).

Ассоциация может иметь имя. Например обучается. Рядом с именем обычно ставится стрелка , которая показывает связь (заштрихованная стрелка – «студен обучается…»)

Связь между экземплярами подразумевает некоторые роли, которые, соответствующие объекты играют по отношению друг к другу направления ассоциации. Так по отношению к студенту институт это организация осуществляющая обучения. То есть роль институра - метсо обучения. Студент для универ – обучаеый. Если роль на диаграмме классов не указана, то етьс роль не имеет имени, то имя роли совпадает с именем класса.

Смотри рисунок (А и Б)

Роль так же обладает характеристиками – мощностью – сколько объектов может участвовать в одной связи с каждой стороны. * - от 0 до беск. N:* -диапазон.N– количество.N:1-N-2 – диапазон объектов. Рисунок 2.

Тип отношения обобщения. Обобщения означает что 2 класса находятся в таком отношении, что любой объект одного класса являестя обязательно объектом другого класса. Обозначается – Стрелка незакрещенная. И указывает стрелка на супер класс. Рисунок 3.

На 4 рис указана контекстная (концептуальная) ДК для программной системы, для решения комбинаторно-оптимизационных задач. Цели использования – это исполнение конкретного задания. Это система предназначена для реализации алгоритма решения задач 3х типов из класс комбинаторно-оптимизационных.

1 – это поиск минимальной длины, проход. Через все вершины графа.

2 – поиск крат пути

3 – поиск остового минимального дерева.

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

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

Композиция – это более сильная разновидность агрегации. Она показывает что объект часть может принадлежать только единственному целому. Объект-часть при этом создается и уничтожается только вместе со своим целым. Композиция предполагается физическое включение. Рисунок 2.В.

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

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

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

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

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

Полное описание операции на ДК в UMLможет выглядеть следующим образом – признак видимости, имя , список параметров в круглых скобках, двоеточие, тип возвращаемого. Ответственностью класс называют краткое , неформальное перечисление основных функций объектов классов. Ответственность классов обычно определяют на начальном этапе проектирования когда атрибуты и иена классов еще не определены. Эту информацию отображаются на ДК в спец секции условного обозначения. Рисунок 11.

Рисунок 7,8,9.

Помимо 2х основных видов отношения наследования и ассоциацию используется реализации и зависимости.

Зависимость является отношением использованием межу клиентов и поставщиком , не зависимым элементом. Обычно операции клиента либо вызывают операции поставщика , либо имею сигнатуры, в которых возвращаемые значения принадлежат классу поставщик. на 7 рисунку показана зависимость от класса книга . Тут книга используется в операциях проверка доступности, добавить , удалить. Вторая зависимость показывает, что просмотр заказ использует класс.. Отношение реализации это семантическое отношение между классами , в котором выполняет реализацию класса источника. На рисунке 8 показано, что класс каталог должен реализовать интерфейс обработчика каталога. Обработчик каталога рассматривается как источник а каталог как приемник. Перед каталогом ставится служебное слово interface– стереотип.

Подкласс может иметь несколько родителей это случай множественного наследования. НА рисунке 9 показан пример в котором подкласс 1 является наследником двух супер классов. Подклассом в таком случае достаются в наследство все свойства и операции двух классов родителей. Множественно наследование имеет множество подводных камней. Пример Классы главные: пирог и яблоко и подкласс – яблочный пирог. Это пример неправильного наследования.

Еще более сложная ситуацию когда потомки имеют одного общего родителя , в этом случае образуется ромбовидная решетка наследования рисунок 10.

4 типа диаграмм использования

ДиаграммК(до работы и после)

Диаграмма этапа анализа а дольше подробнее как на рисунках (фото)

Третий это что будет на след лекции (диагр Последовательности) и желательно показать 2 диаграммы основную и вспомогательную.

4 это диаграмма деательности (тоже желательно 2 основную и маклкую более бодрабную для какой то процедурки метода функции где реализуется что то интересное)