Блинков Ю.А., Месянжин В.В. (сост) Основы объектно-ориетнированного программирования. Саратовский Государственный университет, механико-математический факультет

Подождите немного. Документ загружается.

следует использовать объектный инструментарий (наследование, обертывание), удовлетво-

ряющий критерию Открыт-Закрыт, допускающий расширяемость и повторное использование

если компонент лишь частично удовлетворяет потребностям, его следует переделать

повторно использовать следует лишь тот компонент, который полностью соответствует по-

требностям

8. Перегрузка может быть?

экстраординарной

динамической

многократной

статической

9. Роль универсальности в повторном использовании в том, что?

позволяет справиться с проблемой изменчивости типов

взаимозависимости операций

позволяет справиться с проблемой независимости представлений

позволяет справиться с проблемой изменчивости реализаций

10. Проблема изменчивости реализаций для классов поведения состоит в том, что?

класс поведения может не фиксировать спецификацию, так что реализация зависит от даль-

нейшего уточнения спецификации

класс поведения может не фиксировать алгоритм, так что реализация зависит от дальнейшего

выбора алгоритма

реализация с течением времени изменяется

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

дальнейшего выбора структуры данных

11. Проблемы повторного использования связаны с?

непрерывностью представлений

вариацией представлений

изменчивостью типов

взаимозависимостью операций

12. Форматом распространения ПИК, допускающим расширения, является

двоичный код исполняемого модуля

исходный текст на языке программирования

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

код на промежуточном языке

13. Отметьте истинные высказывания?

решение проблемы "повторно использовать или переделать"должно позволять сохранять одни

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

универсальность решает все проблемы повторного использования

образцы, описанные в литературе, частично решают проблему повторного использования

перегрузка метода является синтаксическим средством; она не решает важных проблем по-

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

14. Отметьте истинные высказывания?

знаки операций могут быть перегруженными

синдромы NIH и HIN препятствуют повторному использованию

пакеты можно рассматривать как абстрактные модули

метод нисходящего проектирования обеспечивает декомпозицию системы на подпрограммы

15. Отметьте истинные высказывания?

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

на создание ПИК требуются дополнительные затраты

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

динамическое связывание является формой

Набрано баллов

Модуль 2

5 К объектной технологии

5.1 Функциональная декомпозиция

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

в качестве основы архитектуры программных систем.

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

Ключевой проблемой при ответе на вопрос: “вокруг чего следует структурировать системы: вокруг

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

непрерывностью в предшествующих лекциях. Как вы помните, метод проектирования удовлетворяет

этому критерию, если он приводит к устойчивой архитектуре, обеспечивающей объем изменений в

проекте, соразмерный объему изменений в спецификации.

Обеспечение непрерывности - это главная забота при рассмотрении реального жизненного цикла

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

и эволюцию системы на протяжении долгого времени. Большинство систем подвергаются много-

численным изменениям после их первоначальной поставки. Поэтому всякая модель разработки ПО,

которая рассматривает только период, предшествующий этой поставке, и игнорирующая последую-

щую эру изменений и пересмотров, весьма далека от реальной жизни.

Чтобы оценить качество архитектуры (и породившего ее метода), нужно понять не только то,

насколько просто было изначально получить эту архитектуру, не менее важно выяснить, насколько

легко ее можно изменить.

Традиционным ответом на этот вопрос была функциональная декомпозиция “сверху вниз”, кратко

определенная в одной из предыдущих лекций. Насколько хорошо разработка сверху вниз отвечает

требованиям модульности?

Проектирование сверху вниз

Там был также весьма изобретательный архитектор, придумавший новый способ постройки домов.

Постройка должна была начинаться с крыши и кончаться фундаментом. Он оправдывал мне этот

способ ссылкой на приемы двух мудрых насекомых - пчелы и паука.

Джонатан Свифт, “Путешествия Гулливера”

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

начинается с самого общего утверждения об ее абстрактной функции, такого как

[C0]

"Оттранслировать СИ-программу в машинный код"

[P0]

’Обработать команду пользователя"

и продолжается путем последовательных шагов уточнения. На каждом шаге уровень абстракции

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

одной или нескольких более простых операций. Например, следующий шаг в первом примере (транс-

лятор с СИ) может привести к декомпозиции

[C1]

"Прочесть программу и породить последовательность лексем"

"Разобрать последовательность лексем и построить

абстрактное синтаксическое дерево"

"Снабдить дерево семантической информацией"

"Сгенерировать по полученному дереву код"

или, используя другую структуру (и сделав упрощающее предположение, что СИ-программа - это

последовательность определений функций):

[C’1]

from

"Инициализировать структуры данных"

until

"Определения всех функций обработаны"

loop

"Прочесть определение следующей функции"

"Сгенерировать частичный код"

end

"Заполнить перекрестные ссылки"

В любом случае разработчик должен на каждом шаге проверять оставшиеся не полностью уточ-

ненными элементы (такие как “Читать программу...“ и “Определения всех функций обработаны”) и

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

низком уровне абстракции, допускающем непосредственную реализацию.

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

элементы декомпозиции, ветви показывают отношение “B есть уточнение A”.

Рис. 5.1: Разработка сверху вниз: структура дерева

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

дисциплину мышления, поддается эффективному изучению, поощряет систематическое проектиро-

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

обычно на начальной стадии разработки систем.

Нисходящий подход может быть весьма полезен при разработке отдельных алгоритмов. Одна-

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

проектировании целых систем:

• Сомнительной является сама идея охарактеризовать всю систему посредством только одной

функции.

• Используя в качестве основы декомпозиции системы на модули свойства, которые склонны

подвергаться наибольшим изменениям, этот метод не способен учесть эволюционную природу

Рис. 5.2: Структура простой системы расчета зарплаты

программных систем.

Не только одна главная функция

При эволюции системы то, что вначале воспринималось как ее главная функция, с течением времени

может стать менее важным.

Рассмотрим типичную систему расчета зарплаты. При формулировке начальных требований заказ-

чик мог представить лишь то, что следует из ее названия: систему для генерации чеков на зарплату

по соответствующим данным. Его представление системы, явное или неявное, могло оказаться вер-

сией следующей схемы, возможно, чуть более амбициозное:

Эта система получает некоторые входные данные (такие как часы работы служащего и некоторую

информацию о нем) и производит некоторые выходные данные (чеки и т. п.). Это простая функ-

циональная спецификация, в строгом смысле слова “функциональный”. Она определяет программу

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

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

задание состоит в вычислении одной функции - “вершины” конструируемой системы.

Предположим, однако, что разработка нашей платежной системы благополучно завершена и про-

грамма выполняет всю необходимую работу. Скорее всего, на этом разработка не прекратится.

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

других вещах, которые они могут делать. Как разработчику системы вам было сказано вначале, что

все, что вы должны сделать - это сгенерировать чеки и пару вспомогательных выходных данных. Но

затем просьбы о расширениях начинают попадать на ваш стол одна за другой: “Может ли программа

собирать некоторую дополнительную статистику?“ “Я говорил вам, что в следующем квартале мы

собираемся начать платить некоторым служащим ежемесячно, а некоторым - дважды в месяц, не так

ли?“ “И, между прочим, мне нужен ежемесячный суммарный отчет для администрации и еще один

ежеквартальный для акционеров”. “Бухгалтерам требуется отдельный отчет для начисления нало-

гов”. “Кстати, правильно ли вы храните информацию о зарплате? Очень хотелось бы предоставить

персоналу интерактивный доступ к ней. Не понимаю, почему трудно добавить такую функцию?“

Процесс изменений происходит непрерывно. Новая система все еще является во многих отно-

шениях “той же”, что и старая: все еще платежной системой, программой для ядерной физики,

компилятором. Но исходная “главная функция”, которая вначале выглядела самой важной, часто

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

Если при анализе и проектировании используется метод декомпозиции, основанный на функции,

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

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

может разрушить всю структуру системы. Поэтому очень важно найти в качестве критерия деком-

позиции свойства менее изменчивые, чем главная функция системы.

Интерфейсы и проектирование ПО

Архитектура системы должна основываться на содержании, а не на форме. Но проектирование

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