Software & Systems

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

· неадекватности структуризации СОИ;

· несогласованности структурных частей СОИ;

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

Все перечисленные проблемы являются следствием сложности СОИ как объекта анализа и проектирования.

Одним из наиболее перспективных путей решения данных проблем является путь, связанный с автоматизацией процессов создания СОИ. В настоящее время в нашей стране и за рубежом интенсивно ведутся исследования, посвященные вопросам создания соответствующих инструментальных средств. В программотехнике данное научное направление получило название CASE (Computer Aided System/Software Engineering) -технологий, которые, как показывает зарубежный опыт [1], позволяют значительно повысить производительность труда проектировщиков (до 600%), уменьшить сложность проектов, улучшить их качество, сократить сроки формирования облика СОИ. До последнего времени в отечественной литературе отсутствовали систематически собранные сведения о состоянии исследований по данной проблематике. Исключение составляет лишь монография [3], которая вышла в свет в период написания данного материала.

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

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

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

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

В программотехнике принято выделять шесть периодов, качественно отличающихся применяемой техникой и методами разработки СОИ и использующих в качестве инструментальных следующие средства [4]:

à ассемблеры, дампы, анализаторы;

à компиляторы, интерпретаторы, трассировщики;

à символические отладчики, пакеты программ;

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

à CASE-средства анализа требований, проектирования спецификаций и структуры, редактирования интерфейсов (первая генерация CASE-I);

à CASE-средства генерации исходных текстов и реализации интегрированного окружения поддержки полного ЖЦ разработки СОИ (вторая генерация СASE-II).

Всесторонний анализ, проведенный в работах [1-6], показал, что в современных CASE-пакетах используются практически все известные методологии проектирования (свыше 90 методов). Однако наибольшее распространение получили методологии:

*       SADT (Structured Analysis and Design Technigue);

*       структурного системного анализа Гейна-Сарсона (Gane-Sarson);

*       структурного анализа и проектирования Иодана/Де Марко (Yourdon/De Marco);

*       развития системы Джексона (Jackson);

*       развития структурных систем Варнье-Орра (WarnieOrr);

*       анализа и проектирования систем реального времени Уорда-Меллора (Word Mellor) и Хатли (Yatley);

*       информационного моделирования Мартина (Martin);

*       объектно-ориентированный подход Буча Г.

Основным недостатком перечисленных выше методологий является то, что их рекомендации, с одной стороны, достаточно жестко регламентируют фазы анализа требований и пректирования спецификаций, а с другой – имеют частный узкий характер (в работе [3] данные рекомендации названы “кулинарными рецептами”).

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

Проведенный анализ показывает, что несмотря на достаточно широкий спектр используемых методов и методик большинство методологий базируется на следующих основных [1-4,8,9]:

¨ диаграммы потоков данных в нотации Иодана/Де Марко или Гейна Сорсона, обеспечивающие анализ требований и функциональное проектирование информационных систем;

¨ расширения Хатли и Уорда-Меллора для проектирования систем реального времени, основанные на диаграммах переходов состояний, таблицах и деревьях решений, картах и схемах потоков управления;

¨ диаграммы “сущность-связь” (в нотации Чена или Баркера) или скобочных диаграммах Варнье-Орра для проектирования структурных данных, схем БД, форматов файлов как части всего проекта;

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

Рассмотрим более подробно, как на ранних этапах ЖЦ СОИ могут использоваться перечисленные методологии анализа и проектирования.

Первой фазой разработки СОИ является фаза анализа требований пользователей, их уточнения, формализации и документирования. Фактически на этом этапе дается ответ на вопрос “Что должна делать будущая система?”. Целью анализа является преобразование общих, неясных знаний о требованиях к СОИ в точные (по возможности) определения. На этом этапе определяются [3]:

*       архитектура системы, ее функции, внешние условия, распределение функций между аппаратурой и ПО СОИ;

*       интерфейсы и распределение функций между человеком и системой;

*       требования к программным и информационным компонентам ПО, необходимые аппаратные ресурсы, требования к БД, физические характеристики компонентов ПО, их интерфейсы.

Широкое распространение при решении основных задач на данной фазе получила методология структурного анализа, которая является составной частью современного обобщенного системного анализа (СА) [1].

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

На практике при проведении структурного анализа чаще всего используют следующие диаграммы [6,9]:

*       диаграммы потоков данных DFD (Data Flow Diagrams); совместно со словарями данных и спецификациями процессов или мини-спецификациями;

*       диаграммы “сущность-связь” ERD (Eutity-Relation ship Diagrams);

*       диаграммы переходов состояний STD (State Transition Diagrams).

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

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

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

Структуры потоков данных и определения их компонентов хранятся и анализируются в словаре данных [1,3].

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

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

Диаграммы DFD строятся при помощи небольшого набора логических абстракций (нотаций):

* внешних сущностей (квадратов), моделирующих источники и приемники информации;

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

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

* информационных потоков (стрелок), связывающих внешние сущности, процессы и накопители.

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

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

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

Завершается процесс построения DFD диаграмм заданием внутренней логики процессов, которая осуществляется при помощи мини-спецификаций, содержащих номер или имя, списки входных и выходных данных и тело (описание) процесса, являющееся спецификацией алгоритма или операции, трансформирующей входные потоки данных в выходные. К настоящему времени разработано большое количество методов спецификации процессов и соответствующих языков, среди которых в первую очередь можно выделить [6]: структурированный естественный язык; деревья и таблицы решений; визуальные языки проектирования спецификации; диаграммы Насси-Шнейдермана; блок-схемы; Р-схемы; псевдокод.

В работе [9] приводятся конкретные рекомендации по выбору варианта мини-спецификации с учетом положительных и отрицательных сторон каждого из перечисленных методов.

Для моделирования баз данных на этапе анализа СОИ применяется, как уже указывалось ранее, подход, использующий диаграммы “сущность-связь” (диаграмма FRD). При построении указанных диаграмм предметная область задается в виде сущностей, имеющих атрибуты, и отношений между ними, которые так же могут иметь атрибуты, сущность в этом случае представляет собой конкретный или абстрактный объект рассматриваемой предметной области, включая ассоциации объектов [3]. Относительно сущностей высказываются некие утверждения, которые в подходе отношений сущностей записываются при помощи отношений и атрибутов. Принято различать независимые, зависимые и ассоциированные сущности [1,5].

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

Для идентификации требований, в соответствии с которыми сущности вовлекаются в отношения, используют связи. Каждая связь соединяет сущность и отношение и может быть направлена только от отношения к сущности. Значение связи характеризует тип и, как правило, выбирается из следующего множества: {“0 или 1”, “0 или более”, “1 или более”, “p:q” (диапазоны)}.

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

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

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

За фазой анализа СОИ наступает фаза проектирования СОИ, на которой вырабатывается реализация требований пользователей, порожденных и зафиксированных на фазе анализа. На этом этапе осуществляется построение модели реализации (или физической модели), демонстрирующей, как система будет удовлетворять предъявленным к ней требованиям (без технических подробностей). Другими словами, на этапе проектирования ищется ответ на вопрос “Как (каким образом) система будет удовлетворять предъявленным требованиям?”.

Модель реализации является дальнейшим расширением модели требований и состоит из взаимосвязанных диаграмм (DFD, STD, ERD, структурные карты), текстов и словаря данных. При этом структурные карты на фазе проектирования позволяют продемонстрировать, каким образом системные требования будут отражаться комбинацией программных структур [1, 3, 6].

На фазе проектирования наибольшее распространение получили следующие методы [1, 3, 9]: структурное проектирование архитектуры ПО; объектно-ориентированное проектирование ПО; проектирование баз данных и пользовательских интерфейсов.

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

Объектно-ориентирование проектирование ориентировано на реализацию в среде, поддерживающую объектно-ориентированные языки программирования.

В основе данного вида проектирования лежит моделирование взаимодействующих объектов. Система рассматривается как совокупность объектов, посылающих друг другу сообщения. Элементарное действие системы – это отклик объекта на некоторое посланное ему сообщение. В результате объектно-ориентированного проектирования получают набор взаимосвязанных диаграмм [12]:

¨ классов;

¨ объектов;

¨ модулей;

¨ процессов;

 В целом по результатам проектирования получают набор схем следующих типов [1, 6]:

*       схемы баз данных;

*       схемы доступа к базам данных;

*       макеты (прототипы) пользовательского интерфейса;

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

*       спецификации интерфейсов частей СОИ;

*       спецификации программных модулей.

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

Список литературы

1.   Козлинский А.В. CASE-технология: индустриальная разработка систем обработки информации // Компьютерное обозрение. - 1993. - №1.
2.   Калянов Г.Н. Системное проектирование – новый вид деятельности на российском рынке // Информационные технологии. - 1995. - № № 3-4.
3.   Калянов Г.Н. CASE структурный системный анализ (автоматизация и применение). - М.: Лори, 1996.
4.   Калянов Г.Н. CASE-технологии проектирования программного обеспечения // Кибернетика и системный анализ. - 1993. - № 5.
5.   Калянов Г.Н. Современные CASE-технологии. - М.: ИПУ. - 1992. - (Препр.)
6.   Морозова А.В. Отечественные CASE-средства разработки проектов информационных систем // Монитор. - 1993. - № 7.
7.   Материалы сем.: CASE-технология. - М.: ЦРДЗ, 1992, 1993, 1994.
8.   Боэм Б.У. Инженерное проектирование программного обеспечения. - М.: Радио и связь, 1985.
9.   Ломако Е.И., Гуков Л.И., Морозова А.В. и др. Макетирование, проектирование и реализация диалоговых информационных систем. - М.: Финансы и статистика, 1993.