Программный инструмент моделирования ArgoUML

Введение

 

Согласно заданию, целью данной работы является разработка модели информационной системы на основе унифицированного языка моделирования UML. Рассмотрим, что представляет собой язык UML.

UML - это язык для визуализации, специфицирования, конструирования и документирования артефактов программных систем.

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

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

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

Язык UML предназначен, прежде всего, для разработки программных систем. Его использование особенно эффективно в следующих областях:

- информационные системы масштаба предприятия;

- банковские и финансовые услуги;

- телекоммуникации;

- транспорт;

- оборонная промышленность, авиация и космонавтика;

- розничная торговля;

- медицинская электроника;

- наука;

- распределенные Web-системы.

Для создания модели и получения программного кода, решено использовать прикладное программное обеспечение – CASE-средство Argo UML.

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

 

 

 

1 Техническое задание

Основание для разработки

 

Основанием создания данной программы послужило задание на курсовую работу, выданное доцентом кафедры «ВТ и АСУ» Юренко К.И. и утвержденное зав. кафедрой «ВТ и АСУ» Черновым А. В.

 

1.2 Назначение разработки, исходные данные

 

Проектирование информационной системы «Интернет-магазин бытовой техники» на основе объектно-ориентированного подхода с использованием унифицированного языка моделирования UML.

 

Требования к проекту

Требования к фундаментальным характеристикам

 

Проект должен соответствовать исходному заданию и выполняться при помощи CASE-средства проектирования и разработки информационных систем ArgoUML.

 

Требования к надежности

 

Проект должен соответствовать максимальным требованиям к надёжности. Исключаются ошибки различного рода.

 

Требования к составу и параметрам технических средств

 

ПК пользователя должен удовлетворять следующим требованиям:

− процессор IntelPentium 1 ГГц;

− объем оперативной памяти -1 Гб;

− дисковая подсистема -16 Гб.

Требования к информационной и программной совместимости

 

Данный программный продукт должен быть совместим операционными системами Windows 2000/XP/Vista/7/8/10.

 

Требования к маркировке и упаковке

 

Требований к упаковке и маркировке не требуется.

 

Требования к транспортированию и хранению

 

Транспортировка и хранение проекта могут быть произведены на любом носителе информации.

 

Теоретические сведения

2.1 Основные понятия и определения

 

Унифицированный язык моделирования (UML, UnifiedModelingLanguage) является преемником методов объектно-ориентированного анализа и проектирования, которые появились в конце 80-х и начале 90-х годов.

Первое упоминание об унифицированном методе (UnifiedMethod) версии 0.8 появилось в 1995 году на конференции OOPSLA ’95. Данный метод был предложен ГрадиБучом и Джимом Рамбо. В дальнейшем к ним присоединился Айвар Якобсон и в течение 1996 года Г. Буч, Д. Рамбо, А. Якобсон, получившие широкую известность как «трое друзей» (amigos) продолжали работа над своим методом, который к тому времени получил название унифицированный язык моделирования (UML). Однако помимо данного метода сообществом разработчиком были предложены и другие методы. Для стандартизации этих методов в рамках OMG (ObjectManagementGroup) была сформирована инициативная группа. В результате работы группы появилась версия языка UML.

Текущей версией языка UML является версия 1.5, также ведется работа над спецификацией языка UML версии 2.0.

UML – это название языка моделирования, но не метода. Следует различать эти понятия. Большинство методов включают в себя помимо языка моделирования процесс. Язык моделирования – это нотация (главным образом графическая), которая используется разработчиками для описания проекта. Процесс – это рекомендация относительно этапов, которых необходимо придерживаться при выполнении проекта.

Основными элементами UML являются сущности (Thing), отношения (Relationship), диаграммы (Diagram). Сущности являются ключевыми абстракциями языка, отношения связывают сущности вместе, диаграммы группируют коллекции сущностей, которые представляют интерес.

 

 

Структурные сущности являются существительными языка. К ним относятся:

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

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

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

- прецеденты (Usecase) — описание набора последовательностей действий, которые выполняются системой и имеют значение для конкретного действующего лица (Actor). Прецеденты изображаются в виде эллипса и используются для структурирования поведенческих сущностей в модели;

- активные классы (Activeclass) — это классы, чьими экземплярами являются активные объекты, которые владеют процессом или потоком управления и могут инициировать управляющее воздействие. Стереотипами конкретного класса являются процесс (Process) и поток (Thread). Графически такой класс изображается как класс с жирной границей;

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

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

Поведенческие сущности — это динамические части моделей UML. К ним относятся:

- взаимодействия (Interaction) — включают набор сообщений, которыми обмениваются указанные объекты с целью достижения указанной цели. Взаимодействие описывается в контексте кооперации и изображается направленной линией, маркируется именем операции сверху;

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

К базовым отношениям между объектами, которые позволяют строить блоки UML, можно отнести следующие:

- зависимость (Dependency) — это семантическое отношение между двумя сущностями, при котором изменение одной из них (независимой сущности) может отразиться на семантике другой (зависимой).

- ассоциация (Association) — структурное отношение, описывающее множество связей между объектами классификаторов, где связь (Link) — это соединение между объектами, которое описывает связи между их экземплярами. Ассоциации являются как бы клеем, который связывает систему воедино. Без ассоциаций мы имели бы просто некоторое количество классов, не способных взаимодействовать друг с другом. У ассоциации может быть имя, однако основную информацию об ассоциации следует искать у ее полюсов, где описывается, каким образом каждый объект участвует в ассоциации: у ассоциации есть список, состоящий из двух или более полюсов ассоциации: каждый из них определяет роль, которую играет данный классификатор в этой ассоциации. Один и тот же классификатор может играть несколько ролей, которые не являются взаимозаменяемыми. Каждый полюс ассоциации описывает свойства, применимые к конкретному объекту этой ассоциации, например сколько раз один объект может появляться в связях (множественность). Некоторые свойства (такие как допустимость навигации) применимы только к бинарным ассоциациям, хотя большинство свойств относится и к бинарным, и к n-арным ассоциациям;

- обобщение (Generalization) — это отношение специализации/обобщения, при котором объекты специализированного элемента (потомка — Child) можно подставить вместо объектов обобщенного элемента (родителя, предка — Parent). В случае обобщения классов прямой предок может именоваться суперклассом, а прямой потомок — подклассом;

- реализация (Realization) — отношение между спецификацией и ее программной реализацией; указание на то, что поведение наследуется без структуры.

Виды диаграмм

UML 1.5 определял двенадцать типов диаграмм, разделенных на три группы:

- четыре типа диаграмм представляют статическую структуру приложения;

- пять представляют поведенческие аспекты системы;

- три представляют физические аспекты функционирования системы (диаграммы реализации).

Итак, мы кратко рассмотрим такие виды диаграмм, как:

- диаграмма прецедентов;

- диаграмма классов;

- диаграмма объектов;

- диаграмма последовательностей;

- диаграмма взаимодействия;

- диаграмма состояний;

- диаграмма активности;

- диаграмма развертывания.

 

Язык моделирования 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 предоставляет средства отображения требований к системе, построения документации, тестов, моделирования необходимых действий для планирования проекта и для управления поставленными конечному пользователю релизами.

 

Диаграмма классов

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

Рисунок 1 – Диаграмма классов

 

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

 

Диаграмма прецедентов

 

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

- внешние пользователи – физические объекты разной природы (от людей и механизмов до программных средств), которые передают или получают информацию для системы;

- блоки использования – группы функций системы, которые объединяются в единое целое для внешнего пользователя;

- связи между блоками использования и связи между блоками использования и внешними пользователями.

Рисунок 2 - Диаграмма прецедентов

 

В дальнейшей работе используем прецеденты данной диаграммы в качестве рассматриваемых частей системы для построения других диаграмм.

 

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

Диаграммы деятельности (рисунок 4) показывают выполнение операций. Предназначение данной диаграммы – показать поток управления, внутренний для операции. Диаграмма действий разделена на 2 полосы, которые включают в себя определенный набор действий и переходов. Каждая полоса имеет свое имя: клиент и менеджер по продажам, и тем самым позволяет группировать действия в единое целое. Графически каждая полоса представляет собой вертикальное разделение диаграммы с помощью сплошной полосы. Каждое действие может находиться только в одной полосе, а переходы могут пересекать полосы.

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

 

Действие изображается в виде овала. Внутри него можно написать выражение.

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

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

Диаграмма состояний

Каждая диаграмма состояний в UML описывает все возможные состояния одного экземпляра определенного класса и возможные последовательности его переходов из одного состояния в другое, то есть моделирует все изменения состояний объекта как его реакцию на внешние воздействия.

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

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

Рисунок 5 - Диаграмма состояний

 

Диаграмма коопераций

 

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

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

Рисунок 6 – Диаграмма коопераций

 

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

Заключение

 

В процессе проектирования информационной системы я подробно изучил сферу данной области.

В ходе работы было использовано 6 видов диаграмм:

- Диаграмма классов

- Диаграмма прецедентов

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

- Диаграмма деятельности

- Диаграмма состояний

- Диаграмма коопераций

В своей работе я использовал CASE средство проектирования и разработки информационной системы ArgoUML.

 

 

Приложение А

(обязательное)

Листинг классов

//

// Generated by ARGOUML(tm) C++ Add-In

//

// @ Project: Untitled

// @ File Name: System.cpp

// @ Author:

//

//

#include "System.h"

void Zakazi::otkrit() {

}

void Zakazi::udalit() {

}

void Zakazi::redaktir() {

}

void Zakazi::peremestitVArchiv() {

}

 

//

//

// Generated by ARGOUML(tm) C++ Add-In

//

// @ Project: Untitled

// @ File Name: Admin.h

// @ Author:

//

//

 

 

#if!defined(_Polzovatel_h)

#define _ Polzovatel _H

class Polzovatel {

public:

segunnedint nom;

unsignedintnom_CHS;

unsignedintnom_shema;

unsigned short vremya;

stringtip_name;

stringpunkt_slyshba;

stringpunkt_status;

voidotkrit()

voidudalit()

voidredaktir();

#endif

//

//

//

// @ Project: Untitled

// @ File Name: MestoCHS.h

// @ Author:

//

//

#if!defined(_MestoCHS _H)

#define _ MestoCHS _H

classMestoCHS {

public:

unsigned short name;

};

#endif //

//

//

//

// @ Project: Untitled

// @ File Name: Status.cpp

// @ Author:

//

//

#include " Status.h"

void Status::ustanovka() {

}

#if!defined(_Status _H)

#define _ Status _H

class Status {

public:

unsignedintnom_name;

voidystanovka();

};

#endif //

#if!defined(_slushba_H)

#define _ slushba _H

class slushba {

public:

string name;

 

};

#endif //_

#include "Stansiya.h"

#if!defined(_Stansiya _H)

#define _ Stansiya _H

class Stansiya {

public:

string name;

segunnedint ID;

};

#endif //_

//

//

// @ Project: Untitled

// @ File Name: Peregon.cpp

// @ Author:

//

//

#include " Peregon.h"

 

//

//

// @ Project: Untitled

// @ File Name: Admin.h

// @ Author:

//

//

#if!defined(_Admin_H)

#define _ Admin _H

 

 

class Admin {

public:

string fam;

string imya;

string otchestvo;

unsignedintntel;

 

};

#endif //

 

 

 

Введение

 

Согласно заданию, целью данной работы является разработка модели информационной системы на основе унифицированного языка моделирования UML. Рассмотрим, что представляет собой язык UML.

UML - это язык для визуализации, специфицирования, конструирования и документирования артефактов программных систем.

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

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

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

Язык UML предназначен, прежде всего, для разработки программных систем. Его использование особенно эффективно в следующих областях:

- информационные системы масштаба предприятия;

- банковские и финансовые услуги;

- телекоммуникации;

- транспорт;

- оборонная промышленность, авиация и космонавтика;

- розничная торговля;

- медицинская электроника;

- наука;

- распределенные Web-системы.

Для создания модели и получения программного кода, решено использовать прикладное программное обеспечение – CASE-средство Argo UML.

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

 

 

 

1 Техническое задание

Основание для разработки

 

Основанием создания данной программы послужило задание на курсовую работу, выданное доцентом кафедры «ВТ и АСУ» Юренко К.И. и утвержденное зав. кафедрой «ВТ и АСУ» Черновым А. В.

 

1.2 Назначение разработки, исходные данные

 

Проектирование информационной системы «Интернет-магазин бытовой техники» на основе объектно-ориентированного подхода с использованием унифицированного языка моделирования UML.

 

Требования к проекту

Требования к фундаментальным характеристикам

 

Проект должен соответствовать исходному заданию и выполняться при помощи CASE-средства проектирования и разработки информационных систем ArgoUML.

 

Требования к надежности

 

Проект должен соответствовать максимальным требованиям к надёжности. Исключаются ошибки различного рода.

 

Требования к составу и параметрам технических средств

 

ПК пользователя должен удовлетворять следующим требованиям:

− процессор IntelPentium 1 ГГц;

− объем оперативной памяти -1 Гб;

− дисковая подсистема -16 Гб.

Требования к информационной и программной совместимости

 

Данный программный продукт должен быть совместим операционными системами Windows 2000/XP/Vista/7/8/10.

 

Требования к маркировке и упаковке

 

Требований к упаковке и маркировке не требуется.

 

Требования к транспортированию и хранению

 

Транспортировка и хранение проекта могут быть произведены на любом носителе информации.

 

Теоретические сведения

2.1 Основные понятия и определения

 

Унифицированный язык моделирования (UML, UnifiedModelingLanguage) является преемником методов объектно-ориентированного анализа и проектирования, которые появились в конце 80-х и начале 90-х годов.

Первое упоминание об унифицированном методе (UnifiedMethod) версии 0.8 появилось в 1995 году на конференции OOPSLA ’95. Данный метод был предложен ГрадиБучом и Джимом Рамбо. В дальнейшем к ним присоединился Айвар Якобсон и в течение 1996 года Г. Буч, Д. Рамбо, А. Якобсон, получившие широкую известность как «трое друзей» (amigos) продолжали работа над своим методом, который к тому времени получил название унифицированный язык моделирования (UML). Однако помимо данного метода сообществом разработчиком были предложены и другие методы. Для стандартизации этих методов в рамках OMG (ObjectManagementGroup) была сформирована инициативная группа. В результате работы группы появилась версия языка UML.

Текущей версией языка UML является версия 1.5, также ведется работа над спецификацией языка UML версии 2.0.

UML – это название языка моделирования, но не метода. Следует различать эти понятия. Большинство методов включают в себя помимо языка моделирования процесс. Язык моделирования – это нотация (главным образом графическая), которая используется разработчиками для описания проекта. Процесс – это рекомендация относительно этапов, которых необходимо придерживаться при выполнении проекта.

Основными элементами UML являются сущности (Thing), отношения (Relationship), диаграммы (Diagram). Сущности являются ключевыми абстракциями языка, отношения связывают сущности вместе, диаграммы группируют коллекции сущностей, которые представляют интерес.

 

 

Структурные сущности являются существительными языка. К ним относятся:

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

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

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

- прецеденты (Usecase) — описание набора последовательностей действий, которые выполняются системой и имеют значение для конкретного действующего лица (Actor). Прецеденты изображаются в виде эллипса и используются для структурирования поведенческих сущностей в модели;

- активные классы (Activeclass) — это классы, чьими экземплярами являются активные объекты, которые владеют процессом или потоком управления и могут инициировать управляющее воздействие. Стереотипами конкретного класса являются процесс (Process) и поток (Thread). Графически такой класс изображается как класс с жирной границей;

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

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

Поведенческие сущности — это динамические части моделей UML. К ним относятся:

- взаимодействия (Interaction) — включают набор сообщений, которыми обмениваются указанные объекты с целью достижения указанной цели. Взаимодействие описывается в контексте кооперации и изображается направленной линией, маркируется именем операции сверху;

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

К базовым отношениям между объектами, которые позволяют строить блоки UML, можно отнести следующие:

- зависимость (Dependency) — это семантическое отношение между двумя сущностями, при котором изменение одной из них (независимой сущности) может отразиться на семантике другой (зависимой).

- ассоциация (Association) — структурное отношение, описывающее множество связей между объектами классификаторов, где связь (Link) — это соединение между объектами, которое описывает связи между их экземплярами. Ассоциации являются как бы клеем, который связывает систему воедино. Без ассоциаций мы имели бы просто некоторое количество классов, не способных взаимодействовать друг с другом. У ассоциации может быть имя, однако основную информацию об ассоциации следует искать у ее полюсов, где описывается, каким образом каждый объект участвует в ассоциации: у ассоциации есть список, состоящий из двух или более полюсов ассоциации: каждый из них определяет роль, которую играет данный классификатор в этой ассоциации. Один и тот же классификатор может играть несколько ролей, которые не являются взаимозаменяемыми. Каждый полюс ассоциации описывает свойства, применимые к конкретному объекту этой ассоциации, например сколько раз один объект может появляться в связях (множественность). Некоторые свойства (такие как допустимость навигации) применимы только к бинарным ассоциациям, хотя большинство свойств относится и к бинарным, и к n-арным ассоциациям;

- обобщение (Generalization) — это отношение специализации/обобщения, при котором объекты специализированного элемента (потомка — Child) можно подставить вместо объектов обобщенного элемента (родителя, предка — Parent). В случае обобщения классов прямой предок может именоваться суперклассом, а прямой потомок — подклассом;

- реализация (Realization) — отношение между спецификацией и ее программной реализацией; указание на то, что поведение наследуется без структуры.

Виды диаграмм

UML 1.5 определял двенадцать типов диаграмм, разделенных на три группы:

- четыре типа диаграмм представляют статическую структуру приложения;

- пять представляют поведенческие аспекты системы;

- три представляют физические аспекты функционирования системы (диаграммы реализации).

Итак, мы кратко рассмотрим такие виды диаграмм, как:

- диаграмма прецедентов;

- диаграмма классов;

- диаграмма объектов;

- диаграмма последовательностей;

- диаграмма взаимодействия;

- диаграмма состояний;

- диаграмма активности;

- диаграмма развертывания.

 

Язык моделирования 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 предоставляет средства отображения требований к системе, построения документации, тестов, моделирования необходимых действий для планирования проекта и для управления поставленными конечному пользователю релизами.

 

Программный инструмент моделирования ArgoUML

 

ArgoUML — средство UML моделирования (UnifiedModelingLanguage(UML) - унифицированный язык визуального моделирования бизнес-процессов). ArgoUML является открытым программным обеспечением и распространяется под лицензией BSD. ArgoUML полностью написан на Java и для работы ему подходит любая операционная система с установленной Java 2 JRE или JDK версии 1.4 или выше.

Функциональность ArgoUML включает в себя:

· Поддержку спецификаций UML 1.3, 1.4, XMI 1.0, 1.1, 1.2

· 9 видов диаграмм UML (диаграммы классов, состояний, кооперации, последовательности, деятельности, прецедентов, объектов, компонентов, развёртывания).

· Поддержку OCL для классов Генерацию исходного кода Java, C++, C# и PHP

· Обратный инжиниринг из исходного кода и байткодаJava<