3.5.3.Применение модели msc uml
UML (Unified Modeling Language) – это унифицированный язык моделирования. UML представляет собой формальный искусственный язык, который постоянно развивается. Описание UML [3] по большей части формальное, но содержит и явно неформальные составляющие, что заметно отличает его от языков, которые, по общему мнению, являются образцами формализма. UML предназначен для моделирования. Сами авторы UML определяют его как графический язык моделирования общего назначения, предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых при разработке приложений.
Для общего представление функционального назначения системы в UML предназначены диаграмма использования (use case). Диаграмма использования призвана ответить на вопрос: что делает система во внешнем мире?
На диаграмме использования применяются два типа основных сущностей: варианты использования и действующие лица, между которыми устанавливаются следующие основные типы отношений:
ассоциация между действующим лицом и вариантом использования;
обобщение между действующими лицами;
обобщение между вариантами использования;
зависимости (различных типов) между вариантами использования.
Кроме того, на диаграмме использования можно применить специальный графический комментарий – обозначить границу системы (действующие лица находятся снаружи, а варианты использования – внутри). Нотация для варианта использования – это имя, помещенное в овал (или помещенное под овалом). Другими словами, функции, выполняемые системой, на уровне моделирования использования никак не раскрываются – им только даются имена.
Семантически вариант использования – это описание множества возможных последовательностей действий (событий), приводящих к значимому для действующего лица результату. Каждая конкретная последовательность действий называется сценарием.
Пример 3.3
На рисунке 3.2 приведена диаграмма использования “Принять программу в архив”, описывающая процесс сдачи программы в архив организации-разработчика.
На диаграмме изображены действующие лица: разработчик, сдающий программу, приемщик, принимающий и регистрирующий программу, и архив, в котором будет храниться программа.
Диаграмма содержит два варианта использования (овала), имена которых идентифицируют функции: «Управление разработчиком» и «Управление архивом».
Рис. 3.2
Диаграмма описывает процесс на очень высоком уровне и здесь явно не достает более подробного описания вариантов (см. пример 3.2).
Диаграмма использования UML показывает объединение и декомпозицию вариантов использования, но не их содержание. Для описания варианта использования нужно использовать другие средства, например, диаграммы состояний и диаграммы последовательности.
3.6.Выявление требований на основе различных точек зрения. Метод vord
Любая достаточно большая программная система имеет несколько различных групп конечных пользователей. Каждая группа пользователей имеет свой взгляд на систему, свои интересы (свою точку зрения на систему) и поэтому должна участвовать в формировании требований. Эти различные точки зрения могут быть независимыми или пересекаться, но главное, они позволяют рассматривать систему с разных сторон и учитывать интересы всех ее пользователей.
Один из подходов к формированию требований основан на учете различных опорных точек зрения (viewpoint-oriented elicitation) и позволяет обнаруживать на ранних этапах проектирования противоречия в требованиях различных групп пользователей.
Существуют различные интерпретации понятия точки зрения. Приведем некоторые из них [9]:
Точка зрения – это источник информации о системных данных. В этом случае точка зрения – основа для построения модели создания и использования данных в системе.
Точка зрения – это особая часть модели системы и на основе различных точек зрения могут быть построены, например, модели сущность-связь или модели конечного автомата системы.
Точка зрения – это получатель системных сервисов. В этом случае точка зрения (точнее ее носитель) является внешним по отношению к системе и помогает определить данные, необходимые для выполнения системных сервисов и управления ими.
При проектировании интерактивных систем нужно учесть, что взаимодействуют с системой, получая от нее сервисы и поставляя ей данные и управляющие сигналы, конечные (внешние) пользователи. Использование внешних опорных точек зрения позволяет:
более естественно структурировать процесс формирования требований (по точкам зрения);
упростить выбор опорных точек зрения, каждая из которых представляет собой способ взаимодействия пользователя с системой;
выявить нефункциональные требования.
На основе такого подхода к интерпретации и выбору опорных точек был разработан метод VORD (Viewpoint-Oriented Requirements Definition) для формирования и анализа требований.
Метод VORD состоит из четырех основных этапов:
Идентификация точек зрения.
Структурирование точек зрения.
Документирование точек зрения.
Отображение системы точек зрения.