2.2Моделирование системы по методологии UML
Унифицированный язык моделирования (Unified Modeling Language, UML) является графическим языком для визуализации, специфицирования, конструирования и документирования систем, в которых большая роль принадлежит программному обеспечению [4]. С помощью UML можно разработать детальный план создаваемой системы, содержащий не только ее концептуальные элементы, но и конкретные особенности, например классы, написанные на специальных языках программирования, схемы баз данных и программные компоненты многократного использования.
UML пригоден для моделирования любых систем: от информационных систем масштаба предприятия до распределенных Web-приложений и даже встроенных систем реального времени. Это очень выразительный язык, позволяющий рассмотреть систему со всех точек зрения, имеющих отношение к ее разработке и последующему развертыванию. Несмотря на обилие выразительных возможностей, этот язык прост для понимания и использования.
Язык состоит из словаря и правил, позволяющих комбинировать входящие в него слова и получать осмысленные конструкции. В языке моделирования словарь и правила ориентированы на концептуальное и физическое представление системы.
Моделирование необходимо для понимания системы. При этом единственной модели никогда не бывает достаточно. Напротив, для понимания любой нетривиальной системы приходится разрабатывать большое количество взаимосвязанных моделей. В применении к программным системам это означает, что необходим язык, с помощью которого можно с различных точек зрения описать представления архитектуры системы на протяжении цикла ее разработки.
Словарь и правила такого языка, как UML, объясняют, как создавать и читать хорошо определенные модели, но ничего не сообщают о том, какие модели и в каких случаях нужно создавать. Это задача всего процесса разработки программного обеспечения.
Некоторые особенности системы лучше всего моделировать в виде текста, другие – графически. На самом деле, во всех сложных системах существуют структуры, которые невозможно представить с помощью одного лишь языка программирования. UML – графический язык, что позволяет понимать его людям, не являющимся специалистами в области ИТ и программирования.
UML позволяет специфицировать все существенные решения, касающиеся анализа, проектирования и реализации, которые должны приниматься в процессе разработки и развертывания системы программного обеспечения. В данном контексте специфицирование означает построение точных, недвусмысленных и полных моделей.
UML не является языком визуального программирования, но модели, созданные с его помощью, могут быть непосредственно переведены на различные языки программирования. Иными словами, UML-модель можно отобразить на такие языки, как Java, C++, Visual Basic, и даже на таблицы реляционной базы данных или устойчивые объекты объектно-ориентированной базы данных. Те понятия, которые предпочтительно передавать графически, так и представляются в UML; те же, которые лучше описывать в текстовом виде, выражаются с помощью языка программирования.
Помимо прямого отображения в языки программирования UML в силу своей выразительности и однозначности позволяет непосредственно исполнять модели, имитировать поведение систем и контролировать действующие системы.
2.2.1Описание бизнес-логики процесса заказа товара
Прежде, чем приступить к моделированию системы на языке UML, необходимо понять, что именно она должна автоматизировать, и убедиться, что разработчик БД получил полную информацию о соответствующей бизнес-логике.
Процесс заказа товара включает следующие этапы:
Размещение заказа клиентом. Заказ может включать несколько товарных позиций. Система принимает заказ через веб-интерфейс. Необходима поддержка функций добавления и удаления товаров в заказ, изменения количества, выбора способа получения (доставка или самовывоз), способа оплаты (наличными при получении или безналичный перевод), подсчета общей стоимости товара. При регистрации заказа клиент указывает необходимые контактные данные: ФИО, телефон, email, адрес.
Заказ регистрируется в системе и передается менеджеру по продажам. Менеджер проверяет наличие товара на складе через ИС и согласовывает заказ с клиентом. Клиент может в любой момент отменить заказ, связавшись с менеджером по телефону или email.
После успешного согласования заказа товар резервируется на складе. Клиенту отправляется уведомление о готовности заказа к отгрузке с напоминанием об оплате.
-
Клиент оплачивает товар:
В кассе при получении в пункте выдачи.
Наличными курьеру при доставке.
Безналичным переводом.
-
После подтверждения оплаты (автоматически при получении денежных средств или после предъявления клиентом документа об оплате) товар отгружается со склада:
В пункт выдачи товара.
Службе доставки.
Клиенту направляется сообщение о готовности товара к получению.
-
Клиент получает товар:
В пункте выдачи товара.
На руки от курьера.
Если клиент по каким-то причинам не получил товар или отказался от покупки, товар возвращается на склад, а заказ отменяется с указанием причины. Клиенту направляется уведомление об аннулировании заказа. Возврат полученного товара и денежных средств выходит за рамки разрабатываемой системы.
Таким образом, в процессе заказа товара можно выделить следующие основные сущности:
субъекты взаимодействия:
клиент;
менеджер;
склад, включая ИС складского учета;
пункт выдачи;
служба доставки;
система безналичной оплаты;
объекты:
Основные операции, совершаемые в процессе обработки заказа товара:
регистрация заказа;
согласование заказа менеджером;
резервирование товара на складе;
оплата заказа клиентом;
отгрузка товара складом;
передача товара в пункт выдачи;
доставка товара клиенту;
получение заказа клиентом;
отмена заказа;
возврат товара на склад.
Основные действия, выполняемые непосредственно в системе:
регистрация заказа;
проверка наличия товара;
резервирование товара;
отметка об оплате заказа;
отметка о получении товара;
отмена (аннулирование) заказа;
отправка клиенту уведомлений о состоянии заказа.
Таким образом, часть операций, связанных с заказом товара, выходит за рамки разрабатываемой ИС. Это операции, связанные с обработкой платежей, логистикой и складским учетом.
2.2.2Диаграмма вариантов использования
Диаграмма вариантов использования (Use Case) применяется для описания функциональных требований к системе, ролей пользователей, а также определения границ системы. Диаграмма вариантов использования составляется, как правило, в ходе этапов анализа предметной области и постановки задачи. Это удобный инструмент описания бизнес-логики системы, ее основного назначения и взаимодействия с внешними сущностями.
Основными объектами на диаграмме являются действующие лица (актеры, actors), прецеденты (варианты использования, use case) и связи между ними.
Актер представляет собой человека, внешнюю систему или любого другого активного субъекта, который взаимодействуют с системой и использует ее. На диаграмме актер изображается в виде человечка. Примеры актеров:
пользователь системы;
системный администратор;
клиент;
сотрудник;
отдел кадров;
время (системный таймер);
операционная система;
внешняя база данных.
Прецедент описывает некоторое действие, которое актер (или несколько актеров) может выполнить в системе. Прецеденты обозначаются на схеме овалами и описываются глаголами либо отглагольными существительными с зависимыми словами. Например, «Внести сведения о сотруднике организации», «Покупка товара», «Ввод пароля», «Печать годового отчета».
На диаграмме Use Case используются следующие виды связей: ассоциация, направленная ассоциация, обобщение, зависимость, включение, расширение.
Ассоциация (assotiation) изображается сплошной линией без стрелки и чаще всего используется для связей между актером с одной стороны и прецедентом с другой. Она не имеет направления и показывает, что данный прецедент выполняется данным актером.
Направленная ассоциация (directed assotiation) показывается сплошной линией со стрелкой и является частным случаем обычной ассоциации. Она применяется, когда нужно указать направление связи. Например, при вводе данных можно поставить направление ассоциации от пользователя к системе, а при выводе – наоборот.
Обобщение (generalization) показывается сплошной стрелкой в виде пустого треугольника. Обобщение может связывать актера с актером или вариант использования с вариантом использования и показывает, что одно является более общим случаем другого. Стрелка ведется от частного к общему. Например, актер «Пользователь» является обобщением для актеров «Администратор» и «Гость». Вариант использования «Оплата» обобщает «Оплату в кассе» и «Безналичный перевод», а «Оплата в кассе», в свою очередь, обобщает «Оплату наличными» и «Оплату банковской картой».
Зависимость (dependency) изображается пунктирной линией со стрелкой. Она показывает, что один вариант использования зависит от другого. Например, «Выдача товара» зависит от «Выбора товара» и «Оплаты». Однако, зависимости на схеме обычно не показывают, если они достаточно очевидны.
Включение (include) и расширение (дополнение, extend) близки по смыслу и показываются пунктирной линией со стрелкой и соответствующей надписью в угловых скобках. Включение означает, что один вариант использования обязательно содержит в себе другой, как один из этапов выполнения, и связь ведется от целого к части. Например, «Авторизация пользователя» включает «Ввод пароля» и «Ввод имени пользователя» (пропустить их нельзя).
Расширение показывает, что один вариант использования дает дополнительные возможности другому, связь ведется от дополнения к основному. Например, «Геопозиционирование» расширяет вариант использования «Ввод адреса» (но не обязательно используется).
Для описания сложных проектов, как правило, недостаточно одной диаграммы вариантов использования (или она будет слишком большой). Разные диаграммы могут показывать систему на разных уровнях (вся система целиком и ее отдельные части) или с разных точек зрения (бизнес-логика, автоматизация, программное обеспечение, аппаратное обеспечение и др.).
Диаграмма, показывающая бизнес-логику процесса заказа товара показана на рисунке . Основные актеры – менеджер и клиент. На диаграмме показаны внешние актеры, с которыми взаимодействует система, и ее границы. Варианты использования, которые находятся за границами системы, закрашены серым.
На рисунке показана диаграмма вариантов использования с точки зрения работы информационной системы. Здесь представлена только внутренняя логика работы системы и ее пользователи.
System
Менеджер
Регистрация
заказа
Провека наличия
товара на складе
Клиент
Согласование
заказа
Склад
Подтверждение
оплаты
Резервирование
товара
Отмена
резервирования
Отметка об
отгрузке товара
Отметка о
получении
Получение
товара
Служба доставки
Доставка товара
Передача товара в
службу довтавки
Оплата товара
Отгрузка товара
Указание причины
возврата
Получение в
пункте выдачи
Пункт выдачи
Передача товара
в пункт выдачи
Отмена заказа
Наличными при
получении
Безналичный
перевод
<>
Рис. . Диаграмма вариантов использования, описывающая бизнес-логику процесса заказа товара
Пользователь
Менеджер
Администратор
Авторизация
Управление
пользователями
Архивация и
восстановление
Ведение
справочников
Клиент
Создание заказа
Выбор товара
Расчет суммы
заказа
Редактирование
заказа
<>
<>
<>
<>
Система
складского учета
Резервирование
товара
Отметка об
отгрузке товара
Отметка о
получении
Провека наличия
товара на складе
Отмена
резервирования
Ввод сведений
о клиенте
<>
<>
Отмена заказа
Указание причины
отмены
<>
Выбор формы
оплаты
<>
<>
Выбор способа
получения
<>
<>
Отправка сообщения
о состоянии заказа
<>
<>
<>
Утверждение
заказа
<>
Рис. . Диаграмма вариантов использования, описывающая бизнес-логику процесса заказа товара
2.2.3Диаграмма классов
Диаграммы классов при моделировании объектно-ориентированных систем встречаются чаще других. На таких диаграммах показывается множество классов, интерфейсов, коопераций и отношений между ними.
Класс – это множество однотипных объектов, обладающих общим набором свойств (атрибутов) и методов поведения. Описание класса содержит стереотип, название, перечень атрибутов и перечень методов (операций). Любая часть описания (кроме названия) может быть пропущена. На схеме классы показываются в виде прямоугольников, разделенных на три части: заголовок, атрибуты и методы.
Между классами могут присутствовать следующие виды связей:
ассоциация;
обобщение;
агрегация;
композиция;
зависимость.
Ассоциация, обобщение и зависимость имеют тот же смысл, что и на диаграмме вариантов использования.
Агрегация означает, что один класс является составной частью другого. Пример: двигатель является частью автомобиля, студент является частью группы.
Композиция – частный случай агрегации. В этом случае часть не может существовать без целого. Пример: факультет является частью вуза и не может существовать без него.
Классы по своей роли в системе делятся на группы. Сам по себе язык UML жестко не оговаривает эти группы, оставляя группировку на усмотрение разработчиков. На основе опыта, накопленного при создании автоматизированных систем, целесообразно выделить следующие группы (категории, стереотипы) классов:
граничные (boundary) классы;
сущностные (entity) классы;
классы управления (control);
классы прикладной логики (logic).
Объекты сущностных классов представляют собой блоки длительно хранимой информации, используемые для организации баз данных и баз знаний, файловых систем хранения данных различной логической структуры. В основном в этих классах развит атрибутный раздел, однако, имеется небольшое число операций контроля ограничений целостности как стандартных, так и специфичных для данной предметной области.
На диаграмме сущностных классов чаще всего используются связи-ассоциации с указанием кратности на каждой стороне связи:
1 – один;
0..1 – ноль или один (необязательная связь);
* – много;
0..* – ноль или много (необязательная связь);
1..* – один или много (как минимум один);
любое конкретное число или диапазон значений.
На рисунке представлена диаграмма сущностных классов разрабатываемой ИС.
Рис. . Диаграмма сущностных классов
На диаграмме присутствует семь основных классов, а также один ассоциативный класс «Получение статуса». Классы «Форма оплаты» и «Способ получения» соответствуют справочникам системы (содержат редко изменяемые данные).
|
