ВУЗ:
Опыт показывает, что незначительные дополнительные усилия, затраченные при разработке программы, впоследствии
могут существенно изменить ситуацию, когда потребуется внести в нее изменения. Например, при обсуждении операторов
описания данных в главе 5 было показано, как вместо безличного числового значения 645 в программе может использовать-
ся символическое имя AirportAlt. В дальнейшем обсуждении разъяснялось, что, если возникнет необходимость в изменени-
ях, гораздо легче изменить значение, связанное с некоторым символическим именем, чем осуществить поиск и изменение
множества вхождений безличного арифметического значения 645. Как следствие, большая часть исследований в области
технологии разработки программного обеспечения концентрирует свое внимание именно на фазе разработки в жизненном
цикле программы. Их задача – найти способы эффективного использования тех преимуществ, которые достигаются за счет
дополнительных усилий на данной стадии, понимаемых как выгодное средство достижения цели.
Традиционные этапы разработки программ. Фаза разработки в жизненном цикле программы традиционно включает
следующие этапы: анализ, проектирование, реализацию и тестирование (рис. 6.2).
Фаза разработки в жизненном цикле программы начинается с анализа, основная задача которого состоит в определении
нужд пользователей предлагаемой системы. Если система должна быть продуктом общего назначения, продаваемым на
рынке в условиях свободной конкуренции, анализ, вероятно, будет включать широкомасштабные исследования в целях оп-
ределения потребностей потенциальных пользователей. Однако если система разрабатывается для нужд конкретного поль-
зователя, исследования будут носить более целенаправленный характер.
По мере того как выясняются потребности потенциального пользователя, они преобразуются в ряд требований, кото-
рым должна удовлетворять новая система. Эти требования формулируются в терминах, принятых в сфере приложения, без
использования специальной терминологии, принятой среди специалистов по обработке данных. Одно из требований может
состоять в том, что доступ к данным должен предоставляться только зарегистрированным пользователям. Другое требование
может заключаться в том, чтобы данные отражали текущее состояние товарных запасов на конец последнего рабочего дня
или чтобы организация данных на экране компьютера соответствовала формату используемых в настоящее время бумажных
документов.
6.2. Фаза разработки в жизненном цикле программного обеспечения
После того как требования к создаваемой системе будут определены, их преобразуют в систему спецификаций, имею-
щих более технически организованный вид. Например, разрешение доступа к данным, только зарегистрированным в системе
пользователям, должно быть представлено отдельным пунктом спецификаций; в нем указывается, что система не должна
отвечать на какие-либо запросы, пока с клавиатуры не будет введен соответствующий пароль из восьми цифр, или же дан-
ные будут отображаться на экране в закодированной форме и примут осмысленный вид только после обработки некоторой
стандартной программой, имя которой должно быть известно лишь зарегистрированным пользователям.
В то время как анализ определяет, что должна делать предлагаемая система, проектирование определяет, как она будет
выполнять эти задачи. Именно на этом этапе определяется структура системы программного обеспечения.
Не вызывает сомнения то, что наилучшей структурой для крупной системы программного обеспечения является мо-
дульная. Именно благодаря разбиению больших систем на модули становится возможной их практическая реализация. Без
этого разбиения технические детали, необходимые при реализации большой системы, превысили бы возможности человече-
ского восприятия. При использовании модульной конструкции разработчик может ограничиться изучением только тех дета-
лей, которые относятся к рассматриваемому модулю. Модульная конструкция также удобна при дальнейшем сопровождении
программы, поскольку позволяет вносить изменения на модульной основе. (Если изменение нужно внести в способ выпол-
нения расчетов по больничным листам работников, то потребуется рассматривать только те модули, которые непосредст-
венно связаны с оплатой больничных листов.)
Однако понятие модуля может трактоваться по-разному. Если подходить к задаче конструирования, используя пара-
дигму традиционного императивного программирования, то модули будут состоять из отдельных процедур и разработка
модульной структуры примет форму выявления различных заданий, которые создаваемая система должна будет выполнять.
В противоположность этому, если предполагается использовать объектно-ориентированный подход, то в качестве модулей
будут выступать отдельные объекты, а процесс конструирования модульной структуры превратится в процесс выявления
имеющихся в предметной области сущностей (объектов) и определения их поведения в предлагаемой системе.
Следующим этапом является реализация. Он включает собственно написание программ, создание файлов данных и разра-
ботку баз данных.
Тестирование тесно связано с реализацией, так как каждый модуль системы, как правило, должен подвергаться тести-
рованию, как только он будет написан. Действительно, в правильно сконструированной системе каждый модуль может и
должен быть проверен либо независимо от других модулей, либо с использованием упрощенных версий других модулей,
называемых заглушками (stub). Назначение заглушек состоит в том, чтобы имитировать взаимодействие тестируемых моду-
лей и остальной части системы. Аналогичным образом можно тестировать и систему в целом, по мере завершения создания
отдельных модулей и их объединения в единое целое.
К сожалению, этап тестирования и устранения обнаруженных в системе неполадок чрезвычайно сложно довести до ус-
пешного завершения. Опыт показывает, что большие системы программного обеспечения могут содержать множество оши-
Страницы
- « первая
- ‹ предыдущая
- …
- 143
- 144
- 145
- 146
- 147
- …
- следующая ›
- последняя »
