5.3. Сцепление модулей, уровни сцепления. Модели управления модульной системой

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

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

Сцепление модуля тем более сильно, чем больше ему для собственного функционирования требуется знаний о других модулях. Для оценки сцепления вводится специальная мера его оценки – степень (уровень) сцепления. В разных источниках приводится различная оценка не только степени сцепления, но и его характера. Здесь рассматривается вариант, приведённый [Орлов-6].

Сцепление	Степень (уровень) сцепления
По данным	1
По образцу	3
По управлению	4
По внешним ссылкам	5
По общей области	7
По содержанию	9

Модули сцеплены по данным, если единственный вид информации, передаваемый от модуля к модулю при взаимодействии, это элементарные данные, то есть вызываемому модулю известны только имя вызываемого модуля, параметры и их типы.

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

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

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

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

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

Модели управления модульной системой.

6. Программирование

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

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

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

В одной программе может быть несколько объектов, имеющих одинаковую структуру, например, окружностей. Тогда они составляют класс. Класс рассматривается как тип данных, к которому принадлежит объект, играющий в программе роль переменной.

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

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

Наследование позволяет одним объектам приобретать атрибуты и свойства других объектов. Наследование позволяет строить иерархию объектов, переходя от более общего к частному, уточняя и конкретизируя объект.

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

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

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

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