Projektowanie systemów komputerowych

(studia stacjonarne i niestacjonarne)

Specjalność: inżynieria komputerowa

wykłady: 30 (24) godz. (egzamin)

projekt przejściowy: 30 (24) godz. (zaliczenie na stopień)

Prowadzący:

wykłady: dr inż. Krzysztof LIDERMAN, tel. 839701 p.82/S

[e-mail]

projekt przejściowy: dr inż. Artur ARCIUCH, tel. 839401 p.88/S

[e-mail]

---------------------------------

Specjalność: systemy multimedialne

wykłady: 20 (16) godz. (zaliczenie na stopień)

laboratoria: 10 (8) godz. (zaliczenie)

Prowadzący:

wykłady: dr inż. Krzysztof LIDERMAN, tel. 839701 p.82/S

[e-mail]

laboratoria: dr inż. Artur ARCIUCH, tel. 839401 p.88/S

[e-mail]

Literatura podstawowa

1. Pressman R.S.: Praktyczne podejście do inżynierii oprogramowania. WNT. Warszawa.2004

2. Liderman K., Arciuch A.: Projektowanie systemów komputerowych. BEL Studio. Warszawa. 2001.

3. Schmuller J.: UML dla każdego. Helion. (Wyd. org. 2001).

4. Trocki M. i in.: Zarządzanie projektami. PWE. Warszawa. 2003.

Literatura uzupełniająca

1. Leffingwell D., Widrig D.: Zarządzanie wymaganiami. WNT. Warszawa. 2003.

2. Hamlet D., Maybee J.: Podstawy techniczne inżynierii oprogramowania. WNT. Warszawa.2003.

3. Roszkowski J.: Analiza i projektowanie strukturalne. Helion. 1998.

4. Bays M.E.: Metodyka wprowadzania oprogramowania na rynek. WNT. Warszawa. 2001.

5. Clements P., Kazman R., Klein M.: Architektura oprogramowania. Metody oceny oraz analiza przypadków. Helion. 2003.

6. Hatley J. D., Pirbhai I. A.: Strategies for Real-Time System Specyfication. Dorset House. 1988.

7. Howard M., Lipner S.: Cykl projektowania zabezpieczeń. Microsoft Press. 2006.

8. Stasiak A., Suski Z., Patkowski A., Bieniek S.: Projektowanie systemów do zastosowań wbudowanych. Biuletyn IAiR. Zeszyt 2. WAT. Warszawa. 1996

9. Yourdon E. Marsz ku klęsce. Poradnik dla projektanta systemów. WNT. Warszawa. 2000.

Strony WWW

1. http://www.mhhe.com/engcs/pressman

2. http://www.sei.cmu.edu

O terminologii uwag kilka ...

Metodologia projektowania - nauka o racjonalnych sposobach projektowania, niezależnie od celu projektowania i środków. Zajmuje się ona wyróżnianiem
i definiowaniem charakterystycznych czynności w procesie projektowania, identyfikacją ich celów i warunków, ich analizą oraz opisywaniem procedur właściwych tym działaniom.

Metoda - świadomie i celowo zastosowany sposób działania, zmierzający do rozwiązania danego problemu w skończonej liczbie kroków.

Jeżeli kolejność działań i same działania są sformułowane jasno i jednoznacznie, to mówi się o metodzie algorytmicznej i przedstawia się ją w postaci algorytmu.

W przeciwnym przypadku mówi się co najwyżej o metodzie heurystycznej
i przedstawia się ją w postaci programu heurystycznego. Do tej grupy zalicza się większość metod projektowania technicznego.

Metoda algorytmiczna zapewnia otrzymanie wyniku końcowego z określoną dokładnością i w skończonej liczbie kroków pod warunkiem, że zastosowano odpowiednią metodę do danego zadania i ściśle jej przestrzegano.

Metoda heurystyczna nie zapewnia uzyskania oczekiwanego wyniku końcowego, lecz tylko zwiększa prawdopodobieństwo jego uzyskania.

Metodyka - zbiór metod określonej klasy przeznaczenia (np. metodyka projektowania strukturalnego). Zbiór ten jest zwykle uzupełniony:

• strategią postępowania, tj. zespołem reguł dotyczących kolejności stosowanych metod w konkretnym przypadku projektowania,

• wskazówkami (najlepiej metodą) dotyczącymi wyboru konkretnej metody spośród danego zbioru w konkretnym przypadku.

Strukturą procesu projektowania nazywamy porządek działań tego procesu, wyróżniony ze względu na określone kryterium, np.:

• odmienność poszczególnych działań (cykl życia systemu komputerowego!),

• główne decyzje podejmowane w tym procesie,

• odmienność wykonawcy.

O projekcie słów kilka ...

Przedsięwzięcie - złożone działanie, wielopodmiotowe, przeprowadzone zgodnie z planem, który ze względu na skomplikowanie bywa sporządzany przy pomocy specjalnych metod.

T. Kotarbiński, Sprawność i błąd, PZWS, Warszawa, 1970

Projekt - celowe, niepowtarzalne (realizowane jednorazowo), złożone przedsięwzięcie zawarte w skończonym przedziale czasu - z wyróżnionym początkiem i końcem - realizowane zespołowo, w sposób względnie niezależny od powtarzalnej działalności przedsiębiorstwa, za pomocą specjalnych metod oraz technik.

Celowość - projekt jest działaniem podejmowanym dla spowodowania rezultatów oczekiwanych przez Zleceniodawcę.

Program - termin ten oznacza:

1. projekt w dziedzinach niekomercyjnych, np. w administracji publicznej;

2. „superprojekt”, bardziej złożony, droższy i obarczony większym ryzykiem niż projekt, bardziej uwarunkowany politycznie, częściej kończy się niepowodzeniem, trudniej opracować miary jego sukcesu

Rodzaje działań związanych z wykonawstwem projektów

Metoda punktów przypadków użycia (UCP)

W metodach obiektowych operuje się na innych artefaktach projektowych niż
w metodach strukturalnych:

• modelach przypadków użycia (Use Case) i związanych z nimi scenariuszach,

• modelach klas biznesowych (Business Class Models).

W przypadku specyfikowania wymagań na system metodami obiektowymi, do oceny wielkości oprogramowania stosuje się, bazującą na idei metody punktów funkcyjnych, metodę punktów przypadków użycia (UCP - ang. Use Case Points). Korzysta się w niej z aktorów i przypadków użycia.

gdzie:

NPU - nieskorygowane punkty przypadków użycia

Na_j - liczba aktorów w systemie w każdej klasie złożoności j,

Wa_j - wagi aktorów w każdej klasie złożoności j,

Nuc_j - liczba przypadków użycia w każdej klasie złożoności j,

Wuc_j - wagi przypadków użycia w każdej klasie złożoności j.

Wyznaczanie skorygowanych punktów przypadków użycia SPU:

SPU = NPU×TCF×EF gdzie:

TCF - współczynnik korekcji złożoności technicznej,

EF - współczynnik korekcji złożoności środowiskowej.

Wzory do wyznaczania współczynników korekcji:

Przyjmuje się, że realizacja jednego SPU wymaga 15 - 30 roboczogodzin.Wartości wag w metodzie UCP

Tab.1. Wycena dla aktorów.

Typ aktora	Opis	Waj
Prosty	Inny system poprzez dobrze zdefiniowany API	5
Średni	Inny system poprzez protokół komunikacyjny Osoba wykorzystująca interfejs tekstowy	10
Skomplikowany	Osoba wykorzystująca interfejs graficzny	15

Tab.2. Wycena dla przypadków użycia - klasyfikacja wg liczby transakcji.

Typ przypadku użycia	Opis	Wucj
Prosty	Maksymalnie 3 transakcje	5
Średni	Od 4 do 7 transakcji	10
Skomplikowany	Powyżej 7 transakcji	15

Transakcja - jednolite i niepodzielne działanie realizujące przypadek użycia.

Tab.3. Wycena dla przypadków użycia - klasyfikacja wg liczby klas analitycznych.

Typ przypadku użycia	Opis	Wucj
Prosty	Mniej niż 5 klas analitycznych	5
Średni	Od 5 do 10 klas analitycznych	10
Skomplikowany	Powyżej 10 klas analitycznych	15

Brane są pod uwagę jedynie przypadki użycia wykorzystywane przez aktorów,
a pomijane są przypadki włączane (<<include>>) i rozszerzane (<<extend>>)

Czynniki złożoności technicznej oraz środowiskowej
i ich wagi

Czynniki złożoności technicznej Pt_k i ich wagi Wt_k:

1. rozproszenie systemu - 2

2. szybkość reakcji systemu - 1

3. wydajność widoczna dla użytkowników pracujących interaktywnie - 1

4. skomplikowane wewnętrzne przetwarzanie - 1

5. przystosowanie do ponownego użycie kodu - 1

6. prostota instalacji - 0,5

7. prostota użycia - 0,5

8. przenośność - 2

9. łatwość wprowadzania zmian - 1

10. współbieżność - 1

11. specjalne funkcje zabezpieczeń - 1

12. udostępnianie użytkownikom zewnętrznym - 1

13. specjalne wymagania na szkolenie użytkowników - 1

Każdy czynnik jest niezależnie oceniany w skali od 0 (brak wpływu na wzrost złożoności ) do 5 (wpływ istotny), tj. Pt_k ⊂ [0,1,2,3,4,5].

Czynniki złożoności środowiskowej Ps_k ich wagi Ws_k:

1. znajomość metodyki RUP - 1,5

2. doświadczenie w tworzeniu aplikacji - 0,5

3. doświadczenie w metodykach obiektowych - 1

4. umiejętności głównego analityka - 0,5

5. motywacja zespołu - 1

6. stabilność wymagań - 2

7. pracownicy zatrudnieni w niepełnym wymiarze - (-1)

8. stopień komplikacji języka programowania - (-1)

Każdy czynnik jest niezależnie oceniany w skali od 0 (brak wpływu na wzrost złożoności ) do 5 (wpływ istotny), tj. Ps_k ⊂ [0,1,2,3,4,5].

Notacja

DIAGRAM KONTEKSTOWY

Dokumenty przepływające w systemie:

1. Lista tematów prac dyplomowych

2. Wykaz pobranych tematów prac dyplomowych

3. Pobrany (konkretny) temat pracy dyplomowej

4. Praca dyplomowa

5. Opinia recenzenta

6. Opinia kierownika pracy dyplomowej

7. Wniosek Komisji Obron Instytutowych

8. Wniosek Komisji Obron Państwowych

DFD_0 (Data Flow Diagram)

DFD_1

STD (State Transition Diagram)

DFD_2

DFD_3

Specyfikacja procesu 4.2.6

proces_4.2.6_EGZAMIAN

zanotuj pytania Komisji Obron Państwowych

jeżeli pytania zrozumiałe to

przygotuj na piśmie konspekt odpowiedzi
/*możesz korzystać ze swojej pracy dyplomowej*/

w_przeciwnym_przypadku

poproś KOP o wyjaśnienia

po upływie wyznaczonego czasu zacznij odpowiadać na pytania
/*nie denerwuj się!*/

Obiekty danych

To przedstawienie może być modelem w postaci diagramu encja-związek (ERD) który opisuje dane w oderwaniu od metod ich przetwarzania.

Opis w modelu dotyczy trzech,
związanych ze sobą, rodzajów informacji:

• obiektów danych, tj. złożonych (mających więcej niż jeden atrybut) elementów informacji;

• atrybutów (opisujących cechy obiektów danych; zestawy atrybutów nazywa się identyfikatorami);

• związków pomiędzy obiektami, opisanymi poprzez nazwę, liczebność
  i modalność.

Liczebność to liczba wystąpień jednego obiektu, które mogą być powiązane
z określoną liczba wystąpień innego obiektu.

Modalność określa obowiązkowość powiązania:

modalność = 1 - powiązanie obowiązkowe,

modalność = 0 - powiązanie opcjonalne.

Dla określenia liczebności i modalności na diagramach, stosuje się np. notację jak na rysunku:

ERD (Entity Relationship Diagram)

Diagramy powiązań danych (ERD) i typy obiektowe

Zawartość i strukturę danych opisuje się za pomocą diagramów ERD, których elementami są typy obiektowe oraz relacje zachodzące pomiędzy obiektami należącymi do różnych typów.

1. Typ obiektowy określa zestaw danych opisujących obiekty lub zjawiska występujące w projektowanym systemie lub jego otoczeniu. Poszczególne wartości danych są pamiętane jako atrybuty obiektów.

Opis typu obiektowego składa się z nazwy (typ nosi nazwę obiektu), nieformalnej definicji i listy atrybutów opisujących każdy obiekt typu. Wartość atrybutu (lub kombinacja wartości określonej grupy atrybutów) jednoznacznie identyfikująca obiekt nazywa się kluczem obiektu i oznacza symbolem @.

2. Relacje opisują statyczne zależności istniejące pomiędzy obiektami należącymi do różnych typów.

W poprawnie zbudowanym ERD:

• każdy typ obiektowy musi mieć nazwę,

• każda relacja musi mieć nazwę,

• każdy obiekt danego typu musi być indywidualnie identyfikowany przez wartości pewnych atrybutów, różne dla różnych obiektów,

• każde wystąpienie relacji musi być indywidualnie identyfikowane.

Diagramy ERD w porównaniu z diagramami DFD nie wnoszą nowych informacji (szczególnie w projektowaniu systemów sterowania) i są w zasadzie nadmiarowe.

Celem odrębnego modelowania danych jest:

• jawne zobrazowanie istotnych zależności w systemie,

• danie projektantowi wskazówek jak organizować dane,

• zapewnienie modelowi większej stabilności (zwykle dane rzadziej ulegają zmianom niż modele przetwarzania).

Diagram kontekstowy

1. Cały system jest reprezentowany przez jeden proces (transformację symbolizowaną okręgiem).

2. Obiekty lub grupy obiektów otoczenia które współdziałają z systemem, są reprezentowane przez terminatory, rysowane w postaci prostokątów.

3. Na schemacie uwidacznia się tylko zewnętrzne przepływy danych między systemem a obiektami otoczenia.

4. Magazyny (zbiory) danych reprezentują dane dzielone przez system i terminatory, a pobranie danych ze zbioru zawsze wymaga aktywności systemu.

5. Kierunki przepływu danych między systemem a terminatorami obrazują relację producent-konsument, przy czym konsument musi być zawsze gotowy do przyjęcia danych, gdy się one pojawią.

6. Diagram kontekstowy powinny uzupełniać opisy tekstowe:

• opis przeznaczenia i celu budowy systemu,

• opis znaczenia przepływów danych i zbiorów,

• lista wymagań niefunkcjonalnych,

• opis zależności pomiędzy terminatorami.

Bardzo duże diagramy kontekstowe można podzielić na fragmenty zawierające segmenty okręgu obrazującego opisywany system.

Terminatorami mogą być:

• obiekty z otoczenia systemu;

• 
  
  urządzenia sprzęgające system z otoczeniem (uzależnia model funkcjonalny od konkretnej techniki realizacji sprzęgu z otoczeniem)

Czujniki i elementy wykonawcze powinny zostać pokazane tylko wtedy, gdy po realizacji systemu będą widoczne nie tylko dla wydzielonych programów WE/WY, ale wpłyną istotnie na organizację danych lub algorytmy przetwarzania.

Pominięcie opisu sprzęgu w modelu funkcjonalnym można interpretować jako wprowadzenie pośredniej warstwy sprzęgu wirtualnego.

Słownik Danych

Słownik Danych to uporządkowany wykaz wszystkich elementów danych (informacji, dokumentów, produktów) mających związek z projektowanym systemem wraz z ich precyzyjnym określeniem tak, aby wszystkie osoby zaangażowane w proces projektowania (analitycy, użytkownicy, projektanci itd.) jednakowo interpretowały (rozumiały) wszystkie wejścia, wyjścia, składniki magazynów, przepływy, obliczenia pośrednie itd.

W Słowniku Danych definiuje się elementy:

• opisując znaczenie przepływów i magazynów pokazanych na diagramie przepływu danych;

• opisując budowę złożonych pakietów danych transmitowanych wzdłuż przepływów, tzn. pakietów (takich jak adres klienta), które można rozbić na bardzie elementarne jednostki (takie jak miasto i kod pocztowy);

• opisując budowę pakietów danych w magazynach;

• określając właściwe wartości i jednostki elementarnych porcji informacji dla przepływów i magazynów danych;

• opisując szczegóły związków między magazynami, pokazanych na diagramie związków encji.

Przykład notacji w Słowniku Danych:

= składa się z

+ i

( ) opcjonalnie (może wystąpić lub nie)

{} iteracja

[] wybór jednej z kilku alternatywnych mośliwości

** komentarz

@ identyfikator ( pole klucza ) dla magazynu

| rozdziela alternatywne możliwości w konstrukcji [ ]

Słownik Danych - przykład zapisów

nazwisko = tytuł + imię + ( inicjał ) + nazwisko

tytuł = [ Pan | Pani | Panna | Dr | Prof. ]

imię = { dowolny- znak }

nazwisko = { dowolny- znak }

dowolny znak = [ A-Z | a-z | ` | - | | ]

Przepływy (1)

Przepływami nazywa się łuki grafu DFD oznaczone graficznie strzałkami, opisujące przepływy (danych, materiałów, sygnałów) pomiędzy procesami (transformacjami) i/lub magazynami (zbiorami).

W klasycznej interpretacji DFD zakłada się, że każdy proces jest wykonywany natychmiast, gdy tylko dostępne są wszystkie przepływy wejściowe. Wynikiem realizacji procesu jest pojawienie się przepływów wyjściowych.
W czasie pomiędzy wystąpieniami przepływów, zawartość magazynów pozostaje stała.

Konwencje interpretacyjne:

1. Każda strzałka łącząca proces z magazynem oznacza dostępność danych przechowywanych w magazynie dla procesu.

2. Strzałka prowadząca od procesu do magazynu oznacza, że proces zmienia zawartość tego magazynu.

3. Strzałka prowadząca od magazynu do procesu oznacza, że dane z tego magazynu są potrzebne procesowi do wygenerowania (np. obliczenia) przepływu wyjściowego.

4. Zależnie od umowy, proces może wymagać jednoczesnego wystąpienia wszystkich przepływów WE, lub niezależne przepływy WE mogą być buforowane przez proces.

Przepływy (2)

Rodzaje przepływów:

1. 
   dyskretne danych ( ) - występują tylko w określonych chwilach. Pojawienie się takiego przepływu można interpretować jako wiadomość powodującą zmianę zawartości magazynu lub wykonanie procesu. Magazyny mogą by połączone z procesami tylko poprzez przepływy dyskretne.

2. 
   
   ciągłe danych ( ) - występują wyłącznie pomiędzy procesami lub procesami a otoczeniem. Procesy do których dochodzą przepływy ciągłe mogą odczytywać ich wartości w dowolnych chwilach; wyjściowe przepływy ciągłe są podtrzymywane przez generujące je procesy w sposób ciągły.

3. 
   dyskretne sterujące tzw. zdarzenia ( ) - przenoszą nie dane, a dwustanowe sygnały sterujące lub synchronizujące (np. start/stop);

4. 
   
   ciągłe sterujące ( ) - np. zawsze dostępne wskazania czujników dwustanowych;

5. wymuszenia (dwustanowe) - specjalne zdarzenia identyfikowane etykietami:

• E/D (Enable/Disable - Włącz/Wyłącz) - proces do którego dochodzi taki przepływ, może przetwarzać przepływy wejściowe tylko po otrzymaniu sygnału Włącz, a przed otrzymaniem sygnału Wyłącz.

• T (Trigger - Wykonaj) - proces, do którego dochodzi wymuszenie Wykonaj, produkuje pojedynczą wartość przepływu wyjściowego dyskretnego po każdym otrzymaniu tego sygnału.

(konwencja notacyjna metodyki Warda-Mellora dla RTS)

Metodyka strukturalna Warda-Mellora projektowania systemów czasu rzeczywistego

Metodyka zakłada budowę kolejnych modeli:

I. Modelu funkcjonalnego (essential model) ETAP ANALIZY

1. modelu otoczenia (enviromental model)

• diagram kontekstowy (context schema)

• specyfikacja danych otoczenia (environmental data)

• lista zdarzeń (event list)

• modelu zachowania (behavioral model)

• diagramy przepływu danych (DFD) i sterowania (STD), opisujące wszystkie funkcje systemu (tj. jego działanie)

• schemat danych (data schema - ERD) opisujący struktury danych związane z przepływami i magazynami (zbiorami) wewnątrz systemu.

Model funkcjonalny uzupełnia się podając ilościowe charakterystyki wejściowe przepływów danych:

• dla przepływów dyskretnych: przeciętna i maksymalna ilość bitów/bajtów przypadających na jedną wiadomość, przeciętna i maksymalna częstotliwość występowania wiadomości, wymagany czas przechowywania wiadomości, itp;

• dla przepływów ciągłych: zakres i amplituda przepływów, pasmo sygnału, stosunek sygnał/szum, itp.

oraz dokumentując powiązania modelu z innymi dokumentami projektowymi (traceability).

II. Modelu implementacyjnego (implementational model)

ETAP PROJEKTOWANIA

1. modelu procesorów (processor model)

2. modelu zadań (task model)

3. modelu modułów (module model)

Diagram przejść stanów (STD)

(przykład notacji)

Diagram przejść stanów dla OBIEKT_x




Podstawowy diagram stanów opisuje zachowanie w czasie pojedynczego typu obiektu poprzez specyfikację sekwencji stanów spowodowanej przez sekwencję zdarzeń.

Stan ma określony czas trwania - zdarzenie separuje dwa stany, a stan separuje dwa zdarzenia.

Visual Modeling with Unified Modeling Language

(przeznaczenie diagramów)

1. Diagram przypadków użycia (use case diagram) - do ilustracji interakcji użytkownika z systemem. Celem diagramu jest opisanie funkcji systemu poprzez dekompozycję ze względu na potrzeby i działania jego użytkowników.

2. Diagram klas (class diagram) - do ilustracji logicznej struktury projektu. Celem diagramu klas jest opisanie zależności strukturalnych: dziedziczenia lub zawierania klas oraz powiązań klas wyrażających możliwość odwoływania się obiektów jednej klasy do obiektów innej klasy.

3. Diagram obiektów (object diagrams) - do ilustracji obiektów i powiązań pomiędzy nimi.

4. Diagramy interakcji: diagram sekwencji (sequence diagrams), i diagram współdziałania (collaboration diagrams) - do ilustracji dynamiki systemu.

5. Diagram stanów (state diagrams) - do ilustracji dynamiki systemu.

6. Diagram aktywności (activity diagrams) - do ilustracji przepływu zdarzeń.

7. Diagram komponentów (component diagrams) - do ilustracji fizycznej struktury oprogramowania.

8. Diagram rozmieszczenia (deployment diagrams) - do ilustracji rozmieszczenia oprogramowania w sprzęcie komputerowym.

Podstawowe etapy cyklu rozwojowego według Rationala:

1. projektowanie wstępne (intercepcion) - podczas tego etapu określa się zakres prac poprzez identyfikację aktorów i podstawowych przypadków użycia (obejmujących zwykle 20% kompletnego modelu)

2. projektowanie szczegółowe (elaboration) - podczas tego etapu określa się podstawową architekturę i kompletuje wymagania (powinno się osiągnąć 80% ukompletowania). Na zakończenie etapu wykonuje się dokładne oszacowanie koszty/resursy.

3. wykonanie produktu (construction) - wykonanie w kilku iteracjach produktu do wersji beta.

4. przekazanie produktu do organizacji klienta (transition) - instalacja, szkolenia i wsparcie techniczne dla użytkownika.

Iteracje:

1. dla złożonych projektów z dużą ilością niewiadomych w dziedzinie techniki i nieprecyzyjnymi wymaganiami, projektowanie szczegółowe może wymagać 3-5 iteracji. Dla prostych projektów, gdzie wymagania są dobrze sformułowane, a architektura jest prosta, projektowanie szczegółowe może wymagać tylko jednej iteracji.

2. każda iteracja zawiera czynności z wszystkich zadań (workflows). zakres tych czynności zmienia się w zależności od iteracji, np. podczas dalszych iteracji na etapie wykonania produktu, główny wysiłek jest skierowany na implementowanie i testowanie, a tylko niewielki na uzupełnienie wymagań.

W metodyce Rationala zakłada się, że wymagania mogą być uzupełniane/zmieniane aż do końca cyklu rozwojowego!

Programowanie Ekstremalne (1)

(XP- ang. eXtreme Programming)

I. Geneza - syndrom LOOP (lata 60/70 ale również i dzisiaj :-):

1. Zamawiane oprogramowanie jest zwykle oddawane
   po terminie - średnio 6-12 m-cy; (ang. Late)

2. Zwykle jest przekroczony budżet- średnio 50-100%; (ang. Over budget)

3. Programiści musza pracować w nadgodzinach; (ang. Overtime)

4. Jakość wykonanego oprogramowania jest zła; (ang. Poor quality)

II. Przeciwdziałanie:

opracowanie standardów i modeli (ISO-9000, CMM, MIL-Std-489 i inne) oraz ich wdrożenie w praktyce.

Nowe zagrożenie: nadmierna biurokratyzacja procesów wytwarzania oprogramowania.

III. Przeciwdziałanie:

opracowanie (koniec lat 90-tych) tzw. lekkich metodyk wytwarzania oprogramowania, do których należy XP.

„Lekkie” oznacza, że narzut na czynności i procesy charakterystyczne dla klasycznego podejścia do rozwoju oprogramowania został mocno ograniczony, np.: uproszczono proces wytwarzania szczegółowego projektu w postaci diagramów na rzecz bardzo prostych modeli, zrezygnowano z formalnej specyfikacji wymagań itd.

Programowanie Ekstremalne (2)

XP jest metodyką wytwarzania oprogramowania (i zarządzania wytwarzaniem oprogramowania), na która składają się:

1. Cztery idee przewodnie:

1. komunikacja,

2. prostota,

3. informacja zwrotna,

4. odwaga

Cel: wytwarzać oprogramowanie o wysokiej jakości za pomocą prostych środków przy uczciwej komunikacji wewnątrz zespołu i w relacji z klientem, ciągłej orientacji na potrzeby klienta oraz odważnym podejmowaniu trudnych decyzji,

2. Dwanaście praktyk:

1. gra planistyczna (zamiast klasycznej analizy)

2. udział klienta w zespole

3. metafora (model referencyjny)

4. prosty projekt systemu (nie istnieje wydzielony etap projektowania)

5. krótkie okresy wydania kolejnych wersji

6. refaktoryzacja (zmiana struktury kodu bez zmiany funkcji)

7. współwłasność kodu (jak w open source)

8. ciągła integracja (nie rzadziej niż raz dziennie)

9. brak nadgodzin

10. standard kodowania

11. programowanie w parach (dyskusyjne ze względu na koszt)

12. testowanie przed kodowaniem (dokładniej: opracowanie testów).

(według Kenta Becka)

Pytania:

1. Czy zbiór praktyk jest zamknięty?

2. Czy rzeczywiste procesy które adaptują tylko niektóre praktyki nie są zbyt mało „ekstremalne”?

Programowanie Ekstremalne (3)

Zalety:

1. humanizacja procesu programowania i maksymalne zacieśnienie kontaktu z klientem

2. testowanie jest procesem ściśle wplecionym w programowanie, co ułatwia eliminację błędów we wczesnych etapach przedsięwzięcia

3. koniec z pisaniem dokumentacji - liczy się komunikacja bezpośrednia (rozmowa)

4. potrzebny jest tylko kod programu i przypadki testowe (można zapomnieć o standardach specyfikowania wymagań :-)

5. jedna osoba pisze kod, druga na bieżąco kontroluje prace partnera - programowanie parami zastępuje inspekcje np. metodą Fagana

6. bardzo krótkie wydania zmniejszają ryzyko przedsięwzięcia.

Wady:

1. odejście od planowanego i udokumentowanego procesu kojarzy się ze spadkiem jakości produkowanego oprogramowania (opory ze strony decydentów):

• brak odpowiedniej dokumentacji jest istotnym czynnikiem ryzyka

• w XP nie planuje się cykli dłuższych niż pojedyncze wydanie (1-2 mc-e);

2. wdrożenie programowania parami jest znacznie kosztowniejsze niż zatrudnienie programistów pracujących pojedynczo;

3. trudne do spełnienia założenia, np. że przedstawiciel klienta pracuje cały czas z zespołem wykonawczym i jest gotowy w każdym momencie udzielić wiążącej odpowiedzi na zadawane przez programistów pytania;

4. niedojrzałość metodyki, m.in. nieznana skuteczność stosowania XP w przypadku wytwarzania systemów o wysokiej niezawodności oraz wymagających ścisłego dotrzymywania harmonogramu.

Obiektowe „widzenie świata”

Metody obiektowe modelują rzeczywistość jako zespół współpracujących i komunikujących się obiektów. Statyczne definicje obiektów nazywane są klasami.

Termin „obiekt” oznacza:

• na etapie analizy - składową dziedziny problemu posiadająca tożsamość, stan i zachowanie;

• na etapie projektowania i implementacji - konstrukcję języka programowania łączącą dane i metody (procedury, funkcje) nazywane też usługami.

Termin „klasa” oznacza:

• na etapie analizy - wzorzec grupy obiektów;

• na etapie projektowania i implementacji - typ obiektowy w języku programowania.

Symbol graficzny klasy w zależności od metodyki (Coada/Yourdona, OMT, Rational, itd.) może mieć różną postać, ale zwykle składa się z trzech części:

• 
  nazwy klasy (obiektu);

• atrybutów (nazywanych też polami, ang. fields, attributes);

• metod (usług, operacji, ang. methods, services, operations).

gdzie:

• atrybuty opisują stan obiektów klasy,

• metody opisują operacje jakie można na atrybutach tej klasy wykonywać.

Przyjmuje się, że części zawierające atrybuty i metody mogą zostać pominięte.




Co to jest „obiekt”?

Obiekt to rzecz lub pojęcie obserwowane w świecie rzeczywistym.

Obiekt ma strukturę - atrybuty (właściwości, cechy) i zachowania (czynności realizowane poprzez wykonywane przez obiekt operacje).

Operacje to działanie (czynności), które klasa może wykonać lub które na danej klasie może wykonać osoba lub inna klasa.

Co możemy powiedzieć o „klasach”?

1. Klasa to kategoria lub grupa rzeczy albo pojęć, które mają podobne atrybuty i wspólne zachowania.

2. Klasa jest szablonem do tworzenia obiektów (egzemplarzy). Ma zatem taką sama strukturę jak obiekt.

3. Klasa to słownik i terminologia określonego zakresu wiedzy.

4. Klasa jest miejscem przechowywania cech obiektów, które są niezmienne (inwariantów).

5. Klasa abstrakcyjna - to klasa, która nie generuje swoich własnych egzemplarzy, lecz służy jako wzorzec dla (pod)klas.















Jak „szukać” klas?

Przy pozyskiwaniu wymagań, np. podczas rozmów klientami o projektowanym systemie i o dziedzinie jego zastosowania, należy zwracać uwagę na:

• rzeczowniki - one zwykle będą klasami (ich nazwami) w budowanym modelu;

• czasowniki - one będą operacjami klas;

• rzeczowniki powiązane z rzeczownikami stanowiącymi nazwy klas - one zwykle będą atrybutami.

Jakie są podstawowe idee związane z „obiektowością”?

1. abstrakcja - oznacza pominięcie cech i operacji nieistotnych (z przyjętego punktu widzenia) i pozostawienie jedynie tych, które są potrzebne.

2. dziedziczenie - oznacza, że obiekt, jako egzemplarz danej klasy, posiada wszystkie jej cechy. Także klasa może dziedziczyć operacje i atrybuty innej klasy.

3. polimorfizm - oznacza, że operacja może w różnych klasach mieć tę samą nazwę i pomimo to oznaczać w poszczególnych przypadkach inne działanie. Każda klasa „wie” jak daną operację wykonać.

4. hermetyzacja (kapsułkowanie) - to jest ukrywanie przez obiekt informacji
   i szczegółów działania. Kontakt z otoczeniem tylko poprzez ściśle zdefiniowane wejścia/wyjścia - interfejsy.

5. komunikaty - to sposób wymiany informacji pomiędzy obiektami.

6. powiązania - to sposób obrazowania związków pomiędzy obiektami/klasami. Obiekt jednej klasy może być powiązany z dowolną liczbą obiektów z różnych klas - do powiązań jest wtedy dołączona tzw. liczność związku.

7. agregacja - jest rodzajem powiązania. Składa się ze zbioru obiektów będących komponentami. Specjalnym rodzajem agregacji jest agregacja całkowita - obiekt będący komponentem może istnieć jedynie jako część składowa całości.

Diagram przypadków użycia (ang. Use-Case)




Agregacja




Klasa/podklasa - dziedziczenie




Diagram klas
(obiektowe „widzenie świata”)

















































Elementy zbioru wymagań w metodzie obiektowej




Słownik

dla systemu wytwarzania i obrony pracy dyplomowej

1. Wstęp

Dokument ten określa terminologię specyficzną dla dziedziny problemowej „wytwarzanie i obrona pracy dyplomowej”. Dokument ten może być używany jako nieformalna baza danych ......

2. Definicje

1. dyplomant - osoba wytwarzająca i broniąca pracę dyplomową

2. WDN - Wydział Dydaktyczo-Naukowy

3. recenzent - osoba recenzująca .....

4. ............

Scenariusz (ang. Use-Case Flow of Events) dla przypadku użycia „pobranie tematu pracy dyplomowej”

1. dyplomant zgłasza się do Wydziału Dydaktyczo-Naukowego

2. WDN udostępnia listę tematów prac dyplomowych

3. dyplomant czyta listę tematów prac dyplomowych i wybiera temat pracy dyplomowej

4. WDN zaznacza na liście temat jako „zajęty”

Specyfikacja przypadków użycia - zawartość

1. Nazwa przypadku użycia (jednoznaczna i zrozumiała!)

2. Krótki opis roli przypadku użycia w systemie

3. Scenariusz

4. Relacje (powiązania i asocjacje)

5. Diagram aktywności

6. Wymagania specjalne

7. Warunki wstępne zastosowania przypadku użycia

8. Warunki zakończenia stosowania przypadku użycia

9. Inne diagramy.

Analiza i projektowanie w metodyce obiektowej RUP

(Rational Unified Process)


Diagram stanów (dla obiektu „praca dyplomowa”)


Diagram aktywności































(dla przypadku użycia „pobranie tematu pracy dyplomowej”)Diagram sekwencji dla skomputeryzowanego przypadku użycia „pobranie tematu pracy dyplomowej” według notacji RUP











40

1

PROCES WYTWARZANIA
I OBRONY PRACY DYPLOMOWEJ

KIEROWNIK

WDN

KOMISJA OBRON PAŃSTWOWYCH

RECENZENT

KOMISJA OBRON INSTYTUTOWYCH

Wykaz tematów pobranych

Lista tematów prac

Recenzja

Praca

Wniosek KOP

Praca + prezentacja

Wniosek KOI

Praca + prezentacja

Praca

Opinia

Lista tematów prac

Wykaz tematów pobranych

KOMISJA OBRON INSTYTUTOWYCH

RECENZENT

KOMISJA OBRON PAŃSTWOWYCH

WDN

KIEROWNIK

Wybranie tematu pracy dyplomowej

1

Recenzja

Praca

Opinia

Praca + prezentacja

Wniosek KOP

Praca + prezentacja

Wniosek KOI

Praca

Wytworzenie pracy dyplomowej

2

Uzyskanie opinii i recenzji pracy dyplomowej

3

Obrona pracy dyplomowej

4

4

Uwagi/poprawki

Elementy pracy

POCZĄTEK

Obrona pracy dyplomowej

4

Uzyskanie opinii i recenzji pracy dyplomowej

3

Wytworzenie pracy dyplomowej

2

Wybranie tematu pracy dyplomowej

1

Opinia pozytywna

Oddanie do recenzji

Praca gotowa (warunek)

Oddanie do opiniowania (akcja)

KOMISJA OBRON INSTYTUTOWYCH

RECENZENT

KOMISJA OBRON PAŃSTWOWYCH

WDN

KIEROWNIK

Praca dyplomowa zaopiniowana i zrecenzowana

RECENZOWANIE

OBRONA

Wykaz pobranych tematów prac dyplomowych

Gotowa praca dyplomowa

Lista tematów prac dyplomowych

Wybrany temat pracy dyplomowej

OPINIOWANIE

KONIEC

Recenzja pozytywna

Obrona

POPRAWIANIE

Opinia negatywna

Poprawianie

Praca poprawiona

Oddanie do opiniowania

???

Recenzja negatywna

???

???

Obrona

symbol na diagramie kontekstowym podstawowego modelowanego procesu (problemu)

Nazwa modelowanego problemu (procesu)

symbol przepływu danych (informacji itd.) pomiędzy elementami DFD

symbol magazynu, tj. elementu mogącego gromadzić dane (infor­macje lub inne, zależne od modelowanego kon­tekstu, elementy)

Nazwa magazynu

lub

Nazwa magazynu

symbol terminatora, tj. elementu zewnętrznego w stosunku do procesów opisywanych za pomocą DFD.

Nazwa terminatora

lub

symbol procesu na DFD

Nazwa procesu

nr

Nazwa procesu

nr

Praca dyplomowa zaopiniowana i zrecenzowana

Praca dyplomowa zaopiniowana i zrecenzowana

Pozytywny wniosek komisji obron instytutowych

Pozytywny wniosek komisji obron instytutowych

Wniosek komisji obron państwowych

Protokół z przebiegu obrony państwowej

Prezentacja pracy

4.2.4

Obrona

instytutowa

4.1

Obrona państwowa

4.2

KOMISJA OBRON INSTYTUTOWYCH

Działające oprogramowanie i/lub sprzęt

KOMISJA OBRON PAŃSTWOWYCH

Praca dyplomowa zaopiniowana i zrecenzowana

Referat

Przygotowanie dokumentów

4.2.3

Przygotowanie pokazu

4.2.2

Przygotowanie prezentacji

4.2.1

Pytania egzaminacyjne

Wniosek komisji obron państwowych

KOMISJA OBRON PAŃSTWOWYCH

Egzamin

4.2.6

Pokaz

4.2.5

Student

Temat pracy dyplomowej

1:1

Lista tematów prac dyplomowych

Temat pracy dyplomowej

1:N

Wykaz pobranych tematów prac dyplomowych

Wybrany temat pracy

obiekt może wykonywać akcje wysyłając zdarzenie do innego obiektu

symbol związku agregacji

Stosowane na diagramach symbole oznaczające krotność związku (asocjacji)

symbol generalizacji (klasa-nadklasa)

Praca

dyplomowa

Tytuł

Autor

Spis

rysunków

Spis

tabel

Spis

treści

Literatura

Załączniki

Wykaz

symboli

Rozdział

Student

nrIndeksu

imię

nazwisko

Dziedziczenie

Dyplomant

tematPracyDypl.

Student

nrIndeksu

imię

nazwisko

Dyplomant

nrIndeksu

imię

nazwisko

tematPracyDyp.

Dyplomant

Nr indeksu

Imię

Nazwisko

Temat pracy dypl.

pobierz_temat

wykonaj_pracę

przekaż_do_opinii

przekaż_do_recenzji

broń_pracę

Praca dyplomowa

Autor

Tytuł

udostępnij

WDN

Wydział

Nr pokoju

przygotuj_listę_tematów

wyznacz_komisję_obron

udostępnij_listę

zaznacz_pobrany_temat

Komisja obron

Skład

Termin obron

wypełnij_protokół

przeprowadź_obronę

Kierownik

Tytuł naukowy

Imię

Nazwisko

konsultuj

opiniuj

weź_udział_w_obronie

Recenzent

Tytuł naukowy

Imię

Nazwisko

recenzuj

Obrona

Termin

Miejsce

Protokół obron

Podpisy komisji

Wyniki obrony

pobiera temat

wyznacza

wykonuje

recenzuje

opiniuje

wypełnia

broni pracę

prowadzi obronę

jest udostępniana na obronę

Praca dyplomowa w realizacji

Praca dyplomowa gotowa

Praca dyplomowa w opiniowaniu

Praca dyplomowa w recenzji

Praca dyplomowa złożona w WDN

opinia negatywna

recenzja pozytywna

recenzja negatywna

opinia pozytywna

:Dyplomant

:PobierzForm

:ListaTematów

Metody

akcja jest operacją natychmiastową o nieistotnym czasie trwania, związaną ze zdarzeniem

:KBTSys

:KBT

jest związana z konkretnym stanem i oznacza operację ciągłą wykonywaną podczas trwania stanu (zaczyna się przy wejściu do stanu i kończy przy wyjściu z niego)

<<entity>>

Dyplomant

// zaznacz temat ( )

//zapamiętaj listę ( )

inny obiekt

NazwaKlasy

atrybutPierwszy

atrybutDrugi

...

operacjaPierwsza()

operacjaDruga()

...

StudentWAT

nrIndeksu: Integer

imię: String

nazwisko: String

...

zakuwaj(Boolean)

zaliczaj(Boolean)

zapominaj(Boolean)

...

nazwa stanu_2

do: czynność

Abacki:StudentWAT

nrIndeksu: 12345

imię: Adam

nazwisko: Abacki

...

zakuwaj(T)

zaliczaj(F)

zapominaj(T)

...

To jest obiekt - egzemplarz klasy „StudentWAT”

To jest klasa „StudentWAT”

//zapamiętaj listę ( )

To jest ogólna ikona klasy

Dyplomant

WDN

Pobranie tematu pracy dyplomowej

Obrona

Komisja obron

Kierownik

Recenzent

Recenzowanie pracy dyplomowej

Wykonanie pracy dyplomowej

Opiniowanie pracy dyplomowej

Przypadek użycia

Aktor

Model przypadków użycia

Aktor

Przypadek użycia

Specyfikacja przypadków użycia

Słownik

Specyfikacja uzupełniająca

....

Specyfikacja przypadków użycia

Przypadek użycia

Aktor

Model przypadków użycia

Analiza

i

projektowanie

Diagram klas

Opis architektury

Model danych

Słownik

Dyplomant zgłasza się do WDN

WDN udostępnia listę tematów

Dyplomant czyta listę

Dyplomant wybiera temat

Dyplomant rezygnuje z pisania pracy

WDN zaznacza na liście wybrany temat jako „zajęty”

Belka synchronizacyjna

Punkt decyzyjny

<<entity>>

ListaTematów

// zamknij listę ( )

<<boundary>>

KBTSys

// udostępnij listę ( )

// zapamiętaj listę ( )

<<control>>

PobierzController

// udostępnij listę ( )

// zaznacz temat ( )

// zamknij i zapamiętaj listę ( )

<<boundary>>

PobierzForm

// wyświetl ( )

// udostępnij listę ( )

// zaznacz temat ( )

// zamknij i zapamiętaj listę ( )

// zaznacz temat ( )

// zaznacz temat ( )

// udostępnij listę ( )

// udostępnij listę ( )

:Pobierz Controller

Komputerowa BazaTematów

Przygotowanie listy tematów

//zamknij listę ( )

//wyświetl listę ( )

//zamknij i zapamiętaj listę ( )

// zaznacz temat ( )

//zamknij i zapamiętaj listę ( )

// udostępnij listę ( )

// udostępnij listę( )

:Dyplomant

Lista tematów

Temat

Kierownik

przygotowuje,

udostępnia,

zaznacza

[wybór]

[rezygnacja]

Atrybuty

Nazwa

klasy

nazwa stanu_1

do: czynność

send
zdarzenie wysłane/akcja

START

zdarzenie/akcja

zdarzenie inicjujące

wykonuje

To odróżnia obiekty danych w analizie strukturalnej od klas i obiektów w analizie obiektowej!

Podstawowa zasada analizy: zrozumieć i odpowiednio przedstawić dziedzinę informacyjną problemu, tj. rodzaje informacji z nim zawiązane.

Podstawowym warunkiem dopuszczającym do egzaminu jest:

• zaliczenie projektu

• zaliczenie zadania domowego.

Warunkiem dopuszczającym do zaliczenia przedmiotu jest zaliczenie zajęć laboratoryjnych

Student

Projekt przejściowy

Liczebność: projekt przejściowy jest wykonywany przez jednego studenta.

Liczebność: student w trakcie studiów wykonuje wiele projektów.

Modalność: związek obowiązkowy - każdy projekt przejściowy jest związany z jakimś studentem.

Modalność: związek opcjonalny - może się zdarzyć, że student nie wykona projektu.

„Początkiem mądrości jest nazywanie rzeczy właściwym mianem”.

Przysłowie chińskie

Działania kierownicze

(zarządcze)

Działania operacyjne

(podstawowe)

Działania wspierające

(pomocnicze)

POTRZEBA

OCZEKIWANY REZULTAT

(zaspokojenie potrzeby)

---