Практический анализ и визуальное моделирование на UMLNikolai Kireev
Презентация курса online-тренингов, проводимых совместно Школой Системного Анализа г. Москва и IT-Студией WebMax.BY г. Минск.
Запись на курс по ссылке: http://school.system-analysis.ru/uml-online/
REQ Labs 2014. Smart Business Modelling: A Key to Success in Enterprise Autom...Alex V. Petrov
Приходя первыми на объект автоматизации, аналитики выполняют крайне ответственную работу по изучению, моделированию и предварительной оптимизации деятельности предприятия. Разнообразие созданных на сегодня подходов и языков описания бизнес-процессов способно вселить в начинающего и даже опытного специалиста веру в то, что инструменты и нотации можно выбирать наугад. Но не все «пути аналитика» ведут к успеху возложенной на него миссии.
Доклад «Умелое описание бизнес-процессов — залог успешной автоматизации» на наглядных примерах демонстрирует проверенную временем, но неоправданно малоизвестную в России методологию многоуровневого описания бизнес-процессов в целях их автоматизации. Вооружившись ею, читатели смогут легко и просто формировать наглядные модели процессов, понятные и значимые для основных заинтересованных сторон проекта; выявлять и описывать основные успешные сценарии выполнения бизнес-процессов; находить альтернативные и исключительные сценарии и задавать правильные вопросы, помогающие устанавливать мельчайшие нюансы будущей программной и внепрограммной реализации таковых.
Базовые принципы и понятия технологии разработки объектно-ориентированных инф...DEVTYPE
Основы современной методологии объектно-ориентированного анализа и проектирования. Особенности визуального моделирования информационных систем. Базовые семантические конструкции языка UML 2 и их описание с помощью специальных обозначений. Основные элементы нотации языка UML 2 и их отличие от языка UML 1. Особенности моделей представления структуры и поведения в проектах разработки сложных программных систем и бизнес-процессов. Канонические диаграммы языка UML 2 и их общая характеристика. Механизмы расширения языка UML 2.
UML2. Eleven Trivial Tips for BPMN Modellers [1.01, RUS]Alex V. Petrov
«Дорога в тысячу ли начинается с первого шага», — гласит китайская мудрость. Простые, правильные и понятные модели бизнес-процессов — своеобразный «знак качества», скреплять которым свою работу мечтает каждый профессионал-аналитик. Однако достижение нужного качества моделей у многих занимает годы непрерывной работы, а такой запас времени — непозволительная роскошь в стремительно развивающемся мире ИТ- и управленческого консалтинга. Многим не добавляет оптимизма и общепризнанный на сегодня открытый международный стандарт BPMN 2.0, допускающий чересчур много равновозможных решений одной и той же задачи в области моделирования.
В ходе общения с аудиторией на дискуссионном онлайн-семинаре Сообщества аналитиков UML2.Ru мы представили ряд простых способов повышения качества BPMN-моделей бизнес-процессов. Придерживаясь этих рекомендаций, вы вместе с участниками семинара сможете:
* унифицировать личную и командную технику моделирования процессов;
* добиться однозначного толкования моделей различными заинтересованными сторонами;
* преодолевать самые известные ограничения BPMN, не нарушая стандарт OMG и не выходя за рамки возможностей промышленных инструментов;
* заложить основу корпоративного соглашения о моделировании на описательном и аналитическом уровне.
Доклад Михаила Бухарина "Разбивка на модули в архитектурном проектировании. Практика DSM (design structure matrix)" на 94 заседании INCOSE, 8 октября 2014г.
Практический анализ и визуальное моделирование на UMLNikolai Kireev
Презентация курса online-тренингов, проводимых совместно Школой Системного Анализа г. Москва и IT-Студией WebMax.BY г. Минск.
Запись на курс по ссылке: http://school.system-analysis.ru/uml-online/
REQ Labs 2014. Smart Business Modelling: A Key to Success in Enterprise Autom...Alex V. Petrov
Приходя первыми на объект автоматизации, аналитики выполняют крайне ответственную работу по изучению, моделированию и предварительной оптимизации деятельности предприятия. Разнообразие созданных на сегодня подходов и языков описания бизнес-процессов способно вселить в начинающего и даже опытного специалиста веру в то, что инструменты и нотации можно выбирать наугад. Но не все «пути аналитика» ведут к успеху возложенной на него миссии.
Доклад «Умелое описание бизнес-процессов — залог успешной автоматизации» на наглядных примерах демонстрирует проверенную временем, но неоправданно малоизвестную в России методологию многоуровневого описания бизнес-процессов в целях их автоматизации. Вооружившись ею, читатели смогут легко и просто формировать наглядные модели процессов, понятные и значимые для основных заинтересованных сторон проекта; выявлять и описывать основные успешные сценарии выполнения бизнес-процессов; находить альтернативные и исключительные сценарии и задавать правильные вопросы, помогающие устанавливать мельчайшие нюансы будущей программной и внепрограммной реализации таковых.
Базовые принципы и понятия технологии разработки объектно-ориентированных инф...DEVTYPE
Основы современной методологии объектно-ориентированного анализа и проектирования. Особенности визуального моделирования информационных систем. Базовые семантические конструкции языка UML 2 и их описание с помощью специальных обозначений. Основные элементы нотации языка UML 2 и их отличие от языка UML 1. Особенности моделей представления структуры и поведения в проектах разработки сложных программных систем и бизнес-процессов. Канонические диаграммы языка UML 2 и их общая характеристика. Механизмы расширения языка UML 2.
UML2. Eleven Trivial Tips for BPMN Modellers [1.01, RUS]Alex V. Petrov
«Дорога в тысячу ли начинается с первого шага», — гласит китайская мудрость. Простые, правильные и понятные модели бизнес-процессов — своеобразный «знак качества», скреплять которым свою работу мечтает каждый профессионал-аналитик. Однако достижение нужного качества моделей у многих занимает годы непрерывной работы, а такой запас времени — непозволительная роскошь в стремительно развивающемся мире ИТ- и управленческого консалтинга. Многим не добавляет оптимизма и общепризнанный на сегодня открытый международный стандарт BPMN 2.0, допускающий чересчур много равновозможных решений одной и той же задачи в области моделирования.
В ходе общения с аудиторией на дискуссионном онлайн-семинаре Сообщества аналитиков UML2.Ru мы представили ряд простых способов повышения качества BPMN-моделей бизнес-процессов. Придерживаясь этих рекомендаций, вы вместе с участниками семинара сможете:
* унифицировать личную и командную технику моделирования процессов;
* добиться однозначного толкования моделей различными заинтересованными сторонами;
* преодолевать самые известные ограничения BPMN, не нарушая стандарт OMG и не выходя за рамки возможностей промышленных инструментов;
* заложить основу корпоративного соглашения о моделировании на описательном и аналитическом уровне.
Доклад Михаила Бухарина "Разбивка на модули в архитектурном проектировании. Практика DSM (design structure matrix)" на 94 заседании INCOSE, 8 октября 2014г.
Открытый семинар для студентов в компании CUSTIS (30 мая 2013 года).
Лектор: Юрий Солдаткин, ведущий разработчик C#.
Аннотация: UML — это средство графического моделирования объектов при проектировании ПО. Из этого семинара вы узнаете, что из себя представляет этот инструмент, где он необходим, в каких случаях применяется, а также получите конкретные примеры его использования в разработке ИТ-систем.
Видеозапись семинара: https://vimeo.com/67624786.
ITGM #5. System Duality and Its Practical Effect on Business Analysis [1.0, RUS]Alex V. Petrov
Как гласит один из постулатов современной системной инженерии, любая сложная инженерная система есть иррациональное единство функции и конструкции, и информационные системы — не исключение.
Постичь внутреннюю онтологическую двойственность таких систем — значит научиться отчетливо видеть альтернативные пути удовлетворения потребностей заинтересованных сторон, осознанно, а не интуитивно различать ограничения и требования, элементы ИТ-архитектур и элементы ИТ-решений, идентифицировать внешние и внутренние интерфейсы систем в их надсистемах и многое-многое другое.
SPb BA & SA Night. Learning a New Business Domain [1.01, RUS]Alex V. Petrov
Известные и неизвестные приемы освоения новых предметных областей — обязательный инструмент в арсенале успешного аналитика. Именно им был посвящен II «Вечер системного и бизнес-анализа» в С.-Петербурге, прошедший 05 сентября 2015 г. Ключевые темы: индукция и дедукция, концептуальные модели и онтологии, разбор примеров, командная работа и менторство.
ISUCT & BSUIR. Successful Communication of the Process Architecture [1.0, RUS]Alex V. Petrov
Архитектура предприятия как системы охватывает такие области, как информационно-технологическая и бизнес-архитектура. В свою очередь, одним из компонентов бизнес-архитектуры, заслуженно привлекающим первоочередное внимание и требующим пристального рассмотрения в контексте реализации самых разнообразных бизнес-инициатив, является процессная архитектура.
Грамотно передать суть и содержание бизнес-процессов современного предприятия не так просто, как может показаться на первый взгляд. Растущая сложность внутри- и межкорпоративных взаимодействий является одной из основных причин того, что на сегодняшний день мы наблюдаем быструю смену целых поколений языков описания бизнес-процессов. Действительно, языки, востребованные в 1990-х – 2000-х гг., стремительно уступают место новым нотациям моделирования, сложность которых поначалу ставит в тупик даже опытных аналитиков. Одним из ярких примеров таких сложных, но актуальных нотаций является язык BPMN 2.0.
Наконец, дисциплина бизнес-моделирования становится по-настоящему значимой только в контексте коммуникации как практики передачи знания о процессной архитектуре предприятия от человека к человеку или от человека — к машине; а коммуникации процессной архитектуры, как и любой другой, нужно последовательно учиться.
В лекциях для студентов ИГХТУ (Иваново) и БГУИР (Минск) проанализирован и обобщен практический опыт применения моделей бизнес-процессов для описания текущих и целевых состояний процессной архитектуры предприятий, подведен теоретический базис под современные представления о подходах к решению задач коммуникации архитектуры, приведен ряд примеров
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]Alex V. Petrov
Приступая к реализации проектов разработки информационных систем, заказчик и исполнитель, как правило, в большей степени нацелены на подготовку технического задания. Однако, в действительности техническое задание — это финальный документ, в подготовке которого участвуют представители аналитического блока команды. Создание технического задания должно предваряться формированием ряда не менее важных документов, относящихся к более ранним этапам жизненного цикла системы. Одним из этих документов являются «Бизнес-требования» (англ. Business Requirements Document, BRD).
Ключевая миссия этого документа — исчерпывающее определение рамок, или объема, проекта. Какие объемы проекта существуют, как определяются и из чего складываются? Включать ли в BRD перечень заинтересованных сторон и предварительно идентифицированные риски проекта? Какую еще информацию следует включать в BRD, а какую — нет? Как провести границу между BRD и документом «Функциональные требования» (англ. Functional Requirements Document, FRD)? Как взаимодействовать с заказчиком для эффективного определения бизнес-требований? Ответы на эти и другие вопросы — в презентации с выступления в Парке высоких технологий (Минск, 03 декабря 2015 г.).встрече
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]Alex V. Petrov
Прошедший в «Академии информационных систем» (г. Москва) семинар «Как измерить архитектуру ПО?» ответил на вопрос о том, реально ли оценить архитектуру программной системы и сказать, насколько она полна, качественна, подвержена тем или иным недостаткам. В ходе семинара слушатели узнали, какие архитектурные метрики существуют, какие из них — признаны отраслью, в чем состоит их польза и как подходить к их применению в условиях производства.
ITGM #5. What Is Enterprise Architecture [1.0, RUS]Alex V. Petrov
«Экономический дарвинизм» XXI в. делает предприятия все более уязвимыми в жесткой конкурентной борьбе. Сегодня мы наблюдаем радикальную трансформацию даже самых консервативных отраслей, не говоря уже о «новой экономике» и высокотехнологичных сферах. Бизнес стремительно осваивает принципиально иные средства производства, каналы коммуникаций, виды инфраструктуры и постоянно перевооружается в попытке опередить соперников по борьбе за клиента. И не всегда удачно.
В этих условиях вопросы эффективного проектирования корпоративной архитектуры (англ. Enterprise Architecture, EA) приобретают все большую актуальность. Из чего складывается такая архитектура и в чем ее отличие от ИТ- и бизнес-архитектуры? Какая она бывает? Как правильно ее создавать? Актуальна ли проблематика корпоративной архитектуры для малого и среднего бизнеса и возможно ли «масштабирование вниз» классических архитектурных подходов?
Вебинар «Схемы бизнес-процессов в различных нотациях»Алеся Гарасимович
Компания Кодерлайн провела вебинар на тему «Схемы бизнес-процессов в различных нотациях»
Вебинар будет интересен консультантам, методологам, аналитикам, руководителям проектов, архитекторам, заинтересованным лица.
Ведущий: Тарас КИРПИКОВ - консультант-аналитик 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. Стоит попробовать.
Будем благодарны за ваши отзывы :)
Открытый семинар для студентов в компании CUSTIS (30 мая 2013 года).
Лектор: Юрий Солдаткин, ведущий разработчик C#.
Аннотация: UML — это средство графического моделирования объектов при проектировании ПО. Из этого семинара вы узнаете, что из себя представляет этот инструмент, где он необходим, в каких случаях применяется, а также получите конкретные примеры его использования в разработке ИТ-систем.
Видеозапись семинара: https://vimeo.com/67624786.
ITGM #5. System Duality and Its Practical Effect on Business Analysis [1.0, RUS]Alex V. Petrov
Как гласит один из постулатов современной системной инженерии, любая сложная инженерная система есть иррациональное единство функции и конструкции, и информационные системы — не исключение.
Постичь внутреннюю онтологическую двойственность таких систем — значит научиться отчетливо видеть альтернативные пути удовлетворения потребностей заинтересованных сторон, осознанно, а не интуитивно различать ограничения и требования, элементы ИТ-архитектур и элементы ИТ-решений, идентифицировать внешние и внутренние интерфейсы систем в их надсистемах и многое-многое другое.
SPb BA & SA Night. Learning a New Business Domain [1.01, RUS]Alex V. Petrov
Известные и неизвестные приемы освоения новых предметных областей — обязательный инструмент в арсенале успешного аналитика. Именно им был посвящен II «Вечер системного и бизнес-анализа» в С.-Петербурге, прошедший 05 сентября 2015 г. Ключевые темы: индукция и дедукция, концептуальные модели и онтологии, разбор примеров, командная работа и менторство.
ISUCT & BSUIR. Successful Communication of the Process Architecture [1.0, RUS]Alex V. Petrov
Архитектура предприятия как системы охватывает такие области, как информационно-технологическая и бизнес-архитектура. В свою очередь, одним из компонентов бизнес-архитектуры, заслуженно привлекающим первоочередное внимание и требующим пристального рассмотрения в контексте реализации самых разнообразных бизнес-инициатив, является процессная архитектура.
Грамотно передать суть и содержание бизнес-процессов современного предприятия не так просто, как может показаться на первый взгляд. Растущая сложность внутри- и межкорпоративных взаимодействий является одной из основных причин того, что на сегодняшний день мы наблюдаем быструю смену целых поколений языков описания бизнес-процессов. Действительно, языки, востребованные в 1990-х – 2000-х гг., стремительно уступают место новым нотациям моделирования, сложность которых поначалу ставит в тупик даже опытных аналитиков. Одним из ярких примеров таких сложных, но актуальных нотаций является язык BPMN 2.0.
Наконец, дисциплина бизнес-моделирования становится по-настоящему значимой только в контексте коммуникации как практики передачи знания о процессной архитектуре предприятия от человека к человеку или от человека — к машине; а коммуникации процессной архитектуры, как и любой другой, нужно последовательно учиться.
В лекциях для студентов ИГХТУ (Иваново) и БГУИР (Минск) проанализирован и обобщен практический опыт применения моделей бизнес-процессов для описания текущих и целевых состояний процессной архитектуры предприятий, подведен теоретический базис под современные представления о подходах к решению задач коммуникации архитектуры, приведен ряд примеров
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]Alex V. Petrov
Приступая к реализации проектов разработки информационных систем, заказчик и исполнитель, как правило, в большей степени нацелены на подготовку технического задания. Однако, в действительности техническое задание — это финальный документ, в подготовке которого участвуют представители аналитического блока команды. Создание технического задания должно предваряться формированием ряда не менее важных документов, относящихся к более ранним этапам жизненного цикла системы. Одним из этих документов являются «Бизнес-требования» (англ. Business Requirements Document, BRD).
Ключевая миссия этого документа — исчерпывающее определение рамок, или объема, проекта. Какие объемы проекта существуют, как определяются и из чего складываются? Включать ли в BRD перечень заинтересованных сторон и предварительно идентифицированные риски проекта? Какую еще информацию следует включать в BRD, а какую — нет? Как провести границу между BRD и документом «Функциональные требования» (англ. Functional Requirements Document, FRD)? Как взаимодействовать с заказчиком для эффективного определения бизнес-требований? Ответы на эти и другие вопросы — в презентации с выступления в Парке высоких технологий (Минск, 03 декабря 2015 г.).встрече
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]Alex V. Petrov
Прошедший в «Академии информационных систем» (г. Москва) семинар «Как измерить архитектуру ПО?» ответил на вопрос о том, реально ли оценить архитектуру программной системы и сказать, насколько она полна, качественна, подвержена тем или иным недостаткам. В ходе семинара слушатели узнали, какие архитектурные метрики существуют, какие из них — признаны отраслью, в чем состоит их польза и как подходить к их применению в условиях производства.
ITGM #5. What Is Enterprise Architecture [1.0, RUS]Alex V. Petrov
«Экономический дарвинизм» XXI в. делает предприятия все более уязвимыми в жесткой конкурентной борьбе. Сегодня мы наблюдаем радикальную трансформацию даже самых консервативных отраслей, не говоря уже о «новой экономике» и высокотехнологичных сферах. Бизнес стремительно осваивает принципиально иные средства производства, каналы коммуникаций, виды инфраструктуры и постоянно перевооружается в попытке опередить соперников по борьбе за клиента. И не всегда удачно.
В этих условиях вопросы эффективного проектирования корпоративной архитектуры (англ. Enterprise Architecture, EA) приобретают все большую актуальность. Из чего складывается такая архитектура и в чем ее отличие от ИТ- и бизнес-архитектуры? Какая она бывает? Как правильно ее создавать? Актуальна ли проблематика корпоративной архитектуры для малого и среднего бизнеса и возможно ли «масштабирование вниз» классических архитектурных подходов?
Вебинар «Схемы бизнес-процессов в различных нотациях»Алеся Гарасимович
Компания Кодерлайн провела вебинар на тему «Схемы бизнес-процессов в различных нотациях»
Вебинар будет интересен консультантам, методологам, аналитикам, руководителям проектов, архитекторам, заинтересованным лица.
Ведущий: Тарас КИРПИКОВ - консультант-аналитик 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.
Практический подход к систематизации требований при проектировании информацио...Anatoly Simkin
Тезисы описывают этапы подхода к проектированию информационной системы с целью организации прозрачного процесса разработки и вовлечения в этот проект заказчика.
Abstracts describing the stages of approach to design the information system for the purpose of organizing a transparent design process and involving of stakeholders.
Доклад А.Левенчука "SysArchi -- системное моделирование в ArchiMate 3.0" на семинаре "Дни инженерии организаций" факультета информатики, математики и компьютерных наук НИУ ВШЭ. Москва-Нижний Новгород, 11 сентября 2018
Неотрефлексированный сдвиг парадигмы: от поколений языков программирования вы...Alexey Neznanov
Лекция на школе учителей 2018-11-05. Название слишком забористое, но в целом это более-менее системное и актуальное рассмотрение того, что происходит с языками программирования. Лекция прочитана перед изучением языка Питон (Python). Много ссылок
Provide a unified vision of automated processes, possibly through a common document that contains hierarchy and relationships of the whole system of technical requirements
2. Основные вопросыОсновные вопросы
Сущность структурного подхода
Основные принципы структурного подхода
Сущность методологии функционального
моделирования IDEF0
Основные понятия методологии IDEF0
Правила построения моделей IDEF0
Пример функциональной модели в нотации
IDEF0
3. Сущность структурного подхода кСущность структурного подхода к
моделированию системмоделированию систем
Система разбивается на функциональные подсистемы,
которые, в свою очередь, делятся на подфункции,
подфункции – на задачи и т.д. до конкретных
процедур
Система
Функция 1
Функция 2
…
Функция n
Подфункция 2
… …
Задача 2 …
Подфункция 1
…
Задача 1
…
…
Задача n …
…
Подфункция n
…
4. Базовые принципы структурногоБазовые принципы структурного
подходаподхода
принцип «Разделяй и властвуй»
принцип иерархического
упорядочивания
принцип абстрагирования
принцип непротиворечивости
принцип структурирования данных
5. Методология структурногоМетодология структурного
анализа и проектированияанализа и проектирования
70-е гг. ХХ века – методология SADTSADT
Предложена Дугласом Россом (Douglas Ross)
Основная идеяОсновная идея данной методологии – построение
древовидной иерархической модели предприятия.
В начале 1990-х1990-х на основе SADT принят стандарт
моделирования бизнес-процессов IDEFIDEF00,
являющийся одним из 14 стандартов линейки IDEF –
Integration Definition for Functional Modeling (в данном
курсе будут рассмотрены некоторые из них, в
частности, IDEF0, IDEF1X, IDEF3) [8, 5].
Положения методологии зафиксированы в
разработанном в США стандарте IDEF0 (В России –
РД IDEF0 – 2000)
6. Модели структурного подхода,Модели структурного подхода,
изучаемые в курсе «Системноеизучаемые в курсе «Системное
моделирование имоделирование и CASECASE-технологии»-технологии»
3 типа моделей, используемых в структурном
подходе:
1) функциональные модели (ФМ)
2) информационные модели (ИМ)
3) динамические модели (ДМ)
ФМ SADT (IDEF0)-модели
DFD-модели
Пакеты BPWin, Design/IDEF
Пакет BPWin
ИМ ERD (IDEF1X) Пакеты Design/IDEF, ERWin
ДМ IDEF/CPN
IDEF3
Пакет Design/IDEF
Пакет BPWin
7. Сущность функциональногоСущность функционального
моделированиямоделирования
Для любой системы определяющим
является ее функциональное
содержание, так как оно определяет ее
основные свойства. Поэтому в основе
функционального моделирования
лежит функциональное содержание
системы, в качестве отношений между
функциями рассматривается
информация об объектах,
связывающих эти функции [1].
8. МетодологияМетодология IDEF0IDEF0
В основе IDEF0-методологии лежат 4
основных понятия:
1) функциональный блок;
2) интерфейсная дуга (стрелка);
3) декомпозиция;
4) глоссарий.
9. Функциональный блокФункциональный блок
Олицетворяет некоторую конкретную функцию или работу в рамках
рассматриваемой системы
РД IDEF0 – 2000: прямоугольник, содержащий имя и номер и
используемый для описания функции
Управлять
предприятием
А0
управление
вход выход
механизм
Наименование
осуществляется
оборотом глагола
или
существительного
Каждый блок в
рамках единой
системы имеет
уникальный номер
Каждая сторона
функционального
блока имеет свое
назначение
10. Интерфейсная дугаИнтерфейсная дуга
Интерфейсная дуга отображает элемент системы,
который обрабатывается функциональным блоком
или оказывает иное влияние на функцию,
отображаемую функциональным блоком.
Графически изображается в виде однонаправленной
стрелки.
Каждая дуга должна иметь свое уникальное
название, сформулированное оборотом
существительного (должно отвечать на вопросы
кто?, что?). Примеры: информация, разработчик,
документ, обработанная заявка.
В зависимости от того, к какой стороне блока она
подходит, интерфейсная дуга будет являться
входящей, выходящей, управления, механизма.
11. Интерфейсная дугаИнтерфейсная дуга
Функциональный
блок
А0
управление
вход выход
механизм
Ресурсы, необходимые для
проведения работы
(человеческие ресурсы,
оборудование, ИС).
Ресурсы,
перерабатываемые
системой
Регулирует работу
системы, управляет
(нормативная
документация и т.п.)
Результат работы
системы,
переработанные
ресурсы, продукт
деятельности
Стрелки входа может не быть. Остальные интерфейсные дуги обязательны.
12. ДекомпозицияДекомпозиция
Принцип декомпозиции применяется при разбиении
сложных процессов на составляющие его функции.
При этом уровень детализации определяется
непосредственно разработчиком модели.
Модель IDEF0 всегда начинается с рассмотрения
системы как единого целого, т.е. одного
функционального блока с интерфейсными дугами,
простирающимися за пределы рассматриваемой
области. Такая диаграмма называется контекстнойконтекстной,
она обозначается идентификатором А-0.
Для определения границ системы на контекстной
диаграмме обязательно должны быть цель и точка
зрения.
13. Цель моделированияЦель моделирования
Цель моделирования должна отвечать на
следующие вопросы:
Почему процесс должен быть
замоделирован?
Что должна показывать модель?
Что может получить читатель?
Примеры целей: «Идентифицировать слабые
стороны процесса сбора данных»,
«Определить ответственность сотрудников
для написания должностных инструкций» и
т.п. [8]
14. Точка зренияТочка зрения
Точка зренияТочка зрения – позиция, с которой будет
строиться модель. В качестве точки зрения
берется взгляд человека, который видит
систему в нужном для моделирования
аспекте.
Как правило, выбирается точка зрения
человека, ответственного за выполнение
моделируемой работы.
Между целью и точкой зрения должно быть
жесткое соответствие.
17. Нумерация работ и диаграммНумерация работ и диаграмм
А0
Цель:
Т.зрения:
А-0
А1
А3
А2
А0
А11
А13
А12
А1
А31
А33
А32
А3
Номер контекстной
диаграммы
Номер
функционального
блока на
контекстной
диаграмме
Диаграммы
декомпозиции
имеют номер
декомпозируемого
блока
Формат номера
блока:
1. Префикс
2. Номер
родительской
работы
3. Собственный
порядковый
номер
18. Основные правила построенияОсновные правила построения
диаграммдиаграмм
1. На одной диаграмме рекомендуется рисовать от 3 до
6 блоков. Иначе диаграмма будет плохо читаемой.
2. Функциональные блоки должны располагаться слева
направо сверху вниз в порядке доминирования.
3. Следует избегать излишнего пересечения стрелок.
19. Основные правила построенияОсновные правила построения
диаграммдиаграмм
4. Выход одного блока может являться входом
(управлением) для другого. Могут быть и обратные
связи по входу и управлению.
Связь по входуСвязь по входу
Связь по управлениюСвязь по управлению
20. Основные правила построенияОсновные правила построения
диаграммдиаграмм
а) обратная связь по входуа) обратная связь по входу
б) обратная связь по управлениюб) обратная связь по управлению
Обратная связь по входу,
как правило, используется
для описания циклов.
Обратная связь по
управлению – выход
нижестоящей работы
передается на управление
вышестоящей
Обратная связь по
механизму – выход
нижестоящей работы
создает ресурсы,
выполняющие
вышестоящую работув) обратная связь по механизмув) обратная связь по механизму
21. Основные правила построенияОсновные правила построения
диаграммдиаграмм
5. Стрелки могут быть сливающимися и
разветвляющимися
Слияние стрелок
Разветвление стрелок
22. Граничные стрелкиГраничные стрелки
Стрелки на контекстной диаграмме служат для описания
взаимодействия системы с окружающим миром. Они
могут начинаться у границы диаграммы и заканчиваться у
функционального блока и наоборот. Такие стрелки
называются граничнымиграничными [8]. Граничные стрелки
помечаются с помощью ICOM-меток (Input, Control,
Output, Mechanism)
I1
I2
M1
C1
O1
O2
ICOM-метки
ICOM-метки
23. Тоннельные стрелкиТоннельные стрелки
Иногда необходимо отобразить граничные стрелки,
которые значимы на данном уровне и не значимы на
родительской диаграмме. Например, некоторые
данные используются только на данном уровне и не
используются на других. Без использования
механизма тоннелирования малозначимая стрелка
появится на всех уровнях модели, что затруднит
чтение диаграмм.
24. Глоссарий иГлоссарий и FEOFEO-страница-страница
Для каждого из элементов в IDEF0 существует
стандарт, подразумевающий создание и поддержку
набора соответствующих определений, ключевых
слов, повествований, изложений и т.д, которые
характеризуют объект, отраженный данным
элементом. Этот набор – глоссарийглоссарий, являющийся
описанием сущности данного элемента.
FEOFEO-диаграмма-диаграмма (For Exposition Only) – это
диаграмма, которая поясняет особо интересные и
тонкие аспекты диаграмм. Эти диаграммы не
ограничены синтаксисом IDEF0. В них может быть
текстовая, графическая информация, схемы,
альтернативная точка зрения на процесс и т.п.
25. Мастерская страницаМастерская страница
(каркас диаграммы)(каркас диаграммы)
Стандартный бланк для диаграмм
(облегчает подшивку и копирование)
Разделен на 3 основные части:
1) поле рабочей информацииполе рабочей информации (для отслеживания
диаграммы в процессе моделирования)
2) поле сообщенийполе сообщений (область рисования
диаграммы)
3) поле идентификацииполе идентификации (идентификация
диаграммы и ее позиционирование в иерархии)
26. Мастерская страницаМастерская страницаUSED AT: AUTHOR: FIO DATE:
REV:PROJECT: model1
27.02.2009
27.02.2009
NOTES: 1 2 3 4 5 6 7 8 9 10
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER DATE CONTEXT:
TOP
NODE: TITLE: NUMBER:
A-0
Поле сообщений
Поле
идентификации
Поле рабочей информации Статусы проекта:
1) Рабочая версия – диаграмма с
большим числом изменений на стадии
разработки
2) Эскиз имеет меньше изменений и
свидетельствует о достижении
некоторого согласия ряда читателей
3) Рекомендовано – сопутствующие
тексты утверждены
4) Публикация – материал может
печататься.
Сведения о модели:
-автор;
-название проекта;
-замечания;
-дата создания и пересмотра.
Сведения о
читателях-
экспертах и дате
экспертизы
Сведения о
родительской
работе
Название диаграммы
(совпадает с названием
родительской работы)
Номер
диаграммы
Уникальный
номер версии
диаграммы
27. Пример модели процесса постройкиПример модели процесса постройки
садового домикасадового домика
Построить дом
Материалы
Строители
Дом
Проект дома
Цель:Цель: Определить действия, необходимые для постройки дачного домика
Точка зрения:Точка зрения: владельца дачного участка
1. Строим контекстную диаграмму.
28. Пример модели процесса постройки садовогоПример модели процесса постройки садового
домикадомика
2. Декомпозируем контекстную диаграмму
Заложить
фундамент
Возвести
стены
Положить
крышу
Выполнить
отделку
Материалы
Проект дома
Строители
Дом
Каменщики Плотники Кровельщики Мастера по
отделке
Фундамент
Стены
Крыша
29. Пример модели, построенной сПример модели, построенной с
использованиемиспользованием CASECASE-средства-средства BPWinBPWin
USED AT: AUTHOR: Шилина М.А. DATE:
REV:PROJECT: Постройка дома
27.02.2009
27.02.2009
NOTES: 1 2 3 4 5 6 7 8 9 10
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER DATE CONTEXT:
TOP
NODE: TITLE: NUMBER:Построить дом
A-0
Материалы Дом
Проект дома
Строители
A0
Построить
дом
Цель: определить действия, необходимые
для постройки дачного домика
Точка зрения: Владельца дачного участка
30. Пример модели, построенной сПример модели, построенной с
использованиемиспользованием CASECASE-средства-средства BPWinBPWin
USED AT: AUTHOR: Шилина М.А. DATE:
REV:PROJECT: Постройка дома
27.02.2009
10.03.2010
NOTES: 1 2 3 4 5 6 7 8 9 10
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER DATE CONTEXT:
A-0
NODE: TITLE: NUMBER:Построить дом
A0
Проект дома
Строители
Материалы
Дом
Фу ндамент
Стены
Крыша
A1
Заложить
фу ндамент
A2
Возвести
стены
A3
Положить
крышу
A4
Выполнить
отделочные
работы
I1
O1
M1
C1
Каменщики Плотники Кровельщики
Мастера
по отделке
31. Дерево узловДерево узлов
USED AT: AUTHOR: Шилина М.А. DATE:
REV:PROJECT: Постройка дома
27.02.2009
27.02.2009
NOTES: 1 2 3 4 5 6 7 8 9 10
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER DATE CONTEXT:
A-0
TOP
NODE: TITLE: NUMBER:Построить дом
A0
USED AT: AUTHOR: Шилина М.А. DATE:
REV:PROJECT: Постройка дома
27.02.2009
27.02.2009
NOTES: 1 2 3 4 5 6 7 8 9 10
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER DATE CONTEXT:
A-0
TOP
NODE: TITLE: NUMBER:Построить дом
A0
A0
Построить
дом
A1
Заложить
фу ндамент
A2
Возвести
стены
A3
Положить
крышу
A4
Выполнить
отделочные
работы
32. FEO-FEO-страницастраница
USED AT: AUTHOR: Шилина М.А. DATE:
REV:PROJECT: Постройка дома
27.02.2009
27.02.2009
NOTES: 1 2 3 4 5 6 7 8 9 10
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER DATE CONTEXT:
A-0
NODE: TITLE: NUMBER:Построить дом
A0F
Проект дома
Строители
Материалы
Дом
Фу ндамент
Стены
Крыша
A0.1
Заложить
фу ндамент
A0.2
Возвести
стены
A0.3
Положить
крышу
A0.4
Выполнить
отделочные
работы
Каменщики Плотники Кровельщики
Мастера
по отделке
33. Итоги лекцииИтоги лекции
Изучены следующие понятия:
Структурный подход
Функциональная модель
Методология SADT/IDEF0
Функциональный блок
Интерфейсная дуга
Декомпозиция
Глоссарий
FEO-диаграмма
Дерево узлов
Мастерская страница
