A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
Cancel Create
PiRIS / articles / 5_1_1_10_uml.md
- Go to file T
- Go to line L
- Copy path
- Copy permalink
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Cannot retrieve contributors at this time
181 lines (126 sloc) 21.8 KB
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents Copy raw contents
Copy raw contents
Проектирование информационных систем на основе унифицированного языка моделирования UML
Основы унифицированного языка моделирования UML
Существует большое количество инструментальных средств, используемых для реализации проекта ИС от этапа анализа до создания программногокода. Отдельно выделяют так называемые CASE-средства верхнего уровня (upper CASE tools) и CASE-средства нижнего уровня (lower CASE tools).
Выделение бизнес-процессов верхнего уровня
Среди основных проблем использования CASE-средств верхнего уровня выделяют проблемы их адаптации под конкретные проекты, так как они жестко регламентируют процесс разработки и не дают возможности организовать работу на уровне отдельных элементов проекта. Альтернативой им может стать использование CASE-средства нижнего уровня, но их использование влечет другие проблемы – трудности в организации взаимодействия между командами, работающими над различными элементами проекта.
Средством, позволяющим объединить эти подходы, явился унифицированный язык объектно-ориентированного моделирования (Unified Modeling Language – UML). К преимуществам языка UML можно отнести разнообразные инструментальные средства, которые как поддерживают жизненный цикл ИС, так и позволяют настроить и отразить специфику деятельности разработчиков различных элементов проекта.
В конце 1980-х годов получили большое распространение объектно-ориентированные языки программирования. Тенденции их активного использования определили задачи разработки языка моделирования, дающего возможность реализовать объектно-ориентированный подход и построить наилучшую модель системы с указанием ее значимых свойств. Этим языком стал UML. В настоящее время UML как нотация моделирования ИС поддерживается рядом объектно-ориентированных CASE-продуктов.
Основными характеристиками объектно-ориентированного языка моделирования UML являются:
- организация взаимодействия заказчика и разработчика (групп разработчиков) ИС путем построения репрезентативных визуальных моделей;
- специализация базовых обозначений для конкретной предметной области.
Базовый набор диаграмм UML содержится в большом количестве средств моделирования. Однако в связи с тем, что каждая прикладная задача имеет свои особенности и не требует всех концепций в каждом приложении, язык предоставляет пользователям такие возможности, как:
10 Карта процессов верхнего уровня
- моделирование с использованием только средств «ядра» для типовых приложений;
- моделирование с использованием дополнительных условных обозначений, если они отсутствуют в «ядре», или специализация нотации и ограничений для данной предметной области.
Для поддержки моделирования различных этапов жизненного цикла ИС язык UML предлагает целую совокупность диаграмм.
При разработке концептуальной модели применяют диаграммы вариантов использования и диаграммы деятельности, модели бизнес-объектов, диаграммы последовательностей.
На этапе работы над логической моделью ИС описать требования к системе позволяют диаграммы вариантов использования, а при предварительном проектировании используют диаграммы классов, диаграммы состояний, диаграммы последовательностей.
Детальное проектирование при разработке физической модели выполняют с применением диаграмм классов, диаграмм развертывания, диаграмм компонентов.
Далее будут подробнее рассмотрены перечисленные диаграммы с указанием их назначения в процессе проектирования ИС.
Проектирование логической модели ИС и моделей баз данных
Одной из диаграмм, применяющихся на этапе проектирования логической модели ИС, является диаграмма вариантов использования (диаграмма прецедентов, use case diagram), предназначенная для построения на концептуальном уровне модели того, как функционирует система в окружающей среде. Основными элементами для построения модели прецедентов на диаграмме являются:
- актёр (actor) – элемент, обозначающий роли пользователя, который взаимодействует с определенной сущностью;
- прецедент – элемент, отражающий действия, выполняемые системой (в т.ч., с указанием возможных вариантов), которые приводят к результатам, наблюдаемым актерами.
Между прецедентами в модели могут быть установлены связи, такие, как:
- обобщение (Generalization) – указывает общность ролей;
- включение (include) – указывает взаимосвязь нескольких вариантов использования, базовый из которых всегда использует функциональное поведение связанных с ним прецедентов;
- расширение (extend) – указывает взаимосвязь базового варианта использования и вариантов использования, являющихся его специальными случаями.
Пример диаграммы вариантов использования:
Более детально описать бизнес-процессы позволяют диаграммы деятельности и диаграммы последовательностей.
Диаграмма деятельности (activity diagram) — диаграмма, использующаяся при моделировании бизнес-процессов, на которой представлено разложение на составные части некоторой деятельности, а именно: скоординированного выполнения отдельных действий и вложенных видов деятельности, которые соединяются между собой потоками от выходов одного узла к входам другого, с указанием их исполнителей.
Пример диаграммы деятельности:
Разработанные на этапе построения моделей бизнес-прецедентов диаграммы видов деятельности могут корректироваться вследствие выявления новых подробностей в описании бизнес-процессов объекта автоматизации на этапах анализа и проектирования.
Диаграмма последовательности (sequence diagram) — диаграмма, отражающая упорядоченные по времени проявления взаимодействия объектов.
На диаграмме данного типа слева направо помещаются основные элементы:
- объекты;
- вертикальные линии (lifeline), моделирующие течение времени при выполнении действий объектом; — стрелки, определяющие действия, выполняемые объектом.
Пример диаграммы последовательности:
В результате построения диаграмм на этом этапе разработаны подробные описания действий специалистов по внедрению ИС, которые необходимы для обеспечения ее функциональности.
На этапе формирования требований разрабатывается модель системных прецедентов, на которой для внутренних и внешних исполнителей указываются их конкретные обязанности с использованием ИС. Модели системных прецедентов разрабатываются на основе бизнес-моделей, построенных на предыдущем этапе, однако при этом необходимо детально описать прецеденты с определениями используемых данных и указанием последовательности их выполнения, то есть подробно описать реализацию функций проектируемой системы.
На этапе анализа требований и предварительного проектирования системы на основе построенных моделей системных прецедентов строятся диаграммы классов системы.
Диаграмма классов, являясь логическим представлением модели, представляет детальную информацию о структуре модели системы с использованием терминологии классов объектно-ориентированного программирования, а именно: о внутреннем устройстве системы (об архитектуре системы). На диаграмме классов могут быть указаны внутренняя структура и типы отношений между отдельными объектами и подсистемами, что приводит к развитию концептуальной модели системы.
Класс в языке UML обозначает некоторое множество объектов, обладающих одинаковой структурой и взаимосвязями с объектами других классов. В диаграммах классов системы указываются объекты из модели системных прецедентов с их описанием и указанием взаимосвязей между классами.
Синтаксис диаграмм классов является эффективным средством структурирования требований к элементам проектируемой системы, к их данным, интерфейсам, функциональности.
Пример диаграммы классов:
На этом этапе проектирования подробно описаны состав и функции системы в соответствии с разработанными бизнес-моделями, что дает уверенность в соответствии проектируемой системы требованиям заказчика.
На следующем этапе элементы разработанных моделей классов отображаются в элементы моделей базы данных и приложений, а именно:
- классы – в таблицы;
- атрибуты – в столбцы;
- типы – в типы данных СУБД;
- ассоциации – в связи между таблицами (в том числе, создавая дополнительные таблицы связей);
- приложения – в классы с определенными методами и атрибутами, связанными с данными в базе.
В модели базы данных для каждого простого класса формируется таблица, которая включает столбцы, поставленные в соответствие атрибутам класса.
Классы подтипов могут отображаться в таблицы несколькими способами:
- в случае отображения одной таблицы на класс отдельная таблица формируется для каждого класса с установлением последующих связей;
- в случае отображения одной таблицы на суперкласс для суперкласса создается таблица, а затем в таблицы подклассов размещаются столбцы для атрибутов суперкласса;
- в случае отображения одной таблицы на иерархию формируется единая таблица, в которой расположены атрибуты суперкласса и всех подклассов с добавлением дополнительных столбцов для определения исходных таблиц подклассов.
Язык UML для разработки проекта БД предлагает специальный профиль Profile for Database Design, в котором используются основные компоненты диаграмм, такие, как: таблица, столбец, ключи, связи, домен, процедура и тд. На диаграммах также можно указывать дополнительные характеристики столбцов и таблиц: ограничения, триггеры, типы данных и тд. В результате этого этапа проект базы данных и приложений системы становится детально описанным.
Проектирование физической модели ИС
Следующий этап проектирования системы включает в себя дополнения модели баз данных и приложений диаграммами их размещения на технических средствах.
На данном этапе рассматриваются такие понятия UML, как:
- компонент – элемент физического представления системы, реализующий определенный набор интерфейсов;
- зависимость – связь между двумя элементами, обозначающая ситуацию, при которой изменение одного элемента модели влечет за собой изменение ее другого элемента;
- процессор и устройство – узел, выполняющий и не выполняющий обработку данных соответственно;
- соединение – связь между процессорами и устройствами.
Наиболее полно особенности физического представления системы на языке UML позволяют диаграммы компонентов и диаграммы развертывания.
Диаграмма компонентов (component diagram) отображает иерархию подсистем, структурных компонентов и зависимостей между ними. Физическими компонентами выступают базы данных, исполняемые файлы, приложения, библиотеки, интерфейсы ИС и т.д. В случае использования диаграммы компонентов для отображения внутренней структуры компонентов, интерфейсы составного компонента делегируются в определенные интерфейсы внутренних компонентов.
Основными целями построения диаграмм компонентов являются:
- определение архитектуры проектируемой системы;
- построение концептуальной и физической моделей баз данных;
- представление структуры исходного и специфики исполняемого кода системы;
- многократное использование определенных фрагментов программного кода.
Пример диаграммы компонентов:
Для описания аппаратной конфигурации ИС применяют диаграмму развертывания (deployment diagram).
С помощью диаграммы развертывания моделируют физическое распределение различных программных, информационных, аппаратных компонентов системы по комплексу технических средств. Особое внимание на диаграмме развертывания уделяется отображению того, какие используются аппаратные компоненты («узлы» — серверы баз данных и приложений, веб-верверы), какие программные компоненты («артефакты» — базы данных, веб-приложения) работают на каждом из них и как части комплекса соединены друг с другом.
Пример диаграммы развертывания:
Таким образом, в случае проектирования сложной ИС ее необходимо разделить на части и исследовать каждую часть отдельно. Существуют два основных способа разбиения ИС на такие подсистемы:
- структурная (функциональная) декомпозиция;
- объектная (компонентная) декомпозиция.
Характерной особенностью объектной декомпозиции является выделением объектов (компонен- тов), взаимодействующих между собой, выполняющих определенные функции (методы) объекта. При проектировании ИС язык UML используют для визуального моделирования системы при ее разбиении на объекты. В случае функциональной декомпозиции ИС при проектировании использование UML нецелесообразно, здесь применяются другие структурные нотации, рассмотренные в предыдущих разделах.
Источник: github.com
Разработка модели процессов на верхнем уровне
На первом этапе разработки необходимо провести серию интервью – собрать информацию о деятельности компании. Обычно достаточно опросить пять-шесть руководителей верхнего уровня и ключевых специалистов, которые хорошо знают бизнес.
Используя полученную информацию, бизнес-аналитики формируют процессную модель деятельности организации на верхнем уровне (модель процессов на верхнем уровне). Для этого можно использовать любую подходящую методику построения структурных моделей верхнего уровня (ЦСЦ, IDEF0, ARIS VAD и т. д.). Важны не применяемые условные обозначения, а принципы, используемые при построении модели. Кроме того, при построении модели ЦСЦ полезно описывать не только основные, создающие ценность процессы (группы процессов, деятельность), но и управляющие, обеспечивающие.
Как правило, при помощи структурной модели процессов верхнего уровня удается получить информацию о возможном перечне процессных категорий и групп, то есть создать основу процессного дерева.
Рис. 3.5.1. Пример схемы процессов верхнего уровня (схема цепочки создания ценности)
* Серой заливкой показаны процессы, выполняемые внешними контрагентами данной организации.
Состав и группировка процессов на рис. 3.5.1 не являются идеальными. Но не следует забывать, что построение модели верхнего уровня – это только инструмент анализа деятельности организации, используемый для формирования системы процессов.
Как правило, для построения модели процессов верхнего уровня приходится делать несколько итераций.
Если начинать моделирование с самого верхнего уровня, то почти для всех компаний сформируется похожая схема: закупка – производство – сбыт. Но такая упрощенная модель не содержит информации о конкретной организации и поэтому не считается ценной. Модель верхнего уровня полезна для понимания процессов только в том случае, если она отражает особенности бизнеса организации, причем в понятной для топ-менеджеров и собственников форме.
Рис. 3.5.2 обобщает пример, представленный на рис. 3.5.1. На нем показано, как используется структурная схема процессов организации на верхнем уровне при построении системы процессов. Категория процессов (процессы верхнего уровня) – это основа для формирования процессного дерева.
Далее определяются процессы второго уровня – группы процессов. Причем на модели верхнего уровня следует показывать минимальное количество связей: нужны только наиболее важные, системообразующие. Ни в коем случае нельзя показывать детальные потоки документов (информации) – это сделает модель нечитаемой. Модель верхнего уровня – эскизная. Она нужна для обоснованного формирования структуры процессных категорий и групп в системе процессов организации.
Рис. 3.5.2. Использование модели процессов верхнего уровня для построения системы процессов
Для формирования третьего уровня используем информацию о деятельности структурных подразделений организации. При этом важно не забыть про сквозные (кросс-функциональные) процессы.
Итак, основа для формирования системы процессов – процессный взгляд на организацию на уровне бизнеса, а информацию для наполнения системы детальными процессами (начиная с третьего уровня) получаем из матриц процессов структурных подразделений.
Отмечу, что при переносе информации из модели верхнего уровня в таблицу процессов организации не всегда возникает однозначное соответствие, поскольку:
• часть процессов может отсутствовать на схеме, но должна быть включена в матрицу (например, вспомогательные процессы);
• процессы могут быть перегруппированы (для получения более адекватного решения);
• некоторые процессы могут быть сгруппированы (то есть изменен уровень);
• некоторые процессы могут быть добавлены на основе стратегического ви2дения собственников;
Работа по формированию матрицы процессов на основе модели верхнего уровня – дело творческое. Как правило, требуется проделать несколько итераций, чтобы матрица процессов соответствовала реальному бизнесу компании.
Построение модели процессов на верхнем уровне – не самоцель, а средство понимания деятельности организации с процессной точки зрения.
Источник: studopedya.ru
Модель бизнес-процессов верхнего уровня предприятия
Создание моделей бизнес-процессов верхнего уровня организации является важнейшей задачей.
Можно выделить несколько целей описания бизнес-процессов верхнего уровня организации:
· понимание основ деятельности организации;
· увязка результатов деятельности (выходов) и процессов, определение границ процессов;
· определение проблемных областей при выполнении процессов;
· подготовка фронта работ для детального описания процессов.
Для систематизации процессов компании всю деятельность организации (компании, предприятия) разумно разделить на три крупных блока:
Основная деятельность (основные бизнес-процессы) — направлена на создание ценности для внешнего потребителя. Основные бизнес-процессы формируют денежные поступления в организацию и являются основой ее конкурентоспособности.
Вспомогательная деятельность (обеспечивающие бизнес-процессы и сервисы) — ориентирована на создание ценности для внутреннего потребителя. Вспомогательные бизнес-процессы и сервисы ориентированы на поддержание основных бизнес-процессов посредством:
· своевременного предоставления необходимых ресурсов и услуг;
· минимизации затрат на обеспечение основной деятельности необходимыми ресурсами и услугами.
Управленческая деятельность (функциональные системы управления, составляющие единую систему управления деятельностью предприятия) — ориентирована на обеспечение согласованности основных и вспомогательных бизнес-процессов и сервисов, достижение общих организационных целей. По сути дела, эти процессы порождают ту общую инфраструктуру и общие правила «игры», которые позволяют существовать каждому отдельному бизнес-процессу или сервису. Как правило, в нашей практике мы выделяем следующие основные подсистемы управления:
· стратегическое управление (общее координирование на горизонтах более 1 года),
· операционное управление (общее координирование на горизонтах от года до месяца/недели, включает в себя бюджетирование),
· организационное управление (структурирование организации и формирование регламентной основы для ее функционирования),
· маркетинг и заключение доходных договоров (относится сюда только в некоторых случаях, когда договорная работа основана на личном авторитете или связях руководителя организации),
· обеспечение безопасности ведения бизнеса (конкретное наполнение данного блока может сильно отличаться для разных типов организаций и отраслей).
Рисунок 1. Модель бизнес-процессов верхнего уровня предприятия (санатория)
Модель закрепления ответственности за бизнес-процессы по каждой категории процессов
Процессная модель предприятия — это состав бизнес-процессов, закрепленных за структурными подразделениями, обеспечивающих жизненный цикл ресурсов предприятия, устав предприятия, положения о структурных подразделениях и должностные инструкции. Процессная модель предприятия включает в себя множество бизнес-процессов, участниками которых являются структурные подразделения и должностные лица иерархической организационной структуры предприятия. Под бизнес-процессом понимается совокупность различных видов деятельности, которые создают результат, имеющий ценность для потребителя, клиента или заказчика.
Встает вопрос о дифференцировании ресурсов и закрепленных за ними дифференцированных производственных процессов для конкретного предприятия, а также закрепления за структурными подразделениями предприятия бизнес-процессов и основных функций в разрезе каждого бизнес-процесса. Решение данного вопроса позволяет во взаимной увязке определить основные производственные и управленческие функции в разрезе всех ресурсов и структурных подразделений предприятия. Эти функции должны отражать замкнутость контура управления по каждому бизнес-процессу.
Проектирование процессной модели предприятия предполагает разработку матрицы матрицу закрепления бизнес-процессов за структурными подразделениями.
Матрица закрепления дифференцированных бизнес-процессов за структурными подразделениями формируется предварительно на основании модели бизнес-процессов верхнего уровня предприятия и существующей организационной структуры. Матрица должна быть построена по следующим правилам:
· любая функция должна выполняться только одним структурным подразделением, то есть не должно быть дублирования функций;
· каждая функция должна быть закреплена за структурным подразделением, то есть не должно быть «повисших» функций.
Модель закрепления ответственности за бизнес-процессы по каждой категории процессов
Процессы верхнего уровня
Ответственные руководители (владелец процесса)
У1. Стратегическое управление
Заместитель ГД по корпоративной политике, стратегии и правовому обеспечению
Департамент корпоративной политики и управления капиталом
У2. Управление финансами
Заместитель ГД по экономике и финансам
Департамент корпоративных финансов, Департамент экономического планирования и анализа
У3. Оперативное управление
Помощник ГД — начальник отдела по рекламе
Отдел по рекламе
У4. Управление бизнес-процессами и качеством
У5. Управление проектами развития
Руководитель проектного офиса
О1. Закупка оборудования
Заместитель ГД по логистике
Департамент технического развития и инвестиций
О2. Установка оборудования
Заместитель ГД по технической политике
Департамент технического развития и инвестиций
О3. Предоставление лечения
Заместитель ГД по маркетингу
Департамент по связям с общественностью и маркетингу
В1. Административно- хозяйственное управление
Заместитель ГД по административно-хозяйственной части
Департамент по хозяйственной части
В2. ИТ-обеспечение и связь
Заместитель ГД по технической политике
Департамент информационных технологий
В3. Обеспечение безопасности
Заместитель ГД по организационной работе
Департамент информационно-аналитической политики
В4. Юридическое обеспечение
Заместитель ГД по корпоративной политике, стратегии и правовому обеспечению
Департамент правового обеспечения
В5.Ремонт и модернизация всего оборудования
Заместитель ГД по технической политике
Департамент управления производством и охраной труда
На основании матрицы закрепления бизнес-процессов за структурными подразделениями формируются заготовки таблиц производственных и управленческих функций в разрезе ресурсов по каждому структурному подразделению.
Классификатор бизнес-процессов
информационный логический модель санаторий
В дальнейшем выделенные процессы детализируют и создают классификатор бизнес-процессов предприятия.
Каждый бизнес-процесс верхнего уровня компании можно разделить на первую детализацию и вторую (более подробную детализацию). Также при построении классификатора бизнес-процесса необходимо выделить владельца процесса.
Таблица 2
Бизнес-процессы верхнего уровня компания
Первая детализация бизнес-процесса верхнего уровня
Вторая детализация бизнес-процесса верхнего уровня
Бизнес-процессы управления (у)
У1. Стратегическое и оперативное управление
У1.1 Стратегическое управление
У1.1.1 Стратегическое планирование
У1.1.2 Управление проектами развития
У1.1.3 Управление инвестиционными проектами
У1.2 Оперативное управление
У1.2.1 Обеспечение соответствия оперативного управления стратегическому планированию
У1.2.2 Управление бизнес-процессами
Генеральный директор (первый заместитель Генерального директора)
У1.2.3 Административное управление
У2. Управление финансами
Заместитель ГД по финансам
У2.1 Управление активами
Заместитель ГД по финансам
У2.1.1 Материальные активы
Заместитель ГД по финансам
У 2.1.2 Невещественные активы
Заместитель ГД по финансам
У2.2 Бухгалтерский учет
У 2.2.2 Баланс и отчетность
Источник: studentopedia.ru