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
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:
Prehistoria. II wojna światowa.
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!
Historia Inżynierii Oprogramowania:
1990 – 2000: Orientowane Obiektowo
• Intensywne użytkownie CASE
• Projektowanie O.O.
• Narzędzia do inżynierii wymagań
• Wzrost popularności architektur
rozproszonych
• Universal Markup Language (UML)
• Java
Historia Inżynierii Oprogramowania:
2000+ : Współczesność
• Zintegrowane środowiska programistyczne
(IDE)
• UML 2.0
• Lekkie języki skryptowe
• Metodologie lekkie
• Zaawansowane metodologie hybrydowe
• Nowe platformy i języki: C# etc.
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
c
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
www.agh.edu.pl
Warunki zaliczenia przedmiotu (1)
www.agh.edu.pl
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
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.)
Dziękuję za uwagę
W przypadku sugestii, pytań lub spostrzeżenia
błędów: kontakt mailowy to kamich@agh.edu.pl
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.1
Wykład 2
Modele cyklu ˙zycia oprogramowania
MIS-1-505-n In˙zynieria oprogramowania
Marzec 2014
Kazimierz Michalik
Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.2
Agenda
1
Przypomnienie: proces produkcji; czynno ´sci a modele
2
Podział metodologii tworzenia oprogramowania
3
Proces ujednolicony (Unified Process)
4
5
6
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
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).
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
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
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.5
Ogólny schemat.
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
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
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.7
Model iteracyjny
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.7
Model iteracyjny
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.7
Model iteracyjny
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.7
Model iteracyjny
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.7
Model iteracyjny
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.7
Model iteracyjny
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.8
Model przyrostowy
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.8
Model przyrostowy
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.8
Model przyrostowy
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.8
Model przyrostowy
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.8
Model przyrostowy
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.8
Model przyrostowy
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.9
Zasady RUP.
1
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
2
zarz ˛
adzanie wymaganiami; we współpracy z klientem i w
oparciu o przypadki u˙zycia
3
stosowanie architektury opartej na komponentach
4
graficzne modelowanie oprogramowania; ró˙zne
perspektywy spojrzenia na system, u˙zycie UML
5
kontrola i weryfikacja jako´sci oprogramowania przez cały
czas procesu wytwarzania
6
zarz ˛
adzanie zmianami w oprogramowaniu
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.10
Fazy projektu RUP.
1
faza pocz ˛
atkowa (inception) – wst ˛epne okre´slenie
wymaga ´n, ryzyka, kosztu, harmonogramu, a tak˙ze
architektury systemu
2
faza opracowania (elaboration) – ustalenie wymaga ´n
(wi ˛ekszo´sci przypadków u˙zycia), architektury systemu
oraz planu całego procesu wytwarzania systemu
3
faza konstrukcji (construction) – tworzenie systemu
(kolejnych komponentów), w trakcie nastepuje oddanie
pierwszej (i by´c mo˙ze dalszych) wersji u˙zytkownikowi
4
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
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.11
Dyscypliny - rodzaje wykonywanych zada ´
n
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)
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.12
Schemat RUP.
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
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 ˛
a
dokumentacj ˛e
Współpraca z klientem ponad negocjacje kontraktu
Reagowanie na zmiany ponad realizowanie planu
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
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)
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
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 ˛
a
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
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
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
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.17
Programowanie ekstremalne - XP
Podstawowe zasady:
przed przyst ˛
apieniem do kodowania opracowywane s ˛
a
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)
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
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
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.19
Programowanie ekstremalne - XP
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
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
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.21
Scrum.
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.22
Model spiralny - zarz ˛
adzanie ryzykiem.
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.23
V(ee)-model.
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.24
Dual V(ee)-model.
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.25
Cleanroom model.
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.26
Rapid Application Development.
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
2.27
Continuous Integration (Continuous Delivery)
Przypomnienie: proces
produkcji; czynno´sci a
modele
Podział metodologii
tworzenia
oprogramowania
Proces ujednolicony
(Unified Process)
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
Projektowanie oprogramowania
Wyk ad 04
ł
In ynieria Oprogramowania
ż
Kazimierz Michalik
Wzorce projektowe
Katalog wzorców projektowych
●
Erich Gamma, Richard Helm, Ralph Johnson, John
Vlissides: Inżynieria oprogramowania: Wzorce
projektowe (Wyd. II). Warszawa: WNT, 2008. ISBN
978-83-204-3472-9.
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
Budowniczy
Metoda wytwórcza
Fabryka abstrakcyjna
Fasada
Singleton
Wzorce projektowe
Wzorce strukturalne
●
Adapter (klasowy także)
●
Dekorator
●
Fasada
●
Kompozyt
●
Most
●
Pełnomocnik
●
Pyłek
Adapter (klasowy)
Adapter
Pyłek
Model-View-Controller (pol.
Model-Widok-Kontroler)
Wzorce projektowe
Wzorce czynnościowe
●
Interpreter (klasowy)
●
Iterator
●
Łańcuch zobowiązań
●
Mediator
●
Metoda szablonowa
●
Obserwator
●
Odwiedzający
●
Pamiętka
●
Polecenie
●
Stan
●
Strategia
●
RAII
Strategia
Obserwator
Metoda szablonowa
Odwiedzający
Łańcuch zobowiązań
Polecenie
Stan
Pamiątka
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
Projektowanie oprogramowania
Wyk ad
ł
Weryfikacja i Zatwierdzanie
In ynieria Oprogramowania
ż
Kazimierz Michalik
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?)
vs
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
Ewolucja
Systemy odziedziczone
Modyfikacja oprogramowania
Restrukturyzacja oprogramowani
Zarządzanie konfiguracjami
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.2
Agenda
1
2
3
4
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.5
Metody testowania.
7.6
Metody testowania.
7.7
Poziomy testowania.
1
Testowanie jednostkowe (unit testing)
2
Testowanie integracyjne (integration testing)
3
Testowanie komponentów (component intf. testing)
4
Testowanie systemowe (system testing)
5
Testowanie akceptacyjne (acceptance testing)
6
Testowanie behawioralne (behaviour testing)
7.8
Poziomy testowania.
7.9
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
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
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
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
3.2
Agenda
1
Przypomnienie: proces produkcji: czynno ´sci i modele
2
Wymagania stawiane oprogramowaniu
3
4
5
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
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).
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
3.4
Ogólny schemat.
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
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 ˛
a
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 ˛
a
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 ˛
a
jej charakterystyk˛e. Mog ˛
a mog ˛
a by´c funkcjonalne lub
niefunkcjonalne.
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
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
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
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 ˛
a.
Specyfikacja projektu oprogramowania.
Abstrakcyjny opis projektu oprogramowania, który jest
podstaw ˛
a bardziej szczegółowego projektu i implementacji.
Poszerza specyfikacj ˛e wymaga ´n systemowych.
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
3.8
Dokumentacja wymaga ´
n (IEEE/ANSI 830-1993)
1
Wst ˛ep.
2
Ogólny opis.
1
Wizja produktu.
2
Funkcje produktu.
3
Charakterystyka u˙zytkowników.
4
Ogólne ograniczenia.
5
Zało˙zenia i zale˙zno´sci.
3
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.
4
Dodatki.
5
Skorowidz.
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
3.9
In˙zynieria wymaga ´
n.
In˙zynieria wymaga ´
n.
Proces, który obejmuje wszystkie czynno´sci niezb ˛edne do
opracowania i aktualizacji dokumentacji wymaga ´n
systemowych.
4 główne czynno´sci:
1
Studium wykonalno´sci.
2
Okre´slenie i analizowanie wymaga ´n.
3
Specyfikowania i dokumentowanie wymaga ´n.
4
Zatwierdzanie wymaga ´n.
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
3.10
Studium wykonalno ´sci.
Studium wykonalno ´sci.
Krótki, skumulowane opracowanie, w którym staramy si ˛e
odpowiedzie´c na pytania:
1
Czy system przyczyni si ˛e do realizacji ogólnych celów
(przedsi ˛ebiorstwa)?
2
Czy system mo˙ze by´c zaimplementowany z u˙zyciem
dost ˛epnych technologii, w ramach ustalonego bud˙zetu i
ogranicze ´n czasowych?
3
Czy system mo˙ze by´c zintegrowany z istniej ˛
acymi
systemami, które ju˙z zainstalowano?
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
3.11
Okre ´slenie i analiza wymaga ´
n.
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.
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
3.12
Zatwierdzanie wymaga ´
n.
Czy wymagania naprawd ˛e definiuj ˛
a system, którego chce
u˙zytkownik?
1
Sprawdzenie wa˙zno´sci.
2
Sprawdzenie niesprzeczno´sci.
3
Sprawdzenie kompletno´sci.
4
Sprawdzenie realno´sci.
5
Mo˙zliwo´s´c weryfikacji.
Metody sprawdzania wymaga ´n:
Przegl ˛
ad wymaga ´n.
Prototypowanie.
Generowanie testów.
Zautomatyzowane sprawdzanie niesprzeczno´sci.
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
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:
1
planowanie, w trakcie którego specyfikuje si ˛e proces
zarz ˛
adzania i zarz ˛
adzanie zmianami
1
Analiza problemu u specyfikacja zmiany.
2
Analiza zmiany i ocena kosztów.
3
Implementacja zmiany.
2
zarz ˛
adzanie zmianami, które polega na analizowaniu zmian
i szacowaniu ich wpływu
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
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:
1
Zewn ˛etrznego (modeluje si ˛e kontekst lub ´srodowisko
systemu).
2
Zachowania (modeluje si ˛e zachowanie systemu).
3
Strukturalnego (architektura systemu lub struktura danych).
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
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
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
3.16
Modele kontekstowe.
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
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
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
3.18
Diagram przepływu danych.
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
3.19
Diagram stanów.
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
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
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
3.21
Modele obiektowe. Diagram hierarchii klas.
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
3.22
Modele obiektowe. Diagram agregacji klas.
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
3.23
Modele obiektowe. Diagram sekwencji.
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
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.
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
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 ˛
a
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 ˛
a
dobrze rozpoznane, aby dowiedzie´c si ˛e wi ˛ecej. Wymagania
oczywiste nie musz ˛
a podlega´c prototypowaniu.
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
3.26
Metody błyskawicznego prototypowania.
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:
1
Tworzenie za pomoc ˛
a dynamicznych j ˛ezyków wysokiego
poziomu.
2
Programowanie baz danych.
3
Scalanie komponentów i programów u˙zytkowych.
Przypomnienie: proces
produkcji: czynno´sci i
modele
Wymagania stawiane
oprogramowaniu
3.27
Prototypowanie interfejsu u˙zytkownika.
Czynno´sci procesu
projektowania
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
Czynno´sci procesu
projektowania
4.2
Agenda
1
2
Czynno ´sci procesu projektowania
3
4
Projektowanie architektoniczne
5
Czynno´sci procesu
projektowania
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
Czynno´sci procesu
projektowania
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!
Czynno´sci procesu
projektowania
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
Czynno´sci procesu
projektowania
4.7
Czynno ´sci procesu projektowania:
Projektowanie architektury
Specyfikowanie abstrakcyjne
Projektowanie interfejsów
Projektowanie komponentów
Projektowanie struktur danych
Projektowanie algorytmów
Czynno´sci procesu
projektowania
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
Czynno´sci procesu
projektowania
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
Czynno´sci procesu
projektowania
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.
Czynno´sci procesu
projektowania
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
Czynno´sci procesu
projektowania
4.12
Czynno ´sci projektowania architektonicznego
1
Strukturalizacja systemu
2
Modelowanie sterowania
3
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 ˛
a
interfejsy do komunikacji z innymi podsystemami
Moduł
: komponent systemu; oferuje co najmniej jedn ˛
a
usług ˛e innym modułom; korzysta z innych
modułów; zwykle nie jest traktowany jako
niezale˙zny system
Czynno´sci procesu
projektowania
4.14
Projektowanie obiektowe
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.
Czynno´sci procesu
projektowania
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
Czynno´sci procesu
projektowania
4.16
Projektowanie obiektowe: pierwsze pi ˛e ´c zasad
S.O.L.I.D.
S
– SRP – Single responsibility principle
O
– OCP – Open/closed principle
L
– LSP – Liskov substitution principle
I
– ISP – Interface segregation principle
D
– DIP – Dependency inversion principle
Czynno´sci procesu
projektowania
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.
Czynno´sci procesu
projektowania
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
Czynno´sci procesu
projektowania
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.
Czynno´sci procesu
projektowania
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
Czynno´sci procesu
projektowania
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.
Czynno´sci procesu
projektowania
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
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
5.2
Agenda
1
2
3
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".
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.
5.5
G.R.A.S.P.
GRASP
General Responsibility Assignment Software Patterns (or
Principles)
1
Controller
2
Creator
3
High Cohesion
4
Indirection
5
Information Expert
6
Low Coupling
7
Polymorphism
8
Protected Variations
9
Pure Fabrication
5.6
G.R.A.S.P.
GRASP
Ogólne zasady przydzielania odpowiedzialno´sci w
oprogramowaniu.
1
Kontroler
2
Twórca
3
Wysoka spójno´s´c
4
Po´srednictwo
5
Expert
6
Mało powi ˛
aza ´n
7
Polimorfizm
8
Chroniona zmienno´s´c
9
Czyste wytwarzanie
Nazwy nie s ˛
a najwa˙zniejsze: najwa˙zniejszy jest sens tych
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
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.
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 ˛
a
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 ˛
ad
bierze dane) – podobno za to idzie si ˛e do
programistycznego piekła ;)
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 ˛
a
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.
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”).
5.12
6. Low Coupling
Mało powi ˛
aza ´
n
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:
1
wiele lokalnych zmian spowodowanych
zmianami w klasach powi ˛
azanych;
2
klasy trudniejsze do zrozumienia w izolacji;
3
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.
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”
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!
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 ˛
acy utrzyma´c inne zasady, gdy
te stoj ˛
a w sprzeczno´sci. Ponadto pomaga ona
uwolni´c si ˛e od dziedziny problemu i rozwi ˛
aza´c go
”czysto informatycznie”. Przykłady: wzorce
Singleton, Factory.
5.16
Jak wa˙zne s ˛
a zasady?
Pick your battles!
zasady nie s ˛
a bezwzgl ˛edne
trzeba d ˛
a˙zy´c do najszerszego ich spełniania
cz ˛esto trzeba wybra´c jedn ˛
a ponad drug ˛
a
trzeba rozumie´c kontekst w jakim si ˛e je stosuje
Je˙zeli si ˛e pomyliłe ´s -> refaktoruj!
projektowanie to proces iteracyjny
ró˙zne diagramy pozwalaj ˛
a zobaczy´c ró˙zne aspekty
systemu
Document Outline
- Slajd 1
- Slajd 2
- Slajd 3
- Slajd 4
- Slajd 5
- Slajd 6
- Slajd 7
- Slajd 8
- Slajd 9
- Slajd 10
- Slajd 11
- Slajd 12
- Slajd 13
- Slajd 14
- Slajd 15
- Slajd 16
- Slajd 19
- Slajd 20
- Slajd 21
- Przypomnienie: proces produkcji; czynnosci a modele
- Podział metodologii tworzenia oprogramowania
- Proces ujednolicony (Unified Process)
- Metody zwinne (Agile)
- Inne metodologie
- Podsumowanie
- Slajd 1
- Slajd 2
- Slajd 3
- Slajd 4
- Slajd 5
- Slajd 6
- Slajd 7
- Slajd 8
- Slajd 9
- Slajd 10
- Slajd 11
- Slajd 12
- Slajd 13
- Slajd 14
- Slajd 15
- Slajd 16
- Slajd 17
- Slajd 18
- Slajd 19
- Slajd 20
- Slajd 21
- Slajd 22
- Slajd 23
- Slajd 24
- Slajd 25
- Slajd 26
- Slajd 1
- Slajd 2
- Slajd 3
- Slajd 4
- Slajd 5
- Slajd 6
- Slajd 7
- Slajd 8
- Slajd 9
- Slajd 10
- Slajd 11
- Slajd 12
- Slajd 13
- Slajd 14
- Slajd 15
- Slajd 16
- Slajd 17
- Slajd 18
- Slajd 19
- Slajd 20
- Slajd 21
- Slajd 22
- Slajd 23
- Slajd 24
- Slajd 25
- Metody testowania.
- Poziomy testowania.
- Typy testów.
- Testy automatyczne.
- Przypomnienie: proces produkcji: czynnosci i modele
- Wymagania stawiane oprogramowaniu
- Inzynieria wymagan
- Modele systemu
- Prototypowanie oprogramowania
- Wprowadzenie
- Czynnosci procesu projektowania
- Metody projektowania
- Projektowanie architektoniczne
- Projektowanie obiektowe
- Wprowadzenie
- GRASP
- Stosowanie zasad
Wyszukiwarka
Podobne podstrony:
IO ALL
ZLL ALL
All Flesh Must Be Eaten Two Rotted Thumbs Up
Jim Hall at All About Jazz
PDH, Broadband ISDN, ATM and all that
mo all
Twarde dyski, Informatyka -all, INFORMATYKA-all
farmacja 12czerwca2007, Receptura, Farma - pytania, testy egzaminacyjne-all
Opis programu komputerowego Twierdzenie Pitagorasa-dowód i z, wrzut na chomika listopad, Informatyka
Kompresja danych (FAQ), Informatyka -all, INFORMATYKA-all
Zagrożenia wynikające z komputerowej rozrywki, wrzut na chomika listopad, Informatyka -all, INFORMAT
CD-KEY The Godfather (PC GAME) All, CD KEY'E
DOS komendy DOS-a-ściąga, szkoła, technik informatyki, INFORMATYKA-all, Ściąga z informatyki-2003
Podzespoły komputera-przekrój wiedzy, Informatyka -all, INFORMATYKA-all
Tel all, Word
Modele?mokracji all
więcej podobnych podstron