Способы применения 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 используются на всех этапах жизненного цикла ПС, начиная с бизнес-анализа и заканчивая сопровождением системы. Разные организации могут применять UML по своему усмотрению в зависимости от своих проблемных областей и используемых технологий.
Краткая история UML
К середине 90-х годов различными авторами было предложено несколько десятков методов ОО моделирования, каждый из которых использовал свою графическую нотацию. При этом любой их этих методов имел свои сильные стороны, но не позволял построить достаточно полную модель ПС, показать ее «со всех сторон», то есть, все необходимые проекции (См. статью 1). К тому же отсутствие стандарта ОО моделирования затрудняло для разработчиков выбор наиболее подходящего метода, что препятствовало широкому распространению ОО подхода к разработке ПС.
По запросу Object Management Group (OMG) – организации, ответственной за принятие стандартов в области объектных технологий и баз данных назревшая проблема унификации и стандартизации была решена авторами трех наиболее популярных ОО методов – Г.Бучем, Д.Рамбо и А.Джекобсоном, которые объединенными усилиями создали версию UML 1.1, утвержденную OMG в 1997 году в качестве стандарта.
UML – это язык
Любой язык состоит из словаря и правил комбинирования слов для получения осмысленных конструкций. Так, в частности, устроены языки программирования, таковым является и UML. Отличительной его особенностью является то, что словарь языка образуют графические элементы. Каждому графическому символу соответствует конкретная семантика, поэтому модель, созданная одним разработчиком, может однозначно быть понята другим, а также программным средством, интерпретирующим UML. Отсюда, в частности, следует, что модель ПС, представленная на UML, может автоматически быть переведена на ОО язык программирования (такой, как Java, C++, VisualBasic), то есть, при наличии хорошего инструментального средства визуального моделирования, поддерживающего UML, построив модель, мы получим и заготовку программного кода, соответствующего этой модели.
Следует подчеркнуть, что UML – это именно язык, а не метод. Он объясняет, из каких элементов создавать модели и как их читать, но ничего не говорит о том, какие модели и в каких случаях следует разрабатывать. Чтобы создать метод на базе UML, надо дополнить его описанием процесса разработки ПС. Примером такого процесса является Rational Unified Process, который будет рассматриваться в последующих статьях.
Словарь UML
Модель представляется в виде сущностей и отношений между ними, которые показываются на диаграммах.
Сущности – это абстракции, являющиеся основными элементами моделей. Имеется четыре типа сущностей – структурные (класс, интерфейс, компонент, вариант использования, кооперация, узел), поведенческие (взаимодействие, состояние), группирующие (пакеты) и аннотационные (комментарии). Каждый вид сущностей имеет свое графическое представление. Сущности будут подробно рассмотрены при изучении диаграмм.
Отношения показывают различные связи между сущностями. В UML определены следующие типы отношений:
- Зависимость показывает такую связь между двумя сущностями, когда изменение одной из них – независимой – может повлиять на семантику другой – зависимой. Зависимость изображается пунктирной стрелкой, направленной от зависимой сущности к независимой.
- Ассоциация – это структурное отношение, показывающее, что объекты одной сущности связаны с объектами другой. Графически ассоциация показывается в виде линии, соединяющей связываемые сущности. Ассоциации служат для осуществления навигации между объектами. Например, ассоциация между классами «Заказ» и «Товар» может быть использована для нахождения всех товаров, указанных в конкретном заказе – с одной стороны, или для нахождения всех заказов в которых есть данный товар, – с другой. Понятно, что в соответствующих программах должен быть реализован механизм, обеспечивающий такую навигацию. Если требуется навигация только в одном направлении, оно показывается стрелкой на конце ассоциации. Частным случаем ассоциации является агрегирование – отношение вида «целое» – «часть». Графически оно выделяется с помощью ромбика на конце около сущности-целого.
- Обобщение – это отношение между сущностью-родителем и сущностью-потомком. По существу, это отношение отражает свойство наследования для классов и объектов. Обобщение показывается в виде линии, заканчивающейся треугольничком направленным к родительской сущности. Потомок наследует структуру (атрибуты) и поведение (методы) родителя, но в то же время он может иметь новые элементы структуры и новые методы. UML допускает множественное наследование, когда сущность связана более чем с одной родительской сущностью.
- Реализация – отношение между сущностью, определяющей спецификацию поведения (интерфейс) с сущностью, определяющей реализацию этого поведения (класс, компонент). Это отношение обычно используется при моделировании компонент и будет подробнее описано в последующих статьях.
Диаграммы. В UML предусмотрены следующие диаграммы:
- Диаграммы, описывающие поведение системы:
- Диаграммы состояний (State diagrams),
- Диаграммы деятельностей (Activity diagrams),
- Диаграммы объектов (Object diagrams),
- Диаграммы последовательностей (Sequence diagrams),
- Диаграммы взаимодействия (Collaboration diagrams);
- Диаграммы, описывающие физическую реализацию системы:
- Диаграммы компонент (Component diagrams);
- Диаграммы развертывания (Deployment diagrams).
Представление управления моделью. Пакеты.
Мы уже говорили о том, что для того чтобы модель была хорошо понимаемой человеком необходимо организовать ее иерархически, оставляя на каждом уровне иерархии небольшое число сущностей. UML включает средство организации иерархического представления модели – пакеты. Любая модель состоит из набора пакетов, которые могут содержать классы, варианты использования и прочие сущности и диаграммы. Пакет может включать другие пакеты, что позволяет создавать иерархии. В UML не предусмотрено отдельных диаграмм пакетов, но они могут присутствовать на других диаграммах. Пакет изображается в виде прямоугольника с закладкой.
Что обеспечивает UML.
- иерархическое описание сложной системы путем выделения пакетов;
- формализацию функциональных требований к системе с помощью аппарата вариантов использования;
- детализацию требований к системе путем построения диаграмм деятельностей и сценариев;
- выделение классов данных и построение концептуальной модели данных в виде диаграмм классов;
- выделение классов, описывающих пользовательский интерфейс, и создание схемы навигации экранов;
- описание процессов взаимодействия объектов при выполнении системных функций;
- описание поведения объектов в виде диаграмм деятельностей и состояний;
- описание программных компонент и их взаимодействия через интерфейсы;
- описание физической архитектуры системы.
И последнее…
Несмотря на всю привлекательность UML, его было бы затруднительно использовать при реальном моделировании ПС без инструментальных средств визуального моделирования. Такие средства позволяют оперативно представлять диаграммы на экране дисплея, документировать их, генерировать заготовки программных кодов на различных ОО языках программирования, создавать схемы баз данных. Большинство из них включают возможности реинжиниринга программных кодов – восстановления определенных проекций модели ПС путем автоматического анализа исходных кодов программ, что очень важно для обеспечения соответствия модели и кодов и при проектировании систем, наследующих функциональность систем-предшественников.
Создавать для программы дополнительное визуальное и документальное сопровождение – процесс трудоемкий и утомительный: отнимает много времени и кажется совершенно излишним, если архитектура программного обеспечения проста или является эталонной. Однако на практике программисты далеко не всегда сталкиваются с такими задачами.
Почему не «взлетел» UML
В большинстве случаев при разработке программного обеспечения, если система требует правок, то программисты просто берут код и исправляют ошибки так, как им удобно, а затем демонстрируют результат заказчику.«Сегодня программирование - это не инженерная наука, а прикладная математика. При этом программисты сразу учатся писать код», - уточняет заведующий кафедрой Технологии программирования Университета ИТМО Анатолий Шалыто.
Чаще всего архитектура решения объясняется на словах или с применением простейших блок-диаграмм. Универсальный язык моделирования (UML), основанный на базе нескольких предыдущих стандартов, таких как метод Гради Буча (Booch), метод Джима Румбаха (OMT) и метод Айвара Джекобсона (OOSE), должен был помочь в этом вопросе. И на него возлагали определенные надежды.
Люди пробовали работать с UML, надеясь, что тот станет своеобразной «серебряной пулей», однако он не приобрел широкой популярности. Исследователи выделяют три главных препятствия, которые помешали массовому распространению диаграмм состояний в качестве общепринятого средства описания алгоритмов и сложных поведений программ.
Во-первых, для описания поведения, кроме диаграмм состояний, предлагалось использовать и другие типы диаграмм, однако правила, определяющие их взаимодействие, не были регламентированы.
«Многие считают, что этот язык слишком объемный, - говорит исследователь и предприниматель Хорди Кабот (Jordi Cabot). - Это связано с большим количеством диаграмм, доступных в UML».
Во-вторых, не было предложено подходов для совместного использования диаграмм, описывающих структуру и поведение программ. В-третьих, диаграммы для описания поведения в основном использовались разработчиками для общения друг с другом, в то время как назначение UML - составление спецификации с последующим её воплощением в программном коде.
Подобная судьба ожидала и множество других решений, которые, однако, не являются полноценными альтернативами UML. Речь идет о системе условных обозначений для моделирования бизнес-процессов (BPMN), моделях сущность-связь (ERM), диаграммах потоков данных (DFD), диаграммах состояний и др. Как отмечает Крис Фурман (Cris Fuhrman), все это не более, чем инструменты общения.
Переход к автоматам
Однако спецификации проектов нужны, поскольку они фиксируют результат процесса проектирования, освобождая ум разработчика для решения других задач, а также используются в качестве входных данных на этапе реализации.
Этапы разработки программной системы со сложным поведением
Автоматное программирование является подходом, способным облегчить процесс формирования спецификации. Во время работы создаются графы, в которых под влиянием внешних или любых других входных воздействий осуществляются переходы между состояниями и формируются выходные «импульсы». Для этого сперва формируется текстовая версия технического задания, в котором заказчик прописывает подробную работу желаемого решения.
После этого объявляются условные обозначения входных и выходных воздействий, источников и приемников информации, а затем рисуется схема. Графы переходов позволяют заказчику лучше понять то, что будет делать программист.
Имея схему связей и диаграмму переходов, с помощью формального преобразования можно построить код, реализующий автомат на языке программирования. После этого спецификации становятся частью проектной документации системы. Проектная документация составляется на естественном языке и обычно содержит постановку задачи, описание структуры и поведения системы, примеры ее использования.
Автоматное описание в ООП
Принципы автоматного подхода находят применение и в объектно-ориентированном программировании. Это возможно благодаря концепции «автоматы и объекты управления как классы». Такая модель принята, например, в инструментальном средстве автоматного программирования UniMod. Архитектура системы со сложным поведением, построенная согласно этому принципу представлена на рисунке ниже.
Сопоставление отдельного класса каждому объекту управления приводит к тому, что усилия разработчиков по выделению этих объектов на стадии моделирования не пропадают на этапе реализации. При этом каждый запрос или команда имеет доступ только к строго определенной части вычислительного состояния.
В целом же процесс проектирования системы со сложным поведением можно описать следующим образом:
- Проведение объектной декомпозиции, когда система разбивается на множество самостоятельных взаимодействующих сущностей.
- Сопоставление сущностей с классами, определение интерфейсов классов и отношений.
- Выделение тех сущностей, которые обладают сложным поведением, - именно для их описания будет применяться автоматный подход.
- Задание набора управляющих состояний для каждой сущности. Запросы и команды сопоставляются с входными и выходными переменными управляющего автомата, а компоненты интерфейса - с его событиями. На их основе строится сам управляющий автомат.
- Реализация неавтоматизированных классов на выбранном объектно-ориентированном языке. Генерация кода может выполняться как автоматически, так и вручную.
