Рис. 1.2. Реальный процесс разработки ПО по каскадной схеме

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

Для преодоления  перечисленных проблем была предложена спиральная модель ЖЦ [10] (рис. 1.3), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость  технических решений проверяется  путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.

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

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

Рис 1.3. Спиральная модель ЖЦ ИС

Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время  широкое распространение методология  быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:

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

Жизненный цикл ПО по методологии RAD ( и по ГОСТу  тоже) состоит из четырех фаз:

• фаза определения требований и анализа;
• фаза проектирования;
• фаза реализации;
• фаза внедрения.

Последовательность  этапов создания ИС на фазе определения  требований и анализа:

• Описание предметной области, структура организации, задачи, решаемые подразделениями, ДПД для существующей информационной технологии.
• Назначение ИС.
• Построение начальной контекстной диаграммы потоков данных (DFD).
• Формирование матрицы списка событий (ELM) и таблицы потоков данных.
• Построение иерархии контекстных диаграмм.
• Диаграмма структур данных.

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

Результатами  проектирования архитектуры являются:

• модель процессов (диаграммы архитектуры системы (SAD) и миниспецификации на структурированном языке);
• модель данных (ERD и подсхемы ERD);
• модель пользовательского интерфейса (классификация процессов на интерактивные и неинтерактивные функции, диаграмма последовательности форм (FSD - Form Sequence Diagram), показывающая, какие формы появляются в приложении и в каком порядке. На FSD фиксируется набор и структура вызовов экранных форм. Диаграммы FSD образуют иерархию, на вершине которой находится главная форма приложения, реализующего подсистему. На втором уровне находятся формы, реализующие процессы нижнего уровня функциональной структуры, зафиксированной на диаграммах SAD.

Инфологическое  проектирование. Модель "сущность-связь"

 

     Понятие модели данных (МД)

     Под моделью данных М будем понимать пару:

     М=<F, O>, где F - множество допустимых форматов данных; а  О - множество  выполняемых над ними операций.

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

     Примером  таких абстрактных машин являются интерпретаторы (или трансляторы) с алгоритмических языков программирования (ЯП) высокого уровня. Каждый ЯП обладает своей МД, независимой от машинной. Например, МД ФОРТРАНа оказывается удобной для представления как отдельных числовых величин (переменные), так и однородных совокупностей чисел (массивы, но не для работы с символьной информацией. Совокупность операторов любого алгоритмического языка (АЯ) может быть разбита на две основные группы: операторы декларативного типа и операторы процедурные. МД АЯ формально описывает множество допустимых логических структур данных, которые могут быть приняты, обработаны и выданы программами, составленными на этом АЯ.

     С позиций систем обработки данных все МД можно разделить на сильноструктурированные МД и слабоструктурированные МД. В сильноструктурированных МД. К сильноструктурированным МД относятся реляционная МД, объектная МД, семантическая сеть;  к слабоструктурированным МД относятся модели данных поиска и обработки документов, которые рассматриваются неструктурированно в виде символьных строк.

     Все сказанное о сильноструктурированных МД относится к МД любой программной системы обработки данных и, в частности к МД, поддерживаемой конкретной СУБД. Поэтому можно сказать, что совокупность языка описания данных (ЯОД) и языка манипулирования данными (ЯМД) определяет МД, поддерживаемую СУБД (т.е. совокупность методов и средств для определения логической структуры БД и динамического моделирования в БД состояний предметной области (ПО)).

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

     Пусть МД оперирует понятиями

     “поле”, “запись”, “БД”, которые определяют ее понятийный базис;

     поле - поименованное элементарное данное;

     запись - поименованная совокупность полей;

     БД - поименованная совокупность записей.

     Тогда прямое моделирование может быть выполнено для следующих типов  понятий инфологической модели ПО:

1. атрибут сущности - поле;

       значение атрибута - значение поля;

2. тип сущности моделируется схемой записи.

     Пример: тип сущности СЛУЖАЩИЙ, описывается атрибутами ТАБЕЛЬНЫЙ-НОМЕР, ФАМИЛИЯ, ГОД-РОЖДЕНИЯ, ОБРАЗОВАНИЕ, может быть смоделироан схемой: СЛУЖАЩИЙ (Т-Н, Ф, Г-Р, О)

     или в терминах ЯОД:

     01 СЛУЖАЩИЙ

     02 ТАБЕЛЬНЫЙ-НОМЕР; ШАБЛОН 9999 /число/; КЛЮЧ /поле является первичным  ключом записи/

     02 ФАМИЛИЯ; ШАБЛОН А (25) /символьное  поле/;

     02 ГОД-РОЖДЕНИЯ; ШАБЛОН 9999

     02 ОБРАЗОВАНИЕ; ШАБЛОН А (10)

3. экземпляр сущности - экземпляр записи;
4. набор ЭС одного типа моделируется одной БД.

     Пример: БД СЛУЖАЩИЕ = совокупность записей  типа СЛУЖАЩИЙ.

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

     Пример: Связь РАБОТАЕТ-В между сущностями СЛУЖАЩИЙ, ОТДЕЛ представлен следующей  схемой записи:

     01 РАБОТАЕТ-В

     02 ТАБЕЛЬНЫЙ-НОМЕР; ШАБЛОН 9999; КЛЮЧ

     02 ШИФР-ОТДЕЛА; ШАБЛОН 9999; КЛЮЧ

     Набор экземпляров сущностей этого  типа моделируется отдельной БД. Другой вариант - представление связи в виде атрибута сущности СЛУЖАЩИЙ и модификация схемы записи добавлением:

     02 ШИФР-ОТДЕЛА; ШАБЛОН 99

     В развитых моделях велико число косвенных  путей моделирования.

     Чем большее количество конструкций инфологической модели ПО может быть представлено прямым моделированием при датологическом проектировании БД, тем более удачной считается МД.

     Кроме анализа возможностей прямого моделирования  проектировщик оценивает и другие свойства МД СУБД:

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

 

Структуры, операции, ограничения МД

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

           Структуры данных. Например, для файловой информационной системы (ФИС): поле - наименьшая поименованная единица данных; запись - поименованная совокупность полей; файл и т. п.). В этой модели агрегация используется для композиции полей в запись, а обобщение - для представления множества экземпляров записей одного типа одной структуры более высокого уровня - файлом. Т. о. структуризация данных базируется на использовании концепций “агрегации” и “обобщения”.

           Для обозначения  типов структур данных широко используется терминология, предложенная CODASYL (The Conference on Data Systems Languages) - ассоциацией по языкам СОД.

           Схема (рис. 1) определяет порядок композиции структур данных.

     

     Рис 1

           Элемент данных (ЭД) - наименьшая поименованная единица данных (аналог “поля” в ФИС), к которой СУБД может адресоваться непосредственно, и с помощью которой выполняется построение всех остальных структур. ЭД имеет имя и значение.

           Агрегат данных (АД) - поименованная совокупность ЭД внутри записи, которую можно рассматривать как единое целое. АД может быть простым (рис. 2) или составным (рис. 3).