Теоретические основы проектирования информационных систем

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

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

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

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

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

При моделировании ИС, когда стрелками являются не физические объекты, а данные, не все так очевидно. Например, при «Приеме пациента» карта пациента может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе -- "Заполненная карта пациента"). Чтобы определить, являются ли данные входом или управлением надо определить, перерабатываются/изменяются ли данные в работе или нет. Если изменяются, то, скорее всего, это вход, если нет - управление.

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

Выход (Output) - материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы.

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

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

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

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

3. Типы связей на диаграммах модели IDEF0

В IDEF0 различают пять типов связей работ.

Связь по входу (output-input), когда стрелка выхода вышестоящей работы направляется на вход нижестоящей.

Связь по входу.

Связь по управлению (output-control), когда выход вышестоящей работы направляется на управление нижестоящей. Связь по управлению показывает доминирование вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в нижестоящей. На рис. 7.16 стрелка "Заказы клиентов" связывает работы "Продажи и маркетинг" и "Сборка и тестирование компьютеров".

Связь по управлению.

Обратная связь по входу (output-input feedback), когда выход нижестоящей работы направляется на вход вышестоящей.

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

Обратная связь по входу.

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



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

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

Связь выход-механизм.

Явные стрелки. Явная стрелка имеет источником одну-единственную работу и назначением тоже одну-единственную работу.

Разветвляющиеся и сливающиеся стрелки.

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

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

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

Пример именования разветвляющейся стрелки.

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

Пример именования разветвляющейся стрелки.

Недопустима ситуация, когда стрелка до разветвления не именована, а после разветвления не именована какая-либо из ветвей.

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

Туннелирование стрелок.

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

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

Процесс разработки IDEF0 диаграммы состоит из следующих условных этапов:

1 этап. Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов, создавая модели деятельности подразделений. При этом их интересуют ответы на следующие вопросы:

1. Что поступает в подразделение "на входе"?

2. Какие функции и в какой последовательности выполняются в рамках подразделения?

3. Кто является ответственным за выполнение каждой из функций?

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

5. Что является результатом работы подразделения (на выходе)?

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

2 этап. Распространение черновика для рассмотрения, согласований и комментариев. На этой стадии происходит обсуждение черновика модели с широким кругом компетентных лиц (в терминах IDEF0 -- читателей) на предприятии.

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

4. ФУНКЦИОНАЛЬНЫЕ МЕТОДИКИ DFD и IDEF3

Рассматриваемые вопросы:

1. Методика построения модели в контексте DFD

2. Правила построения диаграмм модели DFD

3. Метод описания процессов IDEF3

1. Методика построения модели в контексте DFD

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

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

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

Основные понятия:

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

2. Процесс (работа) - это элемент, который преобразует входные потоки в выходные в соответствии с действием, задаваемым именем процесса. Процесс представляет собой совокупность операций по преобразованию входных потоков данных в выходные в соответствии с определенным алгоритмом или правилом. Хотя физически процесс может быть реализован различными способами, наиболее часто подразумевается программная реализация процесса. Процесс на диаграмме потоков данных изображается прямоугольником с закругленными вершинами. Имя процесса должно содержать глагол в неопределенной форме (например, «получить документы по отгрузке продукции»). Каждый процесс имеет уникальный номер для ссылок на него.

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

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

1 этап. Процесс построения DFD начинается с создания основной диаграммы типа «звезда», на которой представлен моделируемый процесс и все внешние сущности, с которыми он взаимодействует.

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

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

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

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

5. процесс может быть описан в виде преобразования входных данных в выходные;

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

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

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

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

2. Правила построения диаграмм модели DFD

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

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

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

4. Символы могут быть повторены для облегчения чтения диаграммы.

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

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

Непротиворечивость системы обеспечивается выполнением наборов формальных правил о возможных типах процессов:

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

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

ь два хранилища данных не могут непосредственно обмениваться информацией - эти хранилища должны быть объединены.

Преимущества:

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

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

Недостатки:

необходимость искусственного ввода управляющих процессов;

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

Пример диаграммы DFD

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

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

3. Метод описания процессов IDEF3

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

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

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

Диаграмма является основной единицей описания в IDEF3.

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

Различают три типа стрелок, изображающих связи:

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

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

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

Потоки объектов (Object Flow) стрелка с двумя наконечниками, применяется для описания того, что объект используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой. Часто результатом работы-источника становится объект, необходимый для запуска работы-цели. В этом случае также изображается стрелка потока объектов. Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы, используются перекрестки (Junction). Различают перекрестки для слияния (Fan-in Junction) и разветвления стрелок (Fan-out Junction). Перекресток не может использоваться одновременно для слияния и для разветвления. Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. В отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки.

Обозначение	Смысл в случае слияния стрелок (Fan-in Junction)	Смысл в случае разветвления стрелок (Fan-out Junction)

Размещено на http://www.allbest.ru/

Все предшествующие процессы должны быть завершены	Все следующие процессы должны быть запущены

Размещено на http://www.allbest.ru/

Все предшествующие процессы завершены одновременно	Все следующие процессы запускаются одновременно

Размещено на http://www.allbest.ru/

Один или несколько предшествующих процессов должны быть завершены	Один или несколько следующих процессов должны быть запущены

Размещено на http://www.allbest.ru/

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

Размещено на http://www.allbest.ru/

Только один предшествующий процесс завершен	Только один следующий процесс запускается

ТЕМА 12. УНИФИЦИРОВАННЫЙ ЯЗЫК ВИЗУАЛЬНОГО МОДЕЛИРОВАНИЯ UNIFIED MODELING LANGUAGE (UML)

1. Синтаксис и семантика основных объектов UML

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

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

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

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

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

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

ь protected (защищенный) - только любой потомок данного класса может пользоваться его защищенными свойствами. Обозначаются знаком «#»;

ь private (закрытый) - только данный класс может пользоваться этими свойствами. Обозначаются символом «-».

Область действия свойства указывает, будет ли оно проявлять себя по-разному в каждом экземпляре класса, или одно и то же значение свойства будет совместно использоваться всеми экземплярами:

ь instance (экземпляр) - у каждого экземпляра класса есть собственное значение данного свойства;

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

Возможное количество экземпляров класса называется его кратностью. В UML можно определять следующие разновидности классов:

v не содержащие ни одного экземпляра - тогда класс становится служебным (Abstract);

v содержащие ровно один экземпляр (Singleton);

v содержащие заданное число экземпляров;

v содержащие произвольное число экземпляров.

2. Основные виды диаграмм языка моделирования UML

ДИАГРАММЫ КЛАССОВ

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

Отношения между классами

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

Обобщение - это отношение между общей сущностью (родителем - класс «клиент») и ее конкретным воплощением (потомком - классы «корпоративный клиент» или «частный клиент»). Объекты класса-потомка могут использоваться всюду, где встречаются объекты класса-родителя, но не наоборот. При этом он наследует свойства родителя (его атрибуты и операции). Класс, у которого нет родителей, но есть потомки, называется корневым.

Ассоциация - это отношение, показывающее, что объекты одного типа неким образом связаны с объектами другого типа («клиент» может сделать «заказ»). Если между двумя классами определена ассоциация, то можно перемещаться от объектов одного класса к объектам другого. При необходимости направление навигации может задаваться стрелкой. Допускается задание ассоциаций на одном классе. В этом случае оба конца ассоциации относятся к одному и тому же классу. Это означает, что с объектом некоторого класса можно связать другие объекты из того же класса. Ассоциации может быть присвоено имя, описывающее отношение. Каждая ассоциация имеет две роли, которые могут быть отражены на диаграмме. Роль ассоциации обладает свойством множественности, которое показывает, сколько соответствующих объектов может участвовать в данной связи.

Например: каждый заказ может быть создан единственным клиентом (множественность роли 1..1). Каждый клиент может создать один и более заказов (множественность роли 1..n). Направление навигации показывает, что каждый заказ должен быть «привязан» к определенному клиенту.

Агрегирование - специальный тип ассоциации. В такой ассоциации один из классов имеет более высокий ранг (целое -- класс «заказ») и состоит из нескольких меньших по рангу классов (частей - класс «строка заказа»).

ДИАГРАММЫ ИСПОЛЬЗОВАНИЯ

Диаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. «Каждая функциональность» изображается в виде «прецедентов использования» (use case) или просто прецедентов.

Прецедент - это типичное взаимодействие пользователя с системой, которое при этом:

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

· может представлять различные уровни детализации,

· обеспечивает достижение конкретной цели, важной для пользователя.

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

Связи на диаграммах прецедентов:

ь связь между действующими лицами и прецедентами;

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

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

ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТЕЙ

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

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

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

Пример на слайде (диаграмма последовательности обработки заказа):

вводятся строки заказа;

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

если запас достаточен - инициируется поставка;

если запас недостаточен - инициируется дозаказ (повторный заказ).

КООПЕРАТИВНЫЕ ДИАГРАММЫ

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

ДИАГРАММЫ СОСТОЯНИЙ

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

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

Переходы имеют метки, которые синтаксически состоят из трех необязательных частей:

Событие> <[Условие]> < / Действие>.

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

выполнить/< деятельность >.

ДИАГРАММЫ ДЕЯТЕЛЬНОСТИ

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

Основными элементами диаграмм деятельности являются (рис. 11.8):

ь овалы, изображающие действия объекта;

ь линейки синхронизации, указывающие на необходимость завершить или начать несколько действий (модель логического условия "И");

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

ь стрелки -- отражают последовательность действий, могут иметь метки условий.

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

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

ДИАГРАММЫ КОМПОНЕНТОВ

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

Элементами диаграммы являются компоненты -- физические замещаемые модули системы. Каждый компонент является полностью независимым элементом системы. Разновидностью компонентов являются узлы. Узел -- это элемент реальной (физической) системы, который существует во время функционирования программного комплекса и представляет собой вычислительный ресурс, обычно обладающий как минимум некоторым объемом памяти, а часто еще и способностью обработки. Узлы делятся на два типа:

устройства -- узлы системы, в которых данные не обрабатываются.

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

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

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

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

Размещено на Allbest.ur