Разработка диаграммы классов

Классы системы в процессе проектирования, как правило, определяются индуктивно: первоначально определяются объекты, которые должны быть вовлечены в процесс функционирования системы, а затем, «отталкиваясь» от объектов, определяются соответствующиеклассы. Формально этот процесс может быть квалифицирован как«обобщение», или «абстракция». Таким образом, диаграмме классовсогласно индуктивной концепции должна предшествовать диаграммаобъектов, но эта диаграмма используется редко.

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

Если вербальное описание предметной области естественнымобразом сводится к описанию состояний сущностей, их состоянийи связанных с состояниями действий, то объекты ИС легко выявляются в процессе построения диаграммы бизнес-прецедентов и соответствующих детализирующих диаграмм автомата. Каждый автоматизначально «прикрепляется» к объекту, кооперации, реже – к методуобъекта. Множество бизнес-исполнителей и бизнес-сущностей легкотрансформируется в множество объектов ИС.

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

В этом случае «на помощь приходят» диаграммы взаимодействиякоммуникации или последовательности, которые следует строитьпо несколько штук для каждого прецедента. Количество диаграммвзаимодействия теоретически ограничено совокупным количествомветвей в диаграммах деятельности, но оно существенно сокращаетсяза счет использования в них алгоритмических элементов – составныхшагов взаимодействия (combinedfragment), заимствованных UMLиз другого графического языка описания поведения – MSC (MessageSequenceChart), разработанного и успешно применяемого производителями встроенных информационно-вычислительных систем.

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

На рис. 18.3 приведен пример диаграммы последовательности, построенной для прецедента «Обслуживание клиента».

Рисунок 18.3. Диаграмма последовательности

для прецедента «Обслуживаниеклиента»

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

Наряду с объектами «Сотрудник» и «Клиент» в диаграмме последовательности определены системные объекты-формы. Формыхотя и представляют определенный интерес, являются достаточноочевидной и вторичной – реализационной – деталью. На этапеформулировки требований внимание следует сосредоточить на объектах, семантически более близких к предметной области.

Рассматривая диаграмму, можно обнаружить завуалированные, но оченьважные объекты. В первом же сообщении, посылаемом от сотрудникак клиенту, содержится тип возвращаемого значения «Фильм» – этоявно объект. Поскольку «Фильм» – это явно составная конструкция, то эти части целесообразно выделить в отдельные объекты, такие как«Жанр», «Режиссер», «Носитель».

Кроме того, сообщения «ОформитьЗаказ» и «ОформитьВыдачуФильма» предполагают наличие носителя информации, на которомбудут размещаться сведения о заказе и факте выдачи фильма. Такимносителем может быть объект с условным именем «Прокат».

Построив диаграммы последовательности для других прецедентов, перенеся имена выделенных объектов на классы и установивотношения между ними, можно получить диаграмму классов, представленную на рис. 18.4.

Обратим внимание на следующие факты. Классы «Клиенты», «Сотрудники» и «Фильм» относительно самостоятельны – объекты этихклассов могут создаваться по мере появления их новых физическиханалогов, т. е. при появлении нового клиента, нового сотрудниканового фильма.

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

Рисунок18.4. Диаграмма классов для прецедента «Обслуживание клиента»

Объекты классов «Жанр», «Режиссер», «Носитель» отличаютсятем, что создаются, в первую очередь, для использования в качествесоставных частей объектов класса «Фильм». По этой причине отношение между классами «Жанр», «Режиссер», «Носитель» и классом «Фильм» следует установить в виде агрегации или композиции.

На диаграмме (рис. 18.4) представлено конкретное проектноерешение – назначено отношение агрегации, предполагающее возможность самостоятельного создания объектов классов «Жанр», «Режиссер», «Носитель» и возможность существования объектов этихклассов, не связанных с объектами класса «Фильм».

Конечно же, определения указанных классов можно было бы непосредственно включить и в класс «Фильм». Тогда имело бы местоотношение композиции. Это вполне приемлемое проектное решение, но оно ограничивает перспективы развития системы. Например, возможно, что в будущем магазин, занятый прокатом фильмоввовлечет в бизнес-процесс прокат аудиокниг. Тогда классы «Жанр» и «Носитель» будут объединяться еще с одним классом – «Книга».

Такое объединение осуществляется легко, если объекты классов«Жанр» и «Носитель» могут создаваться самостоятельно и вступатьв агрегацию с объектами любых других классов.

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