Общая характеристика case-средства

Rational Rose.

Rational Rose со времени своего появления претерпело серьёзные изменения и превратилось в современное средство анализа, моделирования и разработки программных систем.

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

Особенности рабочего интерфейса

Rational Rose

В Rational Rose реализованы общепринятые стандарты на рабочий интерфейс программы подобно известным средствам визуального программирования.

Рабочий интерфейс Rational Rose состоит из различных элементов, основными из которых являются:

1. главное меню программы;

2. стандартная панель инструментов;

3. окно браузера;

4. специальная панель инструментов;

5. окно диаграммы;

6. окно журнала.

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

Стандартная панель инструментов находится ниже меню программы. Некоторые инструменты недоступны (новый проект не имеет никаких элементов).

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

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

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

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

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

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

Основы UML.

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

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

Фундаментальным понятие ООП является понятие класса и объекта.

Под классом понимают некоторую абстракцию совокупности объектов, которые имеют общий набор свойств и обладают одинаковым поведением.

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

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

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

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

В формальной логике имеет место закон обратного отношения:

если содержание понятия А содержится в содержание понятия В, то объём понятия В содержится в объёме понятия А.

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

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

Основными принципами ООП являются:

• наследование;

• инкапсуляция;

• полиморфизм.

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

Рассмотрим в качестве общего класс «Автомобили». Данный класс определяется как некоторая абстракция свойств и поведения всех существующих автомобилей. Если в качестве производного класса рассматривать класс «Легковые автомобили», то все свойства класса «Автомобиль» будет присущи классу «Легковые автомобили». Можно сказать, что класс «Легковые автомобили» наследует свойства родительского класса «Автомобили». Однако класс потомок будет содержать дополнительные свойства.

В свою очередь класс «Легковые автомобили» порождает подклассы, которые могут соответствовать, например, моделям конкретных фирм производителей, т.е. появляется класс «Легковой автомобиль производства ВАЗ».

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

Описанная выше информация обладает серьёзным недостатком – отсутствие наглядности.

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

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

Основным субъектом (клиентом), который взаимодействует с классом «Легковой автомобиль» является водитель. Очевидно, что не каждый водитель в совершенстве знает устройство легкового автомобиля.

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

1. интерфейс;

2. реализация.

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

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

Полиморфизм – свойства некоторых объектов принимать различные внешние формы в зависимости от обстоятельств.

Применительно к ООП полиморфизм означает, что действия, выполненные одним методом, могут отличатся в зависимости от того, к какому из классов относится тот или иной метод.

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

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

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

1. анализ предметной области и формулировка требований к программе;

2. проектирование структуры программы;

3. реализация программы в кодах;

4. внедрение программы;

5. сопровождение программы.

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

Появление case-средств предназначенных для автоматизации первого и второго этапов было встречено неоднозначно, так как в каждом case-средстве имеет место графическая нотация, отличная от привычных языков программирования.

Классические диаграммы языка UML:

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

• диаграмма классов;

• диаграмма состояний;

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

• диаграмма деятельности;

• диаграмма кооперации;

• диаграмма компонентов;

• диаграмма развёртывания.