Ссылка на файл: >>>>>> http://file-portal.ru/Use case диаграмма пример/
Вариант использования (use case)
Основы UML — диаграммы использования (use-case)
Виды диаграмм UML
Диаграммы использования были предложены Иваром Якобсоном в их нынешней графической форме еще в году. Диаграммы использования являются, безусловно, самым стабильным элементом UML — они не менялись уже двадцать лет с лишним, фактически, приняли законченную форму задолго до появления языка. Одновременно эти диаграммы имеют самую простую нотацию: Вопрос о выделении или идентификации действующих лиц при составлении модели — один из самых болезненных. Неудачный выбор действующих лиц может отрицательно повлиять на всю модель в целом. Здесь легко впасть в крайность: Оба экстремальных варианта являются, по существу, моделью черного ящика и сводят к нулю преимущества моделирования использования, рассмотренные в предыдущем разделе. Формального метода идентификации действующих лиц не существует. Здесь мы перечислим некоторые приемы, которые полезно, по нашему мнению, иметь в виду при выделении действующих лиц и покажем применение этих приемов на нашем примере информационной системы отдела кадров. Для начала укажем более детальное определение действующего лица. Для действующего лица указывается только имя, идентифицирующее его в системе. Семантически действующее лицо — это множество логически взаимосвязанных ролей. В данном случае отсылаем читателя к главе 3. С прагматической точки зрения главным является то, что действующие лица находятся вне проектируемой системы или рассматриваемой части системы. В типовых случаях различные действующие лица назначаются для категорий пользователей если их удается выделить естественным образом , внешних программных и аппаратных средств если система взаимодействует с таковыми. Рассмотрим наш пример с информационной системой отдела кадров. Про внешние программные и аппаратные средства в техническом задании ничего не сказано, и этот вопрос пока разумно оставить в стороне. Трудно представить себе организацию, в которой реорганизация внутренней структуры и процесс найма персонала выполняются автоматически, без участия человека, поэтому у нашей системы, очевидно, будут пользователи. Выделение категорий пользователей происходит, как правило, неформально: Тем не менее, несколько советов мы можем дать. Имеет смысл отнести пользователей к разным категориям, если наблюдаются следующие признаки:. Опираясь на собственные советы, применительно к нашему примеру мы в первом приближении склонны выделить две категории пользователей:. Бизнес-процесс пользователя первой категории включает в себя не только работу с приложением, но и беседы с конкретными людьми, интервью и тому подобное, чем явно отличается от других бизнес-процессов предприятия. Пользователи второй категории, очевидно, должны иметь специальные права доступа, поскольку вряд ли допустимо, чтобы кто угодно мог создавать и уничтожать подразделения на предприятии. На следующем фрагменте диаграммы использования мы начинаем формировать представление использования информационной системы отдела кадров. Менеджер персонала имеет имя Personnel Manager , а менеджер штатного расписания — Staff Manager , в соответствии с используемой дисциплиной имен. Для UML пока что нет достаточно устоявшейся дисциплины имен, но некоторый набор рекомендаций можно найти в литературе. Мы, по возможности, следуем этим рекомендациям и при случае пересказываем их. Эти правила основаны на семантике моделирования использования. Выделение вариантов использования — ключ ко всему дальнейшему моделированию. На этом этапе определяется функциональность системы, то есть, что полезного система должна делать во внешнем мире. Нотация для варианта использования очень скудная — это просто имя, помещенное в овал или помещенное под овалом — такой вариант тоже допустим. Другими словами, функции, выполняемые системой, на уровне моделирования использования никак не раскрываются — им только даются имена. Прагматика варианта использования состоит в том, что среди всех последовательностей действий, которые могут произойти при работе приложения, выделяются такие, в результате которых получается явно видимый и достаточно важный для действующего лица в частности, для пользователя результат. Сказанное для действующих лиц уместно повторить и для вариантов использования: Если в вашем распоряжении есть техническое задание, пункты которого естественным образом переводятся в варианты использования, знайте, что вам сильно повезло. Если техническое задание представляет собой смесь очевидных пожеланий пользователя, смутных утверждений и конкретных требований как обычно бывает , то попробуйте поискать в тексте отглагольные существительные и глаголы с прямым дополнением: Если у вас вовсе нет технического задания, составьте его, пользуясь исключительно простыми утверждениями. В нашем примере простой анализ текста технического задания приведенного в разделе 2. Опираясь на знание предметной области, которое не отражено в техническом задании характерный случай , заметим, что термин "вакансия" является сокращением оборота "вакантная должность", то есть должность в некотором особом состоянии. Само же слово "должность" многозначно. Это может быть и обозначение конкретного рабочего места — позиции в штатном расписании, и обозначение совокупности таких позиций, имеющих общие признаки: Кадровые работники легко различают эти случаи по контексту. Примем рабочую гипотезу о том, что автор технического задания использовал слово должность в первом смысле и получим набор вариантов использования, представленный на следующем рисунке. Третьим типом сущности, применяемым на диаграмме использования, является комментарий comment. Заметим, что комментарии являются очень важным средством UML, значение которого часто недооценивается начинающими пользователями. Комментарии можно и нужно употреблять на всех типах диаграмм, а не только на диаграммах использования. UML является унифицированным, но никак не универсальным языком — при моделировании проектировщик часто может сказать о моделируемой системе больше, чем это позволяет сделать строгая, но ограниченная нотация UML. В таких случаях наиболее подходящим средством для внесения в модель дополнительной информации является комментарий. Если пунктирная линия отсутствует, то комментарий относится ко всей диаграмме. Однако они не являются сущностью программы в том смысле, что не присутствуют в объектном коде программы после трансляции. Комментарий содержит текст, который вводит пользователь — создатель модели. Это может быть текст в произвольном формате: Более того, если возможности инструмента это позволяют, в примечаниях можно хранить гиперссылки, вложенные файлы и другие артефакты, внешние по отношению к модели. В UML последовательно проводится следующий важный принцип: Комментарии являются важнейшим примером реализации этого принципа. Комментарии могут иметь стереотипы. В UML определены два стандартных стереотипа для комментариев:. Комментарии первого стереотипа часто присутствуют на диаграммах использования, а комментарии второго стереотипа — на диаграммах классов. Возвращаясь к нашему примеру, будет совсем не лишним указать, что информацию о состоянии кадров нужно хранить постоянно, то есть она не должна исчезать после завершения сеанса работы с системой. Как уже было отмечено в первой главе, на диаграммах использования применяются следующие основные типы отношений:. Ассоциация между действующим лицом и вариантом использования показывает, что действующее лицо тем или иным способом взаимодействует предоставляет исходные данные, получает результат с вариантом использования. Другими словами, эта ассоциация обозначает, что действующее лицо так или иначе, но обязательно непосредственно участвует в выполнении каждого из сценариев, описываемых вариантом использования. Ассоциация является наиболее важным и, фактически, обязательным отношением на диаграмме использования. Действительно, если на диаграмме использования нет ассоциаций между действующими лицами и вариантами использования, то это означает, что система не взаимодействует с внешним миром. Такие системы, равно как и их модели, не имеют практического смысла. Применительно к нашему примеру в первом приближении можно обозначить ассоциации, представленные на следующей диаграмме. Обобщение между действующими лицами показывает, что одно действующее лицо наследует все свойства в частности, участие в ассоциациях другого действующего лица. Во-первых, с помощью обобщения между действующими лицами легко показать иерархию категорий пользователей системы, в частности, иерархию прав доступа к выполняемым функциям и хранимым данным. Во-вторых, действующее лицо, будучи классификатором, может быть абстрактным классификатором, то есть таким классификатором, который не может иметь непосредственных экземпляров. Введение абстрактных действующих лиц позволяет без потери информации сократить количество непосредственных ассоциаций в модели, сделав ее более лаконичной, а значит более наглядной и полезной. Если мы проектируем систему отдела кадров для обычной организации, а не для государственной секретной службы, то разумно предположить, что просматривать данные могут все категории пользователей. Обобщение между вариантами использования показывает, что один вариант использования является частным случаем подмножеством множества сценариев другого варианта использования. Обобщающий вариант использования, будучи классификатором, может быть абстрактным классификатором. Например, такой важный для сотрудника вариант использования, как увольнение, на самом деле является абстракцией: Данное обстоятельство можно отразить в модели так, как показано на следующем фрагменте диаграммы. Обобщенный абстрактный имя написано курсивом вариант использования Fire Person имеет две специализации, которые соответствуют увольнению работника по собственному желанию Self Fire и по инициативе администрации Adm Fire. Зависимость между вариантами использования показывает, что один вариант использования зависит от другого варианта использования. В UML имеются два стандартных стереотипа зависимости между вариантами использования, которые в некотором смысле двойственны друг другу:. Нам будет удобнее объяснить тонкости семантики этих отношений в параграфе 2. Итак, нам известно, что при увольнении сотрудника следует в целях информационной безопасности заблокировать или удалить учетную запись пользователя в локальной сети организации. Причем это действие должны быть выполнено в любом сценарии увольнения. С другой стороны, как сказано в техническом задании, при выполнении определенных условий, при увольнении иногда выплачивается некоторая денежная компенсация за неиспользованный отпуск, выходное пособие при сокращении и т. Все это примеры последовательностей действий то есть вариантов использования , которые вполне могут быть востребованы как при увольнении, так и помимо него. Отношения зависимости между этими вариантами использования могут быть показаны на диаграмме использования, например, так, как это сделано ниже. Последний пример можно отобразить еще компактнее, комбинируя возможности отношений обобщения и зависимости, подобно тому, как скомбинированы возможности отношений обобщения и ассоциации на рис. Если посмотреть на модель использования с самой общей точки зрения, то нетрудно заметить, что в модели присутствуют:. Обычно совершенно ясно, что находится внутри моделируемой системы, а что снаружи. Если это почему-либо неясно, или же требуется увеличить наглядность диаграмм, то можно воспользоваться специальной конструкцией, которая называется "границы системы". Границы системы system boundary — это графический комментарий в форме прямоугольной рамки, применяемый на диаграммах использования и отделяющий внутреннюю часть системы от ее внешнего окружения. Субъект subject — это классификатор, который реализует поведение, декларируемое вариантами использования. Если границы системы используются на диаграмме, то можно указать имя и стереотип! На следующей диаграмме мы построили пример аналогичный представленному на рис. Ассоциации между действующими лицами и вариантами использования , но использовали другие возможности нотации UML. В приведенных примерах действующими лицами являются категории пользователей. Это не случайно, в большинстве случаев действующими лицами в моделях UML действительно являются категории пользователей. Но оборот "в большинстве случаев" еще не означает "всегда". В самом деле, в определениях действующего лица параграф 2. Так вот, в качестве системы может выступать любая сущность, для которой можно определить функциональные или не функциональные требования. Это может быть и подсистема главной системы, отдельный компонент и просто класс. Если мы рассматриваем модель использования некоторой подсистемы, то другие подсистемы взаимодействующие с рассматриваемой будут действующими лицами для рассматриваемой подсистемы. Если мы рассматриваем модель использования некоторого класса, то другие классы взаимодействующие с рассматриваемым будут действующими лицами для рассматриваемого класса. Рассмотрим пример, связанный с взаимодействием нашей информационной системы отдела кадров с внешним программным окружением. Было бы самонадеянно считать, что проектируемая информационная система отдела кадров является первой и единственной программой, которая эксплуатируется на предприятии. Скорее всего, таких программ сотни, и с десятком из них должна взаимодействовать проектируемая система отдела кадров. Заранее все предусмотреть очень трудно. Поэтому удовлетворить новое требование проще всего следующим образом. Предусмотреть в информационной системе отдела кадров интерфейс для доступа к данным и каждый раз, когда потребуется предоставить конкретный API для нового клиента, реализовывать новый модуль, который адаптирует имеющийся интерфейс информационной системы к требуемому. Значение моделирования использования 2. Диаграммы использования Диаграммы использования были предложены Иваром Якобсоном в их нынешней графической форме еще в году. Действующие лица Вопрос о выделении или идентификации действующих лиц при составлении модели — один из самых болезненных. Действующие лица ИС ОК. Варианты использования Выделение вариантов использования — ключ ко всему дальнейшему моделированию. Каждая конкретная последовательность действий называется сценарием scenario. Варианты использования ИС ОК. Комментарии Третьим типом сущности, применяемым на диаграмме использования, является комментарий comment. Нефункциональное требование к ИС ОК. Отношения на диаграммах использования Как уже было отмечено в первой главе, на диаграммах использования применяются следующие основные типы отношений: Ассоциации между действующими лицами и вариантами использования. Иерархия категорий пользователей ИС ОК. Зависимости между вариантами использования. Комбинация отношений обобщения и зависимости. Способы применения моделей использования Если посмотреть на модель использования с самой общей точки зрения, то нетрудно заметить, что в модели присутствуют: Программные системы в качестве действующих лиц.
Приснилась мышка маленькая сонник
Заявление о регистрации по месту пребывания
Цивилизация как гибель культуры
Примеры USE CASE и их реализация
Инструкция шкафа электрического
Воспитатель детского сада новые правила
Молитва александру невскому текст на русском
ГЛАВА 4 Диаграмма вариантов использования (use case diagram)
Дизайн старого комода своими руками
Бланки почтового перевода
ГЛАВА 4 Диаграмма вариантов использования (use case diagram)
Указанные в таблице являются
Задний мост мтз каталог
Условное форматирование сводной таблицы excel
Примеры USE CASE и их реализация
7 приказ минтранса рф 05.06 2014