Книга: Программное обеспечение и его разработка
Последовательный ход процесса проектирования программной системы
Последовательный ход процесса проектирования программной системы
Процесс, ход проектирования понимается недостаточно хорошо даже самыми опытными программистами. Многие выполняют его инстинктивно, пропуская некоторые шаги, необходимые для хорошей разработки. Многие выполняют этот процесс очень плохо.
Показанный на рис. 5.23 процесс проектирования начинается после определения требований к системе и развивается, охватывая все более мелкие его этапы.
Функции процесса определения требований рассматривались нами в предыдущем разделе книги. На этой схеме мы снова показываем этот процесс, причем документы, получающиеся в результате, являются первой, исходной точкой проектирования. Заметьте, что мы отделяем действие от продукта, получающегося в результате, помечая и то и другое. Делаем мы это потому, что при разработке программного обеспечения и систем часто путают некоторые из этих терминов.
Второй шаг, проектирование, связан с рассмотрением различных подходов к решению проблемы и с выяснением, могут ли они привести нас к этому решению. Этот шаг часто связан с применением методов проб и ошибок, нередки возвраты к предыдущему шагу. По мере продвижения вперед, нам часто бывает необходимо развить наш проект еще дальше, чтобы проверить, действительно ли мы можем завершить его так, как нам бы этого хотелось. После того как это будет проделано достаточное число раз и с достаточной степенью детализации, мы получим некий подход — и очень часто он оказывается искомым подходом, в большинстве случаев он более или менее работоспособен.
К сожалению, в подавляющем большинстве случаев проектирование на этом и заканчивается, а все дальнейшие работы по созданию системы связаны с воплощением в жизнь только что выбранных вариантов.
Заметим, однако, что в результате второго шага создаются многие тома документов и отчетов. Ведь мы получили какое-то решение. В некоторых случаях кипа документов достигает двух и более метров в высоту.
Может ли это называться проектом? Конечно, но только не вполне законченным, причем, по всей вероятности, он не очень-то нам понятен и его трудно кому-нибудь объяснить! Даже если он правилен!
И надо проделать еще третий шаг, чтобы сделать полученный проект более компактным, четким, легким для понимания и объяснения и, следовательно, для реализации.
Чаще всего третий шаг, связанный с синтезацией и уменьшением объема проекта, пропускается, многие сразу переходят к четвертому шагу — подробному проектированию после завершения шага 2 — нахождения работоспособного решения. Выполнение шага 3 приносит существенную пользу, потеря преимуществ при отказе от него наносит серьезный удар по всей разработке большой программной системы.
Преимущества этого шага, вносящего в проект ясность и краткость, сразу бросятся в глаза после его выполнения. Проект станет легко описываемым и вполне понятным. Лежащие в основе принципы понять просто. Результаты проведенного ранее эвристического (методом проб и ошибок) проектирования (шаг 2) слишком объемисты и неясны. Проект может быть правильным, но пользование им будет связано с большими затратами труда и времени. Обычно он бывает понятен одному или, в более счастливом случае, нескольким лицам. Все остальные участники работ понимают до конца лишь части системы, но не систему как целое.
Переработанный после шага 3 проект имеет то преимущество, что его можно показать всем, тогда проектировщики и программисты подсистем смогут работать над своими частями с большей пользой для общего дела.
На четвертом шаге создается проект верхнего уровня. Положения, сформулированные в нем, служат исходными требованиями для работ по созданию других проектов, более низких уровней.
Повторным применением шага 4 ко всем более низким уровням проекта мы создаем целую серию проектов. Это длится до тех пор, пока не будет создан проект самого нижнего уровня. На каждом уровне создаются как описания требований к более низкому уровню, так и проект модуля; этот процесс продолжается до тех пор, пока не будет достигнут уровень реализации (написания) или уровень тривиальности. Чаще возникает эта последняя ситуация.
Рассмотрим различные варианты третьего шага: шага критической оценки и очистки. На рис. 5.24 направление процесса проектирования указывается стрелкой — слева направо. С левой стороны, в начале проектирования, обозначен процесс создания. Формирующийся при этом проект еще очень расплывчат и находится пока только в голове проектировщика. Небольшой прямоугольник в центре рисунка обозначает очистку, которая следует дальше. Очистка крайне важна. Из проекта исключаются повторы, неоднозначности и тривиальные положения. Внимание сосредоточивается на самых существенных частях решения. В процессе очистки исключаются все случайные, несущественные элементы, выделяются основные принципы, которым надо следовать. Краткое, сжатое определение метода решения облегчает управление всей оставшейся частью работ по разработке программного обеспечения.
Повторяю, что подобная очистка часто не производится. Производить ее трудно, для этого требуется особый талант и очень много труда. Но проводить ее все же надо обязательно.
Расширяющееся пространство на рисунке справа от шага очистки служит для обозначения всевозрастающего объема проектирования и документирования по мере продолжения работ. На базе сформулированных нами фундаментальных основ проектирования мы приступаем к наращиванию уровней детализации, двигаясь прямо к реализации проекта.
Джон Ливингстон Лоувс (1867–1945) в книге «The Road to Xanadu» (1927 г.) пишет о творчестве и приводит примеры великих открытий. Он устанавливает в процессе творчества, открытия, три части, которые называет: ИСТОЧНИК, ВИДЕНИЕ и ВОЛЯ. В источнике находятся все факты, которые ожидают, чтобы их использовали…
Где, действительно, в каждый момент находятся все несчетные известные нам факты и миллионы пережитых нами эпизодов? Где бы это таинственное место ни было… ИСТОЧНИК — это только подходящее обозначение для тайны. И там, поглощенные некими неведомыми глубинами, для всех намерений и целей как бы не существовавшие — они покоились в глубоком сне. Некоторым было суждено дремать неделями, некоторым месяцами, а некоторым целые годы. И вдруг все сразу они пробудились..
Картина пришла в движение и начала разворачиваться помимо моей воли. На мгновение я просто позволил течь потоку образов. Затем я осторожно стал управлять им…
Без ВИДЕНИЯ хаос элементов остается хаосом. А ФОРМА спит вечным сном в просторном хранилище не родившихся замыслов. И в том хаосе лишь творческое ВИДЕНИЕ может различить эту ФОРМУ. Точно так же без содействия ВОЛИ, подчиненной этому ВИДЕНИЮ, воспринятая в сонме других картина не могла бы стать объективной реальностью.
То, что Лоувс называет тремя основными составляющими, очень напоминает описанные нами три части процесса проектирования. Его «воля» хотя и не является полным эквивалентом очистки, но близка ей.
- Характеристики программ
- Процесс разработки программного обеспечения
- Полный цикл
- Использование
- «Большой взрыв» и эволюция
- Определение требований
- Требования системного уровня
- Изменения неизбежны
- Кто формулирует требования к программному обеспечению?
- Язык документирования требований
- Особая важность требований
- Кто является действительным пользователем в любом проекте?
- Противоречивые требования разных пользователей
- Требования к товарным программам и программному обеспечению проектов
- Изменения, вносимые пользователем
- Адаптируемость способствует непрекращающимся изменениям
- Определение требований — это длительный процесс
- Спецификация требований
- Определение требований к окружающей обстановке в фазе использования
- Управление процессом выработки требований
- Новые методы определения требований
- Личный опыт
- Резюме: требования к большим системам программного обеспечения
- Проектирование
- Что такое проектирование?
- Программное обеспечение — это подсистема
- Многократное и параллельное проектирование
- Параллельная разработка
- Итерации при проектировании и выработке требований
- Проектирование программного обеспечения фазы использования
- Кто должен вести проектирование
- Конечная продукция — что же мы создаем?
- Составные части и процесс проектирования
- Структура
- Описание
- Последовательный ход процесса проектирования программной системы
- Уровни проектирования
- Проектирование верхнего уровня
- Расслоение
- Выделение макрослоев
- Временные ограничения
- Проектирование среднего уровня
- Выделение микрослоев
- Проектирование модуля
- Упрятывание информации
- Проектирование нижнего уровня
- Межуровневые механизмы и уровень тривиальности
- Вариации уровня тривиальности и межуровневых механизмов
- Структурное программирование
- Введение в структурное программирование
- Преимущества структурного программирования
- Приемлемость структурного программирования
- Хорошее проектирование
- Проектирование это…
- Итеративность
- Компромиссы
- Проектирование больших программ типа V — это многогранная деятельность
- Деталировка — это примитивное проектирование
- Устойчивые программы, или программы, дружественные пользователю
- Документирование проекта
- Спецификация — это проектирование и одновременно выработка требований
- Новые методы проектирования
- Данные и процесс
- Структурное проектирование
- Трудности нововведений
- Написание программ — программирование
- Языки
- Мощность языка и связанные с ней трудности
- Рост числа языков
- Язык и мышление
- Ограничения, накладываемые языками
- Процесс написания программы
- Кросс-транслятор
- Множество форм одной программы
- Вычислительные машины для трансляции
- Программирование в диалоговом режиме
- С чем же мы ведем диалог?
- Управление написанием программ
- Различия уровня квалификации программистов
- Главный программист
- Библиотекарь
- Компоновка программ
- Сборка большого числа модулей в одну работающую систему программного обеспечения
- Следует ли проводить компоновку перед тестированием?
- Средства обслуживания руководства
- Автоматическое использование инструментальных средств
- Выбор трансляторов и языков
- Реализация сверху вниз
- Окружение разработки программного обеспечения
- Выводы
- Верификация и тестирование
- Верификация
- Раннее выявление «пробелов»
- Инспектирование
- Пример ошибки
- Тестирование и качество
- Надежное программное обеспечение — неверный термин
- Тестирование с возвратом
- Физическая сохранность
- Тестирование — средство обучения
- Независимость тестирующих групп
- Продолжительность развития
- Выводы
- Документирование
- Самодокументирование
- Структурированное словесное описание
- Документация для других целей
- Отслеживание связей
- Избыток документации
- Исключение блок-схем
- История проекта
- «Как» — это «что». Требование — это проект — уровни детализации
- Реальная ситуация
- 9.3.2. Выходные операнды
- Почему необходима миграция
- Сущность процесса миграции
- Пошаговые инструкции для перехода на 3-й диалект
- Ошибки проектирования базы данных
- Особенности системы защиты данных в InterBase
- V Совершенствование процесса
- Уменьшение времени, необходимого для резервного копирования и восстановления
- Использование сервера Yaffil внутри процесса
- Стиль написания исходного кода
- Обход дерева
- Установка системы на уже подготовленный жесткий диск