Roundtrip Performance Engineering or Architecture Driven Modelling

1. Roundtrip Performance Engineering or Architecture Driven Modelling Rob Pooley Heriot Watt University rjp@macs.hw.ac.uk EPEW 2004

2. The goal Techniques Process Engineering EPEW 2004

3. The goal? Design models Process Software Design EPEW 2004

4. The goal? Functional models Process Formal methods EPEW 2004

5. The goal? Performance models Process Performance Engineering EPEW 2004

6. The goal Design models + Functional models + Performance models Process Software Engineering EPEW 2004

7. Managing Complexity • Software development is hampered by the complexity of large software systems • Software engineering has developed techniques to manage this complexity • These depend on hiding detail not essential to the task in hand • This is design abstraction EPEW 2004

8. Graphical models in software design • Software design has become increasingly a modelling activity • Currently most new design is based on the object oriented paradigm • Increasingly, most new designs use the Unified Modelling Language (UML) EPEW 2004

9. About the UML • The Unified Modelling Language (UML) is an industry standard for object oriented design notation, supported by the Object Management Group (OMG). • It is becoming widely adopted in many areas of the software and computer systems development community. EPEW 2004

10. Key Diagrams in UML Requirements Capture System Structure System Behaviour Use Case Diagrams Class Diagrams Collaboration Diagrams Interaction Diagrams Activity Diagrams State Charts EPEW 2004

11. Modelling the dynamic behaviour of designs • Collaboration diagrams enhanced with • Interactions • internal behaviour • Internal behaviour expressed as statecharts • Generation of reachable system states by marking individual object states • Possible annotation with probabilities to capture non-deterministic behaviour • Simulation or analysis of resulting state machines/stochastic processes EPEW 2004

12. Collaboration diagram p:Producer b:Buffer :Customer c:Consumer EPEW 2004

13. Collaboration diagramwith interaction p:Producer 1a:add() b:Buffer :Customer 1b:request() 1b.1:take() c:Consumer EPEW 2004

14. State diagram producing after(t1) storing when(not blocked)/b.add() EPEW 2004

15. State diagrams • Statecharts, based on Harel's notation define the internal behaviour of an object: • states are lozenges; the initial state is shown as a black filled circle; the terminating state is a white filled circle with a black dot inside it. • transitions are arrows between states, with a trigger and an action sequence; • triggers are the reason for an object to leave and follow the transition • actions are any actions caused by a trigger, carried out before entering a new state; EPEW 2004

16. Triggers and actions • typically a trigger is • an incoming message - shown in the usual way for messages, • a change in a condition -- shown as when followed by the condition enclosed in brackets • the elapsing of time - shown by the word after followed by the duration in brackets • some actions involve sending messages; the name of the object to which it is sent, separated from the message by a dot. EPEW 2004

17. p:Producer producing after(t1) storing when(not blocked)/b.add() c:Consumer consuming after(t2) acquiring when(avail)/b.take() State/collaboration diagram 2:take() 1:add() has none has three add()/avail:=True take()/blocked:=False take()/avail:=False add()/blocked:=True take() has one has two add() EPEW 2004

18. Combined state machine • At any point in the lifetime of this system, each object must be in one, and only one, of its internal states. • Each time a message is passed, it causes a state change in the receiving object and causes a further message to be passed • Execution of the system can be viewed as the unravelling of this sequence, conditioned on values of input data. EPEW 2004

19. Evolution of the system • The overall state of a system will be • the combination of all the current internal states of its objects, • plus the current values of any relevant attributes plus the time currently elapsed in any after triggers. • Those familiar with Petri nets may sense a certainly similarity to the concept of marking and enabling in a timed net. EPEW 2004

20. Generation of a solvable model • At any time this system must have each of its 3 objects in exactly 1 of its states. • We call these combinations markings to reflect their similarity to Petri net markings. • If we assume an initial marking, such as the Producer producing, the Buffer empty and the Consumer acquiring, we derive all the reachable markings by following through the interactions which result. EPEW 2004

21. EPEW 2004

22. State transition graph EPEW 2004

23. UML Profiles • UML Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms • UML Profile for Schedulability, Performance and Time • UML Testing Profile EPEW 2004

24. UML Profile for QoS and Fault Tolerance This specification defines a set of UML extensions to represent Quality of Service and Fault-Tolerance concepts. These extensions reduce the problems of UML 2.0 for the description of Quality of Service and Fault-Tolerance properties, and integrate the extensions in two basic general frameworks (QoS Modeling Framework, and FT Modeling Framework). The general framework for the description of QoS requirements and properties gives the support to describe vocabulary that is used in high quality technologies (e.g., real-time, fault-tolerant). EPEW 2004

25. UML Profile for Schedulability, Performance and Time Specifies a  UML profile that defines standard paradigms of use for modeling of time-, schedulability-, and performance-related aspects of real-time systems" that (1.) enable the construction of models that can be used to make quantitative predictions regarding these characteristics; (2.) facilitate communication of design intent between developers in a standard way; and (3.) enable interoperability between various analysis and design tools. EPEW 2004

26. UML Testing Profile • The UML Testing Profile defines a language for designing, visualizing, specifying, analyzing, constructing and documenting the artifacts of test systems. It is a test modeling language that can be used with all major object and component technologies and applied to testing systems in various application domains. The UML Testing Profile can be used stand alone for the handling of test artifacts or in an integrated manner with UML for a handling of system and test artifacts together. EPEW 2004

27. coherence, demand, dependability, efficiency, integrity, latency, mitigation, security, risk assessment, scalabality, throughput analysis, concurrency, domain viewpoint, extensions, modeling, model processing, performance, real-time, resource, schedulability, tag value language, time, UML Keywords • Arbiter, Coding Rules, Coordination, Data Partition, Data Pool, Log Action, Observation,  Profile, Stimulus, Test Architecture, Test Behavior, Test Case, Test Component, Test Configuration, Test Control, Test Data, Test Elements, Test Invocation, Test Objectives, Test Suite, Test Trace, Time Concepts, Timeout, Timer, Timezone, Utility Part, Validation, Action, Verdict, Wildcard EPEW 2004

28. MDA proposes a hierarchical approach to design High level Platform Independent Models give an architectural view of the design Lower level Platform Specific Models are then derived using patterns or algorithmic techniques Model driven architecture EPEW 2004

29. Model driven architecture • In an MDA development project, this separation of concerns becomes even clearer. Each stakeholder views the application from a unique point of view (business, architecture, development, infrastructure) and contributes to the project from a specific area of expertise using an easy-to-learn subset of UML to visualize a specific domain and ensure that its requirements are clearly stated and well met. The team uses various tools to design, build and test each new iteration of the software under development; and as each iteration builds on the structure and functionality of the ones that came before it, the architecture and the application grow together. Top-level managers can supervise and coordinate all of the contributors. When it’s complete, the application meets both functional and nonfunctional requirements because the experience of the team as a whole covers them, and no individual is required to be a virtuoso in every aspect. MDA leverages the skills of all of these people much better than traditional development does, guaranteeing that their good design carries through into the final product. Grady Booch, Software Development August 2004 EPEW 2004

30. MDA Proficiency: Achieving Best Practices Through Patterns • For me, the most exciting architectural advance in the past decade is the emergence of patterns. What patterns really do is codify the best practices we’ve learned and developed for years. Patterns can be implemented by expert developers once, stored in libraries, and incorporated into applications when the code generator recognizes a pattern in a model. Or a designer can build a pattern into a model using a wizard that, along the way, lets the user set parameters to customize it for a given application. If your company develops its own patterns for competitive advantage in your domain, you should choose a tool that lets you insert your own pattern models into the model library, and corresponding implementations into the code library, for insertion into their applications. Grady Booch, Software Development August 2004 EPEW 2004

31. My view at ICSE 2000 EPEW 2004

32. Our challenges now? • True roundtrip integration with the design process • Hierarchical modelling to match the MDA approach • Integration with realtime modelling • Integration with functional analysis • Incorporation with the pattern world EPEW 2004

33. Roundtrip integration • Analyse performance at the high level • Bring back modifications at lower level to review the high level • Maintain the correspondence of performance, functional and design models at all levels EPEW 2004

34. Hierarchical modelling • Understand which elements are sensitive in terms of performance • Reuse sub-models in designs • Maintain consistency EPEW 2004

35. Integration with realtime modelling • Can we have a single view of time? • Can we use the same structural and functional models? • Will the user have to know the differences? EPEW 2004

36. Integration with functional analysis • We know about this with Petri nets and proces algebras • Can we incorporate this in UML and MDA? EPEW 2004

37. Incorporation with the pattern world • Patterns and anti-patterns • Automatic exploitation of patterns • Automatic identification of anti-patterns • Generation of performance models based on patterns • Testing based on patterns EPEW 2004

38. What we might focus on • Learn from the UML experience • Catalogue our present capabilities • Focus on a shared vocabulary • XML schema for interoperability • UML profiles with compatible tag sets • Then go further • Build open source frameworks for tool integration • Populate these with compatible tools EPEW 2004

39. What we might avoid • More standalone tools • More new languages and formalisms • More esoteric techniques • Analysis without application EPEW 2004

40. EPEW • The start of the realisation of Connie Smith´s vision? EPEW 2004