Моделирование и проектирование программного обеспечения Лекция 8. Реализация вариантов использования

Процесс разработки ПО определение требований – сбор данных о том, что должна делать система; анализ – уточнение и структурирование требований; проектирование – реализация требований в архитектуре системы; реализация (кодирование) – построение программного обеспечения; тестирование – проверяется, отвечает ли реализация предъявляемым требованиям; внедрение – передача ПО заказчику и организация его практического применения.

Реализация вариантов использования

Результаты анализа систем 1.Статическое моделирование – модель классов этапа анализа. – Модель классов анализа – это описание статической структуры системы. 2.Динамическое моделирование – реализации вариантов использования, показывает, как взаимодействуют экземпляры классов анализа для осуществления функциональности системы.

Цели разработчика при реализации вариантов использования 1.выяснить, взаимодействие каких классов анализа обеспечивает поведение, определенное вариантами использования; 2.выяснить, какими сообщениями должны обмениваться экземпляры этих классов для реализации заданного поведения.

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

Динамическое моделирование Два вида динамического моделирования 1.Моделирование не учитывающее состояние объектов. 2.Моделирование учитывающее состояние объектов (зависимое от состояния).

При реализации прецедентов в процессе анализа важно сосредоточиться на отражении – ключевых атрибутов, – операций и – отношений между классами анализа. На этом этапе не надо заниматься такими деталями, как параметры операций. – Эта информация будет раскрыта при проектировании. Также не надо реализовывать все варианты использования. Необходимо выбрать и проработать только самые основные.

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

Диаграммы взаимодействий Динамические модели – реализации вариантов использования описываются на языке UML в виде диаграмм взаимодействия. Используются две основные диаграммы взаимодействия: 1. диаграммы последовательностей; 2. диаграммы коммуникации;

Диаграммы взаимодействий Типы диаграмм взаимодействия: 1. диаграммы последовательностей; 2. диаграммы коммуникации;

Пример диаграммы последовательностей

Пример диаграмма последовательности (2)

Пример диаграммы коммуникации

Пример диаграммы коммуникации (2) Диаграмма последовательности, которая описывает взаимодействия, включающие вставку клиентом в Банкомат карточки и показа ему основного меню.

Диаграммы коммуникации Диаграммы коммуникации (communication diagrams) выделяют структурные отношения между объектами и очень полезны при анализе, особенно для создания эскиза совместной работы объектов. В UML 2 эти диаграммы предоставляют только лишь подмножество функциональности диаграмм последовательностей.

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

Сравнение диаграмм Диаграммы последовательностей (sequence diagrams) основное внимание уделяют на упорядоченности сообщений между участниками взаимодействия во времени. Диаграммы коммуникации (communication diagrams) основное внимание отображению связанности участников взаимодействия между собой.

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

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

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

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

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

Реальные экземпляры можно показать непосредственно на диаграмме взаимодействий. Используется обычная нотация для экземпляров: – символ модели с именем экземпляра, – селектор (если таковой имеется), – двоеточие и – имя классификатора; – все подчеркивается.

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

Когда участник посылает сообщение, то у него находится фокус управления (focus of control), или активация (activation). По мере развития взаимодействия во времени активация перемещается между участниками. Это движение называют потоком управления (flow of control). Сообщения отображаются в виде стрелок между – участниками или – между их линиями жизни (пунктирными вертикальными линиями).

Обозначения разных типов сообщений ОбозначениеНазваниеОписание - семантика Синхронное сообщение Отправитель ожидает завершения выполнения сообщения получателем. Асинхронное сообщение Отправитель посылает сообщение и продолжает исполнение – он не ожидает возврата от получателя. ВозвратПолучатель сообщения возвращает фокус управления отправителю этого сообщения. Создание объекта Отправитель создает экземпляр классификатора, определенного получателем. Уничтожение объекта Отправитель уничтожает получателя. Если у линии жизни есть «хвост», он завершается символом X.

Типы сообщений Выделяют следующие типы сообщений 1.синхронные сообщения - отправитель ожидает завершения выполнения получателем запрашиваемой операции. 2.асинхронные сообщения - отправитель ничего не ожидает, а переходит к следующему этапу. 3.сообщения возврата. 4.сообщения создания и уничтожения объектов.

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

Использование синхронных и асинхронные сообщений Некоторые методы (например, UP) предпочитают все сообщения отображать как синхронные, потому что это наиболее жесткий (не свободный) вариант. – Синхронные сообщения показывают прямую последовательность вызовов операций. Другие методы (например, MBD) предпочитают все сообщения отображать как асинхронные, потому что это наиболее общий вариант, на основе которого можно спроектировать разные системы. – Асинхронные сообщения указывают на возможный параллелизм. При проектировании различие между синхронными и асинхронными сообщениями может иметь значение для создания параллельных потоков управления.

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

Сообщения создания объектов Сообщение создания объекта обычно изображается как сплошная линия с открытой стрелкой. Создание объекта можно показать с помощью сообщения со стереотипом «create» (создать). Или можно послать конкретное именованное сообщение создания объекта, которое также может быть обозначено стереотипом «create».

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