Методические указания по выполнению лабораторных работ для студентов 5 курса специальности 230201 Тамбов

Министерство образования и науки РФ

Тамбовский государственный технический университет

Иванова О.Г.

Автоматизация проектирования и эксплуатации информационных систем

Методические указания по выполнению лабораторных работ для студентов 5 курса специальности 230201

Тамбов

Издательство ТГТУ

2007

ЛАБОРАТОРНАЯ РАБОТА 1. ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ И СПЕЦИФИКАЦИЙ НА СОЗДАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ

Цель работы

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

Методические указания к выполнению работы

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

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

Последовательность выполнения лабораторной работы:

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

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

3. Определить задачи и функции системы в целом и функции каждого подразделения (подсистемы).

4. Выполнить словесное описание работы каждого подразделения (подсистемы), алгоритмов и сценариев выполнения ими отдельных работ.

5. Оформить отчет со следующими разделами:

· исходное задание;

· расширенное описание предметной области с учетом сделанных дополнений;

· состав подразделений (подсистем) информационной системы;

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

· подробное описание работы каждого подразделения (подсистемы);

· описание отдельных сценариев работ подразделений (подсистем);

· входная и выходная информация для каждого подразделения (подсистемы);

ЛАБОРАТОРНАЯ РАБОТА 2. ПОСТРОЕНИЕ ДИАГРАММ РАБОТ ИНФОРМАЦИОННОЙ СИСТЕМЫ

Цель работы

Ознакомиться с методологиями функционального моделирования работ.

Литература:
[3, 4, 6, 7]

Методические указания к выполнению работы

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

Для целей проектирования информационной системы могут быть использованы следующие виды моделей:

· методология функционального моделирования работ SADT (Structured Analysis and Design Technique);

· диаграммы потоков данных DFD (Data Flow Diagrams);

· методология объектного проектирования на языке UML (UML-диаграммы).

Методология SADT (Structured Analisys and Design Technique - технология структурного анализа и проектирования) разработана Дугласом Т. Россом и является одной из самых известных и широко используемых методик проектирования. Новое название методики, принятое в качестве стандарта, -IDEF0 (Icam DEFinition) является частью программы ICAM (Integrated Computer -Aided Manufacturing - интегрированная компьютеризация производства).

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

В IDEF0 система представляется как совокупность взаимодействующих работ (или функций). Связи между работами определяют технологический процесс или структуру взаимосвязи внутри организации. Модель SADT представляет собой серию диаграмм, разбивающих сложный объект на составные части.

Основными понятиями методологии функционального моделирования работ являются:

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

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

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

Выход (Output)
- материал или информация, которые производятся работой (стрелка, исходящая из правой грани). Каждая работа должна иметь хотя бы одну стрелку выхода, так как работа без результата не имеет смысла и не должна моделироваться.

Механизм (Mechanism)
- ресурсы, которые выполняют работу (персонал, станки, устройства - стрелка, входящая в нижнюю грань).

Вызов (Call)
представляет собой взаимодействие одной модели работ с другой (стрелка, исходящая из нижней грани).

Различают в IDEF0 пять типов связей работ.

Связь по входу (input-output)
имеет место, когда выход вышестоящей работы направляется на вход следующей работы.

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

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

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

Связь выход-механизм (output-mechanism)
имеет место, когда выход одной работы направляется на механизм другой и показывает, что работа подготавливает ресурсы для проведения другой работы.

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

Последовательность выполнения лабораторной работы:

1. Ознакомиться с методологией структурного моделирования работ.

2. Ознакомиться с программным продуктом BpWin.

3. С целью освоения программного продукта BpWin проработать пособие по работе с BpWin, включенное в систему меню программного продукта.

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

5. Оформить отчет.

ЛАБОРАТОРНАЯ РАБОТА 3. ПОСТРОЕНИЕ ДИАГРАММ ПОТОКОВ ДАННЫХ ИНФОРМАЦИОННОЙ СИСТЕМЫ

Цель работы

Ознакомиться с методологией построения диаграмм потоков данных с использованием программного продукта BpWin.

Литература:
[3, 4, 6, 7,11]

Методические указания к выполнению работы

Диаграммы потоков данных (Data Flow Diagrams - DFD) используются для описания движения документов и обработки информации как дополнение к IDEF0. В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, стрелки в DFD показывают лишь то, как объекты (включая данные) движутся от одной работы к другой. DFD отражает функциональные зависимости значений, вычисляемых в системе, включая входные значения, выходные значения и внутренние хранилища данных. DFD - это граф, на котором показано движение значений данных от их источников через преобразующие их процессы к их потребителям в других объектах.

DFD содержит процессы, которые преобразуют данные, потоки данных, которые переносят данные, активные объекты, которые производят и потребляют данные, и хранилища данных, которые пассивно хранят данные.

Диаграмма потоков данных содержит:

· процессы, которые преобразуют данные;

· потоки данных, переносящие данные;

· активные объекты, которые производят и потребляют данные;

· хранилища данных, которые пассивно хранят данные.

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

Рисунок 1

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

Рисунок 2.

Активным объектом является объект, который обеспечивает движение данных, поставляя или потребляя их. Хранилище данных
- это пассивный объект в составе DFD, в котором данные сохраняются для последующего доступа. Хранилище данных допускает доступ к хранимым в нем данным в порядке, отличном от того, в котором они были туда помещены. Агрегатные хранилища данных, как, например, списки и таблицы, обеспечивают доступ к данным в порядке их поступления, либо по ключам (рис.3).

Рисунок 3.

Потоки управления.
DFD показывает все пути вычисления значений, но не показывает в каком порядке значения вычисляются. Решения о порядке вычислений связаны с управлением программой, которое отражается в динамической модели. Эти решения, вырабатываемые специальными функциями, или предикатами, определяют, будет ли выполнен тот или иной процесс, но при этом не передают процессу никаких данных, так что их включение в функциональную модель необязательно. Тем не менее, иногда бывает полезно включать указанные предикаты в функциональную модель, чтобы в ней были отражены условия выполнения соответствующего процесса. Функция, принимающая решение о запуске процесса, будучи включенной в DFD, порождает в диаграмме поток управления и изображается пунктирной стрелкой (рис.4).

Рисунок 4.

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

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

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

При построении иерархии DFD переходить к детализации процессов следует только после определения содержания всех потоков и накопителей данных, которое описывается при помощи структур данных. Структуры данных конструируются из элементов данных и могут содержать альтернативы, условные вхождения и итерации. Условное вхождение означает, что данный компонент может отсутствовать в структуре. Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация означает вхождение любого числа элементов в указанном диапазоне. Для каждого элемента данных может указываться его тип (непрерывные или дискретные данные). Для непрерывных данных может указываться единица измерения (кг, см и т.п.), диапазон значений, точность представления и форма физического кодирования. Для дискретных данных может указываться таблица допустимых значений.

На рис.5 приведена диаграмма потоков данных верхнего уровня с ее последующим уточнением:

Рисунок 5.

Последовательность выполнения лабораторной работы:

1. Ознакомиться с методологией диаграмм потоков данных.

2. Ознакомиться с программным продуктом BpWin в части средств работы с диаграммами потоков данных.

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

4. Оформить отчет.

Лабораторная работа 4. Создание логической модели информационной системы

Цель работы

• ознакомиться с технологией построения логической модели в ERWin,

• изучить методы определения ключевых атрибутов сущностей,

• освоить метод проверки адекватности логической модели,

• изучить типы связей между сущностями.

Литература:
[3, 4, 6, 7]

Методические указания к выполнению работы

Первым шагом при создании логической модели БД является постро­ение диаграммы ERD (Entity Relationship Diagram). ERD-диаграммы со­стоят из трех частей: сущностей, атрибутов и взаимосвязей. Сущностями являются существительные, атрибуты - прилагательными или модифика­торами, взаимосвязи - глаголами.

ERD-диаграмма позволяет рассмотреть систему целиком и выяснить требования, необходимые для ее разработки, касающиеся хранения инфор­мации.

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

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

Рисунок 6.

Определение сущностей и атрибутов

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

Логические взаимосвязи

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

Некоторые примеры взаимосвязей:

• команда включает много игроков,

• самолет перевозит много пассажиров,

• продавец продает много продуктов.

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

Кроме взаимосвязи «один-ко-многим» существует еще один тип - это «многие-ко-многим». Этот тип связи описывает ситуацию, при которой эк­земпляры сущностей могут взаимодействовать с несколькими экземпля­рами других сущностей. Связь «многие-ко-многим» используют на перво­начальных стадиях проектирования. Этот тип взаимосвязи отображается сплошной линией с точками на обоих концах.

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

Если взаимосвязи между сущностями были правильно установлены, то можно составить предложения, их описывающие. Например, по моде­ли, показанной на рис. 7, можно составить следующие предложения:

• Самолет перевозит пассажиров.

• Много пассажиров перевозятся одним самолетом.

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

Рисунок 7.

Модель данных, основанная на ключах

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

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

• Никакой из атрибутов первичного ключа не должен иметь нулевое значение.

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

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

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

Потенциальный ключ, не ставший первичным, называется альтернатив­ным ключом (Alternate Key). ERWin позволяет выделить атрибуты альтер­нативных ключей, и по умолчанию в дальнейшем при генерации схемы БД по этим атрибутам будет генерироваться уникальный индекс. При созда­нии альтернативного ключа на диаграмме рядом с атрибутом появляются символы (АК).

Атрибуты, участвующие в неуникальных индексах, называются инвер­сионными входами (Inversion Entries). Инверсионные входы - это атрибут или группа атрибутов, которые не определяют экземпляр уникальным об­разом, но часто используются для обращения к экземплярам сущности. ERWin генерирует неуникальный индекс для каждого инверсионного входа.

При проведении связи между двумя сущностями в дочерней сущности автоматически образуются внешние ключи (foreign key). Связь образует ссылку на атрибуты первичного ключа в дочерней сущности, и эти атри­буты образуют внешний ключ в дочерней сущности. Атрибуты внешнего ключа обозначаются символами (FK) после своего имени.

Пример. Система «Служба занятости в рамках вуза».

Рассмотрим процесс построения логической модели на примере БД сту­дентов системы «Служба занятости в рамках вуза». Первым этапом явля­ется определение сущностей и атрибутов. В БД будут храниться записи о студентах, следовательно, сущностью будет студент.

Таблица 1. Атрибуты сущности «Студент»

Атрибут	Описание
1	2
Номер	Уникальный номер для идентификации пользователя
Ф.И.О.	Фамилия, имя и отчество пользователя
Пароль	Пароль для доступа в систему
Возраст	Возраст студента
Пол	Пол студента
Характеристика	Memo-поле с общей характеристикой поль­зователя
E-mail	Адреса электронной почты
Телефон	Номера телефонов студента (домашний, ра­бочий)
Опыт работы	Специальности и опыт работы студента по каждой из них
Специальность	Специальность, получаемая студентом при окончании учебного заведения
Специализация	Направление специальности, по которому обучается студент
Иностранный язык	Список иностранных языков и уровень вла­дения ими
Тестирование	Список тестов и отметки о их прохождении
Экспертная оценка	Список предметов с экспертными оценками по каждому из них
Оценки по экзаменам	Список сданных предметов с оценками

В полученном списке существуют атрибуты, которые нельзя опреде­лить в виде одного поля БД. Такие атрибуты требуют дополнительных определений и должны рассматриваться как сущности, состоящие, в свою очередь, из атрибутов. К таковым относятся: опыт работы, иностранный язык, тестирование, экспертная оценка, оценки по экзаменам. Определим их атрибуты.

Таблица 2. Атрибуты сущности «Опыт работы»

Атрибут	Описание
Специальность	Название специальности, по которой у студента есть опыт работы
Опыт	Опыт работы по данной специальности в годах
Место работы	Наименование предприятия, где приобретался опыт

Таблица 3. Атрибуты сущности «Иностранный язык»

Атрибут	Описание
Язык	Название иностранного языка, которым владеет студент
Уровень владения	Численная оценка уровня владения иностранным языком

Таблица 4. Атрибуты сущности «Тестирование»

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

Таблица 5. Атрибуты сущности «Экспертная оценка»

Атрибут	Описание
Дисциплина	Наименование дисциплины, по которой оценивался студент
Ф.И.О. преподавателя	Ф.И.О. преподавателя, который оценивал студента
Оценка	Экспертная оценку преподавателя

Таблица 6. Атрибуты сущности «Оценки по экзаменам»

Атрибут	Описание
Предмет	Название предмета, по которому сдавался экзамен
Оценка	Полученная оценка

Составим ERD-диаграмму, определяя типы атрибутов и проставляя связи между сущностями (рис. 8). Все сущности будут зависимыми от сущности «Студент». Связи будут типа «один-ко-многим».

Рисунок 8

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

Следующим этапом при построении логической модели является опре­деление ключевых атрибутов и типов атрибутов.

Таблица 7. Типы атрибутов

Атрибут	Тип
Номер	Number
Ф.И.О.	String
Пароль	String
Возраст	Number
Пол	String
Характеристика	String
E-mail	String
Специальность	String
Специализация	String
Опыт	Number
Место работы >	String
Язык	String
Уровень владения	Number
Название	String
Описание	String
Оценка	Number
Дисциплина	String
Ф.И.О. преподавателя	String
Предмет	String

Выберем для каждой сущности ключевые атрибуты, однозначно опре­деляющие сущность. Для сущности «Студент» это будет уникальный но­мер, для сущности «Опыт работы» все поля являются ключевыми, так как по разным специальностям студент может иметь разный опыт рабо­ты в разных фирмах. Сущность «Тест» определяется названием, так как студент по одному тесту может иметь только одну оценку. Оценка по эк­замену определяется только названием предмета, экспертная оценка зави­сит от преподавателя, который ее составил, поэтому в качестве ключевых атрибутов выберем «Дисциплину» и «Ф.И.О. преподавателя». У сущности «Иностранный язык» уровень владения зависит только от наименования языка, следовательно, это и будет являться ключевым атрибутом.

Последовательность выполнения лабораторной работы:

1. Ознакомиться с методологией построения логических моделей системы.

2. Ознакомиться с программным продуктом BpWin в части средств работы с ERD-диаграммами.

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

5. Оформить отчет.

ЛАБОРАТОРНАЯ РАБОТА 5. ПОСТРОЕНИЕ ДИАГРАММЫ ПРЕЦЕДЕНТОВ

Цель работы

Ознакомиться с методологией моделирования прецедентов на основе языка UML

Литература:
[1-3, 5, 8-10]

Методические указания к выполнению работы

UML (Universal Modeling Language) - универсальный язык моделирования, который был разработан компанией Rational Software с целью создания наиболее оптимального и универсального языка для описания как предметной области, так и конкретной задачи в программировании. Визуальное моделирование в UML можно представить как некоторый процесс поуровневого спуска от наиболее обшей и абстрактной концептуальной модели системы к логической, а затем и к физической модели соответствующей системы. Любая задача, таким образом, моделируется при помощи некоторого набора иерархических диаграмм, каждая из которых представляет собой некоторую проекцию системы.

Диаграмма (Diagram) - это графическое представление множества элементов. Чаще всего она изображается в виде связного графа с вершинами (сущностями) и ребрами (отношениями).

В UML определено восемь видов диаграмм [1]:

· диаграмма прецедентов (Use case diagram) - диаграмма поведения, на которой показано множество прецедентов и актеров, а также отношения между ними;

· диаграмма деятельности (Activity diagram) - диаграмма поведения, на которой показан автомат и подчеркнуты переходы потока управления от одной деятельности к другой;

· диаграмма классов (Class diagram) - структурная диаграмма, на которой показано множество классов, интерфейсов, коопераций и отношения между ними;

· диаграмма состояний (Statechart diagram) - диаграмма поведения, на которой показан автомат и подчеркнуто поведение объектов с точки зрения порядка получения событий;

· диаграмма последовательностей (Sequence diagram) - диаграмма поведения, на которой показано взаимодействие и подчеркнута временная последовательность событий;

· диаграмма кооперации (Collaboration diagram) - диаграмма поведения, на которой показано взаимодействие и подчеркнута структурная организация объектов, посылающих и принимающих сообщения;

· диаграмма компонентов (Component diagram) - диаграмма поведения, на которой показан автомат и подчеркнуто поведение объектов с точки зрения порядка получения событий

· диаграмма развертывания (Deployment diagram) - структурная диаграмма, на которой показаны узлы и отношения между ними.

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

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

Рассмотрим основные элементы диаграммы прецедентов.

Субъект (actor) - любая сущность, взаимодействующая с системой извне [2] или множество логически связанных ролей, исполняемых при взаимодействии с прецедентами [1].
Стандартным графическим обозначением субъекта на диаграммах является фигурка "человечка", под которой записывается конкретное имя субъекта, однако субъектом может быть не только человек, но и техническое устройств о, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик (рис.9).

Рисунок 9

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

Рисунок 10

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

Фрагмент внешне наблюдаемых функций
(отличных от внутренних функций).

Ортогональный
фрагмент функциональных возможностей (прецеденты могут при выполнении совместно использовать объекты, но выполнение каждого прецедента независимо от других прецедентов).

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

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

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

Отношение ассоциации (association)
- определяет наличие канала связи между экземплярами субъекта и прецедента (или между экземплярами двумх субъектов).
Обозначается сплошной линией, возможно наличие стрелки и указание мощности связи.

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

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

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

Пример. Магазин видеопродукции.

Магазин продает видеокассеты, DVD-диски, аудио-кассеты, CD-диски и т.д. , а также предлагает широкой публике прокат видеокассет и DVD-дисков.

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

Видеоносители выдаются в прокат на срок от 1 до 7 дней. При прокате с клиента взимается залоговая стоимость видеоносителя. При возврате видеоносителя возвращается залоговая стоимость минус сумма за прокат. Если возврат задержан менее чем на 2 дня, взимается штраф в размере суммы за прокат за 1 день* кол-во дней задержки. При задержке возврата более чем на 2 дня - залоговая сумма не возвращается. Клиент может взять одновременно до 4 видеоносителей (прокат-заказ). На каждый видеоноситель оформляется квитанция.

Клиенты могут стать членами видео-клуба и получить пластиковые карточки. С членов клуба не берется залог (за исключением случая описанного ниже), устанавливается скидка на ставку проката и покупку товаров. Члены клуба могут делать предварительные заказы на подбор видеоматериалов для проката или покупки.

Каждый член клуба имеет некоторый стутус. Первоначально - "новичок". При возврате в срок 5 прокат-заказов , статус меняется на "надежный". При задержке хотя бы одного видеоносителя более чем на 2 дня , статус "новичок" или "надежный" меняется на "ненадежный" и клиенту высылается предупреждение. При повторном нарушении правил статус меняется на "нарушитель". Члены клуба со статусом "надежный" могут брать до 8 видеоносителей единовременно, все остальные - 4. С членов клуба со статусом "нарушитель" берется залоговая сумма.

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

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

На рис. 8 приведена диаграмма прецедентов для рассматриваемого примера. В этом примере можно выделить следующие субъекты и соответствующие им прецеденты:

· Менеджер
- изучает рынок видеопродукции, анализирует продажи (прецедент "Запрос сведений"), работает с поставщиками: составляет заявки на поставки товара (прецедент "Оформление заказа" ), оплачивает и принимает товар (прецедент "Прием товара"), списывает товар (прецедент "Списание товара").

· Продавец
- работает с клиентами: продает товар (прецедент "Продажа видео"), оформляет членство в клубе (прецедент "Сопровождение клиентов"), резервирует (прецедент "Резервирование видио"), выдает в прокат (прецедент "Прокат видео") и принимает назад видеоносители (прецедент "Возврат видео"), отвечает на вопросы клиента (прецедент "Запрос сведений").

· Поставщик
- оформляет документы для оплаты товара (прецедент "Оформление заказа"), поставляет товар (прецедент "Прием товара"))

· Клиент
- покупает(прецедент "Продажа видео"), берет на прокат и возвращает видеоносители (прецеденты "Прокат видео" и "Возврат видео"), вступает в клуб (прецедент "Сопровождение клиентов"), задает вопросы (прецедент "Запрос сведений").

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

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

Рисунок 11

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

· Краткое описание

· Участвующие субъекты

· Предусловия, необходимые для инициирования прецедента

· Поток событий (основной и, возможно, подпотоки, альтернативный

· Постусловия, определяющие состояние системы, по достижении которого прецедент завершается.

Таблица 7

Описательная спецификация прецедента "Прокат видео"

Раздел	Описание
1	2
Краткое описание	Клиент желает взять на прокат видеокассету или диск, которые снимаются с полки магазина или были предварительно зарезервированы клиентом. При условии, что у клиента нет невозвращенных в срок видеоносителей, сразу после внесения платы фильм выдается напрокат. Если невозвращенные в срок видеоносители есть, клиенту выдается напоминание о просроченном возврате.
Субъекты	Продавец, Клиент.
Предусловия	В наличие имеются видеокассеты или диски, которые можно взять напрокат. У клиентов есть клубные карточки. Устройство сканирования работает правильно. Работники за прилавком знают, как обращаться с системой.
Основной поток	Клиент может назвать номер заказа или взять видеоноситель с полки. Видеоноситель и членская карточка сканируются и продавцу не сообщается никаких сведений о задержках, так, что он не задает клиенту соответствующих вопросов. Если клиент имеет статус <надежный>, он может взять до 8 видеоносителей, во всех остальных случаях - до 4-х. Если статус клиента определен как <нарушитель>, его просят внести задаток. Клиент расплачивается наличными или кредитной картой. После получения суммы, информация о наличии фильмов обновляется и видеоносители передаются клиенту вместе с квитанциями на прокат. О прокате каждого видеоносителя делается отдельная запись с указанием идентификационного номера клиента, даты проката, даты возврата, идентификационного номера продавца, полученной суммы. Прецедент генерирует предупреждения о просроченном возврате клиенту, если видеофильм не был возвращен в течение двух дней по истечении даты возврата и изменяет статус клиента на <ненадежный> (первое нарушение) или <нарушитель> (повторное нарушение).
Альтернативный поток	У клиента нет членской карточки. В этом случае прецедент <Сопровождение клиента> может быть активизирован для выдачи новой карточки. Видеофильмы не выдаются, поскольку у клиента есть невозвращенные в срок видеоносители. Попытка взять на прокат слишком много видеоносителей. Видеоноситель или кредитная карта не могут быть отсканированы из-за их повреждения У клиента не хватило наличных или платеж по кредитной карте отклонен.
Постусловия	Видеофильмы сданы напрокат, и база данных соответствующим образом обновлена

Последовательность выполнения лабораторной работы:

1. Ознакомиться с методологией моделирования прецедентов на основе языка UML.

2. Построить диаграмму прецедентов для своей предметной области.

3. Описать несколько (2-3) прецедента.

4. Оформить отчет.

ЛАБОРАТОРНАЯ РАБОТА 6. ПОСТРОЕНИЕ ДИАГРАММ ДЕЯТЕЛЬНОСТИ

Цель работы

Ознакомиться с методологией моделирования деятельности на основе языка UML

Литература:
[1-3, 5, 8-10]

Методические указания к выполнению работы

Диаграммы деятельности (Activity diagram), называемые также диаграммами активности или диаграммами видов деятельности, были введены в язык UML сравнительно недавно. Диаграмма деятельности - это, по существу, блок-схема, которая показывает, как поток управления переходит от одной деятельности к другой, при этом внимание фиксируется на результате деятельности. Результат может привести к изменению состояния системы или возвращению некоторого значения.

Диаграмма деятельности отличается от традиционной блок-схемы

· более высоким уровнем абстракции;

· возможностью представления с помощью диаграмм деятельности управления параллельными потоками наряду с последовательным управлением.

Основными направлениями использования диаграмм деятельности являются

· визуализация особенностей реализации операций классов;

· отображение внутрисистемной точки зрения на прецедент.

В последнем случае диаграммы деятельности применяют для описания шагов, которые должна предпринять система после того, как инициирован прецедент

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

· детализировать особенности алгоритмической и логической реализации выполняемых системой операций и прецедентов;

· выделить последовательные и параллельные потоки управления;

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

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

Рассмотрим основные элементы диаграммы деятельности.

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

Состояния действия (action state
) - состояние, которое представляет вычисление атомарного действия,
как правило - вызов операции. Состояния действия не могут быть подвергнуты декомпозиции. Они атомарны, то есть внутри них могут происходить различные события, но выполняемая в состоянии действия работа не может быть прервана. И наконец, обычно предполагается, что длительность одного состояния действия занимает неощутимо малое время. Действие может заключаться в вызове другой операции, посылке сигнала, создании или уничтожении объекта либо в простом вычислении - скажем, значения выражения.

Состояния деятельности и состояния действия имеют одинаковое стандартное графическое обозначение - прямоугольник с закругленными краями. Внутри такого символа записывают произвольное выражение (action-expression), которое должно быть уникальным в пределах одной диаграммы деятельности.

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

На рис. 12 приведен пример диаграммы деятельности:

Рисунок 12

Переход (Transitions)
- отношение между двумя состояниями, показывающее, что объект, находящийся в первом состоянии, должен выполнить некоторые действия и перейти во второе состояние. Когда действие или деятельность в некотором состоянии завершается, поток управления сразу переходит в следующее состояние действия или деятельности. Для описания этого потока и используются переходы, показывающие путь из одного состояния действия или деятельности в другое. В UML переход представляется простой линией со стрелкой.

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

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

Пример разделения и слияния потоков приведен на рис.13:

Рисунок 13

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

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

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

Рис.14

На рис.15 приведена диаграмма деятельности прецедента "Прокат видео" для рассмотренного в лабораторной работе №5 примера "Магазин видеопродукции"

Рисунок 15

Последовательность выполнения лабораторной работы:

1. Ознакомиться с методологией моделирования деятельности на основе языка UML.

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

3. Оформить отчет.

Литература

1. Боггс У., Боггс М. UML и Rational Rose: Пер. с англ. - М.: ЛОРИ, 2000.

2. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. - М.:ДМК Пресс, 2001

3. Вендров A.M. Проектирование программного обеспечения экономических информационных систем: Учебник. — М.: Финансы и статистика, 2006.

4. Коберн Л, Современные методы описания функциональных требований к системам: Пер. с англ. — М.: ЛОРИ, 2002.

5. Леоненков А.В. Самоучитель UML. - СПб.: БХВ-Петербург, 2001.

6. Маклаков С.В. BPwin и ERwin. CASE-средства разработки информационных систем. - М.: Диалог-МИФИ, 1999.

7. Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования. — М.: МетаТехнология, 1993.

8. Мацяшек Л. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML: Пер. с англ. - М.: Вильямс, 2002.

9. Розенберг Д., Скотт К Применение объектно-ориентированного моделирования с использованием UML и анализ прецедентов: Пер. с англ. - М.: ДМК, 2002.

10. Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования: Пер. с англ. — М.: Мир, 1999.

11. Черемных СВ. и др. Структурный анализ систем: IDEF-технологии / С.В.Черемных, И.О. Семенов, B.C. Ручкин. — М.: Финансы и статистика, 2001.

Содержание

ЛАБОРАТОРНАЯ РАБОТА 1. ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ И СПЕЦИФИКАЦИЙ НА СОЗДАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ 2

ЛАБОРАТОРНАЯ РАБОТА 2. ПОСТРОЕНИЕ ДИАГРАММ РАБОТ ИНФОРМАЦИОННОЙ СИСТЕМЫ... 3

ЛАБОРАТОРНАЯ РАБОТА 3. ПОСТРОЕНИЕ ДИАГРАММ ПОТОКОВ ДАННЫХ ИНФОРМАЦИОННОЙ СИСТЕМЫ 5

Лабораторная работа 4. Создание логической модели информационной системы... 9

ЛАБОРАТОРНАЯ РАБОТА 5. ПОСТРОЕНИЕ ДИАГРАММЫ ПРЕЦЕДЕНТОВ 15

ЛАБОРАТОРНАЯ РАБОТА 6. ПОСТРОЕНИЕ ДИАГРАММ ДЕЯТЕЛЬНОСТИ 23

Литература 30