2.5.4Моделирование документов и бизнес-сущностей

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

Для описания документов используются следующие элементы:

• производственная сущность (business entity),

• отношение ассоциации (association),

• отношение агрегации (aggregation),

• о тношение обобщения (generalization).

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

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

2.6Использование бизнес-модели на этапах разработки

Результатом бизнес-моделирвания в UML является высокоуровневая визуальная модель, позволяющая обозначить рамки системы, ключевые функции и ввести наиболее важные бизнес-классы.

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

Диаграммы бизнес-функций и бизнес-классов используются параллельно и поочерёдно играют роль “лидера гонки” в рамках последовательных итераций жизненного цикла разработки.

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

С ледующие разделы конспекта относятся к логическому моделированию, то есть к проектированию информационной системы в представлении Logical View.

2.7Диаграмма вариантов использования – use case diagram

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

Суть диаграммы вариантов использования состоит в том, чтобы представить систему в виде множества основных сервисов, которые должны быть включены в систему (use cases), их окружения (actors) и взаимодействия сервисов с окружением.

Актёр (actor) – это любая сущность, взаимодействующая с системой извне.

Вариант использования (use case) – документ, содержащий описание отдельного сервиса, который система предоставляет актёру.

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

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

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

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

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