Unified Modeling Language как унифицированный язык моделирования

Российский государственный университет инновационных технологий и предпринимательства

(филиал г. Пенза)

КУРСОВАЯ РАБОТА

Автор — студент гр.10зУ6 Кильдеев И. Х Руководитель — Такташкин Д. В Пенза 2014

• Введение
• 1) Диаграмма программного обеспечения UML
• 2) Диаграмма деятельности UML
• 3) Диаграмма последовательности UML
• 4) Диаграмма реализации UML
• 5) Диаграмма IDEF0
• Заключение
• Список использованной литературы

UML — это унифицированный графический язык моделирования для описания, визуализации, проектирования и документирования ОО систем. UML призван поддерживать процесс моделирования ПС на основе ОО подхода, организовывать взаимосвязь концептуальных и программных понятий, отражать проблемы масштабирования сложных систем. Модели на UML используются на всех этапах жизненного цикла ПС, начиная с бизнес-анализа и заканчивая сопровождением системы. Разные организации могут применять UML по своему усмотрению в зависимости от своих проблемных областей и используемых технологий.

К середине 90-х годов различными авторами было предложено несколько десятков методов ОО моделирования, каждый из которых использовал свою графическую нотацию. При этом любой их этих методов имел свои сильные стороны, но не позволял построить достаточно полную модель ПС, показать ее «со всех сторон», то есть, все необходимые проекции (См. статью 1). К тому же отсутствие стандарта ОО моделирования затрудняло для разработчиков выбор наиболее подходящего метода, что препятствовало широкому распространению ОО подхода к разработке ПС.

По запросу Object Management Group (OMG) — организации, ответственной за принятие стандартов в области объектных технологий и баз данных назревшая проблема унификации и стандартизации была решена авторами трех наиболее популярных ОО методов — Г. Бучем, Д. Рамбо и А. Джекобсоном, которые объединенными усилиями создали версию UML 1.1, утвержденную OMG в 1997 году в качестве стандарта.

Любой язык состоит из словаря и правил комбинирования слов для получения осмысленных конструкций. Так, в частности, устроены языки программирования, таковым является и UML. Отличительной его особенностью является то, что словарь языка образуют графические элементы. Каждому графическому символу соответствует конкретная семантика, поэтому модель, созданная одним разработчиком, может однозначно быть понята другим, а также программным средством, интерпретирующим UML. Отсюда, в частности, следует, что модель ПС, представленная на UML, может автоматически быть переведена на ОО язык программирования (такой, как Java, C++, VisualBasic), то есть, при наличии хорошего инструментального средства визуального моделирования, поддерживающего UML, построив модель, мы получим и заготовку программного кода, соответствующего этой модели.

Следует подчеркнуть, что UML — это именно язык, а не метод. Он объясняет, из каких элементов создавать модели и как их читать, но ничего не говорит о том, какие модели и в каких случаях следует разрабатывать. Чтобы создать метод на базе UML, надо дополнить его описанием процесса разработки ПС. Примером такого процесса является Rational Unified Process, который будет рассматриваться в последующих статьях.

Модель представляется в виде сущностей и отношений между ними, которые показываются на диаграммах.

Сущности — это абстракции, являющиеся основными элементами моделей. Имеется четыре типа сущностей — структурные (класс, интерфейс, компонент, вариант использования, кооперация, узел), поведенческие (взаимодействие, состояние), группирующие (пакеты) и аннотационные (комментарии). Каждый вид сущностей имеет свое графическое представление. Сущности будут подробно рассмотрены при изучении диаграмм.

Отношения показывают различные связи между сущностями. В UML определены следующие типы отношений:

· Зависимость показывает такую связь между двумя сущностями, когда изменение одной из них — независимой — может повлиять на семантику другой — зависимой. Зависимость изображается пунктирной стрелкой, направленной от зависимой сущности к независимой.

· Ассоциация — это структурное отношение, показывающее, что объекты одной сущности связаны с объектами другой. Графически ассоциация показывается в виде линии, соединяющей связываемые сущности. Ассоциации служат для осуществления навигации между объектами. Например, ассоциация между классами «Заказ» и «Товар» может быть использована для нахождения всех товаров, указанных в конкретном заказе — с одной стороны, или для нахождения всех заказов в которых есть данный товар, — с другой. Понятно, что в соответствующих программах должен быть реализован механизм, обеспечивающий такую навигацию. Если требуется навигация только в одном направлении, оно показывается стрелкой на конце ассоциации. Частным случаем ассоциации является агрегирование — отношение вида «целое» — «часть». Графически оно выделяется с помощью ромбика на конце около сущности-целого.

· Обобщение — это отношение между сущностью-родителем и сущностью-потомком. По существу, это отношение отражает свойство наследования для классов и объектов. Обобщение показывается в виде линии, заканчивающейся треугольничком направленным к родительской сущности. Потомок наследует структуру (атрибуты) и поведение (методы) родителя, но в то же время он может иметь новые элементы структуры и новые методы. UML допускает множественное наследование, когда сущность связана более чем с одной родительской сущностью.

· Реализация — отношение между сущностью, определяющей спецификацию поведения (интерфейс) с сущностью, определяющей реализацию этого поведения (класс, компонент). Это отношение обычно используется при моделировании компонент и будет подробнее описано в последующих статьях.

Диаграммы. В UML предусмотрены следующие диаграммы:

· Диаграммы, описывающие поведение системы:

o Диаграммы состояний (State diagrams),

o Диаграммы деятельностей (Activity diagrams),

o Диаграммы объектов (Object diagrams),

o Диаграммы последовательностей (Sequence diagrams),

o Диаграммы взаимодействия (Collaboration diagrams);

· Диаграммы, описывающие физическую реализацию системы:

o Диаграммы компонент (Component diagrams);

o Диаграммы развертывания (Deployment diagrams).

1) Диаграмма программного обеспечения UML

Диаграмма программного обеспечения:

Рисунок 1 — Диаграмма программного обеспечения

2) Диаграмма деятельности UML

Диаграмма деятельности представляет по существу обычную блок-схему. На ней показываются деятельности — шаги в выполнении процесса, изображаемые в виде прямоугольников с сопряженными дугами горизонтальными сторонами и переходы между ними, показываемые стрелками. Предусмотрена возможность ветвления, изображаемая в виде ромба. На этих диаграммах можно показать распараллеливание процесса на подпроцессы и слияние подпроцессов. Для обозначения этих действий используются жирные горизонтальные или вертикальные линии. Все элементы могут быть проименованы.

С помощью диаграмм деятельности удобно представлять алгоритмы выполнения работ. В частности, использование ветвления дает возможность легко отобразить основной и альтернативные потоки событий при выполнении ВИ.

унифицированный графический язык моделирование

Рисунок 2 — Диаграмма деятельности

3) Диаграмма последовательности UML

На диаграммах последовательностей, иногда называемых сценариями, показываются объекты и сообщения, которыми они обмениваются. Каждый объект изображается в виде вертикальной линии («линии жизни» объекта). По вертикали сверху вниз направлена временная ось. Сообщение, показываемое в виде стрелки от объекта к объекту, соответствует вызову операции соответствующего класса. Таким образом, на диаграмме можно показать поток сообщений во времени (сценарий). С помощью диаграмм этого вида можно описать как основной, так и альтернативные потоки событий для ВИ.

Рисунок 3 — Диаграмма последовательности

4) Диаграмма реализации UML

Диаграммы реализации предназначены для отображения состава компилируемых и выполняемых модулей системы, а так же связей между ними. Диаграммы реализаций разделяются на два конкретных вида: диаграммы компонентов (component diagrams) и диаграммы развертывания (deployment diagrams).

Диаграмма компонентов отражает зависимости составных частей программного обеспечения, в которые включаются файлы исходных текстов, двоичные файлы библиотек объектных модулей и исполняемые файлы. Она состоит из компонентов и отношений между ними. Используются отношения двух типов:

— зависимость — это зависимость любого типа (использование, совместная компиляция);

— композиция — это включение одних компонентов в состав других.

Компонент изображается в виде прямоугольника с двумя маленькими прямоугольниками у левого края, внутри прямоугольника записывается имя компонента.

Зависимость изображается штриховой линией от использующего компонента к используемому. Композиция (или включение) изображается размещением включаемого компонента внутри включающего. Компоненты могут иметь интерфейсы, через которые выражаются зависимости. Интерфейсами могут являться, например, имена вызываемых подпрограмм. Интерфейсы изображаются окружностями, соединенными с компонентой линией без направления, рядом записывается имя интерфейса.

Диаграммы развертывания показывают конфигурацию исполняемой программной системы, состоящей из программных компонентов, процессов, объектов. Она состоит из узлов и отношений взаимодействия между узлами и компонентами. Узлы могут включать компоненты и объекты.

Узлы представляют собой физические элементы времени выполнения, обозначающие вычислительный ресурс, обладающий как минимум запоминающим устройством и возможно вычислительным устройством. Узлы могут обозначать компьютеры, человеческие ресурсы или механические устройства. Внутри узлов могут содержаться компоненты и объекты, что обозначает, что данный компонент или объект существует в рамках данного узла. Узлы изображаются как проекция трехмерного куба. Узел может представлять собой тип узла или конкретный экземпляр узла. В зависимости от этого происходит именования узла.

Рисунок 4 — Диаграмма компонентов Рисунок 5 — Диаграмма развертывания

5) Диаграмма IDEF0

IDEF0 (Integration Definition for Function Modeling) — нотация описания бизнес-процессов. Основана на методологии SADT.

SADT (Structured Analysis and Design Technique, технология структурного анализа и проектирования) — графические обозначения и подход к описанию систем. Разработка SADT началась в 1969 году и была опробована на практике в компаниях различных отраслей (аэрокосмическая отрасль, телефония и т. д.). Публично появилась на рынке в 1975 г и получила очень широкое распространение в мире.

IDEF0 является результатом программы компьютеризации промышленности, которая была предложена ВВС США. Автоматизация деятельности предприятий потребовала соответствующих методик и инструментов. Перед тем, как разрабатывать программное обеспечение, необходимо было четко и понятно описать бизнес-процессы (нельзя автоматизировать хаос). Инструменты, разработанные для задач программирования, так же могут быть полезны и для задач менеджмента. Нотация может быть использована для моделирования широкого круга автоматизированных и неавтоматизированных систем.

Идея IDEF0 лежит в том, что бизнес-процесс отображается в виде прямоугольника, в которой входят и выходят стрелки.

Для IDEF0 имеет значение сторона процесса и связанная с ней стрелка:

· слева входящая стрелка — вход бизнес-процесса — информация (документ) или ТМЦ, который будет преобразован в ходе выполнения процесса;

· справа исходящая стрелка — выход бизнес-процесса — преобразованная информация (документ) или ТМЦ;

· сверху входящая стрелка — управление бизнес-процесса — информация или документ, который определяет как должен выполняться бизнес-процесс, как должно происходить преобразование входа в выход;

· снизу входящая стрелка — механизм бизнес-процесса — то, что преобразовывает вход в выход: сотрудники или техника. Считается, что за один цикл процесса не происходит изменения механизма.

Выход одного бизнес-процесса является входом/управлением/механизмом другого бизнес-процесса. На диаграмме процессы принято располагать по диагонали с верхнего левого угла в нижний правый. Количество процессов не более 6−8.

Преимущества IDEF0 — показывает взаимодействие процессов в общем виде, без лишних подробностей.

Недостатки IDF0 — нельзя увидеть алгоритма выполнения бизнес-процессов. Требует определенной подготовки для разработки и чтения нотации.

Основными потребителями нотации IDEF0 являются руководители, которым необходимо видеть и понимать взаимосвязь процессов, не вникая в мелочи.

Клиент делает запрос в банк о получении кредита. Сотрудник банка обрабатывает запрос клиента и передает данные о клиенте в компьютерную программу. Компьютерная программа проверяет платежеспособность клиента и в случае положительного решения передает сотруднику информацию о выдаче кредита. Сотрудник выдает кредит.

Рисунок 6 — Диаграмма IDEF0

Компьютерная программа проверяет платежеспособность клиента и в случае положительного решения передает сотруднику информацию о выдаче кредита. Сотрудник выдает кредит. Далее компьютерная программа составляет договор для клиента и график платежей. Клиент по графику платежей оплачивает сумму кредита.

Рисунок 7 — Диаграмма IDEF0

Заключение

Слово «моделирование», входящее в название UML, имеет множество смысловых оттенков и сложившихся способов употребления. В частности, английские слова modeling и simulation оба переводятся словом «моделирование», хотя означают разные вещи. В первом случае речь идет о составлении модели, которая используется только для описания моделируемого объекта или явления. Во втором случае подразумевается составление модели, которая может быть использована для получения существенной информации о моделируемом объекте или явлении. При этом во втором случае обычно добавляется уточняющее прилагательное: численное моделирование, математическое моделирование и др. UML является языком моделирования в первом смысле, хотя известны некоторые успешные попытки использования UML и во втором смысле.

В отношении разработки программного обеспечения так сложилось, что результаты фаз анализа и проектирования, оформленные средствами определенного языка, принято называть моделью?. Деятельность по составлению моделей естественно назвать моделированием. Именно в этом смысле UML является языком моделирования.

В этой книге термины «программное обеспечение», «программная система», «программа» и «приложение» используются как синонимы. Авторы понимают, что в действительности между ними существуют определенные различия, однако в контексте книги эти различия не имеют большого значения.

Таким образом, модель UML? это, прежде всего, описание объекта или явления, а также и кое-что другое, а именно все, что авторам UML удалось включить в язык, не нарушая принципа унификации, к изложению которого мы переходим в следующем разделе.

Описывая историю создания UML, его авторы характеризуют эпоху до UML как период «войны методов». Пожалуй, «война»? это слишком сильно сказано, но, действительно, UML является отнюдь не первым языком моделирования. К моменту его появления насчитывались десятки других, различающихся системой обозначений, степенью универсальности, способами применения и т. д. Авторы языков и теоретики программирования препирались между собой, выясняя, чей подход лучше, а разработчики всю эту «войну методов» равнодушно игнорировали, поскольку ни один из методов не дотягивал до уровня индустриального стандарта.

Толчком к изменению ситуации послужили следующие обстоятельства. Во-первых, массовое распространение получил объектно-ориентированный подход к разработке программных систем, в результате чего возникла потребность в соответствующих средствах. Другими словами, появления чего-то подобного UML с нетерпением ждали практики. Во-вторых, три крупнейших специалиста в этой области, авторы наиболее популярных методов, решились объединить усилия именно с целью унификации своих (и не только своих) разработок в соответствии с социальным заказом.

Приложив заслуживающие уважения усилия, авторы UML при поддержке и содействии всей международной программистской общественности смогли свести воедино (унифицировать) большую часть того, что было известно и до них. В результате унификации получилась теоретически изящная и практически полезная вещь? UML.

1) Вендров А. М. Проектирование программного обеспечения ЭИС М.: «Финансы и статистика» 2003

2) Вендров А. М. Практикум по проектированию программного обеспечения ЭИС: Учебное пособие.- М.: Издательство «Финансы и статистика» 2004

3) Галицына О. Л., Максимов Н. В. Базы данных М.: «Форум-ИНФРА-М» 2006