Inżynieria
oprogramowania

Wykład I. Wprowadzenie

Politechnika Radomska

Literatura

Andrzej Jaszkiewicz „Inżynieria

oprogramowania” Helion 1997
Grady Booch, James Rumbaugh, Ivar

Jacobson „UML – przewodnik

użytkownika”, seria inżynieria

oprogramowania, Wydawnictwo

Naukowo-Techniczne 2002
Martin Flower, Kendal Scott „UML w

kropelce” LTP Warszawa 2002

O czym będzie

Złożoność oprogramowania, cykl
życia aplikacji,
Dlaczego modelujemy ? Znaczenie
i zasady modelowania
Modelowanie obiektowe
Historia powstania UML

Złożoność

oprogramowania

jak pokazuje wykres
zależność między wielkością,
a złożonością programu nie
jest liniowa – stworzenie 2
razy większej aplikacji nie
zajmuje 2 razy więcej czasu,
lecz trwa dłużej
istnieje pewna graniczna
wielkość programu, po której
przekroczeniu człowiek
przestaje panować nad jego
złożonością

wielkość

zł

o

żo

n

o

ść

Zależność między wielkością
i złożonością programu

Pokonanie problemu

złożoności

Istnieje jakieś rozwiązanie problemu skoro istnieje
wiele bardzo złożonych i skomplikowanych
aplikacji, które całkiem nieźle działają.
Nie możemy pokonać złożoności problemu –
ponieważ użytkownicy żądają coraz lepszych
(bardziej złożonych aplikacji), ale możemy
budować aplikacje z małych części.
Tworzymy zatem stosunkowo małe moduły,
sprawdzamy je i testujemy, a gdy okażą się
niezawodne, łączymy je w większą całość.

Cykl życia aplikacji

Analiz

a

Projektowa

nie

Kodowa

nie

Testowan

ie

Eksploata

cja

Konserwa

cja

czas

E

ta

p

y

t

w

o

rz

e

n

ia

a

p

lik

a

cj

i

Analiza

definiowanie i zrozumienie problemu
określenie czy do rozwiązania problemu
niezbędny jest komputer
oszacowanie niezbędnych środków (wielkość
zespołu programistów, twórców dokumentacji,
ilość komputerów

Rezultatem analizy powinna być
specyfikacja systemu, zawierająca opis
wszystkich jego funkcji

Projektowanie

tworzymy szczegółowy projekt każdego
rozwiązania
opisujemy zależności między modułami
określamy kolejność wywoływania procedur
projektujemy wygląd formularzy i postać raportów

wszystkie elementy konsultujemy z
zamawiającym (zwykle wielokrotnie aż do
zaakceptowania przez niego naszych
propozycji)

Kodowanie

Stworzenie programu na bazie
projektu (jeśli jest on dobrze
wykonany to jest to program „pisze się
sam”)
Ta faza właściwie się nigdy nie kończy
(trwa przez cały czas życia aplikacji),
gdyż każda zmiana i poprawka w
programie będzie wymagała zmiany
kodu źródłowego programu

Testowanie

głównym celem testowania jest sprawdzenie,

czy stworzony przez nas produkt spełnia

określone wcześniej założenia. Każdą funkcję

powinniśmy skonfrontować z założeniami
testowanie odbywa się zwykle w 2 krokach:

– testowanie poszczególnych modułów (unit

testing) – sprawdzanie poprawności działania

modułów składających się na aplikację

– testowanie całości (integration testing) –

sprawdzenie czy moduły poprawnie współpracują

i komunikują się ze sobą

Eksploatacja,

konserwacja

konserwacja aplikacji to zwykle około 80%

czasu jaki jej poświęcamy
uzupełniamy program o nowe (drobne) funkcje

(„zachcianki klientów”)
usuwamy niezaplanowane funkcje (błędy)

programu
nadzorujemy eksploatację programu

na tym etapie zwraca się wysiłek włożony w

tworzenie założeń, specyfikacji, projektu, opisu

kodu źródłowego czy instrukcji obsługi

Sukces

producenta

oprogramowania

Konsekwentne wdrażanie wyrobów wysokiej jakości
Wyroby spełniają oczekiwania użytkowników
Programy są dostarczone na czas
W trakcie tworzenia oprogramowania efektywnie

wykorzystuje się zasoby ludzkie i sprzętowe
Wynikiem pracy programistów nie są piękne

dokumenty, konferencje na wysokim

poziomie, hałaśliwe slogany, czy piękne

wiersze kodu. Są nimi dobre programy

spełniające zmienne wymagania

użytkowników i przedsiębiorstw. Wszystko

inne ma drugorzędne znaczenie.

Warunki wytworzenie

oprogramowania dobrej

jakości

We wdrożeniu i projektowaniu oprogramowania muszą

brać udział jego użytkownicy – pomogą odkryć

rzeczywiste wymagania stawiane systemowi
System powinien mieć solidną podstawę

architektoniczną, którą można elastycznie modyfikować
Trzeba dysponować właściwym zespołem ludzi i

odpowiednimi narzędziami
Wszystkie działania powinny być spójne i

przewidywalne – zaplanowane!!!; powinny

uwzględniać przyszłe koszty pielęgnacji systemu, rozwój

aplikacji powinien być taki by można go było

dostosować do zmiennych technologii i potrzeb

przedsiębiorstwa

Dlaczego modelujemy ?

Modelowanie to najważniejsza czynność,

która sprzyja wytworzeniu dobrego

oprogramowania.

Modele opracowujemy po to, by

wyrazić pożądaną strukturę i zachowanie systemu
zobrazować architekturę systemu i panować nad

nią
lepiej zrozumieć budowany system (często

przedstawiamy też możliwości jego uproszczenia

bądź ponownego użycia)
lepiej zarządzać ryzykiem

Znaczenie modelowania

Psia buda – deski i gwoździe zabieramy się do roboty
Dom dla rodziny – zazwyczaj przygotowujemy plany ,

konsultujemy i zgodność z lokalnym prawem,

szacujemy koszty, liczmy czas trwania projektu, itd..

(chyba że ktoś już zbudował setki takich domów)
Wielopiętrowy biurowiec - inwestorzy chcą mieć

wpływ na kształt i styl projektu, często zmieniają

zdanie (zwykle gdy budowa idzie pełna parą) .

Staranne planowanie jest nieodzowne – koszt

niepowodzenia jest bowiem bardzo wysoki. Potrzebne

są zatem plany i modele do wewnętrznej komunikacji

między członkami zespołu.

Szczęście

Wielu wytwórców oprogramowania próbuje
wznosić drapacze chmur metodami
przeznaczonymi do zbijania psiej budy.

Projekt mimo to może się udać gdy:

układ planet będzie korzystny
będziecie współpracować tylko z najlepszymi
ludźmi
wyeksploatujecie ich ponad miarę (zwiększenie
obciążenia pracą, jako reakcja na kryzys,
opóźnienie)

Właściwy cel

Nie jest nim napisanie olbrzymiej ilości kodu,
a wybór , bądź wytworzenie właściwego
kodu przy jego minimalnym rozmiarze.
Jest to możliwe tylko wówczas gdy
właściwie opracujemy architekturę
produktu i odpowiednio dobierzemy
narzędzia.
Wiele przedsięwzięć, które wyglądają na psie
budy rozrasta się z czasem do wielkości
drapacza chmur.

Czym jest model?

Model jest uproszczeniem rzeczywistości
Stosowanie modeli

budownictwo – plany, makiety
produkcja samochodów, samolotów – model

komputerowy, model aerodynamiczny, prototyp
urządzenia elektroniczne – schematy, prototypy
film – scenariusze
socjologia, ekonomia – weryfikacja teorii i

wypróbowanie nowych pomysłów przy

minimalnym ryzyku i kosztach

Po co budujemy modele?

By lepiej zrozumieć system, który budujemy:

łatwiej możemy wyobrazić sobie system

taki , jaki jest lub, jaki chcemy, żeby był,
modelowanie umożliwia wyspecyfikowanie

struktury i zachowania systemu
W wyniku modelowania otrzymujemy

szablony, które ułatwiają sterowanie

działaniami w trakcie tworzenia systemu
Modele stanowią dokumentację podjętych

decyzji

Modelowanie

złożonych systemów

Opracowujemy dlatego, że nie jesteśmy w
stanie objąć ich złożoności, ogarnąć tych
systemów w całości.
Możemy skupić się na jednym aspekcie systemu,
zawęzić problem. Trudne problemy atakujemy,
dzieląc je na mniejsze części, które potrafimy
rozwiązać.
Dzięki modelowi nie tracimy jednak widoku
całości i możliwa staje się praca na wyższym niż
osiągany tradycyjnymi metodami poziomie
abstrakcji

Zasady modelowania

Podjęcie decyzji, jakie modele tworzyć, ma

wielki wpływ na to, w jaki sposób zaatakujemy

problem i jaki kształt przyjmie rozwiązanie
Każdy model może być opracowany na różnych

poziomach szczegółowości
Najlepsze modele odpowiadają rzeczywistości
Żaden model nie jest wystarczający. Niewielka

liczba niemal niezależnych modeli to najlepsze

rozwiązanie w przypadku każdego

niebanalnego systemu.

Podejście do modelowania

W inżynierii oprogramowanie istnieją dwa
najważniejsze podejścia do tworzenia modeli:
algorytmiczne (podstawową
opracowywaną jednostką jest tu funkcja lub
procedura; programiści koncentrują się na
przepływie sterowania i podziale algorytmów
na mniejsze części) – powstałe systemy nie
są zazwyczaj odporne na zmiany wymagań
obiektowe – dominuje we współczesnych
metodach wytwarzania oprogramowania

Modelowanie obiektowe

Podstawowym elementem

konstrukcyjnym jest klasa lub obiekt.
Obiekt – rzecz pochodząca z dziedziny

problemu lub przestrzeni dopuszczalnych

rozwiązań
Klasa to zbiór obiektów o podobnych

cechach
Każdy obiekt ma przypisaną tożsamość,

stan i zachowanie

Przykład

Trójwarstwowa architektura systemu

rozliczeniowego: interfejs

użytkownika, powłoka pośrednia,

baza danych.
w interfejsie użytkownika: przyciski,

menu, okna dialogowe
baza danych: tabele
powłoka pośrednia: transakcje, reguły

działania przedsiębiorstwa

Historia UML

Przed 1975 -1989 pojawiają się pierwsze
języki modelowania obiektowego dla
rozwiązań dotyczących analizy i projektowania
1989-1994 – istnieje ponad pięćdziesiąt
metod projektowania obiektowego – nie mogą
być one jednoznaczną platformą
porozumiewania się projektantów. Trwa „wojna
metod’.
Zebrane doświadczenia umożliwiły
opracowanie nowej generacji metod

Historia UML. Przodkowie

UML.

Metoda Boocha – sprawdzała się podczas
projektowania i implementacji
Metoda OOSE (Object – Oriented software
Engineering) Jacobsona – stanowiła wsparcie
przy badaniu spełniania wymagań
Metoda OMT (Object Modeling Technique)
Rumbaugha – OMT2 okazywała się
przydatna do analizy oraz rozwijania
systemów przetwarzających duże ilości
danych

Przełom – unifikacja metod

Grady Booch (Rational Software Corporation),

Ivar Jacobson (Objectory) i James Rumbough

(General Electric) łączą i wzbogacają wspólnie

i unifikują opracowane przez siebie metody by
Modelować system obiektowo – odo

opracowania koncepcji do wytworzenia

gotowego produktu
Wskazać problemy związane ze zwiększeniem

skali złożonych systemów
Opracować język modelowania wygodny dla

ludzi i maszyn

Początek UML

1994 Roumbaugh przechodzi do Rational

Rose Co. I powstaje robocza wersja 0.8

nazwana UM (Unified Method)
1995 Jacobson dołącza do Rational Rose Co.

Co po dołąćzeniu jego metody do UM

doprowadziło do powstania dokumentacji

nazwanej UML (Unified Modelling Language)

w wersji 0.9 w czerwcu 1996
Powołane zostaje konsorcjum skłądające się z

wielu firm (Digital Equipment, HP, IBM< MS,

Oracle, Rational Rose...) promujące standard

UML – proces

standaryzacji

Styczeń 1997 UML 1.0 przekazany do Object

Managment Group (OMG) i oficjalnie

zaproponowany jako standard
Lipiec 1997 przedstawiono zmodyfikowaną wersję

1.1 i dopiero ta wersja została przez OMG ADTF

(Analysiis and Design Task Force ) zaakceptowana

jako standard (ostatecznie 14 listopada 1997)
W czerwcu 1998 OMG RTF (Revison Task Force)

dokonuje poprawek i przedstawia wersją UML 1.2
Jesienią 1999 publikuje wersję 1.3 o której będzie

mowa