Автоматизированное проектирование. Норенков И.П. - 164 стр.

UptoLike

Составители: 

%*#$A&,& +($*,#&($"!)&P !"#$%!#&'&($"!))KH :&:#*%5@!"! 6
которое должно соблюдаться. Ограничения делятся на контексты (группы родственных ограничений). Применение IDEF9
заключается в выполнении нескольких шагов: 1) сбор свидетельств (фактов, указывающих на наличие ограничения); 2)
классификацияопределение контекстов, объектов, отношений; 3) прогнозированиевыявление ограничений на ос-
нове свидетельств; 4) отбор значимых ограничений; 5) определение экспертов для тестирования результатов; 6) детализа-
ция и фильтрация ограничений. В методике даны рекомендации по выполнению этих шагов. Предлагается графический
язык, элементами которого являются система, блоки ограничений, контексты, линии связи, логические связки OR, AND,
XOR (исключающее ИЛИ).
IDEF14 (Network Design) предназначена для проектирования корпоративных вычислительных сетей, их представ-
ления на графическом языке с описанием конфигураций, очередей, сетевых компонентов, требований к надежности и т.п.
Чаще всего методика применяется для модернизации уже существующих сетей. Поэтому в ней предусматривается разра-
ботка моделей как “AS IS”, так и “TO BE”. Проектирование включает в себя определение топологии сети или схемы ком-
муникаций, реализацию нужного качества обслуживания, анализ функционирования (трафик, дисциплины обслуживания
в узлах, протоколы доступа). Модель топологии дополняется моделями очередей, надежности, материальных затрат. Важ-
ную роль играет библиотека методов построения и компонентов сетей. Методика основана на выполнении ряда шагов: ус-
тановление целей модернизации, исследование существующей сети, определение типов компонентов в ней, построение
модели “AS IS”, ее верификация, анализ результатов, корректировка с переходом к “TO BE”. В графическом языке IDEF14
сети и подсети изображаются в виде облаков, топологические связи представляются линиями, для узлов используются
специальные иконки, возможны поясняющие надписи, список характеристик размещается в прямоугольниках.
P0+H+=+849:0012 >?17 /45.D+849:0+> UML. Язык UML положен в основу Rational Unified
Process (RUP) — известной методологии проектирования информационных систем, развиваемой фир-
мой Rational Software. В UML также используется ряд диаграмм.
К основным следует отнести прежде всег о диаграммы классов. Они имеют следующие отличия
от аналогичных диаграмм в IDEF4.
Во-первых, в прямоугольнике класса имеются три секции, в верхней секции записывается имя
класса, в средней секцииатрибуты, в нижней частипроцедуры класса. При записи атрибутов
указываются символ доступности (+ — public, # — prоtected, - - private), идентификатор атрибута, тип
атрибута. Запись процедуры аналогична подобным записям в языках программирования: указывают-
ся имя процедуры и в скобкахсписок параметров.
Во-вторых, в диаграммах классов UML отображение отношений часть-целое (отношений агре-
гации) выполняется с помощью линий с ромбовидной стрелкой, направленной от класса-части к клас-
су-целому, и отношений наследования (суперкласс-подкласс) — с помощью линий с обычной стрел-
кой, направленной от подкласса к суперклассу.
Поведенческий аспект моделирования отражен в диаграммах процессов, имеющихся в UML.
Они бывают двух типовдиаграммы сценариев (ДС) и диаграммы взаимодействия объектов (ДВО).
Сценарийэто последовательность событий, заключающихся в воздействиях (посылках сооб-
щений) одного объекта на некоторый другой объект. В ДС объекты изображаются прямоугольниками
и располагаются в горизонтальном ряду объектов. Ось времени направлена от этого ряда вертикаль-
но вниз. От каждого объекта параллельно оси времени идут так
называемые их линии жизни (lifelines). Каждое событие изобра-
жается горизонтальной линией со стрелкой от линии жизни объ-
екта, посылающего сообщение, к линии жизни объекта, прини-
мающего сообщение. Над этими линиями возможен поясняющий
текст. Линии располагаются одна над другой в порядке, в кото-
ром события совершаются (пример ДС на рис. 6.16).
Диаграмма ДВО представляет собой граф, в котором вер-
шины соответствуют объектам, а ребравоздействиям. Около
ребер возможны поясняющие записи, в частности, последова-
тельные номера, указывающие порядок совершения событий.
К числу других диаграмм относятся диаграммы использо-
вания, цель которыхотобразить взаимодействие системы с пользователем. В этих диаграммах ото-
бражены в виде овалов те функции, которые непосредственно должен (или может) выполнять пользо-
ватель. При этом пользователи различаются ролями, выполняемыми ими при эксплуатации системы.
Проектирование информационной системы в RUP начинает ся с построения диаграмм использо-
вания. При этом определяется и согласовывается внешняя функциональность системы и в итоге фор-
&.+.)$(*),$". !"#$%!#&'&($"!))$* +($*,#&($"!)&*
164
%+,. 6.)6. Вид диаграммы сценариев
 5@!"! 6                                      %*#$A&,&     +($*,#&($"!)&P !"#$%!#&'&($"!))KH :&:#*%

которое должно соблюдаться. Ограничения делятся на контексты (группы родственных ограничений). Применение IDEF9
заключается в выполнении нескольких шагов: 1) сбор свидетельств (фактов, указывающих на наличие ограничения); 2)
классификация — определение контекстов, объектов, отношений; 3) прогнозирование — выявление ограничений на ос-
нове свидетельств; 4) отбор значимых ограничений; 5) определение экспертов для тестирования результатов; 6) детализа-
ция и фильтрация ограничений. В методике даны рекомендации по выполнению этих шагов. Предлагается графический
язык, элементами которого являются система, блоки ограничений, контексты, линии связи, логические связки OR, AND,
XOR (исключающее ИЛИ).
       IDEF14 (Network Design) предназначена для проектирования корпоративных вычислительных сетей, их представ-
ления на графическом языке с описанием конфигураций, очередей, сетевых компонентов, требований к надежности и т.п.
Чаще всего методика применяется для модернизации уже существующих сетей. Поэтому в ней предусматривается разра-
ботка моделей как “AS IS”, так и “TO BE”. Проектирование включает в себя определение топологии сети или схемы ком-
муникаций, реализацию нужного качества обслуживания, анализ функционирования (трафик, дисциплины обслуживания
в узлах, протоколы доступа). Модель топологии дополняется моделями очередей, надежности, материальных затрат. Важ-
ную роль играет библиотека методов построения и компонентов сетей. Методика основана на выполнении ряда шагов: ус-
тановление целей модернизации, исследование существующей сети, определение типов компонентов в ней, построение
модели “AS IS”, ее верификация, анализ результатов, корректировка с переходом к “TO BE”. В графическом языке IDEF14
сети и подсети изображаются в виде облаков, топологические связи представляются линиями, для узлов используются
специальные иконки, возможны поясняющие надписи, список характеристик размещается в прямоугольниках.
      P0+H+=+849:0012 >?17 /45.D+849:0+> UML. Язык UML положен в основу Rational Unified
Process (RUP) — известной методологии проектирования информационных систем, развиваемой фир-
мой Rational Software. В UML также используется ряд диаграмм.
      К основным следует отнести прежде всего диаграммы классов. Они имеют следующие отличия
от аналогичных диаграмм в IDEF4.
      Во-первых, в прямоугольнике класса имеются три секции, в верхней секции записывается имя
класса, в средней секции — атрибуты, в нижней части — процедуры класса. При записи атрибутов
указываются символ доступности (+ — public, # — prоtected, - - private), идентификатор атрибута, тип
атрибута. Запись процедуры аналогична подобным записям в языках программирования: указывают-
ся имя процедуры и в скобках — список параметров.
      Во-вторых, в диаграммах классов UML отображение отношений часть-целое (отношений агре-
гации) выполняется с помощью линий с ромбовидной стрелкой, направленной от класса-части к клас-
су-целому, и отношений наследования (суперкласс-подкласс) — с помощью линий с обычной стрел-
кой, направленной от подкласса к суперклассу.
      Поведенческий аспект моделирования отражен в диаграммах процессов, имеющихся в UML.
Они бывают двух типов — диаграммы сценариев (ДС) и диаграммы взаимодействия объектов (ДВО).
      Сценарий — это последовательность событий, заключающихся в воздействиях (посылках сооб-
щений) одного объекта на некоторый другой объект. В ДС объекты изображаются прямоугольниками
и располагаются в горизонтальном ряду объектов. Ось времени направлена от этого ряда вертикаль-
но вниз. От каждого объекта параллельно оси времени идут так
называемые их линии жизни (lifelines). Каждое событие изобра-
жается горизонтальной линией со стрелкой от линии жизни объ-
екта, посылающего сообщение, к линии жизни объекта, прини-
мающего сообщение. Над этими линиями возможен поясняющий
текст. Линии располагаются одна над другой в порядке, в кото-
ром события совершаются (пример ДС на рис. 6.16).
      Диаграмма ДВО представляет собой граф, в котором вер-
шины соответствуют объектам, а ребра — воздействиям. Около
ребер возможны поясняющие записи, в частности, последова-
тельные номера, указывающие порядок совершения событий.
      К числу других диаграмм относятся диаграммы использо- %+,. 6.)6. Вид диаграммы сценариев
вания, цель которых — отобразить взаимодействие системы с пользователем. В этих диаграммах ото-
бражены в виде овалов те функции, которые непосредственно должен (или может) выполнять пользо-
ватель. При этом пользователи различаются ролями, выполняемыми ими при эксплуатации системы.
      Проектирование информационной системы в RUP начинается с построения диаграмм использо-
вания. При этом определяется и согласовывается внешняя функциональность системы и в итоге фор-

 &.+.)$(*),$" . !"#$%!#&'&($"!))$*                +($*,#&($"!)&*                                            164