Диаграммы реализации предназначены для отображения состава компилируемых и выполняемых модулей системы, а так же связей между ними. Диаграммы реализаций разделяются на два конкретных вида: диаграммы компонентов (component diagrams) и диаграммы развертывания (deployment diagrams).
Диаграмма компонентов отражает зависимости составных частей программного обеспечения, в которые включаются файлы исходных текстов, двоичные файлы библиотек объектных модулей и исполняемые файлы. Она состоит из компонентов и отношений между ними. Используются отношения двух типов:
зависимость - это зависимость любого типа (использование, совместная компиляция);
композиция - это включение одних компонентов в состав других.
Компонент изображается в виде прямоугольника с двумя маленькими прямоугольниками у левого края, внутри прямоугольника записывается имя компонента.
Зависимость изображается штриховой линией от использующего компонента к используемому. Композиция (или включение) изображается размещением включаемого компонента внутри включающего. Компоненты могут иметь интерфейсы, через которые выражаются зависимости. Интерфейсами могут являться, например, имена вызываемых подпрограмм. Интерфейсы изображаются окружностями, соединенными с компонентой линией без направления, рядом записывается имя интерфейса.
Диаграммы развертывания показывают конфигурацию исполняемой программной системы, состоящей из программных компонентов, процессов, объектов. Она состоит из узлов и отношений взаимодействия между узлами и компонентами. Узлы могут включать компоненты и объекты.
Узлы представляют собой физические элементы времени выполнения, обозначающие вычислительный ресурс, обладающий как минимум запоминающим устройством и возможно вычислительным устройством. Узлы могут обозначать компьютеры, человеческие ресурсы или механические устройства. Внутри узлов могут содержаться компоненты и объекты, что обозначает, что данный компонент или объект существует в рамках данного узла. Узлы изображаются как проекция трехмерного куба. Узел может представлять собой тип узла или конкретный экземпляр узла. В зависимости от этого происходит именования узла.
Рисунок 4 - Диаграмма компонентов
Рисунок 5 - Диаграмма развертывания
Диаграмма IDEF0
IDEF0 (Integration Definition for Function Modeling) - нотация описания бизнес-процессов. Основана на методологии SADT.(Structured Analysis and Design Technique, технология структурного анализа и проектирования) - графические обозначения и подход к описанию систем. Разработка SADT началась в 1969 году и была опробована на практике в компаниях различных отраслей (аэрокосмическая отрасль, телефония и т.д.). Публично появилась на рынке в 1975 г и получила очень широкое распространение в мире.является результатом программы компьютеризации промышленности, которая была предложена ВВС США. Автоматизация деятельности предприятий потребовала соответствующих методик и инструментов. Перед тем, как разрабатывать программное обеспечение, необходимо было четко и понятно описать бизнес-процессы (нельзя автоматизировать хаос). Инструменты, разработанные для задач программирования, так же могут быть полезны и для задач менеджмента. Нотация может быть использована для моделирования широкого круга автоматизированных и неавтоматизированных систем.
Идея 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
) Галицына О.Л., Максимов Н.В. Базы данных М.: «Форум-ИНФРА-М» 2006