Декомпозиция

(decomposabilit

y)

Композиция (composability)

Понятность

(understandabili

ty)

Непрерывность

(continuity)

Защищенность

(protection)

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

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

•Метод удовлетворяет критерию Модульной Понятности, если он помогает получить такую программу, читая которую можно понять содержание каждого модуля, не зная текста остальных, или, в худшем случае, ознакомившись лишь с некоторыми из них

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

•Метод удовлетворяет критерию Модульной Защищенности, если он приводит к архитектуре системы, в которой аварийная ситуация, возникшая во время выполнения модуля, ограничится только этим модулем, или, в худшем случае, распространится лишь на несколько соседних модулей

Требовани

я

модульно

сти

Прямое отображение (Direct Mapping)

Минимум интерфейсов (Few Interfaces)

Слабая связность интерфейсов (Small interfaces - weak coupling)

Явные интерфейсы (Explicit Interfaces)

Скрытие

информации

(инкапсуляция) (Information Hiding)

•Модульная структура, создаваемая в процессе конструирования ПО, должна оставаться совместимой с модульной структурой, создаваемой в процессе моделирования проблемной области

•Каждый модуль должен поддерживать связь с возможно меньшим числом других модулей

•Если два модуля общаются между собой, то они должны обмениваться как можно меньшим объемом информации

•Всякое общение двух модулей A и B между собой должно быть очевидным и отражаться в тексте A и/или B

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

Правила

модульно

сти

Принцип

Лингвистических Модульных Единиц

(Linguistic Modular

Units)

Принцип

Самодокументирован

ия (Self-Documentation)

Принцип

Унифицированного

Доступа (Uniform Access)

Принцип Открыт- Закрыт

(Open-Closed)

Принцип

Единственного

выбора (Single Choice)

•Модули должны соответствовать синтаксическим единицам используемого языка

•Разработчик модуля должен стремиться к тому, чтобы вся информация о модуле содержалась в самом модуле

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

•Модули должны иметь возможность быть как открытыми, так и закрытыми

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

Принципы

модульно

сти

Повторное использование персонала

Повторное использование проектов и спецификаций

Образцы проектов (design patterns)

Повторное использование исходного текста

Повторное использование абстрактных модулей

Подходы к повторному использован ию

Изменчивость Типов (Type Variation)

Группирование Подпрограмм (Routine Grouping)

Изменчивость Реализаций (Implementation Variation)

Независимость Представлений (Representation Independence)

Требования к модульным структурам, готовым к повторному использован ию

Влияние ОО- метода на факторы качества (1/2)

•Совместимость:

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

•Переносимость:

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

Влияние ОО- метода на факторы качества (2/2)

•Простота использования:

вклад ОО-инструментов в современные интерактивные системы, и особенно их пользовательские интерфейсы, так хорошо известен, что иногда он затмевает другие аспекты.

•Эффективность:

повторное использование компонентов профессионального качества часто может значительно улучшить производительность.

•Своевременность, экономичность и функциональность:

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

•Целью программной инженерии является нахождение путей построения ПО высокого качества.

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

•Внешние факторы, понятные пользователям и клиентам, следует отличать от внутренних факторов, понятных проектировщикам и конструкторам.

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

Ключевые концепции (1/2)

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

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

Ключевые концепции (2/2)