 ПОЗНАВАТЕЛЬНОЕ Сила воли ведет к действию, а позитивные действия формируют позитивное отношение Как определить диапазон голоса - ваш вокал Игровые автоматы с быстрым выводом Как самому избавиться от обидчивости Противоречивые взгляды на качества, присущие мужчинам Вкуснейший "Салат из свеклы с чесноком" Натюрморт и его изобразительные возможности Применение, как принимать мумие? Мумие для волос, лица, при переломах, при кровотечении и т.д. Как научиться брать на себя ответственность Зачем нужны границы в отношениях с детьми? Световозвращающие элементы на детской одежде Как победить свой возраст? Восемь уникальных способов, которые помогут достичь долголетия Классификация ожирения по ИМТ (ВОЗ) Глава 3. Завет мужчины с женщиной
Оси и плоскости тела человека - Тело человека состоит из определенных топографических частей и участков, в которых расположены органы, мышцы, сосуды, нервы и т.д.
| Нумерация работ на диаграммах 12
Класс Класс в UML служит для обозначения множества объектов с одинаковой структурой, поведением и отношениями с объектами других классов. Графически класс изображается в виде прямоугольника, который может быть разделен на секции.
Даже если какая-то секция атрибутов или операций пустая, то ее оставляют в обозначении класса.
Имя класса Имя класса должно быть уникальным в пределах пакета, состоящего из нескольких диаграмм классов. Примерами имен классов могут быть такие существительные, как: "сотрудник", "компания", "руководитель", и так далее. Для обозначения имени абстрактного класса (не имеющего объектов) используется курсив. Чтобы показать к какому пакету относится класс используют в имени разделитель "::". Синтаксис имени в этом случае следующий: <имя пакета>::<имя класса> Например в пакете "Банк" класс "Счет" может быть представлен именем Банк::Счет. Атрибуты класса Атрибуты (свойства) класса записываются во второй секции прямоугольника класса. Каждому атрибуту класса соответствует строка текста вида: <квантор видимости ><имя атрибута>[кратность]:<тип атрибута>=<исходное значение>{строка-свойство} Квантор видимости может принимать одно из трех возможных значений: "+" (public), "#" (protected), "-" (private). Имя атрибута является единственным обязательным элементом рассматриваемой строки, идентифицирующим атрибут. Кратность атрибута характеризует общее количество атрибутов данного типа в классе. Примерами задания кратности могут быть: [0..1], [0..*], [1..3, 7..10], [1..3, 7..*]. Тип атрибута определяется языком спецификации соответствующей модели (иногда зависит от языка реализации). Примерами задания имен и типов атрибутов классов могут быть следующие: цвет: Color, имя_сотрудника: [1..2]:string форма:многоугольник. Исходное значение определяет начальное значение атрибута в момент создания отдельного экземпляра класса (объекта). Например, выше перечисленные атрибуты могут быть дополнены следующим образом: цвет:Color=(255,0,0) имя_сотрудника[1..2]:string=Иван Иванович форма:многоугольник=прямоугольник Операция Операция представляет собой некоторый сервис, представляемый экземпляром класса по определенному требованию. Совокупность операций характеризует функциональный аспект поведения класса. Запись каждой операции выполняется строкой вида: <квантор видимости><имя операции>(список параметров):<тип возвращаемого значения>{строка-свойство} Требующий пояснения (список параметров) является перечнем разделенным запятой формальных параметров, каждый из которых может быть описан в виде: <вид параметра><имя параметра><выражение типа>=<значение по умолчанию> Здесь вид параметра - одно из ключевых слов in, out или inout. Операция с областью действия на весь класс показывается подчеркиванием имени и строки выражения типа. Операция, которая не может изменять состояние системы, обозначается строкой-свойством. Пример: "{запрос}". Для указания параллельности выполнения операции используется строка-свойство вида: {"concurrency=имя"} где имя может принимать одно из следующих значений: -последовательная (sequential); -параллельная (concurrent); -охраняемая (guarded). В качестве примеров записи операций можно привести следующие: · + создать() · + нарисовать(форма:многоугольник=прямоугольник, цвет_заливки: Color=(0,0,255)) · выдать_сообщение(): {"ошибка деления на ноль"} 27. Диаграмма классов: интерфейс Интерфейсы являются элементами диаграмм вариантов использования. Однако при построении диаграммы классов отдельные интерфейсы могут изображаться в виде прямоугольника со стереотипом "interface". При этом секция атрибутов у прямоугольника отсутствует, а указывается только секция операций.
Из интернета: Интерфейсы являются абстрактными классами, следовательно, объекты данных классов не могут быть созданы напрямую. Они могут содержать методы, но не атрибуты. Классы могут наследоваться от интерфейсов (через ассоциацию реализации), и полученные объекты затем могут использоваться при составлении диаграмм. Интерфейс (interface) — именованное множество операций, которые характеризуют поведение отдельного элемента модели. Интерфейс в контексте языка UML является специальным случаем класса, у которого имеются операции, но отсутствуют атрибуты. Для обозначения интерфейса используется специальный графический символ окружность или стандартный способ – прямоугольник класса со стереотипом <<interface>> (рис. 5.5). На диаграмме вариантов использования интерфейс изображается в виде маленького круга, рядом с которым записывается его имя (рис. 5.5, а). В качестве имени может использоваться существительное, которое характеризует соответствующую информацию или сервис, например" Видеокамера " (рис. 5.5, б). С учетом языка реализации модели имя интерфейса, как и имена других классов, рекомендуется записывать на английском и начинать с заглавной буквы I, например, ITemperatureSensor, IsecureInformation(рис. 5.5, в).
Интерфейсы на диаграмме служат для спецификации таких элементов модели, которые видимы извне, но их внутренняя структура остается скрытой от клиентов. Интерфейсы не могут содержать ни атрибутов, ни состояний, ни направленных ассоциаций. Они содержат только операции без указания особенностей их реализации. Формально интерфейс не только отделяет спецификациюопераций системы от их реализации, но и определяет общие границы проектируемой системы. В последующем интерфейс может быть уточнен явным указанием тех операций, которые специфицируют отдельный аспект поведения системы. Графическое изображение интерфейсов в форме окружности могут использоваться и на других типах канонических диаграмм, например, диаграммах компонентов и развертывания. 28. Диаграмма техники ОО проектирования и их назначение Взаимодействие объектов: · Диаграммы кооперации Является альтернативой диаграммы последовательностей. Если диаграмма последовательности служит для визуализации временных аспектов взаимодействия, то диаграмма кооперации предназначена для спецификации структурных аспектов взаимодействия. Следовательно, на диаграмме лучше просматривается распределение процессов между объектами (из-за отсутствия оси неявного времени). Кооперация может быть представлена на двух уровнях: · на уровне спецификации (показывает роли классов и ассоциации в рассматриваемом взаимодействии). · На уровне примеров (определяются необходимые свойства объектов, участвующих в кооперации, а также указывающие ассоциации, которые должны иметь место в кооперации). Так как одна совокупность объектов может учитываться в различных кооперациях, на кооперации уровня спецификации указываются лишь те свойства операторов и связей, которые необходимы в данной кооперации, а на диаграмме классов должны быть все свойства и ассоциации между элементами диаграммы.
Отметим, что подобное представление используется на начальных этапах проектирования. В последующем, каждая из коопераций подлежит детализации на уровне примеров. При этом в качестве элементов диаграммы кооперации выступают объекты и связи, дополненные сообщениями. На них и акцентируем внимание. · Диаграммы последовательности Диаграмма последовательности используется для представления временных особенностей передачи и приема сообщений между объектами. Они позволяют наглядно показать сценарии вариантов использования разрабатываемого ПО. На диаграмме последовательностей отображаются объекты непосредственно участвующие во взаимодействии при этом объекты с линиями жизни размещены последовательно слева направо а неясное время представлено вертикалью, направленной сверху вниз.
Поведение объектов: · Диаграмма состояний В Visio - трафарет Statechart Diagram. Диаграмма состояний используется для отдельных классов с целью описания поведения порожденных ими объектов. Диаграмма состояний по существу является графом специального вида, который представляет некоторый автомат. Поэтому для построения и понимания семантики конкретной диаграммы состояния надо представлять не только особенности поведения моделируемой сущности, но и знать общие введения по теории автоматов. · Диаграмма деятельности В Visio - трафарет Activity Diagram. Диаграмма деятельности в UML используется для моделирования процесса выполнения операций. Из-за схожести нотаций их можно считать частным случаем диаграммы состояний. Диаграммы деятельности отличается от диаграммы состояния семантикой состояний и отсутствием на переходах сигнатуры событий.
Диаграмма вариантов использования: В Visio для создания диаграмм вариантов использования необходимо выбрать трафарет Use Case Diagram. Диаграммы вариантов использования являются исходными концептуальным представлением системы на этапе ООА. Диаграммы вариантов использования позволяют: · определить общие границы и контекст моделируемой ПРО · сформулировать общие требования к функциональному поведению создаваемой системы · разрабатывать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей · подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями. · Диаграмма классов: Диаграмма классов служит для представления статической структуры модели системы в терминологии объектно-ориентированного подхода. 29. Диаграмма компонентов: назначения и основные элементы Component Diagram Диаграмма компонентов описывает особенности физического представления системы. В состав диаграммы компонентов входит: - компоненты;- интерфейсы;- отношения;- примечания;- ограничения. Диаграмма компонентов используется для: -моделирования исходного кода;-моделирования исполняемых версий; - моделирования физических баз данных;- моделирования адаптивных систем. Компоненты В UML компонент – это физическая сущность, реализующая некоторый набор интерфейсов. Графич. Компонент в UML изображен в виде
Имя компонента уровня экземпляра подчеркивают и пишут с малой буквы. В нижней секции значка может быть указаны объекты реализуемые экземпляром :
В UML выделяют 3 вида компонентов: - компоненты развертывания(LIBRARY, TABLE) - компоненты рабочие продукты (FILE,DOCUMENT) - компоненты исполнения (.EXE – файлы) Часто для упрощения понимания диаграммы компоненты изображают спец-но предназначенными значками
Этим подчеркивают привязку реализ. компонентов конкретных технологий. На кононич. изображении указывают явно стериотип компонентов Интерфейсы Интерфейс – набор операций, которые описывают услуги , предост – емые классом или компонентом. Отношение между компонентом и его интерфейсами можно изобразить 2 способами : в свернутой и развернутой форме.
Здесь comp.java экспортирует интерфейс; а im.java импортирует его. В развернутой форме интерфейса уточняется класс компонента экспортера, реализующий этот интерфейс. Отношения зависимости Зависимость для представления факта наличия такой связи, когда изменение одного элемента модели оказывает влияние или приводит к изменению другого элемента модели. Отношение зависимости на диаграмме компонентов обозначается пунктирной линией от зависимого элемента к нез-го. На рисунке выше отношение зависимости связывает компонент и импортируемый этим компонентом интерфейс. В развернутой форме появляется дополнительно отношение зависимости, связывающий компонент –экспортер с реализующим интерфейс классом. В целом между компонентом-экспортетом и экспортируемым интерфейсом имеет место отношение реализации(сплошная линия). Типичные примеры моделирования: 1)исходный код(некоторые исходные файлы, из которых строится библиотека dll); 2)исполняемые версии; 3)клиент-серверное приложение. 30. Диаграмма развертывания: назначения и основные элементы Deployment Diagramm Диаграмма развертывания применяется для предоставления общей конфигурации и топологии распредел-ой прогр-ой системы и содержит распределенные системы по отдельным ее узлам. Т.е. диаграмма позволяет: - определить распределение компонентов системы по ее физическим узлам - показать физические связи между всеми узлами реализации системы на этапе ее исполнения - выявить узкие места системы и реконфигурировать ее топологию для достижения требуемой производительности Диаграмма развертывания обычно разрабатывается совместно с сист-ми аналитиками, системотехниками… Ниже рассмотрим отдельные элементы из которых состоят диаграммы развертывания. Узел Он представляет собой физически существующий элемент системы, обладающий вычислительным ресурсом. В последней версии UML понятие узла включает не только вычислительные устройства, но и другие механические или электронные устройства, такие как датчики, принтеры, модемы, цифровые камеры, сканеры и манипуляторы. В понятие узла можно включать также людей(персонал) для моделирования бизнес- процессов. На диаграмме развертывания узлы могут представляться как в качестве типов, так и в качестве экземпляров.
Изображение узлов может содержать дополнительную информацию о специфике узла. Если эта информация относится к имени узла, то она записывается под этим именем в форме помеч-го значения.
Указать явно компонентыразмещаемые на отдельном узле можно двумя способами: 1) с использованием списка компонентов 2) либо с их изображением
Важно помнить что в качестве таких сложенных компонент может выступать только исполняемые компоненты. В литературе в качестве дополнения к имени узла можно встретить стереотипы такие как «процессор», «датчик», «модель», «сеть», «консоль» и т.д. Сами же узлы могут быть изображены не только параллелепипедами но и иначе. Соединения Соединения являются разновидностью ассоциации и отображаются линией без стрелок. Эти линии указывают на необходимость организации физических каналов для обмена информацией между узлами. Характер соединения может быть дополнительно специфицирован примечанием, помеченным значением или ограничением.
При большом количестве развернутых на узле компонентов соответствующую информацию можно представить в форме отношения зависимости
На диаграмме развертывания ниже представлен фрагмент для систем удаленного обслуживания клиентов банка
Узлами этой системы являются удаленный терминал(узел-тип) и сервер банка(узел – экземпляр). Разработка встроенных систем предполагает не только создание программного кода, но и согласования между собой всех аппаратных средств и механических устройств.
Примеры типичных диаграмм развертывания 1) моделирование встроенной системы 2) моделирование клиент-серверной системы моделирование полностью распределенной системы 31. BPwin: назначения и возможности Назначение BPwin • наглядно описывать, анализировать и совершенствовать сложные бизнес-процессы, любую деятельность или структуру в виде модели, что позволяет значительно повысить эффективность работы предприятия; • проверить модель на соответствие стандартам ISO9000. Для отечественных предприятий сертификация по ISO 9000 – это пропуск на международный рынок, а также действенное средство для эффективного улучшения работы всего предприятия; • спроектировать структуру информационных потоков, а соответственно, и модернизировать организационную структуру предприятия; • четко выявить факторы, оказывающие влияние на бизнес: какие операции являются наиболее критичными, как повысить их эффективность, какие ресурсы требуются для этого; • снизить издержки и повысить производительность; • выявить и исключить лишние или неэффективные операции; • повысить гибкость и эффективность. • BPwin является также средством системного анализа деловой и производственной активности, позволяющим отслеживать соответствие структуры бизнеса, документооборота, финансовых потоков требованиям современной экономики. Возможности BPwin • позволяет переключиться на любой ветви модели сIDEF0 на нотацию IDEF3 или DFD и создать смешанную модель • имеет инструмент навигации - ModelExplorer, который позволяет представить смешанную модель в виде дерева диаграмм • с помощью Model Explorer можно методом Drag&Drop переносить и копировать работы вместе со всеми соответствующими стрелками как внутри модели так и между моделями • позволяет эффективно манипулировать моделями - сливать и расщеплять, документировать посредством генерации отчетов1 :• BPwin в состоянии поддерживать синтаксис IDEF0, IDEF3 и DFD. Частично ошибки анализируются на этапе внесения новых объектов, частично–детектируются в специальном отчете. • в целях реорганизации предприятия сначала строится функциональная модель существующей организации работы - «AS-IS» (как есть)• найденные в модели «AS-IS» недостатки можно исправить при создании модели «TO-BE» (как будет) - модели новой организации бизнес-процессов • BPwin предоставляет аналитику два инструмента для оценки модели – стоимостный анализ, основанный на работах (Activity Based Costing, ABC) и свойства, определяемые пользователем (UserDefined Properties, UDP) При записи BPWin кроме основного меню появляется основная панель инструментов, палитра инструментов (вид ее зависит от выбранной нотации (IDEF0, IDEF3, DFD) и в левой части - навигатор модели (Model Explorer). При создании новой модели в возникшем диалоге можно указать будет ли модель создана заново или будет открыта из файла либо из репозитария MODEL MART, ввести имя модели и выбрать методологию (нотацию), в которой будет построена модель. Модель в BPWin представляет собой совокупность работ, оперирующих с некоторым набором данных. Контекстное меню к выделенному элементу модели позволяет редактировать отдельные его свойства. 32. BPwin: моделирование процессов в нотации IDEF0 IDEF0 (функциональная модель) предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей - того, к чему нужно стремиться (так называемая модель TO-BE). IDEF0 является подмножеством SADT (Structured Analysis and Design Technique), предложенная в 1973 году Россом. В дальнейшем это подмножество SADT было принято в качестве федерального стандарта США IDEF0. В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Это позволяет не вникая в объекты более четко сформулировать логику и взаимодействие процессов организации. Процесс моделирования системы в IDEF0 начинается с определения контекста, то есть наиболее абстрактного уровня системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель. Субъект моделирования - сама система. Определяя субъект моделирования необходимо точно установить, что входит в систему, а что лежит за ее пределами. То есть первоначально необходимо определить область (scope) моделирования. При этом необходимо учитывать 2 компонента - широту и глубину. Широта подразумевает определение границ модели, а глубина - на каком уровне детализации модель является завершенной. Предполагается, что после определения границ модели новые объекты не должны вноситься в моделируемую систему. При определении глубины системы необходимо не забывать об ограничении времени. Цель моделирования (purpose) - должна отвечать на следующие вопросы.
Точка зрения (view point) должна быть единой и соответствовать цели моделирования. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом (например, руководитель предприятия). Часто при выборе точки зрения на модель важно задокументировать альтернативные точки зрения. Дл этого обычно используют диаграммы FEO (For Exposition Only). IDEF0-модель предполагает наличие четко сформулированной цели единственного субъекта моделирования и одной точки зрения. Для их внесения в модели IDEF0 следует выбрать команду Edit/Model Properties, в закладке Purpose ввести цель и точку зрения, а в закладку DEFINITION - определение модели и описания области. В закладке STATUS - статус модели - черновой, рабочий, окончательный. В закладке SOURCE описываются источники информации (например, опрос экспертов ПРО и анализ документации). Закладка GENERAL служит для внесения имени, проекта модели, имени и инициалов автора, а также временных рамок модели - AS-IS и TO-BE. Работы (Activity) Работы обозначают поименованные процессы, функции, задачи, которые происходят в течении определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольника, должны быть названы (например, "изготовление изделия"),определены (работа относящаяся к полному циклу изготовления изделия от конкретизации качества до отгрузки готового упакованного изделия). При создании новой модели автоматически создается контекстная диаграмма с единственной работой. Стрелки (Arrow) Взаимодействие работ с внешним миром и между собой описываются в виде стрелок в IDEF0 различают 5 типов стрелок:
Граничные стрелки- это стрелки на контекстной диаграмме. Для задания имени стрелки используют команду NameEditor из контекстного меню. Имена стрелок автоматически заносятся в словарь (Arrow Dictionary) ICOM (от Input, Control, Output, Mechanism) - ICOM-коды предназначены для идентификации граничных стрелок в виде префикса типа стрелки и ее порядкового номера.Для отображения ICOM-кодов следует воспользоваться командой Edit/Model Properties..., закладкой Presentation, опция Show ICOM codes. Словарь стрелокРедактируется редактором Arrow Dictionary Editor. Содержимое словаря стрелок может быть распечатать командой Report/Arrow Report. Несвязанные граничные стрелки - это стрелки, которые автоматически появляются на диаграмме декомпозиции. Внутренние стрелки - используются для связи работ между собой. В IDEF0 различают 5 типов связей работ:
Различают явные, развертывающиеся, сливающиеся стрелки. Тоннелирования стрелок - это предотвращение попадания (миграции) стрелок с одной диаграммы на другую.Чтобы затоннелировать либо "перетащить" наверх вновь внесенную на диаграмме декомпозиции граничную стрелку следует:
Если щелкнуть по кнопке [Resolve Border Arrow], стрелка мигрируют на диаграмму верхнего уровня. Если по кнопке [Change to Tunnel] стрелка будет затоннелирована (не будет двигаться никуда). Нумерация работ на диаграммах Все работы модели нумеруются. Номер работы состоит из префикса и числа. Контекстная работа имеет номер A0. Работы декомпозиции A0 имеют номера A1, A2, ... Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер. Например, работы декомпозиции A3 будут иметь номера A31, A32 и так далее, то есть имеет место нумерация по узлам. 33. BPwin: моделирование процессов в нотации DFD Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. DFD описывает: · функции обработки информации (работы); · документы (стрелки, arrow), объекты, сотрудников или отделы, которые участвуют в обработке информации; · внешние ссылки (external references), которые обеспечивают интерфейс с внешними объектами, находящимися за границами модели руемой системы; · таблицы для хранения документов (хранилище данных, data store). · В BPwin для построения диаграмм потоков данных используется нотация Гейна - Сарсона. Для того чтобы дополнить модель IDEF0 диаграммой DFD, нужно в процессе декомпозиции в диалоге Activity Box Count "кликнуть" по радиокнопке DFD. В палитре инструментов на новой диаграмме DFD появляются новые кнопки:
В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы - движение объектов (data flow), хранение объектов (data stores), поставка и распространение объектов (external entities). В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов. Контекстная диаграмма часто включает работы и внешние ссылки. Работы обычно именуются по названию системы, например "Система обработки информации". Включение внешних ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему. Работы. В DFD работы представляют собой функции системы, преобразующие входы в выходы. Хотя работы изображаются прямоугольниками со скругленными углами, смысл их совпадает со смыслом работ IDEF0 и IDEF3. Так же как работы IDEF3, они имеют входы и выходы, но не поддерживают управления и механизмы, как IDEF0. Внешние сущности. Внешние сущности изображают входы в систему и/или выходы из системы. Внешние сущности изображаются в виде прямоугольника с тенью и обычно располагаются по краям диаграммы. Одна внешняя сущность может быть использована многократно на одной или нескольких диаграммах. Обычно такой прием используют, чтобы не рисовать слишком длинных и запутанных стрелок. Стрелки (Потоки данных). Стрелки описывают движение объектов из одной части системы в другую. Поскольку в DFD каждая сторона работы имеет четкого назначения, как в IDEF0, стрелки могут подходить выходить из любой грани прямоугольника работы. В DFD также применяются двунаправленные стрелки для описания диалогов типа "команда-ответ" между работами, между работой и внешней сущностью и между внешними сущностями. 34. BPwin: моделирование процессов в нотации IDEF3 Для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming - методологией моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например последовательность обработки заказа события, которые необходимо обработать за конечное время. Каждый тенарий сопровождается описанием процесса и может быть использован я документирования каждой функции. IDEF3 - это метод, имеющий основной целью дать возможность налитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе. Техника описания набора данных IDEF3 является частью структурного анализа. В отличие от некоторых методик описаний процессов IDEF3 не ограничивает аналитика чрезмерно жесткими рамками синтаксиса, что может привести к созданию неполных или противоречивых моделей. IDEF3 может быть также использован как метод создания процессов. IDEF3 дополняет IDEF0 и содержит все необходимое для построения моделей, которые в дальнейшем могут быть использованы для имитационного анализа. Каждая работа в IDEF3 описывает какой-либо сценарий бизнес-процесса и может являться составляющей другой работы. Поскольку сценарий описывает цель и рамки модели, важно, чтобы работы именовались отглагольным существительным, обозначающим процесс действия, или фразой, содержащей такое существительное. Точка зрения на модель должна быть задокументирована. Обычно это точка зрения человека, ответственного за работу в целом. Также необходимо задокументировать цель модели - те вопросы, на которые призвана ответить модель. Диаграммы. Диаграмма является основной единицей описания в IDEF3. Важно правильно построить диаграммы, поскольку они предназначены для чтения другими людьми (а не только автором). Единицы работы - Unit of Work (UOW). UOW, также называемые работами (activity), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы, и номер (идентификатор); другое имя существительное в составе той же фразы обычно отображает основной выход (результат) работы (например, "Изготовление изделия"). Часто имя существительное в имени работы меняется в процессе моделирования, поскольку модель может уточняться и редактироваться. Идентификатор работы присваивается пhи создании и не меняется никогда. Даже если работа будет удалена, ее идентификатор не будет вновь использоваться для других работ. Обычно номер работы состоит из номера родительской работы и порядкового номера на текущей диаграмме. Связи. Связи показывают взаимоотношения работ. Все связи в IDEF3 однонаправленны и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо. В IDEF3 различают три типа стрелок, изображающих связи, стиль которых устанавливается во вкладке Style диалога Arrow Properties (пункт контекстного меню Style). 35. BPwin: создание системной модели При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново, или она будет открыта из файла либо из репозитория ModelMart, внести имя модели и выбрать методологию, в которой будет построена модель. Как было указано выше, BPwin поддерживает три методологии - IDEF0, IDEF3 и DFD, каждая из которых решает свои специфические задачи. В BPwin возможно построение смешанных моделей, т. е. модель может содержать одновременно как диаграммы IDEF0, так и диаграммы IDEF3, DFD.
После щелчка по кнопке ОК появляется диалог Properties for New Models, в котором следует внести свойства модели.
Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует некоторым набором данных. Работа изображается в виде прямоугольников, данные - в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется всплывающее контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта. 36. BPwin: ABC- анализ Стоимостный анализ представляет собой соглашение об учете, используемое для сбора затрат, связанных с работами, с целью определить общую стоимость процесса. Стоимостный анализ основан на модели работ, потому что количественная оценка невозможна без детального понимания функциональности предприятия. Обычно ABC применяется для того, чтобы понять происхождение выходных затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия (Business Process Re-engineering, BPR). С помощью стоимостного анализа можно решить такие задачи, как определение действительной стоимости производства продукта, определение действительной стоимости поддержки клиента, идентификация работ, которые стоят больше всего (те, которые должны быть улучшены в первую очередь), обеспечение менеджеров финансовой мерой предлагаемых изменений, и др. ABC может проводиться только тогда, когда модель работы последовательная (следует синтаксическим правилам IDEF0), корректная (отражает бизнес), полная (охватывает всю рассматриваемую область) и стабильная (проходит цикл экспертизы без изменений), другими словами, создание модели работы закончено. ABC включает следующие основные понятия: - объект затрат - причина, по которой работа выполняется, обычно, основной выход работы, стоимость работ есть суммарная стоимость объектов затрат ("Готовое изделие"); - движитель затрат - характеристики входов и управлений работы ("Сырье", "Чертеж"), которые влияют на то, как выполняется и как долго длится работа; - центры затрат, которые можно трактовать как статьи расхода.
37. BPwin: UDP- анализ Если стоимостных показателей недостаточно, имеется возможность внесения собственных метрик – свойств, определенных пользователем (User Defined Properties, UDP) [1]. UDP позволяет провести дополнительный анализ, хотя и без суммирующих подсчетов. Для описания UDP служит диалог User-Defined Property Name Editor (меню Model/UDP Definition)
В верхнем окне диалога вносится имя UDP, в списке выбора Datatype описывает тип свойства. Имеется возможность задания 18 различных типов UDP, в том числе управляющих команд и массивов, объединенных по категориям. Для внесения категории следует задать имя категории в окне New Category/Member и щелкнуть по кнопке Add Category. Для присвоения свойства категории необходимо выбрать UDP из списка, затем категорию из списка категорий и щелкнуть по кнопке Update. Одна категория может объединять несколько свойств, в то же время одно свойство может входить в несколько категорий. Свойство типа List может содержать массив предварительно определенных значений. Для определения области значений UDP типа List следует задать значение свойства в окне New Category/Member и щелкнуть по кнопке Add Member. Значения из списка можно редактировать и удалять. Каждой работе можно поставить в соответствие набор UDP. Для этого следует щелкнуть правой кнопкой мыши по работе и выбрать пункт меню UDP Editor. В закладке UDP Values диалога IDEF0 Activity Properties можно задать значения UDP. Свойства типа List отображаются списком выбора, который заполнен предварительно определенными значениями. Кнопка Categories служит для задания фильтра по категориям UDP. По умолчанию в списке показываются свойства всех категорий. Результат задания проанализировать в отчете Diagram Object Report (меню Report/Diagram Object Report…). В левом нижнем углу диалога настройки отчета показывается список UDP. С помощью кнопки Activity Categories можно установить фильтр по категориям. 38. ERwin:назначение и возможности ERwin - средство разработки структуры базы данных (БД). ERwin сочетает графический интерфейс Windows, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД и настольных баз данных. С помощью ERwin можно создавать или проводить обратное проектирование (реинжиниринг) баз данных. Процесс построения информационной модели состоит из следующих шагов: определение сущностей; определение зависимостей между сущностями; задание первичных и альтернативных ключей; определение атрибутов сущностей; приведение модели к требуемому уровню нормальной формы; переход к физическому описанию модели: назначение соответствий имя сущности - имя таблицы, атрибут сущности - атрибут таблицы; задание триггеров, процедур и ограничений; генерация базы данных. ERwin создает визуальное представление (модель данных) для решаемой задачи. Это представление может использоваться для детального анализа, уточнения и распространения как части документации, необходимой в цикле разработки. Однако ERwin далеко не только инструмент для рисования. ERwin автоматически создает базу данных (таблицы, индексы, хранимые процедуры, триггеры для обеспечения ссылочной целостности и другие объекты, необходимые для управления данными). Отображение логического и физического уровня модели данных в ERwin В ERwin существуют два уровня представления и моделирования - логический и физический . Логический уровень означает прямое отображение фактов из реальной жизни. Например, люди, столы, отделы, собаки и компьютеры являются реальными объектами. Они именуются на естественном языке, с любыми разделителями слов (пробелы, запятые и т.д.). На логическом уровне не рассматривается использование конкретной СУБД, не определяются типы данных (например, целое или вещественное число) и не определяются индексы для таблиц. Целевая СУБД, имена объектов и типы данных, индексы составляют второй (физический) уровень модели ERwin. ERwin предоставляет возможности создавать и управлять этими двумя различными уровнями представления одной диаграммы (модели), равно как и иметь много вариантов отображения на каждом уровне. Применение ERwin существенно повышает эффективность деятельности разработчиков информационных систем. Преимущества: -существенное повышение скорости разработки за счет мощного редактора диаграмм, автоматической генерации базы данных, автоматической подготовки документации; -нет необходимости ручной подготовки SQL-предложений для создания базы данных; -возможность легко вносить изменения в модель при разработке и расширении системы; -возможность автоматической подготовки отчетов по базе данных; важно, что эти отчеты всегда в точности соответствуют реальной структуре БД; -разработчики прикладного программного обеспечения снабжены удобными в работе диаграммами; -поддержка однопользовательских СУБД позволяет использовать для персональных систем современные технологии, что значительно упрощает переход от настольных систем к системам в технологии клиент-сервер (upsizing). ИЛИ Область применения Erwin используется для построения модели данных. ERwin имеет два уровня представления модели – логический и физический. На логическом уровне данные не связаны с конкретной СУБД. Физический уровень данных – это по существу отображение системного каталога, который зависит от конкретной реализации СУБД. ERwin позволяет проводить процессы прямого и обратного проектирования БД. Это означает, что по модели данных можно сгенерировать схему БД или автоматически создать модель данных на основе информации системного каталога. Для создания моделей данных в Erwin используются две методологии: IDEF1X и IE. В данной работе рассматривается методология IDEF1X. 39. ERwin: логическое моделирование данных Область применения: Erwin используется для построения модели данных. ERwin имеет два уровня представления модели – логический и физический. На логическом уровне данные не связаны с конкретной СУБД. Физический уровень данных – это по существу отображение системного каталога, который зависит от конкретной реализации СУБД. ERwin позволяет проводить процессы прямого и обратного проектирования БД. Это означает, что по модели данных можно сгенерировать схему БД или автоматически создать модель данных на основе информации системного каталога. Для создания моделей данных в Erwin используются две методологии: IDEF1X и IE. В данной работе рассматривается методология IDEF1X. Отображение модели данных в ERwin. ERwin имеет два уровня представления модели – логический и физический. Логический уровень – это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например, «Фамилия сотрудника», «Отдел». Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель может быть построена на основе другой логической модели, например на основе модели процессов. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД. 40. ERwin: физическое моделирование данных Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД. Поскольку стандартов на объекты БД не существует, физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Разделение модели данных на логические и физические позволяет решить несколько важных задач. 41. ERwin: моделирование хранение данных Место ERwin в информационном моделировании Процесс построения информационной модели состоит из следующих шагов: определение сущностей; определение зависимостей между сущностями; задание первичных и альтернативных ключей; определение атрибутов сущностей; приведение модели к требуемому уровню нормальной формы; переход к физическому описанию модели: назначение соответствий имя сущности - имя таблицы, атрибут сущности - атрибут таблицы; задание триггеров, процедур и ограничений; генерация базы данных. ERwin создает визуальное представление (модель данных) для решаемой задачи. Это представление может использоваться для детального анализа, уточнения и распространения как части документации, необходимой в цикле разработки. Однако ERwin далеко не только инструмент для рисования. ERwin автоматически создает базу данных (таблицы, индексы, хранимые процедуры, триггеры для обеспечения ссылочной целостности и другие объекты, необходимые для управления данными). 42. Взаимодействие BPwin и Erwin Множество сущностей, их атрибутов, связи между ними и их степени зависят от целей информационной системы и определяются неформальными способами. Поэтому определить цель целесообразно на стадии функционального моделирования систем. Например, если один сотрудник может одновременно работать в нескольких подразделениях, а в каждом подразделении могут работать несколько сотрудников, между сущностями «Подразделения» и «Сотрудники» имеет место бинарная связь «много ко многим». Классы принадлежности определяются для каждого конца связи и показывают, могут ли существовать отдельные экземпляры сущности, не связанные с другой сущностью. Если такое имеет место, класс принадлежности называется необязательным. В противном же случае класс называется обязательным. Все это необходимо учитывать в самом начале моделирования. В пакете BPwin для определения сущностей и их атрибутов предназначен специализированный редактор Entity/Attribute Editor (add/drop). Что же касается связей между сущностями, то в BPwin они не определяются, а для этих целей, а также для реализации других этапов автоматизированного проектирования реляционных баз данных предназначен специализированный пакет ERwin той же фирмы Computer Associated, которая разработала BPwin. Экспорт в ERwin Экспорт в ERwin осуществляется путем выбора пункта меню «File» - «Export» - «ERwin 4.0». При этом откроется диалоговое окно для выбора файла с расширением .bрх. Выбрав папку и имя (например, cwdm мультиплексор), нажимаем командную кнопку «Сохранить» и выполняем операцию экспорта. Важное замечание: для правильного взаимодействия между BPwin и ERwin необходимо соблюдать следующее правило: всякое изменение сущностей и атрибутов после экспорта из BPwm в ERwin можно производить только в ER win, после чего измененный файл либо импортируется из ERwin (находясь в Bpwin) либо экспортируется в BPwin (находясь в Erwin). Всякое нарушение этого процесса (например, после экспорта из BPwin в ERwin что-то в BPwm изменяется и еще раз экспортируется) произойдут необратимые изменения в файле для BPwm, в частности будет потеряна возможность изменять и экспортировать ранее существовавшие сущности и атрибуты. При этом никакие переименования указанной программы не «оторвут» ее от ERwin и она будет безнадежно потеряна (в части сущностей и атрибутов). С целью предотвращения подобной ситуации рекомендуется сохранить доэкспортный файл типа .bpl под другим именем. В результате экспорта появится файл с тем же именем, но с расширением .erl. 43. RATIONALROSE: назначение и возможности Rational Rose в отличие от подобных средств проектирования способна проектировать системы любой сложности, то есть инструментарий программы допускает как высокоуровневое (абстрактное) представление (например, схема автоматизации предприятия), так и низкоуровневое проектирование (интерфейс программы, схема базы данных, частичное описание классов). 1. Проектировать системы любой сложности 2. Давать развернутое представление о проекте в сочетании со средствами документирования (SoDA) 3. Проводить кодогенерацию 4. Проводить обратное проектирование имеющихся систем 5. Имеет открытый для дополнений интерфейс 6. Интегрируется со средствами разработки (Visual Studio) 7. Поддержка языка UML 8. Наличие средств автоматического контроля, в том числе проверки соответствия двух моделей 9. Удобный для пользователя графический интерфейс 10. Многоплатформенность Интегрируемость с другими инструментальными средствами, поддерживающими жизненный цикл программных систем, в том числе со средством управления требованиями (Requisite Pro), со средствами тестирования (SQA Suite, Performance Studio), со средствами конфигурационного управления (ClearCase, PVCS). 44. RATIONALROSE: создание модели вариантов использования Создайте диаграмму вариантов использования для системы регистрации. Требуемые для этого действия подробно перечислены далее. Готовая диаграмма вариантов использования изображена на рис. 5. В среде Rose диаграммы вариантов использования создаются в представлении вариантов использования. Главная диаграмма (Main) предлагается по умолчанию. Для моделирования системы можно затем разработать необходимое количество дополнительных диаграмм. Для того чтобы получить доступ к главной диаграмме вариантов использования: 1. Откройте данное представление, щелкнув по значку «+» рядом с представлением вариантов использования в браузере. 2. Откройте главную диаграмму, дважды щелкнув мышью. Строка заголовка изменится, включив фразу [Use Case Diagram: Use Case view / Main]. Для создания новой диаграммы вариантов использования: 1. Щелкните правой кнопкой мыши по пакету представления вариантов использования в браузере. 2. Выберите пункт New / Use Case Diagram из всплывающего меню. 3. Выделив новую диаграмму, введите ее имя. 4. Дважды щелкните по названию этой диаграммы в браузере, чтобы открыть ее. 45. RATIONALROSE: моделирование диаграммы состояния Строят для отдельного класса. Отметим, что и всю систему можно трактовать как класс. Для выбранного класса начать построение можно двумя способами: 1) Раскрыть логическое представление в браузере (Logical View) 2) Через пункт меню Browse/State Diagram Процесс добавления и удаления состояний и переходов на диаграмму состояний аналогичен этим же действиям с элементами других диаграмм. После добавления нового состояния или перехода на диаграмму состояний можно открыть спецификацию выбранных элементов и определить их специфические свойства, допустимые на соответствующих вкладках. При необходимости можно визуализировать вложенность состояний и подключить историю отдельных состояний. 46. RATIONALROSE: моделирование поведения в виде диаграммы деятельности Главное отличие между диаграммой деятельности и диаграммой состояния состоит в том, что в первом случае – основные действия, а во втором – статическое состояние. При этом диаграмма деятельности подходит для моделирования последовательности действий, а диаграмма состояний – для моделирования дискретных состояний объекта. Способы начала разработки обоих диаграмм – идентичны и отличаются выбором опций: {Statechart/Activity} Затем выполняют операции построения диаграммы деятельности. Перечень операций и последовательность действий по выполнению каждой из низ даны в [ ]. 47. RATIONALROSE: моделирование взаимодействие объектов в виде диаграммы последовательности Может быть активизирована одним из следующих способов: 1) Щелкнуть на кнопке с изображением диаграммы последовательности на стандартной панели инструментов 2) Через пункт меню Browse/Interaction Diagram. После выполнения в окне диаграммы появится чистое поле для размещения элементов диаграммы последовательности, которые выбираются с помощью специальной панели инструментов. Построение диаграммы последовательности сводится к добавлению или удалению отдельных объектов и сообщений, а также их спецификации. Доступ к спецификации этих элементов организован через контекстное меню, либо через пункт меню Browse/Specification. При добавлении сообщений на диаграмму последовательности они по умолчанию получают свой номер последовательности. При необходимости можно изменить порядок следования сообщений и их спецификации, а также сопоставить сообщения с операциями. Дополнительно можно установить синхронизацию сообщений, связать с сообщением примечание (комментарий). 48. RATIONALROSE: моделирование взаимодействия в виде диаграммы кооперации Является другим способом визуализации взаимодействия объектов в модели. Особенность работы в среде Rational Rose - в том, что этот вид диаграммы создается автоматически после построения диаграммы последовательности и нажатия F5. С помощью этой же клавиши осуществляется переключение между диаграммой последовательности и кооперации. После того, как диаграмма кооперации активизирована, специальная панель инструментов приобретает соответствующий вид. Работа с диаграммой кооперации состоит в добавлении или удалении объектов и сообщений, а также их специфицировании. При этом изменения, вносимые в диаграмму кооперации, автоматически вносятся и в диаграмму последовательности. Как и для диаграммы последовательности, для диаграммы кооперации можно изменять порядок следования сообщений, добавлять потоки данных, определять устойчивость объектов с помощь соответствующих спецификаций. 49. RATIONALROSE: построение статической модели ПО Диаграмма классов является основным логическим представлением модели и содержит самую подробную информацию о внутреннем устройстве объектно-ориентированной системы. Активизировать диаграмму классов в окне диаграмм можно несколькими способами: 1) Эта диаграмма появляется по умолчанию в окне диаграммы после создания нового проекта 2) Щелкнуть на кнопке с изображением диаграммы классов на стандартной панели инструментов 3) Раскрыть логическое представление в браузере (Logical View) и дважды щелкнуть на пиктограмме Main. 4) Через пункт меню Browse/Class Diagram После активизации диаграммы классов специальная панель инструментов приобретает соответствующий вид. Добавление и удаление элементов происходит как в предыдущем случае. Однако, у каждого класса имеется обширная спецификация с информацией о его атрибутах и операциях. При этом видимость атрибутов и операций отображается в форме специальных пиктограмм, которые изображаются перед именем соответствующего атрибута/операции и имеет следующий смысл: · общий, открытый (public) (+) · защищенный (protected) (#) · закрытый (private) (-) · пакетный (implemented) (знака нет) Пакетный означает, что он общий в пределах своего пакета. Аналогичные пиктограммы применяются для обозначения видимости операций класса. Для отдельных атрибутов выделенного класса можно задать тип данных и начальное значение атрибута, а также назначить стереотип через пункт контекстного меню Open Specification. При этом предполагается выбор соответствующих значений из раскрывающегося списка. Для отдельных операций выбранного класса можно задать тип возвращаемого результата, добавить аргументы к операции, назначить для нее стереотип и так далее. Эти свойства операции доступны через пункт контекстного меню и вкладку Operation. При двойном щелчке на выбранной операции открывается диалог с вкладками, соответствующими отдельным из перечисленных ранее свойств. Для добавления связей между классами необходимо на панели инструментов выбрать требуемый тип связи. Если связь направленная, то на диаграмме классов выделить источник и не отпуская левую кнопку переместить указатель мыши к приемнику. После отпускания кнопки на диаграмму будет добавлена новая связь. Для связей можно определить кратность каждого из концов, задать имя и стереотип, использовать ограничения и роли, а также некоторые другие свойства. Доступ к спецификации связей можно получить через контекстное меню связей. 50. RATIONALROSE: построение диаграммы компонентов Эта диаграмма является частью физического представления модели и играет важную роль в процессе объектно-ориентированного проектирования. Активизация диаграммы компонентов осуществляется одним из следующих способов: 1) Щелкнуть по кнопке с изображением диаграммы компонентов на стандартной панели инструментов 2) Раскрыть компонентное представление в браузере (Component View) и дважды щелкнуть на пиктограмме Main 3) Через пункт меню Browse/Component Diagram. После активизации специальной панели инструментов приобретает соответствующий вид. Добавление и удаление элементов происходит аналогично рассмотренному ранее, однако для каждого компонента можно определить различные детали: стереотип, язык программирования, декларации, классы Работа с этими деталями компонентов осуществляется через спецификацию компонента, доступной после вызова контекстного меню. При работе с диаграммой компонентов можно создавать пакеты и компоненты, менять их спецификацию и зависимости между различными элементами диаграммы. При установлении реализации классов на компоненте можно выделить класс в браузере и перетащить его на нужный компонент диаграммы. 51. RATIONALROSE:построение диаграммы развертывания Эта диаграмма является второй составной частью физического представления модели. Активизация: 1) Щелкнуть на кнопке с изображением диаграммы развертывания на стандартной панели инструментов. 2) Дважды щелкнуть на пиктограмме представления в браузере (Deployment View) 3) Через пункт меню Browse/Deployment Diagram После активизации диаграммы развертывания специальная панель инструментов приобретает соответствующий вид. Работа с диаграммами развертывания состоит в создании процессоров и устройств, их спецификации, установления связей между ними, а также добавление спецификаций. 52. RATIONALROSE: общая последовательность кодогенерации по модели Одним из наиболее мощных свойств среды Rational Rose является возможность генерации программного кода после построения модели. Возможность генерации текста программы на языке программирования зависит от установленной версии Rational Rose. Общая последовательность действий, которые необходимо выполнить: 1) Проверка модели независимо от языка генерации кода 2) Создание компонентов для реализации классов 3) Отображение классов на компоненты 4) Установка свойств генерации программного кода 5) Выбор класса, компонента или пакета 6) Генерация программного кода. Особенности выполнения каждого из этих этапов могут меняться в зависимости от выбора языка. В Rational Rose предусмотрено задание достаточно большого числа свойств, характеризующих как отдельные классы, так и проект в целом. 53. RATIONALROSE:кодогенераци я по модели с использованием библиотеки MFC 1) Создать проект в ВЦ++ при пом. МФЦ AppVisard.exp После создания проекта ВЦ++ можно закрыть 2) Импортировать классы интерфейса и модель RR с пом его мастера - в км поля Visual C++ выбрать новый компонент - в появившемся диалоге выбрать закладку Existing (существующие проекты) - в поле FileName выбрать имя проекта ВЦ++, созданного на шаге 1 и добавить проект в текущий - выбрать все компоненты 3) назначит все классы, код для кот. Собираемся генерировать. Tool/VisualC++/Component Assigment Too/ Появляется окно, перетаскиваем нужный класс из правой части окна в левую. 4) –Tools/Visual C++/Update Code - [Nest] - Выбрать классы->next->… 5) Открыть проект в среде ВЦ++ Сгенерировать 6) Добавить функциональность в шаблонные классы можно и в RR
54. Rational Rose:создание кода класса на Ms VC++ и шаблонов приложения 1) Окно Browser: Logical View -> RClick -> New -> NewClass (Требуется имя) 2) Задание атрибутов и операторов(л.р. №7) 3) Ассоциация класса с ВЦ++ и создание проекта в ВЦ – приложении 4) Корректировка модели класса и обновление кода Logical View ->RClick -&g 12 |
При необходимости имя компонента может содержать дополнительную информацию. В нижн. Секции компонента можно указать информацию о реализуемых классах.
- добавить в диаграмму внешнюю ссылку (External Reference). Внешняя ссылка является источником или приемником данных извне модели;
- добавить в диаграмму хранилище данных (Data store). Хранилище данных позволяет описать данные, которые необходимо сохранить в памяти прежде, чем использовать в работах.
