Компания Rational Software

Компания Rational Software является лидирующей в области создания методологий и программных решений, ориентированных на программистов, аналитиков, тестировщиков. Спектр выпускаемого программного обеспечения целиком покрывает потребность всех участников проекта: от аналитиков до разработчиков и внедренцев. Все программно-методологические решения - плод многолетнего труда аналитиков и разработчиков как самой Rational, так и ее партнеров. В итоге все решения были собраны воедино. Так появился RUP – Rational Unified Process – методологическая энциклопедия, в которой описаны все шаги, необходимые для создания качественного программного продукта. Пользуясь подобной энциклопедией и применяя соответствующие инструменты, рекомендуемые Rational, команда будет создавать обеспечение качественно и в срок. “Строй быстрей и качественней!” – вот лозунг, выдвигаемый Rational.

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

Rational Rose, являясь объектно-ориентированым средством проектирования, способна моделировать ситуации любой сложности: от проектирования банковской системы до разработки кода на С++. В умелых руках Rose неоценимый инструмент!

Описание возможностей

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

Давайте попробуем разобраться, что же реально даст данный инструмент отдельным участникам проекта: проектировщикам, аналитикам, разработчикам.

Проектировщикам. В большинстве случаев подрядчик не может написать качественное программное обеспечение в установленный срок, поскольку заранее не были оговорены с заказчиком наиболее важные моменты в системе. Например, заказчик забыл рассказать об очень важной составляющей своей системы, а вспомнил об этом, когда увидел (запустил) предложенную готовую программу. Соответственно, проблема на данном этапе – взаимопонимание двух сторон. Значит, если проектировщик с заказчиком посредством моделирования предметной области в Rational Rose четко и скрупулезно описали каждую деталь и увидели ее в виде понятных диаграмм, то проблему взаимопонимания можно отбросить. Таким образом, при разработке современных информационных систем много времени уделяется проектированию (моделированию предметной области), поскольку необходимо изначально договориться с заказчиком обо всех нюансах, а не вносить в режиме “пожарной команды” изменения на более поздних этапах. То есть Rational Rose поможет на концептуальном уровне разобраться с генеральным планом автоматизации. Для улучшения взаимопонимания обеих сторон совместно с Rose применяют инструмент SoDA, позволяющий на основе построенной модели дать полный отчет по ее состоянию, соответствующий всем общепризнанным мировым стандартам (в частности ISO 9000). Как видим, внедрение Rose на предприятии позволяет, в дополнение к вышеописанному, структурировать сопроводительную документацию, привести ее к необходимому стандарту с минимальными девиациями.

Разработчикам. Не меньше возможностей Rose дает и разработчикам. Давайте снова повторим очевидную вещь: информационные системы конца 90 гг. вышли на такой уровень сложности, что справиться с ними уже под силу только крупным компаниям с большим количеством узкоспециализированных разработчиков. Времена программистов-одиночек ушли в небытие. В современных условиях механизм “сам все сделаю” дает явный сбой. В качестве второй проблемы можно отметить некоторую текучесть кадров на отдельно взятом предприятии. Каждый раз, при включении нового сотрудника в проект, необходимо посвящать его во все детали проекта, на что уходит драгоценное время коллег, отрываемых от основной работы. При наличии же Rose достаточно показать все диаграммы проекта и предоставить проектную документацию, сгенерированную на основе полученной модели, как все станет на свои места. Разработчик увидит как весь проект в целом, так и свою часть. Конкретно же в плане разработки Rose поддерживает проектирование, основанное на двух способах: прямом и обратном. В режиме прямого проектирования разработчик рисует определенным образом диаграммы классов и их взаимодействия, а на выходе получает сгенерированный код на определенном языке программирования. В режиме же обратного проектирования возможно построение модели на базе имеющегося исходного кода. Из этого следует самая главная возможность для разработчиков: повторное проектирование (Round-trip), когда разработчик описывает классы в Rose, генерирует код, дописывает необходимую полнофункциональную часть и снова закачивает в Rose, для представления того, что же система получила в результате его действий.

Важнейшим свойством Rational Rose принято считать открытость архитектуры, что позволяет дополнять имеющийся в ней инструментарий новыми функциями. Например, в стандартном варианте Rose не поддерживает кодогенерацию на Ассемблере. Путем написания дополнительного модуля подобную проблему можно решить. Спешу обрадовать, на Западе достаточно компаний, выпускающих подобные модули расширения для различных языков программирования, правда, на Ассемблере еще нет, но мы будем надеяться!

Вот список включенных стандартных модулей: С++, ADA, CORBA, Visual Basic, XML, COM, Oracle). То есть Rational Rose способна проводить прямое и обратное проектирование в данных системах.

Подведем первые итоги того, что может делать Rational Rose

1. Проектировать системы любой сложности

2. Давать развернутое представление о проекте в сочетании со средствами документирования (SoDA)

3. Проводить кодогенерацию

4. Проводить обратное проектирование имеющихся систем

5. Имеет открытый для дополнений интерфейс

6. Интегрируется со средствами разработки (Visual Studio)

7. Поддержка языка UML

8. Наличие средств автоматического контроля, в том числе проверки соответствия двух моделей

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

10. Многоплатформенность

11. Интегрируемость с другими инструментальными средствами, поддерживающими жизненный цикл программных систем, в том числе со средством управления требованиями (Requisite Pro), со средствами тестирования (SQA Suite, Performance Studio), со средствами конфигурационного управления (ClearCase, PVCS).

На чем основана работа программы.

 Сущности UML 

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

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

Класс (class) - это описание совокупности объектов с общими атрибутами, операциями отношениями и семантикой. Графически класс изображается в виде прямоугольника, в котором записаны его имя, атрибуты и операции.

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

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

Прецедент (use case) - это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера (actor). Графически прецедент тоже изображается в виде эллипса, только ограниченного непрерывной линией, обычно содержащего только его имя. Активным классом (active class) называется класс, объекты которого вовлечены в один или несколько процессов, или нитей (threads), и поэтому могут инициировать управляющее воздействие. Графически активный класс изображается также как и простой класс, но ограничивается прямоугольником, который рисуется жирной линией, и включает имя, атрибуты и операции.

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

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

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

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

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

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

Примечание (note) - это просто символ для изображения комментариев или ограничений, присоединенный к элементу или группе элементов. Графически примечание изображается в виде прямоугольника с загнутым краем, содержащим текстовый или графический комментарий.

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

UML поддерживает построение  следующих диаграмм:

• Activity diagram (диаграммы описаний технологий, процессов, функций).

• Use case diagram (диаграммы функций).

• Class diagram (диаграммы классов).

• State diagram (диаграммы состояний);

• Sequence diagram (диаграммы последовательностей действий);

• Collaboration diagram (диаграммы взаимодействий)

• Component diagram (диаграммы компонент);