INF5120 Modellering med Objekter 22.01.2004 1 1 Telecom and Informatics INF5120 ”Modellering med objekter” Forelesning 22.01.2004 Arne-Jørgen Berre 2 Telecom and Informatics Velkommen til INF5120 “Modellering med objekter” Modellering med objekter http://www.uio.no/studier/emner/matnat/ifi/INF5120/v04/ Forelesere: Arne-Jørgen Berre Jan Øyvind Aagedal Brian Elvesæter Christoffer Daae-Qvale/Geir Borge Ottersen Birger Møller Pedersen Email: [email protected]Øvingsansvarlig: Sinan Sigurd Tanilkan Email: [email protected]
38
Embed
INF5120 ”Modellering med objekter” · INF5120 Modellering med Objekter 22.01.2004 3 Telecom and Informatics 5 Krav og forutsetninger Ingen formelle krav (student ved UiO) Kunnskaper
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
INF5120 Modellering med Objekter 22.01.2004
1
1Telecom and Informatics
INF5120”Modellering med objekter”
Forelesning 22.01.2004
Arne-Jørgen Berre
2Telecom and Informatics
Velkommen til INF5120 “Modellering med objekter”� Modellering med objekter
� Praktiske ting og litt om faget� Modeller og modellering� Objektorientering og Basisbegreper� UML – notasjon – Strukturell modellering� UML – notasjon – Oppførselsmodellering
� 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
INF5120 Modellering med Objekter 22.01.2004
4
7Telecom and Informatics
INF5120 – Øvinger -2004
� 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
100 stk = 25 grupper a 3-4, 2 grupper hver gang, 12 ganger
The Model Driven Architecture Practice and Promise by Anneke Kleppe, Jos Warmer, Wim Bast
•Paperback: 166 pages ;
•Publisher: Addison+Wesley;
•2003
•ISBN: 0-321-19442-x
10Telecom and Informatics
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
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
14Telecom and Informatics
COMET - MDA for Interoperable Systems (Berre/Aagedal/Elvesæter/…) – new version March 2004� 1: 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
� 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
16Telecom and Informatics
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 Designby Jim Arlow, Ila Neustadt
INF5120 Modellering med Objekter 22.01.2004
9
17Telecom and Informatics
Eksamen
� Case-basert oppgave (ref. tidligere eksamen)� Alle skriftlige hjelpemidler er tillatt
� 09-13 – tentativt, torsdag 3 . juni
18Telecom and Informatics
Modeller og modellering
INF5120 Modellering med Objekter 22.01.2004
10
19Telecom and Informatics
Diskusjon
� MODELLERING� med� OBJEKTER
� Sett dere sammen i grupper a 2-3 og diskuter begrepene:� MODELLERING
Submission of UML 1.1 to OMGfor adoption, Sept ´97
Other methods
publicfeedback UML Partners’
Expertise
UML 1.1 (Sept. 1997)
Taskon,SINTEF
UML 1.4UML 2.0
INF5120 Modellering med Objekter 22.01.2004
12
23Telecom and Informatics
Hvorfor UML: Systemkompleksitet
SubsystemSubsystem
Enhet
System
Enhet
Omgivelse
24Telecom and Informatics
aRealWorldPhenomena
Mental modelSystem
Manifest Model
Objects� A model is created for a purpose� A model is never complete� We think in multiple models� The world is rarely hierarchical
Hvorfor UML: Felles beskrivelse
INF5120 Modellering med Objekter 22.01.2004
13
25Telecom and Informatics
Hvorfor UML: Naturlig del av prosess
UnifiedModelingLanguage
Process
� Convergence Today� Unification
leads to “standards”
� Convergencein the future
� Process frameworks through consensus
Two parts of a Harmonized Whole
26Telecom and Informatics
Evolution of methodologies
UML1.0
UML1.1
UML1.2
UML1.3
UML1.4
OMT
Objectory
Booch
UML Components
Catalysis
OOram
KobrA
COMET
UML4EDOC
UML2
Pulse
UP
RUP
Notation
Process 2002
2001
1995-1999
2000
INF5120 Modellering med Objekter 22.01.2004
14
27Telecom and Informatics
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)
28Telecom and Informatics
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
INF5120 Modellering med Objekter 22.01.2004
15
29Telecom and Informatics
Objektorientering og basisbegreper
30Telecom and Informatics
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
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.
(Fra Simula)
INF5120 Modellering med Objekter 22.01.2004
17
33Telecom and Informatics
Basis for OO TeknologiBasis for OO Teknologi
Kvalitet og Produktivitet
Modellering Abstraksjon ogModularisering
Gjenbruk ogVedlikehold
Objekt Modell
Klassifisering/Instansiering Innkapsling Deling
Arv Polymorfisme
34Telecom and Informatics
Objektorientert ModellObjektorientert Modell
En objektorientert modell er en (simulerings) modell som består avsamspillende objekter i interaksjon med hverandre.
En parallell i “virkeligheten”: en bil. Den består av et settdeler / komponenter som samvirker i et gitt mønster.( ikke alle påvirker alle andre direkte; interaksjonene/samspilleter diktert av oppgaver og hensikt)
INF5120 Modellering med Objekter 22.01.2004
18
35Telecom and Informatics
OO - SYN PÅ VERDENOO - SYN PÅ VERDEN� SAMSPILLENDE OBJEKTER. Hvert Objekt:
� har klart ansvar� vet om samarbeis partnerene� er robust
� Ingen vet om det hele!
Data storage
Internalstorage
Disc
”Monolitisk”
36Telecom and Informatics
System and objectsSystem and objectsA 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 actionswhich may involve itself and other objects.
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 aspossible, 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, 1989
INF5120 Modellering med Objekter 22.01.2004
21
41Telecom and Informatics
The CRC-Cardan object of paper personalizing the object
Class (Name):
Responsibility: Collaborators:
42Telecom and Informatics
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.
� CollaboratorsObjects 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.
INF5120 Modellering med Objekter 22.01.2004
22
43Telecom and Informatics
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!!
44Telecom and Informatics
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
INF5120 Modellering med Objekter 22.01.2004
23
45Telecom and Informatics
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.
46Telecom and Informatics
UML – notasjon –Basis strukturell modellering
INF5120 Modellering med Objekter 22.01.2004
24
47Telecom and Informatics
UML Structural Modeling
� Building blocks of UML� Classes� Attributes/Operations� Associations� Packages� Extension mechanisms