Лабораторная работа №4

(4 часа)

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

1. Представление логики взаимодействия объектов предметной области: классы, объекты, свойства и поведение объектов.

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

3. Инкапсуляция логики управления в управляющем классе: реализация контроля согласованности поведения управляемых объектов соответствующими методами.

4. Инкапсуляция логики управления в управляющем классе: ограничение доступа к инкапсулированным объектам для обеспечения контроля согласованности поведения управляемых объектов.

5. Инкапсуляция логики управления в управляющем классе: организация доступа к элементам инкапсулированного списка по ссылке.

6. Применение паттерна «одиночка» при реализации управляющего объекта.

3.2. Требования к объектно-ориентированной модели
предметной области

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

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

Для реализации указанной выше функциональности между объектами SuitorManager (менеджер поклонников) и Suitor (поклонник) определены две ассоциации.

1. Ассоциация управления менеджером списком поклонников. Один менеджер может управлять любым количеством поклонников, один поклонник может быть управляем только одним менеджером.

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

Рис. 1. Расширенная концептуальная диаграмма классов.

Чтобы гарантировать согласованность состояний множества поклонников, управляющий класс должен контролировать его формирование (реализуя операции добавления AddSuitor и удаления DeleteSuitor поклонника), а также доступ к его элементам (реализуя операции поиска поклонника по идентификационному номеру FindSuitorById, имени FindSuitorByName и индексу FindSuitorByIndex). При этом должны быть исключены любые другие способы изменения множества поклонников.

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

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

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