Архитектура - Тактическое и оперативное планирование разработки интернет-приложения

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

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

Хорошая архитектура облегчает конструирование. Плохая архитектура делает его почти невозможным.

Внесение изменений в архитектуру при конструировании и на последующих этапах обходится недешево. Время, необходимое для исправления ошибки в архитектуре ПО, сопоставимо со временем, нужным для исправления ошибки в требованиях, то есть превышает временные затраты на исправление ошибки в коде. Изменения архитектуры похожи на изменения требований еще и тем, что кажущиеся небольшими изменения могут иметь далеко идущие последствия. Чем бы ни были обусловлены изменения архитектуры -- исправлением ошибок или внесением улучшений, -- чем раньше компания осознает их необходимость, тем лучше.

В первую очередь, архитектура должна включать описание системы. Без такого описания будет трудно составить согласованную картину из тысячи деталей или хотя бы десятка отдельных классов.

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

Архитектура должна определять основные компоненты программы. В зависимости от размера программы ее компонентами могут быть отдельные классы или подсистемы, состоящие из нескольких классов. Каждый компонент является классом или набором классов/методов, которые в совокупности реализуют высокоуровневые функции программы, такие как взаимодействие с пользователем, отображение Web-странцы, интерпретация команд, инкапсуляция бизнес-правил и доступ к данным. За каждую функцию приложения, указанную в требованиях, должен отвечать хотя бы один компонент. Если функцию реализуют несколько компонентов, они должны сотрудничать, а не конфликтовать.

В архитектуре должна быть четко определена ответственность каждого компонента. Компонент должен иметь одну область ответственности и "знать" как можно меньше об областях ответственности других компонентов.

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

Список типичных разделов архитектуры:

    - Основные классы - Организация данных - Бизнес правила (и бизнес процессы) - Пользовательский интерфейс - Управление ресурсами - Безопасность - Взаимодействие с другими системами - Интернационализация/локализация - Обработка ошибок - Возможность реализации архитектуры - Готовые компоненты - Повторное использование кода - Стратегия внесения изменений

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

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

В архитектуре должны быть обоснованы важнейшие принятые решения.

В архитектуре должны быть явно определены области риска, указаны его причины и описаны действия по сведению риска к минимуму.

Похожие статьи




Архитектура - Тактическое и оперативное планирование разработки интернет-приложения

Предыдущая | Следующая