Студопедия

Главная страница Случайная страница

Разделы сайта

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника






Анализ требований и определение спецификаций программного обеспечения при объектном подходе






2.1 UML – стандартный язык описания разработки программных продуктов с использование объектного подхода

Модели разрабатываемого ПО при объектном подходе основаны на предметах и явлениях реального мира. В основе всех моделей лежит описание требуемого поведения разрабатываемого ПО, т. е. его функциональности, но это поведение связывается с состояниями элементов (объектов) конкретной предметной области.

Таким образом, на этапе анализа ставятся две задачи:

· уточнить требуемое поведение разрабатываемого ПО;

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

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

Разрабатываемое с помощью объектного подхода программное обеспечение, как правило, очень сложно, поэтому для описания разработки в настоящее время используют специальный язык – универсальный язык моделирования UML. Этот язык, авторами которого являются Г. Буч, Д. Рамбо и А. Джакобсон, был признан стандартным средством описания объектных разработок.

Полное описание разработки с использованием UML включает несколько моделей, характеризующих определенный аспект проектируемой системы:

· модель использования – представляет собой описание функциональности ПО с точки зрения пользователя;

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

· модель реализации – определяет реальную организацию программных модулей;

· модель процессов – отображает организацию вычислений и оперирует понятиями «процессы» и «нити». Она позволяет оценить производительность, масштабируемость и надежность ПО;

· модель развертывания – показывает особенности размещения программных компонентов на конкретном оборудовании.

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

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

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

· диаграммы пакетов:

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

· диаграммы кооперации:

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

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

· диаграммы компонентов:

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

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

UML и предлагаемая теми же авторами методика разработки ПО названная Rational Unified Process поддерживаются пакетом Rational Rose фирмы Rational Software Corporation. Ряд диаграмм можно получить также средствами программы Microsoft Visual Modeler и других CASE-средств.

Определение вариантов использования

Разработку спецификаций начинают с анализа требований к функциональности, указанных в техническом задании. В процессе этого анализа выявляют внешних пользователей разрабатываемого ПО и перечень отдельных аспектов его поведения в процессе взаимодействия с конкретными пользователями. Аспекты поведения ПО были названы «вариантами использования» или «прецедентами» (use cases).

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

Каждый вариант использования связан с некоторой целью, имеющей самостоятельное значение.

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

· основные – обеспечивают требуемую функциональность разрабатываемого ПО;

· вспомогательные – обеспечивают выполнение необходимых настроек системы и ее обслуживание (например, архивирование информации и т. п.);

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

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

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

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

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

Вариант использования – некоторая очевидная для действующего лица процедура, решающая его конкретную задачу.

Связь – взаимодействие действующих лиц и соответствующих вариантов использования.

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

Использование подразумевает, что существует некоторый фрагмент поведения разрабатываемого ПО, который повторяется в нескольких вариантах использования. Этот фрагмент оформляют, как отдельный вариант использования и указывают связь с ним типа «использование».

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

Пример диаграммы:






© 2023 :: MyLektsii.ru :: Мои Лекции
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав.
Копирование текстов разрешено только с указанием индексируемой ссылки на источник.