6 Проект

20 Февраль 2014 →

6.

Основной способ проектирования, позволяющий бороться со сложностью, состоит в применении известного принципа «разделяй и властвуй», который в отношении ПС состоит в разбиении задач (системных функций, подсистем, модулей и т.д.) на более простые подзадачи. Такая рекурсивная декомпозиция проводится до получения требуемого уровня детализации, обеспечивая возможность независимой работы разработчиков над различными частями системы.

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

Главным результатом процесса проектирования является архитектура системы. Несмотря на широкое использование термина «архитектура», для него до сих пор не существует общепризнанного определения. Филипп Крачтен, Гради Буч, Курт Биттнер и Рич Рейтман предложили следующее определение архитектуры [64]:

«Архитектура ПО заключает в себе ряд важных решений об организации программной системы, среди которых: выбор структурных элементов и их интерфейсов, составляющих и объединяющих систему в единое целое; поведение, обеспечиваемое совместной работой этих элементов; организацию этих структурных и поведенческих элементов в более крупные подсистемы, а также архитектурный стиль, которого придерживается данная организация. Выбор архитектуры ПО влияет на функциональность, удобство использования, устойчивость, производительность, повторное использование, понятность, экономические и технологические ограничения, эстетическое восприятие и поиск компромиссов».

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

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

Необходимо помнить, что архитектура должна:

Раскрывать структуру системы, скрывая детали реализации.

Охватывать все варианты использования и сценарии системы.

Отвечать требованиям различных заинтересованных сторон.

Соответствовать функциональным требованиям и обеспечивать требуемые показатели качества.

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

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

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

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

1.6.1. Основные принципы проектирования

Вне зависимости от типа приложения, необходимо помнить о следующих принципах проектирования:

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

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

Принцип минимального знания, также известный как Закон Деметера (Law of Demeter, LoD). Компоненту или объекту не должны быть известны внутренние детали реализации других компонент или объектов.

DRY (Don't Repeat Yourself). Функциональность должна быть реализована только в одном месте и не должна дублироваться ни в одном другом компоненте. Данный принцип был подробно рассмотрен ранее в теме «Экстремальное программирование».

YAGNI (You Ain't Gonna Need It). Если требования к приложению четко не определены, или существует вероятность изменения дизайна в будущем, не следует тратить силы на проектирование наперед. Данный принцип был подробно рассмотрен ранее в теме «Экстремальное программирование».

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


See also:
Новое
Похожие записи
  • Титльник и содержание
    Министерство образования Омской области БОУ ОО СПО «Омский колледж транспортного строительства» Специальность...
  • Теоретическое содержание
    Основные этапы развития литературно-критической мысли Девятнадцатый век В девятнадцатом веке литературоведение оформилось...
  • Теоретическое содержание (2)
    Тема 7. ПРОБЛЕМА РОДА И ЖАНРА В НАУКЕ О ЛИТЕРАТУРЕ* Большинство исследователей...

Комментарии закрыты.