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