Inżynieria

oprogramowania

Wykład 1 – zagadnienia

wstępne

Prezentacja częściowo oparta na prezentacji przygotowanej przez Prof. J.E. Sienkiewicza

(opartej z kolei na podręczniku Iana Sommerville’a Inżynieria oprogramowania, WNT 2003)

Literatura

• Ian Sommerville, Inżynieria oprogramowania, WNT

2003

• J. Górski (red.), Inżynieria oprogramowania w

projekcie informatycznym, Mikom 2000

• H. Dick, M. Joe, Podstawy techniczne inżynierii

oprogramowania, WNT, 2003

• L. Dean, W. Don, Zarządzanie wymaganiami, WNT

2003

• M. Śmiałek, Zrozumieć UML 2.0. Metody modelowania

obiektowego, Helion 2005

• R. Patton, Testowanie oprogramowania, Mikom, 2002

• R.V. Binder, Testowanie systemów obiektowych, WNT,

2003

Inżynieria – ogólnie

• działalność ludzka polegająca na

projektowaniu, konstrukcji,
modyfikowaniu i konserwacji
sztucznych systemów

• oparta o wiedzę naukową i techniczną
• inżynier wykorzystuje swoją wiedzę,

wyobraźnię, doświadczenie,
umiejętność oceny i rozumowanie

Inżynieria oprogramowania

• zajmuje się teorią, metodami i narzędziami

związanymi z wytwarzaniem oprogramowania

(oprogramowanie – programy komputerowe, cała związana z

nimi dokumentacja i dane konfiguracyjne)

• obejmuje wszelkie aspekty produkcji

oprogramowania: analizę i określenie

wymagań, projektowanie, wdrożenie,

ewolucję gotowego produktu

• praktyczna strona informatyki
• narodziny: lata 60-te XX wieku
• młoda dyscyplina, ciągle się rozwijająca

Znaczenie inżynierii

oprogramowania

• gospodarki wszystkich rozwiniętych krajów

zależą od oprogramowania

• coraz więcej i więcej systemów wymaga

niezawodnego oprogramowania

• obecnie wytwarzanie oprogramowania jest

poważną gałęzią gospodarki narodowej

każdego rozwiniętego kraju

• systematyzuje i porządkuje proces

wytwarzania oprogramowania, ułatwiając

tworzenie oprogramowania wysokiej jakości

Bieżące trendy

w inżynierii oprogramowania

• próby sprostania wymagań stawianych

oprogramowaniu poprzez wielokrotne użycie kodu

• zunifikowany opis zachowania się obiektów w

różnych, często nietypowych sytuacjach

• „okiełznanie” programowania ekstremalnego i

błyskawicznego (problem sprostania wymogowi

dostarczania gotowego oprogramowania w

skróconym czasie bez utraty jakości)

• konserwacja systemów spadkowych
• budowa systemów heterogenicznych
• pielęgnacja i modyfikacja działających dużych

systemów, pełniących poważne funkcje gospodarcze

Inżynieria oprogramowania

–

FAQ

• Jaka jest różnica pomiędzy inżynierią

oprogramowania a informatyką?

Informatyka obejmuje teorie i podstawowe zasady działania

komputerów, a inżynieria oprogramowania obejmuje

praktyczne problemy związane z tworzeniem oprogramowania

Inżynier oprogramowania powinien znać teorie informatyczne, z

drugiej strony nie zawsze przystają one do rzeczywistości

• Co to jest CASE
(Computer-Aided Software Engineering)?

CASE obejmuje rożne programy wykorzystywane do

wspomagania czynności procesu tworzenia oprogramowania

(np. edytory notacji, generatory kodów)

Inżynieria oprogramowania – FAQ

(c.d.)

• Na czym polegają metody inżynierii

oprogramowania?

• Polegają na uporządkowanym podejściu do tworzenia

oprogramowania, poprzez:
- opisy modeli systemu (np. modele obiektów, modele przepływu)
- reguły (ograniczenia, którym podlegają modele systemu)
- zalecenia (heurystyki określające dobre zwyczaje projektantów)
- poradnictwo (opisy czynności, które należy wykonać)

• Co to jest UML (Unified Modeling Language)?

• Jest to formalny język, służący do opisu świata obiektów w analizie

obiektowej oraz programowaniu obiektowym; wykorzystuje

reprezentację graficzną – symbole wiązane ze sobą na diagramach

Inżynieria oprogramowania – FAQ

(c.d.)

• Jakie właściwości ma dobre

oprogramowanie?

• Konkretny zbiór właściwości zależy od zastosowania,

niemniej można podąć ogólny zbiór pożądanych właściwości:
- zdolność do pielęgnacji: zdolność do ewolucji, zgodnie z
potrzebami klientów
- niezawodność: nie powinno powodować fizycznych lub
ekonomicznych katastrof w przypadku awarii
- efektywność: nie powinno marnotrawić zasobów systemu
takich jak pamięć czy czas procesora
- użyteczność: powinno być użyteczne, bez zbędnego wysiłku
ze strony użytkownika

Fazy procesu produkcji

oprogramowania

• idea
• specyfikacja
• projektowanie
• implementacja
• integracja
• testowanie
• wdrożenie
• ewolucja

semestr VI

(przedmiot: Inżynieria oprogramowania)

semestr VII

(przedmiot:

oprogramowanie aplikacyjne / projekt

grupowy)

Modelowanie procesu tworzenia

oprogramowania

• Modele ogólne (paradygmaty) tworzenia

oprogramowania (z natury uproszczone)

– model kaskadowy
– model spiralny
– model przyrostowy i tworzenie ewolucyjne
– model prototypowy
– składanie systemu z komponentów ponownego

użycia

• Modele szczegółowe

– model przepływu prac
– model przepływu danych (lub model czynności)

Inżynier oprogramowania

(software engineer)

• zajęcie wpisane na oficjalną listę zawodów

w roku 1990 (za granicą)

• w Polsce – brak oficjalnego rozróżnienia w

klasyfikacji zawodów (

Inżynierowie i pokrewni

gdzie indziej niesklasyfikowani

)

• według Money Magazine i Salary.com –

zawód uznany w 2006 roku za najlepszy w

Stanach Zjednoczonych, pod względem

możliwości rozwoju, wysokości pensji,

poziomu stresu, elastyczności godzin

pracy i środowiska pracy

Odpowiedzialność etyczna

i zawodowa

• Inżynierowie oprogramowania ponoszą

znacznie większą odpowiedzialność niż tylko

wynikająca z ich technicznych umiejętności

• Powinni postępować etycznie i moralnie,

jeśli chcą być uważani za profesjonalistów

• Powinni pamiętać, że zachowywać się

etycznie, to więcej, niż tylko przestrzegać

obowiązujące prawo

• Powinni przestrzegać Kodeksów etycznych i

zawodowych

Zasady zawodowej

odpowiedzialności

• Zachowywanie tajemnicy

– Inżynierowie powinni zawsze dochowywać tajemnic powierzonych

przez pracodawców i klientów, niezależnie od tego czy podpisano

formalną umowę o ochronie tajemnicy

• Kompetencje

– Inżynierowie nie powinni zawyżać poziomu swoich kompetencji. Nie

powinni świadomie przyjmować prac, które przekraczają ich

możliwości

• Prawo własności intelektualnej

– Inżynierowie powinni znać miejscowe prawo regulujące korzystanie z

własności intelektualnej. Powinni szczególnie dbać o poszanowanie

intelektualnej własności swoich pracodawców i klientów

• Niewłaściwe użycie komputera

– Inżynierowie oprogramowania nie powinni używać swoich

umiejętności do niewłaściwego używania cudzych komputerów

Dylematy etyczne

• Zasadnicza niezgodność z z poglądami

przełożonego

• Nieetyczne postępowanie pracodawcy,

np. przy fałszowaniu dzienników kontroli

przy testowaniu krytycznego systemu

• Nieetyczne lub kontrowersyjne

wymagania klienta na zamówione

oprogramowanie

• Uczestnictwo w tworzeniu systemów

wojskowych i nuklearnych

Inżynieria

oprogramowania

Wykład 2 – inżynieria wymagań:

wymagania stawiane

oprogramowaniu

Prezentacja częściowo oparta na prezentacji przygotowanej przez Prof. J.E. Sienkiewicza

(opartej z kolei na podręczniku Iana Sommerville’a Inżynieria oprogramowania, WNT 2003)

Inżynieria wymagań

• proces szukania, analizowania,

dokumentowania, sprawdzania i
zatwierdzania usług i ograniczeń
projektowanego systemu

• innymi słowy – proces ustalenia, co system

powinien robić, przy uwzględnieniu
istniejących ograniczeń

• opisy usług i ograniczeń są wymaganiami

stawianymi systemowi

Problemy związane

z produkcją oprogramowania

To, co klient zamówił

To, co opisywał projekt

To, co wykonali programiści

Po uruchomieniu i wdrożeniu

To, za co klient zapłacił

To, czego klient
naprawdę potrzebował

Rodzaje specyfikacji wymagań

• Wymagania użytkownika

– Wyrażone w języku naturalnym oczekiwane usługi

systemu, oraz ograniczenia, w których system ma

działać.

• Wymagania systemowe

– Szczegółowo ustalają usługi systemu i

ograniczenia. Dokumentacja wymagań

systemowych powinna być bardzo precyzyjna.

– Mogą być podstawą kontraktu na implementację

systemu, powinny być zatem pełną i niesprzeczną

specyfikacją całego systemu.

– Stanowią punkt wyjścia do projektowania systemu.

Przykłady specyfikacji

Wymaganie użytkownika

1. Oprogramowanie musi zapewniać mechanizmy reprezentowania i
dostępu do plików zewnętrznych tworzonych przez inne narzędzia.

Wymaganie systemowe

1.1 Użytkownik powinien mieć możliwość definiowania typów plików zewnętrznych.
1.2 Każdy typ pliku zewnętrznego może mieć przypisane narzędzie do obróbki takich plików.
1.3 Każdy typ pliku zewnętrznego może być przedstawiony w postaci charakterystycznej
ikony na ekranie użytkownika.
1.4 Należy zapewnić udogodnienia do definiowania przez użytkownika ikon odpowiadających
typom plików zewnętrznych.
1.5 Gdy użytkownik wybierze ikonę powiązaną z plikiem zewnętrznym, następuje
zastosowanie do tego pliku narzędzia skojarzonego z typem tego pliku.

Czytelnicy rodzajów specyfikacji

Wymagania

użytkownika

Wymagania

systemowe

Menedżerowie klienta

Użytkownicy systemu

Inżynierowie klienta

Menedżerowie zleceniobiorcy

Projektanci systemu

Użytkownicy systemu

Inżynierowie klienta

Projektanci systemu

Twórcy oprogramowania

Podział wymagań

stawianych oprogramowaniu

• Wymagania funkcjonalne

– Stwierdzają, jakie usługi ma oferować system, jak ma

reagować na określone dane wejściowe oraz jak ma się

zachowywać w określonych sytuacjach. W niektórych

wypadkach wymagania funkcjonalne określają, czego

system nie powinien robić.

• Wymagania niefunkcjonalne (pozafunkcjonalne)

– Określają ograniczenia usług i funkcji systemu. Obejmują

ograniczenia czasowe, ograniczenia dotyczące procesu

tworzenia, standardy itd.

• Wymagania dziedzinowe

– Pochodzą z dziedziny zastosowania systemu

odzwierciedlają jej charakterystykę. Mogą być zarówno

funkcjonalne jak i niefunkcjonalne.

Wymagania funkcjonalne

• Odpowiadają na pytanie: jakie funkcje system

ma udostępniać użytkownikom?

• Wymagania funkcjonalne opisują

funkcjonalność lub usługi, które system

powinien oferować.

• Zależą od rodzaju tworzonego oprogramowania,

spodziewanych jego użytkowników oraz rodzaju

wytwarzanego systemu.

• Gdy mają postać wymagań użytkownika, ich

opis jest zwykle bardziej ogólny, natomiast

wymagania funkcjonalne systemowe

szczegółowo definiują funkcje systemu, jego

wejścia, wyjścia, wyjątki itd.

Przykłady wymagań

funkcjonalnych

• Użytkownik powinien móc przeszukać

zbiór wszystkich baz danych lub wybrać
tylko ich podzbiór.

• System

powinien

udostępniać

użytkownikom odpowiednie narzędzia do
przeglądania dokumentów z magazynu.

• Każde zamówienie powinno być oznaczone

unikatowym identyfikatorem (ORDE_ID),
który będzie można łatwo skopiować.

Problemy wynikające z braku

ścisłości przy definiowaniu

wymagań

• Natura programisty każe mu interpretować

niejednoznaczne wymagania tak, aby uprościć

implementację. Zwykle nie jest to jednak to, czego

chciał klient. W takim przypadku należy opracować

nowe wymagania i dokonać zmian w systemie –

opóźnia to dostarczenie systemu i podnosi koszty.

• Rozważmy drugie na tej liście wymaganie stawiane

systemowi biblioteki, które mówi o „odpowiednich

narzędziach do oglądania”. Celem tego wymagania

jest zapewnienie narzędzia do oglądania wszystkich

tych formatów. Programista działający pod presją

czasu może udostępnić po prostu narzędzie do

oglądania plików tekstowych i ogłosić spełnienie

wymagania.

Kompletność i spójność

specyfikacji wymagań

funkcjonalnych

• Specyfikacja wymagań funkcjonalnych

stawianych systemowi powinna być kompletna i

spójna.

• Kompletność oznacza, że wszystkie potrzebne

użytkownikowi usługi powinny być zdefiniowane.

• Spójność oznacza, że wymagania nie powinny

mieć sprzecznych definicji.

• W praktyce w wypadku wielkich złożonych

systemów nie da się osiągnąć kompletności i

spójności. Przyczynami tego są swoista złożoność

tych systemów oraz fakt, że różne punkty

widzenia są związane ze sprzecznymi potrzebami.

Wymagania niefunkcjonalne

• Odpowiadają na pytanie: jak system ma działać?

• Mogą definiować ograniczenia systemu, takie jak

możliwości urządzeń wejścia-wyjścia lub dostępne

reprezentacje danych.

• Wymagania niefunkcjonalne wynikają z potrzeb

użytkownika, ograniczeń budżetowych, strategii

firmy, konieczności współpracy z innymi

systemami sprzętu lub oprogramowania,

czynników zewnętrznych.

• Wymagania stawiane procesowi tworzenia

oprogramowania – specyfikacja standardów

jakości, których należy użyć, stwierdzenie, że

projekt należy opracować za pomocą konkretnego

zbioru narzędzi CASE.

Klasyfikacja

wymagań niefunkcjonalnych

• Wymagania produktowe

– Określają zachowanie produktu. Przykładami są

wymagania efektywnościowe dotyczące szybkości

działania systemu i jego zapotrzebowania na pamięć,

wymagania niezawodności.

• Wymagania organizacyjne

– Wynikają ze strategii i procedur w firmie klienta i w

firmie wytwórcy.

• Wymagania zewnętrzne

– Ta szeroka kategoria mieści wszystkie wymagania

wynikające z czynników zewnętrznych. Obejmują m.in.

wymagania współpracy, które definiują interakcje

systemu z systemami innych firm i wymagania prawne.

Przykłady

wymagań niefunkcjonalnych

• Wymaganie produktowe

– 4.C.8 Wszelka niezbędna komunikacja między

projektowanym środowiskiem wspomagającym

programowanie w języku ADA a użytkownikiem,

powinna dać się wyrazić za pomocą standardowego

zestawu symboli języka ADA.

• Wymaganie organizacyjne

– 9.3.2 Proces tworzenia systemu i końcowe dokumenty

powinny być zgodne z procesem i produktami

zdefiniowanymi w standardzie XYZCo-SP-STAN-95.

• Wymaganie zewnętrzne

– 7.6.5 System nie powinien ujawniać operatorom żadnych

danych osobowych klientów oprócz nazwisk i numerów

identyfikacyjnych

Podział szczegółowy

wymagań niefunkcjonalnych

Wymagania

przenośności

Wymagania

niezawodności

Wymagania

sprawnościowe

Wymagania

etyczne

Wymagania

zewnętrzne

Wymagania

współpracy

Wymagania

produktowe

Wymagania

organizacyjne

Wymagania

efektywnościowe

Wymagania

użyteczności

Wymagania

dostawy

Wymagania

implementacyjne

Wymagania

standardów

Wymagania

prawne

Wymagania

pamięciowe

Wymagania

ochrony

prywatności

Wymagania

zabezpieczeń

Problemy związane

z wymaganiami niefunkcjonalnymi

• Trudności z weryfikacją niektórych

wymagań.

• Mogą one być zapisywane w sposób

odzwierciedlający ogólne dążenia klienta,
takie jak łatwość użycia, zdolność do
naprawy awarii i szybka reakcja na
działania użytkownika. To jednak zostawia
bardzo duży margines do interpretacji i
stwarza potencjalną możliwość konfliktów
z klientem już po dostarczeniu systemu.

Rozwiązywanie problemów

związanych

z wymaganiami niefunkcjonalnymi

• Wymaganie nieweryfikowalne

– System powinien być łatwy w użyciu dla

doświadczonych kontrolerów, a sposób jego
organizacji powinien minimalizować liczbę
błędów użytkownika.

• Poprawione, weryfikowalne wymaganie

– Doświadczeni kontrolerzy powinni móc używać

wszystkich funkcji systemu po szkoleniu
trwającym dwie godziny. Po szkoleniu, średnia
liczba błędów robionych przez użytkowników
nie powinna przekroczyć dwóch dziennie.

Miary do specyfikowania

wymagań niefunkcjonalnych

Właściwość

Miara

Szybkość

Rozmi
ar

Łatwość użycia

Niezawodność

Solidność

Przenośn
ość

Liczba przetworzonych transakcji na sekundę
Czas reakcji na zdarzenie wywołane przez użytkownika
Czas odświeżenia ekranu

Kilobajty
Liczba układów pamięci
RAM

Czas szkolenia
Liczba okien
pomocy

Średni czas bez awarii
Częstość błędów

Czas uruchomienia systemu po awarii
Procent zdarzeń powodujących awarie
Prawdopodobieństwo zniszczenia danych
podczas awarii

Procent kodu zależnego od platformy
Liczba docelowych systemów

Trudności związane

z pozyskiwaniem wymagań

funkcjonalnych i niefunkcjonalnych

• Klienci mogą nie wiedzieć, czego naprawdę

potrzebują.

• Z drugiej strony, jeżeli podane wymagania zawierają

zbyt wiele informacji, ograniczają wybór

innowacyjnych rozwiązań oraz utrudniają

zrozumienie wymagań.

• Klienci mogą nie być w stanie przetłumaczyć swoich

celów na wymagania ilościowe.

• Wymagania niefunkcjonalne są często sprzeczne lub

powiązane z innymi wymaganiami funkcjonalnymi.

• W zasadzie należy odróżnić wymagania funkcjonalne

i niefunkcjonalne w dokumentacji wymagań. W

praktyce jest to jednak czasami dość trudne.

Wymagania dziedzinowe

• Wynikają bardziej z dziedziny zastosowania

systemu niż z konkretnych potrzeb

użytkowników.

• Mogą być nowymi wymaganiami

funkcjonalnymi, ograniczać istniejące

wymagania funkcjonalne albo np. ustalać

sposób wykonywania konkretnych obliczeń.

• Wymagania dziedzinowe są istotne, ponieważ

odzwierciedlają podstawy dziedziny

zastosowania. Jeśli nie są spełnione, to

system może nie działać w sposób

zadowalający lub np. nie uzyskać

wymaganych atestów.

Przykład: czytelnia norm

1.

Wszystkie

bazy

danych

powinny

być

dostępne

przez

jednolity

interfejs

użytkownika, którego podstawą jest standard

Z39.50.

2.

Ze względu na ochronę praw autorskich

system powinien udostępniać normy jedynie

w formie przeznaczonej do odczytu na

ekranie monitora, bez możliwości pobrania

pliku ani jego wydruku. Jedynie po uzyskaniu

potwierdzenia dokonania wpłaty, system

powinien umożliwić wydruk dokumentu lub

jego pobranie.

Przykład: system sterowania

ruchem pociągów

• Tempo zmniejszania prędkości pociągu

jest wyznaczane następująco:

D

pociągu

= D

sterowania

+ D

nachylenia

gdzie D

nachylenia

wynosi

9,81m/s

2

* wyrównane nachylenie / alfa,

gdzie z kolei 9,81m/s

2

/alfa są znane dla

różnych typów pociągów.

Problemy

z wymaganiami dziedzinowymi

• Są one zwykle wyrażone za pomocą języka

specyficznego dla dziedziny zastosowania,
co sprawia, że inżynierowie
oprogramowania często ich nie rozumieją.

• Eksperci z danych dziedzin często mogli

pominąć jakąś informację, ponieważ po
prostu jest dla nich oczywista. Może nie
być jednak oczywista dla twórców systemu,
którzy mogą to wymaganie
zaimplementować w sposób nieprawidłowy.

Zapis wymagań

• Wymagania użytkownika:

zapis powinien być

zrozumiały dla udziałowców systemu, którzy nie
mają szczegółowej wiedzy technicznej. Można je
zapisywać w języku naturalnym, posiłkując się
prostymi i intuicyjnymi diagramami (np. UML: use
cases – przypadki użycia).

• Wymagania systemowe:

strukturalny język

naturalny (formularze i szablony), notacja
graficzna (diagramy UML), języki opisu projektu
(Program Description Language - PDL),
specyfikacje matematyczne.

Problemy z językiem naturalnym

• Brak jasności

– Czasem trudno jest wyrażać się w języku

naturalnym precyzyjnie i jednoznacznie, bez

czynienia dokumentów przegadanymi i

nieczytelnymi.

• Sprzeczność wymagań

– Trudno jest jasno rozgraniczać wymagania

funkcjonalne, wymagania niefunkcjonalne,

cele systemu i elementy projektu.

• Łączenie wymagań

– Kilka różnych wymagań może być zapisanych

razem jako jedno wymaganie.

Rady do zapisywania wymagań

• Opracuj standardowy format i spraw, aby wszystkie

definicje wymagań były z nim zgodne.

• Konsekwentnie używaj pojęć językowych. W

szczególności rozróżnij wymagania obowiązkowe od

wskazanych.

• Stosuj wyróżnienia (wytłuszczenia, kursywy) do

zaznaczania głównych części wymagania.

• Unikaj, jeżeli tylko się da, żargonu komputerowego.
• Zapisuj uzasadnienia związane z wymaganiami.

Pomagają one wytwórcom i konserwatorom

systemu w zrozumieniu, dlaczego takie wymaganie

się pojawiło, i w ocenie wpływu zmiany tego

wymagania.

Zapis tekstowy wymagań

użytkownika - przykład

3.5.1 Dodawanie węzłów do projektu
3.5.1.1 Edytor będzie udostępniał użytkownikom udogodnienia
do dodawania do swoich projektów węzłów określonego

typu

3.5.1.2 Sekwencja czynności, które prowadzą do dodania węzła,
powinna być następująca:

1. Użytkownik powinien wybrać typ węzła, jaki należy dodać
2. Użytkownik powinien przesunąć wskaźnik do przybliżonego

miejsca nowego węzła na diagramie i zlecić dodanie symbolu
węzła w tym punkcie

3. Użytkownik powinien następnie przeciągnąć węzeł do jego

ostatecznego położenia

Uzasadnienie: Użytkownik jest najwłaściwszą osobą do
decydowania o położeniu węzłów na diagramie. Takie podejście
daje użytkownikowi całkowite panowanie nad wyborem typu węzła
i jego umiejscowieniem.

Diagram przypadków użycia

(use cases) - przykład

Zapis wymagań systemowych –

formatka karty wymagania

Zapis wymagań systemowych –

wypełniona karta wymagania

Dokumentowanie wymagań

•

Dokumentacja wymagań stawianych

oprogramowaniu (nazywana też specyfikacją

wymagań stawianych oprogramowaniu lub

Software Requirements Specification, SRS) jest

oficjalną deklaracją tego, co jest wymagane od

wytwórców systemu.

•

Powinna zawierać zarówno wymagania

użytkownika stawiane systemowi, jak i

szczegółową specyfikacje wymagań systemowych.

•

Nie jest projektem – powinna opisywać co system

ma robić, a nie jak to robić. Powinna określać

zachowanie systemu jedynie z zewnątrz.

•

Powinno być łatwo ją zmieniać.

Użytkownicy

dokumentacji wymagań

Klienci systemu

Menedżerowie

Projektanci systemów

Testerzy systemów

Inżynierowie

konserwacji systemów

Określają wymagania i czytają je, aby sprawdzić,

czy odpowiadają ich potrzebom.

Określają także zmiany wymagań.

Używają dokumentacji wymagań

do planowania oferty budowy systemu

i do planowania procesu jego tworzenia

Używają wymagań, aby zrozumieć,

jaki system ma być zbudowany

Używają wymagań, aby opracować

i przeprowadzić testy zatwierdzające system

Używają wymagań jako pomocy

w zrozumieniu systemu

i związków między jego częściami

Inżynieria

oprogramowania

Wykład 3 – inżynieria wymagań:

proces inżynierii wymagań

Prezentacja częściowo oparta na prezentacji przygotowanej przez Prof. J.E. Sienkiewicza

(opartej z kolei na podręczniku Iana Sommerville’a Inżynieria oprogramowania, WNT 2003)

Proces inżynierii wymagań

• Służy do określania, analizowania i zatwierdzania

wymagań stawianych systemowi

• Obejmuje wszystkie czynności niezbędne do

opracowania i aktualizacji dokumentacji wymagań

systemowych.

• Ogólne czynności w procesie inżynierii wymagań:

– studium wykonalności

– określenie i analizowanie wymagań

– specyfikowanie i dokumentowanie wymagań

– zatwierdzanie wymagań

Proces inżynierii wymagań

Studium

wykonalności

Określanie

i analizowanie

wymagań

Specyfikowanie

wymagań

Zatwierdzanie

wymagań

Raport

o wykonalności

Dokumentacja

wymagań

Studium wykonalności

• Wynikiem tego studium powinien być raport

wykonalności, który zaleca albo nie zaleca

kontynuacji procesu inżynierii wymagań i tworzenia

systemu.

• Studium wykonalności to krótkie, skumulowane

opracowanie, w którym staramy się odpowiedzieć

na kilka pytań:

– Czy system przyczyni się do realizacji ogólnych

celów przedsiębiorstwa?

– Czy system może być zaimplementowany z

użyciem dostępnych technologii, w ramach

ustalonego budżetu i ograniczeń czasowych?

– Czy system może być zintegrowany z

istniejącymi systemami, które już zainstalowano?

Raport wykonalności

• Kilka szczegółowych pytań do tworzenia raportu:

– Jak firma poradziłaby sobie, jeśli system nie

byłby zaimplementowany?

– Jakie problemy występują w obecnie przyjętych

procesach i jak nowy system ma pomóc w ich

eliminacji?

– Jaki byłby bezpośredni wkład systemu w

osiąganie celów gospodarczych?

– Czy można przekazywać informacje do i z

innych systemów przedsiębiorstwa?

– Czy system wymaga technologii, których

wcześniej w firmie nie stosowano?

– Co system musi wspomagać, a czego nie musi?

Określanie i analizowanie

wymagań

• Po wstępnych studiach wykonalności następna fazą

inżynierii wymagań jest określanie i analizowanie

wymagań.

• W trakcie tej czynności techniczni budowniczowie

oprogramowania pracują z klientem i użytkownikami

systemu nad badaniem dziedziny zastosowania i

usług, które system ma oferować, pożądanej

efektywności, ograniczeniach sprzętowych itd.

• W określaniu i analizowaniu wymagań mogą wziąć

udział osoby z różnych stanowisk w firmie. Pojęcie

udziałowiec (uczestnik) odnosi się do każdego, kto

powinien mieć pewien pośredni lub bezpośredni

wpływ na wymagania systemowe.

Problemy przy analizie

wymagań

• Udziałowcy często nie wiedzą, czego tak

naprawdę oczekują od nowo tworzonego systemu

komputerowego.

• Udziałowcy systemu wyrażają wymagania za

pomocą własnych pojęć.

• Różni udziałowcy mogą stawiać różne

wymagania, często sprzeczne ze sobą.

• Czynniki polityczne mogą mieć wpływ na system.
• Środowisko ekonomiczne i gospodarcze, w którym

prowadzi się analizę, jest dynamiczne.

Nieuchronnie zmienia się w trakcie procesu

analizy.

Proces określania i

analizowania wymagań

Początek

procesu

Rozpoznanie

dziedziny

Zbieranie

wymagań

Klasyfikacja

Usuwanie

sprzeczności

Nadawanie

priorytetów

Sprawdzenie

wymagań

Specyfikacja

wymagań

Dokumentacja

wymagań

Określanie wymagań oparte na

punktach widzenia

• Zwykle systemy maja kilka różnych grup

użytkowników. Należy przyjrzeć się systemowi z ich

punktu widzenia.

Klasyfikacja punktów widzenia

• Ze względu na źródło lub przeznaczenie danych

– Punkt widzenia powiązany z użytkowaniem lub

produkcją danych. W tym wypadku analiza polega

na rozpoznawaniu wszystkich takich punktów

widzenia, danych, które są produkowane lub

użytkowane oraz ich przetwarzaniu.

• Ze względu na usługi zewnętrzne

– W tym wypadku punkty widzenia są zewnętrzne

wobec systemu; osoby mające ten punkt

widzenia korzystają z usług systemu.

Model zewnętrznych punktów

widzenia

• Reprezentanci tych punktów widzenia współpracują z

systemem przez otrzymywanie usług od systemu

oraz przekazywanie do systemu danych i sygnałów

sterujących.

• Punkty widzenia są zewnętrzne wobec systemu,

stanowią zatem naturalny sposób strukturalizacji

procesu określania wymagań.

• Dość łatwo jest stwierdzić, czy coś jest punktem

widzenia, czy nie. Reprezentanci punktów widzenia

muszą bowiem w pewien sposób oddziaływać na

system.

• Punkty widzenia i usługi stanowią dobry sposób

strukturalizacji wymagań niefunkcjonalnych. Każda

usługa może być powiązana z wymaganiami

niefunkcjonalnymi.

Przykład – system

bankomatowy

• Służy do wykonywania operacji

bankomatowych przy użyciu karty

bankomatowej z przypisanym kodem PIN

• W uproszczonej wersji służy klientom

macierzystego banku, oferując im bardziej

skomplikowane usługi, oraz klientom innym

banków w ograniczonym zakresie

• Usługi zaawansowane obejmują np.: wypłatę i

wpłatę środków, przekazywanie komunikatów

do banku, wyświetlanie informacji (np. o

saldzie konta lub wykonanych transakcjach).

Udziałowcy systemu

bankomatowego

• Klienci banku

• Klienci innych banków

• Dyrektorzy oddziałów banków

• Pracownicy obsługi klienta w oddziałach

• Administratorzy baz danych

• Osoby odpowiedzialne za bezpieczeństwo

w banku

• Dział marketingu banku

• Inżynierowie pielęgnacji sprzętu i

oprogramowania

Burza mózgów w trakcie

identyfikacji punktów widzenia

Pytanie

o saldo

Menedżer

Odczyt

transakcji

Zasoby

maszyny

Interfejs

użytkownika

Właściciel

konta

Zdalna

diagnostyka

Karta

skradziona

Niezawodność

Informacje

o koncie

Koszt systemu

Baza danych

klientów

Wypłata

gotówki

Aktualizacja

konta

Zamówienie

wyciągu

Obcy klient

Dziennik

komunikatów

Przelew

środków

Zdalna

aktualizacja

oprogramowania

Zamówienie

czeków

Zwrot karty

Dziennik

transakcji

Drukarka

Rozmiar

oprogramowania

Zatrzymanie

karty

Nieuprawniony

użytkownik

Kasa

banku

Weryfikacja

karty

Przekazywanie

komunikatów

Zabezpieczenia

Pielęgnacja

oprogramowania

Przypisanie usług

do punktów widzenia

WŁAŚCICIEL
KONTA

OBCY
KLIENT

KASA
BANKU

Lista usług

Lista usług

Lista usług

Wypłata gotówki
Pytania o saldo
Zamówienie
czeków
Wysyłanie
komunikatu
Lista transakcji
Zamówienie
wyciągu
Przelew środków

Wypłata gotówki
Pytania o saldo

Diagnostyka
Dodanie gotówki
Dodanie papieru
Wysłanie
komunikatu

Dane wejściowe i dane

sterujące związane z punktami

widzenia

WŁAŚCICIEL
KONTA

Dane sterujące Dane
wejściowe

Rozpocznij transakcję Informacje z karty

Anuluj transakcję PIN

Zakończ transakcję Żądana kwota

Wybór usługi Komunikat

Hierarchia punktów widzenia

Usługi

Usługi

Inżynier

Menedżer

Kasa

Klient

obcy

Właściciel

konta

Klient

Personel banku

Wszystkie PW

Pytanie o saldo
Wypłata
gotówki

Zamówienie czeków
Wysłanie komunikatu
Lista transakcji
Zamówienie wyciągu
Przelew środków

Opis punktu widzenia klienta

i opis usługi wypłaty gotówki

Odnośnik: Klient

Atrybuty: Numer konta
PIN

Zdarzenia: Zacznij transakcję
Wybór usługi
Anuluj transakcję
Zakończ transakcję

Usługi: Wypłata gotówki
Pytanie o saldo

Podrzędne PW: Właściciel konta

Odnośnik: Wypłata gotówki
Uzasadnienie: Celem jest poprawienie
obsługi
klienta, zmniejszenie
obciążenia
okienek kasowych itp.
Specyfikacja: Użytkownicy wybierają
usługę
przez naciśnięcie
przycisku
„wypłata gotówki”.
Następnie
wprowadzają żądaną
kwotę.
Potwierdza się ją i jeśli
na koncie
są odpowiednie środki
następuje

wypłata

PW: Klient
Wymagania
niefunkcjonalne: Wypłacić gotówkę
najpóźniej
po 1 minucie od
potwierdzenia
kwoty

Scenariusze

• Scenariusze są szczególnie użyteczne przy

uszczegóławianiu przeglądowego opisu

wymagań. Są opisami przykładowych sesji

interakcyjnych. Każdy scenariusz obejmuje

jedną lub najwyżej kilka możliwych interakcji.

• Ludzie zwykle wolą przykłady wzięte z życia

niż abstrakcyjne opisy

• Inżynierowie wymagań mogą skorzystać z

informacji zebranych w trakcie dyskusji do

formułowania rzeczywistych wymagań

systemowych.

Cechy scenariusza

•

Opis stanu systemu na początku scenariusza.

•

Opis normalnego następstwa zdarzeń scenariusza.

•

Opis tego, co może pójść źle, i jak to jest

obsługiwane.

•

Informacje o innych czynnościach, które można

wykonywać w tym samym czasie.

•

Opis stanu systemu po zakończeniu scenariusza.

•

Każde odrębne zdarzenie w interakcji, takie jak

wsunięcie karty do bankomatu albo wybranie

usługi, może być udokumentowane za pomocą

oddzielnego scenariusza zdarzenia.

•

Obejmują opis przepływu danych, akcji systemu i

wyjątków, które mogą się pojawić.

Przykład scenariusza

• Zdarzenie inicjujące: wsunięto kartę do szczeliny

• Stan początkowy: karta w bankomacie

• Opis: Monituj o podanie numeru PIN. Gdy

wpisany numer jest poprawny, zidentyfikuj

klienta i wyświetl listę dostępnych operacji

• Sytuacje wyjątkowe:

- przekroczony limit czasu: zwróć kartę
- karta nieważna lub skradziona: zatrzymaj kartę
- niepoprawny numer PIN: zapytaj ponownie
- niepoprawny numer PIN podany po raz drugi:

zatrzymaj kartę

• Stan końcowy: użytkownik zidentyfikowany,

wyświetlone menu z dostępnymi operacjami

Model przypadków użycia

(use cases)

•

Metoda oparta na scenariuszach, służąca do

określania wymagań i interakcji użytkownika z

systemem

•

Po raz pierwszy użyta w 1993 (Jacobson). Obecnie

stała się podstawowym elementem notacji UML

•

Podstawowe pojęcia: przypadek użycia, aktor, relacje

między przypadkami użycia

•

System widziany jest jako czarna skrzynka,

zapewniająca określoną funkcjonalność

•

Model wyraźnie rozdziela system i to, co powinien

realizować (przypadki użycia i relacje między nimi),

od tego, co jest poza nim (aktorzy)

•

Ilustracja graficzna przy pomocy diagramu

przypadków użycia, wspierana odpowiednimi

scenariuszami

Przypadek użycia i aktor

• Aktor: abstrakcyjny użytkownik systemu,

reprezentujący grupę użytkowników używających

podobnych funkcji systemu i sposobu z nim

komunikacji

• Przypadek użycia: ciąg interakcji pomiędzy aktorem a

systemem, dostarczający aktorowi pożądanych

wyników

• Klasyfikacja aktorów:

- aktor główny: używa podstawowych funkcji systemu
- aktor drugorzędny: używa funkcji administracyjnych i

pielęgnacyjnych
- aktor aktywny: inicjuje przypadek użycia
- aktor pasywny: uczestniczy w przypadku użycia, ale

go nie inicjuje

Relacje

między przypadkami użycia

• Relacja „używa” („uses”)

- wskazuje na wspólny fragment
wielu przypadków użycia,
wykorzystanie wspólnego
zachowania

• Relacja „rozszerza” („extends”)

- rozszerzenie przypadku użycia o
sytuację wyjątkową

Przykład - hotel

• Hotel przyjmuje gości. Recepcjonista melduje i

wymeldowuje gości oraz pobiera opłaty.

• W hotelu jest wiele pokoi, sprzątanych przez

sprzątaczki

• Pokój może być wynajęty bezpośrednio przy

przyjeździe gościa, jeżeli są wolne pokoje

• Gość płaci recepcjoniście przed wymeldowaniem

• Pokój może zostać posprzątany po jego zwolnieniu

przez gościa. Pokój musi zostać posprzątany przed

jego ponownym wynajęciem

• Aktorzy: gość, recepcjonista, sprzątaczka

• Przypadki użycia: zameldowanie, wymeldowanie,

sprzątanie pokoju

Przykład – hotel.

Scenariusz dla wymeldowania

•

Nazwa przypadku użycia: wymeldowanie

•

Aktorzy: gość, recepcjonista, sprzątaczka

•

Zdarzenie inicjujące: zgłoszenie wyjazdu przez gościa

•

Stan początkowy: zapłacono za pobyt

•

Opis: Gość zgłasza wyjazd i zwraca klucze od pokoju.

Recepcjonista sprawdza zapłacenie rachunku i

wydaje sprzątaczce polecenie sprzątnięcia pokoju

•

Sytuacje wyjątkowe:
- zgubione klucze: nalicz opłatę za dorobienie nowego
- brak zapłaty: wystaw rachunek kredytowy

•

Stan końcowy: pokój sprzątnięty, gotowy do

ponownego wynajęcia

Przykład – hotel.

Diagram przypadków użycia

Model przypadków użycia -

podsumowanie

• identyfikacja granic systemu i aktorów
• specyfikacja wymagań funkcjonalnych,

postrzeganych przez zewnętrznych aktorów

• wspomaganie walidacji wymagań
• punkt wyjścia dla testów systemu
• przydatność dla celów prezentacji

funkcjonalności systemu – zrozumiałość i

komunikatywność

• podstawa do tworzenia diagramów

sekwencji (interakcji)

Diagram sekwencji (interakcji)

:

Książka

Bibliotek
a

Katalogujący:
Personel biblioteki

Nowa

Usuń

Kataloguj
składnik

Usuń składnik
z katalogu

Zarządzanie wymaganiami

-zatwierdzanie wymagań

• Zatwierdzanie wymagań polega na wykazaniu,

że wymagania naprawdę definiują system,

którego chce użytkownik.

• Błędy w dokumentacji wymagań mogą

przyczynić się do poważnych kosztów

powtarzania prac po sukcesywnym wykrywaniu

tych błędów w trakcie tworzenia lub nawet po

rozpoczęciu korzystania z systemu.

• Wymagania stawiane dużym systemom

oprogramowania zawsze się zmieniają.

• W trakcie procesu tworzenia oprogramowania

stopień zrozumienia problemu stale się zmienia,

a zmiany te mają zwrotny wpływ na wymagania.

Sprawdzenie wymagań

•

Sprawdzenie ważności. Użytkownik może być przekonany,

że system powinien spełniać pewne funkcje.

•

Sprawdzenie zrozumiałości. Czy klienci i użytkownicy

systemu dobrze zrozumieli wymaganie?

•

Sprawdzenie pochodzenia. Czy zaznaczone jest źródło, z

którego pochodzi wymaganie?

•

Sprawdzenie niesprzeczności. Wymagania zapisane w

dokumentacji nie powinny być sprzeczne.

•

Sprawdzenie kompletności. Dokumentacja wymagań

powinna zawierać wymagania, w których zdefiniowano

wszystkie funkcje i ograniczenia zamierzone przez

użytkownika systemu.

•

Sprawdzenie realności. Czy wymagania można

zaimplementować przy użyciu dostępnych środków?

•

Możliwość weryfikacji. Aby uniknąć późniejszych sporów

między klientem a zleceniobiorcą, wymagania systemowe

zawsze powinny być napisane tak, aby można było je

weryfikować.

•

Sprawdzenie giętkości. Czy wymaganie może być

zmienione bez znaczącego wpływu na pozostałe wymagania?

Wymagania stałe i zmienne

• Wymagania stałe - względnie stabilne

wymagania, które wynikają z podstawowej

działalności firmy i bezpośrednio odnoszą się do

dziedziny systemu.

• Wymagania zmienne - wymagania, które z dość

dużym prawdopodobieństwem mogą ulec zmianie

w trakcie tworzenia systemu albo po przekazaniu

go do użytkowania.
- wymagania zmieniające się: zmieniają się na

skutek zmian środowiska, w którym działa firma.
- wymagania pojawiające się: pojawiają się w

trakcie procesu tworzenia w miarę coraz lepszego

rozumienia systemu przez klienta.
- wymagania wynikowe: wynikają z wdrożenia

systemu komputerowego.
- wymagania zgodności: zależą od umów lub

procesów gospodarczych wewnątrz firmy.

Planowanie zarządzania

wymaganiami

•

Oznakowanie wymagań
Każde wymaganie musi być unikatowo oznakowane

tak, aby można było robić do niego odnośniki z

innych wymagań i używać tego wymagania przy

ocenianiu pochodzenia.

•

Proces zarządzania zmianami
Zbiór czynności szacowania wpływu i kosztu zmian.

•

Strategia śledzenia pochodzenia
Te strategie definiują zależności między

wymaganiami i projektem systemu, które należy

odnotowywać.

•

Użycie narzędzi CASE
Zarządzanie wymaganiami polega na przetwarzaniu

ogromnej liczby informacji o wymaganiach. Narzędzia

CASE pomagają np. w weryfikacji wymagań.

Zarządzanie zmianami

wymagań

• Zarządzanie zmianami wymagań należy zastosować

do wszystkich postulowanych zmian wymagań.

• Trzy podstawowe kroki:

– Analiza problemu i specyfikacja zmiany.

Proces rozpoczyna się od rozpoznania problemu z

wymaganiem lub czasem od konkretnej

propozycji zmiany.

– Analiza zmiany i ocena kosztów. Korzystając z

informacji o uzależnieniu i ogólnej wiedzy o

wymaganiach systemowych, ocenia się wpływ

proponowanej zmiany.

– Implementacja zmiany. Modyfikuje się

dokumentacje wymagań oraz, jeśli zachodzi taka

potrzeba, również projekt i implementacje

systemu.

Inżynieria

oprogramowania

Wykład 4 –

proces tworzenia oprogramowania

Prezentacja częściowo oparta na prezentacji przygotowanej przez Prof. J.E. Sienkiewicza

(opartej z kolei na podręczniku Iana Sommerville’a Inżynieria oprogramowania, WNT 2003)

Proces tworzenia

oprogramowania

• Zbiór czynności i związanych z nimi

wyników, które prowadzą do powstania

produktu programowego.

• Może obejmować tworzenie

oprogramowania od zera.

• Coraz częściej nowe oprogramowanie

powstaje przez rozszerzanie i

modyfikowanie istniejących systemów.

• Automatyzacja procesu tworzenia

oprogramowania jest niewielka.

Zasadnicze czynności w

procesie tworzenia

oprogramowania

• Specyfikowanie oprogramowania. Funkcjonalność

oprogramowania i ograniczenia jego działania
muszą być dobrze zdefiniowane. Tematyka
omówiona na wykładach nr 2 i 3.

• Projektowanie i implementowanie

oprogramowania. , Stworzone musi być
oprogramowanie, które spełnia specyfikację.

• Zatwierdzanie oprogramowania. Wykazanie, że

wytworzone oprogramowanie spełnia oczekiwania
klienta.

• Ewolucja oprogramowania. Oprogramowanie musi

ewoluować, aby spełniać zmieniające się
potrzeby użytkowników.

Modele procesów tworzenia

oprogramowania

• Model kaskadowy

– W tym modelu podstawowe czynności specyfikowania,

tworzenia, zatwierdzania i ewolucji są odrębnymi fazami

procesu.

• Tworzenie ewolucyjne

– W tym procesie czynności specyfikowania, projektowania i

zatwierdzania przeplatają się.

• Tworzenie formalne systemu

– To podejście jest oparte na budowaniu formalnych

matematycznych specyfikacji systemu i przekształcaniu tych

specyfikacji w program za pomocą metod matematycznych.

• Tworzenie z użyciem wielokrotnym

– W tym podejściu zakłada się istnienie dużej liczby

komponentów zdatnych do ponownego użycia.

Model kaskadowy

Definiowanie wymagań

Projektowanie systemu

i oprogramowania

Implementacja i testowanie

jednostek

Integracja i
testowanie
systemu

Działanie i pielęgnacja

Problemy modelu kaskadowego

•

Następnej fazy nie powinno się rozpoczynać,

jeśli poprzednia się nie zakończy.

•

Koszty opracowania i akceptacji dokumentów

są wysokie i dlatego iteracje są również

kosztowne oraz wymagają powtarzania wielu

prac.

•

Wadą modelu kaskadowego jest zawarty w

nim nieelastyczny podział na rozłączne etapy.

•

Model kaskadowy powinien być używany

jedynie wówczas, gdy wymagania są jasne i

zrozumiałe.

Tworzenie

ewolucyjne

• Tworzenie ewolucyjne polega na opracowaniu wstępnej

implementacji, pokazaniu jej użytkownikowi z prośbą o
komentarze i udoskonalaniu jej w wielu wersjach aż do
powstania odpowiedniego systemu.

Wersja
początko
wa

Ogólny opis

Specyfikacja

Tworzenie

Zatwierdzanie

Wersje pośrednie

Wersja końcowa

czynności równoległe

Typy tworzenia ewolucyjnego

• Tworzenie badawcze

– Celem procesu jest praca z klientem, polegająca

na badaniu wymagań i dostarczeniu

ostatecznego systemu. Tworzenie rozpoczyna się

od tych części systemu, które są dobrze

rozpoznane. System ewoluuje przez dodawanie

nowych cech, które proponuje klient.

• Prototypowanie z porzuceniem

– Celem procesu jest zrozumienie wymagań klienta

i wypracowanie lepszej definicji wymagań

stawianych systemowi. Budowanie prototypu ma

głównie na celu eksperymentowanie z tymi

wymaganiami użytkownika, które są niejasne.

Tworzenie ewolucyjne –

zastosowania i problemy

• Stosowanie

– W wypadku systemów małych lub średnich oraz

tych z krótkim czasem życia, podejście

ewolucyjne jest najlepsze ze wszystkich modeli.

– W wypadku dużych systemów o długim czasie

życia wady tworzenia ewolucyjnego ujawniają

się jednak z całą ostrością.

• Problemy

– Proces nie jest widoczny

– System ma często złą strukturę

– dokumentacja czasami nie jest aktualna

– Konieczne mogą być specjalne narzędzia i

techniki

Tworzenie formalne

systemów

• Podejście, które ma wiele wspólnego z modelem kaskadowym.

Proces tworzenia jest tu jednak oparty na matematycznych

przekształceniach specyfikacji systemu w program wykonywalny.

• W procesie przekształcania formalna matematyczna

reprezentacja systemu jest metodycznie przekształcana w

bardziej szczegółowe, ale wciąż matematycznie poprawne

reprezentacje systemu.

• Podejście z przekształceniem złożone z ciągu małych kroków jest

łatwiejsze w użyciu. Wybór, które przekształcenie zastosować,

wymaga jednak dużych umiejętności.

• Najlepiej znanym przykładem takiego formalnego procesu

tworzenia jest Cleanroom, pierwotnie opracowany przez IBM

(Proces Cleanroom jest oparty na przyrostowym tworzeniu

oprogramowania, gdy formalnie wykonuje się każdy krok i

dowodzi jego poprawności.)

Definicja
wymagań

Specyfikacja
formalna

Przekształce
nie
formalne

Integracja i testowanie
systemu

Przekształcenia formalne

R2

R3

P2

P3

P4

T1

T2

T3

T4

R1

P1

Specyfikacja
formalna

Program

wykonywal

ny

Tworzenie formalne –

zastosowania i problemy

•

Oprócz specjalistycznych dziedzin procesy

oparte na przekształceniach formalnych są

używane rzadko.

•

Wymagają specjalistycznej wiedzy i w

praktyce okazuje się, że w wypadku

większości systemów nie powodują

zmniejszenia kosztów lub polepszenia

jakości w porównaniu z innymi

podejściami.

•

Interakcje systemów nie poddają się łatwo

specyfikowaniu formalnemu.

Tworzenie z użyciem

wielokrotnym

•

W większości przedsięwzięć programistycznych występuje

wielokrotne użycie oprogramowania.

•

Etapy procesu:

–

analiza komponentów,

–

modyfikacja wymagań,

–

projektowanie systemu z użyciem wielokrotnym,

–

tworzenie i integracja.

•

Zakłada się istnienie dużego zbioru dostępnych

komponentów programowych do użycia wielokrotnego

oraz integrującej je struktury.

Specyfikacja

wymagań

Zatwierdzen

ie

systemu

Tworzenie i

integracja

Projekt

systemu z

użyciem

wielokrotnym

Analiza

komponentów

Modyfikacja

wymagań

Iteracja procesu

• Potrzebne jest także wspomaganie procesu

tworzenia oprogramowania nazywane
iteracjami, które polega na powtarzaniu
fragmentu tego procesu w miarę ewolucji
wymagań stawianych systemowi (na przykład
prace projektowe i implementacyjne musza
być ponownie wykonane, aby spełnić
zmienione wymagania).

• Mamy tutaj dwa hybrydowe modele:

– tworzenie przyrostowe,
– tworzenie spiralne.

Tworzenie przyrostowe

•

Podejście przyrostowe do tworzenia zaproponowane

w 1980 r. jako sposób na ograniczenie

powtarzania prac w procesie tworzenia oraz danie

klientom pewnych możliwości odkładania decyzji o

szczegółowych wymaganiach do czasu, aż zdobędą

pewne doświadczenia w pracy z systemem.

•

W procesie przyrostowym klienci identyfikują w

zarysie usługi, które system ma oferować. Wskazują,

które z nich są dla nich najważniejsze, a które

najmniej ważne. Definiuje się następnie pewną liczbę

przyrostów, które maja być dostarczone.

•

Gdy przyrost jest już gotowy i dostarczony, klienci

mogą go uruchomić. Oznacza to, że szybko

otrzymują część funkcjonalności systemu

Tworzenie przyrostowe –

schemat

Zdefiniuj zarys
wymagań

Wytwórz
przyrost
systemu

Przypisz wymagania
do przyrostów

Zweryfikuj
przyrost

Zaprojektuj
architekturę systemu

Zintegruj system

Zweryfikuj system

System
końcowy

System nie ukończony

Zalety procesu tworzenia

przyrostowego

• Klienci nie muszą czekać na dostarczenie całego

systemu, zanim zaczną czerpać z niego korzyść.

• Klienci mogą używać wstępnych przyrostów jako

rodzaju prototypu i zdobywać doświadczenia,
które inspirują wymagania wobec późniejszych
przyrostów.

• Ryzyko całkowitej porażki przedsięwzięcia jest

mniejsze.

• Usługi o najwyższym priorytecie będą

dostarczane jako pierwsze.

Tworzenie spiralne

•

Zaproponowany w 1998 r.

•

Proces nie jest przedstawiany jako ciąg

czynności z pewnymi nawrotami między

nimi, ale ma postać spirali.

•

Każda pętla spirali reprezentuje jedną

fazę procesu.

•

Najbardziej wewnętrzna pętla może być

poświęcona wykonalności systemu,

następna definicji wymagań stawianych

systemowi, kolejna projektowaniu itd.

•

Jawne potraktowanie zagrożeń.

Model spiralny

Określ cele,
inne strategie
i ograniczenia

Oceń inne strategie,
rozpoznaj i zmniejsz
zagrożenia

RECENZJA

Plan wymagań
Plan cyklu życia

Plan tworzenia

Plan testowania
i integracji

Zaplanuj następną
fazę

Analiza zagrożeń

Analiza zagrożeń

Analiza zagrożeń

Analiz
a
zagroż
eń

Prototyp 1

Prototyp 2

Prototyp 3

Działający
prototyp

Sposób
postępowania

Symulacje, modele, miary odniesienia

Zatwierdzenie
wymagań

Wymagan
ia

Projekto-
wanie
produktu

Weryfikacja i
zatwierdzenie

Działanie

Testy
akceptacji

Testy
integracji

Testy
jednostek

Kodowanie

Szczegółowe
projektowanie

Utwórz, zweryfikuj
produkt następnego
poziomu

Każda pętla spirali jest

podzielona na cztery sektory:

• Ustalanie celów

– Definiuje się konkretne cele tej fazy

przedsięwzięcia. Identyfikuje się ograniczenia,

którym podlega proces i produkt.

• Rozpoznanie i redukcja zagrożeń

– Przeprowadza się szczegółową analizę każdego z

rozpoznanych zagrożeń przedsięwzięcia

.

• Tworzenie i zatwierdzanie

– Po ocenie zagrożeń wybiera się model tworzenia

systemu.

• Planowanie

– Recenzuje się przedsięwzięcie i podejmuje

decyzję, czy rozpoczynać następną pętlę spirali.

Projektowanie i

implementowanie

oprogramowania

• Projekt oprogramowania to opis struktury

oprogramowania, które ma być
zaimplementowane, danych, które są częścią
systemu, interfejsów między komponentami
systemu i użytych algorytmów.

• Proces projektowania może obejmować

opracowanie kilku modeli systemu na różnych
poziomach abstrakcji.

• Faza implementowania w tworzeniu

oprogramowania to proces przekształcania
specyfikacji systemu w działający system, na
postawie projektu.

Charakterystyczne czynności

procesu projektowania

• Projektowanie architektury
• Specyfikowanie abstrakcyjne
• Projektowanie interfejsów
• Projektowanie komponentów
• Projektowanie struktur danych
• Projektowanie algorytmów

Ogólny model procesu

projektowania

Projektowanie
architektury

Specyfikowanie
abstrakcyjne

Projektowanie
interfejsów

Projektowanie
komponentów

Architektura
systemu

Specyfikacja
oprogramowa
nia

Specyfikacja
interfejsów

Specyfikacja
komponentów

Projektowanie
struktury
danych

Specyfikacja
struktury
danych

Specyfikacja
algorytmów

Projektowanie
algorytmów

Specyfikacja
wymagań

Produkty projektowania

Czynności projektowe

Metody projektowania

• Ciągle często projektowanie jest działaniem ad

hoc, bez formalnej kontroli zmian ani

zarządzania projektowaniem.

• Lepsze podejście polega na użyciu metod

strukturalnych, które są zbiorami notacji i porad

dla projektantów oprogramowania. Ich użycie

polega zwykle na opracowaniu graficznych

modeli systemu i prowadzi do dużej ilości

dokumentacji projektowej.

• Metody strukturalne mogą obejmować:

– modele przepływu danych,
– modele encja-związek,
– modele strukturalne,
– modele obiektowe.

Zatwierdzanie

oprogramowania

• Weryfikacja i zatwierdzenie mają

wykazać, że system jest zgodny ze swoją
specyfikacją i spełnia oczekiwania klienta.

• Obejmuje proces sprawdzania, m.in.

kontrole i recenzje w każdym kroku
procesu tworzenia, od definicji wymagań
użytkownika aż do implementacji.

• Z wyjątkiem małych programów, nie

należy testować systemu jako
pojedynczej całości.

Programowanie

i wyszukiwanie błędów

• Programiści wykonują pewne testy kodu, który

napisali. Zwykle prowadzi to do wykrycia
błędów, które należy usunąć z programu.

• Testowanie programu i usuwanie błędów to

dwa różne procesy.

• Lokalizacja błędu może wymagać nowych

przypadków testowych.

Napra
w błąd

Napr
aw
błąd

Przetestuj program
ponownie

Zlokalizuj
błąd

Zaprojektuj
naprawę błędu

Napraw błąd

Fazy procesu testowania

•

Testowanie komponentów (jednostek)

–

Testuje się poszczególne komponenty, aby zapewnić,

że działają poprawnie.

•

Testowanie modułów

– Moduł jest kolekcją niezależnych komponentów takich

jak klasy obiektów, abstrakcyjne typy danych, albo

bardziej luźną kolekcją procedur i funkcji.

•

Testowanie podsystemów

–

Testowanie kolekcji modułów, które zintegrowano w

podsystemie.

•

Testowanie systemu

–

Proces ma wykryć błędy wynikające z

nieprzewidzianych interakcji między podsystemami

zintegrowanymi w pełen system oraz problemy z

interfejsami podsystemów.

Testowanie odbiorcze

–

Jest to końcowa faza procesu testowania przed

przyjęciem systemu do użytkowania.

Testowanie alfa i beta

• Testowanie alfa jest testowaniem odbiorczym,

stosowanym kiedy system jest tworzony dla

konkretnego klienta. Proces testowania trwa

do momentu osiągnięcia zgody pomiędzy

wytwórcą systemu i klientem co do tego, że

dostarczony system jest możliwą do przyjęcia

implementacją wymagań.

• Testowanie beta stosuje się, kiedy system

sprzedawany jako produkt programowy.

Testowanie polega na dostarczeniu systemu

pewnej liczbie potencjalnych klientów, którzy

zgodzili się z niego korzystać. Klienci

informują wytwórców o pojawiających się

problemach.

Ewolucja oprogramowania

•

Elastyczność systemów oprogramowania jest jedną z

głównych przyczyn, że coraz więcej i więcej oprogramowania

włącza się do wielkich, złożonych systemów.

•

W przypadku oprogramowania, w przeciwieństwie do sprzętu,

zmiany mogą być wprowadzone w każdej chwili tworzenia

systemu, lub nawet po jego zakończeniu.

•

Koszt tych zmian może być bardzo wysoki, ale wciąż będzie

niższy niż odpowiednie zmiany w sprzęcie systemu.

Zidentyfikuj

wymagania

stawiane systemowi

Zbadaj istniejące

systemy

Zaproponuj zmiany

systemów

Zmodyfikuj

system

Nowy system

Istniejące

systemy

Zautomatyzowane wspomaganie

procesu tworzenia

oprogramowania

•

Komputerowo wspomagana inżynieria oprogramowania

(CASE) korzysta z różnego oprogramowania do

wspomagania czynności procesu tworzenia

oprogramowania, takich jak inżynieria wymagań,

projektowanie, programowanie i testowanie.

•

Czynności, które można zautomatyzować za pomocą CASE:

– oprogramowanie graficznych modeli systemu jako części

specyfikacji wymagań i projektu oprogramowania,

– czytanie projektu za pomocą słownika danych, który

przechowuje informacje o encjach i związkach w

projekcie,

– generowanie interfejsu użytkownika na podstawie

graficznego opisu interfejsu, opracowanego

interaktywnie przez użytkownika,

– śledzenie błędów przez udostępnienie informacji o

wykonującym się programie,

– automatyczne tłumaczenie programów ze starych wersji

języków programowania.

Technologia CASE

• Technologia CASE jest obecnie dostępna dla

większości rutynowych czynności procesu

tworzenia oprogramowania.

• Inżynieria oprogramowania jest głównie

czynnością projektową opartą na kreatywnym

myśleniu. Istniejące systemy CASE automatyzują

pewne rutynowe czynności, ale próby

zastosowania sztucznej inteligencji do

wspomagania programowania nie powiodły się

dotychczas.

• W większości firm procesy związane z inżynierią

oprogramowania są czynnością zespołową.

Inżynierowie spędzają więc sporo czasu na

interakcji z innymi członkami zespołu. Technologia

CASE nie daje tu zbyt dużego wsparcia.

Klasyfikacja narzędzi CASE

•

Narzędzia do planowania

–

Narzędzia do szacowania kosztów, arkusze kalkulacyjne

•

Narzędzia do zarządzania zmianami

–

Narzędzia do zapisu i śledzenia wymagań, systemy

kontroli zmian, systemy zarządzania wersjami

•

Narzędzia do projektowania

–

Edytory i procesory tekstów, edytory diagramów

•

Narzędzia do zarządzania konfiguracjami

–

Narzędzia do budowania systemów, systemy

zarządzania wersjami

•

Narzędzia do prototypowania

–

Języki bardzo wysokiego poziomu, generatory interfejsu

użytkownika

•

Narzędzia wspomagające

–

Edytory projektów, słowniki danych

Klasyfikacja narzędzi CASE

(c.d.)

•

Narzędzia do przetwarzania kodu źródłowego

–

Kompilatory, interpretatory

•

Narzędzia do analizy programów

–

Generatory wzajemnych odwołań, analizatory

statyczne, analizatory dynamiczne

•

Narzędzia do testowania

–

Dane testowe, programy porównujące pliki

•

Narzędzia do usuwania błędów

–

Systemy interakcyjnego usuwania błędów

•

Narzędzia do dokumentowania

–

Programy do składu tekstu, edytory rysunków

•

Narzędzia do wyszukiwania

–

Systemy wyszukiwania wzajemnych odwołań,

programy do restrukturyzacji systemów

Inżynieria

oprogramowania

Wykład 5 –

projektowanie obiektowe: klasa, obiekt,

związek, budowa modelu obiektowego

Prezentacja częściowo oparta na prezentacji przygotowanej przez Prof. J.E. Sienkiewicza

(opartej z kolei na podręczniku Iana Sommerville’a Inżynieria oprogramowania, WNT 2003)

Projektowanie obiektowe

• Strategia projektowania, w ramach której

projektanci systemu myślą w kategoriach

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

• Działający system składa się z oddziałujących na

siebie obiektów, które przechowują swój lokalny

stan i oferują operacje testujące lub zmieniające

ten stan.

• Obiekty ukrywają informację o reprezentacji stanu

i w ten sposób ograniczają do niego dostęp.

• Proces projektowania obiektowego obejmuje

zaprojektowanie klas obiektów i związków (relacji)

między tymi klasami.

• W działającym programie, potrzebne obiekty są

tworzone na podstawie definicji klas.

Strategie obiektowe

• Analiza i projektowanie obiektowe polegają

na opracowaniu modelu obiektowego dla danej

dziedziny zastosowania przy uwzględnieniu

zidentyfikowanych wymagań. Rozpoznane obiekty

odzwierciedlają byty i operacje związane z

rozwiązywanym problemem.

• Programowanie obiektowe polega na realizacji

projektu

oprogramowania

za

pomocą

obiektowego

języka

programowania.

Języki

obiektowe,

takie

jak

Java,

umożliwiają

bezpośrednią

implementację

obiektów

i

dostarczają udogodnienia do definiowania klas

obiektów.

Obiekt

(ang. object)

• Obiekt jest bytem, który posiada swój stan i

zbiór zdefiniowanych operacji działających na tym
stanie.
- stan jest reprezentowany jako zbiór atrybutów

(ang. attributes)

obiektu.

- operacje

(ang. operations)

skojarzone z obiektem

służą do oferowania usług innym obiektom
(klientom), które mogą żądać tych usług, gdy
potrzebują wyników ich działania.

• Obiekty są tworzone zgodnie z definicja klasy

obiektów. Definicja klasy obiektów służy jako
szablon do tworzenia obiektów. Zawiera
deklaracje wszystkich atrybutów i operacji, które
należy skojarzyć z obiektem tej klasy.

Klasa obiektów

(ang. class)

• Grupa obiektów może mieć wspólną definicję

danych lub usług wykorzystywanych do definicji
interfejsu, stanowiąc wcielenie (instancje)
wspólnej definicji zwanej klasą obiektów.

• Innymi słowy: pojęcie klasy umożliwia

wyróżnienie podobnej grupy obiektów według
pewnego kryterium (pewnych cech, którymi są
atrybuty i operacje).

• Jeżeli mamy zdefiniowaną klasę, to mówimy, że

obiekt należący do niej jest instancją tej klasy

(ang. instance)

.

Klasa – reprezentacja graficzna

(w języku UML)

Przykład - klasa Pracownik

tatus: {current, left, retired}

taxCode: integer

. . .

join ()

leave ()

retire ()

changeDetails (

Pracownik

+ nazwisko : string
+ adres : string
+ dataUrodzenia : Date
+ licznikPracowników : integer
+ PESEL : string
+ dział : Dział
+ przełożony : Pracownik
+ wynagrodzenie : integer = 0
+ stan : {zatrudniony, zwolniony,
emerytowany}
+ NIP : integer
- numerPracownika : integer
+ zatrudnij()
+ zwolnij()
+ przejdźNaEmeryturę()
+ dajPodwyzke(kwota)
# sprawdzPoprawnoscNumeruPESEL()

Jan Kowalski :
Pracownik

Obiekt
(instancja) klasy
Pracownik:

Komunikacja pomiędzy

obiektami

• Obiekty porozumiewają się przez żądania usług od

innych obiektów (wywołania operacji), i jeśli trzeba,

wymianę informacji niezbędnych do realizacji usługi.

• Kopie informacji potrzebnych do wykonania usługi i

wyniki jej wykonania są przekazywane jako parametry.

• Obiekt odbiorca analizuje składniowo komunikat,

rozpoznaje usługę i przekazane dane a następnie

realizuje żądaną usługę.

• Przykłady komunikacji:

//

Wywołaj

operację

(w

obiektowych

językach

programowania operacje nazywa się metodami) dla

obiektu buforCykliczny, która pobiera kolejną wartość z

bufora i zapisuje ją do zmiennej.

w = buforCykliczny.pobierz()

// Wywołaj metodę termostatu, ustawiającą temperaturę

termostat.ustawTemperaturę(20);

Związki między klasami

• W modelu zwykle istnieją różne zależności (wiązania, ang. links)

pomiędzy obiektami należącymi do różnych klas obiektów.

stan o3

o3 : K3

stan o4

o4 : K4

stan o1

o1 : K1

o6 : K6

stan o5

o5 : K5

stan o2

o2 : K2

stan o6

• Zależności te reprezentuje się przez związek (inaczej relację,

ang. association) między klasami.

Związki między klasami

Powiązanie

• Najprostszym, ogólnym związkiem jest powiązanie

(ang. binary association; general association). Używa

się go do wskazania, że atrybut obiektu jest powiązany

z innym obiektem, albo że implementacja metody

korzysta

z

powiązanego

obiektu.

Powiązanie

modelowane jest linią łączącą klasy obiektów, która

może mieć dodatkowe adnotacje (opis związku).

Istnieją również powiązania n-arne, łączące ze sobą

więcej niż 2 klasy.

jest-
członkiem►

jest-zarządzany-przez

zarządza

Kierownik

Dział

Pracownik

Związki między klasami

Uogólnienie

(dziedziczenie, implementacja,

ang. generalization, inheritance,

implementation

)

• Klasy obiektów można ułożyć w hierarchię

uogólnienia, w której widać związek między

ogólnymi i bardziej szczegółowymi klasami obiektów.

• Szczegółowa klasa obiektów jest w pełni zgodna z

ogólną klasą obiektów, ale zawiera więcej informacji.

• W UML uogólnienie obrazuje się za pomocą obrazów

strzałki wskazującej klasę macierzystą.

• W obiektowych językach programowania uogólnienie

zwykle implementuje się za pomocą mechanizmu

dziedziczenia. Klasa potomna dziedziczy atrybuty i

operacje po klasie macierzystej.

Hierarchia uogólnień

Pracownik

Kierownik

zarządzaneBud
żety
dataPrzyjęcia

Programista

przedsięwzięci
e
językiProgr

Kierownik

Przedsięwzięcia

przedsięwzięcie

Kierownik
Działu

dział

Kierownik
Strategiczny

obowiązki

Zalety uogólniania

• Oszczędność czasu, przejrzystość i
wygoda: klasy niższe w hierarchii mają te
same atrybuty i operacje co ich klasy
macierzyste, mogą jednak dodawać nowe
atrybuty i operacje lub modyfikować
niektóre z tych odziedziczonych.

• Bezpieczeństwo: zasada uogólniania
działa jedynie w jednym kierunku.

Związki między klasami

Agregacja i kompozycja

Agregacja

(ang. aggregation)

: tworzenie nowej

klasy, przy użyciu klas już istniejących.

Nowa klasa może być zbudowana z

dowolnej liczby obiektów (obiekty te

mogą być dowolnych typów) i w

dowolnej kombinacji, by uzyskać

żądany efekt. Jest to relacja typu

"zawiera" np: "samochód zawiera koła i

silnik" - gdzie „samochód”, „koło” i

„silnik” są klasami. Symbol – linia

zakończona rombem.

Kompozycja

(ang. composition)

: składanie się

obiektu z obiektów składowych, które

nie mogą istnieć bez obiektu głównego.

Kompozycja jest relacją typu "posiada".

Dana część może należeć tylko do

jednej całości. Część nie może istnieć

bez całości, a usunięcie całości

powoduje automatyczne usunięcie

wszystkich części związanych z nią

związkiem kompozycji. Symbol – linia

zakończona zaczernionym rombem.

Związki między klasami

Zależność

• Zależność

(ang. dependency)

między klasami

zachodzi, jeżeli zmiany dokonane w stanie

jednego z obiektów danej klasy mogą mieć

wpływ na obiekt należący do innej klasy.

Związek, tak jak i obiekt, też może posiadać atrybuty
(tzw. związek kwalifikowany).

prawa dostępu

Plik

Użytkownik

Krotność związku

• Krotność związku

(ang. multiplicity)

określa, ile

obiektów danej klasy jest równocześnie związana

z obiektami innej klasy

0..1

Zero lub jeden

1

Tylko jeden

n

Tylko n (gdzie n > 1)

0..*

Zero lub więcej (skrót: *)

1..*

Jeden lub więcej

0..n

Od zera do n (gdzie n > 1)

1..n

Od jednego do n (gdzie n >

1)

Stereotypy

• Idea stereotypów

(ang. stereotypes)

polega na

ustaleniu pewnej meta-klasyfikacji obiektów (i

innych bytów) i wprowadzeniu oznaczeń

graficznych klas zgodnych z tą meta-klasyfikacją.

• Przykład: obiekty interfejsu, obiekty sterujące i

obiekty rzeczywiste.

• Oznaczenie: ciągi znaków wewnątrz nawiasów «

»; np. «interface»

Budowa modelu obiektowego

• Identyfikacja klas obiektów

Podejście praktyczne polega na wyselekcjonowaniu

rzeczowników z Specyfikacji Wymagań Systemowych

i potraktowaniu ich jako identyfikatorów klas

obiektów.
Innym źródłem identyfikacji obiektów mogą być:

– Specyfikacja przypadków użycia

– dodatkowe klasy obiektów wynikające z ogólnej

wiedzy na temat problemu.

• Identyfikacja związków między klasami

– Wstępna identyfikacja przez rozpatrzenie ze

specyfikacji wymagań fraz zawierających

czasowniki.

Budowa modelu obiektowego

• Identyfikacja atrybutów i operacji

– Wstępna identyfikacja atrybutów polega na

rozważeniu przymiotników, wyrażeń
dzierżawczych odnoszących się do już
zidentyfikowanych klas i związków.

– Wstępna identyfikacja operacji m.in. na

podstawie modelu przypadków użycia.

• Optymalizacja modelu

– Identyfikacja związków dziedziczenia
– Grupowanie klas w moduły (pakiety)
– Weryfikacja, walidacja i uszczegóławianie modelu

DIAGRAM KLAS

Diagram klas

•

Diagram klas - statyczny diagram strukturalny,

przedstawiający strukturę systemu w modelach obiektowych,

przez ilustrację struktury klas i zależności między nimi.

Inżynieria

oprogramowania

Wykład 6 –

Więcej o UML (Unified Modeling

Language, ujednolicony język

modelowania)

Prezentacja częściowo oparta na prezentacji przygotowanej przez Bartosza Waltera (UW)

Historia projektowania

obiektowego

•

Początki projektowania obiektowego: lata 70-te XX

wieku; najważniejsze metodologie obiektowe:
- OOADA (Object-Oriented Analysis and Design with
Aplications) - Grady Booch – nacisk na projektowanie
- OOSE (Object Oriented Software Engineering) - Ivar

Jacobson – nacisk na inżynierię wymagań
- OMT (Object Modeling Technique) - James
Rumbaugh – nacisk na analizę

Historia UML

• Język UML: unifikacja metod Boocha, Jacobsona i

Rumbaugh (1994 r.) – z poszczególnych notacji

przejęto najlepsze rozwiązania

• Język początkowo wspierany przez firmę Rational

Software (program Rational Rose)

• Najbardziej rozpowszechnione wersje UML: 1.1

(1997) oraz 1.4 (2002 r.)

• 2005 r. – wersja UML 1.4 oficjalnym ,

międzynarodowym standardem projektowania

aplikacji (Information technology: ISO/IEC

19501:2005)

• Bieżąca, oficjalna wersja: 2.0 (2005 r.)

• Wersja 2.1 w końcowej fazie specyfikacji (2007 r.)

• Obecnie język UML nie posiada praktycznie

konkurencji w dziedzinie obiektowego projektowania

aplikacji

OMG - Object Management

Group

• OMG – niekomercyjna organizacja powstała w

1989 r. Jej celem jest promowanie teorii oraz

praktyki technologii obiektowych.

• Założycielami OMG było 13 liczących się

przedsiębiorstw z branży software'owej.

• Obecnie do organizacji należy ponad 750 firm -

producentów oprogramowania oraz sprzętu

komputerowego.

• Organizacja zajmuje się opracowywaniem

standardów pomagających w tworzeniu aplikacji

obiektowych.

• W 1997 r. OMG włączyła się do prac nad UML

• 2005 r. – OMG doprowadziła do uznania UML 1.4

jako oficjalnego standardu.

Czym jest UML?

• UML jest językiem do specyfikacji, wizualizacji,

konstrukcji, dokumentowania projektów
związanych z systemami informacyjnymi
intensywnie wykorzystującymi oprogramowanie,
a także do modelowania biznesowego wszelkich
innych systemów.

• UML oferuje standaryzowany sposób zapisu

projektu, obejmującego zarówno jego
konceptualne aspekty, takie jak procesy
biznesowe czy funkcje systemu, jak też i
elementy fizyczne (np. schematy bazy danych,
warstwę sprzętową systemu).

• UML standaryzuje notację graficzną – określa

sposób zapisu modeli.

Czym nie jest UML?

• UML nie jest metodyką

– UML nie określa metody modelowania
– zaleca jedynie stosowanie podejścia
przyrostowego

• UML nie jest narzędziem

– UML to specyfikacja dla narzędzi

• UML nie jest językiem programowania

– generowanie kodu z modelu stosowane jest
obecnie na niewielką, choć stale zwiększającą się
skalę (przyczyna: dopiero teraz powstają
narzędzia CASE lepiej wspomagające ten proces)

„Perspektywy” UML

• Perspektywa przypadków użycia – opisuje funkcjonalność, jaką

powinien dostarczać system, widzianą przez jego użytkowników.

• Perspektywa logiczna – zawiera sposób realizacji

funkcjonalności, strukturę systemu widziana przez projektanta.

• Perspektywa implementacyjna – opisuje poszczególne moduły i

ich interfejsy wraz z zależnościami; perspektywa ta jest
przeznaczona dla programisty.

• Perspektywa procesowa – zawiera podział systemu na procesy

(czynności) i procesory (jednostki wykonawcze); opisuje
właściwości pozafunkcjonalne systemu i służy przede także
programistom i integratorom.

• Perspektywa wdrożenia – definiuje fizyczny podział elementów

systemu i ich rozmieszczenie w infrastrukturze; perspektywa
taka służy integratorom i instalatorom systemu.

Diagramy UML 2.0

diagram klas (class)
diagram obiektów (object)
diagram struktur złożonych (composite structure)
diagram pakietów (package diagram)
diagram komponentów (component)
diagram wdrożenia (deployment)
diagram przypadków użycia (use cases)
diagram maszyny stanowej (state machine)
diagram czynności (activity)
diagram sekwencji (sequence)
diagram komunikacji (communication)
diagram przeglądu interakcji (interaction overview)
diagram uwarunkowań czasowych (timing)

diagramy strukturalne

diagramy zachowania
(behawioralne)

diagramy
interakcji

Diagram przypadków użycia

• Modelowanie użytkowników systemu (aktorów)
i ich potrzeb w stosunku do tworzonego systemu.

• Omówiony na wykładzie nr 2

Diagram klas

• Przedstawia klasy występujące w systemie
i statyczne relacje pomiędzy nimi

• Omówiony na wykładzie nr 5

Diagram obiektów

• Diagram obiektów prezentuje możliwą konfigurację

obiektów w określonym momencie. Jest pewnego

rodzaju instancją diagramu klas, w której zamiast

klas przedstawiono ich obiekty.

• Diagram posługuje się identycznymi symbolami co

diagram klas, zamiast symboli klas występują

symbole obiektów.

Diagramy obiektów przydają się w
przypadku szczególnie
skomplikowanych zależności,
których nie można przedstawić na
diagramie klas.
Wówczas przykładowe konfiguracje
obiektów pomagają w zrozumieniu
modelu.

Diagram struktur złożonych

• Diagram przedstawia hierarchicznie wewnętrzną strukturę

złożonego obiektu z uwzględnieniem punktów interakcji z

innymi częściami systemu.

• Obiekt składa się z części, które reprezentują poszczególne

składowe obiektu realizujące poszczególne funkcje obiektu.

Komunikacja pomiędzy obiektem, a jego środowiskiem

przebiega poprzez port (oznaczany jako mały prostokąt

umieszczony na krawędzi obiektu). Porty są połączone z

częściami obiektu, które są odpowiedzialne za realizacje tych

funkcji.

Diagramy struktur

złożonych mogą

zawierać interfejsy

wewnętrzne i

interfejsy

udostępnione,

widoczne na

zewnątrz obiektu

Diagram komponentów

• Komponent to wymienny, wykonywalny fragment systemu o

hermetyzowanych szczegółach implementacyjnych.

Komponenty z natury służą do ponownego wykorzystania

poprzez połączenie ich z innymi komponentami, zwykle

poprzez ich skonfigurowanie, bez potrzeby rekompilacji.

• Funkcjonalność oferowana przez komponent jest dostępna

przez interfejsy, które ten implementuje. Z drugiej strony,

komponent może wymagać pewnych interfejsów, które muszą

być dostarczone przez inne komponenty.

• Diagram

komponentó

w

przedstawia

komponenty

, ich

interfejsy

oraz

zależności

pomiędzy

nimi.

Diagram pakietów

Służy do modelowania fizycznego i logicznego
podziału systemu. Pakiety są elementem
strukturalizującym elementy UML i służą do
grupowania ich według dowolnego kryterium. W
pakiecie można umieścić praktycznie dowolne
elementy: klasy, komponenty, przypadki użycia,
pojemniki danych a także inne pakiety. W ten
sposób przedstawiają one drzewiastą strukturę
elementów modelu.

Diagram wdrożenia

• Odzwierciedla fizyczną strukturę całego systemu, z
uwzględnieniem oprogramowania i sprzętu.

• Jednostki oprogramowania są reprezentowane przez artefakty
(czyli skompilowane wersje komponentu, który można uruchomić),
dane i biblioteki.

• Stronę sprzętową reprezentują węzły, czyli poszczególne
urządzenia obliczeniowe, komunikacyjne i przechowujące,
powiązane ścieżkami komunikacyjnymi (np. połączeniem TCP/IP).

• Diagram ten istotną rolę odgrywa przy wdrażaniu dużych,
rozproszonych systemów.

Diagram stanów

(maszyny stanowej)

• Reprezentuje zachowanie systemu lub jego elementu

(zwykle obiektów danej klasy), a w szczególności zmiany
tego zachowania.

• Podstawowymi elementami diagramu są stany obiektu

połączone strzałkami przejść. Obiekt, reagując na
nadchodzące zdarzenia, jeżeli spełnione są określone
warunki, zmienia swój stan i położenie na diagramie
stanu.

Stan

•

Stan jest etapem cyklu życia obiektu. Obiekt przebywający

w danym stanie spełnia określony warunek.

•

Stany są reprezentowane przez prostokąty z zaokrąglonymi

narożnikami. Każdy stan ma swoją nazwę.

•

Ze stanem mogą być związane pewne akcje, wykonywane w

określonym momencie:
• entry: jest akcją wykonywaną w momencie gdy obiekt

przyjmuje dany stan; akcja ta jest wykonywana jeden raz i

niepodzielnie
• do: jest akcją wykonywaną nieprzerwanie w czasie, gdy

obiekt przebywa w tym stanie
• exit: oznacza (analogicznie do entry) moment opuszczenia

stanu; podobnie, akcja taka jest wykonywana tylko raz.
• event: reprezentuje akcję wykonywaną w momencie

nadejścia zdarzenia określonego typu

•

Wykonanie każdej z tych akcji może również generować

zdarzenie.

Przejścia pomiędzy stanami

•

Stany są powiązane ze sobą przejściami. Przejścia definiują warunki, jakie

muszą zaistnieć, aby obiekt zmienił swój stan ze źródłowego na docelowy.

Formalnie opis przejścia składa się z czterech elementów:
• wyzwalacza (ang. trigger) – zdarzenia, które może spowodować

przejście i zmianę stanu
• dozoru (ang. guard condition) – warunku, jaki musi być spełniony, aby

przejście zostało wykonane; warunek ten jest ewaluowany w momencie

pojawienia się wyzwalacza
• akcji (ang. action) – operacji wykonywanej w momencie przejścia ze

stanu do stanu; nawet jeżeli akcja przejścia jest złożona z wielu akcji

elementarnych, jest ona wykonywana niepodzielnie
• zdarzenia (ang. event) – wysyłanego w momencie wykonania przejścia.

Przykład –
diagram
dla obiektów
klasy
książka.
Przejście
pomiędzy
dwoma stanami:
Dostępna i
Zniszczona.

Pseudostany

•

Stany pomocnicze (pseudostany):
• początkowy, który reprezentuje obiekt w momencie jego

utworzenia.
• końcowy, który reprezentuje usunięcie obiektu z systemu.
• decyzja, przedstawiająca wybór pomiędzy dwiema wartościami

logicznymi pewnego wyrażenia.
• złączenie/rozwidlenie – powoduje synchronizację stanów

(wszystkie dochodzące do niego przejścia muszą być wykonane)
• historia (literka H w okręgu wewnątrz stanu) – zapewnia możliwość

zapamiętania poprzedniego stanu obiektu i przywrócenie go.

Diagram dla obiektów klasy
rezerwacja.

Stany złożone

•

Stany złożone

posiadają wewnętrzną

maszynę stanów.

Wejście do stanu jest

jej stanem

początkowym, a

wyjście –końcowym.

Przykład –
pełny diagram
maszyny stanowej dla
obiektów klasy książka
(dla przejrzystości nie
uwzględnia akcji).

Diagram czynności

•

Prezentuje przepływ sterowania w systemie związany z

wykonaniem pewnej funkcji.

•

Przepływ łączy czynności wykonywane przez poszczególne

obiekty i stany obiektów, w których znajdują się po wykonaniu

czynności.

•

W odróżnieniu od diagramu maszyny stanowej, diagram

czynności może obejmować wiele obiektów na raz, zwykle

umieszczanych w odpowiednich torach.

<<Interfejs>>

: StacjaMeterologiczna

<<BazaDanych>>

: DaneMeteorologiczne

<<Aktor>>
: Obsługa

1: raportPogodowy()

2: testuj()

4: zbierzDane()

3: podsumuj()

5: danePogodowe

6: raport

Visual Paradigm for UML Community Edition [not for commercial use]

Diagram sekwencji

•

Prezentuje kolejność wywołań operacji, przepływ sterowania pomiędzy obiektami oraz
szablon realizowanego algorytmu.

•

Składa się z pionowych linii życia (ang. lifelines) poszczególnych obiektów
uczestniczących w interakcji oraz wymienianych między nimi komunikatów (wywołań
operacji). Białe prostokąty umieszczone na linii życia obiektu oznaczają, że obiekt jest
zajęty wykonywaniem pewnej czynności. Czas jest reprezentowany w postaci pionowej
osi diagramu. Fizycznie usunięcie obiektu można wprost oznaczyć jako znak X na linii
życia

Blok

•

Często zachodzi konieczność wskazania specjalnej własności pewnej części
interakcji, np. pętli. Na diagramach sekwencji taką grupę operacji obejmuje
się prostokątem, w którego lewym górnym narożniku, w pięciokącie
umieszcza się słowo kluczowe lub opis określający znaczenie danego bloku
(tzw. operator interakcji), np.:
• alt (od alternative) – określający warunek wykonania bloku operacji,
odpowiadający instrukcji if-else; warunek umieszcza się wówczas wewnątrz
bloku w nawiasach kwadratowych
• opt (od optional) – reprezentujący instrukcję if (bez else)
• par (od parallel) – nakazujący wykonać operacje równolegle
• critical – oznaczający obszar krytyczny
• loop – definiujący pętlę typu for (o określonej z góry liczbie iteracji) lub
while (wykonywanej dopóki pewien warunek jest prawdziwy)

Diagram komunikacji

•

Skupia się on na obiektach wchodzących w skład interakcji i
wymienianymi przez nie komunikatach, natomiast w
mniejszym stopniu niż diagram sekwencji wskazuje na aspekt
czasowy.

•

Komunikacje są przedstawiane za pomocą linii łączących
obiekty, natomiast przesyłane między obiektami komunikaty i
dane są umieszczane obok tych linii. Każdy komunikat jest
opatrzony etykietą liczbową, wskazującą na kolejność
wysłania. Etykieta ma postać liczb oddzielonych kropkami.

Diagram przeglądu interakcji

•

Służy do przedstawiania ogólnego przepływu sterowania w
interakcjach pomiędzy obiektami, korzystając z uproszczonej
notacji diagramu czynności.

•

Na jednym diagramie pokazany jest przepływ sterowania
pomiędzy interakcjami pokazanymi w postaci innych
diagramów, np. sekwencji.

•

Diagram ten może korzystać z większości elementów
obecnych na diagramach czynności: punktu decyzyjnego,
pętli, rozwidlenia i synchronizacji, etc.

Diagram uwarunkowań

czasowych

•

Specjalna forma diagramów interakcji, przeznaczona niemal
wyłącznie do prezentowania zależności związanych z czasem
wykonywania operacji przez obiekt lub grupę obiektów.

•

Linia czasu jest reprezentowana przez poziomą oś diagramu,
natomiast oś pionowa przedstawia kolejne obiekty uczestniczące w
interakcji oraz ich zmieniające się stany wewnętrzne. Odległości
pomiędzy momentami zmian stanów wyznaczają uwarunkowania
czasowe.

•

Diagram ten ma duże znaczenie w modelowaniu systemów czasu
rzeczywistego.

Rozszerzanie UML, język OCL

•

Mechanizm rozszerzania języka UML obejmuje trzy elementy:
- stereotypy (stereotypes), zmieniające lub doprecyzowujące
semantykę elementów modelu. Zapisywane są w danym elemencie w
postaci
<<nazwa stereotypu>>.
- metki (tagged values), dołączające do elementu dodatkowe
właściwości w postaci par {klucz = wartość}. Metki są dołączane do
elementów w postaci notatek.
- profile (profiles), zawierające predefiniowane zestawy stereotypów
i metek dla danej dziedziny zastosowań.

•

Język OCL (Object Constraint Language) – język formalnego
wyrażania ograniczeń w UML
- wyraża dowolną regułę logiczną: warunki wstępne, końcowe,
niezmienniki, wyniki metod etc. w postaci warunku zapisanego w
nawiasach klamrowych
- nie może modyfikować modelu, jedynie go sprawdzać
- można go związać z dowolnym elementem modelu (klasą, operacją,
atrybutem, asocjacją itp.)

Uwagi końcowe

•

Metodologia obiektowa także nie jest idealna.

•

Wiele celów łatwiej jest czasem osiągnąć stosując tradycyjne
metody projektowania.

•

Jednak ze względu na konieczność zapewnienia bezpiecznej
pracy przy tworzeniu dużych systemów informatycznych przez
duże zespoły projektantów – właśnie ta metodologia będzie
zapewne dominująca w przyszłości.

•

Krytycyzm UML:
- przeładowanie
- nie zawsze precyzyjny
- trudności w nauce (wynik powyższych dwóch wad)
- język „do wszystkiego”
- narzędzia CASE często implementują UML „po swojemu”

Budowa modelu

behawioralnego

• Identyfikacja scenariuszy:

– Zbiór scenariuszy, które opisują typowe interakcje

systemu ze światem zewnętrznym.

– Punktem wyjścia jest tu specyfikacja przypadków użycia

systemu, o ile została ona sprecyzowana w Specyfikacji
Wymagań Systemowych. Jeśli nie została, należy je
jawnie zidentyfikować i rozpatrzyć różne przypadki
użycia systemu.

• Identyfikacja zdarzeń:

– Dla danego scenariusza powstaje odpowiadający mu

ślad zdarzeń przedstawiający drogi przepływu zdarzeń
pomiędzy obiektami systemu.

• Budowa diagramów interakcji:

– Dla każdego scenariusza budowane są diagramy

sekwencji oraz (rzadziej) diagramy komunikacji,

przeglądu interakcji oraz przebiegów czasowych.

Budowa modelu

behawioralnego

(c.d.)

• Budowa diagramów stanu (maszyny stanowej):

– Dla każdej klasy modelu obiektowego tworzony jest

diagram stanów opisujących jej zachowanie. Jeśli

zachowanie obiektu klasy jest trywialne można pominąć

jawną specyfikacje ich diagramów stanu.

• Identyfikacja wejść i wyjść.
• Budowa diagramu czynności:

– Definiujemy podstawowe (nie podlegające dalszej

dekompozycji) transformacje danych opisywane jako
zależności funkcyjne między danymi wejściowymi i
wyjściowymi.

– tworzymy diagram czynności, który uwidacznia obliczenia

mające na celu wywiedzenie danych wyjściowych na
podstawie odpowiednich wejść.

• Identyfikacja ograniczeń:

– Identyfikacja zależności, których nie da się wyrazić w

terminach relacji wejście – wyjście i naniesienie ich na

diagramy.

Inżynieria

oprogramowania

Wykład 7 –

zarządzanie przedsięwzięciem

Prezentacja częściowo oparta na prezentacji przygotowanej przez Prof. J.E. Sienkiewicza

(opartej z kolei na podręczniku Iana Sommerville’a Inżynieria oprogramowania, WNT 2003)

Cechy zarządzania procesem

tworzenia oprogramowania

• Produkt jest nieuchwytny. Oprogramowania nie

można dotknąć ani zobaczyć. Zarządzający

standardowym procesem inżynierskim może

oglądać produkt w trakcie jego tworzenia, a jeśli nie

dotrzymano harmonogramu, widać to wyraźnie po

stanie produktu (pewne części budowanej struktury

są w oczywisty sposób nie ukończone). W przypadku

oprogramowania nie ma zwykle takiej możliwości.

• Nie ma standardowych procesów tworzenia

oprogramowania. Nie zostały jeszcze rozpoznane w

sposób wystarczająco precyzyjny związki między

procesem, a typem produktu.

• Wielkie przedsięwzięcia programistyczne są często

jednorazowe. Wielkie przedsięwzięcia

programistyczne są zwykle inne niż poprzednie

przedsięwzięcia.

Rola zarządzania

przedsięwzięciem

programistycznym

• Konieczność zarządzania stanowi istotną różnicę

między programowaniem amatorskim a

profesjonalnym tworzeniem oprogramowania.

• Zarządzanie przedsięwzięciami

programistycznymi jest niezbędne, ponieważ

profesjonalna inżynieria oprogramowania zawsze

podlega ograniczeniom budżetowym i czasowym,

ustalanym przez firmę budującą oprogramowanie.

• Zadaniem kierownika zarządzającego

przedsięwzięciem programistycznym jest

zapewnienie, że przedsięwzięcie zmieści się w

narzuconych ograniczeniach i doprowadzi do

dostarczenia oprogramowania.

Kierownik projektu

Naczelny inżynier

czy główny urzędnik?

• zdolność do przewidywania

• umiejętność motywowania

• przystosowanie się do zmieniającej się

sytuacji

• rozwijanie potencjału podwładnych

• zdolność komunikowania się

• zdecydowanie, zdolność do terminowego

podejmowania decyzji

Czynności procesu zarządzania

• Opracowywanie oferty
• Planowanie i tworzenie

harmonogramu przedsięwzięcia

• Szacowanie kosztów przedsięwzięcia
• Wybór i ocena personelu
• Opracowywanie raportów i

prezentacji

Uwagi wstępne

• Pierwsza faza to opracowanie oferty zawierającej cele i

sposoby realizacji. Zwykle zawiera oszacowanie

kosztów i wstępny harmonogram. Od umiejętności

przygotowywania ofert, która nabywa się wraz z

doświadczeniem, zależy ilość podpisanych kontraktów.

• Planowanie przedsięwzięcia polega na identyfikowaniu

czynności, odbiorców i produktów powstających w

przedsięwzięciu. Następnie należy sformułować plan,

który doprowadzi do osiągnięcia celów

przedsięwzięcia.

• Szacowanie kosztów jest czynnością powiązaną z

planowaniem, która polega na kalkulacji zasobów

koniecznych do realizacji przedsięwzięcia.

• Monitorowanie przedsięwzięcia jest ustawiczna

czynnością. Kierownik musi obserwować postęp

przedsięwzięcia i porównywać rzeczywiste koszty w

stosunku do planów.

Ogólny plan przedsięwzięcia

• Wprowadzenie, w którym opisuje się cele i ograniczenia (np.

budżetu i czasu) mające wpływ na zarządzanie.

• Organizacja przedsięwzięcia, w której opisuje się sposób

organizacji zespołu wytwórczego, osoby i ich funkcje w zespole.

• Analiza zagrożeń, w której opisuje się zagrożenia

przedsięwzięcia, prawdopodobieństwo ich wystąpienia i

proponowane strategie ich zmniejszenia.

• Wymagania stawiane zasobom sprzętowym i programowym, w

których opisuje się sprzęt i pomocnicze oprogramowanie

niezbędne do stworzenia produktu.

• Podział pracy, w którym opisuje się podział przedsięwzięcia na

zadania oraz identyfikuje etapy i produkty związane z tymi

zadaniami.

• Harmonogram przedsięwzięcia, w którym opisuje się zależności

pomiędzy zadaniami, czas potrzebny do ich wykonania oraz

przydział osób do poszczególnych zadań.

• Mechanizmy monitorowania i składania raportów, w których

opisuje się raporty menedżerskie, terminy ich dostarczenia i

sposoby monitorowania całego przedsięwzięcia.

Rodzaje planów

Plan

Opis

Plan jakości

Obejmuje procedury

zapewnienia jakości i standardy
obowiązujące w przedsięwzięciu.

Plan zatwierdzania

Obejmuje podejście, zasoby i
harmonogram zatwierdzania

systemu.

Plan zarządzania konfiguracjami Obejmuje procedury zarządzania

konfiguracjami i używane
struktury.

Plan pielęgnacji

Przewiduje się w nim

wymagania stawiane
pielęgnacji, jej koszty i
niezbędne nakłady.

Plan rozwoju umiejętności
personelu

Opisuje się w nim jak będą
wzrastały umiejętności i

doświadczenie personelu.

Etapy i produkty

• Kierownicy potrzebują informacji. Ponieważ

oprogramowanie nie jest uchwytne, informacje

mogą być dostarczane jedynie w postaci

dokumentów, w których opisano stan

budowanego oprogramowania. Bez tej informacji

nie można ocenić postępów, oszacować kosztów

ani skorygować harmonogramu.

• Planując przedsięwzięcie, należy ustalić etapy,

czyli ukończenie określonego zadania związanego

z jakimś formalnym wynikiem.

• Produkt jest wynikiem przedsięwzięcia,

dostarczanym klientowi. Jest zwykle

przekazywany na zakończenie pewnej, dużej fazy

przedsięwzięcia.

• Produkty są zwykle związane z etapami, ale nie

odwrotnie.

Tworzenie harmonogramu

•Menedżerowie szacują czas i zasoby niezbędne do
ukończenia czynności oraz organizują je w zwarte
sekwencje.

•Tworzenie harmonogramu przedsięwzięcia obejmuje
dzielenie całkowitego nakładu pracy na oddzielne
czynności i kalkulowanie czasu wymaganego na ich
ukończenie.

•Tworzenie harmonogramu przedsięwzięcia jest
szczególnie trudnym zadaniem dla zarządzającego
procesem tworzenia oprogramowania. Staje się
jeszcze bardziej skomplikowane wskutek tego, że w
rozmaitych przedsięwzięciach używa się często
różnych metod projektowania i implementacji.

Wykresy czynności
i wykresy paskowe

Opracuj grafy
przedsięwzięcia

Przydziel osoby
do czynności

Opracuj zasoby
dla czynności

Zidentyfikuj

czynności

Zidentyfikuj
zależności
między
czynnościami

Wymagania stawiane
oprogramowaniu

Problemy przy tworzeniu

harmonogramu

• Nie można zakładać, że każdy etap przedsięwzięcia

będzie wolny od problemów. Zatrudnione osoby

mogą zachorować lub pójść na urlop, sprzęt może

się popsuć, a dostawa podstawowego

oprogramowania wspomagającego lub sprzętu może

się opóźnić.

• Oprócz kalendarza zarządzający muszą także

oszacować zasoby niezbędne do ukończenia każdego

zadania. Najważniejszym zasobem jest praca ludzi.

• Dobrą, praktyczną zasadą jest szacowanie tak, jakby

wszystko miało się udać, a następnie zwiększenie

szacunków, aby uwzględnić nie przewidziane kłopoty.

• Na końcu można wszystko pomnożyć przez

dodatkowy czynnik rezerwy.

Wykresy paskowe i sieci

działań

• Wykresy paskowe i sieci działań to notacje

graficzne stosowane do przedstawiania

harmonogramów przedsięwzięcia.

• Na wykresie paskowym obrazuje się, kto

odpowiada za każdą czynność oraz kiedy

ta czynność ma się rozpocząć i skończyć.

• Za pomocą sieci działań zapisuje się

zależności między różnymi czynnościami

składającymi się na przedsięwzięcie.

• Wykresy paskowe oraz sieci działań mogą

być przygotowywane automatycznie przez

narzędzia wspomagające zarządzanie na

podstawie zawartości bazy danych

przedsięwzięcia.

Zbiór zadań, czas ich trwania

oraz zależności

T – zadania; M – etapy

Sieć działań

T2

M3

T6

T10

M7

T5

T7

M2

T4

M5

T8

4/7/99

8

14/7/99

15

4/8/99

15

25/8/99

7

5/9/99

10

19/9/99

15

11/8/99

25

10

20

5

25/7/99

15

dni

25/7/99

18/7/99

10

T1

M1

T3

T9

M6

T11

M8

T12

M4

początek

dni

dni

dni

dni

dni

dni

dni

dni

dni

dni

dni

koniec

Etap Zadanie

Diagram paskowy czynności

4/7

11/7 18/7 25/7

1/8

8/8

15/8

22/8 29/8

5/9

12/9

19/9

T4

T1

T2

M1

T7

T3

M5

T8

M3
M2

T6
T5

M4

T9

M7

T10

M6

T11

M8

T12

Start

Finish

Przydział personelu

4/7

11/7 18/7 25/

1/8

8/8

15/8 22/8 29/8 5/9

12/9 19/9

T4

T8

T11

T12

T1

T3

T9

T2

T6

T10

T7

T5

Fred

Jane

Anne

Mary

Jim

Personel - motywacja

• Potrzeby osobiste

– potrzeby społeczne: kontakty ze współpracownikami,

współtworzenie atmosfery
– szacunek: okazanie ludziom, że są cenieni przez swoją

firmę (wynagradzanie, publiczne uznanie zasług)
– samorealizacja: odpowiedzialność za własną pracę,

przydzielanie wymagających zadań, program szkoleń

• Zgrany zespół

– poczucie przynależności, identyfikacja z grupą
– odczucie własnej roli w grupie

• Właściwa organizacja pracy

– przydzielanie zadań w zależności od umiejętności i

doświadczeń
– warunki i środowisko pracy

Dobór personelu

• Doświadczenie w zakresie dziedziny

aplikacji

• Doświadczenie w ramach platformy

• Doświadczenie w zakresie języka

programowania

• Wykształcenie

• Zdolność komunikacji w grupie

• Elastyczność

• (!) Postawa

• (!) Osobowość

Dobór personelu – ograniczenia

• Przy wyborze pracowników do przedsięwzięcia,

zarządzający procesem tworzenia oprogramowania

musi działać zgodnie z poniższymi ograniczeniami:

- Zwykle tak bywa, że założony budżet przedsięwzięcia nie

wystarcza na odpowiednio dobre opłacanie personelu. W

związku z tym do realizacji przedsięwzięcia trzeba

przyjmować mniej doświadczonych, a co za tym idzie gorzej

wynagradzanych pracowników.
- Najczęściej trzeba poszukiwać personelu z odpowiednim

doświadczeniem w samej firmy bądź w jej otoczeniu. Należy

jednak wziąć pod uwagę, że najlepsi ludzie w firmie mogą już

brać udział w innych przedsięwzięciach.
- Firma może oczekiwać, że pracownicy będą doskonalić

swoje umiejętności. Do przedsięwzięcia przydziela się

wówczas mniej doświadczone osoby, aby w jego trakcie

uczyły się i zdobywały doświadczenie i nowe umiejętności.

Praca zespołowa

• Spójny, zgrany zespół – pożądany cel!

– lojalność
– identyfikacja z zespołem
– dążenie do tych samych celów
– ścisła współpraca
– znajomość pracy wykonywanej przez

innych
członków zespołu

– „programowanie niesamolubne”
• Cienie:
– nieograniczona lojalność względem „wodza”
– „syndrom myślenia grupowego”

Komunikacja w zespole

Czynniki wpływające na zdolność komunikacyjną:

• rozmiar zespołu: trudności komunikacyjne rosną z

kwadratem rozmiaru zespołu; zalecenie: nie

przekraczać 8 osób

• modele organizacji zespołu

• status i predyspozycje członków zespołu

• otoczenie

- rola wspólnego pomieszczenia i udogodnień

socjalnych - „automaty z kawą”;
- sąsiednie pokoje w instytucie.

Przykłady modeli organizacji

• Zespół nieformalny

• Zespół głównego programisty:

– główny programista
– drugi programista
– bibliotekarz
– specjaliści:
administrator

narzędziowiec

specjalista ds. systemu operacyjnego
kierownik testów

Zarządzanie zagrożeniami

• Ważnymi zadaniami zarządzającego

przedsięwzięciem jest przewidywanie zagrożeń,

które mogą mieć wpływ na harmonogram

przedsięwzięcia lub jakość budowanego

oprogramowania, oraz podejmowanie działań w celu

uniknięcia tych zagrożeń.

• Kategorie zagrożeń można podzielić w następujący

sposób:

– zagrożenia przedsięwzięcia mają wpływ na zasoby

i harmonogram przedsięwzięcia,

– zagrożenia produktu mają wpływ na jakość i

efektywność budowanego oprogramowania,

– zagrożenia przedsiębiorstwa maja wpływ na

przedsiębiorstwo budujące bądź zaopatrujące się

w oprogramowanie.

Wyszczególnienie zagrożeń

Proces zarządzania

zagrożeniami

•

Identyfikacja zagrożeń

–

Identyfikuje się możliwe zagrożenia przedsięwzięcia, produktu i

przedsiębiorstwa.

•

Analiza zagrożeń

–

Ocenia się prawdopodobieństwo i konsekwencje zagrożeń.

•

Planowanie przeciwdziałania zagrożeniom

–

Opracowuje się plany radzenia sobie z tymi zagrożeniami przez ich

unikanie lub zmniejszanie ich następstw.

•

Monitorowanie zagrożeń

–

Ustawicznie ocenia się zagrożenia i koryguje plany ich łagodzenia w

miarę napływu coraz lepszych informacji o tych zagrożeniach.

Ocena
zagrożeń

Identyfikacja
zagrożeń

Analiza
zagrożeń

Lista
potencjalnych
zagrożeń

Lista zagrożeń
z przypisanymi
priorytetami

Przeciwdziałania
zagrożeniom

Monitorowanie
zagrożeń

Ocena zagrożeń

Plany
unikania
zagrożeń
i awaryjne

Identyfikacja zagrożeń

• Zagrożenia technologiczne
• Zagrożenia ze strony ludzi
• Zagrożenia organizacyjne
• Zagrożenia narzędziowe
• Zagrożenia wymagań
• Zagrożenia szacowania

Czynniki ryzyka

Typy zagrożeń

Analiza zagrożeń

Zarządzanie zagrożeniami

Przeciwdziałanie zagrożeniom

• W procesie planowania przeciwdziałania

zagrożeniom bierze się pod uwagę każde poważne

zagrożenie i opracowuje strategię panowania nad

nim.

• Strategie unikania

–

Ich zastosowanie prowadzi do zmniejszenia

prawdopodobieństwa wystąpienia zagrożenia.

• Strategie minimalizacji

–

Ich zastosowanie prowadzi do zmniejszenia konsekwencji

zagrożenia.

• Plany awaryjne

–

Ich zastosowanie polega na przygotowaniu się i

opracowaniu strategii przeciwdziałania na wypadek

najgorszego.

Inżynieria

oprogramowania

Wykład 8 –

szacowanie kosztu

oprogramowania

Prezentacja częściowo oparta na prezentacji przygotowanej przez Prof. J.E. Sienkiewicza

(opartej z kolei na podręczniku Iana Sommerville’a Inżynieria oprogramowania, WNT 2003)

Szukamy odpowiedzi na

pytania:

• Ile pracy trzeba na ukończenie

czynności?

• Ile czasu kalendarzowego trzeba na

ukończenie czynności?

• Jaki jest całkowity koszt czynności?

Składniki kosztu

wytworzenia oprogramowania

– koszt sprzętu wraz z pielęgnacją,

– koszt oprogramowania wraz z pielęgnacją,

– koszty podróży służbowych,

– koszt szkoleń,

– koszt pracy

Składniki całkowitego kosztu

pracy

• Koszt udostępnienia, ogrzania i oświetlenia

przestrzeni biurowej.

• Koszt personelu pomocniczego związanego

np.

z

prowadzeniem

księgowości

i

sekretariatu, sprzątaniem i pomocą

techniczną.

• Koszt sieci komputerowej i telekomunikacji.

• Koszt udogodnień centralnych, takich jak

biblioteka, pomieszczenia rekreacyjne.

• Koszt ubezpieczenia społecznego, m.in. na

świadczenia dla pracowników, takie jak

emerytury i ubezpieczenie zdrowotne.

uproszczony schemat kalkulacji ceny:

cena = koszt + zysk

koszt marża (zysk) kalkulacja

ceny

zysk cena kalkulacja

kosztów

Kalkulacja ceny

oprogramowania

Od czego w rzeczywistości

zależy cena oprogramowania?

Czynnik

Przykładowy opis

Okazja rynkowa

Przedsiębiorstwo produkujące może podać niską cenę, ponieważ chce

zaistnieć w nowym segmencie rynku oprogramowania. Zgoda na mały
zysk z jednego przedsięwzięcia może dać okazję do późniejszych zysków.
Zdobyte doświadczenie może umożliwić tworzenie nowych produktów.

Niepewność

Jeśli przedsiębiorstwo nie jest pewne swoich szacunków kosztów, to może

oszacowania

zwiększyć cenę o pewien czynnik rezerwowy powyżej swego zwykłego

kosztów

zysku.

Warunki umowy

Klient może wyrazić zleceniobiorcy zgodę na zatrzymanie prawa własności

kodu źródłowego i wielokrotne wykorzystanie go w następnych
przedsięwzięciach. Ustalona cena może być wówczas niższa niż w wypadku
przekazania kodu źródłowego klientowi.

Płynność

Jeśli wymagania przypuszczalnie będą się zmieniać, to firma może obniżyć

wymagań

cenę, aby zdobyć kontrakt. Po przyznaniu kontraktu można zażądać

wysokich cen za zmiany wymagań.

Kondycja

Firmy produkujące w złej kondycji finansowej mogą obniżać swoje ceny w

finansowa

celu zdobycia kontraktu. Od wypadnięcia z rynku lepszy jest mniejszy niż
zwykle zysk lub nawet strata.

Produktywność

• W

procesie

tworzenia

oprogramowania

menedżerowie muszą oceniać produktywność

inżynierów.

Takie

oszacowania

mogą

być

niezbędne

przy

szacowaniu

kosztów

przedsięwzięcia i przy ustalaniu, czy ulepszenia

procesowe i technologiczne były skuteczne.

• Problemy z określeniem produktywności:

- W wypadku budowy oprogramowania istnieje

wiele różnych rozwiązań o różnych atrybutach.
- Gdy pojawiają się dwa rozwiązania o różnych

atrybutach, porównywanie szybkości ich tworzenia

nic tak naprawdę nie daje. Jedno rozwiązanie może

działać bardziej efektywnie, podczas gdy inne jest

bardziej czytelne i łatwiejsze do pielęgnacji.

Czynniki wpływające na

produktywność

Czynnik

Opis

Wiedza

Wiedza z dziedziny zastosowania jest konieczna do skutecznego tworzenia

z dziedziny

oprogramowania. Inżynierowie, którzy już rozumieją dziedzinę, będą

zastosowania

najbardziej produktywni.

Jakość procesu Zastosowany proces tworzenia może mieć znaczący wpływ na

produktywność.

Wielkość

Im przedsięwzięcie jest większe, tym więcej trzeba komunikacji zespołu.

przedsięwzięcia

Mniej czasu pozostaje na tworzenie, więc indywidualna produktywność

jest mniejsza.

Wspomaganie Dobre wspomaganie technologiczne, takie jak narzędzia CASE, pomocnicze
technologiczne systemy zarządzania konfiguracjami itd. mogą poprawić produktywność.

Środowisko

Ciche środowisko pracy z prywatnymi miejscami pracy przyczynia się do

pracy

wzrostu produktywności.

Rodzaje miar

• Miary wielkościowe. Są związane z

wielkością pewnego wyniku czynności.

Najczęściej stosowaną wielkościową

miarą produktywności jest liczba wierszy

dostarczonego kodu źródłowego.

• Miary funkcyjne. Są związane z ogólną

funkcjonalnością dostarczonego

oprogramowania. Produktywność

wyraża się w kategoriach ilości

użytecznej funkcjonalności dostarczonej

w pewnym czasie.

Szacowanie kosztu pracy

programisty za pomocą liczby

wierszy kodu

• Liczba wierszy kodu na miesiąc pracy

programisty to szeroko stosowana miara
produktywności.

• Wyznacza się ją przez obliczenie całkowitej

liczby dostarczonego kodu źródłowego. Tę
liczbę dzieli się następnie przez miesiące
pracy

programisty,

konieczne

do

ukończenia przedsięwzięcia.

• Ten czas obejmuje zatem czas potrzebny

na analizę, projektowanie, kodowanie i
dokumentowanie.

Czas budowania systemu

Analiza Projek- Kodowanie

Testowanie

Dokumentowanie

towanie

Asembler

3 tyg.

5 tyg.

8 tyg.

10 tyg.

2 tyg.

Język wysokiego 3 tyg.

5 tyg.

8 tyg.

6 tyg.

2 tyg.

poziomu

Wielkość

Praca

Produktywność

Asembler

500 wierszy

28 tyg.

714 wierszy/miesiąc

Język wysokiego 1500 wierszy

20 tyg.

300 wierszy/miesiąc

poziomu

Szacowanie kosztu pracy

programisty za pomocą punktów

funkcyjnych

Inną stosowaną miarą jest liczba punktów funkcyjnych.

Całkowitą liczbę punktów funkcyjnych wyznacza się przez
zmierzenie lub oszacowanie następujących elementów
programu:

- zewnętrzne dane wejściowe i wyjściowe,
- interakcje z użytkownikiem,
- interfejsy zewnętrzne,
- pliki używane przez system.

Wagi: od 3 (proste dane wejściowe) do 15 (złożone pliki)

UFC = ∑ liczba_elementów_danego_typu x waga

Punkty funkcyjne są niezależnie od języka, można więc za
ich pomocą porównywać produktywność w różnych
językach programowania. Produktywność wyraża się jako
liczby punktów funkcyjnych utworzonych w czasie
miesiąca.

Szacowanie kosztu pracy

programisty za pomocą punktów

obiektowych

W przypadku stosowania narzędzi obiektowych,
stosujemy miarę w postaci liczby punktów
obiektowych - miarę ważoną następujących
składników:

- liczba różnych wyświetlanych ekranów
(prosty ekran to 1 punkt obiektowy, bardzo
złożony ekran - 3)
- liczba tworzonych raportów (prosty raport to
2 punkty obiektowe, bardzo złożony - 8
punktów)
- liczba modułów napisanych w językach
proceduralnych, które należy opracować w
celu uzupełnienia kodu (każdy moduł liczy się
jako 10 punktów obiektowych.

Miary – uwagi końcowe

• Kłopot miarami wyrażonymi za pomocą ilości w

czasie polega na tym, że nie bierze się w nich pod
uwagę

niefunkcjonalnych

właściwości

oprogramowania,

takich

jak

niezawodność,

zdatność do pielęgnacji itd.

• Miary nie biorą też pod uwagę możliwości

wielokrotnego

użycia

wytworzonego

oprogramowania

• Wielkość kodu = AVC x UFC

(AVC – średnia liczba wierszy kodu niezbędnych
do zaimplementowania punktu funkcyjnego; 200-
300 dla asemblera, 2-40 dla języków wysokiego
poziomu)

Szacowanie pracy potrzebnej do

zbudowania oprogramowania

• Nie istnieje prosty sposób dokładnego szacowania

pracy niezbędnej do zbudowania systemu

oprogramowania.

• Wstępne szacunki muszą być wykonywane na

podstawie definicji wymagań.

• Oprogramowanie może być przeznaczone do

działania na słabo znanym komputerze lub jego

tworzenie może odbywać się z użyciem nowej

technologii.

• Ludzie biorący udział w przedsięwzięciu i ich

umiejętności nie będą prawdopodobnie znane.

Wszystkie te czynniki oznaczają, że trudno jest

podać dokładnie oszacowanie kosztu budowania

systemu we wczesnej fazie przedsięwzięcia.

Metody szacowania kosztów

Metoda

Opis

Algorytmiczne

Na podstawie historycznej informacji o kosztach opracowuje się model, który wiąże

modelowanie

pewną miarę oprogramowania (zwykle jego wielkość) z kosztem przedsięwzięcia.

kosztów

Szacuje się wartość tej miary i na podstawie modelu ustala się wymaganą pracę.

Ocena

Zasięga się rady kilku ekspertów od zaproponowanych metod tworzenia

ekspertów

oprogramowania i dziedziny zastosowania. Każdy z nich szacuje koszt

przedsięwzięcia. Te szacunki porównuje się i omawia. Proces szacowania powtarza
się do chwili ustalenia uzgodnionego oszacowania.

Szacowanie przez

Tę metodę można zastosować, jeśli ukończono już podobne przedsięwzięcia w tej

analogię

samej dziedzinie zastosowań. Koszt nowego przedsięwzięcia ocenia się przez
analogię do kosztów tych zakończonych przedsięwzięć.

Prawo

Prawo Parkinsona mówi, ze praca rozciąga się tak, że wypełnia wyznaczony czas.

Parkinsona

Koszt jest determinowany przez dostępne zespoły, a nie przez obiektywną ocenę.

Jeśli oprogramowanie musi być dostarczone w ciągu 12 miesięcy i mamy do
dyspozycji pięć osób, to niezbędną pracę ocenia się na 60 osobomiesięcy.

Ustalanie ceny

Koszt oprogramowania jest szacowany na tyle, ile klient może wydać na to

pod zwycięstwo przedsięwzięcie. Przybliżona praca zależy od budżetu klienta, a nie od

funkcjonalności oprogramowania.

Problemy z doświadczalnym

wyznaczaniem kosztów

• Zmiany w technologii tworzenia oprogramowania,

które

mogą

wpłynąć

na

doświadczalne

szacowanie kosztów:

– tworzenie

obiektowe

zamiast

tworzenia

funkcyjnego

– system klient-serwer zamiast systemu na

komputerze głównym

– wielokrotne

wykorzystania

kodu:

użycie

komponentów z półki zamiast tworzenia tych
komponentów

– użycie

narzędzi

CASE

i

generatorów

programów zamiast tworzenia oprogramowania
bez takiego wspomagania.

Modelowanie algorytmiczne

kosztów

• Model algorytmiczny kosztów można zbudować

analizując

koszty

i

atrybuty

ukończonych

przedsięwzięć.

• Do przewidywania kosztów używa się formuły

matematycznej,

w

której

uwzględnia

się

oszacowanie wielkości przedsięwzięcia, liczbę
programistów oraz inne czynniki procesowe i
produktowe.

• Większość modeli algorytmicznych szacowania

zawiera komponent wykładniczy. Odzwierciedla
on fakt, że zwykle koszt nie rośnie liniowo wraz ze
wzrostem wielkości przedsięwzięcia.

Ogólna postać

oszacowania algorytmicznego

• Praca = A x Wielkość

B

x M

• A jest stałym czynnikiem, który zależnie od

lokalnych zwyczajów firmy i rodzaju
tworzonego oprogramowania.

• Wartość wykładnika B zwykle waha się

między

1

i

1,5.

Odzwierciedla

nieproporcjonalność pracy niezbędnej w
wypadku wielkich przedsięwzięć.

• M to mnożnik określany na podstawie

połączenia różnych atrybutów procesu,
produktu i tworzenia.

Dokładność szacunków na

podstawie modelu

algorytmicznego

•Zależy od dostępnej informacji o systemie.

•W miarę postępów procesu tworzenia oprogramowania pojawia się
coraz więcej informacji – oszacowania stają się coraz bardziej
precyzyjne.

x

2x

4x

0.5x

0.25x

Wykonalność

Wymagania

Projekt

Kod

Dostarczenie

Model COCOMO

• Wywnioskowano go na podstawie danych

zebranych z wielkiej liczby przedsięwzięć

programistycznych.

• Zanalizowano je w celu wykrycia formuł

najlepiej pasujących do obserwacji.

• Jest dobrze udokumentowany, publicznie

bezpłatnie dostępny i wspomagany przez

narzędzia bezpłatne i komercyjne.

• Ma długi rodowód od pierwszego wcielenia

w 1981, poprzez poprawki w celu

dostosowania

do

tworzenia

oprogramowania w języku Ada (1989), aż do

najnowszej wersji opublikowanej w 1995 r.

Podstawowy model COCOMO

81

Złożoność

Formuła

Opis

przedsięwzięcia

Mała

PM = 2,4 (KDSI)

1,05

* M

Zrozumiałe programy

użytkowe

tworzone przez małe zespoły.

Średnia

PM = 3,0 (KDSI)

1,12

* M

Bardziej złożone

przedsięwzięcia, w

których członkowie zespołu

mogą mieć

ograniczone doświadczenia z
podobnymi systemami.

Duża

PM = 3,6 (KDSI)

1,20

* M

Złożone przedsięwzięcia,

w których

oprogramowanie jest częścią

silnie

powiązanego złożonego sprzętu,
oprogramowania, regulacji i

procedur

działania.

(KDSI – 1000 linii kodu źródłowego)

Model COCOMO 2

• Stosowany na trzech etapach (poziomach)

tworzenia systemu:
- poziom wczesnego projektowania
- poziom postarchitektoniczny
- poziom wczesnego prototypowania

• W odróżnieniu od modelu 81, uwzględnia

różne nowe podejścia do tworzenia
oprogramowania

• Czynnik skali jest sparametryzowany,

zarówno jak i mnożnik M.

• Czynnik A przyjmowany jest na poziomie

2.5

Wyznaczanie czynnika skali

Czynnik skali jest wyznaczany na podstawie następujących parametrów

(ocenianych w skali 0-5):

• Nadrzędność: wcześniejsze doświadczenia firmy z przedsięwzięciami

danego rodzaju

• Elastyczność tworzenia: użycie nakazanego procesu wytwarzania

oprogramowania lub ustalenie przez klienta jedynie ogólnych celów

• Ocena przeprowadzonej analizy ryzyka
• Spójność zespołu: ocena trudności komunikacyjnych
• Ocena dojrzałości procesu wytwarzania oprogramowania w firmie

B = 1.01 + suma_ocen/100

Przykład: małe doświadczenie (4), brak udziału klienta (1), brak oceny

ryzyka (5), nowy zespół (3), przeciętna dojrzałość procesu (3);
B=1.17

Wyznaczanie mnożnika M

Na poziomie postarchitektonicznym mnożnik M jest wyznaczany jako iloczyn 17

parametrów, szacowanych zwykle w zakresie [0.5 – 1.5]. 1 – wartość
neutralna.

Produkt:

RUSE – wymagany stopień użycia wielokrotnego; DATA – rozmiar użytej bazy
danych; CPLX – złożoność modułów systemowych; DOCU – zakresy
wymaganej dokumentacji; RELY – wymagana niezawodność systemu

Sprzęt:

STOR – ograniczenia pamięciowe; TIME – ograniczenia wydajnościowe; PVOL –
płynność platformy tworzenia

Personel:

PEXP – doświadczenie programistów; PCON – ciągłość zatrudnienia personelu;
ACAP – możliwości analityków; AEXP – doświadczenie analityków; PCAP –
możliwości programistów; LTEX – doświadczenie w zakresie języków i narzędzi

Przedsięwzięcie:

TOOL – użycie narzędzi wspomagających; SCED – kompresja harmonogramu;
SITE – stopień rozproszenia pracy

Przykład

Koszt pracy (osobomiesiące): PM = A x Wielkość

B

x M

Wielkość systemu: 128 000 DSI
B = 1.17; A = 2.5; Wielkość = 128; M = 1
Wynik: 730 osobomiesięcy

Modyfikatory M: wymagana duża niezawodność (1.39), duża złożoność

(1.3), ograniczenia pamięciowe (1.21), małe użycie narzędzi (1.12),
przyspieszony harmonogram (1.29)

Wynik – 2306 osobomiesięcy

Modyfikatory M: wymagana mała niezawodność (0.75), mała

złożoność (0.75), brak ograniczenia pamięciowych (1), duże użycie
narzędzi (0.72), normalny harmonogram (1)

Wynik – 295 osobomiesięcy

Modele algorytmiczne kosztów w

planowaniu przedsięwzięć

• Menedżerowie przedsięwzięć mogą użyć

modelu

algorytmicznego

kosztów

do

porównania różnych sposobów inwestowania
pieniędzy w celu zmniejszenia kosztów
przedsięwzięcia.

• Jest to szczególnie istotne tam, gdzie

konieczny

jest

kompromisowy

wybór

droższego sprzętu albo oprogramowania,
oraz tam, gdzie trzeba przyjąć nowy personel
z

umiejętnościami

specyficznymi

dla

przedsięwzięcia.

Opcje menedżerów

A. Użycie istniejącego sprzętu,

systemu tworzenia i zespołu

wytwórczego

A. Użycie istniejącego sprzętu,

systemu tworzenia i zespołu

wytwórczego

D. Bardziej

doświadczony

personel

D. Bardziej

doświadczony

personel

C. Ulepszenie tylko

pamięci

Rośnie koszt

sprzętu

C. Ulepszenie tylko

pamięci

Rośnie koszt

sprzętu

B. Ulepszenie procesora i pamięci

Rośnie koszt sprzętu

Doświadczenie maleje

B. Ulepszenie procesora i pamięci

Rośnie koszt sprzętu

Doświadczenie maleje

F. Personel

z doświadczeniami

ze sprzętem

F. Personel

z doświadczeniami

ze sprzętem

E. Nowy system tworzenia

Rośnie koszt sprzętu

Doświadczenie maleje

E. Nowy system tworzenia

Rośnie koszt sprzętu

Doświadczenie maleje

Koszty opcji menedżerów

Opcja RELY STOR TIME TOOL LTEX PM Koszt

Koszt

Koszt

(osobomies.) oprogramowania sprzętu

całkowity
A 1,39 1,06 1,11 0,86 1 63 949 393
100 000 1 049 393

B 1,39 1 1 1,12 1,22 88 1 313 550
120 000 1 402 025

C 1,39 1 1,11 0,86 1 60 895 653
105 000 1 000 653

D 1,39 1.06 1,11 0,86 0,84 51 769 008
100 000 897 490

E 1,39 1 1 0,72 1,22 56 844 425
220 000 1 044 159

F 1,39 1 1 1,12 0,84 57 851 180
120 000 1 002 706

Szacowanie czasu

w modelu COCOMO

Przeciętny harmonogram przedsięwzięcia:

TDEV = 3 x (PM)

(0,33 + 0,2 x

(B – 1,01))

•

PM to oszacowanie pracy w osobomiesiącach. B to wykładnik

obliczony zgodnie z wcześniejszymi rozważaniami.

Przykład:

pracę

niezbędną

do

ukończenia

przedsięwzięcia

oszacowano na 60 osobomiesięcy.

•

Załóżmy, że wartością wykładnika B jest 1,17.

•

Na podstawie równania harmonogramu obliczamy czas

niezbędny do ukończenia przedsięwzięcia:

TDEV = 3(60)

0,36

= 13 miesięcy

Optymalna liczba osób zatrudniona w projekcie:

P = PM / TDEV = (przykład) 60/13 ≈ 5 osób

Inżynieria

oprogramowania

Wykład 9 –

projektowanie architektoniczne.

Prezentacja częściowo oparta na prezentacji przygotowanej przez Prof. J.E. Sienkiewicza

(opartej z kolei na podręczniku Iana Sommerville’a Inżynieria oprogramowania, WNT 2003)

Projektowanie architektoniczne

• Wielkie systemy są zwykle podzielone na

podsystemy, które oferują pewien zbiór

powiązanych ze sobą interfejsów.

• Produktem tej fazy procesu jest opis

architektury oprogramowania.

• Model architektoniczny może być punktem

początkowym

do

specyfikowania

rozmaitych części systemu.

• Obejmuje identyfikację najważniejszych

komponentów systemu i komunikacji

między nimi.

Etapy

projektowania

architektonicznego

• Strukturalizacja systemu

– System jest dzielony na kilka podstawowych

podsystemów, przy czym podsystem jest

niezależną jednostką oprogramowania. Identyfikuje

się też komunikację między podsystemami.

• Modelowanie sterowania

– Określa się ogólny model związków sterowania

między częściami systemu.

• Podział na moduły

– Każdy zidentyfikowany podsystem jest dzielony na

moduły.

Podsystemy i moduły

• Podsystem jest systemem na swoich

własnych prawach; jego usługi nie zależą

od

usług

oferowanych

przez

inne

podsystemy. Podsystemy składają się z

modułów i mają interfejsy używane do

komunikacji z innymi podsystemami.

• Moduł jest zwykle komponentem systemu,

który oferuje co najmniej jedną usługę

innym modułom. Korzysta z usług innych

modułów. Zwykle nie jest traktowany jako

niezależny system. Moduły są zwykle

zbudowane z kilku innych, prostszych

komponentów systemu.

• Statyczny model strukturalny obejmuje

komponenty lub podsystemy, które można

zbudować jako niezależne jednostki.

• Model dynamiczny procesu, w którym

przedstawia się podział systemu na procesy

czasu wykonania.

• Model interfejsów, w którym definiuje się

usługi oferowane przez każdy podsystem za

pośrednictwem jego interfejsu publicznego.

• Model związków, który obejmuje związki,

takie

jak

przepływ

danych

między

podsystemami.

Opracowywanie modeli

architektonicznych

Pożądane własności

architektury systemu

• Efektywność

– Krytyczne operacje w niewielkiej liczbie podsystemów.

• Zabezpieczenie

– Należy zastosować w architekturze strukturę

warstwową.

• Bezpieczeństwo

– Operacje dotyczące bezpieczeństwa powinny znaleźć się

w jednym podsystemie lub w niewielkiej liczbie
podsystemów.

• Zdatność do pielęgnacji

– Architektura systemu powinna składać się z

samodzielnych komponentów, można uwzględnić w
architekturze komponenty nadmiarowe

Strukturalizacja systemu

• Faza

projektowania

architektonicznego

polegająca na podziale systemu na zbiór

oddziałujących ze sobą podsystemów.

• Na najbardziej abstrakcyjnym poziomie

projekt architektoniczny można przedstawić w

postaci diagramu blokowego, na którym

każdy prostokąt odpowiada podsystemowi.

• Prostokąty wewnątrz prostokąta oznaczają, że

taki

podsystem

dalej

podzielono

na

podsystemy.

• Strzałki wskazują, że dane lub sterowanie są

przekazywane między podsystemami zgodnie

z kierunkiem grotu.

Diagram blokowy systemu

sterującego robotem

System

wizyjny

System

identyfikacji

przedmiotów

Sterownik

alarmu

Sterownik

chwytacza

System

pakujący

System

wyboru

opakowania

Sterownik

taśmociągu

Model repozytorium

• Aby

efektywnie

współpracować,

podsystemy

wchodzące w skład systemu muszą wymieniać

między sobą informacje.

A. Wszystkie współdzielone dane znajdują się w centralnej

bazie danych, z której mogą korzystać wszystkie

podsystemy. Model systemu oparty na współdzielonej bazie

danych jest czasem nazywany modelem repozytorium.

B. Każdy podsystem prowadzi własną bazę danych. Dane są

przekazywane innym podsystemom przez wysyłanie

komunikatów.

• Większość systemów używających dużej ilości

danych jest zbudowanych wokół centralnej bazy

danych lub repozytorium. Ten model jest więc

przystosowany do zastosowań, w których dane są

generowane przez jeden podsystem, a używane

przez inny.

Architektura zintegrowanego

zestawu narzędzi CASE

Translator

projektów

Edytor

programów

Generator

raportów

Analizator

projektów

Generator

kodu

Edytor

projektów

Repozytorium

przedsięwzięcia

Zalety i wady współdzielonego

repozytorium

• Efektywny sposób współdziałania dużych ilości danych. Nie

ma potrzeby jawnej transmisji danych z jednego podsystemu

do drugiego.

• Twórcy podsystemów musza jednak uzgodnić model danych

repozytorium.

• Podsystemy produkujące dane nie muszą zajmować się

sposobem użycia tych danych przez inne podsystemy.

• Ewolucja może być jednak trudna.

• Czynności takie jak tworzenie kopii zapasowej, sterowanie

zabezpieczeniami i dostępem oraz odtwarzanie po awarii są

scentralizowane.

• Różne podsystemy mogą mieć jednak odmienne wymagania

stawiane zabezpieczeniom oraz strategii odtwarzania i

kopiom zapasowym.

• Model współdziałania jest widoczny przez schemat

repozytorium. Integracja nowych narzędzi jest bardzo łatwa.

• Może być jednak trudno rozproszyć repozytorium na kilku

maszynach.

Model klient-serwer

• Architektoniczny model klient-serwer jest

modelem rozproszonego systemu, w

którym dane i przetwarzanie są rozdzielone

między zbiór procesorów.

1.

Zbiór samodzielnych serwerów oferujących

usługi innym podsystemom. Przykładami

są serwery wydruku realizujące usługi

drukowania, serwery plików realizujące

usługi zarządzania plikami.

2.

Zbiór klientów, którzy korzystają z usług

oferowanych przez serwery. Zwykle same

w sobie są podsystemami.

3.

Sieć, która daje klientom dostęp do tych

usług.

Architektura systemu biblioteki

filmów i zdjęć

Klient 4

Klient 3

Klient 2

Klient 1

Serwer

katalogu

Katalog

Serwer

filmów

Pliki z

filmami

Serwer

Zdjęć

Zdjęcia w

postaci

cyfrowej

Sieć szerokopasmowa

Zalety i wady modelu klient-

serwer

• Największa zaleta modelu klient-serwer polega na

tym, że jest to architektura rozproszona. Umożliwia

to efektowne użycie systemów sieciowych z dużą

liczba rozproszonych procesorów. Łatwo jest dostać

nowy serwer i zintegrować go z resztą systemu albo

przezroczyście aktualizować serwery bez wpływania

na inne części systemu.

• Do odniesienia pełnych korzyści z integracji nowego

serwera może być jednak konieczne wprowadzenie

pewnych

zmian

w

istniejących

klientach

i

serwerach. Nie ma dzielonego modelu danych i

podsystemy porządkują zwykle swoje dane na różne

sposoby.

Oznacza

to

potrzebę

określenia

specyficznego modelu danych dla każdego serwera,

który umożliwi zoptymalizowanie jego efektywności.

Modele sterowania

• Modele do strukturalizacji systemu opisują sposób

podziału

systemu

na

podsystemy.

Aby

podsystemy pracowały jako jeden system, należy

nimi sterować tak, żeby ich usługi były

dostarczone we właściwe miejsce i we właściwym

czasie.

• Sterowanie scentralizowane

– Jeden podsystem jest całościowo odpowiedzialny za

sterowanie; to on uruchamia i zatrzymuje inne

podsystemy.

• Sterowanie zdarzeniowe

– Informacja o sterowaniu nie jest wbudowana w

podsystem, ale każdy system może reagować na

zdarzenia zachodzące na zewnątrz. Te zdarzenia mogą

występować w innych podsystemach lub w otoczeniu

systemu.

Sterowanie scentralizowane

• Model wywołanie-powrót

– Jest to dobrze znany model podprogramów, w

którym sterowanie zaczyna się na wierzchołku
hierarchii podprogramów i przez wywołania
podprogramów przechodzi do niższych
poziomów drzewa..

• Model menedżera

– Ten model można zastosować w wypadku

systemów współbieżnych. Jeden z
komponentów systemu jest wybierany do roli
menedżera systemu i steruje rozpoczynaniem,
zatrzymywaniem i koordynacją innych
procesów systemu.

Sterowanie zdarzeniowe

• Modele sterowania zdarzeniowego są sterowane

zdarzeniami pochodzącymi z zewnątrz.

• Dwa modele sterowania zdarzeniowego:

– Modele rozgłaszania. W takich modelach

zdarzenie jest w zasadzie ogłoszeniem dla
wszystkich podsystemów. Każdy podsystem,
który może obsłużyć to zdarzenie, reaguje na
nie.

– Modele z przerwaniami. Są używane wyłącznie

w systemach czasu rzeczywistego, gdzie
zewnętrzne przerwania są wykrywane przez
obsługę

przerwań.

Następnie

są

one

przekazywane do innego komponentu, który je
przetworzy.

Rozkład na moduły

• Po zaprojektowaniu architektury strukturalnej

następnym krokiem procesu projektowania
architektonicznego jest podział podsystemów na
moduły. Nie ma precyzyjnego rozróżnienia między
podziałem systemu, a podziałem na moduły.

• Dwa modele służą do podziału podsystemu na

moduły:

– Model obiektowy. System jest dzielony na zbiór

porozumiewających się obiektów.

– Model przepływu danych. System jest dzielony

na moduły funkcjonalne, które pobierają dane
wejściowe i w jakiś sposób przetwarzają je na
dane wyjściowe.

Projekt systemu

• Podział na podsystemy i moduły

(w praktyce może to być zgrupowanie gotowych już klas w pakiety

UML odpowiadające funkcjonalnie modułom i podsystemom)

oraz propozycja modelu sterowania

• Projekt interfejsu użytkownika
• Projekt bazy danych
• Projekt użytych algorytmów
• Ogólny kosztorys oparty na modelu

COCOMO

Inżynieria

oprogramowania

Wykład 10 –

architektury systemów

rozproszonych.

Prezentacja częściowo oparta na prezentacji przygotowanej przez Prof. J.E. Sienkiewicza

(opartej z kolei na podręczniku Iana Sommerville’a Inżynieria oprogramowania, WNT 2003)

Systemy rozproszone

• W

systemie

rozproszonym

przetwarzanie

informacji jest wykonywane na kilku komputerach,

a nie przydzielone do jednej maszyny.

• W szczególnym przypadku przetwarzanie może

odbywać

się

na

jednym

komputerze

wieloprocesorowym, a nawet jednoprocesorowym.

• Niemal

wszystkie

współczesne

systemy

komputerowe są systemami rozproszonymi.

• Inżynieria systemów rozproszonych ma wiele

wspólnego z inżynierią każdego innego rodzaju

oprogramowania, istnieją jednak specyficzne

zagadnienia, które należy wziąć pod uwagę,

projektując takie systemy.

Rodzaje systemów

• Systemy osobiste, które nie są rozproszone i są

przeznaczone do pracy na komputerze osobistym

lub stacji roboczej. Przykłady: procesory tekstów,

arkusze kalkulacyjne, systemy graficzne itd.

• Systemy wbudowane, które działają na jednym

procesorze

lub

na

zintegrowanej

grupie

procesorów. Przykłady: systemy sterowania

sprzętem

domowym,

systemy

sterujące

przyrządami.

• Systemy

rozproszone,

w

których

oprogramowanie systemowe działa na luźno

zintegrowanej

grupie

współpracujących

procesorów

połączonych

siecią.

Przykłady:

systemy bankomatów, systemy rezerwacji,

systemy pracy grupowej itd.

Cechy systemu rozproszonego

• Współdzielenie zasobów

• Otwartość

• Współbieżność

• Skalowalność

• Odporność na awarie

• Przezroczystość

• Złożoność
• Trudność zabezpieczenia
• Trudność zarządzania
• Nieprzewidywalność

Wady systemów rozproszonych

Zagadnienia projektowania

systemów rozproszonych

Zagadnienia

Opis

projektowe

Identyfikacja

Zasoby systemu rozproszonego są rozmieszczone na różnych komputerach, należy więc

zasobów

opracować schemat nazewnictwa aby użytkownicy mogli znajdować i wykorzystywać
potrzebne im zasoby. Przykładem takiego schematu jest URL (Uniform Resource Locator-
jednolity lokalizator zasobów) służący do identyfikacji stron WWW. Jeśli nie zastosuje się
znaczącego i powszechnie rozumianego schematu, to wiele zasobów będzie niedostępnych
dla użytkowników systemu.

Komunikacja

Powszechna dostępność Sieci i efektywna implementacja jej protokołu komunikacyjnego
TCP/IP oznacza, że jest to najskuteczniejszy sposób komunikacji komputerów w wypadku
większości systemów rozproszonych. Tam, gdzie występują szczególne wymagania
efektywnościowe, niezawodnościowe itp., można skorzystać z innych mechanizmów
komunikacji.

Jakość usług

Jakość usług oferowanych przez system zależy od jego efektywności, dostępności i nie-

zawodności. Mają na nią wpływ także inne czynniki, takie jak podział procesów do proce-
sorów systemu, rozproszenie zasobów w ramach systemu, sprzęt sieciowy i systemowy
oraz zdolność systemu do adaptacji.

Architektury

W architekturze oprogramowania opisuje się, jak funkcjonalność programu użytkowego

oprogramowania

rozproszono na kilku logicznych komponentach oraz jak te komponenty rozproszono na
procesorach. Wybór odpowiedniej architektury programu użytkowego jest zasadniczym
warunkiem osiągnięcia pożądanej jakości usług.

Rodzaje architektur systemów

rozproszonych

• Architektury wieloprocesorowe

– W tym podejściu system jest postrzegany jako

zbiór procesów uruchomionych na oddzielnych

(ale niekoniecznie) procesorach.

• Architektury klient-serwer

– W tym podejściu system jest postrzegany jako

zbiór usług oferowanych klientom, którzy z nich

korzystają. W takich systemach odmiennie

traktuje się serwery i klientów.

• Architektury obiektów rozproszonych

– W tym podejściu nie istnieje rozróżnienie między

klientami i serwerami. System jest postrzegany

jako zbiór komunikujących się obiektów, których

położenie jest nieistotne. Nie ma różnicy między

dostawcą i użytkownikiem usług.

Śródprogramy

• Różne komponenty systemu rozproszonego mogą

być zaimplementowane za pomocą rozmaitych

języków programowania i działać na zupełnie

innych rodzajach procesorów.

• Modele danych, reprezentacja informacji i protokoły

komunikacyjne mogą być całkowicie odmienne.

• System

rozproszony

musi

zatem

zawierać

oprogramowanie, które będzie zarządzać tymi

różnorodnymi częściami oraz zapewni im możliwość

komunikacji i wymiany danych.

• Do takiego oprogramowania odnosi się podejście

śródprogramu (middleware), które znajduje się w

środku

różnych

rozproszonych

komponentów

systemu.

Architektury wieloprocesowe

• Najprostszym modelem systemu rozproszonego

jest system wieloprocesorowy, składający się z

kilku różnych procesów, które mogą (ale nie

muszą) działać na oddzielnych procesorach.

• Z logicznego punktu widzenia procesory zajmujące

się zbieraniem informacji, podejmowaniem decyzji

i sterowaniem efektorami mogłyby działać na

jednym procesorze sterowanym przez moduł

szeregujący. Użycie wielu procesorów poprawia

jednak efektywność i odporność systemu.

• Przydział procesów procesorów może być zadany z

góry (tak zwykle jest w systemach krytycznych)

albo sterowany przez dyspozytora, który decyduje

o przyznaniu procesora procesowi.

System wieloprocesorowy do

kierowania ruchem

Procesory
detektorów

Proces

sterujący
detektore
m

Procesory
natężenia
ruchu

Proces
wyświe-
tlający

Procesory
sterujące
światłami

Proces
sterując
y
światła
mi

Konsole operatorów

Detektory natężenia
ruchu i kamery

Światła

Architektury klient-serwer

• W takiej architekturze program użytkowy

jest

modelowany

jako

zbiór

usług

oferowanych przez serwery i zbiór klientów,
którzy z tych usług korzystają.

• Klienci muszą znać dostępne serwery, ale

zwykle nie muszą wiedzieć o istnieniu
innych klientów.

• Klienci i serwery są oddzielnymi procesami.
• Procesy i procesory systemu nie muszą być

wzajemnie

jednoznacznie

przyporządkowane.

System klient-serwer

s1

s2

s3

s4

k

1

k

2

k

3

k

4

k

5

k

6

k

7

k

8

k

9

k

10

k

11

k

12

Proces serwera

Proces klienta

Rodzaje architektur klient-

serwer

• Model klienta cienkiego: całość przetwarzania i zarządzania

danymi ma miejsce na serwerze. Jedynym zadaniem klienta jest
uruchomienie oprogramowania prezentacyjnego.

Klient

Prezentacja

Serwer

Zarządzanie
danymi

Przetwarzanie

• Model klienta grubego: serwer odpowiada jedynie za zarządzanie

danymi. Oprogramowanie u klienta implementuje logikę programu
użytkowego i kontakt z użytkownikiem systemu.

Klient

Prezentacja
Przetwarzanie

Serwer

Zarządzanie
danymi

Model klienta cienkiego

• Architektura dwuwarstwowa z klientem cienkim

jest najprostszym rozwiązaniem, które można
wykorzystać w scentralizowanych systemach
odziedziczonych

ewoluujących

w

kierunku

architektur klient-serwer.

• Interfejs użytkowy działa jako serwer i obsługuje

przetwarzanie użytkowe oraz zarządzanie danymi.

• Model klienta cienkiego może być również

zaimplementowany tam, gdzie klienci są raczej
prostymi

urządzeniami

sieciowymi,

a

nie

komputerami osobistymi albo stacjami roboczymi.

• Na

takim

urządzeniu

sieciowym

działa

przeglądarka sieci oraz interfejs użytkownika
realizowany przez ten system.

• Najważniejsza wadą modelu klienta cienkiego jest

duże obciążenie przetwarzaniem zarówno sieci, jak
i serwera.

Model klienta grubego

• Korzysta się z dostępnej mocy obliczeniowej i

przekazuje

klientowi

zarówno

przetwarzanie

związane z logiką programu użytkowego, jak i

prezentację.

• Serwer jest zasadniczo serwerem transakcji, który

zarządza transakcjami w bazie danych.

• Dobrze znanym przykładem architektury tego typu

są systemy bankomatów. Bankomat jest tam

klientem, a serwerem jest komputer główny

obsługujący bazę danych kont klientów.

• W modelu klienta grubego przetwarzanie jest

bardziej efektywne niż w wypadku modelu klienta

cienkiego, zarządzanie systemem jest natomiast

trudniejsze niż w tym pierwszym modelu.

Architektura warstwowa

• W tej architekturze prezentacja, przetwarzanie

użytkowe i zarządzanie danymi są logicznie

oddzielonymi procesami.

• Niekoniecznie potrzebne są trzy systemy

komputerowe włączone do sieci.

• Jeden komputer serwera może obsługiwać

zarówno

przetwarzanie

użytkowe,

jak

i

zarządzanie danymi programu użytkowego jako

dwa oddzielne logicznie serwery.

• Gdy jednak oczekiwania wzrosną, można będzie

dość łatwo wyodrębnić przetwarzanie użytkowe i

zarządzanie danymi, po czym uruchomić je na

oddzielnych procesorach.

• Czasami ze względów praktycznych redukuje się

trzy warstwy do dwóch.

Warstwy rozproszonego

systemu użytkowego

• Warstwa

prezentacji

dotyczy

przedstawiania

informacji użytkownikowi i
całego

kontaktu

z

użytkownikiem.

• W warstwie przetwarzania

implementuje się logikę
programu użytkowego.

• Warstwa

zarządzania

danymi

jest

odpowiedzialna

za

wszystkie

operacje

na

bazie danych

Warstwa przetwarzania

Warstwa zarządzania

danymi

Warstwa prezentacji

Architektura rozproszona

internetowego systemu

bankowego

Klient

Klient

Klient

Klient

Serwer WWW

Obsługa

konta

Serwer bazy danych

Baza danych
SQL kont
klientów

Zapytanie
SQL

Komunikacja HTTP

Zastosowania różnych

architektur klient-serwer

Architektura

Zastosowania

Architektura

Systemy, w których oddzielenie przetwarzania użytkowego od zarządzania

dwuwarstwowa

danymi jest niepraktyczne.

klient-serwer

Programy użytkowe wykonujące dużo obliczeń, ale w małym stopniu (albo wcale)

z klientami cienkimi

zarządzające danymi, np. kompilatory.

Programy użytkowe dużo korzystające z danych (przeglądanie i zapytywanie), ale
wykonujące mało (albo wcale) obliczeń użytkowych.

Architektura

Programy użytkowe, w których obliczenia są wykonywane u klienta, np. biurowe
arkusze kalkulacyjne

klient-serwer

Programy użytkowe wymagające złożonego obliczeniowo przetwarzania danych,

z klientami grubymi

np. przedstawiania graficznego danych.

Programy użytkowe ze względnie stabilną funkcjonalnością oferowaną użytkownikowi,
stosowane w środowisku ze starannie ustalonym zarządzaniem systemem.

Architektura

Ogromne programy użytkowe z setkami lub tysiącami użytkowników.

trójwarstwowa

Programu użytkowe, w których zarówno dane, jak i programy są płynne.

lub wielowarstwowa

Programy użytkowe, w których integruje się dane z wielu źródeł.

klient-serwer

Architektury klient – serwer:

podsumowanie

• W modelu systemu rozproszonego klient-serwer

klienci odróżniają się od serwerów.

• Klienci otrzymują usługi do serwerów, ale nie od

innych klientów.

• Serwery mogą działać jako klienci korzystający z

usług innych serwerów, ale nie mogą żądać usług

od klientów.

• Klienci muszą znać usługi oferowane przez

specyficzne serwery i wiedzieć, jak się z tymi

serwerami porozumieć.

• Ten model sprawdza się w wielu zastosowaniach.

Ogranicza jednak swobodę projektantów systemu,

którzy muszą zdecydować, gdzie mają być

oferowane usługi.

Architektura obiektów

rozproszonych

• Usunięcie rozróżnienia na klientów i serwery
• Obiekty systemu oferują interfejs do wykonywanych przez

siebie usług

• Inne obiekty mogą korzystać z tych usług bez logicznego

podziału na klientów i serwery

Szyna programowa

o1

o2

o3

o4

o5

o6

U (o1)

U (o2)

U (o3)

U

(o4)

U (o5)

U (o6)

Zalety architektury

obiektów rozproszonych

• Umożliwia projektantowi odłożenie w czasie

decyzji, gdzie i jak oferować usługi.

• Jest

architekturą

bardzo

otwartych

systemów, która umożliwia dodawanie

nowych zasobów w miarę potrzeby.

• System jest bardzo elastyczny i skalowalny.

Do obsługi rozmaitych obciążeń można

utworzyć różne egzemplarze systemu z tym

samym zbiorem usług oferowanych przez

odrębne lub powielone obiekty.

• W miarę potrzeby można dynamicznie

zmieniać

konfigurację

systemu

przez

migrację obiektów w sieci.

CORBA / DCOM

• CORBA jest zbiorem standardów dla

śródprogramów,

zdefiniowanym

przez

OMG (Object Management Group).

• Implementacje

CORBA

są

dostępne

zarówno dla systemów unixowych jak i z

rodziny MS Windows.

• DCOM jest standardem, który opracowano

i zaimplementowano w firmie Microsoft i

zintegrowano z systemami operacyjnymi z

rodziny Windows.

• Model rozproszonych obliczeń w DCOM jest

mniej ogólny niż CORBA.

CORBA: wizja programu

użytkowego

• Obiekty

użytkowe

zaprojektowane

i

zaimplementowane dla tego programu

użytkowego.

• Obiekty standardowe zdefiniowane przez

OMG na użytek specyficznej dziedziny.

• Główne

usługi

CORBA

związane

z

podstawowymi

aspektami

obliczeń

rozproszonych,

takie

jak

katalogi,

zarządzanie zabezpieczeniami itd.

• Udogodnienia CORBA, takie jak ułatwienia

interfejsu

użytkownika,

zarządzanie

systemem itp.

Standardy CORBA

• Model obiektów użytkowych, w którym obiekty

CORBA mają dobrze określony i niezależny od

języka interfejs opisany w IDL (Interface

Definition Language – język opisu interfejsów).

• Pośrednik zleceń obiektowych (Object Request

Broker, ORB), który obsługuje żądania obiektów.

• Zbiór ogólnych usług obiektowych, które

prawdopodobnie będą potrzebne w wielu

rozproszonych programach użytkowych.

• Zbiór wspólnych komponentów zbudowanych

na bazie tych podstawowych usług. Te

komponenty mogą się przydać w rozmaitych

programach użytkowych.

Struktura rozproszonego programu

użytkowego opartego na CORBA

Pośrednik zleceń obiektowych

Obiekty
użytkowe

Udogodnienia
dziedzinowe

Udogodnienia
na
poziomie CORBA

Usługi CORBA

Model obiektowy CORBA

• Obiekt jest obudową atrybutów i usług, jak to jest

zwykle w wypadku obiektów.

• Obiekty CORBA muszą mieć jednak oddzielną

definicję interfejsu, w której określa się publiczne

atrybuty i operacje obiektu.

• Interfejs obiektów CORBA ustala się za pomocą

standardowego,

niezależnego

od

języka

programowania języka opisu interfejsów (IDL).

• Gdy obiekt pragnie skorzystać z usług innego

obiektu, dostaje się do nich przez interfejs IDL.

• Obiekty CORBA mają unikatowe identyfikatory

zwane IOR (Interoperable Object Reference –

odniesienia obiektów umożliwiające współpracę).

Pośrednik zleceń

obiektowych(ORB)

• Obiekt wywołujący ma do dyspozycji namiastkę

IDL, która zawiera definicję interfejsu obiektu

oferującego żądaną usługę.

• Osoba programująca umieszcza wywołania tej

namiastki w swojej implementacji wszędzie tam,

gdzie jest potrzebna ta usługa.

• IDL jest nadzbiorem C++, jeśli więc programuje

się w tym języku, to korzystanie z namiastki jest

łatwe. Jest również dość łatwe w C i Javie.

• Zdefiniowano również przekształcenia IDL na inne

języki, na przykład COBOL i Ada. W wypadku tych

języków

zwykle

jest

jednak

konieczne

wspomaganie narzędzi łączących z IDL.

Usługi CORBA

• Usługa katalogowa i usługa handlowa,

dzięki którym obiekty mogą znajdować
się i odwoływać do innych obiektów
sieci.

• Usługi powiadamiania, dzięki którym

obiekty mogą powiadomić inne obiekty
o zajściu pewnego zdarzenia.

• Usługi

transakcyjne

do

obsługi

niepodzielnych

transakcji

i

ich

wycofywania w wypadku niepowodzenia.

Inżynieria

oprogramowania

Wykład 11 –

architektury systemów czasu

rzeczywistego.

Prezentacja częściowo oparta na prezentacji przygotowanej przez Prof. J.E. Sienkiewicza

(opartej z kolei na podręczniku Iana Sommerville’a Inżynieria oprogramowania, WNT 2003)

Systemy czasu rzeczywistego

• Komputery są obecnie używane do sterowania

rozmaitymi systemami, od maszyn domowych

do całych hal produkcyjnych.

• Te komputery bezpośrednio porozumiewają się

z urządzeniami sprzętowymi.

• Ich

oprogramowanie

jest

wbudowanym

systemem czasu rzeczywistego, który musi

reagować na zdarzenia powodowane przez

sprzęt i wysyłać sygnały sterujące w

odpowiedzi na te zdarzenia. Jest wbudowane

w pewien większy system sprzętowy i musi

reagować na zdarzenia w środowisku tego

systemu w czasie rzeczywistym.

Definicja

• System czasu rzeczywistego jest systemem

oprogramowania, którego poprawne działanie

zależy od wyników przez niego wytwarzanych i

czasu potrzebnego do ich wytworzenia.

• „Tolerancyjnym”

systemem

czasu

rzeczywistego jest system, którego działanie

jest gorsze, jeśli wyniki nie są dostępne

zgodnie

z

ustalonymi

wymaganiami

czasowymi.

• „Wymagający” system czasu rzeczywistego to

system, którego działanie jest niepoprawne,

jeśli wyniki nie są tworzone zgodnie z

ustalonymi wymaganiami czasowymi.

System bodziec-reakcja

• Na podstawie otrzymanego bodźca system musi

wygenerować odpowiednią reakcję. Zachowanie

systemu

czasu

rzeczywistego

można

więc

zdefiniować przez wyliczenie bodźców, które może

otrzymać, skojarzonych z nimi odpowiedzi oraz

czasu, w którym należy je utworzyć.

• Podział bodźców:

– Bodźce okresowe pojawiają się w

przewidywanych odstępach czasu.

– Bodźce nieokresowe pojawiają się nieregularnie.

• System czasu rzeczywistego musi reagować na

bodźce pojawiające się w różnych chwilach. Jego

architektura musi więc być tak skonstruowana, aby

sterowanie było przekazywane do odpowiedniej

procedury obsługi natychmiast po pojawieniu się

bodźca.

Uniwersalny model

architektoniczny

• Systemy czasu rzeczywistego zwykle projektowane

są jako zbiór współbieżnych, współpracujących

procesów.

• Zadaniem części systemu czasu rzeczywistego

(moduł wykonawczy) jest zarządzanie tymi

procesami.

• Z każdym rodzajem detektora kojarzy się proces

zarządzania detektorem.

• Procesy

obliczające

wyznaczają

oczekiwaną

odpowiedź na bodźce otrzymane przez system.

• Procesy sterowania efektorami zarządzają działaniem

efektorów.

• Ten model umożliwia szybkie odbieranie danych od

detektorów (zanim będą gotowe następne dane

wejściowe),

późniejsze

ich

przetwarzanie

i

reagowanie przez efektory.

Uniwersalny model systemu

czasu rzeczywistego

Detektor

Detektor

Detektor

Detektor

Detektor

Detektor

Detektor

Detektor

Detektor

Detektor

Detektor

Detektor

System sterujący

czasu rzeczywistego

System sterujący

czasu rzeczywistego

Efektor

Efektor

Efektor

Efektor

Efektor

Efektor

Efektor

Efektor

Procesy sterujące detektorami i

efektorami

Detektor

Detektor

Efektor

Efektor

Sterowanie

efektorem

Sterowanie

efektorem

Procesor

danych

Procesor

danych

Sterowanie

detektorem

Sterowanie

detektorem

Bodziec

Reakcja

• Część

procesu

projektowania

systemu

polega

na

podjęciu

decyzji,

które

udogodnienia

systemu

będą

zaimplementowane przez oprogramowanie,

a które przez sprzęt.

• Ograniczenia czasowe lub inne wymagania

mogą

oznaczać,

że

niektóre

funkcje

systemu, takie jak przetwarzanie sygnałów,

muszą być zaimplementowane w postaci

specjalnie zbudowanego sprzętu.

• Proces projektowania systemu może więc

zarówno

obejmować

projektowanie

specjalnego sprzętu, jak i projektowanie

oprogramowania czasu rzeczywistego.

Projekty systemów czasu

rzeczywistego

Wymagania

systemowe

Podział

wymagań

Wymagania

dla sprzętu

Wymagania

na

oprogramowanie

Projektowanie

oprogramowan

ia

Projektowanie

sprzętu

Projektowanie oprogramowania

i sprzętu

Proces projektowania

• Zidentyfikuj bodźce, które system musi przetwarzać oraz

skojarzone z nimi reakcje.

• Dla każdego bodźca i związanej z nim reakcji zidentyfikuj

wymagania czasowe, które dotyczą przetwarzania

zarówno bodźca, jak i reakcji.

• Pogrupuj bodźce i reakcje w kilku procesach

współbieżnych.

Dobrym

modelem

uniwersalnej

architektury takiego systemu jest skojarzenie jednego

procesu z każdą klasą bodźców i reakcji.

• Dla każdego bodźca i reakcji zaprojektuj algorytmy do

przeprowadzania koniecznych obliczeń. Te projekty

algorytmów często trzeba opracować w dość wczesnej

fazie procesu, aby poznać ilość przetwarzania i czas

potrzebny do wykonania tych obliczeń.

• Zaprojektuj system szeregujący, który zapewni, że

procesy będą uruchamiane w chwili wystarczającej do

spełnienia ograniczeń czasowych.

• Zintegruj system pod kontrolą modułu wykonawczego.

Ograniczenia czasowe

• Systemy czasu rzeczywistego musza spełniać

postawione im ograniczenia czasowe, a zatem
zastosowanie strategii projektowych, które
powodują dodatkowe narzuty implementacyjne,
byłoby

niepraktyczne

w

wypadku

wymagających systemów czasu rzeczywistego.

• Projektowanie obiektowe oznacza na przykład

ukrywanie informacji o reprezentacji danych i
dostęp do atrybutów za pośrednictwem operacji
zdefiniowanych na obiektach. Prowadzi to
nieuchronnie do narzutów i utraty efektywności.

Modelowanie systemu czasu

rzeczywistego

• Najczęściej systemy takie modeluje się za

pomocą modelu stanowego.

• W modelu stanowym systemu zakłada się,

że w każdej chwili system jest w jednym z

wielu swoich stanów.

• Po wystąpieniu bodźca może nastąpić

przejście do innego stanu.

• System sterujący zaworem może na

przykład zmienić stan z „Zawór otwarty”

na „Zawór zamknięty” po otrzymaniu

polecenia operatora (bodźca).

DIAGRAM MASZYNY STANOWEJ UML

Model maszyny stanowej kuchenki

mikrofalowej

Oczekiwanie

do: wyświetlaj

godzinę

Działanie

do:
podgrzewa
nie

Pełna moc

do: ustaw
moc
= 600

Oczekiwanie

do: wyświetlaj

godzinę

Połowa
mocy

do: ustaw
moc
= 300

Ustawienie czasu

do: odczytaj liczbę
exit: ustaw czas

Niegotowy

do:
wyświetlaj
„Czekam”

Gotowy

do:
wyświetlaj
„Gotowy”

Pełna moc

Połow
a

mocy

Połowa
mocy

Pełna
moc

Stop
er

Liczba

Stoper

Zamknię
to

drzwicz
ki

Start

Zatrzymaj

Otworzono
drzwiczki

Zatwierdzo
no czas

Wybór języka programowania

• Język programowania użyty do implementacji

systemu czasu rzeczywistego również może mieć

wpływ na projekt.

• Wymagające systemy czasu rzeczywistego wciąż

programuje się niekiedy w asemblerze, aby

sprostać limitom czasowym.

• Można skorzystać także z języków programowania

systemowego takich jak C, które dają efektywny

kod.

• Zaleta języków programowania systemowego

niskiego poziomu polega na tym, że umożliwiają

tworzenie efektywnego kodu. Taki język nie

obejmuje jednak żadnych konstrukcji do obsługi

współbieżności

albo

zarządzania

zasobami

współdzielonymi.

Problemy z Javą

• Java nie nadaje się do programowania wymagających

systemów czasu rzeczywistego lub systemów, w których
procesy mają ścisłe limity czasowe.

• Oto zasadnicze problemy z zastosowaniem Javy jako języka

programowania czasu rzeczywistego:

• Nie można określić czasu, w którym wątki powinny

działać.

• Odśmiecanie nie podlega sterowaniu – może rozpocząć

się w dowolnym czasie.

• Nie ma możliwości odczytu długości kolejek związanych

ze współdzielonymi zasobami.

• Implementacja maszyny wirtualnej Javy jest inna na

każdym komputerze.

• Język nie przewiduje szczegółowej analizy wykorzystania

procesora i pamięci w czasie wykonania.

Moduły wykonawcze czasu

rzeczywistego

• Moduł wykonawczy czasu rzeczywistego

jest odpowiednikiem systemu operacyjnego

w komputerze ogólnego przeznaczenia.

• Zarządza procesami i przydziałem zasobów

systemu czasu rzeczywistego.

• Uruchamia i zatrzymuje procesy, aby

reagować na bodźce.

• Przydziela pamięć i zasoby procesora.
• Nie obejmuje jednak najbardziej złożonych

udogodnień systemu operacyjnego, np.

zarządzania plikami.

Zbiór komponentów modułu

wykonawczego

• Zegar czasu rzeczywistego.

– Udostępnia informacje niezbędne do okresowego szeregowania

procesów.

• Procedura obsługi przerwań.

– Zarządza nieokresowymi żądaniami usług.

• Moduł szeregujący.

– Odpowiada za znajdowanie procesów, które można wykonać i wybór

jednego z nich, który będzie wykonywany.

• Menedżer zasobów.

– Przydziela procesowi wybranemu do wykonywania odpowiednie zasoby

(czas procesora i pamięć).

• Dyspozytor.

– Odpowiada za rozpoczęcie wykonywania procesu.

• Menedżer konfiguracji.

– Odpowiada za dynamiczną rekonfigurację sprzętu systemu. Bez

zatrzymywania systemu można wyłączyć z użycia pewne moduły

sprzętowe lub rozszerzyć system o nowy sprzęt.

• Menedżer awarii.

– Odpowiada za wykrywania awarii sprzętu i oprogramowania oraz

podjęcie odpowiednich działań zmierzających do odtworzenia stanu po

awariach.

Dyspozytor

Menedżer zasobów

Menedżer zasobów

Moduł

szeregujący

Moduł

szeregujący

Informacje o zasobach

wymaganych przez

procesy

Informacje o zasobach

wymaganych przez

procesy

Informacje

o szeregowaniu

Informacje

o szeregowaniu

Zegar czasu

rzeczywistego

Zegar czasu

rzeczywistego

Procesy

czekające

na zasoby

Procesy

czekające

na zasoby

Lista procesów

gotowych

Lista procesów

gotowych

Lista procesorów

Lista procesorów

Lista dostępnych

zasobów

Lista dostępnych

zasobów

Procedura obsługi

przerwań

Procedura obsługi

przerwań

Proces wykonywany

Proces
Zwolnione
gotowy
zasoby

Poziom priorytetu

• Bodźce

przetwarzane

przez

systemy

czasu

rzeczywistego mają zwykle różne poziomy priorytetu.

• W wypadku niektórych bodźców, takich jak te

związane z sytuacjami wyjątkowymi, ważne jest, aby

zakończyć ich przetwarzanie w ściśle ustalonym

czasie.

• Inne procesy można bezpiecznie opóźnić, gdy obsługi

wymaga bardziej krytyczny proces.

• Poziom przerwania oznacza najwyższy priorytet.

Nadaje się go procesom, które wymagają bardzo

szybkiej reakcji. Jednym z nich jest proces zegara

czasu rzeczywistego.

• Poziom zegarowy jest nadawany procesom

okresowym.

Procesy okresowe

• Procesy okresowe to procesy, które muszą być

wykonywane w ustalonych odstępach czasu w

celu pobrania danych i sterowania efektorami.

• Moduł wykonawczy korzysta ze swojego zegara

czasu rzeczywistego, aby określić, kiedy

proces ma być wykonywany.

• W większości systemów czasu rzeczywistego

występuje kilka klas procesów okresowych.

• Mają one różne okresy (odstępy między

wykonaniami), czasy działania i limity czasowe

(czasy, po których muszą zakończyć działanie).

• Moduł wykonawczy musi wybrać odpowiedni

proces do wykonania w każdej chwili.

Zarządzanie procesami

• Zarządzanie

procesami

w

module

wykonawczym czasu rzeczywistego polega

na

zarządzaniu

zbiorem

procesów

współbieżnych, który jest częścią systemu

czasu rzeczywistego.

• Menedżer procesów musi wybrać proces do

wykonania, przydzielić dla niego pamięć i

zasoby procesora oraz rozpocząć jego

wykonywanie na procesorze.

Moduł szeregujący

Wybierz proces

do wykonania

Menedżer zasobów

Przydziel pamięć

i procesor

Dyspozytor

Rozpocznij wykonywanie

na dostępnym procesorze

Moduł szeregujący

• Przegląda listę procesów okresowych i wybiera proces do

wykonania.

• Wybór zależy od priorytetu, okresu, oczekiwanego czasu

wykonania i limitu poszczególnych procesów gotowych.

• Czasem po jednym tyknięciu zegara trzeba wykonać dwa

procesy z różnymi limitami czasowymi. W takiej sytuacji
jeden z nich musi być opóźniony, jednak najwyżej na tyle,
aby jego zakończenie przed upływem limitu czasowego było
możliwe.

• Szeregowanie bez wywłaszczenia:

– Gdy wybrano proces do wykonywania, działa on aż do

zakończenia swojej pracy lub do chwili zablokowania z
jakiegoś powodu, np. oczekiwania na dane wejściowe.

• Szeregowanie z wywłaszczeniem:

– Działanie procesu może być przerwane, jeśli trzeba

obsłużyć proces o wyższym priorytecie.

Systemy monitorowania i

sterowania

• Systemy monitorowania i sterowania są

ważną klasą systemów czasu rzeczywistego.

• Sprawdzają stan detektorów dostarczających

informacje o środowisku systemu i wykonują
akcje zależne od odczytów z tych detektorów.

• Systemy monitorowania podejmują działania,

gdy detektory wykryją jakąś wyjątkową
wartość.

• Systemy sterowania ustawicznie sterują

sprzętowymi efektorami zależnie od wartości
związanych z nimi detektorów.

Przykład - system antywłamaniowy

• Ten system korzysta z różnych rodzajów

detektorów.

• Gdy detektor wykrywa obecność intruza,

system automatycznie dzwoni do pobliskiego

posterunku policji i za pomocą syntezatora

mowy informuje o miejscu wywołania alarmu.

• System alarmowy zwykle jest zasilany z sieci,

ale ma też zapasowe akumulatory.

• System jest „tolerancyjnym” systemem czasu

rzeczywistego, który nie ma dużych wymagań

czasowych.

• Detektory nie muszą wykrywać bardzo szybko

następujących

zdarzeń,

trzeba

je

więc

odpytywać najwyżej dwa razy na sekundę.

Proces projektowania

• Rozpoczyna się od rozpoznania bodźców

nieokresowych działających na system i
skojarzonych z nimi odpowiedzi.

• Następnym

krokiem

procesu

projektowania

jest

rozważenie

ograniczeń czasowych związanych z
każdym bodźcem i skojarzoną z nim
reakcją.

• Kolejnym krokiem jest podział funkcji

systemu do procesów współbieżnych.

Klasy bodźców w systemie

antywłamaniowym

• Zanik zasilania

– Jest zgłaszany przez układ monitorujący

napięcie. Wymagana odpowiedzią jest

przełączenie na zasilanie zapasowe

przez wysłanie sygnału do urządzenia

przełączającego zasilanie.

• Wtargnięcie intruza

– Reakcją na ten bodziec jest wyznaczenie

numeru pokoju, w którym znajduje się

aktywny detektor, zadzwonienie na

policję, uruchomienie syntezatora mowy

do obsługi telefonu oraz włączenie

syreny i świateł w okolicach włamania.

Wymagania czasowe stawiane

bodźcom i reakcji

Bodziec/reakcja Wymagania czasowe

Przerwanie zaniku

Przełączenie na zasilanie zapasowe musi być

ukończone po najwyżej zasilania 50ms
Alarm drzwiowy Każdy detektor drzwiowy musi być odpytywany dwa
razy na sekundę

Alarm okienny Każdy detektor okienny musi być odpytywany dwa razy
na sekundę

Detektor ruchu Każdy detektor ruchu powinien być odpytywany dwa
razy na sekundę

Sygnał dźwiękowy

Sygnał dźwiękowy musi być włączony po

upływie najwyżej 1 sekundy

od alarmu wywołanego przez detektor

Włączenie świateł

Światła powinny być włączone po upływie

najwyżej 1/2 sekundy

od alarmu wywołanego przez detektor

Komunikacja

Wezwanie policji przez telefon należy rozpocząć po

upływie najwyżej 2

sekund od alarmu wywołanego przez

detektor

Syntezator mowy

Komunikat z syntezatora powinien być dostępny

po upływie najwyżej 4

sekund od alarmu wywołanego przez detektor

Proces

detektorów ruchu

Proces detektorów

drzwiowych

Proces detektorów

okiennych

Proces

komunikacyjny

Proces

monitorowania budynku

Proces systemu

alarmowego

Proces przełączania

zasilania

Proces sygnalizacji

dźwiękowej

Proces sterowania

światłami

Proces syntezatora

mowy

400 Hz

60 Hz

100 Hz

Stan
detektorów

Numer
pokoju

Numer
pokoju

Stan
detektorów

560 Hz

Przerwanie
braku zasilania

System alarmowy

Kontrol
er
budynk
u

System alarmowy

Komunikat
alarmowy

System
alarmowy

Stan
detektorów

Numer
pokoju

System alarmowy

Systemy gromadzenia danych

• Systemy

gromadzenia

danych

stanowią kolejną klasę systemów
czasu

rzeczywistego,

mających

zwykle

uniwersalny

model

architektoniczny.

• Takie systemy zbierają od detektorów

dane do późniejszego przetwarzania i
analizy.

System zbierający dane od detektorów

monitorujących promieniowanie

neutronowe w reaktorze atomowym.

• Dane z detektorów są umieszczane w buforze;

następnie są z niego pobierane i przetwarzane.

• W

rezultacie

na

ekranie

operatora

jest

wyświetlane średnie natężenie promieniowania.

• Każdy detektor ma swój proces, który zmienia

dane analogowe o natężeniu promieniowania

neutronowego na sygnał cyfrowy.

• Następnie przekazuje to natężenie promieniowania

oraz swój identyfikator do bufora danych.

• Proces odpowiedzialny za przetwarzanie danych

pobiera dane z tego bufora, przetwarza je i

przekazuje do procesu wyświetlającego w celu

pokazania na konsoli operatora.

Architektura systemu

monitorującego promieniowanie

Detektory (każdy przepływ danych to stan detektora)

Proces

detektora

Przetwarzanie

danych

Wyświetlacz

Bufor z danymi

z detektorów

Identyfikator
i stan detektora

Wyznaczone
natężenie
promieniowania

Wzajemne wykluczanie

• W

systemach

czasu

rzeczywistego,

które

gromadzą

i

przetwarzają

dane,

czasy

wykonywania i okresy procesów gromadzących

oraz przetwarzających mogą być nierówne.

• W większości systemów gromadzenia danych

neutralizacja tych różnic szybkości polega na

zastosowaniu bufora cyklicznego.

• Ważne: należy zaimplementować wzajemne

wykluczanie,

aby

procesy

producentów

i

konsumentów nie miały w buforze dostępu do tego

samego elementu w tym samym czasie.

• System musi również zadbać o to, żeby producent

nie mógł dodać informacji do pełnego bufora i

żeby konsument nie pobrał informacji z pustego

bufora.

Inżynieria

oprogramowania

Wykład 12 –

systemy krytyczne.

Prezentacja częściowo oparta na prezentacji przygotowanej przez Prof. J.E. Sienkiewicza

(opartej z kolei na podręczniku Iana Sommerville’a Inżynieria oprogramowania, WNT 2003)

Systemy krytyczne

• Awarie większości systemów sterowanych

komputerami powodują jedynie niewygody, a

nie poważne, długotrwałe zniszczenia.

• Istnieją jednak systemy, których awarie

mogą

powodować

znaczne

straty

gospodarcze,

fizyczne

zniszczenia

lub

zagrożenia życia ludzkiego. Systemy te

zwykle nazywa się systemami krytycznymi.

• Pewność

jest

zasadniczym

atrybutem

systemów krytycznych. Każdy z jej aspektów

może być ważny.

Rodzaje systemów krytycznych

• Systemy krytyczne dla bezpieczeństwa to

systemy, których awaria może powodować
obrażenia i utratę życia lub poważne
zniszczenie środowiska.

• Systemy krytyczne dla zadania to systemy,

których

awaria

może

powodować

niepowodzenie pewnej czynności mającej
jakiś cel.

• Systemy krytyczne dla przedsiębiorstwa to

systemy, których awaria może powodować
kłopoty korzystających z nich przedsiębiorstw.

Składniki systemu

podatne na awarie

• Sprzęt, który może się popsuć z powodu

błędów projektowych, błędów przy ich
produkcji lub z powodu naturalnego
zmęczenia materiału.

• Oprogramowanie systemu, które może

ulec

awarii

z

powodu

błędów

w

specyfikacji, projekcie lub implementacji.

• Operatorzy

systemu,

którzy

mogą

niewłaściwie go obsługiwać.

Awarie systemu krytycznego

• Koszt awarii systemu krytycznego jest

zwykle

bardzo

wysoki.

Obejmuje

bezpośrednie koszty awarii (np. konieczność
wymiany systemu) oraz koszty pośrednie
(koszty procesów sądowych, utracone zyski
w związku z niedostępnością systemu).

• W rezultacie systemy krytyczne są zwykle

budowane raczej za pomocą starannie
sprawdzonych metod, a nie nowinek, z
którymi dotychczas nie wiążą się znaczące
praktyczne doświadczenia.

Klasyfikacja awarii

Klasa awarii

Opis

Chwilowa

Zdarza się tylko dla niektórych danych wejściowych

Trwała

Następuje dla wszystkich danych wejściowych

Usuwalna

System może ją usunąć bez interwencji operatora

Nieusuwalna

Usunięcie awarii wymaga interwencji operatora

Nieniszcząca

Awaria nie powoduje zniszczenia stanu i danych systemu

Niszcząca

Awaria powoduje zniszczenie stanu i danych systemu

Pojęcie pewności - ogólnie

• Pewność systemu komputerowego jest właściwością

systemu odpowiadającą zaufaniu, którym jest obdarzony.

• Zaufanie oznacza stopień przekonania użytkownika, że

system będzie działał tak jak należy i nie będzie się

„psuł” przy normalnym użytkowaniu.

• Ta właściwość nie może być wyrażona liczbowo, ale da

się ją zapisać nieformalnie.

• Określenia, takie jak „niepewny”, „bardzo pewny” i

„ultrapewny”, odpowiadają różnym poziomom zaufania,

którymi obdarzamy system.

• Koszt pewności jest funkcją wykładniczą.

• Systemy niepewne zwykle pozostają nieużywane.

• Trudno jest odzyskać pewność.

• Zwykle można zrekompensować np. brak efektywności

systemu, ale nie brak pewności.

• Systemy niegodne zaufania mogą spowodować utratę

informacji.

Składniki pewności

Zabezpieczenie

Bezpieczeństwo

Niezawodność

Dostępność

Pewność

Zdolność systemu do
realizacji usług,
gdy są potrzebne

Zdolność systemu do
realizacji usług zgodnie
ze specyfikacją

Zdolność systemu do
działania bez
katastroficznych
awarii

Zdolność systemu
do
zabezpieczenia
siebie
przed
przypadkowym
lub
celowym
włamaniem

• Niezawodność i dostępność uważa się zwykle za

najważniejsze wymiary pewności.

• Dostępność systemu to prawdopodobieństwo, że będzie

on realizował usługi dla użytkowników, gdy mu to zlecą.

• Niezawodność to prawdopodobieństwo, że system

zaoferuje usługi zgodne ze specyfikacją.

• Niezawodność

wymaga

dostępności,

ponieważ

niezrealizowanie wyspecyfikowanych usług nie jest

oczywiście zachowaniem zgodnym ze specyfikacją.

• Definicje precyzyjne

– Niezawodność: prawdopodobieństwo bezawaryjnego

działania w ciągu ustalonego czasu w zadanym

środowisku w określonym celu.

– Dostępność: prawdopodobieństwo, że w ustalonej

chwili system będzie działał i będzie zdolny do

realizacji żądanych usług.

Dostępność i niezawodność

• Unikanie usterek.

– Stosuje się metody tworzenia, które zmniejszają

możliwość pomyłek lub umożliwiają wychwytywanie

ich, zanim doprowadzą do awarii systemu.

• Wykrywanie i usuwanie usterek.

– Stosuje się metody weryfikacji i zatwierdzania,

które zwiększają szansę wykrycia i usunięcia

usterek przed przystąpieniem do użytkowania

systemu.

• Tolerowanie usterek.

– Stosuje się metody, które zapewniają, że usterki w

systemie nie powodują błędów, a błędy systemu

nie powodują awarii.

Poprawianie niezawodności

systemu

• Program może zawierać znane błędy, a mimo

tego użytkownicy mogą go uważać za

niezawodny.

• Co więcej, doświadczeni użytkownicy zwykle

„obchodzą” usterki oprogramowania, o których

wiadomo, że powodują awarie. Świadomie

unikają korzystania z udogodnień systemu, o

których wiedzą, że spowodują kłopoty.

• Niektórzy nigdy nie wprowadzą błędnych

danych wejściowych, awaria nigdy się więc nie

zdarzy.

• Naprawienie usterek w tych udogodnieniach

praktycznie

nie

zmienia

niezawodności

postrzeganej przez użytkowników.

Niezawodność - uwagi

Bezpieczeństwo

• Bezpieczeństwo

systemu

to

atrybut

odzwierciedlający zdolność systemu do

normalnego lub nienormalnego działania

bez wywoływania zagrożeń dla ludzi lub

środowiska.

• Jeśli bezpieczeństwo jest zasadniczą cechą

systemu krytycznego, to nazywamy go

systemem krytycznym dla bezpieczeństwa.

• Przykładami takich systemów są systemy

sterowania i kontroli w samolocie, systemy

sterowania

procesami

w

reaktorach

chemicznych i farmaceutycznych oraz

systemy sterowania samochodami.

Sposoby zapewnienia

bezpieczeństwa

• Unikanie zagrożeń. System jest zaprojektowany tak, aby

uniknąć zagrożeń.

– System tnący, którego zadziałanie wymaga od operatora

naciśnięcia dwóch przycisków w tej samej chwili, wystrzega

się na przykład ryzyka umieszczenia rąk operatora w

zasięgu noża.

• Wykrywanie i eliminowanie zagrożeń. System jest

zaprojektowany tak, aby wykrywać i eliminować zagrożenia,

zanim doprowadzą do wypadku.

– System reaktora chemicznego może na przykład wykrywać

nadmierne ciśnienie i otwierać zawór bezpieczeństwa w

celu zmniejszenia ciśnienia, zanim dojdzie do eksplozji.

• Ograniczanie szkód. System może obejmować udogodnienia

zabezpieczające, które ograniczają szkody będące

konsekwencją wypadku.

– Silnik lotniczy zawiera na przykład automatyczne gaśnice.

Gdy pojawi się ogień, zwykle można go ugasić, zanim

stanie się zagrożeniem dla pasażerów i załogi.

Zabezpieczenie

• Zabezpieczenie systemu to oszacowanie

stopnia zabezpieczenia systemu przed

atakami

z

zewnątrz,

zarówno

przypadkowymi, jak i celowymi.

• Przykładami

ataków

są

wirusy,

nieuprawnione

użycie

usług

systemu,

nieuprawnione aktualizowanie systemu lub

jego danych itd.

• Bez rozsądnego poziomu zabezpieczeń

dostępność, niezawodność i bezpieczeństwo

systemu mogą być zniweczone przez

zewnętrzne ataki, które wywołały szkody w

systemie.

Szkody, które mogą być

wynikiem ataku z zewnątrz

•

Zaprzestanie usługi. System może być

zmuszony do przyjęcia stanu, w którym nie

jest możliwe normalne realizowanie usług.

•

Uszkodzenie programów lub danych.

Komponenty programowe systemu mogą

być podmienione w nieuprawniony sposób.

•

Ujawnienie poufnej informacji.

Informacja przechowywana w systemie

może być poufna. Atak z zewnątrz może

ujawnić ją nieuprawnionym osobom.

Wymagania dla systemów

krytycznych

• Oczekiwanie

pewności

systemów

krytycznych

prowadzi

do

wymagań

funkcjonalnych i niefunkcjonalnych:

– Wymagania funkcjonalne mogą być

definicjami udogodnień do wykrywania
błędów i odtwarzania systemu oraz
definicjami właściwości systemu, które
uchronią go przed awariami.

– Wymagania niefunkcjonalne mogą być

definicjami wymaganej niezawodności i
dostępności systemu.

Wymagania typu „nie będzie”

• Służą do określenia nieakceptowalnych

zachowań systemu. Oto przykłady takich

wymagań:

– System nie będzie umożliwiał użytkownikom

modyfikowania praw dostępu do plików,

których nie utworzyli (zabezpieczenie).

– System nie będzie umożliwiał wybrania trybu

wstecznej siły ciągu, gdy samolot jest w

powietrzu (bezpieczeństwo).

– System nie będzie umożliwiał jednoczesnego

uruchomienia więcej niż trzech sygnałów

alarmowych (bezpieczeństwo).

Miary niezawodności

• Pierwsze

miary

niezawodności

dotyczyły

komponentów sprzętowych.

• Awarie takich komponentów są nieuchronne ze

względu na czynniki fizyczne, takie jak zużycie

ścierne, ogrzewanie elektryczne itd.

• Te miary sprzętowe nie zawsze są odpowiednie do

specyfikowania niezawodności oprogramowania,

ponieważ natury awarii sprzętu i oprogramowania

są różne.

• Awarie komponentów programowych są zwykle

chwilowe, a nie trwałe. Pojawiają się jedynie dla

pewnych

danych

wejściowych.

Jeśli

nie

uszkodzono danych, to system często może

kontynuować działanie po wystąpieniu awarii.

Miary niezawodności

Miara

Objaśnienie

POFOD

Prawdopodobieństwo awarii przy zleceniu. Prawdopodobieństwo, że

Probability

system ulegnie awarii po zleceniu mu usługi. POFOD o

wartości 0,001

of failure oznacza, że jedno zlecenie na tysiąc skończy się awarią.
on demand

ROCOF

Częstotliwość występowania awarii. Częstotliwość występowania

Rate of failure

nieoczekiwanych zachowań. ROCOF o wartości 0,02 oznacza, że w

occurence ciągu 100 jednostek czasu działania prawdopodobnie zdarza się 2

awarie. Ta miara bywa czasem nazywana intensywnością awarii.

MTTF (MTBF) Średni czas do awarii. Średni czas między zaobserwowanymi awariami
Mean timesystemu. MTTF o wartości 500 oznacza, że co 500 jednostek czasu to
to (between) failure można oczekiwać jednej awarii.

AVAIL

Dostępność. Prawdopodobieństwo, że system jest dostępny dla

Availability

użytkownika w określonej chwili. Dostępność o wartości 0,998 oznacza,

że na 1000 jednostek czasu system prawdopodobnie będzie dostępny

w czasie 998 jednostek.

MTTR

Średni czas (wyrażony np. w godzinach),

Mean time to repair wymagany do naprawy uszkodzonego urządzenia / oprogramowania

od momentu wystąpienia awarii

Przykład specyfikacji

niezawodności

• Rozważmy wymagania niezawodnościowe stawiane

bankomatowi.

• Przypuśćmy, że każda maszyna w sieci jest używana

około 300 razy dziennie.

• Czas życia sprzętu systemu wynosi osiem lat, a

oprogramowanie jest aktualizowane średnio raz na dwa

lata.

• W czasie działania jednej wersji oprogramowania każda

maszyna obsługuje około 200 000 transakcji.

• Sieć banku składa się z 1000 maszyn.

• Oznacza to, że dziennie następuje 300 000 transakcji w

centralnej bazie danych (około 100 milionów rocznie).

• Awarie dzieli się na dwie duże klasy: te, które wpływają

na jedną maszynę w sieci, oraz te, które wpływają na

bazę danych, a zatem na wszystkie bankomaty w sieci.

Specyfikacja niezawodności

bankomatu

Klasa awarii

Przykład

Miara niezawodności

Trwała System nie działa z żadną wsuwaną

ROCOF

nieniszcząca

kartą. Usunięcie awarii wymaga ponownego 1

zdarzenie/1000 dni
uruchomienia oprogramowania.

Chwilowa

Pasek magnetyczny nieuszkodzonej

ROCOF

nieniszcząca

wsuniętej karty nie może być odczytany 1 na 1000 transakcji

Trwała

Zestaw jednoczesnych transakcji w sieci Niemierzalna! Nie

powinna

niszcząca

powoduje uszkodzenie bazy danych

się zdarzyć w

czasie życia

systemu

Cykl życia

bezpieczeństwa

zgodny z IEC 61508

Budowanie systemów

związanych z bezpieczeństwem

Budowanie systemów

związanych z bezpieczeństwem

Planowanie

Zatwierdzenie i instalacja

Planowanie

Zatwierdzenie i instalacja

Instalacja

i przekazanie

Instalacja

i przekazanie

Zatwierdzenie

bezpieczeństwa

Zatwierdzenie

bezpieczeństwa

Działanie

i pielęgnacja

Działanie

i pielęgnacja

Likwidacja systemu

Likwidacja systemu

Zewnętrzne udogodnienia

do redukcji ryzyka

Zewnętrzne udogodnienia

do redukcji ryzyka

Analiza zagrożeń

i ryzyka

Analiza zagrożeń

i ryzyka

Definicja pojęć

i zakresu

Definicja pojęć

i zakresu

Przyporządkowanie

wymagań bezpieczeństwa

Przyporządkowanie

wymagań bezpieczeństwa

Opracowanie wymagań

bezpieczeństwa

Opracowanie wymagań

bezpieczeństwa

Specyfikowanie

bezpieczeństwa

Analiza zagrożeń i ryzyka

• Analiza zagrożeń i ryzyka polega na badaniu systemu i

środowiska, w jakim system działa.

• Jej celem jest znalezienie potencjalnych zagrożeń, które

mogą pojawić się w środowisku, pierwotnych przyczyn

tych zagrożeń i związanego z nimi ryzyka.

• To

złożony

i

trudny

proces,

który

wymaga

niestandardowego myślenia i wiedzy ekspertów z

rozmaitych dziedzin.

• Powinien być wykonywany przez doświadczonych

inżynierów

z

udziałem

ekspertów

z

dziedziny

zastosowania

i

profesjonalnych

doradców

od

bezpieczeństwa.

• Do identyfikacji zagrożeń można użyć sposobów pracy

grupowej, takich jak burza mózgów.

• Zagrożenia mogą być znalezione także dzięki temu, że

jeden z uczestniczących analityków bezpośrednio

doświadczył incydentu, który doprowadził do zagrożenia.

Proces analizy zagrożeń i ryzyka

• Rozpoznawanie zagrożeń. Rozpoznaje się

potencjalne zagrożenia, które mogą wystąpić.

Ich zbiór zależy od środowiska, w którym

system będzie użytkowany.

• Analiza ryzyka i klasyfikacja zagrożeń. Każde

zagrożenie rozpatruje się oddzielnie. Te

szczególnie poważne i nie wykluczone są

wybierane do dalszej analizy.

• Rozkładanie zagrożeń. Każde zagrożenie

rozpatruje się oddzielnie i szuka jego

przyczyn.

• Ocena szans zmniejszenia ryzyka. Znajduje

się propozycje zmniejszenia i redukcji

rozpoznanego ryzyka.

System podawania insuliny

• Za duża dawka insuliny (niepowodzenie usługi).

• Za mała dawka insuliny (niepowodzenie usługi).

• Brak zasilania w związku z wyczerpaniem baterii

(elektryczne).

• Elektryczna interferencja maszyny z innym

sprzętem medycznym, takim jak rozrusznik serca

(elektryczne).

• Złe podłączenie detektora lub efektora

spowodowane przez niedopasowanie (fizyczne).

• Części maszyny pozostawione w ciele chorego

(biologiczne).

• Zakażenie spowodowane podłączeniem maszyny

(biologiczne).

• Reakcja alergiczna na materiał lub insulinę używaną

w maszynie (biologiczne).

Analiza drzewa awarii

• W wypadku każdego rozpoznanego zagrożenia

należy przeprowadzić analizę, której celem jest

znalezienie sytuacji powodujących to zagrożenie.

• Istnieją dedukcyjne i indukcyjne metody analizy

zagrożeń.

• Metody dedukcyjne (zwykle łatwiejsze w użyciu)

polegają na rozpoczęciu od zagrożenia i na jego

podstawie poszukiwania możliwych awarii systemu.

• Metody indukcyjne polegają na rozpoczęciu od

awarii systemu i poszukiwaniu zagrożeń, które

mogą powstać.

• Jeśli to możliwe, w analizie zagrożeń należy użyć

obu rodzajów metod

Drzewo awarii

systemu podawania insuliny

Podano nieodpowiednią

dawkę insuliny

Awaria systemu

podawania

Odpowiednia dawka

podana w niewłaściwym

czasie

Błędne sygnały pompy

Niepoprawny pomiar

poziomu cukru

Awaria zegara

Błąd przy obliczaniu

poziomu cukru

Awaria detektora

Błąd

arytmetyczny

Błąd

algorytmiczny

Błąd przy
obliczaniu
poziomu cukru

Błąd

algorytmiczny

Błąd

arytmetyczny

lub

lub

lub

lub

lub

Potencjalne problemy

oprogramowania

• Błąd arytmetyczny.

– Pojawia się, gdy jakieś obliczenie arytmetyczne

powoduje błąd reprezentacji. W specyfikacji
trzeba wskazać wszystkie błędy arytmetyczne,
które mogą się zdarzyć. Zależą one od
zastosowanego algorytmu.

• Błąd algorytmiczny.

– To znacznie trudniejsza sytuacja, ponieważ

trudno wykryć jakiekolwiek nienormalne
okoliczności. Można je wykryć przez porównanie
obliczonej potrzebnej dawki insuliny z poprzednio
podaną.

Poziomy akceptowalności

zagrożenia

• Nie do przyjęcia. System musi być zaprojektowany

tak, że to zagrożenie nie może wystąpić, a nawet

jeśli wystąpi, nie może doprowadzić do wypadku.

• Tak małe, jak to jest tylko możliwe (ALARP- as

low as reasonably practical). System musi być

zaprojektowany tak, aby biorąc pod uwagę koszty,

czas dostawy, itd., zmniejszyć prawdopodobieństwo

wystąpienia wypadku z powodu tego zagrożenia.

• Akceptowalne. Projektanci powinni przedsięwziąć

wszystkie kroki w celu zmniejszenia

prawdopodobieństwa powstania zagrożenia, jednak

tylko pod warunkiem, że nie zwiększą one kosztu, nie

opóźnią czasu dostawy, ani nie pogorszą atrybutów

niefunkcjonalnych.

Proces szacowania ryzyka

• Obejmuje

kalkulacje

prawdopodobieństwa

i

dotkliwości zagrożenia.

• Zwykle osiągnięcie dokładnych wyników tej

czynności jest bardzo trudne i najczęściej zależy od

inżynierskiego rozsądku.

• Prawdopodobieństwo i dotkliwość są oceniane za

pomocą

wartości

względnych,

takich

jak

„prawdopodobne”, „niemożliwe”, „rzadkie”, „duża”,

„średnia” i „mała”.

• Doświadczenia zdobyte przy pracy nad poprzednimi

systemami umożliwiają skojarzenie z tymi pojęciami

pewnych wartości liczbowych.

• Wypadki są jednak dość rzadkie, zwykle więc trudno

jest zweryfikować dokładność takiej wartości.

Analiza ryzyka

związanego z zagrożeniami

Rozpoznane zagrożenie Prawdo- Dotkliwość

Oszacowanie

Akcepto-

podobieństwo zagrożenia ryzyka walność

Przedawkowanie insuliny

Średnie Duża Wysokie Nie do przyjęcia

Niedostateczna dawka insuliny

Średnie Mała Niskie Akceptowalne

Zanik zasilania

Duże Mała Niskie Akceptowalne

Maszyna podłączona niewłaściwie Duże Duża Wysokie Nie do przyjęcia

Maszyna rani pacjenta Małe Duża Średnie ALARP

Maszyna powoduje infekcję Średnie

Średnia Średnie ALARP

Zakłócenia elektryczne

Małe Duża Średnie ALARP

Reakcja alergiczna Małe Mała Małe Akceptowalne

Specyfikowanie

wymagań zabezpieczenia

• Identyfikacja i wycena. Rozpoznaje się składniki systemu (dane i

programy) i ich oczekiwany stopień ochrony. Stopień pożądanej

ochrony zależy zwykle od wartości składnika. Plik z hasłami ma

zatem zwykle większa wartość niż zbiór ogólnie dostępnych

witryn WWW, ponieważ potencjalny atak na plik z hasłami ma

poważne konsekwencje dla całego systemu.

• Analiza gróźb i oszacowanie ryzyka. Rozpoznaje się możliwe

groźby dla zabezpieczeń systemu i ocenia ryzyko związane z

każdą z tych gróźb.

• Przyporządkowanie gróźb. Rozpoznane groźby przyporządkowuje

się do składników. Dla każdego zidentyfikowanego składnika

powstaje lista związanych z nim gróźb.

• Analizowanie technologii. Ocenia się dostępne technologie

zabezpieczeń i ich skuteczność na rozpoznane groźby.

• Specyfikacja wymagań stawianych zabezpieczeniom. Specyfikuje

się wymagania stawiane zabezpieczeniom. Tam, gdzie ma to

sens, w specyfikacji wymagań wskazuje się technologie

zabezpieczeń, które można zastosować w celu ochrony systemu

przed groźbami.

Inżynieria

oprogramowania

Wykład 13 –

projektowanie z użyciem

wielokrotnym

.

Prezentacja częściowo oparta na prezentacji przygotowanej przez Prof. J.E. Sienkiewicza
(opartej z kolei na podręczniku Iana Sommerville’a Inżynieria oprogramowania, WNT 2003)

Powszechność i zalety

projektowania opartego na

wielokrotnym użyciu

komponentów

• W większości dyscyplin inżynieryjnych

proces projektowania jest oparty na użyciu

wielokrotnym komponentów.

• Podstawą projektów są komponenty, które

wypróbowano i przetestowano w innych

systemach.

• Obecnie powszechnie uważa się, że w

wypadku

tworzenia

oprogramowania

potrzebne

jest

podobne

podejście.

Oprogramowanie powinno być uważane za

składnik majątku. Użycie wielokrotne tego

składnika

majątku

jest

zasadniczym

warunkiem zwiększenia stopy zwrotu z

inwestycji w jego tworzenie.

Wielokrotnie używane elementy

oprogramowania

• Użycie

wielokrotne

systemów

programów

użytkowych

Można ponownie użyć cały system programów

użytkowych przez włączenie go w niezmienionej

postaci do innych systemów.

• Użycie wielokrotne komponentów

Można

wielokrotnie

używać

komponentów

programu użytkowego mających różne rozmiary,

od podsystemów do pojedynczych obiektów.

• Użycie wielokrotne funkcji

Można

wielokrotnie

użyć

komponenty

programowe, takie jak pojedyncze funkcje

matematyczne.

Praktyka

• Użycie wielokrotne systemów programów

użytkowych praktykuje się już od wielu lat –
firmy

budujące

oprogramowanie

implementują swoje systemy na wielu
maszynach i dostosowują je do rozmaitych
środowisk.

• Użycie wielokrotne funkcji również jest

uznane i występuje w postaci standardowych
bibliotek funkcji użycia wielokrotnego, takich
jak biblioteki matematyczne i graficzne.

Zalety użycia wielokrotnego

• Zwiększona niezawodność
• Zmniejszone zagrożenie procesu
• Efektywne wykorzystanie

specjalistów

• Zgodność ze standardami
• Przyspieszone tworzenie

Wymagania stawiane

projektowaniu i budowaniu

oprogramowania z użyciem

wielokrotnym

• Musi

istnieć

możliwość

znalezienia

odpowiedniego

komponentu

użycia

wielokrotnego.

• Osoba ponownie używająca komponent musi

być przekonana, że będzie on działał zgodnie
ze specyfikacją i będzie niezawodny.

• Komponenty muszą mieć dokumentację,

która

pomoże

osobie

pragnącej

je

wykorzystać

w

zrozumieniu

ich

i

zaadaptowaniu do nowych zastosowań.

• Zwiększone koszty pielęgnacji

• Brak wspomagania narzędziowego

• Syndrom „nie wymyślono tutaj”

• Prowadzenie biblioteki komponentów

• Znajdowanie i adaptowanie

komponentów użycia wielokrotnego

Problemy z użyciem

wielokrotnym

• Polega ono na umieszczaniu wielokrotnie

używanej wiedzy w systemie generowania

programów, który może posługiwać się

językiem

specyficznym

dla

dziedziny

zastosowania.

• W opisie programu użytkowego w abstrakcyjny

sposób określa się, które komponenty użycia

wielokrotnego mają być wykorzystane.

• Na

podstawie

tej

informacji

można

wygenerować

działający

system

oprogramowania.

Generowanie jako podejście do

tworzenia komponentowego z

użyciem wielokrotnym

Użycie wielokrotne oparte na

generatorze

Typy generatorów:

• Generatory programów użytkowych do przetwarzania danych
gospodarczych

• Generatory analizatorów składniowych do przetwarzania
języków

• Generatory kodu w narzędziach CASE

Generator programów

Generator programów

Wygenerowany program

Wygenerowany program

Wiedza o dziedzinie

zastosowania

Wiedza o dziedzinie

zastosowania

Baza danych

Baza danych

Opis
programu

użytkowego

Tworzenie komponentowe

• Tworzenie

komponentowe

albo

komponentowa

inżynieria

oprogramowania

pojawiła

się

we

wczesnych

latach

dziewięćdziesiątych XX wieku w postaci podejścia do budowania
systemów oprogramowania z użyciem wielokrotnym.

• Przyczyną jej powstania było rozczarowanie faktem, że tworzenie

obiektowe nie doprowadziło do szerokiego stosowania użycia
wielokrotnego, jak się wcześniej spodziewano.

• Poszczególne klasy obiektów były zbyt szczegółowe i specyficzne.
• Musiały być dowiązane do programu użytkowego w czasie

kompilacji lub konsolidacji systemu.

• Do ich wykorzystania była potrzebna szczegółowa wiedza, co

zwykle oznaczało konieczność udostępnienia kodu źródłowego.
Powodowało to trudne problemy ze sprzedażą komponentów na
rynku.

• Wbrew wczesnym optymistycznym przewidywaniom nigdy nie

powstał znaczący rynek pojedynczych obiektów.

Tworzenie komponentowe c.d.

• Postrzeganie komponentu jako dostawcy usług

dotyczy

dwóch

istotnych

charakterystyk

komponentu użycia wielokrotnego.

• Komponent jest niezależnym wykonywalnym

bytem. Kod źródłowy nie jest dostępny, a zatem

komponentu nie kompiluje się z innymi

komponentami systemu.

• Komponenty publikują swój interfejs. Wszystkie

interakcje odbywają się przez ten interfejs.

Interfejs komponentu jest zapisywany w

kategoriach parametryzowanych operacji. Jego

wewnętrzny stan nigdy nie jest ujawniany.

Interfejsy komponentów

• Interfejs oferowany

– Definiuje się usługi oferowane przez ten

komponent.

• Interfejs wymagany

– Określa się, jakie usługi muszą być dostępne w

systemie używającym tego komponentu. Jeśli nie

są one oferowane, to komponent nie będzie działał.

Komponent

Interfejs wymagany Interfejs oferowany

Komponent usług drukarskich

Komponent usług
drukarskich

PodajPlikOpisu

Interfejsdrukarki

Drukuj

PodajStanKolejki

Usuń

Przekaż

Rejestruj

Wyrejestruj

Interfejs wymagany Interfejs oferowany

Poziomy abstrakcji

komponentów

• Abstrakcja funkcyjna.

– Komponent jest implementacją jednej funkcji,

np. matematycznej.

• Przypadkowe grupowanie.

– Komponent jest grupa luźno powiązanych bytów.

• Abstrakcja danych

– Komponent jest abstrakcją danych lub klasą

obiektowego języka programowania.

• Abstrakcja grupowa.

– Komponent jest grupą powiązanych klas, które

działają razem.

• Abstrakcja systemowa.

– Komponent jest całym samodzielnym systemem.

Tworzenie z wielokrotnym

użyciem

Projektowanie

architektoniczne

Projektowanie

architektoniczne

Poszukaj

komponentów użycia

wielokrotnego

Poszukaj

komponentów użycia

wielokrotnego

Zaprojektuj system

korzystając

z komponentów

użycia wielokrotnego

Zaprojektuj system

korzystając

z komponentów

użycia wielokrotnego

Naszkicuj

wymagania

systemowe

Naszkicuj

wymagania

systemowe

Poszukaj

komponentów użycia

wielokrotnego

Poszukaj

komponentów użycia

wielokrotnego

Na podstawie wyników

poszukiwań zmień

wymagania

Na podstawie wyników

poszukiwań zmień

wymagania

Trudności przy tworzeniu

komponentowym

• Kod źródłowy komponentów jest zwykle

niedostępny. W takiej sytuacji, gdy

program użytkowy wymaga modyfikacji,

nie ma możliwości zmiany komponentu

mającej na celu odzwierciedlenie tych

wymagań.

• Zmiana wymagań tak, by pasowały do

istniejących komponentów, może być

niemożliwa.

Użycie wielokrotne produktów

COTS

• Pojęcie produktów COTS (Commercial-Off-

The-Shelf – komercyjne z półki) może być
zastosowane do każdego komponentu
oferowanego przez zewnętrznego dostawcę.

• Zwykle używa się go jednak tylko w

wypadku produktów będących systemami
oprogramowania.

• Od

wielu

lat

wielokrotnie

używano

niektórych rodzajów systemów COTS.
Systemy baz danych są chyba najlepszym
tego przykładem.

Tworzenie komponentów użycia

wielokrotnego

• Komponenty użycia wielokrotnego są specjalnie

budowane z istniejących komponentów.

• Cechy komponentu świadczące o jego zdatności

do użycia wielokrotnego:

– komponent powinien odzwierciedlać stabilną

abstrakcję dziedzinową,

– komponent musi ukrywać sposób reprezentacji

swoich danych i oferować operacje

umożliwiające odczyt i aktualizację jego stanu,

– komponent powinien być tak niezależny, jak to

tylko jest możliwe,

– wszystkie wyjątki powinny być częścią

interfejsu komponentu.

Problemy

• W wielu obecnie dostępnych systemach

istnieją

duże

fragmenty

kodu,

które

implementują abstrakcje dziedzinowe, ale nie

mogą być wykorzystane jako komponenty.

• Przyczyna leży w tym, że nie opakowano ich

zgodnie z modelem z jasno określonymi

interfejsami wymaganym i oferowanym.

• Uczynienie z nich komponentów użycia

wielokrotnego zwykle wymaga zbudowania

osłony.

• Osłona ukrywa złożoność schowanego kodu i

oferuje zewnętrzne

Uzdatnianie komponentów

• Między zdatnością do użycia wielokrotnego a użytecznością

komponentu występuje nieuchronny konflikt.

• Uzdatnienie komponentu do użycia wielokrotnego pociąga

za sobą zaoferowanie bardzo ogólnego interfejsu z

operacjami obsługującymi rozmaite sposoby użycia tego

komponentu.

• Budowa użytecznego komponentu obejmuje zaoferowanie

prostego, minimalnego interfejsu, który jest łatwy do

zrozumienia.

• Zdatność do użycia wielokrotnego zwiększa złożoność, a

zatem zmniejsza zrozumiałość komponentu.

• Inżynierom jest więc trudno zdecydować, kiedy i jak

wielokrotnie używać komponentu.

• Projektanci komponentów użycia wielokrotnego muszą

zatem wypracować kompromis między ogólnością a

zrozumiałością.

Architektura

• Osiągnięcie

znaczącej

zdatności

do

użycia

wielokrotnego

wymaga

zaprojektowania

architektury, w której zasadnicze udogodnienia

systemowe będą oddzielone od szczegółowej

informacji

o

zasobach,

które

mają

być

inwentaryzowane i od dostępu użytkownika do tych

informacji.

• Architektura może spełniać te wymagania dzięki

zastosowaniu architektury warstwowej, w której

warstwa szczegółów zawiera opisy zasobów,

wyświetlane ekrany i tworzone raporty.

• Wyższe warstwy systemu korzystają z tych opisów i

nie obejmują wpisanej na sztywno informacji o

zasobach. Różne systemy inwentaryzacyjne powstają

przez modyfikację tej warstwy opisowej.

Zręby programów użytkowych

•

Zręby (lub zręby programów użytkowych) są projektami

podsystemów składających się z kolekcji klas

abstrakcyjnych i klas konkretnych oraz interfejsu

między nimi.

•

Poszczególne części systemu programów użytkowych

implementuje się przez dodanie komponentów i

opracowanie

konkretnych

implementacji

klas

abstrakcyjnych zrębu.

•

Zręby rzadko są programami użytkowymi.

•

Zrąb jest uniwersalną strukturą, którą można

rozszerzyć w celu stworzenia bardziej specyficznego

programu użytkowego. Ma on zastosowanie w procesie

tworzenia

obiektowego,

gdzie

można

się

nim

posługiwać zamiast pojedynczymi obiektami.

•

Rozszerzenie zrębu może polegać na dodaniu

konkretnych klas, które dziedziczą operacje po klasach

abstrakcyjnych zrębu.

Klasy zrębów

• Zręby infrastruktury systemów

– Wspomagają

tworzenie

infrastruktury

systemów,

takiej

jak

komunikacja,

interfejsy użytkownika i kompilatory.

• Zręby integracji śródprogramów

– Składają się ze zbioru standardów i

związanych z nimi klas obiektów, które

wspomagają komunikację komponentów i

wymianę informacji.

• Zręby zastosowań przemysłowych

– Dotyczą

specyficznych

dziedzin

zastosowań, takich jak telekomunikacja

lub finanse.

Przykład:

zrąb Model-Widok-Koordynator

• Po raz pierwszy przedstawiono go w latach

osiemdziesiątych XX wieku jako podejście

do projektowania graficznego interfejsu

użytkownika.

• Zrąb MVC pomaga w prezentacji danych

na różne sposoby i odrębne oddziaływanie

z każdą z nich.

• Gdy dane są modyfikowane przez jedna

prezentację,

wszystkie

inne

są

aktualizowane.

Zrąb Model-Widok-Koordynator

Stan widoku

Metody widoku

Stan modelu

Metody modelu

Stan koordynatora

Metody koordynatora

Zapytania
i
aktualizacj
e
modelu

Modyfikacje
modelu

Komunikaty o
modyfikacji
widoku

Inżynieria

oprogramowania

Wykład 14 –

wzorce projektowe.

Prezentacja częściowo oparta na prezentacji przygotowanej przez Bartosza Waltera (UW)

Idea

• Dążenie do jednolitości rozwiązań,

ich klasyfikacji i uproszczenia.

• Czy można zapisać rozwiązanie

jakiegoś problemu w sposób ogólny,
abstrahując od szczegółowych
rozwiązań? Pozwoliłoby to ująć tzw.
dobre praktyki w postaci szablonów,
które można stosować wielokrotnie,
unikając typowych błędów.

Geneza

• Wzorce projektowe wywodzą się z architektury. Twórcą

tego pojęcia jest amerykański architekt, Christopher

Alexander, który postawił tezę, że piękno,

funkcjonalność oraz inne cechy użytkowe lub

konstrukcyjne można zapisać właśnie w postaci

uogólnionych rozwiązań.

• Zdaniem Aleksandra, każdy wzorzec powinien być

opisany przez następujące atrybuty:
- układ sił działających na niego: czyli środowisko i jego

wpływ
- rozwiązanie: schemat konstrukcji, która uwzględnia

działające siły, równoważy je i oferuje najlepsze

osiągnięcie celu przy założonych czynnikach
- kontekst: opis warunków, w których rozwiązanie

można zastosować

• Taki wzorzec jest gotowym schematem postępowania,

który można zastosować w wielu sytuacjach, łącząc go

także z innymi wzorcami.

Wzorce projektowe w

informatyce

• E. Gamma, R. Helm, R.Johnson i J. Vlissides, znani jako

Banda Czterech (Gang of Four) - Design Patterns (Wzorce
projektowe) -1995

• W swojej książce opisali 24 wzorce projektowe dotyczące

konstrukcji, struktury i zachowania obiektów w systemach
informatycznych. Ich zdaniem, poziom abstrakcji wzorca
projektowego powinien znajdować się powyżej poziomu
pojedynczej klasy.

• Od tego czasu wzorce projektowe stały się jednym z

podstawowych narzędzi projektowania systemów.

• Powstały nowe, specjalizowane wzorce poświęcone

rozwiązaniom dla konkretnych technologii czy platform (np.
wzorce dla J2EE).

Klasyfikacja wzorców w

inżynierii oprogramowania

• wzorce architektoniczne – poziom

integracji komponentów.

• wzorce projektowe – poziom interakcji

między klasami.

• wzorce analityczne – poziom opisu

rzeczywistości.

• wzorce implementacyjne – poziom języka

programowania.

Klasyfikacja wzorców

projektowych

• Kreacyjne (konstrukcyjne)

-opisują elastyczne sposoby tworzenia obiektów
-uniezależniają system od sposobu tworzenia obiektów
-wykorzystywane do pozyskiwania obiektów zamiast
bezpośredniego tworzenia instancji klas

• Strukturalne

-pomagają łączyć obiekty w większe struktury
-opisują sposób konstrukcji struktur obiektowych
-korzystają z dziedziczenia i delegacji

• Czynnościowe (behawioralne)

-opisują algorytmy i przydział odpowiedzialności
-służą do zdefiniowania komunikacji pomiędzy obiektami
oraz kontrolowania przepływu danych w złożonej aplikacji

• nazwa – lakoniczny opis istoty wzorca

• klasyfikacja – kategoria, do której

wzorzec należy

• cel – przeznaczenie wzorca

• aliasy – alternatywne nazwy wzorca

• motywacja – scenariusz opisujący

problem i jego rozwiązanie

• zastosowania – sytuacje, w których

wzorzec jest stosowany

• struktura – graficzna reprezentacja klas

składowych wzorca

Szablon wzorca projektowego

• uczestnicy – nazwy i zakres

odpowiedzialności uczestników wzorca

• współdziałanie – opis współpracy między

uczestnikami

• konsekwencje – efekty zastosowania wzorca
• implementacja – opis implementacji wzorca

w danym języku

• przykład – kod stosujący wzorzec
• pokrewne wzorce – wzorce używane w

podobnym kontekście

Szablon wzorca projektowego

(c.d.)

Moduły w systemie bibliotecznym:

• katalogi, przechowujące informacje o zbiorach

biblioteki, i porządkujące je według wybranego

kryterium

• karty książek, które reprezentują poszczególne

egzemplarze książki i które są przechowywane

w katalogach

• karty czytelników, służące do przechowywania

danych o czytelnikach: ich danych osobowych,

historii rezerwacji, wypożyczeń etc.

• mechanizm kontaktu z czytelnikiem,

pozwalający dowiadywać się o stanie

rezerwacji, nowościach w bibliotece etc.

Przykład - biblioteka

Katalog rzeczowy

Wymagania:
• struktura hierarchiczna kategorii oznaczonych
cyframi
• nieograniczone możliwości rozwoju
• łatwość wyszukiwania
• możliwość zmiany położenia książki

(Struktura katalogów: autorskiego i alfabetycznego jest intuicyjnie zrozumiała)

Rozwiązanie: Drzewo

• Interfejs Przeszukiwalny posiada dwie implementacje: Kategorię
(która jest związana relacją agregacji z dowolną liczbą obiektów
zależnych typu Przeszukiwalny, a zatem zarówno innych Kategorii,
jak i Książek) oraz Książkę (reprezentującą element struktury, który
nie posiada obiektów zależnych).

• Obiekt klasy Katalog rzeczowy, który wywoła metodę szukaj() w
kategorii
znajdującej się w korzeniu drzewa katalogu, nie musi znać struktury
tego drzewa, jego głębokości ani innych własności.

• Każda Kategoria, po wywołaniu jej metody szukaj(), realizuje ten
sam algorytm: wykonuje wyszukiwanie na własnym obiekcie, a
następnie wywołuje tę samą metodę na każdym jej obiekcie
zależnym, co powoduje rekurencyjne przeszukanie drzewa w głąb.

Wspólny interfejs o nazwie
Przeszukiwalny jest
implementowany
we wszystkich obiektach, które
są
częścią struktury i w których
można
szukać książek.

Wzorzec Composite (Kompozyt)

• Komponent

– deklaruje wspólny interfejs dla obiektów znajdujących się w strukturze
– implementuje wspólną funkcjonalność wszystkich obiektów

• Liść

– reprezentuje węzeł bez potomków

• Kompozyt

– reprezentuje węzeł z potomkami
– przechowuje referencje do potomków
– deleguje otrzymane polecenia do potomków

Wzorzec Composite –

podsumowanie

• Określa metodę konstrukcji hierarchicznych struktur,

którymi można zarządzać poprzez jeden węzeł – korzeń.

Dzięki temu podstawowe operacje, takie jak

wyszukiwanie elementów, nie wymagają żadnej wiedzy o

strukturze drzewa.

• Popularność tego wzorca wynika z oferowanej przez

niego możliwości elastycznego zarządzania złożonymi

strukturami. Ponadto wszystkie elementy struktury

realizują ten sam algorytm, co ułatwia ich testowanie.

• Mechanizm ten jest jednym z najczęściej

wykorzystywanych wzorców projektowych, np. w

systemach okienkowych. Strukturę drzewiastą tworzą

wówczas składowe okienek: przyciski, etykiety, listy etc.

Przesunięcie okienka na ekranie powoduje automatyczne

przesunięcie wszystkich jego elementów.

• Zalety: elastyczna definicja struktur drzewiastych, proste

dodawanie nowych komponentów, proste i spójne

zarządzanie strukturą o dowolnej liczbie elementów

Karty czytelników

Wymagania:
• istnieją trzy rodzaje kart czytelnika: Standard,

Junior i Senior

• karta może zmieniać swój typ
• typ karty określa zachowanie karty czytelnika (np.

wysokość opłaty za korzystanie z biblioteki i
wysokości kar za nieterminowy zwrot książek.

• istnieją trzy typy kart, lecz liczba ta może ulec

zmianie w przyszłości

Rozwiązanie 1: podklasy

Wady i zalety rozwiązania:
(+) pozwala na dziedziczenie metod i ich pokrywanie.
(–) uniemożliwia dodanie nowego typu karty bez

rekompilacji kodu.

(–) uniemożliwia prostą zmianę typu karty (trzeba by

usuwać obiekt z jednoczesnym utworzeniem
nowego przy przepisaniu atrybutów).

Rozwiązanie 2: delegacja

• Rozdzielenie odpowiedzialności Karty Czytelnika na

część przechowującą dane i część reprezentującą

stan.

• Część przechowująca dane, nadal nazywana Kartą

Czytelnika, posiada referencję do obiektu

reprezentującego aktualny typ, dziedziczącego po

klasie abstrakcyjnej lub implementującej interfejs.

• Dzięki temu zmiana typu karty wymaga jedynie

utworzenia instancji innej klasy Typ Karty i

przypisanie jej do Karty Czytelnika.

Wzorzec State (Stan)

• Kontekst

– posiada referencję do obiektu reprezentującego bieżący stan

• Stan abstrakcyjny

– definiuje interfejs pozwalający hermetyzować zachowanie

związane z każdym stanem

• Stan konkretny

– definiuje własne metody implementujące zachowanie

specyficzne dla tego stanu

Wzorzec State: podsumowanie

• Podział zachowania obiektu wg stanów

– kod związany z jednym stanem jest zapisany w

jednym obiekcie

• Zmiana stanu jest realizowana przez zmianę

obiektu stanu na inny

• Zastosowanie wzorca pozwala modyfikować

zachowanie obiektów tak, jakby zmieniała się ich

klasa – i to jest najważniejszy cel i skutek

• Ochrona przed stanem niespójnym

• Możliwość współdzielenia obiektów

– obiekty zwykle definiują tylko zachowanie
– obiekty zwykle są bezstanowe

Książki

Wymagania
• Docelowa liczba książek jest nieograniczona
• Każda książka posiada swoją kartę
• Książka może składać się z wielu tomów, które mogą być

wypożyczane pojedynczo, niezależnie od innych tomów

• możliwe jest wykonywanie zapytań na liście książek
• umiarkowana złożoność pamięciowa

Rozwiązanie 1: 1 książka = 1

obiekt

Wady i zalety:
(+) intuicyjne i łatwe przetwarzanie
(–) gigantyczne zapotrzebowanie na pamięć
(–) ograniczenia wydajnościowe
(–) nieracjonalne wykorzystanie zasobów

Rozwiązanie 2: anonimowe książki

Przechowujemy obiekty nieaktywne, wymagające inicjacji

przed przekazaniem Klientowi. Dane charakteryzujące obiekt

są w razie potrzeby odczytywane z bazy danych. Klient

otrzymuje więc obiekt dokładnie taki, jakiego oczekuje, bez

niepotrzebnego zużycia zasobów.

Wady i zalety:
(+) ograniczone użycie pamięci z racjonalnym zarządzaniem
(+) niejawne konfigurowanie obiektów danymi instancji
(+) ograniczona liczba jednocześnie wykorzystywanych obiektów

Wzorzec Flyweight (Waga piórkowa)

• Obiekt

– podlega

współdzieleniu między

klientów
– definiuje interfejs do

przyjmowania i

odtwarzania stanu

zewnętrznego obiektu
– przechowuje stan

wewnętrzny

(współdzielony)
– jest niezależny od

kontekstu (z wyjątkiem

stanu zewnętrznego)

• Fabryka obiektów

– tworzy i przechowuje

obiekty

Wzorzec Flyweight:

podsumowanie

• Zmniejszenie wymagań pamięciowych programu

– zmniejszenie ogólnej liczby obiektów
– stan zewnętrzny może być przechowywany lub

wyliczany

• Wzrost złożoności obliczeniowej

– dodatkowy nakład mocy na zarządzanie stanem

zewnętrznym

Rozwiązanie 3: wzorzec Pool of Objects (pula obiektów)

- pula aktywnych obiektów, które definiują swój czas

życia

- klient otrzymuje obiekt za pośrednictwem puli obiektów

- posiada dużą wadę: jest stosowalny do obiektów

nierozróżnialnych

Kontakt z czytelnikiem

Wymagania
• powiadamianie o stanie rezerwacji
• powiadamianie o nowych książkach
• Czytelnik może zarezerwować książkę, która aktualnie jest

niedostępna. Informacja o dostępności książki zostanie
wysłana do czytelnika natychmiast po jej zwrocie przez
poprzedniego czytelnika

Rozwiązanie 1: okresowe

odpytywanie

Wady i zalety:
(+) intuicyjna metoda uzyskiwania informacji
(–) wymaga ciągłej aktywności czytelnika
(–) absorbuje zasoby po stronie Biblioteki

Rozwiązanie 2: powiadamianie

Wady i zalety:
(+) Biblioteka powiadamia tylko gdy nastąpiła zmiana stanu

rezerwacji

(+) brak obciążenia czytelnika

(zasoby po stronie Biblioteki są angażowane jedynie w

momencie rzeczywistej zmiany stanu, a Czytelnik nie jest

przez tę operację absorbowany w żaden sposób)

Wzorzec Observer (Obserwator)

• Podmiot
– utrzymuje rejestr
Obserwatorów
– umożliwia dołączanie i
odłączanie Obserwatorów
– powiadamia Obserwatorów o
zmianie swojego stanu
• Obserwator
– posiada interfejs służący do
powiadamiania o zmianach
– aktualizuje swój stan na
podstawie powiadomienia

Wzorzec Observer: podsumowanie

• Luźniejsze powiązania pomiędzy

obiektami:
– Podmiot komunikuje się z innymi

obiektami przez interfejs Obserwatora
– Podmiot i Obserwatorzy mogą należeć do

różnych warstw abstrakcji

• Programowe rozgłaszanie komunikatów

• Spójność stanu Podmiotu i Obserwatorów

• Czasem używa się nazwy wzorca: Listener

Dostęp do bazy danych

• Każde łączenie się z bazą jest dla aplikacji

kosztowne, bo wymaga czasochłonnego

uwierzytelnienia i autoryzacji.

• W tym przypadku sensowniej jest stworzyć

jeden obiekt przechowujący sesję

połączenia i wykorzystać go do przesłania

wielu zapytań.

• Istnieje zatem potrzeba stworzenia klasy,

która posiadałaby wyłącznie jedną

instancję

Rozwiązanie: Wzorzec Singleton

• Tworzymy klasę, która posiada statyczną metodę, która najpierw

sprawdza, czy istnieje już instancja tej klasy - jeśli nie istnieje to
tworzy ją - i następnie zwraca ją przez referencję. Instancja klasy
jest przechowywana w prywatnym lub chronionym, statycznym
polu, do którego dostęp ma tylko opisana wyżej metoda. Owa
metoda dostępowa jest jedyną drogą pozyskania instancji obiektu
singletonu - aby uniemożliwić tworzenie dodatkowych instancji w
zwykły sposób, czyli przez wywołanie konstruktora, deklaruje się
go jako prywatny lub chroniony.

• Dodatkową korzyścią z zastosowania takiego rozwiązania jest to,

że cały proces jest niewidoczny dla użytkownika i nie musi on
wiedzieć, czy instancja istnieje czy też nie.

Wzorce projektowe –

podsumowanie

• Wzorce projektowe są abstrakcyjnymi rozwiązaniami

powtarzających się problemów

• Każdy wzorzec posiada określony zbiór atrybutów

• Wzorce pozwalają efektywnie rozwiązywać problemy

projektowe

• Są jednym z podstawowych narzędzi projektowania systemów

• Nie należy ich jednak traktować jako gotowe recepty do

bezpośredniego wykorzystania w dowolnym problemie – często

wymagają dostosowania do konkretnego problemu

• Antywzorce – przykłady wzorców postępowania lub

projektowania, których należy unikać

• Krytyka wzorców projektowych:

- Wzorzec musi zostać zaimplementowany dla każdego nowego

zastosowania. Krok wstecz w stosunku do stosowania

komponentów?
-Podejście nie różni się zbytnio od innych form abstrakcji, np.

od paradygmatu Model-Widok-Sterownik, który istniał

wcześniej

Zestawienie podstawowych wzorców

projektowych (polskie nazewnictwo)

Wzorce konstrukcyjne
* Fabryka abstrakcyjna
* Budowniczy
* Metoda fabrykująca
* Prototyp
* Singleton

Wzorce strukturalne
* Adapter
* Most
* Kompozyt
* Dekorator
* Fasada
* Pośrednik
* Waga piórkowa

Wzorce czynnościowe
* Łańcuch odpowiedzialności
* Polecenie
* Interpretator
* Iterator
* Mediator
* Obserwator (Słuchacz)
* Stan
* Strategia
* Metoda szablonu
* Wizytator (Odwiedzający)

Przykład wzorca projektowego: XMLPatterns.com Flyweight

Abstract: If the same information is included at many different points in a document the information can be placed in just one place,

and shared from each place in the document that needs to refer to it.

Problem: Placing the same information in many different place can cause several problems: a) Mistakes can be made in copying the

information. b) If the data changes, all occurrences of the information must be located and changed. This makes maintenance of
the document difficult. c) Documents can become quite large if the same information is repeated over and over again.

Context: This is a very general pattern, almost any document type can make use of it. This pattern can be used anywhere where the

same information must be repeated more than once in a document. The repeated data can occur in the document declaration, or
in the document instance itself.

Forces: This pattern can effect the length of the document, maintainability, and readability of the document.
Solution: Place the shared information in just one place, and make references to it from every place in the document that needs to

include this information. There are several ways to do this: a) Use XML Entity Declarations. These provide a way to do text
substitutions inside of a document. The XML Specification Section 4.2 Entity Declarations (http://www.w3.org/TR/REC-xml#sec-
entity-decl) b) Use the XLink attribute xlink:show="embed". This technique has the advantage of using a standard, so some tools
may be available to do the processing. This is defined in The W3C's XML Linking Language Specification
(http://www.w3.org/TR/xlink/#link-behaviors) c) Use ID and IDREF attributes. A reference can be made to an entity via an IDREF
attribute. Applications processing this will need to do the processing to do this type of Flyweight. See the Examples section for an
example of each of the above techniques.

Examples
XML Entities: This example shows how XML Entities can be used to put a piece of information in just one place, and then have it

appear in multiple places in the document. <!DOCTYPE Doc[ <!ENTITY TITLE "My Document"> ]> <Document>
<title>&TITLE;</title> <H1>&TITLE;</H1> This is my paragraph. </Document>

XLink: This document shows the use of XLink attributes to include the contents of a document in two different places. Since XLink is

a standard it is possible that existing tools could be used to do the substitution. <Document> <title> <include
xlink:show="embed" xlink:href="titledoc.txt"/> </title> <h1> <include xlink:show="embed" xlink:href="titledoc.txt"/> </h1>
This is my paragraph. </Document>

ID and IDREF: This shows how ID and IDREF attributes can be used as a Flyweight. Note thats this would require some extra work on

the part of the processing software to do the substitution. <Document> <text id="title">My Document</text> <title
IDREF="title"/> <h1 IDREF="title"/> </Document>

Discussion: This pattern can greatly enhance the maintainability of a document, if the same data is repeated several times, and that

data changes, every occurrence of that data must be found and updated. This can be a tedious and error prone task. Having the
data in only one place allows all occurrences of it to be changed at once. The Flyweight pattern should not be used if the shared
information can vary over time. This would increase the maintenance burden of the document. Readability of the document can
suffer if the Flyweight pattern is used, readers are forced to reference a different section of the document when looking at the
contents.

Related Patterns: See Declare Before First Use for suggestions on where to place the shared information.
Known Uses: a)XHTML uses a a common attributes parameter entity that is a Flyweight. b) The XML & SGML Cookbook page 1-126

mentions the Flyweight pattern.