Унифицированный процесс разработки программного обеспечения. Унифицированный процесс разработки и экстремальное программирование

В соответствии с ГОСТ 34.601-90 «АС. Стадии создания» устанавливаются следующие стадии создания АИС, которые, в свою очередь, могут подразделяться на этапы:

· формирование требований к АИС;

· разработка концепции АИС;

· техническое задание;

· эскизный проект;

· технический проект;

· рабочая документация;

· ввод в действие.

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

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

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

· модель анализа;

· модель проектирования;

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

· модель реализации;

· модель тестирования.

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

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

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

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

Модель реализации описывает, как реализуются в виде компонентов классы проектирования. Соответственно она включает диаграммы компонентов, трассировки (реализации) классов, детальные диаграммы развёртывания, описание архитектуры системы.

Модель тестирования содержит набор тестовых примеров, процедур тестирования и описания тестовых компонент. Она задаёт способы тестирования исполняемых компонентов системы.

Сопоставим процессы построения моделей со стандартизованными стадиями создания АС. Модель вариантов использования строится на стадии формирования требований к АС; модель анализа – на стадии разработки концепции АС. На стадии технического задания и эскизного проектирования строится модель проектирования. Она уточняется на стадии технического проектирования и дополняется моделью развёртывания. На стадии рабочей документации создаются модели реализации и тестирования. Наконец, на стадии ввода в действие модель тестирования уточняется и становится в процессе эксплуатации эталонной, предназначенной для периодических проверок правильности функционирования и диагностики системы.

1.5 Компоненты языка UML

Унифицированный язык моделирования UML (Unified Modeling Language) – это язык визуального моделирования, используемый для спецификации, визуализации, конфигурирования, и документирования сложных систем (в том числе программного обеспечения) по объектно-ориентированной технологии.

При создании АС в методологии UML используются известные по методологиям Гейна/Сарсона и SADT принципы структурного системного анализа :

· нисходящая поэтапная разработка;

· диаграммная техника;

· иерархичность описаний;

· строгая формализация описания проектных решений;

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

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

· технологическая поддержка инструментальными средствами (CASE-системами).

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

Модели развёртывания, реализации и тестирования программного и информационного обеспечения АС на UML могут быть использованы как проект приложения с последующей автоматизированной генерацией кода приложения в одной из выбранных сред программирования.

Достаточно полная модель сложной системы должна отражать два аспекта:

-статический (структурный) – состав, структура компонент и их взаимосвязи;

-динамический (поведенческий) – описание логики процессов, протекающих в системе или подлежащих реализации.

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

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

В статической модели задается структура, типы объектов и отношения между объектами. В динамической модели определяется поведение объектов во времени (история объектов) и их взаимодействие.

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

Модель имеет два аспекта: семантическую информацию (семантику) и визуальное представление (нотацию).

Полный состав представлений моделей на языке UML приведён в таблице 1

Таблица 1 – Представление моделей системы на языке UML.

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

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

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

В языке имеется 4 вида графических конструкций:

· значки (пиктограммы);

· графические символы на плоскости;

· пути (линии);

· строки текста.

1.6 Концептуальный уровень. Модель вариантов использования

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

Диаграммой самого верхнего уровня считается предложенная А. Якобсоном в OOSE диаграмма вариантов использования системы в целом. Именно она является исходным концептуальным представлением системы и строится с целью:

· определить общие границы и контекст моделируемой предметной области;

· сформировать общие требования к функциональному поведению и интерфейсу системы;

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

Точка зрения модели: внешний пользователь системы. В диаграмму вариантов использования входят актанты (actors), варианты использования (use case) и ассоциации (association).

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

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

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

Во многих АС нет никаких других актантов, кроме людей. Однако, актантами могут быть внешняя система, устройство ввода/вывода или таймер (обычно это встречается во встроенных системах реального времени). Среди актантов в варианте использования выделяется главный актант (primary actor), который инициирует работу с системой. Остальные – второстепенные (secondary), они также участвуют в варианте использования, получая результаты и вводя некоторые промежуточные данные.

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

Актант может изображаться на диаграммах двумя способами:

3. Символ класса (прямоугольник) с внутренним указанием стереотипа

4. Более стандартно: “человек” с надписью (символ человека)

Актант находится вне системы и его внутренняя структура не определяется. Он является источником/приемником сообщений.

Заказчик

Вариант использования (прецедент, use case) – абстрактное описание класса сервиса (сервисных функций), предоставляемого актанту в ответ на его запросы.

Сервис могут предоставлять система в целом, подсистема или класс. Таким образом, вариант использования означает моделирование некоторой части функциональности или поведения системы. Вариант использования имеет имя и означает некоторую последовательность действий, видимых внешнему источнику/приемнику (актанту). Внутренний способ реализации варианта при этом скрывается и на более низких уровнях детализации раскрывается диаграммой кооперации . Как и всякий класс, вариант использования имеет атрибуты и операции, реализация которых раскрывается на физическом уровне.

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

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

Связь между актантом и вариантом использования показывается ассоциацией.

На диаграмме вариант использования изображается двумя способами:

1) эллипсом, внутри ставится имя

2) прямоугольником - как и любой класс

Заказчик

Датчик

Между актантами и вариантами использования ассоциация – единственный вид связи. При этом он имеет семантику коммутативной связи , то есть передачи сообщений, поэтому обычно не помечается, так как контекст ясен из обозначений актанта и варианта использования. Но можно ее пометить, а также указать кратность связи:

Клиент банка

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

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

Имя ассоциации, если оно есть, должно быть уникальным. Его формируют по смыслу отношений между классами - участниками ассоциации. Например, «Сотрудник работает_в Отделе», «Менеджер комплектует Компьютер» и т.п.

Ассоциации сами являются классами (класс-ассоциация , association class), у нее есть как свойства класса, так и свойства ассоциации. Экземпляры этого класса - связи, у которых есть не только ссылки на объекты, но и значения атрибутов (свойств).

Участники ассоциации называются ее полюсами . Все полюса – это роли классов, участвующих в связи, они различаются и могут быть перечислены в некотором упорядоченном списке. В большинстве случаев ассоциации бинарны (две роли в ассоциации с определенной семантикой), но могут быть и n -арными . Один и тот же класс может выступать в различных ролях, то есть быть одновременно в двух полюсах ассоциации.

Множественность связи проставляется у полюсов.

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

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

Ассоциация изображается непрерывной линией, соединяющей границы 2-х классов, если ассоциация n -арная, то рисуется ромб (признак агрегации):

		Множество ассоциаций - агрегация
	Бинарная ассоциация

Между собой варианты использования не обмениваются сообщениями и могут находиться только в отношениях (связях) расширения (extend), включения (include) и обобщения (generalization).

В отношении расширения вариант использования – клиент вносит дополнительную последовательность действий, начиная с некоторой точки основной последовательности, при этом таких “вставок” может быть несколько. Все эти точки называются точками расширения.

Rational Unified Process (RUP ) – одна из лучших методологий разработки программного обеспечения, созданная в компании Rational Software . Основываясь на опыте многих успешных программных проектов, Унифицированный процесс позволяет создавать сложные программные системы, основываясь на индустриальных методах разработки. Одним из основных столпов, на которые опирается RUP , является процесс создания моделей при помощи унифицированного языка моделирования (UML ). Эта статья о применении диаграмм UML в рабочем процессе разработки программных систем по методологии Rational Software .

Ни для кого не секрет, что создание программного обеспечения – это сложный процесс, который, с одной стороны, имеет много общего с творчеством, а с другой, – хотя и высокодоходный, но и высокозатратный бизнес. Жестокая конкуренция на рынке вынуждает разработчиков к поискуболее эффективных методов работы. Путей создания программных систем в еще более короткие сроки, с меньшими затратами и лучшим качеством. Сложность программ постоянно увеличивается. Еще недавно программные продукты могли быть созданы в обозримые сроки одиночками или, например, в IT -отделе автоматизируемого предприятия.

Сейчас же одиночкам, создающим программы «на коленке» остается область небольших утилит и различных модулей расширения «тяжелых» программных продуктов. Будущее за индустриальным подходом к созданию ПО. В 1913 году Генри Форд запустил первый автомобильный конвейер, а в 90-х аналогичный конвейер стал применяться в сфере IT -технологий. Командная разработка требует совсем другого подхода и другой методологии, которая рано или поздно должна была быть создана.

Корпорация Rational Software (http ://www .rational .com ) выпустила на рынок структурированную базу знаний под названием Rational Unified Process (RUP ), которая представляет собойнабор исчерпывающих рекомендаций для создания практически любых программных продуктов. Вобрав в себя опыт лучших разработок, RUP подробно рассказывает когда, кто и что должен делать в проекте, чтобы в результате получить программную систему с установленные сроки, с определенной функциональностью и в рамках отведенного бюджета.

Унифицированный процесс можно представить как сумму различных видов деятельности компании-разработчика, необходимых для перевода требований заказчика в программную систему. Систему, которая давала бы «значимый результат» пользователям и выполняла бы именно то, что они от системы ожидают. Поэтому процесс управляется вариантами использования (Use Case ) системы, или иначе –прецедентами.

Для реализации требований заказчика в установленные сроки, Унифицированный процесс разделяется на фазы, которые состоят из итераций, поэтому процесс еще называют итеративным и инкрементным. Каждая итерация проходит цикл основных работ и подводит разработчиков к конечной цели: созданию программной системы. В ходе итераций создаются промежуточные артефакты, которые требуются для успешного завершения проекта и вариант программной системы, который реализует некоторый набор функций, увеличивающийся от итерации к итерации. Фазы и основные потоки работ процесса показаны на рис. 1, там же даны примерные трудозатраты работ по фазам.

рис. 1 Фазы и потоки работ RUP

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

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

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

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

Унифицированный язык моделирования (Unified Modeling Language ) появился в конце 80-х в начале 90-х годов в основном благодаряусилиям «трех друзей» Гради Буча, Джима Рамбо и Ивара Якобсона. В настоящее время консорциум OMG принял этот язык как стандартный язык моделирования, который предоставляет разработчикам четкую нотацию, позволяющую отображать модели общепринятымии понятными каждому члену проекта графическими элементами.

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

Программная система создается для решения определенных проблем пользователя, а не для опробования новых технологийпрограммистами и получения опыта руководителем проекта. По большому счету, пользователю не важно используете ли вы в процессе разработки объектно-ориентированный подход, UML , RUP или создаете систему по методу XP (экстремального программирования) . Применение тех или иных методик, технологий, создание оптимальной внутренней структуры проекта остается на совести разработчиков, которые принимают решения исходя из предыдущего опыта и собственных предпочтений. Однако пользователь не простит вам игнорирование его требований. Будь программная система хоть десять раз разработана при помощи суперсовременных методов и технологий, если пользователь не получит от нее то, что называется «значимым результатом», ваш программный проект с треском провалится.

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

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

Однажды я проводил семинар по RUP в компании-разработчике программного обеспечения, которая уже десять лет довольно успешно работает на рынке, но не использует в своем рабочем процессе моделирования вовсе, а основывается на прототипах. В зале собралось около двадцати молодых и умудренных опытом программистов, которые внимательно прослушали все, что я им рассказал о RUP и UML . И вот один из них, посмотрев на доску, испещренную примерами диаграмм, заметил: «Это все интересно и, наверное, хорошо подходит для других проектов», – сказал он, «но мы работаем довольно давно без всего этого,раз мы до сих пор обходились без UML , он, наверное, нам это просто не нужен».

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

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

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

рис 2. Пример диаграммы Прецедентов

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

Для детализации конкретного прецедента используется диаграмма Активности (Activity Diagram ), пример которой дан на рис 3.

рис. 3 Пример диаграммы Активности

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

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

Для того чтобы верно определить требования, разработчикидолжны понимать контекст (часть предметной области) в котором будет работать будущая система. Для этого создаются модель предметной области и бизнес-модель, что является различными подходами к одному и тому же вопросу. Часто создается что-то одно: модель предметной области или бизнес-модель.

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

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

2.Анализ

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

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

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

Для отображения модели анализа при помощи UML используется диаграмма классов со стереотипами (образцами поведения) «граничный класс», «сущность», «управление», а для детализации используются диаграммы сотрудничества (Collaboration ) (рис 4). Стереотип «граничный класс» отображает класс, который взаимодействует с внешними актантами, «сущность» – отображает классы, которые являются хранилищами данных, а «управление» – классы, управляющие запросами к сущностям.

рис 4. Пример диаграммы сотрудничества

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

Если акцентировать внимание на порядке взаимодействия, то другим его представлением будет диаграмма последовательности (Sequence ), показанная на рис 5. Эта диаграмма позволяет взглянуть на обмен сообщениями во времени, наглядно отобразить последовательность процесса. При использовании такого инструмента для создания моделей как Rational Rose , эти два вида диаграмм могут быть созданы друг из друга автоматически (подробнее о Rational Rose можно прочитать, например, в ).

Рис. 5 Пример диаграммы последовательности действий

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

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

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

Для создания модели проектирования используются целый набор UML диаграмм: диаграммы классов (рис. 5), диаграммы кооперации, диаграммы взаимодействия, диаграммы активности.

рис 6. Пример диаграммы классов

Дополнительно в этом рабочем процессе может создаваться модель развертывания, которая реализуется на основе диаграммы развертывания (Deployment Diagram ). Это самый простой тип диаграмм, предназначенный для моделирования распределения устройств в сети. Для отображения используется всего два варианта значков процессор и устройство вместе со связями между ними.

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

Основная задача процесса реализации – создание системы в виде компонентов – исходных текстов программ, сценариев, двоичных файлов, исполняемых модулей и т.д. На этом этапе создается модель реализации, которая описывает то, как реализуются элементы модели проектирования, какие классы будут включены в конкретные компоненты. Данная модель описывает способ организации этих компонентов в соответствии с механизмами структурирования и разбиения на модули, принятыми в выбранной среде программирования и представляется диаграммой компонентов (рис. 7).

рис. 7 Пример диаграммы компонентов

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

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

6.Заключ ение

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

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

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

Крачтен. Ф. Введениев Rational Unified Process. Изд. 2- е.- М.: Издательский дом "Вильямс", 2002. - 240 с.: ил.

Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения- Спб.: Питер, 2002. - 496 с.: ил.

Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования: Пер. с англ. – М.:Мир, 1999. – 191 с., ил.

Бек. Е. Экстремальное программирование. – Спб.: Питер, 2002. – 224 с.: ил.

ТрофимовС. CASE-технологии: Практическая работа в Rational Rose.
Изд. 2-е.- М.: Бином-Пресс, 2002 г. - 288 с.

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

История возникновения

Истоки фреймворка лежат в работах сотрудника Ericsson Ивара Якобсона , опубликованных в конце 1960-х годов. Якобсон и его коллеги моделировали огромные телекоммуникационные системы с использованием слоёв «блоков» (того, что позднее стало называться «компонентами»): нижние слои служили основанием для подсистем из верхних слоёв. Команда строила нижние блоки путём рассмотрения «дорожных происшествий» (англ. traffic cases ), которые могли произойти с пользователями системы. Именно эти «происшествия» стали прообразом сценариев использования (англ. use cases ), вошедших позднее в состав UML . Работы Якобсона также послужили толчком для создания диаграмм, используемых в UML , включая диаграммы деятельности и последовательности .

В 1987 году Якобсон основал собственную компанию Objectory AB и совместно с партнёрами провёл несколько лет, разрабатывая проект и продукт под названием Objectory . В 1995 году Якобсон публикует книгу «Object-Oriented Software Engineering », описывающую процесс разработки, движущей силой которого являются требования клиента, трансформируемые в конечный продукт с помощью сценариев использования. Выход книги совпал с первой публикацией онлайн-версии ядра Unified Process .

В 1995 году компанию Objectory AB поглощает корпорация Rational . С помощью значительно возросшего количества коллег, Якобсон приступает к расширению процесса Objectory , дополняя его инструментами для управления проектами и разработки. Наряду с Гради Бучем и Джеймсом Рамбо , работавшими в Rational ранее, Якобсон становится участником группы «трёх амиго» , возглавивших работы по созданию процесса, получившего название Rational Objectory Process (ROP ), а также распространению Unified Process , ставшего основой для Unified Modelling Language .

В процессе работы над ROP и UML , корпорация Rational продолжала слияния и поглощения компаний, занимающихся созданием инструментов для разработки программного обеспечения. Эти инструменты обеспечили возможность управления требованиями («RequisitePro»), общего тестирования («SQA»), тестирования производительности, управления конфигурациями и управления изменениями. В 1998 году Rational изменяет название продукта на RUP , концептуальным ядром которого остаётся Unified Process .

Характеристики

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

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

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

Фазы разработки

Относительный размер фаз разработки для типичного проекта

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

Разновидности рабочего процесса

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

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

Итерации и инкременты

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

Rational Unified Process (RUP) - это основа технологии разработки ПО, разработанная и продаваемая компанией Rational Software. Он включает в себя передовой мировой опыт разработки ПО, и обеспечивает дисциплинарный подход к распределению и управлению задачами и областями ответственности в организации, занимающейся разработкой ПО. Применяя этот процесс, команды разработчиков программ смогут создавать высококачественное ПО, отвечающее потребностям своих конечных пользователей, и делать это в рамках предсказуемого графика и бюджета.

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

В основе Rational Unified Process лежат несколько фундаментальных принципов, собранные из множества успешных проектов:

· Начинайте вести наступление на главные риска раньше и ведите его непрерывно, или они сами пойдут в наступление на вас.

· Обеспечьте выполнение требований заказчиков.

· Сконцентрируйтесь на исполняемой программе.

· Приспосабливайтесь к изменениям с самого начала проекта.

· Рано закладывайте исполняемую архитектуру.

· Стройте систему из компонентов.

· Работайте вместе как одна команда.

· Сделайте качество образом жизни, а не запоздалой идеей.

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

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

Все элементы процесса – роли, задачи, артефакты и связанные с ними концепции, руководства и шаблоны сгруппированы в логические контейнеры, называемые Дисциплинами (Disciplines). В стандартном продукте RUP дисциплин всего девять. К ним относятся: бизнес – моделирование, управление требованиями, управление проектом, управление изменениями и среда.

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

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

· бизнес – модель . Определяет абстракцию организации, для которой создается система;

· модель области определения . Фиксирует контекстное окружение системы;

· модель Use Case . Определяет функциональные требования к системе.

· модель анализа . Интерпретирует требования к системе в терминах проектной модели;

· проектная модель . Определяет словарь предметной области проблемы и ее решения;

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

· модель реализации . Определяет части, которые используются для сборки и реализации физической системы;

· тестовая модель . Определяет тестовые варианты для проверки системы;

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

Технические артефакты подразделяются на четыре основных набора:

· набор требований. Описывает, что должна делать система;

· набор проектирования.

· набор реализаций. Описывает сборку разработанных программных компонентов;

· набор размещения. Обеспечивает всю информацию о поставляемой конфигурации.

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

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

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

Набор размещения группирует всю информацию об упаковке, отправке, установке и запуске системы.

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

Показатель Риска = Вероятность (НУ) *Потеря (НУ).

Управление риском включает шесть действий:

1. Идентификация риска – выявление элементов риска в проекте.

2. Анализ риска – оценка вероятности и величины потери по каждому элементу риска.

3. Ранжирование риска - упорядочение элементов риска по степени их влияния.

4. Планирование управления риском – подготовка к работе с каждым элементом риска.

5. Разрешение риска – устранение или разрешение элементов риска.

6. Наблюдение риска – отслеживание динамики элементов риска, выполнение корректирующих действий.

Первые три действия относятся к этапу оценивания риска, последние три действия – к этапу контроля риска.

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