plik

Inżynieria Oprogramowania
Wykład 01 - Wprowadzenie

MIS-1-502-s
MIO-1-505-s
MIS-1-505-n

Kazimierz Michalik

Wydział Inżynierii Metali i Informatyki Przemysłowej

Katedra Informatyki Stosowanej i Modelowania

Kraków 2014-2015

www.agh.edu.pl

Pojęcie podstawowe

Oprogramowanie (software) – pojęcie podstawowe

(do oprogramowania włącza się niekiedy, oprócz

plików binarnych i z kodem źródłowym, także

dokumentację, pliki konfiguracyjne, przykładowe

dane itp..)

Inżynieria oprogramowania (Software Engineering)

– dziedzina inżynierii związana z wytwarzaniem

oprogramowania we wszystkich jego fazach cyklu

życia.
Jako dziedzina inżynierii, IO rozważa w kontekście

praktycznym rozmaite aspekty wytwarzania

oprogramowania (techniczny, organizacyjny, finansowy

itp..)

Oprogramowanie (software) – pojęcie podstawowe

(do oprogramowania włącza się niekiedy, oprócz

plików binarnych i z kodem źródłowym, także

dokumentację, pliki konfiguracyjne, przykładowe

dane itp..)

Inżynieria oprogramowania (Software Engineering)

– dziedzina inżynierii związana z wytwarzaniem

oprogramowania we wszystkich jego fazach cyklu

życia.
Jako dziedzina inżynierii, IO rozważa w kontekście

praktycznym rozmaite aspekty wytwarzania

oprogramowania (techniczny, organizacyjny, finansowy

itp..)

Cele inżynierii oprogramowania

Cel podstawowy:
Dostarczenie zasad organizacji procesu

wytwarzania oprogramowania (sofware

development) w oparciu o istniejące teorie,

modele, metody i narzędzia (formalne lub

nieformalne).

• W końcowym efekcie proces wytwarzania

oprogramowania ma w sposób efektywny doprowadzić

do powstania produktu wysokiej jakości

• Inżynieria oprogramowania jest częścią szerszej

dyscypliny: inżynierii systemów (system engineering),

w jej aspekcie dotyczącym oprogramowania.

Cel podstawowy:
Dostarczenie zasad organizacji procesu

wytwarzania oprogramowania (sofware

development) w oparciu o istniejące teorie,

modele, metody i narzędzia (formalne lub

nieformalne).

• W końcowym efekcie proces wytwarzania

oprogramowania ma w sposób efektywny doprowadzić

do powstania produktu wysokiej jakości

• Inżynieria oprogramowania jest częścią szerszej

dyscypliny: inżynierii systemów (system engineering),

w jej aspekcie dotyczącym oprogramowania.

Problemy inżynierii oprogramowania

• Złożoność programów
• Złożoność systemów, w ramach których

funkcjonują programy (ludzie, sprzęt, instytucje,

procesy produkcyjne etc.)

• Zmienność systemów
• Złożoność procesów składających się na

wytwarzanie oprogramowania ( w przeciwieństwie

do prostoty pisania samego kodu)

• Łatwość i praktyczna nieuniknioność popełniania

błędów przy wytwarzaniu oprogramowania

• Złożoność programów
• Złożoność systemów, w ramach których

funkcjonują programy (ludzie, sprzęt, instytucje,

procesy produkcyjne etc.)

• Zmienność systemów
• Złożoność procesów składających się na

wytwarzanie oprogramowania ( w przeciwieństwie

do prostoty pisania samego kodu)

• Łatwość i praktyczna nieuniknioność popełniania

błędów przy wytwarzaniu oprogramowania

Cechy dobrego oprogramowania

Wg. Sommerville'a:

• Poprawność, zgodność z wymaganiami

użytkowników

• Łatwość pielęgnacji (konserwacji) i dokonywania

zmian

• Niezawodność (dostępność i pewność)
• Bezpieczeństwo (w obu znaczeniach – safety,

security)

• Wydajność, efektywne korzystanie z zasobów
• Łatwość stosowania, ergonomiczność

Wg. Sommerville'a:

• Poprawność, zgodność z wymaganiami

użytkowników

• Łatwość pielęgnacji (konserwacji) i dokonywania

zmian

• Niezawodność (dostępność i pewność)
• Bezpieczeństwo (w obu znaczeniach – safety,

security)

• Wydajność, efektywne korzystanie z zasobów
• Łatwość stosowania, ergonomiczność

Historia Inżynierii Oprogramowania:

Prehistoria. II wojna światowa.

ABC (us.), Electronic Numerical Integrator And

Computer(us.), Colossus(uk.), Konrad Zuse(de.)

• Nowe komputery (architekturalnie) pojawiają się w

odstępach paru lat.

• Całe oprogramowanie musi być przepisane/napisane na

nowo dla nowych maszyn

• Czasy kart perforowanych i wydruków z wynikami.
• Program = Algorytm.
• 1945: Architektura von Neumanna

Historia Inżynierii Oprogramowania:

1945 – 1965: Narodziny

Język programowania:

• Komputery, wraz z oprogramowaniem, są

stworzone do konkretnych celów i rodzaju

obliczeń.

• Ciągła potrzeba przepisywania programów

doprowadza do powstania języków

programowania

• Oprogramowanie było darmowe

Język programowania:

• Komputery, wraz z oprogramowaniem, są

stworzone do konkretnych celów i rodzaju

obliczeń.

• Ciągła potrzeba przepisywania programów

doprowadza do powstania języków

programowania

• Oprogramowanie było darmowe

Era freeware:

• Wydawcy tworzyli otwarte repozytoria z

oprogramowaniem

• Na uniwersytetach nie istnieje taki przedmiot

jak Informatyka (Inżynieria Oprogramowania

też oczywiście nie)

Era freeware:

• Wydawcy tworzyli otwarte repozytoria z

oprogramowaniem

• Na uniwersytetach nie istnieje taki przedmiot

jak Informatyka (Inżynieria Oprogramowania

też oczywiście nie)

Historia Inżynierii Oprogramowania:

1965 - 1985: Kryzys oprogramowania

• Przekraczanie budżetu – o miliony dolarów (OS/360)
• Przekraczanie czasu – na przykład 10 lat
• Uszkodzenie mienia – w wyniku błędów programu (Mariner 1)
• Zagrożenie zdrowia i życia – np.: śmierć w wyniku napromieniowania

(Therac-25), błędu systemu kierowania ogniem (MIM-104 Patriot)

Historia Inżynierii Oprogramowania:

1968-1969: Software engineering

• Software Engineering: Report of a conference

sponsored by the NATO Science Committee ,

Garmisch, Germany: Scientific Affairs Division, NATO.

• E.W. Dijkastra Go To Statement Considered Harmful

• Software Engineering: Report of a conference

sponsored by the NATO Science Committee ,

Garmisch, Germany: Scientific Affairs Division, NATO.

• E.W. Dijkastra Go To Statement Considered Harmful

• 1969: Termin Inżynieria Oprogramowania

ujrzał światło dzienne

• Wczesne lata '80: Inżynieria Oprogramowania

staje się wyróżnialnym zawodem plasującym

się między informatyką a Inżynierią

• 1969: Termin Inżynieria Oprogramowania

ujrzał światło dzienne

• Wczesne lata '80: Inżynieria Oprogramowania

staje się wyróżnialnym zawodem plasującym

się między informatyką a Inżynierią

Historia Inżynierii Oprogramowania:

1965 - 1985: Wciąż kryzys oprogramowania

•

1972: D.Parnas On the Criteria To Be Used

in Decomposing Systems into Modules

•

Programowanie modułowe i abstrakcyjne

typy danych były już używane.

•

Późne lata '80: Koszty utrzymania

oprogramowania 2x wyższe niż koszt

stworzenia nowego.

•

Wczesne lata '90: Koszty utrzymania nadal

wzrastają o kolejne 30%

•

1995: 50% programów uznawanych za

porażkę, mimo teoretycznie poprawnego

działania

•

Przeciętny projekt przekracza wyznaczony

czas o 50%!

Historia Inżynierii Oprogramowania:

1985 - 1989: Brak panaceum

Propozycje rozwiązania problemów:

• Narzędzia: różne sposoby programowania

(strukturalne, OO), CASE, dokumentacja,

standardy

• Dyscyplina pracy programistów.
• Metody formalne z inżynierii.
• Proces wytwarzania oprogramowania

( Capability Maturity Model)

• Etyka pracy, licencje, profesjonalizm.

1986, Fred Brooks, No Silver Bullet

•

Brak „cudownego leku”, ale Inżynieria

Oprogramowania ma sens!

1986, Fred Brooks, No Silver Bullet

•

Brak „cudownego leku”, ale Inżynieria

Oprogramowania ma sens!

Czynności w czasie produkcji

oprogramowania

Inżynieria oprogramowania stara się zidentyfikować i

opisać podstawowe fazy tworzenia i funkcjonowania

oprogramowania, a także wskazać model optymalnego

przebiegu tych faz.

Co można robić w czasie tworzenia

oprogramowania?

• Planowanie
• Implementacja
• Testowanie
• Dokumentowanie
• Wdrożenie
• Utrzymanie (konserwacja).

Co można robić w czasie tworzenia

oprogramowania?

• Planowanie
• Implementacja
• Testowanie
• Dokumentowanie
• Wdrożenie
• Utrzymanie (konserwacja).

Warto przeczytać

• Sommerville I.: Inżynieria oprogramowania 8-th ed.,

Addison-Wesley, 2006 (wyd.6, WNT, 2003)

• Hunt A., Thomas D.: The Pragmatic Programmer: From

Journeyman to Master

• Yourdon, E.: Marsz ku klęsce. Poradnik dla projektantów

systemów. WNT, 2007

• Booch G., Jacobson I., Rumbaugh J.: UML przewodnik

użytkownika WNT 2002

• Gamma E., Helm R., Johnson R., Vlissides J.: Wzorce

projektowe. Elementy programowania obiektowego

wielokrotnego użytku, WNT 2005

• Sacha K.: Inżynieria oprogramowania, Wydawnictwo

Naukowe PWN, 2010

• Steve McConnel: Kod doskonały. Jak tworzy

oprogramowanie pozbawione błędów. Wydanie II

• Martin Fowler: UML Distilled
• Brooks, Mityczny osobomiesiąc: eseje o inżynierii

oprogramowania. WNT, 2000

www.agh.edu.pl

Warunki zaliczenia przedmiotu (1)

www.agh.edu.pl

Sposób obliczania oceny końcowej:

Wymagania wstępne i dodatkowe:

Programowanie w języku obiektowym

Nakład pracy studenta (bilans punktów ECTS):

Udział w wykładach

30 godz

Udział w ćwiczeniach projektowych

30 godz

Przygotowanie do zajęć

30 godz

Wykonanie projektu

30 godz

Samodzielne studiowanie tematyki zajęć

30 godz

Sumaryczne obciążenie pracą studenta

150 godz

Punkty ECTS za moduł

6 ECTS

WARUNKI UZYSKANIA ZALICZENIA:

91 – 100% bardzo dobry (5.0);
81 – 90% plus dobry (4.5);
71 – 80% dobry (4.0);
61 – 70% plus dostateczny (3.5);
50 – 60% dostateczny (3.0);
poniżej 50% niedostateczny (2.0).

PUNKTACJA: nominalnie jest do zdobycia 100 punktów

Średnia ważona ocen z egzaminu (66%) i projektu (34%)
– po uzyskaniu co najmniej 3.0 z każdej z nich

(Regulamin studiów §13, pkt 1:)

Warunki zaliczenia projektu (2)

www.agh.edu.pl

PUNKTACJA: nominalnie jest do zdobycia 100 punktów

Wykłady: (DODATKOWO!)

Wykład

Semestr

za aktywne uczestnictwo w wykładzie

1 pkt

15 pkt

Zajęcia projektowe:

Zajęcia

Semestr

za poprawne przygotowanie do zajęć

0 do 2 pkt

30 pkt

za punktualną obecność i wykonywanie zadań

0 do 1 pkt

15 pkt

(albo za spóźnienie do 15tu minut i wykonywanie zadań

0 do 0,5 pkt

7,5 pkt)

za poprawne i samodzielne ukończenie zadań na zajęciach

0 do 2 pkt

30 pkt

rozliczanie projektów na koniec listopada

0 do 10 pkt

10 pkt

rozliczanie projektów na koniec semestru

0 do 15 pkt

15 pkt

W SUMIE

100 pkt

Warunki zaliczenia projektu (3)

Terminy poprawkowe:

Termin

W sumie

Przysługują tylko tym, którzy:
- nie uzyskali zaliczenia w poprzednim terminie i
-- byli na przynajmniej 7 zajęciach w semestrze lub

I popr.

25 pkt

II popr.

25 pkt

W SUMIE DODATKOWO

50 pkt

-- przedłożyli w wymaganym terminie
usprawiedliwienie większej ilości nieobecności.

za wykonanie zadań z tematów, w których student
nie wykazał się wiedzą w czasie semestru
za wykonanie zadań z tematów, w których student
nie wykazał się wiedzą w czasie semestru
i I terminu poprawkowego.

Warunki zaliczenia egzaminu (4)

•

Warunkiem przystąpienia do egzaminu jest

pozytywna ocena z zajęć projektowych.

•

Egzamin trzeba po prostu zdać (50%+).

•

Jeżeli w czasie semestru ktoś zdobędzie więcej niż

100 pkt, to dodatkowe punkty są doliczane do

wyniku egzaminu.

Jakie jest absolutne minimum, żeby zdać egzamin na

50%?
W każdym wykładzie, treści absolutnie wymagane do

zdania egzaminu na 3.0 będą wyróżnione w ramkach

koloru czerwonego.
(Technicznie jest to odcień bladopomarańczowego, ale

jestem pewien, że zorientujecie się które to są ramki.)

Jakie jest absolutne minimum, żeby zdać egzamin na

50%?
W każdym wykładzie, treści absolutnie wymagane do

zdania egzaminu na 3.0 będą wyróżnione w ramkach

koloru czerwonego.
(Technicznie jest to odcień bladopomarańczowego, ale

jestem pewien, że zorientujecie się które to są ramki.)

Modele cyklu ˙zycia

oprogramowania

Przypomnienie: proces
produkcji; czynno´sci a
modele

Podział metodologii
tworzenia
oprogramowania

Proces ujednolicony
(Unified Process)

Metody zwinne (Agile)

Inne metodologie

Podsumowanie

2.3

Czynno ´sci w czasie produkcji oprogramowania.

In˙zynieria oprogramowania stara si ˛e zidentyfikowa´c i opisa´c
podstawowe fazy tworzenia i funkcjonowania oprogramowania,
a tak˙ze wskaza´c model optymalnego przebiegu tych faz.

Co mo˙zna robi ´c w czasie tworzenia oprogramowania?

Planowanie.

Implementacja.

Testowanie.

Dokumentowanie.

Wdro˙zenie.

Utrzymanie (konserwacja).

Modele cyklu ˙zycia

oprogramowania

Przypomnienie: proces
produkcji; czynno´sci a
modele

Podział metodologii
tworzenia
oprogramowania

Proces ujednolicony
(Unified Process)

Metody zwinne (Agile)

Inne metodologie

Podsumowanie

2.4

Edward V. Berard

”Walking on water and developing software from a specification
are easy if both are frozen. ”

(1993) Essays on object-oriented software engineering. Volume 1. Englewood Cliffs, N.J. : Prentice Hall

Modele cyklu ˙zycia

oprogramowania

Przypomnienie: proces
produkcji; czynno´sci a
modele

Podział metodologii
tworzenia
oprogramowania

Proces ujednolicony
(Unified Process)

Metody zwinne (Agile)

Inne metodologie

Podsumowanie

2.6

Dwa główne nurty.

Istnieje wiele cało´sciowych metodologii tworzenia
oprogramowania, z których dwie obecnie najwa˙zniejsze (i
istniej ˛

ace w wielu odmianach) to:

Proces ujednolicony - Unified Process

RUP

Metody zwinne - agile methods

Extream programming (XP)

Obydwie grupy metodologii zakładaj ˛

a iteracyjne tworzenie

oprogramowania, ró˙zni ˛

ac si ˛e głównie stosunkiem do

modelowania i planowania w trakcie procesu tworzenia
oprogramowania

Modele cyklu ˙zycia

oprogramowania

Przypomnienie: proces
produkcji; czynno´sci a
modele

Podział metodologii
tworzenia
oprogramowania

Proces ujednolicony
(Unified Process)

Metody zwinne (Agile)

Inne metodologie

Podsumowanie

2.9

Zasady RUP.

iteracyjne i przyrostowe tworzenie oprogramowania;
sterowane ryzykiem i priorytetami, ułatwiaj ˛

ace integracj ˛e

cało´sci kodu i dostosowanie do zmieniaj ˛

acych si ˛e

wymaga ´n

zarz ˛

adzanie wymaganiami; we współpracy z klientem i w

oparciu o przypadki u˙zycia

stosowanie architektury opartej na komponentach

graficzne modelowanie oprogramowania; ró˙zne
perspektywy spojrzenia na system, u˙zycie UML

kontrola i weryfikacja jako´sci oprogramowania przez cały
czas procesu wytwarzania

zarz ˛

adzanie zmianami w oprogramowaniu

Modele cyklu ˙zycia

oprogramowania

Przypomnienie: proces
produkcji; czynno´sci a
modele

Podział metodologii
tworzenia
oprogramowania

Proces ujednolicony
(Unified Process)

Metody zwinne (Agile)

Inne metodologie

Podsumowanie

2.10

Fazy projektu RUP.

faza pocz ˛

atkowa (inception) – wst ˛epne okre´slenie

wymaga ´n, ryzyka, kosztu, harmonogramu, a tak˙ze
architektury systemu

faza opracowania (elaboration) – ustalenie wymaga ´n
(wi ˛ekszo´sci przypadków u˙zycia), architektury systemu
oraz planu całego procesu wytwarzania systemu

faza konstrukcji (construction) – tworzenie systemu
(kolejnych komponentów), w trakcie nastepuje oddanie
pierwszej (i by´c mo˙ze dalszych) wersji u˙zytkownikowi

faza przekazania (transition) – system jest przekazywany
u˙zytkownikowi, wdra˙zany, szkoleni s ˛

a pracownicy obsługi

systemu, nastepuje walidacja i ko ´ncowe sprawdzenie
jako´sci

Modele cyklu ˙zycia

oprogramowania

Przypomnienie: proces
produkcji; czynno´sci a
modele

Podział metodologii
tworzenia
oprogramowania

Proces ujednolicony
(Unified Process)

Metody zwinne (Agile)

Inne metodologie

Podsumowanie

2.11

Dyscypliny - rodzaje wykonywanych zada ´

modelowanie biznesowe

wymagania

analiza i projektowanie

implementacja

testowanie

wdro˙zenie

zarz ˛

adzanie konfiguracj ˛

a i zmianami

zarz ˛

adzanie projektem (zarz ˛

adzanie ryzykiem, planowanie

iteracji, monitorowanie post ˛epów)

organizacja ´srodowiska (m.in. narz ˛edzi)

Modele cyklu ˙zycia

oprogramowania

Przypomnienie: proces
produkcji; czynno´sci a
modele

Podział metodologii
tworzenia
oprogramowania

Proces ujednolicony
(Unified Process)

Metody zwinne (Agile)

Inne metodologie

Podsumowanie

2.13

Agile programming

Metody te maj ˛

a pewne cechy wspólne, które wynikaj ˛

a z

przyj ˛etej ideologii tworzenia oprogramowania zapisanej w
manife´scie metod zwinnych (agile manifesto)

Agile manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Jednostki i interakcje ponad procesy i narz ˛edzia

Działaj ˛

ace oprogramowanie ponad wyczerpuj ˛

ac ˛

dokumentacj ˛e

Współpraca z klientem ponad negocjacje kontraktu

Reagowanie na zmiany ponad realizowanie planu

Modele cyklu ˙zycia

oprogramowania

Przypomnienie: proces
produkcji; czynno´sci a
modele

Podział metodologii
tworzenia
oprogramowania

Proces ujednolicony
(Unified Process)

Metody zwinne (Agile)

Inne metodologie

Podsumowanie

2.14

Agile programming

Co jest charakterystyczne?

Metody zwinne nadaj ˛

a si ˛e dla małych zespołów tworz ˛

acych

małe i ´sredniej wielko´sci oprogramowanie, najcz ˛e´sciej dla
biznesu (wa˙zna szybko´s´c dostarczania i dostosowanie do
cz ˛estych zmian).

Extreme Programming (XP) nale˙zy do grupy metodologii
wytwarzania oprogramowania nazywanych metodami
zwinnymi (agile methods)

Modele cyklu ˙zycia

oprogramowania

Przypomnienie: proces
produkcji; czynno´sci a
modele

Podział metodologii
tworzenia
oprogramowania

Proces ujednolicony
(Unified Process)

Metody zwinne (Agile)

Inne metodologie

Podsumowanie

2.15

Programowanie ekstremalne - XP

Motywacja:

klasyczne metodologie wytwarzania oprogramowania zbyt
wolno reaguj ˛

a na zmiany rynku i wymaga ´n klientów

zbyt du˙zo planowania, analizy i tworzenia modeli oraz
dokumentacji opó´znia wytworzenie i dostarczenie tego co
naprawd ˛e si ˛e liczy – kodu

klasyczne podej´scia powoduj ˛

a, ˙ze zmiany (spowodowane

np. wykryciem bł ˛edu) w pó´znych fazach tworzenia kodu s ˛

bardzo kosztowne

w procesach opartych na drobiazgowej analizie i
planowaniu zbyt mało ufa si ˛e i daje swobody, tym którzy
tak naprawd ˛e tworz ˛

a kod – programistom

Modele cyklu ˙zycia

oprogramowania

Przypomnienie: proces
produkcji; czynno´sci a
modele

Podział metodologii
tworzenia
oprogramowania

Proces ujednolicony
(Unified Process)

Metody zwinne (Agile)

Inne metodologie

Podsumowanie

2.16

Programowanie ekstremalne - XP

Podstawowe zasady:

oprogramowanie jest rozwijane w krótkich cyklach i w
ci ˛

agłej interakcji z klientem, po ka˙zdym cyklu mo˙ze

nast ˛

api´c zmiana zało˙ze ´n co do dalszej pracy, co wi ˛ecej

mo˙ze nast ˛

api´c rewizja ju˙z napisanego kodu (refactoring)

ka˙zdy przyrost dostarcza konkretn ˛

a funkcjonalno´s´c

okre´slan ˛

a na podstawie scenariuszy (opowie´sci

u˙zytkownika , user stories)

ju˙z pierwsze wydanie zawiera system o pewnej
cało´sciowej strukturze realizuj ˛

acy istotne dla klienta

funkcje

kolejne wydania (releases) kodu nast ˛epuj ˛

a co kilka

miesi ˛ecy (maximum), iteracje maj ˛

a po kilka tygodni,

obowi ˛

azuje planowanie zada ´n kilka dni do przodu, przy

zało˙zeniu, ˙ze kolejno´s´c działa ´n jest okre´slana przez
priorytety wa˙zno´sci

Modele cyklu ˙zycia

oprogramowania

Przypomnienie: proces
produkcji; czynno´sci a
modele

Podział metodologii
tworzenia
oprogramowania

Proces ujednolicony
(Unified Process)

Metody zwinne (Agile)

Inne metodologie

Podsumowanie

2.17

Programowanie ekstremalne - XP

Podstawowe zasady:

przed przyst ˛

apieniem do kodowania opracowywane s ˛

szczegółowe testy maj ˛

ace za zadanie sprawdzenie

wszelkich aspektów poprawno´sci wprowadzanych zmian

ka˙zda zmiana jest od razu integrowana z cało´sci ˛

a kodu

oraz testowana – nowe oraz opracowane wcze´sniej testy
(zautomatyzowane) s ˛

a powtarzane codziennie (lub nawet

kilka razy dziennie), ˙zeby sprawdzi´c czy nie zostały
wprowadzone bł ˛edy

w ci ˛

agu całego procesu gromadzona jest informacja

zwrotna słu˙z ˛

aca usprawnieniu procesu i ostatecznego

kodu

wa˙zna jest specyficzna organizacja miejsca pracy

kodowanie realizowane jest zgodnie z przyj ˛etymi przez
cały zespół regułami (coding standards)

Modele cyklu ˙zycia

oprogramowania

Przypomnienie: proces
produkcji; czynno´sci a
modele

Podział metodologii
tworzenia
oprogramowania

Proces ujednolicony
(Unified Process)

Metody zwinne (Agile)

Inne metodologie

Podsumowanie

2.18

Programowanie ekstremalne - XP

Podstawowe zasady:

programowanie odbywa si ˛e parami (zgodnie ze
szczegółowo ustalonymi zasadami), cz ˛este s ˛

a tak˙ze

dyskusje pomi ˛edzy członkami całego zespołu tworz ˛

acego

kod

dokumentacja oprogramowania składa si ˛e z komentarzy w
kodzie, opisu testów i niewiele wi ˛ecej

Modele cyklu ˙zycia

oprogramowania

Przypomnienie: proces
produkcji; czynno´sci a
modele

Podział metodologii
tworzenia
oprogramowania

Proces ujednolicony
(Unified Process)

Metody zwinne (Agile)

Inne metodologie

Podsumowanie

2.20

Programowanie ekstremalne - XP

Troska o programistów:

40sto godzinny tydzie ´n pracy - mamy za du˙zo pracy
zamiast mamy za mało czasu

odpowiednie ´srodowisko pracy - otwarta przestrze ´n z
małymi prywatnymi pomieszczeniami na obrze˙zach i
stanowiskami w ´srodku dla programowania parami

wspólne posiadanie kodu

nacisk na nieustann ˛

a komunikacj ˛e (zwi ˛

azane m.in. z

programowaniem parami)

stworzenie ideologii zespołu walcz ˛

acego o zwyci ˛estwo (i

nagradzaj ˛

acego si ˛e za wszystkie osi ˛

agni ˛ecia)

du˙zo jedzenia i picia w zasi ˛egu r ˛eki

zasada work with human nature, not against it

Modele cyklu ˙zycia

oprogramowania

Przypomnienie: proces
produkcji; czynno´sci a
modele

Podział metodologii
tworzenia
oprogramowania

Proces ujednolicony
(Unified Process)

Metody zwinne (Agile)

Inne metodologie

Podsumowanie

2.28

Istotne czynniki podczas wyboru modelu tworzenia
oprogramowania

Tematyka

Wielko´s´c (obszerno´s´c)

Czas trwania

Zło˙zono´s´c

Ryzyko (poziom i rodzaj)

Zrozumienie wymaga ´n u˙zytkownika

Zrozumienie obszaru zastosowa ´n

Zaanga˙zowanie klienta

Do´swiadczenie zespołu

Wielko´s´c zespołu

Interakcje człowiek-komputer

Dost ˛epno´s´c narz ˛edzi i technologii

Wymagany poziom niezawodno´sci

Wzorce projektowe

●

nazwa wzorca

●

problem – opisuje sposoby rozpoznawania sytuacji, w których
możemy zastosować dany wzorzec oraz warunki jakie muszą
zostać spełnione, by jego zastosowanie miało sens;

●

rozwiązanie – opisuje elementy rozwiązania: ich relacje,
powiązania oraz obowiązki, zawiera także wskazówki
implementacyjne dla różnych technologii;

●

konsekwencje – zestawienie wad i zalet stosowania wzorca,
uwzględniające informacje o jego brakach oraz kosztach
rozwoju i utrzymania systemu wykorzystującego dany
wzorzec.

Wzorce projektowe

●

Wzorce kreacyjne

●

Wzorce strukturalne

●

Wzorce czynnościowe

●

Wzorce współbieżności

Wzorce projektowe

Wzorce kreacyjne

●

Budowniczy

●

Fabryka abstrakcyjna

●

Metoda wytwórcza (klasowy)

●

Prototyp

●

Singleton

Wzorce projektowe

Wzorce strukturalne

●

Adapter (klasowy także)

●

Dekorator

●

Fasada

●

Kompozyt

●

Most

●

Pełnomocnik

●

Pyłek

Wzorce projektowe

Wzorce czynnościowe

●

Interpreter (klasowy)

●

Iterator

●

Łańcuch zobowiązań

●

Mediator

●

Metoda szablonowa

●

Obserwator

●

Odwiedzający

●

Pamiętka

●

Polecenie

●

Stan

●

Strategia

●

RAII

Wzorce projektowe

Wzorce współbieżności

●

Aktywny obiekt,

●

Asynchroniczne sterowanie przez zdarzenia,

●

Udaremnianie,

●

Blokada z podwójnym zatwierdzaniem,

●

Ochraniane wstrzymywanie,

●

Obiekt monitorujący,

●

Blokada zapisu i odczytu,

●

Zarządca procesów,

●

Pula wątków,

●

Pamięć dla wątków,

●

Reaktor

Agenda

●

Weryfikacja i zatwierdzanie

–

Testowanie oprogramowania

●

Zarządzanie

–

Zarządzanie personelem

–

Szacowanie kosztu oprogramowania

–

Zarządzanie jakością

–

Ulepszanie procesu

●

Ewolucja ...

Agenda

●

Ewolucja

–

Systemy odziedziczone

–

Modyfikacja oprogramowania

–

Restrukturyzacja oprogramowania

–

Zarządzanie konfiguracjami

Weryfikacja i zatwierdzanie

●

Co to jest weryfikacja?

●

Czym się różni od zatwierdzania?

●

Z czego wynika przewaga kontroli nad testowaniem?

●

Jak wykrywać defekty w programie podczas kontroli?

●

Jaka jest wzajemna relacja kontroli i testowania?

●

Co to jest analiza statyczna – jak jej używać jako
istotnego elementu weryfikacji?

●

Jaka jest istota metodologii Cleanroom?

Weryfikacja a zatwierdzanie

Zatwierdzanie:

–

Czy budujemy odpowiedni produkt?

(CO budujemy?)

Weryfikacja:

–

Czy budujemy produkt odpowiednio?
(JAK to budujemy?)

Weryfikacja a zatwierdzanie

Weryfikacja:

–

Czy oprogramowanie zgodne ze specyfikacją?

–

Zaczyna się od weryfikacji wymagań

–

Trwa przez wszystkie czynności procesu tworzenia
oprogramowania

Weryfikacja a zatwierdzanie

Zatwierdzanie:

–

Podobny okres trwania

–

Bardziej ogólny proces

–

Czy oprogramowanie spełnia oczekiwania klienta?
(nie tylko czy spełnia formalne wymagania)

Weryfikacja i zatwierdzanie

●

Metody sprawdzania i analizy systemu:

–

Kontrole oprogramowania (inspekcje)

●

Sprawdzanie dokumentacji, diagramów

●

Analizy kodu

●

Nie potrzeba działającego programu

–

Testowanie oprogramowania

●

Dotyczy wykonywalnej wersji systemu

●

Oparte na uruchamianiu programu

Kontrola i testowanie

Kontrola:

●

Bada źródła systemu (model, kod)

●

Jest tańsze niż testowanie

●

Wykrywa więcej błędów

–

Nieformalna kontrola ponad 60%

–

Formalna (matematyczna) ponad 90%

●

Wiele różnych defektów można wykryć w czasie jednej
kontroli

●

Uwzględniają wielokrotne użycie wiedzy dziedzinowej

●

Pozwalają wykazać jakościowe cechy programu

Kontrola i testowanie

Testowanie:

●

Jest jedyną metodą możliwą do zastosowania na
poziomie całego systemu

●

Pozwala na zatwierdzenie dynamicznego stanu systemu

●

Pozwala ocenić niezawodność systemu, analizę
efektywności, zatwierdzenie interfejsu użytkownika.

●

Pozwala zweryfikować zgodność z oczekiwaniami
użytkownika

Proces kontroli

Powinien być przeprowadzony przez zespół przynajmniej 4
osób. Role w zespole:

●

Autor/właściciel – odpowiada za usunięcie znalezionych
defektów

●

Kontroler – znajduje błędy, pominięcia, niespójności

●

Czytelnik – interpretuje kod w trakcie spotkania kontrolnego

●

Pisarz – odnotowuje rezultaty spotkania kontrolnego

●

Przewodniczący/moderator – zarządza procesem i ułatwia
kontrolę, informuje naczelnego moderatora o wynikach
procesu.

●

Naczelny moderator – odpowiada za ulepszanie procesu
kontroli, aktualizację list kontrolnych, standardy

Automatyczna analiza statyczna

Wykorzystuje narzędzia programowe, które przeglądają
kod źródłowy programu i wykrywają potencjalne usterki i
anomalie.

●

Analiza przepływu sterowania

●

Analiza użycia danych

●

Analiza interfejsu

●

Analiza przepływu informacji

●

Analiza ścieżek

Automatyczna analiza statyczna

Analiza statyczna najlepiej sprawdza się w językach bez
ścisłej kontroli typów

●

C (w mniejszym stopniu C++)

●

FORTRAN

●

języki interpretowalne bez ścisłych typów

●

Najbardziej znanym jest LINT (unix/linux, język C)

Metoda Cleanroom

●

Podstawą jest unikanie defektów oprogramowania dzięki
rygorystycznej kontroli

1) Specyfikacja formalna

2)Tworzenie przyrostowe
3)Programowanie strukturalne

4)Weryfikacja statyczna

5)Testowanie statystyczne systemu.

Zarządzanie

●

Zarządzanie personelem

●

Szacowanie kosztu oprogramowania

●

Zarządzanie jakością

●

Ulepszanie procesu

Zarządzanie personelem

●

Personel to najważniejsze dobro firmy

●

Złe zarządzanie personelem jest podstawową przyczyną
niepowodzeń

●

Menedżerowie muszą

–

ludzi motywować

–

planować i organizować pracę

–

dbać by praca była wykonana rzetelnie

Szacowanie kosztu

oprogramowania

Różne metody:

●

Metoda delficka – wspólne oszacowanie niezleżnych
ekspertów

●

Model COCOMO II – na podstawie rozmiaru
oprogramowania

●

Use Case Points – w oparciu i specyfikacje wymagań

●

Gra Planistyczna – klient wybiera w oparciu o
szacowanie dostawcy oprogramowania

Szacowanie kosztu

oprogramowania

Jakie są miary kosztu oprogramowania?

●

SLOC (source lines of code)

●

Czas (osobo-godziny)

●

Pieniądze ($$)

●

http://csse.usc.edu/tools/COCOMOII.php

Systematyczne podejście do

planowania

1.Szacowanie rozmiaru

(SLOC lub inne metryki)

2.Szacowanie pracochłonności

Na podstawie metryki przy pomocy dostępnych modeli

zamienia się rozmiar na pracochłonność.

3.Szacowanie harmonogramu

Posiadając wymaganą pracochłonność oraz dostępne

zasoby (ludzkie) można zaplanować harmonogram
wykonania.

Metoda delficka

●

Koniec lat 40-tych

●

Kilku niezależnych ekspertów szacuje rozmiar według
wspólnej metryki

●

Następnie należy dojść do konsensusu

Metoda delficka

1. Indywidualna analiza dokumentacji

2. Dyskusja w grupie nt. Analizy

3. Głosowanie oszacowania (tajne)
4. Opracowanie raportów przez moderatora

5. Dyskusja ekspertów nt. wyników (bez podawania

oszacowań)

6. Oszacowanie końcowe lub powtórzenie procedury

Oszacowanie = (Pesymista + 4*Średnia + Optymista)/6

7.1

Wykład 7

Testowanie oprogramowania.

In˙zynieria oprogramowania
MIS-1-502-s MIO-1-505-s MIS-1-505-n
Listopad 2014

Kazimierz Michalik

Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie

7.3

Standard

Zasadniczo testowanie jest ju˙z bardzo ugruntowan ˛

a wiedz ˛

a...

ISOIECIEEE 29119 Software Testing

ISOIEC 29119-1: Concepts & Definitions (published
September 2013)

ISOIEC 29119-2: Test Processes (published September
2013)

ISOIEC 29119-3: Test Documentation (published
September 2013)

ISOIEC 29119-4: Test Techniques (at DIS stage,
anticipating publiation in late 2014)

ISOIEC 29119-5: Keyword Driven Testing (at CD stage,
anticipating publication in 2015)

7.4

Metody testowania.

Testowanie statyczne

Testowanie dynamiczne

Black-box testing

White-box testing

Grey-box testing

7.7

Poziomy testowania.

Testowanie jednostkowe (unit testing)

Testowanie integracyjne (integration testing)

Testowanie komponentów (component intf. testing)

Testowanie systemowe (system testing)

Testowanie akceptacyjne (acceptance testing)

Testowanie behawioralne (behaviour testing)

7.10

Typy testów

Testy instalacyjne

Testy kompatybilno´sci

Testy regresyjne

Testy akceptacyjne

Testy alfa

Testy beta

Testy funkcjonalne i niefunkcjonalne.

Testy wydajno´sciowe (obci ˛

a˙zeniowe, obj ˛eto´sciowe,

skalowalno´sci)

Testy u˙zyteczno´sci

Testy dost ˛epno´sci

Testy wariacyjne (A/B testing)

Testy równoległo´sci

7.11

Podej ´scia do testowania

Bottom-up testing.

Najni˙zsze (najmniejsze) fragmenty kodu s ˛

a testowane

najpierw, nast ˛epnie coraz wi ˛eksze.

Top-Down testing.

Najpierw testowany jest system jako cało´s´c, a nast ˛epnie
indywidualnie s ˛

a dokładnie testowane cz ˛e´sci składowe

systemu, a nast ˛epnie ich składowe itd.

7.12

Testy automatyczne

test-driven development

continous integration

continous deployment

7.13

Metryki oprogramowania.

Ilo´s´c Bug’ów na lini ˛e kodu.

Pokrycie kodu (code coverage)

Spójno´s´c

G ˛esto´s´c komentarzy

Zło˙zono´s´c cyklomatyczna

DSQI - Design Structure Quality Index

Ilo´s´c punktów funkcyjnych

SLOC lub k-LOC - ilo´s´c linii kodu

Rozmiar programu

Czas wykonania programu

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.1

Wykład 3

Wymagania

MIS-1-505-n In˙zynieria oprogramowania
Pa´zdziernik 2014

Kazimierz Michalik

Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.3

Czynno ´sci w czasie produkcji oprogramowania.

In˙zynieria oprogramowania stara si ˛e zidentyfikowa´c i opisa´c
podstawowe fazy tworzenia i funkcjonowania oprogramowania,
a tak˙ze wskaza´c model optymalnego przebiegu tych faz.

Co mo˙zna robi ´c w czasie tworzenia oprogramowania?

Planowanie (w tym opracowanie wymaga ´n).

Implementacja.

Testowanie.

Dokumentowanie.

Wdro˙zenie.

Utrzymanie (konserwacja).

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.5

Wymagania funkcjonalne i niefunkcjonalne.

Wymagania funkcjonalne

S ˛

a stwierdzeniami, jakie usługi ma oferowa´c system, jak ma

reagowa´c na okre´slone dane wej´sciowe oraz jak ma si ˛e
zachowywa´c w okre´slonych sytuacjach. Opisuj ˛

funkcjonalno´s´c lub usługi, które system powinien oferowa´c.

Wymagania niefunkcjonalne

Ograniczenia usług i funkcji systemu. Obejmuj ˛

a ograniczenia

czasowe, ograniczenia procesu tworzenia, standardy itd. Mog ˛

by´c zwi ˛

azane z wła´sciwo´sciami systemu (niezawodno´s´c, czas

reakcji, zaj ˛eto´s´c pami ˛eci itd.), definiowa´c ograniczenia systemu
itp. Nie dotycz ˛

a bezpo´srednio funkcji systemu.

Wymagania dziedzinowe.

Pochodz ˛

a z dziedziny zastosowania systemu i odzwierciedlaj ˛

jej charakterystyk˛e. Mog ˛

a mog ˛

a by´c funkcjonalne lub

niefunkcjonalne.

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.6

Wymagania u˙zytkownika.

Wymagania u˙zytkownika

Wyra˙zanie w j ˛ezyku naturalnym oraz diagramy o usługach
oczekiwanych od systemu oraz o ograniczeniach, w których
system ma działa´c.

do´s´c wysoki poziom abstrakcji

nie powinny z góry definiowa´c rozwi ˛

aza ´n

powinno da´c si ˛e spełni´c takie wymagania korzystaj ˛

ac z

ró˙znych podej´s´c

wymagaj ˛

a u´sci´slenia

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.7

Wymagania systemowe.

Wymagania systemowe

Szczegółowo ustalaj ˛

a usługi systemu i ograniczenia.

Dokumentacja wymaga ´n systemowych (specyfikacja
funkcjonalna) powinna by´c precyzyjna. Mo˙ze słu˙zy´c jako
kontrakt mi ˛edzy nabywc ˛

a systemu a wytwórc ˛

Specyfikacja projektu oprogramowania.

Abstrakcyjny opis projektu oprogramowania, który jest
podstaw ˛

a bardziej szczegółowego projektu i implementacji.

Poszerza specyfikacj ˛e wymaga ´n systemowych.

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.8

Dokumentacja wymaga ´

n (IEEE/ANSI 830-1993)

Wst ˛ep.

Ogólny opis.

Wizja produktu.

Funkcje produktu.

Charakterystyka u˙zytkowników.

Ogólne ograniczenia.

Zało˙zenia i zale˙zno´sci.

Szczegółowe wymagania.

Wymagania funkcjonalne, niefunkcjonalne, interfejsy etc.

Najbardziej istotna cz ˛e´sci dokumentu. Definicja jak powinna
wygl ˛

ada´c ta cz ˛e´s´c nie jest zalecana, poniewa˙z mocno zale˙zy

do praktyki w firmie i dziedziny zagadnie ´n.

Dodatki.

Skorowidz.

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.9

In˙zynieria wymaga ´

Proces, który obejmuje wszystkie czynno´sci niezb ˛edne do
opracowania i aktualizacji dokumentacji wymaga ´n
systemowych.

4 główne czynno´sci:

Studium wykonalno´sci.

Okre´slenie i analizowanie wymaga ´n.

Specyfikowania i dokumentowanie wymaga ´n.

Zatwierdzanie wymaga ´n.

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.10

Studium wykonalno ´sci.

Krótki, skumulowane opracowanie, w którym staramy si ˛e
odpowiedzie´c na pytania:

Czy system przyczyni si ˛e do realizacji ogólnych celów
(przedsi ˛ebiorstwa)?

Czy system mo˙ze by´c zaimplementowany z u˙zyciem
dost ˛epnych technologii, w ramach ustalonego bud˙zetu i
ogranicze ´n czasowych?

Czy system mo˙ze by´c zintegrowany z istniej ˛

acymi

systemami, które ju˙z zainstalowano?

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.11

Okre ´slenie i analiza wymaga ´

Rozpoznanie dziedziny

Analitycy musz ˛

a zrozumie´c dziedzin ˛e

zastosowania.

Zbieranie wymaga ´n

Proces interakcji z uczestnikami systemu,

którego celem jest ujawnienie wymaga ´n.

Klasyfikacja

Podział na grupy.

Usuwanie sprzeczno´sci

Wymagania podane przez ró˙zne

grupy nieuchronnie b ˛edzie zawiera´c
sprzeczno´sci.

Nadawanie priorytetów

Interakcja z uczestnikami w celu

wskazania najwa˙zniejszych wymaga ´n w grupie.

Sprawdzanie wymaga ´n

Czy wymagania s ˛

a spójne i zgodne z

tym czego uczestnicy chc ˛

a od systemu.

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.12

Zatwierdzanie wymaga ´

Czy wymagania naprawd ˛e definiuj ˛

a system, którego chce

u˙zytkownik?

Sprawdzenie wa˙zno´sci.

Sprawdzenie niesprzeczno´sci.

Sprawdzenie kompletno´sci.

Sprawdzenie realno´sci.

Mo˙zliwo´s´c weryfikacji.

Metody sprawdzania wymaga ´n:

Przegl ˛

ad wymaga ´n.

Prototypowanie.

Generowanie testów.

Zautomatyzowane sprawdzanie niesprzeczno´sci.

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.13

Zarz ˛

adzanie wymaganiami.

Zmiany gospodarcze, organizacyjne i technologiczne
nieuchronnie prowadz ˛

a do zmian wymaga ´n stawianych

oprogramowaniu.

Zarz ˛

adzanie wymaganiami to proces kierowania i

panowania nad tymi zmianami.

Proces zarz ˛

adzania wymaganiami obejmuje:

planowanie, w trakcie którego specyfikuje si ˛e proces
zarz ˛

adzania i zarz ˛

adzanie zmianami

Analiza problemu u specyfikacja zmiany.

Analiza zmiany i ocena kosztów.

Implementacja zmiany.

zarz ˛

adzanie zmianami, które polega na analizowaniu zmian

i szacowaniu ich wpływu

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.14

Co to s ˛

a modele?

Model systemu

Graficzna reprezentacja na której przedstawia si ˛e, problem do
rozwi ˛

azania i system do zbudowania.

bardziej zrozumiałe ni˙z szczegółowy opis wymaga ´n

etap po´sredni mi ˛edzy analiz ˛

a a projektowaniem

słu˙z ˛

a wypracowaniu lepszego zrozumienia systemu

mog ˛

a słu˙zy´c do zobrazowania systemu z ró˙znych punktów

widzenia:

Zewn ˛etrznego (modeluje si ˛e kontekst lub ´srodowisko
systemu).

Zachowania (modeluje si ˛e zachowanie systemu).

Strukturalnego (architektura systemu lub struktura danych).

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.15

Modele kontekstowe.

nale˙zy ustali´c granice systemu

rozró˙zni´c co jest systemem a co jego ´srodowiskiem

nale˙zy opracowa´c prosty model architektoniczny

opisuje si ˛e ´srodowisko systemu, nie współprac ˛e
system-otoczenie

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.17

Modele zachowania.

Model przepływu danych.

pokazuj ˛

a jak dane przepływaj ˛

a w sekwencji kroków

przetwarzania

jak dane podlegaj ˛

a przekształceniu

w modelu analitycznym "kroki"to przetwarzanie przez ludzi
i komputery

w dokumentacji projektowej"kroki"to funkcje/metody
programu

Model maszyn stanowych.

słu˙z ˛

a do opisywania zachowania systemu

jak reaguje na zewn ˛etrzne i wewn ˛etrzne bod´zce

zawiera stany(1) i zdarzenia (2), które powoduj ˛

a przej´scia

z jednego stanu do drugiego

nie obejmuje przepływu danych w ramach systemu

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.20

Modele obiektowe.

mog ˛

a przedstawia´c sam system (diagramy struktur) jak i

jego działanie(diagramy zachowa ´n)

posługuj ˛

a si ˛e poj ˛eciem klasy i obiektu.

Klasa obiektu.

Abstrakcja zbioru obiektów, która identyfikuje ich wspólne
atrybuty (w znaczeniu modelu danych) oraz usługi i operacje
oferowane przez te obiekty.

Obiekt

Wykonywalna encja, posiadaj ˛

aca atrybuty i operacje klasy.

Egzemplarz klasy obiektów. Wiele obiektów mo˙ze powsta´c z
tej samej klasy.

na ogół modele analityczne s ˛

a po´swi ˛econe klasom

obiektów i ich zwi ˛

azkom

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.24

CASE.

Narz ˛edzia CASE.

Narz ˛edzia Computer Aided Software Engineering to zbiór
narz ˛edzi, które wspomagaj ˛

a konkretny etap procesu tworzenia

oprogramowania. Cz ˛esto ł ˛

aczone w jeden zestaw narz ˛edzi

(warsztat). Zestaw narz ˛edzi CASE do analizy i projektowania,
zawiera:

Edytory diagramów.

Narz ˛edzia do analizy i sprawdzania projektu.

J ˛ezyki zapyta ´n do repozytorium.

Słownik danych.

Narz ˛edzia do definiowania i generowania raportów.

Narz ˛edzia do definiowania formularzy.

Udogodnienia do importu i eksportu.

Generatory kodu.

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.25

Prototypowanie w procesie tworzenie oprogramowania.

Prototypowanie ewolucyjne.

Celem jest dostarczenie u˙zytkownikowi działaj ˛

acego systemu.

Zaczyna si ˛e od tych wymaga ´n, które s ˛

a najlepiej rozpoznane i

maj ˛

a najwy˙zszy priorytet. Wymagania mniej jasne lub o

mniejszym priorytecie s ˛

a implementowane tylko gdy za˙z ˛

adaj ˛

tego u˙zytkownicy.

Prototypowanie z porzuceniem.

Celem jest zatwierdzenie lub dostarczenie wymaga ´n
systemowych. Zaczyna si ˛e od tych wymaga ´n, które nie s ˛

dobrze rozpoznane, aby dowiedzie´c si ˛e wi ˛ecej. Wymagania
oczywiste nie musz ˛

a podlega´c prototypowaniu.

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.26

Metody błyskawicznego prototypowania.

Metody tworzenia, których przeznaczeniem jest skrócenie
czasu dostarczania, a nie poprawa wła´sciwo´sci systemu
(efektywno´sci, niezawodno´sci itd...)

Istniej ˛

a trzy główne metody błyskawicznego prototypowania:

Tworzenie za pomoc ˛

a dynamicznych j ˛ezyków wysokiego

poziomu.

Programowanie baz danych.

Scalanie komponentów i programów u˙zytkowych.

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

4.1

Wykład 4

Projektowanie

MIS-1-505-n In˙zynieria oprogramowania
Pa´zdziernik 2014

Kazimierz Michalik

Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

4.4

Implementacja = Projektowanie + Programowanie

Implementacja

= Projektowanie + Programowanie

Projekt to opis:

struktury oprogramowania

danych w systemie

interfejsów mi ˛edzy komponentami

u˙zytych algorytmów

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

4.5

Projektant nie tworzy od razu ko ´

ncowego projektu!

Projekt opracowuje si ˛e iteracyjnie w czasie

Projekt mo˙ze mie´c wiele ró˙znych wersji

W miar ˛e upływu czasu projekt jest coraz bardziej formalny
i szczegółowy

Powraca si ˛e do ju˙z opracowanych fragmentów w celu ich
poprawy

Sprz ˛e˙zenie zwrotne mi ˛edzy fazami projektowania i powtarzanie
prac s ˛

a nieuniknione w ka˙zdym procesie projektowania!

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

4.6

Wyró˙zniamy ró˙zne rodzaje projektowania:

Projektowanie architektoniczne (Architektury systemów
rozproszonych)

Projektowanie obiektowe

Projektowanie oprogramowania czasu rzeczywistego

Projektowanie z u˙zyciem wielokrotnym

Projektowanie interfejsu u˙zytkownika

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

4.7

Czynno ´sci procesu projektowania:

Projektowanie architektury

Specyfikowanie abstrakcyjne

Projektowanie interfejsów

Projektowanie komponentów

Projektowanie struktur danych

Projektowanie algorytmów

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

4.8

Metoda ad hoc:

Nieformalny projekt

Projekt jest zmieniany w miar ˛e programowania

Nie ma formalnej kontroli zmian

Nie ma zarz ˛

adzania projektem

Po zako ´nczeniu fazy implementacji projekt jest najcz ˛e´sciej
niepoprawny i niekompletny

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

4.9

Metody strukturalne

Graficzne modele systemu

Du˙za ilo´s´c dokumentacji projektowej

Obejmuj ˛

a modele przepływu danych, model

encja-zwi ˛

azek, model strukturalny, modele dziedziczenia,

statycznych i dynamicznych zwi ˛

azków i inne.

Przykładowe metody strukturalne:

Structured Design
Structured System Analysis
Jackson System Development

Ró˙zne dla projektowania obiektowego

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

4.10

Co to jest projektowanie architektoniczne?

Systemy s ˛

a podzielone na podsystemy, powi ˛

azane

poprzez interfejsy.

Definicja

Pocz ˛

atkowa faza procesu projektowania, w której identyfikuje

si ˛e podsystemy i ustala zr ˛

ab sterowania oraz komunikacji to

projektowanie architektoniczne.

Produktem tej fazy jest opis architektury oprogramowania.

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

4.11

Zalety projektowania architektonicznego

Komunikacja z uczestnikami

Podstawa do dyskusji na bardzo ró˙znych poziomach

Analiza systemu

Ujawnienie architektury we wczesnej fazie pozwala na
przeprowadzenie analizy pod k ˛

atem krytycznych cech systemu

U˙zycie wielokrotne w wielkiej skali

Architektura jest zwartym i łatwym do opanowania opisem
organizacji systemu i współpracy komponentów

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

4.12

Czynno ´sci projektowania architektonicznego

Strukturalizacja systemu

Modelowanie sterowania

Podział na moduły

Podsystem a moduł:

Podsystem

: jego usługi nie zale˙z ˛

a od usług oferowanych

przez inne systemy; składa si ˛e z modułów; maj ˛

interfejsy do komunikacji z innymi podsystemami

Moduł

: komponent systemu; oferuje co najmniej jedn ˛

usług ˛e innym modułom; korzysta z innych
modułów; zwykle nie jest traktowany jako
niezale˙zny system

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

4.14

Projektowanie obiektowe

jest to strategia projektowania, w której projektanci systemu
my´sl ˛

a w kategoriach „bytów”, a nie operacji albo funkcji

Działaj ˛

acy system składa si ˛e z oddziałuj ˛

acych na siebie

obiektów.

Obiekty przechowuj ˛

a swój lokalny stan i oferuj ˛

a operacje

na tym stanie

Obiekty ukrywaj ˛

a informacje o reprezentacji stanu i

ograniczaj ˛

a do niego dost ˛ep.

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

4.15

Projektowanie obiektowe

Jest cz ˛e ´sci ˛

a tworzenia obiektowego

w którym strategie obiektowe s ˛

a stosowane w czasie całego

procesu tworzenia:

Analiza obiektowa

Projektowanie obiektowe

Programowanie obiektowe

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

4.16

Projektowanie obiektowe: pierwsze pi ˛e ´c zasad

S.O.L.I.D.

– SRP – Single responsibility principle

– OCP – Open/closed principle

– LSP – Liskov substitution principle

– ISP – Interface segregation principle

– DIP – Dependency inversion principle

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

4.17

SRP

Single responsibility principle

a class should have only a single responsibility (i.e. only one
potential change in the software’s specification should be able
to affect the specification of the class)

Zasada pojedynczej odpowiedzialno ´sci

Nigdy nie powinno by´c wi ˛ecej ni˙z jednego powodu do
modyfikacji klasy.

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

4.18

OCP

Open/closed principle

“software entities . . . should be open for extension, but closed
for modification.”

Zasada otwarte-zamkni ˛ete

elementy systemu takie, jak klasy, moduły, funkcje itd. powinny
by´c otwarte na rozszerzenie, ale zamkni ˛ete na modyfikacje

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

4.19

LSP

Liskov substitution principle

“objects in a program should be replaceable with instances of
their subtypes without altering the correctness of that program.”

Zasada podstawienia Liskov

Funkcje które u˙zywaj ˛

a wska´zników lub referencji do klas

bazowych, musz ˛

a by´c w stanie u˙zywa´c równie˙z obiektów klas

dziedzicz ˛

acych po klasach bazowych, bez dokładnej

znajomo´sci tych obiektów.

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

4.20

ISP

Interface segregation principle

“many client-specific interfaces are better than one
general-purpose interface".

Zasada segregacji interfejsów

wiele interfejsów odpowiadaj ˛

acych konkretnym potrzebom jest

lepsze ni˙z jeden ogólny interfejs do wszystkiego

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

4.21

DIP

Dependency inversion principle

one should “Depend upon Abstractions. Do not depend upon
concretions.”

Zasada odwrócenia zale˙zno ´sci

Zale˙zno´sci powinny opiera´c si ˛e na abstrakcjach, a nie na ich
konkretnych realizacjach.

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

4.22

G.R.A.S.P.

GRASP

General Responsibility Assignment Software Patterns (or
Principles)

Controller

Creator

High Cohesion

Indirection

Information Expert

Low Coupling

Polymorphism

Protected Variations

Pure Fabrication

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

wzorce projektowe.

Wprowadzenie

GRASP

Stosowanie zasad

5.1

Wykład 5

Projektowanie obiektowe: Zasady i
sk ˛

ad si ˛e bior ˛

a wzorce projektowe.

In˙zynieria oprogramowania
MIS-1-502-s MIO-1-505-s MIS-1-505-n
Listopad 2014

Kazimierz Michalik

Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

wzorce projektowe.

Wprowadzenie

GRASP

Stosowanie zasad

5.3

Co to jest G.R.A.S.P.?

C. Larman: „Applying UML and Patterns”

„A Methodical Approach to Basic OO Design”.

„The GRASP principles or patterns are a learning aid to
help you understand essential object design and apply
design reasoning in a methodical, rational, explainable
way”.

C. Larman: „Applying UML and Patterns”

„Metodyczne podej´scie do podstaw projektowania
obiektowego.”.

„Zasady/wzorce GRASP s ˛

a pomoc ˛

a w zrozumieniu istoty

projektowania obiektowego i stosowania go w metodyczny,
racjonalny i zrozumiały sposób".

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

wzorce projektowe.

Wprowadzenie

GRASP

Stosowanie zasad

5.4

Co to s ˛

a wzorce projektowe?

Wzorzec projektowy

uniwersalne, sprawdzone w praktyce rozwi ˛

azanie cz ˛esto

pojawiaj ˛

acych si ˛e, powtarzalnych problemów projektowych.

Pokazuje powi ˛

azania i zale˙zno´sci pomi ˛edzy klasami oraz

obiektami i ułatwia tworzenie, modyfikacj ˛e oraz piel ˛egnacj ˛e
kodu ´zródłowego. Jest opisem rozwi ˛

azania, a nie jego

implementacj ˛

a. Wzorce projektowe stosowane s ˛

a w projektach

wykorzystuj ˛

acych programowanie obiektowe.

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

wzorce projektowe.

Wprowadzenie

GRASP

Stosowanie zasad

5.5

G.R.A.S.P.

GRASP

General Responsibility Assignment Software Patterns (or
Principles)

Controller

Creator

High Cohesion

Indirection

Information Expert

Low Coupling

Polymorphism

Protected Variations

Pure Fabrication

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

wzorce projektowe.

Wprowadzenie

GRASP

Stosowanie zasad

5.6

G.R.A.S.P.

GRASP

Ogólne zasady przydzielania odpowiedzialno´sci w
oprogramowaniu.

Kontroler

Twórca

Wysoka spójno´s´c

Po´srednictwo

Expert

Mało powi ˛

aza ´n

Polimorfizm

Chroniona zmienno´s´c

Czyste wytwarzanie

Nazwy nie s ˛

a najwa˙zniejsze: najwa˙zniejszy jest sens tych

zasad.

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

wzorce projektowe.

Wprowadzenie

GRASP

Stosowanie zasad

5.7

1. Controller

Kontroler

Problem

który obiekt (za interfejsem u˙zytkownika)
powinien obsłu˙zy´c (przej ˛

a´c) operacj ˛e (np.:

zewn ˛etrzn ˛

a) systemu?

Rozwi ˛

azanie

Powinna to by´c klasa, która:

opisuje system jako cało´s´c reprezentuje
główny obiekt lub urz ˛

adzenie na którym

system działa albo
reprezentuje przypadek u˙zycia, w którym
wyst ˛epuje dana operacja

Opis

podstawowa zasada dotycz ˛

aca oddzielenia

interfejsu od logiki aplikacji. Jest realizowana w
wielu wzorcach min.: Model-Widok-Kontroler

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

wzorce projektowe.

Wprowadzenie

GRASP

Stosowanie zasad

5.8

2. Creator

Twórca

Problem

która klasa ma by´c odpowiedzialna za tworzenie
obiektów klasy A?

Rozwi ˛

azanie

Klasa B jest odpowiedzialna za tworzenie A, gdy:

klasa B komponuje lub agreguje (”ma”)
obiekty klasy A
B zapisuje/rejestruje/nadzoruje instancje
klasy A
B współpracuje (blisko!) z A
B ma dane potrzebne do inicjalizacji A
(patrz: Ekspert)

Opis

praktycznie ka˙zdy program obiektowy musi
tworzy´c obiekty; wła´sciwe zorganizowanie i
przypisanie które obiekty tworz ˛

a jakie inne

obiekty pozwala znacz ˛

aco zredukowa´c ilo´s´c

powi ˛

aza ´n mi ˛edzy klasami.

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

wzorce projektowe.

Wprowadzenie

GRASP

Stosowanie zasad

5.9

3. High Cohesion

Wysoka spójno ´s ´c

Problem

jak w praktyce zachowa´c klas ˛e skupion ˛

a na

jednej odpowiedzialno´sci, z przejrzyst ˛

implementacj ˛

a, zwi ˛ekszy´c szanse ponownego

u˙zycia?

Rozwi ˛

azanie

gdy masz wybór, przypisuj odpowiedzialno´s´c tak,
by klasa była skupiona na jednym zadaniu

Opis

Złamanie tej zasady to anty-wzorzec projektowy
"Blob": ma miejsce wtedy, gdy w programie
istnieje wiele klas, ale bardzo niewiele z nich (lub
jedna) ma dominuj ˛

ace znaczenie i zawiera si ˛e w

niej prawie cała istotna funkcjonalno´s´c. Takie
klasy nazywamy cz ˛esto (negatywnie)
super-klasa, klasa-bóstwo, boss-klasa etc. W
szczególno´sci NIGDY nie nale˙zy miesza´c w
jednej klasie logiki aplikacji (co aplikacja
naprawd ˛e robi) z dost ˛epem do danych (sk ˛

bierze dane) – podobno za to idzie si ˛e do
programistycznego piekła ;)

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

wzorce projektowe.

Wprowadzenie

GRASP

Stosowanie zasad

5.10

4. Indirection

Po ´srednictwo

Problem

jak unika´c zale˙zno´sci od klas dostarczaj ˛

acych

funkcjonalno´s´c w specyficzny sposób? jak
przerywa´c zbyt mocne zale˙zno´sci mi ˛edzy
klasami? jak korzysta´c z innych
klas/pakietów/usług bez dostosowywania si ˛e do
nich?

Rozwi ˛

azanie

nale˙zy stworzy´c nowy po´sredni obiekt, słu˙z ˛

acy

jako kanał komunikacji, tak by obiekty nie
kontaktowały si ˛e bezpo´srednio

Opis

aby obni˙zy´c ilo´s´c zale˙zno´sci mi ˛edzy klasami
mo˙zna umie´sci´c mi ˛edzy nimi klas ˛e, przez któr ˛

b ˛ed ˛

a si ˛e komunikowa´c. Zmniejsza si ˛e te˙z ogólna

ilo´s´c powi ˛

aza ´n (zachowanie Low Coupling), bo

jedna klasa warstwy po´sredniej mo˙ze
odpowiada´c paru klasom warstwy pierwotnej.
Przykładem s ˛

a wzorce projektowe typu: Most,

Fasada, Adapter.

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

wzorce projektowe.

Wprowadzenie

GRASP

Stosowanie zasad

5.11

5. Information Expert

Expert

Problem

której klasie przypisa´c dan ˛

a odpowiedzialno´s´c

(zadanie)?

Rozwi ˛

azanie

tej, która posiada najwi ˛ecej informacji
niezb ˛ednych do tego, by to zadanie wykona´c

Opis

Pochopne podejmowanie decyzji mo˙ze
spowodowa´c, ˙ze klasa aby wykona´c zadanie
b ˛edzie musiała przedosta´c si ˛e przez spory graf
obiektów, aby uzyska´c odpowiednie informacje.
Stosowanie zasady Expert pozwala
oddelegowa´c odpowiedzialno´s´c do podmiotu,
który na wst ˛epie jest najlepiej przygotowany do
jej podj ˛ecie (st ˛

ad: Ekspert - w sensie ”najlepszy

spo´sród wszystkich kandydatów”).

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

wzorce projektowe.

Wprowadzenie

GRASP

Stosowanie zasad

5.12

6. Low Coupling

Mało powi ˛

aza ´

Problem

jak utrzyma´c obiekty w niezale˙zno´sci od siebie?

Rozwi ˛

azanie

tak przypisuj odpowiedzialno´sci do obiektów, by
liczba powi ˛

aza ´n była jak najmniejsza

Opis

Klasa, która ma du˙zo powi ˛

aza ´n, jest zale˙zna od

wielu innych klas, co powoduje:

wiele lokalnych zmian spowodowanych
zmianami w klasach powi ˛

azanych;

klasy trudniejsze do zrozumienia w izolacji;

zmniejszony „reuse” (mo˙zliwo´s´c ponownego
wykorzystania), poniewa˙z najcz ˛e´sciej trzeba
jednocze´snie wykorzysta´c cz ˛e´s´c klas
powi ˛

azanych;

Klasa która ma za du˙zo powi ˛

aza ´n

prawdopodobnie jest ”przeci ˛

a˙zona”

obowi ˛

azkami, co implikuje złamanie zasady High

Cohesion.

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

wzorce projektowe.

Wprowadzenie

GRASP

Stosowanie zasad

5.13

7. Polymorphism

Polimorfizm

Problem

jak przypisa´c odpowiedzialno´s´c, która mo˙ze by´c
realizowana na kilka sposobów?

Rozwi ˛

azanie

przypisz odpowiedzialno´s´c do hierarchii
obiektów wykorzystuj ˛

ac polimorfizm wbudowany

w j ˛ezyki obiektowe

Opis

mechanizm polimorfizmu, pozwala
automatycznie decydowa´c o tym ”co si ˛e stanie w
czasie działania programu” na podstawie
informacji ”jaki rodzaj obiektu został przekazany”

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

wzorce projektowe.

Wprowadzenie

GRASP

Stosowanie zasad

5.14

8. Protected Variations

Chroniona zmienno ´s ´c

Problem

jak projektowa´c system, by umo˙zliwi´c
wprowadzanie zmiany, tak by nie wymuszała ona
zmian na innych obiektach?

Rozwi ˛

azanie

zidentyfikuj punkty przewidywanego
zró˙znicowania/niestabilno´sci i przypisz
odpowiedzialno´s´c do stabilnego interfejsu, a nie
konkretnych klas.

Opis

chodzi o to, by wymiana klasy A na klas ˛e B
oferuj ˛

ac ˛

a podobn ˛

a funkcjonalno´s´c była jak

najprostsza. Ta fundamentalna zasada implikuje
enkapsulacj ˛e, polimorfizm, data-driven desig, a
nawet pliki konfiguracyjne!

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

wzorce projektowe.

Wprowadzenie

GRASP

Stosowanie zasad

5.15

9. Pure Fabrication

Czyste wytwarzanie

Problem

jaki obiekt powinien otrzyma´c odpowiedzialno´s´c,
gdy nie chcemy złama´c High Cohesion i Low
Coupling, a proponowany Ekspert jest (z innych
przyczyn) nie do przyj ˛ecia?

Rozwi ˛

azanie

nale˙zy sztucznie ”wytworzy´c” now ˛

a ”czyst ˛

a”

klas ˛e (niezwi ˛

azan ˛

a z problemem) i jej przypisa´c

t ˛e odpowiedzialno´s´c

Opis

Ta zasada cz ˛esto jest u˙zywana jako ”złoty

´srodek” pozwalaj ˛