Сведения о языке UML (1183998), страница 6
Текст из файла (страница 6)
Например, объект account может быть33в состоянии Открыто. При получении некоторого события выполняетсяопределенная деятельность.Переходом (Transition) называется перемещение из одного состоянияв другое. Совокупность переходов диаграммы показывает, как объектможет перемещаться между своими состояниями.
На диаграмме всепереходы изображают в виде стрелки, начинающейся на первоначальномсостоянии и заканчивающейся последующим.Переходы могут быть рефлексивными. Объект может перейти в то жесостояние, в котором он в настоящий момент находится. Рефлексивныепереходы изображают в виде стрелки, начинающейся и завершающейсяна одном и том же состоянии.У перехода существует несколько спецификаций. Они включаютсобытия, аргументы, ограждающие условия, действия и посылаемыесобытия. Рассмотрим каждое из них в контексте примера АТМ.СобытияСобытие (event) – это то, что вызывает переход из одного состоянияв другое.
В нашем примере событие «Клиент требует закрыть» вызываетпереход счета из открытого в закрытое состояние. Событие размещаютна диаграмме вдоль линии перехода.На диаграмме для отображения события можно использовать как имяоперации, так и обычную фразу. В нашем примере события описаныобычными фразами. Если вы хотите использовать операции, то событие«Клиент требует закрыть» можно было бы назвать RequestClosure().У событий могут быть аргументы. Так, событие «Сделать вклад»,вызывающее переход счета из состояния «Превышен счет» в состояние«Открыт», может иметь аргумент Amount (Количество), описывающийсумму депозита.Большинство переходов должны иметь события, так как именно они,прежде всего, заставляют переход осуществиться.
Тем не менее, бываюти автоматические переходы, не имеющие событий. При этом объект самперемещается из одного состояния в другое со скоростью, позволяющейосуществиться входным действиям, деятельности и выходным действиям.34Ограждающие условияОграждающие условия (guard conditions) определяют, когда переходможет, а когда не может осуществиться. В нашем примере событие«Сделать вклад» переведет счет из состояния «Превышение счета»в состояние «Открыт», но только если баланс будет больше нуля.В противном случае переход не осуществится.Ограждающие условия изображают на диаграмме вдоль линииперехода после имени события, заключая их в квадратные скобки.Ограждающие условия задавать необязательно.
Однако еслисуществует несколько автоматических переходов из состояния,необходимо определить для них взаимно исключающие ограждающиеусловия. Это поможет читателю диаграммы понять, какой путь переходабудет автоматически выбран.ДействиеДействием (action), как уже говорилось, является непрерываемоеповедение, осуществляющееся как часть перехода. Входные и выходныедействия показывают внутри состояний, поскольку они определяют, чтопроисходит, когда объект входит или выходит из него. Большую частьдействий, однако, изображают вдоль линии перехода, так как онине должны осуществляться при входе или выходе из состояния.Например, при переходе счета из открытого в закрытое состояниевыполняется действие «Сохранить дату закрытия счета».
Этонепрерываемое поведение осуществляется только во время переходаиз состояния «Открыт» в состояние «Закрыт».Действие рисуют вдоль линии перехода после имени события, емупредшествует косая черта.Событие или действие могут быть поведением внутри объекта,а могут представлять собой сообщение, посылаемое другому объекту.Если событие или действие посылается другому объекту, перед нимна диаграмме помещают знак « ^ ».Диаграммы состояний не надо создавать для каждого класса, ониприменяются только в сложных случаях. Если объект класса может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. Диаграмма размещения для системы АТМИз данной диаграммы можно узнать о физическом размещениисистемы. Клиентские программы АТМ будут работать в нескольких местахна различных сайтах.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
