Норенков И.П. Основы автоматизированного проектирования

Подождите немного. Документ загружается.

5.5.

Инструментальные

средства

концептуального

проектирования

Создание

модели.

Используется нисходящий стиль: сначала разрабаты-

ваются верхние уровни, затем

—

нижние.

Рецензирование модели. Реализуется

итерационной процедуре рассыл-

ки

модели

на

отзыв

и ее

доработки

по

замечаниям рецензентов,

завершение

собирается согласительное совещание.

Связи

функциональной модели, отражающей функции,

со

структурной

мо-

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

помощью

специальных словарей, дающих однозначное толкование вводимых имен

ре-

сурсов.

Методики

Техническое

предложение

САПР

Консалтинговая

фирма

Отдел

САПР

Техническое

предложение

Определить

информационные

Отдел

САПР

Информационные

потоки

—

Консалтинговая

фирма

Рис. 5.6.

Функциональная

модель

процесса

создания

САПР

(начало):

ШЕРО-диаграмма

первого уровня;

б -

IDEFO-диаграмма

обследования предприятия;

ШЕРО-диаграмма

проектирования САПР;

г -

ШЕРО-диаграмма

реализации проекта САПР

253

Методическое

программное

обеспечение

автоматизированных

систем

Информационные

потоки

Техническое

предложение

Определить

типы

характеристики

ЭВМ

А23

Консалтинговая

САПР

Отдел

фирма

информационных САПР

систем

CASE

Проект

ТО

САПР

Опытная

версия

САПР

Отдел

САПР

Консалтинговая

фирма

АХО, Проектные

инженерные

подразделения

службы

Отдел

снабжения

Рис. 5.6. Функциональная

модель

процесса

создания

САПР

(окончание)

254

5.5.

Инструментальные средства концептуального проектирования

Выбрать

структуру

Г*

Изменить

структуру

Изменить

параметры

Перейти

следующей

процедуре

Рис. 5.7.

ШЕРЗ-диаграмма

последовательности

операций

Дальнейшее использование

IDEFO-модели

конкретизация задач выбора

ресурсов, разработка планов реализации, переход

имитационным моделям

т. п.

Поведенческие аспекты приложений отражает методика

IDEF3.

Если

ме-

тодика

IDEFO

связана

функциональными аспектами

позволяет отвечать

на

вопросы «Что делает

система?»,

то в

IDEF3

детализируются

конкретизиру-

ются

IDEFO-функции,

ГОЕРЗ-модель

отвечает

на

вопросы «Как система

это

делает?»

Язык

IDEF3

—

язык диаграмм, помогающий разработчику моделей

наглядно

представить моделируемые процессы.

IDEF3

входят

два

типа опи-

саний:

процессно-ориентированные

виде последовательности операций;

объектно-ориентированные, выражаемые диаграммами перехода состояний,

характерными

для

конечно-автоматных моделей.

На

рис.

5.7

представлен пример

процессно-ориентированной

ШЕРЗ-диаг-

раммы.

Здесь функции (операции) показаны прямоугольниками

горизонталь-

ной

чертой,

отделяющей верхнюю секцию

названием функции

от

нижней сек-

ции, содержащей номер функции. Связи, отражающие последовательность

выполнения функций, изображаются сплошными линиями-стрелками.

Для

ука-

зания

разветвлений

слияний связей

(их

принято называть перекрестками)

ис-

пользуют квадраты,

которых одна

или обе

вертикальные стороны представ-

лены двойными линиями,

внутри квадрата записан один

из

символов

«&»,

«О» или

«X».

При

разветвлении

эти

символы означают реакцию всех, некото-

рых или

только одной

из

последующих функций

на

входное воздействие соот-

ветственно. Аналогичный смысл имеют символы

«&»,

«О» или «X» при

слия-

нии

последующая функция начинает выполняться после окончания всех,

некоторых

или

только одной

из

входных операций.

На

рис.

5.8

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

ШЕРЗ-диаграм-

мы.

таких диаграммах имеются средства

для

изображения состояний сис-

темы, активностей, переходов

из

состояния

состояние

условий перехода.

255

Методическое

программное

обеспечение

автоматизированных

систем

Проектирование Изготовление

Рис. 5.8.

ГОЕРЗ-диаграмма

перехода

состояний

Диаграммы

IDEFO

или

IDEF3 могут быть преобразованы

имитационные

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

за-

граты

ресурсов. Чаще всего имитационные модели представляют

виде

се-

тей

Петри. Преобразование связано

введением времени

функциональную

ГОЕРО

или

поведенческую

ГОЕРЗ-модель

заменой

функций

переходами,

объек-

тов, отождествляемых

со

стрелками блоков ICOM, метками

сетях Петри.

Методика

IDEF1X

IDEF1

-методика

информационного

(мифологического)

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

ложений,

настоящее время применяется

ее

усовершенствованный вариант

IDEF1X,

котором имеется ясный графический

язык

для

описания объектов

отношений

приложениях.

Это

язык

диаграмм

сущность

связь.

Основные

компоненты описаний

IDEF1X:

сущности (блоки), отношения

(связи),

атрибуты.

Сущность

множество

объектов,

обладающих общими

свойствами

(в

язы-

ках

программирования понятие сущности совпадает

понятием типа).

Конк-

ретные элементы этого множества называют экземплярами

сущности.

Ат-

рибуты характеризуют свойства сущностей,

их

значения однозначно иденти-

фицируют экземпляры сущностей. Если сущность

может быть определена

только

помощью ссылки

на

свойства некоторой другой сущности

В, то А

называется

зависимой (дочерней) сущностью,

а В

выступает

роли родитель-

ской

сущности.

Сущности

IDEFlX-диаграммах

изображаются

виде прямоугольников,

при

этом

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

ленными.

Отношения

(связи) между сущностями

IDEF1X

являются бинарными

отношениями.

Выделяют идентифицирующие отношения

связи типа роди-

тель

потомок,

которых потомок (зависимая сущность) однозначно опреде-

ляется

своей связью

родителем,

неидентифицирующие отношения, означа-

ющие,

что у

связанного этим отношением

экземпляра

одной сущности может

быть,

может

и не

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

(при-

256

5.5.

Инструментальные средства концептуального проектирования

мер

идентифицирующего отношения

изготовитель

товар, неидентифициру-

ющего отношения

рабочая станция

дигитайзер). Идентифицирующее отно-

шение

изображают

на

диаграмме сплошной линией между прямоугольниками

связанных сущностей, неидентифицирующее отношение показывают пунктир-

ной

линией.

На

дочернем конце линии должно быть утолщение (жирная точка).

Мощность

связи

—

число экземпляров зависимой сущности,

соответствую-

щее

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

ти

может быть указано около утолщенного

конца

линии связи.

При

этом сим-

вол

означает

символу

соответствует

k =

или

Отсутствие

символа

интерпретируется

как k

Различают также специфические

неспецифические отношения. Неспеци-

фические отношения

- это

связи типа «многие

ко

многим»

обозначаются

сплошной

линией

утолщениями

на

обоих концах.

отношениях родитель

потомок возможно наличие

потомка единственно-

го

родителя (характеристическая связь)

или

нескольких родителей (ассоциа-

тивная

связь). Выделяют также отношения категоризации (наследования),

от-

ражающие связи между некоторой общей сущностью

вариантами

ее

реализации

(категориями). Примером категориальной связи является отноше-

ние

тип

прибора

—

альтернативные варианты этого прибора.

Среди

атрибутов различают ключевые

неключевые. Значение

ключевого

атрибута

(ключа)

однозначно идентифицирует экземпляр сущности.

Внешний

ключ

- это

атрибут (или атрибуты), входящий

ключ родителя

наследуемый

потомком.

На

IDEFIX-диаграммах

ключи записывают

верхней части прямо-

угольника сущности, причем внешние

ключи

помечают меткой

(Foreign Key),

неключевые

атрибуты

помещают

нижнюю часть

прямоугольников.

иден-

тифицирующих отношениях

все

ключи родителя входят

и в

ключи потомка,

неидентифицирующих

ключи родителя относятся

неключевым атрибутам

потомка.

Нормальные

формы отношений позволяют выявить атрибуты, которые

це-

лесообразно

(с

целью устранения избыточности) считать сущностями. Извес-

тно

несколько

нормальных форм, обычно используют первые

три из

них.

Первая

нормальная форма требует, чтобы шапка таблицы (отношения) была

одноэтажная

(т. е. все

атрибуты характеризуются атомарными значениями),

строки-дубли должны быть устранены.

Вторая нормальная форма устанавливается

для

сущностей, удовлетворяю-

щих

условиям первой нормальной формы

имеющих составные ключи.

Она

определяется отсутствием атрибутов, зависящих только

от

части составного

ключа.

Подобные атрибуты должны быть выделены

отдельные сущности.

Третья нормальная форма дополнительно характеризуется

отсутствием

транзитивных

связей

(взаимозависимости) атрибутов.

Разработка информационной модели

по

IDEF1X

выполняется

за

несколько

стадий.

Стадия

Выяснение цели проекта, составление плана сбора информации.

Обычно отправным пунктом

для

разработки информационной

модели

являет-

ся

IDEFO-модель.

Основы автоматизированного

257

проектирования

Методическое

программное обеспечение автоматизированных систем

Независимая

Зависимая

Запись

сущность-

сущность атрибутов

-Атрибуты

первого

ключа

-Остальные

атрибуты

Отношение

категоризации

Общая

сущность

Дискриминатор

Тип

связи

Неидентифи-

цирующее

От

родителя

отношение

любая

I 0 или 1 I >=1

мощ-

|||

потомку

Категории

Рис. 5.9.

Элементы

языка

IDEF1X

Стадия

Выявление

определение сущностей.

Это

неформальная проце-

дура.

Стадия

Выявление

определение основных отношений. Результат пред-

ставляется

или

графически

виде

ER-диаграмм

или в

виде матрицы отноше-

ний, элемент которой

= \,

если имеется связь между сущностями

иу,

иначе

= 0.

Транзитивные связи

не

указываются.

Стадия

Детализация неспецифических отношений, определение ключевых

атрибутов, установление внешних ключей. Детализация неспецифических

отношений заключается

замене связей «многие

ко

многим»

(М

<-»

М) на

связи

«М<->

1» и «1 о М»

введением сущности-посредника. Например,

отношение преподаватель

студенческая группа может быть заменено

на

отношения

этих сущностей

сущностью-посредником «расписание».

Стадия

Определение атрибутов

и их

принадлежности сущностям.

Основные элементы графического языка

IDEF1X

представлены

на

рис. 5.9.

Между

IDEFO-

IDEFlX-моделями

одного

того

же

приложения суще-

ствуют определенные связи. Так, стрелкам

на

IDEFO-диаграммах

соответству-

ют

атрибуты некоторых сущностей

IDEFlX-моделях,

что

нужно учитывать

при

построении информационных моделей.

Унифицированный

язык

моделирования

UML

Язык

объектного моделирования

UML

положен

основу Rational Unified

Process

(RUP)

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

си-

стем, развиваемой фирмой Rational Software.

языке

UML

также использует-

ся

ряд

диаграмм.

основным

следует

отнести прежде всего диаграммы классов. Каждый

класс

изображается

виде прямоугольника,

котором может быть выделено

до

трех секций.

верхней секции записывается

имя

класса,

средней секции

атрибуты,

нижней

процедуры класса.

При

записи атрибутов можно указать

258

5.5. Инструментальные средства концептуального проектирования

Геометрия

Размеры

Сборочный

узел

Деталь

Параметры

Материал

Марка

Рис. 5.10.

Фрагмент

диаграммы

классов

символ доступности

(«

public,«

protected,«

—

private),

идентифи-

катор

атрибута,

тип

атрибута. Запись процедуры аналогична подобным запи-

сям

языках программирования: указываются

имя

процедуры

и в

скобках

список

параметров.

диаграммах классов языка

UML

отношения ассоциации отображаются

линиями,

частности, отображение отношения часть

целое (отношения агре-

гации)

выполняется

помощью линии

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

от

класса-части

классу-целому,

отображение отношения наследования (су-

перкласс

подкласс)

- с

помощью линии

обычной стрелкой, направленной

от

подкласса

суперклассу. Пример диаграммы классов

дан на

рис. 5.10.

Поведенческий аспект моделирования отражен

диаграммах взаимодей-

ствия, имеющихся

языке

UML.

Они

бывают

двух

типов

диаграммы сцена-

риев (ДС)

диаграммы кооперации

(ДК).

Сценарий

- это

последовательность событий, заключающихся

воздей-

ствиях (посылках сообщений) одного объекта

на

некоторый другой объект.

ДС

объекты изображаются прямоугольниками

располагаются

горизонталь-

ном

ряду объектов.

Ось

времени направлена

от

этого ряда вертикально вниз.

От

каждого объекта параллельно

оси

времени идут

так

называемые

их

линии

жизни

(lifelines). Каждое событие изображается горизонтальной линией

со

стрел-

кой

от

линии жизни объекта, посылающего сообщение,

линии жизни объекта,

принимающего сообщение.

Над

этими линиями возможен поясняющий текст.

Линии располагаются одна

над

другой

порядке,

котором события соверша-

ются (пример

ДС см. на

рис.

5.11).

Диаграмма

ДК

представляет собой граф,

котором вершины

соответству-

ют

объектам,

ребра

воздействиям. Около ребер возможны поясняющие

записи,

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

шения

событий.

259

Методическое

программное

обеспечение

автоматизированных

систем

числу

других

диаграмм относятся

ди-

аграммы использования, цель которых

ото-

бразить взаимодействие системы

пользо-

вателем.

этих диаграммах отображены

виде овалов

те

функции, которые непосред-

ственно должен (или может) выполнять

пользователь. Пользователи различаются

ролями, выполняемыми

ими при

эксплуата-

ции

системы.

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

информационной системы

RUP

начинается

построения диаграмм

ис-

пользования.

При

этом определяется

согла-

Рис.

5.11.

Вид

диаграммы

совывается

внешняя

функциональность

систе-

сценариев

мы

тоге

формируется

ТЗ

на

разработку

ПО.

Далее разрабатываются диаграммы взаимодействия пользователь

систе-

ма,

выявляются необходимые объекты, строятся диаграммы классов, форми-

руется

компонентная

структура

ПО.

Программное

обеспечение

CASE-систем

для

концептуального

проектирования

На

рынке программных продуктов имеется много CASE-систем

для

кон-

цептуального проектирования

АС.

Чаще всего

в них

поддерживается методология IDEF.

России широко известны про-

граммы BPwin, ERwin,

OOwin

фирмы Platinum Technology,

Design/IDEF

фирмы Meta

Software,

CASE

—

Аналитик фирмы Эйтэкс,

Silverrun

фирмы

CSA и др.

BPwin

(Business

Processing) служит

для

разработки функциональных моделей

по

методике

IDEFO.

ERwin предназначена

для

разработки информационных моделей

по

методике

IDEF

1X.

Имеются средства, обеспечивающие интерфейс

серверами

баз

данных

(от

пользовате-

ля

скрыто общение

на

SQL-языке), перевод графических изображений

ER-диаграмм

SQL-формы

или

форматы

других

популярных СУБД. Предусмотрены интерактивные

процедуры

для

связывания

дуг

IDEFO

сущностями

атрибутами

IDEF

IX,

т. е. для

установления связей между

BPwin

ERwin.

систему включены также типичные

для

CASE

средства разработки экранных форм.

OOwin служит

для

поддержки объектно-ориентированных технологий проектирова-

ния

информационных систем. Один

из

способов использования OOwin

детализация

объектно-ориентированной модели

на

базе созданной ER-модели.

При

преобразовании

ER в

ОО-представление сущности

атрибуты становятся классами (множествами

по-

добных объектов). Классы могут быть дополнены описанием услуг класса,

т. е.

выполня-

емых операций, передаваемых

возвращаемых параметров, событий. Другой способ

использования

OOwin

реинжиниринг,

так как

модернизация проводится

на

уровне

существующей модели.

Система

Design/IDEF

(фирма Meta Software) предназначена

для

концептуального про-

ектирования

сложных систем.

С ее

помощью разрабатываются спецификации,

IDEFO-

IDEF

IX-диаграммы,

словари данных, проводится документирование

проверяется

не-

противоречивость проектов. Имеется дополнительная система Design/CPN, позволяю-

щая

проводить имитационное моделирование

на

основе моделей, преобразованных

цветные сети Петри.

260

5 5

Инструментальные

средства

концептуального

проектирования

Другой известной инструментальной средой моделирования приложений является

Designer/2000 фирмы Oracle. Модель приложения может быть сгенерирована

по

отве-

там

пользователя

на

вопросы системы. Используются собственные методики

Oracle,

позволяющие

строить диаграммы потоков данных, сущность

—

отношение, иерархичес-

кие

деревья данных

возможностью

их

представления

в SQL

формах,

и,

следовательно,

поддерживается связь

любыми СУБД, работающими

ODBC.

Система

Silver-run

(фирма Computer

Systems

Advisors) предназначена

для

анализа

проектирования

информационных систем. Реализовано раздельное функциональное

информационное моделирование. Система включает

себя четыре основные подсисте-

мы:

моделирование бизнес-процессов, построение моделей сущность

отношение,

инфологическое

проектирование реляционных

баз

данных, управление групповой

ра-

ботой. Имеется интерфейс

Oracle, Informix,

Sybase

ряду других

СУБД.

Среди отечественных систем выделяется

CASE

Аналитик,

которой выполняется

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

тов и др.

Имеется интерфейс

ERwin.

Методология объектно-ориентированного анализа

проектирования

ПО по

методи-

ке

Г.

Буча

использованием языка

UML

реализована

системах Rational

Rose

(фирма

Rational

Software Corporation)

Platinum Paradigm Plus (фирма Platinum Technology).

Rational

Rose

поддерживается генерация кода

по

построенным диаграммам классов,

обратное моделирование

(т. е.

построение

UML-модели

по

программному коду

на

таких

языках,

как

C++,

Java,

Visual

Basic,

IDL

CORBA), визуальное программирование. Язык

UML

применяют

ряде других систем, например

инструментальной

среде

объектно-

ориентированного проектирования

ПО

objectiF (фирма micro

TOOL),

которой автома-

тически генерируется программный

код по

графическому

UML-описанию.

Ряд

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

IDEF-модели,

разработаны фирмой

KBSI,

частности,

ProSim реализует

IDEF3,

SmartER

IDEF1

IDEF1X,

SmartClass

IDEF4.

Поведенческое моделирование предприятий предусмотрено также

некоторых сис-

темах реинжиниринга, например

системе

BAANIV.

Для

преобразования функциональных

или

поведенческих моделей

имитационные

применяют специальные программы. Так, вместе

программой

BPWin

для

получения

имитационных моделей используют программу

BPSimulator.

Преобразование

IDEFO-

модель

сеть Петри реализовано

таких программах,

как

CPN/Design

(фирма Meta

Software)

со

специальным языком программирования

ML,

ProTem (Software Consultants

International

Limited)

вариацией типов меток, РАСЕ (Grossenbacher software)

про-

граммированием

на

языке Smalltalk.

Среды быстрой разработки приложений

CASE-системы

часто отождествляют

инструментальными средами раз-

работки

ПО,

называемыми средами быстрой разработки приложений

(RAD

—

Rapid Application

Development).

Примерами

широко

известных инструмен-

тальных

сред

RAD

являются

Visual

Basic, Delphi, PowerBuilder

фирм

Microsoft,

Borland,

PowerSoft

соответственно. Применение инструментальных сред

су-

щественно

сокращает

объем ручной работы

программистов,

особенно

при

про-

ектировании

интерактивных частей программ.

Большое

практическое значение имеют инструментальные среды

для

раз-

работки

прикладных

программ,

предназначенных

для

работы

под

управлением

операционных

систем Windows,

связи

широкой

распространенностью

по-

следних.

Простейшая

система

для

написания Windows-программ

на

языке

C++,

позволяющая

сократить объем кода, создаваемого пользователем вручную,

261

Методическое

программное обеспечение автоматизированных систем

основана

на

библиотеке

DLL

(Dynamic Link Library), которая содержит

мо-

дули, реализующие функции

API для

связи прикладных программ

с ОС

Windows.

Эта

система получила развитие

в MFC

(Microsoft

Foundation

Classes),

пред-

ставляющей собой библиотеку классов

для

автоматического создания карка-

сов

ПО

многоуровневых приложений.

библиотеке имеются

средства

для

поддержки оконного интерфейса, работы

файлами

и др.

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

программирования, называемый

управлением

событиями.

При

этом

дости-

гается автоматическое создание каркасов программ, существенно сокраща-

ется объем ручного кодирования.

этих средах пользователь может работать

одновременно

несколькими экранами (окнами). Типичными являются

окна

из

следующего списка.

Окно меню

пунктами «file»,

«edit»,

«window»

т.

п.,

реализующими фун-

кции,

очевидные

из

названия пунктов.

Окно формы,

на

котором собственно

создается прототип экрана буду-

щей

прикладной программы.

Палитра инструментов

набор изображений объектов пользовательско-

го

интерфейса,

из

которых можно компоновать содержимое окна формы.

Окно свойств

событий,

помощью которого ставятся

соответствие

друг

другу

объекты окна формы, события

обработчики событий.

Событием

прикладной программе является нажатие клавиши

или

установка курсора

мыши

объект формы. Каждому событию должна соответствовать событий-

ная

процедура (обработчик события), которая проверяет

код

клавиши

вызы-

вает нужную реакцию.

RAD

имеются средства

для

удобства разработки

обработчиков событий.

Окно редактора кода,

котором пользователь записывает создаваемую

вручную часть кода.

Окно проекта

список модулей

форм

создаваемой программе.

Для

написания событийных процедур

Visual

Basic

используется одноимен-

ный

язык

текстовый редактор этого языка,

Delphi

язык

редактор языка

Object

Pascal.

CASE-системе фирмы IBM, включающей части

VisualAge

(для

клиентских

приложений)

VisualGen

(для серверных приложений), базовым язы-

ком

выбран SmallTalk.

среде разработки приложений клиент

—

сервер

SQLWindows

оригинальные фрагменты программ пишутся

на

специальном языке

SAL. Нужно заметить,

что для

реализации вычислительных процедур

и, в

час-

тности,

для

написания мини-спецификаций используется обычная

для

3GL

тех-

нология

программирования.

Обычно после написания прикладной программы

на

базовом языке компи-

лятор

системы переводит программу

на

промежуточный

jo-код.

Вместе

с ин-

терпретатором

/?-кода

эта

программа рассматривается

как

ЕХЕ-файл.

неко-

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

не

требующий

интерпретации

для

своего исполнения.

262