Файл: Моделирование предметной области «Управление персоналом» с помощью UML (Анализ существующей системы предметной области «Архангельская генерация).pdf
Добавлен: 02.04.2023
Просмотров: 232
Скачиваний: 2
Глава 2. Разработка мероприятия по повышению эффективности моделирования предметной области «Управление персоналом»
2.1 Теоретические аспекты UML моделирования предметной области
В основе проектирования ИС лежит моделирование предметной области.
Модель предметной области – это некоторая система, имитирующая структуру или функционирование исследуемой предметной области и отвечающая основному требованию – быть адекватной этой области.
К моделям предметных областей предъявляются следующие требования:
– формализация, обеспечивающая однозначное описание структуры предметной области;
– понятность для заказчиков и разработчиков на основе применения графических средств отображения модели;
– реализуемость, т.е. наличие средств физической реализации модели предметной области в ИС;
– обеспечение оценки эффективности реализации модели предметной области на основе определенных методов и вычисляемых показателей[7].
Для реализации перечисленных требований, как правило, строится система моделей, которая отражает структурный и оценочный аспекты функционирования предметной области.
Структурный аспект предполагает построение:
– объектной структуры, отражающей состав взаимодействующих в процессах материальных и информационных объектов предметной области;
– функциональной структуры, отражающей взаимосвязь функций (действий) по преобразованию объектов в процессах;
– структуры управления, отражающей события и бизнес-правила, которые воздействуют на выполнение процессов;
– организационной структуры, отражающей взаимодействие организационных единиц предприятия и персонала в процессах;
– технической структуры, описывающей топологию расположения и способы коммуникации комплекса технических средств[8].
Язык моделирования – это нотация, в основном графическая, которая используется для описания проектов.
Нотация представляет собой совокупность графических объектов, используемых в модели.
Нотация является синтаксисом языка моделирования.
Главный критерий адекватности структурной модели предметной области – это функциональная полнота разрабатываемой ИС.
Оценочные аспекты моделирования предметной области связаны с разрабатываемыми показателями эффективности автоматизируемых процессов, к которым относятся:
– время решения задач;
– стоимостные затраты на обработку данных;
– надежность процессов;
– косвенные показатели эффективности (объемы производства, производительность труда, оборачиваемость капитала, рентабельность и т.д.)[9]
В основе различных методологий моделирования предметной области ИС лежат принципы последовательной детализации. Обычно модели строятся на трех уровнях:
– внешний уровень (определение требований): модель отвечает на вопрос, что должна делать система, то есть определяется состав основных компонентов системы: объектов, функций, событий, организационных единиц, технических средств.
– концептуальный уровень (спецификация требований): модель отвечает на вопрос, как должна функционировать система, т.е. определяется характер взаимодействия компонентов системы.
– внутренний уровень (реализация требований): модель отвечает на вопрос: с помощью каких программно-технических средств реализуются требования к системе.
UML – это унифицированный графический язык моделирования для описания, визуализации, проектирования и документирования ОО систем. UML призван поддерживать процесс моделирования ПС на основе ОО подхода, организовывать взаимосвязь концептуальных и программных понятий, отражать проблемы масштабирования сложных систем. Модели на UML используются на всех этапах жизненного цикла ПС, начиная с бизнес-анализа и заканчивая сопровождением системы. Разные организации могут применять UML по своему усмотрению в зависимости от своих проблемных областей и используемых технологий[10].
К середине 90-х годов различными авторами было предложено несколько десятков методов ОО моделирования, каждый из которых использовал свою графическую нотацию. При этом любой их этих методов имел свои сильные стороны, но не позволял построить достаточно полную модель ПС, показать ее «со всех сторон», то есть, все необходимые проекции. К тому же отсутствие стандарта ОО моделирования затрудняло для разработчиков выбор наиболее подходящего метода, что препятствовало широкому распространению ОО подхода к разработке ПС.
По запросу Object Management Group (OMG) – организации, ответственной за принятие стандартов в области объектных технологий и баз данных назревшая проблема унификации и стандартизации была решена авторами трех наиболее популярных ОО методов – Г.Бучем, Д.Рамбо и А.Джекобсоном, которые объединенными усилиями создали версию UML 1.1, утвержденную OMG в 1997 году в качестве стандарта[11]..
UML – это язык.
Любой язык состоит из словаря и правил комбинирования слов для получения осмысленных конструкций. Так, в частности, устроены языки программирования, таковым является и UML. Отличительной его особенностью является то, что словарь языка образуют графические элементы. Каждому графическому символу соответствует конкретная семантика, поэтому модель, созданная одним разработчиком, может однозначно быть понята другим, а также программным средством, интерпретирующим UML. Отсюда, в частности, следует, что модель ПС, представленная на UML, может автоматически быть переведена на ОО язык программирования (такой, как Java, C++, VisualBasic), то есть, при наличии хорошего инструментального средства визуального моделирования, поддерживающего UML, построив модель, мы получим и заготовку программного кода, соответствующего этой модели[12].
Следует подчеркнуть, что UML – это именно язык, а не метод. Он объясняет, из каких элементов создавать модели и как их читать, но ничего не говорит о том, какие модели и в каких случаях следует разрабатывать. Чтобы создать метод на базе UML, надо дополнить его описанием процесса разработки ПС. Примером такого процесса является Rational Unified Process.
Модель представляется в виде сущностей и отношений между ними, которые показываются на диаграммах.
Сущности – это абстракции, являющиеся основными элементами моделей. Имеется четыре типа сущностей – структурные (класс, интерфейс, компонент, вариант использования, кооперация, узел), поведенческие (взаимодействие, состояние), группирующие (пакеты) и аннотационные (комментарии). Каждый вид сущностей имеет свое графическое представление[13].
Отношения показывают различные связи между сущностями. В UML определены следующие типы отношений:
– зависимость показывает такую связь между двумя сущностями, когда изменение одной из них – независимой – может повлиять на семантику другой – зависимой. Зависимость изображается пунктирной стрелкой, направленной от зависимой сущности к независимой.
– ассоциация – это структурное отношение, показывающее, что объекты одной сущности связаны с объектами другой. Графически ассоциация показывается в виде линии, соединяющей связываемые сущности. Ассоциации служат для осуществления навигации между объектами. Например, ассоциация между классами «Заказ» и «Товар» может быть использована для нахождения всех товаров, указанных в конкретном заказе – с одной стороны, или для нахождения всех заказов в которых есть данный товар, – с другой. Понятно, что в соответствующих программах должен быть реализован механизм, обеспечивающий такую навигацию. Если требуется навигация только в одном направлении, оно показывается стрелкой на конце ассоциации. Частным случаем ассоциации является агрегирование – отношение вида «целое» – «часть». Графически оно выделяется с помощью ромбика на конце около сущности-целого.
– обобщение – это отношение между сущностью-родителем и сущностью-потомком. По существу, это отношение отражает свойство наследования для классов и объектов. Обобщение показывается в виде линии, заканчивающейся треугольничком направленным к родительской сущности. Потомок наследует структуру (атрибуты) и поведение (методы) родителя, но в то же время он может иметь новые элементы структуры и новые методы. UML допускает множественное наследование, когда сущность связана более чем с одной родительской сущностью.
– реализация – отношение между сущностью, определяющей спецификацию поведения (интерфейс) с сущностью, определяющей реализацию этого поведения (класс, компонент). Это отношение обычно используется при моделировании компонент[14].
В UML предусмотрены следующие диаграммы:
1. Диаграммы, описывающие поведение системы:
– диаграммы состояний (State diagrams),
– диаграммы деятельностей (Activity diagrams),
– диаграммы объектов (Object diagrams),
– диаграммы последовательностей (Sequence diagrams),
– диаграммы взаимодействия (Collaboration diagrams);
2. Диаграммы, описывающие физическую реализацию системы:
– диаграммы компонент (Component diagrams);
– диаграммы развертывания (Deployment diagrams)[15].
Для того чтобы модель была хорошо понимаемой человеком необходимо организовать ее иерархически, оставляя на каждом уровне иерархии небольшое число сущностей. UML включает средство организации иерархического представления модели – пакеты. Любая модель состоит из набора пакетов, которые могут содержать классы, варианты использования и прочие сущности и диаграммы. Пакет может включать другие пакеты, что позволяет создавать иерархии. В UML не предусмотрено отдельных диаграмм пакетов, но они могут присутствовать на других диаграммах. Пакет изображается в виде прямоугольника с закладкой[16].
Что обеспечивает UML.
– иерархическое описание сложной системы путем выделения пакетов;
– формализацию функциональных требований к системе с помощью аппарата вариантов использования;
– детализацию требований к системе путем построения диаграмм деятельностей и сценариев;
– выделение классов данных и построение концептуальной модели данных в виде диаграмм классов;
– выделение классов, описывающих пользовательский интерфейс, и создание схемы навигации экранов;
– описание процессов взаимодействия объектов при выполнении системных функций;
– описание поведения объектов в виде диаграмм деятельностей и состояний;
– описание программных компонент и их взаимодействия через интерфейсы;
– описание физической архитектуры системы[17].
Несмотря на всю привлекательность UML, его было бы затруднительно использовать при реальном моделировании ПС без инструментальных средств визуального моделирования. Такие средства позволяют оперативно представлять диаграммы на экране дисплея, документировать их, генерировать заготовки программных кодов на различных ОО языках программирования, создавать схемы баз данных. Большинство из них включают возможности реинжиниринга программных кодов – восстановления определенных проекций модели ПС путем автоматического анализа исходных кодов программ, что очень важно для обеспечения соответствия модели и кодов и при проектировании систем, наследующих функциональность систем-предшественников.
2.2 Построение дерева целей
Использование метода дерево целей производится в соединении с экспертными процедурами. Место ряда экспертных вероятностей и оценок могут занять разнообразные математические модели и оценки, полученные на основе формализованных методов анализа.
Методы анализа и моделирования целей опираются на процедуры декомпозиции, синтеза и оценки. Сначала общие цели сводятся к частным, упорядочиваются в виде дерева целей. Расщепление проводится до целей, поддающихся количественной или качественной оценке. В результате формируется система частных оценочных критериев. В свою очередь, частные критерии сворачиваются в агрегаты для получения оценок более общих целей и упорядочиваются в виде дерева показателей. В итоге дерево вербально заданных целей проецируется в некоторое дерево оценочных показателей[18].
Построение дерева идет «сверху вниз», от общих целей к частным, путем их дезагрегирования, декомпозиции и редукции. Так, достижение главной цели обеспечивается за счет реализации целей первого уровня.