Каково место визуального моделирования в анализе и проектировании по? Является ли диаграмма первичным и самодостаточным артефактом и почему?

Для автоматизации процессов разработки ПО используется визуальное представление различных процессов и объектов Visual modeling это способ представления идей и проблем реального мира с помощью моделей.

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

Цели визуального моделирования:

• Справиться с разработкой сложной системы. Благодаря технологии визуального моделирования становится возможным работать со сложными системами и проектами. Не имеет значения, преобладает ли в проекте техническая сложность (статическая) или сложность управления, т.е. динамическая. Сложность программных систем возрастает от версии к версии и в какой-то момент наступает эффект критической массы и дальнейшее развитие системы становится невозможным. Никто не понимает, что и как происходит.

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

• Документирование программных решений.

• Экономичная обработка нескольких программных решений. При моделировании большого программного продукта можно предполагать и рассмотреть несколько вариантов проекта и ещё до реализации выбрать оптимальный.

• Хранение, поиск, исследование и редактирование информации о больших проектах. Модели необходимы не только на этапе разработки, но и во время эксплуатации и дальнейшего развития.

Существует 2 подхода к моделированию – структурный и функциональный. Структурный основан на функциональной декомпозиции программы на данные и алгоритм (функциональные модели). Объектный – на объектной(компонентной) декомпозиции.

Методы моделирования для структурного подхода:

• функциональная модель SADT (Structured Analysis and Design Technique);

• модель IDEF3;

• DFD (Data Flow Diagrams) - диаграммы потоков данных.

Методы моделирования для объектного подхода:

-Структурные (structural) модели:

• диаграммы классов (class diagrams) - для моделирования статической структуры классов системы и связей между ними;

• диаграммы компонентов (component diagrams) - для моделирования иерархии компонентов (подсистем) системы;

• диаграммы размещения (deployment diagrams) - для моделирования физической архитектуры системы.

-Модели поведения (behavioral):

• диаграммы вариантов использования (use case diagrams) - для моделирования функциональных требований к системе (в виде сценариев взаимодействия пользователей с системой);

• диаграммы взаимодействия (interaction diagrams):

• диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams) - для моделирования процесса обмена сообщениями между объектами;

• диаграммы состояний (statechart diagrams) - для моделирования поведения объектов системы при переходе из одного состояния в другое;

• диаграммы деятельности (activity diagrams) - для моделирования поведения системы в рамках различных вариантов использования, или потоков управления.

Про артефакты – хз, что ответить, но…

Продукт – набор артефактов создаваемых в течении жизни проекта (модели, тексты программ, документация, используемые файлы).

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

Наверное, это следует знать.

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