23. Диаграммы языка uml.

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

UML включает девять видов диаграмм:

диаграммы классов, диаграммы объектов,

диаграммы вариантов использования (прецедентов), диаграммы последовательности,

диаграммы сотрудничества (кооперации),

диаграммы состояний, диаграммы деятельности, диаграммы компонентов,

диаграммы развертывания (размещения).

Диаграмма классов представляет набор классов, интерфейсов, сотрудничеств и их отношений. При моделировании объектно-ориентированных систем диаграммы классов используются наиболее часто.

Диаграмма объектов состоит из набора объектов и их отношения и представляет статический «моментальный снимок» с экземпляров предметов, находящихся в диаграмме классов.

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

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

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

Диаграмма компонентов, обеспечивающая статическое представление реализации системы, определяет структуру (организацию) набора компонентов и зависимости между ними.

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

24. Анализ требований в проектировании кис

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

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

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

объем и состав требований заказчика, предъявляемый разработчикам в проблемной области; каким образом (посредство каких решений) разработчики собираются реализовать вышеупомянутые требования. Это будет небольшой список, называемый функциями создаваемой системы, и определяемый как обслуживание, которое осуществляет система для удовлетворения потребностей заинтересованных лиц. Функции системы занимают следующий уровень пирамиды анализа потребности. После установления набора функций, согласованного с клиентом, следует шаг для определения более конкретизированных требований, которыми являются требования к программному обеспечению. Требования к программному обеспечению в пирамиде расположатся ниже функций системы.

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