1 Основы проектирования программных систем

Пошаговая детализация
Пошаговая детализация — это нисходящая стратегия разработки, предложенная Н. Виртом [103]. Программа разрабатывается путем добавления уровпей про­цедурной детализации. Иерархия создается путем многошаговой декомпозиции макроопределения функции (процедурной абстракции) на составные детализи­рующие части. Процесс прекращается нри достижении уровня онераторов языка программирования.
Детализация по сути является процессом развития. Вы начинаете с определения функции (или описания информации) на высоком уровпе абстракции. Это озна­чает, что определение онисывает функцию или информацию концептуально, без объяснения внутренней работы функции или внутренней структуры информации. Далее вы развиваете оригинальное онределепие, добавляя повые уточнения па каждом шаге детализации.
Абстракция и детализация дополпяют друг друга. Абстракция нозволяет описы­вать процедуру или дапные изнутри, но побуждает непрофессионалов к получению зпапий о деталях. Детализация помогает переходить па более пизкий уровепь, обе­спечивающий дополнительные уточнения и развивающий проектпое решение. Оба принцина способствуют созданию полной нроектпой модели как эволюционного итога проектирования.
Аспекты
В ходе апализа требований обнаруживается набор понятий. Эти понятия включают требования, варианты использования, характеристики, структуры дапных, границы интеллектуальной собственности, сотрудничества, наттерны и контракты. В идеале модель требований должна быть организована так, чтобы позволить вам изоли­ровать каждое попятие (требование) и рассматривать его отдельпо (независимо от других). На практике некоторые из этих нонятий пересекают всю систему и пе поддаются изоляции.
С пачалом проектирования требования трансформируются в модульные нроект- пые представления. Рассмотрим два требования — X и У. Требование У пересекает требование X, если в программной декомпозиции, которая выбрала для X, нельзя реализовать X без учета У.
Например, требование X задает «функцию отображения выполнения заказа в электронном магазине». Требование же У определяет: «зарегистрированный поль­зователь должен быть проверен перед любым использованием средств электронного магазина». Это требование применимо ко всем фупкциям, которые достунны за­регистрированным пользователям. В итоге проектирования мы получим нроектное представление (решение) для требования X и нроектпое представление (решение) для требования У. Поскольку эти нредставлепия реализуют конкретные понятия, представление для У нересекает представление для X.
Представлением пересекающего попятия является аспект. Поэтому проектным представлением для требования «зарегистрированный пользователь должен быть проверен перед любым использованием средств электронного магазина» становится аснект этого электронного магазина. Очень важпо вовремя выявить все аспекты,

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