Rational Rose

Вводятся глобальные пакеты:

1. базисные (foundation) классы (списки, очереди и т.д.);
2. обработчики ошибок (error handling classes);
3. математические библиотеки:
4. утилиты;
5. библиотеки других поставщиков.

Определяются проектные  классы (design classes):

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

Примеры возможных  подсистем:

1. классы, обеспечивающие сложный комплекс услуг (например, обеспечение безопасности и защита);
2. граничные классы, реализующие сложный пользовательский интерфейс, или интерфейс с внешними системами;
3. различные продукты: коммуникационное ПО (middleware, поддержка COM/CORBA), доступ к базам данных, типы и структуры данных (стеки, списки, очереди), общие утилиты (математические библиотеки), различные прикладные продукты.

Принятие решения о  преобразовании класса в подсистему определяется опытом и знаниями архитектора проекта.

Соглашения по проектированию интерфейсов:

1. имя интерфейса: короткое (одно-два слова), отражающее его роль в системе;
2. описание интерфейса: должно отражать его обязанности (размер - небольшой абзац);
3. описание операций: имя, отражающее результат операции, ключевые алгоритмы, возвращаемое значение, параметры с типами;
4. документирование интерфейса: характер использования операций и порядок их выполнения (показывается с помощью диаграмм последовательности), тестовые планы и сценарии и т.д.

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

класс «subsystem proxy» непосредственно реализует интерфейс и управляет реализацией его операций;

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

Выделение архитектурных  уровней:

Application Layer - содержит элементы прикладного уровня (пользовательский интерфейс);

Business Services Layer - содержит элементы, реализующие бизнес-логику приложений (наиболее устойчивая часть системы);

Middleware Layer - обеспечивает сервисы, не зависимые от платформы.

Пример выделения архитектурных  уровней и объединения элементов 

 

 

 

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

Данное представление  отражает следующие решения, принятые архитектором:

1. выделены три архитектурных уровня (созданы три пакета со стереотипом «layer»);
2. в пакете Application создан пакет Registration, куда включены граничные и управляющие классы;
3. граничный класс CourseCatalogSystem преобразован в подсистему (пакет CourseCatalogSystem со стереотипом «subsystem»);
4. в пакет Business Services, помимо подсистемы CourseCatalogSystem, включены еще два пакета: пакет External System Interfaces включает интерфейс с подсистемой CourseCatalogSystem (класс ICourseCatalogSystem со стереотипом «Interface»), а пакет University Artifacts - все классы - сущности.

Структура и диаграммы  пакета (подсистемы) CourseCatalogSystem показаны на рис.(23 – 27).

 

 

Рис.15. Структура пакета CourseCatalogSystem

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис.16. Зависимости между подсистемой и другими пакетами (диаграмма классов CourseCatalogSystem и Dependencies)

 

 

 

 

Рис.17. Классы, реализующие интерфейс подсистемы

(диаграмма классов ICourseCatalogSystem)

 

 

Рис.18. Диаграмма последовательности

 

Рис.19. Диаграмма последовательности

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

Нажмите кнопку Dependency панели инструментов.

Проведите линию зависимости  от зависимого пакета к тому, от которого он зависит.

Класс DBCourseOffering отвечает за взаимодействие с БД каталога курсов (рис. 26, 27).

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

Распределенная конфигурация системы моделируется с помощью диаграммы размещения. Ее основные элементы:

1. узел (node) - вычислительный ресурс (процессор или другое устройство, дисковая память, контроллеры различных устройств и т.д.). Для узла можно задать выполняющиеся на нем процессы;
2. соединение (connection) - канал взаимодействия узлов (сеть).

 

 

Распределение процессов  по узлам сети производится с учетом следующих факторов:

1. используемые образцы распределения (трехзвенная клиент-серверная конфигурация, «толстый» клиент, «тонкий» клиент, равноправные узлы (peer-to-peer) и т.д.);
2. время отклика;
3. минимизация сетевого графика;
4. мощность узла;
5. надежность оборудования и коммуникаций.

 

Для того чтобы открыть  диаграмму размещения, надо дважды щелкнуть мышью по представлению Deployment View (представлению размещения) в браузере.

Для того чтобы поместить  на диаграмму процессор:

1. На панели инструментов диаграммы нажмите кнопку Processor.
2. Щелкните по диаграмме размещения в том месте, куда хотите поместить процессор.
3. Введите имя процессора.

В спецификациях процессора можно ввести информацию о его стереотипе, характеристиках и планировании. Стереотипы применяются для классификации процессоров (например, компьютеров под управлением UNIX или ПК).

Характеристики  процессора - это его физическое описание. Оно может, в частности, включать скорость процессора и объем памяти.

После планирования (scheduling) процессора содержит описание того, как осуществляется планирование его процессов:

Preemptive (с приоритетом). Высокоприоритетные процессы имеют преимущество перед низкоприоритетными.

Non preemptive (без приоритета). У процессоров не имеется приоритета. Текущий процесс выполняется до его завершения, после чего начинается следующий.

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

Executive (исполнительный). Существует некоторый вычислительный алгоритм, который и управляет планированием процессов.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4. Проектирование классов

 

Классы анализа преобразуются  в проектные классы:

1. Проектирование граничных классов - зависит от возможностей среды разработки пользовательского интерфейса (GUI Builder).
2. Проектирование классов-сущностей - с учетом соображений производительности (выделение в отдельные классы атрибутов с различной частотой использования).
3. Проектирование управляющих классов - удаление классов, реализующих простую передачу информации от граничных классов к сущностям.
4. Идентификация устойчивых (persistent) классов, содержащих хранимую информацию.

Обязанности классов, определенные в процессе анализа, преобразуются в операции. Каждой операции присваивается имя, характеризующее ее результат. Определяется полная сигнатура операции: operationName (parameter: class, ...): returnType. Создается краткое описание операции, включая смысл всех ее параметров. Определяется видимость операции: public, private, protected. Определяется область действия (scope) операции: экземпляр или классификатор.

Определяются (уточняются) атрибуты классов:

1. Кроме имени, задаются тип и значение по умолчанию (необязательное): attributeName:Type = Default.
2. Учитываются соглашения по именованию атрибутов, принятые в проекте и языке реализации.
3. Задается видимость атрибутов: public, private, protected. При необходимости определяются производные (вычисляемые) атрибуты.

Пример определения операций и атрибутов.

 

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

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

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

 

 

 

Рис.20. Диаграмма состояний для класса CourseOffering

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Список используемой литературы

 

1. Quatrani. T. Visual Modeling with Rational Rose and UML.  Addison-Wesley?       1998. 222 h. (Русский перевод 2-го изд. Кватрани Т.  Rational Rose 2000  и UML. Визуальное моделирование. М.: ДМК Пресс, 2001, 176 с.
2. Орлов С.А. Технология разработки программного обеспечения. Учебник для вузов. СПб,: Питер, 2004, 527 с.
3. Леоненков А. UML 2-е издание, Санкт-Петербург: БХВ-Петербург, 2004,432 с.
4. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. Учебник. М.: Финансы и статистика, 2003, 352 с.
5. Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем. М.: Финансы и статистика, 2002,192 с.