Книга: Программное обеспечение и его разработка
Хорошее проектирование
Хорошее проектирование
Хорошее проектирование приводит к ясному проекту; в таком проекте имеется внутреннее единство. В своей книге «Мифический человеко-месяц» Брукс[18] упоминает европейские соборы, строившиеся по нескольку веков. Наиболее эффектны из них те, в которых видна идея самого первого архитектора. К «плохим» относятся те соборы, в которые каждое столетие вносилось что-нибудь от очередного строителя. Многие языки программирования не прижились потому, что их создатели попытались объединить в них слишком много разноречивых свойств. В связи с этим Брукс упоминает язык PL/1.
С концепцией единства проектирования согласны и Милс, и Уитт, и Лингер, с ней согласны также Йенсен и Тонис[19]. Мой опыт говорит, что автором проекта больших систем является обычно один человек. Этот человек определяет направление работ.
Как говорится, о вкусах спорить не приходится. Система диспетчеризации воздушных перевозок доводилась до рабочего состояния в течение 10 лет (совершенно завершена эта работа не будет никогда), за этот период времени заказчик провел немало разных ревизий. Одна ревизия, которую проводила группа независимых экспертов по программному обеспечению, констатировала, что проект управляющей (системной) программы выполнен «архаичными методами и неправильно». Несмотря на это, после завершения работ программа прекрасно работала. (Но скольким толкам дал пищу этот отзыв!)
Некоторые руководители разработок программного обеспечения толкают своих программистов на постоянное использование новейших, самых «привлекательных» методов. Они пытаются привычные вещи делать новыми способами или находить новые работы. Этих программистов снабжают инструментарием, специально проектировавшимся с расчетом на творческое использование. Мы должны называть такие работы не разработками программного обеспечения, а научными исследованиями.
С другой стороны, находятся такие руководители, которые уже закончили проект и теперь хотят, чтобы были написаны программы размером в 400 000 строк или около того. А после того как программы будут написаны, их надо будет отправить пользователям и заняться их сопровождением. Этим руководителям не нужна ни привлекательность, ни изобретательская деятельность. Им требуется надежность, ясность, воспроизводимость. Им нужны простые, незатейливые программы.
- Характеристики программ
- Процесс разработки программного обеспечения
- Полный цикл
- Использование
- «Большой взрыв» и эволюция
- Определение требований
- Требования системного уровня
- Изменения неизбежны
- Кто формулирует требования к программному обеспечению?
- Язык документирования требований
- Особая важность требований
- Кто является действительным пользователем в любом проекте?
- Противоречивые требования разных пользователей
- Требования к товарным программам и программному обеспечению проектов
- Изменения, вносимые пользователем
- Адаптируемость способствует непрекращающимся изменениям
- Определение требований — это длительный процесс
- Спецификация требований
- Определение требований к окружающей обстановке в фазе использования
- Управление процессом выработки требований
- Новые методы определения требований
- Личный опыт
- Резюме: требования к большим системам программного обеспечения
- Проектирование
- Что такое проектирование?
- Программное обеспечение — это подсистема
- Многократное и параллельное проектирование
- Параллельная разработка
- Итерации при проектировании и выработке требований
- Проектирование программного обеспечения фазы использования
- Кто должен вести проектирование
- Конечная продукция — что же мы создаем?
- Составные части и процесс проектирования
- Структура
- Описание
- Последовательный ход процесса проектирования программной системы
- Уровни проектирования
- Проектирование верхнего уровня
- Расслоение
- Выделение макрослоев
- Временные ограничения
- Проектирование среднего уровня
- Выделение микрослоев
- Проектирование модуля
- Упрятывание информации
- Проектирование нижнего уровня
- Межуровневые механизмы и уровень тривиальности
- Вариации уровня тривиальности и межуровневых механизмов
- Структурное программирование
- Введение в структурное программирование
- Преимущества структурного программирования
- Приемлемость структурного программирования
- Хорошее проектирование
- Проектирование это…
- Итеративность
- Компромиссы
- Проектирование больших программ типа V — это многогранная деятельность
- Деталировка — это примитивное проектирование
- Устойчивые программы, или программы, дружественные пользователю
- Документирование проекта
- Спецификация — это проектирование и одновременно выработка требований
- Новые методы проектирования
- Данные и процесс
- Структурное проектирование
- Трудности нововведений
- Написание программ — программирование
- Языки
- Мощность языка и связанные с ней трудности
- Рост числа языков
- Язык и мышление
- Ограничения, накладываемые языками
- Процесс написания программы
- Кросс-транслятор
- Множество форм одной программы
- Вычислительные машины для трансляции
- Программирование в диалоговом режиме
- С чем же мы ведем диалог?
- Управление написанием программ
- Различия уровня квалификации программистов
- Главный программист
- Библиотекарь
- Компоновка программ
- Сборка большого числа модулей в одну работающую систему программного обеспечения
- Следует ли проводить компоновку перед тестированием?
- Средства обслуживания руководства
- Автоматическое использование инструментальных средств
- Выбор трансляторов и языков
- Реализация сверху вниз
- Окружение разработки программного обеспечения
- Выводы
- Верификация и тестирование
- Верификация
- Раннее выявление «пробелов»
- Инспектирование
- Пример ошибки
- Тестирование и качество
- Надежное программное обеспечение — неверный термин
- Тестирование с возвратом
- Физическая сохранность
- Тестирование — средство обучения
- Независимость тестирующих групп
- Продолжительность развития
- Выводы
- Документирование
- Самодокументирование
- Структурированное словесное описание
- Документация для других целей
- Отслеживание связей
- Избыток документации
- Исключение блок-схем
- История проекта
- «Как» — это «что». Требование — это проект — уровни детализации
- Реальная ситуация
- Проектирование базы данных
- 8.2. Проектирование
- 6.2. Проектирование, обеспечивающее прозрачность и воспринимаемость
- Урок 7.4. Проектирование базы данных. Создание связей между таблицами
- Проектирование наследования
- Проектирование
- 1.4.1. Проектирование программ
- Примеры к главе 13 (проектирование пользовательского интерфейса)
- 5.3. Проектирование протоколов прикладного уровня
- Лабораторная работа № 2 Проектирование лексического анализатора
- Глава 1 Модели дистрибуции: проектирование и оптимизация
- Глава 9. Проектирование для конверсии