Projektowanie oprogramowania Inżynieria oprogramowania Wykład 6 Projektowanie oprogramowania Bartosz Walter <Bartosz.Walter@cs.put.poznan.pl>

Agenda Czy oprogramowanie jest zawsze projektowane? Znaczenie projektowania Projektowanie a wyniki fazy analizy Składowe projektowania

Zadania w fazie projektowania Uszczegół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

Uszczegółowienie wyników analizy Dopracowanie 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

Kryteria jakości projektu obiektowego Modularność 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

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

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.

Projektowanie składowych technicznych Skł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

Projektowanie składowej interfejsu użytkownika Klasyfikacja 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

Projektowanie składowej zarządzania danymi Fizyczna 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)

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

Wzorce w budownictwie lądowym Czy 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?

Wzorce w budownictwie lądowym Czy zbudujemy most łukowy czy podwieszany?

Wzorzec Atrybuty wzorca jak? kiedy? zyski/straty? kontekst? alternatywy? warunki wstępne?

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

Systematyka wzorców projektowych Kreacyjne 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

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

Observer: Struktura

Observer: Uczestnicy Subject Observer Concrete Subject zna 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

Observer: Konsekwencje uł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)

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.

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.

Factory Method: Zastosowanie Klient 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

Factory Method: Struktura by the Gang of Four

Factory Method: Uczestnicy Product 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

Factory Method: Konsekwencje przesunię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

Factory Method: Przykład W 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.

Chain of Responsibility: Cel Uniknię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.

Chain of Responsibility: Structure by the Gang of Four

Chain of Responsibility: Participants Handler 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

Chain of Responsibility: Consequences Chain 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

Chain of Responsibility: Przykład 1

Chain of Responsibility: Przykład 1

Chain of Responsibility: Przykład 2

Chain of Responsibility: Przykład 2

State: Cel Umożliwienie obiektowi zmiany jego zachowania w odpowiedzi na zmianę jego wewnętrznego stanu. Obiekt będzie pozornie zmieniał swoją klasę.

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

State: Struktura

Concrete State subclasses State: 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

partition of the behavior for different states State: 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

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.

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!");

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!");

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();

Decorator: Cel Umożliwienie dynamicznego dołączania odpowiedzialności do obiektu Dostarczenie elastycznej alternatywy dla dziedziczenia w celu rozszerzania funkcjonalności

Decorator: Problem public class Invoice { String buyer = null; String issuer = null; List <ListItem> elements = new ArrayList<ListItem>(); Header header = null; private boolean useHeader() { return header != null; } public void print() { if (useHeader()) { header.print(); print("Issuer: " + issuer); print("Buyer: " + buyer); for (e : elements) { e.print();

Decorator: Problem public class Invoice { String buyer = null; String issuer = null; List <ListItem> elements = new ArrayList<ListItem>(); public void print() { print("Issuer: " + issuer); print("Buyer: " + buyer); for (e : elements) { e.print(); } public class HeaderInvoice extends Invoice { Header header = null; private boolean useHeader() { return header != null; if (useHeader()) { header.print(); super.print();

Decorator: Problem

Decorator: Struktura

Decorator: Uczestnicy Component 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

Decorator: Konsekwencje wię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ść

Decorator: Przykład

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

Flyweight: Struktura

Flyweight: Uczestnicy deklaruje 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

Flyweight: Konsekwencje rosną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

Flyweight: Przykład public abstract class TeaOrder { // Flyweight public 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());

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;

Flyweight: Przykład by Lawrence Trurett public 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

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());

Command: Cel Hermetyzacja żądania jako obiektu Umożliwienie parametryzacji klientów różnymi żądaniami Wsparcie dla żądań odwracalnych

Command: Struktura

Command: Uczestnicy Command ConcreteCommand Client Invoker Receiver deklaruje 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ń

Command: Konsekwencje usunię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

Command: Przykład

Command: Przykład public class Bank { // Invoker, Client public 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);

Command: Przykład abstract public class Operation { // Command public 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);

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

Visitor: Struktura

Visitor: Uczestnicy Visitor Concrete Visitor Element Object Structure deklaruje 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

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

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*()

Visitor: Przykład public class Bank { List<BankingProduct> products = new ArrayList<BankingProduct>(); public List<BankingProduct > doReport(Report report) { List<BankingProduct > result = new ArrayList<BankingProduct >(); for (BankingProduct product : products) { result.add(product.accept(report)); } return result;

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 {

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) {

Readings Gamma E. et al., Design Patterns. Elements of Reuseable Object-Oriented Software. Addison-Wesley, 1995 Eckel B., Thinking in patterns. http://www.bruceeckel.com Cooper J., Java. Wzorce Projektowe. Helion, 2001 Shalloway A., Trott J., Projektowanie zorientowane obiektowo. Wzorce projektowe. Helion, 2001

Q & A ?