Проектирование информационных систем. Раздел 5. Индустриальное проектирование информационных систем. Объектно-ориентированная Case-технология проектир

В случае подробного изучения клиентом спецификации приобретаемой продукции актер запросит у системы сервис подробного описания товара. На изучение подробного описания будет затрачен определенный промежуток времени, на протяжении которого выполнение основного прецедента приостановится.

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

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

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

Отношение включения, направленное от прецедента А к прецеденту В, указывает, что каждый экземпляр прецедента А включает в себя функциональные свойства прецедента В.

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

Рисунок 8 – Отношение включения

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

В качестве примера использования отношения включения можно привести создание сайта (рисунок 9). Так, его создание возможно только после проектирования его контента, что показано путем введения преце-

21

дента «Проектирование контента сайта» в базовый прецедент использования.

Рисунок 9 – Пример использования отношения включения

Отношение обобщения

Отношение обобщения служит для указания того факта, что некоторый прецедент A может быть обобщен до прецедента B. В

этом случае прецедент A будет являться потомком прецедента B, а B будет считаться предком или родителем прецедента A. Потомок наследует все свойства и поведение родителя и может быть дополнен новыми свойствами и особенностями поведения.

На диаграмме отношение обобщения представляется сплошной стрелкой, на конце которой располагается незакрашенный треугольник. Отношение обобщения всегда является направленным, указывая на родительский элемент, как показано на рисунке 10.

Рисунок 10 – Пример использования отношения обобщения между прецедентами

Отношение обобщения может возникать и между актерами. От-

ношение обобщения, направленное от актера A к актеру B, призвано отразить тот факт, что каждый экземпляр актера A является одновременно экземпляром актера B и обладает всеми его свойствами.

В этом случае актер B является предком или родителем по отношению к актеру A, а актер A – его потомком.

22

Рисунок 11 – Пример использования отношения обобщения между актерами

Рассмотрим отношение обобщения между актерами на примере системы продажи товаров, разработанной для функционирования в сети Интернет (рисунок 11). Разместить заказ посредством сайта может только зарегистрированный пользователь. Пользователь, не прошедший процедуру регистрации на сайте, может лишь просматривать каталог. Чтобы отразить на диаграмме тот факт, что зарегистрированный пользователь тоже имеет возможность просматривать каталог, введено отношение обобщения между актерами «Пользователь» и «Зарегистрированный пользователь».

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

Потоки событий

Поток событий – это последовательность событий, необходимых для обеспечения требуемого поведения. Поток событий описывается в терминах предметной области.

Поток событий включает:

•краткое описание;

•предусловия;

•основной поток событий;

•альтернативные потоки событий;

23

•постусловия.

Последовательно рассмотрим эти составные части.

Каждый прецедент использования должен иметь связанное с ним

описание того, что он будет делать.

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

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

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

новном и альтернативных потоках событий в форме неформальных текстовых комментариев. Основной поток событий приводит к требуемому результату наиболее коротким путем.

2.2. Диаграммы классов объектов

Диаграмма классов объектов (class diagram) служит для представ-

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

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

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

24

проработки отдельных компонентов диаграммы, описания классов дополняются атрибутами и методами (операциями) (рисунок 12).

Рисунок 12 – Графическое представление класса на диаграмме классов объектов

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

Класс может не иметь экземпляров или объектов. В этом случае он называется абстрактным классом, а для обозначения его имени используется наклонный шрифт (курсив).

Атрибуты – это значения, характеризующие объект в его классе, перечисляются в средней части прямоугольника, изображающего класс. Примерами атрибутов объектов класса «Файл» являются имя файла, дата и время создания, размер, метод доступа; класса «Человек» – имя, возраст, вес и т. д. Среди атрибутов выделяют постоянные (константы) и переменные атрибуты. Постоянные атрибуты характеризуют объект в его классе (например, номер счета, категория, имя человека и т. п.) и имеют неизменное значение. Значения переменных атрибутов характеризуют текущее состояние объекта (например, баланс счета, возраст человека); изменяя значения этих атрибутов, мы изменяем состояние объекта.

В языке UML принята определенная стандартизация записи атрибутов класса, которая подчиняется некоторым синтаксическим правилам.

25

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

<квантор видимости><имя атрибута> : <тип атрибута> Квантор видимости может принимать одно из трех возможных

значений и отображается при помощи специальных символов:

•public (общедоступный) – это значение видимости предполагает, что атрибут будет виден всеми остальными классами. Любой класс может просмотреть или изменить значение атрибута. В соответствии с нотацией UML, символ «+» обозначает атрибут с областью видимости типа «общедоступный».

•protected (защищенный) – атрибут с таким значением видимости доступен только самому классу и его потомкам. Нотация UML для защищенного атрибута – знак « # ».

•private (закрытый) – атрибут, недоступный другим классам. Закрытый атрибут обозначается знаком « – ».

Вместо условных графических обозначений можно записывать соответствующие ключевые слова: public, protected, private.

Квантор видимости может быть опущен. Его отсутствие означает, что видимость атрибута не указывается.

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

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

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

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

26

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

Примерами операций для класса «Файл» – создать, открыть_для_чтения, читать, переименовать, сохранить, закрыть (рисунок 13).

Запись операций класса в языке UML также стандартизована и подчиняется определенным синтаксическим правилам. При этом каждой операции класса соответствует отдельная строка, которая состоит из квантора видимости операции,

имени операции, типа возвращаемого операцией значения:

<квантор видимости> <имя операции (аргумент1 : тип данных аргумента1, аргумент2 : тип данных аргумента2...): <тип возвращаемого значения>

Квантор видимости, как и в случае атрибутов класса, может принимать одно из трех возможных значений и соответственно отображаться при помощи специального символа. Символ «+» обозначает операцию с областью видимости типа «общедоступный» (public). Символ «#» обозначает операцию с областью видимости типа «защищенный» (protected). Символ «–» используется для обозначения операции с областью видимости типа «закрытый» (private).

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

щие ключевые слова: public, protected, private.

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

27

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

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

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

•+создать() – может обозначать операцию по созданию отдельного объекта класса, которая является общедоступной и не содержит формальных параметров. Эта операция не возвращает никакого значения после своего выполнения;

•+нарисовать (форма: Многоугольник = прямоугольник, цвет_заливки: Color = (0, 0, 255)) – может обозначать операцию по изображению на экране монитора прямоугольной области синего цвета;

•запросить_счет_клиента (номер_счета : Integer): Currency – обозначает операцию по установлению наличия средств на текущем счете клиента банка. При этом аргументом данной операции является номер счета клиента, который записывается в виде целого числа. Результатом выполнения этой операции является некоторое число, записанное в денежном формате.

Отношения между классами

Объекты, отражаемые в диаграмме классов объектов, связываются статическими отношениями, которые отображают постоянные связи между объектами независимо от выполнения конкретного бизнес-процесса.

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

Отношение ассоциации

Отношение ассоциации соответствует наличию некоторого отношения между классами. Данное отношение обозначается сплошной линией с дополнительными символами, характеризующими отдельные свойства ассоциации. В качестве дополнительных символов может использоваться имя ассоциации, а также ее кратность. Имя ассоциации является необязательным элементом ее обозначения. Если оно задано, то записывается с заглавной буквы рядом с линией соответствующей ассоциации. Кратность отдельного класса обозначается в виде интервала це-

28

лых чисел. Интервал записывается рядом с концом ассоциации и для N- арной ассоциации означает потенциальное число отдельных экземпляров, которые могут иметь место, когда остальные N-1 экземпляров или значений классов фиксированы.

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

Наиболее простой случай данного отношения – бинарная ассоциа-

ция.

В качестве примера отношения бинарной ассоциации рассмотрим отношение между двумя классами – классом «Компания» и классом «Сотрудник» (рисунок 14). Они связаны между собой бинарной ассоциацией «Работа», имя которой указано на рисунке рядом с линией ассоциации. Кратность «1» для класса «Компания» означает, что каждый сотрудник может работать только в одной компании. Кратность «1..*» для класса «Сотрудник» означает, что в каждой компании могут работать несколько сотрудников, общее число которых заранее неизвестно и ничем не ограничено. Данная ассоциация является двунаправленной.

Рисунок 14 – Графическое изображение отношения бинарной ассоциации между классами

С точки зрения кодогенерации наличие на диаграмме отношения ассоциации указывает на возможность одного класса узнавать об общих атрибутах и операциях другого класса. Если ассоциация двунаправлен-

29

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

На рисунке 15 приведен пример однонаправленной ассоциации от класса «Законодательство» к классу «Гражданин». Так, «Гражданин» должен знать о «Законодательстве» и потому не может использоваться без него. Однако класс «Законодательство» не должен знать о «Гражданине» и потому допускает самостоятельное повторное использование. Однонаправленные отношения позволяют выявить классы, являющиеся кандидатами на повторное использование.

Рисунок 15 – Ассоциация, направленная от класса «Законодательство» к классу «Гражданин»

Отношение зависимости

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

Отношение зависимости используется в ситуации, когда некоторое изменение одного элемента модели может потребовать изменения другого (зависимого от него) элемента модели.

Рисунок 16 – Графическое изображение отношения зависимости на диаграмме классов

30