Projektowanie oprogramowania

Prezentacja na temat: "Projektowanie oprogramowania"— Zapis prezentacji:

1 Projektowanie oprogramowania
Inż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 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

4 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

5 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

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

13 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

14

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

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ą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?

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

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

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

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: 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

31 Factory Method: Struktura
by the Gang of Four

32 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

33 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

34 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.

35 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.

36 Chain of Responsibility: Structure
by the Gang of Four

37 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

38 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

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

47 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

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

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

55 Decorator: Problem

56 Decorator: Struktura

57 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

58 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ść

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: 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

63 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

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

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

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 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ń

71 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

72 Command: Przykład

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

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

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

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

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 ?