ВУЗ:
Рис. 6.7. Логическая и функциональная связность внутри объекта, представляющего отдельную комнату в простой ролевой игре
Вопросы для самопроверки
1. Чем роман отличается от энциклопедии в смысле степени связанности, существующей между его элементами, таки-
ми, как главы, разделы или отдельные записи? Что можно сказать о связности этих элементов?
2. Игра в бридж состоит из двух этапов: торг и розыгрыш. Проанализируйте связанность этих фаз, предварительно оп-
ределив, какая информация передается из первой фазы во вторую в явной форме. Какая информация передается в этом слу-
чае неявно?
3. Совместимы ли задачи максимизации связности и минимизации связанности? Другими словами, будет ли естествен-
ным образом уменьшаться связь модулей системы при возрастании связности элементов модулей?
4. Расширьте диаграмму взаимодействий, представленную на рис. 6.6, включив в нее другие сообщения, которые долж-
ны передаваться между объектами классов Room и PlayerRecord.
6.4. МЕТОДЫ ПРОЕКТИРОВАНИЯ
Разработка методов проектирования систем программного обеспечения является основным предметом поиска в области
технологии разработки программного обеспечения. В этом разделе мы рассмотрим несколько разработанных ранее методов
и познакомимся с направлениями текущих исследований.
Нисходящие и восходящие методы разработки. Возможно, наиболее известной стратегией проектирования про-
граммных систем является нисходящая методология. Суть ее состоит в том, что не следует пытаться решить сложную задачу
за один этап. Приступая к решению поставленной задачи, необходимо сначала разбить ее на меньшие, более простые подза-
дачи, которые, в свою очередь, следует разбить на еще меньшие. В результате сложная задача будет сведена к набору более
простых задач, решение которых приведет к выполнению и самой исходной задачи.
При использовании нисходящей технологии проектирования обычно образуется иерархическая система последователь-
ных уточнений, которая, как правило, может быть прямо отображена в модульную структуру, совместимую с парадигмой
императивного программирования. Решение задач самого нижнего уровня этой иерархии обеспечивается процедурными
модулями, выполняющими элементарные задания. В системе эти модули используются в качестве абстрактных инструмен-
тов модулями более высоких уровней, предназначенными для решения сложных задач.
В противоположность этому методу проектирования, при восходящем методе проектирование системы начинается с
определения отдельных задач внутри системы. Затем изучается, как решение этих задач может использоваться в качестве
абстрактных инструментов для решения более общих задач. Многие годы этот подход считался хуже нисходящего метода
проектирования. Однако в настоящее время методология восходящего проектирования получила мощную поддержку. Одна
из причин этого заключается в том, что нисходящая методология ищет решение, в котором основной модуль использует
подмодули, каждый из которых основывается на подмодулях, и т.д. Однако для многих систем наилучший вариант решения
лишен подобной иерархической природы. Действительно, при построении приложения по принципам архитектуры "кли-
ент/сервер" или использовании методов параллельной обработки проектное решение, в котором два или несколько модулей
взаимодействуют как равноправные партнеры, может оказаться более удачным, чем проект, состоящий из управляющего
модуля, обращающегося к модулям подпрограмм для решения стоящих перед ним задач.
Другой причиной такого интереса к восходящему проектированию является то, что оно лучше соответствует задачам построе-
ния сложных систем программного обеспечения из предварительно созданных, стандартных, свободно продаваемых компонентов.
Однако именно этот подход является наиболее современной тенденцией в технологии разработки программного обеспечения. Под-
робно мы рассмотрим эту стратегию ниже.
Общие инструменты разработки. В технологии разработки программного обеспечения создано множество систем
обозначения, предназначенных для анализа и проектирования систем. Мы уже встречались с некоторыми из них, например
структурными схемами, диаграммами классов и диаграммами взаимодействия. Еще одна разновидность подобных инстру-
ментов – диаграмма потоков данных, содержащая графическое представление путей перемещения данных в системе. На
диаграмме потоков данных указываются места происхождения, конечного назначения и промежуточной обработки данных в
системе. Каждый из символов, который указывается на такой диаграмме, имеет специальное значение: стрелки представля-
Страницы
- « первая
- ‹ предыдущая
- …
- 148
- 149
- 150
- 151
- 152
- …
- следующая ›
- последняя »
