Прецеденты определяют, как исполнители взаимодействуют с программной системой. В процессе этого взаимодействия исполнителем генерируются события, передаваемые системе, которые представляют собой запросы на. выполнение некоторой операции. В качестве системы обозначений в состав языка UML входят диаграммы последовательностей (sequence diagram). С их помощью можно проиллюстрировать взаимодействие исполнителя с системой и операции, выполнение которых при этом инициируется.
Диаграмма последовательностей системы (system sequence diagram) является схемой, которая для определенного сценария прецедента показывает генерируемые внешними исполнителями события, их порядок, а также события, генерируемые внутри самой системы. При этом все системы рассматриваются как "черный ящик". Назначение данной диаграммы — отображение событий, передаваемых исполнителями системе через ее границы. Диаграмма последовательностей должна быть создана для типичного хода событий прецедентов, а при необходимости и для наиболее существенных альтернативных последовательностей. Основная идея - это то, что диаграмма последовательности показывает "прохождение" логики выполнения в сценарии, позволяя вам документировать и реально контролировать проект вашего приложения.
Диаграммы последовательности имеют две размерности: вертикальная представляет время, горизонтальная - различные объекты. Прямоугольники на вертикальных линиях показывают "время жизни" объекта. Линии со стрелками и надписями названий методов означают вызов метода у объекта. Объекты (экземпляры) в UML отображаются подчеркнутыми, чтобы отличить их от классов.
Системные события и операции
Системное событие (system event) — это внешнее входное событие, сгенерированное для системы исполнителем. Событие инициирует выполнение определенной операции. Системная операция (system operation) является операцией, которую система выполняет в ответ на сгенерированное событие. Описание системной операции (contract) — это документ, описывающий предполагаемые результаты выполнения операций и акцентирует внимание на том, что должно произойти, а не на том, ка к этого достичь. Описание системной операции (system operation contract) описывает изменение состояния всей системы при выполнении некоторой системной операции.
23. ООАП. Анализ и проектирование: диаграммы кооперации.
Кооперативные диаграммы (collaboration diagrams) Представляют взаимодействие между объектами и отношения объектов друг к другу. Кооперативные диаграммы представляют собой граф, состоящий из объектов и соединяющих дуг с обозначенными на них событиями. Граф показывает объекты, участвующие в процессе выполнения определенного варианта использования включая объекты, косвенно затронутые этим взаимодействием.
В отличие от некоторых нотаций, которые отображают состояние и поведение на диаграммах классов, UML отделяет поведение в диаграммы взаимодействия. Основное отличие между двумя подходами, это то, что в UML диаграммы классов не содержат сообщений, потому что сообщения больше мешают на диаграммах классов и усложняют их чтение. В UML, чтобы не "перегружать" диаграммы классов и не показывать на них поток сообщений, были созданы диаграммы взаимодействия. Эти диаграммы показывают поток сообщений между объектами в объектно-ориентированном приложении, и подразумевают основные ассоциации между объектами.
Диаграммы взаимодействия обычно рисуются параллельно диаграммам классов, особенно если диаграммы последовательности не разрабатывались для вашего приложения. Вы можете использовать диаграммы взаимодействия, чтобы получить "большую картинку" системы, включающей поток сообщений многих сценариев. Также вы можете указать порядок потока сообщений на диаграмме, нумеруя их. Обычно этого не делается, так как диаграммы последовательностей больше подходят для показа порядка сообщений.
Диаграмма последовательностей последовательно моделирует каждый сценарий. Диаграмма последовательностей и диаграммы совместной работы в UML называются диаграммами взаимодействия. Они являются представлениями одного и того же; однако диаграмма совместной работы обычно используется на более позднем этапе проектирования. Диаграмма последовательностей перехватывает сообщения, посылаемые объектами друг другу при использовании условия в пределах одного и того же сценария. Отразить более одного сценария в диаграмме последовательностей достаточно трудно, но это относительно просто сделать в диаграмме совместной работы.
24. ООАП: использование диаграмм компонентов в процессе проектирования
Диаграммы компонентов показывают организацию наборов компонентов и зависимости между ними.
Диаграммы компонентов применяются для моделирования статического вида системы с точки зрения реализации. Сюда относится моделирование физических сущностей, развернутых в узле, например исполняемых программ, библиотек, таблиц, файлов и документов. По существу, диаграммы компонентов - это не что иное, как диаграммы классов, сфокусированные на системных компонентах.
Диаграммы компонентов важны не только для визуализации, специфицирования и документирования системы, основанной на компонентах, но и для создания исполняемых систем путем прямого и обратного проектирования.
Содержание
· компоненты;
· интерфейсы;
· отношения зависимости, обобщения, ассоциации и реализации.
Диаграммы компонентов могут также содержать пакеты или подсистемы - те и другие используются для группирования элементов модели в крупные блоки.
25. ООАП: использование диаграмм развёртывания в процессе проектирования ИС.
Диаграммы развертывания, или применения, - показывают конфигурацию узлов, где производится обработка информации, и то, какие компоненты размещены на каждом узле.
Диаграммы развертывания используются для моделирования статического вида системы с точки зрения развертывания. В основном под этим понимается моделирование топологии аппаратных средств, на которых выполняется система. По существу, диаграммы развертывания - это просто диаграммы классов, сосредоточенные на системных узлах.
Диаграммы развертывания важны не только для визуализации, специфицирования и документирования встроенных, клиент-серверных и распределенных систем, но и для управления исполняемыми системами с использованием прямого и обратного проектирования.
Содержание
· узлы;
· отношения зависимости и ассоциации.
26. Шаблоны проектирования: обязанности и методы, обязанности и диаграммы взаимодействий.
В UML обязанность определяется как контракт или обязательство классификаторов. Обязанности описывают поведение объекта. В общем случае можно выделить 2 типа обязанностей:
1. знание;
2. действие.
К знаниям объекта относятся:
- наличие информации о закрытых инкапсулированных данных;
- наличие информации о связанных объектах;
- наличие информации о следствиях или вычисляемых величинах.
К действиям объекта относятся:
- выполнение объектом некоторых действий (например, создание экземпляра или выполнение вычислений);
- инициирование действий других объектов;
- управление действиями других объектов и их координирование;
Обязанности присваиваются объектам в процессе ООП.
Шаблон - именованное описание проблемы и её решение, которое можно применить при разработке других систем.
Шаблон должен содержать советы по поводу его применения в различных ситуациях, а также описание его преимуществ и недостатков.
Кооперацией называется реализация прецедента. Кооперации содержат 2 составляющие: статическая (структурная) и динамическая (поведенческая).
Статическая составляющая кооперации задает структуру совместно работающих классов и других элементов (интерфейсов, компонентов, узлов). Для этого используют диаграммы классов. Динамическая составляющая определяет поведение совместно работающих элементов. Для нее используют диаграммы взаимодействия. Настраиваемые кооперации называют шаблонами.
Части шаблона:
Имя – выразительное имя шаблона дает возможность указать проблему проектирования, ее решения и последствия решения
Проблема – формулируется проблема проектирования, ее контекст, на которые ориентировано применение шаблона, задаются условия применения
Решение – описываются элементы решения, их отношения, обязанности, сотрудничество. Представляется в обобщенной форме, которая должна конкретизироваться при применении.
Результаты – перечисляются следствия применения шаблона и вытекающие из них компромиссы. Позволяет оценить эффективности применения шаблона в данной ситуации
27. Проектные решения с использованием шаблонов: шаблон Creator.
Шаблон - именованное описание проблемы и её решение, которое можно применить при разработке других систем.
Проблема: кто должен отвечать за создание нового экземпляра некоторого класса.
Решение: назначить классу В обязанность, создавать экземпляры класса А, если выполняется одно из следующих условий:
- класс В агрегирует объекты А;
- класс В содержит объекты А;
- класс В записывает экземпляры объектов А;
- класс В активно использует объекты А;
- класс В обладает данными инициализации, которые будут передаваться объектам А при их создании;
Если одно из этих условий выполняется, то класс В является создателем класса А.
Если выполняется несколько из этих условий, то лучше использовать класс В агрегирующий или содержащий класс А.Шаблон определяет способ распределения обязанностей, связанный с процессом создания объектов. Основным назначением шаблона является выявление объекта создателя, который при возникновении любого события должен быть связан со всеми созданными им объектами. При таком подходе обеспечивается низкая степень связанности. В шаблоне определяется, что внешний контейнер или класс регистратор это кандидаты на выполнение обязанностей связанных с созданием сущностей, которые они будут создавать или регистрировать.
Преимущества: применение шаблонов не повышает степени связанности, поскольку созданный класс, как правило оказывается видимым для класса создателя по средствам имеющихся ассоциаций.
28. Проектные решения с использованием шаблонов: шаблон Expert
Шаблон - именованное описание проблемы и её решение, которое можно применить при разработке других систем.
Проблема: каков наиболее общий принцип распределения обязанностей между объектами.
Решение: назначить обязанность информационному эксперту, классу у которого имеется информация, требующаяся для выполнения обязанностей.
Главная идея шаблона заключается в том, что объекты осуществляют действия связанные с имеющейся у них информацией. Для выполнения обязанностей зачастую требуется информация, распределённая между различными классами или объектами. Это предполагает, что должно существовать много частичных экспертов взаимодействующих при выполнении общей задачи.
Когда не следует применять шаблон: в ситуациях, когда присутствуют проблемы со связыванием и зацеплением.
Преимущества: шаблон эксперт поддерживает инкапсуляцию, для выполнения требуемых задач объекты используют собственные данные; соответствующее поведение системы обеспечивается несколькими классами, содержащими требуемую информацию, это приводит к определению классов, которые гораздо проще понимать и поддерживать.
29. Проектные решения с использованием шаблонов: шаблон Observer (Наблюдатель).
Задает между объектами такую зависимость «один-ко-многим», при которой изменение состояние одного объекта приводит к оповещению и автоматическому обновлению зависящих от него объектов.
Проблема: при разбиении системы на набор совместно работающих объектов появляется необходимость поддерживать их согласованное состояние. При этом желательно минимизировать сцепление.
Применение:
- необходимо организовать непрямое взаимодействие объектов уровня логики приложения с интерфейсом пользователя
- при изменении состояния одного объекта должны изменить свое состояние все зависимые объекты
- один объект рассылает сообщения другим объектам, не делая о них никаких предположений
Решение: ключевыми элементами решения является субъект и наблюдатель. У субъекта может быть любое количество наблюдателей. Когда происходит изменение состояния субъекта, наблюдатель автоматически об этом уведомляется. Получив уведомление, наблюдатель опрашивает субъект, синхронизируя с ним свое отображение состояния.
Статическая составляющая включает абстрактный класс субъект и наблюдатель. Субъекту известно только об абстрактном наблюдателе. В результате между этими объектами установлено минимальное сцепление.
Недостатки: изменения в субъекте могут привести к неоправданно большому обновлению наблюдателей
30. Проектные решения с использованием шаблонов: шаблон Controller.
Проблема: кто должен отвечать за обработку системных событий?
Решение: делегирование обязанностей по обработке системных сообщений классу, удовлетворяющему одному из следующих условий:
1. Класс представляет систему в целом (внешний контроллер)
2. Класс представляет всю организацию в целом (внешний контроллер)
3. Класс представляет активный объект из реального мира, который может участвовать в решении задачи (контроллер роли)
4. Класс представляет искусственный обработчик всех системных событий некоторого прецедента (контроллер прецедента)
Контроллер – объект, не относящийся к интерфейсу пользователя, отвечающий за обработку системных событий, он определяет методы выполнения системных операций.
Чтобы иметь возможность поддерживать информацию … для обработки системных событий, должен использоваться один и тот же контроллер.
Типичной ошибкой при создании контроллеров является возложение на них слишком большого числа обязанностей. Обычно контроллер должен лишь делегировать функции другим объектам и соответственно контролировать их деятельность.
Внешний контроллер может представлять физический объект, например, вся программная часть системы или любые другие понятия, выбранные разработчиком для представления системы в целом. Внешние контроллеры удобно использовать в том случае, когда существует лишь несколько системных событий или системные сообщения невозможно перенаправить другим контроллерам. Если применяется контроллер прецедента, то для каждого прецедента должен существовать отдельный контроллер, их может быть даже несколько для каждого прецедента.
Важным следствием шаблона Controller является вынесение обязанностей по выполнению системных функций за пределы уровня представления.
Преимущества:
1. Улучшение условий для повторного использования компонентов
2. Контроль состояния прецедента
Раздутым называется контроллер, выполняющий слишком много обязанностей, соответственно, имеющий низкую степень связности.
Признаки раздутого контроллера:
1. В системе имеется единственный класс контроллера, получающий все системные сообщений, которых поступает слишком много. Такая ситуация характерна для внешнего контроллера.
2. Контроллер сам выполняет все обязанности, не делегируя их другим классам.
3. Контроллер имеет много атрибутов и содержит значительный объем информации о системе или предметной области, которую необходимо распределить между другими объектами, либо дублирует информацию, хранящуюся в других объектах.
Для устранения проблем раздутого контроллера нужно:
1. Добавить несколько контроллеров.
2. Спроектировать контроллер таким образом, чтобы он делегировал обязанности по выполнению системных операций другим объектам.
Для системы обработки сообщений при назначении контроллера:
1. Необходимо определить один контроллер для всей системы обработки сообщений. Это может быть внешний контроллер либо контроллер прецедента
2. Для обработки запросов необходимо использовать шаблон Command.
Согласно шаблону Command, для каждого сообщения или команды определяется свой класс с методом execute. Контроллер будет создавать экземпляр команды, соответствующий типу сообщения, и передавать ему сообщения. Класс каждой команды содержит единственный метод execute, определяющий действия для каждой команды.
31. Проектные решения с использованием шаблонов: шаблон Command.
Проблема: кто должен отвечать за обработку входных системных событий
Решение: делегирование обязанностей по обработке системных сообщений классу, удовлетворяющих одному из след. условий:
1. класс представляет всю систему в целом (внешний контроллер)
2. класс представляет всю организацию (внешний контроллер)
3. класс представляет активный объект (контроллер роли)
4. класс представляет искусственный обработчик всех системных событий некоторого прецедента (контроллер прецедента или контроллер сеанса)
Для всех системных событий в рамках одного прецедента используется один и тот же класс-контроллер.
Следствие: в этот перечень не включаются классы, реализующие окно, приложение и документы
32. Размерно-ориентированные метрики.
Размерно-ориентированные метрики.
Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются они на LOC (lines of code) оценках – количество строк в программном продукте. Исходные данные для таких оценок сводятся в таблицу.
| Проект | Затраты, чел.-мес. | Стоимость, тыс. $ | KLOC, тыс. LOC | Программный документ, стр. | Ошибки | Люди |
| аа001 | 12,1 | |||||
| bb02 | 27,2 | |||||
| … |
1. 
2. 
3. 
4. 
Достоинства этих характеристик: хорошо вычисляются и широко распространены.
Недостатки:
1. они зависимы от языка программирования;
2. требуют исходных данных, которые трудно получить на начальной стадии проекта;
3. не приспособлены к непроцедурным языкам программирования.
33. Функционально ориентированные метрики.
Используются 5 информационных характеристик:
1. количество внешних вводов – подсчитываются все вводы пользователя;
2. количество внешних выводов – подсчитываются все выводы;
3. количество внешних запросов – диалоговый ввод, который приводит к немедленному программному ответу;
4. количество внутренних логических файлов;
5. количество внешних интерфейсных файлов – подсчитывается общее количество логических файлов из других приложений, на которые ссылается данное приложение.
34. ОО Метрики: Метрики связности по данным
Л. Отт и Б. Мехра разработали модель секционирования класса. Секционирование основывается на экземплярных переменных класса. Для каждого метода класса получают ряд секций, а затем производят объединение всех секций класса. Измерение связности основывается на количестве лексем данных (data tokens), которые появляются в нескольких секциях и «склеивают» секции в модуль. Под лексемами данных здесь понимают определения констант и переменных или ссылки на константы и переменные.
Базовым понятием методики является секция данных. Она составляется для каждого выходного параметра метода. Секция данных — это последовательность лексем данных в операторах, которые требуются для вычисления этого параметра.
Секционированной абстракцией класса (Class Slice Abstraction) CSA(C) называют объединение секций всех экземплярных переменных класса. Полный набор секций составляют путем обработки всех методов класса.
Склеенными лексемами называют те лексемы данных, которые являются элементами более чем одной секции данных.
Сильно склеенными лексемами называют те склеенные лексемы, которые являются элементами всех секций данных.
Сильная связность по данным (StrongData Cohesion) — это метрика, основанная на количестве лексем данных, входящих во все секции данных для класса. Иначе говоря, сильная связность по данным учитывает количество сильно склеенных лексем в классе С, она вычисляется по формуле:
,
где SG (CSA(C)) — объединение сильно склеенных лексем каждого из методов класса С, лексемы (С) — множество всех лексем данных класса С.
Таким образом, класс без сильно склеенных лексем имеет нулевую сильную связность по данным.
Слабая связность по данным (Weak Data Cohesion) — метрика, которая оценивает связность, базируясь на склеенных лексемах. Склеенные лексемы не требуют связывания всех секций данных, поэтому данная метрика определяет более слабый тип связности. Слабая связность по данным вычисляется по формуле:
,
где G (CSA(C)) — объединение склеенных лексем каждого из методов класса. Класс без склеенных лексем не имеет слабой связности по данным. Наиболее точной метрикой связности между секциями данных является клейкость данных (Data Adhesiveness). Клейкость данных определяется как отношение суммы из количеств секций, содержащих каждую склеенную лексему, к произведению количества лексем данных в классе на количество секций данных. Метрика вычисляется по формуле:
.
35. ОО Метрики: Метрики связности по методам
Д. Биемен и Б. Кенг предложили метрики связности класса, которые основаны на прямых и косвенных соединениях между парами методов. Если существуют общие экземплярные переменные (одна или несколько), используемые в паре методов, то говорят, что эти методы соединены прямо. Пара методов может быть соединена косвенно, через другие прямо соединенные методы.
На рис. представлены отношения между элементами класса Stack. Прямоугольниками обозначены методы класса, а овалами — экземплярные переменные. Связи показывают отношения использования между методами и переменными.
Отношения между элементами класса Stack
Из рисунка видно, что экземплярная переменная top используется методами Stack, Push, Pop, Vtop и IsEmpty. Таким образом, все эти методы попарно прямо соединены. Напротив, методы Size и Pop соединены косвенно: Size соединен прямо с Push, который, в свою очередь, прямо соединен с Pop. Метод Stack является конструктором класса, то есть функцией инициализации. Обычно конструктору доступны все экземплярные переменные класса, он использует эти переменные совместно со всеми другими методами. Следовательно, конструкторы создают соединения и между такими методами, которые никак не связаны друг с другом. Поэтому ни конструкторы, ни деструкторы здесь не учитываются. Связи между конструктором и экземплярными переменными на рис показаны пунктирными линиями.
Для формализации модели вводятся понятия абстрактного метода и абстрактного класса.
Абстрактный метод АМ(М) — это представление реального метода М ввиде множества экземплярных переменных, которые прямо или косвенно используются методом.
Экземплярная переменная прямо используется методом М, если она появляется в методе как лексема данных. Экземплярная переменная может быть определена в том же классе, что и М, или же в родительском классе этого класса. Множество экземплярных переменных, прямо используемых методом М, обозначим как DU(M).
Экземплярная переменная косвенно используется методом М, если: 1) экземплярная переменная прямо используется другим методом М', который вызывается (прямо или косвенно) из метода М; 2) экземплярная переменная, прямо используемая методом М', находится в том же объекте, что и М.
Множество экземплярных переменных, косвенно используемых методом М, обозначим как IU(М).
Количественно абстрактный метод формируется по выражению:
AM (М) = DU (М) 
IU (М).
Абстрактный класс АС(С) — это представление реального класса С в виде совокупности абстрактных методов, причем каждый абстрактный метод соответствует видимому методу класса С. Количественно абстрактный класс формируется по выражению:
АС (С) = [[AM (M) | M 
V (С) ]],
где V(C) — множество всех видимых методов в классе С и в классах — предках для С.
Отметим, что АМ-представления различных методов могут совпадать, поэтому в АС могут быть дублированные элементы. В силу этого АС записывается в форме мультимножества (двойные квадратные скобки рассматриваются как его обозначение).
Локальный абстрактный класс LAC(C) — это совокупность абстрактных методов, где каждый абстрактный метод соответствует видимому методу, определенному только внутри класса С. Количественно абстрактный класс формируется по выражению:
LAC (C) =[[AM (M)|M LV (C) ]],
где LV (C) — множество всех видимых методов, определенных в классе С.
Абстрактный класс для стека, приведенного в табл. 14.2, имеет вид:
AC (Stack) = [[{top}, {size}, {array, top}, {array, top, size}, {pop}]].
Поскольку класс Stack не имеет суперкласса, то справедливо:
AC (Stack) = LAC (Stack)
Пусть NP (C) — общее количество пар абстрактных методов в AC (C). NP определяет максимально возможное количество прямых или косвенных соединений в классе. Если в классе С имеются N методов, тогда NP (C) = N*(N- l)/2. Обозначим:
ü NDC (C) — количество прямых соединений AC(Q;
ü NIC (C) — количество косвенных соединений в АС(С).
Тогда метрики связности класса можно представить в следующем виде:
ü сильная связность класса (Tight Class Cohesion (ТСС)) определяется относительным количеством прямо соединенных методов:
ТСС (С) = NDC (С) / NP (С);
ü слабая связность класса (Loose Class Cohesion (LCC)) определяется относительным количеством прямо или косвенно соединенных методов:
LCC (С) = (NDC (С) + NIC (С)) / NP (С).
Очевидно, что всегда справедливо следующее неравенство:
LCC (C) >=TCC (C).
Для класса Stack метрики связности имеют следующие значения:
TCC(Stack)=7/10=0,7
LCC(Stack)=10/10=l
Метрика ТСС показывает, что 70% видимых методов класса Stack соединены прямо, а метрика LCC показывает, что все видимые методы класса Stack соединены прямо или косвенно.
Метрики ТСС и LCC индицируют степень связанности между видимыми методами класса. Видимые методы либо определены в классе, либо унаследованы им. Конечно, очень полезны метрики связности для видимых методов, которые определены только внутри класса — ведь здесь исключается влияние связности суперкласса. Очевидно, что метрики локальной связности класса определяются на основе локального абстрактного класса. Отметим, что для локальной связности экземплярные переменные и вызываемые методы могут включать унаследованные переменные.
36. ОО Метрики: объектно-ориентированные метрики сцепления
В классическом методе Л. Констентайна и Э. Йордана определены шесть типов сцепления, которые ориентированы на процедурное проектирование [77].
Принципиальное преимущество объектно-ориентированного проектирования в том, что природа объектов приводит к созданию слабо сцепленных систем. Фундаментальное свойство объектно-ориентированного проектирования заключается в скрытости содержания объекта. Как правило, содержание объекта невидимо внешним элементам. Степень автономности объекта достаточно высока. Любой объект может быть замещен другим объектом с таким же интерфейсом.
Тем не менее наследование в объектно-ориентированных системах приводит к другой форме сцепления. Объекты, которые наследуют свойства и операции, сцеплены с их суперклассами. Изменения в суперклассах должны проводиться осторожно, так как эти изменения распространяются во все классы, которые наследуют их характеристики.
Таким образом, сами по себе объектно-ориентированные механизмы не гарантируют минимального сцепления. Конечно, классы — мощное средство абстракции данных. Их введение уменьшило поток данных между модулями и, следовательно, снизило общее сцепление внутри системы. Однако количество типов зависимостей между модулями выросло. Появились отношения наследования, делегирования, реализации и т. д. Более разнообразным стал состав модулей в системе (классы, объекты, свободные функции и процедуры, пакеты). Отсюда вывод: необходимость измерения и регулирования сцепления в объектно-ориентированных системах обострилась.
Рассмотрим объектно-ориентированные метрики сцепления, предложенные М. Хитцем и Б. Монтазери
Зависимость изменения между классами
Зависимость изменения между классами CDBC (Change Dependency Between Classes) определяет потенциальный объем изменений, необходимых после модификации класса-сервера SC (server class) на этапе сопровождения. До тех пор, пока реальное количество необходимых изменений класса-клиента СС (client class) неизвестно, CDBC указывает количество методов, на которые влияет изменение SC.
CDBC зависит от:
ü области видимости изменяемого класса-сервера внутри класса-клиента (определяется типом отношения между CS и СС);
ü вида доступа СС к CS (интерфейсный доступ или доступ реализации).
Возможные типы отношений приведены в табл. 14.3, где п — количество методов класса СС, 
— количество методов СС, потенциально затрагиваемых изменением.
Вклад отношений между клиентом и сервером в зависимость изменения
| Тип отношения | |
| SC не используется классом СС SC — класс экземплярной переменной в классе СС Локальные переменные типа SC используются внутри /-методов класса СС SC является суперклассом СС SC является типом параметра для/-методов класса СС СС имеет доступ к глобальной переменной класса SC | n j n j n |
Конечно, здесь предполагается, что те элементы класса-сервера SC, которые доступны классу-клиенту СС, являются предметом изменений. Авторы исходят из следующей точки зрения: если класс SC является «зрелой» абстракцией, то предполагается, что его интерфейс более стабилен, чем его реализация. Таким образом, многие изменения в реализации SC могут выполняться без влияния на его интерфейс. Поэтому вводится фактор стабильности интерфейса для класса-сервера, он обозначается как к (0 < k < 1). Вклад доступа к интерфейсу в зависимость изменения можно учесть умножением на (1 - k).
Метрика для вычисления степени CDBC имеет вид:
;
CDBC(CC, SC) = min(n, A).
Пути минимизации CDBC:
1) ограничение доступа к интерфейсу класса-сервера;
2) ограничение видимости классов-серверов (спецификаторами доступа public, protected, private).
Локальность данных
Локальность данных LD (Locality of Data) — метрика, отражающая качество абстракции, реализуемой классом. Чем выше локальность данных, тем выше самодостаточность класса. Эта характеристика оказывает сильное влияние на такие внешние характеристики, как повторная используемость и тестируемость класса.
Метрика LD представляется как отношение количества локальных данных в классе к общему количеству данных, используемых этим классом.
Будем использовать терминологию языка C++. Обозначим как Mi(1 
i n) методы класса. В их число не будем включать методы чтения/записи экземплярных переменных. Тогда формулу для вычисления локальности данных можно записать в виде:
,
где:
ü Li(1 i n) — множество локальных переменных, к которым имеют доступ методы Mi (прямо или с помощью методов чтения/записи). Такими переменными являются: непубличные экземплярныё переменные класса; унаследованные защищенные экземплярныё переменные их суперклассов; статические переменные, локально определенные в Mi;
ü Ti(1 i n) — множество всех переменных, используемых в Mi, кроме динамических локальных переменных, определенных в Mi.
Для обеспечения надежности оценки здесь исключены все вспомогательные переменные, определенные в Mi , — они не играют важной роли в проектировании.
Защищенная экземплярная переменная, которая унаследована классом С, является локальной переменной для его экземпляра (и следовательно, является элементом Li), даже если она не объявлена в классе С. Использование такой переменной методами класса не вредит локальности данных, однако нежелательно, если мы заинтересованы уменьшить значение CDBC.
37. ОО Метрики: Набор метрик Чидамбера и Кемерера
Метрика 1: Взвешенные методы на класс (Weighted Methods Per Class)
Пусть в классе C определены n методов со сложностью c1, c2, c3, …, cn
WMC = ∑ ci
В упрощенной версии метрики полагают ci=1, тогда WMC – количество методов в классе.
Метрика 2: Высота дерева наследования DIT (Depth of Inheritance Tree)
Максимальная длина листа от корня дерева.
Метрика 3: Количество детей NOC (Number of children)
Совпадает с количеством непосредственных наследников класса.
Оптимальное значение 7 по ширине и по высоте для дерева.
Метрика 4: Сцепление между классами объектов CBO (Coupling between object classes)
Количество сотрудничеств, предусмотренных для класса.
Метрика 5: Отклик для класса RFC (Response For a Class)
Количество методов класса + количество методов других классов, вызываемых из данного класса.
Метрика 6: Недостаток связности в методах LCOM (Lack of Cohesion in Methods)
Эта метрика показывает, насколько методы несвязанны друг с другом через свойства.
Не связаны – количество пар методов без общих экземпляров переменных;
Связаны – количество пар методов с общими экземплярными переменными.
Ij – набор экземплярных переменных, используемых методом Mj
Очевидно, что НЕ СВЯЗАНЫ=card{Iij|IiпересечениеIj=0}
СВЯЗАНЫ= card{Iij|IiпересечениеIj<>0}
Недостаток связности в методах
LCOM=не связаны-связаны, если (не связаны>связаны) и 0, в противном случае
Связность методов внутри класса должна быть высокой, т.к. …. Но это увеличивает сложность, в том числе, и при проектировании.
38. ОО Метрики: метрик Лоренца и Кидда
Метрики, ориентированные на классы
Все метрик разделены на 4 категории
1. Размер класса CS (Class Size)
Общий размер класса определяется: 1. Общее количество операций, которые инкапсулируются внутри класса; 2. Количество свойств, которые инкапсулируются внутри класса.
Большое значение указывает на то, что у класса есть много обязанностей, т.е. требуется перепроектировать. Рекомендуемое значение CS<=20 методов.
2. Количество операций, переопределяемых подклассом, NOO (Number of Operations Overridden by a Subclass)
Рекомендуемое значение NOO<=3 методов.
3. Количество операций, добавленных подклассом, NOA (Number of Operations Added by a Subclass)
Значение этой характеристики должно уменьшаться. Для рекомендуемых значений SC = 20 и DIT=6 рекомендуемое значение NOA<4 методов.
4. Индекс специализации SI (Specialization Index)
SI = (NOO*уровень)/Mобщ
Уровень – номер уровня в иерархии
Mобщ – количество методов в классе.
Рекомендуемое значение SI<=0,15
Операционно-ориентированные метрики
5. Средний размер операции OSAVG (Average Operation Size)
Рекомендуемое значение OSAVG<=9
6. Сложность операции OC (Operation Complexity)
Весовые коэффициенты для метрики ОС (см. таблицу).
Рекомендуемое значение OC<=65
7. Среднее количество параметров на операцию NPAVG
Рекомендуемое значение =0,7
