Диаграмма классов во время системного анализа и проектирования

Question

Может кто-нибудь объяснить мне разницу между диаграммой классов во время анализа и проектирования?

До сих пор я понимаю, что диаграмма классов проектирования была бы реальной диаграммой классов со всеми методами и атрибутами (готовыми стать кодом), но как насчет анализа? Должен ли я сделать диаграмму классов для каждой диаграммы последовательности? Нужно ли добавлять методы и атрибуты уже на стадии проектирования? Или только связь?

Answer 1

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

Обычно вы начинаете с модели предметной области, основанной на требованиях (например, варианты использования, пользовательские истории, описание работы, пользовательские интервью и т. Д.):

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

Затем вы обогатите модель более подробными схемами проектирования при разработке решения. Таким образом, вы должны добавить любые классы, необходимые для реализации (например, классы интерфейса пользователя, контроллеры приложений, уровни персистентности и т. Д.).

Схемы проектирования используются для того, чтобы получить общее представление о структуре программного обеспечения в группе разработчиков. Таким образом, они должны быть простыми для понимания (то есть сосредоточиться на важных аспектах и ​​не обязательно быть загроможденными слишком многими деталями, которые так или иначе должны были бы быть реализованы в коде и быстро устарели, если у вас нет армии аналитиков для обновления модели).

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

Answer 2

У нас есть 3 основных типа диаграмм классов в объектно-ориентированных методологиях.

1. Диаграммы классов в требовании (моделирование домена)
2. Диаграммы классов анализа
3. Диаграммы классов дизайна

Основным отличием этих диаграмм классов является их абстракция.

1. В моделировании предметной области мы используем диаграммы классов. НО, мы не используем какое-либо Наследование или какие-либо Интерфейсы или какой-либо предварительный анализ классов. Мы просто пишем так мало атрибутов классов (около 3 атрибутов). мы не пишем никаких методов классов. ЗАЧЕМ? из-за абстракции. Основной целью моделирования домена является моделирование домена. И определить, какие классы должны быть в проблемной области системы.

2. В моделировании анализа мы используем диаграмму классов. Классы в анализе более подробны, чем классы в Домене. Но это не окончательная спецификация.

В анализе мы определяем классы анализа. Мы можем использовать Наследование между ними. Мы можем написать их атрибуты и методы подробно. НО, эта фаза выполняется системными аналитиками. (Не системный дизайнер или программист). Их профессия - знание бизнес-логики и программных технологий. Таким образом, они могут написать классы анализа более подробно, чем Домен. Тем не менее, они не могут писать очень подробно, как разработчики систем.

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

Руководство Boundary/Control/Entity относительно абстракции классов находится в этой ссылке. В этом шаблоне мы должны писать только атрибуты для классов Entity и писать только методы для классов Control и писать атрибуты и методы для классов Boundary.

Однако, по моей идее, мы можем следовать руководящим принципам или нет. Мы можем написать больше атрибутов и методов для анализа классов. Что происходит? Если наш системный аналитик попытается написать более подробные атрибуты или методы, что происходит:

Я думаю, что 1) наш системный аналитик не является системным аналитиком. возможно системный дизайнер. 2) нам не нужны их детали. Это просто время для фазы анализа. 3) ТОЛЬКО если наша команда по анализу и проектированию одинакова или мы объединяем анализ и проектирование (например, Agile Methodologies), детали в Analysis могут быть логичными и полезными.

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