Моделирование на UML. Назначение UML. Методология UML. UML-диаграммы
Структурные диаграммы: Диаграмма классов Диаграмма компонентов Композитной составной структуры Диаграмма кооперации UML2.0 Диаграмма развёртывания Диаграмма объектов Диаграмма пакетов Диаграмма профилей UML2.2 Диаграммы поведения: Диаграмма деятельности Диаграмма состояний Диаграмма прецедентов Диаграммы взаимодействия: Диаграмма коммуникации UML2.0 Диаграмма кооперации UML1.
Поделитесь работой в социальных сетях
Если эта работа Вам не подошла внизу страницы есть список похожих работ. Так же Вы можете воспользоваться кнопкой поиск
Методология UML. UML-диаграммы.
Методология UML
UML (англ. Unified Modeling Language унифицированный язык моделирования) язык графического описания для объектного моделирования в области разработки программного обеспечения . UML является языком широкого профиля, это открытый стандарт , использующий графические обозначения для создания абстрактной модели системы , называемой UML-моделью . UML был создан для определения, визуализации, проектирования и документирования в основном программных систем. UML не является языком программирования, но в средствах выполнения UML-моделей как интерпретируемого кода возможна кодогенерация.
Использование UML не ограничивается моделированием программного обеспечения. Его также используют для моделирования бизнес-процессов , системного проектирования и отображения организационных структур .
Использование
UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (generalization), объединение (aggregation) и поведение), и больше сконцентрироваться на проектировании и архитектуре.
Диаграммы
В UML используются следующие виды диаграмм (для исключения неоднозначности приведены также обозначения на английском языке):
|
Structure Diagrams:
Behavior Diagrams:
|
Структурные диаграммы:
Диаграммы поведения:
|
Структуру диаграмм UML 2.3 можно представить на диаграмме классов UML:
Диаграмма классов
Диаграмма классов (Class diagram) статическая структурная диаграмма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами.
Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:
- концептуальная точка зрения диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;
- точка зрения спецификации диаграмма классов применяется при проектировании информационных систем;
- точка зрения реализации диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).
Диаграмма компонентов
Диаграмма компонентов (Component diagram) статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонент могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.
Шаблон проектирования Декоратор на диаграмме кооперации
Диаграмма композитной/составной структуры (Composite structure diagram) статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса.
Подвидом диаграмм композитной структуры являются диаграммы кооперации (Collaboration diagram, введены в UML 2.0), которые показывают роли и взаимодействие классов в рамках кооперации. Кооперации удобны при моделировании шаблонов проектирования .
Диаграммы композитной структуры могут использоваться совместно с диаграммами классов.
Диаграмма развёртывания
Диаграмма развёртывания (Deployment diagram) служит для моделирования работающих узлов (аппаратных средств, англ. node ) и артефактов , развёрнутых на них. В UML 2 на узлах разворачиваются артефакты (англ. artifact ), в то время как в UML 1 на узлах разворачивались компоненты. Между артефактом и логическим элементом (компонентом), который он реализует, устанавливается зависимость манифестации.
Диаграмма объектов
Диаграмма объектов (Object diagram) демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени. На диаграмме объектов отображаются экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей между объектами.
Диаграмма пакетов
Диаграмма пакетов (Package diagram) структурная диаграмма, основным содержанием которой являются пакеты и отношения между ними. Жёсткого разделения между разными структурными диаграммами не проводится, поэтому данное название предлагается исключительно для удобства и не имеет семантического значения (пакеты и диаграммы пакетов могут присутствовать на других структурных диаграммах). Диаграммы пакетов служат, в первую очередь, для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы.
Диаграмма деятельности
Диаграмма деятельности (Activity diagram) диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью (англ. activity ) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов вложенных видов деятельности и отдельных действий (англ. action ), соединённых между собой потоками, которые идут от выходов одного узла к входам другого.
Диаграммы деятельности используются при моделировании бизнес-процессов, технологических процессов, последовательных и параллельных вычислений.
Аналогом диаграмм деятельности являются схемы алгоритмов по ГОСТ 19.701-90.
Диаграмма автомата
Диаграмма автомата (State Machine diagram, диаграмма конечного автомата , диаграмма состояний ) диаграмма, на которой представлен конечный автомат с простыми состояниями , переходами и композитными состояниями.
Конечный автомат (англ. State machine ) спецификация последовательности состояний, через которые проходит объект или взаимодействие в ответ на события своей жизни, а также ответные действия объекта на эти события. Конечный автомат прикреплён к исходному элементу (классу , кооперации или методу) и служит для определения поведения его экземпляров.
Диаграмма вариантов использования (Use case diagram) диаграмма, на которой отражены отношения, существующие между акторами и вариантами использования .
Основная задача представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.
Диаграммы коммуникации и последовательности транзитивны , выражают взаимодействие, но показывают его различными способами и с достаточной степенью точности могут быть преобразованы одна в другую.
Диаграмма коммуникации (Communication diagram, в UML 1.x диаграмма кооперации , collaboration diagram ) диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов).
Диаграмма последовательности (Sequence diagram) диаграмма, на которой изображено упорядоченное во времени взаимодействие объектов. В частности, на ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются.
Диаграмма сотрудничества Этот тип диаграмм позволяет описать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений. На этом типе диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта и типы этих сообщений.
По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм.
Диаграмма обзора взаимодействия (Interaction overview diagram) разновидность диаграммы деятельности, включающая фрагменты диаграммы последовательности и конструкции потока управления.
Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.
Диаграмма синхронизации
Диаграмма синхронизации (Timing diagram) альтернативное представление диаграммы последовательности, явным образом показывающее изменения состояния на линии жизни с заданной шкалой времени. Может быть полезна в приложениях реального времени.
PAGE 7
Другие похожие работы, которые могут вас заинтересовать.вшм> |
|||
| 13400. | ПОСТРОЕНИЕ ПРИЧИННО-СЛЕДСТВЕННОЙ ДИАГРАММЫ ИСИКАВЫ | 140.47 KB | |
| Диаграмма Исикавы внешне напоминает рыбий скелет поэтому ее часто так и называют рис. Причины Следствие Рис. в качестве крупных выступают следующие пять костей рис. Рис. | |||
| 2628. | Методология IDEF3 | 113.73 KB | |
| Название связи Вид связи Смысл связи Связь предшествования Обозначает что вторая работа начинает выполняться после завершения первой работы. Связь отношения Обозначает что вторая работа может начаться и даже закончиться до того момента когда закончится выполнение первой работы. В данном случае вторая работа начинает выполняться после завершения первой работы. При этом выходом первой работы объект название которого надписано над стрелкой в данном случае документ. | |||
| 350. | Методология SADT | 9.44 KB | |
| Таким образом разработчики решили формализовать процесс создания системы разбив его на следующие фазы: Анализ определение того что система будет делать Проектирование определение подсистем и их взаимодействие Реализация разработка подсистем по отдельности объединение соединение подсистем в единое целое Тестирование проверка работы системы Установка введение системы в действие Эксплуатация использование системы. | |||
| 7925. | Методология комплексного ЭА ХД | 9.04 KB | |
| Зависимости объемов выпуска продукции от трудовых факторов выражается следующим образом: Nb = R Tд Тч Дч где Nb объем выпуска продукции R среднесписочное число рабочих Тд число дней отработанных одним рабочим за год Тч среднее число часов отработанных одним рабочим за день Дч средняя выработка продукции на 1 отработанный человекочас. Задача: На основе определить за счет каких факторов произошло изменение сумм взимаемых таможенных платежей Оренбургской таможни. Факторные анализ это процесс комплексного и... | |||
| 7620. | Философия и методология науки | 14.31 KB | |
| Структура научного познания Научное познание это процесс получения объективного истинного знания направленного на отражение закономерностей действительности. Уровни научного познания: эмпирический выявление объективных фактов как правило со стороны их очевидных связей; теоретический выявление фундаментальных закономерностей обнаружение за видимыми проявлениями скрытых внутренних связей и отношений. Формы научного познания научный факт эмпирический закон проблема гипотеза теория. Методы научного познания наблюдение... | |||
| 7651. | Методология энергетического аудита | 6.19 KB | |
| С другой стороны энергоаудит может быть комплексным и трудоемким процессом по определению и идентификации всех направлений расходования энергии и предусматривать установку нового постоянного измерительного оборудования тестирование и измерение в течение длительного периода времени и в результате детальной проверки выдаст детальные рекомендации. Составив несколько первых отчётов по энергоаудиту новичок будет сознавать актуальность и важность рекомендаций по экономии энергии таких например как использование светильников с низким... | |||
| 9173. | Механика и методология Ньютона | 17.2 KB | |
| Одним из первых, кто задумался о сущности движения, был Аристотель. Аристотель определяет движение как изменение положения тела в пространстве. Пространство, по Аристотелю, целиком заполнено материей, неким подобием эфира или прозрачной, как воздух субстанцией. Пустоты в природе нет («природа боится пустоты»). | |||
| 9174. | Методология научных исследований | 91.85 KB | |
| Методы эмпирического и теоретического познания. Методы научного познания включают так называемые всеобщие методы т. общечеловеческие приемы мышления общенаучные методы и методы конкретных наук. Методы могут быть классифицированы и по соотношению эмпирического знания т. | |||
| 4698. | МЕТОДОЛОГИЯ НАУЧНОГО ИССЛЕДОВАНИЯ | 35.45 KB | |
| Метод – это совокупность приемов и операций практического и теоретического освоения действительности. Основная функция метода – внутренняя организация и регулирование процесса познания или практического преобразования того или иного объекта. | |||
| 346. | Функциональное моделирование. Методология IDEF0 | 136.7 KB | |
| Методология IDEF0. История возникновения стандарта IDEF0 Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SDT Structured nlysis nd Design Teqnique. Исторически IDEF0 как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий которая носила обозначение ICM Integrted Computer ided Mnufcturing и была предложена департаментом ВоенноВоздушных Сил США. Собственно семейство стандартов IDEF унаследовало свое... | |||
В настоящее время фирма Rational Software является безусловным лидером в области объектно-ориентированного анализа и проектирования информационных систем с компонентной архитектурой. Разрабатываемая этой фирмой методология, основанная на использовании унифицированного языка моделирования (UML - Unified Modeling Language в настоящее время принят OMG в качестве стандарта), поддержана целым спектром инструментальных программных средств визуального моделирования, совместной разработки (поддерживаются основные языки программирования C++, Java, Visual Basic, SmallTalk и др., а также популярные среды разработки - MS Visual Studio, Delphi, PowerBuilder), автоматизированного тестирования и документирования, охватывающих жизненный цикл создания программных систем .
Помимо Rational Rose, продукта фирмы Rational Software, к числу популярных средств визуального моделирования, поддерживающих стандарты UML, можно отнести Paradigm Plus (программный продукт фирмы PLATINUM Technology), SELECT (SELECT Software), Oracle Designer (Oracle), Together Control Center (Borland), AllFusion Component Modeler (Computer Associates) и Microsoft Visual Modeler (Rational Software&Microsoft Corporation).
Rational Rose. Популярное средство визуального моделирования объектно-ориентированных информационных систем компании Rational Software Согр. Работа продукта основана на универсальном языке моделирования UML (Universal Modeling Language). Благодаря уникальному языку моделирования Rational Rose способен решать практически любые задачи в проектировании информационных систем: от анализа бизнес-процессов до кодогенерации на определенном языке программирования. Только Rose позволяет разрабатывать как высокоуровневые, так и низкоуровневые модели, осуществляя тем самым либо абстрактное проектирование, либо логическое .
Rational Rose поддерживает прямое и обратное проектирование на языках: ADA, Java, С, C++, Basic. Поддерживает технологии COM, DDL, XML. Позволяет генерировать схемы Oracle и SQL.
Rational Rose имеет открытый API, позволяющий создавать собственными силами модули для конкретных языков программирования.
Select Yourdon. Эта система разработана фирмой Select Software Tools Ltd. (England). Select Yourdon поддерживает фазы анализа требований и проектирования программной системы, что покрывает полностью начальный период разработки вплоть до кодирования модулей. При этом поддерживаются следующие виды структурных методов (диаграмм) :
- диаграммы отношения сущностей;
- диаграммы потоков данных и управления, базирующиеся на нотации Yourdon/Ward & Mellor и Hatley;
- диаграммы переходов состояний;
- мини-спецификации процессов;
- структурные диаграммы Константайна (Constantine);
- структурные диаграммы Джексона (Jackson).
Первые три вида диаграмм и мини-спецификации процессов могут использоваться для анализа и формулировки требований к ПО, последние два - для проектирования архитектуры ПО и его отдельных модулей. База данных проекта сосредоточена в так называемом словаре данных (Data Dictionary). Система поддерживает как однопользовательскую работу, так и работу в сети коллектива разработчиков.
Oracle Designer. Набор инструментальных средств Oracle Designer предлагает интегрированное решение для разработки прикладных систем корпоративного уровня для Web и клиент/серверных приложений. Oracle Designer участвует в каждой фазе жизненного цикла разработки программного обеспечения - от моделирования бизнес- процессов до внедрения. Применение единого репозитория делает возможным использование любых его компонент для быстрой разработки масштабируемых, кросс-платформных распределенных приложений .
Задачей Oracle Designer является сбор данных о потребностях пользователей и автоматизация построения гибких графических приложений. Oracle Designer используется не только для создания приложений, но и для ведения учета изменений, которые неизбежно происходят при эксплуатации системы.
Графические модели определений проекта, интегрированные с многопользовательским репозиторием существенно облегчают работу с Oracle Designer. Инструментальные средства построены на базе общепринятых методик, охватывающих весь жизненный цикл разработки. Это обеспечивает гибкость и открытость подхода к разработке программного обеспечения за счет использования только тех частей продукта, которые требуются в данной задаче. В рамках процесса разработки обеспечивается поддержка методов RAD, JAD, информационного проектирования, водопадного метода (waterfall), итеративного метода, а также индивидуального подхода, выбранного компанией.
Microsoft Visual Modeler. Microsoft Visual Modeler (MSVM) - инструмент визуального моделирования, разработанный Rational Software совместно c Microsoft Corporation, обеспечивает базируемое на UML моделирование для проектирования приложений на основе компонентов. Модели, созданные с использованием MSVM, могут автоматически выполнять генерацию объектного кода для проектов, реализуемых в средах разработки Visual Basic 6.0 и Visual C++ .
Microsoft Visual Modeler поддерживает архитектуру Windows-распределенных интернет-приложений (Windows DNA), которая позволяет разработчикам уровня предприятия строить масштабируемые, многоуровневые бизнес-приложения, которые могут быть установлены в любой сети.
Последняя версия Microsoft Visual Modeler предлагает беспрецедентный уровень интеграции между визуальным моделированием и средой разработки Visual Studio, включает обновленные возможности как для разработчиков Visual Basic, так и для поддержки разработки в среде Visual C++.
Windows DNA, Visual Studio и Microsoft Visual Modeler (MSVM) обеспечивают правильную комбинацию инфраструктуры и инструментов проектирования для создания нового поколения п-уровне- вых, создаваемых на основе компонентов приложений.
MSVM упрощает построение сложных, многоуровневых бизнес- приложений, основанных на Windows DNA, позволяя разработчикам наглядно в графическом виде представлять организацию их приложений.
Новые возможности Microsoft Visual Modeler включают интеграцию с Microsoft Visual SourceSafe системой контроля версий; интеграцию с Microsoft Visual Manager (VCM) и улучшенную поддержку Microsoft Repository для разработок на основе Visual Basic. Расширения Visual Modeler для поддержки групповой разработки включают возможность опубликования моделей в репозитории через VCM; в дальнейшем возможен просмотр моделей и их совместное использование членами группы разработчиков. Компоненты могут быть импортированы из репозитория через VCM посредством техники drag-and-drop. Точно так же интерфейсные компоненты СОМ могут быть импортированы из Windows Explorer.
Microsoft Visual Modeler - наиболее простой в освоении инструмент из семейства Rational Rose, мирового лидера среди инструментов визуального моделирования, использует общую кодовую основу и предлагает масштабируемый, интегрированный, полностью совместимый набор решений визуального моделирования для программистов, использующих Visual Basic и/или Visual C++. Visual Modeler поддерживает Унифицированный Язык Моделирования (UML), разработанный таким образом, что даже разработчики, не имеющие опыта в визуальном моделировании, легко его осваивают и успешно создают модели.
Семейство продуктов AllFusion. Component Modeler - базовый компонент комплекта AllFusion Modeling Suite компании Computer Associates. Комплект также включает в себя: Process Modeler (ранее - BPwin), который объединяет моделирование бизнес-процессов, потоков данных и рабочей деятельности в одном простом в использовании инструменте; ERwin Data Modeler (ранее - ERwin), применяемый для моделирования баз данных, и Data Model Validator (ранее - ERwin Examiner) для улучшения согласованности и качества моделей данных. Component Modeler и ERwin Data Modeler работают совместно, что дает возможность разработчикам и аналитикам баз данных приводить информацию в реляционных базах данных к виду, пригодному для использования объектно-ориентированными приложениями. Модели бизнес-процессов Process Modeler могут быть синхронизированы с моделями данных ERwin Data Modeler для обеспечения оптимальной поддержки бизнес-процессов организации .
Семейство AllFusion состоит из средств, предназначенных для управления процессами и проектами, моделирования и разработки, публикации знаний и визуализации. ПО семейства AllFusion улучшает способность автоматизировать процессы жизненного цикла критически важных приложений, что соответствует потребностям постоянно усложняющегося и изменчивого мира электронного бизнеса.
UML предназначен для моделирования. Сами авторы UML определяют свое детище следующим образом.
Язык UML ‒ это графический язык моделирования общего назначения, предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых при разработке программных систем.
Мы полностью согласны с этим определением, и не только одобряем выбор ключевых слов, но придаем большое значение порядку, в котором они перечислены.
1.2.1. Спецификация
В типичных случаях в процессе разработки приложений участвуют по меньше мере два действующих лица: заказчик (конкретный человек или группа лиц, или организация) и разработчик (это может быть программист-одиночка, временная команда проекта или целая организация, специализирующаяся на разработке программного обеспечения). Из-за того, что действующих лиц двое, очень многое зависит от степени их взаимопонимания.
Одним из ключевых этапов разработки приложения является определение того, каким требованиям должно удовлетворять разрабатываемое приложение. В результате этого этапа появляется формальный или неформальный документ (артефакт), который называют по-разному, имея в виду примерно одно и то же: постановка задачи, требования, техническое задание, внешние спецификации и др.
Аналогичные по назначению, но, может быть, отличные по форме и содержанию артефакты появляются и на других этапах разработки, особенно если в разработку включено много действующих лиц. Для них также используются различные названия: функциональные спецификации, архитектура приложения и др. Мы будем все такие артефакты называть спецификациями.
Спецификация ‒ это декларативное описание того, как нечто устроено или работает.
Необходимо принимать во внимание три толкования спецификаций.
- То, которое имеет в виду действующее лицо, являющееся источником спецификации (например, заказчик).
- То, которое имеет в виду действующее лицо, являющееся потребителем спецификации (например, разработчик).
- То, которое объективно обусловлено природой специфицируемого объекта.
Эти три трактовки спецификаций могут не совпадать, и, к сожалению, как показывает практика, сплошь и рядом не совпадают, причем значительно. Заказчик может не осознавать своих объективных потребностей, или неверно их интерпретировать, или заблуждаться относительно природы своих затруднений, пытаясь с помощью заказного офисного приложения лечить симптомы, а не причину болезни своего бизнеса. Разработчик может не разбираться в предметной области заказчика и интерпретировать формулировки спецификаций совершенно превратным образом. Если же в формулировке спецификаций участвует разработчик, то злоупотребление технической терминологией может совершенно дезориентировать заказчика.
Основное назначение UML ‒ предоставить, с одной стороны, достаточно формальное , с другой стороны, достаточно удобное , и, с третьей стороны, достаточно универсальное средство , позволяющее до некоторой степени снизить риск расхождений в толковании спецификаций.
1.2.2. Визуализация
Известная поговорка гласит, что лучше один раз увидеть, чем сто раз услышать. Мы добавим: тем паче тысячу раз прочитать пересказ. Особенности человеческого восприятия таковы, что текст с картинками воспринимается легче, чем голый текст. А картинки с текстом (это называется "комиксы") ‒ еще легче. Модели UML допускают представление в форме картинок, причем эти картинки наглядны, интуитивно понятны, практически однозначно интерпретируются и легко составляются. Фактически, развитие и детализация этого тезиса составляет большую часть содержания остальной части книги. Мы не будем забегать вперед, и просто приведем пример без всяких объяснений.
Разве что-нибудь непонятно?
Таким образом, второе по важности назначение UML состоит в том, чтобы служить адекватным средством коммуникации между людьми. Разумеется, наглядность визуализации моделей UML имеет значение, только если они должны составляться или восприниматься человеком ‒ это назначение UML не имеет отношения к компьютерам.
Графическое представление модели UML не тождественно самой модели. Это важное обстоятельство часто упускается из виду при первом знакомстве с UML.
1.2.3. Проектирование
В оригинале данное назначение UML определено с помощью слова construct, которое мы передаем осторожным термином "проектирование". Речь идет о том, что UML предназначен не только для описания абстрактных моделей приложений, но и для непосредственного манипулирования артефактами, входящими в состав этих приложений, в том числе такими, как программный код. Другими словами, одним из назначений UML является, например, создание таких моделей, для которых возможна автоматическая генерация программного кода (или фрагментов кода) соответствующих приложений. Более того, природа моделей UML такова, что возможен и обратный процесс: автоматическое построение модели по коду готового приложения.
По-английски автоматическое построение модели по коду готового приложения называется reverse engineering и обычно переводится на русский как "обратное проектирование". Нам этот перевод категорически не нравится: какое же это проектирование и почему оно обратное? Есть неплохой альтернативный вариант: "инженерный анализ программ", но он не получил пока распространения.
Сказанное в предыдущем абзаце требует оговорок "до некоторой степени", "в известной мере" буквально после каждого утверждения. Самое досадное, что в данный момент точно указать "степень" и "меру" не представляется возможным. Причина не в том, что никто не удосужился этим заняться, а в том, что это очень трудная задача, но не безнадежная. Инструменты, поддерживающие UML, все время совершенствуются, так что в перспективе третье предназначение UML может выйти и на первое место.
Некоторым уставшим от бесконечной отладки разработчикам может показаться, что стоит изучить UML, и все проблемы программирования будут решены. К сожалению, это не так.
1.2.4. Документирование
Модели UML являются артефактами, которые можно хранить и использовать как в форме электронных документов, так и в виде твердой копии. В последних версиях UML с целью достижения более полного соответствия этому назначению сделано довольно много. В частности, специфицировано представление моделей UML в форме документов в формате XMI, что обеспечивает практическую интероперабельность при работе с моделями. Другими словами, модели UML не являются вещью в себе, которой можно только любоваться ‒ это документы, которые можно использовать самыми разными способами, начиная с печати картинок и заканчивая автоматической генерацией человекочитаемых текстовых описаний.
XMI (XML Metadata Interchange) ‒ внешний формат данных, основанный на языке XML (схема и набор правил использования тэгов), предназначенное для сериализации моделей и обмена ими.
Поясним последнюю фразу предыдущего абзаца. Стандарт требует, чтобы во внутреннем представлении модели для каждого элемента моделирования было отведено место, где можно хранить неформальное текстовое описание этого элемента. Большинство инструментов это требование выполняют: буквально для каждой линии или фигуры на диаграмме можно ввести текст, который поясняет смысл и назначение именно этой линии или фигуры. Более того, многие инструменты умеют из этих текстовых описаний собирать цельные, вполне осмысленные и хорошо отформатированные текстовые документы, которые можно использовать именно как привычные текстовые описания моделируемой системы. К сожалению, это замечательная возможность на практике используется меньше, чем она того заслуживает. Дело в том, что так же, как программисты не любят и ленятся писать осмысленные комментарии к программному коду, так и архитекторы не любят и ленятся писать текстовые пояснения к своим диаграммам.
1.2.5. Чем НЕ является UML
Не следует думать, что UML ‒ это панацея от всех детских ∇ болезней программирования. Для ясного понимания назначения и области применения UML полезно сопоставить UML с другими родственными явлениями.
∇ Информационным технологиям от силы полвека ‒ это еще младенческий возраст для новой области человеческой деятельности.
Во-первых, UML не является языком программирования (хотя генерация кода не возбраняется, см. параграф 1.2.3). Дело не в том, что UML язык графический, а подавляющее большинство практических языков программирования являются текстовыми языками. Гораздо важнее то, что для моделей UML не определена операционная семантика , то есть, не определен способ выполнения моделей на компьютере. Это сделано вполне сознательно, в противном случае UML оказался бы зависимым от некоторой модели вычислимости, уровень абстрактности его концепций пришлось бы существенно снизить, и он не отвечал бы своему основному назначению: служить средством спецификации приложений и других систем на любом уровне абстракции и в различных предметных областях.
Во-вторых, UML не является спецификацией инструмента (хотя инструменты подразумеваются и имеются, например, Magic Draw , Rational Rose Enterprise , Visual Paradigm , Enterprise Architect , и др.). Сам язык никоим образом не навязывает то, как его нужно поддерживать инструментальными средствами. Решение всех вопросов, связанных с реализацией UML на компьютере полностью отдано на откуп разработчикам инструментов.
В-третьих, UML не является моделью процесса разработки приложений (хотя модель процесса разработки необходима и имеется множество различных моделей, предложенных разными авторами). Конечно, у авторов UML есть собственная модель процесса ‒ Rational Unified Process (RUP), которую они не могли не иметь в голове, разрабатывая язык, но, тем не менее, ими сделано все для того, чтобы устранить прямое влияние RUP на UML и сделать UML пригодным для использования в любой модели процесса или даже без оной.
У авторов этой книги тоже есть собственное мнение о взаимосвязи UML с моделью процесса разработки программного обеспечения (см. раздел 5.2), которое не может не сказываться на описании прагматики языка, но везде, где такое влияние замечено, сделаны соответствующие оговорки.
1.2.6. Способы использования UML
Из сказанного выше видно, что UML предназначен для решения различных задач, соответственно он может быть использован и практически используется по-разному. Далее мы перечисляем различные способы использования UML.
Рисование картинок . Графические средства UML можно и нужно использовать безотносительно ко всему остальному. Даже рисование диаграмм карандашом на бумаге позволяет упорядочить мысли и зафиксировать для себя существенную информацию о моделируемом приложении или иной системе.
Обмен информацией . Сообщество людей, применяющих и понимающих UML, стремительно растет. Если вы будете использовать UML, то вас будут понимать другие, и вы будете понимать других "с полувзгляда".
Спецификация систем . Это важнейший способ использования UML. И хотя не во всех случаях UML оказывается абсолютно адекватным средством спецификации, мы надеемся, что по мере развития языка все меньше будет оставаться таких исключений, где UML неприменим.
Повторное использование архитектурных решений . Повторное использование ранее разработанных решений ‒ ключ к повышению эффективности. Наше мнение по этому поводу изложено в разделе 5.2 . К сожалению, модели UML пока что повторно используются в весьма ограниченных масштабах.
Вариант использования drawing ("Рисование диаграмм") подразумевает изображение диаграмм UML с целью обдумывания, обмена идеями между людьми, документирования и тому подобного. Значимым для пользователя User результатом в этом случае является само изображение диаграмм. Вообще говоря, в этом варианте использования языка поддерживающий инструмент не очень нужен. Иногда рисование диаграмм от руки фломастером с последующим фотографированием цифровым аппаратом может оказаться практичнее.
Вариант использования modeling ("Моделирование систем") подразумевает создание и изменение модели системы в терминах тех элементов моделирования, которые предусматриваются метамоделью UML. Значимым результатом в этом случае является машинно-читаемый артефакт с описанием модели. Мы будем для краткости называть такой артефакт просто моделью, деятельность по составлению модели называть моделированием, а субъекта моделирования называть архитектором Architect .
Вариант использования development ("Разработка приложений") подразумевает детальное моделирование, реализацию и тестирование приложения в терминах UML. Значимым для пользователя Developer результатом в этом случае является работающее приложение, которое может быть скомпилировано в язык, поддерживаемый конкретной системой программирования Programming System или сразу интерпретировано средой выполнения инструмента. Этот вариант использования наиболее сложен в реализации.
Современные инструменты поддерживают указанные варианты использования далеко не в равной степени. Все инструменты умеют (плохо или хорошо) визуализировать все типы диаграмм UML, некоторые инструменты позволяют построить модель, допускающую какое-то дальнейшее использование, но только немногие инструменты могут генерировать исполняемый код и то, отнюдь, не для всех диаграмм. Имеется множество практических и организационных причин, по которым указанные выше варианты использования неравноправны и в разной степени поддержаны в современных инструментах. Некоторые из этих причин мы рассматриваем в последующих главах.
Создавать для программы дополнительное визуальное и документальное сопровождение – процесс трудоемкий и утомительный: отнимает много времени и кажется совершенно излишним, если архитектура программного обеспечения проста или является эталонной. Однако на практике программисты далеко не всегда сталкиваются с такими задачами.
Почему не «взлетел» UML
В большинстве случаев при разработке программного обеспечения, если система требует правок, то программисты просто берут код и исправляют ошибки так, как им удобно, а затем демонстрируют результат заказчику.«Сегодня программирование - это не инженерная наука, а прикладная математика. При этом программисты сразу учатся писать код», - уточняет заведующий кафедрой Технологии программирования Университета ИТМО Анатолий Шалыто.
Чаще всего архитектура решения объясняется на словах или с применением простейших блок-диаграмм. Универсальный язык моделирования (UML), основанный на базе нескольких предыдущих стандартов, таких как метод Гради Буча (Booch), метод Джима Румбаха (OMT) и метод Айвара Джекобсона (OOSE), должен был помочь в этом вопросе. И на него возлагали определенные надежды.
Люди пробовали работать с UML, надеясь, что тот станет своеобразной «серебряной пулей», однако он не приобрел широкой популярности. Исследователи выделяют три главных препятствия, которые помешали массовому распространению диаграмм состояний в качестве общепринятого средства описания алгоритмов и сложных поведений программ.
Во-первых, для описания поведения, кроме диаграмм состояний, предлагалось использовать и другие типы диаграмм, однако правила, определяющие их взаимодействие, не были регламентированы.
«Многие считают, что этот язык слишком объемный, - говорит исследователь и предприниматель Хорди Кабот (Jordi Cabot). - Это связано с большим количеством диаграмм, доступных в UML».
Во-вторых, не было предложено подходов для совместного использования диаграмм, описывающих структуру и поведение программ. В-третьих, диаграммы для описания поведения в основном использовались разработчиками для общения друг с другом, в то время как назначение UML - составление спецификации с последующим её воплощением в программном коде.
Подобная судьба ожидала и множество других решений, которые, однако, не являются полноценными альтернативами UML. Речь идет о системе условных обозначений для моделирования бизнес-процессов (BPMN), моделях сущность-связь (ERM), диаграммах потоков данных (DFD), диаграммах состояний и др. Как отмечает Крис Фурман (Cris Fuhrman), все это не более, чем инструменты общения.
Переход к автоматам
Однако спецификации проектов нужны, поскольку они фиксируют результат процесса проектирования, освобождая ум разработчика для решения других задач, а также используются в качестве входных данных на этапе реализации.
Этапы разработки программной системы со сложным поведением
Автоматное программирование является подходом, способным облегчить процесс формирования спецификации. Во время работы создаются графы, в которых под влиянием внешних или любых других входных воздействий осуществляются переходы между состояниями и формируются выходные «импульсы». Для этого сперва формируется текстовая версия технического задания, в котором заказчик прописывает подробную работу желаемого решения.
После этого объявляются условные обозначения входных и выходных воздействий, источников и приемников информации, а затем рисуется схема. Графы переходов позволяют заказчику лучше понять то, что будет делать программист.
Имея схему связей и диаграмму переходов, с помощью формального преобразования можно построить код, реализующий автомат на языке программирования. После этого спецификации становятся частью проектной документации системы. Проектная документация составляется на естественном языке и обычно содержит постановку задачи, описание структуры и поведения системы, примеры ее использования.
Автоматное описание в ООП
Принципы автоматного подхода находят применение и в объектно-ориентированном программировании. Это возможно благодаря концепции «автоматы и объекты управления как классы». Такая модель принята, например, в инструментальном средстве автоматного программирования UniMod. Архитектура системы со сложным поведением, построенная согласно этому принципу представлена на рисунке ниже.
Сопоставление отдельного класса каждому объекту управления приводит к тому, что усилия разработчиков по выделению этих объектов на стадии моделирования не пропадают на этапе реализации. При этом каждый запрос или команда имеет доступ только к строго определенной части вычислительного состояния.
В целом же процесс проектирования системы со сложным поведением можно описать следующим образом:
- Проведение объектной декомпозиции, когда система разбивается на множество самостоятельных взаимодействующих сущностей.
- Сопоставление сущностей с классами, определение интерфейсов классов и отношений.
- Выделение тех сущностей, которые обладают сложным поведением, - именно для их описания будет применяться автоматный подход.
- Задание набора управляющих состояний для каждой сущности. Запросы и команды сопоставляются с входными и выходными переменными управляющего автомата, а компоненты интерфейса - с его событиями. На их основе строится сам управляющий автомат.
- Реализация неавтоматизированных классов на выбранном объектно-ориентированном языке. Генерация кода может выполняться как автоматически, так и вручную.
Большинство существующих методов объектно-ориентированного анализа и проектирования (ООАП) включают как язык моделирования, так и описание процесса моделирования. Язык моделирования – это нотация (в основном графическая), которая используется методом для описания проектов.
Нотация представляет собой совокупность графических объектов, которые используются в моделях; она является синтаксисом языка моделирования. Например, нотация диаграммы классов определяет, каким образом представляются такие элементы и понятия, как класс, ассоциация и множественность.
Процесс – это описание шагов, которые необходимо выполнить при разработке проекта.
Унифицированный язык моделирования UML (Unified Modeling Language) – это преемник того поколения методов ООАП, которые появились в конце 80-х и начале 90-х гг.
Язык UML представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем. Язык UML одновременно является простым и мощным средством моделирования, который может быть эффективно использован для построения концептуальных, логических и графических моделей сложных систем самого различного целевого назначения.
Конструктивное использование языка UML основывается на понимании общих принципов моделирования сложных систем и особенностей процесса объектно-ориентированного проектирования (ООП) в частности. Выбор выразительных средств для построения моделей сложных систем предопределяет те задачи, которые могут быть решены с использованием данных моделей. При этом одним из основных принципов построения моделей сложных систем является принцип абстрагирования, который предписывает включать в модель только те аспекты проектируемой системы, которые имеют непосредственное отношение к выполнению системой своих функций или своего целевого предназначения. При этом все второстепенные детали опускаются, чтобы чрезмерно не усложнять процесс анализа и исследования полученной модели.
Другим принципом построения моделей сложных систем является принцип многомодельности . Этот принцип представляет собой утверждение о том, что никакая единственная модель не может с достаточной степенью адекватности описывать различные аспекты сложной системы. Применительно к методологии ООП это означает, что достаточно полная модель сложной системы допускает некоторое число взаимосвязанных представлений (views), каждое из которых адекватно отражает некоторый аспект поведения или структуры системы. При этом наиболее общими представлениями сложной системы принято считать статическое и динамическое представления, которые в свою очередь могут подразделяться на другие более частные представления.) феномен сложной системы как раз и состоит в том, что никакое ее единственное представление не является достаточным для адекватного выражения всех особенностей моделируемой системы.
Еще одним принципом прикладного системного анализа является принцип иерархического построения моделей сложных систем. Этот принцип предписывает рассматривать процесс построения модели на разных уровнях абстрагирования или детализации в рамках фиксированных представлений. При этом исходная или первоначальная модель сложной системы имеет наиболее общее представление (метапредставление). Такая модель строится на начальном этапе проектирования и может не содержать многих деталей и аспектов моделируемой системы.
Создание UML фактически началось в конце 1994 г., когда Гради Б уч и Джеймс Рамбо начали работу по объединению методов Booch и ОМТ (Object Modeling Technique) под эгидой компании Rational Software. К концу 1995 г. они создали первую спецификацию объединенного метода, названного ими Unified Method, версия 0.8. Тогда же, в 1995 г., к ним присоединился создатель метода OOSE (Object-Oriented Software Engineering) Ивар Якобсон . Таким образом, UML является прямым объединением и унификацией методов Буча, Рамбо и Якобсона , однако дополняет их новыми возможностями.
Главными в разработке UML были следующие цели:
– предоставить пользователям готовый к использованию выразительный язык визуального моделирования, позволяющий разрабатывать осмысленные модели и обмениваться ими;
– предусмотреть механизмы расширяемости и специализации для расширения базовых концепций;
– обеспечить независимость от конкретных языков программирования и процессов разработки;
– обеспечить формальную основу для понимания этого языка моделирования (язык должен быть одновременно точным и доступным для понимания, без лишнего формализма);
– стимулировать рост рынка объектно-ориентированных инструментальных средств;
– интегрировать лучший практический опыт.
Язык UML находится в процессе стандартизации, проводимом OMG (Object Management Group) – организацией по стандартизации в области объектно-ориентированных методов и технологий, в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии ПО.
Язык UML принят на вооружение практически всеми крупнейшими компаниями – производителями ПО (Microsoft, IBM, Hewlett-Packard, Oracle, Sybase и др.). Кроме того, практически все мировые производители CASE-средств, помимо Rational Software (Rational Rose), поддерживают UML в своих продуктах (Paradigm Plus 3.6, System Architec, Microsoft Visual Modeler for Visual Basic, Delphi, PowerBuilder и др.). Полное описание UML можно найти на сайтах http://www.omg.urg, http://www.rational.com и http://uml.shl.com. Описание UML на русском языке содержится в книге М. Фаулера и К. Скотта, в дальнейшем изложении терминология языка соответствует данному переводу.
Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, организационно-экономических, технических и др.
UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов.
Диаграмма в UML – это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями). Диаграммы рисуют для визуализации системы с разных точек зрения.
Диаграмма – в некотором смысле одна из проекций системы. Как правило, за исключением наиболее тривиальных случаев, диаграммы дают свернутое представление элементов, из которых составлена система. Один и тот же элемент может присутствовать во всех диаграммах, или только в нескольких (самый распространенный вариант), или не присутствовать ни в одной (очень редко).
Теоретически диаграммы могут содержать любые комбинации сущностей и отношений. На практике, однако, применяется сравнительно небольшое количество типовых комбинаций, соответствующих пяти наиболее употребительным видам, которые составляют архитектуру программной системы.
В UML выделяют следующие типы диаграмм:
– диаграммы вариантов использования (usecase diagrams) – для моделирования бизнес-процессов организации (требований к системе);
– диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними. На таких диаграммах показывают классы, интерфейсы, объекты и кооперации, а также их отношения. При моделировании объектно-ориентированных систем этот тип диаграмм используют чаще всего. Диаграммы классов соответствуют статическому виду системы с точки зрения проектирования;
– диаграммы поведения системы (behavior diagrams);
– диаграммы взаимодействия (interaction diagrams) – для моделирования процесса обмена сообщениями между объектами. Существуют два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams). На диаграммах взаимодействия представлены связи между объектами; показаны, в частности, сообщения, которыми объекты могут обмениваться. Диаграммы взаимодействия относятся к динамическому виду системы. При этом диаграммы последовательности отражают временную упорядоченность сообщений, а диаграммы кооперации – структурную организацию обменивающихся сообщениями объектов. Эти диаграммы являются изоморфными, то есть могут быть преобразованы друг в друга;
– диаграммы состояний (statechart diagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое. На них представлен автомат, включающий в себя состояния, переходы, события и виды действий. Диаграммы состояний относятся к динамическому виду системы; особенно они важны при моделировании поведения интерфейса, класса или кооперации. Они акцентируют внимание на поведении объекта, зависящем от последовательности событий, что очень полезно для моделирования реактивных систем;
– диаграммы деятельностей (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования или моделирования деятельностей. Это частный случай диаграммы состояний; на ней представлены переходы потока управления от одной деятельности к другой внутри системы. Диаграммы деятельности относятся к динамическому виду системы; они наиболее важны при моделировании ее функционирования и отражают поток управления между объектами;
– диаграммы реализации (implementation diagrams): диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы; диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы. На диаграмме компонентов представлена организация совокупности компонентов и существующие между ними зависимости. Диаграммы компонентов относятся к статическому виду системы с точки зрения реализации. Они могут быть соотнесены с диаграммами классов, так как компонент обычно отображается на один или несколько классов, интерфейсов или коопераций.Краткая история UML
Объектно-ориентированные языки моделирования появились в период с середины 70-х до конца 80-х годов, когда исследователи, поставленные перед необходимостью учитывать новые возможности объектно-ориентированных языков программирования и требования, предъявляемые все более сложными приложениями, вынуждены были начать разработку различных альтернативных подходов к анализу и проектированию.
С 1989 по 1994 год число различных объектно-ориентированных методов возросло с десяти более чем до пятидесяти. Тем не менее, многие пользователи испытывали затруднения при выборе языка моделирования, который бы полностью соответствовал их потребностям, что послужило причиной так называемой «войны методов». В результате этих войн появилось новое поколение методов, среди которых особое значение приобрели языки Booch , созданный Грейди Бучем (Grady Booch), OOSE (Object-Oriented Software Engineering), разработанный Айваром Джекобсоном (Ivar Jacobson) и ОМТ (Object Modeling Technique), автором которого является Джеймс Рамбо (James Rumbaugh). Кроме того, следует упомянуть языки Fusion, Шлаера-Меллора (Shlaer-Mellor) и Коада-Йордона (Coad-Yourdon). Каждый из этих методов можно считать вполне целостным и законченным, хотя любой из них имеет не только сильные, но и слабые стороны.
Выразительные возможности метода Буча особенно важны на этапах проектирования и конструирования модели. OOSE великолепно приспособлен для анализа и формулирования требований, а также для высокоуровневого проектирования. ОМТ-2 оказался особенно полезным для анализа и разработки информационных систем, ориентированных на обработку больших объемов данных.
Критическая масса новых идей начала формироваться к середине 90-х годов, когда Грейди Буч (компания Rational Software Corporation), Айвар Джекобсон (Objectory) и Джеймс Рамбо (General Electric) предприняли попытку объединить свои методы, уже получившие мировое признание как наиболее перспективные в данной области. Являясь основными авторами языков Booch, OOSE и ОМТ , партнеры попытались создать новый, унифицированный язык моделирования и руководствовались при этом тремя соображениями.
Во-первых, все три метода, независимо от желания разработчиков, уже развивались во встречном направлении. Разумно было продолжать эту эволюцию вместе, а не по отдельности, что помогло бы в будущем устранить нежелательные различия и, как следствие, неудобства для пользователей.
Во-вторых, унифицировав методы, проще было привнести стабильность на рынок инструментов объектно-ориентированного моделирования, что дало бы возможность положить в основу всех проектов единый зрелый язык, а создателям инструментальных средств позволило бы сосредоточиться на более продуктивной деятельности.
Наконец, следовало полагать, что подобное сотрудничество приведет к усовершенствованию всех трех методов и обеспечит решение задач, для которых любой из них, взятый в отдельности, был не слишком пригоден.
– моделировать системы целиком, от концепции до исполняемого артефакта, с помощью объектно-ориентированных методов;
– решить проблему масштабируемости, которая присуща сложным системам, предназначенным для выполнения ответственных задач;
– создать такой язык моделирования, который может использоваться не только людьми, но и компьютерами.
Изобретение языка для объектно-ориентированного анализа и проектирования не слишком отличается от разработки языка программирования. Во-первых , требовалось ограничить задачу. Следует ли включать в язык возможность спецификации требований? Должен ли язык позволять визуальное программирование? Во-вторых , было необходимо найти точку равновесия между выразительной мощью и простотой. Слишком простой язык ограничил бы круг решаемых с его помощью задач, а слишком сложный мог ошеломить неискушенного разработчика. Кроме того, при объединении существующих методов приходилось учитывать наличие уже разработанных с их помощью продуктов. Внесение слишком большого числа изменений могло бы оттолкнуть уже имевшихся пользователей, а сопротивляясь развитию языка, авторы потеряли бы возможность привлекать новых пользователей и делать язык более простым и удобным для применения. Создавая UML, разработчики старались найти оптимальное решение этих проблем.
Официально создание UML началось в октябре 1994 года , когда Рамбо перешел в компанию Rational Software, где работал Буч. Первоначальной целью было объединение методов Буча и ОМТ. Первая пробная версия 0.8 Унифицированного Метода (Unified Method), как его тогда называли, появилась в октябре 1995 года . Приблизительно в это же время в компанию Rational перешел Джекобсон, и проект UML был расширен с целью включить в него язык OOSE. В результате совместных усилий в июне 1996 года вышла версия 0.9 языка UML . На протяжении всего года создатели занимались сбором отзывов от основных компаний, работающих в области конструирования программного обеспечения. За это время стало ясно, что большинство таких компаний сочло UML языком, имеющим стратегическое значение для их бизнеса. В результате был основан консорциум UML, в который вошли организации, изъявившие желание предоставить ресурсы для работы, направленной на создание полного определения UML.
Версия 1.0 языка появилась в результате совместных усилий компаний Digital Equipment Corporation, Hewlett Packard, I-Logix, Intellicprp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments и Unisys. UML 1.0 оказался хорошо определенным, выразительным, мощным языком, применимым для решения большого количества разнообразных задач. В январе 1997 года он был представлен Группе по управлению объектами (Object Management Group, OMG) на конкурс по созданию стандартного языка моделирования.
Между январем и июнем 1997 года консорциум UML расширился, в него вошли практически все компании, откликнувшиеся на призыв OMG, а именно: Andersen Consulting, Ericsson, ObjecTime Limited, Platinum Technology, Ptech, Reich Technologies, Softeam, Sterling Software и Taskon. Чтобы формализовать спецификации UML и координировать работу с другими группами, занимающимися стандартизацией, под руководством Криса Кобрина (Cris Kobryn) из компании MCI Systemhouse и Эда Эйкхолта (Ed Eykholt) из Rational была организована семантическая группа. Пересмотренная версия UML (1.1) была снова представлена на рассмотрение OMG в июле 1997 года. В сентябре версия была утверждена на заседаниях Группы по анализу и проектированию и Комитета по архитектуре OMG, a 14 ноября 1997 года принята в качестве стандарта на общем собрании всех членов OMG.
Дальнейшая работа по развитию UML проводилась Группой по усовершенствованию (Revision Task Force, RTF) OMG под руководством Криса Кобрина. В июне 1998 года вышла версия UML 1.2, а осенью 1998 – UML 1.3.
Язык моделирования UML
UML (унифицированный язык моделирования) – язык графического описания для объектного моделирования в области разработки программного обеспечения. Он использует графические обозначения для создания модели системы. Данный язык был создан для определения, визуализации, проектирования и документирования программных систем, а также его используют для моделирования бизнес-процессов, системного проектирования.
Описание унифицированного языка моделирования UML
Краткая история UML (Создатели: Грейди Буч , Айвар Джекобсон и Джеймс Рамбо )
Концептуальная модель UML (концептуальную модель включает: основные строительные блоки языка; правила их сочетания; некоторые общие для всего языка механизмы)
Виды диаграмм для моделирования:
Диаграммы вариантов использования (они описывают функциональное назначение системы или то, что система должна делать)
Диаграммы классов (используются для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования; такие диаграммы могут отражать различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывать их внутреннюю структуру и типы отношений)
Диаграммы взаимодействия (описывают взаимодействие между объектами в системе и подразделяются на два основных типа диаграмм: диаграммы последовательности и кооперативные диаграммы)
Диаграммы состояний (используется для описания всех возможных состояний одного экземпляра определенного класса и возможные последовательности его переходов из одного состояния в другое, то есть моделирует все изменения состояний объекта как его реакцию на внешние воздействия)
Диаграммы деятельности (применяется для моделирования процесса выполнения операций)
Диаграммы реализации (служат для представления компонентов системы и относятся к ее физической модели)
Диаграммы компонентов (описывает особенности физического представления системы и позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный и исполняемый код)
Диаграммы размещения (отражают физические взаимосвязи между программными и аппаратными компонентами системы, а также используются для изображения маршрутов перемещения объектов в распределенной системе)