17. Проектирование систем электронной коммерции. Основные этапы. Средства для создания компонентов систем электронной коммерции.

18. Описание систем электронной коммерции диаграммами прецедентов и классов

Диаграммы прецедентов.

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

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

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

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

1. Заполнить сведения об авторе.

2. Заполнить аннотацию.

3. Скопировать текст статьи в соответствующее окно.

4. Выполнить предварительный просмотр статьи.

5. Подтвердить публикацию.

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

Как мы уже видели, прецеденты можно уподобить подпрограммам, на которые разделяется объемная программа. Однако структура достаточно сложной программы редко бывает плоской, однородной. Обычно главная программа содержит вызов нескольких подпрограмм, те в свою очередь вызывают подпрограммы второго уровня и т.д. Аналогичным образом и прецеденты могут образовывать иерархическую структуру. Однако в отличие от подпрограмм, которые обычно образуют простое отношение типа "А вызывает В" (за исключением не столь часто встречающихся взаимно рекурсивных подпрограмм), отношения между прецедентами несколько сложнее и разбиваются на 3 категории: включение, расширение и обобщение. Включение При включении один прецедент явно включает в себя поведение другого прецедента в определенной точке потока событий. Если одна и та же последовательность действий встречается в нескольких прецедентах, имеет смысл не копировать ее каждый раз, а выделить ее в отдельный прецедент, который включают в себя несколько базовых прецедентов. Графически включение прецедента выглядит следующим образом: На данной диаграмме отражен факт, что и для чтения темы, и для публикации статьи нужно сначала пройти авторизацию на форуме, причем в обоих случаях авторизация выполняется одинаково. Поскольку графическая нотация диаграммы прецедентов не позволяет пометить точку базового потока событий, в которой производится включение, следует отразить это в описании сценария. Расширение Расширение выглядит аналогично включению, однако имеет иной смысл. Если при включении дочернего прецедента в базовый его поток событий копируется в поток событий базового прецедента, то при расширении поток событий дочернего прецедента представляет альтернативный сценарий, который выполняется при определенных условиях. На данной диаграмме прецедент "Edit article" расширяет прецедент "Publish article". Смысл этой конструкции заключается в следующем: при определенном условии, не отраженном на данной диаграмме (а именно - автор недоволен содержимым статьи и не намерен выставлять ее на общее обозрение), процесс публикации приостанавливается, и автор производит редактирование. Обобщение Если включение прецедента можно уподобить вызову подпрограммы, то обобщение скорее напоминает наследование объектов: производные прецеденты могут наследовать поведение базовых, при этом при необходимости уточняя либо переопределяя их поведение. Данная диаграмма сообщает нам, что поиск может осуществляться в двух вариантах: по автору либо по ключевым словам в теле сообщения. При этом оба прецедента являются вариантами базового прецедента "Search".

Диаграммы классов.

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

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

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

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

В первом случае для класса "Прямоугольник" (а) указаны только его атрибуты - точки на координатной плоскости, которые определяют его расположение. Для класса "Окно" (б) указаны только его операции, секция атрибутов оставлена пустой. Для класса "Счет" (в) дополнительно изображена четвертая секция, в которой указано исключение - отказ от обработки просроченной кредитной карточки.

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

Отношение зависимости (dependency relationship)

Отношение ассоциации (association relationship)

Отношение обобщения (generalization relationship)

Отношение реализации (realization relationship)

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

На диаграмме классов данное отношение связывает отдельные классы между собой, при этом стрелка направлена от класса-клиента зависимости к независимому классу или классу-источнику. На данном рисунке Класс_Б является источником некоторой зависимости, а Класс_А - клиентом этой зависимости.

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

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

"Компания" и "Сотрудник" связаны между собой бинарной ассоциацией Работа, имя которой указано на рисунке рядом с линией ассоциации. Для данного отношения определен порядок следования классов, первым из которых является класс "Сотрудник", а вторым - класс "Компания".

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

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

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

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

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

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

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

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