Projektowanie oprogramowania

1
Projektowanie oprogramowania
Inzynieria oprogramowania Wyklad 6

• Bartosz Walter
• ltBartosz.Walter_at_cs.put.poznan.plgt

2
Agenda

• Czy oprogramowanie jest zawsze projektowane?
• Znaczenie projektowania
• Projektowanie a wyniki fazy analizy
• Skladowe projektowania

3
Zadania w fazie projektowania

• Uszczególowienie wyników analizy
• Projektowanie technicznych skladowych
  oprogramowania innych niz skladowa dziedziny
  problemu
• Poprawa efektywnosci systemu
• Definicja architektury systemu
• Wybór technologii

4
Uszczególowienie wyników analizy

• Dopracowanie diagramu klas
• Opracowanie diagramów sekwencji
• Wprowadzenie zwiazków skierowanych
• Okreslenie sposobu implementacji zwiazków
• Dobór typów danych
• Opracowanie sygnatur metod
• Okreslenie algorytmów metod

5
Kryteria jakosci projektu obiektowego

• Modularnosc
• Wysoka spójnosc
• Slabe sprzezenia
• Prostota hierarchii dziedziczenia
• Prostota klas i obiektów
• Prostota protokolów i uslug
• Przejrzystosc
• Modularnosc
• Nazewnictwo proste, spójne, precyzyjne
• Zlozonosc skladowych

6
Spójnosc obiektowa

• Obiekt jest spójny jezeli wszystkie jego skladowe
  sluza do realizacji jednego celu
• Spójnosc mierzy sie stopniem wykorzystania pól
  obiektu przez jego wlasne metody
• Celem jest sytuacja, w której odwolania do pól
  wystepuja jedynie z metod danej klasy lub jej
  podklasy

7
(No Transcript)
8
(No Transcript)
9
Sprzezenie

• Zrozumienie jednej skladowej nie powinno prawie
  nigdy wymagac zrozumienia innych skladowych
• Sprzezenie miedzy dwoma klasami/obiektami opisuje
  zaleznosc pomiedzy nimi. Klasa A jest powiazana z
  klasa B, jezeli A musi posiadac pewna wiedze o B
• jako jej pole skladowe,
• jako implementacja interfejsu,
• jako podklasa,
• jako parametr, typ metody albo wyjatek.

10
(No Transcript)
11
(No Transcript)
12
Projektowanie skladowych technicznych

• Skladowe techniczne moga byc projektowane jak
  skladowa dziedziny problemy, czyli Rzeczywistosc
  ? Model ? Projekt
• W odróznieniu od dziedziny problemu, skladowe
  techniczne sa powtarzalne
• Dlatego stosuje sie
• Gotowe biblioteki
• Generatory kodu
• Wzorce architektoniczne
• Wzorce projektowe
• Zasady tworzenia interfejsu uzytkownika

13
Projektowanie skladowej interfejsu uzytkownika

• Klasyfikacja ludzi
• kim sa uzytkownicy systemu
• Opis scenariuszy ich zadan
• czego oczekuja od systemu, kim sa?
• Hierarchia polecen
• zasada 7 2 albo 3 x 3
• Projektowanie szczególowej interakcji
• minimalizacja klikniec i przycisniec klawisza
• brak "ciszy w eterze"
• Prototypy
• uzytkownik vs. prototyp

14
(No Transcript)
15
Projektowanie skladowej zarzadzania danymi

• Fizyczna struktura serwerów danych
• Mechanizm dostepu do danych
• Dokumenty vs. pojedyncze dane
• Bazy danych vs. pliki
• Stopien dekompozycji danych
• Zapis na biezaco vs. zapis na zadanie
• Kwestie optymalizacyjne (indeksy, partycjonowanie)

16
(No Transcript)
17
(No Transcript)
18
Wzorce projektowe
"Wzorzec opisuje problem, który pojawia sie
wielokrotnie w danym srodowisku, i opisuje
podstawe rozwiazania tego problemu, w taki
sposób, ze mozna uzyc tego rozwiazania milion
razy, bez koniecznosci ponownego wykonywania tych
samych czynnosci" Christopher Alexander "A
Pattern Language", 1977
19
Wzorce w budownictwie ladowym
Czy zbudujemy most, opierajac przeslo na
kolejnych filarach polaczonych lukiem, tak aby
luk usztywnial i naciagal przeslo stanowiac jego
podparcie na calej dlugosci przesla,czy tez
mocujac plyty z obu stron za pomoca kilku lin
stalowych o kolejno coraz krótszych dlugosciach
do pylonów umieszczonych posrodku dlugosci mostu?
20
Wzorce w budownictwie ladowym
Czy zbudujemy most lukowy czy podwieszany?
21
Atrybuty wzorca
Wzorzec
22
Wzorce w inzynierii oprogramowania
"Wzorzec projektowy identyfikuje i specyfikuje
pewna abstrakcje, której poziom znajduje sie
powyzej 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 pomiedzy obiektami zaleznosci
jeden-do-wielu, dzieki której jezeli jeden
(nadrzedny) obiekt zmieni stan, pozostale takze
zostana o tym powiadomione i zaktualizowane
25
Observer Struktura
26
Observer Uczestnicy

• Subject
• zna swoje obserwatory
• posiada interfejs pozwalajacy dolaczac i odlaczac
  obserwatory
• Observer
• definiuje ogólny interfejs dla obserwatorów
• Concrete Subject
• przechowuje stan, który obserwuja obserwatory
• wysyla powiadomienia do obserwatorów
• Concrete Observer
• dolacza i odlacza siebie do/od obiektu
  obserwowanego
• aktualizuje swój stan przy zmianach w obiekcie
  obserwowanym

27
Observer Konsekwencje

• ulatwione utrzymanie spójnosci systemu
• abstrakcyjne powiazanie pomiedzy obiektami
  Subject i Observer
• Subject posiada znikoma wiedze o swoich
  obserwatorach
• Subject i obserwatory moga nalezec do róznych
  warstw aplikacji
• programowy broadcasting
• skalowalnosc aktualizacji obserwatorów
• push obserwatory otrzymuja pelna informacje o
  zmianie (czy jej potrzebuja, czy nie)
• pull obserwatory otrzymuja tylko powiadomienie i
  musza zapytac Subject o szczególy
• "wiszace" referencje po stronie obiektu
  obserwowanego (rozwiazanie w Javie "slabe"
  referencje)

28
Observer Przyklad
Rachunek klienta moze byc powiazany z innymi
rachunkami pobocznymi. Na przyklad, z glównym
rachunkiem jest zwiazany rachunek kredytu
odnawialnego. Wysokosc otwartej linii kredytowej
zalezy od srodków na rachunku glównym. Zmiana
wysokosci salda na tym rachunku skutkuje
podwyzszeniem lub obnizeniem dostepnej kwoty
kredytu.
29
Factory Method Cel

• Zdefiniowanie interfejsu do tworzenia obiektu
• Odsuniecie tworzenia obiektów okreslonej klasy do
  podklas
• Podklasy decyduja której klasy i którego
  konstruktora uzyc do utworzenia obiektu produktu.

30
Factory Method Zastosowanie

• Klient nie moze przewidziec, jakiej klasy obiekt
  nalezy utworzyc
• Klasa chce, aby jej podklasy okreslaly jaki
  obiekt utworzyc w tym celu przekazuje im czesc
  swojej odpowiedzialnosci

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
• moze posiadac domyslna implementacje metody
  fabryki
• ConcreteCreator
• pokrywa metode fabryke, tak aby zwracala obiekt
  Concrete Product

33
Factory Method Konsekwencje

• przesuniecie akcentu na podklasy
• podklasy w ich metodach fabrykach moga tworzyc
  zmieniona lub rozszerzona wersje produktu
• parametryzowane FM vs. polimorficzne FM
• Creator moze wybrac obiekt, który chce utworzyc,
  lub przekazac te odpowiedzialnosc do podklas
• dwa poziomy wyboru podklasy, która utworzy
  specyficzny produkt, oraz konstruktora wewnatrz
  podklasy

34
Factory Method Przyklad
W zaleznosci od wybranego sposobu drukowania
wyciagów, sa one tworzone codziennie,
cotygodniowo lub comiesiecznie. Kazdy z nich jest
reprezentowany przez oddzielny obiekt.
35
Chain of Responsibility Cel

• Unikniecie wiazania nadawcy zadania z jego
  odbiorcom poprzez utworzenie grupy potencjalnych
  odbiorców, którzy moga obsluzyc zadanie
• Odbiorcy sa ulozeni w lancuch i przekazuja sobie
  zadanie wzdluz lancucha az jeden z nich obsluzy
  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 Przyklad 1
40
Chain of Responsibility Przyklad 1
41
Chain of Responsibility Przyklad 2
42
Chain of Responsibility Przyklad 2
43
State Cel
Umozliwienie obiektowi zmiany jego zachowania w
odpowiedzi na zmiane jego wewnetrznego stanu.
Obiekt bedzie pozornie zmienial swoja klase.
44
State Zastosowanie

• Zachowanie obiektu zalezy od jego stanu i podlega
  zmianom w trakcie wykonywania programu
• Wewnatrz metody istnieja zlozone, wieloczesciowe
  wyrazenia warunkowe, które zaleza od stanu
  obiektu
• Kazdy stan jest oddzielnym obiektem, który moze
  zmieniac sie niezaleznie od innych obiektów

45
State Struktura
46
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
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 Przyklad
Rachunek moze znajdowac sie w stanie otwartym lub
zamknietym. W stanie otwartym wlasciciel moze
dokonywac wplat na rachunek, podczas gdy w stanie
zamknietym stan rachunku nie moze ulec zmianie.
49
State Przyklad
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 Przyklad
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
public void credit(Account acc, int amount)
alert("The account is closed!")
51
State Przyklad
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

• Umozliwienie dynamicznego dolaczania
  odpowiedzialnosci do obiektu
• Dostarczenie elastycznej alternatywy dla
  dziedziczenia w celu rozszerzania funkcjonalnosci

53
Decorator Problem
public class Invoice String buyer null
String issuer null List ltListItemgt elements
new ArrayListltListItemgt() 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 ltListItemgt elements
new ArrayListltListItemgt() 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
public void print() if (useHeader())
header.print()
super.print()
55
Decorator Problem
56
Decorator Struktura
57
Decorator Uczestnicy

• Component
• deklaruje interfejs dla obiektów, którym mozna
  zwiekszyc zakres odpowiedzialnosci
• Concrete Component
• implementuje interfejs Component
• Decorator
• posiada interfejs zgodny z interfejsem Component
• jest swiadom istnienia dekorowanego Componentu
  (który jest instancja Concrete Component lub
  innym Decoratorem)
• Concrete Decorator
• dodaje odpowiedzialnosc do komponentu

58
Decorator Konsekwencje

• wieksza elastycznosc niz w przypadku
  dziedziczenia
• odpowiedzielnosc moze byc zwiekszana dynamicznie
• mniej zlozona hierarchia klas
• pay-as-you-go
• poszczególne cechy sa dodawane na zadanie
• róznica w tozsamosci obiektów
• tozsamosc obiektu jest inna od tozsamosci
  dekoratora
• tozsamosc obiektu powinna byc hermetyzowana i
  ukryta przed klientem
• duza liczna malych, dobrze zdefiniowanych klas
  dekoratorów
• poprawiona testowalnosc

59
Decorator Przyklad
60
Flyweight Cel

• Ponowne uzycie i wspóldzielenie obiektów w celu
  zwiekszenia efektywnosci ich wykorzystania
• Oddzielenie wewnetrznego (wspóldzielnonego) i
  zewnetrznego (unikatowego) stanu obiektu

61
Flyweight Struktura
62
Flyweight Uczestnicy

• Flyweight
• deklaruje interfejs, przez który obiekty moga
  otrzymywac swój stan zewnetrzny
• Concrete Flyweight
• musi byc niezalezny od swojego kontekstu (stanu
  zewnetrznego)
• Unshared Concrete Flyweight
• specjalny przypadek obiektu niewspóldzielnonego
• Flyweight Factory
• tworzy i zarzadza obiektami Flyweight
• zapewnia poprawnosc procesu zarzadzania obiektami
• Client
• otrzymuje instancje Flyweight poprzez
  FlyweightFactory

63
Flyweight Konsekwencje

• rosnace oszczednosci pamieci
• ograniczenie calkowitej liczby instancji
• ograniczenie wspóldzielonego stanu wewnetrznego
• stan zewnetrzny moze byc wyliczony lub
  zapamietany
• wzrost kosztu obliczeniowego
• zarzadzanie stanem zewnetrznym

64
Flyweight Przyklad
public abstract class TeaOrder // Flyweight
public abstract void serveTea(TeaOrderContext
teaOrderContext) public class TeaFlavor
extends TeaOrder // ConcreteFlyweight
String teaFlavor // stan wewnetrzny
TeaFlavor(String teaFlavor)
this.teaFlavor teaFlavor public
String getFlavor() return
this.teaFlavor // teaOrderContext
jest zewnetrznym stanem public void
serveTea(TeaOrderContext teaOrderContext)
System.out.println("Serving tea flavor "
teaFlavor " to table number "
teaOrderContext.getTable())
65
Flyweight Przyklad
public class TeaOrderCtx // kontekst dostarcza
stan zewnetrzny int tableNumber
TeaOrderContext(int tableNumber)
this.tableNumber tableNumber public
int getTable() return this.tableNumber

66
Flyweight Przyklad
public class TeaFlavorFactory // Flyweight
Factory TeaFlavor flavors new
TeaFlavor10// lt10 flavors can be made int
teasMade 0 // Factory Method public
TeaFlavor getTeaFlavor(String flavorToGet)
for (int i 0 i lt teasMade i)
if (flavorToGet.equals((flavorsi).getFlavor()))
return flavorsi
flavorsteasMade new
TeaFlavor(flavorToGet) return
flavorsteasMade public int
getTotalTeaFlavorsMade() return teasMade

by Lawrence Trurett
67
Flyweight Przyklad
class TestFlyweight static TeaFlavor
flavors new TeaFlavor100 // zamówienia
static TeaOrderCtx tables new
TeaOrderCtx100 // stoly static int
ordersMade 0 static TeaFlavorFactory
teaFlavorFactory static void
takeOrders(String flavorIn, int table)
flavorsordersMade teaFlavorFactory.getTeaFlavo
r(flavorIn) tablesordersMade new
TeaOrderCtx(table) public static void
main(String args) teaFlavorFactory
new TeaFlavorFactory() takeOrders("chai",
2) takeOrders("chai", 2)
takeOrders("camomile", 1) takeOrders("earl
grey", 1) takeOrders("camomile", 897)
for (int i 0 i lt ordersMade i)
flavorsi.serveTea(tablesi)
System.out.println(" ")
System.out.println("total teaFlavor objects made
" teaFlavorFactory.getTotalTeaFlavorsM
ade())
68
Command Cel

• Hermetyzacja zadania jako obiektu
• Umozliwienie parametryzacji klientów róznymi
  zadaniami
• Wsparcie dla zadan odwracalnych

69
Command Struktura
70
Command Uczestnicy

• Command
• deklaruje interfejs dla wykonywania zadania
  (execute())
• ConcreteCommand
• definiuje powiazanie pomiedzy Receiverem i akcja
• implementuje metode execute()
• Client
• tworzy obiekt ConcreteCommand i wskazuje jego
  odbiorce (Receiver)
• Invoker
• wywoluje obiekt Command w celu wykonania zadania
• Receiver
• zna wykonawce konkretnych zadan

71
Command Konsekwencje

• usuniecie powiazania nadawcy i odbiorcy
  (Receiver)
• obiekty Command moga byc skladane w polecenia
  zlozone
• dodawanie nowych obiektów Command jest latwe
• Command mozna latwo rozszerzyc o odwracanie ich
  dzialania

72
Command Przyklad
73
Command Przyklad
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 Przyklad
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) // store parameters...
public void execute(Account from)
from.subtract(amount) to.add(amount)

75
Visitor Cel

• Reprezentacja operacji, która ma byc wykonana na
  elementach heterogenicznej struktury.
• Umozliwienie zdefiniowania nowej operacji bez
  zmiany samych elementów, na których ona operuje

76
Visitor Struktura
77
Visitor Uczestnicy

• Visitor
• deklaruje sposób realizacji operacji dla kazdego
  ConcreteElement, który ma byc odwiedzony
• Concrete Visitor
• implementuje konkretna operacje
• Element
• definiuje metode accept(), która otrzymuje obiekt
  Visitor jako parametr
• Object Structure
• zwraca pojedyncze elementy struktury
• moze posiadac interfejs wysokiego poziomu który
  pozwala obiektom Visitor odwiedzac elementy

78
Visitor Konsekwencje

• latwe dodawanie nowych operacji (Visitorów)
• trudne dodawanie nowych elementów
  (ConcreteElements)
• kazdy ConcreteElement wymaga stworzenie nowej
  metody we wszystkich istniejacych Visitorach
• obsluga obiektów niezalezna od ich klas
• inaczej niz Iterator, Visitor moze odwiedzac
  obiektów róznych klas

79
Visitor Konsekwencje (cd.)

• akumulacja stanu
• Visitory moga akumulowac stan odwiedzanych
  elementów w sposób dla nich specyficzny
• koniecznosc naruszenia hermetyzacji
• z uwagi na odwrócenie sterowania pomiedzy
  elementem a Visitorem, konieczne jest
  udostepnienie im nazwajem metod accept() i
  visit()

80
Visitor Przyklad
public class Bank ListltBankingProductgt
products new ArrayListltBankingProductgt()
public ListltBankingProduct gt doReport(Report
report) ListltBankingProduct gt result
new ArrayListltBankingProduct gt()
for (BankingProduct product products)
result.add(product.accept(report))
return result
81
Visitor Przyklad
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 public
BankingProduct accept(Report report) if
(isPriviliged(report)) return
report.visit(this) return null

82
Visitor Przyklad
public class Over1000Report implements Visitor
public BankingProduct visit(Account acc)
if (acc.balance gt 1000) return this
return null public BankingProduct
visit(Credit credit) if (credit.draft gt
1000 credit.isActive()) return this
return null
public class PassAllReport implements Visitor
public BankingProduct visit(Account acc)
return this public BankingProduct
visit(Credit credit) return this

83
Readings

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

84
Q A
?