Star UML

StarUML – программный инструмент моделирования, который поддерживает UML (Унифицированный язык моделирования). StarUML ориентирован на UML версии 1.4 и поддерживает одиннадцать различных типов диаграмм, принятых в нотации UML 2.0. Он активно поддерживает подход MDA (Модельно-управляемая архитектура), реализуя концепцию профилей UML. Среда разработки StarUML ™ превосходно настраивается в соответствии с требованиями пользователя и имеет высокую степень расширяемости, особенно в области своих функциональных возможностей. Использование StarUML, одного из ведущих программных инструментов моделирования, гарантирует достижение максимальной производительности и качества ваших программных проектов.

• Диаграмма классов (Сlass diagram). Диаграмма классов – визуальное отображение различных статических отношений между класс-подобными элементами. Диаграмма классов может содержать не только классы, но также и интерфейсы, перечислимые типы, пакеты, различные отношения, инстанции и их связи.

• Диаграмма прецедентов (Use case diagram). Диаграмма прецедентов – отображение отношений между вариантами использования (прецедентами) определенной системы или объекта и внешними акторами. Вариант использования отображает функции системы и то, как эти функции взаимодействуют с внешними акторами.

• Диаграмма последовательности (Sequence Diagram). Диаграмма последовательности отображает взаимодействие инстанций. Она является прямым отображением множества взаимных воздействий (InteractionInstanceSet) между элементами множества инстанций (CollaborationInstanceSet). В то время как Диаграмма сообщений роли ориентирована на классификаторы-роли, обычная Диаграмма сообщений – на инстанции.

• Диаграмма сообщений роли (Sequence Role Diagram). Диаграмма сообщений роли отображает взаимодействия в концепции ролей. Она является прямым отображением Interaction (множества взаимных сообщений между классификаторами-ролями) в пределах Collaboration. В то время как Диаграмма сообщений – отображение инстанций, Диаграмма сообщений роли – отображение классификаторов-ролей.

• Диаграмма коллаборации (Collaboration Diagram). Диаграмма коллаборации отображает взаимодействие между инстанциями. Она является прямым отображением модели взаимодействия инстанций, входящих в CollaborationInstanceSet. В то время как диаграмма коллаборации ролей – отображение классификаторов-ролей, обычная диаграмма коллаборации – отображение инстанций.

• Диаграмма коллаборации ролей. Диаграмма коллаборации ролей отображает взаимодействия между ролями. Она является прямым отображением модели взаимодействия классификаторов-ролей внутри коллаборации. В то время как обычная диаграмма коллаборации ориентирована на отображение инстанций, диаграмма коллаборации ролей – отображение классификаторов-ролей.

• Диаграмма состояний (Statechart Diagram). Диаграмма состояний выражает статическое поведение определенного объекта через состояния и переходы состояний. Хотя диаграмма состояний обычно используется, чтобы выразить поведение инстанций классов, она может также использоваться, чтобы выражать поведение и других элементов.

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

• Диаграмма компонентов (Component Diagram). Диаграмма компонентов отображает зависимость между программными компонентами. Элементы, которые составляют программные компоненты и элементы, которые реализуют эти компоненты, могут быть отображены на диаграмме компонентов.

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

• Композиционная структурная диаграмма (Composite Structure Diagram). Композиционная структурная диаграмма – диаграмма, выражающая внутреннюю структуру классификатора. Она показывает его точки зрения взаимодействия с другими частями системы.

BPWin

На начальных этапах создания ИС необходимо понять, как работает организация, которую собираются автоматизировать. Никто в организации не знает, как она работает в той мере подробности, которая необходима для создания ИС. Руководитель хорошо знает работу в целом, но не в состоянии вникнуть в детали работы каждого рядового сотрудника. Рядовой сотрудник хорошо знает, что творится на его рабочем месте, но плохо знает, как работают коллеги. Поэтому для описания работы предприятия необходимо построить модель. Такая модель должна быть адекватна предметной области, следовательно, она должна содержать в себе знания всех участников бизнес-процессов организации. Наиболее удобным языком моделирования бизнес-процессов является IDEFO.

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

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

Модель может содержать четыре типа диаграмм:

- контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);

- диаграммы декомпозиции;

- диаграммы дерева узлов;

- диаграммы только для экспозиции (FEO).

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

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

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

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