|
|
Какие диаграммы дает в наше распоряжение Rational Rose?12 Вы уже поняли, что UML — это набор диаграмм, которые позволяют проектировать и создавать сложные программные системы. Перед тем как начать вплотную изучать работу с Rational Rose, необходимо кратко ознакомиться с тем, какие диаграммы есть в нашем распоряжении и для чего каждая из них будет использоваться.
Рис. 1.3.Окно Overview
В распоряжение проектировщика системы Rational Rose предоставляет следующие типы диаграмм, последовательное создание которых позволяет получить полное представление обо всей проектируемой системе и об отдельных ее компонентах: · Use case diagram (диаграммы сценариев); · Deployment diagram (диаграммы топологии); · State diagram (диаграммы состояний); · Activity diagram, (диаграммы активности); · Interaction diagram (диаграммы взаимодействия); · Sequence diagram (диаграммы последовательностей действий); · Collaboration diagram (диаграммы сотрудничества); · Class diagram (диаграммы классов); · Component diagram (диаграммы компонент). Use case diagram (диаграммы сценариев) Этот вид диаграмм позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций. Каждая такая диаграмма или, как ее обычно называют, каждый Use case — это описание сценария поведения, которому следуют действующие лица (Actors). Пример такой диаграммы показан на рис. 1.4.
Рис. 1.4.Пример диаграммы Use case Данный тип диаграмм полезен при замысле системы и используется для того, чтобы создать требования к системе, определить действующие в системе объекты и основные задачи, выполняемые этими объектами. Deployment diagram (диаграммы топологии) Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть «железа», а не программ. В прямом переводе с английского Deployment означает «развертывание», но термин «топология» точнее отражает сущность этого типа диаграмм. Для каждой модели создается только одна такая диаграмма, отображающая процессоры (Processor), устройства (Device) и их соединения (рис. 1.5).
Рис. 1.5.Пример диаграммы Deployment Г. Буч[5] советует использовать этот тип диаграмм в самом начале проектирования системы для анализа аппаратных средств, на которых будет эксплуатироваться система. State diagram (диаграммы состояний) Диаграммы состояний (State) предназначены для отображения состояний объектов системы, имеющих сложную модель поведения. Замечание.В версии Rational Rose 2000 и выше данный тип диаграммы изменил название на Statechart. Каждый объект системы, обладающий определенным поведением, может находиться в определенных состояниях и переходить из состояния в состояние в процессе реализации сценария поведения объекта. Поведение большинства объектов реальных систем можно представить с точки зрения теории конечных автоматов, то есть поведение объекта отражается в его состояниях, и данный тип диаграмм позволяет отразить это графически. Пример диаграммы состояний показан на рис. 1.6.
Рис. 1.6.Пример диаграммы состояний Activity diagram (диаграммы активности) Диаграмма активности появилась только в версии Rational Rose 2000. Это дальнейшее развитие диаграммы состояний. Фактически данный тип диаграмм может использоваться и для отражения состояний моделируемого объекта, однако, основное назначение Activity diagram не в том, чтобы отражать состояния, а в том, чтобы отражать бизнес-процессы объекта. В данном типе диаграмм присутствуют такие значки, которые позволяют отразить ветвление, определенную последовательность действий или синхронизацию процессов. Пример такой диаграммы показан на рис. 1.7.
Рис. 1.7.Пример диаграммы активности Замечание.Этот тип диаграмм позволяет проектировать алгоритмы поведения объектов любой сложности, в том числе может использоваться для составления блок-схем. Interaction diagram (диаграммы взаимодействия) Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе. Sequence diagram (диаграммы последовательностей действий) Взаимодействие объектов в системе происходит посредством приема и передачи сообщений объектами-клиентами и обработки этих сообщений объектами-серверами. При этом в разных ситуациях одни и те же объекты могут выступать и в качестве клиентов, и в качестве серверов. Данный тип диаграмм позволяет отразить последовательность передачи сообщений между объектами. Пример такой диаграммы показан на рис. 1.8.
Рис. 1.8.Пример Sequence-диаграммы Этот тип диаграммы не акцентирует внимание на конкретном взаимодействии, главный акцент уделяется последовательности приема/передачи сообщений. Для того чтобы окинуть взглядом все взаимосвязи объектов, служит Collaboration diagram. Collaboration diagram (диаграммы сотрудничества) Этот тип диаграмм позволяет описать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений. На этом типе диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта и типы этих сообщений. Пример диаграммы Collaboration показан на рис. 1.9.
Рис. 1.9.Пример диаграммы Collaboration Замечание.По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм. Class diagram (диаграммы классов) Этот тип диаграмм позволяет создавать логическое представление системы, на основе которого создается исходный код описанных классов. Значки диаграммы позволяют отображать сложную иерархию систем, взаимосвязи классов (Classes) и интерфейсов (Interfaces). Данный тип диаграмм противоположен по содержанию диаграмме Collaboration, на котором отображаются объекты системы. Rational Rose позволяет создавать классы при помощи данного типа диаграмм в различных нотациях. В нотации, предложенной Г. Бучем, которая так и называется Booch, классы изображаются в виде чего-то нечеткого, похожего на облако. Таким образом Г. Буч пытается показать, что класс — это лишь шаблон, по которому в дальнейшем будет создан конкретный объект. Пример изображения классов в этой нотации показан на рис. 1.10.
Рис. 1.10.Пример изображения классов в Booch-нотации Нотация ОМТ[6], на мой взгляд, более строга. Пример изображения классов в нотации ОМТ показан на рис. 1.11.
Рис. 1.11.Пример изображения классов в нотации ОМТ И конечно же, Rational Rose позволяет создавать диаграмму классов в унифицированной нотации, пример изображения классов в которой показан на рис. 1.12.
Рис. 1.12.Пример изображения классов в нотации Unified Component diagram (диаграммы компонентов) Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто данный тип диаграмм называют диаграммами модулей. При проектировании больших систем может оказаться, что система должна быть разложена на несколько сотен или даже тысяч компонентов, и этот тип диаграмм позволяет не потеряться в обилии модулей и их связей. Пример диаграммы компонентов показан на рис. 1.13.
Рис. 1.13.Пример диаграммы компонентов Общий порядок работы Для создания систем различных предметных областей общий порядок работы может несколько отличаться от приведенного, поэтому при разработке другой системы необходимо внести в него соответствующие изменения. Для создания программной системы нашего класса будем использовать описанный ниже порядок работы. В первую очередь произведем анализ списка операций, которые будет выполнять система, и определим список объектов системы, которые данные функции выполняют. Таким образом, определим требования к системе и границы предметной области. Для этого будем использовать диаграммы Use case. Затем, еще до окончательной детализации сценариев поведения, произведем анализ аппаратной части системы при помощи Deployment-диаграммы. Это скорее задача системного анализа, чем практическая. В общем случае она позволит определиться в таких вопросах как технологичность и стоимость системы, а также определить набор аппаратных средств, на которых предстоит эксплуатировать систему. В нашем случае анализ аппаратной части системы ограничится перечислением устройств, которые будут работать под управлением нашего программного обеспечения и ничего более. Возможно, именно аппаратные средства внесут свои коррективы, ограничения или дополнительные требования к создаваемому программному обеспечению. Затем определим список классов, которые должны присутствовать в системе, пока без конкретной детализации и подробного описания действий. Для этого будем использовать диаграмму классов (Class diagram). После заведения в системе необходимых классов определим поведение конкретных классов при помощи диаграмм State diagram (диаграммы состояний) и Activity diagram (диаграммы активности). Дальнейшая детализация взаимодействия классов будет производиться при помощи Sequence diagram (диаграммы последовательностей действий), Collaboration diagram (диаграммы сотрудничества). На основании производимых классами действий создадим окончательную иерархию классов системы при помощи диаграммы классов (Class diagram) и определим компоненты, в которые эти классы необходимо включить при помощи диаграммы компонентов (Component diagram). Необходимо понимать, что разработка — это итерационный процесс. Нельзя за один раз создать полный проект системы. Придется многократно возвращаться к уже созданным диаграммам и вносить в них изменения. Если вы хоть раз писали программу, то, я полагаю, этот процесс вам знаком. Примерные вопросы для самопроверки и защиты 1. Что представляет собой программа Rational Rose. 2. Что такое язык UML. 3. Почему Rational Rose является лидером среди CASE-средств. 4. Что может и чего не может делать Rational Rose. 5. Какие преимущества дает применение Rational Rose при разработке программных систем. 6. Какие диаграммы доступны в программе Rational Rose и их назначение. 7. Общий порядок работы. Литература 1. Трофимов С.А. Case-технологии: практическая работа в Rational Rose — М.: ЗАО «Издательство БИНОМ», 2001 г. — 272 с.: ил. 2. Новичков А.Н.Rational Rose для разработчиков и ради разработчиков. http://citforum.ru/programming/application/rrose.shtml 3. Новичков А.Н. Эффективная разработка программного обеспечения с использованием технологий и инструментов компании RATIONAL. http://citforum.ru/programming/rational_use/index.shtml [1] Сейчас больше. [2] Microsoft Visual Studio — линейка продуктов компании Microsoft, включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств. [3] CASE (англ. Computer-Aided Software Engineering) — набор инструментов и методов программной инженерии для проектирования программного обеспечения, который помогает обеспечить высокое качество программ, отсутствие ошибок и простоту в обслуживании программных продуктов. Также под CASE понимают совокупность методов и средств проектирования информационных систем с использованием CASE-инструментов [4] Microsoft Foundation Classes (MFC) — библиотека на языке C++, разработанная Microsoft и призванная облегчить разработку GUI-приложений для MicrosoftWindows [5] Гради Буч (англ. Grady Booch; 27 февраля 1955 года, Амарилло, Техас, США) — американский инженер, руководитель исследований в IBM Research, IBM Fellow[en] с 2003 года. Гради Буч наиболее известен как создатель унифицированного языка моделирования UML, который он разработал совместно с Иваром Якобсоном и Джеймсом Рамбо. [6] OMG (сокр. от англ. Object Management Group, читается как [о-эм-джи]) — консорциум (рабочая группа), занимающийся разработкой и продвижением объектно-ориентированных технологий и стандартов. 
12 Не нашли, что искали? Воспользуйтесь поиском по сайту: ©2015 - 2024 stydopedia.ru Все материалы защищены законодательством РФ.
|
