Диаграмма последовательности как логическое представление поведения разрабатываемой системы. Понятие линии жизни классов и сообщений, их графическая нотация. Представление времени на диаграмме последовательности. Комбинированные фрагменты, их нотация и семантика. Особенности использования логических условий в комбинированных фрагментах языка UML 2. Временные ограничения и их запись. Примеры построения диаграмм последовательности в проектах UML 2.
Особенности моделирования поведения объектов в форме диаграммы конечного автомата. Понятие состояния и перехода, их графическая нотация. Спецификация внутренних действий простого состояния. Последовательные и параллельные композитные состояния. Исторические состояния глубокой и неглубокой истории, их семантика. Описание реакции объекта на асинхронные внешние события в форме диаграммы конечного автомата. Примеры построения диаграмм конечного автомата.
Диаграмма последовательности как логическое представление поведения разрабатываемой системы. Понятие линии жизни классов и сообщений, их графическая нотация. Представление времени на диаграмме последовательности. Комбинированные фрагменты, их нотация и семантика. Особенности использования логических условий в комбинированных фрагментах языка UML 2. Временные ограничения и их запись. Примеры построения диаграмм последовательности в проектах UML 2.
Особенности моделирования поведения объектов в форме диаграммы конечного автомата. Понятие состояния и перехода, их графическая нотация. Спецификация внутренних действий простого состояния. Последовательные и параллельные композитные состояния. Исторические состояния глубокой и неглубокой истории, их семантика. Описание реакции объекта на асинхронные внешние события в форме диаграммы конечного автомата. Примеры построения диаграмм конечного автомата.
Особенности графического представления диаграмм деятельности в нотации языка UML 2. Понятие узла деятельности и узла объекта. Потоки управления и объектов. Ветвление и распараллеливание потока управления с помощью специальных символов. Центральный буфер и хранилище данных. Особенности графического изображения диаграммы деятельности с дорожками. Использование диаграмм деятельности для моделирования бизнес-процессов. Примеры построения диаграмм деятельности.
Диаграмма компонентов как модель представления физической структуры разрабатываемой системы. Понятие компонента программной системы и его графическая нотация. Семантика компонента в контексте реализации классов логической модели. Порты, интерфейсы и соединители на диаграмме компонентов. Особенности построения диаграммы компонентов в качестве модели архитектуры разрабатываемой программной системы. Примеры построения диаграмм компонентов.
Диаграммы композитной структуры, коммуникации и пакетовDEVTYPE
Особенности представления внутренней структуры классов в UML 2. Основные элементы диаграммы композитной структуры и их графическая нотация. Классы и интерфейсы на диаграмме композитной структуры. Порты и соединители. Интегрированное представление элементов структуры и поведения на диаграмме коммуникации. Нотация линий жизни и связей между ними. Графическое изображение сообщений, посылаемых и принимаемых линиями жизни. Особенности представления архитектуры сложной программной системы в форме диаграммы пакетов. Нотация пакетов и отношений между ними в языке UML 2.Примеры построения диаграмм композитной структуры, диаграмм и пакетов коммуникации.
Диаграмма развертывания как модель представления физической архитектуры распределенной информационной системы. Понятия узла, устройства и среды выполнения, их графическая нотация. Основные отношения на диаграмме развертывания и их графическое представление. Различные способы представления отношения развертывания. Пути коммуникации и аннотирования манифестов. Представление физических аспектов материальных ресурсов, задействованных в реализации системы. Примеры построения диаграмм развертывания.
Разработка пользовательских элементов управления в WPFCUSTIS
Открытый семинар для студентов в компании CUSTIS (20 июня 2013 года).
Лектор: Павел Музыка, ведущий разработчик (С#, SQL), сертифицированный разработчик Microsoft (MCTS, MCPD, MCITPro).
Аннотация: WPF — это система построения клиентских приложений Windows с визуально привлекательными возможностями взаимодействия с пользователем. С помощью WPF можно создавать широкий спектр как автономных, так и браузерных приложений. Из семинара вы узнаете об особенностях создания и кастомизации пользовательских элементов управления в Windows Presentation Foundation.
Видеозапись выступления: https://vimeo.com/69144418.
Разработка исполнимых бизнес-процессов как новая парадигма программированияABPMP Russian Chapter
Михеев Андрей Геннадьевич
Доцент кафедры Бизнес-информатики и систем управления производством, преподаватель кафедры Прикладной информатики в экономике МЭСИ, руководитель проекта RunaWFE.
Доклад на конференции ABPMP Russian Chapter "Преподавание BPM — опыт, проблемы, перспективы"
Москва, 13.12.2013
Особенности графического представления диаграмм деятельности в нотации языка UML 2. Понятие узла деятельности и узла объекта. Потоки управления и объектов. Ветвление и распараллеливание потока управления с помощью специальных символов. Центральный буфер и хранилище данных. Особенности графического изображения диаграммы деятельности с дорожками. Использование диаграмм деятельности для моделирования бизнес-процессов. Примеры построения диаграмм деятельности.
Диаграмма компонентов как модель представления физической структуры разрабатываемой системы. Понятие компонента программной системы и его графическая нотация. Семантика компонента в контексте реализации классов логической модели. Порты, интерфейсы и соединители на диаграмме компонентов. Особенности построения диаграммы компонентов в качестве модели архитектуры разрабатываемой программной системы. Примеры построения диаграмм компонентов.
Диаграммы композитной структуры, коммуникации и пакетовDEVTYPE
Особенности представления внутренней структуры классов в UML 2. Основные элементы диаграммы композитной структуры и их графическая нотация. Классы и интерфейсы на диаграмме композитной структуры. Порты и соединители. Интегрированное представление элементов структуры и поведения на диаграмме коммуникации. Нотация линий жизни и связей между ними. Графическое изображение сообщений, посылаемых и принимаемых линиями жизни. Особенности представления архитектуры сложной программной системы в форме диаграммы пакетов. Нотация пакетов и отношений между ними в языке UML 2.Примеры построения диаграмм композитной структуры, диаграмм и пакетов коммуникации.
Диаграмма развертывания как модель представления физической архитектуры распределенной информационной системы. Понятия узла, устройства и среды выполнения, их графическая нотация. Основные отношения на диаграмме развертывания и их графическое представление. Различные способы представления отношения развертывания. Пути коммуникации и аннотирования манифестов. Представление физических аспектов материальных ресурсов, задействованных в реализации системы. Примеры построения диаграмм развертывания.
Разработка пользовательских элементов управления в WPFCUSTIS
Открытый семинар для студентов в компании CUSTIS (20 июня 2013 года).
Лектор: Павел Музыка, ведущий разработчик (С#, SQL), сертифицированный разработчик Microsoft (MCTS, MCPD, MCITPro).
Аннотация: WPF — это система построения клиентских приложений Windows с визуально привлекательными возможностями взаимодействия с пользователем. С помощью WPF можно создавать широкий спектр как автономных, так и браузерных приложений. Из семинара вы узнаете об особенностях создания и кастомизации пользовательских элементов управления в Windows Presentation Foundation.
Видеозапись выступления: https://vimeo.com/69144418.
Разработка исполнимых бизнес-процессов как новая парадигма программированияABPMP Russian Chapter
Михеев Андрей Геннадьевич
Доцент кафедры Бизнес-информатики и систем управления производством, преподаватель кафедры Прикладной информатики в экономике МЭСИ, руководитель проекта RunaWFE.
Доклад на конференции ABPMP Russian Chapter "Преподавание BPM — опыт, проблемы, перспективы"
Москва, 13.12.2013
BPM: Почему надо говорить о системе курсов для всех заинтересованных лиц орга...ABPMP Russian Chapter
Алёшин В.Д., РАНХ и ГС при Президенте РФ, профессор
Доклад на конференции ABPMP Russian Chapter "Преподавание BPM — опыт, проблемы, перспективы"
Москва, 13.12.2013
Презентация ABPMP Russia и мастер класс по процессному управлению для Профессионального сообщества директоров. Андрей Коптелов, вице-президент ABPMP Russia. Москва, 04.02.2014.
Вебинар «Схемы бизнес-процессов в различных нотациях»Алеся Гарасимович
Компания Кодерлайн провела вебинар на тему «Схемы бизнес-процессов в различных нотациях»
Вебинар будет интересен консультантам, методологам, аналитикам, руководителям проектов, архитекторам, заинтересованным лица.
Ведущий: Тарас КИРПИКОВ - консультант-аналитик 1С
Описание:
Ответили на ряд вопросов, возникающих у руководителей и специалистов в начале проекта по моделированию и реорганизации бизнес-процессов предприятия:
• какое программное обеспечение использовать в проекте («ARIS лучше BPWin?», «ERWin лучше ARIS?», «MS Visio?» и т.п.)
• как моделировать процессы с использованием продукта «Х»?
• как проводить анализ и выявлять проблемы при помощи продукта «Х»?
• какую методологию (нотацию) использовать для описания процессов?
Программа вебинара:
1. Введение;
2. Знакомство с наиболее распространенными процессными нотациями (описание, инструменты, примеры, правила моделирования):
a. IDEF0 (IDEF3, DFD);
b. BFC (процесс), CFF (процедура);
c. EPC;
d. BPMN;
3. Знакомство с некоторыми типами моделей диаграмм:
a. ER-диаграмма (сущность-связь);
b. VAD - процесс добавленной стоимости;
c. Организационная диаграмма;
d. ИТ-инфраструктура;
e. ИТ-архитектура;
4. Сравнение процессных нотаций и стандартов;
5. Области применения процессных нотаций;
6. Оценка применимости различных нотаций;
7. Основные инструменты;
8. Стоит попробовать.
Будем благодарны за ваши отзывы :)
Краткая презентация о нотации UML, как её можно использовать в работе системного аналитика.
Short presentation on UML notation and how it can be used in the work of system analyst.
2. Функциональное моделирование
Методология IDEF0 позволяет моделировать всю
систему как набор чередующихся функций.
Простая система обозначений и строгий
набор правил построения призван обеспечить
точность и ясность при моделировании.
3. Контекстная функция
Функциональная модель имеет иерархическую
структуру.
Контекстная функция – функция верхнего уровня
модели.
Контекстная функция несет имя основного
действия выполняемого системой.
Изображается на отдельной диаграмме,
называемой контекстной.
6. Потоки на контекстной диаграмме
Потоки делятся на:
входные (то, что перерабатывается системой),
выходные (результат работы системы),
управления (регламентирующая и управляющая информации или правила)
механизма (ресурсы выполняющие работы).
Система преобразует входные потоки в выходные с учетом управления и с
использованием механизмов.
9. Диаграмма IDEF0 и ее элементы
Диаграмма IDEF0 формируется из двух типов элементов:
прямоугольники, обозначающие функциональные блоки
стрелки, обозначающие информационные и материальные потоки.
Функциональный
блок
Стрелки
10. Диаграмма IDEF0 и ее элементы
Связи
управления
Входящие
связи
Выходящие
связи
Связи
механизмов
11. Изображение функции
Изображается прямоугольником.
Обозначает действие выполняемое над «входом» и выдающее в
результате «выход».
Имя функции состоит из:
глагола, определяющего действие функции;
существительного определяющего объект или цель действия.
Действие
Объект
действия
Префикс
номера
Уникальный номер
функционального
блока
12. Расположение блоков на диаграмме
Блок А1 доминирует над блоком А2
Блок А2 доминирует над блоком А3
13. Нумерация функций и диаграмм
Все функциональные блоки должны быть
пронумерованы.
Номер состоит из префикса и одной или нескольких
цифр.
Обычно используется префикс «А», но допустимо
использовать префикс любой длины.
Контекстная функция всегда именуется А0.
Функция А0 декомпозируется в функции А1, А2, А3 и т.д.
Функция А2 декомпозируется в функции А21, А22, А23 и
т.д. Каждый уровень декомпозиции добавляет один
разряд в номер функционального блока.
15. Обозначение стрелок
Стрелки могут быть только однонаправленными.
Именуются существительными.
Подписи соединяются со стрелками с помощью специального элемента -
тильды.
Тильда
Наименование
стрелки
16. Применение стрелок
В литературе часто встречается термин ICOM
(Input/Control/Output/Mechanism), обозначающий четыре
основных типа стрелок:
вход;
управление;
выход;
механизм.
Механизм и управление не видоизменяются в процессе
выполнения функции.
Если какой либо поток данных преобразуются функцией,
то характер этих изменений должен быть отражен в
названии потоков на входе и выходе.
17. Входные стрелки
Вход (Input) – материальный или информационный поток который
потребляется или преобразовывается функцией чтобы произвести
результат работы на выходе.
Входит в левую грань блока.
Присутствие не обязательно.
Если какой либо поток данных преобразуются функцией, то характер этих
изменений должен быть отражен в названии потоков на входе и выходе.
18. Управление
Управление (Control) – содержит неизменяемые объекты:
правила;
инструкции;
стандарты в соответствии с которыми выполняется функция.
Присутствие обязательно.
Изображается как входящая в верхнюю грань блока.
19. Выход
Выход (Output) – результат работы функции.
Присутствие выходов обязательно.
Изображается как выходящая из правой грани.
20. Механизм
Механизм (Mechanism) – неизменяемые ресурсы выполняющие
работу функции, например организационные единицы
предприятия, отдельные работники, машины и механизмы,
вычислительные системы и программные средства.
Присутствие обязательно.
Изображается как входящая в нижнюю грань.
22. Внутренние связи
Внутренние связи не касаются границ диаграммы.
Разделяются на виды:
Выход-вход.
Выход-управление.
Выход-механизм.
Обратная связь по входу.
Обратная связь по управлению.
26. Обратная связь по входу
Выход функции направляется на вход предыдущей.
Используется для описания возможности повторной обработки потока
объектов или для описания циклических действий над потоком.
Обратная связь по
входу
28. Слияние стрелок
Случай когда какой либо
однотипный результат
получается от двух
различных функций.
Достаточно отметить только
общую часть стрелки.
Два различных выхода
сливаются в один общий.
Должны быть отмечены
каждая ветвь и общий
участок связи.
Функция производит объекты, которые используется в нескольких других
функциях.
Объекты, полученные в результате работы нескольких функций,
объединяются в один общий поток.
29. Разветвление
Поток разветвляясь
сохраняет первоначальное
содержание.
Подпись необходима
только для общей части
стрелки.
Поток ответвляется от
общего потока, неся в себе
часть объектов (чертежи).
Подписываются общая
стрелка и ответвления.
Если ответвление не
подписано, то оно несет в
себе общий поток объектов.
30. Разветвление
Разделение общего
потока на несколько
независимых потоков.
Обозначается общая
часть стрелки и каждое
ответвление.
Ошибка - не именованы
общая часть стрелки и
какая либо из ветвей.
31. Применение туннелей
Применяются когда:
хотят чтобы стрелка используемая
только начиная с какого либо уровня
не присутствовала на всех
промежуточных уровнях
декомпозиции. Это помогает
освободить промежуточные
диаграммы от неиспользуемых
стрелок.
необходимо скрыть граничную
стрелку на диаграмме декомпозиции.
32. Методика построения модели
1. Определение предмета моделирования
2. Определение цели и точки зрения
3. Создание контекстной функции
Цель: Внедрение электронного
документооборота
Точка зрения: Команда по внедрению
33. 4. Определение основных граничных ICOM
Цель любой функции - получение какого-либо результата.
Следовательно нужно начать с определения выходов функций.
Далее в следующей последовательности:
определение входов;
определение управления;
определение механизмов.
12
3
4
Цель: Внедрение электронного
документооборота
Точка зрения: Команда по внедрению
37. Определение Выходов
Нужно отразить все возможные варианты связанные с
результатами работы функции.
Действие некоторых функций может заканчиваться
неудачно.
Выходы должны отражать любое развитие событий.
Отрицательные результаты часто используются при
создании стрелок обратной связи и должны быть
рассмотрены для каждой функции.
Полезно включить в модель сомнительные или неясные
стрелки, обозначенные знаком вопроса, чтобы потом
обсудить их с экспертом.
38. Определение Входов
Входы - объекты из которых получаются объекты на
выходе.
При работе с материальными объектами они
преобразуются в выходное изделие или уничтожаются в
результате действия функции.
Информационный объект может остаться нетронутым.
39. Определение Управления
Управление принимает форму:
правил;
стандартов;
рекомендаций;
инструкций.
Управление - «неизменная» форма входа.
Если возникает затруднение с определением характера
связи между входом и управлением, то следует выбирать
управление
40. Определение Механизмов
Механизм включает в себя:
людей;
машины и механизмы;
вычислительные системы.
любые материальные ресурсы
силами или с помощью которых
выполняются действия функции.