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

ЛЕКЦИЯ 11

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

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

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

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

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

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

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

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

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

Основная особенность систем реального времени заключается в том, что они контролируют и контролируются внешними события­ми; реагирование на эти события во времени — главная и первооче­редная функция таких систем. Принципиальные отличия информа­ционных систем от систем реального времени приведены в табл. 2;

Таблица 2

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

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

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

Как уже отмечалось, наиболее существенное различие между разновидностями структурного анализа заключается в методах и сред­ствах функционального моделирования. С этой точки зрения все раз­новидности структурного системного анализа могут быть разбиты на две группы: применяющие методы и технологию 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

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

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

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

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

1) Адекватность. Выбор той или иной структурной методологии напрямую зависит от предметной области, для которой создается модель. В нашем случае методологии применяются к автоматизиро­ванным системам управления предприятием, а не к системам вооб­ще, как это предполагается в 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) объеди-

Таблица 5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дата добавления: 2017-01-14