Затонский А.В. Пособие по полному жизненному циклу информационных систем

Подождите немного. Документ загружается.

2. Фреймы и сети фреймов;

3. Продукционные модели.

Семантические сети определяют как граф общего вида, в котором

можно выделить множество вершин и ребер. Каждая вершина графа

представляет некоторое понятие, а дуга — отношение между парой понятий.

Метка и направление дуги конкретизируют семантику. Метки вершин

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

Различные разновидности семантических сетей обладают различной

семантической мощностью, следовательно, можно описать одну и ту же

предметную область более компактно или громоздко.

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

стереотипных объектов, событий или ситуаций. Фреймовая модель

представления знаний состоит из двух частей:

• набора фреймов, составляющих библиотеку внутри представляемых

знаний;

• механизмов их преобразования, связывания и т.д.

Существует два типа фреймов:

• образец (прототип) - интенсиональное описание некоторого множества

экземпляров;

• экземпляр (пример) - экстенсиональное представление фрейм-образца.

В общем виде фрейм может быть представлен следующим кортежем:

<ИФ, (ИС, ЗС, ПП), ..., (ИС, ЗС, ПП)>,

где ИФ – имя фрейма; ИС – имя слота; ЗС – значение слота; ПП – имя

присоединенной процедуры (необязательный параметр).

Слоты — это некоторые незаполненные подструктуры фрейма,

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

соответствие некоторой ситуации, явлению или объекту.

В качестве данных фрейм может содержать обращения к процедурам (так

называемые присоединенные процедуры). Выделяют два вида процедур:

процедуры-демоны и процедуры-слуги. Процедуры-демоны активизируются

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

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

пользователем при создании фрейма.

Продукционные модели — это набор правил вида «условия — действие»,

где условиями являются утверждения о содержимом базы данных, а действия

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

данных.

Формально продукция определяется следующим образом;

(0); Q; Л С; Л → В; N,

где (0 — имя продукции (правила); Q — сфера применения правила; Р —

предусловие (например, приоритетность); С—предикат (отношение); А → В —

ядро; N — постусловия (изменения, вносимые в систему правил).

Практически продукции строятся по схеме «ЕСЛИ» (причина или иначе

посылка), «ТО» (следствие или иначе цель правила).

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

использоваться в следующих целях:

• понимание и интерпретация фактов и правил с использованием

продукций, фреймов, семантических цепей;

• решение задач с помощью моделирования;

• идентификация источника данных, причин несовпадений новых знаний

со старыми, получение метазнаний;

• составление вопросов к системе;

• усвоение новых знаний, устранение противоречий, систематизация

избыточных данных.

Жизненный цикл информационных систем

Современные информационные технологии предоставляют широкий

набор способов реализации ИС [65]. Выбор конкретного способа определяется

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

правило, изменяются в процессе разработки. Для теории принятия решений

процесс проектирования ИС – это процесс принятия проектно-конструкторских

решений, направленных на получение версии ИС, удовлетворяющей

требования заказчика.

Разработка ИС носит творческий характер (на каждом шаге приходится

делать какой-либо выбор, принимать какое-либо решение), а не сводится к

выполнению какой-либо последовательности регламентированных действий.

Тем самым эта разработка ближе к процессу проектирования каких-либо

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

характер разработки ИС сохраняется до самого ее конца.

Продукт разработки ИС представляет собой некоторую совокупность

текстов (т.е. статических объектов), смысл же (семантика) этих текстов

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

запускающих эти процессы (т.е. является динамическим). Это предопределяет

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

Продукт разработки имеет и другую специфическую особенность: ИС

при своем использовании (эксплуатации) не расходуется и не расходует

используемых ресурсов.

Под жизненным циклом ИС понимают весь период его разработки и

эксплуатации (использования), начиная от момента возникновения замысла ИС

и кончая прекращением всех видов его использования. Жизненный цикл

охватывает довольно сложный процесс создания и использования ИС. Этот

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

зависимости от особенностей коллектива разработчиков.

В настоящее время можно выделить несколько основных подходов к

организации процесса создания и использования ИС.

• Водопадный (каскадный) подход. При таком подходе разработка ИС

состоит из цепочки этапов. На каждом этапе создаются документы,

используемые на последующем этапе. В исходном документе

фиксируются требования к ИС. В конце этой цепочки создаются

программы, включаемые в ИС.

• Итерационный (спиральный) подход. ИС создается в несколько «витков

спирали» (итераций) методом прототипирования. На каждом витке в ИС

добавляются новые возможности, тем самым, все более полно

охватывается предметная область.

• Исследовательское программирование. Этот подход предполагает

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

ИС, выполняющих лишь в первом приближении требуемые функции.

После экспериментального применения реализованных программ

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

пользователей. Процесс повторяется до тех пор, пока ИС не будет

достаточно приемлема для пользователей. Исследовательское

программирование исходит из взгляда на программирование как на

искусство. В настоящее время этот подход применяется для разработки

таких ИС, для которых пользователи не могут точно сформулировать

требования или для разработки ИС методами экстремального

программирования.

• Прототипирование. Этот подход моделирует начальную фазу

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

версий программ, предназначенных для проведения экспериментов с

целью установить требования к ИС. В дальнейшем должна последовать

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

другого подхода (например, водопадного).

• Формальные преобразования. Этот подход включает разработку

формальных спецификаций ИС и превращение их в программы путем

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

технология (CASE-технология) разработки ИС.

• Сборочное программирование. Этот подход предполагает, что ИС

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

существуют. Должно быть некоторое хранилище (библиотека) таких

компонент, каждая из которых может многократно использоваться в

разных ИС. Такие компоненты называются повторно используемыми

(reusable). Процесс разработки ИС при данном подходе состоит скорее из

сборки программ из компонент, чем из их программирования.

Водопадный подход

Будем рассматривать водопадный подход с некоторыми модификациями.

Во-первых, потому, что в этом подходе приходиться иметь дело с

большинством процессов программной инженерии, а, во-вторых, потому, что в

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

Именно этот подход рассматривается в качестве индустриального подхода

разработки программного обеспечения [24]. В его рамках различают

следующие стадии жизненного цикла ИС (рис. 9).

Рис. 9. Этапы и стадии водопадного подхода

1. Стадия разработки ИС

1.1. Этап внешнего описания ИС. Включает процессы, приводящие к

созданию внешнего описания ИС. Этот документ содержит: анализ и

определение требований к ИС со стороны пользователей (заказчика),

описание поведения ИС с точки зрения внешнего по отношению к ней

наблюдателя, требования относительно ее качества, процессы

спецификации этих требований, технико-экономическое обоснование.

Внешнее описание завершается созданием технического задания на

разработку ИС или одного из этапов реализации ИС.

1.2. Этап конструирования ИС. Охватывает процессы: разработку

архитектуры ИС, состава автоматизируемых функций,

обеспечивающих подсистем, разработку структур программ ПС и их

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

проекта ИС.

1.3. Этап кодирования (реализации) ИС. Включает процессы создания

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

тестированием ИС (автономное тестирование, затем интеграция и

комплексное тестирование), наполнение баз данных, создание

рабочих инструкций для пользователей. Завершается созданием

рабочего проекта ИС. Часто этапы конструирования и кодирования

существенно перекрываются. На этапе реализации создаются альфа- и

Стадия разработки ИС Стадия эксплуатации ИС

Стадия производства ИС

Стадия вывода ИС из

эксплуатации

Этап аттестации

Этап кодирования

Этап конструирования

Этап внешнего описания

бета-версии (пробная версия для работы разработчиков и пробная

версия для работы пользователей). Создается документация для

пользователей, администраторов и установщиков ИС.

1.4. Этап аттестации ИС. Производится оценка качества ИС. Если эта

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

ИС, то разработка ИС считается законченной. Это обычно

оформляется в виде некоторого документа (акта), фиксирующего

решение комиссии, проводящей аттестацию ИС. Аттестация

проводится в форме тестирования или опытной эксплуатации бета-

версии.

2. Стадия производства программных изделий. Программное изделие (ПИ)

−

экземпляр или копия разработанной ИС. Изготовление ПИ − это процесс

генерации и/или воспроизведения (снятия копии) программ и программных

документов ИС с целью их поставки пользователю для применения по

назначению. Производство ПИ − это совокупность работ по обеспечению

изготовления требуемого количества ПИ в установленные сроки. Стадия

производства ПИ в жизненном цикле ИС является, по существу,

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

которая может быть выполнена автоматически и без ошибок. Этим она

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

связи с этим в литературе эту стадию, как правило, не включают в

жизненный цикл ИС.

3. Стадия эксплуатации ИС. Охватывает процессы хранения, внедрения и

сопровождения ИС, а также транспортировки и применения ПИ по своему

назначению. Она состоит из двух параллельно проходящих фаз: фазы

применения ИС и фазы сопровождения ИС.

3.1. Внедрение ИС – комплексная отладка, адаптация под требования

конкретных пользователей, обучение персонала, поэтапное внедрение

ИС в эксплуатацию, разработка и обеспечение процедур повышения

надежности ИС. Завершается оформлением акта о приемо-сдаточных

испытаниях ИС. Часто совмещается с этапом аттестации, особенно, в

ИС, разрабатываемых под заказ без тиражирования.

3.2. Применение ИС – использование ПС для решения практических задач

на компьютере путем выполнения ее программ.

3.3. Сопровождение ИС − процесс сбора информации о качестве ИС в

эксплуатации, рекламаций, устранения обнаруженных в ней ошибок и

недоработок, ее доработка и модификация, а также извещения

пользователей о внесенных в нее изменениях

4. Стадия вывода ИС из эксплуатации.

Цель проектирования – положить начало изменениям в окружающей

человека искусственной среде» (Дж. К. Джонс). Процесс проектирования

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

детализацией и меньшей общностью (рис. 10.) Основными свойствами

процесса являются дивергенция, трансформация, конвергенция.

Рис. 10. Составляющие процессов жизненного цикла

Дивергенция – расширение границ ситуации с целью обеспечения более

обширного пространства поиска решения.

Трансформация – стадия создания принципов и концепций (исследование

структуры проблемы).

Конвергенция охватывает традиционное проектирование

(программирование, отладка, проработка деталей).

Значительное внимание проектированию будет уделено в следующих

разделах учебника.

Разновидности водопадного подхода

В [66] предлагаются следующие этапы проектирования ИС и их

детализация:

1. Исследование предметной области:

1.1. Спецификация деятельности в предметной области.

1.2. Анализ деятельности в предметной области;

1.2.1. структурно-логический анализ деятельности;

1.2.2. анализ путей;

1.2.3. анализ связности (прочности и сцепления) компонентов

предметной области.

1.2.4. анализ производительности.

1.3. Экономический анализ.

2. Разработка архитектуры системы

2.1. Спецификации требований к проектируемой системе.

2.2. Конструирование концептуальной модели предметной области.

2.3. Спецификации обработки данных в проектируемой системе.

2.4. Спецификации пользовательского интерфейса системы.

2.5. Спецификации деятельности в предметной области с учетом внедрения

системы.

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

представления проектных решений:

3.1. модели классификации объектов;

3.2. модели декомпозиции компонентов предметной области;

3.3. модели потоков;

3.4. модели данных предметной области;

3.5. модели классов;

3.6. модели пользовательского интерфейса;

3.7. модели логики.

Модель классификации ориентирована на группирование объектов

предметной области в соответствии с различными аспектами классификации и

важность тех или иных свойств этих объектов.

Модель декомпозиции ориентирована на описание систем, способных

выполнять действия над данными. Различают виды декомпозиции действий на

основе:

• состава выходных данных;

• входных данных;

• представлений о промежуточных результатах;

• представлений о фазах обработки;

• представлений об альтернативных действиях.

Модели потоков отражают движение различных видов носителей

(материальных, финансовых, информационных и др.).

Модель данных предметной области ориентирована на описание

структуры информационных объектов, их функциональных взаимосвязей,

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

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

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

характеристик модели классов можно выделить отношения наследования,

включения или использования. В основе лежит объектно-ориентированный

подход, в основе которого находится представление о предметной области, как

совокупности взаимодействующих друг с другом объектов, рассматриваемых

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

наследования. Объектно-ориентированный подход содержится в современных

языках высокого уровня Smalltalk, Object Pascal, C++, Java.

Модель пользовательского интерфейса ориентирована на описание

взаимодействий пользователей с проектируемой системой, состава форм

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

Модели логики ориентированы на описание потока управления

(последовательности выполнения) операторов программной системы и

действий пользователей.

Для отображения результатов проектирования на различных этапах

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

1. Схемы первичной классификации;

2. Схемы вторичной классификации;

3. Схемы детализации;

4. Схемы спецификации функциональных возможностей;

5. Схемы локальных моделей данных;

6. Схемы потоков;

7. Диаграммы переходов;

8. Схемы спецификации пользовательского интерфейса;

9. Схемы распределенной обработки данных;

10. Структурированные карты объектов.

Среди средств разработки информационных систем выделяют следующие

основные группы:

• традиционные систем программирования;

• инструменты для создания файл-серверных приложений;

• средства разработки приложений «клиент-сервер»;

• средства автоматизации делопроизводства и документооборота;

• средства разработки Интернет/Интранет-приложений;

• средства автоматизации проектирования (CASE-технологии).

Среди этой группы следует выделить инструментальные средства

быстрой разработки приложений RAD (Rapid Application Development),

обеспечивающие реализацию удаленного доступа к СУБД по двухзвенной

схеме «клиент—сервер»; связь клиентских приложений с серверами БД с

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

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

процедур на серверах БД; реализацию клиентских и серверных триггеров-

процедур; генерацию элементов диалогового интерфейса и отчетов.

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

подразделяются на следующие подгруппы:

• средства автоматизации учрежденческой деятельности Office Automation;

• системы управления электронным документооборотом EDMS;

• EDI – электронный документооборот и UN/EDIFACT – европейский

стандарт EDI в задачах логистики;

• средства обеспечения коллективной работы Groupware;

• средства автоматизации документооборота Workflow.

Данная группа средств включает в свой состав: текстовые редакторы для

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

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

запросов по образцу из различных БД; сетевые планировщики для назначения

рабочих встреч и совещаний; средства разработки и демонстрации

иллюстративных материалов для презентаций; словари и системы построчного

перевода и др. Эти средства представляют собой отдельные пакеты (MS Word,

Excel, Lotus), интегрированный пакет программ (MS Works) или согласованный

набор пакетов (Microsoft Office, Corel Perfect Office).

Средства программирования Internet/Intranet-приложений представлены

различными системами программирования на интерпретируемых языках Java,

Java Script, Tel и др. Построенные с использованием этих средств приложения

могут загружаться с любого Web-сервера сети и интерпретироваться на

клиентском узле. Это обеспечивает платформенную независимость при

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

Средства автоматизации проектирования приложений (CASE-тех-

нологии) предназначенные для анализа предметной области, проектирования и

генерации программных реализаций, подробно описаны в соответствующем

разделе. Новые тенденции в реализации приложений связаны с промышленным

характером разработки программного обеспечения. Среди существующих

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

• комплект специальных инструментальных средств быстрой разработки

прикладных ИС – RAD (Rapid Application Development);

• технологический комплекс разработки программного обеспечения RUP

(Rational Unified Process) фирмы Rational Software;

• технология разработки программного обеспечения Extreme Programming

(XP).

Средства RAD базируются на объектно-ориентированном подходе, когда

информационные объекты формируются как действующие модели и их

функционирование согласовывается с пользователем. Разработка приложений

на основе RAD ведется с использованием множества готовых объектов,

хранимых в виде базы данных. Объектно-ориентированные инструменты RAD

в среде GUI позволяют на основе набора стандартных объектов, для которых

инкапсулированы атрибуты и внутренние процедуры, формировать простые

приложения без написания кода программы. Использование в RAD визуального

программирования позволяет еще более упростить и ускорить процесс создания

информационных систем. Логика приложения, реализованного с помощью

RAD является событийно-ориентированной, что подразумевает наличие

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

клавиатуры, срабатывание системного таймера, получение и передача

управления каждым элементом экрана, некоторые элементы управления базой

данных.

Наиболее полным описанием процесса разработки программного

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

жизненного цикла системы, является метод Rational Unified Process (RUP),

рассматриваемый ниже в соответствующем разделе.

Модель фазы – функции

Важным мотивом развития моделей жизненного цикла программного

обеспечения является потребность в подходящем средстве для комплексного

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

модель должна служить основой организации взаимоотношений между

разработчиками, и, таким образом, одной из ее целей является поддержка

функций менеджера. Это приводит к необходимости наложения на модель

контрольных точек, задающих организационно-временные рамки проекта, и

организационно-технических, так называемых производственных функций,

которые выполняются при развитии проекта.

Наиболее последовательно такое дополнение классической схемы

реализовано в модели Гантера (фазы – функции), где выполнение функции на

одном этапе может продолжаться на следующем [58]. Перекрытие смежных фаз

позволяет, при наличии достаточных ресурсов, уменьшить общее время

создания проекта. На рис. 11 цветом выделена интенсивность выполнения

функции. В результате оценки возможен итеративный возврат к любой из

предыдущих фаз.

Фазы (этапы):

←Исследования

← Анализ осуществимости

← Конструирование

← Программирование

← Оценка

←

Использование

Функции:

Планирование

Разработка

Обслуживание

Выпуск

документации

Испытания

Поддержка

Сопровождение

Контрольные точки (события):

↓

Необходимость разработки

Ресу

рсы распределены

↑

Требования сформулированы

↑

Требования утверждены

↑

Спецификации составлены

↑

Спецификации утверждены

↑

Компоновка завершена

↑

Независимые испытания начались

↑

Начало использования изделия ↑

Изделие передано на

распространение

↑

Изделие снято с производства ↑

Рис. 11. Матрица фазы – функции модели Гантера

с указанием контрольных точек

Итерационный (спиральный) подход

В модели Гантера не был наглядно выделен аспект итеративного подхода,

связанный с постепенным наращиванием возможностей системы по мере

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

которой линия жизни и функциональное измерение оказывались

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

для разработки соответствующего CASE-средства.Покажем, как этот

недостаток можно исправить, причем почти без потери качества модели.