Продукты, поддерживающие RUP

Ниже перечислены самые известные продукты, поддерживающие Rational Unified Process:

• Rational Rose — CASE-средство визуального моделирования информационных систем, имеющее возможности генерирования элементов кода. Специальная редакция продукта — Rational Rose RealTime — позволяет на выходе получить исполняемый модуль;

• Rational Requisite Pro — средство управления требованиями, позволяющее создавать, структурировать, устанавливать приоритеты, отслеживать, контролировать изменения требований, возникающие на любом этапе разработки компонентов приложения;

• Rational ClearQuest — продукт для управления изменениями и отслеживания дефектов в проекте (bug tracking), тесно интегрирующийся со средствами тестирования и управления требованиями и представляющий собой единую среду для связывания всех ошибок и документов между собой;

• Rational SoDA — продукт для автоматического генерирования проектной документации, позволяющий установить корпоративный стандарт на внутрифирменные документы. Возможно также приведение документации к уже существующим стандартам (ISO, CMM);

• Rational Purify, Rational Quantify Rational PureCoverage, — средства тестирования и отладки:

- Rational Purify — весьма мощное средство поиска ошибок на run-time для разработчиков приложений и компонентов, программирующих на C/C++,

- Rational Visual Quantify — средство измерения характеристик для разработчиков приложений и компонентов, программирующих на C/C++, Visual Basic и Java; помогает определять и устранять узкие места в производительности ПО,

- Rational Visual PureCoverage — автоматически определяет области кода, которые не подвергаются тестированию;

• Rational ClearCase — продукт для управления конфигурацией программ (Rational’s Software Configuration Management, SCM), позволяющий производить версионный контроль всех документов проекта. С его помощью можно поддерживать несколько версий проектов одновременно, быстро переключаясь между ними. Rational Requisite Pro поддерживает обновления и отслеживает изменения в требованиях для группы разработчиков;

• SQA TeamTest — средство автоматизации тестирования;

• Rational TestManager — система управления тестированием, которая объединяет все связанные с тестированием инструментальные средства, артефакты, сценарии и данные;

• Rational Robot — инструмент для создания, модификации и автоматического запуска тестов;

• SiteLoad, SiteCheck — средства тестирования Web-сайтов на производительность и наличие неработающих ссылок;

• Rational PerformanceStudio — измерение и предсказание характеристик производительности систем.

Артефакты и роли

Неотъемлемую часть RUP составляют артефакты (artefact), прецеденты (precedent) и роли (role). Артефакты — это некоторые продукты проекта, порождаемые или используемые в нем при работе над окончательным продуктом. Прецеденты — это последовательности действий, выполняемых системой для получения наблюдаемого результата.

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

Таким образом, RUP четко определяет обязанности каждого члена группы разработки на том или ином этапе, то есть когда и кто должен создать тот или иной артефакт.

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

Business modeling

Артефакты-модели — используется Rational Rose:

• модель бизнес-процессов — определение бизнес-требований к разрабатываемой системе;

• модель структуры предприятия — артефакт для разработки функциональной модели системы;

• модели документов, бизнес-сущностей, модели сценариев бизнес-функций, модели состояний бизнес-сущностей — для проектирования пользовательского интерфейса, БД системы; представляют собой описание статического и динамического состояний системы с различных точек зрения;

• модели бизнес-правил — артефакт используется для моделирования правил в программном обеспечении.

Артефакты-документы — используются RequisitePro, SoDA, текстовые процессоры, Microsoft Project:

• оценка организации заказчика, структура бизнеса;

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

• набор бизнес-правил;

• коммерческое предложение;

• спецификации бизнес-функций;

• план работ на этапе бизнес-моделирования;

• рекомендации по проведению бизнес-моделирования;

• запросы на изменение.

Requirements

Артефакты-модели — используется Rational Rose:

• модель функции системы;

• модель сценариев функций системы;

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

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

• модель выходных форм;

• модель правил системы.

Артефакты-документы — используются RequisitePro, SoDA, текстовые процессоры, MS Project:

• план управления требованиями;

• словарь терминов системы;

• спецификация на программную систему;

• спецификация на функции системы;

• правила системы;

• запросы заинтересованных лиц;

• план работ на этапе определения требований к системе;

• рекомендации по моделированию на этапе определения требований;

• запросы на изменение.

Analysis and design

Артефакты-модели — используется Rational Rose:

• логическая модель данных;

• физическая модель данных;

• модель спецификаций компонентов системы;

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

Артефакты-документы — используются RequisitePro, SoDA, текстовые процессоры, MS Project:

• архитектура программного обеспечения;

• спецификации программных компонентов;

• рекомендации на этапе анализа и проектирования;

• план работ на этапе анализа и проектирования;

• запросы на изменение.

Implementation

Артефакты-модели — используется Rational Rose:

• компонентная модель приложения.

Артефакты-код — используются Rational Rose, средства программирования, текстовые процессоры:

• элементы генерации кода, полученные в Rational Rose;

• собственно код приложения;

• документация.

Артефакты-документы — используются RequisitePro, SoDA, текстовые процессоры, MS Project:

• план сборки приложения;

• план работ на этапе реализации.

Test

Артефакты-модели — используется Rational Rose:

• модель тестовых примеров;

• функциональная модель тестовой программы;

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

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

Артефакты-документы — используются SoDA, текстовые процессоры, MS Project:

• описание тестовых примеров;

• план тестирования;

• план работ на этапе тестирования;

• запросы на изменение.

Реализация тестирования — Quantify, Purify, PureCoverage, Robot, SiteLoad, SiteCheck.

Deployment

Артефакты-модели — используется Rational Rose:

• модель размещения — описание размещения компонентов по узлам обработки.

Артефакты-документы — используются SoDA, текстовые процессоры, MS Project:

• обучающие материалы;

• документы по инсталляции;

• описание версий системы;

• план внедрения.

Введение в UML

(https://www.interface.ru/home.asp?artId=3491)

Принципы моделирования

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

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

Сущности в UML

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

Структурные сущности - это имена существительные в моделях на языке UML. Как правило, они представляют статические части модели, соответствующие концептуальным или физическим элементам системы. Примерами структурных сущностей являются «класс», «интерфейс», «кооперация», «прецедент», «компонент», «узел», «актер».

Поведенческие сущности являются динамическими составляющими модели UML. Это глаголы, которые описывают поведение модели во времени и в пространстве. Существует два основных типа поведенческих сущностей:

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

Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Такая первичная сущность имеется в единственном экземпляре - это пакет.

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

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

Отношения в UML

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

Зависимость (dependency) - это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой.

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

Обобщение (generalization) - это отношение, при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (предка). При этом, в соответствии с принципами объектно-ориентированного программирования, потомок (child) наследует структуру и поведение своего предка (parent).

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

• между интерфейсами и реализующими их классами или компонентами;
• между прецедентами и реализующими их кооперациями.

Общие механизмы UML

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

• спецификации (specifications);
• дополнения (adornments);
• деления (common divisions);
• расширения (extensibility mechanisms).

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

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

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

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

Во-вторых, существует деление на интерфейс и его реализацию. Интерфейс декларирует обязательства, а реализация представляет конкретное воплощение этих обязательств и обеспечивает точное следование объявленной семантике. В связи с этим, почти все конструкции UML характеризуются двойственностью «интерфейс/реализация». Например, прецеденты реализуются кооперациями, а операции - методами.

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

• стереотипы (stereotype) - расширяют словарь UML, позволяя на основе существующих элементов языка создавать новые, ориентированные для решения конкретной проблемы;
• помеченные значения (tagged value) - расширяют свойства основных конструкций UML, позволяя включать дополнительную информацию в спецификацию элемента;
• ограничения (constraints) - расширяют семантику конструкций UML, позволяя создавать новые и отменять существующие правила.

Совместно эти три механизма расширения языка позволяют модифицировать его в соответствии с потребностями проекта или особенностями технологии разработки.

Виды диаграмм UML

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

• диаграмма вариантов использования или прецедентов (use case diagram)
• диаграмма классов (class diagram)
• диаграммы поведения (behavior diagrams)
• диаграмма состояний (statechart diagram)
• диаграмма деятельности (activity diagram)
• диаграммы взаимодействия (interaction diagrams)
• диаграмма последовательности (sequence diagram)
• диаграмма кооперации (collaboration diagram)
• диаграммы реализации (implementation diagrams)
• диаграмма компонентов (component diagram)
• даграмма развертывания (deployment diagram)

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

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

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

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

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

При графическом изображении диаграмм рекомендуется придерживаться следующих правил:

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

 

 

Приложение 3

Глоссарий