Рассмотрим вновь пример модуля, обеспечивающего реализацию алгоритма поиска в таблице. Некоторый модуль-клиент, который может быть частью системы, реализующей работу с электронными таблицами, обращается к нашему модулю для поиска в таблице определенного элемента. Предположим далее, что наш алгоритм поиска основан на реализации дерева двоичного поиска, но это его свойство является скрытым - и не отражено в интерфейсе. Автор модуля поиска в таблице может сам решать, сообщать ли автору программы электронных таблиц то, как реализован алгоритм поиска. Это решение относится к управлению проектом или, возможно (в случае серийно выпускаемого программного обеспечения), является решением на уровне маркетинга; так или иначе, это не связано с вопросами скрытия информации.
Скрытие информации означает нечто другое: даже если автор программы электронных таблиц знает о том, что поиск основан на дереве двоичного поиска, ему не следует составлять такой модуль-клиент, который правильно функционирует лишь при этой реализации поиска - и перестанет работать при замене алгоритма поиска на какой-либо другой, например, на поиск с хешированием.
Одной из причин вышеупомянутого недопонимания является сам термин 'скрытие информации' ('information hiding'), который наводит на мысль о защите физического характера. В этом смысле предпочтительным, по-видимому, мог бы явиться термин 'инкапсуляция' ('encapsulation'), иногда используемый в качестве синонима скрытию информации, однако в нашем обсуждении будет по-прежнему использоваться общий термин 'скрытие информации'.
Из этого обсуждения следует, что ключом к скрытию информации являются не решения по организации доступа к исходному тексту модуля в рамках управления проектом или маркетинговой политики, а строгие языковые правила, определяющие, какие права на доступ к модулю следуют из свойств его источника. В следующей лекции показано, что первые шаги в этом направлении реализованы в таких 'языках с инкапсуляцией' как Ada и Modula-2. Объектно-ориентированная технология программирования приведет к более полному решению проблемы.3.5)
Пять принципов
Из предыдущих правил и, косвенным образом, из критериев следуют пять принципов конструирования ПО:
[x]. Принцип Лингвистических Модульных Единиц (Linguistic Modular Units).
[x]. Принцип Самодокументирования (Self-Documentation).
[x]. Принцип Унифицированного Доступа (Uniform Access).
[x]. Принцип Открыт-Закрыт (Open-Closed).
[x]. Принцип Единственного выбора (Single Choice).
Лингвистические Модульные Единицы
Принцип Лингвистических Модульных Единиц утверждает, что формализм описания ПО на различных уровнях (спецификации, проектирования, реализации) должен поддерживать модульность:
Принцип Лингвистических Модульных Единиц
Модули должны соответствовать синтаксическим единицам используемого языка.
Упомянутым выше языком может быть язык программирования, язык проектирования, язык оформления технических требований и т. д. В случае языка программирования модули должны независимо компилироваться.
Этот принцип на любом уровне (анализа, проектирования, реализации) не допускает объединения метода, исходящего из концепции модульности, и языка, не содержащего соответствующих модульных конструкций. В самом деле, нередко встречаются фирмы, которые на этапе проектирования применяют некие методологические подходы, например используя модули языка Ada, но затем реализуют свои замыслы в таком языке программирования, как Pascal или C, не поддерживающим эти подходы. Такой подход нарушает некоторые из критериев модульности:
[x]. Непрерывность: если границы модуля в окончательном тексте программы не соответствуют логической декомпозиции спецификации или проекта, то при сопровождении системы и ее эволюции будет затруднительно или даже невозможно поддерживать совместимость различных уровней. Изменение спецификации можно считать небольшим, если оно затрагивает спецификацию лишь небольшого числа модулей. Для обеспечения 'непрерывности' должно иметь место прямое соответствие между спецификацией, проектом и модулями реализации.
[x]. Прямое отображение: необходимо поддерживать явное соответствие между структурой модели и структурой решения. Для этого необходимо иметь явную синтаксическую идентификацию концептуальных единиц модели и решения, отражающее разбиение, предусмотренное методом разработки.
[x]. Декомпозиция: для разбиения системы на отдельные задачи необходимо быть уверенным, что результатом решения каждой из задач явится четко ограниченная синтаксическая единица; на этапе реализации эти программные компоненты должны быть раздельно компилируемыми.
[x]. Композиция: что же, кроме модулей с однозначно определенными синтаксическими границами, можно объединять между собой?
[x]. Защищенность: лишь в случае, если модули синтаксически разграничены, можно надеяться на возможность контроля области действия ошибок.
Самодокументирование
Подобно правилу Скрытия Информации, принцип Самодокументирования определяет, как следует документировать модули:
Принцип Самодокументирования
Разработчик модуля должен стремиться к тому, чтобы вся информация о модуле содержалась в самом модуле.
Обычно реализации этого принципа мешает общепринятое положение, согласно которому информацию о модуле помещают в отдельные проектные документы.
| Документация, рассматриваемая здесь, является внутренней документацией о компонентах ПО. Пользовательская документация о выпущенном программном продукте может быть отдельным документом, реализованном в виде печатного текста, либо размещенном на CD-ROM или страницах в Интернете. Как отмечалось при обсуждении вопроса о качестве программного обеспечения, следствием общего принципа самодокументирования является наблюдаемая сейчас тенденция к большему использованию средств диалоговой оперативной подсказки. (См.'О документировании' лекция 1) |
