Рекомендации по структуре курсового проекта

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

1. Анализ Описание предметной областиПО.

1.1. Общая характеристика писание ПО решаемой задачи.

1.2.1.1. Модели бизнес-процессовФункции ПО, реализуемые задачей.

1.3.1.1. Перечень документов.

2.1. Постановка задачи для реализации приложений.

2.1.1.1. Организационно-экономическая сущность задачи.

2.3.1.1. Описание вВыходнаяой информацияи задачи (отчеты, справка, экранныеая формы, файлы обменаа).

2.2.1.1. ВхФорматы входнаяых информация задачи (первичные документы, БД, файлы обмена)ов.

1.1. Алгоритмы и технология обработки данных приложений

3.1. Разработка информационных технологий ого обеспечения задачи.

3.1.1.1. Информационный анализ входной информации, необходимой для решения задачи и выделение информационных объектов ПО.

3.2.1.1. ПОпределение связей информационных объектов и построение ИЛМ.

3.3.1.1. Определение Разработка логической структуры БДбазы данных.

3.5.1.1. Разработка программной Создание базы данных на компьютере.

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

3.8.1.1. Обобщенный алгоритм решения задачи и его декомпозиция на модули, реализуемые инструментальными средствами СУБД.

3.7.1.1. Описание технологии ввода в базу данных входной информации задачи (определение перечня документов-источников для загрузки данных и описание макетов экранных форм для ввода данных).

3.4.1.1. Разработка исходных данных контрольного примера.

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

3.10.1.1. Разработка диалогового приложения пользователя.

3.11.1.1. Описание структуры технологического процесса обработки данных для решения задачи.

1.1. БД контрольного примера.

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

3.13.1.1. Инструкция конечному пользователю по решению задачи.

4.1. Приложения к курсовой работе

B.A. Каноническая ИЛМ ПО.

A. Распечатки Структурыа БД (структура данных таблицы, схемысхема БД).

A. Макеты экранных форм.

A. Макеты отчетов.

A. Тексты запросов на языке SQL.

A. Макросы.

A. Распечатки Исходныхе данных данныеБД контрольного примера.

C.A. Выходные документы по рРаспечатки Результатовыам (отчет) решения задачи (в БД (отчет) по данным контрольного примера).

Предметную область следует рассматривать как совокупность бизнес-процессов, которые, согласно трактовке Шера, представляются в виде «порядка выполнения работ, направленных на достижение определенных бизнес-целей» [ ]. При этом бизнес-процесс охватывает различные стороны деятельности, подразумевает участие исполнителей не зависимо от принадлежности к структурным подразделениям, связан с организацией материальных и информационных потоков. Примером типх ов (или функциональных подсистем) для промышленных предприятий являютсяВ описании ПО следует указать виды и цели деятельности, состав бизнес-процессов, проанализировать их особенности, связь с внешней средой. Для описания ПО применяются методы структурного анализа и функционального моделирования, среди которых наиболее популярны:

· IDEF0 – методология функциональной декомпозиции ПО;

· DFD (Data Flow Diagrams) – описание потоков данных ПО;

· IDEF3 – динамическое моделирование ПО.

Используемые термины и определения IDEF0:

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

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

· Контекстная – отделяет систему от внешней среды и отражает взаимодействие с внешней средой (рис. 1).

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

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

· Диаграммы для экспозиций (FEO) – фрагмент модели.

Описание предметной области может соответствовать как текущему (as is - «как есть»), так и будущему состоянию предметной области (to be - «должна быть»).

Рисунок . Взаимодействие системы и внешней среды (контекстная диаграмма)

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

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

Стрелки отображают взаимодействие работ и связи с внешним миром, обозначают входную или выходную информацию, управляющее воздействие для работы. Стрелки именуются существительными (например, «Документ», «База данных» и т.п.). Различают пять типов стрелок.

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

§ Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа.

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

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

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

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

 

Рисунок Диаграмма декомпозиции

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

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

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

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

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

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

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

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

· внешние сущности

· накопители данных или хранилища

· процессы

· потоки данных

· системы/подсистемы

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

Рисунок Изображение внешней сущности

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

Рисунок 4.Изображение процесса на диаграмме потоков данных

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

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

Рисунок Изображение накопителя на диаграмме потоков данных

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

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

 

Рисунок Диаграмма DFD

DFD используется как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в системах обработки информации. Модель DFD содержит:

· описание цели системы,

· контекстную диаграмму,

· список событий (модель поведения).

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

 

Для описания логики взаимодействия источников, приемников и хранилищ данных применяется методология IDEF3, строятся диаграммы потоков работ - Work Flow Diagram. Эти диаграммы позволяют анализировать завершенность процедур обработки данных, описывать сценарии действий сотрудников (последовательность обработки заказов, например) для документирования функций обработки.

Для описания процесса в IDEF3 определены две стратегии и два типа диаграмм:

· process-centered strategy – стратегия описания процесса как последовательности выполняемых действий. Диаграммы этого типа получили название Process Flow Description Diagrams (PFDD) – диаграммы потокового описания процесса;

· object-centered strategy - стратегия описания процесса как последовательности изменений состояний объекта, над которым выполняются действия. Диаграммы такого типа получили название Object State Transition Network (OSTN) – диаграммы последовательности изменений состояний объекта.

Для диаграмм PFDD в IDEF3 используется понятие сценария в качестве базовой структурной единицы описания процесса. Описание процесса может состоять из одного или нескольких сценариев- некий набор ситуаций, описывающих типичный класс проблем в системе или организации, обстановку или среду, в которой происходит рассматриваемый процесс. Именем сценария может быть глагол с поясняющими словами («Оформить заказ на товары», «Проверить пригодность товара») или название совокупности характерных действий («Выполнение последовательности проверок»).

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

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

· модули единицы поведения UOB (Unit Of Behavior) или единицы работы UOW(Unit of Work),

· связи старшинства,

· узлы или перекрестки,

· модули ссылок и примечаний.

UOW имеют имя, которое содержит указание как на процесс, так и на результат, а также номер работы (номер родительской работы + порядковый номер на текущей диаграмме). С UOW связан документ, который содержит: текстовое описание работы; объекты (Object); ограничения (Constraints); дополнительных свойств и описаний (Description).

Связи показывают взаимоотношение работ,

однонаправленные (слева направо), различают три типа стрелок:

§ Старшая (Precedence) – сплошная линия, связывает UOW; слева направо, сверху вниз; UOW в начале связи должен закончиться раньше, чем начнется UOW, стоящий в конце связи;

§ Стрелка отношений (Relational Link) – пунктирная линия, для изображения связей между UOW с объектами ссылок;

§ Потоки объектов (Object Flow) – описание того факта, что объект используется в двух или более UOW. Часто изображается стрелкой с двумя наконечниками.

Связи старшинства подразделяются на простые связи старшинства (Simple Precedence Links) и принуждающие связи старшинства (Constrained Precedence Links).

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

Двойные однонаправленные стрелки на верхней схеме рис. 7 задают правило – действие модуля 1 должно предшествовать действию модуля 2.

Рисунок Принуждающие связи старшинства

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

Все связи IDEF3 описания нумеруются. При этом, связи старшинства обозначаются символом PL (от «precedence link») и порядковым номером, а связи неопределенного типа символом DL (от «dashed link») и своим порядковым номером. Старшая связь показывает, что работа-источник заканчивается раньше, чем начинается работа-цель. Отношение показывает, что стрелка является альтернативой старшей стрелке или потоку объектов в смысле задания последовательности выполнения работ (работа-источник не обязательно должна заканчиваться прежде начала работы цели).

Перекрестки (Junction) обеспечивают отображение логики взаимодействия стрелок при слиянии и разветвлении (табл.1).

 

Таблица

Обозначение	Наименование	Смысл в случае слияния стрелок (Fan-in-Junction)	Смысл в случае разветвления стрелок (Fan-out-Junction)
	Асинхронное «И»	Все предшествующие процессы должны быть завершены	Все следующие процессы должны быть запущены
	Синхронное «И»	Все предшествующие процессы завершены одновременно	Все следующие процессы запускаются одновременно
	Асинхронное «ИЛИ»	Один или более предшествующих процессов должны быть завершены	Один или несколько следующих процессов должны быть запущены
	Синхронное «ИЛИ»	Один или более предшествующих процессов завершены одновременно	Один или несколько следующих процессов запускаются одновременно
	Исключающее «ИЛИ»	Только один предшествующий процесс завершен	Только один следующий процесс запускается

 

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

- And Gate («И»)

- Or Gate («ИЛИ»)

- XOR Gate («ИЛИ»)

 

Стрелки могут сливаться или разветвляться только через перекрестки. Правила создания перекрестков:

1. Каждому перекрестку для слияния должен предшествовать перекресток для разветвления.

1. Перекресток для слияния «И» не может следовать за перекрестком для разветвления типа синхронного или асинхронного «ИЛИ».

1. Перекресток для слияния «И» не может следовать за перекрестком для разветвления типа исключающего «ИЛИ».

1. Перекресток для слияния типа исключающего «ИЛИ» не может следовать за перекрестком для разветвления типа «И».

1. Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой стороне.

Объект ссылки (Referent) выражает идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой. Типы объектов ссылок:

§ OBJECT – описывает участи важного объекта в работе;

§ GOTO – циклический переход, может ссылаться на перекресток;

§ UOB (Unit of behavior) – множественное нециклическое использование работы;

§ NOTE – документирование важной информации;

§ ELAB (Elaboration) – детальное описание разветвления или слияния стрелок на перекрестках.

Объекты связываются с UOW с помощью пунктирными линиями. Различают ссылки:

§ безусловные (unconditional),

§ синхронные (Synchronous),

§ асинхронные (Asynchronous)

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

IDEF3 позволяет логику согласования модели выразить в виде комбинации перекрестков или в виде объекта ссылки типа ELAB.

Рисунок . Модель IDEF3

 

В следует ести условия и результаты предметной области – е Писпользует –ы Существуют различные типы АРМ: (директора, управляющего, главного инженера и т.п.) (бухгалтера, экономиста, менеджера и т.п.)

Например, функВзаимодействие осуществляется через БД ая БДтсяая БДтсяобъНапример, н наличиеимеют доступ к ;ведут Рисунок 3. ЗАДАНИЕ ЗАДАНИЯ НА КУРСОВОЕ ПРОЕКТИРОВАНИЕ

Задание на курсовое проектирование содержит:

· описание предметной области комплекса задач;

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

Примечание

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

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

· “Отдел сбыта продукции предприятия”.;

· “Универмаг”;

· “Ресторан”;

· “Поликлиника”.

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

3.1. Информационная система
“Отдел сбыта продукции предприятия”