Сдам Сам

ПОЛЕЗНОЕ


КАТЕГОРИИ







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





 

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

 

Сложность диаграмм последовательностей

 

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

Следующим обычно бывает вопрос: "Что делать с условными логическими выраже­ниями если—то и иначе, которые воспроизводят реалии предметной области?" И вновь у меня есть традиционный ответ, хотя и довольно субъективный. Если логика проста, т.е. описывается всего несколькими сообщениями, я, как правило, включаю их в одну диаграмму и использую дополнительные примечания для описания возможных вариан­тов выбора. В противном случае целесообразно создавать отдельные диаграммы — для случая если—то, а другую для иллюстрации ветви иначе. Это позволяет значительно упростить восприятие модели. При желании диаграммы можно соединить связями



Диаграмму сотрудничества допустимо конструировать и с «чистого листа». В этом случае на основе диаграммы сотрудничества можно создать диаграмму последовательностей: достаточно выполнить аналогичные действия, выбрав элемент меню Browse→ Create Sequence Diagram.

 

ЗАЧЕМ НУЖНЫ РАЗЛИЧНЫЕ ВИДЫ ДИАГРАММ

 

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

 

РЕЗЮМЕ

 

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

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

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

 

 

Лекция №4

Зачем нужны связи

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

Связи ассоциации

Ассоциация (association) — это двунаправленная семантическая связь между классами. Речь не идет о потоке данных, каковые определяются в процессе структурного анализа и проектирования, — через ассоциацию данные могут передаваться в любых направле­ниях. Наличие ассоциации между классами означает существование связи между объек­тами ассоциированных классов. Например, ассоциация, соединяющая классы "курс" и "контроль предложения курса", свидетельствует о том, что объекты одного класса свя­заны с объектами другого. Количество соединяемых объектов зависит от значения при­знака множественности ассоциации (подробнее об этом рассказано ниже). В UML ассоциация помечается отрезком прямой, связывающим два класса.

 

Связи агрегирования

Связь агрегирования (aggregation relationship), или связь принадлежности (containment relationship),— это специальная форма ассоциации, устанавливающая соотношение частей и целого. В UML для отображения свя­зи агрегирования, соединяющей два класса, применяется отрезок прямой с ромбом, указывающим на агрегатный класс ("целое").

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

• Применяется ли для описания связи выражение "является частью"?

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

• Обладает ли связь внутренне присущим свойством асимметрии, когда один со­единяемый ею класс "подчиняется" другому?

Например, курс "алгебра 101" может преподаваться несколько раз в течение семестра. Каждый раздел курса представляется объектом класса "предложение курса" (скажем, "алгебра 101, раздел 1" и "алгебра 101, раздел 2"). Связь между объектами "курс" и "пред­ложение курса" является агрегатной — "предложение курса" служит "частью" "курса".

 

Ассоциация и агрегирование: "за" и "против"

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

Является ли определенная связь ассоциативной или агрегатной — ответ на этот вопрос часто напрямую зависит от особенностей конкретной предметной области. Связь какого типа уместно использовать для моделирования автомобиля и его по­крышек? Если речь идет о сервисном центре и покрышки воспринимаются только как неотъемлемая часть автомобиля, подлежащего обслуживанию, тогда следует остано­вить внимание на связи агрегирования. Если же приложение предназначено для ис­пользования в магазине, торгующем покрышками, объект "покрышка" надлежит рас­сматривать независимо от объекта "автомобиль", т.е. интерпретировать связь между ними как ассоциацию.

 

Именование связей

 

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

Имена ролей

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

 

Возвратные связи

 

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

 

Как находить связи

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

 

Резюме

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

 









Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:


©2015- 2018 zdamsam.ru Размещенные материалы защищены законодательством РФ.