WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     | 1 |   ...   | 9 | 10 || 12 | 13 |   ...   | 16 |

o Множественное наследование часто можно заменить агрегированием.

o Остерегайтесь циклических отношений обобщения.

o Поддерживайте баланс в отношениях обобщения:

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

o Применяйте ассоциации прежде всего там, где между объектами существуют структурные отношения.

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

o Избегайте пересечения линий.

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

- 84 - УМП «Автоматизированные методы разработки архитектуры ПО» Структурное моделирование, моделирование поведения, аспекты поведения Следуйте стандарту языка моделирования UML Компоненты Конечный результат работы строительной компании – здание, существующее в реальном мире. Для визуализации, специфицирования и документирования принимаемых по ходу строительства решений предназначены логические модели. Заранее продумывается расположение стен, дверей и окон, схемы электропроводки и водопровода, общий архитектурный стиль. В ходе строительства эти воображаемые стены, двери, окна и другие элементы конструкции материализуются в реальные объекты.

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

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

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

- 85 - УМП «Автоматизированные методы разработки архитектуры ПО» Компонент (Component) это физическая заменяемая часть системы, совместимая с одним набором интерфейсов и обеспечивающая реализацию какого-либо другого.

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

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

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

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

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

o Классы могут обладать атрибутами и операциями.

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

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

Компонент имеет физическую природу. Он существует в реальном мире битов, а не в мире концепций.

Компонент это часть системы. Компонент совместим с одним набором интерфейсов и реализует другой набор.

Типичные приемы моделирования.

Исполняемые программы и библиотеки.

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

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

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

Хорошо спроектированные узлы точно соответствуют словарю аппаратного обеспечения области решения.

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

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

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

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

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

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

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

- 87 - УМП «Автоматизированные методы разработки архитектуры ПО» Компоненты принимают участие в исполнении системы в то время, как узлы это сущности, которые исполняют компоненты.

Компоненты представляют физическую упаковку логических элементов, а узлы представляют средства физического развертывания компонентов.

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

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

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

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

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

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

- 88 - УМП «Автоматизированные методы разработки архитектуры ПО» o Идентифицируйте вычислительные элементы представления системы с точки зрения развертывания и смоделируйте каждый из них как узел.

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

o Рассмотрите атрибуты и операции, применимые к каждому узлу.

o Припишите каждый значимый компонент системы к определенному узлу.

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

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

o Соедините каждый узел с компонентами, которые на нем развернуты, отношением зависимости.

o Перечислите компоненты, развернутые на узле, в дополнительном разделе.

o Компоненты не обязательно должны быть статически распределены по узлам системы.

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

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

- 89 - УМП «Автоматизированные методы разработки архитектуры ПО» Кооперациии В контексте архитектуры системы кооперация позволяет присвоить имя некоторому концептуальному фрагменту, охватывающему как статические, так и динамические аспекты.

Кооперация (Collaboration) именует сообщество классов, интерфейсов и.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

o Отношения между кооперацией и тем, что она реализует.

Pages:     | 1 |   ...   | 9 | 10 || 12 | 13 |   ...   | 16 |






















© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.