WWW.DISSERS.RU

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

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


Pages:     | 1 |   ...   | 8 | 9 || 11 | 12 |   ...   | 16 |

1) Определения элементов, с помощью которых выполняется описание задачи или способ ее решения.

Для отыскания правильных абстракций используйте CRCкарточки и анализ прецедентов 2) Множества обязанностей для каждой абстракции.

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

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

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

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

Откройте и составьте словарь системы - 74 - УМП «Автоматизированные методы разработки архитектуры ПО» Распределение обязанностей в системе Если в ваш проект входит нечто большее, нежели пара несложных классов, предстоит позаботиться о сбалансированном распределении обязанностей. Это значит, что надо избегать слишком больших или, наоборот, чересчур маленьких классов. Каждый класс должен хорошо делать что-то одно. Если ваши абстрактные классы слишком велики, то модель будет трудно модифицировать и повторно использовать. Если же они слишком малы, то не исключено, что Вам придется иметь дело с таким большим количеством абстракций, что понимать и управлять ими будет невозможно. Используйте UML для визуализации и специфицировании баланса обязанностей.

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

o Определите обязанности каждого класса.

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

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

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

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

- 75 - УМП «Автоматизированные методы разработки архитектуры ПО» o Смоделируйте сущности, абстрагируемые в виде классов.

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

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

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

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

o Если требуется задать связанный с типом диапазон значений. Воспользуйтесь ограничениями.

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

Cтруктурированный класс обладает следующими свойствами:

o является описанной абстракцией некоторого понятия из словаря проблемной области или области решения;

o содержит определенный набор обязанностей и выполняет каждую из них;

o поддерживает четкое разделение спецификаций абстракции и ее реализации;

o понятен и прост, но в то же время допускает расширение и адаптацию к новым задачам.

- 76 - УМП «Автоматизированные методы разработки архитектуры ПО» Изображая средствами UML, придерживайтесь следующих правил:

o Показывайте только те свойства класса, которые важны для понимания абстракции в данном контексте.

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

o Показывайте взаимосвязанные классы на одной и той же диаграмме.

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

Существует три вида отношений, особенно важных для объектноориентированного моделирования:

o зависимости, которые описывают отношения между классами использования (уточнения, трассировки и связывания). Отношения зависимости это отношения использования;

o обобщения, связывающие обобщенные классы со специализированными классами. Применяемые термины "субкласс/суперкласс" или "потомок/родитель";

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

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

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

Операция потомка с той же сигнатурой, что и у родителя, замещает операцию родителя.

Это свойство называют полиморфизмом (Polymorphism).

Класс может иметь одного или нескольких родителей или не иметь их вовсе. Класс, у которого нет родителей, но есть потомки, называется базовым (base) или корневым (root), а тот, у которого нет потомков, листовым (leaf). О классе, у которого есть только один родитель, говорят, что он использует одиночное наследование (Single inheritance).

если родителей несколько, речь идет о множественном наследовании (Multiple inheritance).

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

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

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

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

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

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

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

Определите роли в системе Кратность Ассоциации отражают структурные отношения между объектами.

Часто при моделировании бывает важно указать, сколько объектов может быть связано посредством одного экземпляра ассоциации (одной связи). Это число называется кратностью роли ассоциации и записывается либо как выражение, значением которого является диапазон значений, либо в явном виде. Указывая кратность на одном конце ассоциации, вы тем самым говорите, что на этом конце именно столько объектов должно соответствовать каждому объекту на противоположном конце. Кратность можно задать равной единице (1), можно указать диапазон: "ноль или единица" (0..1), "много" (0..*), "единица или больше" (1..*). Разрешается также указывать определенное число (например, 3). С помощью списка можно задать и более сложные кратности, например 0..1, 3..4, 6..*, что означает "любое число объектов, кроме 2 и 5".

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

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

Зависимости, обобщения и ассоциации являются статическими сущностями, определенными на уровне классов. Средствами языка UML эти отношения обычно визуализируют в виде диаграмм классов.

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

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

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

- 81 - УМП «Автоматизированные методы разработки архитектуры ПО» o Найдите атрибуты, операции и обязанности, общие для двух или более классов из данной совокупности;

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

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

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

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

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

Это взгляд на ассоциации с точки зрения данных.

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

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

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

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

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

- 83 - УМП «Автоматизированные методы разработки архитектуры ПО» o Используйте зависимость, только если моделируемое отношение не является структурным.

o Используйте обобщение, только если имеет место отношение типа "является".

Pages:     | 1 |   ...   | 8 | 9 || 11 | 12 |   ...   | 16 |






















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

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