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ść
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).
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.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.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.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
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
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
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
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
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.
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.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.
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.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.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.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.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.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.
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.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.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 2
- Slajd 3
- Slajd 4
- Slajd 5
- Slajd 15
- 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 17
- Slajd 18
- Slajd 19
- Slajd 20
- Slajd 6
- Slajd 7
- Slajd 8
- Slajd 9
- Slajd 11
- Slajd 12
- Slajd 15
- Slajd 17
Wyszukiwarka
Podobne podstrony:
IO ALL
IO ALL
io wyk5
ZLL ALL
All Flesh Must Be Eaten Two Rotted Thumbs Up
Jim Hall at All About Jazz
all
PDH, Broadband ISDN, ATM and all that
gprs t6 io pl 1013
mo all
io 8 z
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
więcej podobnych podstron