INF5120 Modellering med objekter

Transkript

1 INF5120 Modellering med objekter Forelesning Arne-Jørgen Berre 1 Velkommen til INF5120 Modellering med objekter Modellering med objekter Forelesere: Arne-Jørgen Berre Jan Øyvind Aagedal Brian Elvesæter Christoffer Daae-Qvale/Geir Borge Ottersen Birger Møller Pedersen mmo-forelesere@ifi.uio.no Øvingsansvarlig: Sinan Sigurd Tanilkan mmo-oppgaver@ifi.uio.no 2 1

2 Forelesning 1 Praktiske ting og litt om faget Modeller og modellering Objektorientering og Basisbegreper UML notasjon Strukturell modellering UML notasjon Oppførselsmodellering Diskusjoner... Kaffemaskinoppgave... 3 Praktisk Forelesninger m/øvinger torsdager (Lille) 10 studiepoeng, skriftlig, åpen bok eksamen To obligatorisk oppgaver 1) Kort presentasjonsoppgave rundt et gitt case m/tilhørende elektronisk innlevering som postes på web 2) Større caseoppgave som skal innleveres elektronisk Papirkopier av foiler på forelesning Oppdatert web før neste forelesning (29/1) 4 2

3 Krav og forutsetninger Ingen formelle krav (student ved UiO) Kunnskaper tilsvarende IN-219, IN-265 og IN-ODS/IN-DIS vil være en fordel Egeninnsats til lesing om UML notasjon (Dette vil etterhvert undervises i fag på lavere grad) se egen støttebok 5 INF Forelesninger M: MDA, O: OptimalJ,, R: RUP, U: UML, C: COMET (Literature references) 1: 22/1: Introduction OO, UML 1.5 and 2.0 (U, R) 2: 29/1: MDA technologies and RUP Process, ( M, R) 3: 5/2: Requirements Modeling, ( R, U) 4: 12/2: PIM Modeling Domain/Service (M, O) 5: 19/2: PSM Mapping EJB and DBMS (M, O) 6: 26/2: PSM Mapping Web and User Interface/Presentation rules (M, O) 7: 4/3: Business Rules and introduction to OCL (M, O) 8: 11/3: Testing, packaging and deployment (M, O) 9: 18/3: Business and CIM Modeling with Architecture mappings: ( C) 10: 25/3: Architecture and System Modeling UML 2.0 (C, U) 11: 1/4: Behavioural Modeling Sequence and State diagrams, exeuml 2.0 (U) 12: 15/4: Non-functional requirements Quality of service (C) 13: 22/4: Component Modeling /design OCL (C, U) 14: 29/4: MDA, MOF, CWM and QVT Transformations (M, C) 15: 6/5: Genericity: Patterns/reuse/Frameworks, Repository, Product line (C) 16: 13/5: Summary preparation for exam 6 3

4 INF5120 Øvinger stk = 25 grupper a 3-4, 2 grupper hver gang, 12 ganger 1: 22/1: Kaffemaskin 2: 29/1: UML modellering Gruppe Oblig 1 3: 5/2: MDA og Prosess - Gruppe Oblig 1 4: 12/2: Krav Modell Gruppe Oblig 1 5: 19/2: PIM modell - Gruppe Oblig 1 6: 26/2: PSM: EJB og DBMS Gruppe Oblig 1 7: 4/3: PSM: Web og UI Gruppe Oblig 1 8: 11/3: Business Rules Gruppe Oblig 1 9: 18/3: Testing, Deployment Gruppe Oblig 1 10: 25/3: Business Modell Gruppe Oblig 1 11: 1/4: Arkitektur Modell Gruppe Oblig 1 12: 15/4: Oppførsels Modeller Gruppe Oblig 1 13: 22/4: Ikke funksjonelle krav Gruppe Oblig 1 14: 29/4: OBLIG 2 15: 6/5: OBLIG 2 16: 13/5: Preparation for exam 7 INF Forelesnings/Øvings ansvarlige : 22/1: AJB 2: 29/1: AJB 3: 5/2: JØA 4: 12/2: JØA, CDQ/GBO 5: 19/2: BRE, CDQ/GBO 6: 26/2: BRE, CDQ/GBO 7: 4/3: AJB, CDQ/GBO 8: 11/3: BRE. CDQ/GBO 9: 18/3: AJB 10: 25/3: AJB 11: 1/4: BMP 12: 15/4: JØA 13: 22/4: JØA 14: 29/4: AJB 15: 6/5: BRE 16: 13/5: AJB Personer og Temaer: Arne-Jørgen Berre AJB: BM, MDA, Brian Elvesæter BRE: Req.Mod, Verktøy, PSM/Implem Christoffer Daae-Qvale Geir Borge Ottersen CDQ/GBO: OptimalJ Jan Øyvind Aagedal JOEA: Presis mod, QoS Birger Møller Pedersen BMP: UML 2.0 Oppførsel HL: Sinan Sigurd Tanilkan, SST 8 4

5 MDA Explained The Model Driven Architecture Practice and Promise by Anneke Kleppe, Jos Warmer, Wim Bast Paperback: 166 pages ; Publisher: Addison+Wesley; 2003 ISBN: x 9 MDA Explained 1: The MDA Development Process 2: The MDA Framework 3: MDA Today 4: Rosa s Application of MDA 5: Rosa;s PIM to three PSMs 6: Rosa s PSMs to Code 7: More on Transformations 8: Metamodeling 9: Defining your own transformations 10: Rosa s transformation definitions 11: OMG Standards and additional technologies 12: The MDA promise A: Glossary B: The Code for Rosa s system 10 5

6 See also and (OptimalJ Demo edition) + MDA chapter 1 og 4 tilgjengelig 11 The Rational Unified Process Third Edition by Philippe Kruchten Paperback: 289 pages ; Publisher: Addison Wesley Professional; ; 3 rd edition, January 2004 ISBN:

7 The Rational Unified Process 1: SW Development Best Practices 2: The Rational Unified Process 3:Static structure: Process description 4: Dynamic structure: Iterative Development 5: An Architecture-centric Process 6: A Use-cased Driven Process 7: The PM Discipline 8: The Business Modeling Discipline 9: The Requirements Discipline 10: The Analysis and Design Discipline 11: The Implementation Discipline 12: The Test Discipline 13: The Configuration and change Discipline 14: The Environment Discipline 15: The Deployment Discipline 16: Typical Interation plans 17: Implementing RUP A: Roles, B: Artifacts, C: Acronyms RUP 13 COMET - MDA for Interoperable Systems (Berre/Aagedal/Elvesæter/ ) new version March : Introduction to COMET overview/motivation/nutshell 2: An introduction to Interoperable Systems and Enterprise Architecture 3: An introduction to the sample application 4: Business Modeling and Enterprise Architecture 5: Requirements (Actors and use cases, User Experience ) 6: Architecture 7. Components and Design 8: Extra-functional requirements, Quality of Service 9: Implementation 10: Phases: Inception, Elaboration, Construction, Transition 11: Additional. Topics: Testing, Repository, Tool environment A: Profiles and stereotypes, B. MDA environment & tools/umt ++ X: Web Structure support COMET 14 7

8 UML 1.4/1. 5 and UML 2.0 UML Background and Reference material (UML) (MDA) (MOF, XMI, CWM) Supporting litterature: UML book 1: UML Distilled - Third edition w/uml 2.0 UML book 2: Applying UML and patterns UML book 3: UML and Unified Process 15 UML reference books UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition) by Martin Fowler, Kendall Scott Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nd Edition) by Craig Larman UML and the Unified Process: Practical Object- Oriented Analysis and Design by Jim Arlow, Ila Neustadt 16 8

9 Eksamen Case-basert oppgave (ref. tidligere eksamen) Alle skriftlige hjelpemidler er tillatt tentativt, torsdag 3. juni 17 Modeller og modellering 18 9

10 Diskusjon MODELLERING med OBJEKTER Sett dere sammen i grupper a 2-3 og diskuter begrepene: MODELLERING OBJEKTER (5 min) 19...tilbake til OO

11 OOAD metoder Phase Class 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 OOAD - Booch (93 w/c++) RDOOD - Wirfs-Brock et. al OOSD - Wasserman HOOD - ESA OSDL-92 - CCITT/Bræk et. al OOSE/ObjectOry - Jacobson CRC-cards - Cunningham OOram - Reenskaug et. al Catalysis, Syntropy, SOMA, OBA, BHS,... UML (96) Booch/OMT/ObjectOry 21 Evolution of the UML Submission of UML 1.1 to OMG for adoption, Sept 97 UML 1.0 UML 2.0 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 22 11

12 Hvorfor UML: Systemkompleksitet Enhet Enhet Omgivelse Subsystem Subsystem System 23 Hvorfor UML: Felles beskrivelse System Mental model arealworldphenomena A model is created for a purpose A model is never complete We think in multiple models The world is rarely hierarchical Manifest Model Objects 24 12

13 Hvorfor UML: Naturlig del av prosess Two parts of a Harmonized Whole Unified Modeling Language Process Convergence Today Unification leads to standards Convergence in the future Process frameworks through consensus 25 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 2002 COMET UML

14 Målsetning med faget Modellering med objekter Ikke programmering med objekter Forståelse for modelldrevet systemutvikling Komponentbasert utvikling Gjenbruk Lære teknikker Unified Modeling Language (UML) 27 Undervisning Forelesninger Dekker utvalgte deler av teorien i bøkene Litt annen fokus enn bøkene Øvinger Bruke forelest stoff i praksis Case-oppgave på eksamen Eksempler i forelesninger og øvingstimer 28 14

15 Objektorientering og basisbegreper 29 Objektorientering, Begreper og konsepter Basis tanker Objekt Modellering Basis konsepter Klassifisering / Typer / skaping av individer Innkapsling Deling og Arv Polymorfi og dynamisk binding CRC kort 30 15

16 Historisk fokus Kvalitet og Produktivitet Modellering (mdlg) Abstraksjon og Modularisering Gjenbruk og Vedlikehold Funksjonell mdlg ( -55 -> ) Data mdlg (-60 ->) Simula mdlg av individer mdlg av individers oppgave ( -70 ->) Oppgave-behandlere / saksbehandlere [Oppgavefokus] SW Engineering + komplekse systemer fra velprøvete deler Abstrakte Data Typer Klassifisering Ferdiglagete deler / komponenter av gitt type [Eksterne egenskaper] Biblioteker ( -55 -> ) Komponenter og rammeverk ( -80 -> ) Patterns (-90 -> ) Vedlikehold kostbart Økende kompleksitet / størelse. [modulbygging] Splitt og hersk : store, komplekse problemer deles opp i et sett av små, selvstendige og enkle problemer. (i ett eller flere trinn!) 31 Skandinavisk Modellerings-perspektiv (Fra 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

17 Basis for OO Teknologi Kvalitet og Produktivitet Modellering Abstraksjon og Modularisering Gjenbruk og Vedlikehold Klassifisering/ Instansiering Innkapsling Deling Arv Polymorfisme Objekt Modell 33 Objektorientert Modell En objektorientert modell er en (simulerings) modell som består av samspillende objekter i interaksjon med hverandre. En parallell i virkeligheten : en bil. Den består av et sett deler / komponenter som samvirker i et gitt mønster. ( ikke alle påvirker alle andre direkte; interaksjonene/samspillet er diktert av oppgaver og hensikt) 34 17

18 OO - SYN PÅ VERDEN SAMSPILLENDE OBJEKTER. Hvert Objekt: har klart ansvar vet om samarbeis partnerene er robust Ingen vet om det hele! Monolitisk Data storage Internal storage Disc 35 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 36 18

19 Object oriented modeling arealworld- Phenomena anobjectmodel rolemodels animplemented System Environment Model environment Mental model Real-World phenomenon System model Manifest Model 37 Noen ord om Objekt-Orientering En filosofi ; en måte å betrakte verden på En måte å spesifisere systemer på En måte å designe systemer på En måte å programmere systemer på Alt er objekter Det som skjer, hender ved at objekter agerer i samspill Peker mot oppdeling, distribusjon og delegering 38 19

20 OO Programming Terminology Encapsulation Object Message Method Class Instance Inheritance Polymorphism Dynamic (Late) Binding 39 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,

21 The CRC-Card an object of paper personalizing the object Class (Name): Responsibility: Collaborators: 41 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

22 CRC is Not distinguishing between Object Instance and Class It is not needed because the CRC-methods physical aspects where each class description becomes an individual physical object, a filing card. This enables the double role of class and object in discussion and analysis with no confusions. It gives an benefit the number of concepts to be handled and mastered are kept to a minimum!! 43 Card Playing Rules - Notation Every card represents possibly several objects at the same time (if needed) Overlapping cards implies close collaboration Positioned above a card implies that the object is controlled by this card A stack of cards implies hierarchical detailing of abstractions - the most abstract card is placed on top and represents the rest of the hierarchy 44 22

23 Card Playing Rules - Process Regard the cards as objects Start with the known, evolve towards the unknown Evolve design by 'playing' through scenarios (simulate execution) pick up the object which is executing and identify yourself with it create new objects or responsibilities founded on requirements / needs emerging during simulation. (not for some hypothetical future needs) Work in a team. A single person will have difficulties finding all requirements or scenarios. 45 UML notasjon Basis strukturell modellering 46 23

24 UML Structural Modeling Building blocks of UML Classes Attributes/Operations Associations Packages Extension mechanisms 47 Building blocks of the UML Things Structural, Behavioural, Grouping, Annotational Relationships Dependency, Association, Generalisation, Realisation Diagrams Use Case, Sequence, Class, Object, Collaboration, Statechart, Activity, Component, Deployment 48 24

25 Metamodel Architecture <<metamodel>> MOF Meta-Metamodel «metaclass» Attribute «metaclass» Class «metaclass» Operation «instanceof» «instanceof» <<use>> «instanceof» <<metamodel>> UML Metamodel «metaclass» Attribute «metaclass» Class «metaclass» Operation «instanceof» <<use>> The attribute fare of the PassengerTicket class is an instance of the metaclass Attribute. Analysis Model PassengerTicket +issuedby : Airline +issuingagent : TravelAgent +fare : Currency +tax : Currency +total() +issue() +surrender() +refund() The operation issue of the PassengerTicket class is an instance of the metaclass Operation. «instanceof» From Modeling CORBA Applications with UML chapter in [Siegel 00] : PassengerTicket +issuedby : Airline = AcmeAirlines +issuingagent : TravelAgent = TerrificTravel +fare : Currency = tax : Currency = Represents the User Object layer of the 4-layer metamodel architecture pattern. 49 UML Overview Behavioral Elements Model Management Foundation Core Extension Mechanisms Data Types 50 25

26 Different kind of models Conceptual models Specification models Implementation models 51 Class diagram GM_Object + mbregion : GM_Object + representativepoint : DirectPosition + SRS() : SpatialReferenceSystem + transform(srs : SpatialReferenceSystem) : GM_Object + equals(object : GM_Object) : Boolean + distance(object : GM_Object) : Distance + dimension() : Integer + dimension(point : DirectPosition) : Integer + coordinatedimension() : Integer + envelope() : Envelop + boundary() : Set(GM_Object) + buffer(radius : Distance) : GM_Object + convexhull() : GM_Object + centroid() : DirectPosition + representativepoint() : GM_Point + isincomplexes() : Set(GM_Complex) + ispartof(geomcplx : GM_Complex) : Boolean + universe() : GM_Complex 1 +srs SpatialReferenceSystem (from DirectPositioningSchema) GM_Primitive (from GeomPrimitive) GM_Complex (from GeomComplex) + boundary() : Set(GM_Primitive) 52 26

27 The object symbol Can represent an instance John :Person a type/interface <<Interface>> Person a class Person 53 Class diagram - notation Class name attributtename-1 : datatype-1 = defaulval-1 attributtename-2 : datatype-2 = defaultval operationname-1 (argumentlist-1) : resulttype-1 operationname-2 (argumentlist-2) : resulttype An Abstract class is shown with class name in italics (means no implementation of this class, i.e. subclasses are needed) 54 27

28 Encapsulation and visibility ClassName / /* derived attribute + /* public visibility # /* protected visibility - /* private visibility underline /* class level (static) 55 Attributes [visibility] name [multiplicity] [:type] [= initial value] [{property-string}] + origin [0..1] : Point = (0,0) {frozen} defined properties: changeable, addonly, frozen (const) 56 28

29 Attributes and data types A data type specifies a legal value domain and the operations on values of that domain Four categories a) Basic data types b) Collection data types (from OCL) c) Enumerated data types d) Model types 57 Operations [visibility] name [(parameter-list)] [:return-type] [{property-string}] [(parameter-list element)] ::= [direction] name : type [= default-value] [direction] ::= in out inout + set ( in name : Name, in place : String = Oslo ) : Boolean {sequential} defined properties: isquery, sequential, guarded, concurrent No syntax for exceptions (?) Notes w/ stereotypes: <<precondition>>, <<postcondition>>, <<invariant>> 58 29

30 Relationships Association A semantic connection between two instances Generalization A relationship between an element and the subelements that may be substituted for it Dependency The use of one element by another Refinement A shift in levels of abstraction 59 Different relationships in UML Diagrams Purpose: To show relationships between model entities, To define multi-way constraints Multiplicity of an Association 2 RoleName AssociationName 1..* RoleName Generalization Dependency (Client-Server) Association Notation used to anchor at note to a model entity Aggregation Composition (Strong Aggregation) Link Attribute 60 30

31 Generalisation and Association Superclass Association Person 0..1 loans 0..* Loan customer Loanentity Book Generalisation Man husband wife Married with {not siblings} Woman Subclasses (inherits attributes and operations) Arrow can be used to show direction of knowledge 61 Multiplicity constraints Multiplicity shows how many instances of a class that can be related to one instance of the class at the other end of the association Exactly one Many, optional zero or more One, optional one or more At lease one Given number 1 Class 0..* Class 0..1 Class 1..* Class 3,5,10 Class * Class 62 31

32 Aggregation (can be shared) Loose (weak) part-of relationship Multiplicity > 1 possible Exists even if a phone book goes away Phone book 0..* * listedin subscriptions Subscription Open diamond association role names 63 Composition (sometimes called strong aggregatgion) Strong part-of relationship Multiplicity max 1 Existence dependent File contains 1 * Record Filled diamond 64 32

33 Associations Company Job 1.. employer employee Person Job salary worker boss 0..1 Manages Person Account {X or} Corporation Fig. 3-31, UML Notation Guide 65 Association Ends Polygon 1 1 +points Contains 3.. {ordered} 1 -bundle Point GraphicsBundle color texture density Fig. 3-32, UML Notation Guide 66 33

34 UML notasjon Basis oppførselsmodellering 67 UML Behavioral Modelling Use Cases Interactions Sequence diagrams Collaboration diagrams Statecharts Activity Diagrams 68 34

35 Use cases A special instance of collaboration: between external actors and the system Has its own special simple notation: Use case diagrams 69 Understanding requirements - using Use-Case models The use-case model consists of Actors Use cases It is a model of what the system is supposed to do (use cases) and the system's surroundings (actors). Register Car Clerk Print Car Report A Car-Register System Actors can be subclassed 70 35

36 Structuring of a Use case (1) Use Case Extension of a Use Case (Bottle-machine) <<extend>> Buy a bottle Remove bottle that is not properly dispensed <<extend>> can be used to describe for instance exceptional situations. Can be added later Main use case will not be impacted by an extension 71 Structuring of Use Case (2) Use Case Common parts of multiple use cases <<include>> Remove bottle <<include>> Open machine Advantages Fill new bottles Common description in one place Changes is done in one place 72 36

37 Extenstion point & realisation Place order extension points set priority <<extend>> (set priority) Place rush order realisation Order management 73 The context of a system Credit Card validation system Perform card transaction Retail institution Customer Process customer bill Reconcile transactions Sponsoring financial institution 74 37

38 Developing the Use Case Model Find the Actors Find the Use Cases Briefly describe each Use Case Describe the Use Case Model (UML) Prioritize Use Cases Detail each Use Case Sketch interfaces 75 38