Применение аналитических и проектных методов
Этот материал поясняет концепцию анализа и проектирования, включая контрольные вопросы, ключевые компоненты и теги.
In a Nutshell
Анализ структурирует задачу с предметной точки зрения и определяет границы области. Проектирование преобразует результаты в техническое решение с четкими ответственностями, интерфейсами и критериями качества.
Краткое описание
Анализ
Цель: однозначность, тестируемость, определение границ системы.
Типичные артефакты:
- Описания прецедентов
- UML-диаграммы
- Глоссарий
- Критерии приемки
Проектирование
Цель: жизнеспособная архитектура и процессы.
- Структурные модели: диаграмма классов
- Поведенческие модели: диаграммы последовательности, активности, состояния
- Уточнение: пред- и постусловия, при необходимости OCL
Принципы и эвристики:
- GRASP (например, Controller, Creator, Low Coupling, High Cohesion)
- SOLID (SRP, OCP, LSP, ISP, DIP)
Атрибуты качества (Security, Performance, надежность) фиксируются как нефункциональные требования и решаются через архитектурные тактики.
Контрольные моменты
- Анализ = “Что?”, Проектирование = “Как?”
- Критерии приемки формулировать измеримо
- Структуру и поведение моделировать отдельно
- GRASP: распределить ответственности осмысленно
- SOLID: продемонстрировать (значимо для IHK)
- Требования к качеству как сценарии
- Трассируемость: требование → модель → тест
- Версионирование + утверждения
Ключевые компоненты
- Сбор требований
- Структурная модель (диаграмма классов)
- Поведенческая модель (последовательность/активность)
- Модель состояний (жизненный цикл)
- Уточнение (пред-/постусловия/OCL)
- Принципы проектирования (SOLID)
- Ответственности (GRASP)
- Паттерны (Patterns/архитектурные паттерны)
- QA (обзоры, прототипы, TDD)
- Трассируемость
Практический пример (онлайн-магазин: заказ)
Анализ:
- Актор: Клиент
- Прецедент: "Оформить заказ"
- Критерий приемки: Платеж авторизован -> Заказ создан
Проектирование (фрагмент):
- Классы: Order, Cart, Payment
- Сервис: OrderService
- Адаптер: PaymentServiceAdapter
- Хранилище: OrderRepository
Процесс:
- Вычислить сумму
- Авторизовать платеж
- Сохранить заказ
- Отправить подтверждение
Достоинства и недостатки
Достоинства
- Лучшая коммуникация
- Выше тестируемость
- Меньше рисков изменений
Недостатки
- Начальные затраты
- Риск избыточного моделирования
- Требует дисциплины при ведении и версионировании
Типичные контрольные вопросы (с кратким ответом)
- Анализ против проектирования? Анализ описывает что, проектирование конкретизирует как.
- Зачем GRASP? Распределить ответственности осмысленно.
- Зачем SOLID? Улучшить поддерживаемость и тестируемость.
- Как обеспечить консистентность между прецедентом и моделями? Сообщения в диаграмме последовательности соответствуют операциям в диаграмме классов.
Стратегия обучения
- Написать прецедент и критерии приемки.
- Диаграмма последовательности для основного сценария.
- Распределить ответственности (GRASP).
- Проверка SOLID + модульные тесты.
Далее в пути обучения SOLID
Все статьи SOLID теперь завершены. Вернитесь к первой статье: Clean Code и SOLID-принципы.