Разработка концептуальной модели

информационной системы»

Цель работы: разработать концептуальную модель информационной системы.

В соответствии с ГОСТ 34.601.90 «Автоматизированные системы. Стадии разработки.» после организационных мероприятий по созданию коллектива разработчиков и подписания контракта на создании программного обеспечения наступает стадия «Формирование требований и разработка технического задания». Эта стадия состоит из следующих этапов: системно-аналитического обследования объекта автоматизации, анализа и обработки полученной информации, разработки концептуальной модели системы, разработки технического задания и этапа согласования и утверждения ТЗ.

В лабораторной работе №1 был проведен анализ предметной области и собрана информация о требованиях заказчика к системе.

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

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

Суть данной диаграммы состоит в следующем [1]: проектируемая система представляется в виде множества актеров, взаимодействующих с системой с помощью вариантов использования. При этом актером (действующим лицом, актантом, актором) называется любой объект, субъект или система, взаимодействующая с моделируемой системой извне. Это может быть человек, техническое устройство или другая система, которая может служить источником воздействия на моделируемую систему. В свою очередь вариант использования – это спецификация сервисов (функций), которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемых системой при взаимодействии с актером. При этом в модели никак не отражается то, каким образом будет реализован этот набор действий.

В структурном подходе аналогом диаграммы вариантов использования являются диаграммы IDEF0 и DFD, вариантов использования – работы (IDEF0) и процессы (DFD), актеров – внешние сущности (DFD).

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

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

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

· ассоциаций;

· обобщения;

· включения;

· расширения.

Рекомендации по разработке диаграмм вариантов использования

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

2. Затем построить для каждого из них диаграммы декомпозиции.

3. Для лучшего восприятия отдельная диаграмма не должна быть перенасыщена элементами. Рекомендуется отображать не более 15 вариантов использования.

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

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

· краткое описание поведения, реализуемого в варианте использования;

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

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

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

· постусловия – условия, которые должны быть выполнены после завершения варианта использования. Например, таким условием может быть обязательное сохранение результатов расчета в базе данных на сервере.

Содержание отчета.

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

Рекомендованная литература.

1. Новиков Ф.А., Иванов Д.Ю. Моделирование на UML. Теория, практика, видеокурс. – Спб.: Профессиональная литература, Наука и техника, 2010.

2. Фаулер М., Скотт К. UML: Основы. – СПб: Символ-Плюс, 2002.

Вопросы для самопроверки.

1. Опишите стадию «Формирование требований и разработка технического задания».

2. Перечислите элементы диаграммы вариантов использования и дайте им определения.

3. Какие виды отношений могут использоваться на диаграмме вариантов использования.

4. Чем отношение включения отличается от отношения расширение.