Методы проектирования
Во многих проектах разработки ПО процесс проектирования выполняется с помощью специально подобранных методов. Отталкиваясь от множества требований, обычно записанных естественным языком, сначала выполняется неформальное проектирование. Комментарии к программному коду и промежуточные спецификации могут изменяться в процессе реализации системы. После завершения стадии реализации (т.е. программирования и отладки системы) в проектную документацию также вносятся изменения, призванные устранить ошибки и неполноту описания системы в первоначальной спецификации.
Наиболее разработанным подходом к проектированию ПО обладают так называемые структурные методы, которые предлагают множество формализованных нотаций и нормативных руководств для проектирования программных продуктов. В качестве примера этих методов можно назвать структурное проектирование [79, 7*, 24*], структурный анализ систем [125, 10*, 12*], разработку систем Джексона (Jackson, [181, 9*]), а также разнообразные методы, основанные на объектно-ориентированном подходе [295, 54, 302, 55, 303, 304, 7*, 32*, 34*].
Применение структурных методов обычно приводит к созданию графических моделей системы и большому объему проектной документации. CASE-средства (см. раздел 3.7) предназначены для поддержки именно таких методов. Структурные методы успешно применялись во многих программных проектах. Они значительно снижают стоимость разработки, поскольку используют стандартные нотации для получения стандартной проектной документации. Ни об одном из этих методов нельзя сказать, что он лучше или хуже других. Успешное или неуспешное применение того или иного метода часто зависит от типа разрабатываемого ПО.
Каждый структурный метод включает такие компоненты, как модель процесса проектирования, стандартизованные нотации для представления структуры системы, форматы отчетов, правила и нормативные указания по проектированию. Хотя разработано большое количество таких методов, они имеют нечто общее. Структурные методы поддерживают все или по крайней мере некоторые из перечисленных ниже моделей систем.
1. Модель потоков данных, где система моделируется в виде потока данных, преобразуемых в этой системе.
2. Модель сущность-связь, которая применяется для описания сущностей (объектов программной системы) и связей между ними. Эта модель часто используется при проектировании структур баз данных.
3. Структурная модель, предназначенная для документирования системных компонентов и их взаимосвязей.
4. Объектно-ориентированные методы, с помощью которых получают иерархическую модель системы, модели статических и динамических отношений между объектами и модель взаимодействия объектов во время работы системы.
Некоторые структурные методы дополняются другими системными моделями, такими как диаграммы переходов (из одного состояния в другое) или сценарии жизни сущностей, которые показывают последовательность преобразований для каждой сущности. Многие методы предполагают наличие централизованных хранилищ (репозиториев) для системной информации или словарей используемых данных. Многие из этих подходов к моделированию систем описаны в главе 7.
На практике методы представляют нормативные руководства неформально, так что различные проектировщики могут реализовать разные пути проектирования. Фактически эти методы являются набором стандартных нотаций и просто отображают успешную практику проектирования. Следуя этим методам и их нормативным руководствам, можно прийти к рациональному и разумному процессу проектирования. Вместе с тем творчество проектировщиков должно проявиться в способе декомпозиции системы, адекватно отображающей системные требования. С другой стороны, проведенные исследования труда проектировщиков показали, что чаще всего они просто слепо следуют этим методам [20]. Да и сами методы они выбирают в зависимости от частных обстоятельств, а не в соответствии с их достоинствами или недостатками.
Программирование и отладка
Процесс программирования (написания программного кода, кодирования) обычно следует непосредственно за процессом проектирования. Но для некоторых классов программ, например критических по надежности систем, последняя стадия проектирования (детальное проектирование) и начало кодирования могут перекрываться. В процессе проектирования могут использоваться CASE-средства, которые позволяют получить скелетную программу. Такая программа содержит код для определения и реализации интерфейсов, и во многих случаях программисту остается только добавить код, реализующий некоторые детали функционирования программного компонента.
Программирование – индивидуальный процесс, здесь не существует общих правил, которым необходимо следовать при написании программного кода. Некоторые программисты начинают кодирование с компонентов, которые они хорошо понимают, оставляя напоследок кодирование компонентов, которые являются для них темными. Другие применяют противоположный подход, оставляя простые для них компоненты на потом.
Обычно программисты сами тестируют написанный ими программный код для обнаружения возможных ошибок и программных дефектов. Этот процесс называется отладкой программы. В принципе тестирование и отладка являются разными процессами. При тестировании устанавливается наличие программных ошибок. В ходе отладки устанавливается местоположение ошибок, затем они устраняются. На рис. 3.10 показан возможный процесс отладки программы. Отладка может быть частью как процесса разработки, так и процесса тестирования ПО.
Проводящий отладку программист должен сгенерировать такие режимы работы системы, которые помогут обнаружить программные ошибки по аномальному поведению системы. Локализация ошибок может потребовать проведения ручной трассировки кода программы. В процессе тестирования и отладки могут помочь отладочные средства, показывающие значения программных переменных и выполняющие трассировку исполняемых операторов.
Рис. 3.10. Процесс отладки
