Материал: 695_Poletajkin_A.N._Uchebno-metodicheskoe_posobie_Realizatsija_zhiznennogo_ch.1_

Концепция RUP и основные ее элементы разработаны А. Джекобсоном в ходе его работы над языком UML.

Унифицированный процесс – это процесс, управляемый прецедентами, которые отражают сценарии взаимодействия пользователей. Фактически, это взгляд пользователей на программную систему снаружи. Суть концепции RUP заключается в последовательной декомпозиции или разбиении процесса ООП на отдельные этапы. На каждом этапе осуществляется разработка соответствующих типов канонических диаграмм модели системы.

1 этап. Строятся логические представления статической модели структуры системы,

2 этап. Строятся логические представления модели поведения,

3 этап. Строятся физические представления модели системы.

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

Более детально основные этапы RUP выглядят так:

1.Определение требований

2.Анализ

3.Проектирование

4.Реализация

5.Тестирование

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

Рис. 6. Пример диаграммы вариантов использования (прецедентов)

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

31

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

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

Требования к содержанию отчета

Вподразделе 1 описывается назначение программы и цели ее создания. При этом следует руководствоваться рекомендациями, изложенными в разделе 2.2 настоящегопособия.

Вподразделе 2 указывается перечень задач, программную реализацию которых предполагается осуществить. Разрабатывается статическая объектная модель будущей программы в виде диаграммы вариантов использования и диаграммы классов. Диаграммы реализовать в пакете программ Rational Rose, Visio или Altova UModel.

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

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

3.1 Требования к задаче “...”

3.2 Требования к задаче “...”

3.3 Требования к задаче “...”

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

– к временному регламенту реализации каждой задачи;

– к качеству реализации каждой задачи;

– к выходным данным;

– к входным данным;

– к преобразованию входной информации к машиночитаемому виду;

– к возможной одновременности выполнения нескольких задач;

– к достоверности результатов.

При описании требований к входным данным приводится: перечень и

32

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

–наименование;

–необходимую точность ее числового значения (при необходимости);

–источник информации (документ, видеокадр, устройство, кодограмма, информационная база на машинных носителях и т.д.);

–идентификатор источника информации.

Требования к программной реализации задач должны содержать:

–требования к организации хранения данных в виде односвязного списка с заданной дисциплиной манипуляции данными (приложение А);

–предварительное описание (структуру) интерфейса для доступа к реализации отдельных задач и подзадач;

–требования к методу программирования, к структуре кода, к именованию программных и информационных объектов.

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

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

–требования к операционной среде;

–требования к инструментальным средствам программной инженерии, обеспечивающих разработку ПО (CASE-средства и средства объектно-ориентированного моделирования);

–требования к инструментальным средствам разработки ПО;

–требования к использованию готовых программных пакетов;

–требования к вспомогательным программным средствам (сервисные программы и утилиты).

В подразделе 4 указывают нефункциональные требования к разрабатываемой программе. При этом следует руководствоваться рекомендациями, изложенными в разделе 2.3 настоящего пособия. Следует учитывать, что реализация нефункциональных требований часто требует больших затрат, чем функциональных. Так, сопровождаемость требует значительных усилий по поддержанию соответствия проекта исходному коду и применения специальных методов создания модифицируемых программ и структур данных. Надежность – дополнительных средств восстановления системы при сбоях. Эффективность – поиска специальных архитектурных решений и оптимизации структуры системы и программного кода. А удобство – проектирования не «интуитивно» понятного, а профессионально понятного интерфейса пользователя. Все требования к подсистеме согласовываются с руководителем. ГОСТ на содержание технического задания на создание программ приведен в приложении Б.

33

Контрольные вопросы и упражнения

1.Что такое техническое задание и какова его структура?

2.Для чего и зачем разрабатываются компьютерные программы?

3.Какие положительные результаты могут быть получены в процессе использования компьютерной программы?

4.Что подразумевает программная реализация задач бизнес-процесса?

5.Каково назначение разрабатываемой компьютерной программы?

6.Назовите цели, в соответствии с которыми разрабатывается программа.

7.Дайте определение функционально-структурной и объектной модели компьютерной программы. Укажите принципиальные различия между этими моделями.

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

9.Что такое рациональный унифицированный процесс (RUP)?

10.Перечислите основные этапы RUP при проектировании ПО.

11.Что такое функциональные и нефункциональные требования к компьютерной программе?

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

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

14.Какие виды обеспечения компьютерной программы разрабатываются при ее создании?

15.Что такое прикладное обеспечение компьютерной программы?

16.Какие требования предъявляются к входным и выходным данным при программной реализации задач бизнес-процессов?

17.Какие требования предъявляются собственно к программной реализации задач бизнес-процессов?

18.Какие требования предъявляются к прикладному математическому обеспечению при программной реализации задач бизнес-процессов?

19.Улучшение каких технических, технологических, производственноэкономических или других показателей бизнес-процесса может быть достигнуто в результате создания и использования компьютерной программы?

20.Какова численность оперативного персонала, задействованного в автоматизируемых задачах до и после предполагаемого внедрения компьютерной программы?

21.Сформулировать функциональные и нефункциональные требования к программному приложению, реализующему поиск данных в односвязном списке тремя разными способами. Разработать объектные модели на языке UML, описывающие работу программы.

34

Лабораторная работа №4

Тема: Проектирование функциональной структуры программного продукта.

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

Задание

1.Построить функциональную модель разрабатываемого ПО в виде контекстной диаграммы в нотации IDEF0 при помощи пакета BPWin.

2.На основе контекстной диаграммы создать диаграмму декомпозиции А0 на дочерние подпроцессы (задачи).

3.Для всех функциональных блоков диаграммы А0 построить диаграммы декомпозиции А2 на подзадачи.

Теоретические положения

4.1 Функционально-ориентированный подход к проектированию ИС Функционально-ориентированный подход рассматривает объект

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

Распространенной методикой реализации функциональноориентированного подхода является IDEF0, являющаяся следующим этапом развития графического языка описания функциональных систем SADT (Structured Analysis and Design Technique). Целью методики является построение функциональной схемы исследуемой системы, описывающей все необходимые процессы с точностью, достаточной для однозначного моделирования деятельности системы.

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

Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги"). На диаграмме функциональный блок изображается прямоугольником с текстом названия внутри (см. рис. 2).

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

35