INSTITUTIONEN FÖR MATEMATIK, NATUR- OCH DATAVETENSKAP TENTAMEN

Transkript

1 INSTITUTIONEN FÖR MATEMATIK, NATUR- OCH DATAVETENSKAP TENTAMEN Kurs: Metoder för objektorienterad utveckling, 15 hp Kurskod: DV014C Kursmoment: 0040, Skriftlig tentamen Design/Realisering Datum: Tid: 15:00-19:00 Plats: 96:243 Lärare: Fredrik Bökman ) Hjälpmedel: Inga särskilda Antal uppgifter: 7 Max antal poäng: 41 Betygsgränser: Minst 22 p av 41 för godkänt. Skriv ditt namn och frågans nummer på varje ark. Besvara endast en fråga per ark. Börja med att titta igenom hela tentamen. Uppgifterna är inte ordnade tematiskt eller i svårighetsgrad. LYCKA TILL!

2 Högskolan i Gävle Tentamen, DV014C 2 ( 8) (1) Diverse [12 p] (a) Grunden för Larmans GRASPs är RDD, responsibility-driven design. Beskriv i egna ord vad RDD handlar om. [1 p] (b) Förklara vad Larmans GRASP Creator handlar om. Vilket problem är det som skall lösas och hur ser lösningen ut? [2] (c) Hitta på ett eget exempel (inte från Larman) där du använder Creator. Beskriv designalternativen och det val du gör utifrån Creator. [2] (d) Beskriv vad som menas med designmönster. [1] (e) Hur skall man gå tillväga ifall man har uppfunnit ett nytt designmönster? [1] (f) Förklara vad som menas med the Model-View Separation Principle. [1] (g) Vilket designmönster (GoF) förknippar du med modell-vy-separationen? Varför? [1] (h) Ett av Larmans GRASPs handlar bl.a. om hur man skapar utbytbara mjukvarukomponenter. Eftersom klassen User beror av klassen Server måste User ändras ifall vi vill byta ut Server mot Server2. Hur kan man lösa detta så att User inte behöver ändras när Server byts mot Server2? Beskriv lösningen i egna ord samt en figur. [3] User Server (2) Databaser [3 p] När en applikation kodad i ett objektorienterat språk som Java skall kopplas till en relationsdatabas krävs någon form av mappning mellan Javas objektmodell och relationsdatamodellen. Beskriv ett lämpligt relationsschema för följande domänklassdiagram. (Visa alltså vilka tabeller, kolumner och nycklar som är lämpliga.) Motivera dina lösningar i text. Photo datetaken binaryim age Player name position 1..* * age gender Team 1 * Trainer name trainerlicense

3 Högskolan i Gävle Tentamen, DV014C 3 ( 8) (3) POS enteritem [3 p] enteritem(id, qty) :Register 2: makelineitem(desc, qty) :Sale 1: desc = getproductdesc(id) 2.1: create(desc, qty) :Product Catalog sl: SalesLineItem 1.1: desc = get(id) 2.2: add(sl) : Map<ProductDescription> lineitems : List<SalesLineItem> (Från Larman, Figur 20.2, sid 372) I kursboken (Craig Larman, Applying UML and Patterns, 3:e uppl., Pearson Education, 2005) finns ett löpande exempel POS (PointOfSale) om försäljning med kassaapparater. Ovanstående interaktionsdiagram visar hur systemoperationen enteritem är tänkt att lösas av objekt i domänlagret (affärslogiken). Uppgift: Skapa Javaklasser (d.v.s. kod) som realiserar så mycket som möjligt av designdiagrammet ovan. Lägg till nödvändiga detaljer. Det behövs t.ex. en datatyp för qty (quantity). Ifall du behöver göra några antaganden så beskriv dem. Motivera val mellan olika alternativ. Du skall inte lägga till kod som behövs för att systemet skall fungera i praktiken (t.ex. användargränssnitt eller databaser), inte heller stöd för andra systemoperationer än enteritem. Det ingår inte i uppgiften att rita ett klassdiagram, men det kanske underlättar.

4 Högskolan i Gävle Tentamen, DV014C 4 ( 8) (4) Facade och Singleton [10 p] I Larman (Applying UML and Patterns, 3:e uppl., 2005, sid 462) finns följande beskrivning av designmönstret Facade: Problem: A common, unified interface to a disparate set of implementations or interfaces such as within a subsystem is required. There may be undesirable couplings to many things in the subsystem, or the implementation of the subsystem may change. What to do? Solution: Define a single point of contact to the subsystem a façade object that wraps the subsystem. Larman är tydlig med att Façade-objektet skall vara den enda ingången till subsystemet: the implementation and other components of the subsystem can t be seen by external components. Andra författare (t.ex. Grand, Patterns in Java, Vol 1, 1998 och Stelting & Maassen, Applied Java Patterns, 2002) anser tvärtom att Facade inte behöver innebära att subsystemets inre döljs för externa klienter. Klienter kan alltså, vid behov, skicka meddelanden direkt till objekt inne i subsystemet, utan att gå via Facade-objektet. Om man går tillbaka till den ursprungliga beskrivningen av Facade (Gamma, Helm, Johnson & Vlissides, Design Patterns, 1995) så står där bl.a.: Consequences [of Facade] 1. It shields clients from subsystem components making the subsystem easier to use. 2. It promotes weak coupling between the subsystem and its clients. 3. It doesn t prevent applications from using subsystem classes if they need to. Vad är egentligen bäst? (a) [2 p] Gör en jämförelse (diskutera för- och nackdelar) mellan (i) (ii) att bara tillåta anrop till subsystemet via Facaden och att tillåta klienter att anropa metoder direkt inne hos subsystemets klasser, utan att nödvändigtvis gå via Facaden. En av orsakerna till att GoF-boken förespråkade att klienterna skulle kunna gå runt facadeobjektet var att de språk (C++ och Smalltalk) som användes av författarna (GoF) inte kunde dölja subsystemets klasser för externa klienter. (b) [4 p] Hur kan man i Java se till att dölja subsystemets inre så att klienterna tvingas att endast använda facaden? Beskriv vilka språkmekanismer i Java som används och visa ett litet exempel på hur det kan se ut med en Facade, en Client och ett subsystem med de sinsemellan samarbetande klasserna A, B och C (eller intressantare namn) samt några lämpliga metoder.

5 Högskolan i Gävle Tentamen, DV014C 5 ( 8) Många designmönster liknar varandra och varje beskrivning av ett designmönster brukar ha en litet avsnitt Related Patterns. GoF (Design Patterns, 1995) kommenterar det t.ex. så här: You might think of a façade as an adapter to a set of other objects. But that interpretation overlooks the fact that (c) [1 p] Vad kan det vara för en viktig skillnad mellan Adapter och Facade som kommer efter But? (Ledtrådar: Vad är syftet med respektive mönster? Hur nya är de gränssnitt som är inblandade?) Det är vanligt att Facade-objekten implementeras enligt designmönstret Singleton. (d) [3 p] Beskriv designmönstret (GoF) Singleton. Vad går det ut på? Visa hur det kan implementeras i Java. (5) Information hiding [3 p] I boken Code Complete 2 (Microsoft Press, 2:a upplagan, 2004) diskuterar Steve McConnell Information Hiding som en milstolpe i utvecklingen av software engineering: Information hiding is part of the foundation of both structured design and object-oriented design. In structured design, the notion of "black boxes" comes from information hiding. In objectoriented design, it gives rise to the concepts of encapsulation and modularity and it is associated with the concept of abstraction. Information hiding is one of the seminal ideas in software development (sid 92) Information hiding is one of the few theoretical techniques that has indisputably proven its value in practice, which has been true for a long time (Boehm 1987a). Large programs that use information hiding were found years ago to be easier to modify by a factor of 4 than programs that don t (Korson and Vaishnavi 1986). Moreover, information hiding is part of the foundation of both structured design and object-oriented design. (sid 97) Asking about what needs to be hidden supports good design decisions at all levels. It promotes the use of named constants instead of literals at the construction level. It helps in creating good routine and parameter names inside classes. It guides decisions about class and subsystem decompositions and interconnections at the system level. (sid 98) Get into the habit of asking, "What should I hide?" You'll be surprised at how many difficult design decisions vanish before your eyes. (sid 98) a) Vilken forskare var det som i början på 1970-talet introducerade begreppet information hiding? [0 p] b) Vilket av Larmans GRASP hänger starkt ihop med Information hiding? [1 p] c) Förklara varför Information hiding hänger ihop med just detta GRASP. I den här förklaringen bör du beskriva GRASP:et ifråga samt förklara hur information hiding är relevant i sammanhanget. [2 p]

6 Högskolan i Gävle Tentamen, DV014C 6 ( 8) (6) Frameworks [3 p] I kapitel 37 av Applying UML and Patterns (3:e upplagan) presenterar Craig Larman PFW, ett förenklat ramverk för persistens. Han är tydlig med att det finns bättre robusta liknande ramverk tillgängliga och att bokens exempel bl.a. är till för att ge en introduktion till design av ramverk i ett viktigt tillämpningsområde (persistens). Men vad är ett ramverk? Larman själv ger i ordlistan följande förklaring: framework A set of collaborating abstract and concrete classes that may be used as a template to solve a related family of problems. It is usually extended by subclassing for application-specific behavior. (sid 690) För att tydligare visa på skillnaden mellan ett ramverk (framework) och ett vanligt klassbibliotek eller toolkit kan följande citat ur GOF-boken (Design Patterns: Elements of Reusable Object- Oriented Software. Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison- Wesley, 1995) vara lämpliga: toolkit A collection of classes that provides useful functionality but does not define the design of an application. (sid 362) Toolkits don't impose a particular design on your application; they just provide functionality that can help your application do its job. They let you as an implementer avoid recoding common functionality. Toolkits emphasize code reuse. They are the object-oriented equivalent of subroutine libraries. (sid 26) framework A set of cooperating classes that makes up a reusable design for a specific class of software. A framework provides architectural guidance by partitioning the design into abstract classes and defining their responsibilities and collaborations. A developer customizes the framework to a particular application by subclassing and composing instances of framework classes. (sid 360) The framework dictates the architecture of your application. It will define the overall structure, its partitioning into classes and objects, the key responsibilities thereof, how the classes and objects collaborate, and the thread of control. A framework predefines these design parameters so that you, the application designer/implementer, can concentrate on the specifics of your application. The framework captures the design decisions that are common to its application domain. Frameworks thus emphasize design reuse over code reuse, though a framework will usually include concrete subclasses you can put to work immediately. (sid 26) Avslutningsvis, tillbaka till Larman: A framework relies on the Hollywood principle Don t call us, we ll call you. This means that the user-defined classes (for example new subclasses) will receive messages from the predefined framework classes. These are usually handled by implementing superclass abstract methods. (sid 623) Uppgift: Ge ett litet exempel som visar hur en applikation använder ett ramverk enligt Hollywoodprincipen (se ovan). Du kan välja ett ramverk du har arbetat med eller läst om, eller hitta på ett förenklat miniramverk som visar principerna. Exemplet bör innehålla klassdiagram, javakod samt förklaringar.

7 Högskolan i Gävle Tentamen, DV014C 7 ( 8) (7) Konsultföretaget K [7 p] Du har fått i uppgift att skriva en applikation åt ett litet konsultföretag K som har specialiserat sig på att hjälpa andra konsultföretag med kniviga programmerings- och modelleringsproblem. Applikationen skall hjälpa konsultföretaget K att fakturera sina kunder. Det finns redan en annan applikation X som hanterar fördelningen av uppdrag/projekt på olika anställda hos firman K, så det skall din nya applikation inte ta hand om. Faktureringen utgår från timkort som företaget K:s anställda skriver. Där framgår bl.a. datum, antal arbetade timmar och en projektkod. Varje anställd har en viss fix timtaxa som debiteras kunden. De anställda har en grundlön plus en bonus efter hur många timmar de har fakturerat under månaden. Din applikation skall inte hantera lönerna, det gör ett annat system Y, men den skall kunna hjälpa lönesystemet Y med antalet timmar. Din applikation skall bl.a. stödja följande uppgifter: Skapa fakturor för en viss tidsperiod (för alla kunder eller för en enda kund). Skapa en faktura för en viss kund och alla timkort som inte redan har fakturerats. Sortera kunder efter fakturerat belopp ( kundvärde ) Lagra kunduppgifter Lagra uppgifter om timkort Ta reda på antalet timmar en anställd har fakturerat under en given månad. (a) Beskriv vilka domänklasser som är lämpliga i ett klassdiagram. Motivera. [1 p] (b) Rita ett interaktionsdiagram och ett designklassdiagram som stödjer följande scenario: Ekonomiavdelningen skapar en faktura till en kund och på den faktura finns med allt arbete för kunden som inte redan tidigare fakturerats. Antag en traditionell trelagersarkitektur (GUI-domän-persistens). Motivera med hjälp av Larmans GRASP tilldelningen av ansvar för varje operation. [6 p]

8 Högskolan i Gävle Tentamen, DV014C 8 ( 8) Bilaga 1: Craig Larmans nio GRASP Information Expert Creator Controller Low Coupling High Cohesion Polymorphism Pure Fabrication Indirection Protected Variation Bilaga 2: 23 GoF patterns (Gamma, Helm, Johnson & Vlissides) Creational: Abstract factory, Builder, Factory, Prototype, Singleton Structural: Adapter, Bridge, Composite, Decorator, Façade, Flyweight, Proxy Behavioral: Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template method, Visitor