Объектно-ориентированная технология программирования, развитие которой началось в середине 80-х годов, к 90-м годам достигла поры своей зрелости, и в настоящее время ее поклонники говорят о начале революции в программировании. При этом имеется в виду уже не объектно-ориентированное программирование, а набирающая силу тенденция проводить разработку проектов корпоративного уровня на основе компонентов (CBD, Component Based Development). На рынке инструментальных CASE-средств поддержки CBD-моделирования и разработки в середине 90-х годов доминировали четыре фирмы: Rational Software, Cayenne, Platinum, Select.
В 1995 г. по объему продаж Rational Software вырвалась вперед и продолжает лидировать с большим отрывом со своим “широко известным в узких корпоративных кругах” CASE-продуктом Rational Rose. Если в 1997 г. существовала собственная модификация системы Rational Rose для каждого языка программирования (Си++, Visual Basic, Java, PowerBuilder, Ada, Forte, Smalltalk), то теперь имеется единая система — Rational Rose 98 с поддержкой нескольких языков программирования.
UML — Introduction to rational rose
Rational Rose 98 занимает особое место в ряду CASE-продуктов визуального моделирования сложных программных систем, имеющихся на рынке, и обладает стратегическим преимуществом в плане развития продукта. Такая оценка основана на следующих особенностях Rational Rose 98:
— он поддерживает генерацию кода и обратное проектирование (т. е. построение модели по программному коду) сразу для нескольких языков, включая Visual Basic, C++, Java, PowerBuilder, CORBA Interface Definition Language(IDL), Data Definition Language для большинства СУБД, Erwin-модели;
— поддерживает визуальное объектно-ориентированное моделирование, полностью совместимое с UML (Unified Modeling Language), который с 1997 г. определен как стандарт языка для этой быстро развивающейся области инструментальных средств;
— имеет широкие перспективы развития, в том числе за счет появления дополнительных продуктов-переходников (Links), тесно интегрированных с Rational Rose и создаваемых многочисленными независимыми разработчиками инструментальных средств в рамках программы Rational Rose Link Partner Program;
— ориентирован на разработчиков архитектуры информационных систем (ИС), менеджеров ИС и программистов.
CASE-продукты в России
Особенностью Rational Rose 98 является его концептуальная новизна в России как CASE-инструментария. Что это значит? В настоящее время в России (и других странах СНГ) популярны CASE-средства, основанные на структурных методах моделирования сложных архитектур ИС. К наиболее известным продуктам в этой области относятся ERwin (Logic Works), Designer-2000 (Oracle) и ряд других, рассмотренных в обзоре Георгия Калянова “Российский рынок CASE-средств” (PC Week/RE, № 23/98, с. 39). В отличие от них, Rational Rose 98 — это объектно-ориентированный CASE-инструментарий.
UML — Working with rational rose
С точки зрения создания корпоративных информационных систем (КИС) объектно-ориентированное моделирование, анализ и проектирование заслуживают повышенного внимания и CASE-поддержки в российских фирмах — разработчиках крупных программных проектов и интеграторов. Действительно, многие руководители информационных и разрабатывающих отделов подозревают, что программирование “в объектах” — это хорошо, особенно если речь идет о создании сложных программных систем.
Однако объектно-ориентированное программирование (ООП) по-разному понимается разными людьми, и в свое время Рентр отмечал: “Я полагаю, что ООП в 90-х годах будет тем, чем в 70-х являлось структурное программирование. Все были в восторге от него. Каждый производитель предлагал продукты для его поддержки. Каждый программист был знаком на практике с ним. И никто не знал, что же это такое. ” (см. врезку “Структурная или объектная декомпозиция”).
Unified Modeling Language
В Rational Rose 98 поддерживается UML версии 1.0 наряду с ранее широко используемыми нотациями Буча и ОМТ. Это означает, что проектировщики и аналитики могут продолжать пользоваться, например, нотацией Буча, на которой основаны их прежние проекты в старых версиях Rational Rose. А затем можно легко привести полученную модель проекта к UML-нотации простым выбором установки нотации UML в Rational Rose 98.
UML был разработан фирмой Rational Software и ее партнерами — крупными компаниями, разрабатывающими КИС: Hewlett-Packard, IBM, i-Logix, ICON Computing, IntelliCorp, MCI Systemhouse, Microsoft, ObjecTeam, Oracle, Platinum Technology, Ptech, Reich Technologies, Softeam, Sterling Software и Unisys.
UML — преемник языков визуального моделирования программных архитектур Буча, OOSE/Jacobson и OMT. Ряд крупных компаний уже используют UML как стандарт в процессе разработки крупных программных систем. UML служит для проведения бизнес-моделирования (см. врезку “Проектирование”), управления требованиями, анализа и проектирования архитектуры системы, программирования и тестирования. Описание истории и особенностей UML в контексте объектно-ориентированной CASE-технологии заслуживает отдельной работы.
Этапы проведения моделирования в Rational Rose 98
Моделирование проводится как поуровневый спуск от концептуальной модели к логической, а затем к физической модели программной системы.
Концептуальная модель выражается в виде диаграмм прецедентов (use case diagram). Этот тип диаграмм служит для проведения итерационного цикла общей постановки задачи вместе с заказчиком. Часто можно услышать следующее: “Заказчик и раньше не знал, и теперь не знает, и в будущем не будет точно знать, что ему нужно”. Диаграммы прецедентов как раз и служат основой для достижения взаимопонимания между программистами-профессионалами, разрабатывающими проект, и заказчиками проекта. Внутри каждого прецедента могут быть определены:
— вложенная диаграмма прецедентов;
— диаграмма взаимодействия объектов (collaboration diagram);
— диаграмма последовательности взаимодействий (sequence diagram);
— диаграмма классов (class diagram);
— диаграмма перехода состояний (state diagram).
Логическая модель позволяет определять два различных взгляда на системы: статический и динамический. Статический подход выражается диаграммами классов (class diagram). На рис. 1 приведена такая диаграмма в UML-нотации. Именно диаграммы классов служат основой для генерации программного кода на целевом языке программирования.
Возможна очень гибкая настройка генерации кода, позволяющая учитывать конкретные соглашения (например, по префиксам имен идентификаторов), принятые в команде разработчиков проекта.
Динамический подход описывается двумя типами диаграмм (см. рис. 2а, б):
— диаграммами взаимодействия объектов;
— диаграммами последовательности взаимодействий.
В текущей версии Rational Rose 98 эти диаграммы не влияют на генерируемый код, однако фирмы-партнеры Rational Software применяют эти диаграммы в своих приложениях. Так, диаграммы последовательности взаимодействий используются в пакете SQA Suite для автоматизированного тестирования компонентов, разработанных в Rational Rose 98. Классы, введенные на этих диаграммах, попадают в список классов модели и могут использоваться при конструировании диаграмм классов. Динамика конкретного класса может быть выражена с помощью диаграмм перехода состояний, определяющих модель конечного автомата, описывающего поведение класса. Каждое состояние задается своей вершиной, и определены входное и выходные состояния, а также условия перехода из состояния в состояние.
Физическая модель задается компонентной диаграммой (component diagram), которая описывает распределение реализации классов по модулям, и диаграммой поставки (deployment diagram).
После построения первого/последующего слоя статической модели с использованием диаграмм классов можно провести генерацию кода на целевом языке программирования. На уровне кода можно ввести новые уточняющие классы, изменить атрибуты и методы классов модели и затем синхронизировать код и модель, выполнив обратное проектирование, т. е. по модифицированному коду Rational Rose 98 позволяет построить новую логическую модель взаимосвязи классов между собой! Повторение такой процедуры несколько раз называется итерационным моделированием (round-trip modeling), которое составляет основу мягкого и постепенного уточнения постановки задачи и согласования требований заказчика с имеющимися ресурсами (вычислительными, временными, финансовыми и т. п.).
Обеспечение групповой разработки
Поддержка групповой разработки является ключевым элементом любого программного инструмента ведения больших проектов. Действительно, создание корпоративной ИС может представлять собой такой крупный проект, для реализации которого при высокой организации труда и использовании современных CASE-инструментов нужны десятки или даже сотни разработчиков. Обычно задача заключается в том, чтобы проект сначала сделать целиком в виде визуальной модели, а затем разбить ее на части и раздать исполнителям для программирования. Основная проблема — как потом собирать вместе представленный программистами код. Rational Rose 98 поддерживает такую технологию определения и последующей сборки программных компонентов, которая была методологически отработана еще в предыдущих версиях продукта.
Имеются три варианта продукта Rational Rose 98:
Modeler Edition — инструмент для базового анализа архитектуры разрабатываемой системы, поддерживает моделирование, полностью совместимое с UML. Отсутствует возможность генерации программного кода по построенной визуальной модели системы.
Professional Edition — добавлена поддержка одного из языков высокого уровня (например, Си++, Java, Visual Basic). Версия продукта предназначена для компаний, в которых при разработке проекта используется только один язык программирования.
Enterprise Edition — дополнительно поддерживает многоязычную разработку, что освобождает от необходимости приобретать инструментальные средства отдельно для каждого языка программирования.
Rational Software выпустила ряд продуктов, расширяющих возможности системы Rational Rose 98:
SoDA — система, поддерживающая документирование визуальных моделей, созданных как с помощью Rational Rose 98, так и других продуктов. Обеспечивает согласованность визуальной модели и проектной документации на всех этапах разработки проекта ИС: прямого, обратного (reverse) и циклического проектирования (round-trip). Автоматически генерирует документы проекта по различным типам диаграмм, поддерживаемым в Rational Rose 98, согласно стандартам оформления, выбранным пользователем. К достоинствам продукта относятся:
— сокращение времени оформления документации в заданном стандарте за счет автоматической генерации текста и графики по модели Rational Rose;
— автоматическое обновление существующей документации при развитии проекта в ходе обратного и циклического проектирования;
— единообразное оформление документации из отчетов, создаваемых из файлов-отчетов SQA Suite, RequisitePro и Rational Rose 98;
— поддержка документов и шаблонов MS Word.
SQA Suite — продукт, обеспечивающий полный жизненный цикл тестирования клиент-серверных приложений (под Windows) и Internet-приложений, начиная от планирования и проектирования и заканчивая разработкой и поставкой созданного продукта. Это единственный продукт на рынке для проведения автоматизированного тестирования.
Обеспечивает высокую степень интеграции с Rational Rose 98 и позволяет автоматически конвертировать диаграммы прецедентов Rational Rose в требования на тестирование. Поддерживает расширяемый репозитарий тестов (БД) на базе технологии клиент-сервер. Реализует формализованную методологию тестирования, включая планирование тестов, записи сценариев тестирования и их выполнения. Поддерживает администрирование процесса исправления ошибок и модификации версий.
Requisite Pro — продукт, расширяющий поддержку групповой разработки проекта. Позволяет команде разработчиков создавать, структурировать, устанавливать приоритеты, отслеживать и контролировать изменения требований, возникающих на любом этапе разработки компонентов приложения. Поддерживается репозиторий требований с динамическим связыванием с MS Word, что позволяет управлять требованиями на продукт, спецификациями программных компонентов и планированием тестирования. Интеграция с Rational Rose 98 позволяет отслеживать внесение изменений в визуальные модели на каждом этапе проектирования: прямого, обратного (reverse) и циклического (round-trip).
Продукт предназначен для преодоления типичных системных проблем (перерасход бюджета, несоблюдение сроков, проблемы качества продукта), возникающих перед командами разработчиков, группами поддержки качества и менеджерами разработки, вовлеченными в создание сложных приложений корпоративного уровня.
В заключение хочется отметить важное обстоятельство. Использование языка UML — нового стандарта разработки визуальных моделей — делает Rational Rose 98 не только открытой системой, позволяющей обмениваться моделями с другими продуктами, использующими UML. Главное, что вокруг Rational Rose 98 как продукта-лидера в рыночной нише объектно-ориентированного CASE-инструментария сосредотачивается ряд фирм, разрабатывающих продукты-переходники (Links). Существуют такие переходники между Rational Rose 98 и Delphi 3 (Borland), Jbuilder (Borland), C++ Builder (Borland), Cafe/ (Symantec). Эти переходники позволяют проводить итерационное моделирование, используя не просто целевой язык программирования (например, Java), а основываясь уже на файлах проектов в формате соответствующих RAD-инструментариев.
Грамотное использование CASE-инструментария предполагает владение основами методологии, реализованной в CASE-продукте, которая для Rational Rose 98 называется Rational Objectory Process. Научиться работе с Rational Rose 98 можно в фирме Interface — ведущей российской фирме, обучающей CASE-технологиям. Здесь также можно получить как демонстрационную копию Rational Rose 98, так и соответствующие продукты-переходники фирм — партнеров Rational Software и материалы по UML.
Структурная или объектная декомпозиция?
Известно два подхода к проведению декомпозиции системы при построении ее информационной модели:
1) алгоритмическая декомпозиция (структурный анализ/проектирование), основанная на упорядочении событий/потоков данных;
2) объектно-ориентированная декомпозиция (ОО анализ/проектирование) базирующаяся на выделении агентов, которые или сами действуют, или с которыми производится действие.
Согласно Грэди Бучу, “ООП — этот метод реализации, в результате программы организованы как взаимодействующие коллекции объектов. Каждый объект является экземпляром некоторого класса, а все классы являются членами иерархии классов, объединенной отношением наследования. Объектно-ориентированное проектирование — это метод, включающий процесс объектно-ориентированной декомпозиции, нотацию для описания как логических, так и физических, а также как статических, так и динамических моделей проектируемой системы. Объектно-ориентированное проектирование приводит к объектно-ориентированной декомпозиции системы. Используется различная нотация для выражения разных моделей системы: логической (структура классов и объектов) и физической (модульная и процессорная архитектура)”.
Проектирование в Rational Rose 98 реализуется как дисциплинированный и упорядоченный подход, который используется для итерационного нахождения пути решения заданной проблемы. Это обеспечивает “движение модели” от требований заказчика к программной реализации. Цель проектирования состоит в том, чтобы полученная система:
— удовлетворяла заданным (возможно, неформальным) спецификациям;
— соответствовала ограничениям целевой вычислительной аппаратуры;
— удовлетворяла (явным и/или неявным) требованиям по производительности и используемым ресурсам.
При разработке системы должны быть выполнены ограничения на сам процесс проектирования по цене, времени и т. п.
При построении общей модели в Rational Rose 98 используются принципы:
— декомпозиции и абстрагирования;
— иерархии на концептуальном, логическом и физическом уровнях;
— повторного использования элементов моделей/программных компонентов;
— разработки различных типов моделей для различных аспектов системы;
— согласованности статических и динамических моделей системы;
— пошагового и итеративного моделирования/программирования;
— поддержки коллективной разработки/использования компонентов.
Источник: www.itweek.ru
Особенности рабочего интерфейса Rational Rose
В CASE-средстве Rational Rose реализованы общепринятые стандарты на рабочий интерфейс программы, подобно известным средам визуального программирования. После установки Rational Rose на компьютер пользователя, что практически не вызывает трудностей даже у начинающих, запуск этой программы в среде MS Windows 95/98 приводит к появлению на экране рабочего интерфейса (рис. 12.1).
Рис. 12.1. Общий вид рабочего интерфейса программы Rational Rose
Рабочий интерфейс Rational Rose состоит из различных элементов, основными из которых являются:
- Главное меню программы
- Окно диаграммы
- Стандартная панель инструментов
- Окно документации
- Окно браузера
- Окно журнала
- Специальная панель инструментов
Рассмотрим кратко назначение и основные функции каждого из этих элементов.
Главное меню программы
Главное меню программы выполнено в общепринятом стандарте и имеет следующий вид (рис. 12.2).
Отдельные пункты меню, назначение которых понятно из их названий, объединяют сходные операции, относящиеся ко всему проекту в целом. Некоторые из пунктов меню содержат хорошо знакомые функции (открытие проекта, вывод печать диаграмм, копирование в буфер и вставка из буфера различных элементов диаграмм). Другие настолько специфичны, что могут потребовать дополнительных усилий на изучение (опции генерации программного кода, проверка согласованности моделей, подключение дополнительных модулей).
Рис. 12.2. Внешний вид главного меню программы
Стандартная панель инструментов
Стандартная панель инструментов располагается ниже главного меню программы и имеет следующий вид (рис. 12.3). Некоторые из инструментов недоступны (новый проект не имеет никаких элементов). Стандартная панель инструментов обеспечивает быстрый доступ к тем командам меню, которые выполняются разработчиками наиболее часто.
Рис. 12.3. Внешний вид стандартной панели инструментов
Пользователь может настроить внешний вид этой панели по своему усмотрению. Для этого необходимо выбрать пункт меню Tools -> Options (Инструменты -> Параметры) и открыть вкладку Toolbars (Панели инструментов). Этим способом можно показать или скрыть различные кнопки инструментов, а также изменить их размер.
Примечание
Следует заметить, что внешний вид панели инструментов определяется не только выбором и не только видом разрабатываемой диаграммы, но и выбором графической нотации для изображения самих элементов этих диаграмм. В Rational Rose реализованы три таких нотации: UML, ОМТ и Booch. Речь идет о том, что одна и та же диаграмма может быть представлена различным образом, для этого достаточно выбрать желаемое представление через пункт меню View (Вид). При этом никаких дополнительных действий выполнять не требуется — диаграмма преобразуется в выбранную нотацию автоматически. Однако, рассматривая Rational Rose в контексте только языка UML, мы оставим без внимания особенности двух других нотаций, которые отражают эволюционный аспект этого средства.
Окно браузера
Окно браузера по умолчанию располагается в левой части рабочего интерфейса под стандартной панелью инструментов (рис. 12.4).
Браузер организует представления модели в виде иерархической структуры, которая упрощает навигацию и позволяет отыскать любой элемент модели в проекте. При этом любой элемент, который разработчик добавляет в модель, сразу отображается в окне браузера. Соответственно, выбрав элемент в окне браузера, мы можем его визуализировать в окне диаграммы или изменить его спецификацию.
Браузер позволяет также организовывать элементы модели в пакеты и перемещать элементы между различными представлениями модели. При желании окно браузера можно расположить в другом месте рабочего интерфейса либо скрыть вовсе, используя для этого пункт меню View (Вид). Можно также изменить размеры браузера, переместив мышью границу его внешней рамки.
Рис. 12.4. Внешний вид браузера
Специальная панель инструментов
Специальная панель инструментов располагается между окном браузера и окном диаграммы в средней части рабочего интерфейса. По умолчанию предлагается панель инструментов для построения диаграммы классов модели (рис. 12.5).
Рис. 12.5. Внешний вид специальной панели инструментов для диаграммы классов
Расположение специальной панели инструментов можно изменять, переместив рамку панели в нужное место. Можно настраивать и состав панели, добавляя или удаляя отдельные кнопки, соответствующие тем или иным инструментам. Назначения кнопок можно узнать из всплывающих подсказок, появляющихся после задержки указателя мыши над соответствующей кнопкой.
Окно диаграммы
Окно диаграммы является основной рабочей областью ее интерфейса, в которой визуализируются различные представления модели проекта. По умолчанию окно диаграммы располагается в правой части рабочего интерфейса, однако его расположение и размеры также можно изменить. При разработке нового проекта, если не был использован мастер проектов, окно диаграммы представляет собой чистую область, не содержащую никаких элементов модели (рис. 12.6).
Название диаграммы, которая располагается в данном окне, указывается в строке заголовка программы (самая верхняя строка программы) или, если окно не развернуто во весь экран, в строке заголовка окна диаграммы. Одновременно в окне диаграммы могут присутствовать несколько диаграмм, однако активной может быть только одна из них. Например, на рис.
12.6 активной является диаграмма развертывания, хотя имеются и другие диаграммы. Переключение между диаграммами можно осуществить выбором нужного представления на стандартной панели инструментов либо через пункт меню Window (Окно). При активизации отдельного вида диаграммы изменяется внешний вид специальной панели инструментов, которая настраивается под конкретный вид диаграммы.
Рис. 12.6. Внешний вид окна диаграмм с различными видами представлений модели
Окно документации
Окно документации по умолчанию может не присутствовать на экране. В этом случае оно может быть активизировано через пункт меню View -> Documentation (Вид->Документация), после чего появится ниже браузера (рис. 12.7).
Окно документации, как следует из его названия, предназначено для документирования элементов представления модели. В него можно записывать самую различную информацию, и что важно — на русском языке. Эта информация в последующем преобразуется в комментарии и никак не влияет на логику выполнения программного кода.
В окне документации активизируется та информация, которая относится к отдельному выделенному элементу диаграммы. При этом выделить элемент можно либо в окне браузера, либо в окне диаграммы. При добавлении нового элемента на диаграмму (например, класса) автоматически генерируется документация к нему, которая является пустой (No documentation). В последующем разработчик самостоятельно вносит необходимую пояснительную информацию, которая запоминается и может быть изменена в ходе работы над проектом.
Так же, как и для других окон рабочего интерфейса, можно изменять размеры и положение окна документации.
Рис. 12.7. Внешний вид окна документации
Окно журнала
Окно журнала (Log) предназначено для автоматической записи различной служебной информации, образующейся в ходе работы с программой. В журнале фиксируется время и характер выполняемых разработчиком действий, таких как обновление модели, настройка меню и панелей инструментов, а также сообщений об ошибках, возникающих при генерации программного кода.
Окно журнала всегда присутствует на рабочем интерфейсе в области окна диаграммы (рис. 12.8). Однако оно может быть закрыто другими окнами с диаграммами или быть свернутым. Активизировать окно журнала можно через меню Window->Log (Окно->Журнал). В этом случае оно изображается поверх других окон в правой области рабочего интерфейса.
Полностью удалить это окно нельзя, его можно только минимизировать.
Источник: www.znannya.org
Описание, преимущества Rational Rose Enterprise Edition
Rational Rose Enterprise Edition — является по моему мнению наиболее удобным визуальным CASE средством проектирования информационных системна языке UML.
Появление на рынке программных продуктов первых CASE-средств (Computer Aided Software Engineering) ознаменовало новый этап развития программной инженерии, характерными особенностями которого являются существенное сокращение сроков разработки программных проектов, реализация проектов группой программистов и ориентация на визуальные средства специфицирования компонентов программного обеспечения.
Классической областью применения этих средств стали приложения баз данных, особенно те из них, которые требовали серьезных усилий при разработке своих концептуальных схем. Поддержка возможности автоматической генерации программного кода на основе предварительно разработанной концептуальной схемы оказалась настолько конструктивной, что стимулировала появление более двух десятков CASE-средств различных фирм.
Среди всех фирм-производителей CASE-средств именно компания Rational Software Coip. одна из первых осознала стратегическую перспективность развития объектно-ориентированных технологий анализа и проектирования программных систем. Эта компания выступила инициатором унификации языка визуального моделирования в рамках консорциума OMG, что, в конечном итоге, привело к появлению первых версий языка UML. И эта же компания первой разработала инструментальное объектно-ориентированное CASE-средство, в котором был реализован язык UML как базовая нотация визуального моделирования.
В рамках Rational Rose существуют различные программные инструментарии, отличающиеся между собой диапазоном реализованных возможностей. Существует в четырех основных модификациях:
Rational Rose Enterprise Edition
Rational Rose Professional Edition
Rational Rose Modeler Edition
Rational Rose для UNIX
В последующих версиях, аккумулируют практически все современные достижения в области информационных технологий:
Интеграция с MS Visual Studio 6, что включает в себя поддержку на уровне прямой и обратной генерации кодов и диаграмм VB 6, Visual C++ 6, Visual J++ 6 (ATL-Microsoft Active Template Library, Web-Classes, DHTML, Data Connections).
Непосредственная работа (инжиниринг и реинжиниринг) с исполняемыми модулями и библиотеками форматов EXE, DLL, TLB, OCX.
Поддержка технологий MTS (Microsoft Transaction Server) и ADO (ActiveX Data Objects) на уровне шаблонов и исходного кода, а также элементов стратегической технологии Microsoft — СОМ+ (DCOM).
Полная поддержка CORBA 2.2, включая реализацию технологии компонентной разработки приложений CBD (Component-Based Development), языка определения интерфейса IDL (Interface Definition Language) и языка определения данных DDL (Data Definition Language).
Полная поддержка среды разработки Java-приложений JDK 1.2, включая прямую и обратную генерацию классов Java формата JAR, а также работу с файлами форматов CAB и ZIP.
Уже этого перечня основных особенностей может оказаться достаточно, чтобы сделать вывод о достижении совершенно нового уровня реализации CASE-технологий, когда само инструментальное средство становится не только рабочим инструментом, но и своеобразной базой данных для практически всех современных объектных стандартов и компонентных интерфейсов.
Назначение языка UML
Язык UML предназначен для решения следующих задач:
Предоставить в распоряжение пользователей легко воспринимаемый и выразительный язык визуального моделирования, специально предназначенный для разработки и документирования моделей сложных систем самого различного целевого назначения.
Речь идет о том, что важным фактором дальнейшего развития и повсеместного использования методологии ООАП(объектно-орентированый анализ и проектирование) является интуитивная ясность и понятность основных конструкций соответствующего языка моделирования. Язык UML включает в себя не только абстрактные конструкции для представления метамоделей систем, но и целый ряд конкретных понятий, имеющих вполне определенную семантику. Это позволяет языку UML одновременно достичь не только универсальности представления моделей для самых различных приложений, но и возможности описания достаточно тонких деталей реализации этих моделей применительно к конкретным системам.
Снабдить исходные понятия языка UML возможностью расширения и специализации для более точного представления моделей систем в конкретной предметной области.
Хотя язык UML является формальным языком — спецификаций, формальность его описания отличается от синтаксиса как традиционных формально-логических языков, так и известных языков программирования. Разработчики из OMG предполагают, что язык UML как никакой другой может быть приспособлен для конкретных предметных областей. Это становится возможным по той причине, что в самом описании языка UML заложен механизм расширения базовых понятий, который является самостоятельным элементом языка и имеет собственное описание в форме правил расширения.
Язык UML допускает также специализацию базовых понятий. Речь идет о том, что в конкретных приложениях пользователи должны уметь дополнять имеющиеся базовые понятия новыми характеристиками или свойствами, которые не противоречат семантике этих понятий в языке UML.
Описание языка UML должно поддерживать такую спецификацию моделей, которая не зависит от конкретных языков программирования и инструментальных средств проектирования программных систем.
Речь идет о том, что ни одна из конструкций языка UML не должна зависеть от особенностей ее реализации в известных языках программирования. То есть, хотя отдельные понятия языка UML и связаны с последними очень тесно, их жесткая интерпретация в форме каких бы то ни было конструкций программирования не может быть признана корректной. Другими словами, разработчики из OMG считают необходимым свойством языка UML его контекстно-программную независимость.
С другой стороны, язык UML должен обладать потенциальной возможностью реализации своих конструкций на том или ином языке программирования. Конечно, в первую очередь имеются в виду языки, поддерживающие концепцию ООП, такие как C++, Java, Object Pascal. Именно это свойство языка UML делает его современным средством решения задач моделирования сложных систем. В то же время, предполагается, что для программной поддержки конструкций языка UML могут быть разработаны специальные инструментальные CASE-средства. Наличие последних имеет принципиальное значение для широкого распространения и использования языка UML.
Описание языка UML должно включать в себя семантический базис для понимания общих особенностей ООАП.
Говоря об этой особенности, имеют в виду самодостаточность языка UML для понимания не только его базовых конструкций, но что не менее важно — понимания общих принципов ООАП. В этой связи необходимо отметить, что поскольку язык UML не является языком программирования, а служит средством для решения задач объектно-ориентированного моделирования систем, описание языка UML должно по возможности включать в себя все необходимые понятия для ООАП. Без этого свойства язык UML может оказаться бесполезным и невостребованным большинством пользователей, которые не знакомы с проблематикой ООАП сложных систем.
С другой стороны, какие бы то ни было ссылки на дополнительные источники, содержащие важную для понимания языка UML информацию, по мнению разработчиков из OMG, должны быть исключены. Это позволит избежать неоднозначного толкования принципиальных особенностей процесса ООАП и их реализации в форме базовых конструкций языка UML.
Поощрять развитие рынка объектных инструментальных средств.
Способствовать распространению объектных технологий и соответствующих понятий ООАП.
Эта задача тесно связана с предыдущей и имеет с ней много общего. Если исключить из рассмотрения рекламные заявления разработчиков об исключительной гибкости и мощности языка UML, а попытаться составить объективную картину возможностей этого языка, то можно прийти к следующему заключению. Следует признать, что усилия, достаточно большой группы разработчиков были направлены на интеграцию в рамках языка UML многих известных техник визуального моделирования, которые успешно зарекомендовали себя на практике (см. главу 2). Хотя это привело к усложнению языка UML по сравнению с известными нотациями структурного системного анализа, платой за сложность являются действительно высокая гибкость и изобразительные возможности уже первых версий языка UML. В свою очередь, использование языка UML для решения всевозможных практических задач будет только способствовать его дальнейшему совершенствованию, а значит и дальнейшему развитию объектных технологий и практики ООАП.
Интегрировать в себя новейшие и наилучшие достижения практики ООАП.
Язык UML непрерывно совершенствуется разработчиками, и основой этой работы является его дальнейшая интеграция с современными модельными технологиями. При этом различные методы системного моделирования получают свое прикладное осмысление в рамках ООАП. В последующем эти методы могут быть включены в состав языка UML в форме дополнительных базовых понятий, наиболее адекватно и полно отражающие наилучшие достижения практики ООАП.
Чтобы решить указанные выше задачи, за свою недолгую историю язык UML претерпел определенную эволюцию. В результате описание самого языка UML стало нетривиальным, поскольку семантика базовых понятий включает в себя целый ряд перекрестных связей с другими понятиями и конструкциями языка. В связи с этим так называемое линейное или последовательное рассмотрение основных конструкций языка UML стало практически невозможным, т. к. одни и те же понятия могут использоваться при построении различных диаграмм или представлений. В то же время каждое из представлений модели обладает собственными семантическими особенностями, которые накладывают отпечаток на семантику базовых понятий языка в целом.
Общая структура языка UML
С самой общей точки зрения описание языка UML состоит из двух взаимодействующих частей, таких как:
Семантика языка UML. Представляет собой некоторую метамодель, которая определяет абстрактный синтаксис и семантику понятий объектного моделирования на языке UML.
Нотация языка UML. Представляет собой графическую нотацию для визуального представления семантики языка 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)
Диаграмма функций IDEF0
Применительно к моей системе EDEFO используется для анализа функций, выполняемых системой и отображения механизмов, посредством которых эти функции выполняются. Двумя наиболее важными компонентами, из которых строятся диаграммы EDEFO, являются бизнес-функции или работ! (представленные на диаграммах в виде прямоугольников) и данные и объекты (изображаемые в виде стрелок), связывающие между собой работы. При этом стрелки, в зависимости от того в какую грань прямоугольника работы они входят или из какой грани выходят, делятся на пять видов:
Стрелки входа (входят в левую грань работы) — изображают данные или объекты, изменяемые в ходе выполнения работы.
1.Детальный заказ клиента
2.Запчасти от поставщика
4.Регистрационные данные клиента
Стрелки управления (входят в верхнюю грань работы) — изображают правила и ограничения, согласно которым выполняется работа.
2.Список зарегистрированных клиентов
4.Список запчастей на складе
Стрелки выхода (выходят из правой грани работы) — изображают данные или объекты, появляющиеся в результате выполнения работы.
2.Документы подлежащие к оплате клиентом
3.Список для доставки необходимых запчастей
5.Дкументы подтверждающие выполнения заказа
Стрелки механизма (входят в нижнюю грань работы) — изображают ресурсы, необходимые для выполнения работы, но не изменяющиеся в процессе работы (например, оборудование, людские ресурсы. )
Стрелки вызова (выходят из нижней грани работы) — изображают связи между разными диаграммами или моделями, указывая на некоторую диаграмму, где данная работа рассмотрена более подробно.
Контекстная диаграмма IDEF0
Источник: infopedia.su