Составление описаний операций
Описания операций нужны для описания изменения состояния объектов предметной области после реакции системы на системные события. Системные события определяются в процессе составления СДП, эти события будут обрабатываться проектируемой системой в соответствующих системных операциях. Совокупность всех системных операций, реализуемых для всех прецедентов системы, называется открытым системным интерфейсом.
В процессе составления описания системных операций модель предметной области может изменяться и эволюционировать. Сами описания могут быть составлены неполно в рамках одной итерации и уточняться на последующих итерациях.
Рассмотрим шаблон описания системной операции.
Описание операции ОП№операции: имя операции
Операция Имя операции и её параметры.
Ссылки Прецеденты, в рамках которых может выполняться операция.
Предусловия Предположения о состоянии системы или объектов модели предметной области до выполнения операции.
Постусловия Состояние объектов модели предметной области после завершения операции.
Теперь в качестве примера составим описание операции для выделенного в предыдущем параграфе системного события takeCard.
Описание операции ОП1: takeCard
Операция takeCard(studentID:integer)
Ссылки Прецеденты: Получение билета
Предусловия Студент успешно зарегестрирован на экзамене и имеет идентификатор.
Постусловия - Создан экземпляр card класса Card (создание экземпляра).
- Атрибуту card.timeOfBegin присвоено значение time (модификация атрибута).
- Экземпляр card связан с классом CardDescriptor на основе соответствия идентификатора (номера) билета (формирование ассоциации).
- Атрибут pickCount экземпляра класса CardDescriptor,ассоциированного с экземпляром card, изменен (модификация атрибута).
- Экземпляр card связан с классом Student на основе соответствия идентификатора студента (формирование ассоциации).
В результате создания описания новые атрибуты были добавлены в модель предметной области (рис. 4).
Рисунок 4 - Модель предметной области
Результатом описания системных операций могут являться и более серьезные изменения модели предметной области: создание новых ассоциаций и концептуальных классов.
Реализация прецедентов
Реализация прецедентов предполагает построение модели проектирования с отображением двух аспектов взаимодействия: динамического и статического. Соответственно, будут использованы два вида диаграмм UML: диаграммы взаимодействий и диаграммы классов. Два вида диаграмм строятся параллельно для каждого прецедента и соответствующих этому прецеденту описаний операций. Начинать построение модели проектирования необходимо с диаграмм взаимодействий. Прецедент "Запуск системы" должен быть реализован последним (на самом деле в рамках итерационной разработки создается простая реализация прецедента запуска, которая обязательно уточняется после реализации каждого прецедента).
В рамках объектно-ориентированного проектирования предлагается использование метода распределения обязанностей (responsibility-driven design - RDD). Основными правилами или принципами для распределения обязанностей между взаимодействующими объектами являются GRASP (General Responsibility Assignment Software Patterns - Общие шаблоны распределения обязанностей в программных системах).
GRASP насчитывают девять принципов распределения обязанностей:
1. Information Expert (Информационный эксперт).
2. Creator (Создатель).
3. Controller (Контроллер).
4. Low Coupling (Слабая связанность).
5. High Cohesion (Сильное зацепление).
6. Polymorphism (Полиморфизм).
7. Pure Fabrication (Чистая выдумка).
8. Indirection (Посредник).
9. Protected Variations (Сокрытие реализации).
В рамках данного курсового проектирования требуется использовать первые пять принципов обязательно, оставшиеся четыре - только если к этому есть обоснованные на базе индивидуального задания предпосылки.