Download præsentationen
Præsentation er lastning. Vent venligst
Offentliggjort afKurt Vestergaard Redigeret for ca. et år siden
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
Lignende præsentationer
© 2024 SlidePlayer.dk Inc.
All rights reserved.