all

background image

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

background image

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

background image

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.

background image

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

background image

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

background image

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

background image

Historia Inżynierii Oprogramowania:

Prehistoria. II wojna światowa.

background image

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)

background image

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)

background image

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ą

background image

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

background image

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!

background image

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

background image

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.

background image

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

background image

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

background image

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

background image

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

background image

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.

background image

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

background image

Dziękuję za uwagę

W przypadku sugestii, pytań lub spostrzeżenia

błędów: kontakt mailowy to kamich@agh.edu.pl

background image

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

background image

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

Agenda

1

Przypomnienie: proces produkcji; czynno ´sci a modele

2

Podział metodologii tworzenia oprogramowania

3

Proces ujednolicony (Unified Process)

4

Metody zwinne (Agile)

5

Inne metodologie

6

Podsumowanie

background image

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

background image

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

background image

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

Ogólny schemat.

background image

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

background image

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

Model iteracyjny

background image

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

Model iteracyjny

background image

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

Model iteracyjny

background image

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

Model iteracyjny

background image

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

Model iteracyjny

background image

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

Model iteracyjny

background image

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

Model przyrostowy

background image

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

Model przyrostowy

background image

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

Model przyrostowy

background image

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

Model przyrostowy

background image

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

Model przyrostowy

background image

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

Model przyrostowy

background image

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.

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

background image

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.

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

background image

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 ´

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)

background image

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

Schemat RUP.

background image

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 ˛

a

dokumentacj ˛e

Współpraca z klientem ponad negocjacje kontraktu

Reagowanie na zmiany ponad realizowanie planu

background image

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)

background image

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 ˛

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

background image

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

background image

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 ˛

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)

background image

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

background image

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

Programowanie ekstremalne - XP

background image

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

background image

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

Scrum.

background image

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

Model spiralny - zarz ˛

adzanie ryzykiem.

background image

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

V(ee)-model.

background image

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

Dual V(ee)-model.

background image

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

Cleanroom model.

background image

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

Rapid Application Development.

background image

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

Continuous Integration (Continuous Delivery)

background image

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

background image

Projektowanie oprogramowania

Wyk ad 04

ł

In ynieria Oprogramowania

ż

Kazimierz Michalik

background image

Wzorce projektowe

background image

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.

background image

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.

background image

Wzorce projektowe

Wzorce kreacyjne

Wzorce strukturalne

Wzorce czynnościowe

Wzorce współbieżności

background image

Wzorce projektowe

Wzorce kreacyjne

Budowniczy

Fabryka abstrakcyjna

Metoda wytwórcza (klasowy)

Prototyp

Singleton

background image

Budowniczy

background image

Metoda wytwórcza

background image

Fabryka abstrakcyjna

background image

Fasada

background image

Singleton

background image

Wzorce projektowe

Wzorce strukturalne

Adapter (klasowy także)

Dekorator

Fasada

Kompozyt

Most

Pełnomocnik

Pyłek

background image

Adapter (klasowy)

background image

Adapter

background image

Pyłek

background image

Model-View-Controller (pol.
Model-Widok-Kontroler)

background image

Wzorce projektowe

Wzorce czynnościowe

Interpreter (klasowy)

Iterator

Łańcuch zobowiązań

Mediator

Metoda szablonowa

Obserwator

Odwiedzający

Pamiętka

Polecenie

Stan

Strategia

RAII

background image

Strategia

background image

Obserwator

background image

Metoda szablonowa

background image

Odwiedzający

background image

Łańcuch zobowiązań

background image

Polecenie

background image

Stan

background image

Pamiątka

background image

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

background image

Projektowanie oprogramowania

Wyk ad

ł

Weryfikacja i Zatwierdzanie

In ynieria Oprogramowania

ż

Kazimierz Michalik

background image

Agenda

Weryfikacja i zatwierdzanie

Testowanie oprogramowania

Zarządzanie

Zarządzanie personelem

Szacowanie kosztu oprogramowania

Zarządzanie jakością

Ulepszanie procesu

Ewolucja ...

background image

Agenda

Ewolucja

Systemy odziedziczone

Modyfikacja oprogramowania

Restrukturyzacja oprogramowania

Zarządzanie konfiguracjami

background image

background image

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?

background image

Weryfikacja a zatwierdzanie

Zatwierdzanie:

Czy budujemy odpowiedni produkt?

(CO budujemy?)

vs

Weryfikacja:

Czy budujemy produkt odpowiednio?
(JAK to budujemy?)

background image

Weryfikacja a zatwierdzanie

Weryfikacja:

Czy oprogramowanie zgodne ze specyfikacją?

Zaczyna się od weryfikacji wymagań

Trwa przez wszystkie czynności procesu tworzenia
oprogramowania

background image

Weryfikacja a zatwierdzanie

Zatwierdzanie:

Podobny okres trwania

Bardziej ogólny proces

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

background image

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

background image

background image

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

background image

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

background image

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

background image

background image

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

background image

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)

background image

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.

background image

Zarządzanie

Zarządzanie personelem

Szacowanie kosztu oprogramowania

Zarządzanie jakością

Ulepszanie procesu

background image

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

background image

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

background image

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

background image

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.

background image

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

background image

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

background image

Ewolucja

Systemy odziedziczone

Modyfikacja oprogramowania

Restrukturyzacja oprogramowani
Zarządzanie konfiguracjami

background image

Testowanie

oprogramowania.

Metody testowania.

Poziomy testowania.

Typy testów.

Testy automatyczne.

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

background image

Testowanie

oprogramowania.

Metody testowania.

Poziomy testowania.

Typy testów.

Testy automatyczne.

7.2

Agenda

1

Metody testowania.

2

Poziomy testowania.

3

Typy testów.

4

Testy automatyczne.

background image

Testowanie

oprogramowania.

Metody testowania.

Poziomy testowania.

Typy testów.

Testy automatyczne.

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)

background image

Testowanie

oprogramowania.

Metody testowania.

Poziomy testowania.

Typy testów.

Testy automatyczne.

7.4

Metody testowania.

Testowanie statyczne

Testowanie dynamiczne

Black-box testing

White-box testing

Grey-box testing

background image

Testowanie

oprogramowania.

Metody testowania.

Poziomy testowania.

Typy testów.

Testy automatyczne.

7.5

Metody testowania.

background image

Testowanie

oprogramowania.

Metody testowania.

Poziomy testowania.

Typy testów.

Testy automatyczne.

7.6

Metody testowania.

background image

Testowanie

oprogramowania.

Metody testowania.

Poziomy testowania.

Typy testów.

Testy automatyczne.

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)

background image

Testowanie

oprogramowania.

Metody testowania.

Poziomy testowania.

Typy testów.

Testy automatyczne.

7.8

Poziomy testowania.

background image

Testowanie

oprogramowania.

Metody testowania.

Poziomy testowania.

Typy testów.

Testy automatyczne.

7.9

background image

Testowanie

oprogramowania.

Metody testowania.

Poziomy testowania.

Typy testów.

Testy automatyczne.

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

background image

Testowanie

oprogramowania.

Metody testowania.

Poziomy testowania.

Typy testów.

Testy automatyczne.

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.

background image

Testowanie

oprogramowania.

Metody testowania.

Poziomy testowania.

Typy testów.

Testy automatyczne.

7.12

Testy automatyczne

test-driven development

continous integration

continous deployment

background image

Testowanie

oprogramowania.

Metody testowania.

Poziomy testowania.

Typy testów.

Testy automatyczne.

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

background image

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

background image

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.2

Agenda

1

Przypomnienie: proces produkcji: czynno ´sci i modele

2

Wymagania stawiane oprogramowaniu

3

In˙zynieria wymaga ´

n

4

Modele systemu

5

Prototypowanie oprogramowania

background image

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

background image

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.4

Ogólny schemat.

background image

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 ˛

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.

background image

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

background image

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 ˛

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.

background image

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)

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.

background image

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

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.

background image

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

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?

background image

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 ´

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.

background image

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

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.

background image

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:

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

background image

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:

1

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

2

Zachowania (modeluje si ˛e zachowanie systemu).

3

Strukturalnego (architektura systemu lub struktura danych).

background image

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

background image

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.16

Modele kontekstowe.

background image

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

background image

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.18

Diagram przepływu danych.

background image

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.19

Diagram stanów.

background image

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

background image

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.21

Modele obiektowe. Diagram hierarchii klas.

background image

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.22

Modele obiektowe. Diagram agregacji klas.

background image

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.23

Modele obiektowe. Diagram sekwencji.

background image

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.

background image

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 ˛

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.

background image

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

background image

Wymagania

Przypomnienie: proces
produkcji: czynno´sci i
modele

Wymagania stawiane
oprogramowaniu

In˙zynieria wymaga ´n

Modele systemu

Prototypowanie
oprogramowania

3.27

Prototypowanie interfejsu u˙zytkownika.

background image

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

background image

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

4.2

Agenda

1

Wprowadzenie

2

Czynno ´sci procesu projektowania

3

Metody projektowania

4

Projektowanie architektoniczne

5

Projektowanie obiektowe

background image

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

4.3

Implementacja

background image

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

background image

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!

background image

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

background image

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

background image

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

background image

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

background image

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.

background image

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

background image

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

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

background image

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

4.13

Model architektoniczny 4+1

background image

Projektowanie

Wprowadzenie

Czynno´sci procesu
projektowania

Metody projektowania

Projektowanie
architektoniczne

Projektowanie
obiektowe

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.

background image

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

background image

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.

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

background image

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.

background image

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

background image

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.

background image

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

background image

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.

background image

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

background image

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

a

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

background image

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

a

wzorce projektowe.

Wprowadzenie

GRASP

Stosowanie zasad

5.2

Agenda

1

Wprowadzenie

2

GRASP

3

Stosowanie zasad

background image

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

a

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

background image

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

a

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.

background image

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

a

wzorce projektowe.

Wprowadzenie

GRASP

Stosowanie zasad

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

background image

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

a

wzorce projektowe.

Wprowadzenie

GRASP

Stosowanie zasad

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.

background image

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

a

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

background image

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

a

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.

background image

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

a

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 ˛

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

background image

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

a

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 ˛

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.

background image

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

a

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”).

background image

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

a

wzorce projektowe.

Wprowadzenie

GRASP

Stosowanie zasad

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.

background image

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

a

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”

background image

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

a

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!

background image

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

a

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 ˛

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.

background image

Projektowanie

obiektowe: Zasady i

sk ˛

ad si ˛e bior ˛

a

wzorce projektowe.

Wprowadzenie

GRASP

Stosowanie zasad

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


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