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

1 Обозначения в стандарте IDEF0 при построении схем бизнес – процессов. 1

2 Обозначения при построении диаграмм потоков данных (DFD) 2

3 Обозначения в стандарте UML.. 3

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

3.2 Концептуальная модель предметной области: диаграмма концептуальных классов. 4

3.3 Модель проектирования: диаграмма классов проектирования. 5

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

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

3.6 Диаграмма взаимодействия. 6

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

3.6.2 Диаграмма кооперации. 7

3.7 Диаграмма компонентов. 8

3.8 Диаграмма развертывания. 9

4 Обозначения в стандарте IDEF1X, используемые при построении логической модели реляционной базы данных. 9

5 Обозначения в стандарте ARIS EEPC.. 10

6 Литература. 11

1 Обозначения в стандарте IDEF0 при построении схем бизнес – процессов

Стандарт IDEF0 (Integrated computer aided manufacturing DEFinition) используется для описания бизнес процессов исследуемой предметной области или проектируемой системы. Данный стандарт использует методику SADT (Structured Analysis & Design Technique): основными структурными методами любой модели бизнес – процесса являются деятельность или «работа», которая представляет собой некое действие или набор действий, приводящих к определенному результату и

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

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

НЕ нашли? Не то? Что вы ищете?

«AS-IS» означает то, что строится диаграмма бизнес – процесса, который имеет место в настоящее время, а не того, который должен происходить после внедрения программной системы.

“TO-BE” - диаграмма бизнес – процесса, который будет происходить после внедрения программной системы.

На Рис. 1 показан элемент диаграммы в стандарте IDEF0. Прямоугольник обозначает отдельный вид деятельности в рамках описания бизнес – процесса – «работу». Для стрелок используются следующие роли (ICOM):

· Вход (Input) – внешняя информация, которая используется при выполнении операции. Стрелка входит в левую грань «работы».

· Управление (Control) – правила, стратегии, процедуры или стандарты, которыми руководствуются при выполнении операции. Стрелка входит в верхнюю грань «работы».

· Выход (Output) – информационные данные, которые получаются при выполнении операции, стрелка выходит из правой грани «работы».

· Механизм (Mechanism) – исполнитель операции или программное обеспечение, используемое для выполнения операции. Стрелка входит в нижнюю грань «работы».

Рис. 1 Типы стрелок в стандарте IDEF0.

2 Обозначения при построении диаграмм потоков данных (DFD)

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

Условные обозначения приведены в Табл. 1.

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

Табл. 1 Условные обозначения для DFD диаграмм.

3 Обозначения в стандарте UML

UML (Unified Modeling Language) – унифицированный язык моделирования, который предназначен для описания, визуализации и документирования обьектно – ориентированных систем и бизнес – процессов с ориентацией на их последующую реализацию в виде программного обеспечения.

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

Элемент диаграммы	Описание
	Пакет. Кроме наименования пакета на диаграмму также может помещаться краткое описание данного пакета.
	Вложенные пакеты.
	Отношение зависимости между пакетами. Стрелка направлена к независимому пакету.
	Примечание

Табл. 2 Обозначения пакетов.

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

Диаграмма прецедентов (Use Case Diagram) является исходным концептуальным представлением системы, описывает функциональное назначение системы, отображает границы системы и внешние для системы понятия.

Некоторые обозначения UML, которые использовались при построении диаграмм вариантов использования приведены в Табл. 3.

Элемент диаграммы	Описание
	Исполнитель (Actor) - любая внешняя по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для решения определенных задач
	Вариант использования (Use Case) - используется для спецификации общих особенностей поведения системы или любой другой сущности предметной области без рассмотрения внутренней структуры этой сущности Каждый вариант использования определяет последовательность действий, которые должны быть выполнены проектируемой системой при взаимодействии ее с соответствующим исполнителем.
	Отношение ассоциации - служит для обозначения специфической роли исполнителя в отдельном варианте использования.
	Отношение включения - некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования.
	Отношение расширения – один из вариантов использования может присоединить к своему поведению некоторое дополнительное поведение, определенное для другого варианта использования.
	Отношение обобщения – некоторый вариант использования может быть обобщен до другого варианта использования, стрелка указывает на родительский вариант использования.
	Примечание

Табл. 3 Некоторые обозначения диаграммы вариантов использования.

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

Концептуальная модель предметной области - визуализация реальных понятий из предметной области (визуальный словарь предметной области). Концептуальный класс – представление объекта или идеи предметной области (это не программный класс). Некоторые обозначения, которые используются при построении диаграммы концептуальных классов: перечислены в Табл. 4.

Элемент диаграммы	Описание
	Концептуальный класс – обозначение для множества объектов предметной области, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов.
	Абстрактный класс – не имеет экземпляров. Имя Абстрактного класса выделяется курсивом.
	Отношение зависимости. Стрелка направлена от Класса – клиента зависимости к Независимому классу.
	Отношение ассоциации. Цифры обозначают кратность. Для приведенного примера: в Компании работает от 1 до n сотрудников, но каждый Сотрудник работает только в одной Копании. Однонаправленная ассоциация обозначается сплошной стрелкой.
	Отношение агрегации. Служит для выделения специальной формы отношения «часть – целое». Ромб указывает на Класс – целое.
	Направленная агрегация, стрелка указывает на объект, которому «передается» действие.
	Отношение обобщения. Класс – потомок обладает всеми свойствами и поведением класса – предка, а также, имеет свои собственные свойства и поведение, которые отсутствуют у класса – предка. Стрелка указывает на класс – предок.
	Примечание.

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

Модель проектирования: диаграмма классов проектирования

Модель проектирования строится в аспекте спецификации, она описывает программные абстракции или компоненты со своими спецификациями и интерфейсами, однако без привязки к конкретной реализации (например, без конкретного соответствия какому-либо языку программирования). В Табл. 5 приведено обозначение для класса проектирования. Все остальные обозначения в диаграмме классов проектирования для отношений и абстрактного класса совпадают с обозначениями в Табл. 4.

Элемент диаграммы

Описание

Класс проектирования (программный класс) – программная сущность, представляющая спецификацию или реализацию программного компонента.

Описание атрибута

<видимость><имя атрибута>: <тип атрибута> = <исходное значение>, где Атрибут1 - закрытый (private, Атрибут 2 – общедоступный (public), Атрибут3 - защищенный (protected).

Описание операции

< видимость><имя операции>(список параметров):

<выражение типа возвращаемого значения>.

Для приведенного примера:

Атрибут1 – закрытый (private).

Атрибут2 – общедоступный (public),

Атрибут3 – защищенный (protected);

Операция1 - общедоступная (public),

Операция2 - защищенная (protected),

Операция3 - закрытая (private).

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

Табл. 5 Обозначения диаграммы классов проектирования.

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

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

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

Табл. 6 Обозначения диаграммы состояний.

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

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

Элемент диаграммы	Описание
	Состояние действия – частный случай состояния с некоторым входным действием и по крайней мере одним выходящим из состояния переходом. Состояние действия считается элементарным.
	Переход.
	Конечное состояние.
	Начальное состояние.
	Точка ветвления, сторожевое условие (булево выражение) записывается в квадратных скобках над соответствующим переходом
	Раздел или слияние.
	Примечание.

Табл. 7 Обозначения диаграммы деятельности.

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

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

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

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

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

Элемент диаграммы	Описание
	Объект – отдельный экземпляр класса, который создается на этапе выполнения программы.
	Линия жизни объекта – пунктирная линия, которая показывает то время, в течение которого объект существует в системе и может потенциально участвовать во всех ее взаимодействиях.
	Фокус управления - обозначает то, что объект находится в активном состоянии, непосредственно выполняя определенные действия.
	Сообщение – вызов процедур, выполнение операций или отдельные вложенные потоки управления.
	Асинхронное сообщение - простой, не вложенный поток управления. Каждая такая стрелка указывает на прогресс одного шага потока.
	Асинхронное сообщение между двумя объектами в некоторой процедурной последовательности.
	Сообщение – возврат из вызова процедуры.
	Сообщение, передаваемое объектом самому себе.
	Символ уничтожения объекта. Ниже этого символа линия жизни объекта не изображается.
	Примечание.

Табл. 8 Обозначения диаграммы последовательности.

При построении диаграмм последовательности используются следующие виды (стереотипы) сообщений:

- ”call” - сообщение, требующее вызова операции или процедуры принимающего объекта,

- “return” – сообщение, возвращающее значение выполненной операции или процедуры вызвавшему ее объекту,

- “create” – сообщение, требующее создания другого объекта для выполнения определенных действий,

- “destroy” – сообщение с явным требованием уничтожить соответствующий объект,

- “send” – обозначает посылку другому объекту некоторого сигнала, который асинхронно инициируется одним объектом и принимается другим.

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

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

Условные обозначения, использованные при построении диаграмм кооперации, перечислены в Табл. 9.

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

Табл. 9 Обозначения диаграммы кооперации.

При построении диаграммы кооперации используются следующие виды (стереотипы) связей:

- association” – ассоциация (предполагается по умолчанию),

- “parameter” – параметр метода, соответствующий объект может быть только параметром некоторого метода,

- “local” - локальная переменная метода, ее область видимости ограничена только соседним объектом,

- “global” – глобальная переменная, ее область видимости распространяется на всю диаграмму кооперации,

- “self” - рефлексивная связь объекта с самим собой, которая допускает передачу объектом сообщения самому себе.

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

Диаграмма компонентов представляет состав и зависимости между компонентами программной системы. Компонент реализует некоторый набор интерфейсов и служит для общего обозначения элементов физического представления модели. Различают следующие виды компонентов:

- компоненты развертывания – обеспечивают непосредственное выполнение системой своих функций (например, динамически подключаемые библиотеки с расширением «dll», web – страницы с расширением «html» файлы справки с расширением «hlp» и т. д.).

- компоненты, которые представляют собой файлы с исходными текстами на языке программирования высокого уровня, «белые компоненты»,

-компоненты исполнения, исполняемые модули с расширение «exe».

В языке UMLопределены следующие основные виды (стереотипы) компонентов:

-Библиотека – динамическая или статическая библиотека,

- Таблица – таблица базы данных,

-Файл – файл с исходным текстом программы,

-Документ,

- Исполняемый компонент.

Условные обозначения, использованные при построении диаграмм компонентов, перечислены в Табл. 10.

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

Табл. 10 Обозначения диаграммы компонентов.

Диаграмма развертывания

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

Условные обозначения, использованные при построении диаграмм развертывания, перечислены в Табл. 11.

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

Табл. 11 Обозначения диаграммы развертывания.

4 Обозначения в стандарте IDEF1X, используемые при построении логической модели реляционной базы данных

IDEF1X (Integration DEFinition for Information Modeling) является методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схем данных, то есть универсальное представление структуры данных, независимое от конечной реализации базы данных и аппаратной платформы. Возможны два уровня модели в стандарте IDEF1X. Первый - логический описывает данные, задействованные в бизнес – процессе, является универсальным представлением данных и никак не связан с конкретной СУБД (Системой управления Базами Данных). Второй - физический - определяет представление информации в базе данных, зависит от конкретной СУБД. В физическом уровне модели могут содержаться все объекты базы данных. Использование метода IDEF1X наиболее целесообразно для построения логической структуры базы данных после того, как все информационные ресурсы исследованы и решение о внедрении реляционной базы данных как части корпоративной информационной системы, было принято. Обозначения, используемые в логической модели, приведены в Табл. 12.

Элемент диаграммы	Описание
	Сущность - это (в рамках стандарта IDEF1X) множество индивидуальных объектов - экземпляров, причем все эти объекты являются различными. Экземпляры независимой сущности (верхний рисунок) могут быть уникально идентифицированы без определения ее связей с другими сущностями; зависимая сущность, наоборот, не может быть уникально идентифицирована без определения ее связей с другими сущностями. Зависимая сущность отображается прямоугольником с закругленными углами (нижний рисунок). Каждая сущность обладает атрибутами. Атрибут - это свойство объекта, характеризующее его экземпляр. Первичный ключ - это атрибут или набор атрибутов, уникально идентифицирующий экземпляр сущности. Атрибуты первичного ключа располагаются над линией в ключевой области. Как следует из названия, неключевой атрибут - это атрибут, который не был выбран ключевым. Неключевые атрибуты располагаются под чертой, в области данных.
	Идентифицирующая связь. Связь - это функциональная зависимость между сущностями. Связь называется идентифицирующей, если экземпляр дочерней сущности идентифицируется через ее связь с родительской сущностью. Атрибуты, составляющие первичный ключ родительской сущности, при этом входят в первичный ключ дочерней сущности. Дочерняя сущность при идентифицирующей связи всегда является зависимой.
	Неидентифицирующая связь. Связь называется неидентифицирующей, если экземпляр дочерней сущности идентифицируется иначе, чем через связь с родительской сущностью. Атрибуты, составляющие первичный ключ родительской сущности, при этом входят в состав неключевых атрибутов дочерней сущности. Допустимость пустых (NULL) значений в неидентифицирующих связей ERwin изображает пустым ромбиком на дуге связи со стороны родительской сущности (верхний рисунок).

Табл. 12 Некоторые обозначения в стандарте IDEF1X (логическая модель).

5 Обозначения в стандарте ARIS EEPC

EEPC (Extended Event Driven Process Chain) – расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия). В Табл. 13 приводятся основные используемые в рамках нотации eEPC объекты.

Элемент	Описание
	Объект «Функция» служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия.
	Объект «Событие» служит для описания реальных состояний системы, влияющих и управляющих выполнением функций
	Объект, отражающий различные организационные звенья предприятия (например, управление или отдел)
	Объект, отражающий реальные носители информации, например бумажный документ
	Объект отражает реальную прикладную систему, используемую в рамках технологии выполнения функции
	Объект описывает тип отношений между другими объектами, например – активацию выполнения функции некоторым событием
	Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Оператор «И».
	Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Оператор исключающее «ИЛИ».
	Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Оператор «ИЛИ».