Шпаргалка по "Корпоративным сетям"

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

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

• каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.

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

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

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

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

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

Графическая нотация Гейна-Сарсона моделирования данных.

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

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

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

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

На приведенной ниже иллюстрации использована нотация Гейна-Сарсона.

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

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

Кроме того, нотация DFD поддерживает понятие подсистемы — структурной компоненты разрабатываемой системы.

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

 

15 Построение функциональной модели информационной системы с помощью UML диаграмм прецендентов

UML обеспечивает поддержку всех этапов жизненного цикла ИС и предоставляет для этих целей ряд графических средств – диаграмм.

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

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

На этапе создания физической модели детальное проектирование выполняется с использованием диаграмм классов, диаграмм компонентов, диаграмм развертывания.

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

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

Диаграммы видов деятельности (диаграммы деятельностей, activity diagrams) – модель бизнес-процесса или поведения системы в рамках прецедента.

Диаграммы взаимодействия (interaction diagrams) – модель процесса обмена сообщениями между объектами, представляется в виде диаграмм последовательностей (sequence diagrams) или кооперативных диаграмм (collaboration diagrams).

Диаграммы состояний (statechart diagrams) – модель динамического поведения системы и ее компонентов при переходе из одного состояния в другое.

Диаграммы классов (class diagrams) – логическая модель базовой структуры системы, отражает статическую структуру системы и связи между ее элементами.

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

Диаграммы компонентов (component diagrams) – модель иерархии подсистем, отражает физическое размещение баз данных, приложений и интерфейсов ИС.

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

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

 
Рис. 12.1. Взаимосвязи между диаграммами UML

Ниже приводятся описания последовательных этапов проектирования ИС с использованием UML.

 

16. Построение  алгоритмов функционирования модели  информационной системы с помощью UML диаграмм активностей 

Диаграмма деятельности (Activity diagram) — диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью (англ. activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий (англ. action), соединённых между собой потоками, которые идут от выходов одного узла к входам другого.

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

Аналогом диаграмм деятельности являются схемы алгоритмов по ГОСТ 19.701-90 и дракон-схемы.

 

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

 

17.1. Назначение и состав.

17.2. Правила и рекомендации по разработке диаграммы деятельности.

17.3. Примеры построения диаграмм деятельности.

Вопросы для самопроверки. 

 

17.1. Назначение и состав 

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

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

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

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

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

Основными элементами диаграммы являются состояния действия, состояния деятельности, переходы, решения, ветвления и слияния параллельных потоков и дорожки [26].

Состояние действия (англ. action state) является аналогом процесса на блок-схемах. Обычное использование состояния действия заключается в моделировании одного шага выполнения алгоритма (процедуры) или потока управления.

Графически состояние действия отображается, как обыкновенное состояние (рис. 17.1).

Рис. 17.1. Примеры состояний действия

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

Состояние деятельности (поддеятельности, англ. subactivity state) является аналогом предопределенного процесса на блок-схемах. Деятельность является составным состоянием, отображаемым на диаграмме как единое целое (например, на рис. 17.1 – «Разработать план проекта»), а ее детализация выполняется в случае необходимости на отдельной диаграмме. Графически деятельность от действия отличает специальный знак, помещаемый в правый нижний угол состояния (рис. 17.2).

Рис. 17.2. Пример состояния деятельности

Каждая диаграмма деятельности должна иметь начальное и конечное (конечные) состояния, обозначаемые так же, как и на диаграмме состояний.

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

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

Ветвление (англ. fork) и слияние (англ. join) параллельных потоков (англ. concurrent flow) являются аналогом параллельных действий на блок-схемах. Ветвление и слияние потоков показываются так же, как и на диаграмме состояний (рис. 17.3).

Рис. 17.3. Ветвление (а) и слияние (б)

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

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

 

17.2. Правила и рекомендации по  разработке диаграммы деятельности  

 

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