«Д.Г. Штенников Разработка информационных систем в образовании Учебное пособие Санкт-Петербург 2012 1 Штенников Д.Г. Приемы работы с приложениями Picasa и Pixlr. Учебное пособие. – СПб: СПбГУ ИТМО, 2012. – 40 с. ...»

В зависимости от того, к какой из сторон функционального блока подходит данная интерфейсная дуга, она носит название "входящей", "исходящей" или "управляющей". Любой функциональный блок по требованиям стандарта должен иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую. Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

Декомпозиция позволяет постепенно представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой.

Для каждого из элементов IDEF0 — диаграмм, функциональных блоков, интерфейсных дуг — существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.

Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой. В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми. Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели.

Выделение подпроцессов. В процессе декомпозиции функциональный блок, отображающий систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы, и называется дочерней (Child Diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме, соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок — предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме.

Этим достигается структурная целостность IDEF0–модели.

Иногда отдельные интерфейсные дуги высшего уровня не имеет смысла продолжать рассматривать на диаграммах нижнего уровня, или наоборот — отдельные дуги нижнего отражать на диаграммах более высоких уровней – это будет только перегружать диаграммы и делать их сложными для восприятия. Для решения подобных задач в стандарте IDEF предусмотрено понятие туннелирования. Обозначение "туннеля" (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из "туннеля") только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока–приемника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии, – в таком случае они сначала "погружаются в туннель", а затем при необходимости "возвращаются из туннеля".

На диаграмме должно быть от трех до шести функциональных блоков, при этом количество подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг предполагается не более четырех.

Наглядность графического языка IDEF0 делает модель вполне читаемой и для лиц, которые не принимали участия в проекте ее создания, а также эффективной для проведения показов и презентаций. В дальнейшем на базе построенной модели могут быть организованы новые проекты, нацеленные на производство изменений в модели.

Функциональная методика потоков данных Целью методики является построение модели рассматриваемой системы в виде диаграммы потоков данных (Data Flow Diagram — DFD), обеспечивающей правильное описание выходов (отклика системы в виде данных) при заданном воздействии на вход системы (подаче сигналов через внешние интерфейсы). Диаграммы потоков данных являются основным средством моделирования функциональных требований к проектируемой системе. При создании диаграммы потоков данных используются четыре основных понятия: потоки данных, процессы (работы) преобразования входных потоков данных в выходные, внешние сущности, накопители данных (хранилища).

Потоки данных являются абстракциями, использующимися для моделирования передачи информации (или физических компонент) из одной части системы в другую. Потоки на диаграммах изображаются именованными стрелками, ориентация которых указывает направление движения информации.

Назначение процесса (работы) состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Имя процесса должно содержать глагол в неопределенной форме с последующим дополнением (например, "получить документы по договорам"). Каждый процесс имеет уникальный номер для ссылок на него внутри диаграммы, который может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.

Хранилище (накопитель) данных позволяет на указанных участках определять данные, которые будут сохраняться в памяти между процессами.

Фактически хранилище представляет "срезы" потоков данных во времени.

Информация, которую оно содержит, может использоваться в любое время после ее получения, при этом данные могут выбираться в любом порядке.

Имя хранилища должно определять его содержимое и быть существительным.

Внешняя сущность представляет собой материальный объект вне контекста системы, являющейся источником или приемником системных данных. Ее имя должно содержать существительное, например, "склад товаров". Предполагается, что объекты, представленные как внешние сущности, не должны участвовать ни в какой обработке.

Кроме основных элементов, в состав DFD входят словари данных и миниспецификации.

Словари данных являются каталогами всех элементов данных, присутствующих в DFD, включая групповые и индивидуальные потоки данных, хранилища и процессы, а также все их атрибуты.

Миниспецификации обработки — описывают DFD-процессы нижнего уровня. Фактически миниспецификации представляют собой алгоритмы описания задач, выполняемых процессами: множество всех миниспецификаций является полной спецификацией системы.

Процесс построения DFD должен начинается с создания основной диаграммы типа "звезда", на которой представлен моделируемый процесс и все внешние сущности, с которыми он взаимодействует. В случае сложного основного процесса он сразу представляется в виде декомпозиции на ряд взаимодействующих процессов. Критериями сложности в данном случае многофункциональность системы, ее распределенный характер. Внешние сущности выделяются по отношению к основному процессу. Для их определения необходимо выделить поставщиков и потребителей основного процесса, т.е. все объекты, которые взаимодействуют с основным процессом.

На этом этапе описание взаимодействия заключается в выборе глагола, дающего представление о том, как внешняя сущность использует основной процесс или используется им. Например, основной процесс – "учет обращений студентов", внешняя сущность – "студенты", описание взаимодействия – "подает заявления и получает ответы". Этот этап является принципиально важным, поскольку именно он определяет границы моделируемой системы. Для всех внешних сущностей строится таблица событий, описывающая их взаимодействие с основным потоком. Таблица событий включает в себя наименование внешней сущности, событие, его тип (типичный для системы или исключительный, реализующийся при определенных условиях) и реакцию системы.

На следующем шаге происходит декомпозиция основного процесса на набор взаимосвязанных процессов, обменивающихся потоками данных. Сами потоки не конкретизируются, определяется лишь характер взаимодействия.

Декомпозиция завершается, когда процесс становится простым, т.е.:

1. процесс имеет два-три входных и выходных потока;

2. процесс может быть описан в виде преобразования входных данных в 3. процесс может быть описан в виде последовательного алгоритма.

Для простых процессов строится миниспецификация – формальное описание алгоритма преобразования входных данных в выходные.

Миниспецификация удовлетворяет следующим требованиям: для каждого процесса строится одна спецификация; спецификация однозначно определяет входные и выходные потоки для данного процесса; спецификация не определяет способ преобразования входных потоков в выходные;

спецификация ссылается на имеющиеся элементы, не вводя новые;

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

После декомпозиции основного процесса для каждого подпроцесса строится аналогичная таблица внутренних событий.

Следующим шагом после определения полной таблицы событий выделяются потоки данных, которыми обмениваются процессы и внешние сущности. Простейший способ их выделения заключается в анализе таблиц событий. События преобразуются в потоки данных от инициатора события к запрашиваемому процессу, а реакции – в обратный поток событий. После построения входных и выходных потоков аналогичным образом строятся внутренние потоки. Для их выделения для каждого из внутренних процессов выделяются поставщики и потребители информации. Если поставщик или потребитель информации представляет процесс сохранения или запроса информации, то вводится хранилище данных, для которого данный процесс является интерфейсом.

После построения потоков данных диаграмма должна быть проверена на полноту и непротиворечивость. Полнота диаграммы обеспечивается, если в системе нет "повисших" процессов, не используемых в процессе преобразования входных потоков в выходные. Непротиворечивость системы обеспечивается выполнением наборов формальных правил о возможных типах процессов: на диаграмме не может быть потока, связывающего две внешние сущности – это взаимодействие удаляется из рассмотрения; ни одна сущность не может непосредственно получать или отдавать информацию в хранилище данных – хранилище данных является пассивным элементом, управляемым с помощью интерфейсного процесса; два хранилища данных не могут непосредственно обмениваться информацией – эти хранилища должны быть объединены.

К преимуществам методики DFD относятся:

возможность однозначно определить внешние сущности, анализируя потоки информации внутри и вне системы;

возможность проектирования сверху вниз, что облегчает построение модели "как должно быть";

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

К недостаткам модели отнесем: необходимость искусственного ввода управляющих процессов, поскольку управляющие воздействия (потоки) и управляющие процессы с точки зрения DFD ничем не отличаются от обычных; отсутствие понятия времени, т.е. отсутствие анализа временных промежутков при преобразовании данных (все ограничения по времени должны быть введены в спецификациях процессов).

Объектно-ориентированная методика Принципиальное отличие между функциональным и объектным подходом заключается в способе декомпозиции системы. Объектноориентированный подход использует объектную декомпозицию, при этом статическая структура описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Целью методики является построение бизнес-модели ОУ, позволяющей перейти от модели сценариев использования к модели, определяющей отдельные объекты, участвующие в реализации ее функций.

Концептуальной основой объектно-ориентированного подхода является объектная модель, которая строится с учетом следующих принципов:

абстрагирование;

инкапсуляция;

модульность;

иерархия;

типизация;

параллелизм;

устойчивость.

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

Объект — предмет или явление, имеющее четко определенное поведение и обладающие состоянием, поведением и индивидуальностью.

Структура и поведение схожих объектов определяют общий для них класс.

Класс – это множество объектов, связанных общностью структуры и поведения. Следующую группу важных понятий объектного подхода составляют наследование и полиморфизм. Понятие полиморфизм может быть интерпретировано как способность класса принадлежать более чем одному типу. Наследование означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов.

Важным качеством объектного подхода является согласованность моделей деятельности организации и моделей проектируемой информационной системы от стадии формирования требований до стадии реализации. По объектным моделям может быть прослежено отображение реальных сущностей моделируемой предметной области (организации) в объекты и классы информационной системы.

Большинство существующих методов объектно-ориентированного подхода включают язык моделирования и описание процесса моделирования.

Процесс – это описание шагов, которые необходимо выполнить при разработке проекта. В качестве языка моделирования объектного подхода используется унифицированный язык моделирования UML, который содержит стандартный набор диаграмм для моделирования.

Диаграмма (Diagram) — это графическое представление множества элементов. Чаще всего она изображается в виде связного графа с вершинами (сущностями) и ребрами (отношениями) и представляет собой некоторую проекцию системы.

Объектно-ориентированный подход обладает следующими преимуществами:

Объектная декомпозиция дает возможность создавать модели меньшего размера путем использования общих механизмов, обеспечивающих необходимую экономию выразительных средств.

Использование объектного подхода существенно повышает уровень унификации разработки и пригодность для повторного использования, что ведет к созданию среды разработки и переходу к сборочному созданию моделей.

Объектная декомпозиция позволяет избежать создания сложных моделей, так как она предполагает эволюционный путь развития модели на базе относительно небольших подсистем.

Объектная модель естественна, поскольку ориентирована на человеческое восприятие мира.

К недостаткам объектно-ориентированного подхода относятся высокие начальные затраты. Этот подход не дает немедленной отдачи. Эффект от его применения сказывается после разработки двух–трех проектов и накопления повторно используемых компонентов. Диаграммы, отражающие специфику объектного подхода, менее наглядны.

Синтетическая методика Каждая из рассмотренных методик позволяет решить задачу построения формального описания рабочих процедур исследуемой системы.

Все методики позволяют построить модель "как есть" и "как должно быть". С другой стороны, каждая из этих методик обладает существенными недостатками. Их можно суммировать следующим образом: недостатки применения отдельной методики лежат не в области описания реальных процессов, а в неполноте методического подхода.

Функциональные методики в целом лучше дают представление о существующих функциях ОУ, о методах их реализации, причем чем выше степень детализации исследуемого процесса, тем лучше они позволяют описать систему. Под лучшим описанием в данном случае понимается наименьшая ошибка при попытке по полученной модели предсказать поведение реальной системы. На уровне отдельных рабочих процедур их описание практически однозначно совпадает с фактической реализацией в потоке работ.

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

Хорошо описать систему на этом уровне позволяет объектный подход, основанный на понятии сценария использования. Ключевым является понятие о сценарии использования как о сеансе взаимодействия действующего лица с системой, в результате которого действующее лицо получает нечто, имеющее для него ценность. Использование критерия ценности для пользователя дает возможность отбросить не имеющие значения детали потоков работ и сосредоточиться на тех функциях системы, которые оправдывают ее существование. Однако и в этом случае задача определения границ системы, выделения внешних пользователей является сложной.

Технология потоков данных, исторически возникшая первой, легко решает проблему границ системы, поскольку позволяет за счет анализа информационных потоков выделить внешние сущности и определить основной внутренний процесс. Однако отсутствие выделенных управляющих процессов, потоков и событийной ориентированности не позволяет предложить эту методику в качестве единственной.

Наилучшим способом преодоления недостатков рассмотренных методик является формирование синтетической методики, объединяющей различные этапы отдельных методик. При этом из каждой методики необходимо взять часть методологии, наиболее полно и формально изложенную, и обеспечить возможность обмена результатами на различных этапах применения синергетической методики. В бизнес-моделировании неявным образом идет формирование подобной синергетической методики.

Идея синтетической методики заключается в последовательном применении функционального и объектного подхода с учетом возможности реинжиниринга существующей ситуации.

Рассмотрим применение синтетической методики на примере разработки административного регламента.

При построении административных регламентов выделяются следующие стадии:

1. Определение границ системы. На этой стадии при помощи анализа потоков данных выделяют внешние сущности и собственно моделируемую систему.

2. Выделение сценариев использования системы. На этой стадии при помощи критерия полезности строят для каждой внешней сущности набор сценариев использования системы.

3. Добавление системных сценариев использования. На этой стадии определяют сценарии, необходимые для реализации целей системы, отличных от целей пользователей.

4. Построение диаграммы активностей по сценариям использования. На этой стадии строят набор действий системы, приводящих к реализации сценариев использования;

5. Функциональная декомпозиция диаграмм активностей как контекстных диаграмм методики IDEF0.

6. Формальное описание отдельных функциональных активностей в виде административного регламента (с применением различных нотаций ).

Моделирование бизнес-процессов средствами ERwin Моделирование бизнес процессов, как правило, выполняется с помощью CASE-средств. К таким средствам относятся BPwin - ERWin (PLATINUM technology), Silverrun (Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software) и др. Функциональные возможности инструментальных средств структурного моделирования деловых процессов будут рассмотрены на примере CASE-средства ERWin.

функциональное моделирование (IDEF0); описание бизнес-процессов (IDEF3); диаграммы потоков данных (DFD).

Инструментальная среда ERWin При запуске ERwin по умолчанию появляется основная панель инструментов, палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели — Model Explorer.

При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново или она будет открыта из файла либо из репозитория ModelMart, затем внести имя модели и выбрать методологию, в которой будет построена модель.

ERwin поддерживает три методологии — IDEF0, IDEF3 и DFD, каждая из которых решает свои специфические задачи. В ERwin возможно построение смешанных моделей, т. е. модель может содержать одновременно диаграммы как IDEF0, так и IDEF3 и DFD. Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую.

Модель в ERwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные — в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.

Построение модели IDEF Процесс моделирования системы в IDEF0 начинается с создания контекстной диаграммы — диаграммы наиболее абстрактного уровня описания системы в целом, содержащей определение субъекта моделирования, цели и точки зрения на модель.

Цель моделирования IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEF0 в ERwin следует выбрать пункт меню Model > Model Properties, вызывающий диалог Model Properties. В закладке Purpose следует внести цель и точку зрения, а в закладку Definition — определение модели и описание области.

В закладке Status того же диалога можно описать статус модели (черновой вариант, рабочий, окончательный и т. д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате).

В закладке Source описываются источники информации для построения модели (например, "Опрос экспертов предметной области и анализ документации").

Закладка General служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели — AS-IS и ТО-ВЕ.

Модели AS-IS и ТО-ВЕ. Обычно сначала строится модель существующей организации работы — AS-IS (как есть). Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) — модели новой организации бизнес-процессов. Иногда текущая AS-IS и будущая ТО-ВЕ модели очень сильно отличаются, в этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состоянию системы.

Результат описания модели можно получить в отчете Model Report.

Диалог настройки отчета по модели вызывается из пункта меню Tools > Reports > Model Report.

В диалоге настройки следует выбрать необходимые поля, при этом автоматически отображается очередность вывода информации в отчет.

И на основе выбранных параметров получить отчет Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм.

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

Модель может содержать четыре типа диаграмм:

контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма );

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

диаграммы дерева узлов ;

диаграммы только для экспозиции (FEO).

Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой.

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

диаграммы для экспозиции (FEO) строятся для иллюстрации отдельных фрагментов модели, для иллюстрации альтернативной точки зрения, либо для специальных целей.

Работы (Activity) обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников.

Все работы должны быть названы и определены.

Имя блока должно следовать следующим правилам:

Семантические правила блоков и стрелок Имя блока должно быть активным глаголом или глагольным оборотом.

Каждая сторона функционального блока должна иметь стандартное отношение блок/стрелки:

входные стрелки должны связываться с левой стороной блока;

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

выходные стрелки должны связываться с правой стороной блока;

стрелки механизма (кроме стрелок вызова) должны указывать вверх и подключаться к нижней стороне блока.

стрелки вызова механизма должны указывать вниз, подключаться к нижней стороне блока, и помечаться ссылкой на вызываемый блок При создании новой модели (меню File > New) автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом.

Пример контекстной диаграммы Если необходимо создавать новую модель, а не модернизировать старую, то после выполнения команды File > New, И задания имени модели появляется диалоговое окно в котором можно ввести основные параметры модели, к которым относится имя автора (General) Задание необходимых для отображения элементов (Display) Единиц измерения (ABC Units) Размеров страницы (Page setup) И данных, отображаемых в колонтитулах (Header/Footer) После этого открывается контекстная диаграмма, предсталенная блоком Чтобы внести ее название необходимо дважды щелкнуть по ней левой клавишей мыши (2лкм), после чего откроется диалоговое окно в котором необходимо указать основные параметры диаграммы.

Следующее действие связано с тем, что Erwin был разработан в первую очередь для американских потребителей и если сразу нажать Ок, то текст на модели будет нечитаемым.

Поэтому, необходимо постоянно переходить во вкладку Fonts и задавать и сейчас и в дельнейшем тип шрифта – Кириллический или писать на английском языке.

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

При желании и для лучшего визуального отображения элементов диаграмм, можно заходить во вкладку Color, в которой можно выбрать цвет для шрифта, для фона шрифта и для диаграммы.

Для того, чтобы добавить входную стрелку, необходимо воспользоваться инструментом Precedence Arrow Tool (РАТ) и с ее помощью нарисовать стрелки, отвечающие за объекты, поступающие на вход ОУ, на выход, ограничивающие и руководящие параметры и механизмы.

Для этого, после выбора инструмента РАТ, наведите курсор мыши на левую границу листа модели, после того, как область выделится, щелкните левой клавишей мышки (лкм) и подведите к левой части блока И снова щелкните лкм Появится стрелка. Аналогичным образом, добавляются другие стрелки.

Для того, чтобы задать параметры стрелок, необходимо выбрать Pointer Tool (РТ – стрелка) и по стрелке с которой необходимо работать 2лкм. После чего внести название стрелки во вкладке Name.

Во вкладке Style есть возможность задать толщину и тип стрелки.

Если речь идет про явные ссылки и IEDF0, то менять тип стрелок не надо. После нажатия на ОК появится название стрелки, но это название будет нечитабельным. Для того, чтобы его изменить, необходимо по названию стрелки 2лкм и во вкладке Font снова задать тип шрифта Кириллический, а во вкладке Color – цвет стрелки и текста. Имена вновь внесенных стрелок автоматически заносятся в словарь Arrow Dictionary.

Диаграммы декомпозиции содержат родственные работы, т. е.

дочерние работы, имеющие общую родительскую работу. Для создания диаграммы декомпозиции следует щелкнуть по кнопке на панели инструментов.

Возникает диалог Activity Box Count в котором следует указать нотацию новой диаграммы и количество работ на ней. Выберите нотацию IDEF0 и щелкните ОК и количество основных видов работ.

Появляется диаграмма декомпозиции. Допустимый интервал числа работ — 4(от 2 до 8).

Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от трех до шести блоков на одной диаграмме. Аналогично предыдущей диаграмме, необходимо поменять шрифты у стрелок. Сами стрелки можно перемещать при помощи РТ. При желании можно отдельно перемещать надписи для лучшей читаемости диаграммы. На приведенном выше рисунке стрелки являются несвязанными.

Чтобы их связать с нужными блоками работы, необходимо и подписать блоки, и перетащить стрелки. Также при помощи инструмента РТ можно увеличивать, уменьшать и перетаскивать блоки на диаграмме.

Работы на диаграммах декомпозиции обычно располагаются по диагонали от левого верхнего угла к правому нижнему. Такой порядок называется порядком доминирования. Согласно этому принципу расположения в левом верхнем углу располагается самая важная работа или работа, выполняемая по времени первой. Далее вправо вниз располагаются менее важные или выполняемые позже работы. Такое расположение облегчает чтение диаграмм, кроме того, на нем основывается понятие взаимосвязей работ.

Чтобы присоединить стрелки к нужным блокам их можно просто дорисовать или щлкнув лкм по острию или «хвостику» стрелки (в зависимости от ее положения) и указать нужный блок диаграммы.

Теперь надо разобраться с типами стрелок внутри декомпозиции и как эти стрелки нужно применять.

Синтаксические правила Размеры блоков должны быть достаточными для того, чтобы включить имя блока.

Блоки должны быть прямоугольными, с прямыми углами.

Блоки должны быть нарисованы сплошными линиями.

Ломаные стрелки изменяют направление только под углом 90 град.

Стрелки должны быть нарисованы сплошными линиями различной толщины.

Стрелки могут состоять только из вертикальных или горизонтальных отрезков; отрезки, направленные по диагонали, не допускаются.

4. Концы стрелок должны касаться внешней границы функционального блока, но не должны пересекать ее.

5.Стрелки должны присоединяться к блоку на его сторонах.

Присоединение в углах не допускается.

Ломаный сегмент стрелки и дуга сопряжения –90 град.

Стрелки как ограничения.

Стрелки на диаграмме IDEF0, представляя данные или материальные объек ты, одновременно задают своего рода ограничения (условия).

Входные и управляющие стрелки блока, соединяющие его с другими блоками или с внешней средой, по сути описывают условия, которые должны быть выполнены для того, чтобы реализовалась функция, записанная в качестве имени блока.

Рисунок, приведенный выше, иллюстрирует случай, при котором "функция 3" может быть выполнена только после получения данных, выработанных "функцией 1" и "функцией 2" Параллельное функционирование.

Различные функции в модели могут быть выполнены параллельно, если удовлетворяются необходимые ограничения (условия). Один блок может создать данные или материальные объекты, необходимые для параллельной работы нескольких блоков.

Ветвление и слияние сегментов стрелок Ветвление и слияние стрелок призвано уменьшить загруженность диаграмм графическими элементами (линиями). Чтобы стрелки и их сегменты правильно описывали связи между блоками - источниками и блоками - потребителями, используется аппарат меток. Метки связываются с сегментами посредством тильд. При этом между сегментами возникают определенные отношения, описанные ниже:

непомеченные сегменты содержат все объекты, указанные в метке стрелки перед ветвлением (т.е. все объекты принадлежат каждому из сегментов);

сегменты, помеченные после точки ветвления, содержат все объекты, указанные в метке стрелки перед ветвлением, или их часть, описываемую меткой каждого конкретного сегмента;

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

при слиянии помеченных сегментов объединенный сегмент содержит все или некоторые объекты, принадлежащие сливаемым сегментам и перечисленные в общей метке после слияния; если общая метка после слияния отсутствует, это означает, что общий сегмент передает все объекты, принадлежащие сливаемым сегментам;

Отношения блоков на диаграммах.

В методологии IDEF0 существует 6 (шесть) типов отношений между блоками в пределах одной диаграммы:

• доминирование;

• управление;

• обратная связь по управлению;

• обратная связь по входу;

• выход – механизм.

Первое из перечисленных отношений определяется взаимным расположением блоков на диаграмме. Предполагается, что блоки, расположенные на диаграмме выше и левее, «доминируют» над блоками, расположенными ниже и правее. «Доминирование» понимается как влияние, которое один блок оказывает на другие блоки диаграммы.

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

Отношения управления и выход – вход являются простейшими, поскольку отражают прямые взаимодействия, которые понятны и очевидны.

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

Отношение выход – вход возникает при соединении выхода одного блока с входом другого блока с меньшим доминированием.

Обратная связь по управлению и обратная связь по входу являются более сложными типами отношений, поскольку они представляют итерацию (выход функции влияет на будущее выполнение других функций с большим доминированием, что впоследствии влияет на исходную функцию).

Обратная связь по управлению возникает тогда, когда выход некоторого блока создает управляющее воздействие на блок с большим доминированием.

Отношение обратной связи по входу имеет место тогда, когда выход блока становиться входом другого блока с большим доминированием.

Связи «выход – механизм» отражают ситуацию, при которой выход одной функции становиться средством достижения цели для другой. Связи «выход – механизм» возникают при отображении в модели процедур пополнения и распределения ресурсов, создания или подготовки средств для выполнения функций системы (например, приобретение или изготовление требуемых инструментов и оборудования, обучение персонала, организация физического пространства,, финансирование, закупка материалов и т.д.).

Отношения между блоками диаграммы и другими диаграммами (окружающей средой).

Все описанные выше отношения отображаются внутренними стрелками, т.е. такими, у которых оба конца связаны с блоками диаграммы.

Отношения между блоками диаграммы и другими диаграммами, являющимися по отношению к рассматриваемой диаграмме окружающей средой (окружением), описываются граничными стрелками.

Граничные стрелки.

На обычной (не контекстной) диаграмме граничные стрелки представляют входы, управления, выходы или механизмы родительского блока диаграммы. Источник или потребитель граничных стрелок можно обнаружить, только изучая родительскую диаграмму. Все граничные стрелки на дочерней диаграмме (за исключением стрелок, помещенных в тоннель) должны соответствовать стрелкам родительского блока.

Стрелки, помещенные в «туннель».

Туннель - круглые скобки в начале и/или окончании стрелки.

Туннельные стрелки означают, что данные, выраженные этими стрелками, не рассматриваются на родительской диаграмме и/или на дочерней диаграмме.

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

Кроме этого, необходимо знать дополнительные правила составления диаграмм.

Дополнительные правила составления диаграмм Имена блоков (выполняемых функций) и метки стрелок должны быть уникальными. Если метки стрелок совпадают, это значит, что стрелки отображают тождественные данные.

При наличии стрелок со сложной топологией целесообразно повторить метку для удобства ее идентификации.

Следует обеспечить максимальное расстояние между блоками и поворотами стрелок, а также между блоками и пересечениями стрелок для облегчения чтения диаграммы. Одновременно уменьшается вероятность перепутать две разные стрелки.

Блоки всегда должны иметь хотя бы одну управляющую и одну выходную стрелку, но могут не иметь входных стрелок.

Если одни и те же данные служат и для управления, и для входа, вычерчивается только стрелка управления. Этим подчеркивается управляющий характер данных и уменьшается сложность диаграммы.

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

Стрелки связываются (сливаются), если они представляют сходные данные и их источник не указан на диаграмме Обратные связи по управлению должны быть показаны как "вверх и над". Обратные связи по входу должны быть показаны как "вниз и под". Так же показываются обратные связи посредством механизма. Таким образом обеспечивается показ обратной связи при минимальном числе линий и пересечений.

Циклические обратные связи для одного и того же блока изображаются только для того, чтобы их выделить. Обычно обратную связь изображают на диаграмме, декомпозирующей блок. Однако иногда требуется выделить повторно используемые объекты.

Стрелки объединяются, если они имеют общий источник или приемник, или они представляют связанные данные. Общее название лучше описывает суть данных. Следует минимизировать число стрелок, касающихся каждой стороны блока.

Если возможно, стрелки присоединяются к блокам в одной и той же позиции. Тогда соединение стрелок конкретного типа с блоками будет согласованным и чтение диаграммы упростится.

При соединении большого числа блоков необходимо избегать необязательных пересечений стрелок. Следует минимизировать число петель и поворотов каждой стрелки.

Блоки (функции) являются сопряженными через среду, если они имеют связи с источником, генерирующим данные, без конкретного определения отношения отдельной части данных к какому-либо блоку.

Две или более функций являются сопряженными через запись, если они связаны с набором данных и не обязательно зависят от того, представлены ли все возможные интерфейсы как сопряжение через среду.

Необходимо использовать (где это целесообразно) выразительные возможности ветвящихся стрелок.

Добавление или удаление элементов на диаграмме Если оказывается, что количество работ недостаточно, то работу можно добавить в диаграмму, щелкнув сначала по кнопке Activity Box Tool (АВТ) на палитре инструментов, а затем по свободному месту на диаграмме.

Если элемент необходимо удалить, то достаточно его выделить и нажать Del. Аналогичным образом можно добавлять и убирвать стрелки. Для блокоы деятельнсти есть еще один способ. Необходимо щекнуть правой клавишей мышки (пкм) по конектстому меню работ в левой части экрана и выбрать Insert Before или Insert After Для того, чтобы добавить ветвление к стрелке, необходимо нарисовать новую стрелк при помощи инструмента РAT Затем инструментом АТ перенести или хвостик стрелки или ее окончание в зависимости о той задачи которая была поставлена.

При этом стоит учитывать, что Неправильный вариант стрелки.

Правильный вариант стрелки.

Например первый уровень декомпозиции ИСО может выглядеть следующим образом:

ICOM-коды Диаграмма декомпозиции предназначена для детализации работы. В отличие от моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в IDEF0 — это не элемент управления нижестоящими работами. Работы нижнего уровня — это то же самое, что работы верхнего уровня, но в более детальном изложении. Как следствие этого границы работы верхнего уровня — это то же самое, что границы диаграммы декомпозиции. ICOM (аббревиатура от Input, Control, Output и Mechanism) — коды, предназначенные для идентификации граничных стрелок. Код ICOM содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер. ERwin вносит ICOM-коды автоматически.

Для отображения ICOM-кодов следует включить опцию ICOM codes на закладке Display диалога Model Properties (меню Model > Model Properties) Словарь стрелок редактируется при помощи специального редактора Arrow Dictionary Editor, в котором определяется стрелка и вносится относящийся к ней комментарий.

Содержимое словаря стрелок можно распечатать в виде отчета (меню Tools > Report > Arrow Report...) и получить толковый словарь терминов предметной области, использующихся в модели.

Туннелирование стрелок Для "перетаскивания" стрелок наверх нужно щелкнуть пкм по квадратным скобкам граничной стрелки и в контекстном меню выбрать команду Arrow Tunnel.

Появляется диалог Border Arrow Editor.

Если щелкнуть по кнопке Resolve Border Arrow, стрелка мигрирует на диаграмму верхнего уровня, если по кнопке Change To Tunnel — стрелка будет туннелирована и не попадет на другую диаграмму.

Туннелирование может быть применено для изображения малозначимых стрелок. Другим примером туннелирования может быть ситуация, когда стрелка механизма мигрирует с верхнего уровня на нижний, причем на нижнем уровне этот механизм используется одинаково во всех работах без исключения. (Предполагается, что не нужно детализировать стрелку механизма, т. е. стрелка механизма на дочерней работе именована до разветвления, а после разветвления ветви не имеют собственного имени). В этом случае стрелка механизма на нижнем уровне может быть удалена, после чего на родительской диаграмме она может быть туннелирована, а в комментарии к стрелке или в словаре можно указать, что механизм будет использоваться во всех работах дочерней диаграммы декомпозиции. Такое туннелирование называется "не-в-дочерней-работе".

Диаграммы дерева узлов и FEO Диаграмма деревьев узлов показывает иерархию работ в модели и позволяет рассмотреть всю модель целиком, но не показывает взаимосвязи между работами.Процесс создания модели работ является итерационным, следовательно, работы могут менять свое расположение в дереве узлов многократно. Чтобы не запутаться и проверить способ декомпозиции, следует после каждого изменения создавать диаграмму дерева узлов. ERwin имеет мощный инструмент навигации по модели — Model Explorer, который позволяет представить иерархию работ и диаграмм в удобном и компактном виде.

Для создания диаграммы дерева узлов следует выбрать в меню пункт Diagram > Add Node Tree. Возникает диалог формирования диаграммы дерева узлов Node Tree Definition В диалоге Node Tree Definition следует указать глубину дерева — Number of Levels (по умолчанию — 3) и корень дерева (по умолчанию — родительская работа текущей диаграммы). По умолчанию нижний уровень декомпозиции показывается в виде списка, остальные работы — в виде прямоугольников. Для отображения всего дерева в виде прямоугольников следует выключить опцию Bullet Last Level. При создании дерева узлов следует указать имя диаграммы, поскольку, если в нескольких диаграммах в качестве корня на дереве узлов использовать одну и ту же работу, все эти диаграммы получат одинаковый номер (номер узла + постфикс N, например AON) и в списке открытых диаграмм (пункт меню Window) их можно будет различить только по имени.

Диаграммы "только для экспозиции" (FEO) часто используются в модели для иллюстрации других точек зрения, для отображения отдельных деталей, которые не поддерживаются явно синтаксисом IDEF0. Диаграммы FEO позволяют нарушить любое синтаксическое правило, поскольку по сути являются просто картинками — копиями стандартных диаграмм и не включаются в анализ синтаксиса. Для создания диаграммы FEO следует выбрать пункт меню Diagram > Add FEO Diagram. В возникающем диалоге Add New FEO Diagram следует указать имя диаграммы FEO и тип родительской диаграммы.

Новая диаграмма получает номер, который генерируется автоматически (номер родительской диаграммы по узлу + постфикс F, например A1F ).

Слияние и расщепление моделей Возможность слияния и расщепления моделей обеспечивает коллективную работу над проектом. Так, руководитель проекта может создать декомпозицию верхнего уровня и дать задание аналитикам продолжить декомпозицию каждой ветви дерева в виде отдельных моделей.

После окончания работы над отдельными ветвями все подмодели могут быть слиты в единую модель. С другой стороны, отдельная ветвь модели может быть отщеплена для использования в качестве независимой модели, для доработки или архивирования.

Поля подвала каркаса (слева направо) Номер узла диаграммы (номер родительской работы ) Node Имя диаграммы. По умолчанию — имя родительской работы Title C-Number, уникальный номер версии диаграммы Number Номер страницы, может использоваться как номер страницы Page при формировании папки Слияние и расщепление модели Эта функция позволяет обеспечить коллективную работу над проектом или если нет необходимости вести работу со всей моделью целиком, то можно вычленить отдельную диаграмму и продолжить работу только с ней, а потом при необходимости слить ее с основной моделью.Для этого необходимо сделать следующее:

- Перейти на родительскую диаграмму.

- Кликнуть правой клавишей мыши на блоке действий и выбрать из контекстного меню Split Model - В появившемся диалоговом окне ввести имя новой модели и нажать ОК:

Флажок "Copy entire dictionaries" означает, что будут скопированы все словари из модели-источника в модель-приемник. Флажок "Enable Marge/Overwrite Option" позволяет при слиянии переписать данные из диаграммы-источника в диаграмму-приемник.

Если стрелка вызова была не сделана, то она будет создана.

Чтобы произвести слияние моделей, необходимо:

Открыть обе модели (приемник и источник) в.

Кликнуть правой клавишей мыши на стрелке вызова и выбрать "Merge Model…":

- В открывшемся диалоговом окне определяются параметры слияния:

Cut/Paste entire dictionaries - установка этого флажка обеспечит слияние всех имен, содержащихся в словарях модели-источника.

Overwrite existing fields - свойств объектов будут переписаны в соответствии с данными диаграммы источника.

Rename matching arrows - выбор этого флажка позволит добавить знак "~" для дублирующихся имен объектов.

Rename matching data stores - выбор этого флажка позволит добавить знак "~" для дублирующихся имен данных (только для DFD).

Rename matching externals - выбор этого флажка позволит добавить знак "~" для дублирующихся имен ссылок.

- При нажатии на кнопку ОК произойдет сливание моделей, причем модель-источник останется Диаграммы IDEF Используя декомпозицию, можно использовать диаграммы в нотации IDEF3, выбрав тип диаграммы декомпозиции.

Данная методика предназначена для моделирования сценариев.

Единицы работы — Unit of Work (UOW) — также называемые работами (activity), являются центральными компонентами модели. В IDEF работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы, и номер (идентификатор); другое имя существительное в составе той же фразы обычно отображает основной выход (результат) работы (например, "Изготовление изделия").

Связи показывают взаимоотношения работ. Все связи в IDEF однонаправлены и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо. В IDEF3 различают три типа стрелок, изображающих связи, стиль которых устанавливается через меню Edit/Arrow Style:

Старшая (Precedence) сплошная линия, связывающая единицы работ (UOW). Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется.

Отношения (Relational Link) пунктирная линия, использующаяся для изображения связей между единицами работ (UOW) а также между единицами работ и объектами ссылок.

Потоки объектов (Object Flow) стрелка с двумя наконечниками, применяется для описания того факта, что объект используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой.

Старшая связь показывает, что работа-источник заканчивается ранее, чем начинается работа-цель. Часто результатом работы-источника становится объект, необходимый для запуска работы-цели. В этом случае стрелку, обозначающую объект, изображают с двойным наконечником. Имя стрелки должно ясно идентифицировать отображаемый объект. Поток объектов имеет ту же семантику, что и старшая стрелка.

Отношение показывает, что стрелка является альтернативой старшей стрелке или потоку объектов в смысле задания последовательности выполнения работ — работа-источник не обязательно должна закончиться, прежде чем работа-цель начнется. Более того, работа-цель может закончиться прежде, чем закончится работа-источник.

Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы, используются перекрестки (Junction). Различают перекрестки для слияния (Fan-in Junction) и разветвления стрелок (Fan-out Junction). Перекресток не может использоваться одновременно для слияния и для разветвления.

Смысл каждого типа приведен в таблице.

Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Junction Properties, который вызывается в контекстном меню перекрестка командой Definition / Note. В отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки.

Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой.

. Имя объекта ссылки задается в диалоге Referent (пункт Name контекстного меню), в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок — безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous). ERwin поддерживает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используемые в диаграммах переходов состояний объектов, не поддерживаются.

Таблица. Типы перекрестков При внесении объектов ссылок помимо имени следует указывать тип объекта ссылки.

В IDEF3 декомпозиция используется для детализации работ.

Методология IDEF3 позволяет декомпозировать работу многократно, т. е.

работа может иметь множество дочерних работ. Это позволяет в одной модели описать альтернативные потоки. Возможность множественной декомпозиции предъявляет дополнительные требования к нумерации работ.

Так, номер работы состоит из номера родительской работы, версии декомпозиции и собственного номера работы на текущей диаграмме.

Таблица/ Типы объектов ссылок объекта ссылки

OBJECT

Инструмент циклического перехода (в повторяющейся GOTO последовательности работ), возможно на текущей диаграмме, но не обязательно. Если все работы цикла присутствуют на текущей диаграмме, цикл может также изображаться стрелкой, возвращающейся на стартовую работу. GOTO UOB (Unit of множественное использование какой-либо работы, но без behaviour) цикла. Например, работа "Контроль качества" может быть использована в процессе "Изготовление изделия" несколько раз, после каждой единичной операции. Обычно этот тип ссылки не используется для моделирования автоматически NOTE информации, относящейся к каким-либо графическим объектам на диаграмме. NOTE является альтернативой внесению текстового объекта в диаграмму Используется для усовершенствования графиков или ELAB их более детального описания. Обычно употребляется для (Elaboration) детального описания разветвления и слияния стрелок на В результате дополнения диаграмм IDEF0 диаграммами DFD и IDEF может быть создана смешанная модель, которая наилучшим образом описывает все стороны деятельности ОУ. Иерархию работ в смешанной модели можно увидеть в окне Model Explorer. Модели в нотации IDEF изображаются зеленым цветом, в IDEF3 — желтым, в DFD — голубым.

Как видно из изображения, вид функционального блока несколько отличается от его представления в методике IDEF0. Также появились логические элементы. Они могут быть отображены при вставке логической операции:

Кроме функциональных и логических блоков, так же методика IDEF содержит блок ссылки (Referent):

А из новых элементов Логический блок Блок ссылки Оба типа блоков добавляются через меню.

Диаграммы потоков данных Диаграммы потоков данных (Data Flow Diagramming) являются основным средством моделирования функциональных требований к проектируемой системе. Требования представляются в виде иерархии процессов, связанных потоками данных. Диаграммы потоков данных показывают, как каждый процесс преобразует свои входные данные в выходные, и выявляют отношения между этими процессами. DFDдиаграммы успешно используются как дополнение к модели IDEF0 для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет моделируемую систему как сеть связанных работ. Основные компоненты DFD – процессы или работы, внешние сущности, потоки данных, накопители данных (хранилища).

В ERwin для построения диаграмм потоков данных используется нотация Гейна-Сарсона.

Для того чтобы дополнить модель IDEF0 диаграммой DFD, нужно в процессе декомпозиции в диалоге Activity Box Count "кликнуть" по кнопке DFD.

В палитре инструментов на новой диаграмме DFD появляются новые кнопки:

( External Reference ) — добавить в диаграмму внешнюю ссылку;

( Data store ) — добавить в диаграмму хранилище данных ;

Diagram Dictionary Editor – ссылка на другую страницу. В отличие от IDEF0 этот инструмент позволяет направить стрелку на любую диаграмму (а не только на верхний уровень).

В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы — движение объектов, хранение объектов, поставка и распространение объектов.

В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов.

Контекстная диаграмма часто включает работы и внешние ссылки. Работы обычно именуются по названию системы, например "Система обработки информации". Включение внешних ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему.

В DFD работы ( процессы ) представляют собой функции системы, преобразующие входы в выходы. Хотя работы изображаются прямоугольниками со скругленными углами, смысл их совпадает со смыслом работ IDEF0 и IDEF3. Так же, как процессы IDEF3, они имеют входы и выходы, но не поддерживают управления и механизмы, как IDEF0.

Внешние сущности изображают входы в систему и/или выходы из системы. Внешние сущности изображаются в виде прямоугольника с тенью и обычно располагаются по краям диаграммы Потоки работ изображаются стрелками и описывают движение объектов из одной части системы в другую. Поскольку в DFD каждая сторона работы не имеет четкого назначения, как в IDEF0, стрелки могут подходить и выходить из любой грани прямоугольника работы. В DFD также применяются двунаправленные стрелки для описания диалогов типа "команда-ответ" между работами, между работой и внешней сущностью и между внешними сущностями. В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое.

В материальных системах хранилища данных изображаются там, где объекты ожидают обработки, например в очереди. В системах обработки информации хранилища данных являются механизмом, который позволяет сохранить данные для последующих процессов.

В DFD стрелки могут сливаться и разветвляться, что позволяет описать декомпозицию стрелок. Каждый новый сегмент сливающейся или разветвляющейся стрелки может иметь собственное имя. Диаграммы DFD могут быть построены с использованием традиционного структурного анализа, подобно тому, как строятся диаграммы IDEF0.

В DFD номер каждой работы может включать префикс (A), номер родительской работы и номер объекта. Номер объекта — это уникальный номер работы на диаграмме. Например, работа может иметь номер А.12.4.

Уникальный номер имеют хранилища данных и внешние сущности независимо от их расположения на диаграмме. Каждое хранилище данных имеет префикс D и уникальный номер, например D5. Каждая внешняя сущность имеет префикс Е и уникальный номер, например Е5.

Генерация кода в Visual Basic ERwin поддерживает генерацию кода в Visual Basic версий 4.0 и 5.0. В качестве источника информации при генерации форм служит модель ERwin.

С помощью ERwin можно одновременно описывать как клиентскую часть (объекты, отображающие данные на экране), так и сервер БД (процедуры и триггеры ), тем самым оптимально распределяя функциональность ИС между клиентской и серверной частью. Компонент ERwin Form Wizard автоматически проектирует формы с дочерними объектами – кнопками, списками, полями, радиокнопками и т. д., используя расширенные атрибуты.

Совместное использование ERwin и Visual Basic позволяет сократить жизненный цикл разработки ИС путем употребления для каждой задачи наиболее эффективного инструмента. Visual Basic может быть использован для проектирования визуального интерфейса, а ERwin – для разработки физической и логической модели данных с последующей генерацией системного каталога сервера. Если БД уже существует, то с помощью ERwin можно провести обратное проектирование, полученную модель дополнить расширенными атрибутами и сгенерировать клиентское приложение.

Создание отчетов Для генерации отчетов в ERwin имеется простой и эффективный инструмент – Report Browser. По умолчанию Report Browser содержит предварительно определенные отчеты, позволяющие наглядно представить информацию об основных объектах модели данных – как логической, так и физической. С помощью специального редактора существующие отчеты можно изменить или создать собственный отчет. Каждый отчет может быть настроен индивидуально, данные в нем могут быть отсортированы и отфильтрованы. Browser Report позволяет сохранять результаты выполнения отчетов, печатать и экспортировать их в распространенные форматы.

Генерация словарей Для управления большими проектами ERwin имеет специальный инструмент – ERwin Dictionary, который обеспечивает коллективную работу над диаграммами и позволяет сохранять и документировать различные версии моделей данных. ERwin Dictionary представляет собой специальную БД, которая позволяет решить проблемы документирования и хранения моделей, однако не полностью отвечает требованиям многопользовательской работы.

Моделирование UML Вторым подходом к разработке ИСО является моделирование на универсальном языке UML, который использует объектный подход и может в совокупности с описанием бизнес – процессов является необходимым дополнением. Одной из наиболее известных программ для описания систем на языке UML является программа IBM Rational Rose. Являясь объектноориентированным инструментом моделирования, Rose базируется на UML (Universal Modeling Language) - универсальном языке моделирования, который был разработан компанией Rational именно с целью создания наиболее оптимального и универсального языка для описания как предметной области, так и конкретной задачи в программировании. Любая задача программируется при помощи определенных диаграмм. UML поддерживает построение следующих диаграмм:

Activity diagram (диаграммы описаний технологий, процессов, Use case diagram (диаграммы функций).

Class diagram (диаграммы классов).

State diagram (диаграммы состояний);

Sequence diagram (диаграммы последовательностей действий);

Collaboration diagram (диаграммы взаимодействий Component diagram (диаграммы компонент);

Deployment diagram (диаграммы топологии).

3. ПРОЕКТИРОВАНИЕ АРХИТЕКТУРЫ ИСО

IBM Rational Rose CASE-средство IBM Rational Rose со времени своего появления претерпело серьезную эволюцию, и в настоящее время представляет собой современный интегрированный инструментарий для проектирования архитектуры, анализа, моделирования и разработки программных систем.

Именно в IBM Rational Rose язык UML стал базовой технологией визуализации и разработки программных систем, что определило популярность и стратегическую перспективность этого инструментария.

В рамках общего продукта IBM Rational Rose существуют различные варианты этого средства, отличающиеся между собой диапазоном предоставляемых возможностей. Базовым средством в настоящее время является IBM Rational Rose Enterprise Edition, которое обладает наиболее полными возможностями. Наиболее характерные функциональные особенности этой программы заключаются в следующем:

интеграция с MS Visual Studio 6, которая включает поддержку на уровне прямой и обратной генерации кодов и диаграмм Visual Basic и Visual С++ с использованием ATL (Microsoft Active Template Library), Web-Классов, DHTML и протоколов доступа к различным базам непосредственная работа (инжиниринг и реинжиниринг) с исполняемыми модулями и библиотеками форматов EXE, DLL, TLB, поддержка технологий MTS (Microsoft Transaction Server) и ADO (ActiveX Data Objects) на уровне шаблонов и исходного кода, а также элементов технологии Microsoft - COM+ (DCOM);

полная поддержка компонентов CORBA и J2EE, включая реализацию технологии компонентной разработки приложений CBD (ComponentBased Development), языка определения интерфейса IDL (Interface Definition Language) и языка определения данных DDL (Data Definition Language);

полная поддержка среды разработки Java-приложений, включая прямую и обратную генерацию классов Java формата JAR, а также работу с файлами формата CAB и ZIP.

Интерфейс программы IBM Rational Rose В CASE-средстве IBM Rational Rose реализованы общепринятые стандарты на рабочий интерфейс программы, аналогично известным средам визуального программирования. После запуска программы появляется диалоговое окно в котором уточняется под какой язык программирования ведется разработка ИСО.

Рабочий интерфейс программы IBM Rational Rose состоит из различных элементов, основными из которых являются:

главное меню;

стандартная панель инструментов;

специальная панель инструментов;

окно браузера проекта;

рабочая область изображения диаграммы или окно диаграммы;

окно документации;

окно журнала.

В данном случае, был выбран один из шаблонов программирования и в проекте сразу появилось три элемента.

Разработка диаграммы вариантов использования и редактирование свойств ее элементов Для вновь создаваемого проекта можно воспользоваться мастером типовых проектов, если он установлен в данной конфигурации. Мастер типовых проектов доступен из меню File>New или при первоначальной загрузке программы. В случае разработки проекта, для которого не известна или не выбрана технология его реализации, следует отказаться от мастера, в результате чего появится рабочий интерфейс программы IBM Rational Rose с чистым окном активной диаграммы классов и именем проекта untitled по умолчанию.

IBM Rational Rose позволяет настраивать глобальные параметры среды, такие как выбор шрифтов и цвета для представления различных элементов модели. Настройка шрифтов, цвета линий и графических элементов производится через операцию главного меню: Tools>Options.

Характерной особенностью среды является возможность работы с символами кириллицы.

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

Для разработки диаграммы вариантов использования модели необходимо активизировать соответствующую диаграмму в окне диаграммы.

Это можно сделать следующими способами:

раскрыть представление вариантов использования Use Case View в браузере проекта и дважды щелкнуть на пиктограмме Main (Главная);

с помощью операции главного меню Browse>Use Case Diagram Появляется диалоговое окно, а затем новое окно с чистым рабочим листом диаграммы вариантов использования и специальная панель инструментов, содержащая кнопки с изображением графических элементов, необходимых для разработки диаграммы вариантов использования.

Таблица Назначение кнопок специальной панели инструментов для диаграммы вариантов использования изображение На специальной панели инструментов по умолчанию присутствует только часть кнопок с пиктограммами элементов, которые могут быть использованы для построения диаграммы. Добавить кнопки с пиктограммами других графических элементов, например, таких как бизнес-вариант использования (business use case), бизнес-актер (business actor), сотрудник (business worker), или удалить ненужные кнопки можно с помощью настройки специальной панели инструментов. Открыть диалоговое окно настройки специальных панелей инструментов для диаграмм в среде IBM Rational Rose можно с помощью операции главного меню: Tools>Options, раскрыв вкладку Toolbars и нажав соответствующую кнопку (например, Use Case diagram) в группе опций Customize Toolbars. Это окно настройки также можно открыть с помощью операции контекстного меню Customize при позиционировании курсора на специальной панели инструментов.

Для добавления необходимых кнопок на панель следует выделить их в левом окне со списком пиктограмм графических элементов, после чего нажать кнопку Добавить в центре диалогового окна. Для удаления ненужных кнопок с панели инструментов следует выделить их в правом окне со списком пиктограмм графических элементов, после чего нажать кнопку Удалить в центре диалогового окна. Для восстановления набора пиктограмм по умолчанию можно нажать кнопку Сброс. После настройки специальной панели инструментов соответствующее окно следует закрыть нажатием на кнопку Закрыть.

Добавление актера на диаграмму вариантов использования и редактирование его свойств Для добавления актера на диаграмму варианта использования нужно нажать лкм кнопку с изображением пиктограммы актера на специальной панели инструментов, и щелкнуть лкм на свободном месте рабочего листа диаграммы. На диаграмме появится изображение актера с маркерами изменения его геометрических размеров и предложенным программой именем по умолчанию NewClass.

Имя размещенного на диаграмму элемента разработчик может изменить либо сразу после добавления элемента на диаграмму, либо в ходе последующей работы над проектом.

Чтобы изменить атрибуты графического элемента, необходимо по нему щелкнуть ПКМД и выбрать пункт Open Specification. В этом случае появляется дополнительное диалоговое окно со специальными вкладками, в поля ввода которых можно занести всю информацию по данному элементу.

Открыть диалоговое окно спецификации свойств любого элемента модели можно также 2лкм.

Для актера можно уточнить его назначение в модели. С этой целью следует изменить его стереотип и добавить текст документации. Для изменения стереотипа во вложенном списке Stereotype нужно выбрать строку Business Actor (бизнес-актер). Для добавления текста документации в секцию Documentation следует ввести текст: "Любое физическое лицо, пользующееся услугами системы ДО" и нажать кнопку Apply или OK. После изменения данных свойств актера Клиент Банкомата окно спецификации свойств будет выглядеть следующим образом.

Добавление и редактирование варианта использования Для добавления варианта использования на диаграмму нужно нажать лкм кнопку с изображением варианта использования на специальной панели инструментов и щелкнуть лкм на свободном месте диаграммы. На диаграмме появится изображение варианта использования с именем по умолчанию NewUseCase. Для разрабатываемой модели имя варианта использования следует изменить на Оплата образовательных услуг.

Для уточнения свойств данного варианта использования надо открыть диалоговое окно спецификации его свойств. Для изменения стереотипа во вложенном списке Stereotype нужно выбрать строку Business Use Case. Для добавления текста документации в секцию Documentation следует ввести текст и нажать кнопку Apply или OK.

Добавление ассоциации Для добавления ассоциации между актером и вариантом использования на диаграмму нужно лкм нажать на специальной панели инструментов кнопку с изображением пиктограммы направленной ассоциации и щелкнуть лкм на изображении актера на диаграмме и отпустить ее на изображении варианта использования. В результате этих действий на диаграмме появится изображение ассоциации, соединяющей актера с вариантом использования.

При необходимости можно сделать направленную ассоциацию ненаправленной, для чего следует воспользоваться диалоговым окном свойств ассоциации. Открыть это окно можно, двойным щелчком лкм на изображении линии ассоциации на диаграмме, после чего убрать отметку строки выбора Navigable (Навигация) на вкладке Role A Detail (Детальные свойства концевой точки ассоциации А).

Добавление отношения зависимости и редактирование его свойств Для добавления отношения зависимости между двумя вариантами использования на диаграмму необходимо предварительно рассмотренным выше способом добавить второй вариант использования с именем Проверка логина и пароля. После этого нажать кнопку с изображением пиктограммы зависимости на специальной панели инструментов, и щелкнуть лкм на изображении варианта использования Оплата образовательных услуг и отпустить ее на изображении варианта использования «проверка логина и пароля». В результате этих действий на диаграмме появится изображение отношения зависимости, которое соединяет два выбранных варианта использования.

Поскольку вариант использования «проверка логина и пароля»-кода выполняется всегда, для добавленного отношения зависимости дополнительно следует указать текстовый стереотип.

Выполнить это можно с помощью диалогового окна спецификации свойств этого отношения и выбора нужного стереотипа из предлагаемого списка.

После задания для данного отношения зависимости стереотипа текст этого стереотипа в угловых скобках появится рядом с изображением пунктирной линии зависимости, связывающей соответствующие варианты использования. С целью лучшей визуализации диаграммы текстовую область стереотипа можно переместить в нужное место диаграммы.

Аналогичным образом могут быть добавлены на диаграмму вариантов использования отношения зависимости со стереотипом, которые применяются для моделирования исключений при выполнении отдельных вариантов использования.

Построение сценария диаграммы вариантов использования К отдельному варианту использования можно добавить текстовый файл с описанием сценария его выполнения. Для этого необходимо выделить этот вариант использования в браузере проекта и выполнить операцию контекстного меню: New>File. В результате этого будет вызвано стандартное окно открытия файла в котором необходимо задать имя предварительно созданного с помощью MS Word файла. После нажатия кнопки Открыть пиктограмма добавленного файла появится в браузере проекта ниже соответствующего варианта использования. В последующем можно вернуться к редактированию этого файла сценария, выполнив двойной щелчок лкм на этой пиктограмме.

Для окончательного построения диаграммы варианта использования для рассматриваемой модели оплаты услуг в системе ДО следует выполнить следующие действия:

1. Добавить актера с именем Система ДО, для которого выбрать стереотип Service (Сервис) или Business Entity, означающий, что ИСО использует некоторые услуги в качестве сервиса.

2. Добавить вариант использования Получение справки о состоянии счета обучения, для которого выбрать стереотип Business Use Case (Бизнесвариант использования).

3. Добавить вариант использования Приостановление платного обучения.

4. Добавить направленную ассоциацию от бизнес-актера Студент к варианту использования Получение справки о состоянии счета.

5. Добавить направленную ассоциацию от варианта использования Пополнение счета к сервису Система ДО.

6. Добавить направленную ассоциацию от варианта использования Получение справки о состоянии счета к сервису Система ДО.

7. Добавить отношение зависимости со стереотипом, направленное от варианта использования Получение справки о состоянии счета к варианту использования Проверка логина и пароля.

8. Добавить отношение зависимости со стереотипом, направленное от варианта использования Приостановление платного обучения к варианту использования Проверка логина и пароля.

Диаграмма вариантов использования не должна содержать слишком много вариантов использования и актеров. Для удаления любого графического элемента с диаграммы его следует выделить на диаграмме и нажать клавишу Delete на клавиатуре. При этом выделенный элемент будет удален с активной диаграммы, но не из модели. Для удаления элемента не только из диаграммы, но и из модели проекта необходимо выделить удаляемый элемент на диаграмме и воспользоваться операцией главного меню Edit>Delete from Model (Редактирование>Удалить из модели). Для этой же цели служит комбинация клавиш быстрого доступа: Ctrl+D. Кроме того, если для двух элементов выбранный вид отношения не является допустимым, то в большинстве случаев программа IBM Rational Rose сообщит об этом разработчику, и соответствующая линия связи не будет добавлена на диаграмму.

4. ДЕТАЛЬНОЕ ПРОЕКТИРОВАНИЕ ИСО

Разработка диаграммы классов и редактирование их свойств Особенности разработки диаграмм классов в среде IBM Rational Rose Диаграмма классов является основным логическим представлением модели и содержит детальную информацию о внутреннем устройстве объектно-ориентированной программной системы или, используя современную терминологию, об архитектуре программной системы.

Активизировать рабочее окно диаграммы классов можно несколькими способами:

окно диаграммы классов появляется по умолчанию в рабочем окне диаграммы после создания нового проекта;

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

раскрыть логическое представление (Logical View) в браузере проекта и дважды щелкнуть на пиктограмме Main (Главная);

выполнить операцию главного меню: Browse > Class Diagram (Обзор>Диаграмма классов) после чего в диалоговом окне, надо нажать Появляется новое окно с чистым рабочим листом диаграммы классов и специальная панель инструментов, содержащая кнопки с изображением графических примитивов, необходимых для разработки диаграммы классов.

Назначение отдельных кнопок панели можно узнать также из всплывающих подсказок.

Таблица Назначение кнопок специальной панели инструментов для диаграммы классов изображение На специальной панели инструментов по умолчанию присутствует только часть пиктограмм элементов, которые могут быть использованы для построения диаграммы классов. Добавить или удалить кнопки можно с помощью с помощью операции контекстного меню Customize (Настройка) при позиционировании курсора на специальной панели инструментов.

Добавление класса на диаграмму классов и редактирование его свойств Для добавления класса на диаграмму классов нужно нажать кнопку с изображением пиктограммы класса на специальной панели инструментов, щелкнуть лкм на свободном месте рабочего листа диаграммы. На диаграмме появится изображение класса с маркерами изменения его геометрических размеров и предложенным средой именем по умолчанию NewClass.

Продолжая разработку модели платной ИСО в качестве примера проекта, измените предложенное по умолчанию имя диаграммы Main на Диаграмма классов ДО, а имя добавленного на диаграмму класса – на операции в системе ДО.

Для класса можно уточнить его назначение в модели с помощью указания стереотипа и пояснительного текста в форме документации. С этой целью 2 лкм на изображении этого класса на диаграмме или в браузере проекта следует открыть диалоговое окно спецификации свойств этого класса и на вкладке General (Общие) выбрать из вложенного списка Stereotype стереотип entity (сущность).

Выбор данного стереотипа означает, что соответствующий класс предназначен для хранения информации, которая должна сохраняться в системе после уничтожения объектов данного класса. Далее в секцию документации данного класса можно ввести поясняющий текст:

"Используется для сохранения информации о выполненных операциях" и нажать кнопку Apply или OK.

Для отдельного класса можно уточнить также и другие его свойства, доступные для редактирования на вкладке Detail (Подробно) окна спецификации свойств этого класса.

Например, на этой вкладке с помощью вложенного списка Multiplicity (Кратность) можно задать количество объектов или экземпляров данного класса, для чего следует выбрать строку с буквой n. Данное значение означает, что у класса может быть любое конечное число экземпляров (Поле ввода с именем Space (Пространство) служит для указания объема абсолютной или относительной памяти, которая требуется, по оценке разработчика, для реализации каждого объекта данного класса.

Применительно к рассматриваемой модели это поле можно оставить пустым.

Далее можно задать устойчивость классов в группе выбора Persistence.

При этом выбор свойства Persistent (Устойчивый) означает, что информация об объектах данного класса должна быть сохранена в системе. Выбор свойства Transient (Временный) означает, что нет необходимости сохранять информацию об объектах данного класса в системе после завершения работы программного приложения. Применительно к рассматриваемой модели следует выбрать свойство Persistent. В группе выбора Concurrency (Параллельность) можно специфицировать условия на возможность реализации объектов данного класса в параллельных потоках управления.

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

Sequential (Последовательный) - свойство по умолчанию, которое означает, что объекты класса будут вести себя нормально только при наличии одного потока управления, т. е. соответствующие операции объектов должны выполняться последовательно. В то же время при наличии нескольких потоков управления стабильное поведение объектов класса не гарантируется.

Guarded (Безопасный) - означает, что при наличии нескольких потоков управления объекты класса будут вести себя ожидаемым от них образом. Для этого объекты в различных потоках должны взаимодействовать друг с другом для того, чтобы гарантировать отсутствие конфликта между ними.

Active (Активный) - означает, что класс должен иметь свой собственный поток управления.

Synchronous (Синхронный) - означает, что объекты класса будут вести себя ожидаемым от них образом при наличии нескольких потоков управления. При этом нет необходимости во взаимодействии объектов в различных потоках управления, поскольку объекты данного класса могут самостоятельно разрешать возможные конфликты.

Для того, чтобы специфицировать класс как абстрактный, т.е. не имеющий экземпляров, следует на этой же вкладке выставить отметку в свойстве

Abstract

(Абстрактный). Применительно к рассматриваемой модели для класса Транзакция банкомата следует выбрать свойства Persistent и Sequential, а отметку для свойства Abstract оставить пустой.

Стереотипы классов и их графическое представление На диаграмме классов можно выбрать способ изображения стереотипов классов. Изменить изображение стереотипа для отдельного класса можно, например, с помощью одной из вложенных операций контекстного меню:

Options>Stereotype Display (Параметры>Изображение стереотипа). В качестве примера можно представить изображение класса Транзакция Банкомата в форме специальной графической пиктограммы стереотипа. С этой целью следует выполнить операцию контекстного меню: Options > стереотипа>Пиктограмма).

Или Options > Stereotype Display > Decoration (Параметры > Изображение стереотипа > Декорация).

Изменить изображение стереотипов одновременно для нескольких классов диаграммы можно с помощью одной из вложенных операций главного меню: Format > Stereotype Display (Формат > Изображение стереотипов). В этом случае необходимо выделить все классы модели в окне диаграммы классов или в браузере проекта. Для выделения группы классов на диаграмме или в браузере проекта следует, удерживая нажатой клавишу Ctrl или Shift на клавиатуре, последовательно щелкать на их изображении левой кнопкой мыши.

Добавьте на диаграмму второй класс с именем Контроллер ДО, для которого в окне спецификации свойств выберите стереотип control (управляющий класс) Добавьте на диаграмму третий класс с именем Устройство авторизации, для которого в окне спецификации свойств выберите стереотип boundary (граничный класс).

Применение этого стереотипа означает, что данный класс находится на границе моделируемой системы.

Далее следует добавить класс с именем IКонтроллер системы ИСО, для которого выбрать стереотип Interface (Интерфейс), означающий, что система ДО пользуется услугами глобальной ИСО при обработке своих операций.

Первой буквой в имени этого класса является английское "I", которое служит в языке UML для указания интерфейса.

Добавление атрибутов и операций на диаграмму классов. Добавление и редактирование атрибутов классов Добавить атрибут к созданному ранее классу можно одним из следующих способов:

С помощью операции контекстного меню New Attribute (Новый атрибут ) для класса, выделенного на диаграмме классов. В этом случае активизируется курсор ввода текста в области графического изображения класса на диаграмме.

С помощью операции контекстного меню: New>Attribute (Новый>Атрибут) для класса, выделенного в браузере проекта. В этом случае активизируется курсор ввода текста в области иерархического соответствующего класса.

С помощью операции контекстного меню Insert (Вставить), вызванного при позиционировании курсора в области открытой вкладки атрибутов в диалоговом окне свойств Class Specification соответствующего класса.

После добавления атрибута к классу по умолчанию ему присваивается имя name и квантор видимости.

Для модели ИСО имя добавленного атрибута следует изменить на идентификатор студенческого билета. Имена атрибутов и операций классов должны начинаться со строчной буквы. Видимость атрибутов на диаграмме классов изображается в форме специальных пиктограмм или украшений.

Таблица Пиктограммы видимости атрибутов классов ое изображение ый аналог Для редактирования свойств атрибутов предназначено диалоговое окно спецификации атрибута Class Attribute Specification, которое открывается двойным щелчком мыши на строке выбранного атрибута в окне спецификации свойств класса. В окне свойств отдельного атрибута класса можно задать тип данных атрибута и его начальное значение, а также назначить атрибуту стереотип из раскрывающегося списка или изменить его квантор видимости.

Для атрибута идентификатор студенческого билета в качестве типа его допустимых значений из вложенного списка Type следует выбрать тип Integer (целочисленный), а для задания квантора видимости следует выбрать в группе Export Control (Управление экспортом) квантор Public. Поскольку начальное значение для данного атрибута не определено, соответствующее поле ввода следует оставить пустым. В секцию документации данного атрибута класса можно ввести поясняющий текст: "Устройство чтения студенческого билета считывает значение этого атрибута с студенческого билета студента" и нажать кнопку Apply или OK, чтобы сохранить результаты редактирования этих свойств атрибута.

Для отдельного атрибута можно также определить дополнительные свойства, доступные для редактирования на вкладке Detail (Подробно) На вкладке Detail в группе выбора Containment (Локализация) можно специфицировать условия хранения атрибута у объектов выбранного класса.

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

By value (По значению) - свойство по умолчанию, которое означает, что значения атрибута хранятся в пределах адресного пространства, выделенного для объекта данного класса. Например, если имеется атрибут типа String, то значение этой строки содержится в пределах определения класса.

By reference (По ссылке) - означает, что значение атрибута хранится вне адресного пространства, выделенного для объекта данного класса, но у объектов класса имеется указатель на этот атрибут.

Unspecified (Не определен) - означает, что метод локализации данного атрибута не определен. В этом случае при генерации программного кода для данного атрибута по умолчанию выбирается значение By Далее можно определить атрибут как статичный, выставив отметку в строке выбора Static. Статичный атрибут по определению имеет одно и тоже значение для всех объектов рассматриваемого класса. Наконец, на вкладке Detail можно определить атрибут как производный, выставив отметку в строке выбора Derived. Значение производного атрибута по определению может быть вычислено на основании значений других атрибутов этого или другого класса.

Добавление и редактирование операций классов Функционирование ИСО основано на выполнении отдельными его устройствами тех или иных действий. В модели структуры ИСО все действия представляются с помощью операций классов. Таким образом, следующий этап разработки диаграммы классов связан со спецификацией операций классов.

Добавить операцию к созданному ранее классу можно одним из следующих способов:

С помощью операции контекстного меню New Operation (Новая операция ) для класса, выделенного на диаграмме классов. В этом случае активизируется курсор ввода в области графического изображения класса на диаграмме.

С помощью операции контекстного меню: New>Operation (Новая>Операция) для класса, выделенного в браузере проекта. В этом случае активизируется курсор ввода в области иерархического представления класса в браузере под именем соответствующего класса.

С помощью операции контекстного меню Insert (Вставить), вызванного при позиционировании курсора в области открытой вкладки операций в диалоговом окне свойств Class Specification соответствующего класса.

После добавления операции к классу по умолчанию ей присваивается имя opname и некоторый квантор видимости. Видимость операций на диаграмме классов также изображается в форме специальных пиктограмм.

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

Таблица.Пиктограммы видимости операций классов ое изображение ый аналог В модели ИСО в качестве имени первой операции для класса Операция обмена данными ИСО следует задать: создать новую транзакцию. При этом скобки при задании имени операции не записываются, поскольку программа IBM Rational Rose добавляет их автоматически.

Каждая из операций классов имеет собственное диалоговое окно спецификации свойств Operation Specification, которое может быть открыто по двойному щелчку на имени операции на соответствующей вкладке спецификации класса или на имени этой операции в браузере проекта. Для операции создать новую транзакцию() в качестве квантора видимости следует выбрать из вложенного списка квантор public. В секцию документации данной операции класса можно ввести поясняющий текст:

"Вызывается после того, как студенческий билет вставлена в Устройство чтения " и нажать кнопку Apply или OK, чтобы сохранить результаты редактирования свойств этой операции. Соответствующее окно спецификации свойств операции создать новую транзакцию() после редактирования ее свойств будет иметь следующий вид.

Для операций классов кроме квантора видимости можно также задать:

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

Для отдельной операции эти дополнительные свойства доступны для редактирования на вкладке Detail (Подробно) диалогового окна спецификации свойств выбранной операции.

На вкладке Detail в многостраничном поле Arguments (Аргументы) можно определить аргументы редактируемой операции. Для этого следует выполнить операцию контекстного меню Insert (Вставить). После этого в этом поле появится аргумент данной операции с именем по умолчанию argname. Для редактирования свойств аргумента предназначено специальное окно свойств аргумента.

На вкладке Detail в поле Protocol (Протокол) можно специфицировать порядок выполнения операций класса, например, указать, что одна операция не может быть вызвана раньше другой. Соответствующий текст в данное поле вводится с клавиатуры и попадает в генерируемый код в форме комментария. В поле Qualification (Квалификация) можно уточнить детали реализации операции, связанные с конкретным языком программирования.

Соответствующий текст также вводится в данное поле с клавиатуры и попадает в генерируемый код в форме комментария.

Далее на этой же вкладке в полях Size (Размер) и Time (Время) можно специфицировать предполагаемый объем памяти и время, необходимое для выполнения операции. Соответствующая информация попадает в генерируемый код в форме комментария.

специфицировать условия на возможность параллельного выполнения данной операции. Для выбора могут быть использованы следующие свойства:

Sequential (Последовательная) - свойство по умолчанию, которое означает, что данная операция класса может быть выполнена только при наличии одного потока управления, т. е. соответствующая операция класса должна выполняться последовательно. При наличии нескольких потоков управления выполнение данной операции класса не гарантируется.

Guarded (Безопасная) - означает, что при наличии нескольких потоков управления выполнение данной операции класса гарантируется только в том случае, когда обеспечено взаимодействие объектов друг с другом в различных потоках.

Synchronous (Синхронная) - означает, что выполнение данной операции класса гарантируется при наличии нескольких потоков управления. При этом нет необходимости во взаимодействии объектов в различных потоках управления, поскольку данная операция класса будет выполняться в отдельном потоке управления вплоть до своего завершения.

Применительно к рассматриваемой модели для операции создать новую транзакцию() следует выбрать свойство Sequential, а поля всех других свойств оставить пустыми.

Остальные действия по детализации необходимо выполнить самостоятельно.

Добавление отношений на диаграмму классов и редактирование их свойств Диаграмма классов является логическим представлением структуры модели, поэтому она должна содержать столько классов, сколько необходимо для реализации всего проекта. При этом для полного представления структуры модели необходимо установить и специфицировать отношения между классами.

Добавление ассоциации на диаграмму классов и редактирование ее свойств Добавление ассоциации осуществляется при помощи инструмента аа специальной панели инструментов. Если ассоциация - направленная, то на диаграмме классов надо выделить первый элемент ассоциации или источник, от которого исходит стрелка, и, не отпуская нажатую левую кнопку мыши, переместить ее указатель ко второму элементу отношения или приемнику, к которому направлена стрелка.

Продолжая разработку диаграммы классов модели ИСО, добавьте на нее направленную ассоциацию между классами.

Измените имя для данной ассоциации. Это можно выполнить с помощью окна спецификации свойств ассоциации. Доступ к диалоговому окну спецификации свойств ассоциации Association Specification можно получить после выделения линии ассоциации на диаграмме классов или в браузере проекта и двойного щелчка на ней лкм.

Для задания имени ассоциации следует на вкладке General (Общие) в поле ввода Name (Имя) ввести текст ее имени и нажать кнопку Apply или OK. Для ассоциации можно задать также кратность каждого из концов ассоциации, стереотип, использовать ограничения и роли и т.д.

Для добавленной на диаграмму классов ассоциации задайте кратность конца ассоциации у класса Контроллер ИСО, равную 1. Для этого следует в окне спецификации свойств ассоциации перейти на вкладку Role B Detail и выбрать значение 1 из вложенного списка Multiplicity.