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

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

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

- утверждение общих стандартов (соглашений) моделирования и документирования системы;

- предварительное выявление архитектурных механизмов анализа;

- формирование набора основных абстракций предметной области (классов анализа);

- формирование начального представления архитектурных уровней.

Соглашения моделирования определяют:

- используемые диаграммы и элементы модели;

- правила их применения;

- соглашения по именованию элементов модели;

- организацию модели (пакеты).

При выполнении заданий, приведенных в лабораторных работах, будет использован следующий набор соглашений моделирования:

- имена вариантов использования должны быть короткими глагольными фразами;

- имена классов должны быть существительными, соответствующими понятиям предметной области;

- имена классов должны писаться с прописной буквы;

- имена атрибутов и операций должны писаться со строчной буквы;

- составные имена должны быть сплошными, без подчеркиваний, каждое отдельное слово должно писаться с прописной буквы;

- все классы и диаграммы, описывающие предварительный системный проект, помещаются в пакет с именем AnalysisModel;

- диаграммы классов, реализующие вариант использования, и диаграммы взаимодействия, отражающие взаимодействие объектов в процессе реализации сценариев варианта использования, помещаются в кооперацию с именем данного варианта использования и стереотипом << usecaserealization >>;

- все кооперации помещаются в пакет с именем UseCaseRealizations. Связь между вариантом использования и его реализацией изображается на специальной диаграмме трассировки.

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

Следуя этим рекомендациям, необходимо определить для системы классы анализа.

Анализ вариантов использования включает:

- идентификацию классов, участвующих в реализации потоков событий варианта использования;

- распределение поведения, реализуемого вариантом использования, между классами (определение обязанностей классов);

- определение атрибутов и ассоциаций классов;

- унификацию классов анализа.

Выполнение данной лабораторной работы будет включать в себя первые два этапа из приведенного выше списка, остальные будут рассмотрены при выполнении лабораторной работы № 10.

В потоках событий варианта использования выявляются классы анализа трех типов. Граничные классы (Boundary) – посредники при взаимодействии внешних объектов с системой. Как правило, для каждой пары "действующее лицо – вариант использования" определяется один граничный класс. Типы граничных классов: пользовательский интерфейс (обмен информацией с пользователем без деталей интерфейса: кнопок, списков, окон), системный интерфейс и аппаратный интерфейс (используемые протоколы без деталей их реализации).

Классы-сущности (Entity) – ключевые абстракции (понятия) разрабатываемой системы. Источники выявления классов-сущностей: ключевые абстракции, созданные в процессе архитектурного анализа, глоссарий, описание потоков событий вариантов использования.

Управляющие классы (Control) – обеспечивают координацию поведения объектов в системе. Могут отсутствовать в некоторых вариантах использования, ограничивающихся простыми манипуляциями с хранимыми данными. Как правило, для каждого варианта использования определяется один управляющий класс. Примеры управляющих классов: менеджер транзакций, координатор ресурсов, обработчик ошибок.

Исходя из назначения трех выделенных типов классов, можно кратко охарактеризовать распределение обязанностей между ними:

- граничные классы отвечают за взаимодействие с внешней средой системы (действующими лицами);

- классы-сущности отвечают за хранение данных и манипулирование ими;

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

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

Разработка структуры модели и классов анализа в соответствии с требованиями архитектурного анализа включает:

1. Создание пакетов (команда New ® Package пакета UseCaseRealizations, входящего в пакет DesignModel логического представления) и создание диаграмм трассировки.

2. Создание в каждом из пакетов типа UseCaseRealization соответствующих коопераций (каждая кооперация создается как вариант использования со стереотипом << usecaserealization >>.

3. Создание новой диаграммы вариантов использования с названием RealizeDependency в каждом из пакетов типа UseCaseRealization и размещение на них соответствующих кооперации и варианта использования.

4. Создание классов анализа, которое выполняется в пакете AnalysisModel логического представления браузера (New ® Class).

5. Создание соответствующей диаграммы KeyAbstractions в пакете AnalysisModel (New ® ClassDiagram) путем перемещения уже созданных классов на открытую диаграмму мышью.

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

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

Более детальное распределение обязанностей (в виде операций классов) выполняется с помощью диаграмм взаимодействия: диаграммы последовательности и/или кооперативной диаграммы.

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

Этапы создания диаграммы последовательности и кооперативных диаграмм:

1. Установить переключатели SequenceNumbering, Collaboration Numbering, а переключатель FocusOfControl – выключить (меню Tools ® Options на вкладке диаграмм).

2. В кооперации пакета UseCaseRealization выполнить команду New ® Sequence Diagram.

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

4. Добавить сообщения с помощью кнопки панели инструментов ObjectMessage.

5. Соотнести сообщения с операциями (пункт контекстного меню сообщения NewOperation), при этом в классах автоматически появляются операции анализа.

6. На диаграмму может быть добавлено примечание (кнопка Note) и/или текстовая область (кнопка TextBox).

7. Создать кооперативную диаграмму, аналогичную текущей диаграмме последовательности, можно с помощью клавиши F 5.

Основные элементы диаграммы последовательности (Sequence Diagram)

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

Линия жизни объекта (ObjectLifeline) служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях.

Фокус управления (FocusOfControl) используется для выделения активного состояния объекта, в течение которого непосредственно выполняются определенные действия.

Актер (Actor), который является инициатором взаимодействия.

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

Ветвление позволяет изобразить более сложную логику взаимодействия объектов между собой.

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

Задание к выполнению

В соответствии с вариантом, определяющим предметную область, продолжить разработку моделей анализа вариантов использования, дополнив их для анализа не менее трех вариантов использования следующими элементами:

1. Диаграммами трассировки.

2. Диаграммами последовательности.

3. Диаграммами классов с операциями анализа.

4. Диаграммами кооперации.

Контрольные вопросы

1. Что включают в себя архитектурный анализ и анализ вариантов использования?

2. Что определяют соглашения моделирования. Какой набор соглашений моделирования используется при выполнении заданий?

3. Каким образом определяется набор классов анализа системы?

4. Идентификация классов анализа?

5. Распределение обязанностей между классами?

6. Назначение диаграмм трассировки?

7. Какие этапы включает разработка структуры модели и классов анализа в соответствии с требованиями архитектурного анализа?

8. Назначение и виды диаграмм взаимодействия?

9. Назначение основных элементов диаграммы последовательности?

10. Временные оси диаграммы последовательности, линия жизни объекта и фокус управления?

11. Виды сообщений на диаграммах последовательностей, использование ветвления потока управления и стереотипов сообщений?

12. Особенности использования диаграмм кооперации и назначение их основных элементов?

Дата добавления: 2017-01-14