курсовая работа. Учебное пособие по дисциплине технология разработки программного обеспечения специальность Программирование в компьютерных системах
 Скачать 7.57 Mb.
|
|
Глава 6. Язык визуального моделирования UML 1. Базис UML Для создания моделей анализа и проектирования объектно-ориентированных программных систем используют языки визуального моделирования. Появившись сравнительно недавно, в период с 1989 по 1997 год, эти языки уже имеют представительную историю развития. В настоящее время различают три поколения языков визуального моделирования. И если первое поколение образовали 10 языков, то численность второго поколения уже превысила 50 языков. Каждый язык вводил свои выразительные средства, ориентировался на собственный синтаксис и семантику, иными словами — претендовал на роль единственного и неповторимого языка. В результате разработчики (и пользователи этих языков) перестали понимать друг друга. Возникла острая необходимость унификации языков. Идея унификации привела к появлению языков 3-го поколения. В качестве стандартного языка третьего поколения был принят Unified Modeling Language (UML), создававшийся в 1994-1997 годах (основные разработчики Г. Буч, Дж. Рамбо, И. Джекобсон). UML — стандартный язык для написания моделей анализа, проектирования и реализации объектно-ориентированных программных систем. UML может использоваться для визуализации, спецификации, конструирования и документирования результатов программных проектов. UML — это не визуальный язык программирования, но его модели прямо транслируются в текст на языках программирования (Java, C++, Visual Basic, Ada 95, Object Pascal) и даже в таблицы для реляционной БД. Словарь UML образуют три разновидности строительных блоков: предметы, отношения, диаграммы. 1.1.Предметы в UML Предметы — это абстракции, которые являются основными элементами в модели, отношения связывают эти предметы, диаграммы группируют коллекции предметов. В UML имеются четыре разновидности предметов: структурные предметы; предметы поведения;группирующие предметы; поясняющие предметы. Эти предметы являются базовыми объектно-ориентированными строительными блоками. Они используются для написания моделей. 1.1.Структурные предметы Структурные предметы являются существительными в UML-моделях. Они представляют статические части модели — понятийные или физические элементы. Перечислим восемь разновидностей структурных предметов. 1. Класс — описание множества объектов, которые разделяют одинаковые свойства, операции, отношения и семантику (смысл). Класс реализует один или несколько интерфейсов. Как показано на рис. 1, графически класс отображается в виде прямоугольника, обычно включающего секции с именем, свойствами (атрибутами) и операциями.
Рис.1.Классы 2  . Интерфейс — набор операций, которые определяют услуги класса или компонента. Интерфейс описывает поведение элемента, видимое извне. Интерфейс может представлять полные услуги класса или компонента или часть таких услуг. Интерфейс определяет набор спецификаций операций (их сигнатуры), а не набор реализаций операций. Графически интерфейс изображается в виде кружка с именем, как показано на рис.2. Имя интерфейса обычно начинается с буквы «I». Интерфейс редко показывают самостоятельно. Обычно его присоединяют к классу или компоненту, который реализует интерфейс.  Рис.2.Интерфейсы 3. Кооперация (сотрудничество) определяет взаимодействие и является совокупностью ролей и других элементов, которые работают вместе для обеспечения коллективного поведения более сложного, чем простая сумма всех элементов. Таким образом, кооперации имеют как структурное, так и поведенческое измерения. Конкретный класс может участвовать в нескольких кооперациях. Эти кооперации представляют реализацию паттернов (образцов), которые формируют систему. Как показано на рис.3, графически кооперация изображается как пунктирный эллипс, в который вписывается ее имя. обслуживание клиента  Рис.3. Кооперации4. Актер — набор согласованных ролей, которые могут играть пользователи при взаимодействии с системой (ее элементами Use Case). Каждая роль требует от системы определенного поведения. Как показано на рис. 4, актер изображается как проволочный человечек с именем.  Заказчик Рис.4.Актеры 5. Элемент Use Case (Прецедент) — описание последовательности действий (или нескольких последовательностей), выполняемых системой в интересах отдельного актера и производящих видимый для актера результат. В модели элемент Use Case применяется для структурирования предметов поведения. Элемент Use Case реализуется кооперацией. Как показано на рис. 5, элемент Use Case изображается как эллипс, в который вписывается его имя.  Рис.5.Элементы UseCase 6. Активный класс — класс, чьи объекты имеют один или несколько процессов (или потоков) и поэтому могут инициировать управляющую деятельность. Активный класс похож на обычный класс за исключением того, что его объекты действуют одновременно с объектами других классов. Как показано на рис. 6, активный класс изображается как утолщенный прямоугольник, обычно включающий имя, свойства (атрибуты) и операции.
Рис.6.Активные классы 7. Компонент— физическая и заменяемая часть системы, которая соответствует набору интерфейсов и обеспечивает реализацию этого набора интерфейсов. В систему включаются как компоненты, являющиеся результатами процесса разработки (файлы исходного кода), так и различные разновидности используемых компонентов (СОМ+-компоненты, Java Beans). Обычно компонент — это физическая упаковка различных логических элементов (классов, интерфейсов и коопераций). Как показано на рис. 10.7, компонент изображается как прямоугольник с вкладками, обычно включающий имя.  Рис.7.Компоненты 8.Узел — физический элемент, который существует в период работы системы и представляет ресурс, обычно имеющий память и возможности обработки. В узле размещается набор компонентов, который может перемещаться от узла к узлу. Как показано на рис. 8, узел изображается как куб с именем.  Рис.8.Узлы 1.2.Предметы поведения Предметы поведения — динамические части UML-моделей. Они являются глаголами моделей, представлением поведения во времени и пространстве. Существуют две основные разновидности предметов поведения. 1. Взаимодействие— поведение, заключающее в себе набор сообщений, которыми обменивается набор объектов в конкретном контексте для достижения определенной цели. Взаимодействие может определять динамику как совокупности объектов, так и отдельной операции. Элементами взаимодействия являются сообщения, последовательность действий (поведение, вызываемое сообщением) и связи (соединения между объектами). Как показано на рис. 9, сообщение изображается в виде направленной линии с именем ее операции. display  Рис.9.Сообщения 2. Конечный автомат — поведение, которое определяет последовательность состояний объекта или взаимодействия, выполняемые в ходе его существования в ответ на события (и с учетом обязанностей по этим событиям). С помощью конечного автомата может определяться поведение индивидуального класса или кооперации классов. Элементами конечного автомата являются состояния, переходы (от состояния к состоянию), события (предметы, вызывающие переходы) и действия (реакции на переход). Как показано на рис. 10.10, состояние изображается как закругленный прямоугольник, обычно включающий его имя и его подсостояния (если они есть).  Рис.10.Состяния Эти два элемента — взаимодействия и конечные автоматы — являются базисными предметами поведения, которые могут включаться в UML-модели. Семантически эти элементы ассоциируются с различными структурными элементами (прежде всего с классами, кооперациями и объектами). 1.3.Группирующие предметы Группирующие предметы — организационные части UML-моделей. Это ящики, по которым может быть разложена модель. Предусмотрена одна разновидность группирующего предмета — пакет. Пакет — общий механизм для распределения элементов по группам. В пакет могут помещаться структурные предметы, предметы поведения и даже другие группировки предметов. В отличие от компонента (который существует в период выполнения), пакет — чисто концептуальное понятие. Это означает, что пакет существует только в период разработки. Как показано на рис. 11, пакет изображается как папка с закладкой, на которой обозначено его имя и, иногда, его содержание.  Рис.11.Пакеты 1.4.Поясняющие предметы Поясняющие предметы — разъясняющие части UML-моделей. Они являются замечаниями, которые можно применить для описания, объяснения и комментирования любого элемента модели. Предусмотрена одна разновидность поясняющего предмета — примечание. Примечание — символ для отображения ограничений и замечаний, присоединяемых к элементу или совокупности элементов. Как показано на рис.12, примечание изображается в виде прямоугольника с загнутым углом, в который вписывается текстовый или графический комментарий.  Рис.12.Примечания 1.2.Отношения в UML В UML имеются четыре разновидности отношений: 1)зависимость; 2)ассоциация; 3)обобщение; 4)реализация. Эти отношения являются базовыми строительными блоками отношений. Они используются при написании моделей. 1. Зависимость— семантическое отношение между двумя предметами, в котором изменение в одном предмете (независимом предмете) может влиять на семантику другого предмета (зависимого предмета). Как показано на рис. 13, зависимость изображается в виде пунктирной линии, возможно направленной на независимый предмет и иногда имеющей метку. Зависимый-------------Независимый Рис. 13. Зависимости 2 1 * . Ассоциация— структурное отношение, которое описывает набор связей, являющихся соединением между объектами. Агрегация — это специальная разновидность ассоциации, представляющая структурное отношение между целым и его частями. Как показано на рис. 14, ассоциация изображается в виде сплошной линии, возможно направленной, иногда имеющей метку и часто включающей другие «украшения», такие как мощность и имена ролей. Заказчик Заказ Рис. 14. Ассоциации 3. Обобщение— отношение специализации/обобщения, в котором объекты специализированного элемента (потомка, ребенка) могут заменять объекты обобщенного элемента (предка, родителя). Иначе говоря, потомок разделяет структуру и поведение родителя. Как показано на рис. 15, обобщение изображается в виде сплошной стрелки с полым наконечником, указывающим на родителя. Потомок Родитель Рис..15. Обобщения 4. Реализация — семантическое отношение между классификаторами, где один классификатор определяет контракт, который другой классификатор обязуется выполнять (к классификаторам относят классы, интерфейсы, компоненты, элементы Use Case, кооперации). Отношения реализации применяют в двух случаях: между интерфейсами и классами (или компонентами), реализующими их; между элементами Use Case и кооперациями, которые реализуют их. Как показано на рис. 16, реализация изображается как нечто среднее между обобщением и зависимостью. Рис.16.Реализации 1.3.Диаграммы в UML Диаграмма — графическое представление множества элементов, наиболее часто изображается как связный граф из вершин (предметов) и дуг (отношений). Диаграммы рисуются для визуализации системы с разных точек зрения, затем они отображаются в систему. Обычно диаграмма дает неполное представление элементов, которые составляют систему. Хотя один и тот же элемент может появляться во всех диаграммах, на практике он появляется только в некоторых диаграммах. Теоретически диаграмма может содержать любую комбинацию предметов и отношений, на практике ограничиваются малым количеством комбинаций, которые соответствуют пяти представлениям архитектуры ПС. По этой причине UML включает 9 видов диаграмм: диаграммы классов; диаграммы объектов; диаграммы Use Case (диаграммы прецедентов); диаграммы последовательности; диаграммы сотрудничества (кооперации); диаграммы схем состояний; диаграммы деятельности; компонентные диаграммы; диаграммы размещения (развертывания). Диаграмма классов показывает набор классов, интерфейсов, сотрудничеств и их отношений. При моделировании объектно-ориентированных систем диаграммы классов используются наиболее часто. Диаграммы классов обеспечивают статическое проектное представление системы. Диаграммы классов, включающие активные классы, обеспечивают статическое представление процессов системы. Диаграмма объектов показывает набор объектов и их отношения. Диаграмма объектов представляет статический «моментальный снимок» с экземпляров предметов, которые находятся в диаграммах классов. Как и диаграммы классов, эти диаграммы обеспечивают статическое проектное представление или статическое представление процессов системы (но с точки зрения реальных или фототипичных случаев). Диаграмма Use Case (диаграмма прецедентов) показывает набор элементов Use Case, актеров и их отношений. С помощью диаграмм Use Case для системы создается статическое представление Use Case. Эти диаграммы особенно важны при организации и моделировании поведения системы, задании требований заказчика к системе. Диаграммы последовательности и диаграммы сотрудничества — это разновидности диаграмм взаимодействия.Диаграмма взаимодействия показывает взаимодействие, включающее набор объектов и их отношений, а также пересылаемые между объектами сообщения. Диаграммы взаимодействия обеспечивают динамическое представление системы. Диаграмма последовательности — это диаграмма взаимодействия, которая выделяет упорядочение сообщений по времени. Диаграмма сотрудничества (диаграмма кооперации) — это диаграмма взаимодействия, которая выделяет структурную организацию объектов, посылающих и принимающих сообщения. Диаграммы последовательности и диаграммы сотрудничества изоморфны, что означает, что одну диаграмму можно трансформировать в другую диаграмму. Диаграмма схем состояний показывает конечный автомат, представляет состояния, переходы, события и действия. Диаграммы схем состояний обеспечивают динамическое представление системы. Они особенно важны при моделировании поведения интерфейса, класса или кооперации. Эти диаграммы выделяют такое поведение объекта, которое управляется событиями, что особенно полезно при моделировании реактивных систем. Диаграмма деятельности — специальная разновидность диаграммы схем состояний, которая показывает поток от действия к действию внутри системы. Диаграммы деятельности обеспечивают динамическое представление системы. Они особенно важны при моделировании функциональности системы и выделяют поток управления между объектами. Компонентная диаграмма показывает организацию набора компонентов и зависимости между компонентами. Компонентные диаграммы обеспечивают статическое представление реализации системы. Они связаны с диаграммами классов в том смысле, что в компонент обычно отображается один или несколько классов, интерфейсов или коопераций. Диаграмма размещения (диаграмма развертывания) показывает конфигурацию обрабатывающих узлов периода выполнения, а также компоненты, живущие в них. Диаграммы размещения обеспечивают статическое представление размещения системы. Они связаны с компонентными диаграммами в том смысле, что узел обычно включает один или несколько компонентов. 2. Диаграммы USE CASE 2.1 Особенности диаграмм Use Case Диаграмма Use Case определяет поведение системы с точки зрения пользователя. Диаграмма Use Case рассматривается как главное средство для первичного моделирования динамики системы, используется для выяснения требований к разрабатываемой системе, фиксации этих требований в форме, которая позволит проводить дальнейшую разработку. В русской литературе диаграммы Use Case часто называют диаграммами прецедентов, или диаграммами вариантов использования. В течение достаточно длительного периода времени в процессе как объектно-ориентированного, так и традиционного структурного проектирования разработчики использовали типичные сценарии, помогающие лучше понять требования к системе. Эти сценарии трактовались весьма неформально — они почти всегда использовались и крайне редко документировались. Ивар Якобсон впервые ввел понятие "вариант использования" (Use Case) и придал ему такую значимость, что он превратился в основной элемент разработки и планирования проекта. Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой. Например, два типичных варианта использования обычного текстового процессора — "сделать некоторый текст полужирным" и "создать индекс". Даже на таком простом примере можно выделить ряд свойств варианта использования: он ухватывает некоторую очевидную для пользователей функцию, может быть как небольшим, так и достаточно крупным и решает для пользователя, некоторую дискретную задачу. В простейшем случае" вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать. Когда Якобсон в 1994 г. предложил варианты использования в качестве основных элементов процесса разработки ПО, он также предложил применять для их наглядного представления диаграммы вариантов использования В состав диаграмм Use Case прежде всего входят: элементы Use Case ; актеры; отношения - зависимости, обобщения и ассоциации. Как и другие диаграммы, диаграммы Use Case могут включать примечания и ограничения. Кроме того, диаграммы Use Case могут содержать пакеты, используемые для группировки элементов модели в крупные фрагменты. 2.2 Актеры и элементы Use Case Вершинами в диаграмме Use Case являются актеры и элементы Use Case . Актеры представляют внешний мир, нуждающийся в работе системы. Элементы Use Case представляют действия, выполняемые системой в интересах актеров.  Актер — это роль объекта вне системы, который прямо взаимодействует с ее частью — конкретным элементом (элементом Use Case ). Различают актеров и пользователей. Пользователь — это физический объект, который использует систему. Он может играть несколько ролей и поэтому может моделироваться несколькими актерами. Справедливо и обратное — актером могут быть разные пользователи. Например, для коммерческого летательного аппарата можно выделить двух актеров: пилота и кассира. Сидоров — пользователь, который иногда действует как пилот, а иногда — как кассир.  Элемент Use Case — это описание последовательности действий (или нескольких последовательностей), которые выполняются системой и производят для отдельного актера видимый результат. Один актер может использовать несколько элементов Use Case и наоборот, один элемент Use Case может иметь несколько актеров, использующих его. Каждый элемент Use Case задает определенный путь использования системы. Набор всех элементов Use Case определяет полные функциональные возможности системы. Варианты использования являются необходимым средством на стадии формирования требований к ПО. Каждый вариант использования — это потенциальное требование к системе, и пока оно не выявлено, невозможно запланировать его реализацию. Хорошим источником для идентификации вариантов использования служат внешние события. Следует начать с перечисления всех событий, происходящих во внешнем мире, на которые система должна каким-то образом реагировать. Какое-либо конкретное событие может повлечь за собой реакцию системы, не требующую вмешательства пользователей, или, наоборот, вызвать чисто пользовательскую реакцию. Идентификация событий, на которые необходимо реагировать, помогает выделить варианты использования. Различные разработчики подходят к описанию вариантов использования с разной степенью детализации. Например, Ивар Якобсон утверждает, что для проекта с трудоемкостью в 10 человеко-лет количество вариантов использования может составлять около 20 (не считая связей «использование» и «расширение»). Следует предпочитать небольшие и детализированные варианты использования, поскольку они облегчают составление и реализацию согласованного плана проекта. 2.3 Отношения в диаграммах Use Case Между актером и элементом Use Case возможен только один вид отношения — ассоциация, отображающая их взаимодействие . Как и любая другая ассоциация, она может быть помечена именем, ролями, мощностью.  Между актерами допустимо отношение обобщения, означающее, что экземпляр потомка может взаимодействовать с такими же разновидностями экземпляров элементов Use Case , что и экземпляр родителя.  Между элементами Use Case определены отношение обобщения и две разновидности отношения зависимости — включения и расширения. Отношение обобщения фиксирует, что потомок наследует поведение родителя. Кроме того, потомок может дополнить или переопределить поведение родителя. Элемент Use Case , являющийся потомком, может замещать элемент Use Case , являющийся родителем, в любом месте диаграммы.  Отношение включения между элементами Use Case означает, что базовый элемент Use Case явно_ включает поведение другого элемента Use Case в точке, которая определена в базе. Включаемый элемент Use Case никогда не используется самостоятельно — его конкретизация может быть только частью другого, большего элемента Use Case. Отношение включения является примером отношения делегации. При этом в отдельное место (включаемый элемент Use Case) помещается определенный набор обязанностей системы. Далее остальные части системы могут агрегировать в себя эти обязанности (при необходимости).   Отношение расширения между элементами Use Case означает, что базовый элемент Use Case неявно включает поведение другого элемента Use Case в точке, которая определяется косвенно расширяющим элементом Use Case. Базовый элемент Use Case может быть автономен, но при определенных условиях его поведение может расширяться поведением из другого элемента Use Case. Базовый элемент Use Case может расширяться только в определенных точках — точках расширения. Отношение расширения применяется для моделирования выбираемого поведения системы. Таким способом можно отделить обязательное поведение от необязательного поведения. Например, можно использовать отношение расширения для отдельного подпотока, который выполняется только при определенных условиях, находящихся вне поля зрения базового элемента Use Case . Наконец, можно моделировать отдельные потоки, вставка которых в определенную точку управляется актером. 2.4 Примеры диаграмм USE CASE Пример 1 простейшей диаграммы Use Case , в которой использованы отношения включения и расширения.  Внутри элемента Use Case может быть дополнительная секция с заголовком Extension points. В этой области перечисляются точки расширения. В указанную здесь точку дополнительные запросы вставляется последовательность действий от расширяющего элемента Use Case «Запрос каталога». Для справки отмечено, что точка расширения размещена после действий, обеспечивающих создание заказа. На этом же рисунке отображены отношения наследования между элементами Use Case . Видно, что элементы Use Case «Оплата наличными2 и «Оплата в кредит» наследуют поведение элемента Use Case «Произвести оплату» и являются его специализациями. Пример 2. - Варианты использования для системы торговой организации; человеческие фигурки здесь обозначают действующих лиц, овалы - варианты использования, а линии и стрелки — различные связи между действующими лицами и вариантами использования. Действующее лицо (актер) — это роль, которую пользователь играет по отношению к системе. В примере представлены четыре действующих лица: Менеджер по продажам, Оптовый торговец, Продавец и Система учета. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. Несмотря на то, что на диаграммах вариантов использования они изображаются в виде стилизованных человеческих фигурок, действующее лицо может также быть внешней системой, которой необходима некоторая информация от данной системы (например, Система учета). Показывать на диаграмме действующих лиц системы следует только в том случае, когда им действительно необходимы некоторые варианты использования.  Все варианты использования так или иначе связаны с внешними требованиями к функциональности системы. Если Системе учета требуется файл, то это требование должно быть удовлетворено. Варианты использования всегда следует анализировать вместе с действующими лицами системы, определяя при этом реальные задачи пользователей и рассматривая альтернативные способы решения этих задач. Действующие лица могут играть различные роли по отношению" к варианту использования. Они могут пользоваться его результатами или могут сами непосредственно в нем участвовать. Значимость различных ролей действующего лица зависит от того, каким образом используются его связи. В дополнение к связям между действующими лицами и вариантами I использования существуют два других типа связей: "использование" "расширение" между вариантами использования. Связь типа "расширение" применяется тогда, когда один вариант использования подобен другому, но несет несколько большую нагрузку. В данном примере основным вариантом использования является Заключить сделку. В этом варианте предполагается нормальный ход процесса. Однако в случае превышения некоторого лимита — например, максимальной суммы торговой сделки, установленной для конкретного клиента, процесс, связанный с данным вариантом использования, не может выполняться обычным образом и должен претерпеть некоторое изменение. Такое изменение можно предусмотреть в рамках основного варианта использования Заключить сделку. Однако такой подход может привести к загромождению варианта использования разной "побочной" логикой, за которой теряется его "нормальная" логика. Другой способ учесть изменение — это поместить нормальный процесс в рамки одного варианта использования, а все отклонения от него — в другие варианты. Связь "использование" применяется в тех ситуациях, когда имеется какой-либо фрагмент поведения системы, который повторяется более чем в одном варианте использования, и нет необходимости копировать его описание в каждом из этих вариантов. Например, варианты Проанализировать риск и Договориться о цене требуют оценки стоимости сделки. Таким образом, создается отдельный вариант использования под названием Оценка стоимости, и предыдущие два варианта будут на него ссылаться. Отметим сходства и различия между связями "расширение" и "использование". Оба они предполагают выделение общих фрагментов поведения из нескольких вариантов использования в единственный вариант, который "используется" или "расширяет" несколько других вариантов. С другой стороны, в каждом случае это делается с различными целями. Два типа связей подразумевают различный смысл связей с действующими лицами. В случае "расширения" у действующих лиц имеется связь с основным вариантом использования. При этом предполагается, что данное действующее лицо реализует как основной вариант использования, так и все его расширения. В случае применения связи "использование" действующие лица, связанные с общим вариантом использования, как правило, отсутствуют. Даже если имеются исключения, то такое действующее лицо не имеет отношения к реализации других вариантов использования. Выбор применяемой связи определяется следующими правилами: связь "расширение" следует применять при описании изменений в нормальном поведении системы; связь "использование" следует применять во избежание повторов в двух (или более) вариантах использования. 3. Модели реализации объектно-ориентированных программных систем в UML 3.1.Компонентные диаграммы Компонентная диаграмма — первая из двух разновидностей диаграмм реализации, моделирующая физические аспекты объектно-ориентированных систем. Компонентная диаграмма показывает организацию набора компонентов и зависимости между компонентами. Элементами компонентных диаграмм являются компоненты и интерфейсы, а также отношения зависимости и реализации. Как идругие диаграммы, компонентные диаграммы могут включать примечания и ограничения. Кроме того, компонентные диаграммы могут содержать пакеты или подсистемы, используемые для группировки элементов модели в крупные фрагменты. Компоненты .По своей сути компонент является физическим фрагментом реализации системы , который заключает в себе программный код (исходный, двоичный, исполняемый) сценарные описания или наборы команд операционной системы (имеются в виду командные файлы). Язык UML. дает следующее определение. Компонент — физическая и заменяемая часть системы, которая соответствует набору интерфейсов и обеспечивает реализацию этогонабора интерфейсов. Интерфейс — очень важная часть понятия «компонент». Графически компонент изображается как прямоугольник с вкладками, обычно включающий имя (рис. 17).  Рис.17.Обозначение компонента Компонент — базисный строительный блок физического представления ПО, поэтому интересно сравнить его с базисным строительным блоком логического представления ПО — классом. Сходные характеристики компонента и класса: наличие имени; реализация набора интерфейсов; участие в отношениях зависимости; возможность быть вложенным ; наличие экземпляров (экземпляры компонентов можно использовать только в диаграммах размещения). И, тем не менее, между компонентами и классами есть существенная разница:
 Рис..18. Классы в компоненте Итак, в компоненте — физической реализации — располагается набор логики. Как показано на рис. 18, с помощью отношения зависимости можно явно отобразить отношение между компонентом и классами, которые он реализует. Интерфейсы Интерфейс — список операций, которые определяют услуги класса или компонента. С помощью интерфейсов компоненты стыкуются друг с другом, объединяясь в систему. Все операции интерфейса открыты и видимы клиенту (в противном случае они потеряли бы всякий смысл). Итак, операции интерфейса только именуют предлагаемые услуги, не более того. Очень важна взаимосвязь между компонентом и интерфейсом. Возможны два способа отображения взаимосвязи между компонентом и его интерфейсами. В первом, свернутом способе, как показано на рис. 19, интерфейс изображается в форме пиктограммы. Компонент Образ.java, который реализует интерфейс, соединяется со значком интерфейса (кружком). Наблюдатель Образа простой линией. Компонент РыцарьПечальногоОбраза.java, который использует интерфейс, связан с ним отношением зависимости.  Рис. 19. Представление интерфейса в форме пиктограммы Второй способ представления интерфейса иллюстрирует рис. 20. Здесь используется развернутая форма изображения интерфейса, в которой могут показываться его операции. Компонент, который реализует интерфейс, подключается к нему отношением реализации. Компонент, который получает доступ к услугам другого компонента через интерфейс, по-прежнему подключается к интерфейсу интерфейсом зависимости.  Рис.20 Развёрнутая форма представления интерфейса. Компоновка системы За последние полвека разработчики аппаратуры прошли путь от компьютеров размером с комнату до крошечных «ноутбуков», обеспечивших возросшие функциональные возможности. За те же полвека разработчики программного обеспечения прошли путь от больших систем на Ассемблере и Фортране до еще больших систем на С++ и.jаvа, но программный инструментарий развивается медленнее, чем аппаратный инструментарий. В чем главный секрет аппаратчиков? Этот секрет — компоненты. Разработчик аппаратуры создает систему из готовых аппаратных компонентов (микросхем), выполняющих определенные функции и предоставляющих набор услуг через ясные интерфейсы, Задача конструкторов упрощается за счет повторного использования результатов, полученных другими. Повторное использование — магистральный путь развития программного инструментария. Создание нового ПО из существующих, работоспособных программных компонентов приводит к более надежному и дешевому коду. При этом сроки разработки существенно сокращаются. Основная цель программных компонентов — допускать сборку системы из двоичных заменяемых частей. Они должны обеспечить начальное создание системы из компонентов, а затем и ее развитие — добавление новых компонентов и замену некоторых старых компонентов без перестройки системы в целом. Ключ к воплощению такой возможности – интерфейсы. После того как интерфейс определён, к выполняемой системе можно подключить любой компонент, который удовлетворяет ему или обеспечивает этот интерфейс. Для расширения системы производятся компоненты, которые обеспечивают дополнительные услуги через новые интерфейсы. Такой подход основывается на особенностях перечисленных в табл. 2 Таблица 2.
Вывод: компоненты — базисные строительные блоки, из которых может проектироваться и составляться система, Компонент может появляться на различных уровнях иерархии представления сложной системы. Система на одном уровне абстракции может стать простым компонентом на более высоком фоне абстракции. Разновидности компонентов Мир современных компонентов достаточно широк и разнообразен. В языке UML для обозначения новых разновидностей компонентов используют механизм стереотипов. Стандартные стереотипы, предусмотренные в UML для компонентов, представлены в таблице 3 Таблица 3 - Разновидности компонентов
В языке UML неопределенны пиктограммы для перечисленных стереотипов, применяемые на практике пиктограммы компонентов показаны ниже:  3.2. Использование компонентных диаграмм Компонентные диаграммы используют для моделирования статического представления реализации системы. Это представление поддерживает управление конфигурацией системы , составляемой из компонентов. Подразумевается, что для получения работающей системы существуют различные способы сборки компонентов. Компонентные диаграммы показывают отношения: периода компиляции (среди текстовых компонентов); периода сборки, линковки (среди объектных двоичных компонентов); периода выполнения (среди машинных компонентов); Рассмотрим типовые варианты применения компонентных диаграмм. Моделирование программного текста системы При разработке сложных систем программный текст (исходный код ) разбросан по многим файлам исходного кода. При использовании Java исходный код сохраняется в java – файлах , при использовании C++ - в заголовочных файлах (.h – файлах ) и телах (.cpp – файлах), при использовании Ada 95 – в спецификациях (.ads – файлах) и реализациях (.adb – файлах). Между файлами существуют многочисленные зависимости компиляции. Если к этому добавить , что по мере разработки рождаются новые версии файлов , то становится очевидной необходимость управления конфигурацией системы, визуализации компиляционных зависимостей.  .Рис. 21. Моделирование исходного кода  Рис.22. Моделирование исходного кода с использованием пиктограмм В качестве примера на рис 21 приведена компонентная диаграмма, где изображены файлы исходного кода, используемые для построения библиотеки Визуализация.dll. Имеются четыре заголовочных файла -Визуализация.h,ВизЯдро.h, Прил.h, ТабЦветов.h ,которые представляют исходный код для спецификации определённых классов. Файл реализации здесь один (Визуализация.cpp), он является реализацией одного из заголовков. Отметим , что для каждого файла явно указана его версия , причём для файла Визуализация.h показаны три версии и история их появления. На рис 22 повторяется та же диаграмма, но здесь для обозначения компонентов использованы специальные пиктограммы. Моделирование реализации системы Реализация системы может включать большое количество разнообразных компонентов: исполняемых элементов; динамических библиотек; файлов данных; справочных документов; файлов инициализации; файлов регистрации; сценариев; файлов упаковки. Моделирование этих компонентов, отношений между ними – важная часть управления конфигурацией системы. Например, на рис. 23 показана часть реализации системы, группируемая вокруг исполняемого элемента Видеоклип.exe. Здесь изображены четыре библиотеки (Регистратор.dll,СвернФормат.dll, Визуализация.dll, ТрассЛучей.dll), один документ (Видеоклип.htp), один простой файл (Видеоклип.ini), а также таблица базы данных (Фигуры.tbl). В диаграмме указаны отношения зависимости, существующие между компонентами. Для исполняемого компонента Видеоклип.exe указан номер (с помощью теговой величины), представлены его экспортируемые интерфейсы (IСценарии, IВизуализация, IМодели, IПрименение). Эти интерфейсы образуют API компонента (интерфейс прикладного программирования).  Рис.23 Моделирование реализации системы На рис 24 повторяется та же диаграмма, моделирующая реализацию, но здесь для обозначения компонентов использованы специальные пиктограммы.  Рис.24 Моделирование реализации с помощью пиктограмм. Таким образом, статические и динамические модели описывают логическую организацию системы, отражают логический мир программного приложения. Модели реализации обеспечивают представление системы в физическом мире, рассматривал вопросы упаковки логических элементов в компоненты и размещения компонентов в аппаратных узлах . Контрольные вопросы Поясните назначение языка UML. Охарактеризуйте строительные блоки языка UML. Какие разновидности предметов определены в UML? Перечислите известные вам разновидности структурных предметов UML. Перечислите известные вам разновидности группирующих предметов UML Перечислите известные вам разновидности поясняющих предметов UML Охарактеризуйте известные вам отношения UML. Что является основой моделей в UML? Перечислите известные вам виды диаграмм UML. Возможна ли трансляция UML-моделей в исходные коды на языках программирования? Для проектирования каких систем используется язык UML? Каково назначение диаграмм Use Case? Из каких элементов состоит диаграмма Use Case? Какие отношения разрешены между элементами Use Case? Чем отличаются отношения включения и расширения в диаграммах Use Case? На каком этапе жизненного цикла стоятся диаграммы Use Case? В чем основное назначение диаграмм реализации? Что такое компонент? Чем он отличается от класса? Какие разновидности компонентов вы знаете? В чем назначение компонентных диаграмм Use Case? Что такое интерфейс? Какие формы интерфейсов в компонентных диаграммах UML вы можете назвать? |