699

1.2. Разработка и анализ бизнес-модели. Трансформации бизнес-модели в объекты базы данных. Функциональное моделирование

Определяются основные задачи АИС, проводится декомпозиция задач по модулям и определяются функции, с помощью которых решаются эти задачи (рис. 2). Описание функций осуществляется на языке производственных (описание процессов предметной области), функциональных (описание форм обрабатываемых документов) и технических требований (аппаратное, программное, лингвистическое обеспечение АИС) [3].

Метод решения: Функциональное моделирование

Результат:

1.Концептуальная модель АИС, состоящая из описания предметной области, ресурсов и потоков данных, перечень требований и ограничений к технической реализации АИС.

2.Аппаратно-технический состав создаваемой АИС

[3].

Рис. 2. Последовательность трансформации бизнес-модели в объекты БД и приложения

21

1.2.1. Разработка и анализ бизнес-модели

При построении эффективной автоматизированной системы первым этапом является исследование и формализация бизнес-процессов деятельности банка или предприятия. Другими словами, описание системы ведения делопроизводства с целью эффективного использования информации для достижения поставленных задач и решения проблем, стоящих перед организацией. Организация работы с документами является важной составной частью процессов управления и принятия управленческих решений, существенно влияющей на оперативность и качество управления. Процесс принятия управленческого решения включает в себя получение информации, переработку информации, анализ, подготовку и принятие решения. Все эти этапы самым тесным образом связаны с документационным обеспечением процессов управления, проектирования и производства [3].

1.2.2. Организационный анализ компании. Моделирование процессов средствами UML

Бизнес-модель компании представляет организационный анализ компании. В организационной модели указываются руководитель, отделы по руководству деятельностью организации, коммерческие службы и т.д. (рис. 3).

Администрация Секретариат

Рис. 3. Организационная структура предприятия

22

Составляются диаграммы для конкретных отделов. На рис. 4 представлена организационная структура отдела продаж.

Рис. 4. Организационная структура отдела продаж

Организационный анализ предполагает построение комплекса взаимосвязанных информационных моделей компании. Модели полно и точно описывают компанию и позволяют разработать понятные требования к проектируемой информационной системе.

Реинжиниринг технологических процессов решает следующие задачи: определение автоматизированной предметной области, подлежащей преобразованию; декомпозиция уровня информационной поддержки средствами UML-диаграмм; внедрение изменений в полученную логическую модель; переход к физической реализации [35].

В терминах языка UML технологический процесс можно выразить как диаграмму последовательностей, диаграмму взаимодействия или диаграмму видов деятельности.

Диаграмма последовательностей отображает взаимодействия объектов, временные особенности передачи и приема сообщений объектами.

23

Диаграмма сотрудничества позволяет описать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений. На этом типе диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта и типы этих сообщений [24].

1.2.3. Моделирование данных

Моделирование данных в инженерии программного обеспечения – это процесс создания модели данных для информационной системы путем применения к данным методов моделирования.

Диаграммы структурного системного анализа

Под структурным системным анализом принято понимать метод исследования системы, который начинается с наиболее общего ее описания с последующей детализацией представления отдельных аспектов ее поведения и функционирования. При этом общая модель системы строится в виде некоторой иерархической структуры, которая отражает различные уровни абстракции с ограниченным числом компонентов на каждом из уровней. Одним из главных принципов структурного системного анализа является выделение на каждом из уровней абстракции только наиболее существенных компонентов или элементов системы [8].

В программной инженерии принято рассматривать три вида структурных диаграмм: диаграммы «сущность-связь»

(Entity-Relationship Diagrams, ERD), диаграммы функционального моделирования (Structured Analysis and Design Technique, SADT) и диаграммы потоков данных (Data Flow Diagrams, DFD).

Структурные диаграммы UML

В UML существует четыре структурных диаграммы для визуализации, специфицирования, конструирования и

24

документирования статических аспектов системы. Названия структурных диаграмм UML соответствуют названиям основных групп сущностей, используемых при моделировании системы:

–диаграммы классов – классам, интерфейсам и кооперациям;

–диаграммы объектов – объектам;

–диаграммы компонентов – компонентам;

–диаграммы развертывания – узлам.

На диаграмме классов изображают множество классов, интерфейсов, коопераций и их отношений. Это самый распространенный тип диаграмм, применяемый при моделировании объектно-ориентированных систем; он используется для иллюстрации статического вида системы с точки зрения проектирования. Диаграммы, на которых показаны активные классы, применяются для работы со статическим видом системы с точки зрения процессов.

На диаграмме объектов показывают множество объектов и отношения между ними. Такие диаграммы используются для иллюстрации структуры данных, т.е. статических «мгновенных снимков» экземпляров тех сущностей, которые представлены на диаграмме классов. Диаграммы объектов, так же как и диаграммы классов, относятся к статическому виду системы с точки зрения процессов, но заостряют внимание на реальных или модельных прецедентах.

На диаграммах компонентов показаны множества компонентов и отношения между ними. С их помощью иллюстрируют статический вид системы с точки зрения реализации. Диаграммы компонентов соотносятся с диаграммами классов, так как обычно компонент отображается на один или несколько классов, интерфейсов или коопераций.

На диаграммах развертывания представлены узлы и отношения между ними. С помощью таких изображений иллюстрируют статический вид системы с точки зрения

25

развертывания. Они соотносятся с диаграммами компонентов, так как узел обычно содержит один или несколько компонентов.

Существует несколько распространенных разновидностей четырех основных типов диаграмм, названных по основным содержащимся в них объектам. Например, для иллюстрации структурной декомпозиции системы на подсистемы можно использовать диаграмму подсистем, которая представляет собой обыкновенную диаграмму классов, содержащую главным образом подсистемы.

Диаграммы поведения

Пять основных диаграмм поведения в UML используются для визуализации, специфицирования, конструирования и документирования динамических аспектов системы. Диаграммы поведения в UML условно разделяются на пять типов в соответствии с основными способами моделирования динамики системы:

–диаграммы прецедентов описывают организацию поведения системы;

–диаграммы последовательностей акцентируют внимание на временной упорядоченности сообщений;

–диаграммы кооперации сфокусированы на структурной организации объектов, посылающих и получающих сообщения;

–диаграммы состояний описывают изменение состояния системы в ответ на события;

–диаграммы деятельности демонстрируют передачу управления от одной деятельности к другой.

На диаграммах прецедентов показывается совокупность вариантов использования (прецедентов), актеров (частный случай классов) и отношений между ними. С помощью таких диаграмм иллюстрируют статический вид сис-

26

темы с точки зрения прецедентов, что особенно важно для ее организации и моделирования ее поведения.

Для моделирования динамики системы можно воспользоваться диаграммами последовательностей и кооперации.

На диаграмме последовательностей основное внимание уделяется временной упорядоченности событий. На них изображают множество объектов и посланные или принятые ими сообщения. Объекты, как правило, представляют собой анонимные или именованные экземпляры классов, но могут быть также экземплярами других сущностей, таких как кооперации, компоненты или узлы. Диаграммы последовательностей относятся к динамическому виду сис-

темы [35].

Диаграммы кооперации заостряют внимание на структурной организации объектов, принимающих или отправляющих сообщения. На диаграмме кооперации показано множество объектов, связи между ними и сообщения, которые они посылают или получают. Объекты обычно представляют собой анонимные или именованные экземпляры классов, но могут быть также экземплярами других сущностей, например коопераций, компонентов и узлов. Диаграммы коопераций относятся к динамическому виду системы.

Диаграмма состояний показывает автомат, содержащий состояния, переходы, события и действия. Диаграммы такого рода относятся к динамическому виду системы и особенно важны при моделировании поведения интерфейса, класса или кооперации. Основное внимание в них уделяется порядку возникновения событий, связанных с объектом, что особенно полезно при моделировании реактивных систем [8].

На диаграммах деятельности изображают передачу управления от одной деятельности к другой внутри систе-

27

мы. На них показаны виды деятельности, последовательные или параллельные ветвления потока управления и объекты, которые воздействуют на что-либо или сами подвергаются воздействию. Диаграммы деятельности относятся к динамическому представлению системы и особенно важны при моделировании ее функций. Они являются особой разновидностью диаграмм состояния. На диаграммах деятельности основное внимание уделено потоку управления между объектами.

Обзор CASE-средств для построения диаграмм UML

UML – CASE-средства – программы специального вида, средство моделирования, используемое с целью облегчить труд проектировщика. CASE-средства помогут вам построить профессионально выглядящие диаграммы [6].

•CASE-средства (от Computer Aided Software/System Engineering) позволяют проектировать любые системы на компьютере. Необходимый элемент системного и струк- турно-функционального анализа, CASE-средства позволяют моделировать бизнес-процессы, базы данных, компоненты программного обеспечения, деятельность и структуру организаций. Rational Rose пригодится при решении практически любых задач проектирования информационных систем: от анализа бизнес-процессов до генерации кода на определенном языке программирования. Позволяет спроектировать новую систему и доработать старую, произведя процесс обратного проектирования.

•Rational Rose Modeler позволяет выполнять анализ бизнес-процессов и проектировать систему.

•Rational Rose Professional позволяет выполнять пря-

мое и обратное проектирование. Продукт нацелен и на аналитиков, и на разработчиков.

•Rational Rose RealTime позволяет проводить прямое

иобратное проектирование на языках С или С++. На выхо-

28

де модель автоматически компилируется и собирается в исполняемый файл. Продукт предназначен для разработчиков.

•Rational Rose Enterprise полная версия. Поддержива-

ются все функции других редакций. Это программный пакет для всех участников проекта.

•Rational Rose DataModeler по проектированию баз данных. Функции DataModeler входят в состав Rose Enterprise или Professional [6].

Rational Rose поддерживает прямое и обратное проектирование на языках: ADA, Java, С, C++, Basic, поддержка технологий COM, DDL, XML, возможность генерации схем БД Oracle и SQL. Большой интерес представляет обратное проектирование (reverse engineering), когда по исходному коду восстанавливается диаграмма классов, позволяющая понять структуру программы.

Также Rational Rose имеет открытый API, позволяющий самостоятельно создавать модули для других языков программирования. На рынке уже имеется достаточное число модулей для популярных языков программирования

иRAD-систем. Одна из ведущих компаний в области создания дополнительных модулей Ensemble Systems.

Rational Rose много раз признавалось различными изданиями лучшим средством проектирования. С помощью Visual Modeler можно рисовать диаграммы классов в трех различных нотациях – нотации Буча, ОМТ и на UML. По диаграммам классов можно провести генерацию каркасного кода (на C++, VB или Java). Такая генерация программного кода называется прямым проектированием (forward engineering). Взаимозависимости классов, изображенных на диаграмме классов, отображаются в программном коде.

Другие программы для построения диаграмм Borland Together, Sparx Systems Enterprise Architect, Gentleware Poseidon, SmartDraw, Dia, Telelogic TAU G2, StarUML [6].

29

Диаграммы потоков данных. Контекстная диаграмма АИС

DFD (Data Flow Diagrams) – диаграммы потоков дан-

ных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ. Для описания диаграмм DFD используются две нотации – Йордана (Yourdon) и Гейна-Сарсона (GaneSarson), отличающиеся синтаксисом. Модель DFD использует для описания ИС понятия внешней сущности и процессов [8].

DFD поддерживает понятие подсистемы – структурного компонента разрабатываемой системы. Контекстная диаграмма DFD показывает АИС в коммуникации с внешней средой. Это диаграмма верхнего уровня в иерархии диаграмм DFD. Диаграмма верхнего уровня ограничивает рамки разрабатываемой АИС. Кроме DFD при формировании контекстной диаграммы используются диаграмма SADT, диаграмма вариантов использования.

External Entity (внешняя сущность) представляет собой материальный предмет или физическое лицо, представляющее собой источник или приемник информации за пределами границ анализируемой ИС, например заказчики, персонал, поставщики, клиенты, склад. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой ИС, если это необходимо, или, наоборот, часть процессов ИС может быть вынесена за пределы диаграммы и представлена как внешняя сущность. Внешняя сущность обозначается квадратом.

Process (системы и подсистемы) представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически про-

30