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

 

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

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

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

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

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

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

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

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

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

9. Разработать комплексную модель функционирования системы на основе нотаций IDEF0, DFD, IDEF3.

10. Оформление пояснительной записки по курсовой работе.

11. Защита курсовой работы

 

Содержание и объем работы

 

Отчет по курсовой работе представляется в виде пояснительной записки объемом 20-30 страниц и 2-3 листов графического материала, иллюстрирующего комплексную модель функционирования системы. Пояснительная записка должна содержать следующие пункты:

· титульный лист (прил. 1);

· задание на курсовую работу (прил. 2);

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

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

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

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

· отчет по диаграммам нотаций IDEF0, DFD, IDEF3;

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

· отчет по комплексной модели;

· заключение;

· список используемой литературы.

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

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

 

Список рекомендуемой литературы

 

1. Зиндер Е.З. Бизнес-реинжиниринг и технологии системного проектирования. Учеб. пособие. – М.: Центр информационных технологий, 1996.

2. Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение). – М.: "Лори", 1996.

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

4. Новоженов Ю.В. Объектно-ориентированные технологии разработки сложных программных систем. – М.: "МетаТехнология", 1996.

5. Панащук С.А. Разработка информационных систем с использованием CASE-системы Silverrun // СУБД. – 1995. – №3.

6. Горин С.В., Тандоев А.Ю. Применение CASE-средства Erwin 2.0 для информационного моделирования в системах обработки данных // СУБД. – 1995. – №3.

Приложение 1

 

 

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

 

 

Брянский государственный технический университет

 

Кафедра «Компьютерные технологии и системы»

 

Тема курсовой работы:

 

Документы текстовые

Всего листов

 

 

Руководитель

«»200г.

Студент

«»200г.

 

 

Брянск 2006

 

Приложение 2

 

Задание

на курсовую работу по дисциплине

«Информационные технологии»

 

Студент Группа

Тема курсовой работы:

 

Дата выдачи задания «» 200г.

График выполнения курсовой работы

1. Функциональная модель системы (стандарт IDEF0)

начало «» 200 окончание «» 200г.

2. Диаграмма потоков данных

начало «» 200 окончание «» 200г.

3. Диаграмма описания потоков процессов (стандарт IDEF3)

начало «» 200 окончание «» 200г.

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

начало «» 200 окончание «» 200г.

Дата сдачи задания «» 200г.

 

Заведующий кафедрой

«Компьютерные технологии и системы»

д.т.н., профессор В.И. Аверченков

(подпись)

Руководитель курсовой работы

(подпись)

 

Приложение 3

Пример пояснительной записки

ВВЕДЕНИЕ

Программный продукт BPWin (Computer Associates corp.) является мощным инструментом для создания моделей, позволяющих анализировать, документировать и планировать изменения сложных бизнес-процессов. BPwin является средством сбора необходимой информации о работе предприятия и графического изображения этой информации в виде целостной и непротиворечивой модели. ВРwin–модель является графическим представлением действительности, то есть средством документирования и формализации бизнес–процессов. BPWin — это современное средство позволяющие анализировать бизнес–процесс с трех ключевых точек зрения:

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

2. С точки зрения потоков информации в системе. Диаграммы DFD (Data Flow Diagram) дополняют функциональные IDEF0–модели, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. Также модели потоков данных могут использоваться как самостоятельное средство при проектировании информационных систем или описании бизнес–процесса, но в DFD-модели акцент ставиться на поток данных, его структуру, место и вид хранения данных в системе.

3. С точки зрения последовательности этапов выполняемых работ — методология событийного моделирования IDEF3. Этот метод привлекает внимание к очередности выполнения этапов работ или изменения состояний. В IDEF3 включены элементы логики, что позволяет моделировать и анализировать альтернативные сценарии развития бизнес-процесса.

Описание(IDEF0).

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

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

В основе методологии IDEF0 лежат следующие правила:

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

· С дугами связаны надписи (или метки) на естественном языке, описывающие данные, которые они представляют.

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

· Выходы одной функции могут быть Входами, Управлением или Исполнителями для другой.

· Дуги могут разветвляться и соединяться.

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

· Эти блоки представляют основные подфункции (подмодули) единого исходного модуля.

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

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

· Работа со стрелками. Имена стрелок автоматически заносятся в словарь (Arrow Dictionary).

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

Для внесения граничной стрелки надо:

Щелкнуть по кнопке с символом стрелки в палитре инструментов, затем следует перенести курсор к левой стороне экрана, пока не появится начальная штриховая полоска;

Щелкнуть один раз по полоске (откуда выходит стрелка) и еще раз в левой части блока со стороны входа (где заканчивается стрелка);

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

Щелкнуть правой кнопкой мыши на линии стрелки, во всплывающем меню выбрать Name и добавить имя стрелки в закладке Name диалога Arrow Properties.

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

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

Недопустима ситуация, когда стрелка до разветвления не именована, и после разветвления не именована какая-либо из ветвей. BPWin определяет такую стрелку как синтаксическую ошибку. Правила именования сливающихся стрелок аналогичны.

На рисунке 1 представлена комплексная модель водозабора где представлены рабочие(слесаря, электрики, реагентщики, хлораторщики, машинисты и лаборанты), руководители(ГОСТ, руководство) и ресурсы(вода, реагенты, Гипохлорит Na) для получения конечного продукта(вода питьевая) и то что осталось(вода в очистные сооружения).

 

Рис.1

 

Далее на рис. 2 представлены объекты, из которых и состоит водозабор, и кто где, с чем работает и чем при этом руководствуется.

 

Рис. 2

На рисунке 3 рассмотрим работу станции 1-го подъёма, стоит обратить внимание на работу «всасов», возникает вопрос, чем руководствуются машинисты, открывая их, а дело вот в чём, открытие всасов возможно только тогда когда машинисты, получат указание пустить в работу машинное отделение, работу которого рассмотрим далее.

Рис. 3

На рисунках 4 и 5 раскрыта схема процесса работы Маш. Отделения.

 

Рис. 4

Рис. 5

На следующем рисунке можно узнать чем очищают воду, посмотрев на то что выходит с расходных ёмкостей.

Рис. 6

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

Рис. 7

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

Рис. 8

 

Описание(IDEF3).

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

На рисунке 9 мы видим последовательность событий происходящих на водозаборе.

Рис. 9

На рисунках 10,11,12 мы видим, как происходит процесс закачки воды в систему водозабора, запуск системы, устранение возможных неполадок, при выполнение этих действий.

Рис. 10

Рис. 11

Рис. 12

На рисунках 10,11 можно увидеть логические блоки, например:

Эксклюзивное ИЛИ (XOR, exclusive OR)

Только один предшествующий процесс завершен

Только один следующий процесс запускается

 

А на рисунке 13 можно узнать, в какой последовательности действий осуществляется подача воды на город.

Рис. 13

Описание(DFF).

 

DFD – моделирование потоков данных (процессов) – основа методологии Gane/Sarson, в соответствии с которой модель системы определяется как иерархия диаграмм потоков данных (ДПД или DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи объекту или субъекту. Контекстные диаграммы иерархии определяют основные процессы или подсистемы системы с внешними входами и выходами. Они детализируются при помощи диаграмм-потомков. Декомпозиция ведется до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процессы становятся элементарными и детализировать их далее невозможно.

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

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

Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.

 

Процесспредставляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Процесс на диаграмме потоков данных изображается.

 

 

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

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

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

 

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

Рис. 14

На 14-м рисунки изображены источники накопления данных (Инф…), внешние сущности (слесаря, электрики, реагентщики, хлораторщики, лаборанты, ГОСТ, руководство, потребитель и машинисты) и сами процессы.