13.4. Автоматизация проектирования АИС
Автоматизированные системы проектирования — эффективное средство улучшения показателей проектирования АИС. За последнее десятилетие в области проектирования сформировалось новое направление — так называемая программная инженерия или CASE-техноло- гии (Computer-Aided Software/System Engineering — система компьтер- ной разработки программного обеспечения) [21]. CASE-технологии — это совокупность методов анализа, проектирования, разработки и сопровождения АИС, поддержанных комплексом взаимосвязанных средств автоматизации. САБЕ-технологии — это средство для системных аналитиков, разработчиков и программистов, обеспечивающее автоматизацию процессов проектирования АИС различного класса и назначения.
Основная цель САБЕ-технологии — максимально автоматизировать процесс разработки и отделить процесс проектирования от кодирования программных средств АИС. В большей части современных САБЕ- технологий применяется методология структурного анализа, основанная на описании модели проектируемой системы в виде графов, диаграмм, таблиц и схем. К числу несомненных достоинств САБЕ-технологии следует отнести следующие:
• улучшение качества создаваемых АИС за счет средств автоматизированного контроля программных средств и других проектных решений;
• создание прототипа будущей АИС за короткое время, возможность на ранних этапах провести оценку ожидаемого результата;
• ускорение процесса проектирования и разработки АИС;
• освобождение разработчика от рутинной работы в пользу творческой работы по проектированию;
• поддержка развития и сопровождение разработки АИС;
• поддержка технологии повторного использования компонентов проекта.
Автоматизация проектирования основана на соответствующих методах. В зависимости от содержания и класса АИС выбирается наиболее адекватный метод проектирования. Эти методы основаны на формализованном отображении бизнес-процессов и систем управления предприятием (фирмой). В настоящее время имеются десятки методов построения формализованных моделей функционирования предприятия и концепций построения систем управления. Методы построения моделей предприятий можно разделить на структурные и объектно - ориентированные. Каждая из этих групп методов включает в себя несколько вариантов конкретных методик.
Структурные методы построения моделей предприятий. Структурным принято называть такой метод исследования системы или процесса, который начинается с общего обзора объекта исследования, а затем предполагает его последовательную детализацию. Структурные методы имеют три основные особенности:
• расчленение сложной системы на части, представляемые как «черные ящики», каждый «черный ящик» реализует определенную функцию системы управления;
• иерархическое упорядочение выделенных элементов системы с определением взаимосвязей между ними;
• использование графического представления взаимосвязей элементов системы.
Модель, построенная с применением структурных методов, представляет собой иерархический набор диаграмм, графически изображающих выполняемые системой функции и взаимосвязи между ними. Попросту говоря, это рисунки, на которых показан набор прямоугольников, определенным образом связанных между собой. В диаграммы также включается текстовая информация для обеспечения точного определения функций и взаимосвязей. Примером может служить блок-схема технологий и алгоритмов обработки данных (см. рис. 13.12, 13.13). Использование графического представления процессов существенно повышает наглядность модели и облегчает процесс ее восприятия. От обычных рисунков, с помощью которых можно представить процесс управления, структурные диаграммы отличаются тем, что выполняются по вполне определенным правилам, а процесс их составления и анализа может быть поддержан соответствующим ПО.
В составе методологий структурного анализа к наиболее распространенным можно отнести следующие:
• SADT — технология структурного анализа и проектирования, и ее подмножество — стандарт IDEFO.
• DFD — диаграммы потоков данных.
• ERD — диаграммы «сущность — связь».
• STD — диаграммы переходов состояний.
В методологии IDEFO используются четыре основных понятия:
1) функциональный блок — функция определенной системы, в графическом виде обозначаемая прямоугольником. Каждая из четырех сторон этого прямоугольника имеет свое значение: левая сторона — вход, верхняя сторона — управление, нижняя сторона — механизм, правая сторона — выход;
2) интерфейсная дуга — элемент системы, который обрабатывается функциональным блоком или отображает определенное влияние на выполнение блоком своей функции, изображается в виде направленной стрелки. По отношению к стороне блока интерфейсные дуги носят названия входящей, исходящей, управляющей дуги или дуги механизма. Началом и концом каждой дуги могут быть только функциональные блоки, при этом началом может быть только выходная сторона блока, а концом — любые другие. При построении моделей функционирования предприятия входящими и исходящими дугами могут обозначаться потоки информации (документы, устные распоряжения и др.), ресурсы (персонал, оборудование и др.). Управляющими дугами обозначаются только объекты, относящиеся к потокам информации, а дугами механизмов — только ресурсы;
3) декомпозиция — разделение сложного объекта на составные части. Уровень детализации определяется непосредственно разработчиком модели. Таким образом, общая модель процесса представляется в виде иерархической структуры отдельных диаграмм, что делает ее более понятной;
4) глоссарий — это совокупность определений, ключевых слов, терминов, характеризующих объекты на диаграмме. Глоссарий обеспечивает включение в диаграммы IDEFO необходимой дополнительной информации. Например, для управляющей интерфейсной дуги «распоряжение об оплате» глоссарий может содержать перечень реквизитов соответствующего дуге документа, необходимый набор виз и т.д.
Модель IDEFO всегда начинается с представления процесса как единого функционального блока с интерфейсными дугами, выходящими за пределы рассматриваемой области.
Иногда такие диаграммы снабжаются так называемой контекстной справкой.Цель выделяет те направления деятельности предприятия, которые следует рассматривать прежде всего. Так, например, модель, построенная с целью рационализации маркетинга, может существенно отличаться от модели, разработанной с целью повышения эффективности управления АИС предприятия.
Цель устанавливает направление и уровень декомпозиции разрабатываемой модели. Однозначность цели позволяет упростить модель, исключив детализацию элементов, в данном случае не главных. Например, функциональные модели одного и того же предприятия с точки зрения главного инженера и руководителя службы маркетинга будут явно отличаться по направленности и детализации.
В методологии DFD исследуемый процесс разбивается на подпроцессы и представляется в виде сети, связанной потоками данных. Внешне DFD похожа на БАОТ, но отличается по набору используемых элементов. В их число входят процессы, потоки данных и хранилища. Хранилища позволяют в необходимых случаях определить данные, которые будут сохраняться в памяти между процессами. Подобного элемента в SADT нет. Поэтому ряд авторов считает, что DFD лучше приспособлена для построения моделей создаваемых систем автоматизации управления, в то время как SADT ориентирована на общие аспекты построения модели системы управления.
Методология ЕКО применяется для построения моделей БД, она обеспечивает стандартизованный способ описания данных и определение связей между ними. Основные элементы методологии — понятия «сущность», «отношение» и «связь». Сущность задают базовые типы информации, а отношения указывают, как эти типы данных взаимодействуют между собой. Связи объединяют сущности и отношения. 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.4. Автоматизация проектирования АИС:
- 13.3. Проектирование АИС
- 8.5. АВТОМАТИЗАЦИЯ ПРОЕКТИРОВАНИЯ ЭКОНОМИЧЕСКИХ ИНФОРМАЦИОННЫХ СИСТЕМ
- 8.4. ПРОЕКТИРОВАНИЕ ЭКОНОМИЧЕСКИХ ИНФОРМАЦИОННЫХ СИСТЕМ 8.4.1. ЗАДАЧИ ПРОЕКТИРОВАНИЯ
- § 3. Районная планировка — связующее звено между проектированием предприятий и проектированием их размещения
- Фаза IV - Проектирование: Проектирование новогоадминистративного бизнес-процесса
- 13.5. Построение и внедрение АИС
- 6.2. Программные средства автоматизации с моделями предметнойобласти
- 13.1. Основные принципы АИС
- 2.1. Цели АИС
- 13.2.2.Формализованное моделирование АИС
- 2.3. Функции АИС
- 2.2. Задачи АИС
- 13.2.1. Концептуальное моделирование АИС
- 3.2. Обеспечивающая часть структуры АИС
- 14.1. Параметризация АИС
- 8.1. Особенности автоматизации бухгалтерского учета
- 13.2.3. Физическое моделирование АИС
- 3.1. Определение структуры и целостности АИС