|
|
|
содержание .. 39 40 41 42 ..
%
*#$A&,& +($*,#&($"!)&P !"#$%!#&’&($"!))KH :&:#*%
5
@!"!
6
тов
и
процессов
вместе
с
их
взаимосвязя
-
ми
.
Для
этого
применяют
символические
обозначения
(
дескрипторы
)
объектов
,
их
ассоциаций
,
ситуаций
и
схемный
язык
описания
отношений
(
классификации
,
часть
-
целое
,
перехода
и
т
.
п
.),
составляют
словарь
дескрипторов
.
В
методике
имеются
правила
связыва
-
ния
объектов
(
термов
)
в
правильные
предложения
,
языковые
механизмы
для
установления
соответст
-
вия
между
объектами
реального
мира
и
их
идентификаторами
(
дескрипторами
).
В
IDEF5
имеются
две
части
:
1
)
схемный
язык
; 2)
язык
разработки
(elaboration).
Основные
сим
-
волы
схемного
языка
представлены
на
рис
. 6.
1
3,
пример
классификационной
схемы
—
на
рис
. 6.
1
4
и
пример
диаграммы
перехода
состояний
с
символикой
IDEF5 —
на
рис
. 6.
1
5.
Развитие
методик
реинжиниринга
(BPR Business Process Reenginiring)
продолжается
в
США
по
программе
IICE
(Information Integration for Concurrent Engineering).
Разработаны
,
но
пока
(
1
998
г
.)
не
получили
официального
статуса
от
органов
стандартизации
методики
,
имеющие
индексы
IDEF6, 8, 9,
1
4,
разрабатываются
методики
IDEF7,
1
0,
1
2.
IDEF6 (Design Rationale Capture)
направлена
на
получение
и
представление
решений
по
выбору
стратегии
проекти
-
рования
и
обоснованию
предпринятых
шагов
.
В
отличие
от
других
методик
IDEF,
в
которых
фиксируются
результаты
про
-
ектирования
,
в
IDEF6
главный
упор
сделан
на
пути
получения
этих
результатов
и
обоснование
промежуточных
решений
.
Такой
подход
особенно
важен
при
разработке
сложных
систем
в
недостаточно
определенных
ситуациях
.
Фиксация
шагов
и
обоснований
помогает
при
дальнейших
модернизациях
систем
,
сохранению
и
использованию
рационального
опыта
про
-
ектирования
.
Методика
упорядочивает
обнаружение
и
устранение
неопределенностей
,
ошибок
,
неудовлетворенных
огра
-
ничений
.
Язык
методики
включает
предложения
,
связывающие
компоненты
проекта
с
пунктами
обоснования
.
Под
компо
-
нентами
проекта
обычно
подразумевают
компоненты
,
отражаемые
на
диаграммах
IDEF0-5,
например
,
стрелки
ICOM
из
IDEF0,
сущности
,
атрибуты
,
отношения
из
IDEF
1
X,
объекты
,
сообщения
,
события
из
IDEF4
и
т
.
п
.
В
качестве
пунктов
обоснования
могут
фигурировать
стандарты
,
экспериментальные
данные
,
ограничения
и
т
.
п
.
IDEF8 (Human-System Interaction Design)
предназначена
для
проектирования
взаимодействия
человека
с
техничес
-
кой
системой
.
Эта
методика
не
является
методикой
создания
графического
пользовательского
интерфейса
и
потому
обыч
-
но
дополняется
некоторой
системой
GUI (Graphic User Interface).
Здесь
определяется
содержание
(
на
абстрактном
уровне
)
той
части
работы
,
которую
выполняет
человек
.
Создаваемые
сценарии
должны
удовлетворять
ряду
оговоренных
в
мето
-
дике
принципов
таких
,
как
уменьшение
нагрузки
на
человека
,
идентичность
средств
диалога
в
разных
системах
,
наличие
обратной
связи
для
исправления
ошибок
,
хранение
истории
диалога
,
помощь
советами
по
выполнению
действий
и
т
.
д
.
IDEF9 (Business Constraint Discovery)
нацелена
на
выявление
разнообразных
ограничений
(
технических
,
физичес
-
ких
,
юридических
,
политических
,
организационных
),
которые
должны
быть
учтены
при
разработке
системы
,
и
для
анали
-
за
их
влияния
на
принимаемые
решения
в
процессе
реинжиниринга
.
Обычно
в
качестве
систем
фигурируют
сложные
ин
-
формационные
системы
с
ориентацией
на
экономические
и
управленческие
приложения
.
Ограничение
—
это
отношение
,
&
.
+
.
)
"#$%!#&’&($"!))$* +($*,#&($"!)&*
163
%+,
. 6.
)
2.
IDEF4-
диаграмма
клиентов
%+,
. 6.
)
3.
Символы
графического
языка
IDEF5
%+,
. 6.
)
4.
Диаграмма
классификации
%+,
. 6.
)
5.
Диаграмма
перехода
состояний
в
IDEF5
%
*#$A&,& +($*,#&($"!)&P !"#$%!#&’&($"!))KH :&:#*%
5
@!"!
6
которое
должно
соблюдаться
.
Ограничения
делятся
на
контексты
(
группы
родственных
ограничений
).
Применение
IDEF9
заключается
в
выполнении
нескольких
шагов
:
1
)
сбор
свидетельств
(
фактов
,
указывающих
на
наличие
ограничения
); 2)
классификация
—
определение
контекстов
,
объектов
,
отношений
; 3)
прогнозирование
—
выявление
ограничений
на
ос
-
нове
свидетельств
; 4)
отбор
значимых
ограничений
; 5)
определение
экспертов
для
тестирования
результатов
; 6)
детализа
-
ция
и
фильтрация
ограничений
.
В
методике
даны
рекомендации
по
выполнению
этих
шагов
.
Предлагается
графический
язык
,
элементами
которого
являются
система
,
блоки
ограничений
,
контексты
,
линии
связи
,
логические
связки
OR, AND,
XOR (
исключающее
ИЛИ
).
IDEF
1
4 (Network Design)
предназначена
для
проектирования
корпоративных
вычислительных
сетей
,
их
представ
-
ления
на
графическом
языке
с
описанием
конфигураций
,
очередей
,
сетевых
компонентов
,
требований
к
надежности
и
т
.
п
.
Чаще
всего
методика
применяется
для
модернизации
уже
существующих
сетей
.
Поэтому
в
ней
предусматривается
разра
-
ботка
моделей
как
“AS IS”,
так
и
“TO BE”.
Проектирование
включает
в
себя
определение
топологии
сети
или
схемы
ком
-
муникаций
,
реализацию
нужного
качества
обслуживания
,
анализ
функционирования
(
трафик
,
дисциплины
обслуживания
в
узлах
,
протоколы
доступа
).
Модель
топологии
дополняется
моделями
очередей
,
надежности
,
материальных
затрат
.
Важ
-
ную
роль
играет
библиотека
методов
построения
и
компонентов
сетей
.
Методика
основана
на
выполнении
ряда
шагов
:
ус
-
тановление
целей
модернизации
,
исследование
существующей
сети
,
определение
типов
компонентов
в
ней
,
построение
модели
“AS IS”,
ее
верификация
,
анализ
результатов
,
корректировка
с
переходом
к
“TO BE”.
В
графическом
языке
IDEF
1
4
сети
и
подсети
изображаются
в
виде
облаков
,
топологические
связи
представляются
линиями
,
для
узлов
используются
специальные
иконки
,
возможны
поясняющие
надписи
,
список
характеристик
размещается
в
прямоугольниках
.
P
0+H+=+84
9:0012
>?17
/
4
5.D+84
9:0+>
UML.
Язык
UML
положен
в
основу
Rational Unified
Process (RUP) —
известной
методологии
проектирования
информационных
систем
,
развиваемой
фир
-
мой
Rational Software.
В
UML
также
используется
ряд
диаграмм
.
К
основным
следует
отнести
прежде
всего
диаграммы
классов
.
Они
имеют
следующие
отличия
от
аналогичных
диаграмм
в
IDEF4.
Во
-
первых
,
в
прямоугольнике
класса
имеются
три
секции
,
в
верхней
секции
записывается
имя
класса
,
в
средней
секции
—
атрибуты
,
в
нижней
части
—
процедуры
класса
.
При
записи
атрибутов
указываются
символ
доступности
(+ — public, # — pr
о
tected, - - private),
идентификатор
атрибута
,
тип
атрибута
.
Запись
процедуры
аналогична
подобным
записям
в
языках
программирования
:
указывают
-
ся
имя
процедуры
и
в
скобках
—
список
параметров
.
Во
-
вторых
,
в
диаграммах
классов
UML
отображение
отношений
часть
-
целое
(
отношений
агре
-
гации
)
выполняется
с
помощью
линий
с
ромбовидной
стрелкой
,
направленной
от
класса
-
части
к
клас
-
су
-
целому
,
и
отношений
наследования
(
суперкласс
-
подкласс
) —
с
помощью
линий
с
обычной
стрел
-
кой
,
направленной
от
подкласса
к
суперклассу
.
Поведенческий
аспект
моделирования
отражен
в
диаграммах
процессов
,
имеющихся
в
UML.
Они
бывают
двух
типов
—
диаграммы
сценариев
(
ДС
)
и
диаграммы
взаимодействия
объектов
(
ДВО
).
Сценарий
—
это
последовательность
событий
,
заключающихся
в
воздействиях
(
посылках
сооб
-
щений
)
одного
объекта
на
некоторый
другой
объект
.
В
ДС
объекты
изображаются
прямоугольниками
и
располагаются
в
горизонтальном
ряду
объектов
.
Ось
времени
направлена
от
этого
ряда
вертикаль
-
но
вниз
.
От
каждого
объекта
параллельно
оси
времени
идут
так
называемые
их
линии
жизни
(lifelines).
Каждое
событие
изобра
-
жается
горизонтальной
линией
со
стрелкой
от
линии
жизни
объ
-
екта
,
посылающего
сообщение
,
к
линии
жизни
объекта
,
прини
-
мающего
сообщение
.
Над
этими
линиями
возможен
поясняющий
текст
.
Линии
располагаются
одна
над
другой
в
порядке
,
в
кото
-
ром
события
совершаются
(
пример
ДС
на
рис
. 6.
1
6).
Диаграмма
ДВО
представляет
собой
граф
,
в
котором
вер
-
шины
соответствуют
объектам
,
а
ребра
—
воздействиям
.
Около
ребер
возможны
поясняющие
записи
,
в
частности
,
последова
-
тельные
номера
,
указывающие
порядок
совершения
событий
.
К
числу
других
диаграмм
относятся
диаграммы
использо
-
вания
,
цель
которых
—
отобразить
взаимодействие
системы
с
пользователем
.
В
этих
диаграммах
ото
-
бражены
в
виде
овалов
те
функции
,
которые
непосредственно
должен
(
или
может
)
выполнять
пользо
-
ватель
.
При
этом
пользователи
различаются
ролями
,
выполняемыми
ими
при
эксплуатации
системы
.
Проектирование
информационной
системы
в
RUP
начинается
с
построения
диаграмм
использо
-
вания
.
При
этом
определяется
и
согласовывается
внешняя
функциональность
системы
и
в
итоге
фор
-
&
.
+
.
)
"#$%!#&’&($"!))$* +($*,#&($"!)&*
164
%+,
. 6.
)
6.
Вид
диаграммы
сценариев
%
*#$A&,& +($*,#&($"!)&P !"#$%!#&’&($"!))KH :&:#*%
5
@!"!
6
мируется
техническое
задание
на
разработку
ПО
.
Далее
разрабатываются
диаграммы
взаимодействия
“
пользователь
-
система
”,
при
этом
выявляются
необходимые
объекты
,
строятся
диаграммы
классов
,
формируется
компонентная
структура
ПО
.
"84@8://04.
4B
.
,3.
A.0+.
CASE-
,+,-./
5D>
7
40=.3-
<
:
DF04@
4
384.7-+84
9:0+>
.
На
рынке
программных
продуктов
имеется
много
CASE-
систем
для
концептуального
проектирования
АС
.
Чаще
всего
в
них
поддерживается
методология
IDEF.
В
России
широко
известны
программы
BPwin, ERwin, OOwin
фирмы
Platinum Technology, Design/IDEF
фирмы
Meta Software, CASE-
Аналитик
фирмы
Эйтэкс
, Silverrun
фирмы
CSA
и
др
.
B
Р
win (Business Processing)
предназначена
для
разработки
функциональных
моделей
по
методике
IDEF0.
ERwin
предназначена
для
разработки
информационных
моделей
по
методике
IDEF
1
|