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	24	168	12,1	365	29	3
bb02	62	440	27,2	1221	86	5
…

 

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). Клейкость данных определяется как отношение суммы из количеств секций, содержащих каждую склеенную лексему, к произведению количества лексем данных в классе на количество секций данных. Метрика вычисляется по формуле:

.