Præsentation er lastning. Vent venligst

Præsentation er lastning. Vent venligst

Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.1 Programmering og systemudvikling Lektion 6 Design - part 1.

Lignende præsentationer


Præsentationer af emnet: "Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.1 Programmering og systemudvikling Lektion 6 Design - part 1."— Præsentationens transcript:

1

2 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.1 Programmering og systemudvikling Lektion 6 Design - part 1

3 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.2 Indhold è Micro design regler GRASP mønstre CD afspiller è Makro design Arkitektur design komponent design

4 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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 –Don’t Talk to Strangers

5 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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.

6 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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!

7 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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

8 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.7 Low coupling è Coupling Dependencies between one element (class, operation, attribute, …) and other element’s 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.

9 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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!

10 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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 class’s responsibilities.

11 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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

12 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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

13 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.12 Et eksempel Vi ønsker at ændre leveringen af en bestemt vare - ”Flytte” varen til en anden ordre

14 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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]

15 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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.

16 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.15 Flyt ordrelinie (2) è Hvor skal operationen der styrer flow’et i use case’n placeres?  Order  OrderLine  Customer  Item  moveOrderLine kontrolklasse

17 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.16 FlytOrdreLinie (3) moveOrderLineOrderLine Delete CREATE(toOrder,...) moveOrderLine(fromOrder, toOrder, customer, item) Order state select if fromOrder.state<>delivered then fromOrderLine:= select from fromOrder.OrderLines where OrderLine.Item=item fromOrderLine.delete OrderLine.CREATE(toOrder, info from fromOrderLine)

18 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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.

19 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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

20 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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

21 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.20 Eksempel è Stair: è Fork

22 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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

23 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.22 How do we use all this patterns ?

24 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.23 Water fall methodology? è 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 Analysis Design Implementation Test

25 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.24 Iterative development implemen- tation evaluation designanalysis new requirements

26 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.25 One iteration/version Spec. Analysis Design Impl. Test Activities Degree of completion 0% 100% 40% 60% 80% 100% 20%

27 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.26 Use cases Versions/iterations... Development model

28 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.27 Von Petersen Charter è Von Petersen’s Charter is a small regional carrier with small-aircraft service to nearby destinations. è Von Petersen’s Charter needs an application for scheduling flights and making reservations. VPC

29 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.28 The System è We will make a simple reservation system Implement a prototype on the computer No GUI but TUI Waterfall development

30 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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

31 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.30 Features/requirements è You must be able to reserve a flight The “Fisher Price” system User Reserve flight

32 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.31 Reserve use case

33 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.32 System events (reserve use case)

34 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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

35 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.34 The system viewed as use cases

36 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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

37 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.36 Problem domain class model

38 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.37 Patterns è Here we have a common case: Something (FlightDescription) there can be many instances of (ScheduledFlight) item/instance of item pattern: General information common to all instances. For exmaple: departure airport Instance specific information. For example: departure time

39 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.38 Architectural decisions è A closed three tier architecture minimise the places to change a good default choice

40 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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/responsibilities/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,...

41 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.40 Create airport “use case” creator pattern controller pattern

42 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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

43 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.42 Just one Containers è There is just one instance of the Containers class singleton è How do we implement the singleton? Singleton pattern aAirportManager : ContainersaContainers : Containersr instance( ) Containers( ) if the instance attribute points to a Conatiners object, return that one otherwise create a new, update the instance attribute and return getAirports( )

44 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.43 aReservationController : ReservationController GUI requestRoutes( ) : ContainersaFlight Decription : : Scheduled Flight getFlightDescriptions( ) getScheduledFlights(flightDescription) getScheduledFlights() hasRoom() Reserve flight interaction Usecase controller Expert pattern

45 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.44 (part of) enhanced class diagram

46 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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: what how m : Manage Airports : AirportImpl : Containers createAirport("Århus", "aar") AirportImpl("Århus", "aar") instance( )

47 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.46 ManageAirports class ManageAirports { //creates an airport public abstract void createAirport(String name, String code); //returns the airport with the code public abstract Airport findAirport(string code); //adds a departure to the ariport public abstract void changeAirport(string code, string newName); //erases the airportwith code public abstract void eraseAirport(string code); // return the airports public abstract Iterator airports(); //add an arrival };

48 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.47 Arkitektur

49 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.48 3 lags arkitektur Grænseflade- komponent Funktions- komponent Model- komponent >

50 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.49 Hvad er arkitektur? è OOA&D: ”Arkitekturen kan udtrykkes som en overordnet strukturering af dele, der modsvarer kriterier for systemets design…Arkitekturen sætter på afgørende vis vilkårene for resten af designet. En uklar arkitektur vil føre til meget spildt arbejde i resten ”

51 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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 } HvadHvordan Hvorfor

52 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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.

53 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.52 Practioner’s 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

54 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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 implentationsdetaljer skjult.

55 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.54 Kriterier

56 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.55 Kriterier (2)

57 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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

58 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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

59 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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

60 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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)

61 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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

62 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.61 Afhængighed è Afhængige vs. afhænger Afhængige af klassen FÅ MANGE Afhænger af andre FÅ MANGE Normal moduler Stabil Ustabil Der er mange der afhænger  svært at ændre afhænger af få  få grunde til at ændre Der er få der afhænger  let at ændre afhænger af mange  mange grunde til at ændre

63 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.62 The main sequence è Stabilitet vs. generalitet Generalitet, abstrakhed Lav Høj Stabilitet (Placering på forrige slide) Stabil Ustabil The main sequence Arkitektur/ Overordnet struktur Implementations detaljer

64 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.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 Generalitet, abstrakhed Lav Høj Stabilitet Stabil Ustabil The main sequence Arkitektur/ Overordnet struktur Implementations detaljer

65 Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.64 Hvorfor omvendt ved OO?? è interface klasser Interfaces til begreber Implementations detaljer gemmes længere nede Mulighed for at genbruge procedurelle abstraktioner


Download ppt "Objektorienteret analyse og design Ó Bennedsen 2001 Design - part 1 6.1 Programmering og systemudvikling Lektion 6 Design - part 1."

Lignende præsentationer


Annoncer fra Google