Лекционные материалы

Глава 1. Основные сведения о языке UMLСамое лучшее средство – это большая диаграмма, приколотая к стене.Даг Скотт1.1. Цели и история создания языка UMLУнифицированный язык моделирования UML (Unified ModelingLanguage) – это преемник того поколения методов объектноориентированного анализа и проектирования, которые появились в конце80-х и начале 90-х годов. Создание UML фактически началось в конце1994 г., когда Гради Буч и Джеймс Рамбо начали работу по объединениюих методов Booch [Буч-1999] и OMT (Object Modeling Technique)под эгидой компании Rational Software. К концу 1995 г.

они создалипервую спецификацию объединенного метода, названного ими UnifiedMethod, версия 0.8. Тогда же в 1995 г. к ним присоединился создательметода OOSE (Object-Oriented Software Engineering) Ивар Якобсон. Такимобразом, UML является прямым объединением и унификацией методовБуча, Рамбо и Якобсона, однако дополняет их новыми возможностями.UML находится в процессе стандартизации, проводимомконсорциумом OMG (Object Management Group), в настоящее время онпринят в качестве стандартного языка моделирования и получил широкуюподдержку. UML принят на вооружение практически всеми крупнейшимикомпаниями – производителями программного обеспечения (Microsoft,IBM, Hewlett-Packard, Oracle, Sybase и др.).

Кроме того, практически всемировые производители CASE-средств, помимо Rational Software (RationalRose), поддерживают UML в своих продуктах (Paradigm Plus (CA), SystemArchitect (Popkin Software), Microsoft Visual Modeler и др.). Полноеописание UML можно найти на сайтах http://www.omg.orgи http://www.rational.com. Первое описание UML на русском языкесодержится в книге [Фаулер-1999], в дальнейшем изложениитерминология языка соответствует данному переводу.

Кроме него,имеются также переводы [Боггс-2000], [Буч-2000] и [Ларман-2001].31.2. Средства UMLСоздатели UML представляют его как язык для определения,представления, проектирования и документирования программных систем,организационно-экономических систем, технических систем и другихсистем различной природы. UML содержит стандартный набор диаграмм инотаций самых разнообразных видов. Стандарт UML версии 1.1, принятыйOMGв 1997 г.,предлагаетследующийнабордиаграммдля моделирования:– диаграммы вариантов использования (use case diagrams) –для моделирования бизнес-процессов организации и требованийк создаваемой системе);– диаграммы классов (class diagrams) – для моделированиястатической структуры классов системы и связей между ними;– диаграммы поведения системы (behavior diagrams):•диаграммы взаимодействия (interaction diagrams):♦ диаграммы последовательности (sequence diagrams) и♦ кооперативные диаграммы (collaboration diagrams) –для моделированияпроцессаобменасообщениямимежду объектами;•диаграммысостояний(statechartdiagrams)–для моделирования поведения объектов системы при переходеиз одного состояния в другое;•диаграммыдеятельностей(activitydiagrams)–для моделирования поведения системы в рамках различныхвариантов использования, или моделирования деятельностей;– диаграммы реализации (implementation diagrams):•диаграммыкомпонентов(componentdiagrams)–для моделирования иерархии компонентов (подсистем) системы;•диаграммыразмещения(deploymentdiagrams)для моделирования физической архитектуры системы.–1.3.

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

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

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

На рис. 1.1 показанпример такой диаграммы для банкомата (Automated Teller Machine, ATM).На данной диаграмме человеческие фигурки обозначаютдействующих лиц, овалы – варианты использования, а линии и стрелки –различные связи между действующими лицами и вариантамииспользования.На этой диаграмме показаны два действующих лица: клиент икредитная система. Существует также шесть основных действий,выполняемых моделируемой системой: перевести деньги, сделать вклад,5снять деньги со счета, показать баланс, изменить идентификационный коди осуществить оплату.Перевести деньгиСделать вкладКлиентСнять деньги сосчетаИзменитьидентификационный кодПоказать балансОсуществитьоплатуБанковскаясистемаРис.

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

В нашем примере, клиент банка инициируетбольшое количество различных вариантов использования: «Снять деньги6со счета», «Перевести деньги», «Сделать вклад», «Показать баланс» и«Изменить идентификационный код». От варианта использования«Осуществить оплату» стрелка указывает на Банковскую систему.Действующими лицами могут быть внешние системы, и потому в данномслучае Банковская система показана именно как действующее лицо – онавнешняя для системы АТМ. Направленная от варианта использованияк действующему лицу стрелка показывает, что вариант использованияпредоставляет некоторую информацию, используемую действующимлицом. В данном случае вариант использования «Осуществить оплату»предоставляет Банковской системе информацию об оплате по кредитнойкарточке.Все варианты использования, так или иначе, связаны с внешнимитребованиями к функциональности системы.

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

Это означает, что связи между ними также не относятсяк её компетенции.– Не соединяйте сплошной стрелкой (коммуникационной связью) дваварианта использования непосредственно. Диаграммы данного типаописывают только, какие варианты использования доступнысистеме, а не порядок их выполнения. Для отображения порядка7выполнения вариантов использования применяют диаграммыдеятельности.– Вариант использования должен быть инициирован действующимлицом. Это означает, что должна быть сплошная стрелка,начинающаяся на действующем лице и заканчивающаяся на вариантеиспользования.Хорошим источником для идентификации вариантов использованияслужат внешние события.

Следует начать с перечисления всех событий,происходящих во внешнем мире, на которые система должна каким-тообразом реагировать. Какое-либо конкретное событие может повлечьза собой реакцию системы, не требующую вмешательства пользователей,или, наоборот, вызвать пользовательскую реакцию. Идентификациясобытий,накоторыенеобходимореагировать,помогаетидентифицировать варианты использования.Варианты использования начинают описывать, что должна будетделать система. Чтобы фактически разработать систему, однако,потребуются более конкретные детали. Эти детали описываютсяв документе, называемом «поток событий» (flow of events).