Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Моделирование требований к системе

Моделирование контекста системы.

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

Моделирование контекста системы состоит из следующих шагов:

1. Опре6деляются окружающие систему актеры. Для этого нужно найти

2. Похожие актеры моделируются с помощью отношений обобщения/специализации.

3. Если необходимо уточнить роль актера для них определяются стереотипы.

4. Актеры помещаются на диаграмму прецедентов и определяются способы их связи с прецедентами системы.

Требование (Requirement) - это особенность проекта, свойство или поведение системы. При описании требований, мы как описываем условия контракта, заключаемого между системой и сущностями вне нее, в котором декларируется, что система должна делать, какие процессы обработки информации будут выполнятся. При анализе системы понимание того, как она себя ведет, имеет принципиальное значение для ее правильного использования.

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

Моделирование требований к системе производится следующим образом:

1. Установите контекст системы, идентифицировав, окружающих ее актеров.

2. Для каждого актера рассматривается поведение, которого он ожидает или требует от системы.

3. Варианты поведения определяются как прецеденты.

4. Общее поведение выделяется в новые прецеденты, которые будут использоваться другими как дополняющие или расширяющие прецеденты.

5. На базе определенных прецедентов, актеров и отношениях между ними разрабатывается диаграмма прецедентов.

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

 

Отношения, используемые в диаграммах прецедентов.

В ДП используются отношения зависимости, обобщения и ассоциации.

Отношение ассоциации

Отношение ассоциации моделирует взаимодействие между Актером и Вариантом использования. Изображается сплошной линией – двунаправленная ассоциация или либо линией со стрелкой - однонаправленная ассоциация. Может иметь имя и кратность. Кратность показывает количество объектов сущности, которое участвует в конкретной связи. Кратность изображается обычно конкретным числом или 0..*, которое обозначает 0 или более объектов.

Например:

В приведенной модели показано, что каждый экземпляр ВИ связан только с одним экземпляром актера. Это означает, что конкретный клиент банка может оформить несколько кредитов но ему также могут отказать в кредите.

По умолчанию кратность равна 1.

Отношение зависимости.

В диаграммах прецедентов используются 2 стереотипа отношения зависимости: расширение и включение.

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

Например:

При оформлении заказа проверяется условие «нужен ли клиенту каталог?» и ели оно истинно то выполняются действия по предоставлению каталога, если нет, то каталог не предоставляется. Отношение расширения направлено от расширяющего прецедента к основному и помечается как стереотип «extend»

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

Например:

При оформлении каждого заказа выполняются действия по выписки счета на оплату товара, эти действия выделены как стандартные в отдельный прецедент, который дополняет основной. Отношение включения направлено от основного прецедента к дополняющему и помечается как стереотип «include».

Отношение обобщения(специализации).

Применятся на диаграмма ВИ как для моделирования между ПРЕЦЕДЕНТАМИ или АКТРАМИ того факта, что одна сущность является наследником другой сущности, т.е. сущность потомок наследует свойства и поведение сущности родителя и может быть дополнена новыми свойствами и новым поведением.

Отношение обобщения направлено от потомка к родителю.

 

Диаграмма классов

Диаграммой классов (Class diagram) называют диаграмму, на которой показано множество классов, интерфейсов, коопераций и отношений между ними. Ее изображают в виде множества вершин и дуг.

Диаграммы классов используются для моделирования статического вида системы с точки зрения проектирования. Сюда относится моделирование словаря системы и коопераций. Кроме того, диаграммы классов составляют основу еще двух диаграмм - компонентов и развертывания.

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

Диаграммы классов содержат следующие сущности:

  • классы;
  • интерфейсы;
  • кооперации;
  • отношения зависимости, обобщения, ассоциации реализации.

Они могут включать в себя примечания и ограничения.

Также в диаграммах классов могут присутствовать пакеты, применяемые для группирования элементов модели в более крупные блоки. Иногда в эти диаграммы помещают экземпляры (объекты).

Диаграммы классов могут использоваться в следующих целях:

  • для моделирования словаря системы. Моделирование словаря системы предполагает принятие решения о том, какие абстракции являются частью системы, а какие - нет. С помощью диаграмм классов определяются эти абстракции и их обязанности;
  • для моделирования простых коопераций. Кооперация - это сообщество классов, интерфейсов и других элементов, работающих совместно для обеспечения некоторого кооперативного поведения, более значимого, чем сумма составляющих его элементов. Например, моделируя семантику транзакций в распределенной системе, можно понять происходящие процессы, поскольку соответствующая семантика обеспечивается несколькими совместно работающими классами. С помощью диаграмм классов удается визуализировать и специфицировать эти классы и отношения между ними;
  • для моделирования логической схемы базы данных.

Классы

Классом (Class) называется описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Графически класс изображается в виде прямоугольника разделенного на 3 области.

Рис. Примеры классов

На начальных этапах моделирования класс может содержать только область имени.

У каждого класса должно быть имя, отличающее его от других классов. Имя класса - это текстовая строка. Взятое само по себе, оно называется простым именем; к составному имени спереди добавлено имя пакета, куда входит класс. Имя класса на диаграмме должно быть уникальным.

Имя класса может состоять из любого числа букв, цифр и ряда знаков препинания (за исключением таких, например, как двоеточие, которое применяется для отделения имени класса от имени объемлющего пакета). Имя может занимать несколько строк. На практике для именования класса используют одно или несколько коротких существительных, взятых из словаря моделируемой системы. Обычно каждое слово в имени класса пишется с заглавной буквы, например: Customer (Клиент), Wall (Стена), TemperatureSensor (ДатчикТемпературы).

<== предыдущая лекция | следующая лекция ==>
Реализации | Обязанности
Поделиться с друзьями:


Дата добавления: 2014-01-11; Просмотров: 1855; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.018 сек.