Главная страница

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


Скачать 7.57 Mb.
НазваниеУчебное пособие по дисциплине технология разработки программного обеспечения специальность Программирование в компьютерных системах
Анкоркурсовая работа
Дата08.01.2023
Размер7.57 Mb.
Формат файлаdoc
Имя файла2_5397965015586183048-7.doc
ТипУчебное пособие
#877236
страница11 из 30
1   ...   7   8   9   10   11   12   13   14   ...   30
Глава 5. Основы объектно-ориентированного

представления программных систем. Метрики
1. Принципы объектно-ориентированного

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

Абстрагирование

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

Инкапсуляция

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

Модульность

В языках C++, Object Pascal, Ada 95 абстракции классов и объектов формируют логическую структуру системы. При производстве физической структуры эти абстракции помещаются в модули. В больших системах, где классов сотни, модули помогают управлять сложностью. Модули служат физическими контейнерами, в которых объявляются классы и объекты логической разработки. Модульность определяет способность системы подвергаться декомпозиции на ряд сильно связанных и слабо сцепленных модулей. Общая цель декомпозиции на модули: уменьшение сроков разработки и стоимос­ти ПС за счет выделения модулей, которые проектируются и изменяются незави­симо. Каждая модульная структура должна быть достаточно простой, чтобы быть полностью понятой. Изменение реализации модулей должно проводиться без зна­ния реализации других модулей и без влияния на их поведение. Определение классов и объектов выполняется в ходе логической разработки, а определение модулей — в ходе физической разработки системы. Эти действия сильно взаимосвязаны, осуществляются итеративно.

Иерархическая организация

Мы рассмотрели три механизма для борьбы со сложностью:

  • абстракцию (она упрощает представление физического объекта);

  • инкапсуляцию (закрывает детали внутреннего представления абстракций);

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

Дополнением к этим механизмам является иерархическая организа­ция — формирование из абстракций иерархической структуры. Определением иерархии в проекте упрощаются понимание проблем заказчика и их реализация — сложная система становится обозримой человеком. Иерархическая организация задает размещение абстракций на различных уров­нях описания системы.

Двумя важными инструментами иерархической организации в объектно-ориен­тированных системах являются:

  • структура из классов («is a»-иерархия);

  • структура из объектов («part of »-иерархия).

Чаще всего «is а»-иерархическая структура строится с помощью наследования. Наследование определяет отношение между классами, где класс разделяет структу­ру или поведение, определенные в одном другом (единичное наследование) или в нескольких других (множественное наследование) классах.

Другая разновидность иерархической организации — «part of»- иерархическая структура — базируется на отношении агрегации. Агрегация не является понятием, уникальным для объектно-ориентированных систем. Например, любой язык про­граммирования, разрешающий структуры типа «запись», поддерживает агрегацию. И все же агрегация особенно полезна в сочетании с наследованием:

  • агрегация обеспечивает физическую группировку логически связанной структуры;

  • наследование позволяет легко и многократно использовать эти общие группы
    в других абстракциях.

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

2.1 Определение, характеристика объектов
Объекты — конкретные сущности, которые суще­ствуют во времени и пространстве. Объектэто конкретное представление абстракции. Объект обладает индивиду­альностью, состоянием и поведением. Структура и поведение подобных объектов определены в их общем классе. Термины «экземпляр класса» и «объект» взаимозаменяемы. На рис. 1 приведен пример объекта по имени «Стул», имеющего опре­деленный набор свойств и операций.



Рис.1. Представление объекта с именем Стул


Индивидуальность — это характеристика объекта, которая отличает его от всех других объектов.

Состояние объекта характеризуется перечнем всех свойств объекта и текущими значениями каждого из этих свойств (рис.1). Объекты не существуют изолированно друг от друга. Они подвергаются воздей­ствию или сами воздействуют на другие объекты.

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

Возможны пять видов операций клиента над объектом: модификатор (изменяет состояние объекта); селектор (дает доступ к состоянию, но не изменяет его); итератор (доступ к содержанию объекта по частям, в строгом порядке); конструктор (создает объект и инициализирует его состояние); деструктор (разрушает объект и освобождает занимаемую им память).
Примеры операций приведены в табл.1

Таблица 1. - Разновидности операций

Вид операции

Пример операции

Модификатор

Пополнеть(кг)

Селектор

Какой Вес():integer

Итератор

Показать Ассортимент Товаров(): string

Конструктор

Создать Робот(параметры)

Деструктор

Уничтожить Робот()

В чистых объектно-ориентированных языках программирования операции могут объявляться только как методы — элементы классов, экземплярами которых являют­ся объекты. Гибридные языки (C++, Ada 95) позволяют писать операции как свобод­ные подпрограммы (вне классов). Соответствующие примеры показаны на рис. 2


Иванушка



Методы

Спать()

Есть()

Пить()

Быть Гражданином()
Свободные подпрограммы


Голосовать(имя)


Выражать Мнение(имя)


Рис.2. Методы и свободные подпрограммы

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

Наличие у объекта внутреннего состояния означает, что по­рядок выполнения им операций очень важен. Иначе говоря, объект может представ­ляться как независимый автомат. По аналогии с автоматами можно выделять ак­тивные и пассивные объекты (рис. 4).



Рис. 3. Пространство поведения объекта




активные объекты (самостоятельное поведение)

Пассивные объекты (поведение по заказу)


Рис. 4. Активные и пассивные объекты

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

1.Связи

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

  • объект-клиент вызывает операции объекта-поставщика;

  • один объект перемещает данные к другому объекту.

Можно сказать, что связи являются рельсами между станциями-объектами, по которым ездят «трамвайчики сообщений». Связи между объектами показаны на рис.5 с помощью соединительных линий. Связи представляют возможные пути для передачи сообщений. Сами сообщения показаны стрелками, отмечающими их направления, и помечены именами вызы­ваемых операций.

Как участник связи объект может играть одну из трех ролей:

  • актер — объект, который может воздействовать на другие объекты, но никогда не подвержен воздействию других объектов;

  • сервер — объект, который никогда не воздействует на другие объекты, он толь­ ко используется другими объектами;

  • агент — объект, который может как воздействовать на другие объекты, так и ис­пользоваться ими. Агент создается для выполнения работы от имени актера
    или другого агента.


На рис. 5 Том — это актер, Мери, Колонки — серверы, Музыкальный центр — агент.

Актер




Сервер

Том

т анцевать()

Мери


























Сервер

Муз. центр

з вучать()

Колонки

Агент










Рис.5. Связи между объектами

2.Агрегация

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

Агрегация может обозначать, а может и не обозначать физическое включение час­ти в целое. На рис.6 приведен пример физического включения (композиции) частей (Двигателя, Сидений, Колес) в агрегат Автомобиль. В этом случае говорят, что части включены в агрегат по величине.

На рис.7 приведен пример нефизического включения частей (Студента, Препо­давателя) в агрегат Колледж. Очевидно, что Студент и Преподаватель являются эле­ментами Вуза, но они не входят в него физически. В этом случае говорят, что части включены в агрегат по ссылке.

Целое


Автомобиль

Корпус











Двигатель



Сиденья




Колеса




часть часть часть

Рис.6. Физическое включение частей в агрегат



Рис.7. Нефизическое включение частей в агрегат

Итак, между объектами существуют два вида отношений — связи и агрегация. Ка­кое из них выбрать? При выборе вида отношения должны учитываться следующие факторы:

  • связи обеспечивают низкое сцепление между объектами;

  • агрегация инкапсулирует части как секреты целого.


3. Классы

3.1 Понятие, характеристика
Понятия объекта и класса тесно связаны. Тем не менее, существует важное разли­чие между этими понятиями. Класс — это абстракция существенных характерис­тик объекта. Класс — описание множества объектов, которые разделяют одинаковые свойства, опе­рации, отношения и семантику (смысл). Любой объект — просто экземпляр класса. Как показано на рис. 8, различают

  • внутреннее представление класса (реализа­цию)

  • внешнее представление класса (интерфейс).


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

интерфейсные

Части

Публичная



Защищенная



Приватная

Реализация

Рис. 8. Структура представления класса

Интерфейс может быть разделен на 3 части:

  1. публичную (public), объявления которой доступны всем клиентам;

  2. защищенную (protected), объявления которой доступны только самому классу,его подклассам и друзьям;

  3. приватную (private), объявления которой доступны только самому классу и его
    друзьям.

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

Реализация класса описывает секреты поведения класса. Она включает реализа­ции всех операций, определенных в интерфейсе класса.

3.2 Виды отношений между классами

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

  • Ассоциация (фиксирует структурные отношения — связи между экземплярами классов);

  • Наследование ( обобщение-специализация («is а»-отношение) )

  • Агрегация ( целое-часть («part of»-отношение) )

  • Зависимость (отображает влияние одного класса на другой класс).

Для покрытия основных отношений большинство объектно-ориентированных язы­ков программирования поддерживает следующие отношения: ассоциация; наследование; агрегация; зависимость; конкретизация; метакласс; реализация.

Ассоциацииобеспечивают взаимодействия объектов, принадлежащих разным клас­сам. Они являются клеем, соединяющим воедино все элементы программной сис­темы. Благодаря ассоциациям мы получаем работающую систему. Без ассоциаций система превращается в набор изолированных классов-одиночек.

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

Агрегацияобеспечивает отношения целое-часть, объявляемые для экземпляров классов.

Зависимость часто представляется в виде частной формы — использования, кото­рое фиксирует отношение между клиентом, запрашивающим услугу, и сервером, предоставляющим эту услугу.

Конкретизация выражает другую разновидность отношения обобщение-специали­зация. Применяется в таких языках, как Ada 95, C++, Эйфель.

Отношения метаклассов поддерживаются в языках SmallTalk и CLOS. Мета­класс — это класс классов, понятие, позволяющее обращаться с классами как с объектами.

Реализация определяет отношение, при котором класс-приемник обеспечивает свою собственную реализацию интерфейса другого класса-источника. Иными сло­вами, здесь идет речь о наследовании интерфейса. Семантически реализация — это «скрещивание» отношений зависимости и обобщения-специализации.

1).Ассоциации классов

Ассоциация обозначает семантическое соединение классов.

Пример: в системе обслуживания читателей имеются две ключевые абстракции — Книга и Библиотека. Класс Книга играет роль элемента, хранимого в библиотеке. Класс Библиотека играет роль хранилища для книг:



Рис. 9. Ассоциация

Отношение ассоциации между классами изображено на рис. 9. Очевидно, что ассоциация предполагает двухсторонние отношения:

  • для данного экземпляра Книги выделяется экземпляр Библиотеки, обеспечиваю­щий ее хранение;

  • для данного экземпляра Библиотеки выделяются все хранимые Книги.

Здесь показана ассоциация один-ко-многим. Каждый экземпляр Книги имеет ука­затель на экземпляр Библиотеки. Каждый экземпляр Библиотеки имеет набор указа­телей на несколько экземпляров Книги. Ассоциация обозначает только семантическую связь. Она не указывает направле­ние и точную реализацию отношения. Ассоциация пригодна для анализа пробле­мы, когда нам требуется лишь идентифицировать связи. С помощью создания ас­социаций мы приходим к пониманию участников семантических связей, их ролей, мощности (количества элементов). Ассоциация один-ко-многим, введенная в примере, означает, что для каждого эк­земпляра класса Библиотека есть 0 или более экземпляров класса Книга, а для каж­дого экземпляра класса Книга есть один экземпляр Библиотеки. Эту множествен­ность обозначает мощность ассоциации. Мощность ассоциации бывает одного из трех типов: один-к-одному; один-ко-многим; многие-ко-многим.

Примеры ассоциаций с различными типами мощности :

  • у европейской жены один муж, а у европейского мужа одна жена;

  • у восточной жены один муж, а у восточного мужа сколько угодно жен;

  • у заказа один клиент, а у клиента сколько угодно заказов;

  • человек может посещать сколько угодно зданий, а в здании может находиться сколько угодно людей.

2). Наследование (Обобщение , специализация)

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

3). Агрегация (Целое – часть )

Отношения агрегации между классами аналогичны отношениям агрегации между объектами.



По ссылке По величине (композиция)

Рис.10 Агрегация классов

4).Зависимость

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

Зависимый элемент --------------- > Независимый элемент

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

Конкретизация Г. Буч определяет конкретизацию как процесс наполнения шаблона (родового или параметризованного класса). Целью является получение класса, от которого воз­можно создание экземпляров. Родовой класс служит заготовкой, шаблоном, параметры которого могут напол­няться (настраиваться) другими классами, типами, объектами, операциями. Он может быть родоначальником большого количества обычных (конкретных) клас­сов. Возможности настройки родового класса представляются списком формаль­ных родовых параметров. Эти параметры в процессе настройки должны заменять­ся фактическими родовыми параметрами. Процесс настройки родового класса называют конкретизацией.
4. Метрики объектно-ориентированных программных систем
Метрический аппарат объектно-ориентированных систем развивает идеи классического оценивания сложных программных систем, основанного на метриках сложности, связности и сцепления. Вместе с тем он учитывает специфические особенности объектно-ориентированных решений. Рассматриваются наиболее известные объектно-ориентированные метрики, а также описывается методика их применения.
4.1 Метрические особенности объектно-ориентированных систем
Объектно-ориентированные метрики вводятся с целью:

  • улучшить понимание качества продукта;

  • оценить эффективность процесса конструирования;

  • улучшить качество работы на этапе проектирования.

Все эти цели важны, но для программного инженера главная цель- повышение качества продукта. Возникает вопрос - как измерить качество объектно-ориентированных системы? Для любого инженерного продукта метрики должны ориентироваться на его уникальные характеристики. Например, для электропоезда вряд ли полезна метрика «расход угля на километр пробега». С точки зрения метрики выделяют пять характеристик объектно-ориентированных систем:

    1. локализацию

    2. инкапсуляцию,

    3. информационную закрытость

    4. наследование

    5. способы абстрагирования объектов.

Эти характеристики оказывают максимальное влияние на О-О метрики.

Локализация

Локализация фиксирует способ группировки информации в программе.

  • В классических методах используется группировка вокруг функций; функции в них реализуется как процедурные модули.

  • В методах, управляемых данными, информация группируется вокруг структур данных.

  • В О-О среде информация группируются внутри классов или объектов (инкапсуляцией как данных, так и процессов).

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

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

Инкапсуляция

Инкапсуляция - упаковка (связывание) совокупность элементов. Для классических ПС примером низкоуровневой инкапсуляции является записи и массивы. Механизмом инкапсуляции среднего уровня являются подпрограммы (процедуры, функции).

В О-О системах инкапсулируются обязанности класса, представляемые его свойствами (а для агрегатов и свойствами др. классов), операциями и состояниями.

Для метрик учет инкапсуляции приводит к смещению фокуса измерений с одного модуля на группу свойств и обрабатывающих модулей (операций). Кроме того, инкапсуляция переводит измерения на более высокий уровень абстракции (пример-метрика «количество операций на класс»).Напротив, классические метрики ориентированы на низкий уровень-количество булевых условий(цикломатическая сложность) и кол-во строк программ.

Информационная закрытость

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

Наследрвание

Наследование - механизм, обеспечивающий тиражирование обязанностей одного класса в другие классы. Наследование распространяется через все уровни иерархии классов. Стандартные ПС не поддерживают эту характеристику. Наследование - основная характеристика О-О метрики (количество детей-потомков класса, количество родителей, высота класса в иерархии наследования).

Абстракция

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

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

4. 2.Эволюция мер связи для объектно-ориентированных систем
Ранее в разделах «Связности модуля» и «Сцепление модулей» было показано, что классической мерой сложности внутренних связей модуля является связность, а классической мерой сложности внешних связей - сцепление. Рассмотрим развитие этих мер применительно к объектно-ориентированным системам.

4. 2.1. Связность объектов. В классическом методе Л.Констентайна и Э.Йордана определены 7 типов связности.

  1. Связность по совпадению. В модуле отсутствует явно выраженные внутренние связи.

  2. Логическая связность. Части модуля объединены по принципу функционального подобия.

  3. Временная связность. Части модуля не связанны, но необходимы в один и тот же период работы системы.

  4. Процедурная связность. Части модуля связанны порядком выполняемых ими действий, реализующий некоторый сценарий поведения.

  5. Коммуникационная связность. Части модуля связанны по данным (работают с одной и той же структурой данных).

  6. Информационная (последовательная) связность. Выходные данные одной части используются как входные данные в другой части модуля.

  7. Функциональная связность. Части модуля вместе реализуют одну функцию.

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

Следовательно, 8-й тип связности можно определить так:

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

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

4. 2.2 Сцепление объектов. В классическом методе Л. Констентайна и Э. Йордана определены 6 типов сцепления, которые ориентированны на процедурное проектирование.Принципиальное преимущество объектно-ориентированного проектирования в том , что природа объектов приводит к созданию слабо сцепленных систем. Фундаментальное свойство объектно-ориентированного проектирования заключается в скрытости содержания объекта. Степень автономности объекта достаточно высока. Любой объект может быть замещен другим объектом с таким же интерфейсом.

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

Таким образом, сами по себе объектно-ориентированные механизмы не гарантируют минимального сцепления. Конечно, классы - мощное средство абстракции данных. Их введение уменьшило поток данных между модулями и, следовательно, снизило общее сцепление внутри системы. Однако количество типов зависимостей между модулями выросло. Появились отношения наследования, делегирования, реализации и т.д. Более разнообразным стал состав модулей в системе (классы, объекты, свободные функции процедуры, пакеты). Отсюда вывод: необходимость измерения и регулирования сцепления в объектно-ориентированных системах обострилась.
4.3. Набор метрик Чидамбера И Кемерера
В 1994 году С. Чидамбер и Л. Кемерер предложили 6 проектных метрик, ориентированных на классы. Класс - фундаментальный элемент О-О системы. Поэтому измерения и метрики для отдельного класса, иерархии классов бесценны для программного инженера, который должен оценить качество проекта.

Набор Чидамбера – Кемерера наиболее часто цитируется в программной индустрии и научных исследованиях. Рассмотрим каждую из метрик набора.

Метрика 1: ВЗВЕШЕННЫЕ МЕТОДЫ НА КЛАСС WMC (Weughted Methods Per Class)

Допустим, что в классе С определенны n методов со сложностью с1,с2,…сn.Для оценки сложности может быть выбрана любая метрика сложности (например, цикломатическая сложность). Главное - нормализовать эту метрику так, чтобы номинальная сложность для метода принимала значение 1. В этом случае

n

WMC=∑Ci.

i=1

Количество методов и их сложность являются индикатором затрат на реализацию и тестирование классов. Кроме того, чем больше методов, тем сложнее дерево наследования(все подклассы наследуют методы их родителей).С ростом количества методов в классе его применение становится все более специфическим, тем самым ограничивается возможность многократного использования. По этим причинам метрика WMC должна иметь разумно низкое значение. Очень часто применяют упрощенную версию метрики. При этом полагают Ci=1, и тогда WMC-количество методов в классе.

Оказывается, что подсчитывать количество методов в классе достаточно сложно.

Возможно 2 противоположных варианта учета.

  1. Подсчитываются только методы текущего класса. Унаследованные методы игнорируются. Обоснование - унаследованные методы уже подсчитаны в тех классах, где они определялись.

  2. Подсчитываются методы, определенные в текущем классе, и все унаследованные методы. Этот подход подчеркивает важность пространства состояний в понимании класса.

На практике приемлем любой из описанных вариантов. Главное - не менять вариант учета от проекта к проекту. Только в этом случае обеспечивается корректный сбор метрических данных.

Метрика WMC дает относительную меру сложности класса. Если считать, что все методы имеют одинаковую сложность, то это будет просто количество методов в классе. Существуют рекомендации по сложности методов. Например, М. Лоренц считает, средняя длина метода должна ограничиваться 8 строками для Smalltalk и 24 строками для С++. Вообще, класс, имеющий максимальное количество методов среди классов одного с ним уровня, является наиболее сложным; скорее всего, он специфичен для данного приложения и содержит наибольшее количество ошибок.

Метрика 2: ВЫСОТА ДЕРЕВА НАСЛЕДОВАНИЯ DIT(Depth of inheritance Tree).

DIT определяется как длина пути от листа до корня дерева наследования классов. Для показанной на рис.1 иерархии классов метрика DIT равна 3.



Рис.1 Дерево наследования классов.

Соответственно, для отдельного класса DIT , это длина максимального пути от данного класса до корневого класса в иерархии классов.

ПО мере роста DIT вероятно, что классы нижнего уровня будут наследовать много методов. Это приводит к трудностям в предсказании поведения класса. Вместе с тем, большое значение DIT подразумевает , что многие методы могут использоваться многократно.

Метрика 3: КОЛИЧЕСТВО ДЕТЕЙ NOC( NUMBEROFCHILDREN)

Подклассы которые непосредственно подчинены суперклассу, называются его детьми. Значение NOC равно количеству детей, то есть количеству непосредственных наследников класса в иерархии классов. На рис.1 класс С2 имеет двух детей-подклассы С21 и С22. С увеличением NOC возрастает многократность использования, так как наследование-это форма повторного использования. Однако при возрастании NOC ослабляется абстракция родительского класса. Это означает, что в действительности некоторые из детей уже не являются членами родительского класса и могут быть неправильно использованы. Кроме того, количество детей характеризует потенциальное влияние класса на проект. По мере роста NOC возрастает количество тестов, необходимых для проверки каждого ребенка.

Метрики DIT и NOC - количественные характеристики формы и размера структуры классов. Хорошо структурированная О-О система чаще бывает организованна как лес классов, чем как сверхвысокое дерево. По мнению Г. Буча, следует строить сбалансированные по высоте и ширине структуры наследования: обычно не выше, чем 7+-2 уровня, и не шире, чем 7+-2 ветви.
Метрика 4: СЦЕПЛЕНИЕ МЕЖДУ КЛАССАМИ ОБЪЕКТОВ СВО (Cjupling between object classes)

CВО - это количество сотрудников, предусмотренных для класса, то есть количество классов, с которыми он соединен. Соединение означает, что методы данного класса используют методы или экземплярные переменные другого класса.

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

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

Метрика 5: ОТКЛИК ДЛЯ КЛАССА RFC (Response For a Class)

Введем вспомогательное определение. Множество отклика класса RS-это множество методов, которые могут выполнять в ответ на прибытие сообщение в объект этого класса. Формула для определения RS имеет вид:

RS={M}Uall-i{R},

где{Ri}-множество методов, вызываемых методом i, {M}-множество всех методов в классе. Метрика RFC равна количеству методов во множестве отклика, то есть равна мощности этого множества:

RFC=card{RS}.

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

С ростом RFC увеличивается сложность класса. Наихудшая величина отклика может использоваться при определении времени тестирования.

Метрика 6: НЕДОСТАТОК СВЯЗНОСТИ В МЕТОДАХ LCOM(Lack of Cohesion in Methods)

Каждый метод внутри класса обращается к одному или нескольким свойствам (экземплярным переменным).Метрика LCOM показывает, насколько методы не связаны друг с другом через свойства .Введём обозначения:

  • НЕ СВЯЗАНЫ- количество пар методов без общих экземплярных переменных;

  • СВЯЗАНЫ- количество пар методов с общими экземплярными переменными.

  • Ij-набор экземплярных переменных, используемых методом Mj.

Очевидно, что НЕ СВЯЗАНЫ=card{Iy|Ii∩Ij=0},

СВЯЗАНЫ=card{Iy|Ii∩Ij≠0}.

Тогда формула для вычисления недостатка связности методах примет вид

LCOM={ НЕ СВЯЗАНЫ - СВЯЗАНЫ, если (НЕ СВЯЗАНЫ>СВЯЗАНЫ)

0 в противном случае.

Можно определить метрику по-другому: LCOM - это количество пар методов, не связанных по свойствам класса, минус количество пар методов, имеющих такую связь.

Рассмотрим примеры применения метрики LCOM.

Пример 1:В классе имеются методы:М1,М2,М3,М4.Каждый метод работает со своим набором экземплярных переменных:

I1={a,b}; I2={a,c}; I3={x,y}; I4={m,n}.

В этом случае

НЕ СВЯЗАНЫ=card(I13, I14,I23,I24,I34,)=5; СВЯЗАНЫ=card(I12)=1.

LCOM=5-1=4

Пример 2:Вклассе используются методы:М1,М2,М3.

Для каждого метода задан свой набор экземплярных переменных:

I1={a,b}; I2={a,c}; I3={x,y},

НЕ СВЯЗАНЫ=card(I13,I23)=2; СВЯЗАНЫ=card(I12)=1

LCOM=2-1=1

Cвязность методов внутри класса должна быть высокой, так как это содействует инкапсуляции. Если LCOM имеет высокое значение, то методы слабо связаны друг с другом через свойства. Это увеличивает сложность, в связи с чем возрастает вероятность ошибок при проектировании. Высокие значения LCOM означают, что класс. вероятно, надо спроектировать лучше (разбиение на 2 или более отдельных класса).Любое вычисление LCOM помогает определить недостатки в проектировании классов, так как эта метрика характеризует качество упаковки данных и методов в оболочку класса. Вывод: связность в классе желательно сохранять высокой, то есть стоит добиваться низкого значения LCOM.

Поскольку основу логического представления ПО образует структура классов, для оценки ее качества удобно использовать метрики Чидамбера-Кемерера.

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


  1. В чем отличие алгоритмической декомпозиции от объектно-ориентированной декомпозиции сложной системы?

  2. Перечислите основные принципы ООП.

  3. В чем заключается объектно-ориентированное абстрагирование?

  4. В чем заключается объектно-ориентированная инкапсуляция?

  5. Каковы средства обеспечения объектно-ориентированной модульности?

  6. Какова особенность объектно-ориентированной иерархии? Какие разновидности иерархии вы знаете?

  7. Дайте общую характеристику объекта. Что такое протокол объекта?

  8. Чем отличается объект от класса?

  9. Охарактеризуйте связи между объектами. Охарактеризуйте роли объекта в связях.

  10. Какие виды агрегации между объектами вы можете назвать?

  11. Дайте общую характеристику класса.

  12. Поясните внутреннее и внешнее представление класса.

  13. Какие вы знаете секции в интерфейсной части класса?

  14. Какие виды отношений между классами вы знаете?

  15. Поясните ассоциацию между классами.

  16. Поясните наследование классов.

  17. Поясните понятие полиморфизма.

  18. Поясните отношение агрегации между классами.

  19. Поясните отношение зависимости между классами.

  20. Какие факторы объектно-ориентированных систем влияют на метрики для их оценки?

  21. Какое влияние оказывает наследование на связность классов?

  22. Какие метрики входят в набор метрик Чидамбера и Кемерера? Какие задачи они решают?

  23. Какая метрика Чидамбера и Кемерера оценивает связность класса? Поясните ее смысл.

  24. Какая метрика Чидамбера и Кемерера оценивает сцепление класса? Поясните ее смысл.

  25. Как можно подсчитать количество методов в классе?

1   ...   7   8   9   10   11   12   13   14   ...   30


написать администратору сайта