Лабораторная работа № 1 Построение модели вариантов использования
Цель работы: Выполнение начального этапа разработки системы – анализ требований, предъявляемых к системе; общее знакомство с инструментальной средой Rational Rose 2003; построение функциональной модели системы и написание сценариев взаимодействия пользователей с системой.
Основные теоретические сведения
В настоящее время разработчики программного и информационного обеспечения автоматизированных систем (АС) используют объектно-ориентированный подход, в котором фундаментальными понятиями являются понятия класса и объекта.
Класс– некоторая абстракция совокупности объектов, имеющих общий набор свойств и обладающих одинаковым поведением.
Классы характеризуются атрибутами (свойствами) и операциями, определяющими поведение класса. Реализация операции класса называется в UMLметодом класса.
Объект– экземпляр соответствующего класса с собственным именем и конкретными значениями атрибутов. Объект обладает всеми операциями класса.
Класс образуется операцией обобщения, каждый объект является (ISA) частным примером своего класса. Классы могут быть организованы в иерархическую структуру, напоминающую по своему виду схему классификации. Среди классов может быть выделен самый общий (верхний) класс самого высокого уровня абстракции, например, система, сущность, связь, событие и т.д.
Основным принципами объектно-ориентированного подхода являются наследование, инкапсуляция и полиморфизм.
Наследование - принцип, в соответствии с которым родительский класс (предок) передает все свои наборы свойств и поведение дочерним классам (потомкам). Дочерние классы называютсяпроизводными классами (рис.1), они добавляют к наследуемым свои специфические свойства и операции.
Рис.1. Иерархия классов, полученная операцией обобщения
Инкапсуляция - сокрытие деталей внутреннего устройства классов от внешних для него объектов или пользователей.Полиморфизм(много форм) - действия, выполняемые одноимёнными методами, могут отличаться в зависимости от того, к какому из классов относится метод.
Использование объектов заранее подготовленных библиотечных классов с определёнными свойствами и методами позволило решить многие кризисные вопросы создания программного и информационного обеспечения сложных АС.
Процесс создания системы носит итеративный и инкрементный характер. Это же подчеркивают авторы UML, определяя понятие унифицированного процесса разработки программного и информационного обеспечения [ ]. Хотя на первой стадии формируется набор требований к АС в целом, на самом деле он всегда в начале неполон и уточняется на последующих стадиях. Приходится делать итерации, то есть повторять отдельные этапы и стадии, либо целиком, либо частично. Кроме того, реальная система многофункциональна и сложна, поэтому обычно ее разбивают на подсистемы и отдельные комплексы задач, выделяя в них подсистемы и задачи первой очереди, второй и т.д. Система создается инкрементно, путем постепенных приращений функциональности с заменой предварительных проектных решений на более проработанные и лучше отвечающие требованиям пользователей. Это снижает финансовые риски и экономит время и расход ресурсов на последних стадиях создания.
При использовании методологии UML для создания программного и информационного обеспечения АИС предлагается построить набор взаимосвязанных моделей , отражающих статические и динамические свойства будущей системы:
модель вариантов использования;
модель анализа ;
модель проектирования;
модель реализации;
модель развертывания;
модель тестирования.
Модель вариантов использования включает диаграммы вариантов использования и соответствующие сценарии, описывает функциональные требования к системе и ее поведение при взаимодействии с пользователями.
Модель анализа включает диаграммы обобщенных классов реализации вариантов использования на логическом уровне, соответствующие диаграммы последовательностей и/или диаграммы кооперации и является эскизной проработкой того, как будут реализованы варианты использования на логическом уровне.
Модель проектирования является детальным представлением физической реализации модели анализа и включает диаграммы пакетов (подсистем), детальные диаграммы классов, диаграммы последовательности и/или диаграммы кооперации, диаграммы состояний, диаграммы деятельности различной степени детализации.
Модель реализации описывает, как реализуются в виде компонентов классы проектирования. Соответственно она включает диаграммы компонентов, трассировки (реализации) классов, описание архитектуры системы.
Модель развёртывания включает диаграммы развёртывания, определяющие все конфигурации сетей, на которых может выполняться система. На диаграммах развёртывания указываются узлы сети, типы соединений, распределение активных классов и компонентов системы по узлам.
Модель тестирования содержит набор тестовых примеров, процедур тестирования и описания тестовых компонент. Она задаёт способы тестирования исполняемых компонентов системы.
Наиболее общей концептуальной моделью системы является диаграмма вариантов использования, она является исходной для построения остальных диаграмм.
Все диаграммы языка являются графами специального вида, содержат вершины (геометрические фигуры), связанные ребрами (дугами). Связи обозначаются различными линиями на плоскости, внутри фигур пишется текст, около вершин и связей могут изображаться некоторые графические символы. В расширениях UMLдопускаются пространственные диаграммы.
В языке имеется 4 вида графических конструкций:
значки (пиктограммы);
графические символы на плоскости;
пути (линии);
строки текста.
В целом процесс объектно-ориентированного проектирования происходит в соответствии с основными принципами структурного системного анализа: нисходящее проектирование с построением иерархии диаграмм, постепенно переводящих нас с уровня на уровень: концептуальный – логический – физический (реализация)
Диаграммой самого верхнего уровня является диаграмма вариантов использованиясистемы в целом. Именно она является исходным концептуальным представлением системы и строится с целью:
определить общие границы и контекст моделируемой предметной области;
сформировать общие требования к функциональному поведению и интерфейсу системы;
подготовить исходную документацию для взаимодействия разработчиков и заказчиков - пользователей системы.
Точка зрения модели: внешний пользователь системы. В диаграмму вариантов использования входят актанты (actors), варианты использования (usecase) и ассоциации (association).
Актант(актер, внешняя сущность,actor) - абстрактное описание класса источников/приемников сообщений, которые напрямую взаимодействует с системой, подсистемой или классом. Это-описаниероли, которую играет пользователь (человек или другая система, подсистема, класс) во время взаимодействия с системой. На самом верхнем уровне, например, актантами могут являться оператор, системный администратор, администратор базы данных, обычный пользователь, какой-либо класс устройств.
Каждая роль требует для себя вполне определенного сервиса (обслуживания).
Все возможные актанты исчерпывают все возможные пути взаимодействия пользователя с системой (подсистемой, классом). При реализации системы актанты воплощаются в людях и физических объектах. Один человек или физический объект в зависимости от режима взаимодействия может представлять собой несколько актантов (разные роли). Например, один и тот же человек может быть оператором и администратором базы данных, продавцом и покупателем и т.п.
Во многих АС нет никаких других актантов, кроме людей. Однако, актантами могут быть внешняя система, устройство ввода/вывода или таймер (обычно это встречается во встроенных системах реального времени). На логическом и физическом уровнях актанты представляются классами и объектами-экземплярами классов. Актант может изображаться на диаграммах двумя способами:
Символ класса (прямоугольник) с внутренним указанием стереотипа