INŻYNIERIA OPROGRAMOWANIA
3.10.2012r.
Prowadzący dr inż Marek Stansuzek, prof. PK, pokój 140a.
www.pk,edu.pl/~mareks
[e-mail]
Warunki zaliczenia:
-zaliczone laboratorium (40pkt.)
-egzamin testowy  test wielokrotnego wyboru, póz
niej egzamin ustny (60pkt.)
-dodatkowe punkty za aktwność w trakcie wykładu (3/wykład)
-skala ocen: 0-61-68-75-85-92
Inżynieria Oprogramowania stanowi wstęp do zarządzania projektami informatycznymi.
Jest to zbiór umiejętności, pojęć i procedur mających pomóc dobrze wykonywać pracę w tworzeniu
oprogramowania.
-dekompozycja  przejście do modelu dyskretnego (rozkład całości na elementy składowe)
-cykl życia oprogramowania
-odzwierciedlanie rzeczywistości w systemach informatycznych (na przykład przycisk do
wykonywania rozmów w telefonach cyfrowych odpowiada słuchawce telefonu analogowego)
System informatyczny to cyfrowy model kawałka rzeczywistości, tego kawałka który chcemy
modelować. Inżynieria oprogramowania to nauka o tych modelach.
Kryzys oprogramowania  oprogramwanie nie nadąża za rozwojem sprzętu i potrzebami. Nie ma
szans dopracować systemów informatycznych, kiedy ciągle zmienia się sprzęt, na których te
systemy pracują. Procedury tworzenia oprogramowania jest niejednoznaczny, wynika to z materii
jaką dysponujemy (każdy człowiek przetwarza informacje w inny sposób), informacja jest rzeczą
niematerialną, niejednoznaczną.
Literatura:
-Podstawy techniczne inżynierii oprogramowania, Dick Hamlet, Joe Maybee, wyd. WNT Warszawa
2003
-Zrozumieć UML 2.0 metody modelowania obiektowego, Michał Śmiałek, Helion 2005
10.10.2012r.
Inżynieria Oprogramowania to modelowanie rzeczywistości. Przedstawianie jakichś elementów
rzeczywistości w formie cyfrowej.
Semantyka języka programowania, to swojego rodzaju formularz. Formularze są potrzebne do
komunikacji z systemami informatycznymi.
Jakie błędy można popełnić przy programowaniu?
Błąd kompilacjikonsolidacji (linkowania)wykonania
Przed tworzeniem systemu informatycznego (modelowaniem), trzeba zdekomponować
rzeczywistość, którą chcemy zmodelować. Trzeba zidentyfikować elementy rzeczywistości, które
mają być zmodelowane, określić co ma być zawarte, co system ma być w stanie zrobić.
Rozkładając rzeczywistość, tworzymy model wymagań (model opisowy), zapisany w języku
potocznym. Do stworzenia takiego modelu potrzebny jest klient i menadżer projektu, który
zadecyduje czy podejmować się takiego przedsięwzięcia, okresli jak bardzo będzie trudny, na tej
podstawie określi cenę itp.
Rzeczywistość model opisowy (dekompozycja, analiza) model numeryczny model
cyfrowy (działający system informatyczny, po procesie syntezy)
Sprawdzanie czy model jest dobry  testowanie. Dla ściśle określonego wejścia sprawdzamy, czy
system zwraca ściśle określone, oczekiwane przez nas wyjście.
Jakość oprogramowania - oprogramowanie powinno posiadać różne  ośći :
-odpowiednią funkcjonalność (reklamowane funkcje, ustalone przez klienta i menadżera projektu)
-niezawodność (na przykład mierzona przez średni czas awarii)
-pewność (czy realizuje to czego oczekujemy i jest odporne na awarie krytyczne)
-łatwość użycia
-zdolność do pielęgnacji  łatwość usuwania błędów
-wydajność (na przykład czas wyszukiwania, przetwarzania, dostępu do danych rekordów) jest
pomijana
Szacowanie ilości niewykrytych błędów (wprowadzanie sztucznych itd.)
Kaskadowy model wytwarzania oprogramowania (cyklu życia oprogramowania):
wymagania
specyfikowanie
projektowanie
kodowanie
testowanie
gotowy produkt
Jest to tylko model teoretyczny, wskazówka do tego jak powinno wyglądać projektowanie systemu
informatycznego.
17.10.2012r.
Inżynieria oprogramowania jest wstępnym procesem do zarządzania projektem. Nie można
stworzyć sensownego oprogramowania bez projektu. Zakładamy, że właściwy projekt jest wtedy
kiedy powstanie produkt i ktoś nam za niego zapłaci.
Przedsięwzięcia projektowe:
wytwórcze
wdrożeniowe
projektowanie sieci komputerowych
Każde z tych przedsięwzięć wymagają innego typu umiejętności.
Celem takiego przedsięwzięcia jest zbudowanie aplikacji. Budowaine aplikacji składa się z projektu
i implementacji.
Sukces projektu, jego czynniki:
Zadowolenie klientów
Nie przekraczanie ograniczeń
czas, budżet, jakość (spełnianie odpowiednich wymagań)
Zgodność ze specyfikacją
Model kaskadowy:
Po zrealizowaniu każdego etapu projektu, nie wraca się już do wcześniejszych.
wymaganiaspecyfikowanieprojektowaniekodowanietestowaniegotowy produkt
Przy projektowaniu aplikacji rozpisuje się ją na formę modeli numerycznych.
Tworzenie systemów numerycznych to przechodzenie przez modele:
rzeczywistywymagańnumerycznycyfrowy
Fazy tworzenia systemów informatycznych:
strategicznaanalizysyntezyinstalacji
Im póz
niej wykryty zostanie błąd w systemie, tym bardziej kosztowne jest jego usunięcie.
Przy rozmowie z klientem dobrze jest od razu zapisywać wymagania na kilku kartkach, rozkładając
je od razu na poszczególne moduły. Moduły mają między sobą wymieniać dane. Jeśli tego nie
robią, to mamy do czynienia praktycznie z kilkoma różnymi programami, całkiem osobnymi. Jeśli
każdy moduł wymienia dane z pozostałymi, wszystkie wymieniają razem ze sobą dane, to nie ma
potrzeby rozbijania ich na różne moduły.
Pytania:
1. Czy czas wprowadzania oprogramowania jest istotny?
2. Wyjaśnij różnicę pomiędzy niezawodnością, a pewnością.
3. Jak to może być, że program jest łatwy w pielęgnacji, ale ma małą funkcjonalność?
4. Jeśli inżynier błędnie wymawia "kamień milowy" (milestone) jako "kamień młyński", o
czym może on nieświadomie myśleć?
5. Opisz etapy kaskadowego życia oprogramowania.
6. Czy plan testów może stanowić jeden z elementów kaskady?
7. Porównaj menadżerskie i inżynierskie spojrzenie na tworzenie oprogramowania.
Omówienie wymagań z klientem i uzgodnienie ich realizacji jest praktycznie umową między
klientem i producentem.
Zasady tworzenia oprogramowania
1. Tylko złożone oprogramowanie wymaga inżynierii.
2. Złożoność przedsięwzięcia programistycznego stanowi trzon problemu.
3. Ogólną metodą rozwiązywania złożoności jest dekompozycja  sztuką jest określenie na
jakie części [rozwiązanie części może nie rozwiązać problemu, trzeba też przewidzieć ich
złożenie w całość; czasem części mogą być trudniejsze do rozwiązania niż całość]
Metoda dziel i zwyciężaj:
1. Podstawa dekompozycji  części niezależne
2. Ograniczenie elementów niezależnych (około 7 jest optymalnie)
Dzięki temu można rozwiązywać problemy dużo bardziej złożone, niż w przypadku rozwiązywania
całego problemu naraz.
3. Każdy etap jest realizowany dla określonego odbiorcy
4. Zdolność do abstrakcyjnego myślenia jest największym talentem ludzkiego rozumu
5. Zasada "od rozmycia do skupienia"
6. Dokumentacja:
Dobrym z
ródłem dokumentacji jest dokumentacja testowa. Podczas testów analizuje się
działanie całego systemu, więc spisanie wyników tych testów powinno stanowić dobrą
dokumentację pracy programu, pomocną użytkownikom w jego używaniu. W dokumentacji
nie stosuj synonimów.
7. Wejście/wyjście  podstawa oprogramowania
określenie wszystkich wejść/wyjść
określenie zakresu dopuszczalnych wejść/wyjść
określenie szczególnych wartości we/wy
określenie czasu w jakim ma się pojawić wyjście
Problem miar:
zarejestrowana historia, poprzednie projekty pomagają określić złożoność kolejnego
powiązanie ilość kodu z innymi potrzebnymi elementami:
ludzie
czas
Przy projektowaniu i rozmowie z klientem trzeba absolutnie dbać o satysfakcję klienta, najlepiej
nawet sugerować, że to dzięki niemu udało się stworzyć taki dobry system, że to jego pomysły były
bardzo ważne w procesie jego budowania.
24.10.2012r.
Przy rozwijaniu funkcjonalności trzeba postarać się powstrzymać 'pączkowanie', w momencie jak
efekt prac już nas zadowala.
Rola menadżera:
Wszystko sprowadza się do planowania wykorzystania dostępnych zasobów. Takimi zasobami
między innymi są zasoby ludzkie.
Programowanie NIE równa się inżynierii oprogramowania. Mają one wiele wspólnych elementów,
ale to NIE to samo. Programowanie wprowadza się dopiero po zdeterminowaniu w jakiej
technologii to zrobić. Inżynieria oprogramowania wprowadzana jest dużo wcześniej.
Problem miary informacji:
Trzeba obrać jakieś kryterium jak mierzyć ilość informacji. Jest to trudne, ale 'lepsza płytka miara
niż żadna miara'. W ocenie systemu informatycznego można stosować miarę ilości linii kodu. W
dzisiejszych czasach nie mierzy się tego już w ten sposób, nie jest on już zbyt adekwatny. Teraz
mierzy się raczej ilość funkcjonalności jakie system realizuje, czyli ilości bibliotek jakie są w nim
zaimplementowane, bo to one pozwalają a korzystanie z funkcjonalności. Przez to włączając
biblioteki niekoniecznie korzystamy z całości tych bibliotek. Powstaje przez to problem czy
zaliczać do tej miary całe biblioteki, jeśli niekoniecznie korzystamy z ich całości. Odpowiedz
jest
oczywista, jeśli nam za to zapłacą, to tak.
Najważniejsza własność miary  obiektywność.
Można miary bazować na:
1  Zarejestrowana historia (wcześniejsze realizowane przez nas projekty, porównanie z nimi)
2  Ilość linii kodu (efektywnego [wykorzystywanego] lub ogólnie)
3  W przypadku braku danych historycznych  modele estymacyjne, algorytmiczne (na podstawie
wzorów)
Jeśli jest możliwość podziału danych elementów na różne moduły, należy to zrobić i zlecić ich
zrobienie różnym osobom. Historycznie nie było to konieczne, bo projekty były na tyle małe, że nie
wymagały dzielenia.
Modelowanie to przejście od modelu opisowego do numerycznego. Stosuje się wtedy metody
modelowania  obiektowe lub strukturalne.
Jeżeli oprogramowanie przejdzie wszystkie testy, to znaczy tylko że spełnia wymagania określone
przez klienta. W określonych przypadkach działa tak jak oczekujemy, nic więcej. Nie jest dzięki
temu idealny.
Wady i zalety modelu kaskadowego:
+jesteśmy w stanie utrzymać projekt w ryzach, pozwala trzymać się harmonogramu
-kontakt z klientem jest utrudniony, ciężej jest mu wmówić że to on jest głównym pomysłodawcą i
'twórcą' oprogramowania, a to by pomogło w jego zadowoleniu
Inne modele:
1. Realizacja kierowana dokumentami (model armii USA)  kaskadowy z warunkiem
kompletnej dokumentacji każdej fazy (tzw. Milestone), klient sprawdza postępy i problemy
po każdej fazie
2. Prototypowanie  tworzenie kolejnych prototypów, pierwsze nawet bez funkcjonalności, ale
z widocznym interfejsem, żeby zainteresować klienta
ten model zakłada cykliczną realizaję systemu przez weryfikowane przez klienta
prototypy
pozwala łatwo uniknąć błędów wynikających z niedomówienia, klient widzi na bieżąco
co będzie zawarte w systemie
3. Model ewolucyjnej konstrukcji prototypów
nie ma w tym modelu elementu instalacji po każdym etapie, jest to rozwiązane trochę
inaczej
4. Programowanie odktywcze  złożone systemy o trudnych do sprecyzowania wymaganiach
cyklicznie realizuje się różne wymagania, aż klient będzie zadowolony
5. Realizacja przyrostowa
6. Montaż z gotowych elementów  narzędzia CASE (Compact Aided Software Engineering) 
wytwarzanie oprogramowania wspomagane komputerowo
7. Model spiralny  (Boehma 1988)  najbardziej ogólny model cyklu życia oprogramowania
rzeczywistość wytwórcza podzielona na 4 ćwiartki, w których zawarte jest planowanie,
analiza ryzyka, konstrukcja (model kaskadowy) oraz atestowanie
8. Model kaskadowy z rozbudowanym testowaniem  testowanie po każdej fazie
9. Model przyrostowy  często stosowany w praktyce do modeli iteracyjnych i metodyki
dla każdego modułu istnieje możliwość sprecyzowania wymagań
Testowanie walidacyjne wymagań  sprawdzanie czy wymagania są możliwe do zrealizowania.
Studium wykonalności  bierze pod uwagę wszystkie czynniki, które mogą zadecydować o tym czy
projekt jest możliwy i opłacalny do zrealizowania. Podejmuje się wtedy decyzję 'go or no-go';
analiza SWOT.
Atestowanie oprogramowania (customer evaluation) to sprawdzanie go przez klienta.
Baza RUP [Ratonal Unified Process]:
Błędy procesu tworzenia oprogramowania:
zarządzanie wymaganiami ad-hoc (najczęściej brak zarządzania)
niejednoznaczna komunikacja
architektura nieodporna na obciążenia
zbytnia, niepotrzebna złożoność oprogramowania
niewykryte niespójności w wymaganiach, projekcie, implementacji
brak (lub niewystarczające) testowanie
subiekywna ocena postępu projektu
brak zarządzania ryzykiem, atakowania ryzyka
brak automatyzacji prowadzenia projektu
Zasady IO, najlepsze praktyki programistyczne:
Iterative Development
Requirement Management
Component-based Architecture
graficzne projektowanie oprogramowania
Quality Assurance
BPMN (Business Process Modelling Notation)  bazowany na UML, służy do modelowania
procesów biznesowych.
Skodyfikowanie  zapisywanie w formie regulaminu lub kolejnych zadań.
KONTEKST PRZEDSI
WZI
CIA PROJEKTOWEGO  NA NAST
PNY WYKA
AD
SPRAWDZIĆ CO TO JEST
7.11.2012r.
Podstawa dobrego modelu cyfrowego, to zapewnienie takich samych wyników jak w
rzeczywistości.
Rzeczywistość model opisowy wymagań [od niego pochodzi model specyfikacji] model
numeryczny [w formie DFD, UML, BPMN] model cyfrowy (system informatyczny).
Data Flow Diagram jest używany w programowaniu strukturalnym. Jest tam ukazane jak zmienia
się używana struktura danych, poprzez użycie różnych funkcji.
W programowaniu obiektowym zmiany używanych struktur zaszyte są w obiektach poszczególnych
klas. Nie wiemy dokładnie jak przepływają dane i jak się zmieniają.
Baza RUP  Rational Unified Process:
iteracyjne wytwarzanie oprogramowania (Iterative Development)
zarządzanie wymaganiami (Requirement Management)
używanie architektury bazowanej na komponentach (Component-based Architecture)
graficzne projektowanie oprogramowania
kontrola jakości oprogramowania (Quality Assurance)
proces kontroli zmian w oprogramowaniu (Change Management)
(IBM 2003)  coś więcej niż model cyklu życia oprogramowania; środowisko RUP platform dla
programistów obejmujące szereg narzędzi asystujących i prowadzących twórców programowania w
dwóch wymiarach [Wertykalny i Horyzontalny].
Czynności w fazie strategicznej:
Określenie celów przedsięwzięcia z punktu widzenia klienta
Określenie zakresu przedsięwzięcia
Określenie kontekstu przedsięwzięcia
W fazie strategicznej trzeba podjąć decyzje:
wybór modelu, zgodnie z którym realizowane będzie przedsięwzięcie
wybór technik stosowanych do analizy
wybór środowiska implementacji

Niezbędne elementy [moduły] systemu informatycznego:
baza danych (bardzo często)
interfejs
silnik obliczeniowy, bazodanowy, przetwarzający dane
moduł bezpieczeństwa (rozróżnianie użytkowników, żeby administrator mógł dokonać
większych zmian w systemie)
14.11.2012r.
Na koszty oprogramowania składają się:
koszt sprzętu
koszt wyjazdów, szkoleń
koszt zakupu narzędzi
nakład pracy
Pierwsze trzy łatwo oszacować, z nakładem pracy jest już ciężej. Jest to bezpośrednio związane z
analizą wymagań jakie oprogramowanie ma spełnić.
Metody szacowania kosztów nakładu pracy:
modele algorytmiczne (np. model COCOMO)
ocena przez eksperta (koszt ocenia osoba, która jest doświadczona w tworzenu oprogramowania)
ocena przez analogię
prawo Parkinsoa (zakłada, że w zasadzie każde przedsięwzięcie kończy się sukcesem i mieści się
w założonych nakładach)
wycena dla wygranej
szacowanie (np. wstępujące  dzieli się całe przedsięwzięcie na moduły i szacuje się koszty
poszczególnych modułów)
Modele algorytmiczne:
COCOMO (COst COnstruction MOdel)  przedsięwzięcie można zaliczyć do jednekj z klas:
organiczne (proste) [A=2.4, b=1.05]  małe zespoły o podobnym, wysokim, poziomie
umiejętności technicznych, dziedzina jest dobrze znana, wykonywane za pomocą dobrze znanych
metod
półoderwane (średnie) [A=3, b=1.12] członkowie zespołu różnią się stopniem zaawansowania,
pewne aspekty dziedziny nie są znane
osadzone (wbudowane) [A=3.6, b=1.20] realizacja złożonych systemów, dziedzina i narzędzia
w znacznej części nieznane, większość członkół zespołu nie ma doświadczenia w takich projektach
Wylicza się to na zasadzie: Nakład [osobomiesiące] = A(KDSI)D
Ten model zakłada, że z nakładu można wyliczyć koszt przedsięwzięcia.
Ocena rozwiązań:
Wybór najlepszego sposobu realizacji przesięwzięcia jest niezbędne do pozytywnego jego
ukończenia.
Można to stworzyć tabelę z przedstawionymi rozważanymi rozwiązaniami, w nich zawarty będzie
koszt, czas, niezawodność, wydajność, przenośność oraz możliwość ponownego wykorzystania. Na
tej podstawie dokonuje się wielokryterialnej analizy. Ustala się wagi poszczególnych wymagań, w
zależności od tego co jest przez użytkownika najbardziej wymagane. Dzięki temu można
wszystkim rozwiązaniom nadać oceny łączne, dzieki którym łatwo wybrać optymalne rozwiązanie.
Po wybraniu najlepszych rozwiązań  analizuje się niepewności, określa się pesymistyczne i
optymistyczne koszty poszczególnych rozwiązań i wyznacza ich prawdopodobieństwa, dopiero na
tej podstawie liczy się koszt przedsięwzięcia.
W fazie określania wymagań definiujemy tylko co ma być na wejściu do programu i na wyjściu z
niego. Nie wskazuje się wtedy sposobu uzyskania takiego wyjścia.
Dobry opis wymagań powinien być dokładny i niesprzeczny. Dokument ten powinien być podstawą
formalnego, szczegółowego kontraktu między klientem, a producentem, powinien być zrozumiały
dla obu stron.
Dokument opisujący wymagania powinien zawierać:
wprowadzenie (cele, zakres, kontekst systemu  wyniki fazy strategicznej)
opis ewolucji systemu (opis przewidywanych zmian wymagań wobec systemu)
opis wymagań funkcjonalnych (funkcje, czynności, operacje wykonywane przez system)
opis wymagań niefunkcjonalnych (ograniczenia, przy zachowaniu których system powinien
realizować swoje funkcje)  na przykład rozmiar, wydajność, łatwość użytkowania
model systemu
słownik (wyjaśnienie terminów, które mogą być niezrozumiałe dla jednej ze stron)
Czynniki sukcesu:
zaangażowanie odpowiednich osób ze strony klienta
pełne rozpoznanie wymagań
sprawdzenie kompletności wymagań
21.11.2012r.
Przy programowaniu obiektowym nie określa się najpierw funkcji programu. Zamiast tego określa
się byty (podmioty, obiekty) i czynności jakie można na tych bytach wykonywać (można, nie
trzeba).
W programowaniu strukturalnym określamy funkcje jakie program ma realizować.
Notacje stworzone są w celu jednoznacznego określenia wejścia, wyjścia i szeregu metod jakie
trzeba opracować żeby dla określonych wejść uzyskać pożądane wyjście.
W programowaniu strukturalnym wprowadzamy do programu strukturę danych i po przetworzeniu
otrzymujemy inną strukturę danych. W programowaniu obiektowym zmieniamy atrybuty, własności
obiektów, na których pracujemy.
Analiza i programowanie obiektowe ułatwia ukrywanie danych (hermetyzację), wykorzystywanie
gotowych elementów, ponowne wykorzystanie oprogramowanie, szybkie prototypowanie,
programowanie oparte na zdarzeniach, programowanie przyrostowe.
UML  graficzny język do obrazowania, specyfikowania, tworzenia i dokumentowania systemów
informatycznych. Konieczne jest stosowanie obrazowania wymagań, ponieważ może ich być
ogromna ilość, która byłaby bardzo ciężka do zapisania, przedstawienia, wyobrażenia sobie bez
tego.
Klasy  grupy obiektów o podobnych własnościach.
Związki między klasami (zależności):
UML definiuje powiązania między klasami takie jak dziedziczenie,
Use Case (Przypadki Użycia)  definiują funkcjonalność systemu, przedstawiają CO system
powinien realizować (nie JAK). Są ważne przy tworzeniu testów sytstemu. Dla każdego wymagania
przygotowujemy wejście i sprawdzamy, czy system zwraca odpowiednie wyjście.
Przypadki Użycia w UML  diagramy przypadków użycia służą do obrazowania zachowania
systemu, podsystemu lub klasy w taki sposób, by użytkownicy mogli zrozumieć jak z tego bytu
skorzystać, a programiści mogli go zaimplementować.
Przy modelowaniu przypadków użycia niezbędne jest najpierw zdefiniowanie aktorów danego
przesięwzięcia (przypadku użycia).
Budowa statycznego modelu klas. Obserwowanie kolejnych stanów widocznych w rzeczywistości
klas i analiza zmian, dzięki temu można stworzyć model cyfrowy, zaprojektować klasy w systemie.
Weryfikacja klas i obiektów: należy sprawdzić czy klasy i obiekty widoczne w rzeczywistości są
istotne z poziomu użytkownika. Przykładowo przy wydawaniu dowodu rejestracyjnego nie jest
istotny obiekt osoby, która nam ten dowód wydaje. Ważny jest tylko fakt, że ten dowód zostanie
nam wydany, nieistotne jest przez kogo. Tak samo element sprawdzania tożsamości przez
przedstawienie dowodu osobistego także nie jest wymagany, można go zastąpić przez inne metody
weryfikacji, jak hasło, czy odczyt linii papilarnych.
Dokumentacja musi być (a właściwie wymagania w niej zawarte):
kompletna (zawarcie wszystkich wymagań)
zwięzła (nie używać skrótów, określić hierarchię wymagań)
precyzyjna (wszystko formułować jednoznacznie)
jasna
jednoznaczna
spójna
możliwa do śledzenia
łatwa do modyfikacji
możłiwa do testowania
wykonalna
Dokumenty wymagań i specyfikacji trafiają do:
użytkowników docelowych (w celu sprawdzenia systemu, czy chcą za niego zapłacić)
do projektantów (w celu określenia kolejnych działań)
do testerów (w celu opracowania planów testów)
18.11.2012r.
Model strukturalny to najkrócej mówiąc model z nakierowaniem na podmiot. Obserwujemy szereg
akcji, czynności, metod, które odbywają się na pojedynczym obiekcie, obserwujemy jak zmieniają
się jego parametry/atrybuty.
Model obiektowy określa obiekty, które mogą mieć różne atrybuty, jak również metody jakie
można na tych obiektach wywołać, dzięki temu można samemu określać jak bardzo złożone będą te
obiekty.
Analiza strukturalna  zaczyna się od budowy dwóch modeli systemu: diagramu DFD, będącego
opisem pasywnej części systemu oraz modelu funkcji opisującego aktywną część systemu.
Analiza obiektowa:
W pierwszym etapie analizy jesteśmy w stanie określić obiekty, dzieje się to w fazie określania
wymagań. Póz
niej określa się klasy, jakie należy stworzyć żeby mogły zaistnieć takie obiekty
(model numeryczny). Podczas tego określa się jakie klasa ma mieć atrybuty i metody.
Generalizacja  specjalizacja:
Dwie klasy pozostają w związku generalizacji-specjalizacji jeżeli jedna z nich, zwana specjalizacją,
jest rodzajem drugiej, zwanej generalizacją. Przykładowo 'nauczyciel' to specjalizacja 'pracownika'.
Definiowanie związków klas  może być za pomocą symboli relacji, może być też za pomocą nazw
związku. Przykładowo nazwa związku między uczelnią i instytutem jest zatrudnienie. Pracodawca
zatrudnia pracownika.
Stan systemu  stan wszystkich obiektów w danym momencie. Upływ czasu w systemach
obiektowych odbywa się na podstawie zmiany stanu systemu. Po tym, że stan systemu się zmienił
wiadomo, że jakiś czas upłynął.
Podczas tworzenia modelu obiektowego należy przejść przez cztery etapy:
identyfikacja klas i obiektów
identyfikacja związków klas i obiektów
identyfikacja metod i komunikatów
identyfikacja i definiowanie pól
przy czym nie ma znaczenia od którego etapu zaczniemy i w jakiej kolejności przez te etapy
przejdziemy.
Agregacja (zawieranie)  relacja w której obiekt podrzędny jest częścią obiektu nadrzędnego. Na
przykład instytut jest częścią wydziału, a wydział jest częścią uczelni. Może (lub nawet musi)
istnieć kilka elementów podrzędnych, żeby złożyły się w jeden nadrzędny.
05.12.2012r.
Cztery elementy podane na poprzednim wykładzie są z sobą ściśle powiązane. Elemeny nie
powiązane z innymi częściami systemu nie powinny do niego należeć, nie będą funkcjonalne.
Diagramy klas:
Asocjacja  zależność łącząca dwie klasy lub więcej (łącząca instancje)
Mnogość  określa jak wiele instancji jednej klasy jest w relacji do jednej instancji drugiej klasy (0
w mnogości określa asocjację opcjonalną)
Agregacja -
Specjalizacja -
Generalizacja -
Diagramy przypadków użycia:
Zostały stworzone, żeby zobrazować schemat działania głównych funkcjonalności systemu. Do
tych diagramów tworzony jest też diagram, na którym widoczne są powiązania pomiędzy
poszczególnymi przypadkami użycia. Poszczególne UseCase'y wywoływane są poszczególnymi
triggerami/komunikatami.
12.12.2012r.
Hierarchia wymagań  wprowadzana po to, żeby określić relacje między modułami (które są
ważniejsze), wyodrębnić wymagania główne i powiązane z nimi wymagania poboczne.
Dzięki temu tworzymy model wymagań, z którego z kolei tworzony jest model specyfikacji. Nie
musi być przejrzysty dla klienta, ale dla nas. Zawarte są w nim sformułowania logiczne, które są
bardziej jednoznaczne niż w modelu opisowym.
Póz
niej tworzy się model numeryczny, na podstawie modelu specyfikacji. Transformacja od modelu
specyfikacji do modelu numerycznego może się odbywać na dwa sposoby  przez budownie
modelu strukturalnego lub obiekowego.
Model strukturalny jest przedstawiany przez schemat DFD (zwykle schemat blokowy)
przetwarzania struktury danych z wejścia.
Model obiektowy jest przedstawiany przez diagramy UML, który pokazuje statykę i dynamikę
bytów.
W modelu obiektowym, klasy mogą świadczyć różne usługi, ale to nie znaczy że muszą to robić.
Robią to, gdy dotrze do nich odpowiedni komunikat (trigger, 'cyngiel').
Modele obiektowe dzielą się na:
model stanu systemu (state models)  pokazują statyczny stan systemu
model zachowania systemu (behavior models)  pokazują m.in. interakcje między obiektami
model zmiany stanu systemu (state change models)
W UML wprowadzone jest sześć typów diagramów:
struktura stanu (state structure)
przypadki użycia (use case)  mają być zapisane na maksymalnie wysokim poziomie abstrakcji
wykres (rejestr) stanu (statechart)
diagram współpracy (collaboratoin, communication diagrams)
wykres aktywności (activity diagrams)
wykres implementacji (implementation diagram)
Warstwy aplikacji:
architektury jednowarstwowe  standalone, włączane z danej maszyny bezpośrednio
architektury dwuwarstwowe  client-server, większość zadań jest wykonywane przez klienta,
serwer dostarcza danych
architektury trójwarstwowe
architektury czterowarstwowe  na przykład po dołączenio warstwy mobilnej do aplikacji
Instancje klasy  różne obiekty tworzone(powoływane) z jednej klasy.
Asocjacja  zależnośc łącząca dwie klasy lub więcej (łącząca instancje)
Mnogość  określa jak wiele instancji jednej klasy jest w relacji do jednej instancji drugiej klasy (0
określa opcjonalną asocjację)
Agregacja  jest rodzajem asocjacji wskazującej na zawieranie się klas. Nadklasa zawiera wszystkie
instancjie podklasy.
Generalizacja  jest rodzajem związku pomiędzy klasyfikatorami (klasami, a nie instancjami), więc
nie definiujemy w niej mnogości
09.01.2013r.
W systemie strukturalnym najważniejszym czynnikiem do działania jest czas. Po uruchomieniu
systemu i wprowadzeniu do niego struktury danych wejściowych, wykonywane są po kolei
zaprogramowane metody, jedna po drugiej, w kolejności w jakiej zostały zaprogramowane żeby
działać, po czym prezentowane są użytkownikowi efekty tej pracy.
W systemie obiektowym, triggerem do działania danej funkcji systemu nie jest czas (czy też
moment zakończenia działania wcześniejszego elementu programu), tylko interakcja z
użytkownikiem, a konkretniej  wysłany komunikat.
Tworzenie systemu to przejście przez cztery etapy:
Środowisko rzeczywistości model rzeczywistości model kodu kod.
Zależność między bazami danych i modelem obiektowym: tabele w bazach danych są analogiczne
do obiektów w bazie danych. Tabela w bazie danych przechowuje wartości różnych atrybutów,
podobnie jak dana klasa, a właściwie jej obiekty.
Różnice między diagramami Use Case, a diagramami czynności (Activity Diagram).
Przykład: autoryzacja. Use Case to autoryzacja, a dopiero to specyfikuje, że potrzebne są do tego
odpowiednie mechanizmy, które tą autoryzację umożliwiają. Use Case to diagram scenariuszy,
które mogą być odegrane, jest ich kilka i nie jest określane które konkretnie zostaną wybrane dla
danego Use Case'u.
Activity Diagram specyfikuje który konkretny scenariusz będzie zastosowany.
Diagramy Use Case:
Przypadki użycia  jednostki opisu dynamiki systemu  zestawy scenariuszy.
Scenariusze  sekwencja interakcji podlegających określonym warunkom i prowadzącym do
określonego celu (w opisie prezentowana jako tekst lub diagramy czynności).
Actor  obiekt, który wywołuje dane scenariusze.
Diagramy Czynności:
Jest to uszczegółowienie diagramów Use Case.
Węzeł początkowy i końcowy  ograniczniki sieci akcji.
Akcje  określone czynności opisane w zaokrąglonych prostokątach.
Węzły decyzyjne  romby z opisem decyzji.
Przepływy sterowania  strzałki, mogą być z uwarunkowanim.
DIAGRAMY INTERAKCJI:
Diagramy Interakcji (Sekwencji):
Pokazują następstwo czasowe w sekwencji komunikatów
Linie życia  pionowe kolumny odnoszące się do obiektów z diagramów obiektów
Fragment włączony  sekwencja komunikatow realizowanych iteracyjnie
Aktorzy również włączeni jako obiekty. Nazwa komunikatu nad sztrzałkami obrazującymi ich
wymianę. Komunikat powrotny  powrót sterowania.
Obiekt uznawany jest za 'żywy', dopóki można zmienić któryś z jego atrybutów.
Diagramy Interakcji (Komunikacji)
Diagramy Interakcji (Opisu Interakcji)
Połączenie diagramu czynności i diagramu sekwencji.
Bazą jest notacja diagramów czynności, gdzie poszczególne akcje są zastąpione interakcjami.
Obrazowanie czynności złożonych z ciągu kolejnych interakcji pomiędzy obiektami.
MODELOWANIE DYNAMIKI:
Diagramy Interakcji (Następstw)
Diagramy maszyny stanów
Określają sposób zachowania się wybranego elementu modelu (obiektu) w postaci przejść
pomiędzy jego stanami.
Stan  pewna, stabilna sytuacja, w jakiej znajduje się dany element.
Przejścia do innych mogą następować pod wpływem określonych zdarzeń (np. komunikatów
otrzymanych od innych elementów modelu)
Należy pamietać, że model obiektowy nie może istnieć bez przesyłania komunikatów. Na tym cały
ten system bazuje (w odróżnieniu od systemu strukturalnego, który wykonuje poszczególne
czynności jedna po drugiej).
PRAKTYCZNE ZASTOSOWANIE DIAGRAMÓW STRUKTURY I DYNAMIKI:
Użytkownik lub zamawiający system:
diagramy przypadków użycia, diagramy klas, diagramy czynności
Architekci systemu oprogramowania
didatkowo  diagramy komponentów, diagramy wdrożeń, diagramy sekwencji, diagramy
składowych
Projektanci systemów czasu rzeczywistego
diagramy następstw, diagramy maszyny stanów
SYSTEMY CZASU RZECZYWISTEGO  systemy, w których odpowiedz
systemu oczekiwana
jest w ściśle określonym czasie.
16.01.2013
Use Case'y to zestaw scenariuszy na maksymalnie wysokim poziomie abstrakcji (nie da się ich już
bardziej rozłożyć), nie da się ich dołączyć do innych elementów, wymagań.
Dekompozycja to rozłożenie na poszczególne elementy, analiza to także rozłożenie na poszczególne
elementy, ale z dodatkową analizą tych elementów.
Tworzenie modułów  grupowanie Use Case'ów w zależności od ich kategorii, tego czego dotyczą.
23.01.2013r.
EGZAMIN 28.01.2013, godzina 9:00 osoby A-M; godzina 12:00 osoby N-Ż
Składniki dokumentacji:
opis funkcjonalny  zwarty opis przeznaczenia i głównych możliwości systemu
podręcznik użytkownika  opis, w którym zawarte są informacje jak użytkować system, jak z
niego korzystać, przeznaczony głównie do początkujących użuytkowników
opis instalacji  zawiera procedury instalacji i konfiguracji, niezbędne zwłaszcza w systemach
wielowarstwowych
podręcznik administratora systemu  opis możliwości zmian systemu, konfiguracji
słownik używanych terminów; indeks
Forma dokumentacji użytkowej:
drukowana
elektroniczna  bardziej funkcjonalna, przez możliwość użycia hipertekstu, odnośników do
konkretnych rozdziałów dokumentacji
Jakość dokumentacji użytkowej:
struktura  należy wprowadzić strukturę do dokumentacji, żeby była łatwiejsza do zrozumienia
Testowanie systemu:
Cele testowania:
wykrycie i usunięcie błędów w systemie
ocena niezawodności systemu
Testowanie powinno być wykonywane etapowo:
testowanie wymagań  sprawdzanie na etapie opisywania wymagań, czy są możliwe do
zrealizowania
testowanie architektury
testowanie gotowego systemu
Testy NIE zapewniają 100% niezawodności systemu/
Testy statyczne: wykrywają przyczyny najczęstszych błędnych wykonań i pozwalają ocenić
niezawodność systemu
Testy dynamiczne: wykonywanie fragmentu programu i porównywanie wyników
Fazy testowania:
testy modułów/podsystemów/komponentów
testy systemu
testy aplikacji
Komponenty wymieniają informacje za pomocą interfejsów.
Testowanie wstępujące (unit testyklasy/komponentytesty integracyjne(testy interfejsów)cały
system) i zstępujące (w drugą stronę).
Testy strukturalne:
kryterium pokrycia wszystkich instrukcji  testy są dobrane tak, aby każda instrukcja była
wykonana co najmniej raz
kryterium pokrycia instrukcji warunkowych  testy układane są tak, aby sprawdzona została
każda instrukcja warukowa zawarta w systemie
Testy statyczne (analiza kodu bez uruchamiania problemu)
Stosowane techniki:
testy poprawności
metody nieformalne
Wyszukiwane są:
-niezainicjowane zmienne
-porównanie liczb zmiennopozycyjnych
-indeksy wykraczające poza tablice
-błedne operacje na wskaz
nikach
-błędy w warunkach instrukcji warunkowych
-niekończące się pętle
-błędy popełnione dla wartości granicznych
-błędne użycie lub pominięcie nawiasów w złożonych typach
-nieuwzględnienie błędnych danych
Testy funkcjonalne są pewniejsze od testów strukturalnych.
Testy pod obciążeniem  ważne dla systemów wielodostępnych i wieloprocesorowych.
Narzędzia CASE  narzędzia które wspomagają wytwarzanie oprogramowania
Technologia (metodyka) tworzenia oprogramowania jako suma notacji, technik i procesu
technicznego:
notacja (UML)  wszystkie produkty projektu mogą być zapisane z pomocą odpowiednich
diagramów UML
techniki  dyskusje, tworzenie modeli poprzez narzędzia CASE; obiektowe, strukturalne są
przykładem technik tworzenia oprogramowania
proces techniczny (wytwórczy)  porządek definiujący proces tworzenia oprogramowania w
sposób zorganizowany
Podział metodyk:
techniki PRINTS  zorientowane na procesy (inaczej formalne)  stwarzają wrażenie, że
najważniejszy ich produkt to dokumenty
-UP (Unified Process)
OPEN (Object Oriented Process Environment and Notation)
MDA (Model Driven Architecture)
techniki AGILE  zorientowane na umiejętną reakcję na zmianę (inaczej agilne  AGILE) 
najważniejszym produktem jest kod
-XP
-FDD
-Agile
-AM
NIE tworzymy aplikacji, tylko budujemy, czyli:
projektujemy
implementujemy
Przeglądy systemu
Skróty:
BPMN - Business Process Modelling Notation
UML - Unified Modelling Language
DFD - Data Flow Diagram
RUP  Rational Unified Process
KDSI  Kod Dostarczony Systemu Informatycznego
CRUD  Create, Read, Update, Delete
OMG  Object Modelling Group
MDA  Model Driven Architecture (póz
niej Model Driven Development)
PIM  Platform Independent Model
PSM  Platform Specific Model
CASE  Computer Assisted/Aided Software/System Engineering