Проектирование программных систем — это деятельность, результат которой состоит из двух составных частей:
| Уровень | Описание |
|---|---|
| Архитектурный дизайн (макро уровень) | Описание высокоуровневой структуры и организации крупных компонентов системы. Концептуальное или эскизное проектирование. |
| Детализированная архитектура (мини уровень) | Описание каждого компонента в объеме, необходимом для реализации. |
1. Элементы проектирования
**──────────── Архитектура ────────────
Подсистема
│
Компонент
│
──────────── Граница проектирования ────────────────
Модуль
│
Класс
│
Метод
──────────── Реализация ─────────────
**
Компонент — основная единица архитектурного проектирования , а модуль — основная единица детального проектирования, которая классами
2. Декомпозиция структуры ПО
Модуль — это логически обособленная часть программного кода (файл, класс, пакет), выполняющая определенную функцию и предоставляющая четкий интерфейс для взаимодействия. Модульность оценивается двумя фундаментальными метриками:
Зацепление\связанность (Cohesion) — внутри модуля
Показывает, насколько элементы внутри одного модуля сфокусированы на выполнении единой задачи.
Связность\сцепление (Coupling) — между модулями
Показывает степень взаимозависимости модулей. Изменение в одном модуле не должно ломать другой.
Инкапсуляция реализации
Внутренние классы могут изменяться без изменения внешних клиентов
3. Принципы SOLID
На микро-уровне
Принципы SOLID
- S (Single Responsibility): Каждый класс/модуль должен иметь ровно одну причину для изменения (одну бизнес-функцию).
- O (Open/Closed): Программные сущности должны быть открыты для расширения, но закрыты для модификации.
- L (Liskov Substitution): Объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности работы программы.
- I (Interface Segregation): Много специализированных интерфейсов лучше, чем один универсальный. Клиенты не должны зависеть от методов, которые они не используют.
- D (Dependency Inversion): Зависимости должны строиться на абстракциях (интерфейсах), а не на конкретных реализациях.
Принципы GRASP (Шаблоны распределения обязанностей)
- Information Expert (Информационный эксперт): Обязанность по выполнению действия должна принадлежать тому классу, у которого есть вся необходимая информация для этого.
- Creator (Создатель): Определяет, какой класс должен создавать экземпляры другого класса.
- Controller (Контроллер): Не визуальный компонент, который отвечает за обработку системных событий от пользователя.
- Low Coupling & High Cohesion: Фундаментальные метрики (слабая связанность модулей и высокая сфокусированность задач внутри одного класса).
4. Шаблоны проектирования
Шаблон это описание хорошо проверенной, обобщенной схемы решения некоторой часто повторяющейся проблемы (задачи) разработки ПО, которая возникает в некоторых специфических условиях (контексте).
| Категория | Назначение | Классические примеры |
|---|---|---|
| Порождающие (Creational) | Изолируют систему от процесса создания объектов, делая его гибким. | Singleton (Одиночка), Factory Method (Фабричный метод), Builder (Строитель). |
| Структурные (Structural) | Отвечают за компоновку классов и объектов в более крупные и гибкие структуры. | Adapter (Адаптер), Facade (Фасад), Decorator (Декоратор). |
| Поведенческие (Behavioral) | Алгоритмы и распределение обязанностей между взаимодействующими объектами. | Observer (Наблюдатель), Strategy (Стратегия), Command (Команда). |
5. Семейства программ и фреймворки
Повторное использование кода (Software Reuse) — один из главных способов снижения стоимости и времени разработки ПО. Семейства программ и фреймворки представляют собой системные инженерные подходы к реализации массового повторного использования на макро- и микро-уровнях.
Семейство программ (или линейка продуктов) — это набор программных систем, которые разделяют общее управляемое множество архитектурных свойств, создаются из единой базы базовых активов (Core Assets) и предназначены для удовлетворения потребностей конкретной рыночной ниши или миссии.
Инженерия семейств программ строится на жестком разделении системы на две части:
- Стабильное архитектурное ядро, общее для всех программ в линейке (например, ядро операционной системы, базовые функции СУБД).
- Точки варьирования, в которых продукты семейства адаптируются под конкретного клиента или задачу (например, поддержка разных языков интерфейса, специфические драйверы, разные алгоритмы шифрования).
Двухуровневый процесс инженерии в SPL:
- Инженерия предметной области (Domain Engineering): Разработка многократно используемых компонентов, платформы, инструментов и общей архитектуры семейства («взгляд внутрь»).
- Инженерия приложений (Application Engineering): Сборка конкретного конечного продукта для заказчика на основе платформы, созданной на первом этапе, путем настройки точек изменчивости («взгляд наружу»).
Фреймворк — это полуфабрикат программной системы, представляющий собой расширяемую архитектурную основу (каркас), которую разработчик дополняет собственным кодом для создания конкретного приложения.
