BIZNESA PROCESU MODELĒŠANA IZMANTOJOT METAMODELĒŠANAS PAŅĒMIENUS
Valdis Vītoliņš Promocijas eksāmens
2/56
Saturs
• • • Modeļi, metamodeļi un metamodelēšana Unified Modeling Language (UML) 2.0 standarti
– (pasaule, kurā dzīvojam)
Pētījumu apraksts:
– Vienots biznesa procesa metamodelis
– Biznesa procesu mērīšana
– UML 2.0 aktivitāšu diagrammas precīzā semantika – Biznesa procesu transformācijas
•
Turpmākie pētījumi
3/56
Kas ir metamodelēšana
• Metamodelēšana ir modelēšanas valodas un tās likumu izstrāde.
•
• •
Metamodelēšana ir vispārīgu likumu piemērošana (―instancēšana‖) konkrētiem modeļiem vairākos piegājienos, tā veidojot vairākus metaslāņus.
Metamodelēšana ir modeļu izstrāde, pielietošana un manipulācijas ar tiem, tajā skaitā arī modeļu transformācijas Metamodelis ir precīza modeļa un tā semantikas (jēgas) apraksts, kas nepieciešams modeļa izveidei.
•
•
www.wikipedia.org,
Mili, H., Pachet, F., Benyahia, I., and Eddy, F. (1995). Metamodeling in OO. OOPSLA '95 Workshop summary.
4/56
Kas ir biznesa procesu modelēšana
• Biznesa procesu modelēšana (Business Process Modeling - BPM) ir ir uzņēmuma darbības aprakstīšana ieskaitot pašreizējo un vēlamo stāvokli, un iespējams arī izmaiņu (pārejas) procesu no esošā stāvokļa uz vēlamo stāvokli. BPM tiek veikta, izmantojot dažādas BPM valodas, rīkus un metodikas. Mēs galvenokārt izmantojam – – UML valodu (Unified Modeling Language), MDA (Model Driven Architecture) konkrētāk - MDD (Model Driven Development) metodiku. http://www.wikipedia.org/ http://www.omg.org
• •
– –
5/56
Metaslāņu hierarhijas piemērs pēc UML 2.0 jeb ―kā mēs redzam pasauli‖
Unified Modeling Language (UML) Specification: Infrastructure version 2.0 http://www.omg.org/cgi-bin/doc?ptc/2004-10-14
6/56
Metamodeļu slāņi (layers)
M0 – izpildes laika (runtime) instances (mēs parasti neaplūkojam, jo attiecas uz implementāciju) M1 – modeļi, kuros var tikt iekļautas konkrētas instances specifikācija (instance specification) kā :Video title = "2001: A Space Odyssey" M2 – metamodeļi, valodas (UML, BPMN, ORM, DSL, u.c.) M3 – metametamodeļi, ―valodu modeļi‖ – variācijas par diskrēto modelēšanas valodu uzbūvi sastāv no ―metaklasēm‖ un ―metaasociācijām‖
Tony Clark, Andy Evans, Paul Sammut, James Willans, Applied Metamodelling A Foundation for Language Driven Development Version 0.1, http://albini.xactium.com/content/
7/56
Ontoloģiskā metamodelēšana (Ontological metamodeling) jeb ―nepareizā‖ metaslāņu hierarhija
Colin Atkinson, Thomas Kühne, ―The Role of Metamodeling in MDA‖, ―Calling a Spade a Spade in the MDA Infrastructure‖, ―The Essence of Multilevel Metamodeling‖, u.c. http://www.db.informatik.uni-bremen.de/umlbib/authors/AtkinsonColin.html ―Nepareizais‖ skats – Mūsu (UML) skats pūdeli uzskata par suņa instanci Pūdelis ir suņa specializācija – Pilnai ģenealoģijai sanāk patvaļīgi dauz metaslāņu Visa ģenealoģija ir M1 Ir tikai 4 metaslāņi
Mammal
Dog
Poodle > Fido:Poodle
M0
8/56
Unified Modeling Language (UML) 2.0
• Standarti:
– Unified Modeling Language: Superstructure
version 2.0, http://www.omg.org/cgi-bin/doc?formal/05-07-04
– Unified Modeling Language: Infrastructure,
version 2.0 http://www.omg.org/cgi-bin/doc?ptc/2004-10-14
– MOF 2.0 Versioning Final Adopted Specification,
http://www.omg.org/cgi-bin/doc?ptc/2005-08-01
– OCL 2.0 Specification,
Version 2.0, http://www.omg.org/cgi-bin/doc?ptc/2005-06-06
9/56
Vienots biznesa procesa metamodelis
• •
Pētījumi tika veikti 2002-2003 gadā. Šī pētījuma rezultāti tika apvienotu un publicēti: Vitolins Valdis, Audris Kalnins. Modeling Business. Modeling and Simulation of Business Systems, Kaunas University of Technology Press, Vilnius, May 13-14, 2003, pp. 215.-220.
10/56
Biznesa modeļu izpēte
• Pirmie biznesa jēdzienu definēšanas pētījumi ir veikti:
– – The Zachman Institute for Framework Advancement (ZIFA), http://www.zifa.com System Architect,Tutorial, 2001, Popkin Software, http://www.popkin.com/products/product_overview.htm
• •
Bet tie neatbilst objektorientētai pieejai Precīzākus (objektorientētus un UML atbilstošus) modeļus ir veidojuši:
– A. Osterwalder, S. Ben Lagha, Y. Pigneur, An Ontology for Developing e-Business Models, INFORGE, Encole des HEC, http://inforge.unil.ch/aosterwa Andreas Dietzsch. Adapting the UML to Business Modelling's Needs - Experiences in Situational Metod Engineering, UML 2002. LNCS 2460, pp 73-83 Sandy Tyndale-Biscoe. Business Modelling for Component Systems with UML. Proceedings of the Sixth EDOC Conference (’02)
–
–
11/56
A. Osterwalder biznesa modelis
•
•
An e-Business Model Ontology for the Creation of New Management Software Tools and IS Requirement Engeneering, Ecole des Hec, Université de Lausanne, http://inforge.unil.ch/aosterwa Metamodelis pamatā aprakstīts angļu valodā
– Pamatā apskata augsta pārvaldības līmeņa jēdzienus (ne ikdienas workflow operācijas)
12/56
Andreas Dietzsch, Sandy Tyndale-Biscoe biznesa modeļi
Critical Succes s Factor 1..* 1 Strategy Business Goal Service Proces s Map 1..* 1..* Business Process 1..* 1..* Index Value Is Provided Output 1..* 1..* Customer
Is Consumed Supplier 1..* 1..* Management Process Input
Labi attēlo Deminga ―Value Added Chain‖ procesu
Performing Process
Support Process
Andreas Dietzsch. Adapting the UML to Business Modelling's Needs - Experiences in Situational Metod Engineering, UML 2002. LNCS 2460, pp 73-83
Subgoals 0..* 1..* met by Enabling behaviour to meet 1..* Is constrained 1..* by Cons trains 0..* 1..* Step
Goal 1..* Has 1..* Is objective of Comunity Is behaviour of 1..* 1..* Executes 1..* Is member Has Is fulfilled by1..* Resource 1..* Fulfills 1..*
Business Proces s
Behavioural Policy
Labi attēlo resursu pārvaldību un procesu veicējus
Is performed by 1..* Role 1..* Is actor for
Sandy Tyndale-Biscoe. Business Modelling for Component Systems with UML. Proceedings of the Sixth EDOC Conference (’02)
13/56
Mūsu apvienotais uzņēmuma (biznesa) metamodelis
Subs idiary 0..* 1..* Supplement 1..*
Notation Inde pendent Business Concepts
Enterprise
Organisation
1..* 1..* 1..* 1..* Objective
Cons umption
Resource
Tangible Intangible
Business Goal
Subgoal 0..* 1..* Nomination
Realization Plant 0..*
Instrumen ts, cash
1..*
1..* Strategy
People 1..*
Material
Mea ns of produ ctio n
Knowledge
Kn ow How
0..*
1..* Index Value 1..* Men surab le Meas urement
Supplier
1..* 1..*
1..*
1..* 1..* Operating Actor 1..* 1..* Performer
Re feren ce
1..*
0..* Best practice
1..* Support
Staple
Meas urement
Conformity
Quality
Requirement
1..*
Input
1..* Actor 1..* Utilization 1..* 1..* Service
Pu bli c Interface
Determination 1..* 1..* 1..* 0..* 1..* Satisfaction Refinement 0..* Sub proces s 1..*
Raw Material
Task
Business Process
Al l activites fl owe d in en te rp ri se
Customer
Production 1..* 1..* 1..*
Atomic activity
Proces sed Material
Internal
Output
Apvienotajā metamodelī ir daudzi jēdzieni, kas šķiet svarīgi biznesa analītiķiem, bet kuru nav UMLā. Acīmredzot tāpēc, ka UML vēsturiski ir veidojies kā programmatūras izstrādes, nevis biznesa analīzes standarts. Zīmīgi vārdi ir ―Notataion Independent‖ – tas atspoguļo mūsu tā laika domas par kopīgo metamodeli dažādām valodām
14/56
Mūsu biznesa procesa metamodelis
0..* Subprocess Performer
Re feren ce
Notation Independent Business Process Decomposition
Business Process
0..* 1..* Task
Smal l est un it of execu ta bl efuncti on
Service Internal Transition
1..* 1..* Actor 1..* 0..* Control 1 0.. 2 0..1
0..2 0..1 Incoming Join Merge Outgoing 0.. * 1..* Pass
Resource
HW, SW, etc.
1 0..*
1 0..*
Organisational Unit 1..* 1..* 1..* 1..* Role
Bu si ness rol e, or pri vi le ges
1
Qualification
Impl icit reference throug h requ ireme nts
Start End
Decision Fork
Metamodelis sasaucas ar UML 2.0 aktivitāšu diagrammu, bet tas ir papildināts ar jaunām klasēm un asociācijām (―stipri modificēts‖). Piem. Performer klase un Actor asociācija ir janievedums, kas ir nācis no mūsu biznesa procesa profila (pakotnes). Šādi papildinājumi gan ir saskaņā ar MOF un UML, bet datu apmaiņu starp dažādiem rīkiem veikt nevar, jo papildinājumus tie var nesaprast.
15/56
GRADE BM un UML 2.0 Aktivitāšu diagrammu piemēri
Abās valodās aprakstīts tas pats biznesa process
New problem appears Review Coordinator Is Motivated Development OR Developer a Testing AND Tes ter g Is Not Fixed h b Is Not Motivated
(Coordinator) Review [Is Motivated] [Is Not Motivated]
Integration Integrator
g
(Developer) Developm ent (Integrator) a Integration b c d (Tester) T esting [Is Fixed] e (Coordinator or Tester) Close
Is Fixed Close OR Coordinator OR Tes ter
[Is Not Fixed] f
16/56
Biznesa modeļu “transformācija” kopējā metamodeļa pieejā
• Dažādas valodas uzskatījām kā ―valodas neatkarīgu‖ jēdzienu attēlojumus
Notation A Domain Concept Layer Notation Dependent BP DomainA Is view of
Notation B
Notation Independent BP Domain
Is view of
Notation Dependent BP DomainB
1..* Concept A 1 0..1 Presentation Layer Concept Presentation A Concept A mapping 1..* 1..*
1..* Notation Independent Concept
Actual mappingway Concept B mapping 1..* 1..*
1..* Concept B 1 0..1
Presentation mapping 0..*
Depends on concept mapping 0..*
Concept Presentation B
17/56
Modeļu “transformācija” pirms MOLA
Exigen Business Modeler pieeja – izmantojot kopīgo metamodeli
Grade BP domain Domain concepts layer Notation independent domain XOR Tas k Join Merge Incoming Tas k XOR Guard-In-Path Guard Guard-Out-Path Path Outgoing Fork Decision Pass XOR XOR a:Activity Edge a:Path b:Path Tes ting:Tas k b:Activity Edge c:Join Node d:Activity Edge Tes ting:Action e:Activity Edge g:Guard-In-Path Is Not Fixed:Guard h:Guard-Out-Path Domain Instances f:Decis ion Node g:Activity Edge Condition = "Is Not Fixed" UML 2.0 Activity Diagram domain (According concepts logical instances are as sumed) Join Node Merge Node Action Fork Node Decision Node Activity Edge
Pareizāk būtu teikt, ka šeit veikta modeļu salāgošana (mapping), jo transformācija tīrā veidā netiek veikta. Šobrīd, izmantojot MOLA, modeļi tiktu pārveidoti no viena uz otru, izlaižot Notation Independent Domain.
18/56
Citas saites
A. Osterwalder, S. Ben Lagha, Y. Pigneur, An Ontology for Developing e-Business Models, INFORGE, Encole des HEC, http://inforge.unil.ch/aosterwa Kalnins, A., Barzdins, J., Celms, E., Lace, L., Opmanis, M., Podnieks, K., Zarins, A.: The First Step Towards Generic Modelling Tool. Proceedings of Baltic DB&IS 2002, Vol. 2, Tallinn (2002) 167-180 ESPRIT project ADDE. http://www.fast.de/ADDE International Standard, ISO/DIS 9001 Quality management systems — Requirements, International Organization For Standardization, http://www.iso.com Business Process Modeling Notation. Working Draft (0.9) November 13, 2002, Business Process Management Initiative (BPMI), http://www.bpmi.org International Standard, ISO/TS 16949 Quality systems - Automotive suppliers, International Organization For Standardization, http://www.iso.com
19/56
Biznesa procesu mērīšana
Pētījumi tika veikti 2003-2004 gadā. Šī pētījuma rezultāti tika apvienotu un publicēti: – Vitolins Valdis, Business Process Measures. Computer Science and Information Technologies, Databases and Information Systems Doctoral Consortium, Scientific Papers University of Latvia Vol. 673, University of Latvia, 2004, pp. 186.-197
20/56
Kas ir biznesa procesu mērīšana
• Biznesa procesa mēri ir jēdzieni, kas attēlo dažādus biznesa procesu aspektus (īpašības):
• Laiks • Nauda • Resursi • Kvalitāte ar precīzu definīciju un jēgu Ar precīzu skaitli un mērvienību.
– –
•
Saskaņā ar Gartner, biznesa procesu precīza mērīšana ir noteikta kā kritiska Biznesa procesu pārvaldības (BPM) joma.
– Gartner, Inc, Executive Report Library, ―Winning Asset Management Series. Introduction and Report Overview‖ http://www.gartnerconnects.com/executivereports/executive_reports_asset_management.pdf ISO 9000:2000, Quality management systems - Fundamentals and vocabulary , ISO 9001:2000, Quality management systems – Requirements, http://www.iso.org Mark C. Paulk, et.al., The Capability Maturity Model : Guidelines for Improving the Software Process, Addison Wesley Professional, 1995 Douglas T. Hicks, Activity-Based Costing : Making It Work for Small and Mid-Sized Companies, 2nd Edition edition, John Wiley & Sons, 2002 Robert S. Kaplan, David P. Norton, The Strategy-Focused Organization: How Balanced Scorecard Companies Thrive in the New Business Environment, Harvard Business School Press, 2000 Farok J. Contractor, Valuation of Intangible Assets in Global Operations, Quorum Books, 2001
•
Procesu mērīšanas metodika ir aprakstīta:
– – – – –
•
Bet nevienā no šīm metodikām nav balstīta uz metamodelēšanu, tāpēc var teikt, ka nav pietiekami precīza un formāla
21/56
Balanced Scorecard metodika
– – Dažādas mēru perspektīvas • (Customer, Financial, Internal, Learning & Growth) Katras perspektīvas mēri izsakāmi ar precīziem skaitļiem
22/56
Intangible Asset Monitoring
– – Bāzēta uz Balanced Scorecard metodiku Piedāvā dažādus skaitliski izmērāmus mērus ―netaustāmiem rādītājiem‖, un daļēji arī to saistību, piem.:
• • • • • Indicators of Growth Indicators of Renewal/Innovation Indicators of Efficiency/Utilisation Indicators of Risk/Stability Indicators of Renewal/Innovation
–
Iesaka pielietot skaitliskus mērus arī dažādām gaisīgām lietām, kā piem. ―customer satisfaction‖ kā atgriezušos klientu skaitu, vai procentu no visiem apkalpotiem klientiem, u.tml.
23/56
Nopietnākie rīki ar procesu mērīšanu
• GRADE, IDS Scheer ARIS, Popkin Software System Architect – Ļauj mērīt procesu simulāciju (laiks, izmantotās instances, rindas, u.tml) – Mērus uzdot atsevišķā simulatorā
Sekojošie rīki praktiski atbalsta tikai Internal Business un Financial perspektīvu mērus, kurus var piemērot procesu pārvaldībai
•
• •
•
Mēru agregācija notiek veidojot pārskatus, pašam jāzin, ko un kā saskaitīt QPR ScoreCard – Elementārajām aktivitātēm predefinēti vienādi mēri, kā: • Izpildes laiki (sākums, beigas, kopējais ilgums, aktīvais ilgums) • Izmaksas, objektu dekompozīcija var sadalīt % izmaksas • Skaitītāji (% defektiem, kopējais skaits u.tml.) – Līdz ar to, ne visiem elementa mēriem ir būtiska jēga (reālā varbūt ir) CaseWise Corporate Modeler – Balanced Scorecard metodika
24/56
Biznesa procesa piemērs (aktivitāšu diagrammas M1 slānis)
Sell Pizzas Start
Make Order
(Clerk) Make Order Amount, items Production Order ID Quantity Address (Packer) Pack Pizza Cost, EUR Processing Time, min Customer Total Time, min
Start
Sales
Start Time, datetime
Fill Order
Cost, EUR Amount, items
Make Corrections
Sales
Pizza
Packed Pizza ID
Cost=2 Box EUR/hour* Cost, EUR Amount, items Processing Time, EUR Processing Time, min Cost, EUR
Amount, items
(Clerk) Check Order Yes No Need Correction
Order ID Quantity Size Address
(Driver, Expeditor, Car) Deliver (Expeditor) Encash Finish
Cost, EUR Cost = 0.1, Total Time, hour EUR Profit, EUR Cash
Transport
Processing Time, min
(Clerk) Send to Production
Accounting
Finish
End Time, datetime
UML 2.0 aktivitāšu diagramma ir papildināta ar procesu mēriem, kas attēloti formatēti komentāri diagrammas elementiem Turpmākajos zīmējumos ir apskatīts tikai Make Order apakšprocess
25/56
Biznesa procesa modelis ―no iekšpuses‖ (klašu diagramma)
> Make Order measure container *Unit=min container Declaration=Minus(MO Finish, MO Start) > MO Total Time container > Pizzeria Not All > Customer
> Make Corrections
> Fill Order
> Start arg2 primitive measure
> Finish primitive
> Clerk
> Sales measure
> Order
> Need Correction > MO Cost
> MO Start *Unit=datetime arg1
> Clerk measure > Send to Production primitive
> Check Order primitive primitive measure
primitive
*Unit=EUR Declaration=Sum(SP Cost, CO Cost) arg measure > SP Cost *Unit=EUR *Declaration=0.1 > CO Cost *Unit=EUR *Declaration=CO ProcTime*2 EUR/hour
> MO Finish *Unit=datetime measure
> MO Processing Time *Unit=min Declaration=Sum(CO ProcTime, SP ProcTime)
> CO ProcTime arg *Unit=min measure arg > arg SP ProcTime *Unit=min
measure
arg
Šajā attēloti visi Make Order procesa elementi (iekļaujot aktivitāšu diagrammā neredzamos), kā konkrētas metamodeļa instances. Attēlojumam ir nestandarta pieeja: • metamodeļa klase ir attēlota kā stereotips, t.i. > Make Order , jālasa kā Make Order:Business Process • metamodeļa dekompozīcija attēlota kā modeļa dekompozīcija ar konkrētām klasēm, un konkrētām asociācijām (UML standartā ieteiktā klases nodalījuma (compartment) izmantošana iespējama tikai vienai metamodeļa->modeļa pārejai)
26/56
Mēru definīcijas metamodelis (M2 slānis)
* subprocess container 1 > Business Process 1..* 1 container > People Not all > Enterprise Not all * > Organisational Unit * XOR > EUR 1..* unit 1 XOR
container 1 measure 0..1 > Total Time decl 0..1 1 1..* > End primitive 1 1..* > Performer 1..* 1
* * > Task
* > Decision XOR
primitive 1 primitive * measure measure 0..1 > 1..* 1..* Processing Time unit 1 unit 1..* 1 arg > arg 0..1 Time Range Unit 1 decl 1 > Sum
1..*
> Minus 1
> 1 Start
measure * * measure 1 > Cost arg * 0..1 decl 0..1 decl
primitive 1 1 1 0..1 0..1 measure arg2 arg1 measure > Start Time unit 1 1 > End Time 1 unit 1
1
> Time*Rate rate 1 1
> Sum
0..1 decl
> datetime
> hour
> min
> Declared Cost Rate
> Declared Cost
Arī šis metamodelis ir veidots ar ―spēcīgo pielāgošanu‖, ieviešot jaunu ―Biznesa procesu mērīšanas‖ profilu. Mēru definīcijas metamodelis ir izmantojams kā šablons biznesu procesa mēriem (uz metamodeli balstītā) rīkā. T.i. rīkā jau ir definēti gatavi procesa biznesa mēri un to vērtību aprēķināšanas veids (―formula‖).
27/56
Mēru veidi un to saistība ar biznesa procesu definīcijas elementiem (M2 slānis)
* Subunit * * > Any Measure * > Resource * * * 1 * > Enterprise > Turnaround 0..1 > Money * 1 1 > Amount 0..1 * * 1..* 1 * Sub process * 1
*
> Org Unit
*
> Business Process
> > > 0..1 > 1 1 * 1..* Quality > 1 Equipment Value > * * > Performer 1 1 Flow 1 1 Total Time 1 > Branch > 0..1 Object Flow 0..1 Age > 0..1 1 1 0..1 1 * 1 1..* 1 1 Item 0..1 1 > > > > End Start Con 1 Work Task 1 0..1 1 0..1 OR 1 1 0..1 0..1 0..1 0..1 0..1 1 1 0..1 1 0..1 0..1 > 0..1 > mēriem var uzdot gatavus veidus, kā > jāvidējo, > > > 0.. > jāskaita kā Profit procenti u.tml.) Cost RepeatingTime Processing Time End Time Šis modelis vairāk lasāms kā ―konceptuāla diagramma‖, kas atspoguļo mūsu domas par noderīgiem biznesa procesu mēriem, nekā precīzs metamodelis. Lai metamodelis būtu precīzs, tajā būtu jāatspoguļo metaklašu instanču un metaasociāciju instanču konkrētās vērtības, bet kā jau tika norādīts, UMLā nav noderīgu veidu, kā to īsti attēlot.
0..1 > 1 People
0..1
> Price
0..1 0..1 1
28/56
Biznesa procesu mēru metametamodelis (M3 slānis)
• • Šajā darbā mēs ne tikai izveidojām savu metamodeli (biznesa procesu mērīšanas profilu), bet patiesībā izveidojām arī savu metametamodeli jeb MOFu. Kā labumu var minēt to, ka šādi specializējot UML MOFu, mēs varam vienkāršot metamodeli, jo daudzas vajadzīgas īpašības (piem., saprātīgi ierobežojumi) mums jau ir ―iešūtas‖ MOFā + Tas gan ir saskaņā ar MOF standartu, kas pieļauj dažādus MOFus – Tomēr, tas lauž tradīcijas, jo apgrūtina datu apmaiņu (ko gan varētu labot ar transformācijām)
Class (from InfrastructureLibrary::Constructs)
Object Attribute
*
Business Object
child *
1 measure * 1 Me asu re Measure object 1..* Unit source * source * arg * 0..1 Containing 1 Declaration measures 1 1 0..1 * 1 * 0..1 Declared Value
Primitive Conainer 1 arg
Aggregation Function
Math 1 0..1 Function arg
Jāteic, ka šobrīd mēs cenšamies dzīvot precīzā saskaņā ar UML MOFu un UMLu, lai varam mierīgu sirdsapziņu apgalvot, ka mēs dzīvojam saskaņā ar tiem.
29/56
Citas saites
• • • ARIS 6 – Collaborative Suite, System White Paper, IDS Scheer, 2003, http://www.ids-scheer.com/sixcms/media.php/1186/ARIS+6-2+SWP+en+2003-07.pdf System Architect,Tutorial, 2001, Popkin Software, http://www.popkin.com/products/product_overview.htm QPR Process Guide White Paper, QPR ScoreCard White Paper, 2002, QPR Software Plc, http://www.qpr.com/protected/whitepapers/QPRProcessGuide/QPRProcessGuideWhitePap er.pdf, http://www.qpr.com/protected/whitepapers/QPR_ScoreCard_WhitePaper.pdf Casewise Corporate Modeler Product Info, Casewise, http://www.casewise.com/products/corporate-modeler/corporate-modeler.php Unified Modeling Language: Superstructure, version 2.0, Object Management Group (OMG), 2003, http://www.omg.org/docs/ad/03-04-01.pdf Meta Object Facility (MOF) 2.0 Core Proposal, Object Management Group (OMG), 2003, http://www.omg.org/docs/ad/03-04-07.pdf Response to the UML 2.0 OCL RfP Revised Submission,Version 1.6, Object Management Group (OMG), 2003, http://www.omg.org/docs/ad/03-01-07.pdf
• • • •
UML 2.0 aktivitāšu diagrammas precīzā semantika
Pētījumi tika veikti 2004-2005 gadā. Šī pētījuma rezultāti tika apvienotu un publicēti:
Valdis Vitolins, Audris Kalnins, Semantics of UML 2.0 Activity Diagram for Business Modeling by Means of Virtual Machine, Proceedings Ninth IEEE International EDOC Enterprise Computing Conference, IEEE, 2005, pp. 181.-192.
31/56
AD precīzās semantikas pētījumi
• • • UML standartā AD precīzā semantika ir aprakstīta angļu valodā Precīzai AD izpilde ir nepieciešama formāla semantika precīzākā valodā Ar precīzās semantikas pētījumiem ir nodarbojušies
– – Stephen A. White, Process Modeling Notations and Workflow Patterns, March, 2004, http://www.omg.org/bp-corner/pmn.htm Conrad Bock, ―UML 2 Activity and Action Models Part 4: Object Nodes‖, in Journal of Object Technology, vol. 3, no. 1, pp. 27-41. http://www.jot.fm/issues/issue_2004_01/column3 Conrad Bock, ―UML 2 Activity and Action Models Part 2: Actions‖, in Journal of Object Technology, vol. 2, no. 5, pp. 41-56. http://www.jot.fm/issues/issue_2003_09/column4 Rik Eshuis, Roel Wieringa, Comparing Petri Net and Activity Diagram Variants for Workfow Modelling – A Quest for Reactive Petri Nets, 2003, http://is.tm.tue.nl/staff/heshuis/pnt.pdf Harald Störrle, Jan Hendrik Hausmann, Towards a Formal Semantics of UML 2.0 Activities, 2004, http://www.pst.informatik.unimuenchen.de/~stoerrle/V/AD-11-Limits.pdf Harald Störrle, Semantics and Verification of Data Flow in UML 2.0 Activities, 2004, http://www.pst.informatik.uni-muenchen.de/~stoerrle/V/AD2bDataFlow.pdf
–
–
–
–
32/56
UML 2.0 aktivitāšu diagrammas piemērs
33/56
Kondrāda Boka (Conrad Bock) skaidrojumi Jot
• Skaidrojumi ar detalizētākām bildēm un detalizētāku tekstu kā standartā, bet dinamika tik un tā aprakstīta angļu valodā
34/56
Stefena vaota (Stephen A. White) Workflow Patterns
• Apskatījis izplatītākos (un ne tik izplatītus) workflow paternus, ko skaidro ar BPMNu un UML AD.
– – – – Zarošanās (paralelitāte) Izvēles Cilpas Pārtraukumi
35/56
Rik Eshuis, Roel Wieringa
• • Semantics and Verification of UML Activity Diagrams for Work flow Modelling, Comparing Petri Net and Activity Diagram Variants for Work ow Modelling – A Quest for Reactive Petri Nets Skaidro translējot AD uz Petri tīkliem, apskata tikai notikumus, bet nav datu plūsmas AD apakškopa ir salīdzināma ar Stāvokļu diagrammu (State Chart)
• •
36/56
UML Activity mapping to the Petri Nets, Harald Störrle
Semantics of UML 2.0 Activities, Semantics and Verification of Data Flow in UML 2.0 Activities Semantics of Exceptions in UML 2.0 Activities
Apskata gan notikumus, gan datu plūsmas, gan apakšizsaukumus translējot tos uz Petri tīkliem. Vispilnīgākais no skaidrojumiem, izmantojot Petri Nets
37/56
Mūsu izveidotā AD VM ir savādāka no UML standarta • Implementē tikai apakškopu (kas nepieciešama biznesa procesu parakstīšanai): – Elementi no Fundamental, Basic, Intermediate, daži no Complete Activities:
– Activities, Actions, Control and Object Flows, Activity Parameter Nodes, Pins, Control Nodes, Activity Partitions and Groups
•
Ierobežojumi diagrammām:
a) outgoing edge from a ControlNode is not an incoming edge for the same ControlNode b) there should be no paths between CallBehaviorActions, InitialNodes, FinalNodes or ActivityParameterNodes containing both ForkNodes and JoinNodes a) b) Forbidden Constructs:
...
...
38/56
Activity Diagram standarta semantika • Control Nodes with Guards are working as "traffic switches‖ for ―visibility‖ of ―offered tokens‖ • Only active elements are Action Engines
– They try to fill up their input pins with sets of tokens using "transitive closure visibility― of ―offered tokens‖
• Activity Diagram Standard Semantics:
– ―visibility rules‖ are harder to implement than simple actions – Processing of ―offered tokens‖ ―all at once‖ doesn’t work correctly for Single Execution mode (important for simulation) concurrent control tokens may be lost
39/56
Mūsu virtuālās mašīnas semantika • Edges and Control nodes between stable nodes are concatenated into Paths:
– PassRule is created from Guards of Path’s edges which are "anded" together – each PassRule can be evaluated independently
• Main active elements are Push and Pull token Engines:
– provide token movement between stable nodes (actions, initial, final) – Push engines are used for outgoing branches – Pull engines are used for incoming branches
• Our semantics:
– Simple and more suitable for execution – Works also in Single Execution mode
40/56
AD metamodeļa apakškopa un atbilstošās ADVM klases
Activity isSingleExecution: Boolean = False Activity 0..1 behavior * node isSingleExecution: Boolean = False ActivityR ActivityNode *0..1 behavior parameter ActivityR ParameterR behavior * Behavior node target 1 *source incoming * outgoing * ActivityNode edge ActivityEdge target 1 source incoming * outgoing Condition * edge ActivityEdge Constraint 1 guard 0..1 1 * CallBehaviorAction 1 CallBehaviorAction Action 1 ObjectNode Action * Queue 0..1 locus ControlNode FinalNode ControlNode StableNode Type StableNode FlowFinal FlowFinalNode ActivityFinalNode ActivityFinal InitialNode DecisionNode ForkNode MergeNode Fork Merge Initial Decision 1 type ValueSpecification joinSpec 1 JoinNode Join Final
Path Type Queue Output Pin * outgoingPath * incomingPath * input * output * IntermediateNode Path Parameter Input Pin Output Pin 0..1sourceNode 0..1 * outgoingPath 1..* ObjectFlow * incoming incomingPath * parameter 1 targetNode Edge * IntermediateNode outgoing * * incoming * outgoing outgoing incoming 1 TokenEngine 0..1sourceNode 0..1 1..* OpaqueBehavior 1 1..* ObjectFlow * incoming 1 input 0..1 finish 0..1 targetNode Edge returnResult 0..1 output outgoing * * incoming 1..* * target 0..1 InputQueue outgoing incoming 1* outgoing 1 token ActionBody ActivityParameterNode Token OpaqueBehavior 1 start 1..* input 0..1 finish 1 tokenID: long * formalParameter output 0..1 source returnResult 0..1 value * target 0..1 InputQueue OutputQueue 1 ActionBody ActivityParameterNode start * formalParameter 0..1 source OutputQueue behavior parameter * {ordered} Behavior* Input Pin
1 ObjectNode * * input * output
41/56
Ceļi (Paths) un marķieru dzinēji (Token Engines)
• Paths are created as a "transitive closure" of Edges and IntermediateNodes between Queues of StableNodes.
– constraints and conditions, coming from Guards and Control Nodes are "concatenated" into the PassRule
• TokenEngines for queues are added the following way:
– if for an OutputQueue there exists at least one OutgoingPath without Join, then a PushEngine for this OutputQueue is created
– if for an InputQueue there exists at least one IncomingPath with Join, then a PullEngine for this InputQueue is created
a [a] [b] b Push c d [a] Pull j Pull e k Pull [b] Push [c] f g h i
42/56
Mūsu AD virtuālās mašīnas metamodelis
(bez ActivityFactory klases)
Action ActivityR isSynchronous : Boolean = True activityID: long process(): Bool isSingleExecution: Boolean = True delToken(InputQueue,Token) isActive: Bool * execute(Object[*]): Bool action putToken(OutputQueue, Token) isFinal: Bool = True 1 guard activate() Condition 1..* activity stableNode process(): Bool expression: String joinCriteria action joinSpec evaluate(Token[*]): Bool terminate() StableNode 1 1 invoke(Oject[*]) 1 passRule node ActionBody getParams() Behavior Body: String setParams() 0..1 1..* path 0..1actionBody Path {subsets iNode} hasJoin: Bool Decision engine 1..* 1 join 1..* Join canPass(Token): Bool 1..* TokenEngine pullPath Merge * output input * queue process(): Bool 1..* end 1 {subsets queue} {ordered} putToken(InputQueue, Token) PullPath * input Fork input 1 InputQueue hasJoin: Bool = True delToken(OutputQueue, Token) Queue * fork {subsets queue} target moveToken(Queue, Token) {subsets iNode} * parameter parameter * locus inputQueue 1 {ordered} 0..1 0..1 tokenGroup ParameterR outputParameter * 1 * {ordered} 0..1 direction: ParameterDirectionKind inputParameter * 1 type * TokenGroup parameter 0..1 source value start 1 OutputQueue * output Type 0..1 parameter PushEngine tokenGroup {subsets queue} PushPath 0..1 type 1 1 type 0..1 pushEngine 1 hasJoin: Bool = False pushPath finalNode 1..* output 1 1 outputQueue token * token {ordered} * {subsets queue} Final Token * FlowFinal 0..1 * process(): Bool pullEngine passedToken * tokenID: long PullEngine value {subsets token} initialNode * checkTokens(): Token[*] 1 ActivityFinal selectedToken * delete() Initial canJoin(Token[*]): Bool {subsets token} 0..1 targetNode incoming * IntermediateNode Edge 0..1 sourceNode outgoing * edge iNode * * iNode 1..* * 1 incoming {ordered} {ordered} edge 1 outgoing
43/56
Mūsu ADVM ekvivalence un izmantošana
• Equivalence:
– Essential event trace – starts of action executions and the token sets consumed and produced by these actions are the same for both virtual machines on any activity diagram. In our subset of UML Activity Diagrams
• there is no real race for tokens by actions in the selected subset (no implicit fork, no forks in a path leading to a pull engine, mutually exclusive guards for decisions) • any token will be delivered to its destination in our VM not later than in the original VM • assertion that all input pins must have at least one token (or an appropriate group of tokens, if this is a ―join pin‖) for the action to start, becomes true at exactly the same moment when the original VM would have finally collected all the offered tokens
• Usage:
– Works well for BPM and workflow systems, easily implementable – AD simulator – a tool important for workflow validation
44/56
Citas saites
• A.Kalnins, J. Barzdins, E.Celms. Efficiency Problems in MOLA Implementation. 19th International Conference, OOPSLA’2004, Vancouver, Canada, October 2004 http://melnais.mii.lu.lv/audris/OOPSLA_MOLA.pdf QVT-Merge Group. MOF 2.0 QVT RFP, Revised submission, version 1.0. OMG Document, ad/2004-04-01, http://www.omg.org/cgi-bin/doc?ad/2004-04-01
•
45/56
Biznesa procesu transformācijas
Pētījumi uzsākti 2005. gadā un tiek turpināti. Pētījuma rezultāti ir apvienoti rakstā Use of UML and Model Transformations for Workflow Process Definitions, kas tiek gatavots iesniegšanai konferencē.
46/56
Kas ir biznesa procesu transformācijas
Mūsdienu pasaulē pastāv daudz un dāžādas modelēšansa valodas, kuras var izmantot biznesa procesu modelēšanai:
UML 2.0 Activity Diagram UML 2.0 State Machine JPDL - jBPM Process Definition Language. DSL -Domain Specific Language (biznesa procesu modelēšanas ―profils‖ gan nav definēts) BPEL - Business Process Execution Language for Web Services XPDL (XML Process Definition Language), BPML (Business Process Modelling Language), YAWL (Yet Another Workflow Language)
Ir arī daudz un dažādi dzinēji, kas izpilda procesu definīcijas (šobrīd vairums no tiem izpilda uz UML stāvokļu diagrammu bāzētas valodas). Mūsu uzskats ir ka izstrādājot sistēmas ar MDD pieeju nepārtraukti rodas vajadzība transformēt modeļus:
a) b) abstraktāku procesa definīciju konkrētākā valodā (PIM->PSM transformācija), Procesa definīciju vienā valodā uz citu līdzīgu valodu (PIM->PIM transformācija)
Ja transformācijas nav iespējams veikt automātiski, MDD ideja nav dzīvotspējīga, jo tad biznesa procesu ir izdevīgāk uzreiz implementēt kādā specifiskā veidā (programmēšanas valodā).
47/56
Derek Miers, Paul Harmon, The 2005 BPM Suites Report, Process Modeling & Simulation Tools Report
• • Analizē (definē) Workflow sistēmas Norāda uz svarīgajām funkcijām
– – – – – Integrācija (prasme izsaukt citas sistēmas), Automatizācija (kontroles struktūras, izvēles, cilpas) Resursu pārvaldība (t.i. materiāli un arī cilvēki) Dažādi uzdevumu veidi (sistēmas iekšienē, citu sistēmu izsaukšana, manuālas operācijas) Atbalstu manuālu operāciju veikšanai uzsveram arī mēs
48/56
BPMN vs AD
• Stephen A. White, Process Modeling Notations and Workflow Patterns
– –
– –
BPTrends March, 2004, http://www.omg.org/bp-corner/pmn.htm Apgalvo, ka BPMN un UML AD ar laiku saplūdīs vienā valodā, jo esot ļoti līdzīgas. Mēs tam nepiekrītam, jo metamodeļi ir ļoti dažādi Dažādi skaidrots (biznesa un viena ―sadarbības partnera‖) procesa jēdziens, AD ir vairāk ―datu plūsmas vadīta‖, bet BPMN vairāk ―notikumu vadīta‖
Arī apgalvo līdzīgi, ka UML AD un BPMN ir līdzīgi
•
Howard Smith, BPM and MDA: Competitors, Alternatives or Complementary
–
•
AD ir PIM pēc definīcijas, bet:
– – Domas dalās, vai PSM jābūt izpildāmām, daži uzskata, ka PIM ir tuvāks biznesa līmenim un tādas lietas kā iterators, vērtību pieškiršana PIMā nav vajadzīga Bet, tad, lai PIMu varētu izpildīt, transformējot uz PSMu, būs jāliek klāt (parasti jāimplementē manuāli) kaut kas papildus
•
BPMN tiek uzskatīta par PIM, bet dažās jomās tā ir specifiskāka par AD. Tai ir labāk izstrādāta:
– – – procesu sadarbība procesu veicēju norāde operācijām dažādu veidu procesu (iekšējie, izsaukumi uz ārējām sistēmām, manuāli) izdalīšana
49/56
Business Process Definition Metamodel
• Standarts:
– Business Process Definition Metamodel Revised Submission to BEI RFP bei/2003-01-06, Object Management Group (OMG), http://www.omg.org/docs/bei/04-01-02.pdf
•
Sasaucas ar Stephen A. White, un ir dots vienkāršāko diagrammas elementu mapings no BPMN uz AD,
– – Nav mapojuši pašu galveno - Business Process/Process/Pool/Lane uz AD un tās elementiem Notikumu mapošana ir vienkāršota, nav ņemti vērā start/intermedia/end notikumu mapošanas atšķirība uz AD elementiem, Nav ņemta vērā elementu asociāciju pretējo galu elementu mapošana
–
Timeout
Error Signal
Throw Exception
50/56
Jaunākās ziņas: BPMN un OMG
• Endrjū Votsona (Andrew Watson) 9-Nov-2005 prezentācija "OMG ’s new modelling specifications―
– norāda, beidzot arī OMG ir ķērušies pie biznesa modelēšanas sakārtošanas. Viņš min jomas, kas augstā līmenī sasaucas ar mūsu pēdējo gadu pētījumiem:
• Business motivation model (biznesa apkārtne) • Business Process Modelling Notation (dinamikas apraksts BPMN AD vietā) • Semantics of Business Vocabulary & Rules (―statiskās struktūras‖ apraksts) • Organisational structure metamodel (beidzot!)
– Šobrīd balstās uz mūsu veco ideju, ka BPMN un AD var ―pabāzt‖ zem vienota metamodeļa cepures.
• Tālāk parādīsim, ka ar transformāciju to izdarīt ir efektīvāk, jo nav vajadzīgas nedabīgas ―kopīgās konstrukcijas‖
51/56
PIM -> PSM workflow transformācijas
• • • • Stephen A. White "Using BPMN to Model a BPEL Process― BPMN -> BPEL (Business Process Execution Language (for Web Services)) Jean Bezivin, u.c., Applying MDA Approach to B2B Applications – AD -> BPEL Behzad Bordbar, Athanasios Staikopoulos, On behavioural model transformation in Web services,izveidojuši BPEL metamodeli, AD -> BPEL Keith Mantell, From UML to BPEL, Model Driven Architecture in a Web services world AD -> BPEL Tā kā mērķa valoda (BPEL) ir šaura, izmanto tika daļu no workflow definēšanas līdzekļiem (tikai automātiskas procedūras), iztrūkst:
– – resursu pārvaldība manuālu operāciju atbalsts
•
•
Nav darbu, kas veiktu pilnvērtīgu (mūsu izpratnē) workflow transformāciju
52/56
Biznesa process, aktivitāšu diagrammā un BMPNā
nam order e: type: Order
Validate Order
perform ers:Receiption
Customer Invoice Calculate Discount PreparePayment
perform ers:Custom er im plem S :W interface: Paym ents nam discount e: type: Discount
order.status= Rejected CreateInvoice
im plem :EJB interface: Invoices
order.status= Accepted
Invoice Payment
Fill Order
Payment order.status:= Cancelled Payment.invoice= Order.invoice Close Order
perform ers:Accountant
53/56
AD biznesa procesa profils (M2 slānis)
* nestedClassifier Element 0..1 represents 0..1 class 0..1 context *ow nedBehavior base$Class ObjectNode Behavior 0..1 behavior * Com ponent ow nedOperation provided * Interface 0..1 interface * Operation ow nedOperation ex tension$OrgUnit 1 operation OrgUnit OpaqueBehavior Activity body : String name : String ex tension$Position language : String activityScope 0..1 Position activity superGroup * activityGroup edge node * * 0..1 * subGroup * outgoing source 1 ActivityNode 0..1 inGroup containedEdge * ActivityEdge ActivityGroup * incoming target1 containedNode* 0..1 inGroup variable * interruptingEdge * * VariableAction Variable 1 variable Action variable base$Variable * ActivityPartition body * ex tension$PartitionVariable input * ReadVariableAction 1 name : String PartitionVariabe InputPin WriteVariableAction base$Activ ity Partition 0..1 0..1 ex tension$Component scope Com ponent 0..1 setup value 1 CallBehaviorAction LoopNode ValuePin * base$CallBehav iorAction 0..1 test ex tension$Performer 0..1 CallOperationAction EJB WS ex tension$ManualTask Perform er CallManualTask base$CallOperationAction 1 Entity ex tension$Process 1 ex tension$Serv iceTask Process guard value CallServiceTask Role ex tension$UserTask ValueSpecification 0..1 CallUserTask expression : String InterruptibleActivityRegion interrupts 0..1 class Class
Šis ir Aktivitāšu diagrammas metamodeļa daļa, (MOLA transformācijas avots) Metamodelis ir papildināts, izmantojot ―vājo‖ paplašināšanu, t.i. izmantojot tikai stereotipus. Ar stereotipiem metamodelis mainīts netiek - stereotipiem var tikai pievienot papildus elementārus atribūtus, vai mainīt esošo asociāciju jēgu, bet nevar ieviest jaunas klases vai asociācijas
54/56
BPMN metamodelis (M2 slānis)
BusinessProcess 1 diagramRef 1 Object * graphicalElements 1 Process Role properties * process 0..1processRef 0..1 Entity 1 * assignments Property Swimlane Assignm ent name : String toProperty * expression : String parentLane Participant 0..1 type : String 1 assign assignTime : String pool 1..* pools 1 participant * properties assignments * * assignments Lane * parentPool Pool pools Gate * lanes pool 1 objects * FlowObject 1 * 0..1 1 lanes * Event * gates activity 0..1 * includedElements 1 Task 2 Activity Gatew ay implem : String caller * * caller loopType : LoopType IndependentSubprocess 0..1 subprocess performers : String[*] Em beddedSubprocess interface : String
Šis ir BPMN metamodeļa daļa, (MOLA transformācijas mērķis) Metamodelis ir veidots pēc Business Process Modeling Notation (BPMN), Version 1.0 - May 3, 2004, Business Proc-ess Management Initiative (BPMI, http://www.bpmi.org/) vārdiskā apraksta
55/56
AD->BMN MOLA transformācijas fragments
AD (diagrammas) transformācija uz BPMN Business Process un Pool
AD Partition transformācija uz BPMN Pool un Process
56/56
Citas Saites
•
• •
• • • • • • • • • • • •
Web Services Business Process Execution Language Version 2.0, Working Draft 01, December 2004, OASIS Open, Inc., http://www.oasis-open.org/apps/org/workgroup/wsbpel/ Tom Baeyens, The State of Workflow, May 2004, http://www.theserverside.com/articles/content/Workflow/article.html Derek Miers, Paul Harmon, The 2005 BPM Suites Report, Version 1.0, March 15, 2005, http://www.bptrends.com/reports_toc_01.cfm Curtis Hall, Paul Harmon, The 2005 Enterprise Architecture,Process Modeling & Simulation Tools Report, Version 1.0, April 28, 2005, http://www.bptrends.com/reports_toc_02.cfm Petia Wohed, et.al., Pattern-based Analysis of UML Activity Diagrams, http://is.tm.tue.nl/research/patterns/download/uml2patterns BETA TR.pdf Behzad Bordbar, Athanasios Staikopoulos, On behavioural model transformation in Web services, 5th International Workshop on Conceptual Modeling Approaches for e-Business eCOMO'2004, November 8-12, 2004, http://www.cs.bham.ac.uk/~bxb/Papres/eCOMO-paper-011.pdf Jean Bezivin, et.al., Applying MDA Approach to B2B Applications: A Road Map, Workshop on Model Driven Development (WMDD 2004) at ECOOP 2004, Springer-Verlag, LNCS, vol. 3344, June 2004, http://www.sciences.univ-nantes.fr/lina/atl/www/papers/ECOOP2004bezivin.pdf Rational Software Architect, http://www-306.ibm.com/software/awdtools/architect/swarchitect/ Tracy Gardner, UML Modelling of Automated Business Processes with a Mapping to BPEL4WS, Apr 21, 2004, http://www-128.ibm.com/developerworks/rational/library/4593.html Stephen A. White, Using BPMN to Model a BPEL Process, BPTrends, March 2005, http://www.bptrends.com/publicationfiles/03-05 WP Mapping BPMN to BPEL- White.pdf QVT-Merge Group. MOF 2.0 QVT RFP, Revised submission, version 1.0. OMG Document, ad/2004-04-01, QVTMerge. http://www.omg.org/docs/ad/05-03-02.pdf A. Kalnins, J. Barzdins, E. Celms. ―Model Transformation Language MOLA‖. Proceedings of MDAFA 2004 (ModelDriven Architecture: Foundations and Applications 2004), Linkoeping, Sweden, June 10-11, 2004. pp.14-28. ProGuide, http://www.proformacorp.com xBML, http://www.xbmlinnovations.com Celms E., A. Kalnins, L. Lace. ―Diagram definition facilities based on metamodel mappings‖. OOPSLA’2003 (Workshop on Domain-Specific Modeling), Anaheim, California, USA, October 2003, pp. 23-32.
57/56
Turpmākie pētījumi
• Modelēšanas valodu metamodeļu izstrāde MOLA transformāciju pielietojumiem – BPMN, – .. Domēnspecifisku modelēšanas rīku izstrāde (uz EBM vai Jaunā rīka bāzes) – ...
•