![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Анализ требований и определение спецификаций программного обеспечения при объектном подходе
2.1 UML – стандартный язык описания разработки программных продуктов с использование объектного подхода Модели разрабатываемого ПО при объектном подходе основаны на предметах и явлениях реального мира. В основе всех моделей лежит описание требуемого поведения разрабатываемого ПО, т. е. его функциональности, но это поведение связывается с состояниями элементов (объектов) конкретной предметной области. Таким образом, на этапе анализа ставятся две задачи: · уточнить требуемое поведение разрабатываемого ПО; · разработать концептуальную модель его предметной области с точки зрения поставленных задач. В основе объектного подхода к разработке ПО лежит объектная декомпозиция, т. е. представлении разрабатываемого ПО в виде совокупности объектов, в процессе взаимодействия которых посредством передачи сообщений и происходит выполнение требуемых функций. Разрабатываемое с помощью объектного подхода программное обеспечение, как правило, очень сложно, поэтому для описания разработки в настоящее время используют специальный язык – универсальный язык моделирования UML. Этот язык, авторами которого являются Г. Буч, Д. Рамбо и А. Джакобсон, был признан стандартным средством описания объектных разработок. Полное описание разработки с использованием UML включает несколько моделей, характеризующих определенный аспект проектируемой системы: · модель использования – представляет собой описание функциональности ПО с точки зрения пользователя; · логическая модель – описывает ключевые абстракции ПО (классы, интерфейсы, и т. п.), т. е. средства, обеспечивающие требуемую функциональность; · модель реализации – определяет реальную организацию программных модулей; · модель процессов – отображает организацию вычислений и оперирует понятиями «процессы» и «нити». Она позволяет оценить производительность, масштабируемость и надежность ПО; · модель развертывания – показывает особенности размещения программных компонентов на конкретном оборудовании. Всего UML предлагает девять дополняющих друг друга диаграмм, входящих в различные модели: · диаграммы вариантов использования; · диаграммы классов; · диаграммы пакетов: · диаграммы последовательностей действий; · диаграммы кооперации: · диаграммы деятельностей: · диаграммы состояний объектов: · диаграммы компонентов: · диаграммы размещения. Полная спецификация разрабатываемого ПО, помимо указанных диаграмм, как и при структурном подходе, обязательно включает словарь терминов и различного рода описания и текстовые спецификации. UML и предлагаемая теми же авторами методика разработки ПО названная Rational Unified Process поддерживаются пакетом Rational Rose фирмы Rational Software Corporation. Ряд диаграмм можно получить также средствами программы Microsoft Visual Modeler и других CASE-средств. Определение вариантов использования Разработку спецификаций начинают с анализа требований к функциональности, указанных в техническом задании. В процессе этого анализа выявляют внешних пользователей разрабатываемого ПО и перечень отдельных аспектов его поведения в процессе взаимодействия с конкретными пользователями. Аспекты поведения ПО были названы «вариантами использования» или «прецедентами» (use cases). Вариант использования представляет собой характерную процедуру применения разрабатываемой системы конкретным действующим лицом, в качестве которого могут выступать не только люди, но и другие системы и устройства. Каждый вариант использования связан с некоторой целью, имеющей самостоятельное значение. В зависимости от цели выполнения процедуры различают следующие варианты использования: · основные – обеспечивают требуемую функциональность разрабатываемого ПО; · вспомогательные – обеспечивают выполнение необходимых настроек системы и ее обслуживание (например, архивирование информации и т. п.); · дополнительные – обеспечивают дополнительные удобства для пользователя (как правило, реализуются в том случае, если не требуют серьезных затрат каких-либо ресурсов ни при разработке, ни при эксплуатации). В зависимости от уровня абстракции вариант использования может описываться кратко или более подробно. Краткая форма описания содержит: название варианта использования, его цель, действующих лиц, тип варианта использования (основная, второстепенная или дополнительная) и его краткое описание. Диаграммы вариантов использования позволяют наглядно представить ожидаемое поведение системы. Основными понятиями диаграмм вариантов использования являются: действующее лицо, вариант использования, связь. Действующее лицо – внешняя по отношению к разрабатываемому ПО сущность, которая взаимодействует с ним с целью получения или предоставления какой-либо информации. Как уже упоминалось выше, действующими лицами могут быть пользователи, другое ПО или какие-либо технические средства, взаимодействующее с разрабатываемым ПО. Вариант использования – некоторая очевидная для действующего лица процедура, решающая его конкретную задачу. Связь – взаимодействие действующих лиц и соответствующих вариантов использования. Варианты использования также могут быть связаны между собой. При этом фиксируют связи использования и расширения. Использование подразумевает, что существует некоторый фрагмент поведения разрабатываемого ПО, который повторяется в нескольких вариантах использования. Этот фрагмент оформляют, как отдельный вариант использования и указывают связь с ним типа «использование». Расширение применяют, если имеется два подобных варианта использования, различающиеся наличием в одном из них некоторых дополнительных действий. В этом случае дополнительные действия определяют как отдельный вариант использования, который связан с основным вариантом связью типа «расширение». Пример диаграммы:
|