Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++, страница 7

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

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

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

Метод был непосредственно основан на топологии традиционных языковвысокого уровня типа FORTRAN или COBOL. В этих языках основной базовой единицейявляется подпрограмма, и программа в целом принимает форму дерева, в котором одниподпрограммы в процессе работы вызывают другие подпрограммы. Структурное проектированиеиспользует именно такой подход: алгоритмическая декомпозиция применяется для разбиениябольшой задачи на более мелкие.Тогда же стали появляться компьютеры еще больших, поистине гигантских возможностей. Значение структурного подхода осталось прежним, но как замечает Стейн,«оказалось, что структурный подход не работает, если объем программы превышаетприблизительно 100 000 строк» [19]. В последнее время появились десятки методов, вбольшинстве которых устранены очевидные недостатки структурного проектирования.

Наиболееудачные методы были разработаны Петерсом [20], Йеном и Цаи [21], а также фирмой TeledyneBrown Engineering [22]. Большинство этих методов представляют собой вариации на одни и те жетемы. Саммервилль предлагает разделить их на три основные группы [23]:• метод структурного проектирования сверху вниз;• метод потоков данных;• объектно-ориентированное проектирование.Примеры структурного проектирования приведены в работах Иордана и Константина [24],Майерса [25] и Пейдж-Джонса [26]. Основы его изложены в работах Вирта [27, 28], Даля,Дейкстры и Хоара [29]; интересный вариант структурного подхода можно найти в работе Милса,Лингера и Хевнера [30].

В каждом из этих подходов присутствует алгоритмическаядекомпозиция. Следует отметить, что большинство существующих программ написано, повидимому, в соответствии с одним из этих методов. Тем не менее структурный подход непозволяет выделить абстракции и обеспечить ограничение доступа к данным; он также непредоставляет достаточных средств для организации параллелизма. Структурный метод не можетобеспечить создание предельно сложных систем, и он, как правило, неэффективен в объектных иобъектно-ориентированных языках программирования.Метод потоков данных лучше всего описан в ранней работе Джексона [31, 32], а такжеВарниера и Орра [33].

В этом методе программная система рассматривается как преобразовательвходных потоков в выходные. Метод потоков данных, как и структурный метод, с успехомприменялся при решении ряда сложных задач, в частности, в системах информационногообеспечения, где существуют прямые связи между входными и выходными потоками системы игде не требуется уделять особого внимания быстродействию.Объектно-ориентированное проектирование (object-oriented design, OOD) — это подход,основы которого изложены в данной книге. В основе OOD лежит представление о том, чтопрограммную систему необходимо проектировать как совокупность взаимодействующих друг сдругом объектов, рассматривая каждый объект как экземпляр определенного класса, причемклассы образуют иерархию.

Объектно-ориентированный подход отражает топологию новейшихязыков высокого уровня, таких как Smalltalk, Object Pascal, C++, CLOS и Ada.Роль иерархииДругим способом, расширяющим информационные единицы, является организациявнутри системы иерархий классов и объектов. Объектная структура важна, так как онаиллюстрирует схему взаимодействия объектов друг с другом, которое осуществляется с помощьюмеханизмов взаимодействия. Структура классов не менее важна: она определяет общностьструктур и поведения внутри системы. Зачем, например, изучать фотосинтез каждой клеткиотдельного листа растения, когда достаточно изучить одну такую клетку, поскольку мы ожидаем,что все остальные ведут себя подобным же образом.

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

Однако после их определения, структура сложной системы и, в своюочередь, наше понимание ее сразу во многом проясняются. В главе 3 детально рассматриваетсяприрода иерархий классов и объектов, а в главе 4 описываются приемы распознавания этихструктур.1.4. О проектировании сложных системИнженерное дело как наука и искусствоНа практике любая инженерная дисциплина, будь то строительство, механика, химия,электроника или программирование, содержит в себе элементы и науки, и искусства. Петроскикрасноречиво утверждает: «Разработка новых структур предполагает и полет фантазии, и синтезопыта и знаний: все то, что необходимо художнику для реализации своего замысла на холсте илибумаге. После того, как этот замысел созрел в голове инженера-художника, он обязательнодолжен быть проанализирован с точки зрения применимости данного научного методаинженером-ученым со всей тщательностью, присущей настоящему ученому» [38].

Аналогично,Дейкстра отмечает, что «Программная постановка задачи является упражнением в примененииабстракции и требует способностей как формального математика, так и компетентного инженера»[39].Когда разрабатывается совершенно новая система, роль инженера как художникавыдвигается на первый план. Это происходит постоянно при проектировании программ. А темболее при работе с системами, обладающими обратной связью, и особенно в случае системуправления и контроля, когда нам приходится писать программное обеспечение, требования ккоторому нестандартны, и к тому же для специально сконструированного процессора.

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

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

В контексте инженерного проектирования Мостовопределил цель проектирования как создание системы, которая• «удовлетворяет заданным (возможно, неформальным) функциональнымспецификациям;•согласована с ограничениями, накладываемыми оборудованием;•удовлетворяет явным и неявным требованиям по эксплуатационным качествам иресурсопотреблению;•удовлетворяет явным и неявным критериям дизайна продукта;•удовлетворяет требованиям к самому процессу разработки, таким, например, какпродолжительность и стоимость, а также привлечение дополнительныхинструментальных средств» [40].По предположению Страуструпа: «Цель проектирования — выявление ясной иотносительно простой внутренней структуры, иногда называемой архитектурой... Проект естьокончательный продукт процесса проектирования» [41].