Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Аннотация

В данной пояснительной записке содержится описание результатов дипломного проектирования на тему «Разработка встроенного модуля среды Rational Rose для автоматизированного преобразования диаграмм деятельностей в диаграммы Use case». Главной целью этой работы было изучение особенностей и методик моделирования сложных программных систем в CASE Rational Rose и разработка технологии автоматизации некоторых стадий этого процесса. Итогом проделанной работы является разработанный программный модуль и данная пояснительная записка.

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

Раздел «Постановка задачи» содержит подразделы, описывающие методы моделирования в системе Rational Rose, описание нотаций диаграмм, а также требования, предъявляемые к разрабатываемой системе.

Далее, в разделе «Использование средства разработки», приводятся сведения о принципах выбора средства разработки для реализации поставленной задачи и особенности интегрированной среды разработки Borland Delphi 5.

Описание технологии COM, используемой для доступа из ИСР Delphi к ресурсам Rational Rose, приводится в разделе «Организация взаимодействия Delphi с Rational Rose».

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

Разработанная система признана годной к эксплуатации. В разделе «Тестирование и отладка» содержится информация о методике проверки правильности преобразования диаграмм и о возможностях отладчика ИСР Delphi 5.

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

Содержание

• Введение
• 1. Постановка задачи
• 1.1 Задачи моделирования предметной области с помощью UML
• 1.2 Описание нотаций диаграмм
• 1.3 Требования к системе
• 2. Использование средства разработки
• 2.1 Выбор средства разработки
• 2.2 Описание Delphi 5
• 2.2.1 Описание среды Delphi
• 2.2.2 Язык Object Pascal
• 3. Организация взаимодействия Delphi с Rational Rose
• 4. Описание реализации
• 4.1 Использование системы
• 5. Тестирование и отладка
• Заключение
• Приложения

Введение

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

- компонентную технологию разработки моделей ИС;

- визуальное программирование (RAD-средства);

- визуальное представление различных аспектов проекта (визуальное моделирование, CASE-средства).

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

Современные RAD-средства программирования используют библиотеки компонентов, позволяющих повторно применять отлаженный программный код, что значительно облегчает сборку программных приложений. Такое “сборочное программирование” стало возможным за счет объектного подхода и привело к изменению организации жизненного цикла разрабатываемой информационной системы. Новые модели жизненного цикла предполагают минимальное время кодирования, больше времени уделяя моделированию системы.

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

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

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

Одним из признанных лидеров в области средств и методов визуального моделирования является фирма Rational Software (США). В её продуктах используется так называемый унифицированный язык моделирования (Unified Modeling Language - UML). В UML определен набор диаграмм, позволяющий представить различные взгляды на проектируемую программную систему. Он включает:

- диаграммы классов (class diagram);

- диаграммы вариантов использования (use case diagram);

- поведенческие диаграммы (behavior diagrams), - деятельностей (activity diagram), последовательностей (sequence diagram) и сотрудничества (collaboration diagram);

- диаграммы реализации (implementation diagrams), включающие диаграммы компонентов (component diagram) и распределения (deployment diagram).

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

В данной работе будут рассмотрены диаграммы деятельностей и автоматическое преобразование их в диаграммы классов и диаграммы use-case.

1. Постановка задачи

1.1 Задачи моделирования предметной области с помощью UML

rational rose borland delphi система

Объектом исследования в данной работе является CASE-средство Rational Rose. Это основной продукт фирмы Rational Software - признанного лидера в области объектных методологий. Средство предназначено для разработки и поддержания сложных автоматизированных информационных систем. Цель проектирования состоит в том, чтобы полученная система:

1) Удовлетворяла заданным (возможно неформальным) спецификациям.

2) Соответствовала ограничениям целевой вычислительной аппаратуры.

3) Удовлетворяла (явным и/или неявным) требованиям на производительность и используемые ресурсы.

4) При ее разработке были выполнены ограничения на сам процесс проектирования по цене, времени, и т.п.

В основе методологии проектирования Rational Rose лежит унифицированный язык моделирования (UML), разработанный в 1997 году консорциумом из множества фирм-разработчиков программного обеспечения. Он стал промышленным стандартом моделирования, что многократно повышает важность CASE-средств, которые основаны на UML. При построении общей модели в Rational Rose используются принципы:

- декомпозиции и абстрагирования;

- иерархии на концептуальном, логическом и физическом уровнях;

- повторного использования элементов моделей/программных компонент;

- разработки различных типов моделей для различных аспектов системы;

- согласованности статических и динамических моделей системы;

- пошаговое и итеративное моделирование/программирование.

Традиционно, при проектировании автоматизированной информационной системы в среде Rational Rose, необходимо построить ряд диаграмм, отражающих разные стороны проекта. В частности, для описания динамики работы проектируемой системы надо построить набор диаграмм деятельностей разной степени детализации. На таких диаграммах изображаются виды деятельности, связанные с решением задачи, подлежащей автоматизации, входные и выходные документы или данные, связанные с конкретной деятельностью, исполнители деятельности и подразделения, в которых она выполняется. На основе этого требуется определить и зафиксировать функциональные требования к системе и отразить их в диаграммах Use-Case.

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

1. Возможность выдержать единый стиль диаграмм;

2. Возможность автоматизации преобразования и обработки диаграмм;

3. Возможность внедрения формальных способов контроля;

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

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



1.2 Описание нотаций диаграмм

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

Моделирование проводится как "поуровневый спуск" от концептуальной модели к логической, а затем к компонентной модели программной системы. Концептуальная модель выражается в виде "диаграмм прецедентов" (use case diagram). Этот тип диаграмм служит для проведения итерационного цикла общей постановки задачи вместе с заказчиком.

Техника Прецедентов Использования (Use-case) - была впервые предложена Айваром Якобсоном в 1992 и быстро завоевала всеобщее признание за счет простоты и легкости восприятия и применения. Суть ее состоит в следующем: проектируемая система представляется в виде наборов Актеров, взаимодействующих с системой с помощью так называемых use-case. Актером является любая сущность, взаимодействующая с системой извне. Им может быть человек, оборудование, другая система, то есть мы определяем, что взаимодействует с системой. Графическое обозначение актера представляет собой схематичное изображение человека и название (рис.1).

В свою очередь Use-case описывает, что система предоставляет актеру, то есть определяет некоторый набор транзакций, совершаемый актером при диалоге с системой, при этом ничего не говориться о том, каким образом будет реализовано взаимодействие. Графическое изображение Use Case представляет собой горизонтальный овал с названием внизу. На рисунке 1 представлен пример диаграммы Use Case.



Рисунок 1. Диаграмма UseCase

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

- Вложенная диаграмма прецедентов (диаграмма функций, use case diagram);

- Диаграмма взаимодействия объектов (Collaboration diagram);

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

- Диаграмма классов (Class diagram);

- Диаграмма перехода состояний (State diagram).

Далее будут рассмотрены некоторые виды диаграмм, необходимые для понимания проблематики данного проекта.

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

Рисунок 2. Пример диаграммы классов

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

Диаграммы деятельностей устраняют следующие недостатки блок-схем:

1. Невозможно отобразить операции, выполняющиеся параллельно;

2. Нельзя явно задать область ответственности для классов системы;

3. Невозможно правильно и наглядно отобразить работу в событийно-ориентированной среде.

Графическая нотация включает:

1. Дорожка (Swim lane) - делит диаграмму вертикальными линиями на поименованные области, задавая ответственность класса, указанного в названии.

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

3. Состояние (State)

4. Линейка синхронизации (Synchronization) - показывает момент синхронизации параллельно выполняющихся процессов. Изображается утолщенной горизонтальной или вертикальной линией.

5. Принятие решения (Decision) - условный переход. В отличие от классического блока перехода имеется возможность более гибко варьировать условия перехода, задавая более двух направлений. Главная особенность в том, что обязательно должно выполнится одно из условий. Изображается ромбом.

6. Переход (Transition) - отношение между двумя состояниями или деятельностями. С его помощью организуется связь по управлению между элементами диаграммы. Обозначается стрелкой.

Кроме диаграмм действий и состояний, в разделе диаграмм поведения предусмотрено два типа диаграмм, отвечающих за описание взаимодействия объектов системы:

· Диаграмма Следования

· Диаграмма Кооперации

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

Для Диаграмм Кооперации главным является возможность отобразить не столько последовательность взаимодействия, сколько все окружение объектов, участвующих в нем. То есть, показаны не только посылаемые и принимаемые сообщения, но и косвенные связи между ассоциированными объектами. Говорят, что Диаграммы Кооперации описывают полный контекст взаимодействия и представляет собой своеобразный временной "срез" конфигурации сети объектов, взаимодействующих для выполнения определенной бизнес-цели программной системы. Диаграмма кооперации изображает объекты, участвующие во взаимодействии, в виде прямоугольников, содержащих имя объекта, его класс и, возможно, значение атрибутов. Ассоциации между объектами, как и на диаграммах классов, изображаются в виде соединительных линий. Возможно указание имени ассоциации и ролей, которые играют объекты в данной ассоциации. Динамические связи - потоки сообщений, представляются также в виде соединительных линий между объектами, сверху которых располагается стрелка с указанием направления и имени сообщения. Отдельно используются диаграммы, призванные осветить вопросы, связанные с физической реализацией системы:

· Диаграмма Компонент

· Диаграмма Размещения

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

Таким образом, язык UML предоставляет нам полный набор инструментов, необходимый нам для описания предметной области и моделирования автоматизированной системы.

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

1. Формулировка задач, подлежащих автоматизации;

2. Описание бизнес процессов по каждой сформулированной задаче. Описание бизнес процессов должно производиться с использованием диаграмм деятельности (activity diagram);

3. На основе бизнес процессов определение бизнес требований по автоматизации предприятия, т.е. определение видов деятельности предприятия, подлежащих автоматизации;

4. На основе бизнес требований описание структуры автоматизируемого предприятия с использованием диаграммы функций (use case diagram). На диаграмме функций (use case diagram) должно быть замоделировано:

действующие лица и их бизнес функции, подлежащие автоматизации с использованием элементов бизнес актер (business actor), бизнес работник (business worker), бизнес функция (business use case);

документы с использованием элементов бизнес сущностей (business entity);

сценарии функций с использованием диаграмм последовательностей (sequence diagram) или диаграмм деятельности (activity diagram);

состояния документов с использованием диаграмм деятельности (activity diagram);

бизнес правила, включая алгоритмы, с использованием диаграмм деятельности (activity diagram) и элементов бизнес сущностей (business entity).

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

1. Диаграмма деятельностей должна иметь начало и конец.

2. На одной диаграмме следует отображать не более 8-10 видов деятельности. Для этого необходимо декомпозировать отдельные виды деятельности. На декомпозирующей диаграмме должны быть отражены разделительные линии.

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

4. Начальная точка должна именоваться аналогично.

5. Конечная точка должна иметь название деятельности, следующее за декомпозированной.

6. Нельзя в одном элементе Activity указывать несколько видов деятельности, например, «формирует товарный отчет и проводки, получает и передает акт о недостаче».

7. Условия на переходах, соединяющих деятельности и состояния, должны указываться строчными буквами.

Выполнение этих соглашений позволит значительно повысить качество и позволит избежать множество ошибок на ранних стадиях проектирования.

1.3 Требования к системе

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

1. Всем деятельностям (activity), которые находятся на диаграмме, должны быть определены стереотипы. Причем нельзя присваивать одинаковые стереотипы деятельностям разных уровней.

2. Переходы должны идти: От деятельностей первого уровня к соответствующим деятельностям второго и третьего уровня. От деятельностей третьего уровня к деятельностям четвертого уровня.

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

1. Первый уровень становится пакетами (packages);

2. Деятельности второго уровня становятся на диаграмме use-case актерами (actors);

3. Деятельности третьего уровня становятся Use-case;

4. Документы (четвертый уровень) должны лечь на диаграмму классов под соответствующим use-case и получить название: Документы <имя use-case>;

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

Задача признана оправданной и принята к исполнению.



2. Использование средства разработки

2.1 Выбор средства разработки

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

- Соответствие требованиям концепции RAD (быстрая разработка приложений);

- Работа в операционной системе Windows (версии 95, 98 и NT);

- Поддержка работы с серверами COM;

- Возможность быстрого освоения разработчиком;

- Оправданная стоимость.

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

- Наличие интегрированной среды разработки (ИСР);

- Объектно-ориентированный базовый язык программирования;

- Использование библиотеки компонентов, позволяющих повторно применять отлаженный программный код;

- Визуальный стиль проектирования интерфейса;

- Наличие галерей форм и шаблонов приложений;

- Интеграция с другими продуктами через поддержку COM, DDE, создание и использование DLL.

Технология COM представляет собой возможность работы с компонентной моделью объекта. Это модель объекта в системном обеспечении, которая предусматривает полную совместимость во взаимодействии между компонентами, написанными разными компаниями и на разных языках. Главная особенность этой модели - это автоматизация OLE, которая обеспечивает доступ к объектам приложения и манипуляцию ими извне. Такие объекты, предоставленные (экспонированные) для внешнего пользования называются автоматными объектами OLE, а приложение - сервером автоматизации.

В результате исследования было найдено два средства, отвечающих указанным требованиям: Microsoft Visual Basic и Inprise Delphi 5. Оба эти средства обеспечивают визуальный стиль проектирования интерфейса, работают в среде Windows и хорошо с ней интегрированы.

Легкость в освоении разработчиком достигается использованием в качестве базовых языков - объектных версий классических языков программирования. Visual Basic, как видно из названия, основан на языке BASIC (Бейсик). В основе Delphi лежит объектное расширение языка Паскаль - Object Pascal.

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

Сравнительное тестирование Visual Basic и Delphi 5 выявило следующие недостатки Visual Basic:

- Низкая производительность разрабатываемых приложений;

- Низкая скорость компиляции;

- Недостаточная строгость и объектная ориентированность языка.

Delphi базируется на языке Object Pascal. Компиляторы с языков семейства Паскаль фирмы Borland (начиная с Turbo Pascal 1.0) были одними из самых быстрых компиляторов. В настоящее время Object Pascal - это объектно-ориентированный язык с твердой опорой в виде хорошего компилятора. По заявлениям фирмы-разработчика скорость компиляции - до 350000 строк кода в минуту (на Pentium 90).

В итоге в качестве средства разработки приложения была выбрана среда Inprise Delphi 5.

2.2 Описание Delphi 5

2.2.1 Описание среды Delphi

Среда Delphi основана на спецификации, называемой Single Document Interface (SDI), и состоит из нескольких отдельно расположенных окон. Это было сделано из-за того, что SDI близок к той модели приложений, что используется в Windows 95. Общий вид рабочего места разработчика представлен на рис. 1.

Рисунок 1. Интерфейс Delphi 5

Среда Delphi включает следующие составляющие:

1) Дизайнер Форм (Form Designer);

2) Окно Редактора Исходного Текста (Editor Window);

3) Палитра Компонент (Component Palette);

4) Инспектор Объектов (Object Inspector).

Дизайнер форм - средство, для создания визуального интерфейса программы. Работа над интерфейсом заключается в «перетаскивании» мышью необходимых элементов с палитры компонент на бланк формы (рис.2). Использовать можно все стандартные для Windows элементы: кнопки, полосы прокрутки, меню, надписи и. т. п. На форму также можно поместить невизуальные компоненты: таймер, компоненты доступа к данным.

Рисунок 2. Пустой бланк формы

Редактор исходного текста в Delphi обладает возможностью не только редактировать текст программы, но и развитыми средствами навигации.

Палитра Компонент (см. рис.3) позволяет выбрать нужные объекты для размещения их на Дизайнере Форм. Палитра использует постраничную группировку объектов. Внизу Палитры находится набор закладок - Standard, Additional, Dialogs и т.д.

Рисунок 3. Палитра компонентов

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

Рисунок 4. Инспектор Объектов

2.2.2 Язык Object Pascal

Язык Object Pascal - это объектно-ориентированный язык программирования, основанный на классическом языке Паскаль. Так как в Object Pascal соблюдается преемственность, то будут рассмотрены только новые возможности языка, использованные при реализации поставленной задачи.

Класс Object Pascal - основной элемент программирования в Delphi. В классе в одно целое объединяются данные и код, образуя единый компонент. Как и структурные типы Паскаля, класс сам по себе не является типом. Подобно типу record, тип class состоит из более мелких частей (элементов). Класс, по существу, является набором таких элементов. Классы известны также как объектные типы. Конкретный образец класса - объект. Однако ввиду модели адресации объекта это не вполне идентично переменной типа class. С функциональной точки зрения класс можно разделить на следующие компоненты:

- Поля - аналогичны полям record, но без вариантных частей;

- Методы - процедуры и функции для обработки полей объекта;

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

В отличие от других типов, тип class можно объявлять только глобально. Object Pascal запрещает определение класса в некоторых участках. В частности, нельзя делать такие объявления в разделе объявления переменных var, а также внутри процедур или функций. Синтаксис объявления следующий:

Туре

<имя класса> = Class (<имя класса - родителя>)

public {доступно всем}

<поля, методы, свойства, события>

published {видны в Инспекторе Объекта и изменяемы}

<поля, свойства>

protected {доступ только потомкам}

<поля, методы, свойства, события>

private {доступ только в модуле}

<поля, методы, свойства, события>

end;

Имя класса может быть любым допустимым идентификатором. Но принято идентификаторы большинства классов начинать с символа "T". Имя класса - родителя может не указываться. Тогда предполагается, что данный класс является непосредственным наследником TObject - наиболее общего из предопределенных классов.

Каждому классу, за исключением самого первого, должен предшествовать класс-родитель. В свою очередь, любой класс можно использовать для создания других классов, и он в этом случае будет являться их родителем. В Delphi у класса бывает только один родитель, в C++ родителей может быть несколько. Поэтому в Delphi классы образуют иерархическое дерево с классом TObject в роли корня.

Класс наследует поля, методы, свойства, события от своих предков и может отменять какие-то из этих элементов класса или вводить новые. Доступ к объявляемым элементам класса определяется тем, в каком разделе они объявлены.

Раздел public (открытый) предназначен для объявлений, которые доступны для внешнего использования. Это открытый интерфейс класса. Раздел published (публикуемый) содержит открытые свойства, которые появляются в процессе проектирования на странице свойств Инспектора Объектов и которые, следовательно, пользователь может устанавливать в процессе проектирования. Раздел private (закрытый), содержит объявления полей, процедур и функций, используемых только внутри данного класса. Раздел protected (защищенный) содержит объявления, доступные только для потомков объявляемого класса. Как и в случае закрытых элементов, можно скрыть детали реализации защищенных элементов от конечного пользователя. Однако, в отличие от закрытых, защищенные элементы остаются доступны для программистов, которые захотят производить от этого класса производные объекты, причем не требуется, чтобы производные объекты объявлялись в этом же модуле.

Объявления полей выглядят так же, как объявления переменных или объявления полей в записях:



<имя поля>: <тип>;

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

TMyClass=class(TObject)

class procedure DoSomething(K:integer);

{Class method}

function AddOne(N:integer):integer; {Keywords class

absent - means method}

end;

…

implementation

…

class procedure TMyClass.DoSomething(K:integer);

begin

…

end;

function TMyClass.AddOne(N:integer):integer;

begin

…

end;

Классовые методы можно вызывать без создания экземпляра класса. Разновидность классовых методов - конструкторы - используются для создания рабочих копий (экземпляров) класса. Классовый метод полностью характеризуется одним адресом (указателем) в памяти, в этом его отличие от других методов класса. Процессор просто передает управление по этому адресу при вызове соответствующего метода. В классовых методах (но не в конструкторах!) нельзя использовать классовые переменные: они становятся доступными только после создания экземпляра класса, а классовый метод можно вызывать, не создавая экземпляр. Главное отличие обычных методов от классовых заключается в том, что они могут работать с классовыми переменными, то есть с переменными, которые определены в классе (см. выше). Эти методы характеризуются уже двумя адресами: адресом метода и адресом данных. Второй адрес необходим потому, что для обслуживания всех созданных экземпляров класса используется единственная копия метода в памяти. Методы загружаются сразу же после старта приложения. При создании каждого нового экземпляра данного класса он пользуется уже загруженными в память методами. При этом для работы с классовыми переменными каждому методу незаметно для программиста передается ссылка на данные, и таким образом достигается экономия ресурсов: при создании новых экземпляров класса память выделяется только для хранения переменных.

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

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

Для перехвата исключений и защиты ресурсов в Object Pascal предусмотрены две конструкции:

1) Конструкция try...finally:

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

{начало блока try...finally}

................

finally

................

end;

Операторы раздела finally будут выполняться независимо от того, было или не было сгенерировано исключение при выполнении операторов раздела try. Если где-то в разделе try произошла ошибка и сгенерировано исключение, то выполнение блока try прерывается и управление немедленно передается разделу finally. Даже если при выполнении операторов раздела finally случилась ошибка, операторы этого раздела все-таки выполняются до конца.

Обычно в раздел finally помещают операторы, необходимые для того, чтобы: освободить динамически выделенную память, закрыть ненужные файлы, удалить временные файлы и т.д. Если не помещать такие операторы в защищенный раздел finally, то из-за прерывания выполнения вследствие возможных ошибок они могут оказаться не выполненными, что приведет к "утечке ресурсов".

В блок try...finally не включаются обработки исключений. При выполнении операторов раздела finally неизвестно, было или не было сгенерировано исключение. Для обработки исключений используются блоки try...except, которые никак не связаны с блоками try...finally. Впрочем, эти виды блоков могут использоваться совместно.

2) Конструкция try...except:

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

Раздел except может использоваться двумя способами. При первом способе в нем могут располагаться любые выполняемые операторы, кроме обработчиков исключений on...do. Это могут быть операторы сообщений об ошибке, операторы освобождения ресурсов и т.д. Второй и главный способ использования раздела except - обработка исключений. В этом случае в него могут включаться только обработчики исключений: операторы on...do и необязательный обработчик любых исключений, предваряемый ключевым словом else. При наличии такого обработчика блок имеет вид:

try

{Исполняемый код}

except

on ............;

on ............;

else <обработчик всех не перехваченных ранее событий>;

end;

Если при выполнении операторов раздела try генерируется исключение, выполнение этого раздела прерывается и управление передается операторам раздела except. Если среди обработчиков встретился соответствующий сгенерированному исключению, выполняется оператор этого обработчика, исключение разрушается и управление передается оператору, следующему за блоком on...do, т.е. оператору, следующему за последним оператором блока end. Если же обработчик не нашелся, то управление передается на следующий уровень, т.е. разделу except следующего обрамляющего блока try...except (если таковой есть).

Технология Component Object Model является важнейшим фактором интеграции разрабатываемых приложений.

В технологии COM приложение предоставляет для использования свои службы, применяя для этого объекты COM. Каждый объект имеет один или несколько интерфейсов, которые обеспечивают доступ к его свойствам и выполнение его операций. Клиент получает доступ к службам объекта только через интерфейс и его методы. Поэтому любой клиент может работать с любым объектом, независимо от среды разработки. Согласно спецификации COM, уже созданный интерфейс не может быть изменен ни при каких обстоятельствах. Это гарантирует постоянную работоспособность приложений на основе COM, не взирая на любые модернизации. Объявление интерфейса включает в себя описание методов и их параметров, но не включает их реализации. Кроме того, в объявлении может указываться идентификатор интерфейса -- уникальное 16-байтовое число, сгенерированное по специальным правилам, гарантирующим его статистическую уникальность (GUID -- Global Unique Identifier). Интерфейсы могут наследоваться. Наследование интерфейсов -- это декларация, указывающая, что унаследованный интерфейс должен включать в себя все методы предка. Для поддержки интерфейсов Delphi расширяет синтаксис языка Pascal дополнительными ключевыми словами. Объявление интерфейса в Delphi реализуется ключевым словом interface:

type

IMyInterface = interface

['{412AFF00-5C21-11D4-84DD-C8393F763A13}']

procedure DoSomething(var I: Integer); stdcall;

function DoSomethingAnother(S: String): Boolean;

end;

IMyInterface2 = interface(IMyInterface)

['{412AFF01-5C21-11D4-84DD-C8393F763A13}']

procedure DoAdditional(var I: Integer); stdcall;

end;

Для ссылки на различные типы серверов COM компания Microsoft ввела новый термин - ActiveX. Он используется для ссылок на OLE, элементы управления ActiveX и активные документы.

Для получения клиентом информации о интерфейсах объектов COM их разработчик может распространять вместе с объектом информацию о типе. Эта информация содержится в библиотеке типов, которая создается при помощи специального языка описания интерфейса (Interface Definition Language, IDL). В Delphi в качестве основного варианта применяется синтаксис и операторы Object Pascal. То есть библиотеки типов преобразуются из IDL в Object Pascal и обратно.

Delphi 5 при импорте библиотек типов в приложения предоставляет возможность установить COM-серверы в палитру компонентов, при этом полученный компонент (наследник класса TOleServer) обладает свойствами, методами и событиями, имеющимися у данного объекта автоматизации (это касается, в том числе и библиотек типов COM-серверов Microsoft, предназначенных для работы с наборами данных). Это позволяет создавать их обработчики с помощью инспектора объектов, тем самым существенно упрощая создание кода для реагирования на события сервера.

3. Организация взаимодействия Delphi с Rational Rose

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

Приложение Rational Rose является совокупностью серверов COM, то есть экспонирует свои объекты для внешнего использования. В среде Delphi необходимо получить информацию об интерфейсах этих объектов. Это выполняется с помощью импорта описаний из библиотеки типов. На основе данных об объектах COM, ActiveX или OLE, зарегистрированных в реестре Windows, Delphi создает стандартный модуль на языке Object Pascal. В результате этого обращение к объектам Rational Rose ничем не отличается от работы с компонентами VCL. На рис. 1 представлено диалоговое окно Delphi, в котором осуществляется импорт.

Рисунок 1. Импортирование библиотеки типов



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

Таблица 1

Метод/свойство	Назначение
Connect	Соединение с COM-сервером
Disconnect	Завершение соединения
ConnectKind	Свойство показывает способ связи компонента с сервером
AutoConnect	Если это свойство True, то соединение с сервером происходит автоматически при запуске приложения

Важнейшим классом Rational Rose является класс roseApplication. Он включает в себя все необходимые свойства и методы. Создав в приложении Delphi объект класса TroseApplication, и выполнив метод Connect, можно получить доступ ко всем ресурсам среды Rational Rose.



4. Описание реализации

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

Рисунок 1. Алгоритм

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

- Tdiagramm - предназначен для описания диаграмм деятельностей;

- Tdepart - предназначен для описания подразделений, найденных на диаграмме;

- Tusecase - предназначен для описания use-case.

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

Код описания полей и методов содержится в модуле Structura.pas. Код описания интерфейса - в модуле action.pas.

Рисунок 2. Диаграмма классов

В начале работы программы создается объект класса TroseApplication, который инкапсулирует ссылки на COM-интерфейсы приложения Rational Rose. С помощью метода OpenModel производится загрузка необходимой модели. В процессе работы программы с помощью метода CurrentModel имеется возможность получить доступ ко всем составляющим модели.

Далее создается экземпляр класса TDiagram, выступающий как промежуточная структура для накопления данных о модели. С помощью методов RoseApplication находится ссылка на интерфейс RoseActivityCollection - источник информации о Деятельностях, используемых в данной модели. Эта ссылка передается в качестве параметра методу AddDeparts объекта типа Tdiagram, который:

1. Производит поиск деятельностей со стереотипом «department»;

2. Для каждого найденного подразделения создает объект типа Tdepart и заносит его в список Departs;

3. Для каждого объекта типа Tdepart вызывает метод AddData.

Метод AddData класса Tdepart выполняет следующие действия:

1. Производит поиск деятельностей со стереотипами «use case» и «actor»;

2. Заносит имя каждого найденного актера в список Actors;

3. Для каждого найденного use case создает объект типа TUseCase и заносит его в список UseCases;

4. Для каждого объекта типа TUseCase вызывает метод AddDocuments.

Метод AddDocuments класса TUseCase выполняет следующие действия:

1. Производит поиск деятельностей со стереотипами «document»;

2. Заносит имя каждого найденного документа в список Documents;

3. Проверяет наличие детализирующей коллекции деятельностей. Если она присутствует, то создается новый объект Tdiagram, заносится в поле SubDiagram и вызывается его метод AddDeparts.

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

Процесс создания диаграмм use-case начинается с вызова метода MakeCategory стартового экземпляра класса Tdiagram. В качестве параметра ему передается ссылка на COM-интерфейс RoseUseCaseCategory, который обеспечивает доступ к методам создания диаграмм use-case. Метод MakeCategory выполняет следующие действия:

1. Создает пакет (package) для размещения всей иерархии диаграмм;

2. Создает диаграмму ”main” для отображения пакетов подразделений;

3. На основании списка Departs для каждого объекта TDepart: создает подкатегорию с именем подразделения, отображает на диаграмме “main”, выполняет метод MakeActorsAndUC.

Метод MakeActorsAndUC класса Tdepart выполняет следующие действия:

1. Для каждого актера из списка Actors создает пакет с названием «Функции» + <имя актера>;

2. Создает диаграмму и размещает на ней пакеты;

3. В каждом пакете строит диаграмму use-case и размещает на ней актера и use-case'ы из списка UseCases;

4. Для каждого объекта TuseCase из списка UseCases выполняет метод MakeUseCase.

Метод MakeUseCase класса TUseCase выполняет следующие действия:

1. Создает диаграмму классов под названием: «Документы» + <Имя Use-case>;

2. На основе списка Documents размещает на созданной диаграмме классы с соответствующими названиями;

3. Если ссылка на объект TDiagram в поле SubDiagram не пуста, то запускает метод MakeCategory.

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

Исходный текст программных модулей приведен в Приложении 1.



4.1 Использование системы

Разработанное приложение является встроенным модулем среды Rational Rose. При установке оно интегрируется в эту среду и в разделе tools главного меню приложения Rational Rose появляется пункт Diagram Converter. Выбрав этот пункт, разработчик модели видит на экране диалоговое окно, представленное на рисунке 3.

Рисунок 1. Диалоговое окно «Diagram Converter»

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

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

· У всех деятельностей (activity), которые находятся на диаграмме, должны быть определены стереотипы. Причем нельзя присваивать одинаковые стереотипы деятельностям разных уровней.

· Переходы (transitions) должны идти: От деятельностей первого уровня к соответствующим деятельностям второго и третьего уровня. От деятельностей третьего уровня к деятельностям четвертого уровня.

Так как приложение функционирует совместно со средой Rational Rose, требования к аппаратной части системы совпадают требованиям этого пакета.

Они следующие (для пакета Rational Rose 98):

· Microsoft Windows 95 или NT 4.0

· PC-совместимая компьютерная система на базе 80486 процессора или старше

· 16 Mb RAM (24 Mb рекомендуется)

· 25 Mb дискового пространства



5. Тестирование и отладка

Для отладки разрабатываемого модуля применялись встроенные средства отладки среды Delphi 5. Среда включает широкий спектр новейших средств для локализации всех типов ошибок. Ниже перечислены некоторые из них:

· В прежних версиях Delphi точки прерывания были предназначены только для остановки процесса выполнения в режиме отладки. В Delphi 5 можно указать, какие именно действия (breakpoint actions) следует выполнить в момент достижения точки остановки: приостановить выполнение (как в прежних версиях Delphi), добавить текстовое сообщение в log-файл для регистрации событий отладчика (event log), записать в log-файл результат вычисления выражения, содержащего переменные отлаживаемого процесса (или вычислить выражение и никуда результат не записывать), а также сделать доступной или недоступной группу точек прерывания (о группах будет сказано ниже). Можно выполнить одновременно несколько действий в одной точке прерывания.

· С помощью пункта меню Run/Attach to Process можно начать отлаживать любой из уже запущенных процессов, в том числе, не имеющий отношения к Delphi.

· Среда разработки Delphi 5 поддерживает операции drag-and-drop во время отладки. Например, из редактора кода можно перенести выражение в окно Watch List, после чего это выражение останется в соответствующем списке. Можно перенести выражение в Debug Inspector. Можно также перенести выражение на панель, содержащую дамп памяти в окне CPU, и получить его адрес.

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

1. Преобразование тестовой модели с помощью разработанного модуля;

2. Анализ полученных результатов на предмет соответствия требованиям;

3. Составление протокола испытаний с указанием ошибок и несоответствий.

В результате тестирование и отладки модуль признан годным к эксплуатации.



Заключение

В результате проделанной работы был разработан встраиваемый модуль для преобразования диаграмм деятельностей в диаграммы use-case в среде Rational Rose. Он представляет собой Windows-приложение, которое функционирует совместно с Rational Rose, используя предоставляемые этой средой ресурсы с помощью COM-интерфейса.