INF5120 Modellbasert Systemutvikling Modelbased System development

Transcription

1 INF5120 Modellbasert Systemutvikling Modelbased System development Lecture 14: Arne-Jørgen Berre or 1

2 Course parts (16 lectures) n January February (1-7) (BAE/WebRatio): n 1-18/1: MDE-1: Introduction to INF5120 n 2-25/1: MDE-2: Modeling structure and behaviour (UML and UML 2.0 and metamodeling) ( B. Hjelle, Biocaching) n 3-1/2: BAE-1: Business Architecture Business Model Canvas - Strategyzer tool. n 4-8/2: SAE-1: WebRatio for Mobile App development (Get an App up and running!) n 5-15/2: BAE-2: Essence, Scrum, User stories and Use cases 2.0, Backlog, with Someone n 6-22/2: BAE-3: BPMN process, VDML and UML Activ.Diagrams, (MD/EA, Smaply and Balsamiq) n 7-29/2: BAE-4: Service Design, AT ONE,Touchpoints, UI, UX, Smaply and Balsamiq (Ragnhild Halvorsrund, SINTEF) n Oblig 1: BA Spec, WebRatio App1 (individual) (end of February, March 7 th ), Agile Scrum n March (8,9) (MDE/IFML/Client-Side): n 8-7/3: MDE-3: Model driven engineering Metamodels, DSL, UML Profiles, EMF, Sirius Editors n 9-14/3: SAE-2: IFML Interaction Flow Modeling Language, WebRatio advanced n April (10, 11,12,13) (BPMN, SAE/UML/Server-side): n 10-4/4: SAE-3: BPMN and WebRatio BPM platform/magicdraw BPMN n 11/4: SAE-4: UML Service Modeling, ServiceML,SoaML, REST, UML 2.0 Composition, MagicDraw n 12-18/4:MDE-4: Guest lecture: DSL and ThingML, Franck Fleurey) and Web Meet with project from Florida Atlantic University, FAU, Boca Raton, FL, USA (from ) n Oblig 2: Sirius DSL Editor for IFML +/- (individual), WebRatio/IFML App2 UI (inc. 2) (April 18 th ) n 13-25/4:SAE-5: MDE transformations, Non Functional requirements OCL and PLanguage n May (14,15,16): (Bringing it together) n 14-2/5: MDE-5: Enterprise Architecture, TOGAF, UPDM, SysML DSLs etc. Oblig 2: demos n 15-9/5: SAE-6: S Summary of course, Metamodeling/DSL principles, Oblig 3 demos: BPMN/BPM, WebRatio SenseApp (May 9 th ) n 16-23/5: MDE-6: Conclusions, Preparations for the Exam by old exams n 6/6: Exam (4 hours), (June 6 th ) 2

3 Content n Enterprise Architecture - MagicDraw n ISO RM/ODP n UPDM for MODAF/DODAF/(NAF) n EuroControl SJU n TOGAF n INF5120: EA = BA (BMC, SD) + SA (IFML, UML) n ArchiMate og Archi 3

4 MagicDraw Cameo Enterprise Architecture 4

5 5

6 6

7 7

8 8

9 9

10 10

11 11

12 Zachman Framework n Row 1 Scope External Requirements and Drivers Business Function Modeling n n n n n 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 12

13 Zachman Framework for Enterprise Architecture (IBM, 1987) VA Enterprise Architecture 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 (CONCEPTUAL) Semantic Model Business Process Model Business Logistics System Work Flow Model Master Schedule Business Plan ENTERPRISE MODEL (CONCEPTUAL) Owner Ent = Business Entity Proc = Business Process Rel = Business Relationship I/O = Business Resources Node = Business Location Link = Business Linkage People = Organization Unit Work = Work Product Time = Business Event Cycle = Business Cycle End = Business Objectiv e Means = Business Strategy Owner SYSTEM MODEL (LOGICAL) Logical Data Model Application Architecture Distributed System Architecture Human Interface Architecture Processing Structure Business Rule Model SYSTEM MODEL (LOGICAL) Designer TECHNOLOGY MODEL (PHYSICAL) Ent = Data Entity Rel = Data Relationship Physical Data Model Proc = Application Function Node = IS Function I/O = User Views Link = Line Characteristics System Technology Design Architecture People = Role Work = Deliv erable Presentation Architecture Time = System Event Cycle = Processing Cycle Control Structure End = Structural Assertion Means = Action Assertion Rule Design Designer TECHNOLOGY MODEL (PHYSICAL) Builder Ent = Segment/Table Rel = Pointer/Key Proc = Computer Function I/O = Data Elements/Sets Node = Hardware/Softw are People = User Link = Line Specifications Work = Screen Format Time = Execute Cycle = Component Cycle End = Condition Means = Action Builder DETAILED Data REPRESENTATIONS Definition (OUT-OF-CONTEXT) Program Network Architecture Security Architecture 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 Network Organization Schedule Strategy FUNCTIONING ENTERPRISE Ent = Rel = DATA What Proc = I/O = FUNCTION How Node = Link = NETWORK Where People = Work = PEOPLE Who Time = Cycle = TIME When End = Means = MOTIVATION Why 13

14 Content n EA and the Zachman Framework n Architectural Frameworks - (IEEE/ 1471/ISO 42010, ADL, UML 2.x, TOGAF, UPDM n UPDM (DODAF/MODAF, NAF), n NIEM n TOGAF n Service modeling and Service oriented views n Tool support, Metamodels and UML profiles No Magic, Magic Draw 14

15 Many Architectural Frameworks. ARIS ZACHMAN GERAM EKA - POPS EN/ISO Athena OEA NIST 15

16 TOGAF 9 (The Open Group) 16

17 17

18 ISO RM/ODP (ISO 10746)

19 Why and When: Historical Development of AF s. MODAF Meta-Model (M3) expressed using UML Notation NAF v NAF v DNDAF v C4ISR Architectur e Framework v C4ISR Architectur e Framework v MACCIS Norway DoDAF v1.0 MODAF v TOGAF1 - MODAF v Scope of UPDM 1.0 Approved Sept 2008 MODAF v DoDAF v DoDAF V Scope of UPDM 2.0 Started Sept 2009 TOGAF9

20 Towards a Unified Architecture Framework 20

21 Three Views in DOD Architecture Framework and C4ISR-AF 21

22 DODAF viewpoints 22

23 EAEA European Air Traffic Management Enterprise Architecture 23

24 IEEE 1471, ISO

25 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 Architecture SoaML, UML Distributed System Architecture SoaML, UML Human Interface Architecture BPMN, CMPM Process Structure BPMN, CMPM, DTFV Business Rule Model SBVR Technology (Physics) Physical Data Model IMM (CWM), UML System Design SoaML, UML Technology Architecture SoaML, UML Presentation Architecture Control Structure BPMN, CMPM, DTFV Rule Design SBVR Component (Assemblies) Data Definition IMM (CWM), UML Program UML Network Architecture UML Security Architecture Timing Definition DTFV Rule Definition SBVR Operation (Instances) Data Function Network Organization Schedule Strategy 25

26 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 Architecture Business Logistics System Distributed System Architecture BPMN CMPM Workflow Model Human Interface Architecture Master Schedule Process Structure Business Plan SBVR Business Rule Model Technology (Physics) IMM (CWM) Physical Data Model SoaML System Design UML Technology Architecture Presentation Architecture Control Structure DTFV Rule Design Component (Assemblies) Data Definition Program Network Architecture Security Architecture Timing Definition Rule Definition Operation (Instances) Data Function Network Organization Schedule Strategy 26

27 UPDM coverage Data (What) Function (How) Network (Where) People (Who) Time (When) Motivation (Why) Scope (Contexts) Business (Concepts) System (Logic) BPMN UPDM SoaML Technology (Physics) Component (Assemblies) Operation (Instances) 27

28 Model Based Systems Engineering and Interoperability Business Architecture (SysML Context + BPMN 2.0/BMM) BMM BPMN VDM CaseMgmt OSM SBVR ModelDriven Architecture (MDA,Oslo) Enterprise Architecture (EA) for Systems of Systems (UPDM) System & IT Service oriented Architecture (UML&SysML/SoaML) Interoperability Architecture (MDI) UML 2.0 SoaML SysML

29 What is UPDM? - Summary n UPDM 1.0 is a standardized way of expressing DoDAF 1.5 and MODAF 1.2 artefacts using UML and SysML n UPDM is NOT a new Architectural Framework n UPDM is not a methodology or a process n UPDM 2.0 is scheduled to address DoDAF 2.0, MODAF 1.2, NAF 3.x, and DNDAF 1.7 n UPDM 1.0 was developed by members of the OMG with help from industry and government domain experts. n UPDM 1.0 has been implemented by multiple tool vendors. n Tools supporting UPDM 1.0 are available now.

30 n UPDM: UML Profile for DoDAF and MODAF Context n n n n Stakeholders n n n n n OMG n n n US DoD UK MOD NATO Canada/Australia OMG, INCOSE XMI, UML, SysML BPMN UPMS, BMM End Users n n Aerospace Commercial Tool Vendors n n n Software Systems Enterprise NAF Meta Model DoDAF 1.5 Concepts CADM 1.5 UJTL SF List CDD CONOPS SSDD etc. MODAF Meta Model UPDM Domain Meta Model UPDM Profile Meta Model External References UPDM Profile & Library <<import/merge>> UML4SysML SysML Extensions SoaML, BMM, SBVr Extensions Products -- Reports -- Simulations DoDAF 2.0 Ontology Transformations CADM AP233 XMI IDEF UML SysML BPMN SoaML BMM

31 UPDM - Unified Model for DODAF and MODAF 31

32 UPDM 32

33 33

34 34

35 Enterprise Architecture Modeling with UPDM

36 Introduction nenterprise Architecture modeling n No rocket science! nit's a standard! nupdm: nunified Profile for MODAF and DoDAF

37 What is Enterprise Architecture?

38 Enterprise Architecture n Business, partners, customers n Application ecosystem nsystem of system architecture nthe world nnot: application or device n

39 UML EA Framework nsemantic classification nextra rules for construction nadditional data ntraceability between views

40 UPDM n Unified Profile for DoDAF and MODAF (UPDM) n Developed by OMG with DoD support n Created by multiple vendors, governments, customers n Implements architecture for DoD, MOD, and others

41 UPDM 2.0 Standard n Approved by the OMG September, 2011 with DoD/MOD support n Implements DoDAF 2.0 guidance and traced to DM2 metamodel as a UML extension n Submitted to DISR as Emerging September, 2011 (in registry 14 November 2011) n Beta from existing UPDM vendors n UPDM 1.0 to 2.0 conversion available now

42 Advantages of UPDM n Leverages existing UML tools and capabilities n Automated completeness/correctness of models n Supported by multiple vendors in consistent form n Customizable via standard-based methods/interoperability n Supports executable architecture via executable UML n

43 Structure

44 Simple Example n Two things (very simple model) n Presentation not in build order n Key elements of UPDM used

45 High Level Operational Concept n Elevator Speech of the architecture n Summarizes the key concepts of the architecture n Picture, not a model n Usually one diagram per project, but there may be many if required. n HLOC can be composite diagram

46 OV-1 Thing Concept

47 Thing HLOC

48 Operational Resource Flow (OV-2) n Documents logical view of performers and logical data interactions n Summarizes the architecture's business viewpoint n Business, not the implementation of the business n Also used to build OV-3 (Operational Exchange Matrix) and others

49 Thing World

50 More Things

51 Whole/Part Hierarchy n Composite can show detailed communication paths n Further details added via ports n Same thing as Internal Block Diagram n

52 Part Design Method

53 Operational Exchanges

54 The World

55 Services View

56 Service Context

57 UPDM IN PRACTICAL USE n Relevant approach for Enterprise Architecture n Agile: Iterative model development n Accepted and promoted by the DoD n Reporting and traceability n Integrated architecture and development n Useful tool for capturing customer requirements

58 OV-1a: Operational Context Graphic OV-1a [High Level Operational Concept] Maritime Rescue control Rescue Helo : Aircraft trackinfo Yacht : Boat assistance trackinfo distresssignal Monitor Unit : Monitor Rescue Boat : Boat Naval Ship : Boat trackinfo control control C2 Center : Control Center

59 OV-1: Operational Context Graphic

60 OV-2 Operational Nodes OV-2 [Node] Search and Rescue (With Ports) TCN «PerformerRole» SN : Search POS WO : warningorder SN «PerformerRole» PoS : Place of Safety SAC RN PID Tsk : tasking Ctrl : control Stat : status «PerformerRole» RN : Rescue SAC Tsk : tasking SN DS2 : distresssignal PID TCN Ctrl : control DS3 : distresssignal RN SN1 «PerformerRole» PiD : Person in Distress SN2 DS1 : distresssignal SN RN RN PID «PerformerRole» Rqst : request SAR AC : SAR Asset Control TCN SAC «PerformerRole» TC2N : Tactical C2 MN TI : trackinfo TCN «PerformerRole» MN : Monitoring SN

61 OV-5 Activity Diagram OV-5 [Architectural Description] Operational Activities «Activity(Operational)» Search «ActivityPerformedByPerformer» «StandardOperationalActivity» Find Victim «ActivityPerformedByPerformer» «Performer» «block» Search «ActivityPerformedByPerformer» «Activity(Operational)» Receive Distress Signal «Activity(Operational)» Send Warning Order «ActivityPerformedByPerformer» «ActivityPerformedByPerformer» «StandardOperationalActivity» Monitor Health «Activity(Operational)» Rescue «StandardOperationalActivity» Recover Victim «ActivityPerformedByPerformer» «ActivityPerformedByPerformer» «ActivityPerformedByPerformer» «Performer» «block» Rescue «Activity(Operational)» Receive Distress Signal «ActivityPerformedByPerformer» «StandardOperationalActivity» Provide Medical Assistance

62 OV-5 Activity Diagram

63 SV-1: Resource Interaction Specification SV-1 [System] Maritime Rescue Unit v1 «SystemRole» MR Boat : Boat «DataExchange» «ItemFlow» BI : boatinstruction «SystemRole» MRT : Maritime Rescue Team «OrganizationRole» Driver : MRT Boat Driver «SystemRole» Beacon : Lighting Device Mon «SystemRole» Radio : Communication Device «SystemRole» Life Preserver : Life Saving Device «DataExchange» «ItemFlow» BCI : beaconinstruction Comm «DataExchange» «ItemFlow» RI : radioinstruction «DataExchange» «ItemFlow» LPI : lifepreserverinstruction «OrganizationRole» Searcher : MRT Searcher Med «OrganizationRole» Radio Operator : MRT Communicator «OrganizationRole» Rescue Swimmer : MRT Swimmer «SystemRole» MR Aircraft : Aircraft Air «DataExchange» «ItemFlow» AI : aircraftinstruction «OrganizationRole» Pilot : MRT Helicopter Pilot

64 SV-2: Resource Interaction Specification SV-2 [System] Maritime Rescue Architecture v1 «SystemRole» Rescue Unit : Maritime Rescue Unit v1 Src Rsc DS : distresssignal «SystemRole» MR Boat : Boat «SystemRole» Yacht : Boat Src Rsc «MaterielRole» dsout Distress Beacon : Lighting Device DS : distresssignal dsin «MaterielRole» Monitor : ESM System «SystemRole» MR Aircraft : Aircraft trkin TRK2 : track dsin «MaterielRole» Monitor : ESM System TRK1 : track trkin RI1 : radioinstruction transmitter receiver «MaterielRole» Radio : Communication Device RI2 : radioinstruction «MaterielRole» Radio : Communication Device trkout «MaterielRole» Digital Service : Link 16 TD1 : TDM tdmreceiver tdmtransmitter TD2 : TDM trkout «MaterielRole» Digital Service : Link 16 transmitter receiver tdmtransmitter tdmreceiver

65 SysML Example: Requirements Traceability

66 Associated Analysis Tools

67 Related Elements n Traceability Matrix n Dependency Matrix n Related elements display n Show relationships n Show ports n Show internal structure

68 TOGAF 9 (The Open Group) 68

69 Open Group ADM 69

70 70

71 Building block evolution 71

72 Service categories 72

73 73

74 74

75 ArchiMate 75

76 Archi 76

77 77

78 Business Product View 78

79 ArchiMate Authors : eschoolink Group - ITNLU

80 Contents 1. What s ArchiMate? 2. Why ArchiMate? 3. Main Benefits of ArchiMate 4. Layers of ArchiMate 5. ArchiMate vs UML 6. Notations of ArchiMate 7. Demo

81 What is ArchiMate? n ArchiMate is a modelling technique ("language") for describing enterprise architectures. n It presents a clear set of concepts within and relationships between architecture domains, and offers a simple and uniform structure for describing the contents of these domains. n ArchiMate distinguishes itself from other languages such as Unified Modeling Language (UML) and Business Process Modeling Notation (BPMN) by its well defined metamodel, and wider enterprise modelling scope.

82 What is ArchiMate? n ArchiMate offers a common language for describing the construction and operation of business processes, organizational structures, information flows, IT systems, and technical infrastructure. n This insight helps the different stakeholders to design, assess, and communicate the consequences of decisions and changes within and between these business domains.

83 What is ArchiMate? n An architecture framework is used to structure the concepts and relationships of the ArchiMate language n It divides the enterprise architecture in to a business, application and technology layer. In each layer, three aspects are considered: active elements that exhibit behavior (e.g. Process and Function), an internal structure and elements that define use or communicate information.

84

85 Why ArchiMate? n Enterprise architecture is an important instrument to address this company-wide integration. n It is a coherent whole of principles, methods and models that are used in the design and realization of the enterprise's organizational structure, business processes, information systems, and IT infrastructure.

86 Why ArchiMate? n A good architecture practice enables an organization to align business and IT operations with its strategy, quickly respond to changes in the environment, and make optimal use of technological opportunities. n The development and maintenance of architectures will lead to efficiency, cost reduction and flexibility.

87 Why ArchiMate? n Within companies various domain architectures can be found, like organization, business process, application, information, and technical architectures. n Each architecture domain has its own concepts for the modelling and visualization of its internal coherence. These specific models and visualizations simplify communication, discussion and analysis within the domain

88 Why ArchiMate? n However, the relations between the concepts in these different domains are in many cases unclear. Moreover, these domains often partially overlap but use different notions to express the same ideas, sometimes even with-out the people involved knowing this. n The resulting ambiguities and confusion stand in the way of the flexibly and efficiently operating organizations we envisage.

89 Why ArchiMate? n ArchiMate wants to do away with these ambiguities. It presents a unified way of modelling enterprise architectures, integrating the various domains and describing them in an easily readable way n ArchiMate is of course not an isolated development. The relationships with existing methods and techniques, like modelling languages such as UML and BPMN, and methods and frameworks like TOGAF and Zachman, are well-described.

90 Main Benefits of ArchiMate 1. It is an international, vendor-independent standard of The Open Group, liberating you from the lock-in of vendor-specific tools and frameworks. There is active support from the ArchiMate Forum of The Open Group. 2. Its well-founded concepts and models provide precision. It helps you get away from the 'fuzzy pictures' image of architecture. 3. It is a lean and simple language. It contains just enough concepts for modeling enterprise architecture and is not bloated to include everything possible. Its uniform structure makes it easy to learn and apply.

91 Main Benefits of ArchiMate 4. It has clear links to existing approaches for specific architecture areas such as software or business processes. Several concepts in ArchiMate have deliberately been borrowed from other languages such as UML or BPMN, to provide an easy bridge. 5. It does not prescribe a way of working, but it is easily combined with existing methods such as TOGAF. 6. It has been tried and tested by many different user organizations and is supported by numerous consultancies and software tools.

92 Layers n A layered view provides a natural way to look at service-oriented models. The higher layers use services that are provided by the lower layers. ArchiMate distinguishes three main layers: q The Business layer offers products and services to external customers, which are realized in the organization by business processes performed by business actors and roles. q The Application layer supports the business layer with application services which are realized by (software) application components. q The Technology layer offers infrastructural services (e.g., processing, storage and communication services) needed to run applications, realized by computer and communication hardware and system software.

93 Layers

94 Layers, domains

95 Layers, domains

96 Overview of the ArchiMate concepts and main relationships.

97 ArchiMate vs UML ArchiMate n ArchiMate was created to model the architecture of an enterprise (all of the systems in an organization). n ArchiMate models the business, information system (application and data), and technology architectures of the environment, including how these architectures are inter-related. l l UML UML still functions best as a way to document the architecture of a single system UML provides 13 diagram types, providing flexibility to describe many different types of systems.

98 ArchiMate vs UML n Archimate started with an understanding that these problems relate to one another; that the entire complex and difficult business of understanding IT requires a rich inter-relationship of completely different domains, from business motivation to business process to managed services to systems to infrastructure. n Thus Archimate goes where UML doesn t: it defines a metamodel that allows these relationships to be constructed, and constrained, and communicated. The constraints allow analysis, traceability, governance, and consistency. UML is unconstrained between model types. Archimate is not.

99 Notations n Every concept and relation should have a precise graphical notation, with a sufficient resemblance the standard ArchiMate notation. The notation in the Visio stencils can be used as a guideline n Optionally, multiple notations may exist for a single concept. n It should be possible to denote composition, aggregation and assignment both with their line notation and with nesting.

100 Relations n The following relation types should be supported: n n n Structural relations: n composition* n aggregation n assignment n used by n realisation n access n association Dynamic relations: n triggering n flow Other relations: n grouping n junction n specialisation*

101 Notations

102 Notations & Relations

103 Demo

104 Demo

105 Demo

106 Demo

107 Demo

108

109