Автоматизация проектирования АИС

Проектировочные работы требуют значительного объема ресурсов различного характера — временных, финансовых, материальных и др. Необходимо стремиться к минимизации этих ресурсов за счет привлечения прогрессивных средств проектирования АИС.

Автоматизированные системы проектирования — эффективное средство улучшения показателей проектирования АИС. За последнее десятилетие в области проектирования сформировалось новое направление — так называемая программная инженерия или CASE-технологии (Computer-Aided Software/System Engineering — система компьтер- ной разработки программного обеспечения) [21]. CASE-технологии — это совокупность методов анализа, проектирования, разработки и сопровождения АИС, поддержанных комплексом взаимосвязанных средств автоматизации. CASE-технологии — это средство для системных аналитиков, разработчиков и программистов, обеспечивающее автоматизацию процессов проектирования АИС различного класса и назначения.

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

• улучшение качества создаваемых АИС за счет средств автоматизированного контроля программных средств и других проектных решений;

• создание прототипа будущей АИС за короткое время, возможность на ранних этапах провести оценку ожидаемого результата;

• ускорение процесса проектирования и разработки АИС;

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

• поддержка развития и сопровождение разработки АИС;

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

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

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

• расчленение сложной системы на части, представляемые как «черные ящики», каждый «черный ящик» реализует определенную функцию системы управления;

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

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

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

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

• SADT — технология структурного анализа и проектирования, и ее подмножество — стандарт IDEFO.

• DFD — диаграммы потоков данных.

• ERD — диаграммы «сущность — связь».

• STD — диаграммы переходов состояний.

В методологии IDEFO используются четыре основных понятия:

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

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

3) декомпозиция — разделение сложного объекта на составные части. Уровень детализации определяется непосредственно разработчиком модели. Таким образом, общая модель процесса представляется в виде иерархической структуры отдельных диаграмм, что делает ее более понятной;

4) глоссарий — это совокупность определений, ключевых слов, терминов, характеризующих объекты на диаграмме. Глоссарий обеспечивает включение в диаграммы IDEFO необходимой дополнительной информации. Например, для управляющей интерфейсной дуги «распоряжение об оплате» глоссарий может содержать перечень реквизитов соответствующего дуге документа, необходимый набор виз и т.д.

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

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

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

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

Методология ERD применяется для построения моделей БД, она обеспечивает стандартизованный способ описания данных и определение связей между ними. Основные элементы методологии — понятия «сущность», «отношение» и «связь». Сущность задают базовые типы информации, а отношения указывают, как эти типы данных взаимодействуют между собой. Связи объединяют сущности и отношения. ERD используется, в частности, для построения моделей данных в хранилищах DFD.

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

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

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

2) определение структуры класса, описывающей связь между классами и объектами;

3) разработка диаграмм объектов, которые показывают взаимосвязь объекта с другими объектами;

4) разработка архитектуры ПО, описывающей физический проект создаваемой системы.

Подавляющая часть существующих методов объектно-ориентированного анализа и проектирования включает в себя как язык моделирования, так и средства описания процессов моделирования. Язык моделирования — это нотация, которая представляется совокупностью правил построения графических объектов, применяемых в моделях. Процесс моделирования отображает шаги, которые следует выполнять при разработке проекта. UML версии 1.1 принят OMG (Object Management Group) — Организацией по стандартизации объектно-ориентированных методов и технологий в качестве стандарта в 1997 г. Этот язык используется практически всеми компаниями — разработчиками программных средств — IBM, Microsoft, Oracle Sybase и др.

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

• диаграммы вариантов использования — для моделирования требований к системе (бизнес-процессов организации);

• диаграммы классов — для моделирования статистической структуры классов и связей между ними;

• диаграммы поведения системы — для моделирования отображения функционального состояния системы;

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

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

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

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

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

Объектно-ориентированный подход не противопоставляется структурному, а может служить его дополнением. Например, для формализации модели бизнеса может использоваться методология IDEFO, а при построении модели системы управления — методология UML.

13.5.