Понятия проекта и объекта проектирования. (№1 -- 1 к.р.)

Проект можно понимать в нескольких смыслах. Основной смысл, который будет использован в данном предмете -- то, что это совокупность документов: расчетов, чертежей, схем, спецификаций, регламентов для создания какого-либо сооружения или изделия. Второе значение -- это замысел, план, прототип какого-либо объекта. Третье значение -- проект-документ: проект закона, проект ТЗ и т.д. Объект проектирования -- можно рассматривать его как то, над чем совершается процесс проектирования, и то, что изучает дисциплина проектирования.

В качестве объекта проектирования могут выступать:

-предвидимый объект,

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

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

-развивающаяся модель будущего,

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

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

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

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

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

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

Определения проектирования (процесса проектирования). (№2 -- 1 к.р.)

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

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

для подготовки к реализации и тестированию системы.

Проектирование - вид целенаправленной деятельности человека (или коллектива специалистов) по решению задач проектирования, направленной на создание устройств

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

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

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

Основные проблемы проектирования. (№3 -- 1 к.р.)

Основные проблемы проектирования:

-определение задач проектирования.

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

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

-определение логической схемы проектирования (методологии проектирования).

-непосредственное решение задач проектирования -- получение проектных решений с определенными характеристиками качества.

-решение проблем конкретной реализации поставленных задач

-сравнение полученных характеристик качества с заданными характеристиками и определение отклонений.

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

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

Понятие автоматизированной информационной системы. (№4 -- 1 к.р.)

1. Автоматизированная информационная система — совокупность информации, экономико-математических методов и моделей, технических, программных, технологических средств и специалистов, предназначенная для обработки информации и принятия управленческих решений.

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

В целом АИС можно рассматривать как человеко-машинную систему с автоматизированной технологией получения результатной информации, необходимой для информационного обеспечения персонала и оптимизации процесса управления в предметной деятельности.

Перед началом проектирования АИС необходимо детально обосновать необходимость ее создания, подробно описать цели и задачи проекта, ожидаемую прибыль, временные затраты, доступные ресурсы, ограничения и т. д. Необходимость разработки любой АИС может быть обусловлена следующими факторами:    • ростом значимости информационной среды предприятия;    • комплексностью системы управления предприятием;    • необходимостью анализа потенциальных возможностей и опасностей предприятия;    • необходимостью систематизации деятельности предприятия;    • необходимостью постоянного повышения эффективности использования основных фондов предприятия, улучшения соотношения цены и качества;    • повышением роли капиталовложений в сферу информатизации предприятия;    • необходимостью кадрового планирования для адекватного обеспечения развития предприятия;    • ростом сложности и комплектности существующих ИС, влекущим за собой усложнение функциональных требований к ИС и их развитию.   Разработка и внедрение любой АИС осуществляется в определенной последовательности в соответствии с техническим заданием. Содержание первой очереди управленческой системы определяется составом задач учета, анализа, планирования и оперативного управления, наиболее поддающихся автоматизации и имеющих существенное значение для принятия управленческих решений в организации. В процессе разработки последующих очередей системы происходит расширение и интеграция информационного, программного и математического обеспечения, модернизация технических средств.    Жизненный цикл АИС позволяет выделить четыре основных периода: предпроектный, проектный, внедрение, эксплуатация и сопровождение [23].    Технология проектирования автоматизированных информационных систем в настоящее время определяется действующим ГОСТ 34.601—90, согласно которому весь процесс разбит на стадии и этапы [2].    1. Стадия «Формирование требований к АИС»:    • определение объема обоснования, необходимого для создания АИС (сбор данных об объекте автоматизации и осуществляемых видах деятельности, оценка качества его функционирования, выявление проблем, решение которых возможно средствами автоматизации, оценка целесообразности создания АИС);    • формирование требований пользователя к АИС;    • оформление отчета о выполненных работах и подача заявки на разработку АИС.    2. Стадия «Разработка концепции АИС»:    • изучение объекта АИС;    • проведение необходимых исследовательских и проектных работ;    • разработка вариантной концепции АИС и выбор варианта, который удовлетворяет требованиям пользователя, оценка преимуществ и недостатков альтернативных вариантов;    • оформление отчета о выполненной работе.    3. Стадия «Техническое задание»:    • разработка и оформление технического задания на создание АИС (общие сведения, назначение и цели создаваемой системы, характеристика объекта автоматизации, требования к системе в целом, ее функциям и задачам, видам обеспечения, планам работ по созданию, вводу в действие и приемке).    4. Стадия «Эскизный проект»:    • разработка предварительных проектных решений по системе и ее частям (функции АИС, ее подсистемы, состав задач, концепция и структура информационной базы, состав и основные характеристики технических средств);    • разработка документации на АИС и ее элементы.    5. Стадия «Технический проект»:    • разработка проекта решений по системе и ее элементам, по функциональной, алгоритмической и организационной структуре системы, структуре технических средств, организации и ведения базы данных, по системе классификации и кодирования информации, алгоритму решения задач, используемым языкам программирования и программному обеспечению;    • разработка документов АИС;    • разработка и оформление документации на поставку изделий для комплектования АИС и технических требований на их разработку;    • разработка заданий на проектирование.    6. Стадия «Рабочее проектирование»:    • разработка рабочей документации на систему и ее части;    • разработка или адаптация программ.    7. Стадия «Ввод в действие»:    • подготовка АИС к внедрению;    • сдача задач и подсистем в опытную эксплуатацию;    • составление отчета о вводе в действие.    8. Стадия «Сопровождение АИС»:    • анализ функционирования системы;    • авторский надзор.    Особенность разработки АИС заключается в концентрации сложности и трудоемкости на стадиях предпроектного обследования, так как ошибки, допущенные на этапах обследования, анализа и проектирования, порождают на этапах внедрения и эксплуатации часто неразрешимые проблемы достижения поставленных целей и эффективности использования АИС [32].    Формирование требований к системе подразумевает определение ее функциональных возможностей, пользовательских требований, требований к надежности и безопасности, к внешним интерфейсам и т. д. [26].    Планирование работ включает предварительную экономическую оценку проекта, построение плана-графика выполнения работ, создание и обучение совместной рабочей группы. На этом этапе осуществляется системный анализ рассматриваемой системы, который включает в себя описание структуры элементов системы и проведение обследования деятельности автоматизируемого объекта; анализ распределения функций по подразделениям и сотрудникам, информационных потоков внутри подразделений и между ними, внешних по отношению к организации объектов и внешних информационных взаимодействий.    Анализ завершается построением моделей деятельности организации, предусматривающих обработку материалов обследования и построения функциональных и информационных моделей двух видов:    • модели «as is» («как есть»), отражающей существующее положение дел в организации;      • модели «to be» («как должно быть»), отражающей представление о новых технологиях и бизнес-процессах организации.

Роли аналитика и продавца в процессе проектирования ПО. Содержание и результаты деятельности аналитика. (№5 -- 1 к.р.)

Анализ является первым этапом создания АСОИУ, на котором требования

заказчика уточняются, формализуются и документируются. Фактически на этом

этапе дается ответ на вопрос: «Что должна делать будущая система?». Именно здесь

лежит ключ к успеху всего проекта.

Структурный анализ начинается с исследования того, как организована

система управления предприятием, с обследования функциональной и

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

аналитик на первой стадии анализа строит обобщенную логическую модель

исходной предметной области, отображающую ее функциональную структуру,

особенности основной деятельности и информационное пространство, в котором эта

деятельность осуществляется. Используя специальную терминологию, можно

сказать, что аналитик строит модель «как есть».

Вторая стадия работы, к которой привлекаются заинтересованные

представители заказчика, а при необходимости и независимые эксперты, состоит в

анализе модели «как есть», выявлении ее недостатков и узких мест, определение

путей совершенствования системы управления на основе выделенных критериев

качества.

Третья стадия анализа, содержащая элементы проектирования, – создание

усовершенствованной обобщенной логической модели, отображающей

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

автоматизации. Эту модель можно назвать моделью «как надо», т.е. здесь

происходит формализация системы.

Роль проектировщика в процессе проектирования ПО. Содержание и результаты деятельности проектировщика. (№6 -- 1 к.р.)

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

Роли разработчика и тестировщика в процессе проектирования. (№7 -- 1 к.р.)

Ресурсное обеспечение проекта (кадровые, материальные и другие ресурсы).

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

Понятия проблемы, решения и его эффективности. (№8 -- 1 к.р.)

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

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

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

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

1.          технико-экономическое обследование и анализпроизводственно-хозяйственной деятельности объекта  и предметаинформатизации;

2.           содержательная постановка задачи, ориентированной  на рыночные методыхозяйствования и применение СВТ;

3.            определение предметной области;

4.           анализ состава и содержания входной и выходной информации дляприложений.

5.            изучение документации предметной области;

6.            разработка информационно-логической модели;

7.            реализация поставленной задачи;

Нотация ARIS: назначение, основные особенности. (№9 -- 1 к.р.)

ARIS (Architecture of Integrated Information Systems) — методология и тиражируемый программный продукт для моделирования бизнес-процессов организаций.

Любая организация в методологии ARIS рассматривается с четырёх точек зрения: организационной, функциональной, обрабатываемых данных и структуры бизнес-процессов. При этом каждая из этих точек зрения разделяется ещё на три подуровня: описание требований, описание спецификации, описание внедрения. Для описания бизнес-процессов предлагается использовать около 80 типов моделей, каждая из которых принадлежит тому или иному аспекту. ARIS предоставляет визуальный инструментарий для обеспечения наглядности моделей. Также инструментарий поставляется с набором референтных моделей, заранее разработанных для типичных процессов в различных отраслях.

Среди большого количества возможных методов описания можно выделить следующие:

eEPC (англ. extended event-driven process chain) — метод описания процессов;

ERM (англ. entity-relationship model) — модель «сущность-связь» для описания структуры данных;

UML (англ. unified modeling language) — объектно-ориентированный язык моделирования.

Нотация ARIS eEPC относится к классу нотаций work flow (описания потоков работ), которые предназначены для описания деятельности в динамике

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

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

Нотация EPC была разработана в 90х годах XX века. EPC придумал немецкий профессор Вильгельм-Август Шеер в рамках методологии ARIS.

Диаграмма бизнес-процесса в EPC должна начинаться и заканчиваться Событием. За Функцией всегда должно следовать Событие, т.е. выполнение Функции создает некоторое событие (состояние). Документы, организационные звенья, информационные и материальные потоки, элементы информационной системы (программное обеспечение, базы данных) имеют свое графическое обозначение.

Для ветвления процесса используются операторы И, ИЛИ, исключающее ИЛИ.

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

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

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

Нотация ARIS: основные группы элементов. (№10 -- 1 к.р.)

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

Объект — самостоятельная часть методологии, отражающая элемент описываемой предметной области.

Каждый объект:

• имеет уникальное имя;

• принадлежит к определенному типу объектов;

• соединен одной или несколькими связями с другими объектами;

• имеет свое определенное значение в методологии и описывается свойствами,

• определяющими конкретный объект данного типа;

• может использоваться в одной или нескольких типах моделей;

• может создавать свои экземпляры, представленные одним или несколькими символами.

Внешний вид экземпляра объекта может быть изменен в определенных пределах.

Каждый объект моделей ARIS имеет следующие свойства:

• размещение атрибутов {Attribute placements),

• взаимосвязи (Relationships};

• назначение (Assignments);

• местонахождение (Occurrences);

• внешний вид (Object Appearance);

• варианты (Variants);

• управление изменениями (Change Management);

• предложения по улучшениям (Improvement Proposals);

• атрибуты объекта (Attributes).

Объекты классифицируются на:

• структурно-зависимые.

Эти типы объектов определяют общую структуру модели. Конкретный тип модели подразумевает наличие конкретных структурно-зависимых типов объектов;

• структурно-независимые.

Методология ARIS предусматривает возможность описывать объекты более подробно с помощью детализирующих моделей. Такая связь между типом объекта (базовым объектом) и типом модели называется типом детализации.

Нотация BPMN: назначение, основные особенности. (№11 -- 1 к.р.)

Основной целью языка BPMN является обеспечение абсолютно доступной нотацией для описания бизнес-процессов всех бизнес-пользователей: от бизнес-аналитиков, создающих схемы процессов, и разработчиков, ответственных за внедрение технологий выполнения бизнес-процессов, до руководителей и обычных пользователей, управляющих этими бизнес-процессами и отслеживающих их выполнение. Таким образом, BPMN нацелен на устранение расхождения между моделями бизнес-процессов и их реализацией.

, не менее важной целью разработки BPMN, явилось то, что языки XML (например,WSBPEL - Web Services Business Process Execution Language), разработанные для исполнения бизнес-процессов, теперь могут быть визуализированы в графической нотации, понятной обычным бизнес-пользователям.

В данном документе объединены лучшие практические наработки в области бизнес-моделирования. Это было сделано для выбора нотации и семантики диаграммВзаимодействия (Collaboration), Процессов (Process) и Хореографии (Choreography). Предназначение BPMN – стандартизировать модель бизнес-процесса и нотацию перед лицом множества различных нотаций моделирования и точек зрения. Таким образом, благодаря BPMN, бизнес-пользователи, внедренцы, заказчики и поставщики получают простые средства доступа к информации о процессе.

Особенность BPMN:

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

Нотация BPMN: основные группы элементов. (№12 -- 1 к.р.)

Существуют пять основных категорий элементов:

1. Элементы потока (Flow Objects); 

2. Данные (Data) 

3. Соединяющие элементы (Connecting Objects); 

4.  Зоны ответственности (Swimlanes); 

5.  Артефакты (Artifacts).

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

1. События (Events); 

2. Действия (Activities); 

3. Шлюзы (Gateways).

Данные на диаграмме могут быть представлены любыми из следующих четырех элементов:

1. Объект данных (Data Objects)

2. Входные данные (Data Inputs)

3. Выходные данные (Data Outputs)

4. Хранилища данных (Data Stores)

Выделяют четыре вида соединяющих Элементов потока, связывающихся друг с другом и с другими элементами:

1. Поток операций (Sequence Flow);

2. Поток сообщений (Message Flow);

3. Ассоциация (Association);

4. Ассоциация данных (Data Associations).

Существуют два способа группировки основных элементов моделирования с помощью Зон ответственности:

1. Группировка с помощью Пула (Pool);

2. Группировка с помощью Дорожки (Lane).

Артефакты используются для добавления дополнительной информации о Процессе.

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

1.  Группа (Gruop);

2. Текстовая аннотация (Text Annotation).

Нотация BPMN: объекты потока управления. (№13 -- 1 к.р.)

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

• События (Events);

• Действия (Activities);

• Шлюзы (Gateways).

1.1. События

Событие – это то, что происходит в течение бизнес-процесса и оказывает влияние на его ход. Чаще всего событие имеет причину (триггер) или воздействие (результат).

Примеры: Получение некоторого сообщения, Отправка некоторого сообщения, ожидание (по времени) и т.д. Т.е., чтобы некоторый процесс был запущен, должно быть получено некоторое сообщение.

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

Рис.1 – Графическое представление события

Согласно влиянию Событий на ход бизнес-процесса, выделяют три типа:

- Стартовое событие (Start),

- Промежуточное событие (Intermediate),

- Конечное событие (End).

1.1.1. Стартовое событие (Start Event)

Как видно из названия, Стартовое событие указывает на то, в какой точке берет начало тот или иной бизнес-процесс.

В контексте потока операций Стартовое событие является начальной точкой в процессе; это означает, что никакой входящий поток операций не может быть соединен со стартовым событием.

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

Рис.2 – Графическое представление начального события

Стартовое событие имеет следующие особенности:

• Стартовое событие является НЕОБЯЗАТЕЛЬНЫМ. Процессы верхнего уровня, а также Развернутые Подпроцессы МОГУТ начинаться со Стартового события, однако, данное условие не является обязательным.

• В случае если Процесс является комплексным и/или исходные условия – не очевидны, то РЕКОМЕНДУЕТСЯ использовать Стартовое событие.

• В случае, если диаграмма содержит Конечное событие, то ДОЛЖНО БЫТЬ по меньшей мере одно Стартовое событие.

1.1.2. Конечное событие (End Event)

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

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

Конечное событие представляет собой круг, выполненный одиночной, жирной, черной линией (см. рис.3). Толщина линии должна быть жирной настолько, чтобы без труда можно было отличить Конечное событие от Стартового и Промежуточного.

Рис.3 – Графическое представление конечного события

Конечное событие имеет следующие особенности:

• Процессы МОГУТ содержать несколько Конечных событий.

• Значок Конечного события является ОПЦИОНАЛЬНЫМ. Процесс определенного уровня - Процесс верхнего уровня или Развернутый Подпроцесс – МОЖЕТ удовлетворять данному требованию, однако, это не является необходимым условием.

• В случае, если диаграмма содержит Стартовое событие, то ДОЛЖНО БЫТЬ по меньшей мере одно Конечное событие.