Проектирование программных систем — это деятельность, результат которой состоит из двух составных частей:
| Уровень | Описание |
|---|---|
| Архитектурный дизайн (макро уровень) | Описание высокоуровневой структуры и организации крупных компонентов системы. Концептуальное или эскизное проектирование. |
| Детализированная архитектура (мини уровень) | Описание каждого компонента в объеме, необходимом для реализации. |
1. Элементы проектирования
**──────────── Архитектура ────────────
Подсистема
│
Компонент
│
──────────── Граница проектирования ────────────────
Модуль
│
Класс
│
Метод
──────────── Реализация ─────────────
**
Компонент — основная единица архитектурного проектирования , а модуль — основная единица детального проектирования
Инженерная задача
Дана архитектура системы. Для каждого компонента:
- определить его внутреннюю структуру;
- выделить модули;
- определить классы;
- определить интерфейсы;
- определить взаимодействия.
Артефакт
Design Model
Component
↓
Module
↓
Class
↓
Method
2. Декомпозиция структуры ПО
Декомпозиция — это не разбиение кода на файлы, а распределение ответственности между независимыми частями системы.
Модуль — это логически обособленная часть программного кода (файл, класс, пакет), выполняющая определенную функцию и предоставляющая четкий интерфейс для взаимодействия. Модульность оценивается двумя фундаментальными метриками:
Зацепление\связанность (Cohesion) показывает, насколько элементы внутри одного модуля сфокусированы на выполнении единой задачи.
Связность\сцепление (Coupling) показывает степень взаимозависимости модулей. Изменение в одном модуле не должно ломать другой.
ВНУТРИ МЕЖДУ
COHESION COUPLING
↑ ↓
высокая лучше низкая лучше
Инкапсуляция реализации
внутренние классы могут изменяться без изменения внешних клиентов
Инженерная задача
Разделите заданную систему на модули так, чтобы изменение одного модуля минимально затрагивало остальные.
Артефакт
Диаграмма декомпозиции модулей
3. Принципы SOLID
SOLID — не набор правил оформления классов, а критерии оценки устойчивости проектных решений к изменениям.
| Принцип | Вопрос проектировщика |
|---|---|
| SRP | Сколько причин для изменения у класса? |
| OCP | Нужно ли изменять существующий код при добавлении поведения? |
| LSP | Можно ли заменить реализацию без нарушения контракта? |
| ISP | Не заставляем ли клиента зависеть от ненужных методов? |
| DIP | Зависит ли код от абстракции или конкретной реализации? |
Инженерная задача
Дан «плохой» класс:
OrderManager
├── calculatePrice()
├── saveToDatabase()
├── sendEmail()
├── generatePDF()
└── validateUser()
Разделить его на несколько классов.
Артефакт
UML диаграмма классов
Принципы GRASP (Шаблоны распределения обязанностей)
- Information Expert (Информационный эксперт): Обязанность по выполнению действия должна принадлежать тому классу, у которого есть вся необходимая информация для этого.
- Creator (Создатель): Определяет, какой класс должен создавать экземпляры другого класса.
- Controller (Контроллер): Не визуальный компонент, который отвечает за обработку системных событий от пользователя.
- Low Coupling & High Cohesion: Фундаментальные метрики (слабая связанность модулей и высокая сфокусированность задач внутри одного класса).
4. Шаблоны проектирования
Шаблон это описание хорошо проверенной, обобщенной схемы решения некоторой часто повторяющейся проблемы (задачи) разработки ПО, которая возникает в некоторых специфических условиях (контексте).
| Категория | Назначение | Классические примеры |
|---|---|---|
| Порождающие (Creational) | Изолируют систему от процесса создания объектов, делая его гибким. | Singleton (Одиночка), Factory Method (Фабричный метод), Builder (Строитель). |
| Структурные (Structural) | Отвечают за компоновку классов и объектов в более крупные и гибкие структуры. | Adapter (Адаптер), Facade (Фасад), Decorator (Декоратор). |
| Поведенческие (Behavioral) | Алгоритмы и распределение обязанностей между взаимодействующими объектами. | Observer (Наблюдатель), Strategy (Стратегия), Command (Команда). |
Инженерная задача
Дана проблема:
алгоритм расчета должен изменяться независимо от класса, который его использует.
- определить проектную проблему;
- найти несколько вариантов решения;
- выбрать паттерн;
- построить диаграмму;
- объяснить последствия.
Артефакт
Проект, основанный на паттерне
Например:
Context
↓
Problem
↓
Alternative solutions
↓
Pattern
↓
Design
5. Семейства программ и фреймворки
Повторное использование кода (Software Reuse) — один из главных способов снижения стоимости и времени разработки ПО. Семейства программ и фреймворки представляют собой системные инженерные подходы к реализации массового повторного использования на макро- и микро-уровнях.
Семейство программ (или линейка продуктов) — это набор программных систем, которые разделяют общее управляемое множество архитектурных свойств, создаются из единой базы базовых активов (Core Assets) и предназначены для удовлетворения потребностей конкретной рыночной ниши или миссии.
Инженерия семейств программ строится на жестком разделении системы на две части:
- Стабильное архитектурное ядро, общее для всех программ в линейке (например, ядро операционной системы, базовые функции СУБД).
- Точки варьирования, в которых продукты семейства адаптируются под конкретного клиента или задачу (например, поддержка разных языков интерфейса, специфические драйверы, разные алгоритмы шифрования).
Двухуровневый процесс инженерии в SPL:
- Инженерия предметной области (Domain Engineering): Разработка многократно используемых компонентов, платформы, инструментов и общей архитектуры семейства («взгляд внутрь»).
- Инженерия приложений (Application Engineering): Сборка конкретного конечного продукта для заказчика на основе платформы, созданной на первом этапе, путем настройки точек изменчивости («взгляд наружу»).
Фреймворк — это полуфабрикат программной системы, представляющий собой расширяемую архитектурную основу (каркас), которую разработчик дополняет собственным кодом для создания конкретного приложения.
Инженерная задача
Дана задача:
Выберите между самостоятельной реализацией, библиотекой и фреймворком.
Обосновать выбор.