Язык Unified Modelling Language (UML) можно считать результатом довольно длинной и еще не завершившейся эволюции методологий моделирования и дизайна.В 90-х годах наиболее популярными были три объектно-ориентированных подхода: OMT (автор Джеймс Рамбо), сильной стороной которого является анализ, а слабой - дизайн; OODA (автор Гради Буч) - сильная сторона этого языка - дизайн, а слабая - анализ; OOSE (автор Айвар Якобсон) - сильной стороной данного языка является анализ поведения (behavior analysis), однако в остальных областях он достаточно слаб.В результате соперничества этих методов авторы вышеперечисленных методологий создали унифицированный язык моделирования UML (рис. 1), который унаследовал присутствовавшие в других языках элементы. Далее приведена оригинальная терминология заимствованных/унаследованных элементов языка этой методологии - дело в том, что сейчас существует несколько вариантов переводов этих терминов на русский язык.Данная унификация преследовала три основные цели: моделирование системы, начиная с концепции и заканчивая исполняемым модулем, с применением объектно-ориентированных методик; разрешение проблем масштабирования в сложных системах; создание языка моделирования, используемого и человеком, и компьютером.Официальной датой начала работ по UML считают октябрь 1994 года, когда Рамбо перешел в компанию Rational (ныне Rational - одно из подразделений корпорации IBM). Последним стандартом этого языка является версия UML1.3, вышедшая в 1999 году.Средства UML-моделирования Является ли UML необходимым компонентом RUP? Да, безусловно. Но практика использования UML как средства описания процесса моделирования и разработки программного обеспечения не ограничивается RUP. Как и любой другой язык, UML - это всего только средство. В RUP предусмотрен ряд утилит, позволяющих довольно легко использовать UML, но их набор не ограничивается лишь продуктами IBM/Rational. Ниже приводится далеко не полный список некоторых продуктов, поддерживающих UML: Rational Rose (Rational Software, Windows 98/NT/2000/XP, Linux Red Hat 6.2, 7.0, Solaris 2.5.1, 2.6, 7, 8, HP-UX 10.20, 11.0, 11.i); Microsoft Visual Studio .NET Enterprise Architect, Microsoft Visio (Microsoft, платформы: Windows 8/NT/2000/XP/Server 2003); Describe Enterprise (Embarcadero technologies, платформы: Windows 98/NT/2000/XP); семейство продуктов Together (Borland, платформы: Windows 98/NT/2000/XP, Linux, Solaris);
Bold for Delphi (Borland, платформы: Windows 98/NT/2000/XP);
MagicDraw (Magic, Inc., платформы: Windows 98/Me/NT/2000/XP, Solaris, OS/2, Linux, HP-UX, AIX, Mac OS);
QuickUML (ExcelSoftware, платформы: Windows 98/NT/2000/XP) - неплохая утилита для начинающих.
Отметим также некоторые продукты OpenSourse, например ArgoUML, Novosoft UML Library.
Документ, который содержит списки продуктов, поддерживающих UML, компаний-производителей, платформ, а также информацию о примерных ценах продуктов, можно найти по адресу: http://www.objectsbydesign.com/tools/umltools_byCompany.html.
Следует также отметить, что, несмотря на факт существования стандарта UML 1.3, поддерживаемые перечисленными продуктами реализации UML или обладают собственными особенностями, или не полностью следуют стандарту, поэтому при выборе средства моделирования следует обращать внимание на поддерживаемые типы диаграмм и особенности синтаксиса. Кроме того, возможности прямого и обратного проектирования (Round-Trip Engineering) в разных продуктах весьма различны. Не все вышеуказанные продукты могут поддерживать языки программирования Java, C++, CORBA IDL, поэтому следует обращать особое внимание на то, какую модель сможет сгенерировать тот или иной продукт из имеющегося у вас кода, на каком языке может быть получен код из вашей UML-модели и какого она должна быть типа.Таблица, показывающая, какие диаграммы UML реализованы в том или ином продукте, находится по адресу: http://www.jeckle.de/umltools.htm.
Для чего применяется UML
UML - прежде всего язык, и, как всякое языковое средство, он предоставляет словарь и правила комбинирования слов в этом словаре. В данном случае словарь и правила фокусируются на концептуальном и физическом представлениях системы. Язык диктует, как создать и прочитать модель, однако не содержит никаких рекомендаций о том, какую модель системы необходимо создать, - это выходит за рамки UML и является прерогативой процесса разработки программного обеспечения. В связи с этим, видимо, UML довольно часто ассоциируют с RUP - одним из возможных процессов, рекомендующих, какие модели, как и когда нужно создавать для успешной разработки продукта.
UML - это язык визуализации. Написание моделей на UML преследует одну простую цель - облегчение процесса передачи информации о системе. За каждым символом UML стоит строго определенная семантика, что позволяет избегать ошибок интерпретации (ответы на вопросы типа «а что имел в виду разработчик Х, когда он описал иерархию классов Y…» и т.п. будут достаточно прозрачны).
UML - это язык спецификаций и точных определений. В этом смысле моделирование на UML означает построение моделей, которые точны, недвусмысленны и полны.
UML - это язык конструирования. UML не является визуальным языком программирования, но модели в терминах UML могут быть отображены на определенный набор объектно-ориентированных языков программирования. UML предоставляет возможности прямого (существующая модель ® новый код) и обратного (существующий код ® новая модель) проектирования. Достаточно часто средства UML-моделирования реализуют отображения UML-моделей в коде на языках Java, C++, CORBA, VB, Smalltalk.
UML - это язык документирования. Процесс разработки программного обеспечения предусматривает не только написание кода, но и создание таких артефактов, как список требований, описание архитектуры, дизайн, исходный код системы, планирование проекта, тесты, набор прототипов, релизы продукта. В зависимости от культуры разработки продукта в той или иной компании степень формализации данных документов существенно различается, варьируясь от строго определенных шаблонов и формата документов до разговоров на произвольную тему по e-mail или лично. Тем не менее все эти артефакты критичны для успешного процесса разработки продукта. UML предоставляет средства отображения требований к системе, построения документации, тестов, моделирования необходимых действий для планирования проекта и для управления поставленными конечному пользователю релизами.
История создания UML
Разработка UML началась в октябре 1994 года, когда Гради Буч и Jim Rumbaugh из Rational Software Corporation приступили к совместной работе по унифицированию методов Booch и OMT (Object Modeling Technique). Оба метода развивались независимо друг от друга и были по праву названы одними из лучших методов объектно-ориентированного подхода при разработке программных систем. Было принято решение об объединении этих двух методов, и в октябре 1995 вышла бета-версия, которая получила название Unified Method.
К концу 1996 года выяснилось, что ряд крупных компаний готовы рассмотреть UML в качестве основной стратегии своего бизнеса. Был создан некоммерческий консорциум OMG (Object Modeling Group), который объединил таких ведущих производителей ПО, как DEC, HP, IBM, Microsoft, Oracle, Rational Software и др. В январе 1997 был выдан UML 1.0. Вскоре к OMG примкнули такие компании, как IBM, Objectime, Platinum Technology и Softeam. Как результат этого сотрудничества появилась версия UML 1.1. В 2003 была принята версия 1.5. 2004 г. – принята версия 2.0
Структура UML
UML (сокр. от англ. Unified Modeling Language - унифицированный язык моделирования) - язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт использующий графические обозначения для создания абстрактной модели системы, которая называется UML моделью. UML был создан для определения, визуализации, проектирования и документирования по большей части программных систем.
UML обеспечивает разработку репрезентативных моделей для организации взаимодействия заказчика и разработчика ИС, различных групп разработчиков ИС.
Прежде всего, UML наследует техники Booch, OMT и OOSE.
Во-вторых, перекрывает их.
В-третьих, надо отметить, что UML - это стандарт языка, а не стандарт процесса.
Язык UML включает набор графических элементов, используемых на диаграммах. Будучи языком, UML содержит правила для объединения этих элементов. Диаграммы используются для отображения различных представлений системы. Этот набор различных представлений называется моделью. Модель UML описывает, что должна будет делать система. В то же время, ничего не сообщается о том, как она будет реализована.
С самой общей точки зрения описание языка UML состоит из двух взаимодействующих частей, таких как:
Семантика языка UML . Она представляет собой некоторую метамодель, которая определяет абстрактный синтаксис и семантику понятий объектного моделирования на языке UML.
Нотация языка UML . Она представляет собой графическую нотацию для визуального представления семантики языка UML.
Диаграммы UML
Перейдем теперь к обзору графической нотации UML. Графическая нотация - это отображение визуального представления в семантику языка. Как упоминалось ранее, UML является квинтэссенцией трех техник моделирования, и, по существу, наследует их графическую нотацию, отвергая малоиспользуемые и невыразительные элементы и добавляя новые, отвечающие запросам современного рынка программных систем. При создании UML старались сохранить баланс между простотой, понятностью языка и его выразительной мощью и точностью. Модель разрабатываемой системы являет собой совокупность взаимосвязанных подмоделей, каждая из которых описывается набором диаграмм, описанных с помощью определенной в UML графической нотации.
Проект, создаваемый с помощью языка UML 1.x, может включать в себя следующие диаграммы (сгруппированы в соответствии с их предназначением). Таких диаграмм насчитывается восемь :
· Диаграмма вариантов (прецедентов) использования (use case diagram)
· Диаграмма классов (class diagram)
· Диаграммы поведения (behavior diagrams)
o Диаграмма состояний (statechart diagram)
o Диаграмма активности (activity diagram)
o Диаграммы взаимодействия (interaction diagrams)
§ Диаграмма последовательности (sequence diagram)
§ Диаграмма кооперации (collaboration diagram)
· Диаграммы реализации (implementation diagrams)
o Диаграмма компонентов (component diagram)
o Диаграмма размещения (развертывания) (deployment diagram)
3.1. Диаграмма вариантов (прецедентов) использования (use case diagram)
Диаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. «Каждая функциональность» изображается в виде «прецедентов использования» (use case) или просто прецедентов. Прецедент - это типичное взаимодействие пользователя с системой, которое при этом:
описывает видимую пользователем функцию,
может представлять различные уровни детализации,
обеспечивает достижение конкретной цели, важной для пользователя.
Прецедент обозначается на диаграмме овалом, связанным с пользователями, которых принято называть действующими лицами (актерами, actors). Действующие лица используют систему (или используются системой) в данном прецеденте. Действующее лицо выполняет некоторую роль в данном прецеденте. На диаграмме изображается только одно действующее лицо, однако реальных пользователей, выступающих в данной роли по отношению к ИС, может быть много. Список всех прецедентов фактически определяет функциональные требования к ИС, которые лежат в основе разработки технического задания на создание системы.
На диаграммах прецедентов, кроме связей между действующими лицами и прецедентами, возможно использование еще двух видов связей между прецедентами: «использование» и «расширение» (рис. 3.1.1). Связь типа «расширение» применяется, когда один прецедент подобен другому, но несет несколько большую функциональную нагрузку. Ее следует применять при описании изменений в нормальном поведении системы. Связь типа «использование» позволяет выделить некий фрагмент поведения системы и включать его в различные прецеденты без повторного описания.
Унифицированный язык моделирования (UML) является стандартным инструментом для создания «чертежей» информационных систем (ИС). С помощью UML можно визуализировать, специфицировать, конструировать и документировать элементы этих систем.
UML пригоден для моделирования любых систем: от информационных систем масштаба предприятия до распределенных Web-приложений и даже встроенных систем реального времени. Это очень выразительный язык, позволяющий рассмотреть систему со всех точек зрения, имеющих отношение к ее разработке и последующему развертыванию. Несмотря на обилие выразительных возможностей, этот язык прост для понимания и использования. Изучение UML удобнее всего начинать с его концептуальной модели, которая включает в себя три основных элемента: базовые строительные блоки, правила, определяющие, как эти блоки могут сочетаться между собой, и некоторые общие механизмы языка.
UML является одной из составляющих процесса разработки ИС. Хотя UML не зависит от моделируемой реальности, лучше всего применять его, когда процесс моделирования основан на рассмотрении прецедентов использования, является итеративным и пошаговым, а сама система имеет четко выраженную архитектуру.
UML — это язык для визуализации, специфицирования, конструирования и документирования элементов программных систем. Язык состоит из словаря и правил, позволяющих комбинировать входящие в него слова и получать осмысленные конструкции. В языке моделированиясловарь и правила ориентированы на концептуальное и физическое представление системы. Язык моделирования, подобный UML, является стандартным средством для составления «чертежей» ИС.
При создании ИС любой сложности проводиться моделирование будущей системы, однако во многих случаях это делается неформально, без разработки какого-либо документа. Однако такой подход чреват неприятностями. Во-первых, обмен мнениями по поводу концептуальной модели возможен только тогда, когда все участники дискуссии говорят на одном языке. Во-вторых, нельзя получить представление об определенных аспектах информационных систем без модели, выходящей за границы текстового языка программирования. В-третьих, если автор кода никогда не воплощал в явной форме задуманные им модели, эта информация будет навсегда утрачена, если он сменит место работы. В лучшем случае ее можно будет лишь частично воссоздать исходя из реализации.
Использование UML позволяет решить третью проблему: явная модель облегчает общение.
Некоторые особенности системы лучше всего моделировать в виде текста, другие — графически. На самом деле во всех интересных системах существуют структуры, которые невозможно представить с помощью одного лишь языка программирования. UML — графический язык, что позволяет решить вторую из обозначенных проблем.
UML — это не просто набор графических символов. За каждым из них стоит хорошо определенная семантика. Это значит, что модель, написанная одним разработчиком, может быть однозначно интерпретирована другим — или даже инструментальной программой. Так решается первая из перечисленных выше проблем.
В данном контексте специфицирование означает построение точных, недвусмысленных и полных моделей. UML позволяет специфицировать все существенные решения, касающиеся анализа, проектирования и реализации, которые должны приниматься в процессе разработки и развертывания информационной системы.
UML является языком визуального проектирования, а модели, созданные с его помощью, могут быть непосредственно переведены на различные языки программирования ИС.
При разработке ИС, создаются и такие элементы, как:
- требования к системе;
- описание архитектуры;
- проект;
- исходный код;
- проектные планы;
- тесты;
- прототипы;
- версии, и др.
В зависимости от принятой методики разработки выполнение одних работ производится более формально, чем других. Упомянутые элементы — это не просто поставляемые составные части проекта; они необходимы для управления, для оценки результата, а также в качестве средства общения между членами коллектива во время разработки системы и после ее развертывания.
UML позволяет решить проблему документирования системной архитектуры и всех ее деталей, предлагает язык для формулирования требований к системе и определения тестов и, наконец, предоставляет средства для моделирования работ на этапе планирования проекта и управления версиями.
Где используется UML
Язык UML предназначен прежде всего для разработки информационных систем. Его использование особенно эффективно в следующих областях:
- информационные системы масштаба предприятия;
- банковские и финансовые услуги;
- телекоммуникации;
- транспорт;
- оборонная промышленность, авиация и космонавтика;
- розничная торговля;
- медицинская электроника;
- наука;
- распределенные Web-системы.
Сфера применения UML не ограничивается моделированием программного обеспечения. Его выразительность позволяет моделировать, скажем, документооборот в юридических системах, структуру и функционирование системы обслуживания пациентов в больницах, осуществлять проектирование аппаратных средств.
Концептуальная модель UML
Для понимания UML необходимо усвоить его концептуальную модель, которая включает в себя три составные части: основные строительные блоки языка, правила их сочетания и некоторые общие для всего языка механизмы. Усвоив эти элементы, вы сумеете читать модели на UML и самостоятельно создавать их — начале, конечно, не очень сложные. По мере приобретения опыта в работе с языком вы научитесь пользоваться и более развитыми его возможностями.
Строительные блоки UML
Словарь языка UML включает три вида строительных блоков:
- сущности;
- отношения;
- диаграммы.
Сущности — это абстракции, являющиеся основными элементами модели. Отношения связывают различные сущности; диаграммы группируют представляющие интерес совокупности сущностей.
В UML имеется четыре типа сущностей:
- структурные;
- поведенческие;
- группирующие;
- аннотационные.
Сущности являются основными объектно-ориентированными блоками языка. С их помощью можно создавать корректные модели. Существует семь разновидностей структурных сущностей:
- Класс (Class)
- Интерфейс (Interface)
- Кооперация (Collaboration)
- Прецедент (Use case)
- Активным классом (Active class)
- Компонент (Component)
- Узел (Node)
Эти семь базовых элементов — классы, интерфейсы, кооперации, прецеденты, активные классы, компоненты и узлы — являются основными структурными сущностями, которые могут быть включены в модель UML. Существуют также разновидности этих сущностей: актеры, сигналы, утилиты (виды классов), процессы и нити (виды активных классов), приложения, документы, файлы, библиотеки, страницы и таблицы (виды компонентов).
Поведенческие сущности (Behavioral things) являются динамическими составляющими модели UML. Это глаголы языка: они описывают поведение модели во времени и пространстве. Существует всего два основных типа поведенческих сущностей:
- Взаимодействие (Interaction)
- Автомат (State machine)
Эти два элемента взаимодействия и автоматы являются основными поведенческими сущностями, входящими в модель UML. Семантически они часто бывают связаны с различными структурными элементами, в первую очередь — классами, кооперациями и объектами.
Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель . Есть только одна первичная группирующая сущность, а именно пакет .
Пакеты — это основные группирующие сущности, с помощью которых можно организовать модель UML Существуют также вариации пакетов, например каркасы (Frameworks), модели и подсистемы.
Аннотационные сущности — пояснительные части модели UML. Это комментарии для дополнительного описания, разъяснения или замечания к любому элементу модели. Имеется только один базовый тип аннотационных элементов — примечание (Note). Примечание — это просто символ для изображения комментариев или ограничений, присоединенных к элементу или группе элементов. Графически примечание изображается в виде прямоугольника с загнутым краем, содержащим текстовый или графический комментарий.
В языке UML определены четыре типа отношений:
- зависимость;
- ассоциация;
- обобщение;
- реализация.
Эти отношения являются основными связующими строительными блоками в UML и применяются для создания корректных моделей.
Четыре описанных элемента являются основными типами отношений, которые можно включать в модели UML Существуют также их вариации, например уточнение (Refinement), трассировка (Trace), включение и расширение (для зависимостей).
Диаграмма в UML — это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями). Диаграммы рисуют для визуализации системы с разных точек зрения. Диаграмма в некотором смысле одна из проекций системы. Как правило, за исключением наиболее тривиальных случаев, диаграммы дают свернутое представление элементов, из которых составлена система. Один и тот же элемент может присутствовать во всех диаграммах, или только в нескольких (самый распространенный вариант), или не присутствовать ни в одной (очень редко). Теоретически диаграммы могут содержать любые комбинации сущностей и отношений. На практике, однако, применяется сравнительно небольшое количество типовых комбинаций, соответствующих пяти наиболее употребительным видам, которые составляют архитектуру информационной системы. Таким образом, в UML выделяют девять типов диаграмм:
- диаграммы классов;
- диаграммы объектов;
- диаграммы прецедентов;
- диаграммы последовательностей;
- диаграммы кооперации;
- диаграммы состояний;
- диаграммы действий;
- диаграммы компонентов;
- диаграммы развертывания.
Здесь приведен неполный список диаграмм, применяемых в UML. Инструментальные средства позволяют генерировать и другие диаграммы, но девять перечисленных встречаются на практике чаще всего.
Правила языка UML
Строительные блоки UML нельзя произвольно объединять друг с другом. Как и любой другой язык, UML характеризуется набором правил, определяющих, как должна выглядеть хорошо оформленная модель, то есть семантически самосогласованная и находящаяся в гармонии со всеми моделями, которые с нею связаны.
В языке UML имеются семантические правила, позволяющие корректно и однозначно определять:
- имена , которые можно давать сущностям, отношениям и диаграммам;
- область действия (контекст, в котором имя имеет некоторое значение);
- видимость (когда имена видимы и могут использоваться другими элементами);
- целостность (как элементы должны правильно и согласованно соотноситься друг с другом);
- выполнение {что значит выполнить или имитировать некоторую динамическую модель).
Модели, создаваемые в процессе разработки информационных систем, эволюционируют со временем и могут неоднозначно рассматриваться разными участниками проекта в разное время. По этой причине создаются не только хорошо оформленные модели, но и такие, которые:
- содержат скрытые элементы (ряд элементов не показывают, чтобы упростить восприятие);
- неполные (отдельные элементы пропущены);
- несогласованные (целостность модели не гарантируется).
Появление не слишком хорошо оформленных моделей неизбежно в процессе разработки, пока не все детали системы прояснились в полной мере. Правила языка UML побуждают — хотя не требуют — в ходе работы над моделью решать наиболее важные вопросы анализа, проектирования и реализации, в результате чего модель со временем становится хорошо оформленной.
Общие механизмы языка UML
Строительство упрощается и ведется более эффективно, если придерживаться некоторых соглашений. Следуя определенным архитектурным образцам, можно оформить здание в викторианском или французском стиле. Тот же принцип применим и в отношении UML. Работу с этим языком существенно облегчает последовательное использование общих механизмов, перечисленных ниже:
- спецификации (Specifications);
- дополнения (Adornments);
- принятые деления (Common divisions);
- механизмы расширения (Extensibility mechanisms).
Архитектура
Для визуализации, специфицирования, конструирования и документирования информационных систем необходимо рассматривать их с различных точек зрения. Все, кто имеет отношение к проекту, — конечные пользователи, аналитики, разработчики, системные интеграторы, тестировщики, технические писатели и менеджеры проектов — преследуют собственные интересы, и каждый смотрит на создаваемую систему по-разному в различные моменты ее жизни. Системная архитектура является, пожалуй, наиболее важным элементом, который используется для управления всевозможными точками зрения и тем самым способствует итеративной и инкрементной разработке системы на всем протяжении ее жизненного цикла.
Архитектура — это совокупность существенных решений касательно:
- организации программной системы;
- выбора структурных элементов, составляющих систему, и их интерфейсов;
- поведения этих элементов, специфицированного в кооперациях с другими элементами;
- составления из этих структурных и поведенческих элементов все более и более крупных подсистем;
- архитектурного стиля, направляющего и определяющего всю организацию системы: статические и динамические элементы, их интерфейсы, кооперации и способ их объединения.
Архитектура программной системы охватывает не только се структурные и поведенческие аспекты, по и использование, функциональность, производительность, гибкость, возможности повторного применения, полноту, экономические и технологические ограничения и компромиссы, а также эстетические вопросы.
Вид с точки зрения прецедентов (Use case view) охватывает прецеденты, которые описывают поведение системы, наблюдаемое конечными пользователями, аналитиками и тестировщиками. Этот вид специфицирует не истинную организацию программной системы, а те движущие силы, от которых зависит формирование системной архитектуры. В языке UML статические аспекты этого вида передаются диаграммами прецедентов, а динамические — диаграммами взаимодействия, состояний и действий.
Вид с точки зрения проектирования (Design view) охватывает классы, интерфейсы и кооперации, формирующие словарь задачи и се решения. Этот вид поддерживает прежде всего функциональные требования, предъявляемые к системе, то есть те услуги, которые она должна предоставлять конечным пользователям. С помощью языка UML статические аспекты этого вида можно передавать диаграммами классов и объектов, а динамические — диаграммами взаимодействия, состояний и действий.
Вид с точки зрения процессов (Process view) охватывает нити и процессы, формирующие механизмы параллелизма и синхронизации в системе. Этот вид описывает главным образом производительность, масштабируемость и пропускную способность системы. В UML его статические и динамические аспекты визуализируются теми же диаграммами, что и для вида с точки зрения проектирования, но особое внимание при этом уделяется активным классам, которые представляют соответствующие нити и процессы.
Вид с точки зрения реализации (Implementation view) охватывает компоненты и файлы, используемые для сборки и выпуска конечного программного продукта. Этот вид предназначен в первую очередь для управления конфигурацией версий системы, составляемых из независимых (до некоторой степени) компонентов и файлов, которые могут по-разному объединяться между собой. В языке UML статические аспекты этого вида передают с помощью диаграмм компонентов, а динамические — с помощью диаграмм взаимодействия, состояний и действий.
Вид с точки зрения развертывания (Deployment view) охватывает узлы, формирующие топологию аппаратных средств системы, на которой она выполняется. В первую очередь он связан с распределением, поставкой и установкой частей, составляющих физическую систему. Его статические аспекты описываются диаграммами развертывания, а динамические -диаграммами взаимодействия, состояний и действий.
Каждый из перечисленных видов может считаться вполне самостоятельным, так что лица, имеющие отношение к разработке системы, могут сосредоточиться на изучении только тех аспектов архитектуры, которые непосредственно их касаются. Но нельзя забывать о том, что эти виды взаимодействуют друг с другом. Например, узлы вида с точки зрения развертывания содержат компоненты, описанные для вида с точки зрения реализации, а те, в свою очередь, представляют собой физическое воплощение классов, интерфейсов, коопераций и активных классов из видов с точки зрения проектирования и процессов. UML позволяет отобразить каждый из пяти перечисленных видов и их взаимодействия.
В настоящее время фирма 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 улучшает способность автоматизировать процессы жизненного цикла критически важных приложений, что соответствует потребностям постоянно усложняющегося и изменчивого мира электронного бизнеса.
Структурные диаграммы: Диаграмма классов Диаграмма компонентов Композитной составной структуры Диаграмма кооперации 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 унаследовало свое... | |||
