Основы проектирования ( Software Design Fundamentals )

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

Далее рассмотрим подразделы данной секции:

1.1. Общие концепции проектирования.  

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

Отсюда каркасный подход к построению программных систем, где любая конфигурация строится из двух частей: первая, постоянная часть — каркас, не меняющийся от конфигурации к конфигурации. Каркас несет в себе гнезда, в которых размещается вторая, переменная часть — сменные модули (или точки расширения).           

Например, архитектурный инструмент - фреймворк TOGAF, разработанный и развиваемый консорциумом The Open Group преследует следующие цели.    

- Повышение продуктивности бизнес - процессов.

-    Уменьшение затрат.

-    Улучшение операционной бизнес – деятельности.

-    Повышение эффективности управления.

- Уменьшение рисков.

- Повышение эффективности ИТ – организации.

-  Повышение продуктивности работы пользователей.

-  Повышение интероперабельности

(возможности и прозрачности взаимодействия).

-  Уменьшение стоимости поддержки жизненного цикла.

-  Улучшение характеристик безопасности.

-  Повышение управляемости.

Контекст проектирования (Context of Software Design)

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

Стандарты жизненного цикла, например, IEEE и ISO/IEC (ГОСТ Р) 12207 уделяют специальное внимание вопросам проектирования и детализируют их, описывая контекст проектирования – от требований до тестов.

 

 

1.3. Процесс проектирования (Software Design Process)            

   Проектирование в основном рассматривается как двухшаговый процесс:

·  Архитектурное проектирование – декомпозиция структуры (статическая компонента) и организации (динамическая компонента).

· Детализация архитектуры – описывает специфическое

·поведение и характеристики отдельных блоков, модулей, компонентов.

·

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

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

 

Техники применения (Enabling Techniques)

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

 

Абстракция

   В контексте проектирования программных систем существует два механизма абстракции – параметризация и специфицирование (может интерпретироваться как детализация).

  При этом, абстракция через специфицирование бывает трех видов:

- процедурная абстракция (динамическая, то есть в отношении поведения);

- абстракция данных (статическая, то есть в отношении информации);

- абстракция контроля (то есть управления системой и обрабатываемой ею информацией).

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

 

 

Связанность и соединение

    Связанность – определяет степень взаимного влияния между модулями. Соединение – обусловливает связь элементов  внутри модуля, внутреннюю связь.

    В зависимости от контекста, «связанность» и «соединение» могут рассматриваться как степень самодостаточности или функциональная зависимость, соответственно.

   Эти понятия важны, так как с развитием сервисно - ориентированной архитектуры (Service - Oriented Architecture, SOA), слабосвязанной по своей природе, все чаще приходится сравнивать различные подходы и решения. Которые, в свою очередь, определятся способом и степенью связанности различных модулей, компонентов и самих программных систем.

  Напомним, что Сервис – ориентированная архитектура (SOA, англ. service - oriented architecture) – это модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных (loose coupling) заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам.

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

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

 Этим обеспечивается комбинирование и многократное использование компонентов для построения сложных распределённых программных комплексов.

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