ЖИЗНЕННЫЙ ЦИКЛ СИСТЕМЫ

Модели ЖЦ и его основные этапы

При описании жизненного цикла системы используются следующие понятия:

-        процесс - цепочка последовательно выполняемых работ;

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

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

Традиционно выделяются следующие основные этапы ЖЦ АСУП:

-        анализ требований;

-        проектирование;

-        программирование/внедрение;

-        тестирование и отладка;

-        эксплуатация и сопровождение.

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

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

1.        Каскадная модель (в 70 - 80-е годы) - предполагает переход на следующий этап после полного окончания работ по предыдущему этапу и характеризуется четким разделением данных и процессов их  разработки

2.        Поэтапная модель с промежуточным контролем (в 80-85-е годы) - итерационная модель разработки с циклами обратной связи между этапами. Преимущество такой модели заключается в том, что межэтапные корректировки обеспечивают меньшую трудоемкость по сравнению с каскадной моделью; с другой стороны, время жизни каждого из этапов растягивается на весь период разработки.

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

Специалистами отмечаются следующие преимущества спиральной модели:

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

-        ориентация на развитие и модификацию системы в процессе ее проектирования;

-        анализ риска и издержек в процессе проектирования.

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

Анализ требований

Анализ требований является первой фазой разработки АСУП, на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос «Что должна делать будущая система?». Именно здесь лежит ключ к успеху всего проекта. В практике создания больших систем известно немало примеров неудачной реализации проекта именно из-за неполноты и нечеткости определения системных требований.I

Список требований к АСУП должен включать:

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

-        описание выполняемых системой функций;

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

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

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

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

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

Модель требований должна включать:

-        полную функциональную модель требований к будущей системе с глубиной проработки до уровня каждой операции каждого должностного лица;

-        спецификации операций нижнего уровня;

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

-        концептуальную информационную модель требований;

-        пакет отчетов и документов по информационной модели;

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

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

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

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

-          описать, «увидеть» и скорректировать будущую систему до того, как она будет реализована физически;

-          уменьшить затраты на разработку и внедрение системы;

-          оценить разработку по времени и результатам;

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

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

2.        Модель требований полностью независима и отделяема от конкретных разработчиков, не требует сопровождения ее создателями и может быть безболезненно передана другим лицам. Более того, если по каким-либо причинам предприятие не готово к реализации системы на основе модели требований, она может быть положена «на полку» до тех пор, пока в ней не возникнет необходимость.

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

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

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

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

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

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

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

-        традиционная (текстовая) спецификация системы из-за объема технических терминов часто непонятна заказчику;

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

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

Структурные методы анализа

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

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

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

-        использование строгих формальных правил записи;

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

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

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

-        Облегчается тестирование таких систем. Если появляется плохой звук одной из колонок, можно поменять колонки местами. Если неисправность переместилась с колонкой, то именно она подлежит ремонту; если нет, тогда проблема в усилителе, магнитофоне или местах их соединения.

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

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

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

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

-        каждый черный ящик должен реализовывать единственную функцию системы;

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

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

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

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

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

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

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

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

-        отношения между данными,

-        зависящее от времени поведение системы (аспекты реального времени).

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

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

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

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

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

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

рис. 20.

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

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

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

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

В настоящее время успешно используются практически все известные методологии структурного анализа, однако наибольшее распространение получили методологии SADT (Structured Analysis and Design Technique), структурного системного анализа Гейна-Сарсона (Gane-Sarson), структурного анализа и проектирования Йодана-Де Марко (Yourdon-DeMarko), развития систем Джексона (Jackson), развития структурных систем Варнье-Oppa (Warmer-Orr), анализа и проектирования систем реального времени Уорда-Меллора (Ward-Mellor) и Хатли (Hatley), информационного моделирования Мартина (Martin).

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

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

-        по отношению к школам - Software Engineering (SE) и Information Engineering (IE);

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

-        по типу целевых систем - для систем реального времени (СРВ) и информационных систем (ИС).

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

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

Основная особенность систем реального времени заключается в том, что они контролируют и контролируются внешними событиями; реагирование на эти события во времени - главная и первоочередная функция таких систем. Принципиальные отличия информационных систем от систем реального времени приведены в табл. 2; средствами поддержки этих особенностей и различаются соответствующие структурные методологии. Необходимо отметить, что для целей анализа требований к системам реального времени используются специальные типы структурных диаграмм: диаграммы потоков управления, диаграммы переходов состояний, матрицы состояний/событий, таблицы решений и др. Однако многие из них являются вариациями структурных диаграмм для анализа требований к информационным системам. Более того, известные методологии анализа и проектирования СРВ (в частности, методологии Хатли и Уорда-Меллора) базируются на перечисленных методологиях анализа и проектирования ИС, расширяя их соответствующими диаграммными техниками.

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

Таблица 2

Информационные системы	Системы реального времени
Управляемы данными	Управляемы событиями
Сложные структуры данных	Простые структуры данных
Большой объем входных данных	Малое количество входных данных
Интенсивный ввод/вывод	Интенсивные вычисления
Машинная независимость	Машинная зависимость

Как уже отмечалось, наиболее существенное различие между разновидностями структурного анализа заключается в методах и средствах функционального моделирования. С этой точки зрения все разновидности структурного системного анализа могут быть разбиты на две группы: применяющие методы и технологию DFD (в различных нотациях) и использующие SADT-методологию. По материалам наиболее авторитетной в рассматриваемой области исследовательской компании CASE Consulting Group соотношение применения этих двух разновидностей структурного анализа на практике Доставляет 90% для DFD и 10% для SADT.

Таблица 3

Методологии	Частота использования	Школа	Порядок построения	Тип целевых систем
Йодан- Де Марко	36,5%	SE	процедурно-ориентированная	ИС, СРВ
Гейн- Сарсон	20,2%	SE	процедурно-ориентированная	ИС, СРВ
Константайн	10,6%	SE	процедурно-ориентированная	ИС, СРВ
Джексон	7,7%	SE	информационно-ориентированная	ИС, СРВ
Варнье- Орр	5,8%	SE	информационно-ориентированная	ИС
Мартин	22,1%	IE	информационно-ориентированная	ИС
SADT	3,3%	IE	процедурно-ориентированная	ИС

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

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

-        адекватность средств рассматриваемой проблеме;

-        согласованность с другими средствами структурного анализа;

-        интеграция с последующими этапами разработки (и прежде всего с этапом проектирования).

рис. 21.

I) Адекватность. Выбор той или иной структурной методологии напрямую зависит от предметной области, для которой создается модель. В нашем случае методологии применяются к автоматизированным системам управления предприятием, а не к системам вообще, как это предполагается в SADT. Для рассматриваемых задач DFD вне конкуренции.

Во-первых, SADT-диаграммы значительно менее выразительны и удобны для моделирования АСУП (сравните рис. 21 и рис. 22). Так, дуги в SADT жестко типизированы (вход, выход, управление, механизм). В то же время применительно к АСУП стирается смысловое различие между входами и выходами, с одной стороны, и управлениями и механизмами, с другой: входы, выходы, механизмы и управления являются потоками данных и/или управления и правилами их трансформации. Анализ системы при помощи потоков данных и процессов, их преобразующих, является более прозрачным и недвусмысленным.

рис. 22.

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

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

2) Согласованность. Главным достоинством любых моделей является возможность их интеграции с моделями других типов. В данном случае речь идет о согласованности функциональных моделей со средствами информационного и событийного (временного) моделирования. Согласование SADT-модели с ERD и/или STD практически невозможно или носит тривиальны и характер. В свою очередь, DFD, ERD и STD взаимно дополняют друг друга и по сути являются согласованными представлениями различных аспектов одной и той же модели (см. рис. 20 ). В табл. 4 отражена возможность такой интеграции для DFD- и SADT-моделей.

Таблица 4

Название	ERD	STD	Структурные карты
DFD	+	+	+
SADT	+	-	-

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

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

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

Объектно-ориентированные методы анализа

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

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

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

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

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

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

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

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

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

-        динамической модели, отражающей временные аспекты и последовательность операций (при этом достаточно часто используется STD);

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

В табл. 5 приведены оценки объемов продаж объектно-ориентированных методологий поданным International Data Corp. на 1995 г.

Главными недостатками перечисленных объектно-ориентированных методологий являются следующие:

-        отсутствие стандартизации в рассматриваемой области программотехники (конкретно, для представления объектов и взаимосвязей между ними);

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

Для преодоления этих недостатков авторы известных методологий Буч (Booch), Рамбо (Rumbaugh) и Якобсон (Jacobson) объединились с целью выработки унифицированной методологии, получившей название UML (Unified Modeling Language). При создании UML его авторы руководствовались целями ускорения эволюции наиболее популярных методологий в направлении сближения их друг с другом, обобщения накопленного опыта их использования, обеспечения стабильности проектов на основе единого целостного метода.

Таблица 5

Название методологии	Объем продаж, %
Rumbaugh (OMT)	40
Shlaer- Mellor	16
Booch	11
Martin-Odell	11
другие	22

В UML используются следующие ключевые диаграммы:

-        диаграмма классов, демонстрирующая статическую структуру системы, ее содержимое - классы, объекты и отношения между ними;

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

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

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

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

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

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

Разработка технического задания

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

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

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

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

-        разработку топологии, состава и структуры локальной вычислительной сети;

-        требования к этапам и срокам выполнения работ.

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

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

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

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

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

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

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

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

Проектирование

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

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

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

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

Структурное проектирование

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

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

2.    Модуль имеет имя, по которому к нему можно ссылаться как к единому фрагменту.

3.    Модуль может принимать и/или передавать данные как параметры в вызывающей последовательности или связывать данные через фиксированные ячейки или общие области.

При структурном проектировании выполняется два вида работ:

• проектирование архитектуры АСУП, включающее разработку структуры и интерфейсов ее компонент (автоматизированных рабочих мест), согласование функций и технических требований к компонентам, определение информационных потоков между основными компонентами, связей между ними и внешними объектами;

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

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

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

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

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

Структурные карты Константайна являются моделью отношений иерархии между программными модулями. Узлы структурных карт соответствуют модулям и областям данных, потоки изображают межмодульные вызовы (в том числе циклические, условные и параллельные). Межмодульные связи по данным и управлению также моделируются специальными узлами, привязанными к потокам, стрелками указываются направления потоков и связей. Фундаментальные элементы структурных карт Константайна стандартизованы IBM, ISO и ANSI.

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

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

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

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

-        уменьшается количество соединений между двумя модулями, что приводит к уменьшению вероятности появления «волнового эффекта» (ошибка в одном модуле влияет на работу других модулей);

-        минимизируется риск появления «эффекта ряби» (внесение изменений, например, при исправлении ошибки, приводит к появлению новых ошибок), так как изменение влияет на минимальное количество модулей;

-        при сопровождении модуля отпадает необходимость беспокоиться о внутренних деталях других модулей;

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

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

Два модуля А и В нормально сцеплены, если: А вызывает В; В возвращает управление А; вся информация, передаваемая между А и В, представляется значениями параметров при вызове.

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

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

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

Два модуля сцеплены по управлению, если один посылает другому информационный объект - флаг, предназначенный для управления его внутренней логикой. Существует два типа флагов - описательный и управляющий. Описательный флаг обычно описывает ситуацию, которая произошла, и именуется с использованием существительных и прилагательных: Конец файла, Введенная кредитная карта. Управляющий флаг используется для декларирования определенных действий в вызываемом модуле и именуется с использованием глаголов: Читать следующую запись, Установить в начало. В общем случае управляющие флаги усиливают сцепление и, следовательно, ухудшают качество проекта.

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

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

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

В табл. 6 приведены сравнительные характеристики по каждому типу сцепления.

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

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

Таблица 6

Тип сцепления	Устойчивость к волновому эффекту	Модифицируемость	Понятность	Используемость в других системах
По данным	*	хорошая	хорошая	хорошая
По образцу	*	средняя	средняя	средняя
По управлению	средняя	плохая	плохая	плохая
По общей области	плохая	средняя	плохая	плохая
По содержимому	плохая	плохая	плохая	плохая

* - зависит от количества параметров интерфейса.

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

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

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

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

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

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

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

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

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

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

В табл. 7 приведены сравнительные характеристики для каждого уровня связанности.

Таблица 7

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

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

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

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

Рассмотрим основные принципы, позволяющие получать качественные системы.

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

-        уменьшения размеров модуля;

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

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

-        отделения собственно вычислений от управления (вызовы и принятия решения);

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

-        упрощения реализации.

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

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

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

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

-        легче избежать дублирования сообщений;

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

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

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

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

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

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

-        включает в себя условия о месте и способе его использования.

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

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

-        имеет дело со слишком избыточными типами данных, их значениями и структурами. Например, использование числа типа REAL вместо INTEGER для того, чтобы следить за количеством болтов на складе, было бы чрезмерным обобщением;

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

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

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

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

Объектно-ориентированное проектирование

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

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

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

-        наследуемые от этапа анализа требований и развиваемые на этапе проектирования диаграммы классов и диаграммы объектов, являющиеся основой статической логической модели;

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

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

Реализация (программирование/адаптация)

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

Тестирование и отладка

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

Установление корректности является главной целью рассматриваемого этапа жизненного цикла. Следует отметить, что этап тестирования и отладки - один из наиболее трудоемких, утомительных и непредсказуемых этапов разработки АСУП. В среднем при разработке традиционными методами этот этап занимает от 1/3 до 1/2 полного времени разработки. С другой стороны, тестирование и отладка представляют собой серьезную проблему: в некоторых случаях тестирование и отладка программы требуют в несколько раз больше времени, чем непосредственно программирование.

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

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

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

-        формулировку целей тестирования;

-        критерии качества тестирования, позволяющие оценить его результаты;

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

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

Для целей тестирования программные элементы АСУП удобно представлять в виде ориентированного графа

G = (N, Е),

где N = (N₁, N₂, ..., N_m) - множество узлов (вершин), соответствующих выполняемым операторам тестируемой программы;

E = (E₁, E₂, ..., E_n) - множество ребер (дуг), соответствующих передачам управления между операторами.

Путем (маршрутом) называется последовательность вершин и дуг

P=(N₁, E_1,2, N2, E_2,3, …, E_k-1,k, N_k),

где каждая дуга E_i,i+1 выходит изN_i и входит в N_i+1, причем N_i, не обязательно начальный узел. Ветвью называется путь Р, в котором N₁ - либо начальный узел, либо узел ветвления, N_k - либо узел ветвления, либо завершающий узел, все остальные N_i не являются узлами ветвления.

Очевидно, что полное тестирование всех возможных маршрутов не реально в связи с огромными затратами труда и времени. Поэтому на практике применяются критерии выбора тестов, не гарантирующие полной проверки программы. Общим требованием к этим критериям является достижение лишь определенной степени полноты АСУП или ее компонент. Как правило, эти критерии устанавливают требование по крайней мере однократной проверки всех операторов программы, всех ветвей программы, либо всех подпутей специального вида (например, всех подпутей, проверяющих циклы при начальном, завершающем и одном из промежуточных значений переменной - счетчика цикла). Самым распространенным критерием тестирования является критерий, требующий по крайней мере однократной проверки каждой из ветвей программ (критерий С₁). Так, например, тестирование при приемке программного обеспечения для ВВС США производится на основании этого критерия. По ряду независимых оценок использование критерия С₁, обеспечивает обнаружение от 67 до 90% ошибок.

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

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

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

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

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

Автоматизация тестирования и отладки

Система автоматизации тестирования и отладки (САТО) представляет собой сложный комплекс алгоритмических и программных средств, предназначенных для автоматизации анализа АСУП, тестирования, отладки и оценки ее качества, и позволяет облегчить модификацию компонент АСУП, обеспечить выявление ошибок на ранних стадиях отладки, повысить процент автоматически обнаруживаемых ошибок. На рис. 23 показано, как использование САТО влияет на цену обнаружения ошибок в течение жизненного цикла АСУП. АСУП становится «работоспособной», когда цена обнаруженной ошибки меньше некоторого значения μ, которое отражает уровень терпимости пользователя к программным ошибкам. Число имеющихся ошибок (область под кривой) одно и то же в обоих случаях. Отметим, что число обнаруженных ошибок после того, как АСУП становится работоспособной, почти постоянно по следующим причинам:

1.    влияние эффекта «ряби» - исправление ошибки служит источником внесения новых ошибок (практика показывает, что такие ошибки составляют 19% всех обнаруженных ошибок);

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

рис. 23.

САТО значительно сокращает количество ошибок, возникающих по вышеперечисленным причинам за счет предсказания влияния модификации, которые будут содержать эффект «ряби» а также за счет генерации и оценки тестов для тщательного и систематического тестирования АСУП.

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

Средства автоматизации, включаемые в САТО, в зависимости от решаемых ими задач разбиваются на средства автоматизации тестирования и средства автоматизации отладки.

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

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

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

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

4.    средства автоматизированного контроля тестирования, позволяющие оценить, насколько полная и тщательная проверка АСУП была осуществлена, например на основе информации о непроверенных операторах/функциях, непроверенных маршрутах и т. п.;

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

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

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

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

1.    средства анализа потоков управления, осуществляющие контроль структуры АСУП в целом, а также отдельных ее конструкций на основе графовой модели. Средства данного типа позволяют автоматически обнаружить следующие изъяны: невыполняемые операторы/функции, тупиковые ветви, некоторые виды бесконечных циклов и др.;

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

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

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

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

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

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

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

Средства частичной автоматизации позволяют пользователю автоматически получать необходимую ему информацию для дальнейшей локализации ошибок вручную. Среди таких средств наиболее распространены DDT (Dinamic Debugging Tools) - «системы для уничтожения блох» (слово «bug» в английском языке означает не только «ошибка», но и »блоха», а ДДТ - популярное в недавнее время средство борьбы с насекомыми). Управление системой DDT и, соответственно, управление отладкой осуществляются посредством языка отладки командного типа, его операторы имеют форму приказов (команд), состоящих из ключевого слова и списка операндов, если последние необходимы. Операторы языка отладки обеспечивают взаимодействие программиста с DDT и инициируют выполнение соответствующих отладочных функций, согласно которым они могут быть разбиты на следующие группы:

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

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

3.   контролирующие операторы, осуществляющие контроль знамени-' переменных, маршрутов и т. п. на предмет сравнения с заранее заданными;

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

5.   служебные операторы, обеспечивающие загрузку отлаживаемых программных и информационных компонент АСУП, переключение режимов (пакет, диалог), ввод в протокол сеанса отладки комментариев и т. д.

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

Эксплуатация и сопровождение

Основные задачи этапа эксплуатации и сопровождения:

-        обеспечение устойчивости работы системы и сохранности информации - администрирование;

-        своевременная модернизация и ремонт отдельных элементов - техническая поддержка;

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

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

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

CASE-технологии – инструментарий поддержки ЖЦ

Практически ни один серьезный проект по созданию АСУП не осуществляется без использования CASE-средств. CASE (Computer-Aided Software/System Engineering) представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных программных систем, поддержанную комплексом взаимоувязанных средств автоматизации. CASE - это инструментарий для системных аналитиков, разработчиков и программистов, заменяющий им бумагу и карандаш компьютером для автоматизации процесса проектирования и разработки ПО. При применении этого инструментария отмечается значительный рост производительности труда, составляющий (по оценкам фирм, использующих CASE) от 100 до 600% в зависимости от объема и сложности работ и опыта использования CASE. Общее число распространяемых пакетов превышает 500 наименований. Объем рынка CASE-средств превышает 10 млрд. долл. в год, число инсталляций наиболее популярных пакетов составляет десятки тысяч.

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

Следует отметить, что CASE - не революция в программотехнике, а результат естественного эволюционного развития всей отрасли средств, называемых ранее инструментальными или технологическими. Однако это и не Confuse Array of Software that does Everything, существует ряд признаков и свойств, наличие которых позволяет классифицировать некоторый продукт как CASE-средство. Одним из ключевых признаков является поддержка структурных и/или объектно-ориентированны методологий. С самого начала CASE-средства развивались с целью преодоления ограничений при использовании структурных (а в настоящее время и объектно-ориентированных) методологий (сложности понимания, большой трудоемкости и стоимости использования, трудности внесения изменений в проектные спецификации и т. д.) за счет их автоматизации и интеграции поддерживающих средств.

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

-        улучшают качество создаваемой системы за счет средств автоматического контроля (прежде всего контроля проекта);

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

-        ускоряют процесс проектирования и разработки;

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

-        поддерживают развитие и сопровождение разработки;

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

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

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

В табл. 8 приведены оценки трудозатрат по фазам ЖЦ. В табл. 9 сведены основные изменения в ЖЦ при использовании CASE по сравнению с традиционной разработкой.

Таблица 8

Способ разработки	Анализ, %	Проектирование,  %	Кодирование, %	Тестирование,  %
Традиционная разработка	20	15	20	45
Использование структурных методологий	30	30	15	25
Использование CASE-технологий	40	40	5	15

Таблица 9

Традиционная разработка	CASE
Основные усилия - на кодирование и тестирование	Основные усилия - на анализ и проектирование
«Бумажные» спецификации	Быстрое итеративное прототипирование
Ручное кодирование	Автоматическая кодогенерация
Ручное документирование	Автоматическая генерация документации
Тестирование кодов	Автоматический контроль проекта
Сопровождение кодов	Сопровождение спецификаций проектирования

На рис. 24 представлены преимущества разработки с применением CASE-технологий

Ниже кратко характеризуются основные функциональные возможности CASE-средств.

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

рис. 24.

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

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

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

5.   Прототипирование. Важную роль при автоматизации ранних этапов ЖЦ играют возможности поддержки прототипирования. CASE позволяет строить быстрые прототипы системы, что позволяет на ранних этапах разработки оценить, насколько будущая система устраивает заказчика и насколько дружественна она будущему пользователю. Соответствующие средства используются для определения системных требований и ответа на вопросы об ожидаемом поведении системы. Такие средства, как генераторы меню, экранов и отчетов, позволяют быстро построить прототипы пользовательских интерфейсов и снабдить моделью функционирования системы с позиций конечного пользователя. Использование языков четвертого поколения позволяет строить более сложные модели, при этом прототип позволяет промоделировать основные функции системы, но не способен контролировать ее ожидаемое поведение. Исполняемые языки спецификаций преобразуют процесс разработки в следующий итеративный процесс: спецификации определяются и выполняются, затем производится переопределение или корректировка. Созданные таким образом прототипы позволяют определять, является ли проектируемая система полной и корректной.

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

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

-          ошибки проектирования и ошибки кодирования составляют соответственно 64 и 32% общего числа ошибок;

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

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

-          контроль синтаксиса диаграмм и типов их элементов;

-          контроль полноты и состоятельности диаграмм;

-          контроль декомпозиции функций;

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

8.      Автоматическая кодогенерация. Кодогенерация осуществляется на основе репозитария и позволяет автоматически построить до 80-90% объектных кодов или текстов программ на языках высокого уровня. При этом различными CASE-пакетами поддерживаются практически все известные языки программирования, однако наиболее часто в качестве целевых языков выступают COBOL, С и ADA. Средства кодогенерации по отношению к полноте целевого продукта разделяются на средства генерации каркаса и средства генерации полного продукта. В первом случае автоматически строится откомментированная логика (потоки управления) программной системы, а также коды для баз данных, файлов, экранов, отчетов и т. п., остальные фрагменты кодируются вручную. Во втором случае из проектных спецификаций генерируется полная документированная программа, включая выполняемый код, пользовательскую и программную документацию, наборы тестов и т. д. Все эти компоненты полной программы связываются в единый объект, хранящийся в репозитарии для облегчения доступа и сопровождения.

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

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