• Analysis – What shall we do?
OOA/OOD
• Design – How shall we do it? • Implementation – Do it! • Testing – Did we get it right? • Deployment – Start it! • Maintenance – Keep it running! (fix bugs, add functionality, etc…) javaprogrammering
Documentation – UML • UML is a standard notation, not a programming language! • Shows the system’s structure and function (static and dynamic aspects) • Helps us “see the forest in spite of all the trees” • We use: – Use cases / Use case diagrams – Class diagrams – Interaction diagrams
javaprogrammering
Use cases • Used for: communication with customer understanding the system • Especially useful during early planning • Describe typical interactions between user and system • Input from customer and domain experts
javaprogrammering
Use cases • Short textual descriptions • Can be shown in diagram form • Note: Use cases describe dynamic features of a system, not static (classes) • They are primarily useful when constructing interaction diagrams, not class diagrams
javaprogrammering
Use case “Köp vara”:
Use case, snabbköp
Aktör = kunden (K) System = expediten (E) 1. 2. 3. 4. 5.
K visar varan för E E ger K prisuppgift K ger pengar till E E registrerar köpet E lämnar växel och kvitto till K
Alt. I: 3. K har inte nog med pengar Alt. II: 1. K gömmer varan för E (snatteri!)
javaprogrammering
alternative scenarios (other paths)
Use case diagram - snabbköp Use cases actor
Köp vara System boundary
Returnera vara kund Erhåll prisuppgift
javaprogrammering
Use case diagram - bank Ny kund
Avsluta konto
Nytt konto Betala räkning kassör
Insättning Överföring
kund
nätbanken
<>
Uttag <>
bankomat
<>
Erhåll saldo javaprogrammering
<>
bankgirot
Use case - bank Use case: Betala räkning via nätbanken: •
Kunden (i rollen som nätbanken) är inloggad på startsidan
•
Systemet presenterar ett grafiskt formulär för att mata in bank- eller postgironummer
•
Kunden matar in ett nummer
•
Systemet verifierar att numret stämmer med användaren
•
Systemet presenterar en meny med följande möjligheter…
•
osv
javaprogrammering
Exercise - mäklare • A stock trading company • Functional requirements – What shall the system handle? – Persistent? – Distributed?
• Non-functional requirements – – – –
Fast User-friendly Extendable Object-oriented
• Time frame • Resources – DB – Java javaprogrammering
Exercise - mäklare •
Construct a use case diagram for the broker application
•
Which are the actors? (Are all humans?)
•
What services should the system supply?
javaprogrammering
Conceptual diagram • The problem subdivided into concepts • Shows concepts, not software components • Uses customer’s terminology (“jargon”) • Some concepts may become our classes… • Some will be thrown away… • Concepts identified through Use case descriptions • Look for nouns (“substantivfrasidentifiering”) • Diagram shows: • concepts • attributes • associations javaprogrammering
Attribute or concept? • Concepts are composite • Attributes are simple (values inside concepts) • Ex: – Is “flight” an attribute? ( “SK499”) – Or is it a concept? (name=“SK499”, dest=“ARN”, aircraft=“MDxx”) – Is “dest” an attribute or a concept? (an airport)
javaprogrammering
Associations • Shows meaningful relations between concepts • May be given names • Shows multiplicity
Person name
owns
Car color 1
* 1
1
has
1
1
has
1
has * TeenageChild
1
drives
4
Wheel
javaprogrammering
Engine
Class diagram • • • •
(Implementation) class diagram shows software classes Is based on the conceptual diagram Shows the static relations between types Requires software knowledge (usually the customer is no longer involved) • Shows: – – – – – – –
Generalization Realization Associations (aggregation, composition) Multiplicity Navigability Attributes, and their visibility Operations, and their visibility javaprogrammering
Exercise - mäklare • Construct a class diagram for the stock trader • Find: – – – – –
Classes Relations Multiplicity Navigability Important attributes and operations
javaprogrammering
Finding classes • A dual process: class suggestion and class rejection • Examining requirements documentation is not enough (also takes talent, expertise, luck, creativity, experience, intuition…) • Is the concept a separate type with its own clearly identified operations? • Is the concept relevant to the system? (Ex: Person has a Father and a Mother, but is this always relevant?) javaprogrammering
Finding classes • Association classes are usually not found by recognizing nouns (e.g. Employment, Transaction, Payment) • Is the suggested class in fact a routine? Indications: – “This class does…” – Verb as class name – Class with a single public method
• Is the suggested class in fact a data record? (Can be appropriate in some situations…e.g. CustomerInfo) • Premature classification (Ex: Cow and Goat inheriting from Mammal instead of representing instances of Mammal) javaprogrammering
Finding classes • If a non-OO application exists, look for data structures, records, or files • Look for useful patterns (which may introduce useful classes) • [See chapter 22 in Mayer (1997): “Object-oriented software construction”]
javaprogrammering
Interaction diagrams • • • • • • •
Describes how objects work together Based on use cases and contracts Typically, one diagram / use case Contract describes what happens, interaction diagrams describe how it happens Shows objects and the messages sent between them Reveals over-centralized designs Two kinds: 1. Sequence diagrams 2. Collaboration diagrams
javaprogrammering
Sequence diagram • Objects are shown together with their lifelines • Messages are sent between the lifelines :ClassA
:ClassB aMetod () anotherMetod () aThirdMetod () new ()
:ClassC
aFourthMetod () X javaprogrammering
Collaboration diagram • Objects are shown as icons • Messages are numbered to show sequence 1:2:1 aThirdMetod () :ClassA
1:1 aMetod ()
:ClassB
1:2 anotherMetod () 1:2:2 new () 1:2:3 aFourthMetod () :ClassC
javaprogrammering
Package diagram • Shows the “big picture” • Shows packages and how they depend on each other
Java.awt Java.awt
bank bank admin admin atm atm
Dependency Dependency (a change inin (a change core may core may require require changes inin changes the atm) the atm)
core core
javaprogrammering
How much A/D? • “Analysis paralysis” • Documents are useful for: – Understanding the domain – Communicating with customers and colleagues
• Documents have no value in themselves…
javaprogrammering
Use case diagram - mäklare Köp Sälj
Ny depå (portfölj)
Stoppa system
Ny kund mäklare
Lämna aktiekurs Lägg köp/säljorder
vd
admin
Ny användare Hämta aktiekurs
börsen
Ändra kunddata Totala värdet
sälj
Starta system
Veckorapport
Bästa kunderna javaprogrammering
kalender
Note! The module about OOA/OOD (object-oriented analysis and design) contains a few OHs which are available only in paper format. Get them from Ulf N, or copy them from a fellow student!
javaprogrammering
This document was created with Win2PDF available at http://www.daneprairie.com. The unregistered version of Win2PDF is for evaluation or non-commercial use only.
