1 Projektowanie oprogramowaniaInżynieria oprogramowania Wykład 6 Projektowanie oprogramowania Bartosz Walter
2 Agenda Czy oprogramowanie jest zawsze projektowane? Znaczenie projektowania Projektowanie a wyniki fazy analizy Składowe projektowania
3 Zadania w fazie projektowaniaUszczegółowienie wyników analizy Projektowanie technicznych składowych oprogramowania innych niż składowa dziedziny problemu Poprawa efektywności systemu Definicja architektury systemu Wybór technologii
4 Uszczegółowienie wyników analizyDopracowanie diagramu klas Opracowanie diagramów sekwencji Wprowadzenie związków skierowanych Określenie sposobu implementacji związków Dobór typów danych Opracowanie sygnatur metod Określenie algorytmów metod
5 Kryteria jakości projektu obiektowegoModularność Wysoka spójność Słabe sprzężenia Prostota hierarchii dziedziczenia Prostota klas i obiektów Prostota protokołów i usług Przejrzystość Nazewnictwo – proste, spójne, precyzyjne Złożoność składowych
6 Spójność obiektowa Obiekt jest spójny jeżeli wszystkie jego składowe służą do realizacji jednego celu Spójność mierzy się stopniem wykorzystania pól obiektu przez jego własne metody Celem jest sytuacja, w której odwołania do pól występują jedynie z metod danej klasy lub jej podklasy
7
8
9 Sprzężenie Zrozumienie jednej składowej nie powinno prawie nigdy wymagać zrozumienia innych składowych Sprzężenie między dwoma klasami/obiektami opisuje zależność pomiędzy nimi. Klasa A jest powiązana z klasą B, jeżeli A musi posiadać pewną wiedzę o B: jako jej pole składowe, jako implementacja interfejsu, jako podklasa, jako parametr, typ metody albo wyjątek.
10
11
12 Projektowanie składowych technicznychSkładowe techniczne mogą być projektowane jak składowa dziedziny problemy, czyli Rzeczywistość Model Projekt W odróżnieniu od dziedziny problemu, składowe techniczne są powtarzalne Dlatego stosuje się Gotowe biblioteki Generatory kodu Wzorce architektoniczne Wzorce projektowe Zasady tworzenia interfejsu użytkownika
13 Projektowanie składowej interfejsu użytkownikaKlasyfikacja ludzi kim są użytkownicy systemu Opis scenariuszy ich zadań czego oczekują od systemu, kim są? Hierarchia poleceń zasada 7± 2 albo 3 x 3 Projektowanie szczegółowej interakcji minimalizacja kliknięć i przyciśnięć klawisza brak "ciszy w eterze" Prototypy użytkownik vs. prototyp
14
15 Projektowanie składowej zarządzania danymiFizyczna struktura serwerów danych Mechanizm dostępu do danych Dokumenty vs. pojedyncze dane Bazy danych vs. pliki Stopień dekompozycji danych Zapis na bieżąco vs. zapis na żądanie Kwestie optymalizacyjne (indeksy, partycjonowanie)
16
17
18 Wzorce projektowe "Wzorzec opisuje problem, który pojawia się wielokrotnie w danym środowisku, i opisuje podstawę rozwiązania tego problemu, w taki sposób, że można użyć tego rozwiązania milion razy, bez konieczności ponownego wykonywania tych samych czynności" Christopher Alexander "A Pattern Language", 1977
19 Wzorce w budownictwie lądowymCzy zbudujemy most, opierając przęsło na kolejnych filarach połączonych łukiem, tak aby łuk usztywniał i naciągał przęsło stanowiąc jego podparcie na całej długości przęsła, czy też mocując płyty z obu stron za pomocą kilku lin stalowych o kolejno coraz krótszych długościach do pylonów umieszczonych pośrodku długości mostu?
20 Wzorce w budownictwie lądowymCzy zbudujemy most łukowy czy podwieszany?
21 Wzorzec Atrybuty wzorca jak? kiedy? zyski/straty? kontekst?alternatywy? warunki wstępne?
22 Wzorce w inżynierii oprogramowania"Wzorzec projektowy identyfikuje i specyfikuje pewną abstrakcję, której poziom znajduje się powyżej poziomu abstrakcji pojedynczej klasy, instancji lub komponentu" E. Gamma et al., 1993
23 Systematyka wzorców projektowychKreacyjne abstract the instantiation process make the system independent of how the objects are created Strukturalne how the classes are composed use inheritance or composition appropriately Behawioralne deal with algorithms and assignment of responsibilities characterize control flow & interaction
24 Observer: Cel Zdefiniowanie pomiędzy obiektami zależności jeden-do-wielu, dzięki której jeżeli jeden (nadrzędny) obiekt zmieni stan, pozostałe także zostaną o tym powiadomione i zaktualizowane
25 Observer: Struktura
26 Observer: Uczestnicy Subject Observer Concrete Subjectzna swoje obserwatory posiada interfejs pozwalający dołączać i odłączać obserwatory Observer definiuje ogólny interfejs dla obserwatorów Concrete Subject przechowuje stan, który obserwują obserwatory wysyła powiadomienia do obserwatorów Concrete Observer dołącza i odłącza siebie do/od obiektu obserwowanego aktualizuje swój stan przy zmianach w obiekcie obserwowanym
27 Observer: Konsekwencjeułatwione utrzymanie spójności systemu abstrakcyjne powiązanie pomiędzy obiektami Subject i Observer Subject posiada znikomą wiedzę o swoich obserwatorach Subject i obserwatory mogą należeć do różnych warstw aplikacji programowy broadcasting skalowalność aktualizacji obserwatorów push: obserwatory otrzymują pełną informację o zmianie (czy jej potrzebują, czy nie) pull: obserwatory otrzymują tylko powiadomienie i muszą zapytać Subject o szczegóły "wiszące" referencje po stronie obiektu obserwowanego (rozwiązanie w Javie: "słabe" referencje)
28 Observer: Przykład Rachunek klienta może być powiązany z innymi rachunkami pobocznymi. Na przykład, z głównym rachunkiem jest związany rachunek kredytu odnawialnego. Wysokość otwartej linii kredytowej zależy od środków na rachunku głównym. Zmiana wysokości salda na tym rachunku skutkuje podwyższeniem lub obniżeniem dostępnej kwoty kredytu.
29 Factory Method: Cel Zdefiniowanie interfejsu do tworzenia obiektu Odsunięcie tworzenia obiektów określonej klasy do podklas Podklasy decydują której klasy i którego konstruktora użyć do utworzenia obiektu produktu.
30 Factory Method: ZastosowanieKlient nie może przewidzieć, jakiej klasy obiekt należy utworzyć Klasa chce, aby jej podklasy określały jaki obiekt utworzyć; w tym celu przekazuje im część swojej odpowiedzialności
31 Factory Method: Strukturaby the Gang of Four
32 Factory Method: UczestnicyProduct deklaruje interfejs dla obiektów utworzonych przez Factory Method ConcreteProduct implementuje interfejs Product Creator deklaruje interfejs dla metody fabryki obiektów typu Product może posiadać domyślną implementację metody fabryki ConcreteCreator pokrywa metodę fabrykę, tak aby zwracała obiekt Concrete Product
33 Factory Method: Konsekwencjeprzesunięcie akcentu na podklasy podklasy w ich metodach fabrykach mogą tworzyć zmienioną lub rozszerzoną wersję produktu parametryzowane FM vs. polimorficzne FM Creator może wybrać obiekt, który chce utworzyć, lub przekazać tę odpowiedzialność do podklas dwa poziomy wyboru: podklasy, która utworzy specyficzny produkt, oraz konstruktora wewnątrz podklasy
34 Factory Method: PrzykładW zależności od wybranego sposobu drukowania wyciągów, są one tworzone codziennie, cotygodniowo lub comiesięcznie. Każdy z nich jest reprezentowany przez oddzielny obiekt.
35 Chain of Responsibility: CelUniknięcie wiązania nadawcy żądania z jego odbiorcom poprzez utworzenie grupy potencjalnych odbiorców, którzy mogą obsłużyć żądanie Odbiorcy są ułożeni w łańcuch i przekazują sobie żądanie wzdłuż łańcucha aż jeden z nich obsłuży je.
36 Chain of Responsibility: Structureby the Gang of Four
37 Chain of Responsibility: ParticipantsHandler defines an interface for handling requests (optional) implements the successor link Concrete Handler handles requests it is responsible for can access its successor if the ConcreteHandler can handle the request, it does so; otherwise it forwards the request to its successor Client initiates the request to a ConcreteHandler object on the chain by the Gang of Four
38 Chain of Responsibility: ConsequencesChain of Responsibility allows for: reduced coupling Object does not need to know which other object handles the request both Sender and Receiver have no knowledge of each other chain elements do not know the chain's structure added flexibility in assigning responsibilities to objects responsibilities can be freely distributed among chain elements no guarantee of receipt by the Gang of Four
39 Chain of Responsibility: Przykład 1
40 Chain of Responsibility: Przykład 1
41 Chain of Responsibility: Przykład 2
42 Chain of Responsibility: Przykład 2
43 State: Cel Umożliwienie obiektowi zmiany jego zachowania w odpowiedzi na zmianę jego wewnętrznego stanu. Obiekt będzie pozornie zmieniał swoją klasę.
44 State: Zastosowanie Zachowanie obiektu zależy od jego stanu i podlega zmianom w trakcie wykonywania programu Wewnątrz metody istnieją złożone, wieloczęściowe wyrażenia warunkowe, które zależą od stanu obiektu Każdy stan jest oddzielnym obiektem, który może zmieniać się niezależnie od innych obiektów
45 State: Struktura
46 Concrete State subclassesState: Uczestnicy Context defines the interface of interest to clients maintains an instance of a ConcreteState subclass that defines the current state State defines an interface for encapsulating the behavior associated with a particular state of the Context Concrete State subclasses each subclass implements a behavior associated with a state of the Context
47 partition of the behavior for different statesState: Konsewencje partition of the behavior for different states state-specific code lives in State subclasses intent of the state-dependent behavior is clearer explicit state transitions protection from inconsistent internal states possible sharing of state objects States are stateless
48 State: Przykład Rachunek może znajdować się w stanie otwartym lub zamkniętym. W stanie otwartym właściciel może dokonywać wpłat na rachunek, podczas gdy w stanie zamkniętym stan rachunku nie może ulec zmianie.
49 State: Przykład public class Account { private int balance = 0;private String owner = null; private boolean isOpen = false; public Account(String owner, int balance) { this.owner = owner; this.balance = balance; this.isOpen = true; } public void credit(int amount) { if (isOpen) { balance += amount; } else { alert("The account is closed!");
50 State: Przykład public interface AccountState {public void credit(Account acc, int amount); } public class AccountOpen implements AccountState { public void credit(Account acc, int amount) { acc.balance += amount; public class AccountClosed implements AccountState { alert("The account is closed!");
51 State: Przykład public class Account { private int balance = 0;private String owner = null; private AccountState state = null; public Account(String owner, int balance) { this.owner = owner; this.balance = balance; this.state = new AccountOpen(); } public void credit(int amount) { this.state.credit(this, amount); public void close() { this.state = new AccountClosed();
52 Decorator: Cel Umożliwienie dynamicznego dołączania odpowiedzialności do obiektu Dostarczenie elastycznej alternatywy dla dziedziczenia w celu rozszerzania funkcjonalności
53 Decorator: Problem public class Invoice { String buyer = null;String issuer = null; List
54 Decorator: Problem public class Invoice { String buyer = null;String issuer = null; List
55 Decorator: Problem
56 Decorator: Struktura
57 Decorator: UczestnicyComponent deklaruje interfejs dla obiektów, którym można zwiększyć zakres odpowiedzialności Concrete Component implementuje interfejs Component Decorator posiada interfejs zgodny z interfejsem Component jest świadom istnienia dekorowanego Componentu (który jest instancją Concrete Component lub innym Decoratorem) Concrete Decorator dodaje odpowiedzialność do komponentu
58 Decorator: Konsekwencjewiększa elastyczność niż w przypadku dziedziczenia odpowiedzielność może być zwiększana dynamicznie mniej złożona hierarchia klas pay-as-you-go poszczególne cechy są dodawane na żądanie różnica w tożsamości obiektów tożsamość obiektu jest inna od tożsamości dekoratora tożsamość obiektu powinna być hermetyzowana i ukryta przed klientem duża liczna małych, dobrze zdefiniowanych klas dekoratorów poprawiona testowalność
59 Decorator: Przykład
60 Flyweight: Cel Ponowne użycie i współdzielenie obiektów w celu zwiększenia efektywności ich wykorzystania Oddzielenie wewnętrznego (współdzielnonego) i zewnętrznego (unikatowego) stanu obiektu
61 Flyweight: Struktura
62 Flyweight: Uczestnicydeklaruje interfejs, przez który obiekty mogą otrzymywać swój stan zewnętrzny Concrete Flyweight musi być niezależny od swojego kontekstu (stanu zewnętrznego) Unshared Concrete Flyweight specjalny przypadek obiektu niewspółdzielnonego Flyweight Factory tworzy i zarządza obiektami Flyweight zapewnia poprawność procesu zarządzania obiektami Client otrzymuje instancje Flyweight poprzez FlyweightFactory
63 Flyweight: Konsekwencjerosnące oszczędności pamięci ograniczenie całkowitej liczby instancji ograniczenie współdzielonego stanu wewnętrznego stan zewnętrzny może być wyliczony lub zapamiętany wzrost kosztu obliczeniowego zarządzanie stanem zewnętrznym
64 Flyweight: Przykład public abstract class TeaOrder { // Flyweightpublic abstract void serveTea(TeaOrderContext teaOrderContext); } public class TeaFlavor extends TeaOrder { // ConcreteFlyweight String teaFlavor; // stan wewnętrzny TeaFlavor(String teaFlavor) { this.teaFlavor = teaFlavor; public String getFlavor() { return this.teaFlavor; // teaOrderContext jest zewnętrznym stanem public void serveTea(TeaOrderContext teaOrderContext) { System.out.println("Serving tea flavor " + teaFlavor + " to table number " + teaOrderContext.getTable());
65 Flyweight: Przykład public class TeaOrderCtx { // kontekst dostarcza stan zewnętrzny int tableNumber; TeaOrderContext(int tableNumber) { this.tableNumber = tableNumber; } public int getTable() { return this.tableNumber;
66 Flyweight: Przykład by Lawrence Trurettpublic class TeaFlavorFactory { // Flyweight Factory TeaFlavor[] flavors = new TeaFlavor[10];// <10 flavors can be made int teasMade = 0; // Factory Method public TeaFlavor getTeaFlavor(String flavorToGet) { for (int i = 0; i < teasMade; i++) { if (flavorToGet.equals((flavors[i]).getFlavor())) { return flavors[i]; } flavors[teasMade] = new TeaFlavor(flavorToGet); return flavors[teasMade++]; public int getTotalTeaFlavorsMade() { return teasMade; by Lawrence Trurett
67 Flyweight: Przykład class TestFlyweight {static TeaFlavor[] flavors = new TeaFlavor[100]; // zamówienia static TeaOrderCtx[] tables = new TeaOrderCtx[100]; // stoły static int ordersMade = 0; static TeaFlavorFactory teaFlavorFactory; static void takeOrders(String flavorIn, int table) { flavors[ordersMade] = teaFlavorFactory.getTeaFlavor(flavorIn); tables[ordersMade++] = new TeaOrderCtx(table); } public static void main(String[] args) { teaFlavorFactory = new TeaFlavorFactory(); takeOrders("chai", 2); takeOrders("camomile", 1); takeOrders("earl grey", 1); takeOrders("camomile", 897); for (int i = 0; i < ordersMade; i++) { flavors[i].serveTea(tables[i]); System.out.println(" "); System.out.println("total teaFlavor objects made: " + teaFlavorFactory.getTotalTeaFlavorsMade());
68 Command: Cel Hermetyzacja żądania jako obiektu Umożliwienie parametryzacji klientów różnymi żądaniami Wsparcie dla żądań odwracalnych
69 Command: Struktura
70 Command: Uczestnicy Command ConcreteCommand Client Invoker Receiverdeklaruje interfejs dla wykonywania zadania (execute()) ConcreteCommand definiuje powiązanie pomiędzy Receiverem i akcją implementuje metodę execute() Client tworzy obiekt ConcreteCommand i wskazuje jego odbiorcę (Receiver) Invoker wywołuje obiekt Command w celu wykonania żądania Receiver zna wykonawcę konkretnych żądań
71 Command: Konsekwencjeusunięcie powiązania nadawcy i odbiorcy (Receiver) obiekty Command mogą być składane w polecenia złożone dodawanie nowych obiektów Command jest łatwe Command można łatwo rozszerzyć o odwracanie ich działania
72 Command: Przykład
73 Command: Przykład public class Bank { // Invoker, Clientpublic void income(Account acc, long amount) { Operation oper = new Income(amount); acc.doOperation(oper); } public void transfer(Account from, Account to, long amount) { Operation oper = new Transfer(to, amount); from.doOperation(oper); public class Account { // Reciever long balance = 0; Interest interest = new InterestA(); History history = new History(); public void doOperation(Operation oper) { oper.execute(this); history.log(oper);
74 Command: Przykład abstract public class Operation { // Commandpublic void execute(); } public class Income { // ConcreteCommand1 public Income(long amount) { // store parameters... public void execute(Account acc) { acc.add(amount); public class Transfer { // ConcreteCommand2 public Income(Account to, long amount) { public void execute(Account from) { from.subtract(amount); to.add(amount);
75 Visitor: Cel Reprezentacja operacji, która ma być wykonana na elementach heterogenicznej struktury. Umożliwienie zdefiniowania nowej operacji bez zmiany samych elementów, na których ona operuje
76 Visitor: Struktura
77 Visitor: Uczestnicy Visitor Concrete Visitor Element Object Structuredeklaruje sposób realizacji operacji dla każdego ConcreteElement, który ma być odwiedzony Concrete Visitor implementuje konkretną operację Element definiuje metodę accept(), która otrzymuje obiekt Visitor jako parametr Object Structure zwraca pojedyncze elementy struktury może posiadać interfejs wysokiego poziomu który pozwala obiektom Visitor odwiedzać elementy
78 Visitor: Konsekwencjełatwe dodawanie nowych operacji (Visitorów) trudne dodawanie nowych elementów (ConcreteElements) każdy ConcreteElement wymaga stworzenie nowej metody we wszystkich istniejących Visitorach obsługa obiektów niezależna od ich klas inaczej niż Iterator, Visitor może odwiedzać obiektów różnych klas
79 Visitor: Konsekwencje (cd.)akumulacja stanu Visitory mogą akumulować stan odwiedzanych elementów w sposób dla nich specyficzny konieczność naruszenia hermetyzacji z uwagi na odwrócenie sterowania pomiędzy elementem a Visitorem, konieczne jest udostępnienie im nazwajem metod accept() i visit*()
80 Visitor: Przykład public class Bank {List
81 Visitor: Przykład public abstract class BankingProduct { }public interface Element { public BankingProduct accept(Report report); public class Account extends BankingProduct implements Element { public BankingProduct accept(Report report) { if (isPriviliged(report)) { return report.visit(this); return null; public class Credit extends BankingProduct implements Element {
82 Visitor: Przykład public class Over1000Report implements Visitor {public BankingProduct visit(Account acc) { if (acc.balance > 1000) return this; return null; } public BankingProduct visit(Credit credit) { if (credit.draft > 1000 && credit.isActive()) return null public class PassAllReport implements Visitor { public BankingProduct visit(Account acc) { return this; } public BankingProduct visit(Credit credit) {
83 Readings Gamma E. et al., Design Patterns. Elements of Reuseable Object-Oriented Software. Addison-Wesley, 1995 Eckel B., Thinking in patterns. Cooper J., Java. Wzorce Projektowe. Helion, 2001 Shalloway A., Trott J., Projektowanie zorientowane obiektowo. Wzorce projektowe. Helion, 2001
84 Q & A ?