Основные теоретические сведения
В настоящее время разработчики программного и информационного обеспечения информационных систем (ИС) используют объектно-ориентированный подход, в котором фундаментальными понятиями являются понятия класса и объекта.
Класс – некоторая абстракция совокупности объектов, имеющих общий набор свойств и обладающих одинаковым поведением. Классы характеризуются атрибутами (свойствами) и операциями, определяющими поведение класса. Реализация операции класса называется в UML методом класса.
Объект – экземпляр соответствующего класса с собственным именем и конкретными значениями атрибутов. Объект обладает всеми операциями класса.
Классы могут быть организованы в иерархическую структуру, напоминающую по своему виду схему классификации. Основным принципами объектно-ориентированного подхода являются наследование, инкапсуляция и полиморфизм [1 ].
Наследование - принцип, в соответствии с которым родительский класс (предок) передает все свои наборы свойств и поведение дочерним классам (потомкам).
Инкапсуляция - сокрытие деталей внутреннего устройства классов от внешних для него объектов или пользователей.
Полиморфизм (много форм) - действия, выполняемые одноимёнными методами, могут отличаться в зависимости от того, к какому из классов относится метод.
Процесс создания системы носит итеративный и инкрементный харак –
тер. Это же подчеркивают и авторы UML, определяя понятие унифицирован-
|
|
|
ного процесса разработки программного и информационного обеспечения [3]. Хотя на первой стадии формируется набор требований к ИС в целом, на самом деле он всегда вначале неполон и уточняется на последующих стадиях. Приходится делать итерации, то есть повторять отдельные этапы и стадии, либо целиком, либо частично. Кроме того, реальная система многофункциональна и сложна, поэтому обычно ее разбивают на подсистемы и отдельные комплексы задач, выделяя в них подсистемы и задачи первой очереди, второй и т.д. Система создается инкрементно, путем постепенных приращений функциональности с заменой предварительных проектных решений на более проработанные и лучше отвечающие требованиям пользователей. Это снижает финансовые риски и экономит время и расход ресурсов на последних стадиях создания.
При использовании методологии UML для создания программного и информационного обеспечения ИС предлагается построить набор взаимосвязанных моделей, отражающих статические и динамические свойства будущей системы:
· модель вариантов использования;
· модель анализа;
· модель проектирования;
· модель реализации;
· модель развертывания;
|
|
|
· модель тестирования.
Модель вариантов использования включает диаграммы вариантов использования и соответствующие сценарии, описывает функциональные требования к системе и ее поведение при взаимодействии с пользователями.
Все диаграммы языка являются графами специального вида, содержат вершины (геометрические фигуры), связанные ребрами (дугами). Связи обозначаются различными линиями на плоскости, внутри фигур пишется текст, около вершин и связей могут изображаться некоторые графические символы.
В целом процесс объектно-ориентированного проектирования происходит в соответствии с основными принципами структурного системного анализа: нисходящее проектирование с построением иерархии диаграмм, постепенно переводящих нас с уровня на уровень: концептуальный – логический – физический (реализация).
Диаграммой самого верхнего уровня является диаграмма вариантов использования системы в целом. Именно она является исходным концептуальным представлением системы и строится с целью:
· определить общие границы и контекст моделируемой предметной области;
· сформировать общие требования к функциональному поведению и
интерфейсу системы;
· подготовить исходную документацию для взаимодействия разработчиков и заказчиков - пользователей системы.
|
|
|
Точка зрения модели: внешний пользователь системы. В диаграмму вариантов использования входят актанты (actors), варианты использования (use case) и ассоциации (association).
Актант (актер, внешняя сущность, actor) - абстрактное описание класса источников/приемников сообщений, которые напрямую взаимодействуют с системой, подсистемой или классом. Это-описание роли, которую играет пользователь (человек или другая система, подсистема, класс) во время взаимодействия с системой. На самом верхнем уровне, например, актантами могут являться оператор, системный администратор, администратор базы данных, обычный пользователь, какой-либо класс устройств.
Каждая роль требует для себя вполне определенного сервиса (обслуживания).
Один человек или физический объект в зависимости от режима взаимодействия может представлять собой несколько актантов (разные роли). Например, один и тот же человек может быть оператором и администратором базы данных, продавцом и покупателем и т.п. Актант обычно изображается на диаграммах как “человек” с надписью (символ человека):
 |
Заказчик
Актант находится вне системы и его внутренняя структура не определяется. Он является источником/приемником сообщений.
|
|
|
Вариант использования (прецедент, use case) – абстрактное описание класса сервиса (сервисных функций), предоставляемого актанту в ответ на его запросы. Сервис могут предоставлять система в целом, подсистема или класс. Таким образом, вариант использования означает моделирование некоторой части функциональности или поведения системы. Вариант использования имеет имя и означает некоторую последовательность действий, видимых внешнему источнику/приемнику (актанту). Подробно этот процесс описывается сценарием, построение которого рассматривается в следующей лабораторной работе.
Связь между актантом и вариантом использования показывается ассоциацией.
На диаграмме вариант использования изображается обычно эллипсом, внутри ставится имя.
Ассоциация показывается линией:
 |
Менеджер
Между актантами и вариантами использования ассоциация – единственный вид связи. Можно ее пометить, а также указать кратность связи. Имя ассоциации, если оно есть, должно быть уникальным.
В отношении расширения вариант использования – клиент вносит дополнительную последовательность действий, начиная с некоторой точки основной последовательности, при этом таких “вставок” может быть несколько. Все эти точки называются точками расширения.
 |
Направление стрелки имеет смысл: вариант “Запросить каталог” знает, в какой точке расширения варианта “Принять заказ” он начинает выполняться (таких точек может быть несколько). Для правильного определения направления стрелки следует задать вопрос по данному варианту: «Расширяет что?». Каждая точка расширения имеет уникальное имя в рамках варианта “Принять заказ”. Имена точек расширения можно указать в специальном разделе в обозначении варианта использования.
Таким образом, все альтернативные отклонения от обычного хода протекания процесса использования системы могут быть оформлены как расширения.
В отношении включения один вариант использования включается в базовый вариант использования, начиная с точки включения. Управление безусловное, выполнение включения длится до полного его завершения. После этого продолжается выполнение базового варианта, начиная с операции, следующей за точкой включения.
В отличие от расширения, меняющего характер протекания основного процесса и не обязательно передающего ему управление, включение является часто повторяемым фрагментом, выполняющим некоторый типовой сервис. Точек включения может быть несколько, причем в разных вариантах.
Таким образом, включение выгодно использовать, когда имеется какой-либо фрагмент поведения системы, который повторяется многократно и обязательно в вариантах использования и который не хотелось бы копировать в каждом из вариантов.
Для правильного определения направления стрелки следует задать вопрос по основным вариантам: «Включают что?». Каждая точка включения имеет уникальное имя в рамках варианта использования. Имена точек включения можно указать в специальном разделе в обозначении варианта использования
Пример:
.
Третье отношение между вариантами использования – обобщение (use case generalization) в обычном смысле. Прямой предок может иметь одного или нескольких прямых потомков:
 |
Потомки наследуют все атрибуты и операции родителя. Однако, потомки могут вносить в последовательность действий родителей свою специфику: дополнительноеповедение. Вариант-потомок является частным примером родительского варианта и участвует во всех его отношениях.
Дата добавления: 2016-01-05; просмотров: 15; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!