Конспект лекций case cals. Конспект_САСТ-2. Конспект лекций по дисциплине case и cals технологии по направлению подготовки
 Скачать 3.53 Mb.
|
|
8.2. Концепция построения диаграмм UML Процесс построения отдельных типов диаграмм имеет свои особенности, которые тесно связаны с семантикой элементов этих диаграмм. Сам процесс объектно-ориентированного анализа и проектирования в контексте языка UML получил специальное название — рациональный унифицированный процесс (Rational Unified Process, RUP). Суть концепции RUP заключается в последовательной декомпозиции или разбиении процесса объектно-ориентированного анализа и проектирования на отдельные этапы, на каждом из которых осуществляется разработка соответст- вующих типов канонических диаграмм модели системы. При этом порядок эта- пов построения модели следующий: 1) логические представления статической модели структуры системы; 2) логические представления модели поведения; 3) физические представления модели системы. В результате RUP должны быть построены канонические диаграммы на языке UML, при этом последовательность их разработки в основном совпадает с их последовательной нумерацией. 8.3. Основные элементы UML Для диаграмм языка UML существуют три типа визуальных обозначений: 1) связи — представляются различными линиями на плоскости (табл. 8.1); 2) графические символы — изображаются вблизи от тех или иных визу- альных элементов диаграмм (табл. 8.2); 3) текст — содержится внутри отдельных геометрических фигур, форма которых (прямоугольник, эллипс) соответствует некоторым элементам языка UML (класс, вариант использования) и имеет фиксированную семантику. Таблица 8.1 Связующие элементы UML Графический символ Название элемента 109 Графический символ Название элемента отношение ассоциации отношение зависимости отношение наследования Агрегация Композиция приёмник события источник события Замена Граница простой поток управления Ограничение Вызов Рекурсия Возвратить послать Таблица 8.2 Основные графические символы UML Графический символ Название элемента действующее лицо (актёр) вариант использования Примечание пакет 110 Графический символ Название элемента Класс Объект Компонент Узел Кооперация Деятельность Состояние начальное состояние конечное состояние Контроль сущность граница разветвление линия жизни разветвление 8.4. Диаграмма вариантов использования Диаграмма вариантов использования (Use Case Diagram) представляет со- бой графическое изображение взаимодействия некоторой сущности (действую- 111 щего лица) и моделируемой системы. Каждый вариант использования охватыва- ет некоторую функцию системы и решает некоторую дискретную задачу, по- ставленную сущностью перед системой. Список всех вариантов использования фактически определяет функциональные требования к системе. Таким образом, диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в про- цессе её проектирования и разработки. При разработке диаграммы вариантов использования должны быть реше- ны следующие задачи: –– должны быть определены общие границы и контекст предметной об- ласти моделируемой системы; –– должны быть сформулированы общие требования к функциональному поведению проектируемой системы; –– должна быть разработана исходная концептуальная модель системы. Основными элементами диаграммы вариантов использования являются действующее лицо, вариант использования, интерфейс, отношения, примечания. 8.4.1. Действующее лицо Действующее лицо или актёр (Actor) представляет собой некоторую внеш- нюю по отношению к моделируемой системе сущность, которая взаимодейству- ет с системой и использует её функциональные возможности для достижения определённых целей. В общем случае актёр находится вне системы, его внут- ренняя структура никак не определяется. Действующему лицу ставится в соответствие множество логически свя- занных ролей, исполняемых при взаимодействии с системой. Под ролью (Role) понимается поведение сущности, участвующей в конкретном контексте. Стандартным графическим обозначением актёра на диаграммах является фигурка «человечка», под которой записывается его имя (рис. 8.1). 112 Рис. 8.1. Графическое изображение актёра в языке UML Актёрами являются сущности, имеющие отношение к концептуальной мо- дели соответствующей предметной области: клиент, служащий, сотовый теле- фон, станция сотовой связи, абонент, автомобиль и пр. В качестве актёров могут выступать также другие системы, подсистемы проектируемой системы или от- дельные классы. Действующие лица взаимодействуют с системой посредством передачи и приёма сообщений от вариантов использования. Сообщение представляет собой запрос актёром сервиса от системы и получение этого сервиса. Кроме того, с ак- тёрами могут быть связаны интерфейсы, которые определяют, каким образом другие элементы модели взаимодействуют с этими актёрами. 8.4.2. Вариант использования Вариант использования (Use Case) представляет собой внешнюю специфи- кацию последовательности действий, которые система или другая сущность мо- гут выполнять в процессе взаимодействия с действующими лицами. Варианты использования предназначены для определения функциональ- ных требований к системе. Они служат для описания сервисов, которые система предоставляет актёру. Другими словами, каждый вариант использования опре- деляет конечный набор действий, совершаемый системой при диалоге с актёром, а также описывает реакции сущности системы на получение отдельных сообще- ний от действующих лиц и восприятие этих сообщений за пределами сущности. При этом реализация самого взаимодействия не определяется. 113 Вариант использования представляется на диаграмме эллипсом (рис. 8.2), внутри которого или под ним располагается его имя (в форме существительного или глагола). Рис. 8.2. Графическое изображение варианта использования в языке UML 8.4.3. Интерфейс Интерфейс (Interface) представляет собой именованное множество опера- ций, которые характеризуют поведение отдельного элемента модели. Интерфей- сы могут содержать только операции без указания особенностей их реализации. Интерфейс изображается в виде маленького круга, рядом с которым запи- сывается его имя (рис. 8.3). Рис. 8.3. Графическое изображение интерфейса в языке UML Формально интерфейс не только отделяет спецификацию операций систе- мы от их реализации, но и определяет общие границы проектируемой системы. Интерфейсы определяют стыковочные узлы в проектируемой системе и позво- ляют безболезненно модифицировать уже существующую систему при переходе на новые технологические решения. 114 8.4.4. Отношения Отношение (Relationship) представляет собой семантическую связь между отдельными элементами модели. Различные виды отношений в той или иной степени используются при построении всех диаграмм. В языке UML определены следующие виды отношений между действую- щими лицами и вариантами использования: ассоциации, расширения, включе- ния, обобщения. Отношение ассоциации (Association Relationship) представляет собой структурное отношение, показывающее, что объекты одного типа некоторым образом связаны с объектами другого типа. В ассоциации могут связываться два или более объектов. Тогда ассоциация называется соответственно бинарной или n-арной. Графически отношение ассоциации обозначается сплошной линией ме- жду взаимодействующими объектами системы (рис. 8.4). Ассоциации может быть присвоено имя (Name), характеризующее природу связи. Ассоциация также может иметь кратность (Multiplicity), характеризую- щую общее количество конкретных экземпляров данного компонента, которые могут выступать в качестве элементов данной ассоциации. Кратность указывает- ся рядом с обозначением компонента диаграммы, являющегося участником дан- ной ассоциации. Рис. 8.4. Графическое изображение ассоциации в языке UML между актё- ром и вариантом использования с указанием кратности 115 Применительно к диаграммам вариантов использования ассоциация слу- жит для обозначения специфической роли актёра при его взаимодействии с от- дельным вариантом использования. Отношение расширения (Extend Relationship) определяет взаимосвязь ба- зового варианта использования с другим вариантом использования, функцио- нальное поведение которого задействуется базовым не всегда, а только при вы- полнении дополнительных условий. Отношение расширения является отношением зависимости (Dependency Relationship), т.е. связью между объектами системы, при которой изменение в спецификации одного объекта может повлиять на поведение другого объекта, использующего первый объект. Зависимость изображается прерывистой линией со стрелкой, направленной к объекту, от которого имеется зависимость. Отношение расширения между вариантами использования обозначается, как и зависимость, пунктирной линией со стрелкой, направленной от того вари- анта использования, который является расширением для исходного варианта ис- пользования. Данная линия со стрелкой помечается ключевым словом «extend» (рис. 8.5). В представленном на рис. 8.5 примере при оформлении заказа услуг у опе- ратора только в некоторых случаях может потребоваться предоставление кли ен- ту списка всех возможных услуг. При этом условием расширения является за- прос от клиента на получение списка возможных услуг. Рис. 8.5. Графическое изображение отношения расширения в языке UML Отношение включения (Include Relationship) также является разновидно- стью отношения зависимости, но устанавливается только между двумя вариан- 116 тами использования и указывает на то, что заданное поведение для одного вари- анта использования включается в качестве составного фрагмента в последова- тельность поведения другого варианта использования. Графически данное отно- шение обозначается как отношение зависимости в форме пунктирной линии со стрелкой, направленной от базового варианта использования к включаемому ва- рианту использования, с указанием ключевого слова «include» (рис. 8.6). Рис. 8.6. Графическое изображение отношения включения в языке UML Отношение обобщения (Generalization Relationship) представляет собой связь между общей сущностью, называемой родителем, и более специализиро- ванной разновидностью этой сущности, называемой потомком. Потомок насле- дует все свойства и поведение своего родителя, но потомок может иметь собст- венное поведение и свойства. В UML допускается и множественное наследова- ние, когда один объект-потомок определяется на основе нескольких родитель- ских объектов. Графически данное отношение обобщения обозначается сплош- ной линией со стрелкой в форме незакрашенного треугольника, указывающей на родительский объект (рис. 8.7). Рис. 8.7. Графическое изображение отношения обобщения в языке UML 117 8.4.5. Примечания Примечания (Notes) предназначены для включения в модель произвольной текстовой информации, имеющей непосредственное отношение к контексту раз- рабатываемого проекта. Графически примечания обозначаются прямоугольни- ком с «загнутым» верхним правым уголком, внутри которого содержится текст примечания. Примечание может относиться к любому элементу диаграммы, в этом случае их соединяет пунктирная линия (рис. 8.8). Рис. 8.8. Графическое изображение примечания в языке UML Примечания могут присутствовать не только на диаграмме вариантов ис- пользования, но и на других канонических диаграммах. 8.4.6. Пример диаграммы вариантов использования В качестве примера рассмотрим модель системы оказания услуг (рис. 8.9). 118 Рис. 8.9. Пример диаграммы вариантов использования Здесь в качестве действующих лиц системы выступают два субъекта — Клиент и Сотрудник компании, оказывающей, например, услуги сотовой связи. Каждый из них взаимодействует с системой, обращаясь к сервису Оформить за- каз на услугу, который выступает в качестве варианта использования разрабаты- ваемой диаграммы. Значения указанных на диаграмме кратностей отражают об- щие правила и логику оформления заказов на услугу: один сотрудник может участвовать в оформлении нескольких заказов, но каждый заказ может быть оформлен только одним сотрудником, который несёт ответственность за кор- ректность его оформления; аналогично каждый клиент может оформлять на себя несколько заказов, но в то же время каждый заказ должен быть оформлен на единственного покупателя. В качестве отдельных сервисов на диаграмме выделены такие действия, как Обеспечить клиента информацией об услуге, Согласовать условия оплаты, 119 которые раскрывают поведение исходного варианта использования, и поэтому между ними имеет место отношение включения. Оказание услуг предполагает наличие самостоятельного информационного объекта — списка возможных оказываемых услуг, который не зависит от реали- зации сервиса по обслуживанию клиентов, т.к. может запрашиваться как клиен- тами, так и сотрудниками компании. Также на диаграмме присутствует объект Форма заказа, который выступа- ет в качестве интерфейса взаимодействия Клиента и Сотрудника компании при оформлении заказа на услугу. 8.5. Диаграмма классов Диаграммой классов (Class Diagram) в терминологии UML называется диа- грамма, на которой показан набор классов и связей между этими классами. Диаграмма классов не содержит информации о временных аспектах функ- ционирования системы. Она предназначена для представления только статиче- ской структуры модели системы. В этом представлении удобнее всего описывать функциональные требования к системе — услуги, которые система предоставля- ет конечному пользователю. Диаграмма классов может содержать следующие сущности: классы, отно- шения (зависимости, обобщения, ассоциации, кооперации), интерфейсы, ком- ментарии, ограничения, пакеты, подсистемы. 8.5.1. Класс Классом (Class) называется именованное описание совокупности объектов с общими атрибутами, операциями, связями и семантикой. Графически класс изображается в виде прямоугольника, который дополнительно может быть раз- делен горизонтальными линиями на секции, содержащие имя класса, атрибуты (переменные) и операции (методы) (рис. 8.10). Имя класса уникально в пределах пакета, указывается по центру в первой верхней секции прямоугольника полу- жирным шрифтом с заглавной буквы. 120 Рис. 8.10. Графическое изображение класса в языке UML Атрибутом (Attribute) называется именованное свойство класса, описы- вающее множество значений, которые могут принимать экземпляры этого свой- ства. Класс может иметь любое число атрибутов. Свойство, выражаемое атрибу- том, является свойством моделируемой сущности, общим для всех объектов данного класса. Всем атрибутам должно быть присвоено некоторое значение. Имена атрибутов представляются в разделе класса, расположенном под именем класса. Каждому атрибуту класса соответствует отдельная строка текста, которая может состоять из квантора видимости, имени, кратности, типа значений атри- бута и его исходного значения: <квантор видимости><имя>[кратность]:<тип>=<исходное значение>{свойство} Квантор видимости (Visibility) может принимать одно из следующих зна- чений: –– символ «+» — общедоступный (Public) — атрибут доступен или виден из любого другого класса пакета, в котором определена диаграмма; –– символ «#» — защищённый (Protected) — атрибут недоступен или не- виден для всех классов, за исключением подклассов данного класса; –– символ «−» — закрытый (Private) — атрибут недоступен или невиден для всех классов без исключения; 121 –– символ « » — пакетный (Package) — атрибут недоступен или невиден для всех классов за пределами пакета, в котором определён класс-владелец дан- ного атрибута. Имя атрибута представляет собой текстовую строку, которая используется в качестве идентификатора соответствующего атрибута и поэтому должна быть уникальной в пределах данного класса. Кратность атрибута (Multiplicity) характеризует общее количество кон- кретных атрибутов данного типа, входящих в состав отдельного класса. Тип атрибута представляет собой выражение, семантика которого обу- словлена некоторым типом данных, определённым в пакете «Типы данных» языка UML или самим разработчиком. Исходное значение служит для задания начального значения соответст- вующего атрибута в момент создания отдельного экземпляра класса. Операцией (Operation) или методом класса называется именованная услу- га, которую можно запросить у любого объекта этого класса. Совокупность опе- раций характеризует функциональный аспект поведения класса. Операции класса определяются в разделе, расположенном ниже раздела с атрибутами. Каждой операции класса соответствует отдельная строка текста, ко- торая может состоять из квантора видимости, имени, списка параметров опера- ции, типа возвращаемого операцией значения: <квантор видимости><имя>(список параметров):<тип возвр.знач.>={свойство} Правила задания квантора видимости и имени операции аналогичны их определению для атрибутов. Список параметров является перечнем разделённых запятой формальных параметров, каждый из которых может быть представлен в следующем виде: <вид параметра><имя параметра>:<выражение типа>=<знач. по умолчанию>, где вид параметра — одно из ключевых слов in, out или inout; имя пара- метра — идентификатор соответствующего формального параметра; выражение типа является зависимой от конкретного языка программирования спецификаци- ей типа возвращаемого значения для соответствующего формального параметра; 122 значение по умолчанию в общем случае представляет собой выражение для зна- чения формального параметра, синтаксис которого зависит от конкретного языка программирования и подчиняется принятым в нём ограничениям. Выражение типа возвращаемого значения является зависимой от языка реализации спецификацией типов значений параметров, которые возвращаются объектом после выполнения соответствующей операции. Свойство служит для указания значений свойств, которые могут быть применены к данному элементу. |