Некоторые теоретические сведения о UML- унифицированном языке моделирования 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Некоторые теоретические сведения о UML- унифицированном языке моделирования



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

Для создания моделей анализа и проектирования объектно-ориентированных программных систем используют языки визуального моделирования, самым популярным из которых на сегодняшний день является UML.


 

Спецификация разрабатываемого программного обеспечения при использовании UML объединяет несколько моделей: логическую, использования, реализации, процессов, развертывания [1].

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

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

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

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

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

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

Всего UML предлагает девять дополняющих друг друга диаграмм, входящих в различные модели:

• диаграммы вариантов использования;

• диаграммы классов;

• диаграммы пакетов;

• диаграммы последовательностей действий;

• диаграммы кооперации;

• диаграммы деятельностей;

• диаграммы состояний объектов;

• диаграммы компонентов;

• диаграммы размещения.

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

6.2. Определение прецедентов (вариант использования)

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

Прецеденты (варианты использования — Use Cases) — это подробные процедурные описания вариантов использования системы всеми заинтересованными лицами, а также внешними системами, т. е. всеми, кто (или что) может рассматриваться как акторы (actors) — действующие лица.

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

В зависимости от цели выполнения конкретной задачи различают следующие варианты использования [1]:

• основные, обеспечивают выполнение функций проектируемой системы;

• вспомогательные, обеспечивают выполнение настроек системы и ее обслуживание;

• дополнительные, служат для удобства пользователя (реализуются в том случае, если не требуют серьезных затрат ка­ких-либо ресурсов ни при разработке, ни при эксплуатации).

Пример 3.3. Анализ функциональных требований и пользователей системы тестирования (модуль обучающей системы).

Система тестирования прежде всего требуется следующим заинтересованным лицам:

• обучаемому (студенту);

• составителю тестов (преподавателю);

• преподавателю, принимающему экзамен;

• сотруднику деканата, осуществляющему контроль за успе­ваемостью;

• администратору сети и баз данных учебного учреждения.

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

• студент (тестируемый);

• администратор (он же преподаватель, он же составитель тестов).

Соответственно основные прецеденты (варианты использования) для нашей системы следующие:

Прецедент для студента:

• П1 — пройти тестирование.

Прецеденты для администратора:

• П2 — создать/изменить тест;

• ПЗ — просмотреть результаты тестирования;

• П4 — добавить/изменить пользователей и др.

Вариант использования можно описать кратко или подробно. Краткая форма описания содержит название варианта использования, его цель, действующих лиц, тип варианта использования (основной, второстепенный или дополнительный) и его краткое описание [1].


Краткое описание варианта использования для данного примера:

 

Подробное описание варианта использования Прохождение теста

Для большей наглядности используют диаграммы вариантов использования.

Диаграммы вариантов использования

На рис. 3.38 приведены условные обозначения, которые применяют при изображении диаграмм прецедентов [48].


Рис. 3.38. Условные обозначения диаграмм прецедентов: а — актор;

б — вариант использования; в — связь

Приведем диаграмму прецедентов для вышеописанного при­мера (рис. 3.39).

Рис. 3.39. Диаграмма вариантов использования тестовой системы


 

Естественно, все варианты использования определить, как правило, не удается: новые варианты фиксируют постоянно, даже в процессе эксплуатации. Но чем больше вариантов выявлено в процессе уточнения спецификаций, тем лучше, так как при этом получают более точную модель предметной области, что уменьшает вероятность ее пересмотра при добавлении функций.



Поделиться:


Последнее изменение этой страницы: 2016-12-29; просмотров: 821; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 54.205.243.115 (0.007 с.)