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

В системном дизайне понимание разницы между классами проектирования (design classes) и классами анализа (analysis classes) носит ключевой характер. Классы анализа подобны детективу — они исследуют и понимают проблему. Они сфокусированы на том, что система должна делать, без погружения в то, как именно это должно быть реализовано. Эти классы помогают разработчикам понять требования к программе и ее цели. В то время как классы проектирования подобно архитектору берут результаты изысканий классов анализа и создают план, как именно система будет работать.

Что такое классы проектирования?

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

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

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

Характеристики классов проектирования

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

Применение классов проектирования

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

Что такое классы анализа?

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

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

Характеристики классов анализа

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

Использование классов анализа

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

Отношения между классами анализа и проектирования

1. Взаимозависимость

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

2. Итеративность

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

Переход от классов анализа к классам проектирования

Шаг 1. От анализа к проектированию

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

Шаг 2. Создание классов проектирования

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

Шаг 3. Уточнения и итерация

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

Примеры из практики классов анализа и проектирования

1. Классы анализа

Система электронной коммерции (интернет-магазин):

Юз-кейс: Определим классы анализа такие как «Customer», «Product», «Order» и «Payment» чтобы понять, какими сущностями мы располагаем и какие отношения между ними вовлечены в систему магазина.
Цель: Проанализировать требования пользователей и бизнес‑процессов, чтобы определить какие функции система должна поддерживать и как они будут взаимодействовать между собой.
Например: класс «Customer» может иметь атрибуты, такие как имя, адрес электронной почты и почтовый адрес, тогда как класс «Order» может иметь атрибуты номер заказа, товары и общая цена.

Система управления больницей:

Юз‑кейс: Определим классы анализа такие как «Patient», «Doctor», «Appointment» и «MedicalRecord» чтобы зафиксировать основные сущности в системе.
Цель: Проанализируем потоки пациентов, докторов и администраторов чтобы определить требования к составлению расписания, управлению записями в медицинских карточках и координации медицинской помощи.
Например: класс «Appointment» может включать в себя такие атрибуты как дата и время приема, идентификатор доктора и пациента, отражающие процессы составления расписания приемов.

2. Классы проектирования

Система электронной коммерции (интернет-магазин):

Юз-кейс: Переводим классы анализа в классы проектирования чтобы уточнить, как система должны быть реализована.
Цель: Определить внутреннюю структуру и поведение компонентов приложения, чтобы удовлетворить требованиям, определенным на этапе анализа.
Например: Классы проектирования могут включать в себя «CustomerManager», «ProductCatalog», «OrderProcessor» и «PaymentGateway», каждый отвечает за определенный функционал и взаимодействие внутри системы.

Система управления больницей:

Юз‑кейс: Разработаем классы проектирования такие как «AppointmentScheduler», «PatientRecordManager,» «DoctorRegistry», и «BillingSystem» чтобы уточнить реализацию компонентов системы.
Цель: Уточнить алгоритмы, структуры данных и интерфейсы чтобы поддержать функции системы, требуемые ТЗ.
Примеры: Класс «AppointmentScheduler» может включать в себя методы для записи, отмены и переноса приема с алгоритмами по оптимизации свободных слотов и предотвращению накладок в расписании.

Разница между классами проектирования и классами анализа

Аспект	Классы анализа	Классы проектирования
Назначение	Определить требования и понять проблематику предметной области	Определить как система будет построена и управляться
Фокус	Что система должна мочь делать (функциональные требования)	Как система будет выполнять свои задачи (детали реализации)
Уровень детализации	Поверхностный уровень, фокус на сущностях, атрибутах и взаимоотношениях	Детальный уровень, специфицируют методы, атрибуты и взаимодействие
Реализация	Без деталей реализации, абстрактное представление	Уточнение деталей реализации, конкретное представление
Зависимости	Зависит от требований пользователей, бизнес-процессов и внешних систем	Строится на основе классов анализа, переводя требования в структурированный план
Получаем на выходе	Примеры применения, пользовательские истории, модели предметной области	Диаграммы классов, диаграммы последовательностей, паттерны проектирования
Очередность	Ранняя стадия разработки системы, до проектирования	Следует за стадией анализа, до реализации
Гибкость	Более гибки и могут меняться в процессе анализа	Менее гибки, изменения могут потребовать больше усилий в процессе проектирования

Классы проектирования против классов анализа