Бизнес-информатика. Введение в специальность
.pdf• |
«разд ляй и властвуй» – принцип решения сложных проблем путем их |
|||||
|
разбиения |
на множество мелких задач, легких для понимания и реше- |
||||
• |
ния; |
|
– принцип организации |
|
|
ча |
иерархическое |
|
|
||||
|
стей пробл мыупорядочиваниеиерархические древовидные структурысоставныхдобавлени- |
|||||
|
ем новых деталей на каждом уровне. |
|
|
|
||
Наибольшее распространение |
получили следующие методы структурного |
|||||
моделирования: |
|
модели, основанные на методе структурно- |
||||
• |
IDEF0 – |
|
||||
|
го анализафункциональныепроектирования SADT (Structured Analysis and Design |
|||||
|
Technique) Дугласа Росса; |
|
|
|
|
|
• IDEF1X – модели данных, основанные на диаграммах «сущность – |
||||||
|
связь» (ERD, Entity-Relationship Diagrams); |
|
|
|
||
• IDEF3 – диаграммы потоков работ (Work Flow Diagrams); |
|
|
||||
• |
DFD (Data Flow Diagrams) – диаграммы потоков данных. |
|
|
|||
Методология IDEF0 является одной из самых известных и широко ис- |
||||||
пользуемых методологий моделирования, она базируется |
методе |
SADT |
||||
(Structured Analysis and Design Technique) Росса, предназначенном |
для р шения |
|||||
широкого спектра проблем, включая разработку программного |
обеспечения, |
|||||
бизнес-анализ, проектирование, |
управление производственны- |
|||||
ми системами, управление финансамипланированиематериально-техническими |
. |
|||||
IDEF0-модель использует графический язык для отражения информацресурсамии |
||||||
о конкретной системе. Модель |
из диаграмм и фрагментов текста. На |
|||||
диаграммах все функции системысостоитих взаимодействия представлены как блоки |
||||||
(функции) и дуги (отношен я) [9]. |
|
|
|
|
||
|
конструкцией модели является функцио альный блок, пред- |
|||||
ставленныйОсновнойвиде |
рямоугольника и отображающий некоторую функц ю |
|||||
(действие, процесс, |
операцию). Внутри блока записывается его |
наименование. |
||||
Оно должно сод ржать глаг |
отглагольное существительное, например: |
|||||
«разработать проект», «изготовленили |
продукта», «планир вание». |
|
|
|||
играютДуги,рольизображаемыесвязей блоковнас диаграммевнешней дляв видених линийсредойсо. Каждаястрелкамииз дугна конце,имеет руюметку,стрелкахарактеризующуювходит или изеекоторой. Назначениевыходитдуг(рисзависит. 2.3): т стороны блока, в кото-
• |
«вх д» (I – input) – дуги, входящие слева от блока. Они представляют |
|||||||
|
собой предметы или данные, необходимые для выполнения функции |
|||||||
• |
блока (сырье, материалы, исходная информация); |
|||||||
«выход» (O – output) – дуги, выходящие |
|
из блока. Они показы- |
||||||
|
вают предметы или данные, полученныесправарезультате выполнения |
|||||||
• |
функции (продукция, услуга, выходные данные); |
|||||||
«управление» (C – control) – дуги, входящие сверху блока. Они опи |
||||||||
|
сывают условия или данные, которые управляют выполнением функ- |
|||||||
• |
ции (инструкции, требования, стандарты); |
|
|
|||||
«механизм» (M – mechanism) – дуги, входящие снизу блока. Они |
||||||||
|
значают испо нителей или средства, выполняющие функцию (персобо |
|||||||
|
нал, подразделения фирмы, оборудование, инструменты, информаци- |
|||||||
|
онная система). |
|
Функциональный |
|
|
|
||
|
Входы |
|
|
Выходы |
||||
|
|
|
блок |
|
|
|||
|
Рис. 2.3 – Функциональный блок IDEF0-диаграммы |
|||||||
Выход вход показывают, что и из чего делается функциональным бло- |
||||||||
о , управление показывает, как и почему это делается, а механизм показывает, |
||||||||
кем и с помощью чего это делается. |
|
|
|
|
|
|||
Функциональный блок может быть декомпозирован, т. е. представлен в |
||||||||
виде совокупности других взаимосвязанных функциональных блоков, которые |
||||||||
детально описывают исходный блок. Таким образом, IDEF0-модель состоит из |
||||||||
набора иерархически св занных диаграмм (рис. 2.4). На диаграмме корневого |
||||||||
уровня представлена вся |
система в виде одного бл ка |
дуг, изображающих |
||||||
вязи с внешним окружением. На диаграмме деком озиц и первого уровня си- |
||||||||
тема представлена более детально в виде |
совокупнос |
блоков-подмодулей, |
||||||
соединенных дугами друг с другом |
окружением. На тиаграммах декомпози- |
|||||||
следующего уровня |
детализируются |
блоки |
диаграммы первого уровня |
|||||
циит. д.Пример декомпозиции бизнес-процесса «Создание продукта» (рис. 2.5, 2.6).
|
|
А0 |
|
|
|
Диаграмма А0 |
|
|
|
|
|
I1 |
|
( )А1 |
|
||
|
|
|
|
С1 |
А3 |
О1 |
||
|
|
|
I2 |
|
М1 |
А2 |
||
I1 |
|
А11 |
Диаграмма А1 |
|
|
|
||
|
А12 |
|
А13 |
О1 |
|
|
||
) |
|
|
|
|
||||
( |
|
|
|
|
||||
|
I2 |
|
|
|
|
|
||
|
|
М1Рис. 2.4 – Иерархия диаграмм IDEF0-модели |
|
|||||
|
|
Заявка |
|
Созпродуктаание |
|
Доставленный |
|
|
|
Материалы |
|
|
продукт |
|
|||
|
|
|
|
Оборудование |
|
|
||
|
|
Рис. 2.5 – Пример контекстной диаграммы |
|
|||||
I1 Заявка |
|
Прием |
|
|
Заказ |
|
|
|
|
|
|
|
|
|
|
|
||||
|
заявки |
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||
) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||
( |
|
|
|
|
А1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Деньги |
|
|
|
|
|
Изготовление |
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||||
I2 Материалы |
|
|
|
продуктаА2 |
|
|
Продукт |
|
|
|
|
|
||||||||
|
|
|
|
|
|
|
|
|
|
|||||||||||
Отдел |
|
|
|
|
|
|
|
|
Станок |
|
|
|
Доставкапродукт |
|
|
О1 |
|
|||
|
|
|
|
Цех |
|
|
|
|
|
|
||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|||||||||
приема |
|
|
|
|
|
|
|
|
|
|
|
А3 |
Доставленный |
|
||||||
заявок |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
продукт |
|
|
||
|
|
|
|
|
|
|
Отдел доставки |
|
|
|
|
|||||||||
|
|
|
|
|
|
|
|
|
|
|
||||||||||
|
|
|
М1 |
|
|
|
|
|
Транспорт |
|
|
|||||||||
|
|
|
|
|
|
М2 |
|
|
|
|
|
|
||||||||
|
Персонал |
|
|
|
|
|
|
|
|
|
|
|
||||||||
|
|
|
Рис. 2.6 – Пример диаграммы декомпозиции |
наглядно |
||||||||||||||||
Диаграммы п токов данных DFD позволяют эффективно |
||||||||||||||||||||
описать процессы документооб рота |
обработки информации. С их помощью |
|||||||||||||||||||
система разбивается |
а |
|
|
|
|
компоненты (процессы, которые пре- |
||||||||||||||
образуют входные данныефункциональныев выходные) представляется в виде сети, связанной |
||||||||||||||||||||
потоками да ных. В методологии DFD используется четыре т па структурных |
||||||||||||||||||||
элементов: внешние |
сущности, процессы, потоки данных, хранилища данных. |
|
||||||||||||||||||
Внешние сущности определяют элементы вне контекста системы, кото |
|
|||||||||||||||||||
рые участвуют в процессе обмена информацией системой, являясь источни- |
||||||||||||||||||||
ками или приемниками информации. Внешние сущности изображают входы в |
||||||||||||||||||||
с стему и/или выходы з системы. Как правило, они представляют собой мате- |
||||||||||||||||||||
риальный предмет, физическое или юридическое лицо. |
|
|
|
|
|
|||||||||||||||
Процессы обоз ачают функции, операции, дейс вия, которые описывают, |
||||||||||||||||||||
каким образом |
входные |
пот ки данных преобразуются |
в выходные. Процесс |
|||||||||||||||||
обозначается в виде |
прямоугольника |
со ск угленными углами, разделенного на |
||||||||||||||||||
три поля. Верхнее поле |
одержит номер процесса, среднее – его имя, нижнее – |
|||||||||||||||||||
имя исполнителя |
процесса. |
|
|
|
|
|
|
|
|
|
|
|
|
- |
||||||
Потоки данных используются для отображения взаимодействия |
||||||||||||||||||||
ов с внешней средой и между собой. Поток данных соединяет выход |
процесса |
|||||||||||||||||||
сотражаетвходом содержимоедругого процессапотока)и. обозначается в виде именованной стрелки (имя
Хранилища данных представляют собой собственно данные, к которым |
||||||||||||||||||||||||
осуществляется доступ. Эти данные также могут быть созданы или изменены |
||||||||||||||||||||||||
п оцессами. В |
|
|
|
от потоков данных, описывающих данные в движении, |
||||||||||||||||||||
хранилища данныхотличие |
бражают данные в покое, т. е. данные, которые сохра- |
|||||||||||||||||||||||
няются в базе ежду последующими процессами. |
|
|
|
|
|
графического |
||||||||||||||||||
Диаграммы |
потоков данных имеют несколько |
|
|
|
||||||||||||||||||||
представления элементов структуры программной системывариантовее интерфейсов. |
||||||||||||||||||||||||
Элементы DFD-диаграммы в нотации Гейна – |
|
|
|
приведены на рисун |
||||||||||||||||||||
ке 2.7. В [10] внешние сущности предлагается отображСарсонать в виде прямоуг ль |
||||||||||||||||||||||||
ников; процессы преобразования данных обозначаются окружностями или ова- |
||||||||||||||||||||||||
лами; потоки данных – стре ками с названиями; |
хранилища данных – |
|||||||||||||||||||||||
отрезками горизонтальных параллельных линий (рис. 2.8). |
|
|
|
|
||||||||||||||||||||
|
|
|
Но |
|
ер |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
мя |
|
|
Имя |
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||
|
|
|
Исполнитель |
|
|
|
|
|
|
|
Имя |
|
|
|
Имя |
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Рис. 2.7 – Элементы DFD-диаграммы в нотации Гейна – Сарсона: |
||||||||||||||||||||||
|
|
|
а – процесс; б – поток да ных; в – хранилище данных; |
|||||||||||||||||||||
|
|
|
|
|
|
|
|
г – внешняя сущность |
|
|
|
|
|
|
|
|
||||||||
Пример диаграммы потоков данных в нотации Гейна – Сарсона приведен |
||||||||||||||||||||||||
на рисунке 2.8. |
|
|
Заявка |
1 |
|
|
|
|
|
Заказ |
|
1 |
|
База данных |
|
|||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||||||||
|
|
|
|
|
|
|
|
Формирование |
|
|
|
|
|
|||||||||||
|
|
Заказчик |
|
|
|
|
|
|
|
|
|
«Заказ» |
||||||||||||
|
|
|
|
|
|
|
|
|
|
заказа |
|
|
|
|
|
|
||||||||
|
|
|
Платеж |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||
|
|
3Опл та |
|
|
Стоимость |
Расчет |
|
|
|
|
2 |
|
База д нных |
|
||||||||||
|
|
заказа |
|
|
|
стоимости заказа |
Цена |
|
|
|
«Прайс» |
|
||||||||||||
|
|
|
|
|
|
Рис. 2.8 – |
Пример DFD-диаграммы |
|
|
|
|
|
|
|||||||||||
|
|
|
|
|
|
|
|
|
|
|
||||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|||||||||||||
к2.2построениямОбъектно-ориентированныймоделей бизне -процессовподход |
|
|
||||
Главным структурообразующим элементом в объектно-ориентированном |
||||||
подходе является объект. При моделировании бизнеса объектами являются |
||||||
участники б знес-процесса (активные объекты) – |
низационные единицы, |
|||||
конкретные |
исполнители, информационные системы,оргатакже пассивные объек- |
|||||
ты – материалы, документы, |
|
над которыми выполняют действия |
||||
активные объекты. Таким |
бразом,оборудование,объектно-ориентированном подходе мо- |
|||||
дель бизнес-процессов строится |
вокруг участников процессов |
их действий. |
||||
Общепризнанным стандартом в области объектно-ориент |
подхода |
|||||
яв яется язык моделирования UML. В основу бъектно-ориентированного мо- |
||||||
делирования с использованием языка UML положен ряд |
принципов. |
|||||
Принцип абстрагирования предписывает включатьключевыхмодель только те ас- |
||||||
пекты проектируемой системы, которые |
меют непосредственное отношение к |
|||||
выполнению систем й своих функций или своего целевого назначения. |
||||||
Принцип мн гомодельности своди ся к утверждению том, что никакая |
||||||
отдель о взятая модель не может |
достаточной степенью адекватности описать |
|||||
различные аспекты предметной области |
и ее основные бизнес-процессы. При |
|||||
менительно |
UML это означает, что достаточно полная модель предметной об- |
|||||
ласти допус ает некоторое число взаимосвязанных предста лений, каждое из |
||||||
адекватно отражает некоторый аспект функционирования или структу |
||||||
которыхпредметной области. В этом случае интегрированная модель предметной об- |
||||||
ласти представляется в виде совокупности диаграмм (рис. 2.9) [9]. |
|
|||||
Диаграмма |
Диаграмма |
Диаграмма |
|
|||
прецедентов |
|
классов |
состояний |
|
||
Диаграмма |
Интегрированная |
Диаграмма |
||||
|
модель |
|||||
деятельности |
предметной области |
последовательности |
||||
Диаграмма |
Диаграмма |
Диаграмма |
|
|||
кооперации |
компонентов |
развертывания |
||||
Рис. 2.9 – Интегрированная модель предметной области в нотации UML
построениМодпрецедентнойлированиедвух видовбизнесамоделей:с помощью UML предполагает последовательное
1) функциствие с окружением;нальностьмодели– бизнес(аналога-процессымодели(прецеденты)поведения),и ихописывающейвзаимодей- 2) ренобъектнойбизнес устройствомодели (аналогабизнесаструктурной– объекты, модели),участвующиеописывающейвыполнениивнут- Диаграмма-процессовпрецедентови ихописываетвзаимодействиебизнес. в виде графа специальногоотношеви- да,нияосновнымимежду нимиэлементами. Прецеденткоторогомодели являютсябизнеса –прецеденты,это относительноакторызаконченная последовательностьщая ощутимый результатдействийконкретномув рамкахдействующемунекоторого бизнеслицу-процесса,(актору). Примерып носянипрецедентыцедентов:, разработкапроизводствопродукта, продукта,маркетингвнутрипродажасбыт.продукта,СогласнодержитсясервисноеспецификацииобслуживаUML- текст, называемыйобозначаютсяименемэллипсом,прецедента (рис.которого2.10). Имена прецедентампоясняющийформулируютсяпоясняющимлибословаглаголом,. либо существительным, обозначающим действие и
Заказчик требованияОпределитьк ПП Заказчик требованийОпределениек ПП Рис. 2.10 – Эквивалентные прецеденты
ствующиеАкторамис бизнможетвсмодели-процессомбизнесаявляющиесяявляются человек,элеменго потребы окружения,ителями либовзаимодейинициа- тораминии или. Этоработающийбытьвфизическоеподразделениях,партнер,лицо –акционер,охваченныхработающиймоделью вбизнесакомп (клиент,лицо – компания,покупатель,организпостация,вщик,предприятие, органы власти,заказчик),являющиесяюридическоепо- ставщикамидартным обозначениемресурсов либоакторапотребителявляетсямипиктограммапродуктов бизнес(рис. 2-.10),процессовпод которой. Стан р сполагается имя актора.
кацтокииМеждукоторыепрецедентамиописывают информационные,акторами устанавливаютсяматериальныеотношеи финансовыеия коммунипо-
акторами:междупредметнаяними. Все областьпрецеденты,не должнавводимыесодержатьв модель,бизнесдолжны-процессы,быть связаныкоторыес никемНаиболеене востребованыважным. для описываетания прецедента является документ, называе- мыйвиде потокомпоследовательностисобытий. Оншагов процессадеятельностисценарии. П токособытуществленияий прецедентапрецедентаможетв бытьусловныепредставленобозначениявидеосновныхдиаграммыэлементов диаграммы. На.рисунке 2.11 приведены
Рис.б2–.11конечное– Элементысостояние;диаграммыв – действие;деятельности:г – переход;а – начальноед – ветвление;состояние;
– синхронизация ствие,Каждыйпереводящеешаг прецедент(событие) впрецедентановое состояниепредставляет.В воюсобойочередьнекотороеновое состоядей-
ниетия).прецедентаНа рисункеявляется2.12 приведенстимуломпримердля выполнениядиаграммы,следующегоиллюстрирующийшага (собыход событийОбъектнаяп ецедентамодель«Продажараскрываетпродукта»внутреннее. устройство бизнеса,какимименно: какиезом онивидывзаимодействуютресурсов используются. Основнымдляпонятиемреал зациимоделипрецедентовбизнес-процесса обраявля- етсяскихпонятиелиц), участвующихобъект. Объектыв выполнениимодели процессов,бизн а представляюти различногоактороврода сущности,(физиче которыетами,чи . д.обрабатываются). Участники процессовили создаются(исполнители)бизнесомназываются(продукция,активнымипредметы,объекзадавремя сущностивыполнения– пассивнымибизнес-процессов,. Для тогоиспользуетсячтобы отразитьдиаграммауч стиепоследовательакторов во- ности (рис. 2.13).
|
|
|
|
Получить заявку |
|
|
|
|
|
Указан готовый продукт |
Указан заказной продукт |
||||||
Проверить наличие |
Передать заказ изготовителю |
|||||||
|
Изготовить продукт |
|
||||||
|
на складе |
|
|
|
|
|||
|
|
|
Сообщить о готовности |
Отправить на склад |
||||
|
Нет |
Продукт имеется |
Принять оплату |
|
||||
|
|
|
|
Заказать транспорт |
|
|||
|
|
|
|
|
Доставить продукт |
|
||
Рис. 2.12 – Диаграмма деятельности прецедента «Продажа продукта» |
||||||||
Заказчик |
Продавец |
Изготовитель |
Склад |
|
Отправитель |
|||
|
|
Оформление |
|
|
|
|
||
Подача заявки |
|
заказа |
Изготовле- |
|
|
|||
|
|
|
Передача заказа |
|
|
|||
|
|
|
С общение |
ние продукта |
|
|
||
Сообщение |
|
о готовности |
Отправкапродукта |
|
|
|||
|
|
|
Заказ |
|
|
|
||
|
Оплата |
|
|
|
|
|
|
|
|
|
|
|
|
транспорта |
Запрос |
||
|
|
|
|
Доставка продукта |
|
|||
|
|
|
|
|
Отгрузка |
|||
|
Рис. 2.13 – Диаграмма последовательности прецедента |
|||||||
|
|
|
|
«Продажа продукта» |
|
|
|
|
|
Каждый акто , |
|
|
|
в реализации прецедента, изображается |
|
|||||||
верхней части диаграммыучаствующийвиде |
|
|
от которого вниз |
проведена |
|||||||||
линия («линия |
жизни»). Внутрипрямоугольника, записывается имя актора. |
||||||||||||
Между объектами (акторами) устанавливаются отношения сообщений, отра- |
|||||||||||||
жающие аналогично отношениям коммуникации передачу информации (или |
|||||||||||||
некоторый матери |
ый поток) между объектами. Сообщен е изображается |
||||||||||||
отрезком горизонта ьной |
линии |
стрелкой, проведенной от линии жизни объ |
|||||||||||
екта (актора), посылающего сообщение, |
до линии жизн |
объекта (актора), |
- |
||||||||||
лучающ го сообщение. При этом прием сообщения инициирует выполнение |
|||||||||||||
опре е енных действий тем объектом, которому сообщение пер дано. Сообще- |
|||||||||||||
ния |
должны быть упорядоч ны по времени: первое сооб |
е |
изображается |
||||||||||
вверху диаграммы, следующее – ниже, следующее – еще |
нижещени |
. д. |
разработ |
|
|||||||||
позволяет упростить |
взаимодействие заказчиков разработчиками |
|
|||||||||||
|
Использ вание описанных выше методологий описания |
изнес-процессов |
|||||||||||
ч ков между собой |
ри разработке анализе требован й, проектировании ар |
|
|||||||||||
хитектурного и |
компонентного дизайна |
ПП и |
создании в последующем про- |
||||||||||
граммного кода. |
|
|
|
|
|
|
архитектуры |
|
|
||||
2.3 Моделирование процессов |
|
|
|
|
|||||||||
и требований программной системыразработкина снове диаграммы |
|
||||||||||||
потоков данных |
|
вание – это способ |
|
проблем с помощью |
|||||||||
|
Визуальное модели |
|
|||||||||||
римых абстракций, воспроизводящих понятия |
объекты реального мира. Ви- |
||||||||||||
зуальное |
|
|
оказало большое влияниевосприятияна азвитие техническ |
|
|||||||||
средств ПОмоделированиеобще CASE-средств в частности. Большинство существующих |
|||||||||||||
ех |
л гий создания |
программного обеспечения основано на методах струк |
|
||||||||||
турного или объектно-ориентиров нного анализа и про |
|
|
|
использу |
|
||||||||
ющих спецификации |
в виде диаграмм или текстов для ектирования,исания внешних тре- |
||||||||||||
бований, связей между моделями системы, динамики |
поведения системы и |
||||||||||||
архитектуры программных средств. |
|
|
|
|
|
|
|
|
|||||
|
Под моделью ПО в общем случае понимается форм лизованное описание |
||||||||||||
системы ПО на определенном уровне абстракции. Каждая |
дель определяет |
||||||||||||
к нкретный |
системы, |
|
|
набор диаграм |
и документов задан- |
||||||||
ного формата,аспекттакже отражаетиспользуетточку ния |
является |
объектом деятельности |
|||||||||||
различных людей с конкретными |
интересами, |
ролями или задачами. Модели- |
|||||||||||