КИС

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

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

2.3.МЕТОДОЛОГИИ И ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ (CASE-СРЕДСТВА)

Методологии, технологии и инструментальные средства проектирования (CA-SE-средства) составляют основу проекта любой ИС. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ.

Технология проектирования определяется как совокупность трех составляющих:

1)пошаговой процедуры, определяющей последовательность технологических операций проектирования (рис. 2.4);

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

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

Рис. 2.4. Представление технологической операции проектирования

71

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

Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям:

1)поддерживать полный ЖЦ ПО;

2)обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время;

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

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

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

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

ееверсий с версиями проекта;

7)обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования);

8)поддерживаться комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.

Реальное применение любой технологии проектирования, разработки и сопровождения ИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглаше-

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

Ктаким стандартам относятся следующие.

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

72

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

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

кнастройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.

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

2.4.СТРУКТУРНЫЙ ПОДХОД К ПРОЕКТИРОВАНИЮ ИНФОРМАЦИОННЫХ СИСТЕМ

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

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

73

1)принцип абстрагирования – выделение существенных аспектов системы и отвлечения от несущественных;

2)принцип формализации – необходимость строгого методического подхода к решению проблемы;

3)принцип непротиворечивости – обоснованность и согласованность элементов;

4)принцип структурирования данных – данные должны быть структурированы и иерархически организованы.

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

− ERD (Entity-Relationship Diagrams) диаграммы «сущностьсвязь» (п. 2.4.3).

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

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

2.4.1.Моделирование потоков данных (процессов) DFD

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

Для изображения DFD используются различные графические нотации, приведенные в табл. 2.1. Наиболее часто используются нотации Йодана (Yoardan) и Гейна-Сарсона (Gane-Sarson).

74

2.1. Нотации диаграмм потоков данных

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

75

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

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

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

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

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

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

76

ли и другие внешние системы. Основной процесс должен отражать главную цель или природу системы насколько это возможно.

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

−наличие большого количества внешних сущностей (десять и

более);

−распределенная природа системы;

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

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

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

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

иколлективы разработчиков.

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

На рисунке 2.6 показана детализация контекстной диаграммы, на которой выделено четыре подсистемы. Заметим, что на этой диаграмме внешняя сущность «Руководство» показана дважды для того, чтобы избежать лишних пересечений потоков данных. Некоторые нотации разрешают также изображать на детализирующих диаграммах объекты, имеющиеся на диаграмме верхнего уровня.

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

77

Рис. 2.6. Пример детализирующей диаграммы потоков данных

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

79

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

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

2.4.2. CASE-средство ERwin7

ERwin – обобщенное название линейки средств разработки баз данных. В настоящее время наиболее популярна версия AllFusion ERwin Data Modeler 7 (Erwin7). Для визуального проектирования систем обработки транзакций, витрин и хранилищ данных в единой интегрированной среде ERwin7 поддерживает три популярные нотации моделирования данных: Integration DEFinition for Information Modeling

(IDEF1X), Information Engineering (IE), Dimensional Modeling (DM). По разработанной модели данных может быть автоматически сгенерирована структура базы данных в заданной реляционной СУБД.

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

Сначала создадим логическую модель данных, для чего в меню Model выберем пункт Logical Model. С помощью инструмента «Entity» создадим четыре сущности и назовем их «Служащий», «Дети», «Должность», «Зарплата».

Выбрав каждую сущность с помощью контекстного меню «Entity Properties» на вкладке Entities/Definition, зададим для нее подробное описание на русском языке. Это описание можно будет поместить в отчет по модели или отобразить на диаграмме.

Укажем связи между сущностями. Свяжем сущность «Служащий» идентифицирующей связью с сущностью «Дети», для чего выберем инструмент «Identifying relationship» и укажем мышкой вначале на родительскую сущность «Служащий», а затем на дочернюю «Дети». Затем можно выбрать на диаграмме эту связь и в окне «Relationships» задать ее свойства, в поле «Verb Phrase/Parent-to-Child» укажем фразу характеризующую связь между сущностями «Воспитывает». Анало-

80