Смекни!
smekni.com

Методические указания к выполнению курсовой работы для студентов всех форм обучения специальности 230201 «Информационные системы и технологии» Брянск 2009 г (стр. 2 из 3)

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

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

Рис. 5. Накопитель данных

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

Рис. 6. Поток данных

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

Нотация IDEF3 использует категорию Сценариев (Scenario) для упрощения структуры описаний сложного многоэтапного процесса. IDEF3 осуществляет реализацию информации о процессе:

· объекты, участвующие в описании операции;

· функции, которые выполняют эти объекты;

· взаимосвязь между процессами;

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

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

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

Существует два типа диаграмм в стандарте IDEF3: диаграммы описания последовательности этапов процесса (PFDD), диаграммы состояния объекта и его изменений в процессе (OSTN).

На рис. 7 изображена диаграмма PFDD, показывающая процессы создания программного обеспечения. Прямоугольники на диаграмме PFDD называются функциональными элементами или элементами поведения (UOB) и обозначают событие, стадию процесса или принятие решения (рис. 8). Каждый UOB имеет конкретное имя (функция, процесс, действие, акт, событие, сценарий, процедура, операция, решение), отображаемое в глагольном наклонении и уникальный номер. В правом нижнем углу UOB элемента (рис. 8) располагается ссылка, которая используется на какие-либо элементы функциональной модели IDEF0 или на указания отделы, конкретных исполнителей, выполняющие конкретный процесс.

Рис. 7. PFDD диаграмма создания электронной программы

Рис. 8. Функциональный элемент (UOB)

Стрелки или линии являются отображением хода выполнения операций между UOB-блоками в ходе процесса (рис. 9).

а) б) в)

Рис. 9. Стрелки для отображения хода выполнения операции

Линии в нотации IDEF3 бывают следующих видов:

1. Старшая (precedence, рис. 9, а) - сплошная линия, связывающая UOB. Рисуется слева направо или сверху вниз.

2. Отношения (relational link, рис. 9, б)- пунктирная линия, использующаяся для изображения связей между UOB

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

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

а) б) в)

Рис. 10. Семантика связей

Объект, обозначенный J1 (рис. 7) - называется перекрестком (Junction) со своим определенным идентификационным номером. Перекрестки используются для представления логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. При вводе перекрестка в диаграмму необходимо указать тип перекрестка. Типы перекрестков представлены в таблице.

Таблица

Описание типов перекрестков

Обозначение Наименование Смысл для стрелок слияния Смыл для стрелок разветвления
Асинхронное И (asynchronous AND) Все предшествующие процессы должны быть завершены Все следующие процессы должны быть запущены
Cинхронное И (synchronous AND) Все предшествующие процессы завершены одновременно Все следующие процессы запускаются одновременно
Асинхронное ИЛИ (asynchronous OR) Один или несколько предшествующих процессов должны быть завершены Один или несколько следующих процессов должны быть запущены
Синхронное ИЛИ (synchronous OR) Один или несколько предшествующих процессов завершаются одновременно Один или несколько следующих процессов запускаются одновременно
Эксклюзивное ИЛИ (XOR, exclusive OR) Только один предшествующий процесс завершен Только один следующий процесс запускается

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

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

Если диаграммы PFDD технологический процесс "С точки зрения наблюдателя", то другой класс диаграмм IDEF3 OSTN позволяет рассматривать тот же самый процесс "С точки зрения объекта". На рис. 10 представлено отображение процесса окраски с точки зрения OSTN диаграммы. Состояния объекта (в нашем случае детали) и изменение состояния являются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.

Рис. 11. Пример OSTN диаграммы

3. Тематика курсовой работы

Работа должна включать:

1) функциональную модель систему на основе нотации и стандарта IDEF0;

2) диаграмму потоков данных в системе;

3) описание потока процессов, взаимодействия процессов и объектов на основе нотации и стандарта IDEF3;

4) Комплексную модель функционирования системы.

Задание на курсовую работу выдается на бланке (прил. 2).

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

Курсовая работа выполняется в следующей последовательности:

1. Изучить методику составления модели с помощью пакета BPwin.

2. Составить схему функциональной модели в соответствии с заданным вариантом.

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

4. Разработать функциональную модель системы на основе нотации IDEF0 (черновой вариант).

5. Разработать диаграмму потоков данных, имеющихся в системе (черновой вариант).

6. Разработать описания потоков процессов в системе на основе нотации IDEF3 (черновой вариант).

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