UP - fáze rozpracování II (návrh) J. Zendulka (s využitím obrázků z knihy C.Larmana a L.A.Maciaszka)

Transkript

1 UP - fáze rozpracování II (návrh) J. Zendulka (s využitím obrázků z knihy C.Larmana a L.A.Maciaszka)

2 Obsah Logická architektura Závislosti balíčků Architektonické vzory OO návrh - úvod OO návrh - modelovací techniky UML OO návrh principy návrhu GRASP OO návrh návrhové vzory Návrh viditelnosti objektů Programování Návrh řízený testem a refaktorizace UP - fáze rozpracování II (návrh) 2

3 Vliv artefaktů UP Sample UP Artifact Relationships Business Modeling Domain Model * * Requirements Use-Case Model Vision Supplementary Specification Glossary The logical architecture is influenced by the constraints and non-functional requirements captured in the Supp. Spec. Design Model package diagrams UI of the logical architecture (a static view) Domain Tech Services : Register : ProductCatalog Design interaction diagrams (a dynamic view) enteritem (itemid, quantity) spec = getproductspec( itemid ) class diagrams (a static view) Register makenewsale() enteritem() 1 1 ProductCatalog getproductspec() UP - fáze rozpracování II (návrh) 3

4 Logická architektura Logická architektura organizace tříd do balíčků (jmenných prostorů), podsystémů, vrstev. Neříká nic o nasazení do různých prostředí, na různé počítače atd. (architektura nasazení (deployment architecture)). UP - fáze rozpracování II (návrh) 4

5 Vrstvy Seskupení tříd, balíčků, podsystémů, které souvisejí z hlediska zodpovědnosti za nějaký významný aspekt systému. Organizovány hierarchicky, vyšší využívá služeb nižší vrstvy. Typické vrstvy: uživatelské rozhraní aplikační logika a objekty domény technické služby (přístup k databázi, záznam chyb, ) UP - fáze rozpracování II (návrh) 5

6 Vrstvené architektury Striktní (uzavřená) vrstvená architektura - vyšší vrstva může používat jen bezprostředně nižší vrstvu. Uvolněná (otevřená) vrstvená architektura - vyšší vrstva může používat několik nižších vrstvev. Organizace architektury do vrstev je v současnosti velmi běžné. UP - fáze rozpracování II (návrh) 6

7 Softwarová architektura Soubor významných rozhodnutí o organizaci SW systému, výběru strukturních prvků a jejich rozhraní, pomocí nichž je systém sestaven, společně s jejich chováním specifikovaným spoluprací těchto prvků, seskupení do postupně větších podsystémů a architektonický styl, který řídí tuto organizaci. Organizace ve velkém UP - fáze rozpracování II (návrh) 7

8 Modelování logické architektury v UML diagram balíčků UI Domain Swing Web Sales UI UI::Swing UI::Web Domain::Sales Swing Web Domain Sales UP - fáze rozpracování II (návrh) 8

9 Návrh s vrstvami Organizace do vrstev s různou zodpovědností, s jasným oddělením toho, co řeší ( concern ), tak, že nižší vrstvy poskytují obecnější služby nižší úrovně, zatímco vyšší vrstvy jsou aplikačně specifičtější. Spolupráce a vazba (reprezentovaná závislostmi) je od vyšších vrstev k nižším, ne naopak. UP - fáze rozpracování II (návrh) 9

10 Návrh s vrstvami řešené problémy Šíření změn v systému. Provázání aplikační logiky a uživatelského rozhraní. Obecné technické služby jsou provázány s aplikačně specifičtější logikou Vysoké provázání částí řešících různé věci je obtížné rozdělení práce vývojářům. UP - fáze rozpracování II (návrh) 10

11 Typické vrstvy architektury IS GUI windows reports speech interface HTML, XML, XSLT, JSP, Javascript, UI (AKA Presentation, View) handles presentation layer requests workflow session state window/page transitions consolidation/transformation of disparate data for presentation handles application layer requests implementation of domain rules domain services (POS, Inventory) - services may be used by just one application, but there is also the possibility of multi-application services Application (AKA Workflow, Process, Mediation, App Controller) Domain (AKA Business, Application Logic, Model) dependency more app specific very general low-level business services used in many business domains CurrencyConverter Business Infrastructure (AKA Low-level Business Services) (relatively) high-level technical services and frameworks Persistence, Security Technical Services (AKA Technical Infrastructure, High-level Technical Services) low-level technical services, utilities, and frameworks data structures, threads, math, file, DB, and network I/O Foundation (AKA Core Services, Base Services, Low-level Technical Services/Infrastructure) width implies range of applicability UP - fáze rozpracování II (návrh) 11

12 Návrh s vrstvami výhody Oddělení věcí, které vrstvy řeší, oddělení aplikačně specifických od obecných služeb redukce provázanosti a zvýšení koheze, zvýšení potenciálního opakovaného použití a srozumitelnosti. Komplexnost je zapouzdřena ve vrstvách. Některé vrstvy mohou být nahrazeny novou implementací. Některé vrstvy mohou být distribuované. Jsou vytvořeny lepší podmínky pro vývoj v týmu. UP - fáze rozpracování II (návrh) 12

13 Objekty domény Jak navrhnout OO aplikační logiku? Jedna třída zahrnující všechny potřebné metody. Třídy odpovídající reálné doméně s odpovídající informací a operacemi (SW) objekty domény. UP - fáze rozpracování II (návrh) 13

14 Vztah modelu domény a modelu návrhu UP Domain Model Stakeholder's view of the noteworthy concepts in the domain. A Payment in the Domain Model is a concept, but a Payment in the Design Model is a software class. They are not the same thing, but the former inspired the naming and definition of the latter. This reduces the representational gap. This is one of the big ideas in object technology. Payment amount Payment amount: Money 1 Pays-for 1 inspires objects and names in 1 1 Pays-for date time Sale Sale date: Date starttime: Time getbalance(): Money gettotal(): Money... UP Design Model The object-oriented developer has taken inspiration from the real world domain in creating software classes. Therefore, the representational gap between how stakeholders conceive the domain, and its representation in software, has been lowered. UP - fáze rozpracování II (návrh) 14

15 Vrstvy a sekce Vrstva architektury reprezentuje vertikální řezy. Sekce reprezentují horizontální dělení relativně paralelních podsystémů. Pozn.: 1. Vztahy podsystémů: a) klient-server, b) sobě rovný (peer-to-peer) 2. Vztah označení layer a tier UP - fáze rozpracování II (návrh) 15

16 Příklad vrstvené architektury aplikace řízení uživatelského rozhraní grafika okna grafika obrazovky grafika bodu operační systém HW simulační knihovna UP - fáze rozpracování II (návrh) 16

17 Příklad architektury Windows NT Win16 MS-DOS NTVDM POSIX subsystem Win32 subsystem OS/2 subsystem Security subsystem User mode Kernel mode Executive Services System Services I/O Manager Cache manager File System drivers Network drivers Hardware Device Drivers Object Manager Security Reference Monitor Process Manager Microkernel Local Procedure Call Facility Hardware Abstraction Layer (HAL) Virtual Memory Manager Window Manager (WIN32K.SYS) Graphics Device Drivers Hardware UP - fáze rozpracování II (návrh) 17

18 Příklad vrstvené architektury v UML Domain POS Inventory Tax Vertical Layers Technical Services Persistence Security Logging Horizontal Partitions UP - fáze rozpracování II (návrh) 18

19 Zásada: Nezobrazuj externí zdroje a služby Worse mixes logical and deployment views Better a logical view Domain(s) Technical Services Domain(s) POS Technical Services Inventory a logical representation of the need for data or services related to these subdomains, abstracting implementation decisions such as a database. Foundation Persistence Naming and Directory Services Web AppFramework MySQL Inventory «component» Novell LDAP Foundation UML notation: A UML component, or replaceable, modular part of the physical system UML notation: A physical database in the UML. UP - fáze rozpracování II (návrh) 19

20 Obsah Logická architektura Závislosti balíčků Architektonické vzory OO návrh - úvod OO návrh - modelovací techniky UML OO návrh principy návrhu GRASP OO návrh návrhové vzory Návrh viditelnosti objektů Programování Návrh řízený testem a refaktorizace UP - fáze rozpracování II (návrh) 20

21 Závislost Balíček (třída) A závisí na balíčku B jestliže si změny v balíčku B mohou vynutit změny v balíčku A. Klíčová z pohledu zajištění podporovatelnosti (supportability), tj. udržovatelnosti, srozumitelnosti a škálovatelnosti. Závislost tříd závislost balíčků závislost vrstev UP - fáze rozpracování II (návrh) 21

22 Závislosti tříd Package A <<layer>> Layer 1 Package B P ac kage A depends on P ac kage B bec ause Clas s X depends on Class Y Class X Class Y Layer 1 depends on Layer 2 because Class X depends on Class Z Package C <<layer>> Layer 2 Package D Class Z Package E UP - fáze rozpracování II (návrh) 22

23 Dědění Asociace Volání operace Parametr operace Zdroje závislostí UP - fáze rozpracování II (návrh) 23

24 Závislost třídy Test na Object zjistitelná v době překladu Test dotest() 1 Object wait() public void dotest(){ Object a = new A(); a.wait(); } A do1() do2() UP - fáze rozpracování II (návrh) 24

25 Závislosti z asociací a volání control CActioner do1() 0..1 p ubl ic cla ss EOu tmessa ge { EEmp lo yee emp; p ubl ic void d o2() { emp.do 3(); } } public class CActioner { EEmployee emp; public void do1() { emp.do3(); } } Act Emp entity EOut Message do2() n OutEmp EEmployee do3() 0..n UP - fáze rozpracování II (návrh) 25

26 Závislosti vrstev Nižší vrstvy by měly být stabilní. <<layer>> Layer 1 <<layer>> Layer 2 Package A Package B Package C Package D Layer 1 depends on Layer 2 Package E UP - fáze rozpracování II (návrh) 26

27 Cykly mezi balíčky Package A Package B Package C Package D Package E UP - fáze rozpracování II (návrh) 27

28 Odstranění cyklů mezi balíčky Package A Package B circularly-dependable Package A2 elements of Package A extracted into Package A2 UP - fáze rozpracování II (návrh) 28

29 Odstranění cyklů použitím rozhraní (1) <<layer>> presentation PPrimaryWindow do2() <<layer>> control CInit do1() public class CInit { PPrimaryWindow window; public void do1() { window.do2(); } } PDialogBox do3() CActioner do4() pu blic class PDial ogbox { CActione r acti oner; public vo id do3() { actioner.do4(); } } public class CActioner{ public void do4() { //perform some actions } } UP - fáze rozpracování II (návrh) 29

30 Odstranění cyklů použitím rozhraní (2) public class PPri marywindow im plem ents control.icpresenter { public void do2() { //im plem entation code } } publ ic interface PController { publ ic void do2(); } public class CInit { ICPresenter presenter; public void do1(){ presenter.do2(); } } <<layer>> presentation <<layer>> control PPrimaryWindow ICPresenter <<uses>> CInit do2() do2() do1() PDialogBox CActioner do3() do4() UP - fáze rozpracování II (návrh) 30

31 Zásada: Princip oddělení modelu a pohledu Nevytvářet vazbu objektů vnitřních vrstev (ne-ui) na objekty uživatelského rozhraní (UI) (např. třída Sale má referenci na JFrame ze Java Swing). Tj. závislost Sale na JFrame. Nevkládat aplikační logiku do operací tříd UI (např. výpočet daně), ale delegovat požadavky ne-ui objektům. UP - fáze rozpracování II (návrh) 31

32 Zpracování asynchronních událostí Použitím návrhového vzoru Observer UP - fáze rozpracování II (návrh) 32

33 Příklad z případové studie (1) Goal: When the total of the sale changes, refresh the display with the new value total Sale settotal( newtotal ) UP - fáze rozpracování II (návrh) 33

34 Příklad z případové studie (2) { } for each PropertyListener pl in propertylisteners pl.onpropertyevent( this, name, value ); { } propertylisteners.add( lis ); Sale addpropertylistener( PropertyListener lis ) publishpropertyevent( name, value ) settotal( Money newtotal ) { total = newtotal; publishpropertyevent( "sale.total", total ); } javax.swing.jframe settitle() setvisible() propertylisteners «interface» PropertyListener onpropertyevent( source, name, value ) * { if ( name.equals("sale.total") ) saletextfield.settext( value.tostring() ); } SaleFrame1 onpropertyevent( source, name, value ) initialize( Sale sale ) { sale.addpropertylistener( this ) } UP - fáze rozpracování II (návrh) 34

35 Vztah SSD, systémových operací a vrstev SSD ukazuje systémové operace. Kde se provedou? V dobře navržené vrstvené architektuře delegují objekty UI požadavek na zpracování vrstvě domény. UP - fáze rozpracování II (návrh) 35

36 Systémové operace v SSD a ve vrstvách UI :System : Cashier makenewsale() enteritem(id, quantity) description, total Domain Swing ProcessSale Frame makenewsale() enteritem() endsale() makenewsale() enteritem() endsale() : Cashier endsale() Register makenewsale() enteritem() the system operations handled by the system in an SSD represent the operation calls on the Application or Domain layer from the UI layer UP - fáze rozpracování II (návrh) 36

37 Logická architektura NextGen POS pro UI 1.iteraci Swing not the Java Swing libraries, but our GUI classes based on Swing Web Domain Sales Payments Taxes Technical Services Persistence Logging RulesEngine UP - fáze rozpracování II (návrh) 37

38 Obsah Logická architektura Závislosti balíčků Architektonické vzory OO návrh - úvod OO návrh - modelovací techniky UML OO návrh principy návrhu GRASP OO návrh návrhové vzory Návrh viditelnosti objektů Programování Návrh řízený testem a refaktorizace UP - fáze rozpracování II (návrh) 38

39 MVC Model-View-Controler (1) Application Program View Database and Web Services Model Persistent Data Controller UP - fáze rozpracování II (návrh) 39

40 MVC Model-View-Controller (2) Model odpovídá vrstvě domény, obsahuje objekty domény, přidává k datům aplikační logiku (např. výpočet sumy prodeje u třídy Sale). View zodpovědný za prezentaci modelu (objekty UI, dynamické HTML stránky). Controler zpracovává a reaguje na události (typicky akce uživatele), může měnit stav objektů balíčků Model i View. UP - fáze rozpracování II (návrh) 40

41 Architektura PCMEF (Maciaszek) Core J2EE tiers Client Tier applets, apps user interaction, UI presentation PCMEF layers <<layer>> presentation Presentation Tier servlets, JSP session management, content management, format and delivery <<layer>> control Core J2EE patterns Business Tier EJB business logic, transactions Integration Tier JDBC, JMS, Connectors, Legacy resource adapters, external systems, rules engines, workflow entity <<layer>> domain mediator Resource Tier Databases, external systems resources, data and external services <<layer>> foundation UP - fáze rozpracování II (návrh) 41

42 Principy architektury PCMEF DDP - Downward Dependency Principle UNP - Upward Notification Principle NCP - Neighbor Communication Principle EAP - Explicit Association Principle CEP - Cycle Elimination Principle CNP - Class Naming Principle APP - Acquaintance Package Principle UP - fáze rozpracování II (návrh) 42

43 Význam principů PCMEF CNP konvence pro pojmenování (jmého začíná písmenem vrstvy, např. EEmployee). NCP komunikace pouze se sousední vrstvou. EAP komunikace objektů je vizualizována prostřednictvím asociací. DDP vyšší vrstvy závisí jen na nižších. CEP cykly mezi vrstvami jsou vyloučeny (použitím rozhraní nebo vytvořením speciálního balíčku). APP vytvoření speciální vrstvy obsahující rozhraní pro složitější komunikaci objektů ve vrstvách. UNP oznamování ve směru zdola nahoru mechanismem zpracování asynchronních událostí. UP - fáze rozpracování II (návrh) 43

44 Obsah Logická architektura Závislosti balíčků Architektonické vzory OO návrh - úvod OO návrh - modelovací techniky UML OO návrh principy návrhu GRASP OO návrh návrhové vzory Návrh viditelnosti objektů Programování Návrh řízený testem a refaktorizace UP - fáze rozpracování II (návrh) 44

45 Způsoby návrhu Přímé kódování návrh prováděn při programování, užitečné s nástrojem podporujícím refaktorizaci. Namodelování, pak kódování. Pouze modelování MDA, nikdy zcela automatické, vždy je potřeba připojit nějaký kód. UP - fáze rozpracování II (návrh) 45

46 Agilní modelování a CASE nástroje Modely v podobě náčrtků na tabuli, snímání kamerou a tisk, Souběžné vytváření několika modelů (např. interakce a tříd) viz CASE nástroje s vazbou na integrovaná vývojová prostředí (IDE) (Eclipse, Visual Studio, JDeveloper, ), žádoucí podpora reverzního inženýrství. UP - fáze rozpracování II (návrh) 46

47 Kolik času strávit modelováním Larman: Pro iteraci v trvání tří týdnů několik hodin, max. 1 den na začátku iterace, pak kódování inspirované modely. Podstatná je schopnost uvažovat a navrhovat objektově a schopnost aplikovat osvědčené praktiky OO návrhu. Důležité otázky OO návrhu: Jaké jseo zodpovědnosti třídy/objektu a s kým spolupracuje. UP - fáze rozpracování II (návrh) 47

48 CRC štítky UP - fáze rozpracování II (návrh) 48

49 Obsah Logická architektura Závislosti balíčků Architektonické vzory OO návrh - úvod OO návrh - modelovací techniky UML OO návrh principy návrhu GRASP OO návrh návrhové vzory Návrh viditelnosti objektů Programování Návrh řízený testem a refaktorizace UP - fáze rozpracování II (návrh) 49

50 Základní diagramy OO návrhu Diagramy interakce interakce objektů zasíláním zpráv (dynamický model). Diagram tříd statická struktura tvořená třídami a rozhraními (statický model). UP - fáze rozpracování II (návrh) 50

51 Diagram sekvence modelování singletonu dox : Register doa : Store 1 the 1 implies this is a Singleton, and accessed via the Singleton pattern UP - fáze rozpracování II (návrh) 51

52 Diagram sekvence modelování návratové hodnoty : Register : Sale dox d1 = getdate getdate adate UP - fáze rozpracování II (návrh) 52

53 Diagram sekvence vytvoření objektu : Register : Sale note that newly created objects are placed at their creation "height" makepayment(cashtendered) create(cashtendered) : Payment authorize UP - fáze rozpracování II (návrh) 53

54 Diagram sekvence zrušení objektu : Sale create(cashtendered) «destroy» : Payment X the «destroy» stereotyped message, with the large X and short lifeline indicates explicit object destruction UP - fáze rozpracování II (návrh) 54

55 Diagram sekvence volání operace třídy message to class, or a static method call :Foo «metaclass» Calendar dox locales = getavailablelocales public class Foo { public void dox() { // static method call on class Calendar Locale[] locales = Calendar.getAvailableLocales(); // } // } UP - fáze rozpracování II (návrh) 55

56 Diagram sekvence polymorfismus Payment is an abstract superclass, with concrete subclasses that implement the polymorphic authorize operation Payment {abstract} authorize() {abstract} CreditPayment authorize() DebitPayment authorize() polymorphic message object in role of abstract superclass :Register :Payment {abstract} dox authorize stop at this point don t show any further details for this message :DebitPayment :Foo :CreditPayment :Bar authorize doa authorize dox dob separate diagrams for each polymorphic concrete case UP - fáze rozpracování II (návrh) 56

57 Diagram sekvence aktivní třída a stick arrow in UML implies an asynchronous call a filled arrow is the more common synchronous call In Java, for example, an asynchronous call may occur as follows: :ClockStarter active object System : Class // Clock implements the Runnable interface Thread t = new Thread( new Clock() ); t.start(); startclock create :Clock the asynchronous start call always invokes the run method on the Runnable (Clock) object run to simplify the UML diagram, the Thread object and the start message may be avoided (they are standard overhead ); instead, the essential detail of the Clock creation and the run message imply the asynchronous call runfinalization UP - fáze rozpracování II (návrh) 57

58 Diagram komunikace polymorfismus polymorphic message stop at this point don t show any further details for this message dox :Register authorize :Payment {abstract} object in role of abstract superclass authorize authorize :DebitPayment doa dob :Foo :CreditPayment dox :Bar separate diagrams for each polymorphic concrete case UP - fáze rozpracování II (návrh) 58

59 Diagram komunikace aktivní třída startclock :ClockStarter 3: runfinalization System : Class :Clock 1: create 2: run asynchronous message active object UP - fáze rozpracování II (návrh) 59

60 Diagram tříd singleton, vlastnosti třídy UML notation: in a class box, an underlined attribute or method indicates a static (class level) member, rather than an instance member instance : ServicesFactory ServicesFactory accountingadapter : IAccountingAdapter inventoryadapter : IInventoryAdapter taxcalculatoradapter : ITaxCalculatorAdapter getinstance() : ServicesFactory 1 UML notation: this '1' can optionally be used to indicate that only one instance will be created (a singleton) getaccountingadapter() : IAccountingAdapter getinventoryadapter() : IInventoryAdapter gettaxcalculatoradapter() : ITaxCalculatorAdapter UP - fáze rozpracování II (návrh) 60

61 Diagram tříd aktivní třída active class «interface» Runnable Clock run() run() UP - fáze rozpracování II (návrh) 61

62 Vztah diagramů interakce a diagramu tříd : Register : Sale makepayment(cashtendered) makepayment(cashtendered) messages in interaction diagrams indicate operations in the class diagrams Register makepayment( ) 1 currentsale Sale makepayment( ) classes identified in the interaction diagrams are declared in the class diagrams UP - fáze rozpracování II (návrh) 62

63 Obsah Logická architektura Závislosti balíčků Architektonické vzory OO návrh - úvod OO návrh - modelovací techniky UML OO návrh principy návrhu GRASP OO návrh návrhové vzory Návrh viditelnosti objektů Programování Návrh řízený testem a refaktorizace UP - fáze rozpracování II (návrh) 63

64 Podstata OO návrhu Nalézt třídy a interakci jejich objektů, které budou realizovat chování reprezentované případy použití při respektování omezení daných nefunkčními požadavky. Pro OO návrh je kritická znalost a schopnost aplikovat principy návrhu (ne znalost UML nebo konkrétních technologií). UP - fáze rozpracování II (návrh) 64

65 Vstupy OO návrhu Specifikace případů použití Doplňující specifikace Systémové diagramy sekvence (SSD) Kontrakty operací Slovník Model domény UP - fáze rozpracování II (návrh) 65

66 Výstupy OO návrhu Sample UP Artifact Relationships Domain Model Business Modeling date... Sale 1 1..* Sales... LineItem... quantity Use-Case Model Process Sale inspiration for names of some software domain objects Requirements starting events to design for, and detailed postcondition to satisfy Cashier Process Sale Use Case Diagram Operation: enteritem( ) Post-conditions: -... Operation Contracts ideas for the postconditions use case names system operations : Register : Cashier 1. Customer arrives Cashier enters item identifier. Use Case Text system events make NewSale() enteritem (id, quantity) : System System Sequence Diagrams Design Model functional requirements that must be realized by the objects : ProductCatalog Glossary Supplementary Specification item details, formats, validation non-functional requirements domain rules : Sale Design enteritem (itemid, quantity) d = getproductdescription(itemid) addlineitem( d, quantity ) Register makenewsale() enteritem() * 1 ProductCatalog getproductdescription() UP - fáze rozpracování II (návrh) 66

67 Odpovědnosti (1) Jde o oblíbený způsob uvažování o návrhu tříd, ale i větších celků (viz vrstvy architektury). Odpovědnost za činnost: dělání něčeho vytvoření objektů, výpočet něčeho, spuštění nějaké akce u jiných objektů řízení a koordinace akcí jiných objektů UP - fáze rozpracování II (návrh) 67

68 Odpovědnosti (2) Odpovědnost za vědomost: privátních zapouzdřených dat souvisejících objektů věcí, které může odvodit nebo spočítat Př) Třída Sale je zodpovědná za vytvoření SalesLineItems a znalost celkové částky. Odpovědnosti jsou implementovány pomocí metod a spolupráce s jinými metodami a objekty. UP - fáze rozpracování II (návrh) 68

69 Návrh řízený odpovědností Způsob návrhu založený na uvažování o zodpovědnostech a spolupráci, jejich přiřazování třídám. Hledání množiny spolupracujících zodpovědných objektů které zajistí splnění cílů návrhu. Principy GRASP (General Responsibility Assignment Software Patterns - Larman) učební pomůcka pro OO návrh založený na zodpovědnostech. UP - fáze rozpracování II (návrh) 69

70 Vztah zodpovědností a UML diagramů : Sale makepayment(cashtendered) create(cashtendered) : Payment abstract, implies Sale objects have a responsibility to create Payments Při kreslení diagramu interakce přiřazujeme zodpovědnosti. UP - fáze rozpracování II (návrh) 70

71 Tvůrce (Creator) Principy GRASP Informační expert (Information Expert) Nízká vazba (Low Coupling) Řadič (Controller) Vysoká koheze (High Cohesion) Polymorfismus (Polymorphism) Pouhá konstrukce (Pure Fabrication) Nepřímost (Indirection) Chráněné změny (Protected Variation) UP - fáze rozpracování II (návrh) 71

72 Creator Problém: Kdo vytváří objekty? Řešení: Přiřaď třídě B zodpovědnost za vytváření instancí třídy A, pokud platí některá z následujících podmínek: B obsahuje A B agreguje A B má inicializační data pro A B zaznamenává A B hodně užívá A UP - fáze rozpracování II (návrh) 72

73 Př) Kdo vytváří instance SalesLineItem? Sale time 1 Contains Sales LineItem quantity 1..* * Described-by 1 Product Description description price itemid : Register : Sale makelineitem(quantity) create(quantity) : SalesLineItem UP - fáze rozpracování II (návrh) 73

74 Creator kdy nepoužít, přínos Jsou-li speciální požadavky, které činí vytváření složité (recyklace instancí kvůli výkonnosti, podmíněné vytváření z rodiny podobných tříd atd.), pak raději použít návrhový vzor Factory, resp. Abstract Factory. Přínos: Nezvyšuje vazbu, třída tvůrce velmi pravděpodobně již závisí na vytvářené třídě díky asociaci či zanoření. UP - fáze rozpracování II (návrh) 74

75 Information Expert Problém: Kdo má za co zodpovídat? (Základní princip OO návrhu a přiřazení zodpovědností.) Řešení: Přiřaď zodpovědnost informačnímu expertovi - třídě, která má informace nezbytné ke splnění zodpovědnosti. UP - fáze rozpracování II (návrh) 75

76 Př) Kdo zodpovědný za celkovou částku? (1) Sale time 1 Contains Sales LineItem quantity 1..* * Described-by 1 Product Description description price itemid t = gettotal :Sale Sale time New method gettotal() UP - fáze rozpracování II (návrh) 76

77 Př) Kdo zodpovědný za celkovou částku? (2) this notation will imply we are iterating over all elements of a collection t = gettotal : Sale 1 *: st = getsubtotal lineitems[ i ] : SalesLineItem time Sale gettotal() SalesLineItem quantity New method getsubtotal() UP - fáze rozpracování II (návrh) 77

78 Př) Kdo zodpovědný za celkovou částku? (3) Sale t = gettotal : Sale 1 *: st = getsubtotal lineitems[ i ] : SalesLineItem time gettotal() 1.1: p := getprice() SalesLineItem quantity :Product Description getsubtotal() Product Description description price itemid New method getprice() UP - fáze rozpracování II (návrh) 78

79 Information Expert kdy nepoužít, přínos Někdy by použití mohlo mít nežádoucí dopad na vazbu, propojení a duplikaci. Např. ukládání info o prodeji do DB (Sale?, totéž pro každou třídu domény?) Přínos: Obvykle vede na nízkou vazbu a vysokou kohezi. UP - fáze rozpracování II (návrh) 79

80 Low coupling Problém: Jak redukovat vliv změn Řešení: Přiřaď zodpovědnost tak, aby nezbytná vazba byla nízká. Použij tento princip pro vyhodnocování alternativ. UP - fáze rozpracování II (návrh) 80

81 Př) Kdo zodpovědný za vytváření instance Payment a její spojení se Sale? (1) Předpokládejme existenci tříd Payment, Register a Sale. makepayment() 1: create() : Register p : Payment 2: addpayment(p) :Sale UP - fáze rozpracování II (návrh) 81

82 Př) Kdo zodpovědný za vytváření instance Payment a její spojení se Sale? (2) makepayment() 1: makepayment() : Register :Sale 1.1. create() :Payment Která varianta je lepší z pohledu nižší vazby? UP - fáze rozpracování II (návrh) 82

83 Low Coupling kdy nepoužít, přínos Silnější vazba na stabilní a běžně používané prvky (např. knihovny Javy) není problémem. Přínos: Obvykle vede na nízkou vazbu a vysokou kohezi. UP - fáze rozpracování II (návrh) 83

84 Controller Problém: Který první objekt za vrstvou UI dostává a koordinuje (řídí) operaci systému? Řešení: Přiřaď zodpovědnost objektu, který reprezentuje jednu z následujících možností: 1. Reprezentuje celý systém, kořenový objekt nebo zařízení, v němž SW běží, nebo hlavní podsystém (varianty tzv. facade controller ). 2. Reprezentuje scénář případu použití, v jehož rámci se systémová událost vyskytuje (tzv. use case/session controller ). UP - fáze rozpracování II (návrh) 84

85 Př) Která třída by měla být řadičem pro enteritem? (1) System endsale() enteritem() makenewsale() makepayment()... UP - fáze rozpracování II (návrh) 85

86 Př) Která třída by měla být řadičem pro enteritem? (2) presses button : Cashier actionperformed( actionevent ) UI Layer :SaleJFrame enteritem(itemid, qty) system operation message Domain Layer :??? Which class of object should be responsible for receiving this system event message? It is sometimes called the controller or coordinator. It does not normally do the work, but delegates it to other objects. The controller is a kind of "facade" onto the domain layer from the interface layer. UP - fáze rozpracování II (návrh) 86

87 Př) Která třída by měla být řadičem pro enteritem? (3) Možnosti dle principu Controller: Register/POSSystem ProcessSaleHandler/ProcessSaleSession enteritem(id, quantity) :Register enteritem(id, quantity) :ProcessSaleHandler UP - fáze rozpracování II (návrh) 87

88 Př) Která třída by měla být řadičem pro enteritem? (3) UP - fáze rozpracování II (návrh) 88

89 Př) Která třída by měla být řadičem pro enteritem? (4) UP - fáze rozpracování II (návrh) 89

90 Controller doporučení Řadič by neměl dělat mnoho, spíše deleguje a řídí a koordinuje systémovou operaci. První varianta je vhodná, není-li mnoho systémových operací, resp. nelze-li přesměrovat alternativním řadičům. Řadiče pro případy použití je navíc vhodné použít tehdy, když by jediný řadič vedl na návrh s nízkou kohezí nebo vysokou vazbou. Systémové operace by měly být řešeny ve vrstvě aplikační logiky nebo domény, nikoliv objekty vrstvy UI. UP - fáze rozpracování II (návrh) 90

91 Vrstva UI nezpracovává systémové události - OK presses button : Cashier actionperformed( actionevent ) UI Layer :SaleJFrame system operation message 1: enteritem(itemid, qty) controller Domain Layer :Register 1.1: makelineitem(itemid, qty) :Sale UP - fáze rozpracování II (návrh) 91

92 Vrstva UI nezpracovává systémové události - NE presses button Cashier actionperformed( actionevent ) UI Layer :SaleJFrame It is undesirable for an interface layer object such as a window to get involved in deciding how to handle domain processes. Business logic is embedded in the presentation layer, which is not useful. Domain Layer 1: makelineitem(itemid, qty) :Sale SaleJFrame should not send this message. UP - fáze rozpracování II (návrh) 92

93 High Cohession Problém: Jak nechat objekty soustředěné, srozumitelné, spravovatelné a jako boční efekt podporovat princip Low Coupling? Řešení: Přiřaď odpovědnost, aby koheze zůstala vysoká. Použij tento princip pro vyhodnocování alternativ. UP - fáze rozpracování II (návrh) 93

94 Př) Kdo zodpovědný za vytváření instance Payment a její spojení se Sale? (1) Varianta přiřazení zodpovědnosti třídě Register. : Register : Sale makepayment() create() p : Payment addpayment( p ) UP - fáze rozpracování II (návrh) 94

95 Př) Kdo zodpovědný za vytváření instance Payment a její spojení se Sale? (2) Varianta přiřazení zodpovědnosti třídě Sale. : Register : Sale makepayment() makepayment() create() : Payment UP - fáze rozpracování II (návrh) 95

96 High Cohesion kdy nepoužít, přínos Někdy je oprávněné akceptovat nižší kohezi (např. soustředit zodpovědnost do jedné třídy z důvodu údržby, např. znalost SQL pro mapování na databázi). Přínos: Srozumitelnost, lepší udržovatelnost, zpravidla nízká vazba. UP - fáze rozpracování II (návrh) 96

97 Další principy a shrnutí Viz Larman str UP - fáze rozpracování II (návrh) 97

98 Další principy a shrnutí UP - fáze rozpracování II (návrh) 98

99 Další principy a shrnutí UP - fáze rozpracování II (návrh) 99

100 Příklad použití GRASP při realizaci makenewsale (1) Kontrakt systémové operace UP - fáze rozpracování II (návrh) 100

101 Příklad použití GRASP při realizaci makenewsale (2) Volba třídy řadiče je pouze několik systémových operací. :Register makenewsale create :Sale UP - fáze rozpracování II (návrh) 101

102 Příklad použití GRASP při realizaci makenewsale (3) Vytvoření instance třídy Sale. by Creator and Controller makenewsale :Register create Register creates a Sale by Creator :Sale by Creator, Sale creates an empty collection (such as a List) which will eventually hold SalesLineItem instances create lineitems : List<SalesLineItem> this execution specification is implied to be within the constructor of the Sale instance UP - fáze rozpracování II (návrh) 102

103 Případová studie CD vrstvy domény pro 1.iteraci Store address : Address name : Text addcompletesale() 1 catalog catalog 1 ProductCatalog getproductdesc() descriptions {Map} 1..* ProductDescription description : Text price : Money itemid: ItemID register 1 Register endsale() enteritem() makenewsale() makepayment() currentsale 1 completedsales {ordered} Sale iscomplete : Boolean time : DateTime becomecomplete() makelineitem() makepayment() gettotal() * lineitems {ordered} payment 1 1..* SalesLineItem quantity : Integer getsubtotal() Payment amount : Money description 1 UP - fáze rozpracování II (návrh) 103

104 Případová studie navázání na vrstvu UI (1) presses button Cashier actionperformed( actionevent ) UI Layer :ProcessSale JFrame 1: enteritem(id, qty) system event Domain Layer :Register UP - fáze rozpracování II (návrh) 104

105 Případová studie navázání na vrstvu UI (2) Chceme zobrazit celkový součet po každé položce (gettotal). Odkud volat? Register: + nízká vazba vrstvy domény na UI - růst rozhraní třídy Register pokles koheze. třída UI: - zvyšuje vazbu vrstvy UI a domény + je-li Sale stabilní, pak nevadí UP - fáze rozpracování II (návrh) 105

106 Případová studie navázání na vrstvu UI (3) presses button Cashier actionperformed( actionevent ) UI Layer :ProcessSale JFrame 3: t = gettotal 1: enteritem(id, qty) 2 [no sale] : s = getsale : Sale Domain Layer :Register s : Sale UP - fáze rozpracování II (návrh) 106

107 Obsah Logická architektura Závislosti balíčků Architektonické vzory OO návrh - úvod OO návrh - modelovací techniky UML OO návrh principy návrhu GRASP OO návrh návrhové vzory Návrh viditelnosti objektů Programování Návrh řízený testem a refaktorizace UP - fáze rozpracování II (návrh) 107

108 Podstata a historie návrhových vzorů Osvědčená řešení často se vyskytujících problémů OO návrhu. Popsány strukturovaně katalog. Historie: Počátky v polovině 80. let (K.Beck) 1994: Gamma, Helm, Johnson, Vlissides (GoF) : Design Patterns - kniha s 23 návrhovými vzory ( bible návrhových vzorů). Další: Fowler, Larman (GRASP - General Responsibility Assignment Software Patterns), UP - fáze rozpracování II (návrh) 108

109 Adapter (GoF) Problém: Jak vyřešit nekompatibilní rozhraní nebo poskytnout stabilní rozhraní pro podobné komponenty s různými rozhraními. Řešení: Převést původní rozhraní komponent na jiné rozhraní prostřednictvím pomocného objektu adaptoru. UP - fáze rozpracování II (návrh) 109

110 «interface» ITaxCalculatorAdapter gettaxes( Sale ) : List of TaxLineItems Adapters use interfaces and polymorphism to add a level of indirection to varying APIs in other components. TaxMasterAdapter GoodAsGoldTaxPro Adapter gettaxes( Sale ) : List of TaxLineItems gettaxes( Sale ) : List of TaxLineItems «interface» IAccountingAdapter postreceivable( CreditPayment ) postsale( Sale ) «interface» ICreditAuthorizationService Adapter requestapproval(creditpayment,terminalid, MerchantID) SAPAccountingAdapter GreatNorthernAccountingAdapter «interface» IInventoryAdapter postreceivable( CreditPayment ) postsale( Sale ) postreceivable( CreditPayment ) postsale( Sale ) UP - fáze rozpracování II (návrh) 110

111 Použití vzoru Adapter :Register : SAPAccountingAdapter makepayment SOAP over HTTP postsale( sale ) xxx «actor» : SAPSystem the Adapter adapts to interfaces in other components UP - fáze rozpracování II (návrh) 111

112 Factory (Simple/Concrete) Problém: Kdo by měl být zodpovědný za vytváření objektů, když jde o složitou logiku vytvoření nebo je snaha oddělit zodpovědnost za vytvoření kvůli lepší kohezi atd. Řešení: Vytvořit specielní objekt zodpovědný za vytvoření. UP - fáze rozpracování II (návrh) 112

113 ServicesFactory accountingadapter : IAccountingAdapter inventoryadapter : IInventoryAdapter taxcalculatoradapter : ITaxCalculatorAdapter note that the factory methods return objects typed to an interface rather than a class, so that the factory can return any implementation of the interface getaccountingadapter() : IAccountingAdapter getinventoryadapter() : IInventoryAdapter gettaxcalculatoradapter() : ITaxCalculatorAdapter if ( taxcalculatoradapter == null ) { // a reflective or data-driven approach to finding the right class: read it from an // external property String classname = System.getProperty( "taxcalculator.class.name" ); taxcalculatoradapter = (ITaxCalculatorAdapter) Class.forName( classname ).newinstance(); } return taxcalculatoradapter; UP - fáze rozpracování II (návrh) 113

114 Singleton (GoF) Problém: Může existovat jen jedna instance, tj. tzv. singleton. Objekty potřebují globální a jediný bod přístupu. Řešení: Definovat statickou metodu třídy, která vrátí singleton. UP - fáze rozpracování II (návrh) 114

115 UML notation: this '1' can optionally be used to indicate that only one instance will be created (a singleton) ServicesFactory 1 UML notation: in a class box, an underlined attribute or method indicates a static (class level) member, rather than an instance member instance : ServicesFactory accountingadapter : IAccountingAdapter inventoryadapter : IInventoryAdapter taxcalculatoradapter : ITaxCalculatorAdapter getinstance() : ServicesFactory getaccountingadapter() : IAccountingAdapter getinventoryadapter() : IInventoryAdapter gettaxcalculatoradapter() : ITaxCalculatorAdapter singleton static attribute singleton static method // static method public static synchronized ServicesFactory getinstance() { if ( instance == null ) instance = new ServicesFactory() return instance } UP - fáze rozpracování II (návrh) 115

116 Abstract Factory (GoF) - motivace Domain Sales JavaPOS Register Sale «interface» jpos.cashdrawer «interface» jpos.coindispenser isdraweropened() opendrawer() waitfordrawerclose( timeout ) dispensechange(amount) getdispenserstatus() UP - fáze rozpracování II (návrh) 116

117 Abstract Factory (GoF) Problém: Vytvořit rodiny souvisejících tříd, které implementují společné rozhraní. Řešení: Definovat rozhraní továrna (abstract factory) a definovat konkrétní třídu pro vytváření objektů pro každou třídu rodiny tříd. Případně vytvořit abstraktní třídu, která implementuje rozhraní továrny a poskytuje společné služby konkrétním továrnám, které je rozšiřují (varianta Abstract Class Abstract Factory). UP - fáze rozpracování II (návrh) 117

118 this is the Abstract Factory--an interface for creating a family of related objects «interface» IJavaPOSDevicesFactory getnewcashdrawer() : jpos.cashdrawer getnewcoindispenser() : jpos.coindispenser IBMJavaPOSDevicesFactory NCRJavaPOSDevicesFactory getnewcashdrawer() : jpos.cashdrawer getnewcoindispenser() : jpos.coindispenser getnewcashdrawer() : jpos.cashdrawer getnewcoindispenser() : jpos.coindispenser { return new com.ibm.pos.jpos.cashdrawer() } { return new com.ncr.posdevices.cashdrawer() } com.ibm.pos.jpos.cashdrawer isdraweropened() «interface» jpos.cashdrawer isdraweropened() com.ncr.posdevices.cashdrawer isdraweropened() UP - fáze rozpracování II (návrh) 118

119 // THIS METHOD IS THE USEFUL TRICK public static synchronized IJavaPOSDevicesFactory getinstance() { if ( instance == null ) { String factoryclassname = System.getProperty("jposfactory.classname"); Class c = Class.forName( factoryclassname ); instance = (IJavaPOSDevicesFactory) c.newinstance(); } return instance; } italics indicate abstract methods & abstract class subclassing an abstract superclass «interface» IJavaPOSDevicesFactory getnewcashdrawer() : jpos.cashdrawer getnewcoindispenser() : jpos.coindispenser JavaPOSDevicesFactory instance : IJavaPOSDevicesFactory getinstance() : IJavaPOSDevicesFactory getnewcashdrawer() : jpos.cashdrawer getnewcoindispenser() : jpos.coindispenser 1 1 IBMJavaPOSDevicesFactory 1 NCRJavaPOSDevicesFactory 1 getnewcashdrawer() : jpos.cashdrawer getnewcoindispenser() : jpos.coindispenser getnewcashdrawer() getnewcoindispenser() { return new com.ibm.pos.jpos.coindispenser() } { return new com.ncr.posdevices.coindispenser() } UP - fáze rozpracování II (návrh) 119

120 Strategy Problém: Jak navrhnout řešení pro lišící se, ale související algoritmy/postupy? Řešení: Navrhnout samostatnou třídu pro každý algoritmus/postup se společným rozhraním. UP - fáze rozpracování II (návrh) 120

121 «interface» ISalePricingStrategy gettotal( Sale ) : Money PercentDiscount PricingStrategy percentage : float gettotal( s:sale ) : Money AbsoluteDiscount OverThreshold PricingStrategy discount : Money threshold : Money gettotal( s:sale ) : Money??? PricingStrategy { return s.getprediscounttotal() * percentage } { pdt := s.getprediscounttotal() if ( pdt < threshold ) return pdt else return pdt - discount } UP - fáze rozpracování II (návrh) 121

122 s : Sale lineitems[ i ] : SalesLineItem :PercentDiscount PricingStrategy t = gettotal loop st = getsubtotal { t = pdt * percentage } t = gettotal( s ) pdt = getprediscounttotal note that the Sale s is passed to the Strategy so that it has parameter visibility to it for further collaboration UP - fáze rozpracování II (návrh) 122

123 Composite Problém: Jak zpracovat skupinu nebo složenou strukturu objektů stejně (polymorfně), jako by byly atomickým objektem? Řešení: Vytvořit třídu pro kompozit a atomické objekty tak, aby implementovaly totéž rozhraní. UP - fáze rozpracování II (návrh) 123

124 { return pricingstrategy.gettotal( this ) } All composites maintain a list of contained strategies. Therefore, define a common superclass CompositePricingStrategy that defines this list (named strategies). Sale date gettotal() 1 pricingstrategy «interface» ISalePricingStrategy gettotal( Sale ) : Money 1..* strategies PercentageDiscount PricingStrategy percentage : float gettotal( Sale ) : Money AbsoluteDiscount OverThreshold PricingStrategy discount : Money threshold : Money gettotal( Sale ) : Money Composite PricingStrategy add( ISalePricingStrategy ) gettotal( Sale ) : Money { return sale.getprediscounttotal() * percentage } CompositeBestForCustomer PricingStrategy gettotal( Sale ) : Money CompositeBestForStore PricingStrategy gettotal( Sale ) : Money { lowesttotal = INTEGER.MAX for each ISalePricingStrategy strat in pricingstrategies { total := strat.gettotal( sale ) lowesttotal = min( total, lowesttotal ) } return lowesttotal } UP - fáze rozpracování II (návrh) 124

125 UML: ISalePricingStrategy is an interface, not a class; this is the way in UML 2 to indicate an object of an unknown class, but that implements this interface s : Sale lineitems[ i ] : SalesLineItem :CompositeBestForCustomer PricingStrategy strategies[ j ] : : ISalePricingStrategy t = gettotal loop st = getsubtotal t = gettotal( s ) { t = min(set of all x) } loop x = gettotal( s ) the Sale object treats a Composite Strategy that contains other strategies just like any other ISalePricingStrategy UP - fáze rozpracování II (návrh) 125

126 Facade Problém: Požaduje se společné sjednocující rozhraní množiny nesourodých implementací nebo rozhraní, např. podsystému. Může existovat nežádoucí propojení prvků podsystému nebo když se implementace podsystému může změnit. Řešení: Definovat bod kontaktu s podsystémem - objekt fasáda, který zabalí podsystém. Tento objekt je jediným sjednocujícím rozhraním a je zodpovědný za spolupráci s komponentami podsystému. UP - fáze rozpracování II (návrh) 126

127 Domain package name may be shown in the tab + Sale + Register visibility of the package element (to outside the package) can be shown by preceding the element name with a visibility symbol POSRuleEngine + POSRuleEngineFacade instance : RuleEngineFacade getinstance() : RuleEngineFacade * «interface» - IRule isinvalid( SalesLineItem, Sale ) isinvalid( Payment, Sale ) - Rule1 - Rule2 UP - fáze rozpracování II (návrh) 127

128 Observer (Publish - Subscribe) Problém: Různé druhy objektů odběratele se zajímají o změny stavu nebo události objektu vydavatele a chtějí reagovat svým způsobem na události generované uživatelem. Navíc vydavatel chce být málo vázán na odběratele. Řešení: Definovat rozhraní odběratele, které implementují konkrétní odběratelé. Vydavatel může dynamicky registrovat odběratele a uvědomuje je, když událost nastane. UP - fáze rozpracování II (návrh) 128

129 Goal: When the total of the sale changes, refresh the display with the new value total Sale settotal( newtotal ) UP - fáze rozpracování II (návrh) 129

130 { } for each PropertyListener pl in propertylisteners pl.onpropertyevent( this, name, value ); { } propertylisteners.add( lis ); Sale addpropertylistener( PropertyListener lis ) publishpropertyevent( name, value ) settotal( Money newtotal ) { } total = newtotal; publishpropertyevent( "sale.total", total ); javax.swing.jframe settitle() setvisible() propertylisteners «interface» PropertyListener onpropertyevent( source, name, value ) * { if ( name.equals("sale.total") ) saletextfield.settext( value.tostring() ); } SaleFrame1 onpropertyevent( source, name, value ) initialize( Sale sale ) { sale.addpropertylistener( this ) } UP - fáze rozpracování II (návrh) 130

131 sf : SaleFrame1 s : Sale propertylisteners : List<PropertyListener> initialize( s : Sale ) addpropertylistener( sf ) add( sf ) UP - fáze rozpracování II (návrh) 131

132 s :Sale propertylisteners[ i ] : PropertyListener settotal( total ) loop publishpropertyevent ( "sale.total", total ) onpropertyevent( s, "sale.total", total ) UP - fáze rozpracování II (návrh) 132

133 Since this is a polymorphic operation implemented by this class, show a new interaction diagram that starts with this polymorphic version : SaleFrame1 saletextfield : JTextField onpropertyevent( source, name, value ) settext( value.tostring() ) UML notation: Note this little expression within the parameter. This is legal and consise. UP - fáze rozpracování II (návrh) 133

134 { } for each AlarmListener al in alarmlisteners al.onalarmevent( this, time ); { } alarmlisteners.add( lis ); AlarmClock addalarmnlistener( AlarmListener lis ) publishalarmevent( time ) javax.swing.jframe settitle() setvisible() settime( newtime ) alarmlisteners * «interface» AlarmListener onalarmevent( source, time ) { } time = newtime; if ( time == alarmtime ) publishalarmevent( time ); AlarmWindow Beeper ReliabilityWatchDog onalarmevent( source, time ) { display notification dialog box } onalarmevent( source, time ) { beep } onalarmevent( source, time ) { check that all required processes are executing normally } UP - fáze rozpracování II (návrh) 134

135 presentation PWindow displaycontact() control CActioner retrievecontact() entity mediator foundation EConta ct <<insta ntiate >> MBroker FReader retrievecontact() retrievecontact() UP - fáze rozpracování II (návrh) 135

136 Obsah Logická architektura Závislosti balíčků Architektonické vzory OO návrh - úvod OO návrh - modelovací techniky UML OO návrh principy návrhu GRASP OO návrh návrhové vzory Návrh viditelnosti objektů Programování Návrh řízený testem a refaktorizace UP - fáze rozpracování II (návrh) 136

137 Viditelnost mezi objekty Schopnost jednoho objektu vidět (mít referenci) na jiný objekt. class Register { private ProductCatalog catalog; } Tak ví o příjemci ( vidí ho ) enteritem (itemid, quantity) : Register desc = getproductdesc( itemid ) : ProductCatalog public void enteritem( itemid, qty ) { desc = catalog.getproductdesc(itemid) } Tak viditelnost použije UP - fáze rozpracování II (návrh) 137

138 Způsoby dosažení viditelnosti Viditelnost atributu B je atributem A. Viditelnost parametru B je parametrem operace/metody A. Lokální viditelnost B je lokálním objektem (ne parametrem) metody A. Globální viditelnost B je nějakým způsobem viditelná globálně. UP - fáze rozpracování II (návrh) 138

139 Viditelnost atributu class Register { private ProductCatalog catalog; } public void enteritem(itemid, qty) { desc = catalog.getproductdesc(itemid) } enteritem (itemid, quantity) : Register desc = getproductdesc( itemid ) : ProductCatalog UP - fáze rozpracování II (návrh) 139

140 Viditelnost parametru enteritem(id, qty) :Register 2: makelineitem(desc, qty) :Sale 1: desc = getproductdesc(id) 2.1: create(desc, qty) :Product Catalog makelineitem(productdescription desc, int qty) { sl = new SalesLineItem(desc, qty); } sl : SalesLineItem UP - fáze rozpracování II (návrh) 140

141 Viditelnost parametru na atribut enteritem(id, qty) :Register 2: makelineitem(desc, qty) :Sale 2: desc = getproductdesc(id) 2.1: create(desc, qty) :Product Catalog // initializing method (e.g., a Java constructor) SalesLineItem(ProductDescription desc, int qty) { description = desc; // parameter to attribute visibility } sl : SalesLineItem UP - fáze rozpracování II (návrh) 141

142 Lokální viditelnost vytvoření lokální instance a přiřazení do lokální proměnné přiřazení vráceného objektu lokální proměnné enteritem(id, qty) { // local visibility via assignment of returning object ProductDescription desc = catalog.getproductdes(id); } enteritem (itemid, quantity) : Register desc = getproductdesc( itemid ) : ProductCatalog UP - fáze rozpracování II (návrh) 142

143 Globální viditelnost Globální viditelnost z A k B značí, že B je globální vzhledem k A. Způsoby dosažení: dosazení do globální proměnné (C++) použití návrhového vzoru Singleton UP - fáze rozpracování II (návrh) 143

144 Obsah Logická architektura Závislosti balíčků Architektonické vzory OO návrh - úvod OO návrh - modelovací techniky UML OO návrh principy návrhu GRASP OO návrh návrhové vzory Návrh viditelnosti objektů Programování Návrh řízený testem a refaktorizace UP - fáze rozpracování II (návrh) 144

145 Mapování modelu návrhu na model CD návrhu d. interakce implementace PROGRAMOVÁNÍ zdrojový kód, SQL skript pro vytvoření DB, JSP, HTML stránky, Programování není mechanický přepis modelu návrhu. Typicky neúplný, během programování a testování je třeba udělat řadu změn, zjistí se a řeší problémy. návrhový model základem důležitým pro pochopení a řešení problémů zjištěných při programování. UP - fáze rozpracování II (návrh) 145

146 Vytvoření definic tříd z diagramu tříd public class SalesLineItem { private int quantity; private ProductDescription description; public SalesLineItem(ProductDescription desc, int qty) { } public Money getsubtotal() { } } SalesLineItem quantity : Integer getsubtotal() : Money description 1 ProductDescription description : Text price : Money itemid : ItemID UP - fáze rozpracování II (návrh) 146

147 Vytvoření metod z diagramů interakce 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> UP - fáze rozpracování II (návrh) 147

148 Př) třída Register public class Register { private ProductCatalog catalog; private Sale currentsale; public Register(ProductCatalog pc) {} public void endsale() {} public void enteritem(itemid id, int qty) {} public void makenewsale() {} public void makepayment(money cashtendered) {} } catalog 1 ProductCatalog getproductdesc() Register endsale() enteritem(id: ItemID, qty : Integer) makenewsale() makepayment(cashtendered : Money) currentsale 1 Sale iscomplete : Boolean time : DateTime becomecomplete() makelineitem() makepayment() gettotal() UP - fáze rozpracování II (návrh) 148

149 Př) metoda Register.enterItem { } ProductDescription desc = catalog.productdescription(id); currentsale.makelineitem(desc, qty); enteritem(id, qty) :Register 2: makelineitem(desc, qty) :Sale 1: desc := getproductdescription(id) :Product Catalog UP - fáze rozpracování II (návrh) 149

150 Kolekce v kódu Implementace asociací s násobností * Zpravidla několik typů kolekcí (pole, seznam, ) public class Sale { private List lineitems = new ArrayList(); } Sale iscomplete : Boolean time : DateTime becomecomplete() makelineitem() makepayment() getttotal() lineitems 1..* SalesLineItem quantity : Integer getsubtotal() Doporučení: implementuje-li třída rozhraní, deklaruj třídu z hlediska rozhraní (tedy ne ArrayList) A collection class is necessary to maintain attribute visibility to all the SalesLineItems. UP - fáze rozpracování II (návrh) 150

151 Př) metoda Sale.makeLineItem { } lineitems.add( new SalesLineItem(desc, qty) ); enteritem(id, qty) :Register 2: makelineitem(desc, qty) :Sale 2.2: add(sl) 2.1: create(desc, qty) lineitems : List<SalesLineItem> sl: SalesLineItem UP - fáze rozpracování II (návrh) 151

152 Pořadí implementace Store 7 address : Address name : Text addsale() 1 1 ProductCatalog getproductdesc() 3 1..* ProductDescription description : Text price : Money itemid : ItemID 2 1 Register endsale() enteritem() makenewsale() makepayment() 6 1 Sale iscomplete : Boolean time : DateTime becomecomplete() makelineitem() makepayment() gettotal() * 5 SalesLineItem quantity : Integer getsubtotal() Payment amount : Money UP - fáze rozpracování II (návrh) * 1 1 4

153 Obsah Logická architektura Závislosti balíčků Architektonické vzory OO návrh - úvod OO návrh - modelovací techniky UML OO návrh principy návrhu GRASP OO návrh návrhové vzory Návrh viditelnosti objektů Programování Návrh řízený testem a refaktorizace UP - fáze rozpracování II (návrh) 153

154 Podstata vývoje řízeného testem (TDD) Praxe prosazovaná iterativními a agilními metodami, aplikovatelná rovněž u UP. Také označovaná jako vývoj principem nejprve testuj (test-first development). Podstata: Nejprve se napíše test a teprve potom se implementuje to, co se testuje. UP - fáze rozpracování II (návrh) 154

155 Výhody TDD Jednotkové testy se skutečně napíší. Uspokojení programátorů vede ke psaní konzistentnějších testů. Ujasnění si detailního rozhraní a chování. Prokazatelná, opakovatelná automatizovaná verifikace. Důvěra v provádění změn. Podpora TDD rámce pro jednotkové testování (xunit JUnit,NUnit,CppUnit, ). UP - fáze rozpracování II (návrh) 155

156 Př)Ilustrace TDD při vytváření třídy Sale (1) Před programováním třídy Sale naprogramujeme testovací metodu pro testovací případ ve třídě SaleTest: 1. Vytvoření instance Sale (tzv. přípravek (fixture)). 2. Přidání několika položek prodeje pomocí metody makelineitem (tu chceme testovat). 3. Zjištění celkové částky prodeje (použitím gettotal a asserttrue) UP - fáze rozpracování II (návrh) 156

157 Př)Ilustrace TDD při vytváření třídy Sale (2) UP - fáze rozpracování II (návrh) 157

158 Př)Ilustrace TDD při vytváření třídy Sale (3) UP - fáze rozpracování II (návrh) 158

159 Př)Ilustrace TDD při vytváření třídy Sale (4) UP - fáze rozpracování II (návrh) 159

160 Obecný postup TDD při implementaci třídy 1. Vytvoř testovací třídu. 2. Vytvoř přípravek testované třídy. 3. do 1. Vytvoř testovací metodu: 1. Aplikuj metodu, kterou testuješ. 2. Ověř očekávané výsledky. 2. Implementuj testovanou metodu. 3. while implementace vykazuje chyby do 1. Uprav implementaci until implementace třídy je úplná UP - fáze rozpracování II (návrh) 160

161 Integrace do IDE (př.junit v Eclipse) Zelený pruh, až projdou testy UP - fáze rozpracování II (návrh) 161

162 Podstata refaktorizace (refactoring) Disciplinovaná metoda přepisu nebo restrukturalizace existujícího kódu beze změny vnějšího chování, aplikace malých transformací kombinovaných s opakovaným spouštěním testů. Vede ke snadnějšímu pochopení kódu a usnadnění dalších úprav Soustavná refaktorizace kódu je opět běžná metoda XP a je aplikovatelná na každou iterativní metodu vývoje. UP - fáze rozpracování II (návrh) 162

163 Aktivity a cíle refaktorizace Odstranění duplicitního kódu Zvýšení srozumitelnosti Zkrácení dlouhých metod Odstranění natvrdo kódovaných literálových konstant Tzv. pachy v kódu (code smells): duplicitní kód rozsáhlé metody třída s mnoha atributy nápadně podobné podtřídy silné provázání (coupling) mnoha objektů UP - fáze rozpracování II (návrh) 163

164 Příklady typů faktorizace Typ/Vzor Extract Method Extract Constant Introduce Explaining Variable Replace Constructor Call with Factory Method Popis Transformuj dlouhou metodu na kratší vyčleněním logické části do privátní pomocné metody. Nahraď literálovou konstantu konstantní proměnnou. Ulož výsledek výrazu nebo části výrazu do přechodné proměnné se jménem vysvětlujícím smysl V Javě se nahradí použití new a konstruktoru voláním pomocné metody, která skryje detaily vytvoření. Viz UP - fáze rozpracování II (návrh) 164

165 void printowing() { printbanner(); Př) Extract Method } //print details System.out.println ("name: " + _name); System.out.println ("amount " + getoutstanding()); void printowing() { printbanner(); printdetails(getoutstanding()); } void printdetails (double outstanding) { System.out.println ("name: " + _name); System.out.println ("amount " + outstanding); } UP - fáze rozpracování II (návrh) 165

166 Př) Introduce Explaining Variable // good method name, but the logic of the body is not clear boolean isleapyear( int year ) { return ( ( ( year % 400 ) == 0 ) ( ( ( year % 4 ) == 0 ) && ( ( year % 100 )!= 0 ) ) ); } // that s better! boolean isleapyear( int year ) { boolean isfourthyear = ( ( year % 4 ) == 0 ); boolean ishundrethyear = ( ( year % 100 ) == 0); boolean is4hundrethyear = ( ( year % 400 ) == 0); return ( is4hundrethyear ( isfourthyear &&! ishundrethyear ) ); } UP - fáze rozpracování II (návrh) 166

167 Př) Replace Constructor with Factory Method Employee (int type) { _type = type; } static Employee create(int type) { return new Employee(type); } UP - fáze rozpracování II (návrh) 167

168 Proč refaktorizujeme (M. Fowler) Refaktorizujeme proto, abychom zlepšili návrh software. Refaktorizace vede k lepší srozumitelnosti software. Refaktorizace pomáhá hledat chyby - lepší pochopení kódu při refaktorizaci. (K.Beck: Nejsem skvělý programátor, jsem pouze dobrý programátor se skvělými návyky. ) UP - fáze rozpracování II (návrh) 168

169 Kdy refaktorizujeme (M. Fowler) (1) Refaktorizujeme místo třetího opakování ( Poprvé to prostě uděláš, podruhé se rozmýšlíš kvůli duplicitě, ale uděláš to, ale potřetí bys měl refaktorizovatat. ) Refaktorizujte před přidáním funkcionality (nejčastější případ refaktorizace). Refaktorizujte při opravách chyb (lepší pochopení kódu) a při revizi kódu. UP - fáze rozpracování II (návrh) 169

170 Některé užitečné zásady (M. Fowler) (1) Když zjistíte, že do programu musíte přidat novou funkci a přitom jeho struktura k tomu není vhodná, nejprve v programu refaktorizujte tak, aby přidání funkce bylo snadné a teprve pak funkci přidejte. Než začnete refaktorizovat, zkontrolujte, jestli máte kvalitní sadu testů, které se samy vyhodnocují. UP - fáze rozpracování II (návrh) 170

171 Některé užitečné zásady (M. Fowler) (2) Refaktorizace mění programy po malých krocích. Pokud se spletete, je jednoduché chybu najít. Kód, kterému rozumí počítač, dokáže napsat každý. Dobří programátoři píší kód, kterému rozumí lidé. UP - fáze rozpracování II (návrh) 171

172 Problémy s refaktorizací Jednou z problematických oblastí jsou databáze (většina podnikových aplikací je těsně spojena se strukturou databáze, navíc problémy s nutností migrace dat při změně struktury). Řešení u neobjektových databází: vrstva oddělující databázový a objektový model (při změně nutno aktualizovat jen oddělující vrstvu). UP - fáze rozpracování II (návrh) 172

173 Podpora refaktorizace v IDE (Eclipse) (1) UP - fáze rozpracování II (návrh) 173