- •Основные подходы к построению моделей системы.
- •Структурный подход к моделированию бизнес-процессов. Базовые принципы структурного подхода в проектировании.
- •Модель idef0, синтаксис диаграмм, примеры. Правила и процедуры метода idef0.
- •Idef3 имеет прямую взаимосвязь с методологией – каждая функция (функциональный блок idef0) может быть представлена в виде отдельного процесса средствами idef3.
- •Два типа диаграмм в idef3
- •Dfd модель, синтаксис диаграмм, примеры. Использование dfd диаграммы потоков данных для описания структуры проектируемой системы.
- •Принципы объектного подхода (абстрагирование, инкапсуляция, модульность, иерархия).
- •Примеры сложных систем
- •Пять признаков сложной системы
- •Организованная и неорганизованная сложность
- •Элементы объектной системы (состояние, поведение, класс, атрибут). Объектно-ориентированный подход к моделированию бизнес-процессов. Объектно-ориентированный анализ.
- •Язык моделирования uml и его применение
- •Модель бизнес-процессов uml. Стереотипы модели. Отличия uml от idef0, dfd.
- •Основные понятия моделирования бизнес-процессов.
- •Методика проектирования rup (Rational Unified Process).
- •Принципы
Основные понятия моделирования бизнес-процессов.
Модель - любой образ, аналог, описание, схема, чертеж - (т.е. знаковая синтагма - В.Р.) к-л процесса или явления. Модель не должна быть сложнее объекта, который она моделирует. Моделирование - это иссл. объектов путем построения и изучения их моделей (т.е. мы делаем знаковые преобразования с МОДЕЛЬЮ как знаком исходноного объекта - денотата, надеясь, что это будет справедливо по отношения к самому объекту - денотату. - В.Р.) Поэтому модель ограничена по своей сути. Бизнес-моделирование представляет собой процесс разработки различных бизнес-моделей предприятия (стратегия, процессы, оргструктура, ресурсы и т.п.) с целью формализации и оптимизации деятельности предприятия. Сразу напрашивается определение, что такое бизнес-модель. Бизнес-модель – это формализованное описание (графическое, табличное, в некоторых случаях текстовое, либо в нотации специализированного программного продукта) определенного аспекта или сферы деятельности предприятия. Например, модели стратегических целей и показателей, стратегические карты, модели бизнес-процессов, модели оргструктуры, модели библиотек документов и т.п. Исходя из определения бизнес-модели, существует 4 основных способа разработки бизнес-моделей. Перечислим их в порядке убывания уровня эффективности построения и использования бизнес-моделей. - В нотации (правилах) специализированного программного продукта: комбинация графики, таблиц и текста. - Графический: дерево, блок-схема, технологическая карта и т.п. - Табличный - Текстовый Один из самых распространенных способов построения бизнес-моделей – это дерево (или иерархический список), которое позволяет перечислить все элементы бизнес-модели, показать связи (подчинение, включение и т.п.) между ними и параметры каждого элемента. Таблица также является распространенным способом построения бизнес-моделей, который позволяет перечислить все элементы бизнес-модели (по строкам) и дать им подробные характеристики (по столбцам). Самый известный пример – это матрица (таблица) распределения ответственности. Наименее эффективным способом построения бизнес-моделей является текстовое описание. В тексте очень проблематично формализовать сложные бизнес-модели, отследить взаимосвязи между их элементами. Самый оптимальный вариант – это комбинация 3-х способов разработки бизнес-моделей (графика, таблица, текст), который и реализован во всех профессиональных продуктах бизнес-моделирования.
Если совокупность бизнес-моделей охватывает большинство основных сфер деятельности и систем управления в банке, то такая совокупность называется Комплексной бизнес-моделью банка. Комплексная бизнес-модель банка, которая содержит типовые успешные практики и решения, типовые модели, документы, регламенты по основным областям менеджмента и бизнес-инжиниринга в банке, называется Комплексной типовой бизнес-моделью банка.
Методика проектирования rup (Rational Unified Process).
Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software.
Принципы
В основе RUP лежат следующие принципы:
Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.
Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов (вариантов использования)).
Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.
Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.
Постоянное обеспечение качества на всех этапах разработки проекта (продукта).
Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.
Проектирование структуры потоков управления.
Моделирование структурной организации потоков управления состоит из следующих шагов:
Установите контекст взаимодействия. Это может быть система, подсистема, операция, класс или один из сценариев прецедента либо кооперации.
Определите сцену для взаимодействия, выяснив, какие объекты принимают в нем участие. Разместите их на диаграмме кооперации в виде вершин графа так, чтобы более важные объекты оказались в центре диаграммы, а их соседи - по краям.
Определите начальные свойства каждого из этих объектов. Если значения атрибутов, помеченные значения, состояния или роли объектов изменяются во время взаимодействия, поместите на диаграмму дубликаты с новыми значениями и соедините их сообщениями со стереотипами becomeи сору? сопроводив их соответствующими порядковыми номерами.
Детально опишите связи между объектами, вдоль которых передаются сообщения. Для этого: - сначала нарисуйте связи-ассоциации. Они наиболее важны, поскольку представляют структурные соединения; - после этого нарисуйте остальные связи, дополнив их соответствующими стереотипами пути (такими, как globalили local), чтобы явным образом показать, как объекты связаны друг с другом.
Начав с сообщения, инициирующего взаимодействие, присоедините все последующие сообщения к соответствующим связям, задав порядковые номера. Вложенность показывайте с помощью нотации Дьюи.
Если требуется специфицировать временные или пространственные ограничения, дополните сообщения отметками времени и присоедините нужные ограничения.
Если требуется описать поток управления более формально, присоедините к каждому сообщению пред- и постусловия .
Как и в случае диаграмм последовательностей, на одной диаграмме кооперации можно показать только один поток управления (хотя нотация UML для итераций и ветвлений помогает проиллюстрировать простые вариации). Поэтому, как правило, создают несколько диаграмм взаимодействий, одни из которых считаются основными, а другие описывают альтернативные пути и исключительные условия. Такие наборы диаграмм кооперации можно организовать в пакеты , дав каждой диаграмме подходящее имя, отличающее ее от остальных.
Проектирование конфигурации системы