Programmering og systemudvikling

1
Programmering og systemudvikling

• Lektion 6
• Design - part 1

2
Indhold

• Micro design regler
• GRASP mønstre
• CD afspiller
• Makro design
• Arkitektur design
• komponent design

3
GRASP Patterns (Larman)

• What are the GRASP patterns?
• The GRASP patterns describe fundamental
  principles of assigning responsibilities to
  objects, expressed as patterns
• Patterns are named problem/solution pairs that
  codify good advice and principles

• The patterns
• Expert
• Creator
• Low coupling
• High cohesion
• Controller
• Polymorphism
• Pure Fabrication
• Indirection
• Dont Talk to Strangers

4
Objektorienteret design
There are many possible activities and artifacts
in analysis and design, and a wealth of
principles and guidelines. Suppose we must
choose a single practical skill from all the
topics discussed here a dessert island skill.
What would it be? Why? Because it is the
one activity which must be performed (it is
inescapable) and it has the most profound effect
on the robustness, maintainability, and
reuseability of software components. Craig
Larman, 1998 Applying UML and Patterns An
Introduction to Object-Oriented Analysis and
Design
The most single important ability in
object-oriented analysis and design is to
skillfully assign responsibilities to software
components.
5
Expert

• Which class is responsible for performing an
  operation?
• Expert Pattern
• Assign a responsibility to the class or classes
  that have the information required to carry out
  the responsibility!

6
Creator

• Who is responsible for creating an object?
• Creator pattern
• Determine which class should create instances of
  a class based on the relationship between the
  potential creator classes and the class to be
  created
• B is responsible for creating A if
• Instances of B composes or aggregates inst. of A
• Instances of B contains inst. of A
• Instances of B records inst. of A
• Instances of B directly uses inst. of A
• Instances of B have the data that is passed
• to constructors of A

7
Low coupling

• Coupling
• Dependencies between one element (class,
  operation, attribute, ) and other elements
  properties
• We shall strive for low coupling
• Minimize the dependency of other classes
  properties
• Why?
• To minimize rippling when modifying classes so
  that changes only have local consequences.

8
High cohesion

• The inner relatedness within the properties of an
  element
• Strive for uniqueness within a element
• Maximize the uniqueness of a elements
  responsibility
• Maximize the mutual connection between the
  properties within a element
• Strive for a high degree of cohesion!

9
On coupling and cohesion

• If
• a class is so highly coupled or lacking in
  cohesion as to make a design brittle or difficult
  to modify...
• Then
• apply other appropriate GRASP patterns to
  reassign the classs responsibilities.

10
Hvor skal operationen placeres?

• Har koen en afMælk operation eller har mælken
  en udKo operation?
• Det er ikke altid oplagt at operationalitet kan
  placeres på et domæne begreb

11
Kontrolklasse

• Når styringen af en use case ikke kan placeres
• operation på speciel klasse - kontrolklasse
• kontrolklasse ? procedure
• En kompleks use case ? en eller flere
  kontrolklasser

12
Et eksempel
Vi ønsker at ændre leveringen af en bestemt vare
- Flytte varen til en anden ordre
13
Flyt ordrelinie

• BRUGER
• 1) Følgende indtastes
• Kundenummer,
• FraOrdre,
• TilOrdre,
• Vare
• SYSTEM
• 1) Ordrerne fremfindes udfra ordrenumrene.
• 2) Hvis FraOrdren ikke er leveret flyttes netop
  den Ordrelinie, som er knyttet til den indtastede
  Vare.
• Undtagelse 1) FraOrdren er leveret
• 3) Den relevante ordrelinie knyttes til den
  indtastede TilOrdre.
• Undtagelse 2) TilOrdren har allerede en
  Ordrelinie med denne Vare

14
flytOrdrelinie (2)

• Sluttilstand
• Ordrelinien er flyttet til den ønskede ordre
• Undtagelser
• 1) FraOrdren er ekspederet Der gives en
  fejlmeddelelse
• 2) TilOrdren har allerede en OrdreLinie for den
  aktuelle Vare Antallet på den eksisterende
  OrdreLinie opdateres med antallet fra den
  flyttede OrdreLinie.

15
Flyt ordrelinie (2)

• Hvor skal operationen der styrer flowet i use
  casen placeres?
• Order
• OrderLine
• Customer
• Item
• moveOrderLine kontrolklasse

16
FlytOrdreLinie (3)
moveOrderLine
OrderLine
Order
moveOrderLine(fromOrder, toOrder, customer, item)
state
if fromOrder.stateltgtdelivered then
fromOrderLine select from fromOrder.OrderLines
select
where OrderLine.Itemitem
Delete

fromOrderLine.delete
CREATE(toOrder,...)
OrderLine.CREATE(toOrder,
info from fromOrderLine)
17
Typer af kontrol

• Fork struktur En operation styrer
• kalder alle andre operationer
• Stair struktur Ansvaret er delegeret
• Der er ingen "central" klasse.
• Alle klasser kender kun få andre klasser - ved
  hvilken klasse der kan hjælpe med en specifik
  egenskab.

18
Stair versus fork

• En stair struktur bruges når
• operationerne er tæt koblede
• Klasserne er aggregeringsstruktur
• Associeringerne repræsenterer en fast tidsmæssig
  sammenhæng
• advertisement-order-invoice-delivery-payment
• operationerne altid skal udføres i den samme
  rækkefølge

19
Stair vs. Fork (2)

• En fork struktur anvendes når
• operationerne kan/vil ændre rækkefølge
• nye operationer skal kunne indføjes
• der er tale om en kontrolklasse

20
Eksempel

• Stair
• Fork

21
Polymorphism

• Avoid if-statements
• When alternate behaviours are selected based on
  the type of an object, use a polymorphic method
  call to select the behaviour rather that using if
  statements to test on the type

22
How do we use all this patterns ?
23
Water fall methodology?
Analysis
Design
Implementation
Test

• The analysis need not to be finished before
  starting with design, implementation and test it
  can be advantageous to complete the process for
  one or more use cases before continuing with the
  rest of the system

24
Iterative development
implemen- tation
evaluation
new requirements
design
analysis
25
One iteration/version
Degree of completion
100
100
80
60
40
20
0
Spec. Analysis Design Impl. Test
Activities
26
Development model
Use cases
...
...
...
...
...
...
...
Versions/iterations
27
Von Petersen Charter

• Von Petersens Charter is a small regional
  carrier with small-aircraft service to nearby
  destinations.
• Von Petersens Charter needs an application for
  scheduling flights and making reservations.

VPC
28
The System

• We will make a simple reservation system
• Implement a prototype on the computer
• No GUI but TUI
• Waterfall development

29
So what is the system going to do?

• Look at the basic features
• Functionality of the system
• Look at the concepts of the problem domain
• Concepts of the flight domain
• Look at other reservation systems (for
  inspiration)
• library
• movie theatre
• Which of these views on the problem to start
  with?
• BOTH - hand in hand

30
Features/requirements

• You must be able to reserve a flight
• The Fisher Price system

Reserve flight
User
31
Reserve use case
32
System events (reserve use case)
33
Other features

• Enter (add, change, delete) airports
• Enter flight descriptions
• Enter scheduled flights
• You can really get carried away here - remember
• Your customer will vote with his wallet
• The best features will satisfy a want for the
  customer who will be served by the system or
  whomever is paying for the system

34
The system viewed as use cases
35
What are the problem domain concepts?

• Airport
• An airport that Von Petersen Charter operates on
• Route (FlightDescription)
• A route that Von Petersen Charters flies
• Scheduled Flight
• A concrete flight of a route at a given day
  having a given capacity.
• Reservation
• A reservation of one or more seats in a scheduled
  flight
• Passenger
• A person of a given type flying with Von Petersen
  Charter

36
Problem domain class model
37
Patterns

• Here we have a common case Something
  (FlightDescription) there can be many instances
  of (ScheduledFlight)
• item/instance of item pattern

Instance specific information. For example
departure time
General information common to all instances. For
exmaple departure airport
38
Architectural decisions

• A closed three tier architecture
• minimise the places to change
• a good default choice

39
Elaborate on the use case - make a scenario

• Place responsibilities/properties on the classes
• How is the interaction of the objects
• Where should one place the operations/responsibili
  ties/properties?
• Expert pattern (Larman 18.9)
• Who is responsible for the overall execution of
  the use case?
• Possible Add new classes responsible for
  controlling the use cases (use case controller -
  Larman 18.13)
• The scenario for now No problems
• customer exists, scheduled flight exists, ...

40
Create airport use case
creator pattern
controller pattern
41
Where does all the airports go?

• We need somewhere in our system where the
  airports are stored/saved
• Container class

Returns the container holding the airports
42
Just one Containers

• There is just one instance of the Containers
  class
• singleton
• How do we implement the singleton?
• Singleton pattern

Containers
aContainers
aAirportManager
Containersr
instance( )
Containers( )
getAirports( )
if the instance attribute points
to a Conatiners object, return that one
otherwise create a new, update
the instance attribute and return
43
Reserve flight interaction
Usecase controller
aReservationController
GUI
Containers
aFlight
Scheduled
ReservationController
Decription
Flight
requestRoutes( )
Expert pattern
getFlightDescriptions( )
getScheduledFlights(flightDescription)
getScheduledFlights()
hasRoom()
44
(part of) enhanced class diagram
45
Now we just need the code -)

• Use the class diagram to find out which classes
  there is -)
• Use the interaction diagram to implement the
  different operations - eg

m Manage
AirportImpl
Containers
Airports
createAirport("Århus", "aar")
AirportImpl("Århus", "aar")
what
instance( )
how
46
ManageAirports
class ManageAirports //creates an airport
public abstract void createAirport(String name,
String code) //returns the airport with the
code ltcodegt public abstract Airport
findAirport(string code) //adds a departure to
the ariport public abstract void
changeAirport(string code, string newName)
//erases the airportwith code ltcodegt public
abstract void eraseAirport(string code) //
return the airports public abstract Iterator
airports() //add an arrival

47
Arkitektur
48
3 lags arkitektur
Grænseflade- komponent
ltltinterfacegtgt
Funktions- komponent
ltltcontrolgtgt
Model- komponent
ltltentitygtgt
49
Hvad er arkitektur?

• OOAD
• Arkitekturen kan udtrykkes som en overordnet
  strukturering af dele, der modsvarer kriterier
  for systemets designArkitekturen sætter på
  afgørende vis vilkårene for resten af designet.
  En uklar arkitektur vil føre til meget spildt
  arbejde i resten

50
Hvad er arkitektur?

• UML 1.3
• Architecture is the organizational structure of a
  system. An architecture can be recursively
  decomposed into parts that interact through
  interfaces, relationships that connect parts, and
  constraints for assembling parts. Parts that
  interact through interfaces include classes,
  components and subsystems.
• Perry and Wolf
• Software Architecture Elements, Form,
  Rationale

Hvad
Hvordan
Hvorfor
51
Arkitektur (2)

• Shaw and Garlan
• Software architecture is a level of design that
  involves
• the description of elements from which systems
  are built,
• interactions among those elements,
• patterns that guide their composition,
• and constraints on these patterns.
• Kruchten
• Software architecture deals with the design and
  implementation of the high-level structure of
  software. Architecture deals with abstraction,
  decomposition, composition, style, and aesthetics.

52
Practioners definitions

• The following definitions are samples from
  software architects and senior software
  engineers
• Software architecture is
• an overall view of the solution to a problem
• the high-level design of modular components and
  how they interact
• a foundation that one can build on to solve a
  problem (e.g., rules, policies, attributes, etc.)
  
• an efficient method to meet a fixed set of
  well-defined attributes

53
Arkitektur og krav. spec.

• Software arkitektur er den overordnede struktur
  af et software system. Vigtige egenskaber er
  bl.a
• Det er på et så højt abstraktionsniveau, at
  systemet kan ses som et hele.
• Strukturen skal understøtte den funktionalitet
  der er krævet af systemet. Det vil sige, at den
  dynamisk opførsel af systemet skal tages med i
  betragtning når arkitekturen.
• Arkitekturen skal passe til kvalitetskravene til
  systemet (også kendt som non-funktionelle krav).
  Disse krav inkluderer sandsynligvis performance,
  sikkerhed og krav om at det skal passe med det
  nuværende system samt krav om fleksibilitet og
  udvidbarhed i forbindelse med fremtidige krav til
  en rimelig pris. Disse krav kan konflikte og
  afvejninger mellem alternativer er en essentiel
  del af arkitektur design.
• På arkitektur niveauet er alle implentationsdetalj
  er skjult.

54
Kriterier
55
Kriterier (2)
56
Opdeling i delsystemer

• Skal hver klasse realiseres i sin .java fil?
• I et lille skole system giver det 50 filer
• I et virkeligt system giver det 2-500 filer
• Svært at holde styr på
• Svært at bruge som arbejdsenhed når der skal
  uddeles kodeansvar
• Er dette et design- eller projektledelses
  problem?
• Begge

57
Moduler

• Moduler skal danne baggrund for hvad der måles på
  - ikke individuelle klasser
• Modul er en release enhed
• Modul er en genbrugsenhed
• I et modul er klasser tæt bundne med løst koblede
  til andre moduler
• Moduler i java understøttes af packages

58
Moduler

• Klasserne i et modul skal være tæt bundne
• At være tæt bundet i et modul betyder
• 1 De skal være lukkede overfor de samme ændringer
  og immune over de samme andre ændringer
• 2 De skal genbruges sammen
• 3 De skal have en fælles funktionalitet eller
  politik
• Det er en prioriteret rækkefølge

59
Afhængighed

• Forskellige typer af afhængighed
• Arv (En klasse fra modul A arver fra modul B)
• Instantiering (en klasse fra modul B skal
  instantieres i modul A)
• Kald (En operation i modul A kalder en operation
  i modul B)
• Association (En klasse i modul A er associeret
  til en klasse i modul B)
• Aggregering (En klasse i modul A indeholder en
  forekomst fra modul B)

60
Afhængighed

• Afhængighed
• Et modul A afhænger af modul B hvis en eller
  flere klasse i modul A det ikke kan oversættes og
  aftestes uden tilgang til mindst en klasse fra
  modul B
• UML Package
• Kan bruges til at lave
• releaseplan
• testplan
• projektplan

61
Afhængighed

• Afhængige vs. afhænger

Der er mange der afhænger ? svært at
ændre afhænger af få ?få grunde til at ændre
Stabil
MANGE
Normal moduler
Afhængige af klassen
Ustabil
Der er få der afhænger ? let at ændre afhænger
af mange ? mange grunde til at ændre
FÅ
FÅ
Afhænger af andre
MANGE
62
The main sequence

• Stabilitet vs. generalitet

Arkitektur/ Overordnet struktur
Høj
The main sequence
Generalitet, abstrakhed
Implementations detaljer
Lav
Stabil
Ustabil
Stabilitet (Placering på forrige slide)
63
Traditionel software

• DFD har den modsatte egenskab Jo mere detaljeret
  en boble jo flere afhænger af den
• Ændringer i nedre lag propagerer opad

Arkitektur/ Overordnet struktur
Høj
Generalitet, abstrakhed
The main sequence
Implementations detaljer
Lav
Stabil
Ustabil
Stabilitet
64
Hvorfor omvendt ved OO??

• interface klasser
• Interfaces til begreber
• Implementations detaljer gemmes længere nede
• Mulighed for at genbruge procedurelle
  abstraktioner