<< Пред. стр. 1 (из 3) След. >>
Список литературы по разделу
Федеральное агентство по образованию
Омский государственный институт сервиса
И.В.Червенчук.Информационные системы и процессы, моделирование и управление
МОДЕЛИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ С ПОМОЩЬЮ UML
Учебное пособие
Омск 2006
УДК 004.3
Ч 45
Червенчук И.В.
Информационные системы и процессы, моделирование и управление. Моделирование информационных систем с помощью UML: Учебное пособие. - Омск: Омский государственный институт сервиса, 2006. 48с.
Рассмотрены основы унифицированного языка моделирования UML, даются рекомендации по использованию средств данного языка при моделировании программного обеспечения, приводятся примеры разработки моделей информационных систем. Учебное пособие составлено в соответствии с Государственным образовательным стандартом высшего профессионального образования по специальности "Прикладная информатика (в сфере сервиса)".
Учебное пособие предназначено для студентов специальности "Прикладная информатика (в сфере сервиса)" очной и заочной формы обучения. Содержит материал для самостоятельной проработки студентами лекций по курсу "Информационные системы и процессы, моделирование и управление", может использоваться при подготовке к экзаменам и выполнении курсовой работы.
Рецензент: канд. техн. наук, доцент О.П. Шафеева (Омский государственный технический университет)
ОГЛАВЛЕНИЕ
Предисловие.....................................................................
4
ВВЕДЕНИЕ.....................................................................
5
1. ОБЗОР UML .................................................................
8
1.1.
Строительные блоки UML .......................................
12
1.2.
Правила языка UML.............................................
19
1.3.
Общие механизмы языа UML.................................
20
1.4.
Архитектура программной системы........................
24
Выводы...................................................................
27
Контрольные вопросы...................................................
27
Упражнения .............................................................
28
2. КЛАССЫ.......................................................................
29
2.1.
Термины и понятия ................................................
30
2.2.
Типичные приемы моделирования. Словарь системы...
35
2.3.
Непрограммные сущности ........................................
38
2.4.
Примитивне типы......................................................
39
2.5.
Рекомендации к моделированию классов ....................
40
Выводы...................................................................
41
Контрольные вопросы....................................................
41
Упражнения ..............................................................
42
3. ПРИМЕРЫ МОДЕЛИРОВАНИЯ.....................................
43
3.1.
Диаграмма прецедентов ...........................................
43
3.2.
Диаграмма классов ..................................................
45
3.3.
Диаграммы взаимодействия....................................
47
3.4.
Реализация информационной системы......................
49
Выводы...................................................................
52
Контрольные вопросы.....................................................
53
Упражнения ...............................................................
54
ЗАКЛЮЧЕНИЕ.......................................................................
56
БИБЛИОГРАФИЧЕСКИЙ СПИСОК..................................
57
Словарь терминов и определений................................................
58
Предисловие
Данное учебное пособие знакомит читателя с возможностями унифицированного языка моделирования UML (Unified Modeling Language), который постепенно становится стандартом де-факто при описании объектно-ориентированных систем. Язык UML является мощным современным средством моделирования программного обеспечения и его изучению уделяется особое внимание в курсе "Информационные системы и процессы. Моделирование и управление". Программные средства, основанные на UML: "Rational Rose" и "Visual Paradigm" являются основными программными средствами, используемыми в рамках данного курса. С использованием указанных программных средств проводятся практические занятия и выполняется курсовая работа по курсу "Информационные системы и процессы. Моделирование и управление". Кроме того, средства UML рекомендуется использовать при работе над дипломным проектом, особенно если тематика дипломного проекта связана с разработкой модели информационной системы.
В основу данного пособия положена значительная, при этом самая существенная, часть курса "Информационные системы и процессы. Моделирование и управление" читаемого автором студентам Омского государственного института сервиса, связанная с моделированием программных средств.
Пособие содержит теоретические разделы (первый и второй разделы). Первый раздел (Обзор UML) содержит базовые понятия языка UML, основные структурные единицы и правила. Поясняется назначение основных диаграмм, рассматриваются выразительные средства UML. Материал иллюстрируется примерами.
Второй раздел (Классы) сдержит материал, необходимый при разработке модели системы с точки зрения проектирования. Основное внимание раздела сосредоточено на классах - базовых элементах объектно-ориентированного программирования, составляющих основу объектно-ориентированных систем. Рассматриваются особенности моделирования классов средствами UML, даются рекомендации по моделированию.
В третьем разделе учебного пособия приводится пример подробно разработанной модели справочно-информационной системы музыки на CD. Иллюстрируются возможности применения различных диаграмм UML для моделирования различных аспектов информационно-справочной системы. Материал данного раздела может использоваться студентами при выполнении курсовой работы по курсу "Информационные системы и процессы. Моделирование и управление" и дипломного проекта.
Учебное пособие адресовано студентам специальности "Прикладная информатика (в сфере сервиса)" очной и заочной формы обучения, но может с успехом использоваться студентами родственных специальностей, связанных с разработкой программного обеспечения.
ВВЕДЕНИЕ
На заре вычислительной техники с появлением первых программ быстро стала очевидным необходимость средств описания программного обеспечения. Необходимость выделить основной принцип работы того или иного алгоритма, отделить его существенную часть от вспомогательных операций с целью облегчения в дальнейшем многократной реализации его на разных языках программирования послужила стимулом развития средств документирования и спецификации программного обеспечения.
Первый этап развития вычислительной техники характеризовался так называемыми алгоритмическими языками. Основой данной методологии разработки программ являлась процедурная или алгоритмическая организация структуры программного кода, что было естественно для решения вычислительных задач, доминирующих на данном этапе. Исходным понятием этой методологии являлось понятие алгоритма, под которым, в общем случае, понимается некоторое предписание выполнить точно определенную последовательность действий, направленных на достижение заданной цели или решение поставленной задачи. Примерами алгоритмов являются хорошо известные правила нахождения корней квадратного уравнения, расчет определителя матрицы или решение системы линейных уравнений. Введенное на данном этапе первое графическое средство документирования программ получило название блок-схемы алгоритма, содержащая основные структурные элементы: процесс, ветвление, цикл. Соответствующая система графических обозначений была зафиксирована в ГОСТ 19.701-90, который регламентировал использование условных обозначений в схемах алгоритмов, программ, данных и систем. Данные средства с успехом использовались, был организован специальный фонд алгоритмов и программ, где хранилась и куда поступала документация наиболее интересных и используемых вычислительных алгоритмов.
Со временем сложность программ увеличивалась. Успешное решение сложной задачи потребовало ее разбиения на фрагменты. В языках программирования возникло и закрепилось новое понятие процедуры. Так же, как и алгоритм, процедура представляет собой законченную последовательность действий или операций, направленных на решение отдельной задачи. В языках программирования появилась специальная синтаксическая конструкция, которая получила название процедуры, возникла методология процедурного программирования, ее естественное развитие привело к методологии структурного программирования [4]. Основой данной методологии является процедурная декомпозиция программной системы и организация отдельных модулей в виде совокупности выполняемых процедур. Хорошим тоном стало программирование без использования оператора безусловного перехода (goto), при этом языками программирования стали поддерживаться конструкции ветвления с несколькими условиями (if... else, case...), циклы с предусловием (while...) и постусловием (do...until) и пр. В рамках методологии структурного программирования получило развитие нисходящее проектирование программ или программирование "сверху-вниз". Период наибольшей популярности идей структурного программирования приходится на конец 70-х-начало 80-х годов. В арсенал блок схем были введен элемент "процедура", были дополнительно введены такие элементы как "цикл с пред условием", "цикл с постусловием", однако интерес к их использованию резко падал. Программисты стали отдавать предпочтению непосредственно тексту программы, при этом было рекомендовано использование отступов в начале каждой строки, которые должны выделять вложенные циклы и условные операторы, использовалась так называемая венгерская нотация, позволяющая по имени легко определить тип переменной или константы, хотя при жесткой необходимости продолжали использовать блок-схемы. В этот период основным показателем сложности разработки программ считали размер ее исходного кода.
Примерно во второй половине 80-х годов стало очевидным, что традиционные методы процедурного программирования не способны справиться ни с растущей сложностью программ и их разработки, ни с необходимостью повышения их надежности. Возникла необходимость новой методологии программирования. Такой методологией стало объектно-ориентированное программирование (ООП). Базовыми понятиями ООП являются понятия класса и объекта. При этом под классом понимают некоторую абстракцию совокупности объектов, которые имеют общий набор свойств и обладают одинаковым поведением. Каждый объект в этом случае рассматривается как экземпляр соответствующего класса. Принцип инкапсуляции (заключение в некоторой программной единице - классе некоторого логически законченного программного элемента с соответствующими ему данными и функциями) становится одним из фундаментальных принципов программирования. Применение принципов наследования и полиморфизма позволило в значительной степени оптимизировать программу, повысить ее надежность.
При разработке крупной информационной системы возникает совокупность задач. Эта совокупность задач не столько связана с написанием кода, сколько с общим анализом требований к будущей программе, а также с анализом конкретной предметной области, для которой разрабатывается программа. Все эти обстоятельства привели к появлению специальной методологии, получившей название методологии объектно-ориентированнного анализа и проектирования (ООАП). В рамках этого подхода возникало много направлений, период конца 80-х и начало 90-х годов принято называть "войной методов", завершение которой (хотя споры продолжаются) связано с появлением языка UML.
Унифицированный язык моделирования (UML, Unified Modeling Language) является преемником методов объектно-ориентированного анализа и проектирования, он непосредственно унифицирует методы ведущих специалистов в этой области Буча, Рамбо и Джекобсона, однако обладает большими возможностями [1]. Язык UML прошел процесс стандартизации в рамках консорциума OMG (Object Management Group) и с 1997 года является стандартом OMG.
Унифицированный язык моделирования (UML) является стандартным инструментом для создания "чертежей" программного обеспечения. С помощью UML можно визуализировать, специфицировать, конструировать и документировать артефакты программных систем.
UML пригоден для моделирования любых систем: от информационных систем масштаба предприятия до распределенных Web-приложений и даже встроенных систем реального времени. Это очень выразительный язык, позволяющий рассмотреть систему со всех точек зрения, имеющих отношение к ее разработке и последующему развертыванию.
1. ОБЗОР UML
Несмотря на обилие выразительных возможностей язык UML прост для понимания и использования. Его изучение удобнее всего начать с его концептуальной модели, которая включает в себя три основных элемента: базовые строительные блоки, правила, определяющие, как эти блоки могут сочетаться между собой, и некоторые общие механизмы языка.
Несмотря на свои достоинства, UML - это всего лишь язык; он является одной из составляющих процесса разработки программного обеспечения, и не более того. Хотя UML не зависит от моделируемой реальности, лучше всего применять его, когда процесс моделирования основан на рассмотрении прецедентов использования, является итеративным и пошаговым, а сама система имеет четко выраженную архитектуру.
UML - это язык для визуализации, специфицирования, конструирования и документирования артефактов программных систем.
UML - это язык
Язык состоит из словаря и правил, позволяющих комбинировать входящие в него слова и получать осмысленные конструкции. В языке моделирования словарь и правила ориентированы на концептуальное и физическое представление системы. Язык моделирования, подобный UML, является стандартным средством для составления "чертежей" программного обеспечения.
Моделирование необходимо для понимания системы. При этом единственной модели никогда не бывает достаточно. Напротив, для понимания любой нетривиальной системы приходится разрабатывать большое количество взаимосвязанных моделей. В применении к программным системам это означает, что необходим язык, с помощью которого можно с различных точек зрения описать представления архитектуры системы на протяжении цикла ее разработки .
Словарь и правила такого языка, как UML, объясняют, как создавать и читать хорошо определенные модели, но ничего не сообщают о том, какие модели и в каких случаях нужно создавать. Это задача всего процесса разработки программного обеспечения. Хорошо организованный процесс должен подсказать вам, какие требуются артефакты, какие ресурсы необходимы для их создания, как можно использовать эти артефакты, чтобы оценить выполненную работу и управлять проектом в целом.
UML - это язык визуализации
С точки зрения большинства программистов, размышления по поводу реализации проекта почти эквивалентны написанию для него кода. Вы думаете - значит, вы кодируете. И действительно, некоторые вещи лучше всего выражаются непосредственно в коде на каком-либо языке программирования, поскольку текст программы - это самый простой и короткий путь для записи алгоритмов и выражений.
Но даже в таких случаях программист занимается моделированием, хотя и неформально. Он может, допустим, записать набросок идеи на доске или на салфетке. Однако такой подход чреват неприятностями. Во-первых, обмен мнениями по поводу концептуальной модели возможен только тогда, когда все участники дискуссии говорят на одном языке. Как правило, при разработке проектов компаниям приходится изобретать собственные языки, и новичку непросто догадаться, о чем идет речь. Во-вторых, нельзя получить представление об определенных аспектах программных систем без модели, выходящей за границы текстового языка программирования. Так, назначение иерархии классов можно, конечно, понять, если внимательно изучить код каждого класса, но воспринять всю структуру сразу и целиком не получится. Аналогично изучение кода системы не позволит составить целостное представление о физическом распределении и возможных миграциях объектов в Web-приложении. В-третьих, если автор кода никогда не воплощал в явной форме задуманные им модели, эта информация будет навсегда утрачена, если он сменит место работы. В лучшем случае ее можно будет лишь частично воссоздать исходя из реализации.
Использование UML позволяет решить третью проблему: явная модель облегчает общение.
Некоторые особенности системы лучше всего моделировать в виде текста, другие - графически. На самом деле во всех интересных системах существуют структуры, которые невозможно представить с помощью одного лишь языка программирования. UML - графический язык, что позволяет решить вторую из обозначенных проблем.
UML - это не просто набор графических символов. За каждым из них стоит хорошо определенная семантика (см. "The Unified Modeling Language Reference Manual"). Это значит, что модель, написанная одним разработчиком, может быть однозначно интерпретирована другим - или даже инструментальной программой. Так решается первая из перечисленных выше проблем.
UML - это язык специфицирования
В данном контексте специфицирование означает построение точных, недвусмысленных и полных моделей. UML позволяет специфицировать все существенные решения, касающиеся анализа, проектирования и реализации, которые должны приниматься в процессе разработки и развертывания системы программного обеспечения.
UML - это язык конструирования.
UML не является языком визуального программирования, но модели, созданные с его помощью, могут быть непосредственно переведены на различные языки программирования. Иными словами, UML-модель можно отобразить на такие языки, как Java, C++, Visual Basic, и даже на таблицы реляционной базы данных или устойчивые объекты объектно-ориентированной базы данных. Те понятия, которые предпочтительно передавать графически, так и представляются в UML; те же, которые лучше описывать в текстовом виде, выражаются с помощью языка программирования.
Такое отображение модели на язык программирования позволяет осуществлять прямое проектирование: генерацию кода из модели UML в какой-то конкретный язык. Можно решить и обратную задачу: реконструировать модель по имеющейся реализации. Обратное проектирование не представляет собой ничего необычного. Если вы не закодировали информацию в реализации, то эта информация теряется при прямом переходе от моделей к коду. Поэтому для обратного проектирования необходимы как инструментальные средства, так и вмешательство человека. Сочетание прямой генерации кода и обратного проектирования позволяет работать как в графическом, так и в текстовом представлении, если инструментальные программы обеспечивают согласованность между обоими представлениями.
Помимо прямого отображения в языки программирования UML в силу своей выразительности и однозначности позволяет непосредственно исполнять модели, имитировать поведение систем и контролировать действующие системы.
UML - это язык документирования
Компания, выпускающая программные средства, помимо исполняемого кода производит и другие артефакты, в том числе следующие:
- требования к системе;
- архитектуру;
- проект;
- исходный код;
- проектные планы;
- тесты;
- прототипы;
- версии, и др.
В зависимости от принятой методики разработки выполнение одних работ производится более формально, чем других. Упомянутые артефакты - это не просто поставляемые составные части проекта; они необходимы для управления, для оценки результата, а также в качестве средства общения между членами коллектива во время разработки системы и после ее развертывания.
UML позволяет решить проблему документирования системной архитектуры и всех ее деталей, предлагает язык для формулирования требований к системе и определения тестов и, наконец, предоставляет средства для моделирования работ на этапе планирования проекта и управления версиями.
Где используется UML
Язык UML предназначен, прежде всего, для разработки программных систем. Его использование особенно эффективно в следующих областях:
- информационные системы масштаба предприятия;
- банковские и финансовые услуги;
- телекоммуникации;
- транспорт;
- оборонная промышленность, авиация и космонавтика;
- розничная торговля;
- медицинская электроника;
- наука;
- распределенные Web-системы.
Сфера применения UML не ограничивается моделированием программного обеспечения. Его выразительность позволяет моделировать, скажем, документооборот в юридических системах, структуру и функционирование системы обслуживания пациентов в больницах, осуществлять проектирование аппаратных средств.
Концептуальная модель UML
Для понимания UML необходимо усвоить его концептуальную модель, которая включает в себя три составные части: основные строительные блоки языка, правила их сочетания и некоторые общие для всего языка механизмы. Усвоив эти элементы, вы сумеете читать модели на UML и самостоятельно создавать их -вначале, конечно, не очень сложные. По мере приобретения опыта в работе с языком вы научитесь пользоваться и более развитыми его возможностями.
1.1. Строительные блоки UML
Словарь языка UML включает три вида строительных блоков:
- сущности;
- отношения;
- диаграммы.
Сущности - это абстракции, являющиеся основными элементами модели. Отношения связывают различные сущности; диаграммы группируют представляющие интерес совокупности сущностей.
В UML имеется четыре типа сущностей:
структурные; поведенческие; группирующие; аннотационные.
Сущности являются основными объектно-ориентированными блоками языка. С их помощью можно создавать корректные модели.
Структурные сущности - это имена существительные в моделях на языке UML. Как правило, они представляют собой статические части модели, соответствующие концептуальным или физическим элементам системы. Существует семь разновидностей структурных сущностей.
Класс (Class) - это описание совокупности объектов е общими атрибутами, операциями, отношениями и семантикой. Класс реализует один или несколько интерфейсов. Графически класс изображается в виде прямоугольника, в котором обычно записаны его имя, атрибуты и операции, как показано на рис. 1.1.
Интерфейс (Interface) - это совокупность операций, которые определяют сервис (набор услуг), предоставляемый классом или компонентом. Таким образом, интерфейс описывает видимое извне поведение элемента. Интерфейс может представлять поведение класса или компонента полностью или частично; он определяет только спецификации операций (сигнатуры), но никогда - их реализации. Графически интерфейс изображается в виде круга, под которым пишется его имя, как показано на рис. 1.2. Интерфейс редко существует сам по себе - обычно он присоединяется к реализующему его классу или компоненту.
Кооперация (Collaboration) определяет взаимодействие; она представляет собой совокупность ролей и других элементов, которые, работая совместно, производят некоторый кооперативный эффект, не сводящийся к простой сумме). Кооперация, следовательно, имеет как структурный, так и поведенческий аспект. Один и тот же класс может принимать участие в нескольких кооперациях; таким образом, они являются реализацией образцов поведения, формирующих систему. Графически кооперация изображается в виде эллипса, ограниченного пунктирной линией, в который обычно заключено только имя, как показано на рис. 1.3.
Прецедент (Use case) - это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера (Actor). Прецедент применяется для структурирования поведенческих сущностей модели. Прецеденты реализуются посредством кооперации. Графически прецедент изображается в виде ограниченного непрерывной линией эллипса, обычно содержащего только его имя, как показано на рис. 1.4.
Три другие сущности - активные классы, компоненты и узлы - подобны классам: они описывают совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Тем не менее они в достаточной степени отличаются друг от друга и от классов и, учитывая их важность при моделировании определенных аспектов объектно-ориентированных систем, заслуживают специального рассмотрения.
Активным классом (Active class) называется класс, объекты которого вовлечены в один или несколько процессов, или нитей (Threads), и поэтому могут инициировать управляющее воздействие. Активный класс во всем подобен обычному классу, за исключением того, что его объекты представляют собой элементы, деятельность которых осуществляется одновременно с деятельностью других элементов. Графически активный класс изображается так же, как простой класс, но ограничивающий прямоугольник рисуется жирной линией и обычно включает имя, атрибуты и операции, как показано на рис. 1.5.
Два оставшихся элемента - компоненты и узлы - также имеют свои особенности. Они соответствуют физическим сущностям системы, в то время как пять предыдущих - концептуальным и логическим сущностям.
Компонент (Component) - это физическая заменяемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечивает его реализацию. В системе можно встретить различные виды устанавливаемых компонентов, такие как СОМ+ или Java Beans, а также компоненты, являющиеся арт,ефакта-ми процесса разработки, например файлы исходного кода. Компонент, как правило, представляет собой физическую упаковку логических элементов, таких как классы, интерфейсы и кооперации. Графически компонент изображается в виде прямоугольника с вкладками, содержащего обычно только имя, как показано на рис. 1.6.
Узел (Node) - это элемент реальной (физической) системы, который существует во время функционирования программного комплекса и представляет собой вычислительный ресурс, обычно обладающий как минимум некоторым объемом памяти, а часто еще и способностью обработки. Совокупность компонентов может размещаться в узле, а также мигрировать с одного узла на другой. Графически узел изображается в виде куба, обычно содержащего только имя, как показано на рис. 1.7.
Эти семь базовых элементов - классы, интерфейсы, кооперации, прецеденты, активные классы, компоненты и узлы - являются основными структурными сущностями, которые могут быть включены в модель UML Существуют также разновидности этих сущностей: актеры, сигналы, утилиты (виды классов), процессы и нити (виды активных классов), приложения, документы, файлы, библиотеки, страницы и таблицы (виды компонентов).
Поведенческие сущности (Behavioral things) являются динамическими составляющими модели UML. Это глаголы языка: они описывают поведение модели во времени и пространстве. Существует всего два основных типа поведенческих сущностей.
Взаимодействие (Interaction) - это поведение, суть которого заключается в обмене сообщениями (Messages) между объектами в рамках конкретного контекста для достижения определенной цели. С помощью взаимодействия можно описать как отдельную операцию, так и поведение совокупности объектов. Взаимодействие предполагает ряд других элементов, таких как сообщения, последовательности действий (поведение, инициированное сообщением) и связи (между объектами). Графически сообщения изображаются в виде стрелки, над которой почти всегда пишется имя соответствующей операции, как показано на рис. 1.8.
Автомат (State machine) - это алгоритм поведения, определяющий последовательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ на различные события, а также реакции на эти события). С помощью автомата можно описать поведение отдельного класса или кооперации классов. С автоматом связан ряд других элементов: состояния, переходы (из одного состояния в другое), события (сущности, инициирующие переходы) и виды действий (реакция на переход). Графически состояние изображается в виде прямоугольника с закругленными углами, содержащего имя и, возможно, подсостояния.
Эти два элемента - взаимодействия и автоматы -являются основными поведенческими сущностями, входящими в модель UML Семантически они часто бывают связаны с различными структурными элементами, в первую очередь - классами, кооперациями и объектами.
Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Есть только одна первичная группирующая сущность, а именно пакет.
Пакеты (Packages) представляют собой универсальный механизм организации элементов в группы. В пакет можно поместить структурные, поведенческие и даже другие группирующие сущности. В отличие от компонентов, существующих во время работы программы, пакеты носят чисто концептуальный характер, то есть существуют только во время разработки.
Изображается пакет в виде папки с закладкой, содержащей, как правило, только имя и иногда - содержимое (см. рис. 1.10).
Пакеты - это основные группирующие сущности, с помощью которых можно организовать модель UML. Существуют также вариации пакетов, например каркасы (Frameworks), модели и подсистемы.
Аннотационные сущности - пояснительные части модели UML. Это комментарии для дополнительного описания, разъяснения или замечания к любому элементу модели. Имеется только один базовый тип аннотационных элементов - примечание (Note). Примечание - это просто символ для изображения комментариев или ограничений, присоединенных к элементу или группе элементов. Графически примечание изображается в виде прямоугольника с загнутым краем, содержащим текстовый или графический комментарий, как показано на рис. 1.11.
Этот элемент является основной аннотационной сущностью, которую можно включать в модель UML. Чаще всего примечания используются, чтобы снабдить диаграммы комментариями или ограничениями, которые можно выразить в виде неформального или формального текста. Существуют вариации этого элемента, например требования, где описывают некое желательное поведение с точки зрения внешней по отношению к модели.
В языке UML определены четыре типа отношений:
зависимость; ассоциация; обобщение; реализация.
Эти отношения являются основными связующими строительными блоками в UML и применяются для создания корректных моделей.
Зависимость (Dependency) - это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой. Графически зависимость изображается в виде прямой пунктирной линии, часто со стрелкой, которая может содержать метку (см. рис. 1.13).
Ассоциация (Association) - структурное отношение, описывающее совокупность связей; связь - это соединение между объектами. Разновидностью ассоциации является агрегирование (Aggregation) - так называют структурное отношение между целым и его частями. Графически ассоциация изображается в виде прямой линии (иногда завершающейся стрелкой или содержащей метку), рядом с которой могут присутствовать дополнительные обозначения, например кратность и имена ролей. На рис. 1.13 показан пример отношений этого типа.
Обобщение (Generalization) - это отношение "специализация/обобщение", при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка). (Таким образом, потомок (Child) наследует структуру и поведение своего родителя (Parent). Графически отношение обобщения изображается в виде линии с незакрашенной стрелкой, указывающей на родителя, как показано на рис. 1.14.
Наконец, реализация (Realization) - это семантическое отношение между классификаторами, при котором один классификатор определяет "контракт", а другой гарантирует его выполнение. Отношения реализации встречаются в двух случаях: во-первых, между интерфейсами и реализующими их классами или компонентами, а во-вторых, между прецедентами и реализующими их кооперациями. Отношение реализации изображается в виде пунктирной линии с незакрашенной стрелкой, как нечто среднее между отношениями обобщения и зависимости.
Четыре описанных элемента являются основными типами отношений, которые можно включать в модели UML. Существуют также их вариации, например уточнение (Refinement), трассировка (Trace), включение и расширение (для зависимостей).
Диаграмма в UML - это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями). Диаграммы рисуют для визуализации системы с разных точек зрения. Диаграмма - в некотором смысле одна из проекций системы. Как правило, за исключением наиболее тривиальных случаев, диаграммы дают свернутое представление элементов, из которых составлена система. Один и тот же элемент может присутствовать во всех диаграммах, или только в нескольких (самый распространенный вариант), или не присутствовать ни в одной (очень редко). Теоретически диаграммы могут содержать любые комбинации сущностей и отношений. На практике, однако, применяется сравнительно небольшое количество типовых комбинаций, соответствующих пяти наиболее употребительным видам, которые составляют архитектуру программной системы (см. следующий раздел). Таким образом, в UML выделяют девять типов диаграмм:
- диаграммы классов
- диаграммы объектов;
- диаграммы прецедентов;
- диаграммы последовательностей;
- диаграммы кооперации;
- диаграммы состояний;
- диаграммы действий;
- диаграммы компонентов;
- диаграммы развертывания.
Концептуальная модель UML
На диаграмме классов показывают классы, интерфейсы, объекты и кооперации, а также их отношения. При моделировании объектно-ориентированных систем этот тип диаграмм используют чаще всего. Диаграммы классов соответствуют статическому виду системы с точки зрения проектирования. Диаграммы классов, которые включают активные классы, соответствуют статическому виду системы с точки зрения процессов.
На диаграмме объектов представлены объекты и отношения между ними. Они являются статическими "фотографиями" экземпляров сущностей, показанных на диаграммах классов. Диаграммы объектов, как и диаграммы классов, относятся к статическому виду системы с точки зрения проектирования или процессов, но с расчетом на настоящую или макетную реализацию.
На диаграмме прецедентов представлены прецеденты и актеры (частный случай классов), а также отношения между ними. Диаграммы прецедентов относятся к статическому виду системы с точки зрения прецедентов использования. Они особенно важны при организации и моделировании поведения системы.
Диаграммы последовательностей и кооперации являются частными случаями диаграмм взаимодействия. На диаграммах взаимодействия представлены связи между объектами; показаны, в частности, сообщения, которыми объекты могут обмениваться Диаграммы взаимодействия относятся к динамическому виду системы. При этом диаграммы последовательности отражают временную упорядоченность сообщений, а диаграммы кооперации - структурную организацию обменивающихся сообщениями объектов. Эти диаграммы являются изоморфными, то есть могут быть преобразованы друг в друга.
На диаграммах состояний (Statechart diagrams) представлен автомат, включающий в себя состояния, переходы, события и виды действий. Диаграммы состояний относятся к динамическому виду системы; особенно они важны при моделировании поведения интерфейса, класса или кооперации. Они акцентируют внимание на поведении объекта, зависящем от последовательности событий, что очень полезно для моделирования реактивных систем.
Диаграмма деятельности - это частный случай диаграммы состояний; на ней представлены переходы потока управления от одной деятельности к другой внутри системы. Диаграммы деятельности относятся к динамическому виду системы; они наиболее важны при моделировании ее функционирования и отражают поток управления между объектами.
На диаграмме компонентов представлена организация совокупности компонентов и существующие между ними зависимости. Диаграммы компонентов относятся к статическому виду системы с точки зрения реализации. Они могут быть соотнесены с диаграммами классов, так как компонент обычно отображается на один или несколько классов, интерфейсов или коопераций.
На диаграмме развертывания представлена конфигурация обрабатывающих узлов системы и размещенных в них компонентов. Диаграммы развертывания относятся к статическому виду архитектуры системы с точки зрения развертывания. Они связаны с диаграммами компонентов, поскольку в узле обычно размещаются один или несколько компонентов.
Здесь приведен неполный список диаграмм, применяемых в UML. Инструментальные средства позволяют генерировать и другие диаграммы, но девять перечисленных встречаются на практике чаще всего.
1.2. Правила языка UML
Строительные блоки UML нельзя произвольно объединять друг с другом. Как и любой другой язык, UML характеризуется набором правил, определяющих, как должна выглядеть хорошо оформленная модель, то есть семантически самосогласованная и находящаяся в гармонии со всеми моделями, которые с нею связаны.
В языке UML имеются семантические правила, позволяющие корректно и однозначно определять:
- имена, которые можно давать сущностям, отношениям и диаграммам;
- область действия (контекст, в котором имя имеет некоторое значение);
- видимость (когда имена видимы и могут использоваться другими элементами);
- целостность (как элементы должны правильно и согласованно соотноситься друг с другом);
- выполнение (что значит выполнить или имитировать некоторую динамическую модель).
Модели, создаваемые в процессе разработки программных систем, эволюционируют со временем и могут неоднозначно рассматриваться разными участниками проекта в разное время. По этой причине создаются не только хорошо оформленные модели, но и такие, которые:
- содержат скрытые элементы (ряд элементов не показывают, чтобы упростить восприятие);
- неполные (отдельные элементы пропущены);
- несогласованные (целостность модели не гарантируется).
Появление не слишком хорошо оформленных моделей неизбежно в процессе разработки, пока не все детали системы прояснились в полной мере. Правила языка UML побуждают - хотя не требуют - в ходе работы над моделью решать наиболее важные вопросы анализа, проектирования и реализации, в результате чего модель со временем становится хорошо оформленной.
1.3 Общие механизмы языка UML
Строительство упрощается и ведется более эффективно, если придерживаться некоторых соглашений. Следуя определенным архитектурным образцам, можно оформить здание в викторианском или французском стиле. Тот же принцип применим и в отношении UML. Работу с этим языком существенно облегчает последовательное использование общих механизмов, перечисленных ниже:
- спецификации (Specifications);
- дополнения (Adornments);
- принятые деления (Common divisions);
- механизмы расширения (Extensibility mechanisms).
UML - это не просто графический язык. За каждой частью его системы графической нотации стоит спецификация, содержащая текстовое представление синтаксиса и семантики соответствующего строительного блока. Например, пиктограмме класса соответствует спецификация, полностью описывающая его атрибуты, операции (включая полные сигнатуры) и поведение, хотя визуально пиктограмма порой отражает только малую часть этой совокупности. Более того, может существовать другое представление этого класса, отражающее совершенно иные его аспекты, но тем не менее соответствующее все той же спецификации. С помощью графической нотации UML вы визуализируете систему, с помощью спецификаций UML - описываете ее детали. Таким образом, допустимо строить модель инкрементно, то есть пошаговым образом - сначала нарисовать диаграмму, а потом добавить семантику в спецификацию модели, или наоборот - начать со спецификации (возможно, применив обратное проектирование к существующей системе), а потом на ее основе создавать диаграммы.
Спецификации UML создают семантический задний план, который полностью включает в себя составные части всех моделей системы, согласованные между собой. Таким образом, диаграммы UML можно считать визуальными проекциями на этот задний план, при этом каждая из них раскрывает один из значимых аспектов системы.
Почти каждый из элементов UML имеет соответствующее ему уникальное графическое обозначение, которое дает визуальное представление о самых важных аспектах этого элемента. Например, обозначение класса специально придумано так, чтобы его было легко рисовать, поскольку классы - наиболее употребительный элемент при моделировании объектно-ориентированных систем. Нотация класса содержит самые важные его характеристики: имя, атрибуты и операции.
Спецификация класса может содержать и другие детали, например видимость атрибутов и операций или указание на то, что класс является абстрактным. Многие такие детали можно визуализировать в виде графических или текстовых дополнений к стандартному прямоугольнику, служащему изображением класса. Так, на рис. 1.16 показан класс, в обозначение которого включены сведения о том, что он имеет три открытых атрибута с указанными типами и три открытые операции с параметрами.
Каждый элемент нотации UML содержит базовый для него символ, к которому можно добавлять разнообразные специфичные для него дополнения.
Принятые деления. При моделировании объектно-ориентированных систем реальность членится с учетом по крайней мере двух подходов.
Прежде всего, существует разделение на классы объекты. Класс - это абстракция, объект - конкретная материализация этой абстракции В языке UML можно моделировать и классы, и объекты, как показано на рис. 1.17.
На этом рисунке показан один класс Customer (Клиент) и три объекта: Jan (явно определенный как объект данного класса), :Customer (анонимный объект класса Customer) и Elyse (спецификация которого относит его к классу Customer, хотя это и не выражено явно).
Практически все строительные блоки UML характеризуются дихотомией "класс/объект". Так, имеются прецеденты и экземпляры прецедентов, компоненты и экземпляры компонентов, узлы и экземпляры узлов и т.д. В графическом представлении для объекта принято использовать тот же символ, что и для его класса, а название объекта подчеркивать.
Еще одним вариантом членения является деление на интерфейс и его реализацию. Интерфейс декларирует контракт, а реализация представляет конкретное воплощение этого контракта и обязуется точно следовать объявленной семантике интерфейса. UML позволяет моделировать обе эти категории, интерфейсы и их реализации, как показано на рис. 1.18: в данном случае один компонент spellingwizard.dll реализует два интерфейса lUnknown и ISpelling. Почти все строительные блоки UML характеризуются дихотомией "интерфейс/реализация". Например, прецеденты реализуются кооперациями, а операции - методами.
<< Пред. стр. 1 (из 3) След. >>
Список литературы по разделу