Диаграммы анализа и проектирования
Диаграмма в UML – это графическое представление набора элементов, изображаемое в виде связанного графа с вершинами (сущностями) и ребрами (отношениями), используемое для визуализации системы с разных точек зрения. В UML выделяют 8 типов диаграмм (рис. 19). 29 Рис. 19
На диаграмме классов (Class diagram) изображаются классы, интерфейсы, объекты и кооперации, а также их отношения. Используется при моделировании объектно-ориентированных систем.
На диаграмме вариантов использования (Use case diagram) представлены прецеденты и актеры (частный случай классов), а также отношения между ними. Они используются при моделировании поведения системы.
Диаграммы последовательностей (Sequence diagram) и кооперации (Collaboration diagram) являются частными случаями диаграмм взаимодействия. На диаграммах взаимодействия представлены связи между объектами (сообщения, которыми объекты могут обмениваться). Диаграммы взаимодействия относятся к динамическому виду системы. При этом диаграммы последовательности отражают временную упорядоченность сообщений, а диаграммы кооперации – структурную организацию обменивающихся сообщениями объектов. Эти диаграммы могут быть преобразованы друг в друга.
На диаграммах состояний (Statechart diagrams) представлен автомат, включающий состояния, переходы, события и виды действий. Диаграммы состояний используются при моделировании поведения интерфейса, класса или кооперации, зависящем от последовательности событий.
Диаграмма деятельности (Activity diagram) представляют переходы потока управления между объектами от одной деятельности к другой внутри системы.
Диаграмма компонентов (Component diagram) представляет зависимости между компонентами. Диаграммы компонентов отображаются на один или несколько классов, интерфейсов или коопераций.
На диаграмме развертывания (Deployment diagram) представлена конфигурация обрабатывающих узлов системы и размещенных в них компонентов
35. Основные задачи анализа. Функциональные и нефункциональные требования.
Цель анализа требований в проектах — получить максимум информации о заказчике и специфике его задач, уточнить рамки проекта, оценить возможные риски, а также сформировать проектную группу, на которую будет возложена значительная часть предстоящих работ.
Цель процесса анализа и проектирования состоит в разработке технических инструкций, предписывающих, как реализовать ПС, удовлетворяющую сформулированным требованиям. Для этого следует хорошо понять требования к ПС и преобразовать их в проект системы, выбрав правильную стратегию реализации. На ранних стадиях процесса должна быть создана устойчивая архитектура, на основе которой можно спроектировать ПС, легкую для понимания, построения и развертывания. Архитектура должна быть согласована со средой реализации с целью удовлетворения требований к производительности, устойчивости, безопасности, расширяемости и тестируемости.
К числу решаемых задач при этом относятся:
· разработка точной архитектуры распределенной программной системы;
· преобразование модели требований в модель проектную разрабатываемой системы;
· адаптация проекта системы к среде реализации с целью повышения производительности разработки;
· выбор механизмов реализации и определение ограничений на реализацию;
· разработка компонентной структуры;
· распределение компонентов по узлам.
Главной задачей анализа является преобразование требований в форму, понятную разработчику, то есть, определение подсистем, компонентов и классов, с помощью которых реализуется требуемое поведение ПС. В основе такого преобразования лежат ВИ, созданные при определении требований к ПС. При этом рассматриваются только функциональные требования и игнорируются нефункциональные.
Каждая система имеет свои функциональные и нефункциональные требования.
Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. Бизнес-требования формулируют в документе об образе и границах проекта — уставе проекта (project charter), или документом рыночных требований (market requirements document). Определение границ проекта представляет собой первый этап управление общими проблемами расползания границ.
Требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.
Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда именуемые требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Термином системные требования (system requirements) обозначают высокоуровневые требования к продукту, которые содержат многие подсистемы, то есть система (IEEE, 1998с). Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространяться и на людей.
Бизнес-правила (business rules) включают корпоративные политики,правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес-правила не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Однако они часто налагают ограничения, определяя, кто может выполнять конкретные варианты использования, или диктовать, какими функциями должна обладать система, подчиняющаяся соответствующим правилам. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности. Следовательно, вы можете отследить происхождение конкретных функциональных требований вплоть до соответсвующих им бизнес-правил.
Нефункциональные требования содержат цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся легкость и простота использования, легкость перемещения, целостность, эффективность и устойчивость к сбоям. Другие нефункциональные требования описывают внешние взаимодействия между системой и внешним миром, а также ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта.
Отличия пользовательских и функциональных требований проявляются уже на этапе их выявления. Пользовательские требования (User Requirements) соответствуют конструкции:
<действующее лицо> должно делать <действие>
Системные и/или функциональные требования (System Requirements &/or Functional Requirements) соответствуют конструкции:
<система> должна делать <действие>
Пользовательские требования описывают более общие сервисы с точки зрения самих пользователей, а функциональные требования или функции – это их конкретная реализация, рассматриваемая со стороны архитектуры системы.
Пользовательские требования должны быть очевидны и понятны пользователям, а функции системы зачастую скрыты от них. Функциональные требования используют разработчики, которые в процессе проектирования на каждую функцию создают соответствующую архитектуру, а затем, на этапе кодирования, реализуют её в программном коде.
В приведенной выше классификации (рис. 1) К. Вигерс предлагает создавать спецификацию и, соответственно, модель вариантов использования на основе пользовательских требований. Данный подход является классическим, но обладает своими недостатками. Часто такие варианты использования оказываются слишком абстрактными и с трудом могут быть использованы для дальнейшего проектирования архитектуры системы.
Другой подход – создавать модель вариантов использования на основе функциональных требований. При этом отдельные функции системы следует объединять в более общие функциональные сервисы, которые инициируются непосредственно пользователями. Проектировать архитектуру, реализующую конкретную функциональность проще чем ту, которая реализует более абстрактные пользовательские требования, однако, при таком подходе возникают другие крайности – излишняя детализация и скатывание к функциональной декомпозиции, а также сложность выявления функций системы могут свести на нет все его преимущества.
