Лекционные материалы, страница 6
Описание файла
PDF-файл из архива "Лекционные материалы", который расположен в категории "". Всё это находится в предмете "объектно-ориентированный анализ и проектирование" из 7 семестр, которые можно найти в файловом архиве МГУ им. Ломоносова. Не смотря на прямую связь этого архива с МГУ им. Ломоносова, его также можно найти и в других разделах. .
Просмотр PDF-файла онлайн
Текст 6 страницы из PDF
Входные и выходныедействия показывают внутри состояний, поскольку они определяют, чтопроисходит, когда объект входит или выходит из него. Большую частьдействий, однако, изображают вдоль линии перехода, так как онине должны осуществляться при входе или выходе из состояния.Например, при переходе счета из открытого в закрытое состояниевыполняется действие «Сохранить дату закрытия счета». Этонепрерываемое поведение осуществляется только во время переходаиз состояния «Открыт» в состояние «Закрыт».Действие рисуют вдоль линии перехода после имени события, емупредшествует косая черта.Событие или действие могут быть поведением внутри объекта,а могут представлять собой сообщение, посылаемое другому объекту.Если событие или действие посылается другому объекту, перед нимна диаграмме помещают знак « ^ ».Диаграммы состояний не надо создавать для каждого класса, ониприменяются только в сложных случаях.
Если объект класса может35существовать в нескольких состояниях и в каждом из них ведет себяпо-разному, для него может потребоваться такая диаграмма.1.7. Диаграммы деятельностиВ отличие от большинства других средств UML, диаграммыдеятельностей не имеют явно выраженного источника в предыдущихработах Буча, Рамбо и Якобсона, и заимствуют идеи из несколькихразличных методов, в частности, метода моделирования состояний SDL исетей Петри. Эти диаграммы особенно полезны в описании поведения,включающегобольшоеколичествопараллельныхпроцессов[Фаулер-1999].Подобно большинству других средств, моделирующих поведение,диаграммы деятельностей обладают определенными достоинствамии недостатками, поэтому их лучше всего использовать в сочетаниис другими средствами.Самым большим достоинством диаграмм деятельностей являетсяподдержка параллелизма. Благодаря этому они являются мощнымсредством моделирования потоков работ и, по существу, параллельногопрограммирования.
Самый большой их недостаток заключается в том, чтосвязи между действиями и объектами просматриваются не слишком четко.Этисвязиможнопопытатьсяопределить,используядля деятельностей метки с именами объектов, но этот способ не обладаеттакой же простой непосредственностью, как у диаграмм взаимодействия.Диаграммы деятельностей предпочтительнее использовать в следующихситуациях:• Анализ варианта использования. На этой стадии нас не интересуетсвязь между действиями и объектами, а нужно только понять,какие действия должны иметь место и каковы зависимостив поведении системы.
Связывание методов и объектов выполняетсяпозднее с помощью диаграмм взаимодействия.• Анализ потоков работ (workflow) в различных вариантахиспользования. Когда варианты использования взаимодействуютдруг с другом, диаграммы деятельностей являются мощнымсредством представления и анализа их поведения.361.8.
Диаграммы компонентовДиаграммы компонентов показывают, как выглядит модельна физическом уровне. На них изображены компоненты программногообеспечения и связи между ними. При этом на такой диаграмме выделяютдва типа компонентов: исполняемые компоненты и библиотеки кода.Каждый класс модели (или подсистема) преобразуется в компонентисходного кода. После создания они сразу добавляются к диаграммекомпонентов. Между отдельными компонентами изображают зависимости,соответствующие зависимостям на этапе компиляции или выполненияпрограммы.На рис. 1.17 изображена одна из диаграмм компонентов для системыАТМ.ATM.exeCash DispenserCard ReaderATM ScreenCard ReaderCash DispenserATM ScreenРис. 1.17.
Диаграмма компонентов для клиента АТМНа этой диаграмме показаны компоненты клиента системы АТМ.В данном случае система разрабатывается на языке С++. У каждого класса37имеется свой собственный заголовочный файл и файл с расширением .СРР,так что каждый класс преобразуется в свои собственные компонентына диаграмме. Например, класс ATM screen преобразуется в компонентATM Screen диаграммы. Он преобразуется также и во второй компонентATM Screen.
Вместе эти два компонента представляют тело и заголовоккласса ATM Screen. Выделенный темным компонент называетсяспецификацией пакета (package specification) и соответствует файлу телакласса ATM Screen на языке C++ (файл с расширением .СРР).Невыделенный компонент также называется спецификацией пакета,но соответствует заголовочному файлу класса языка С++ (файлс расширением .Н). Компонент ATM.exe является спецификацией задачии представляет поток обработки информации (thread of processing).В данном случае поток обработки является исполняемой программой.Компоненты соединены штриховой линией, что соответствуетзависимостям между ними. Например, класс Card Reader зависит от классаATM Screen.
Это означает, что, для того, чтобы класс Card Reader мог бытьскомпилирован, класс ATM Screen должен уже существовать.После компиляции всех классов может быть создан исполняемый файлATMClient.exe.Пример АТМ содержит два потока обработки и, таким образом,получаются два исполняемых файла. Один из них – это клиент АТМ, онсодержит компоненты Cash Dispenser, Card Reader и ATM Screen.
Второйфайл – это сервер ATM, включающий в себя компонент Account.Диаграмма компонентов для сервера АТМ показана на рис. 1.18.Как видно из примера, у системы может быть несколько диаграммкомпонентов, в зависимости от числа подсистем или исполняемых файлов.Каждая подсистема является пакетом компонентов. В общем случае,пакеты – это совокупности компонентов. Пример АТМ содержит двапакета: клиент АТМ и сервер АТМ.Диаграммы компонентов применяются теми участниками проекта, ктоотвечает за компиляцию системы.
Из нее видно, в каком порядке надокомпилировать компоненты, а также какие исполняемые компонентыбудут созданы системой. На такой диаграмме показано соответствие38классов реализованным компонентам. Она нужна там, где начинаетсягенерация кода.ATMServer.exeAccountAccountРис. 1.18.
Диаграмма Компонентов для сервера АТМ1.9. Диаграммы размещенияДиаграмма размещения (deployment diagram) отражает физическиевзаимосвязи между программными и аппаратными компонентамисистемы. Она является хорошим средством для того, чтобы показатьмаршруты перемещения объектов и компонентов в распределеннойсистеме.Каждый узел на диаграмме размещения представляет собойнекоторый тип вычислительного устройства – в большинстве случаев,часть аппаратуры. Эта аппаратура может быть простым устройством илидатчиком, а может быть и мэйнфреймом.Диаграмма размещения показывает физическое расположение сети иместонахождение в ней различных компонентов.
В нашем примересистема АТМ состоит из большого количества подсистем, выполняемых наотдельных физических устройствах, или узлах (node). Диаграммаразмещения для системы АТМ показана на рис. 1.19.39Banking DatabaseServerOracle Server<<LAN>>RegionalATM ServerATMServer.exePrinter<<Private Network>><<Private Network>>125 First St.ATM459 Elm St.ATMATMClient.exeATMClient.exeРис.
1.19. Диаграмма размещения для системы АТМИз данной диаграммы можно узнать о физическом размещениисистемы. Клиентские программы АТМ будут работать в нескольких местахна различных сайтах. Через закрытые сети будет осуществлятьсяих сообщение с региональным сервером АТМ. На нём будет работатьпрограммное обеспечение сервера АТМ.
В свою очередь, посредствомлокальной сети региональный сервер будет сообщаться с серверомбанковской базы данных, работающим под управлением Oracle. Наконец,с региональным сервером АТМ соединен принтер.Диаграмма размещения используется менеджером проекта,пользователями, архитектором системы и эксплуатационным персоналом,чтобы понять физическое размещение системы и расположениееё отдельных подсистем.40Глава 2. Основные сведения о CASE-средстве Rational RoseНекоторые проектные команды рассматривают CASE-средствакак „костыли“ для новичков, а другие считают их не менееважными, чем текстовые процессоры.Э. Йордон „Путь камикадзе“2.1. Введение в Rational RoseRational Rose – семейство объектно-ориентированных CASE-средствфирмы Rational Software Corporation – предназначено для автоматизациипроцессов анализа и проектирования ПО, а также для генерации кодовна различных языках и выпуска проектной документации.