| Современные автоматизированные информационные системы (АИС) относятся к числу наиболее сложных систем, создаваемых человеком. Методы и средства их создания развиваются быстрыми темпами, как в качественном, так и в количественном отношениях, вовлекая в русло системной интеграции все большее число специалистов. В предлагаемой обзорной статье рассмотрены состояние и общие вопросы методического обеспечения проектирования АИС. |
Этапы проектирования автоматизированных информационных систем. К проектированию АИС непосредственное отношение имеют два направления деятельности: 1) собственно проектирование АИС конкретных предприятий (отраслей) на базе готовых программных и аппаратных компонентов с помощью специальных инструментальных средств разработки; 2) проектирование упомянутых компонентов АИС и инструментальных средств, ориентированных на многократное применение при разработке многих конкретных информационных систем.
Сущность первого направления может быть выражена словами “системная интеграция”. Разработчик АИС должен быть специалистом в области системотехники, хорошо знать международные стандарты, состояние и тенденции развития информационных технологий и программных продуктов, владеть инструментальными средствами разработки приложений (CASE-средствами) и быть готовым к восприятию и анализу автоматизируемых прикладных процессов в сотрудничестве со специалистами соответствующей предметной области. Существует ряд фирм, специализирующихся на разработке проектов АИС (например, Price Waterhouse, Jet Info, Consistent Software и др.)
Второе направление в большей мере относится к области разработки математического и программного обеспечения для реализации функций АИС — моделей, методов, алгоритмов, программ на базе знания системотехники, методов анализа и синтеза проектных решений, технологий программирования, операционных систем и т. п. В каждом классе АИС (АСУ, САПР, ГИС и т. д.) имеются фирмы, специализирующиеся на разработке программных (а иногда и программно-аппаратных) систем. Каждая из них рекламирует свою технологию создания АИС и придерживается стратегии либо тотального поставщика, либо открытости и расширения системы приложениями и дополнениями третьих фирм.
Как, собственно, АИС, так и компоненты АИС являются сложными системами, и при их проектировании целесообразно использовать нисходящий стиль блочно-иерархического проектирования, включающего ряд уровней и этапов [1, 2].
Верхний уровень проектирования АИС часто называют концептуальным проектированием. Концептуальное проектирование выполняется в процессе предпроектных исследований, формулировки технического предложения, разработки эскизного проекта.
Предпроектные исследования проводятся путем анализа (обследования) деятельности предприятия (компании, учреждения, офиса), на котором создается или модернизируется АИС. Перед обследованием формируются и в процессе его проведения уточняются цели обследования — определение возможностей и ресурсов для повышения эффективности функционирования предприятия на основе автоматизации процессов управления, проектирования, документооборота. Содержание обследования — выявление структуры предприятия, выполняемых функций, информационных потоков, опыта и имеющихся средств автоматизации. Обследование проводится системными аналитиками (системными интеграторами) совместно с представителями организации-заказчика.
На основе анализа результатов обследования разрабатывается исходная концепция АИС. Эта концепция включает предложения по изменению структуры предприятия и взаимодействия подразделений, по выбору базовых программно-аппаратных средств, причем предложения должны учитывать прогноз развития предприятия. В отношении аппаратных средств и особенно программного обеспечения (ПО) такой выбор чаще всего есть выбор фирмы — поставщика необходимых средств (или, по крайней мере, базового ПО), так как правильная совместная работа программ разных фирм достигается с большим трудом.
В концепции может быть предложено несколько вариантов выбора. При анализе выясняются возможности покрытия автоматизируемых функций имеющимися программными продуктами и, следовательно, объемы работ по разработке оригинального ПО. Подобный анализ необходим для предварительной оценки временных и материальных затрат на автоматизацию. Учет ресурсных ограничений позволяет уточнить достижимые масштабы автоматизации, выполнить разделение создания АИС на работы первой, второй и т. д. очереди.
Результаты анализа — техническое предложение и бизнес-план создания АИС — представляются заказчику для окончательного согласования.
Как на этапе обследования, так и на последующих этапах целесообразно придерживаться определенной дисциплины фиксации и представления получаемых результатов, основанной на той или иной методике формализации спецификаций. Формализация нужна для однозначного понимания исполнителями и заказчиками требований, ограничений и принимаемых решений.
При концептуальном проектировании применяют ряд спецификаций, среди которых центральное место занимают модели преобразования, хранения и передачи информации. Модели, полученные в процессе обследования предприятия, являются моделями его функционирования. В процессе разработки АИС модели, как правило, претерпевают существенные изменения и в окончательном виде они рассматриваются уже как модели проектируемой АИС.
Различают функциональные, информационные, поведенческие и структурные модели. Функциональная модель системы описывает совокупность выполняемых системой функций. Информационная модель отражает структуры данных — их состав и взаимосвязи. Поведенческая модель описывает информационные процессы (динамику функционирования), в ней фигурируют такие категории, как состояние системы, событие, переход из одного состояния в другое, условия перехода, последовательность событий. Структурная модель характеризует морфологию системы (ее построение) — состав подсистем, их взаимосвязи.
Содержанием последующих этапов нисходящего проектирования является определение перечней приобретаемого оборудования и готовых программных продуктов, построение системной среды, детальное инфологическое проектирование баз данных и их первоначального наполнения, разработка собственного оригинального ПО, которая, в свою очередь, делится на ряд этапов нисходящего проектирования.
Особое место в ряду проектных задач занимает разработка проекта корпоративной вычислительной сети, поскольку техническое обеспечение АИС имеет сетевую структуру.
Если территориально АИС располагается в одном здании или в нескольких близкорасположенных зданиях, то корпоративная сеть может быть выполнена в виде совокупности нескольких локальных подсетей типа Ethernet или Token Ring, связанных опорной сетью типа FDDI, ATM или высокоскоростными вариантами Ethernet. Кроме выбора типов подсетей, связных протоколов и коммутационного оборудования приходится решать задачи распределения узлов по подсетям, выделения серверов, выбора сетевого ПО, определения способа управления данными в выбранной схеме распределенных вычислений и т. п.
Если АИС располагается в удаленных друг от друга пунктах, в частности, расположенных в разных городах, то решается вопрос об аренде каналов связи для корпоративной сети, поскольку альтернативный вариант использования выделенного канала в большинстве случаев оказывается неприемлемым из-за высокой цены. Естественно, что при этом, прежде всего, рассматривается возможность использования услуг Internet. Именно через Internet могут взаимодействовать предприятия, работающие по технологии CALS (Computer Acquisition Life-Cycle System). Возникающие при этом проблемы связаны с обеспечением информационной безопасности и надежности доставки сообщений.
Одной из главных тенденций современной индустрии информатики является создание открытых систем. Свойство открытости означает, во-первых, переносимость (мобильность) программного обеспечения на различные аппаратные платформы, во-вторых, приспособленность системы к ее модификациям (модифицируемость или собственно открытость) и комплексированию с другими системами в целях расширения ее функциональных возможностей и/или придания системе новых качеств (интегрируемость).
Важное значение для создания открытых систем имеет унификация и стандартизация средств межпрограммного интерфейса или, другими словами, необходимо наличие профилей АИС для информационного взаимодействия программ, входящих в АИС. Профилем открытой системы называют совокупность стандартов и других нормативных документов, обеспечивающих выполнение системой заданных функций. Так, в профилях АИС могут фигурировать язык EXPRESS стандарта STEP, стандарт графического пользовательского интерфейса Motif, унифицированный язык SQL обмена данными между различными системами управления базами данных (СУБД), стандарты сетевого взаимодействия, в профили САПР машиностроения может входить формат IGES и в случае САПР радиоэлектроники — формат EDIF и т. п.
CASE - системы. В современных информационных технологиях важное место отводится инструментальным средствам и средам разработки АИС и, в частности, системам разработки и сопровождения их ПО. Эти технологии и среды образуют системы, называемые CASE-системами.
Используется двоякое толкование аббревиатуры CASE, соответствующее двум направлениям использования CASE-систем. Первое из них — Computer Aided Software Engineering — переводится как автоматизированное проектирование программного обеспечения, соответствующие CASE-системы часто называют инструментальными средами разработки ПО (RAD — Rapid Application Development). Второе — Computer Aided System Engineering — подчеркивает направленность на поддержку концептуального проектирования сложных систем, преимущественно слабоструктурированных. Такие CASE-системы часто называют системами BPR (Business Process Reengineering).
Инструментальные системы разработки программного обеспечения. Среди систем RAD различают интегрированные комплексы инструментальных средств для автоматизации всех этапов жизненного цикла ПО (такие системы называют Workbench) и специализированные инструментальные средства для выполнения отдельных функций (Tools). Средства CASE по своему функциональному назначению принадлежат к одной из следующих групп: 1) средства программирования; 2) средства управления программным проектом; 3) средства верификации (анализа) программ; 4) средства документирования.
Проектирование ПО с помощью CASE систем включает несколько этапов. Начальный этап — предварительное изучение проблемы. Результат представляется в виде исходной диаграммы потоков данных и согласуется с заказчиком. На следующем этапе выполняется детализация ограничений и функций программной системы, полученная логическая модель вновь согласуется с заказчиком. Далее разрабатывается физическая модель, т. е. определяется модульная структура программы, выполняется инфологическое проектирование базы данных, детализируются граф-схемы программной системы и ее модулей, проектируется пользовательских интерфейс.
Спецификации проектов программных систем. Важное значение в процессе разработки ПО имеют средства спецификации проектов ПО. Средства спецификации в значительной мере определяют суть методов CASE.
Существует ряд способов представления моделей [3]. Практически все способы функциональных спецификаций имеют следующие общие черты:
· модель имеет иерархическую структуру, представляемую в виде диаграмм нескольких уровней;
· элементарной частью диаграммы каждого уровня является конструкция "вход—функция—выход";
· необходимая дополнительная информация содержится в файлах поясняющего текста.
В большинстве случаев функциональные диаграммы являются диаграммами потоков данных (DFD — Data Flow Diagram). В DFD блоки (прямоугольники) соответствуют функциям, дуги — входным и выходным потокам данных. Поясняющий текст дается в виде "словарей данных", в которых указываются компонентный состав потоков данных, число повторений циклов и т. п. Для описания структуры информационных потоков можно использовать нотацию Бэкуса—Наура.
Разработка DFD начинается с построения диаграммы верхнего уровня, отражающей связи программной системы, представленной в виде единого процесса, с внешней средой. Декомпозиция процесса проводится до уровня, на котором фигурируют элементарные процессы. Эти элементарные процессы могут быть представлены одностраничными описаниями алгоритмов (мини-спецификациями) на терминальном языке программирования.
Для описания информационных моделей наибольшее распространение получили диаграммы "сущность—связь" (ERD — Entity-Relations Diagrams), фигурирующие, например, в методике IDEF1X.
Поведенческие модели описывают процессы обработки информации. В системах CASE их представляют в виде граф-схем, диаграмм перехода состояний, таблиц решений, псевдокодов (языков спецификаций), языков программирования, в том числе языков четвертого поколения (4GL).
В граф-схемах блоки, как и в DFD, используют для задания процессов обработки, но дуги имеют иной смысл — они описывают последовательность передач управления (вместе со специальными блоками управления).
В диаграммах перехода состояний узлы соответствуют состояниям моделируемой системы, дуги — переходам из состояния в состояние, атрибуты дуг — условиям перехода и инициируемым при их выполнении действиям. Очевидно, что, как и в других, конечно-автоматных моделях, кроме графической формы представления диаграмм перехода состояний можно использовать и табличные формы. Так, при изоморфном представлении с помощью таблиц перехода состояний каждому переходу соответствует строка таблицы, в которой указываются исходное состояние, условие перехода, инициируемое при этом действие и новое состояние после перехода.
Близкий по своему характеру способ описания процессов основан на таблицах (или деревьях) решений. Каждый столбец таблицы решений соответствует определенному сочетанию условий, при выполнении которых осуществляются действия, указанные в нижерасположенных клетках столбца.
В псевдокодах алгоритмы записываются с помощью как средств некоторого языка программирования (преимущественно для управляющих операторов), так и естественного языка (для выражения содержания вычислительных блоков). Используются конструкции (операторы) следования, условные, цикла.
Языки четвертого поколения направлены на описание программ как совокупностей заранее разработанных программных модулей. Поэтому одна команда языка 4GL может соответствовать значительному фрагменту программы на языке 3GL. Примерами языков 4GL могут служить Informix-4GL, JAM, NewEra.
Мини-спецификации процессов могут быть выражены с помощью псевдокодов (языков спецификаций), визуальных языков проектирования или языков программирования.
Инструментальные среды разработки ПО. Примерами широко известных инструментальных сред RAD являются VB (Visual Basic), Delphi, PowerBuilder соответственно фирм Microsoft, Borland, PowerSoft. Применение инструментальных сред существенно сокращает объем ручной работы программистов, особенно при разработке интерфейсных частей программы.
В средах быстрой разработки приложений обычно реализуется способ программирования, называемый управлением событиями. При этом достигается автоматическое создание каркасов программ, существенно сокращается объем ручного кодирования, особенно при разработке интерфейсных частей программ. В этих средах пользователь может работать одновременно с несколькими экранами (окнами). Типичными являются окна из следующего списка:
I. Окно меню с пунктами "file", "edit", "windows" и т. п., реализующими функции, очевидные из названия пунктов.
II. Окно формы, на котором, собственно, и создается прототип экрана будущей прикладной программы.
III. Палитра инструментов — набор изображений объектов пользовательского интерфейса, из которых можно компоновать окно формы.
IV. Окно свойств и событий, с помощью которого ставятся в соответствие друг другу объекты окна формы, события и обработчики событий. Событием в прикладной программе является нажатие клавиши или установка курсора мыши в объект формы. Каждому событию должна соответствовать событийная процедура (обработчик события), которая проверяет код клавиши и вызывает нужную реакцию.
V. Окно редактора кода, на котором пользователь записывает создаваемую вручную часть кода.
VI. Окно проекта — список модулей и форм в создаваемой программе.
Для написания событийных процедур в Visual Basic используется язык и текстовый редактор языка Basic, в Delphi — язык и редактор языка Object Pascal. В CASE-системе фирмы IBM, включающей части VisualAge (для клиентских приложений) и VisualGen (для серверных приложений), базовым языком выбран SmallTalk. В среде разработки приложений "клиент-сервер" SQLWindows оригинальные фрагменты программ пишутся на специальном языке SAL. Нужно заметить, что для реализации вычислительных процедур и, в частности, для написания мини-спецификаций используется обычная для 3GL технология программирования.
Обычно после написания ПП на базовом языке компилятор системы переводит программу на промежуточный р - код. Вместе с интерпретатором р - кода эта программа рассматривается как ЕХЕ-файл. В некоторых развитых средах компилируется обычный ЕХЕ-файл, не требующий интерпретации для своего исполнения.
Помимо упрощения написания пользовательского интерфейса, в средах RAD предусматриваются средства для реализации и ряда других функций. Так, в наиболее развитой версии Visual Basic к ним относятся средства выполнения следующих функций:
· поддержка ODBC, что дает возможность работы с различными СУБД;
· разработка баз данных;
· разработка трехзвенных систем распределенных вычислений;
· интерактивная отладка процедур на SQL Server;
· управление версиями при групповой разработке ПО;
· моделирование и анализ сценариев распределенных вычислений.
Создание сред RAD для сетевого программирования требует решения ряда дополнительных проблем, обусловливаемых многоплатформенностью, обилием применяемых форматов данных и т. п. Решение этих проблем, а также устранение некоторых особенностей языка C++, усложняющих программирование, достигнуто в языке программирования Java. Для этого языка разработана своя инструментальная среда JDK (Java Developer's Kit). В ней имеются библиотека классов и инструментальные средства такие, как компилятор байт-кодов, интерпретатор, просмотрщик аплетов, отладчик, формирователь оконных форм и т. п. Значительное внимание уделяется разработке инструментальных сред для создания Web-узлов, примером такой среды может служить HAHTSite фирмы HAHTSoftware. Для разработки Java-программ из готовых компонентов служит среда IBM Visual Age for Java, в которой имеются (как и в среде VB) версии учебная, профессиональная и общецелевая (Enterprise).
Технологии реинжиниринга и параллельного проектирования. Взаимосвязанная совокупность методик концептуального проектирования IDEF (Integrated Definition) разработана по программе Integrated Computer-Aided Manufacturing в США. В этой совокупности имеются методики функционального, информационного и поведенческого моделирования и проектирования, в ее состав в настоящее время входят IDEF-методики, отмеченные в таблице.
Наиболее известной методикой функционального моделирования сложных систем является методика SADT (Structured Analysis and Design Technique), предложенная в 1973г. Д. Россом и впоследствии ставшая основой стандарта IDEF0 [4, 5].
Таблица
Название
Назначение
IDEF0
Функциональное моделирование (Function Modeling Method)
IDEF1 и IDEF1X
Информационное моделирование (Information and Data Modeling Methods)
IDEF2
Поведенческое моделирование (Simulation Modeling Method)
IDEF3
Моделирование процессов (Process Flow and Object State Description Capture Method)
IDEF4
Объектно-ориентированное проектирование (Object-Oriented Design Method)
IDEF5
Систематизации объектов приложения (Ontology Description Capture method)
IDEF6
Использование рационального опыта проектирования (Design Rationale Capture Method)
IDEF8
Взаимодействие человека и системы (Human-System Interaction Design)
IDEF9
Учет условий и ограничений (Business Constraint Discovery)
IDEF14
Моделирование вычислительных сетей (Network Design)
Эта методика рекомендуется для начальных стадий проектирования сложных искусственных систем управления, производства, бизнеса, включающих людей, оборудование, программное обеспечение.
Разработка SADT-модели начинается с формулировки вопросов, на которые модель должна давать ответы, т. е. формулируется цель моделирования. Далее выполняются этапы:
· сбор информации. Источниками информации могут быть документы, наблюдение, анкетирование и т. п. Существуют специальные методики выбора экспертов и анкетирования;
· создание модели. Используется нисходящий стиль: сначала разрабатываются верхние уровни, затем нижние;
· рецензирование модели. Реализуются в итерационной процедуре рассылки модели на отзыв и ее доработки по замечаниям рецензентов, в завершение собирается согласительное совещание.
Поведенческое моделирование сложных систем используется для определения динамики функционирования сложных систем. В его основе лежат модели и методы имитационного моделирования систем массового обслуживания, сети Петри, возможно применение конечно-автоматных моделей, описывающих поведение системы как последовательности смены состояний.
Поведенческие аспекты приложений отражает методика IDEF3 [6]. Если методика IDEF0 связана с функциональными аспектами и позволяет отвечать на вопрос "Что делает система?", то в IDEF3 детализируются и конкретизируются IDEF0-функции, IDEF3-модель отвечает на вопрос "Как система это делает?". В IDEF3 входят два типа описаний: 1) процесс - ориентированные в виде последовательности операций; 2) объект - ориентированные, представляемые диаграммами перехода состояний, характерными для конечно-автоматных моделей; в этих диаграммах имеются средства для изображения состояний системы, активности, переходов из состояния в состояние и условий перехода.
Системы информационного моделирования реализуют методики инфологического проектирования баз данных. Широко используются язык и методика IDEF1X создания информационных моделей приложений, развивающая более раннюю методику IDEF1 [7]. Кроме того, развитые коммерческие СУБД, как правило, имеют в своем составе совокупность CASE-средств проектирования приложений.
В IDEF1X имеется ясный графический язык для описания объектов и отношений в приложениях. Этот язык есть язык диаграмм "сущность-связь" (ERD). Разработка информационной модели по IDEF1X выполняется за несколько стадий.
Стадия 0. Выясняются цели проекта, составляется план сбора информации. Обычно исходные положения для информационной модели следуют из IDEF0-модели.
Стадия 1. Выявление и определение сущностей. Это неформальная процедура.
Стадия 2. Выявление и определение основных отношений. Результат представляется или графически в виде ER-диаграмм, или в виде матрицы отношений, элемент которой Aij = 1, если имеется связь между сущностями i и j, иначе Aij = 0, транзитивные связи не указываются.
Стадия 3. Детализация неспецифических отношений, определение ключевых атрибутов, установление внешний ключей. Детализация неспецифических отношений заключается в замене связей "многие ко многим" на связи "многие к одному" и "один ко многим" введением сущности-посредника.
Стадия 4. Определение атрибутов и их принадлежности сущностям.
Методика IDEF4 реализует объективно-ориентированное проектирование больших систем [2]. Она предоставляет пользователю графический язык для изображения классов, диаграмм наследования, таксономии методов.
Методика IDEF5 направлена на представление онтологической информации приложения в удобном для пользователя виде. Для этого используются символические обозначения (дескрипторы) объектов, их ассоциаций, ситуаций и схемный язык описания отношений классификации, "часть—целое", перехода и т. п. В методике имеются правила связывания объектов (термов) в правильные предложения и аксиомы интерпретации термов.
Развитие BPR методик продолжается в США по программе IIСЕ (Information Integration for Concurrent Engineering) [8]. Разработаны методики:
· IDEF6, направленная на сохранение рационального опыта проектирования информационных систем, что способствует предотвращению повторных ошибок;
· IDEF8 для проектирования диалога человека с технической системой;
· IDEF9 для анализа имеющихся условий и ограничений (в том числе физических, юридических, политических) и их влияния на принимаемые решения в процессе реинжиниринга;
· IDEF14 для представления и анализа данных при проектировании вычислительных сетей на графическом языке с описанием конфигураций, очередей, сетевых компонентов, требований к надежности и т. п.
Основные положения стандартов IDEF0 и IDEF1X использованы также при создании комплекса стандартов ISO 10303, задающих технологию STEP для представления в компьютерных средах информации, относящейся к промышленному производству. В свою очередь, стандарты STEP, совокупность языков таких, как Express и SGML, а также разрабатываемые стандарты P-LIB и MANDATE [9] составляют основу технологии CALS информационного обеспечения всех этапов жизненного цикла промышленных изделий.
Технология CALS призвана разрешить проблему согласования содержания и формы представления данных о промышленной продукции в территориально распределенной сети проектных и производственных узлов на основе совокупности международных стандартов и телекоммуникационных технологий. Только в этих условиях станет возможной оптимальная специализация предприятий, распределенное проектирование, минимизация затрат на освоение и эксплуатацию созданных систем.
Программное обеспечение CASE-систем. На рынке программных продуктов имеется много CASE-систем для концептуального проектирования АИС.
Чаще всего в них поддерживается методология IDEF. В России широко известны продукты BPWin, ERWin, OOWin фирмы Logic Works, Design/IDEF фирмы Meta Software, CASE-Аналитик фирмы Эйтэкс, Silverrun фирмы CSA и др.
BPWin (Business Processing) предназначена для разработки функциональных моделей по методике IDEF0.
ERWin предназначена для разработки информационных моделей по методике IDEF1X. Имеются средства, обеспечивающие интерфейс с серверами баз данных (от пользователя скрыто общение на SQL-языке), перевод графических изображений ER-диаграмм в SQL-формы или в форматы других популярных СУБД. В систему включены также типичные для CASE средства разработки экранных форм.
OOWin служит для поддержки объектно-ориентированных технологий проектирования информационных систем. Один из способов использования OOWin — детализация объектно-ориентированной модели на базе созданной ER-модели. При преобразовании ER в ОО-представление сущности и атрибуты становятся классами (множествами подобных объектов). Классы могут быть дополнены описанием услуг класса, т. е. выполняемых операций, передаваемых и возвращаемых параметров, событий. Другой способ использования OOWin — реинжиниринг, так как модернизация проводится на уровне существующей модели.
Ряд программных продуктов, реализующих IDEF-модели, разработаны фирмой KBSI, в частности, ProSim реализует IDEF3, SmartER — IDEF1 и IDEF1X, SmartClass - IDEF4.
Поведенческое моделирование предприятий предусмотрено также в некоторых системах реинжиниринга, например, в системе BAAN IV [10].
Важной проблемой является разработка метамоделей приложений, включающих методы взаимной трансформации функциональных, информационных и структурных моделей. В частности, требуется систематизация понятий, фигурирующих в приложениях, и построение словарей соответствия моделей этих типов.
Системные (операционные) среды автоматизированных информационных систем (АИС). Системы автоматизированного проектирования относятся к числу наиболее сложных и наукоемких автоматизированных систем. Более того, на крупных и средних предприятиях заметна тенденция к интеграции САПР с системами документооборота, а иногда и с системами управления производством.
Системные среды САПР [11] часто называют инфраструктурами САПР или Frameworks (FW). Основные функции системных сред САПР:
· управление данными;
· управление процессом проектирования;
· интеграция программного обеспечения;
· реализация интерфейса с пользователем САПР;
· помощь в разработке и сопровождении ПО САПР.
Сходные функции реализуются и в системных средах АСУ с той разницей, что в них вместо проектных операций и процедур фигурируют бизнес-функции и бизнес-процессы. В типичной структуре программного обеспечения системных сред САПР выделяют следующие подсистемы.
Ядро FW отвечает за взаимодействие компонентов FW, доступ к ресурсам операционной системы и к сети, возможность работы в гетерогенной распределенной среде, настройку на конкретную САПР с помощью специальных языков расширения.
Подсистема управления проектом выполняет функции слежения за состоянием проекта, координации и синхронизации параллельно выполняемых процедур разными исполнителями. Часто в отдельную подсистему выделяют управление методологией проектирования. При этом под методологией понимают совокупность методов и средств образования маршрутов проектирования — последовательностей проектных операций и процедур, ведущих к цели проектирования.
Подсистема управления методологией проектирования представлена в виде базы знаний БЗ УПР. В этой базе знаний содержатся такие сведения о предметной области, как информационная модель (например, в виде диаграмм "сущность—отношение"), иерархическая структура проектируемых объектов (например, в виде И—ИЛИ-дерева), описания типовых проектных процедур, типовые фрагменты маршрутов проектирования — так называемые потоки (flows) процедур, соответствие между процедурами и имеющимися пакетами прикладных программ, ограничения на их применение и т. п. Часто БЗ УПР дополняется обучающей подсистемой, используемой для подготовки специалистов к использованию САПР.
Основные функции подсистемы управления данными реализуются в банке данных, предназначенном для информационного обеспечения проектирования. Кроме того, межпрограммный интерфейс в значительной мере реализуется через информационный обмен с помощью банка данных.
Подсистема интеграции программного обеспечения предназначена для организации взаимодействия программ в маршрутах проектирования. Она состоит из ядра, отвечающего за интерфейс на уровне подсистем, и менеджеров процедур, согласующих конкретные программные модули, программы и/или программно-методические комплексы со средой проектирования. Методы построения маршрутов (flow) проектирования зависят от типа проектных задач. Различают простые задачи, выполняемые одной программой, линейные, в которых нет разветвлений в межпрограммных связях, и комплексные. Методы построения маршрутов могут быть основаны на предварительном описании задач или на предварительном описании правил конструирования задач. В описании задач фигурируют порты, которым соотнесены данные. Порты могут быть обязательными и необязательными, порождающими дополнительные данные или данные нового объекта. Описания задач даются в виде графов или на языках расширения.
Интеграция может быть на основе унифицированных форматов или общего банка данных. Пример унифицированного формата — TES (Tool Encapsulation Specification), предложенного консорциумом CFI (CAD Framework Initiative). Информация из TES используется для создания конверторов файлов при инкапсуляции.
Подсистема пользовательского интерфейса включает текстовый и графический редакторы и поддерживается системами многооконного интерфейса типа X Windows System или Open Look.
Подсистема CASE предназначена для адаптации САПР к нуждам конкретных пользователей, для разработки и сопровождения прикладного ПО. Обычно CASE-подсистема включает обычные CASE-компоненты для разработки структурных схем алгоритмов, "экранов" для взаимодействия с пользователем в интерактивных процедурах, средства для инфологического проектирования баз данных (БД), отладки программ, документирования, сохранения "истории" проектирования и т. п. Но наряду с этим, в подсистему входят и компоненты со специфическими для САПР функциями.
Так, в состав САПР Microstation [12] (фирма Bentley Systems) включена RAD-среда Microstation Basic и язык MDL (Microstation Development Language) с соответствующей программной поддержкой. Microstation Basic близка по своим функциям к среде MS Visual Basic, в ней имеются генератор форм, редактор, конструктор диалога, отладчик. Язык MDL — С - подобный, с его помощью можно лаконично выразить обращения к проектным операциям и процедурам.
САПР Спрут [13] (российская фирма Sprut Technologies) вообще создана как инструментальная среда для разработки пользователем потоков задач конструкторского и технологического проектирования в машиностроении с последующим возможным оформлением потоков в виде пользовательских версий САПР. Сконструированный поток поддерживается компонентами системы, в число которых входят графические 2D и 3D подсистемы, СУБД, продукционная экспертная система, документатор, технологический процессор создания программ для станков с ЧПУ, постпроцессоры.
Тенденция к созданию интегрируемых производственных систем привела к развитию технологии CALS. Одной из развитых реализаций CALS-технологии является концепция EPD (Electronic Product Definition) фирмы Computervision. В соответствии с ней следующие компоненты должны входить в CALS-систему [14]:
· комплекс прикладных программ автоматизированного проектирования (проектирующие подсистемы САПР), включая программы для конструирования изделий и инженерного анализа проектных решений;
· подсистема автоматизации технологической подготовки производства;
· средства управления процессом проектирования;
· средства управления данными;
· средства визуализации и разработки документации;
· CASE-подсистема;
· языковые средства межпрограммных обменов;
· методики анализа проектно-технологической, производственной и управленческой деятельности предприятия.
Как видно из названий подсистем этого перечня, функции и состав системных сред CALS и входящих в них САПР в значительной мере совпадают.
Сущность первого направления может быть выражена словами “системная интеграция”. Разработчик АИС должен быть специалистом в области системотехники, хорошо знать международные стандарты, состояние и тенденции развития информационных технологий и программных продуктов, владеть инструментальными средствами разработки приложений (CASE-средствами) и быть готовым к восприятию и анализу автоматизируемых прикладных процессов в сотрудничестве со специалистами соответствующей предметной области. Существует ряд фирм, специализирующихся на разработке проектов АИС (например, Price Waterhouse, Jet Info, Consistent Software и др.)
Второе направление в большей мере относится к области разработки математического и программного обеспечения для реализации функций АИС — моделей, методов, алгоритмов, программ на базе знания системотехники, методов анализа и синтеза проектных решений, технологий программирования, операционных систем и т. п. В каждом классе АИС (АСУ, САПР, ГИС и т. д.) имеются фирмы, специализирующиеся на разработке программных (а иногда и программно-аппаратных) систем. Каждая из них рекламирует свою технологию создания АИС и придерживается стратегии либо тотального поставщика, либо открытости и расширения системы приложениями и дополнениями третьих фирм.
Как, собственно, АИС, так и компоненты АИС являются сложными системами, и при их проектировании целесообразно использовать нисходящий стиль блочно-иерархического проектирования, включающего ряд уровней и этапов [1, 2].
Верхний уровень проектирования АИС часто называют концептуальным проектированием. Концептуальное проектирование выполняется в процессе предпроектных исследований, формулировки технического предложения, разработки эскизного проекта.
Предпроектные исследования проводятся путем анализа (обследования) деятельности предприятия (компании, учреждения, офиса), на котором создается или модернизируется АИС. Перед обследованием формируются и в процессе его проведения уточняются цели обследования — определение возможностей и ресурсов для повышения эффективности функционирования предприятия на основе автоматизации процессов управления, проектирования, документооборота. Содержание обследования — выявление структуры предприятия, выполняемых функций, информационных потоков, опыта и имеющихся средств автоматизации. Обследование проводится системными аналитиками (системными интеграторами) совместно с представителями организации-заказчика.
На основе анализа результатов обследования разрабатывается исходная концепция АИС. Эта концепция включает предложения по изменению структуры предприятия и взаимодействия подразделений, по выбору базовых программно-аппаратных средств, причем предложения должны учитывать прогноз развития предприятия. В отношении аппаратных средств и особенно программного обеспечения (ПО) такой выбор чаще всего есть выбор фирмы — поставщика необходимых средств (или, по крайней мере, базового ПО), так как правильная совместная работа программ разных фирм достигается с большим трудом.
В концепции может быть предложено несколько вариантов выбора. При анализе выясняются возможности покрытия автоматизируемых функций имеющимися программными продуктами и, следовательно, объемы работ по разработке оригинального ПО. Подобный анализ необходим для предварительной оценки временных и материальных затрат на автоматизацию. Учет ресурсных ограничений позволяет уточнить достижимые масштабы автоматизации, выполнить разделение создания АИС на работы первой, второй и т. д. очереди.
Результаты анализа — техническое предложение и бизнес-план создания АИС — представляются заказчику для окончательного согласования.
Как на этапе обследования, так и на последующих этапах целесообразно придерживаться определенной дисциплины фиксации и представления получаемых результатов, основанной на той или иной методике формализации спецификаций. Формализация нужна для однозначного понимания исполнителями и заказчиками требований, ограничений и принимаемых решений.
При концептуальном проектировании применяют ряд спецификаций, среди которых центральное место занимают модели преобразования, хранения и передачи информации. Модели, полученные в процессе обследования предприятия, являются моделями его функционирования. В процессе разработки АИС модели, как правило, претерпевают существенные изменения и в окончательном виде они рассматриваются уже как модели проектируемой АИС.
Различают функциональные, информационные, поведенческие и структурные модели. Функциональная модель системы описывает совокупность выполняемых системой функций. Информационная модель отражает структуры данных — их состав и взаимосвязи. Поведенческая модель описывает информационные процессы (динамику функционирования), в ней фигурируют такие категории, как состояние системы, событие, переход из одного состояния в другое, условия перехода, последовательность событий. Структурная модель характеризует морфологию системы (ее построение) — состав подсистем, их взаимосвязи.
Содержанием последующих этапов нисходящего проектирования является определение перечней приобретаемого оборудования и готовых программных продуктов, построение системной среды, детальное инфологическое проектирование баз данных и их первоначального наполнения, разработка собственного оригинального ПО, которая, в свою очередь, делится на ряд этапов нисходящего проектирования.
Особое место в ряду проектных задач занимает разработка проекта корпоративной вычислительной сети, поскольку техническое обеспечение АИС имеет сетевую структуру.
Если территориально АИС располагается в одном здании или в нескольких близкорасположенных зданиях, то корпоративная сеть может быть выполнена в виде совокупности нескольких локальных подсетей типа Ethernet или Token Ring, связанных опорной сетью типа FDDI, ATM или высокоскоростными вариантами Ethernet. Кроме выбора типов подсетей, связных протоколов и коммутационного оборудования приходится решать задачи распределения узлов по подсетям, выделения серверов, выбора сетевого ПО, определения способа управления данными в выбранной схеме распределенных вычислений и т. п.
Если АИС располагается в удаленных друг от друга пунктах, в частности, расположенных в разных городах, то решается вопрос об аренде каналов связи для корпоративной сети, поскольку альтернативный вариант использования выделенного канала в большинстве случаев оказывается неприемлемым из-за высокой цены. Естественно, что при этом, прежде всего, рассматривается возможность использования услуг Internet. Именно через Internet могут взаимодействовать предприятия, работающие по технологии CALS (Computer Acquisition Life-Cycle System). Возникающие при этом проблемы связаны с обеспечением информационной безопасности и надежности доставки сообщений.
Одной из главных тенденций современной индустрии информатики является создание открытых систем. Свойство открытости означает, во-первых, переносимость (мобильность) программного обеспечения на различные аппаратные платформы, во-вторых, приспособленность системы к ее модификациям (модифицируемость или собственно открытость) и комплексированию с другими системами в целях расширения ее функциональных возможностей и/или придания системе новых качеств (интегрируемость).
Важное значение для создания открытых систем имеет унификация и стандартизация средств межпрограммного интерфейса или, другими словами, необходимо наличие профилей АИС для информационного взаимодействия программ, входящих в АИС. Профилем открытой системы называют совокупность стандартов и других нормативных документов, обеспечивающих выполнение системой заданных функций. Так, в профилях АИС могут фигурировать язык EXPRESS стандарта STEP, стандарт графического пользовательского интерфейса Motif, унифицированный язык SQL обмена данными между различными системами управления базами данных (СУБД), стандарты сетевого взаимодействия, в профили САПР машиностроения может входить формат IGES и в случае САПР радиоэлектроники — формат EDIF и т. п.
CASE - системы. В современных информационных технологиях важное место отводится инструментальным средствам и средам разработки АИС и, в частности, системам разработки и сопровождения их ПО. Эти технологии и среды образуют системы, называемые CASE-системами.
Используется двоякое толкование аббревиатуры CASE, соответствующее двум направлениям использования CASE-систем. Первое из них — Computer Aided Software Engineering — переводится как автоматизированное проектирование программного обеспечения, соответствующие CASE-системы часто называют инструментальными средами разработки ПО (RAD — Rapid Application Development). Второе — Computer Aided System Engineering — подчеркивает направленность на поддержку концептуального проектирования сложных систем, преимущественно слабоструктурированных. Такие CASE-системы часто называют системами BPR (Business Process Reengineering).
Инструментальные системы разработки программного обеспечения. Среди систем RAD различают интегрированные комплексы инструментальных средств для автоматизации всех этапов жизненного цикла ПО (такие системы называют Workbench) и специализированные инструментальные средства для выполнения отдельных функций (Tools). Средства CASE по своему функциональному назначению принадлежат к одной из следующих групп: 1) средства программирования; 2) средства управления программным проектом; 3) средства верификации (анализа) программ; 4) средства документирования.
Проектирование ПО с помощью CASE систем включает несколько этапов. Начальный этап — предварительное изучение проблемы. Результат представляется в виде исходной диаграммы потоков данных и согласуется с заказчиком. На следующем этапе выполняется детализация ограничений и функций программной системы, полученная логическая модель вновь согласуется с заказчиком. Далее разрабатывается физическая модель, т. е. определяется модульная структура программы, выполняется инфологическое проектирование базы данных, детализируются граф-схемы программной системы и ее модулей, проектируется пользовательских интерфейс.
Спецификации проектов программных систем. Важное значение в процессе разработки ПО имеют средства спецификации проектов ПО. Средства спецификации в значительной мере определяют суть методов CASE.
Существует ряд способов представления моделей [3]. Практически все способы функциональных спецификаций имеют следующие общие черты:
· модель имеет иерархическую структуру, представляемую в виде диаграмм нескольких уровней;
· элементарной частью диаграммы каждого уровня является конструкция "вход—функция—выход";
· необходимая дополнительная информация содержится в файлах поясняющего текста.
В большинстве случаев функциональные диаграммы являются диаграммами потоков данных (DFD — Data Flow Diagram). В DFD блоки (прямоугольники) соответствуют функциям, дуги — входным и выходным потокам данных. Поясняющий текст дается в виде "словарей данных", в которых указываются компонентный состав потоков данных, число повторений циклов и т. п. Для описания структуры информационных потоков можно использовать нотацию Бэкуса—Наура.
Разработка DFD начинается с построения диаграммы верхнего уровня, отражающей связи программной системы, представленной в виде единого процесса, с внешней средой. Декомпозиция процесса проводится до уровня, на котором фигурируют элементарные процессы. Эти элементарные процессы могут быть представлены одностраничными описаниями алгоритмов (мини-спецификациями) на терминальном языке программирования.
Для описания информационных моделей наибольшее распространение получили диаграммы "сущность—связь" (ERD — Entity-Relations Diagrams), фигурирующие, например, в методике IDEF1X.
Поведенческие модели описывают процессы обработки информации. В системах CASE их представляют в виде граф-схем, диаграмм перехода состояний, таблиц решений, псевдокодов (языков спецификаций), языков программирования, в том числе языков четвертого поколения (4GL).
В граф-схемах блоки, как и в DFD, используют для задания процессов обработки, но дуги имеют иной смысл — они описывают последовательность передач управления (вместе со специальными блоками управления).
В диаграммах перехода состояний узлы соответствуют состояниям моделируемой системы, дуги — переходам из состояния в состояние, атрибуты дуг — условиям перехода и инициируемым при их выполнении действиям. Очевидно, что, как и в других, конечно-автоматных моделях, кроме графической формы представления диаграмм перехода состояний можно использовать и табличные формы. Так, при изоморфном представлении с помощью таблиц перехода состояний каждому переходу соответствует строка таблицы, в которой указываются исходное состояние, условие перехода, инициируемое при этом действие и новое состояние после перехода.
Близкий по своему характеру способ описания процессов основан на таблицах (или деревьях) решений. Каждый столбец таблицы решений соответствует определенному сочетанию условий, при выполнении которых осуществляются действия, указанные в нижерасположенных клетках столбца.
В псевдокодах алгоритмы записываются с помощью как средств некоторого языка программирования (преимущественно для управляющих операторов), так и естественного языка (для выражения содержания вычислительных блоков). Используются конструкции (операторы) следования, условные, цикла.
Языки четвертого поколения направлены на описание программ как совокупностей заранее разработанных программных модулей. Поэтому одна команда языка 4GL может соответствовать значительному фрагменту программы на языке 3GL. Примерами языков 4GL могут служить Informix-4GL, JAM, NewEra.
Мини-спецификации процессов могут быть выражены с помощью псевдокодов (языков спецификаций), визуальных языков проектирования или языков программирования.
Инструментальные среды разработки ПО. Примерами широко известных инструментальных сред RAD являются VB (Visual Basic), Delphi, PowerBuilder соответственно фирм Microsoft, Borland, PowerSoft. Применение инструментальных сред существенно сокращает объем ручной работы программистов, особенно при разработке интерфейсных частей программы.
В средах быстрой разработки приложений обычно реализуется способ программирования, называемый управлением событиями. При этом достигается автоматическое создание каркасов программ, существенно сокращается объем ручного кодирования, особенно при разработке интерфейсных частей программ. В этих средах пользователь может работать одновременно с несколькими экранами (окнами). Типичными являются окна из следующего списка:
I. Окно меню с пунктами "file", "edit", "windows" и т. п., реализующими функции, очевидные из названия пунктов.
II. Окно формы, на котором, собственно, и создается прототип экрана будущей прикладной программы.
III. Палитра инструментов — набор изображений объектов пользовательского интерфейса, из которых можно компоновать окно формы.
IV. Окно свойств и событий, с помощью которого ставятся в соответствие друг другу объекты окна формы, события и обработчики событий. Событием в прикладной программе является нажатие клавиши или установка курсора мыши в объект формы. Каждому событию должна соответствовать событийная процедура (обработчик события), которая проверяет код клавиши и вызывает нужную реакцию.
V. Окно редактора кода, на котором пользователь записывает создаваемую вручную часть кода.
VI. Окно проекта — список модулей и форм в создаваемой программе.
Для написания событийных процедур в Visual Basic используется язык и текстовый редактор языка Basic, в Delphi — язык и редактор языка Object Pascal. В CASE-системе фирмы IBM, включающей части VisualAge (для клиентских приложений) и VisualGen (для серверных приложений), базовым языком выбран SmallTalk. В среде разработки приложений "клиент-сервер" SQLWindows оригинальные фрагменты программ пишутся на специальном языке SAL. Нужно заметить, что для реализации вычислительных процедур и, в частности, для написания мини-спецификаций используется обычная для 3GL технология программирования.
Обычно после написания ПП на базовом языке компилятор системы переводит программу на промежуточный р - код. Вместе с интерпретатором р - кода эта программа рассматривается как ЕХЕ-файл. В некоторых развитых средах компилируется обычный ЕХЕ-файл, не требующий интерпретации для своего исполнения.
Помимо упрощения написания пользовательского интерфейса, в средах RAD предусматриваются средства для реализации и ряда других функций. Так, в наиболее развитой версии Visual Basic к ним относятся средства выполнения следующих функций:
· поддержка ODBC, что дает возможность работы с различными СУБД;
· разработка баз данных;
· разработка трехзвенных систем распределенных вычислений;
· интерактивная отладка процедур на SQL Server;
· управление версиями при групповой разработке ПО;
· моделирование и анализ сценариев распределенных вычислений.
Создание сред RAD для сетевого программирования требует решения ряда дополнительных проблем, обусловливаемых многоплатформенностью, обилием применяемых форматов данных и т. п. Решение этих проблем, а также устранение некоторых особенностей языка C++, усложняющих программирование, достигнуто в языке программирования Java. Для этого языка разработана своя инструментальная среда JDK (Java Developer's Kit). В ней имеются библиотека классов и инструментальные средства такие, как компилятор байт-кодов, интерпретатор, просмотрщик аплетов, отладчик, формирователь оконных форм и т. п. Значительное внимание уделяется разработке инструментальных сред для создания Web-узлов, примером такой среды может служить HAHTSite фирмы HAHTSoftware. Для разработки Java-программ из готовых компонентов служит среда IBM Visual Age for Java, в которой имеются (как и в среде VB) версии учебная, профессиональная и общецелевая (Enterprise).
Технологии реинжиниринга и параллельного проектирования. Взаимосвязанная совокупность методик концептуального проектирования IDEF (Integrated Definition) разработана по программе Integrated Computer-Aided Manufacturing в США. В этой совокупности имеются методики функционального, информационного и поведенческого моделирования и проектирования, в ее состав в настоящее время входят IDEF-методики, отмеченные в таблице.
Наиболее известной методикой функционального моделирования сложных систем является методика SADT (Structured Analysis and Design Technique), предложенная в 1973г. Д. Россом и впоследствии ставшая основой стандарта IDEF0 [4, 5].
Таблица
Название
Назначение
IDEF0
Функциональное моделирование (Function Modeling Method)
IDEF1 и IDEF1X
Информационное моделирование (Information and Data Modeling Methods)
IDEF2
Поведенческое моделирование (Simulation Modeling Method)
IDEF3
Моделирование процессов (Process Flow and Object State Description Capture Method)
IDEF4
Объектно-ориентированное проектирование (Object-Oriented Design Method)
IDEF5
Систематизации объектов приложения (Ontology Description Capture method)
IDEF6
Использование рационального опыта проектирования (Design Rationale Capture Method)
IDEF8
Взаимодействие человека и системы (Human-System Interaction Design)
IDEF9
Учет условий и ограничений (Business Constraint Discovery)
IDEF14
Моделирование вычислительных сетей (Network Design)
Эта методика рекомендуется для начальных стадий проектирования сложных искусственных систем управления, производства, бизнеса, включающих людей, оборудование, программное обеспечение.
Разработка SADT-модели начинается с формулировки вопросов, на которые модель должна давать ответы, т. е. формулируется цель моделирования. Далее выполняются этапы:
· сбор информации. Источниками информации могут быть документы, наблюдение, анкетирование и т. п. Существуют специальные методики выбора экспертов и анкетирования;
· создание модели. Используется нисходящий стиль: сначала разрабатываются верхние уровни, затем нижние;
· рецензирование модели. Реализуются в итерационной процедуре рассылки модели на отзыв и ее доработки по замечаниям рецензентов, в завершение собирается согласительное совещание.
Поведенческое моделирование сложных систем используется для определения динамики функционирования сложных систем. В его основе лежат модели и методы имитационного моделирования систем массового обслуживания, сети Петри, возможно применение конечно-автоматных моделей, описывающих поведение системы как последовательности смены состояний.
Поведенческие аспекты приложений отражает методика IDEF3 [6]. Если методика IDEF0 связана с функциональными аспектами и позволяет отвечать на вопрос "Что делает система?", то в IDEF3 детализируются и конкретизируются IDEF0-функции, IDEF3-модель отвечает на вопрос "Как система это делает?". В IDEF3 входят два типа описаний: 1) процесс - ориентированные в виде последовательности операций; 2) объект - ориентированные, представляемые диаграммами перехода состояний, характерными для конечно-автоматных моделей; в этих диаграммах имеются средства для изображения состояний системы, активности, переходов из состояния в состояние и условий перехода.
Системы информационного моделирования реализуют методики инфологического проектирования баз данных. Широко используются язык и методика IDEF1X создания информационных моделей приложений, развивающая более раннюю методику IDEF1 [7]. Кроме того, развитые коммерческие СУБД, как правило, имеют в своем составе совокупность CASE-средств проектирования приложений.
В IDEF1X имеется ясный графический язык для описания объектов и отношений в приложениях. Этот язык есть язык диаграмм "сущность-связь" (ERD). Разработка информационной модели по IDEF1X выполняется за несколько стадий.
Стадия 0. Выясняются цели проекта, составляется план сбора информации. Обычно исходные положения для информационной модели следуют из IDEF0-модели.
Стадия 1. Выявление и определение сущностей. Это неформальная процедура.
Стадия 2. Выявление и определение основных отношений. Результат представляется или графически в виде ER-диаграмм, или в виде матрицы отношений, элемент которой Aij = 1, если имеется связь между сущностями i и j, иначе Aij = 0, транзитивные связи не указываются.
Стадия 3. Детализация неспецифических отношений, определение ключевых атрибутов, установление внешний ключей. Детализация неспецифических отношений заключается в замене связей "многие ко многим" на связи "многие к одному" и "один ко многим" введением сущности-посредника.
Стадия 4. Определение атрибутов и их принадлежности сущностям.
Методика IDEF4 реализует объективно-ориентированное проектирование больших систем [2]. Она предоставляет пользователю графический язык для изображения классов, диаграмм наследования, таксономии методов.
Методика IDEF5 направлена на представление онтологической информации приложения в удобном для пользователя виде. Для этого используются символические обозначения (дескрипторы) объектов, их ассоциаций, ситуаций и схемный язык описания отношений классификации, "часть—целое", перехода и т. п. В методике имеются правила связывания объектов (термов) в правильные предложения и аксиомы интерпретации термов.
Развитие BPR методик продолжается в США по программе IIСЕ (Information Integration for Concurrent Engineering) [8]. Разработаны методики:
· IDEF6, направленная на сохранение рационального опыта проектирования информационных систем, что способствует предотвращению повторных ошибок;
· IDEF8 для проектирования диалога человека с технической системой;
· IDEF9 для анализа имеющихся условий и ограничений (в том числе физических, юридических, политических) и их влияния на принимаемые решения в процессе реинжиниринга;
· IDEF14 для представления и анализа данных при проектировании вычислительных сетей на графическом языке с описанием конфигураций, очередей, сетевых компонентов, требований к надежности и т. п.
Основные положения стандартов IDEF0 и IDEF1X использованы также при создании комплекса стандартов ISO 10303, задающих технологию STEP для представления в компьютерных средах информации, относящейся к промышленному производству. В свою очередь, стандарты STEP, совокупность языков таких, как Express и SGML, а также разрабатываемые стандарты P-LIB и MANDATE [9] составляют основу технологии CALS информационного обеспечения всех этапов жизненного цикла промышленных изделий.
Технология CALS призвана разрешить проблему согласования содержания и формы представления данных о промышленной продукции в территориально распределенной сети проектных и производственных узлов на основе совокупности международных стандартов и телекоммуникационных технологий. Только в этих условиях станет возможной оптимальная специализация предприятий, распределенное проектирование, минимизация затрат на освоение и эксплуатацию созданных систем.
Программное обеспечение CASE-систем. На рынке программных продуктов имеется много CASE-систем для концептуального проектирования АИС.
Чаще всего в них поддерживается методология IDEF. В России широко известны продукты BPWin, ERWin, OOWin фирмы Logic Works, Design/IDEF фирмы Meta Software, CASE-Аналитик фирмы Эйтэкс, Silverrun фирмы CSA и др.
BPWin (Business Processing) предназначена для разработки функциональных моделей по методике IDEF0.
ERWin предназначена для разработки информационных моделей по методике IDEF1X. Имеются средства, обеспечивающие интерфейс с серверами баз данных (от пользователя скрыто общение на SQL-языке), перевод графических изображений ER-диаграмм в SQL-формы или в форматы других популярных СУБД. В систему включены также типичные для CASE средства разработки экранных форм.
OOWin служит для поддержки объектно-ориентированных технологий проектирования информационных систем. Один из способов использования OOWin — детализация объектно-ориентированной модели на базе созданной ER-модели. При преобразовании ER в ОО-представление сущности и атрибуты становятся классами (множествами подобных объектов). Классы могут быть дополнены описанием услуг класса, т. е. выполняемых операций, передаваемых и возвращаемых параметров, событий. Другой способ использования OOWin — реинжиниринг, так как модернизация проводится на уровне существующей модели.
Ряд программных продуктов, реализующих IDEF-модели, разработаны фирмой KBSI, в частности, ProSim реализует IDEF3, SmartER — IDEF1 и IDEF1X, SmartClass - IDEF4.
Поведенческое моделирование предприятий предусмотрено также в некоторых системах реинжиниринга, например, в системе BAAN IV [10].
Важной проблемой является разработка метамоделей приложений, включающих методы взаимной трансформации функциональных, информационных и структурных моделей. В частности, требуется систематизация понятий, фигурирующих в приложениях, и построение словарей соответствия моделей этих типов.
Системные (операционные) среды автоматизированных информационных систем (АИС). Системы автоматизированного проектирования относятся к числу наиболее сложных и наукоемких автоматизированных систем. Более того, на крупных и средних предприятиях заметна тенденция к интеграции САПР с системами документооборота, а иногда и с системами управления производством.
Системные среды САПР [11] часто называют инфраструктурами САПР или Frameworks (FW). Основные функции системных сред САПР:
· управление данными;
· управление процессом проектирования;
· интеграция программного обеспечения;
· реализация интерфейса с пользователем САПР;
· помощь в разработке и сопровождении ПО САПР.
Сходные функции реализуются и в системных средах АСУ с той разницей, что в них вместо проектных операций и процедур фигурируют бизнес-функции и бизнес-процессы. В типичной структуре программного обеспечения системных сред САПР выделяют следующие подсистемы.
Ядро FW отвечает за взаимодействие компонентов FW, доступ к ресурсам операционной системы и к сети, возможность работы в гетерогенной распределенной среде, настройку на конкретную САПР с помощью специальных языков расширения.
Подсистема управления проектом выполняет функции слежения за состоянием проекта, координации и синхронизации параллельно выполняемых процедур разными исполнителями. Часто в отдельную подсистему выделяют управление методологией проектирования. При этом под методологией понимают совокупность методов и средств образования маршрутов проектирования — последовательностей проектных операций и процедур, ведущих к цели проектирования.
Подсистема управления методологией проектирования представлена в виде базы знаний БЗ УПР. В этой базе знаний содержатся такие сведения о предметной области, как информационная модель (например, в виде диаграмм "сущность—отношение"), иерархическая структура проектируемых объектов (например, в виде И—ИЛИ-дерева), описания типовых проектных процедур, типовые фрагменты маршрутов проектирования — так называемые потоки (flows) процедур, соответствие между процедурами и имеющимися пакетами прикладных программ, ограничения на их применение и т. п. Часто БЗ УПР дополняется обучающей подсистемой, используемой для подготовки специалистов к использованию САПР.
Основные функции подсистемы управления данными реализуются в банке данных, предназначенном для информационного обеспечения проектирования. Кроме того, межпрограммный интерфейс в значительной мере реализуется через информационный обмен с помощью банка данных.
Подсистема интеграции программного обеспечения предназначена для организации взаимодействия программ в маршрутах проектирования. Она состоит из ядра, отвечающего за интерфейс на уровне подсистем, и менеджеров процедур, согласующих конкретные программные модули, программы и/или программно-методические комплексы со средой проектирования. Методы построения маршрутов (flow) проектирования зависят от типа проектных задач. Различают простые задачи, выполняемые одной программой, линейные, в которых нет разветвлений в межпрограммных связях, и комплексные. Методы построения маршрутов могут быть основаны на предварительном описании задач или на предварительном описании правил конструирования задач. В описании задач фигурируют порты, которым соотнесены данные. Порты могут быть обязательными и необязательными, порождающими дополнительные данные или данные нового объекта. Описания задач даются в виде графов или на языках расширения.
Интеграция может быть на основе унифицированных форматов или общего банка данных. Пример унифицированного формата — TES (Tool Encapsulation Specification), предложенного консорциумом CFI (CAD Framework Initiative). Информация из TES используется для создания конверторов файлов при инкапсуляции.
Подсистема пользовательского интерфейса включает текстовый и графический редакторы и поддерживается системами многооконного интерфейса типа X Windows System или Open Look.
Подсистема CASE предназначена для адаптации САПР к нуждам конкретных пользователей, для разработки и сопровождения прикладного ПО. Обычно CASE-подсистема включает обычные CASE-компоненты для разработки структурных схем алгоритмов, "экранов" для взаимодействия с пользователем в интерактивных процедурах, средства для инфологического проектирования баз данных (БД), отладки программ, документирования, сохранения "истории" проектирования и т. п. Но наряду с этим, в подсистему входят и компоненты со специфическими для САПР функциями.
Так, в состав САПР Microstation [12] (фирма Bentley Systems) включена RAD-среда Microstation Basic и язык MDL (Microstation Development Language) с соответствующей программной поддержкой. Microstation Basic близка по своим функциям к среде MS Visual Basic, в ней имеются генератор форм, редактор, конструктор диалога, отладчик. Язык MDL — С - подобный, с его помощью можно лаконично выразить обращения к проектным операциям и процедурам.
САПР Спрут [13] (российская фирма Sprut Technologies) вообще создана как инструментальная среда для разработки пользователем потоков задач конструкторского и технологического проектирования в машиностроении с последующим возможным оформлением потоков в виде пользовательских версий САПР. Сконструированный поток поддерживается компонентами системы, в число которых входят графические 2D и 3D подсистемы, СУБД, продукционная экспертная система, документатор, технологический процессор создания программ для станков с ЧПУ, постпроцессоры.
Тенденция к созданию интегрируемых производственных систем привела к развитию технологии CALS. Одной из развитых реализаций CALS-технологии является концепция EPD (Electronic Product Definition) фирмы Computervision. В соответствии с ней следующие компоненты должны входить в CALS-систему [14]:
· комплекс прикладных программ автоматизированного проектирования (проектирующие подсистемы САПР), включая программы для конструирования изделий и инженерного анализа проектных решений;
· подсистема автоматизации технологической подготовки производства;
· средства управления процессом проектирования;
· средства управления данными;
· средства визуализации и разработки документации;
· CASE-подсистема;
· языковые средства межпрограммных обменов;
· методики анализа проектно-технологической, производственной и управленческой деятельности предприятия.
Как видно из названий подсистем этого перечня, функции и состав системных сред CALS и входящих в них САПР в значительной мере совпадают.
Да, сложный процесс Так почитаешь и прямо руки опускаются сколько всего надо учесть при проектировании информационных систем
ОтветитьУдалить