Количественный анализ диаграмм UML

 

Методика количественной оценки и сравнения диаграмм U ML основана на присвоении элементам диаграмм оценок, зависящих от их информационной ценности, а также от вносимой ими в диаграмму дополнительной сложности. Ценность отдель­ных элементов меняется в зависимости от типа диаграммы, на которой они находятся.

Количественную оценку диаграммы можно провести по сле­дующей формуле:

где S — оценка диаграммы, — оценки для элементов диаграм­мы, — оценки для связей на диаграмме, Obj — число объектов на диаграмме, — число типов объектов на диаграмме, — число типов связей на диаграмме.

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

Если на диаграмме классов показаны атрибуты и операции классов, можно учесть их при расчете, при этом оценка прибав­ляется к оценке соответствующего класса:

где — оценка операций и атрибутов для класса, Op — число операций у класса, Atr - число атрибутов у класса. При этом учи­тываются только атрибуты и операции, отображенные на диаг­рамме.

Далее приводятся оценки для различных типов элементов и связей.

Основные элементы языка UML

Тип элемента	Оценка для элемента
Класс
Интерфейс
Вариант использования
Компонент
Узел (node)
Процессор
Взаимодействие
Пакет
Состояние
Примечание

Основные типы связей языка UML

Тип связи	Оценка для связи
Зависимость
Ассоциация
Агрегация
Композиция
Обобщение
Реализация

 

Остальные типы связей должны рассматриваться как ассоци­ации.

Недостатком диаграммы является как слишком низкая оцен­ка (при этом диаграмма недостаточно информативна), так и слишком высокая оценка (при этом диаграмма обычно слишком сложна для понимания). Далее приведены диапазоны оптималь­ных оценок для основных типов диаграмм.

Диапазоны оценок для диаграмм UML

Тип диаграммы	Диапазон оценок
Классов — с атрибутами и операциями	5-5,5
Классов — без атрибутов и операций	3-3,5
Компонентов	3,5-4
Вариантов использования	2,5-3
Размещения	2-2,5
Последовательности	3-3,5
Кооперативная	3,5-4
Пакетов	3,5-4
Состояний	2,5-3

2.6.

ОБРАЗЦЫ

 

Образцы (patterns) — это одни из важнейших составных частей объектно-ориентированной технологии разработки ПО. Они широко применяются в инструментах анализа, подробно описываются в книгах[20] и часто обсуждаются на конференциях семина­рах по объектно-ориентированному проектированию. Существу­ет множество групп и курсов по их изучению. Изучение образцов помогает лучше понять объектно-ориентированный анализ и проектирование.

Объектно-ориентированное проектирование ПО — достаточ­но сложный процесс, который еще больше усложняется в случае необходимости повторного использования проектных решений. 11еобходимо подобрать подходящие объекты, отнести их к раз­личным классам, соблюдая разумную степень детализации, опре­делить интерфейсы классов и иерархию наследования и установить существенные связи между классами. Проектное решение должно, с одной стороны, соответствовать решаемой задаче, а с другой — быть достаточно общим, чтобы удалось учесть все тре­бования, которые могут возникнуть в будущем. Желательно так­же избежать или, по крайней мере, свести к минимуму необходимость перепроектирования. Опытные разработчики знают, что обеспечить «правильное», т.е. в достаточной мере гибкое и при­годное для повторного использования решение, с первого раза очень трудно, если вообще возможно. Прежде чем считать цель достигнутой, они обычно пытаются опробовать найденное реше­ние на нескольких задачах и каждый раз модифицируют его.

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

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

По словам Кристофера Александера, «любой образец описы­вает задачу, которая снова и снова возникает в нашей работе, а также принцип ее решения, причем таким образом, что это реше­ние можно потом использовать миллион раз, ничего не изобретая заново». Хотя Александер имел в виду образцы, возникающие при проектировании зданий и городов, но его слова верны и в от­ношении образцов объектно-ориентированного проектирова­ния. Решения относительно ПО выражаются в терминах объек­тов и интерфейсов, а не стен и дверей, но в обоих случаях образец можно определить как общее решение некоторой проблемной ситу­ации в заданном контексте. Образец состоит из четырех основных элементов:

· имя;

· проблема;

·решение;

·следствия.

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

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

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

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

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

·образцы бизнес-моделирования;

·образцы анализа;

·образцы поведения;

·образцы проектирования;

·архитектурные образцы;

·образцы программирования.

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

В языке UML образец представляется с помощью коопера­ции со стереотипом «pattern». Кооперация (collaboration) опреде­ляется как описание совокупности взаимодействующих объек­тов, реализующих некоторое поведение (например, в рамках ва­рианта использования или операции класса). Кооперация имеет статическую и динамическую части. В статической части (на ди­аграмме классов) описываются роли, которые могут играть объ­екты и связи в экземпляре данной кооперации. Динамическая часть состоит из одной или более диаграмм взаимодействия, по­казывающих потоки сообщений, которыми обмениваются участники кооперации. Кроме того, любой образец содержит стандартную диаграмму классов под названием «Participants» («Участники»), на которой изображается сам образец в виде ко­операции с его именем и набор классов, участвующих в реализа­ции образца.

В качестве примера приведем образец бизнес-моделирования под названием Employment (Занятость).

Проблема заключается в моделировании различных форм за­нятости в пределах организации. Данная задача решается в кон­тексте системы планирования ресурсов предприятия.

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

На рис. 2.60 приведена диаграмма «Участники» для данного образца. Она содержит кооперацию Employment и набор из пяти классов.

· Employee Profile (Служащий) — описание служащего с набо­ром атрибутов.

· Organization Profile (Организация) — описание самой орга­низации.

·Employment (Занятость) — описание связи между служащим и организацией.

·Position (Должность) — описание должности со своими ат­рибутами (такими, как должностной оклад и должностные инструкции).

·Position Assignment (Назначение на должность) — описание связи между служащим и занимаемыми должностями.

Рис. 2.60. Диаграмма «Участники» для образца Employment

Статическая часть образца (диаграмма классов) показана на рис. 2.61.

Достоинства применения образцов при проектировании ПО заключаются в следующем:

· Возможность многократного использования. Повторное ис­пользование решений из уже завершенных успешных про­ектов позволяет быстро приступить к решению новых проб­лем и избежать типичных ошибок. Разработчик получает прямую выгоду от использования опыта других разработчи­ков, избежав необходимости вновь и вновь «изобретать ве­лосипед».

· Применение единой терминологии. Профессиональное обще­ние и работа в группе (команде разработчиков) требует на­личия единого базового словаря и единой точки зрения на проблему.

Рис. 2.61. Статическая часть образца Employment

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

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

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

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

 

2.7.