INF Lecture plan

Transcription

1 INF5120 Modellbasert Systemutvikling Modelbased System development Lecture 2: Arne-Jørgen Berre and 1 INF Lecture plan Part I: SSI Service Innovation and Agile Service/Software Engineering Part II: SSMDE Model Driven Engineering Part III Model Driven Interoperability and ADM 1: 16/1: Introduction to Model Based System Development (INF5120) 2: 23/1: SIE I: Enterprise, Role modeling-collaboration and Value Networks Verna Allee (VNA) 3: 30/1: SIE II:: Business Process Modeling with BPMN 2.0 and Business Model Innovation - Peter Lindgren (BMI) 4: 6/2: SIE III: AT ONE Service Design, Agile User-oriented design with Use cases/stories and UI models 5: 13/2: SIE IV: Service modeling with SoaML Service modeling - Design, patterns 6: 20/2: SIE V: Information Modeling with UML and Design with DCI - Design, patterns 7: 27/2: MDE I: Software Process Model Frameworks Essence/SEMAT, SPEM, EPF and ISO Shihong Huang/Brian Elvesæter 8: 5/3: MDE II: Metamodels, Domain specific languages and UML profiles (Franck Fleurey) 9: 12/3: MDE III: Metamodeling, MDLE and DSL Tools (EMF, GMF, ATL, Kermeta) 10: 19/3: MDE IV: Model transformations - MOFScript, QVT DSLs with examples 11: 26/3: MDE V: Internet Service s - with BPM/BPEL and SOA/Cloud transformations 2/4, 9/4: EASTER 12: 16/4: MDE VI: User Interface Modeling IFML etc. - ESITO 13: 23/4: MDI I: Semantic technologies, Ontologies and Semantic annotations, Rules/SBVR 14: 30/4: MDI II: Model Driven Service Interoperability 15: 7/5: MDI III: ADM and Migration to Cloud computing 16: 13/5: Conclusion and Summary for INF Preparation of Exam Exam: Monday June 4th, 2011, (4 hours) 2 1

2 Content EA and the Zachman Framework Architectural Frameworks - (IEEE/ 1471/ISO 42010, UML 2.x, TOGAF, UPDM (DODAF/MODAF) OO Modeling and abstraction levels Role modeling UML Collaboration modeling GRASP - General Responsibility Assignment Software Patterns VNA Value Network Analysis, Verna Allee 3 Value Network Analysis Verna Allee verna.allee@valuenetworks.com 4 2

3 Zachman Framework for Enterprise (IBM, 1987) VA Enterprise DATA What FUNCTION How NETWORK Where PEOPLE Who TIME When MOTIVATION Why Based on work by John A. Zachman SCOPE (CONTEXTUAL) Things Important to the Business Processes Performed Business locations Important Organizations Ev ents Significant to the Business Business Goals and Strategy SCOPE (CONTEXTUAL) Planner Entity = Class of Business Thing Function = Class of Business Process Node = Major Business Locations People = Major Organizations Time = Major Business Event Ends/Means = Major Business Goals Planner ENTERPRISE MODEL (CONCEPTU AL) Semantic Model Business Process Model Business Logistics System Work Flow Model Master Schedule Business Plan ENTERPRISE MODEL (CONCEPTU AL) Owner Ent = Business Entity Proc = Business Process Node = Business Location People = Organization Unit Time = Business Event Rel = Business Relationship I/O = Business Resources Link = Business Linkage Work = Work Product Cycle = Business Cycle End = Business Objectiv e Means = Business Strategy Owner SYSTEM MODEL (LOGICAL) Logical Data Model Application Distributed System Human Interface Processing Structure Business Rule Model SYSTEM MODEL (LOGICAL) Designer Ent = Data Entity Rel = Data Relationship Proc = Application Function Node = IS Function People = Role I/O = User Views Link = Line Characteristics Work = Deliverable Time = System Event End = Structural Assertion Cycle = Processing Cycle Means = Action Assertion Designer TECHNOLOGY MODEL (PHYSICAL) Physical Data Model System Design Technology Presentation Control Structure Rule Design TECHNOLOGY MODEL (PHYSICAL) Builder Ent = Segment/Table Rel = Pointer/Key Proc = Computer Function Node = Hardware/Softw are People = User I/O = Data Elements/Sets Link = Line Specifications Work = Screen Format Time = Ex ecute End = Condition Cycle = Component Cycle Means = Action Builder DETAILED Data REPRESENTATIONS Definition (OUT-OF-CONTEXT) Program Netw ork Security Timing Definition Rule Design DETAILED REPRESENTATIONS (OUT-OF-CONTEXT) Sub-Contractor Ent = Field Rel = Address Proc = Language Statement Node = Addresses I/O = Control Block Link = Protocols People = Identity Work = Job Time = Interrupt Cycle = Machine Cycle End = Sub-Condition Means = Step Sub-Contractor FUNCTIONING ENTERPRISE Data Function Netw ork Organization Schedule Strategy FUNCTIONING ENTERPRISE Ent = Rel = Proc = I/O = Node = Link = People = Work = Time = Cycle = End = Means = DATA What FUNCTION How NETWORK Where PEOPLE Who TIME When MOTIVATION Why 5 Zachman Framework Row 1 Scope External Requirements and Drivers Business Function Modeling Row 2 Enterprise Model Business Process Models Row 3 System Model Logical Models Requirements Definition Row 4 Technology Model Physical Models Solution Definition and Development Row 5 As Built As Built Deployment Row 6 Functioning Enterprise Functioning Enterprise Evaluation Contextual Conceptual Logical Physical As Built Functioning What What How How Where Where Who Who When When Why Why Contextual Conceptual Logical Physical As Built Functioning 6 3

4 Many Architectural Frameworks. ARIS ZACHMAN GERAM EKA - POPS EN/ISO Athena OEA NIST 7 TOGAF 9 (The Open Group) 8 4

5 Open Group ADM

6 Building block evolution 11 Service categories 12 6

7 DODAF viewpoints 13 EAEA European Air Traffic Management Enterprise 14 7

8 IEEE 1471, ISO Zachman with OMG standards Data (What) Function (How) Network (Where) People (Who) Time (When) Motivation (Why) Scope (Contexts) List of things important to business SBVR List of processes that the business performs VDM List of locations which the business operates VDM List of organizations important to the business OSM List of events/cycles important to the business DTFV List of business goals/strategies BMM Business (Concepts) Semantic Model ODM, IMM (CWM) Business Process Model BPMN, CMPM Business Logistics System BPMN, CMPM Workflow Model OSM, BPMN, CMPM Master Schedule BPMN, CMPM, DTFV Business Plan SBVR System (Logic) Logical Data Model ODM, IMM (CWM), UML Application SoaML, UML Distributed System SoaML, UML Human Interface BPMN, CMPM Process Structure BPMN, CMPM, DTFV Business Rule Model SBVR Technology (Physics) Physical Data Model IMM (CWM), UML System Design SoaML, UML Technology SoaML, UML Presentation Control Structure BPMN, CMPM, DTFV Rule Design SBVR Component (Assemblies) Data Definition IMM (CWM), UML Program UML Network UML Security Timing Definition DTFV Rule Definition SBVR Operation (Instances) Data Function Network Organization Schedule Strategy 16 8

9 Use of OMG metamodels BPMN (BPMN 2.0) BMM UML 2.0 SoaML OSM VDM Case Management SBVR ODM 17 OMG standards coverage Data (What) Function (How) Network (Where) People (Who) Time (When) Motivation (Why) Scope (Contexts) SBVR List of things important to business List of processes that the business performs VDM List of locations which the business operates OSM List of organizations important to the business List of events/cycles important to the business BMM List of business goals/strategies Business (Concepts) System (Logic) Semantic Model ODM Logical Data Model Business Process Model Application Business Logistics System Distributed System BPMN CMPM Workflow Model Human Interface Master Schedule Process Structure Business Plan SBVR Business Rule Model Technology (Physics) IMM (CWM) Physical Data Model SoaML System Design UML Technology Presentation Control Structure DTFV Rule Design Component (Assemblies) Data Definition Program Network Security Timing Definition Rule Definition Operation (Instances) Data Function Network Organization Schedule Strategy 18 9

10 Interaction Structure Function Coordination Information Quality Agile Service Development (1/3) New book in the publishing process until April 2012, Springer. We will use a publication preprint initially 19 ASD Framework Requirements Context and Goals Design Interactions Roles Functions Processes Information EFA Extra Functional Aspects Implementation Interface Actors Tasks Orchestration Data QoS SLA Infrastructure Channels Resources Executors Workflows Stores and Messages Monitoring, adaptation 10

11 Interaction Structure Function Coordination Information Quality with INF5120 Modeling techniques Requirements Design UI Interactions Role Models SoaML Roles Context and Goals Functions collaboration BPMN Processes Goal oriented Use cases/stories UML Class Information Ontologies OCL EFA Extra Functional Aspects Implementation Interface Actors Tasks Orchestration Data Model Driven /MDE QoS SLA Infrastructure Channels Resources Executors Workflows Stores and Messages Monitoring, adaptation Object-orientation Simula and Smalltalk OORAM and UML Collaboration OORAM role modeling, MVC, DCI Prof. emeritus Trygve Reenskaug See Simula-67 Kristen Nygaard Ole Johan Dahl

12 Scandinavian Modeling perspective (From Simula) A program execution is regarded as a physical model, simulating the behaviour of either a real or imaginary part of the world. A physical model consists of objects, each object is characterized by attributes and a sequence of actions. Objects organize the substance aspect of phenomena, and transformations on substance are reflected by objects executing actions. Objects may have part-objects. An attribute may be a reference to a part object or to a separate object. Some attributes represent measurable properties of the object. The state of an object at a given moment is expressed by its substance, its measurable properties and the actions going on then. The state of the model is the states of the objects in the model. 23 Basis for OO Technology Quality and Productivity Modeling Abstraction and Modularisation Reuse and Maintenance Classification/ Instantiation Encapsulation Sharing Inheritance Polymorphism Object Model 24 12

13 Object oriented model An object oriented model is a (simulation) model that consists of cooperative objects in interaction with each other. Consider also a class model: A set of classes with descriptions of properties and behaviour and a structure of subclasses that inherits from superclasses 25 System and objects A system is a part of the real world which we choose to regard as a whole, separated from the rest of the world during some period of consideration. A whole that we choose to consider as a collection of objects, each object being characterized by attributes and by actions which may involve itself and other objects. Mental modell Real-World phenomenon Manifest Model 26 13

14 Object oriented modeling arealworld- Phenomena anobjectmodel rolemodels animplemented System Environment Model environment Mental model Real-World phenomenon System model Manifest Model 27 OO Programming Terminology Encapsulation Object Message Method Class Instance Inheritance Polymorphism Dynamic (Late) Binding 28 14

15 CRC Method, class, responsibilities, and collaborators Method to learn the most basic OO concepts plus OO thinking The most effective way of teaching the idiomatic way of thinking with objects is to immerse the learner in the "object-ness" of the material. To do this we must remove as much familiar material as possible, expecting that details such as syntax and programming environment operation will be picked up quickly enough once the fundamentals have been thoroughly understood. Technique also very useful during informal and creative analysis and design Created by Kent Beck and Ward Cunningham, Textronix, The CRC-Card an object of paper personalizing the object Class (Name): Responsibility: Collaborators: 30 15

16 Class, responsibilities, and collaborators Class The class name of an object creates a vocabulary for discussing a design. Indeed, many people have remarked that object design has more in common with language design than with procedural program design. We urge learners (and spend considerable time ourselves while designing) to find just the right set of words to describe our objects, a set that is internally consistent and evocative in the context of the larger design environment. Responsibilities Responsibilities identify problems to be solved. The solutions will exist in many versions and refinements. A responsibility serves as a handle for discussing potential solutions. The responsibilities of an object are expressed by a handful of short verb phrases, each containing an active verb. The more that can be expressed by these phrases, the more powerful and concise the design. Again, searching for just the right words is a valuable use of time while designing. Collaborators Objects which will send or be sent messages in the course of satisfying responsibilities. Collaboration is not necessarily a symmetric relation. For example in Smalltalk, View and Controller operate as near equals while OrderedCollection offers a service with little regard or even awareness of its client. 31 UML og ( R )UP Two parts of a Harmonized Whole Unified Modeling Language Process Convergence Today Unification leads to standards Convergence in the future Process frameworks through consensus 32 16

17 OOAD methods Class Phase Traditional SA/SD/ERA ANALYSIS DESIGN DETAILED DESIGN SA - Yordon SD - Page Jones ERA - Chen ER-Rel.db - 3NF SA-based OO ERA-based OO Hybrid SA/ERbased OO SD-basert OO Ada(C++)-based SDL-based OO OO-based OO RT SA - Wards OOA/OOD - Coad/Yordon OMT - Rumbaugh et. al OOAD - Martin/Odell Fusion - HP OOSD - Wasserman HOOD - ESA OOAD - Booch (93 w/c++) OOSE/ObjectOry - Jacobson RDOOD - Wirfs-Brock et. al OSDL-92 - CCITT/Bræk et. al CRC-cards - Cunningham OOram - Reenskaug et. al Catalysis, Syntropy, SOMA, OBA, BHS,... UML (96) Booch/OMT/ObjectOry Collaboration Modeling! 33 Evolution of the UML Submission of UML 1.1 to OMG for adoption, Sept 97 UML 1.0 UML 2.0 (2004) UML 1.4 UML 1.1 (Sept. 1997) Taskon, SINTEF public feedback June 96 & Oct 96 OOPSLA 95 UML 0.9 & 0.91 Unified Method 0.8 UML Partners Expertise Booch 93 OMT - 2 Other methods Booch 91 OMT - 1 OOSE 34 17

18 Evolution of methodologies OOram Catalysis Pulse OMT UML Components 2001 KobrA Booch UML1.0 Objectory UML1.1 Notation UP UML1.2 RUP UML1.3 UML1.4 UML4EDOC Process Objecteering SOA COMET COMET-S Agile Methods UML2 Method frameworks 35 UML Structural Modeling Class Diagram Object Diagram Component Diagram (new in UML 2.0) Package Diagram Deployment diagram 36 18

19 UML Behavioral Modelling Use Case Diagrams Interactions Sequence diagrams (enhanced in UML 2.0) Timing diagrams (new in UML 2.0) Interaction overview diagrams (new in UML 2.0) Communication diagrams (i.e. collaboration diagram) State machine diagrams (enhanced in UML 2.0) Activity Diagrams (enhanced in UML 2.0) 37 Different kind of models Conceptual models Specification models Implementation models 38 19

20 Dealing with Complexity and Change Working at the right level of abstraction OO dealing with complexity objects -> components -> services *SOA Design by contract, role composition Aspect-oriented programming Use of patterns Visual Modeling (MDA) 39 Role model The role model is the basic abstraction in OOram. It is an object oriented model of an object structure and represents a bounded part of an interesting phenomen Traveler Authorizer Bookkeeper Paymaster A role abstraction: - A general role played by many objects - Part of the responsibility for an object 20

21 Synthesis of ExpenseReport and AirlineBooking ExpenseReport Traveler Authorizer Bookkeeper Paymaster AirlineBooking Traveler Secretary Bookkeeper Paymaster TravelAgent CompositModel Traveler Authorizer Secretary Bookkeeper Paymaster TravelAgent Use of synthesis 1. Sep. of concern and composition on one abstraction level 2. Sep. of concern and composition between abstraction levels 3. Specialization - generalization 21

22 Collaboration Collaboration 22

23 CollaborationUse CollaborationUse 23

24 CollaborationUse OORAM role modeling See professor Trygve Reenskaug website See BabyUML & Role Modeling With book reference Working with objects. The OOram Software Engineering Method. Manning/Prentice Hall ISBN

25 OORAM role model Role model Synthesis 25

26 General Responsibility Assignment Software Patterns. Responsibility assignment. 1. knowing (answering) 2. or, doing Guidance and evaluation in mechanistic design. 1. Expert 2. Creator 3. Controller 4. Low Coupling 5. High Cohesion 6. Polymorphism 7. Pure Fabrication 8. Indirection 9. Don t Talk to Strangers Controller What class should receive a system event message? Assign the responsibility for handling a system event message to one of these choices: 1 The business or organization (a façade controller). 2 or, The overall system or aggregate concept (a façade controller). 3 or, An artificial class representing the use case (a use case controller). 26

27 Expert Most general purpose responsibility assignment principle? Assign a responsibility to the information expert the class that has the information necessary to fulfill the responsibility. That which knows, does Who has the most data/information for solving the problem? Expert To have the information means, for example, the object may: know it as an attribute or object reference be able to derive it What is the motivation for Expert? Looking for task-owners that support encapsulation and low coupling. This reduces change impacts. 27

28 High Cohesion How to design classes to increase the likelihood of reuse and not be overwhelmingly complex? Assign responsibilities so that cohesion remains high. Low Coupling How to create reusable components that are resilient to change? Assign responsibilities so that coupling remains low. 28

29 Polymorphism How to handle alternatives based on type? When related alternatives or behaviors vary by type (class), assign responsibility for the behavior using polymorphic operations to the types for which the behavior vary. Applying Polymorphism Square {abstract} name : String... landonby( p: Player )... GoSquare LuxuryTaxSquare IncomeTaxSquare PlainSquare landonby( p: Player ) landonby( p: Player ) landonby( p: Player ) landonby( p: Player ) 29

30 Other GRASP Patterns Creator who creates? Usually the aggregate or containing object. Pure Fabrication design objects. Make it up when desperate. Indirection most problems in computer science Don t Talk to Strangers Law of Demeter 1. Expert 2. Creator 3. Controller 4. Low Coupling 5. High Cohesion 6. Polymorphism 7. Pure Fabrication 8. Indirection 9. Don t Talk to Strangers for more information... Quick overview of Design Principles The Open-Closed Principle by Bertrand Meyer The Dependency Inversion Principle by Robert C. Martin The Liskov Substitution Principle by Barbara Liskov The Interface Segregation Principle by Robert C. Martin 30

31 The Open-Closed Principle Software should be open for extension but closed to modification The goal is to design software that be easily extended without changing any of the existing code Inheritance and the development of abstract base classes play a big role in trying to fulfill this goal The Dependency Inversion Principle High-level modules should not depend on low-level modules. Both should depend on abstractions Abstractions should not depend on details. Details should depend on abstractions Button PushButton ButtonClient Lamp Button and ButtonClient can now vary independently! 31

32 The Liskov Substitution Principle Functions that use base class interfaces must not depend on or be confused by any derivatives of those interfaces A logical extension of the Open-Closed Principle All subclasses should implement the interface of the base class in a manner consistent with the intent of the base class The Interface Segregation Principle Clients should not be forced to depend on interfaces that they do not use The principle here is to avoid cluttering up an interface with things (functions, inheritance relationships) that the clients don t need to use Take a clients perspective!! 32

33 Patterns Abstract Factory Next Lecture BPMN and Business Model Innovation. January 30th, 2012 BPMN Business Model Innovation, Peter Lindgren