11 ) Цель и объекты проектирования. Архитектурное и детальное

Процесс проектирования является неотъемлемой частью создания продукта. Основная цель процесса проектирования — преобразовать общие внешние требования к продукту в конкретные требования к внутреннему устройству и функционированию продукта. Поэтому при переходе от анализа к проектированию происходит так называемый «взрыв производных требований». Список проектных требований часто в 50 раз длиннее списка исходных требований.

Пять основных объектов (аспектов) проектирования программной системы:

• физическая структура (physical structure) определяет состав и взаимосвязь физических частей системы: исполняемых программ, динамических библиотек, COM-объектов, сборок, баз данных и т. д. Для сложных систем ненужно создание одного исполняемого файла и даже невозможно, особенно если программная система заведомо должна быть распределенной (distributed);

• логическая структура (logical structure) определяет состав и взаимосвязь логических частей системы: классов, объектов, подпрограмм, модулей. Как правило, логическая структура проектируется отдельно для каждой физической части системы. Что именно является элементом логической структуры системы — зависит от выбранной парадигмы программирования: процедурной (процедуры и функции), объектно-ориентированной (классы и обьекты) и т. д. Кроме того, при проектировании логической структуры выполняется разделение на модули.

• алгоритмы (algorithms);

• структуры данных (data structures) в памяти, а также базы данных;

• пользовательский интерфейс (user interface).

Проектные решения делятся на два вида:

Архитектурное проектирование (architectural design) те проектные решения, которые являются наиболее важными, определяющими для системы. Каждое из них влияет на то, какой будет существенная часть системы или вся система.

Детальное проектирование (detail design) те проектные решения, которые не влияют на другие части системы и могут быть проработаны позже, в том числе во время реализации.

Приоритеты в проектировании аспектов зависят от специфики программы. Для приложений баз данных проект базы данных является архитектурно-значимым и должен быть создан вовремя архитектурного проектирования, для вычислительно-интенсивных приложений алгоритмы являются архитектурно-значимыми (например, программы-архиваторы). Концепции построения физической и логической структуры входят в архитектуру любой системы.

Стоимость ошибок архитектурного проектирования высока, поэтому на него должно выделяться отдельное время и самые квалифицированные проектировщики. Детальное проектирование, напротив, нередко осуществляют сами программисты в процессе разработки, если их квалификация это позволяет. Например, алгоритм конкретной процедуры или дизайн конкретной рядовой формы, поэтому детальное проектирование зачастую почти полностью сливается с процессом кодирования.

12 ) Виды декомпозиции системы. Основные структурные методы проектирования (по направлению декомпозиции).

Сложную систему человеческий разум никогда не может осознать целиком одновременно. Главным способом преодолеть эту сложность является последовательная декомпозиция системы (decomposition), то есть разделение системы как целого на совокупность взаимосвязанных элементов.

Что именно является элементом системы — зависит от выбранной парадигмы программирования: процедурной (процедуры и функции), объектно-ориентированной (классы и обьекты) и т.д. Все они являются основаниями декомпозиции. В настоящее время имеет смысл рассматривать лишь два основания декомпозиции: процедурное и объектно-ориентированное.

По направлению процесса декомпозиции принято выделять три основных метода проектирования.

При нисходящем проектировании (проектировании «сверху вниз», top-down design) проектирование начинается с верхнего уровня абстракции — представления системы как «черного ящика». Система иерархически разбивается на подсистемы/классы и т. д. вплоть до элементов нижнего уровня. Это метод общего назначения, универсальный, с его помощью можно проектировать любую систему.

При восходящем проектировании (проектировании «снизу вверх», bottom-up design) сразу выделяется множество необходимых элементов нижнего уровня реализации, затем над ними надстраивается уровень управления. Этот метод не универсален, его используют для относительно небольших систем, как правило, инструментального назначения. В таких системах обычно четко прослеживается большое количество инструментальных компонент нижнего уровня, а на верхнем уровне, практически, реализуется только интерфейс к ним. Например, так может быть спроектирована утилита-архиватор: сначала проектируется множество алгоритмов для заведомо необходимых операций (архивация, разархивация, шифрование, дешифрование и т. д.), затем «надстраивается» пользовательский интерфейс.

При проектировании методом расширения ядра (проектировании

«от центра») выделяется базовый процесс или объект (ядро), на котором основана вся система. Проектирование ведется одновременно «вниз» (для реализации ядра на низком уровне) и «вверх» (для использования ядра на верхнем уровне).

Наиболее часто используется смешанный подход к проектированию, при котором основное проектирование ведется сверху вниз, однако для некоторых частей системы используются элементы проектирования от центра и снизу вверх.

Проектирование средних и крупных систем есть столь сложный и длительный процесс, что его стремятся также вести параллельно несколькими группами проектировщиков. При этом декомпозиция системы органично приводит к декомпозиции самого процесса проектирования.