GrandM-Patterns_in_Java

вания называются основными ситуациями использования. Реже встречающиеся

ситуации называются второстепенными ситуациями использования. Опишем си­

туацию использования для часто встречающегося случая применения системы учета рабочего времени.

Ситуация использования: Сотрудник использует терминал учета времени.

сти приема данных от следующего со­ трудника

Рассмотрим менее детализированную ситуацию использования.

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

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

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

более позднее время. Чтобы сотрудники не имели такой возможности обмана

компании, необходимо добавить еще одно требование:

Rl.З. Разность показаний времени, отображаемых и записываемых раз­ ными терминалами, не должна превышать пять секунд.

Как только будут разработаны ключевые случаи ситуации использования, будут

найдены новые уточнения требований.

Объектн о - о р и ентированный анализ

Объектно-ориентированный анализ занимается построением модели пробле­

мы, подлежащей решению. Он отвечает на вопрос, что будет делать программ-

Глава 3. Жизненный цикл программного обеспечения - 49

ОСНОВНЫМ результатом объектно-ориентированного анализа является концеп-

1Уальная модель проблемы, описывающая предлагаемую систему и объекты реаль­ ного мира, с которыми система будет взаимодействовать. Кроме того, концеп­

туальная модель рассматривает отношения и взаимодействия между объектами

проблемной области, а также между объектами и системой.

Как правило, концептуальные модели создаются в два этапа:

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

2.Создание концептуальной модели для идентификации отношений между

объектами.

Для описания объектов и отношений концептуальной модели UML использует

ту же символику, которую он применяет при описании классов и ассоциаций в модели классов. На рис. 3.2 изображена диаграмма, содержащая (в произ­

вольном порядке) только те объекты, присутствие которых оБУСЛОRЛено требо­ ваниями и ситуациями использования. Изображенная на рис. 3.3 диаграмма со­ держит наиболее очевидные отношения.

PayPeriod

При внимательном рассмотрении рис. 3.3 можно обнаружить два объекта, ко­

торые не участвуют ни в одном из указанных отношений, это объекты

TimekeepingSystem и EmployeeID.

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

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

Объект EmployeeID очень тесно связан с объектом Employee. В таком случае его лучше представлять в виде атрибута. На рис. 3.4 представлена конuептуаль­ ная модель, в которую добавлены атрибуты.

Эта диаграмма отражает всю глубину проведенного нами анализа данной про­

блемы.

Объектн о - ор ие нтированное п р о е ктирование

Объектно-ориентированное проектирование занимается разработкой внутрен­

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

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

Рис. 3.4. Концептуальная модель с атрибутами

данных. Конечной целью объектно-ориентированного проектирования является

создание детального проекта классов, обеспечивающих эту внугреннюю логику.

Существуют различные стратегии использования результатов анализа при соз­

дании проекта. Стратегия, используемая в данной книге, заключается в созда­

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

МОдели. Затем разрабатываются диаграммы взаимодействия с целью моделирова­

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

дополняются требованиями, которые не были охвачены концептуальной моде­

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

СОбствующие достижению цели.

Создадим первую диаграмму классов, предполагая, что существует класс для

Представления каждого объекта концептуальной модели (рис. 3.5). Даннаяа диа­

грамма не представляет атрибутов объектов концептуальной модели, описы-

кработе со следующим служащим

вданной ситуации использования участвуют классы, которых нет на рис. 3.6.

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

проект класс пользовательского интерфейса.

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

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

Вводимый в проект класс-фасад называется TimekeepingController. Он от­ вечает за управление последовательностью событий во время взаимодействия терминала учета времени с пользователем.

На основании предыдущих ситуаций использования можно создать диаграмму взаимодействия (рис. 3.7).

Опишем взаимодействия, показанные на данной диаграмме.

1.Объект UserInterface начинает взаимодействие с передачи иден­

тификационного номера служащего методу doTransaction объекта

TimekeepingController.

1.1.Объект TimekeepingController получает информацию о со­ труднике, имеющем данный идентификатор, передавая иденти­

фикационный номер служащего методу LookupEmployee объекта Database. Метод LookupEmployee возвращает объект Employee,