Омпс. Як утворити кооперацію реалізації прецеденту?
В контексте архитектуры системы кооперация позволяет присвоить имя некоторому концептуальному фрагменту, охватывающему как статические, так и динамические аспекты. Кооперация (Collaboration) именует сообщество классов, интерфейсов и. других элементов, которые работают совместно для обеспечения кооперативного поведения, более значимого, чем сумма его слагаемых.
Кооперации используются для описания реализации прецедентов и операций и для моделирования архитектурно-значимых механизмов системы.
Кооперация (Collaboration) - это сообщество классов, интерфейсов и других элементов, которые работают совместно для обеспечения кооперативного поведения, более значимого, чем сумма его составляющих. Кооперация также специфицирует то, как некий элемент, допустим классификатор (класс, интерфейс, компонент узел или прецедент) либо операция, реализуется с помощью классификаторов и ассоциаций, каждая из которых играет свою роль. Изображается кооперация в виде эллипса с пунктирной границей. (Эта нотация отнюдь не случайно подобна нотации прецедента.
Каждая кооперация должна иметь имя, отличающее ее от других коопераций. Имя - это текстовая строка. Взятое само по себе, оно называется простым. К составному имени кооперации спереди добавлено имя пакета, в котором она находится. Внутри объемлющего пакета имя должно быть уникальным
Одно из назначений коопераций состоит в моделировании прецедентов. Как правило, при анализе системы вы руководствуетесь тем, как она может использоваться. Переходя же к этапу реализации, вы должны реализовать идентифицированные прецеденты в виде конкретных структур и поведений. В общем случае каждый прецедент должен быть реализован одной или несколькими кооперациями. Если рассматривать систему в целом, то классификаторы, участвующие в кооперации, которая связана с некоторым прецедентом, будут принимать участие и в других кооперациях.
Моделирование реализации прецедента состоит из следующих этапов:
Идентифицируйте те структурные элементы, которые необходимы и достаточны для осуществления семантики прецедента.
Организуйте эти структурные элементы в диаграмму классов.
Рассмотрите отдельные сценарии, которые представляют данный прецедент. Каждый сценарий описывает один из путей прохождения прецедента.
Отобразите динамику этих сценариев на диаграммах взаимодействия. Воспользуйтесь диаграммами последовательности, если нужно подчеркнуть порядок сообщений, и диаграммами кооперации, если более важны структурные отношения между кооперирующимися объектами.
Организуйте эти структурные и поведенческие элементы как кооперацию, которую вы можете соединить с прецедентом через реализацию.
Например, на рис__ изображены прецеденты, относящиеся к системе контроля кредитных карточек, в том числе основные из них - Разместить заказ и Создать счет, а также два вспомогательных - Распознать подлог и Проверить транзакцию. Хотя в большинстве случаев не возникает необходимости в явном моделировании этого отношения (такую задачу можно оставить инструментальным: средствам), на рисунке показана явная модель реализации. Разместить заказс помощью кооперации Управление заказами. В свою очередь эта кооперация: может быть разложена на структурный и поведенческий аспекты, что в итоге дает диаграмму классов и диаграмму взаимодействия. Вот так, через отношение реализации, вы и связываете прецедент с его сценариями.
Рис. 27.5. Моделирование реализации прецедента
В большинстве случаев нет необходимости явно моделировать отношение между прецедентом и реализующей его кооперацией. Лучше оставить это на заднем: плане модели и позволить инструментальным средствам воспользоваться имеющейся связью для навигации между прецедентом и его реализацией.
МОДЕЛЮВАННЯ КЛАСІВ
МК. Які відношення застосовують на діаграмі класів?
Відношення асоціації на діаграмах класів трапляються найчастіше. Асоціацію позначають суцільною лінією (може завершуватися однією чи двома стрілками), що з’єднує класи. Асоціація означає, що екземпляри одного класу взаємодіють з екземплярами іншого класу під час виконання програми. Оскільки екземплярів
класу може бути багато і кожен може взаємодіяти з декількома екземплярами іншого класу, то асоціація є дескриптором, що описує множину зв’язаних об’єктів (екземплярів асоціації).
У мові UML використовують два часткові й дуже важливі випадки відношення асоціації – агрегацію та композицію. В обох випадках йдеться про моделювання відношення типу “частина – ціле”. Відношення такого типу є відношеннями асоціації, оскільки
частини і ціле, зазвичай, взаємодіють між собою.
Агрегація (Aggregation) від класу А до класу В означає, що об’єкти (один чи декілька) класу А входять до складу об’єкта класу В. На діаграмі класу це відзначається за допомогою спеціального графічного доповнення: на полюсі асоціації з боку “цілого” (у на
шому випадку клас В) зображається порожній ромбик.
Композиція (Composition) є посиленою формою агрегації і створюється на основі бінарної асоціації. Композиція накладає дещо сильніші обмеження: композиційно “частина” може входити тільки в одне “ціле”, “частина” існує доти, доки існує “ціле”, і припиняє своє існування разом з “цілим”. Графічно відношення композиції зображають зафарбованим ромбиком.
Узагальнення (generalіzatіon) – це відношення між двома сутностями, одна з яких є частковим (або спеціалізованим) випадком іншої.
Залежність (dependency) – це найузагальненіше відношення між двома сутностями, яке вказує на те, що зміна незалежної сутності якось впливає на залежну сутність. Графічно відношення залежності зображають пунктирною стрілкою, спрямованою від
залежної сутності до незалежної (рис. 4.11). Зазвичай, семантика конкретної залежності уточнюється в моделі за допомогою додаткової інформації.