Примечания:

1. Не по ГОСТ и ОРММ ИСЖТ.

2. Основные проектные решения на создание ИС включают в себя определение:

 функциональной и организационной структур системы;

 состава и структуры комплекса технических и программных средств;

 применяемых инструментальных средств;

 технологии обработки информации;

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

 входных и выходных форм;

 алгоритмов обработки данных.

3. Цель макетирования (прототипирования) - снять неопределенность в требованиях Заказчика.

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

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

6. Приемочные испытания проводят для определения соответствия информационной системы ТЗ, оценки качества опытной эксплуатации и решения вопроса о возможности приемки ИС в постоянную (промышленную) эксплуатацию.

7. ОФАП – отраслевой фонд алгоритмов и программ.

8. Гарантийные обязательства (выполняются бесплатно согласно договору):

 устранение выявленных недостатков и ошибок;

 внесение необходимых изменений в программы и документацию;

 внесение изменений в технологический процесс;

 консультации пользователей.

9. Послегарантийные обязательства (выполняются за отдельную плату):

 анализ функционирования системы;

 выявление отклонений фактических эксплуатационных характеристик ИС от проектных значений и установление причин этих отклонений;

 устранение выявленных недостатков и обеспечение стабильности эксплуатационных характеристик ИС;

 внесение необходимых изменений в документацию на ИС;

 передача очередных версий.

 Согласно ГОСТ 34.601-90иОРММ ИСЖТ 5.03-00допускается:

 исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях;

 объединять стадии «Технический проект» и «Рабочая документация» в одну стадию «Технорабочий проект»;  выполнять отдельные этапы работ до завершения предшествующих стадий;

 параллельное во времени выполнение этапов работ;

 включение дополнительных этапов работ.

3. Распределение обязанностей между участниками проекта

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

Таблица 2.2. Роли участников в проекте

 

Роль	Функции
Руководитель (менеджер) проекта	Ищет потенциальных заказчиков. Заключает договор на разработку системы. Отвечает за планирование сроков и ресурсов. Выполняет управление и контроль за ходом выполнения проекта. Отвечает за взаимодействие с заказчиком
Эксперт-технолог	Делает постановку задачи. Определяет (совместно с системным аналитиком) основные функциональные и нефункциональные требования к системе. Определяет технологию использования разрабатываемой системы. Консультирует разработчиков в процессе создания системы. Участвует в процессе приемки системы в эксплуатацию
Системный аналитик (архитектор, главный конструктор)	Определяет функциональные и нефункциональные требования к системе, а также технологию ее использования. Выполняет анализ требований и ищет пути их реализации на уровне концепции системы. Задает архитектуру (скелет) системы и несет ответственность за соответствие моделей системы заданной архитектуре (отвечает за проектирование). Квалифицированный аналитик должен быть специалистом в области разработки программного обеспечения и должен быть (стать) специалистом в предметной области
Проектировщик	Разрабатывает модели системы на основе архитектуры
Программист	Реализует модели в виде программного обеспечения
Тестировщик	Разрабатывает тесты и тестирует модели системы и разработанное программное обеспечение
Технический редактор (писатель)	Готовит документацию для пользователей на разработанную систему. В комплект документации могут входить технологические инструкции, руководства пользователя, администратора системы, БД и т. д.
Инженер по внедрению	Внедряет разработанную систему на объекте автоматизации. В его функции может входить как первоначальная установка и настройка системы, так и обучение пользователей
Пользователь	Эксплуатирует систему в штатном режиме. Кроме этого, желательно, чтобы пользователь (помимо эксперта-технолога) был вовлечен в процесс формирования требований к системе

 

У проекта должен быть один руководитель и, как правило, один системный аналитик. За остальные роли в крупных проектах отвечает обычно по несколько человек. В табл. 2.2 роли эксперта-технолога и пользователя выполняют представители заказчика, остальные роли – представители разработчика. Эксперты-технологи могут быть приглашены из сторонней организации. По мере необходимости в проекте могут принимать участие координатор работ (ответственный) со стороны заказчика, аудиторы и т. д.

Лекция 3. МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА ИС

 1. Классификация моделей жизненного цикла

2. Каскадная стратегия

3. Инкрементная  стратегия

4. Спиральная стратегия

5. Сравнительный анализ моделей

6. Методологии, поддерживающие спиральную модель

1. Классификация моделей жизненного цикла

 К настоящему времени наибольшее распространение получили следующие модели (стратегии) жизненного цикла:

 каскадная;

 инкрементная;

 спиральная.

Дальнейшее рассмотрение моделей жизненного цикла ведется с использованием терминологии классического жизненного цикла.

2. Каскадная стратегия

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

 

Рис.3.1. Каскадная стратегия

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

Достоинства модели:

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

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

Недостатки модели:

 реальный процесс разработки информационной системы редко полностью укладывается в такую жесткую схему. Особенно это относится к разработке нетиповых и новаторских систем;

 жизненный цикл основан на точной формулировке исходных требований к информационной системе. Реально в начале проекта требования заказчика определены лишь частично;

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

3. Инкрементная  стратегия

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

 

Рис.3.2. Инкрементная стратегия

 

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

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

 отсутствия у заказчика возможности сразу профинансировать весь дорогостоящий проект;

 отсутствия у разработчика необходимых ресурсов для реализации сложного проекта в сжатые сроки;

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

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

4. Спиральная стратегия

 Спиральная стратегия (эволюционная или итерационная модель, автор Барри Боэм, 1988 г.) подразумевает разработку в виде последовательности версий, но в начале проекта определены не все требования. Требования уточняются в результате разработки версий (рис. 3.3).

 

Рис. 3.3. Спиральная стратегия

 

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

Достоинства модели:

 позволяет быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований;

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

 обеспечивает большую гибкость в управлении проектом;

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

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

 уменьшаются риски заказчика. Заказчик может с минимальными для себя финансовыми потерями завершить развитие неперспективного проекта.

Недостатки модели:

 увеличивается неопределенность у разработчика в перспективах развития проекта. Этот недостаток вытекает из предыдущего достоинства модели;

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

5. Сравнительный анализ моделей

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

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

Таблица 3.1. Сравнение моделей жизненного цикла

 

Характеристика проекта	Модель (стратегия)
	Каскадная	Инкрементная	Спиральная
Новизна разработки и обеспеченность ресурсами	Типовой. Хорошо проработаны технология и методы решения задачи		Нетиповой (новаторский). Нетрадиционный для разработчика
	Ресурсов заказчика и разработчика хватает для реализации проекта в сжатые сроки	Ресурсов заказчика или разработчика не хватает для реализации проекта в сжатые сроки
Масштаб проекта	Малые и средние проекты	Средние и крупные проекты	Любые проекты
Сроки выполнения проекта	До года	До нескольких лет. Разработка одной версии может занимать срок от нескольких недель до года
Заключение отдельных договоров на отдельные версии	Заключается один договор. Версия и есть итоговый результат проекта	На отдельную версию или несколько последовательных версий обычно заключается отдельный договор
Определение основных требований в начале проекта	Да	Да	Нет
Изменение требований по мере развития проекта	Нет	Незначительное	Да
Разработка итерациями	Нет	Да	Да
Распространение промежуточного ПО	Нет	Может быть	Да

 

В табл. 3.1 не стоит рассматривать значения «Да» и «Нет» как жесткие требования. Например, незначительное изменение требований по мере развития проекта при использовании каскадной модели (например, добавление некоторых непредусмотренных сервисных функций) встречается не так уж редко и в случае их реализации способствует улучшению взаимоотношений между сторонами. Аналогично распространение промежуточного программного обеспечения при спиральной модели необязательно, а иногда даже вредно отражается на процессах внедрения и опытной эксплуатации системы.

При разработке системы под итоговым продуктом и промежуточным программным обеспечением согласно следует понимать:

 ревизию (исправительную или опытную) – любые оперативные изменения программного и информационного обеспечения, а также БД,  необязательные в данный момент к передаче на объекты внедрения и связанные с устранением ошибок и усовершенствованием;

модификацию – любые оперативные изменения программного и информационного обеспечения, а также БД, обязательные для передачи на объекты внедрения и обусловливающие изменение эксплуатационных характеристик без изменения функций (предусмотренных ТЗ), а также изменения, связанные с устранением ошибок, усовершенствованием;

 версию – любые изменения программного и информационного обеспечения, а также БД, обязательные для передачи на объекты внедрения, позволяющие выполнять заявленные или дополнительные функции, а также обеспечивающие переход на новые операционные системы и информационную среду;

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

В соответствии с приведенной классификацией итоговым продуктом для любой из моделей жизненного цикла является обязательная к передаче версия или очередь системы. Разработка очередями характерна при инкрементной стратегии. В качестве промежуточного программного обеспечения следует рассматривать ревизии и модификации. Как было отмечено выше, частая передача ревизий и модификаций конечным пользователям (особенно занятым другими производственными делами) нежелательна. Согласно [12] смена версий информационных систем на железнодорожном транспорте должна выполняться не чаще одного - двух раз в год, а модификаций – не чаще раза в месяц.

6. Методологии, поддерживающие спиральную модель

 В настоящее время имеется несколько методологий¹ разработки программного обеспечения, которые можно рекомендовать при использовании спиральной модели жизненного цикла. Наиболее известными из них являются методология быстрой разработки приложений (Rapid Application Development, RAD) и экстремальное программирование (eXtreme Programming, XP – автор Кент Бек, 1999).

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

Под RAD-разработкой обычно понимается процесс разработки, содержащий 3 элемента:

 небольшую команду программистов (до 10 человек);

 короткий, но тщательно проработанный производственный график (от 2 до 6 месяцев);

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

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

 CASE²-средств для формирования и анализа требований, проектирования системы, автоматической генерации кода программ и структуры БД, а также автоматического тестирования программного обеспечения;

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

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

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

 шаблонов и библиотек готовых решений как собственной разработки, так и сторонних производителей.

Условия применения методологии RAD:

 применима для относительно небольших проектов, разрабатываемых под конкретного заказчика;

 неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т. е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода;

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

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

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

Отличительными особенностями XP-разработки являются:

 частая смена версий и модификаций (длительность итераций вплоть до часов и минут, а обычно – 2 недели; в RAD – минимум 2 месяца);

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

 простое проектирование – при разработке всегда выбирается наиболее простое решение. «Лучше сделать простую вещь сегодня и завтра заплатить еще немного за внесение небольших изменений, чем делать сегодня сложную вещь, которая завтра может не понадобиться»]. Спорное утверждение, на которое можно возразить, что «скупой платит дважды». Нередко опытному разработчику, особенно неплохо разбирающемуся в поставленной задаче, видно, что если применить более сложную схему реализации некоторой функции или расширить структуру данных, то это увеличит круг решаемых задач, позволит с меньшими затратами адаптировать систему под изменяющиеся или новые требования заказчика и т. д.;

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

 коллективное владение кодом – любой, кто видит возможность улучшить какую-то часть кода, может сделать это в любой момент времени. Это подразумевает применение одинаковых стандартов и правил оформления кода с исчерпывающими комментариями, а также и ведение общедоступной истории развития системы;

 программирование в парах – на пару программистов приходится один компьютер. Пока один из них непосредственно программирует, другой обдумывает вопросы реализации требований (функций, БД и т. п.). Смысл положения заключается не в экономии на материально-техническом обеспечении команды разработчиков, а в более разумном сочетании разных видов деятельности каждого из них. Как показывает опыт, при непосредственном программировании, исправлении ошибок и т.п. программист начинает думать односторонне и все более узкими категориями. Именно поэтому во время «отдыха от компьютера» приходят наиболее удачные решения;

 непрерывное и пересекающееся проектирование, разработка, интеграция и тестирование системы.

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

¹Методология – последовательность выполнения работ, правил выбора методов и решений на разных этапах разработки.

²CASE – Computer Aided Software Engineering (автоматизированная разработка ПО).

 

Лекция 4. ОСНОВЫ АНАЛИЗА И ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

 1. Особенности анализа и проектирования крупных систем

2. Документы, содержащие требования на разработку системы

3. Основные принципы проектирования

4. Классификация моделей информационной системы

1. Особенности анализа и проектирования крупных систем

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

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

 наличие совокупности тесно взаимодействующих компонентов (подсистем);

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

 необходимость интеграции существующих и вновь разрабатываемых подсистем;

 функционирование в неоднородной среде на разных аппаратных и операционных платформах;

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

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

 изменение или уточнение потребностей пользователей в процессе разработки и эксплуатации системы.

Непременным условием успешной реализации информационной системы является четкое и как можно более полное формирование требований на разработку системы, а также ее адекватное описание на стадии проектирования. Согласно [15]: «На обнаружение ошибок, допущенных на этапе анализа и проектирования, расходуется примерно в 2 раза больше времени, а на их исправление – примерно в 5 раз, чем на ошибки, допущенные на более поздних стадиях».

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

2. Документы, содержащие требования на разработку системы

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

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

Рис. 4.1. Пример календарного плана

 

Как было отмечено выше, техническое задание (ТЗ) является основным документом, определяющим требования и порядок создания (развития или модернизации) системы. Несмотря на то, что согласно [9,13] ТЗ составляется после заключения договора, нередко оно должно быть подготовлено разработчиком еще до его подписания.

Состав, содержание, правила оформления этого документа устанавливаются ГОСТ 34.602–89 «Техническое задание на создание автоматизированной системы» [3]. ТЗ, как правило, содержит следующие разделы:

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

 назначение и цели создания (развития) системы;

 характеристика объектов автоматизации;

требования к системе в целом, к функциям и обеспечению. При этом выделяют следующие виды обеспечения:

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

o информационное – совокупность форм документов, классификаторов, нормативной базы и реализованных решений по объемам, размещению и формам существования информации;

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

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

o техническое – совокупность всех технических средств, используемых при функционировании системы;

o организационное – совокупность документов, устанавливающих организационную структуру, права и обязанности пользователей и эксплуатационного персонала системы;

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

 состав и содержание работ по созданию системы;

 порядок контроля и приемки системы;

 требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

 требования к документированию;

 источники разработки – документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

Техническое задание может включать приложения, например:

 расчет ожидаемой эффективности системы;

 оценку научно-технического уровня системы;

 перечень основных входных и выходных форм и т. д.

Грамотно составленное ТЗ является залогом успешной реализации проекта. В некоторых организациях, обычно имевших «печальный» опыт недооценки этого важного документа, существует практика составления расширенного и более детального технического задания. Особое внимание при его подготовке следует уделить полному и точному описанию требований, полный перечень которых приведен в [3]. В противном случае разработчик может создать систему, которая не нужна заказчику или не соответствует всем его ожиданиям.

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

Требования к видам обеспечения, в отличие от предыдущих, не должны быть слишком жесткими. Они должны быть составлены разработчиком так, чтобы у него была возможность для маневра. По возможности рекомендуется эти требования декларировать без указания конкретных способов и методов решения задач, языков программирования и СУБД, технических устройств и т. п. Например, «Формирование файлов исходных данных и результатов расчета интервалов должны выполняться в достаточном объеме и форматах, необходимых для их автоматического использования в АРМ инженера-графиста ГВЦ МПС РФ». В то же время для некоторых видов обеспечения у заказчика могут быть жесткие требования по их реализации. Это может касаться математического обеспечения (например, «Расчет движения поездов должен выполняться в соответствии с действующими Правилами тяговых расчетов»), информационного обеспечения (например, «Формирование и выдача на печать Приказа начальника дороги об установлении допускаемых скоростей на перегонах должны производиться в виде типового документа») и т. д.

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

3. Основные принципы проектирования

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

Все наиболее распространенные методологии анализа и проектирования информационных систем при построении моделей базируются на ряде общих принципов [14,16,17].

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

2. Принцип иерархического упорядочения – принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне. Этот принцип предписывает рассматривать процесс построения модели системы на разных уровнях абстрагирования и детализации в рамках фиксированных представлений. Таким образом, проектирование можно представить как поуровневый спуск от наиболее общих и абстрактных моделей системы к более частным и детальным. При разработке программного обеспечения с помощью объектно-ориентированного подхода данный принцип получил название «наследование» – принцип, в соответствии с которым знание об общей категории разрешается применять для более узкой.

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

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

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

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

7. Принцип логической независимости заключается в концентрации внимания на логическом проектировании в целях обеспечения независимости от физической реализации.

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

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

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

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

4. Классификация моделей информационной системы

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

Классифицировать модели можно по следующим признакам.

1. По строгости описания:

 неформальные – представлены в неструктурированном виде и дают общее представление о моделируемой системе. Недостаточно наглядны (особенно при сложном взаимодействии между объектами) и неприемлемы для какого-либо количественного анализа и обработки автоматическими средствами;

 формальные:

o описательные – модели, где сведения представлены с помощью специальных документов (бланки, формы, анкеты, таблицы и т. п.);

o графические – модели представляют собой схемы, чертежи, графы, диаграммы и т. д. Наиболее наглядны и получили широкое распространение при проектировании с помощью CASE-средств;

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

2. По степени физической реализации (логической независимости):

 логические – описывают состав, структуру, состояние или поведение элементов системы без привязки к конкретным языкам или средам программирования, СУБД, техническим средствам и т. д. При разработке системы это обеспечивает гибкость в выборе и быстрый переход с одной программно-аппаратной платформы на другую;

 физические – описывают элементы системы в соответствии с принятой физической реализацией этих элементов (языками программирования, СУБД, устройствами, и т. д.);

3. По степени отображения динамики происходящих процессов:

 статические – описывают состав и структуру системы;

 динамические – описывают поведение системы и/или ее отдельных элементов. Как правило, такие модели описывают порядок действий или состояния системы и переходы между ними. Другими словами, в этих моделях явно или не явно присутствует понятие времени;

4. По отображаемому аспекту:

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

 информационные – описывают состав и структуру данных (реляционных БД, классов и др.). Относятся к статическим моделям;

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

 компонентные – описывают состав и структуру программных и аппаратных средств. Относятся к статическим моделям;

 смешанные  – характеризуют сразу несколько аспектов системы (например, диаграммы потоков данных отображают работы, накопители данных, подсистемы) и т. д.

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

5. ТЕХНОЛОГИИ И ПОДХОДЫ К АНАЛИЗУ И ПРОЕКТИРОВАНИЮ ИНФОРМАЦИОННЫХ СИСТЕМ

 1. CASE-технологии анализа и проектирования

2. Сущность структурного анализа и проектирования

1. CASE-технологии анализа и проектирования

 Максимально упростить и формализовать процессы формирования требований и проектирования системы позволяют современные CASE-средства.

В 70-х и 80-х гг. ХХ в. при разработке информационных систем достаточно широко стала применяться структурная методология анализа, предоставляющая в распоряжение разработчиков строгие формализованные методы описания системы и принимаемых технических решений. Она основана на применении наглядной графической техники (схем и диаграмм), предназначенной для описания различного рода моделей. Наглядность и строгость средств структурного анализа позволяла разработчикам и будущим пользователям системы с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных технических (проектных) решений[14].

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

CASE-технология представляет собой методологию проектирования информационных систем, набор методов, нотаций¹ и инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать модель системы на всех этапах разработки и сопровождения системы и разрабатывать приложения в соответствии с информационными потребностями пользователей [14].

В качестве инструментария реализации технологии используются CASE-средства, основными функциями которых являются:

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

 прямое проектирование программного обеспечения и баз данных. При этом порядок использования разработчиками CASE-средства следующий:

o создается логическая модель системы;

o выбирается конкретный язык программирования или СУБД для построения физической модели, после чего CASE-средство автоматически создает физическую модель системы;

o дорабатывается физическая модель;

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

обратное проектирование (реинжиниринг). В этом случае порядок использования CASE-средства обратный – от текста программы или базы данных на диске к логической модели. Помимо построения, CASE-средства позволяют быстро интегрировать полученные таким образом модели в проект, а также с меньшими потерями переходить от одной физической реализации к другой (например, в случае ухода «старых» разработчиков, плохо документирующих программное обеспечение, или появления новых, более перспективных языков программирования и СУБД);

 синхронизация моделей системы с ее физической реализацией. В случае изменения модели системы могут быть автоматически внесены необходимые изменения в физическую реализацию или наоборот;

 автоматическое обеспечение качества и тестирование моделей на наличие ошибок (например, ошибок нормализации БД), полноту и непротиворечивость;

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

Основная цель использования CASE-технологий заключается в максимальной автоматизации стадий анализа и проектирования систем с целью построения формальных и непротиворечивых моделей системы.

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

Большинство современных CASE-средств поддерживает методологии структурного и/или объектно-ориентированного анализа и проектирования информационных систем. Выбор того или иного подхода (парадигмы²) подразумевает следование ему и на стадии кодирования (согласно принципу концептуальной общности). Их отличие друг от друга заключается в выборе способа декомпозиции системы (задачи). Если за основу принимается функциональная (алгоритмическая) декомпозиция, то речь идет о структурном подходе, если объектная – об объектно-ориентированном.

Выбор того или иного подхода зависит от специфики решаемой задачи. Как правило, структурный подход применяется для автоматизации задач, оперирующих большими объемами «пассивных» данных и ориентированных на использование реляционных баз данных (например, учет, сбор статистики, математические и инженерные расчеты, анализ данных). Объектно-ориентированный подход в основном ориентирован на решение задач, в которых четко прослеживается деление системы на взаимодействующие между собой сущности (например, имитационное моделирование, управление техническими объектами или технологическими процессами, мониторинг³). Наиболее характерна эта особенность для распределенных систем.

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

¹Нотация – установленные способы отображения элементов системы, т. е. графы, таблицы, блок-схемы, формальные и естественные языки.

²Парадигма – исходная концептуальная схема (модель) постановки проблемы и ее решения.

³Мониторинг – комплексная система наблюдения, контроля, оценки и прогноза явлений, процессов, объектов и т. п.

2. Сущность структурного анализа и проектирования

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

Методологии структурного анализа и проектирования информационных систем появились позже фактического использования этих принципов на практике (структурного программирования). В конце 60-х гг. ХХ в.  стали появляться и применяться первые методологии, ориентированные на структурный подход.

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

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

Таблица 5.1. Методологии структурного анализа и проектирования

 

Методология	Тип разрабатываемой модели
SADT (Structured Analysis and Design Technique, методология структурного анализа и проектирования)	Функциональная
DFD (Data Flow Diagrams, диаграммы потоков данных)	Смешанная (функциональная, информационная, компонентная)
ERD (Entity-Relationship Diagrams, диаграммы «сущность-связь»)	Информационная
STD (State Transition Diagrams, диаграммы изменения состояний)	Поведенческая
Flowcharts (блок-схемы)	Смешанная (поведенческая, информационная, компонентная)

 Схематично применение структурного подхода изображено на рис. 5.1.

Рис. 5.1. Схема применения структурного подхода

 

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

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

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

Лекция 6,7. РАЗРАБОТКА ФУНКЦИОНАЛЬНОЙ МОДЕЛИ

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

2. Назначение и состав методологии SADT (IDEF0)

3. Элементы графической нотации IDEF0

4. Типы связей между работами

5. Правила и рекомендации построения диаграмм IDEF0

6. Пример построения модели IDEF0 для системы определения допускаемых скоростей

7. ICOM-коды

1. Назначение и состав DFD

2. Элементы графической нотации DFD

3. Правила и рекомендации построения DFD

4. Пример построения модели DFD для системы определения допускаемых скоростей

5. Расширения DFD для систем реального времени

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

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

При разработке функциональной модели (определении функциональных требований) может возникнуть множество проблем:

 заказчик не может точно выразить, решение каких задач возлагается на информационную систему. Зачастую заказчик даже не знает, что такое требование и как его формулировать;

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

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

 заказчик не верит в возможность выполнения некоторых функций «бездушными» машинами.

Построение функциональной модели должно решить большую часть этих проблем. Наиболее подробно этот процесс рассмотрен в [18,19].

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

 бесполезные, неуправляемые и дублирующие работы;

 работы без результата;

 неэффективный документооборот (нужный документ не оказывается в нужное время в нужном месте) и т. д.

Найденные в модели недостатки исправляются при создании модели TO-BE (как будет) – модели новой организации работы предприятия. Модель TO-BE нужна для анализа альтернативных путей решения задачи и выбора наилучшего из них.

Следует указать на распространенную ошибку при создании модели TO-BE – это создание идеализированной модели. Примером может служить создание модели на основе знаний руководителя, а не конкретного исполнителя работ. Руководитель знаком с тем, как предполагается выполнение работы по руководствам и должностным инструкциям и часто не знает, как на самом деле подчиненные выполняют работы. В результате получается приукрашенная, искаженная модель, которая несет ложную информацию и которую невозможно в дальнейшем использовать для анализа. Такая модель называется SHOULD-BE (как должно было быть).

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

Построение системы на основе модели SHOULD-BE приводит к тому, что такая система просто не будет использоваться.

Таким образом, наиболее эффективная технология построения функциональной модели заключается в разработке модели TO-BE на основе предварительно построенных моделей AS-IS и SHOULD-BE.

В настоящее время двумя наиболее популярными методологиями построения функциональных моделей являются SADTиDFD.

2. Назначение и состав методологии SADT (IDEF0)

 Методология SADT (Structured Analysis and Design Technique – методология структурного анализа и проектирования) представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели системы.

Начало разработки данной методологии было положено Дугласом Россом (США) в середине 60-х гг. ХХ в. С тех пор системные аналитики компании SofTech, Inc. улучшили SADT и использовали ее в решении широкого круга проблем. Программное обеспечение телефонных сетей, диагностика, долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, конфигурация компьютерных систем, обучение персонала, управление финансами и материально-техническим снабжением – вот некоторые из областей эффективного применения SADT. Широкий спектр областей указывает на универсальность и мощь методологии SADT. В программе «Интеграции компьютерных и промышленных технологий» (Integrated Computer Aided Manufacturing, ICAM) Министерства обороны США была признана полезность SADT. Это привело к публикации ее части в 1981 г., называемой IDEF0 (Icam DEFinition), в качестве федерального стандарта на разработку программного обеспечения. Под этим названием SADT стала применяться тысячами специалистов в военных и промышленных организациях [15]. Последняя редакция стандарта IDEF0 была выпущена в декабре 1993 г. Национальным институтом по стандартам и технологиям США (National Institute Standards and Technology, NIST).

Стоит отметить, что IDEF0 рекомендована для использования Госстандартом РФ и активно применяется в отечественных госструктурах (например, в Государственной налоговой инспекции РФ).

Данная методология при описании функционального аспекта информационной системы конкурирует с методами, ориентированными на потоки данных (DFD). В отличие от них IDEF0 позволяет:

 описывать любые системы, а не только информационные (DFD предназначена для описания программного обеспечения);

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

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

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

Модель (AS-IS, TO-BE или SHOULD-BE) может содержать 4 типа диаграмм [14,15,18,19]:

 контекстную диаграмму;

 диаграммы декомпозиции;

 диаграммы дерева узлов;

 диаграммы только для экспозиции (for exposition only, FEO).

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

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

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

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

3. Элементы графической нотации IDEF0

 Методология IDEF0 нашла широкое признание и применение, в первую очередь, благодаря простой графической нотации, используемой для построения модели. Главными компонентами модели являются диаграммы. На них отображаются функции системы в виде прямоугольников, а также связи между ними и внешней средой посредством стрелок. Использование всего лишь двух графических примитивов (прямоугольник и стрелка) позволяют быстро объяснить правила и принципы построения диаграмм IDEF0 людям, незнакомым с данной методологией. Это достоинство позволяет подключить и активизировать деятельность заказчика по описанию бизнес-процессов с использованием формального и наглядного графического языка.

Рассмотрим основные элементы графической нотации IDEF0 (рис. 6.1.) [15,18].

Рис. 6.1. Элементы графической нотации IDEF0

 Прямоугольник представляет собой работу (процесс, деятельность, функцию или задачу), которая имеет фиксированную цель и приводит к некоторому конечному результату. Имя работы должно выражать действие (например, «Изготовление детали», «Расчет допускаемых скоростей», «Формирование ведомости ЦДЛ № 3»).

Взаимодействие работ между собой и внешним миром описывается в виде стрелок. В IDEF0 различают 5 видов стрелок:

 вход (англ.  input) – материал или информация, которые используются и преобразуются работой для получения результата (выхода). Вход отвечает на вопрос «Что подлежит обработке?». В качестве входа может быть как материальный объект (сырье, деталь, экзаменационный билет), так и не имеющий четких физических контуров (запрос к БД, вопрос преподавателя). Допускается, что работа может не иметь ни одной стрелки входа. Стрелки входа всегда рисуются входящими в левую грань работы;

 управление (англ. control) – управляющие, регламентирующие и нормативные данные, которыми руководствуется работа. Управление отвечает на вопрос «В соответствии с чем выполняется работа?». Управление влияет на работу, но не преобразуется ей, т. е. выступает в качестве ограничения. В качестве управления могут быть правила, стандарты, нормативы, расценки, устные указания. Стрелки управления рисуются входящими в верхнюю грань работы. Если при построении диаграммы возникает вопрос, как правильно нарисовать стрелку сверху или слева, то рекомендуется ее рисовать как вход (стрелка слева);

 выход (англ. output) – материал или информация, которые представляют результат выполнения работы. Выход отвечает на вопрос «Что является результатом работы?». В качестве выхода может быть как материальный объект (деталь, автомобиль, платежные документы, ведомость), так и нематериальный (выборка данных из БД, ответ на вопрос, устное указание). Стрелки выхода рисуются исходящими из правой грани работы;

 механизм (англ. mechanism) – ресурсы, которые выполняют работу. Механизм отвечает на вопрос «Кто выполняет работу или посредством чего?». В качестве механизма могут быть персонал предприятия, студент, станок, оборудование, программа. Стрелки механизма рисуются входящими в нижнюю грань работы;

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

4. Типы связей между работами

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

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

1. Иерархическая связь (связь «часть» – «целое») имеет место между функцией и подфункциями, из которых она состоит (рис. 6.2).

Рис. 6.2. Иерархическая связь

 

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

Рис. 6.3. Прямая связь по управлению

Рис. 6.4. Обратная связь по управлению

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

Рис. 6.5. Прямая связь по входу

Рис. 6.6. Обратная связь по входу

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

Рис. 6.7. Потребительская связь

 

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

Рис. 6.8. Логическая связь

 

6. Коллегиальная (методическая) связь имеет место между функциями, алгоритм работы которых определяется одним и тем же управлением (рис. 6.9). Аналогом такой связи является совместная работа сотрудников одного отдела (коллег), подчиняющихся начальнику, который отдает указания и приказы (управляющие сигналы). Такая связь также возникает, когда алгоритмы работы этих функций определяются одним и тем же методическим обеспечением (СНИП, ГОСТ, официальными нормативными материалами и т. д.), служащим в качестве управления.

Рис. 6.9. Методическая связь

 

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

 

Рис. 6.10. Ресурсная связь

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

 

Рис. 6.11. Информационная связь

 

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

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

Рис. 6.12. Временная связь

 

10. Случайная связь возникает, когда конкретная связь между функциями мала или полностью отсутствует (рис. 6.13).

Рис. 6.13. Случайная связь

 

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

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

5. Правила и рекомендации построения диаграмм IDEF0

 В IDEF0 существуют соглашения (правила и рекомендации) по созданию диаграмм, которые призваны облегчить чтение и экспертизу модели [14,15,18,19]. Некоторые из этих правил CASE-средства поддерживают автоматически, выполнение других следует обеспечить вручную.

1. Перед построением модели необходимо определиться, какая модель (модели) системы будет построена. Это подразумевает определение ее типа AS-IS, TO-BE или SHOULD-BE, а также определения позиции, с точки зрения которой строится модель. «Точку зрения» лучше всего представлять себе как место (позицию) человека или объекта, в которое надо встать, чтобы увидеть систему в действии. Например, при построении модели работы продуктового магазина можно среди возможных претендентов, с точки зрения которых рассматривается система, выбрать продавца, кассира, бухгалтера или директора. Обычно выбирается одна точка зрения, наиболее полно охватывающая все нюансы работы системы, и при необходимости для некоторых диаграмм декомпозиции строятся диаграммы FEO, отображающие альтернативную точку зрения.

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

3. Количество блоков на диаграммах декомпозиции рекомендуется в пределах 3–6. Если на диаграмме декомпозиции два блока, то она, как правило, не имеет смысла. При наличии большого количества блоков диаграмма становится перенасыщенной и трудно читаемой.

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

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

Рис. 6.14. Функция без управления и входа

 

Блок с наличием только управления можно рассматривать как вызов в программе функции (процедуры) без параметров. Если у блока имеется вход, то он эквивалентен вызову в программе функции с параметрами. Таким образом, блок без управления и входа эквивалентен функции, которая в программе ни разу не вызывается на исполнение.

На рис. 6.7–6.12, отображающих фрагменты диаграмм IDEF0, встречаются блоки без входа и управления. Это не стоит рассматривать как ошибку, так как подразумевается, что одна из этих стрелок должна быть.

6. У каждого блока должен быть как минимум один выход (рис. 6.15).

Рис. 6.15. Функция без выхода

Работы без результата не имеют смысла и не должны моделироваться. Исключение составляют работы, отображаемые в модели AS-IS. Их наличие свидетельствует о неэффективности и несовершенстве технологических процессов. В модели TO-BE эти работы должны отсутствовать.

7. При построении диаграмм следует минимизировать число пересечений, петель и поворотов стрелок.

8. Обратные связи и итерации (циклические действия) могут быть изображены с помощью обратных дуг. Обратные связи по входу рисуются «нижней» петлей, обратная связь по управлению – «верхней» (см. рис. 6.4 и 6.6).

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

Рис. 6.16. Ветвление стрелок

При этом допускается задание различным ветвям стрелки уточняющих имен после разветвления (до слияния). Если какая-либо ветвь после ветвления не именована, то считается, что ее имя соответствует имени стрелки, записанному до ветвления.

Так, на рис. 6.16 управления, входящие в блоки «Изготовление деталей» и «Сборка изделия», имеют уточняющие значения и являются составной частью более общего управления «Чертежи». Для работы блока «Контроль качества» используются все чертежи.

На диаграмме не допускается рисовать стрелки, когда до и после ветвления они не именованы. На рис. 6.17 стрелка, входящая в блок «Формирование типовых ведомостей», не имеет имени до и после ветвления, что является ошибкой.

Рис. 6.17. Неправильное именование стрелок

 

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

Рис. 6.18. Туннелирование стрелок

 

В данном примере при построении модели проведения новогоднего утренника механизм «два топора» не будет отображаться на диаграммах верхних уровней, при чтении которых может возникнуть справедливый вопрос: «А зачем нужны два топора на новогоднем утреннике?».

Аналогичным образом можно выполнять туннелирование с обратной целью – недопущения отображения стрелки на диаграммах низших уровней. В этом случае круглые скобки ставятся на конце стрелки. На контекстной диаграмме (см. рис. 6.21) затуннелирован механизм «Инженер службы пути», входящий в блок «Определение допускаемых скоростей». Такое решение принято, так как инженер непосредственно участвует во всех работах, отображенных на диаграмме декомпозиции этого блока (см. рис. 6.22). Чтобы не показывать эту связь и не загромождать диаграмму декомпозиции, стрелка была затуннелирована.

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

12. Если две стрелки проходят параллельно (начинаются из одной и той же грани одной работы и заканчиваются на одной и той же грани другой работы), то по возможности следует их объединить и называть единым термином (рис. 6.19).

Рис. 6.19. Объединение связей

13. Каждый блок на диаграммах должен иметь свой номер. Для того чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Блок на диаграмме верхнего уровня обозначается 0, блоки на диаграммах второго уровня – цифрами от 1 до 9 (1, 2, …, 9), блоки на третьем уровне – двумя цифрами, первая из которых указывает на номер детализируемого блока с родительской диаграммы, а вторая номер блока по порядку на текущей диаграмме (11, 12, 25, 63) и т. д. Контекстная диаграмма имеет обозначение «А – 0», диаграмма декомпозиции первого уровня – «А0», диаграммы декомпозиции следующих уровней – состоят из буквы «А», за которой следует номер декомпозируемого блока (например, «А11», «А12», «А25», «А63»). На рис. 6.20 показано типичное дерево диаграмм (диаграмма дерева узлов) с нумерацией.

Рис. 6.20. Иерархия диаграмм

 

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

6. Пример построения модели IDEF0 для системы определения допускаемых скоростей

 Расчет допускаемых скоростей движения поездов является трудоемкой инженерной задачей. При проходе поездом какого-либо участка фактическая скорость движения поезда не должна превышать предельно допускаемую. Эта предельно допускаемая скорость устанавливается исходя из опыта эксплуатации и специально проводимых испытаний по динамике движения и воздействию на путь подвижного состава. Непревышение этой скорости гарантирует безопасность движения поездов, комфортабельные условия езды пассажиров и т. п. Они определяются в зависимости от типа подвижного состава (марки локомотива и типа вагонов), параметров верхнего строения пути (типа рельсов, балласта, эпюры шпал) и плана (радиуса кривых, переходных кривых, возвышения наружного рельса и т. д.). Как правило, для установления допускаемых скоростей необходимо определить не менее двух (на прямых) и пяти (в кривых) скоростей, из которых и выбирается окончательная допускаемая скорость, как наименьшая из всех рассчитанных. Расчет этих скоростей регламентируются Приказом МПС России № 41 от 12 ноября 2001 г. «Нормы допускаемых скоростей движения подвижного состава по железнодорожным путям колеи 1520 (1524) мм Федерального железнодорожного транспорта».

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

Контекстная диаграмма для задачи определения допускаемых скоростей показана на рис.6.21. Для построения модели использовался продукт BPwin 4.0 фирмы Computer Associates.

Рис. 6.21. Контекстная диаграмма системы определения допускаемых скоростей (методология IDEF0)

 

В качестве исходной информации, на основе которой выполняется определение допускаемых скоростей, используются:

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

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

 паспорт дистанции пути (содержит информацию, аналогичную рассмотренной выше, а также сведения о верхнем строении пути (ВСП));

 данные о результатах съемки плана пути вагоном-путеизмерителем;

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

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

Управляющими данными являются:

 указание начальника службы пути дороги или Департамента пути и сооружений ОАО «РЖД» на расчет;

 Приказ № 41, содержащий нормативно-справочную информацию, порядок и формулы определения допускаемых скоростей;

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

 сведения о планируемых ремонтах пути, реконструкции и переустройстве сооружений и устройств.

Результатом работы системы должны быть:

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

 ведомости Приказа начальника дороги об установлении допускаемых скоростей на перегонах и раздельных пунктах (Приказ «Н») согласно принятой на дороге форме. Утвержденный Приказ «Н» официально закрепляет допускаемые скорости движения поездов;

 типовые формы № 1, 1а и 2, содержащие планируемые допускаемые скорости для разработки графика движения поездов.

Скорости, содержащиеся в Приказе «Н» и типовых формах, могут отличаться от рассчитанных и показываемых в ведомостях допускаемых скоростей. Это связано с тем, что в них отражают ограничения скорости не только по конструкции подвижного состава, параметров ВСП и кривых, но и по состоянию устройств и сооружений (деформация земляного полотна, перекос опор контактной сети и т. д.). Кроме того, они корректируются с учетом планируемых ремонтов пути, реконструкции и переустройства сооружений и устройств и т. д.

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

Диаграмма декомпозиции первого уровня для рассматриваемой задачи приведена на рис.6.22. Как правило, при построении диаграммы декомпозиции исходная функция (декомпозируемая) разбивается на 3–8 подфункций (блоков). При этом блоки на диаграмме декомпозиции рекомендуется располагать слева направо сверху вниз, чтобы лучше была видна последовательность и логика взаимодействия подфункций.

Рис. 6.22. Диаграмма декомпозиции первого уровня (методология IDEF0)

 

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

 ввод и корректировка нормативно-справочной информации и данных по участкам дороги (блоки 1 и 2);

 подготовка задания на расчет (блок 3). В нем указывается, для какого участка и пути, а также марки локомотива и типа вагонов следует выполнить расчет;

 расчет допускаемых скоростей в соответствии с порядком и формулами, указанными в Приказе № 41 (блок 4). В качестве исходной информации выступают данные по пути участка (план, верхнее строение пути и т. д.) и нормативы, выбираемые на основании задания на расчет;

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

 формирование и подготовка проекта Приказа «Н» и типовых ведомостей (блоки 6 и 7).

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

7. ICOM-коды

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

ICOM-коды (аббревиатура от Input, Control, Output и Mechanism) предназначены для идентификации граничных стрелок. ICOM-код содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер (см. рис. 6.22).

8. Назначение и состав DFD

При построении функциональной модели системы альтернативой методологии SADT(IDEF0) является методологиядиаграмм потоков данных (Data Flow Diagrams, DFD). В отличие от IDEF0, предназначенной для проектирования систем вообще, DFD предназначена для проектирования информационных систем. Ориентированность этой методологии на проектирование автоматизированных систем делает ее удобным и более выгодным инструментом при построении функциональной модели TO-BE.

Как и в IDEF0основу методологии DFD составляет графический язык описания процессов. Авторами одной из первых графических нотаций DFD (1979 г.) стали Эд Йордан (Yourdon) и Том де Марко (DeMarko).

В настоящее время наиболее распространенной является нотация Гейна-Сарсона (Gane-Sarson).

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

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

Лекция 7.

1. Элементы графической нотации DFD

 Согласно DFD источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации [14,17,18,19].

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

Таблица 6.1. Элементы графической нотации DFD

 

Наименование	Нотация Йордана	Нотация Гейна-Сарсона
Поток данных
Процесс (система, подсистема)
Накопитель данных
Внешняя сущность

 

Далее в примерах будет использоваться нотация Гейна-Сарсона.

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

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

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

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

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

 «Ввести сведения о клиентах»;

 «Рассчитать допускаемую скорость»;

 «Сформировать ведомость допускаемых скоростей»

Номер процесса служит для его идентификации и ставится с учетом декомпозиции. В отличие от IDEF0вложенность процессов обозначается через точку (например, вIDEF0– «236», в DFD – «2.3.6»).

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

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

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

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

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

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

2. Правила и рекомендации построения DFD

 Правила и рекомендации построения модели DFD в основном совпадают с принятыми в IDEF0. Часть из них приведена вподразд. 6.9.

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

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

Наличие только выходящих потоков из накопителя также является ошибкой. Прежде чем использовать данные из накопителя, они должны там появиться в результате работы какого-либо процесса (подсистемы, внешней сущности). Исключением из правил считается случай, когда накопитель является внешней сущностью. Тогда допускается наличие либо только входящих стрелок, либо только выходящих стрелок (см. рис. 6.23, накопитель «БД АРМ-П или СБД-П»).

 

 

6.11. Пример построения модели DFD для системы определения допускаемых скоростей

 

Описание задачи приведено в подразд. 6.

Построение функциональной модели DFD начинается как и в IDEF0 с разработки контекстной диаграммы. На ней отображается основной процесс (сама система в целом) и ее связи с внешней средой (внешними сущностями). Это взаимодействие показывается через потоки данных. Допускается на контекстной диаграмме отображать сразу несколько основных процессов или подсистем. Пример контекстной диаграммы для рассматриваемой задачи приведен на рис. 6.23.

Рис. 6.23. Контекстная диаграмма системы определения допускаемых скоростей (методология DFD)

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

В то же время в системе оставлена возможность ее ручного ввода и корректировки. Несмотря на то, что БД АРМ-П или СБД-П по отношению к системе являются внешними сущностями, они, в целях лучшего восприятия, показаны в виде накопителя данных.

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

Диаграмма декомпозиции первого уровня проектируемой системы приведена на рис. 6.24.

Рис. 6.24.  Диаграмма декомпозиции первого уровня (методология DFD)

 

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

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

Контекстная диаграмма и диаграмма декомпозиции выполнены с использованием BPwin 4.0.

Решение о завершении детализации процесса и использовании миниспецификации принимается проектировщиком исходя из следующих критериев:

 наличия у процесса относительно небольшого количества входных и выходных потоков данных (2–3 потока);

 возможности описания процессов в виде простого алгоритма;

 возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20–30 строк).

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

3. Расширения DFD для систем реального времени

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

Квазинепрерывный поток (лат. quasi – как будто, якобы) – поток данных, непрерывный во времени. Отображается линией с двумя стрелками на конце (рис. 6.25).

Рис. 6.25. Квазинепрерывный поток

 

Управляющий процесс – процесс, формирующий сигналы управления на выходе (рис. 6.26).

Рис. 6.26. Управляющий процесс

 

Управляющий поток – управляющая информация, запускающая процесс (подсистему) или изменяющая ход его выполнения (рис. 6.27).

 

Рис. 6.27. Управляющий поток

 

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

Накопитель управлений – накопитель управляющих потоков (рис. 6.28).

Рис. 6.28. Накопитель управления

 

На рис. 6.29 показан пример использования новых элементов на DFD.

Рис. 6.29. Фрагмент DFD системы реального времени