2с лекция 5 Архитектурн проект

ЛЕКЦИЯ 5
Тема 2.4 Архитектурное проектирование программного изделия
1. Цель фазы. Виды деятельности в фазе. Ответственные за определение
архитектурного проекта.
2. Документ Архитектурный проект.
1 Цель фазы. Виды деятельности в фазе. Ответственные за определение
архитектурного проекта.
Фаза архитектурного проектирования – фаза "принятия решения".
Цель фазы – определить совокупность компонент ПИ и их интерфейсы,
чтобы дать каркас для последующей разработки ПИ.
Архитектурный
проект
должен
охватывать
все
требования,
сформулированные на предыдущей фазе.
Ответственные за архитектурный проект – инженеры (разработчики
программного обеспечения), консультируются с другими специалистами и
представителями заказчика.
Операционный персонал проводит обзор архитектурного проекта.
Результат фазы – документ Архитектурный проект, документирующий
каждую компоненту ПИ и ее связи с другими компонентами.
Документ завершен, если уровень описания компонент и их интерфейсов
достаточен для того, чтобы над каждой из них могли независимо работать
отдельные исполнители или их небольшие группы во время следующей фазы
детального проектирования.
Заканчивается фаза формальным утверждением документа Архитектурный
проект после рассмотрения и критического обзора.
Работы выполняются в соответствии с планами, разработанными на
предыдущей фазе.
Сюда входят:
 конструирование физической модели ПИ;
 описание требований к архитектурному проекту;
 выбор языка программирования;
 обзор проекта.
Виды деятельности
Разработчик должен сконструировать физическую модель, описывающую
проект программного изделия в терминах программной обстановки. Физическая
модель должна быть выведена из логической модели, описанной в Требованиях к
программному изделию. При преобразовании логической модели в физическую
принимаются проектные решения, связанные с распределением функций по
компонентам и определением входов и выходов каждой компоненты.
Все проектные решения должны фиксироваться документально.
Моделирование – итеративный процесс. После описания каждой части
проекта необходимо возвращаться к описанию предыдущих частей, пока не будет
достигнуто ясное и точное описание каждой компоненты.
Программное изделие должно быть представлено в виде иерархии компонент
в соответствии с методами функциональной декомпозиции, а все компоненты –
располагаться по уровням иерархии, каждая компонента при этом – занимать точно
определенное место. Функциональная декомпозиция осуществляется с помощью
метода нисходящего проектирования. Декомпозиция реализует принцип сокрытия
информации, требуя, чтобы компоненты нижнего уровня рассматривались как
"черные ящики" для компонент более высокого уровня. Т.е. для верхнего уровня
известны только функции и интерфейсы компонент более низкого уровня,
особенности их внутреннего функционирования остаются неизвестными.
Нисходящее проектирование требует, чтобы каждый уровень проекта был
описан с использованием терминов, отражающих степень абстракции,
соответствующую данному уровню.
Компоненты нижнего уровня проекта должны быть достаточно независимы,
чтобы обеспечить проведение независимого и параллельного дальнейшего их
детального проектирования и кодирования с минимальными взаимосвязями между
программистами.
Архитектурный проект должен быть понятным, простым для модификации и
обеспечивать высокую эффективность программного изделия. Эффективность
определяется минимальным использованием имеющихся ресурсов, простота
модификации – незначительными затраты на сопровождение. Функциональная
простота характеризуется "связностью" отдельных компонент, т.е. внутренней
структурой компоненты. При проектировании стремятся максимизировать связность
каждой компоненты.
Архитектурный проект должен быть модульным, с минимальным сцеплением
между компонентами и с максимальной связностью внутри каждой из них.
{Модуль – отдельная функционально-законченная программная единица,
которая может применяться самостоятельно, либо быть частью программы.
Связность (связанность) модуля определяется как мера независимости его
частей.
Сцепление модулей, т.е. мера взаимозависимости модулей по данным,
характеризуется как способом передачи данных, так и свойствами самих данных.}
Компоненты модульной схемы должны описываться как "черные ящики",
скрывая информацию о их внутренней структуре от других компонент. Важно знать,
что они делают, а не как они работают.
Для упрощения понимания при описании проектов используются стандарты и
соответствующая терминология; для решения одинаковых проблем – одинаковые
решения.
2 Документ Архитектурный проект
В документе Архитектурный проект программного изделия должен быть
отражен один выбранный подход к решению поставленной проблемы, но в
документе История проекта обычно описываются такие моменты, как
необходимость создания прототипа, перечень разработанных программ, критерии
выбора альтернатив и причины, определившие выбор варианта.
Документ Архитектурный проект программного изделия – ключевой
документ, суммирующий все принятые решения. Он является основой для
детального проектирования. Кроме описания всех компонент изделия, он должен
содержать ссылки на все внешние интерфейсы.
Основное требование к документу – требование полноты охвата всех
требований к программному изделию, представленных в предыдущем документе.
Для демонстрации полноты в документ должна быть включена таблица
перекрестных ссылок между требованиями к программному изделию и
компонентами архитектурного проекта. Документ не может быть противоречивым.
Документ Архитектурный проект должен быть достаточно детальным,
позволяющим составить план следующей фазы проектирования. Степень
детализации на уровне архитектурного проекта должна обеспечивать возможность
более точной оценки стоимости работ, последующих фаз разработки программного
изделия.