Institute of Informatics Web services and sensor networks laboratory. Enn Õunapuu

Transcription

1 Institute of Informatics Web services and sensor networks laboratory Enn Õunapuu

2 Content Oveall approach BPMN Examples

3 Main research area Enterprise architecture (EA) is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise's future state and enable its evolution. [1]

4 Enterprise information systems development Model-driven engineering (MDE) is a software development methodology which focuses on creating and exploiting domain models (that is, abstract representations of the knowledge and activities that govern a particular application domain), rather than on the computing (or algorithmic) concepts.

5

6 Problem statement We have to change how we create enterprise systems. Todays problems: 1. Takes a lot of time, money and resources 2. Quality is not on needed level 3. Software created is loosely coupled with domain goals

7 Our approach Evolutionary approach to systems Model driven software engeneering Aditionally to software models (uml like), Business model, business context model, business rules Stongly connected with formal method event-b

8 Evolutionary systems Enterprise systems are social systems with machine and man agents They evolve over time For evolution we need DNA

9 Lehman s Laws of Software Evolution Based on measurement of a few (commercially-developed) systems, most notably IBM s OS 360 Originally three laws, now there are eight. Controversial as laws Has been criticized for strong claims based on limited data. However, it s pioneering work on software evolution and software engineering.

10 Lehman s Laws of Software Evolution 1. Continuing change An E-type program that is used must be continually adapted else it becomes progressively less satisfactory. 2. Increasing complexity As a program is evolved, its complexity increases unless work is done to maintain or reduce it. 3. Self regulation The program evolution process is self-regulating with close to normal distribution of measures of product and process attributes.

11 Lehman s Laws of Software Evolution 4. Invariant work rate The average effective global activity rate on an evolving system is invariant over the product lifetime. 5. Conservation of familiarity During the active life of an evolving program, the content of successive releases is statistically invariant. 6. Continuing growth Functional content of a program must be continually increased to maintain user satisfaction over its lifetime.

12 Lehman s Laws of Software Evolution 7. Declining quality E-type programs will be perceived as of declining quality unless rigorously maintained and adapted to a changing operation environment. 8. Feedback system E-type programming processes constitute multiloop, multi-level feedback systems and must be treated as such to be successfully modified or improved.

13 Lehman s Laws in a nutshell Observations: (Most) useful software must evolve or die. As a software system gets bigger, its resulting complexity tends to limit its ability to grow. Development progress/effort is (more or less) constant. Advice: Need to manage complexity. Do periodic redesigns. Treat software and its development process as a feedback system (and not as a passive theorem).

14 Additional laws for systems Systems have goals and this designates the direction of evolution Systems must have selforganizing features In man-machine systems, machines take more and more functions

15 Change patterns and evolutionary narratives Cathedral style [Raymond] careful control and management debugging done before committing code evolution is slow, planned, rarely undone Bazaar style (OSD) lots of low-level changes, frequent fixes lots of building around rather than wholesale changing, occasional redesigns creeping feature-itis, complete dependency graph

16 Change patterns and evolutionary narratives Band-aid evolution (just add a layer) quick & dirty way to add new functionality, esp. if system is not well understood e.g., Y2K fixing, adding portability, new features Vestigial features design artifact persists after rationale dies e.g., whale fin bone structure resembles hand

17 Change patterns and evolutionary narratives Adaptive radiation [Lehman] when conditions permit, encourage wild variation for a while. later, evaluate and let best ideas live on. e.g., Linux kernel evolution Convergent evolution compare similar systems to reference arch. (or to each other) e.g., everyone grows an XML generator in response to market pressure

18 Change patterns and evolutionary narratives Radical redesigns (localized and global) aka refactoring little new functionality added, but structure changes significantly, legacy cruft dissipates likely goodness (design metrics) improves Migration patterns look out for known translation idioms, especially if migration is not one big bang e.g., procedural-to-oo idioms

19 Change patterns and evolutionary narratives OO evolutionary patterns one recognizable design pattern transformed into another (or a variation of the original) requires good OO extraction tools (dynamic binding, polymorphism, reflection, etc.) Reuse patterns components are (re)used in different systems e.g., build COTS interface, throw out homebrew DB

20 Change patterns and evolutionary narratives Phenomena observed in Linux evolution Bandwagon effect Contributed third party code Mostly parallel enables sustained growth Clone and hack Careful control of core code; more flexibility on contributed drivers, experimental features

21 Summary of future research More case studies needed Qualitative and quantitative Industrial and open source systems Different problem domains, architectures Supporting tools to aid analysing, visualizing, and querying program evolution More than just RCS and perl Support for architecture repair Why and how does software change? Build catalogue of change patterns and evolutionary narratives

22

23

24 MDE Perspectives

25 Perspektiivide metamudel

26 Äriprotsessi konteksti perspektiiv

27 Business process definition The word process is defined in the dictionary as a series of actions, changes, or functions bringing about a result. Martyn Ould: A process is a coherent set of activities carried out by a collaborating group to achieve a goal.

28

29

30 Agenda for BPMN BPM reference model BPMN basic elements Modelling methodology BPMN diagramming style BPMN practical patterns BPMN-based modelling procedure Evolution of BPMN BPMN advanced use summer

31 Context for BPMN Ideally, one formal description of business processes model in design input for project planning and execution executable program for coordination of work documentation for all staff members Explicit expression of coordination Express relationships between BPM artefacts Understandable by all staff members A tool for communication A tool for joint work of the business and the IT summer

32 BPMN standard An original development by Business Process Management Initiative to align modelling notations since 2000 The primary goal understanding by business stakeholders OMG standard since 2005 Current version 1.2 since Jan 2009 Version 2 is under development summer

33 Standards 2002 Timeline Releases Ref Model WfMC WPDL XPDL 1.0 XPDL 2.0 XPDL 2.1 XPDL 2.2 BPMI BPMN 1.0 XML OMG BPMN 1.0 BPMN 1.1 BPMN 1.2 BPMN 2.0

34 Agenda BPM reference model BPMN basic elements Modelling methodology BPMN diagramming style BPMN practical patterns BPMN-based modelling procedure Evolution of BPMN BPMN advanced use summer

35

36 BPMN basic set shapes 3 kinds of flow objects Activity Gateway Event 3 ways of connecting Sequence flow Message flow Association Two types of container Pools Lanes (swimlanes) summer

37 Three types of coordination logic (1) Template-based static connection of flow objects or sequence relationship (predecessor and successor) similar to a river (upstream and downstream) process template is an abstract description of a process summer

38 Three types of coordination logic (2) Token-based token marks elements which active at a particular time dynamic connection of flow objects or synchronisation (wait for) / chronologic relationship similar to a flock of ducks (split and join) several tokens may co-exist summer

39 Three types of coordination logic (3) Instance-based process instance is an enactment of a process template each instance may have different behaviour of tokens a process instance is completed when all tokens have been consumed a process instance may start several instances of another process (although the latter is mentioned only once in the former) summer

40 Event types Start event produces a token End (or finish) event consumes a token Intermediate token means that something happened within a business process engine summer

41 Event details Too many events details Recommendations to use: Mainly message Sometimes empty, error and timer Start message Throw message Catch message End message summer

42 Event Details as Applied to Start, Intermediate, and End Events summer

43 Simplest useful process It has at least one activity! summer

44 Parallel gateway Activity02, Activity03 and Activity04 will be executed in parallel; the process will only be continued when each of them is completed Logic of tokens is used summer

45 Exclusive gateway A single activity Activity02 or Activity03 or Activity04 will be executed. The choice is based on the logic defined within the gateway G01 Logic of tokens is used summer

46 Inclusive gateway Several activities can be executed in parallel It covers functionality of parallel and exclusive gateways Logic of tokens is used summer

47 Logic of templates vs. logic of tokens Many tokens can pass the same activity summer

48 Process fragments Process fragment is a compound activity Also called sub-process summer

49 Repeatable process fragments (1) Repeating conditions may be different in different systems summer

50 Repeatable process fragments (2) Be explicit within fragments; the exclusive gateway G01 which is used to specify two branches one to continue the loop and one to exit it summer

51 Process fragment as logical grouping Catching errors and time-outs summer

52 Handling of messages (1) summer

53 Pool A pool is a container for activities carried out by a particular participant in a process Typically, a participant is a role for a human activity a service (or a process) for an automated activity summer

54 Connectors Flow connector represents the sequence of activities within the same pool Message connection represents the communication between activities in separate pools summer

55 Handling of messages (2) summer

56 The full set of elements summer

57 Agenda BPM reference model BPMN basic elements Modelling methodology BPMN diagramming style BPMN practical patterns BPMN-based modelling procedure Evolution of BPMN BPMN advanced use summer

58 Sub- models There are three basic types of sub-models within an end-to-end BPMN model: 1. Private (internal) business processes 2. Abstract (public) processes 3. Collaboration (global) Processes summer

59 Private Business Process summer

60 Abstract public process summer

61 Collaboration Business Process summer

62 Example of unstructured BPMN summer

63 Diagramming style in BPMN (1) Horizontal vs. vertical timeline Timeline summer

64 Diagramming style in BPMN (2) P a r t i c i p a n t s summer

65 Agenda BPM reference model BPMN basic elements Modelling methodology BPMN diagramming style BPMN practical patterns BPMN-based modelling procedure Evolution of BPMN BPMN advanced use summer

66 Workflow patterns Recent research work led by several universities has led to the identification of about 40 workflows patterns; used for comparison of different workflow engines Visit Most of them are complex summer

67 Anti-pattern PRF Process Realisation Faked summer

68 Pattern PP Process Package With a process instance we carry a package with Business objects (by value and by reference) Business documents (by value and by reference) Key Performance Indicators (KPIs) Audit trails Comments Local variables etc summer

69 Agenda BPM reference model BPMN basic elements Modelling methodology BPMN diagramming style BPMN practical patterns BPMN-based modelling procedure Evolution of BPMN BPMN advanced use summer

70 Principles of the modelling procedure it treats human and automated activities equally it is primarily for capturing the flow of control, and not for optimisation it is a tool for both the business and the IT (maybe with coaching by a process architect/engineer) it provides validation by simulation it provides validation by quick prototyping real services can be invoked it is a visual programming approach summer

71 The modelling procedure Its purpose is to analyse a building block (what it is supposed to do) to synthesise its implementation (how it does this) as the explicit coordination of other building blocks (processes or activities) It is iterative we can apply it until we have left only indivisible building blocks (i.e. activities) Artefacts are constructed recursively, like Russian dolls summer

72 Four phases summer

73 Blackboxing phase The purpose to analyse a building block as a whole to discover its functional characteristics and some related artefacts The method the business story behind this building block should be carefully analysed to determine some of its artefacts Recommendations at this point, don t go into excessive detail for each artefact; this should be done later summer

74 Structuring phase (1) The purpose to analyse a building block from within to determine its internal structure and its major artefacts The method determine the main functional (or logical) steps add check-points between steps classify artefacts for these steps Recommendations don t have more than 7 steps avoid loop-back over check-points summer

75 Structuring phase (2) Steps and check points summer

76 Structuring phase (3) Steps, check points and artefacts summer

77 Re-construction phase (1) The purpose to synthesize an initial version of the formal coordination: some kind of process skeleton The method add intra-step logic start formalising the business objects involved collect test scenarios Recommendations consider implementation of human activities as interactive forms summer

78 Re-construction phase (2) The diagram summer

79 Instrumentation phase (1) The purpose to enrich the process skeleton by adding more automated activities The method add pools apply different practical patterns use a business rule engine if available collect test scenarios Recommendations work iteratively (step-by-step) summer

80 Instrumentation phase (2) The diagram summer

81

82

83

84 Example of business rules usage

85 HTML5 and CSS

86 Bizagi models Remote desktop connection ID035P

87 Questions?