Projektowanie systemów informatycznych - LK -...

Projektowanie systemów informatycznych

1 Metodyka i takie tam gadanie bzdur

1.1 Metodyka tworzenia SI - elementy

Metodyka tworzenia systemu informatycznego Metodyka tworzenia systemu informatycznego -- elementyelementy

Dziedzinaprzedmiotowa

Dziedzinaprzedmiotowa

Wspomaganie

ModeleDP

ModeleDP

Narz�dzia komputerowego

wspomagania

Narz�dzia komputerowego

wspomagania

Metodyi techniki

Metodyi techniki

Zadania

Para-metry Pakiety

Fazy

Dokumentacja

Poj�ciaabstrakcyjne

Regu�ymodelowania

Systeminformatyczny

Systeminformatyczny

PROCES

TWORZENIA

SYSTEMU

INFORMATYCZNEGO

PROCES

TWORZENIA

SYSTEMU

INFORMATYCZNEGO

Zespó�projektuj�cy

Zespó�projektuj�cy

Kryteriaoceny

Kryteriaoceny

Korekty i modyfikacje

Prezentacjai eksperymentalnaeksploatacja

Akceptacja

Tworzeniesystemu

Kierowanie projektami

Wynikianaliz

Cele, problemy,potrzeby informatyczne

�ród�o: S. Wrycza, Analiza i projektowanie systemów informatycznych zarz�dzania. Metodyki, techniki, narz�dzia, PWN,Warszawa 1999.

1.2 �ródªa zªo»ono±ci procesu tworzenia SI

• Dziedzina przedmiotowa, badany wycinek rzeczywisto±ci, obejmuj¡cy ogromn¡ liczb¦ wzajemnie uza-le»nionych aspektów i problemów

• Zespóª projektuj¡cy - ograniczenia pami¦ci, percepcji, wyra»ania informacji i komunikacji

I jeszcze 2 punktu z tego slajdu, nie bardzo wiadomo, czemu na tym dlajdzie.

• Modele DP, metody i itechniki, narz¦dzia wspomagania komputerowego � warsztat analityka projek-tanta syste

• System informatyczny przekazany do oceny, a nast¦pnie u»ytkowania potencjalnym u»ytkownikom

1.3 Jak minimalizowa¢ zªo»ono±¢?

• Zasada dekompozycji - rozdzielenie problemu na podproblemy (które mo»na rozpatrywa¢ niezale»nieod siebie i niezale»nie od caªo±ci)

• Zasada abstrakcji - eliminacja, ukrycie lub pomini¦cie mniej istotnych szczegóªów rozwa»anego przed-miotu lub mniej istotnej informacji; wyodr¦bnianie cech wspólnych i niezmiennych dla pewnego zbiorubytów i wprowadzaniu poj¦¢ lub symboli oznaczaj¡cych takie cechy

1

• Zasada ponownego u»ycia - wykorzystywanie schematów, metod, wzorców, komponentów projektu,komponentów oprogramowania, itd.

• Zasada sprzyjania naturalnym ludzkim wªasno±ciom - dopasowanie modeli poj¦ciowych i modeli real-izacyjnych systemów do wrodzonych ludzkich wªasno±ci psychologicznych, instynktów oraz mentalnychmechanizmów percepcji i rozumienia ±wiata

1.4 Metodyka tworzenia systemu informatycznego - wymagania

• metodyka powinna obj¡¢ caªy cykl »ycia systemu informatycznego

• metodyka powinna obejmowa¢ ró»norodne, dostosowane do specy�ki podej±cia, metody, techniki inarz¦dzia komputerowe wspomagaj¡ce proces tworzenia systemu i analiz¦

• metodyka powinna uªatwia¢ porozumiewanie si¦ pomi¦dzy ró»nymi grupami zawodowymi tworz¡cymiSI

• metodyka powinna by¢ stosunkowo ªatwa w u»ytkowaniu, powinna móc ewoluowa¢ i podlega¢ mody-�kacjom

1.5 Klasy�kacja metodyk teorzenia SI

Kryteria oceny metodyk:

• podej±cie do procesu tworzenia SI (metodyki techniczne lub spoªeczne)

• de�niowanie danych lub procesów w projekcie (podej±cie strukturalne)

• oddziaªywanie SI na dziedzin¦ przedmiotow¡ (organizacyjne odwzorowanie, organizacyjne sterowanie)

• kierunek tworzenia systemów informatycznych (top-down, buttom-up)

Podej±cia metodologiczne do tworzenia SI

• strukturalne

• obiektowe

• spoªeczne

1.6 Etapy tworzenia, wdra»ania i stabilizacji SI

Zadania na poszczególnych etapach:

• Wst¦pne rozpoznanie systemu - identy�kacja celu, problemów, stanu obecnego i perspektyw rozwojusystemu lub jego zmian

• Analiza informacyjna systemu - identy�kacja otoczenia, ª¡czno±ci z otoczeniem, podsystemów, skªad-owych systemu oraz obecnych i przyszªych warunków jego dziaªania

• Projekt systemu - stworzenie modelu obecnego lub przyszªego systemu, projekt techniczny systemu lubzmian

• Oprogramowanie (kodowanie) - oprogramowanie :)

• Wdro»enie (zastosowanie, aplikacja) - instalacja i stworzenie dokumentacji systemu oraz testowaniesystemu (w wypadku niepowodzenia powrót do etapu analizy lub projektowania)

• Uruchomienie (realizacja) - monitoring, ocena i mody�kacje systemu

2

1.7 Cykl »ycia systemu

Cykl »ycia systemu to ci¡g wyodr¦bnionych, wzajemnie spójnych etapów, pozwalaj¡cych na peªne i skutecznezaprojektowanie a nast¦pnie u»ytkowanie systemu informatycznego .

2 Cykle (modele)

2.1 Tradycyjne cykle »ycia oprogramowania

1. Kaskadowy (klasyczny, waterfall)

2. V

3. Prototypowy

4. Spiralny

5. Przyrostowy

2.1.1 Model kaskadowy (klasyczny, waterfall)

Model kaskadowy (ang. waterfall model) � jeden z kilku rodzajów procesów tworzenia oprogramowaniazde�niowany w in»ynierii oprogramowania. Jego nazwa wprowadzona zostaªa przez Winstona W. Royce wroku 1970, w artykule "Managing the Development of Large Software Systems" (zarz¡dzanie tworzeniemdu»ych systemów informatycznych). Polega on na wykonywaniu podstawowych czynno±ci jako odr¦bnych fazprojektowych, w porz¡dku jeden po drugim.

Klasyczny cykl �ycia systemu z iteracjamiKlasyczny cykl �ycia systemu z iteracjami

��

��

��

��

��

��

��

�

�ród�o: S. Szejko (red.), Metody wytwarzania oprogramowania, Wyd. MIKOM, Warszawa 2002.

Ka»da czynno±¢ to kolejny schodek (kaskada):

1. Planowanie systemu (w tym Specy�kacja wymaga«)

2. Analiza systemu (w tym Analiza wymaga« i studium wykonalno±ci)

3

3. Projekt systemu (poszczególnych struktur itp.)

4. Implementacja (wytworzenie kodu)

5. Testowanie (poszczególnych elementów systemu oraz elementów poª¡czonych w caªo±¢)

6. Wdro»enie i piel¦gnacja powstaªego systemu.

Je±li która± z faz zwróci niesatysfakcjonuj¡cy produkt cofamy si¦ wykonuj¡c kolejne iteracje a» do momentukiedy otrzymamy satysfakcjonuj¡cy produkt na ko«cu schodków.

Wady:

• Nie mo»na przej±¢ do nast¦pnej fazy przed zako«czeniem poprzedniej

• Model ten posiada bardzo nieelastyczny podziaª na kolejne fazy

• Iteracje s¡ bardzo kosztowne - powtarzamy wiele czynno±ci

Tego typu modelu nale»y u»ywa¢ wyª¡cznie w przypadku gdy wymagania s¡ zrozumiaªe i przejrzyste,poniewa» ka»da iteracja jest czasochªonna i wymaga du»ych wydatków na ulepszanie.

2.1.2 Model V

http://en.wikipedia.org/wiki/V-Model_%28software_development%29

Schemat wytwarzania wed�ug modelu VSchemat wytwarzania wed�ug modelu V

��

��

��

��

��

��

��

��

��

�

�

�

� �

�

�

�


2.1.3 Model prototypowy

Model prototypowy tworzenia oprogramowania polega na stworzeniu podczas projektowania prototypu wcelu przedyskutowania oraz akceptacji z klientem. Po akceptacji prototypu przechodzi si¦ do kolejnychetapów tworzenia oprogramowania. Prototypowanie zapobiega bª¦dnym zrozumieniem wymaga« systemu,które mo»e powodowa¢ wzrost kosztów, zwªaszcza w modelu kaskadowym. Spis tre±ci [ukryj]

4

Schemat prototypowaniaSchemat prototypowania

��

��

��

��

��

��

��

��

��

��

��


Zalety prototypowania

• Prototyp jest ªatwy do zmiany

• Zwi¦ksza zrozumienie programistów co do potrzeb klienta

• Pozwala klientowi zobaczy¢ jak mniej wi¦cej system b¦dzie wygl¡daª

• W zale»no±ci od rodzaju prototypu, mo»e pozwala¢ rozpocz¡¢ szkolenie obsªugi systemu po stronieklienta

• Redukcja kosztów

Wady

• Mo»liwo±¢ nieporozumie« z klientem (klient widzi prawie gotowy produkt, który w rzeczywisto±ci jestdopiero w pocz¡tkowej fazie rozwoju)

• Wysoki koszt budowy systemu

Rodzaje prototypów

• Zªy system wykonany za pomoc¡ modelu odkrywkowego, którym stosunkowo szybko si¦ wykonuje

• Rozpisanie interfejsów na kartce papieru

• Implementacja jedynie kilku moduªów

• U»ycie kreatorów w celu szybszego stworzenia interfejsów

• Implementacja metod dziaªaj¡cych jedynie w wi¦kszo±ci przypadków lub dla niektórych danych w celupokazanie jedynie idei.

5

2.1.4 Model spiralny

Proces tworzenia ma posta¢ spirali, której ka»da p¦tla reprezentuje jedn¡ faz¦ procesu. Najbardziej wewn¦trznap¦tla przedstawia pocz¡tkowe etapy projektowania, np. studium wykonalno±ci, kolejna de�nicji wymaga«systemowych, itd. Spis tre±ci [ukryj]

Ka»da p¦tla spirali podzielona jest na cztery sektory:

• Ustalanie celów - De�niowanie konkretnych celów wymaganych w tej fazie przedsi¦wzi¦cia. Identy�kacjaogranicze« i zagro»e«. Ustalanie planów realizacji.

• Rozpoznanie i redukcja zagro»e« - Przeprowadzenie szczegóªowej analizy rozpoznanych zagro»e«, ich¹ródeª i sposobów zapobiegania. Podejmuje si¦ odpowiednie kroki zapobiegawcze.

• Tworzenie i zatwierdzanie - Tworzenia oprogramowania w oparciu o najbardziej odpowiedni model,wybrany na podstawie oceny zagro»e«.

• Ocena i planowanie - Recenzja post¦pu prac i planowanie kolejnej fazy przedsi¦wzi¦cia b¡d¹ zako«czenieprojektu.

Cykl spiralny wytwarzania oprogramowaniaCykl spiralny wytwarzania oprogramowania

��

��

��

��

��

��

��

��

��


Cechy

• Widoczn¡ cech¡ modelu spiralnego jest szczegóªowe potraktowanie zagro»e« realizacji projektu. Dobrzerozpoznane zagro»enia i przedsi¦wzi¦te kroki im zapobiegania lub redukcji skutkuj¡ m.in. wysok¡niezawodno±ci¡ (dependability) powstaj¡cego oprogramowania, b¡d¹ pewno±ci¡, »e projekt ma szansedalszej realizacji.

• W modelu spiralnym nie ma takich faz jak specy�kowanie albo projektowanie. Jeden cykl spiralimo»e przebiega¢ w oparciu o model kaskadowy procesu tworzenia oprogramowania, w innym mo»nau»y¢ prototypowania lub przeksztaªce« formalnych, w zale»no±ci od aktualnego etapu przedsi¦wzi¦cia/ realizowanej cz¦±ci systemu (np. inny dla tworzenia interfejsu u»ytkownika, inny dla krytycznychfunkcji bezpiecze«stwa)

6

• Ka»dy cykl wymaga formalnej decyzji o kontynuacji projektu.

Zalety

• Mo»na wykorzysta¢ gotowe projekty

• Faza oceny w ka»dym cyklu pozwala unikn¡¢ bª¦dów lub wcze±niej je wykry¢

• Caªy czas istnieje mo»liwo±¢ rozwijania projektu.

Wady

• Metodologia nie do ko«ca dopracowana. Ka»dy projekt jest inny i powstaje w innych warunkach.Ci¦»ko okre±li¢ jakie warunki bra¢ pod uwag¦.

• Tworzenia w oparciu o model spiralny wymaga do±wiadczenia w prowadzeniu tego typu projektów orazcz¦sto wiedzy ekonomicznej w zarz¡dzaniu.

Zastosowanie Model spiralny z racji ogólnego charakteru stosuje si¦ przy du»ych projektach.

2.1.5 Model przyrostowy

Podej�cie przyrostowePodej�cie przyrostowe

��

��

��

��

��

��

��

��

��

��

��

�

�


Fazy

• okre±lenie caªo±ci wymaga« (w ramach naszych mo»liwo±ci, na tyle na ile uda nam si¦ j¡ sprecyzowa¢),wykonanie wst¦pnego, ogólnego projektu caªo±ci systemu

• wybór pewnego podzbioru funkcji systemu

• szczegóªowy projekt (wg modelu kaskadowego) oraz implementacja cz¦±ci systemu realizuj¡cej wybranefunkcje

7

• testowanie zrealizowanego fragmentu i dostarczenie go klientowi

• powtarzanie kolejnych etapów, a» do zako«czenia implementacji caªego systemu

Zalety

• cz¦ste kontakty z klientem (skrócenie przerw w porównaniu z modelem kaskadowym)

• brak konieczno±ci zde�niowania z góry caªo±ci wymaga« (na wst¦pie de�niujemy co nam si¦ uda maj¡cnadziej¦, »e uda nam si¦ wyspecy�kowa¢ caªo±¢ wymaga« na etapie testowania zrealizowanych frag-mentów)

• wczesne wykorzystanie przez klienta fragmentów systemu (funkcjonalno±ci)

• mo»liwo±¢ elastycznego reagowania na opó¹nienia realizacji fragmentu � przyspieszenie prac nad inn¡/innymicz¦±ciami (sumarycznie � bez opó¹nienia caªo±ci przedsi¦wzi¦cia projektowego)

Wady

• dodatkowy koszt zwi¡zany z niezale»n¡ realizacj¡ fragmentów systemu

• potencjalne trudno±ci z wycinaniem podzbioru funkcji w peªni niezale»nych

• dlatego: konieczno±¢ implementacji szkieletów (interfejs zgodny z docelowym systemem) � dodatkowynakªad pracy (koszt), ryzyko niewykrycia bª¦dów w fazie testowania

Uwagi

• Stosuje si¦ do przypadków, gdy dopuszczalna jest okrojona funkcjonalno±¢ systemu.

2.2 Wspóªczesne cykle wytwarzania oprogramowania

1. Prototypowanie wytwórcze

2. Cykl wytwarzania obiektowego

3. Proces wytwarzania z wykorzystaniem zasobów ponownego u»ycia

4. Cykl »ycia systemu wedªug metodyki SSM (Soft Systems Methodology)

8

2.2.1 Procesy prototypowania wytwórczego

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

PROTOTYPOWANIE

WYMAGA�


9

2.2.2 Cykl wytwarzania obiektowego

��

��

��

��

��

��

��


��

��

��

��

��

��

��

��

��

��

��

��


10

2.2.3 Zasoby ponownego u»ycia

• komponenty oprogramowania (jednostki monta»owe oprogramowania, których interfejsy s¡ okre±lonena drodze umów i których kontekstowe zale»no±ci s¡ jawne)

• wzorce oprogramowania (formy reprezentacji wiedzy i do±wiadczenia projektantów w postaci opisówtypowych problemów wyst¦puj¡cych w tworzeniu oprogramowania oraz ich rozwi¡za«, które mog¡ by¢wielokrotnie wykorzystywane w ró»nych okoliczno±ciach)

� wzorce analizy (analysis patterns)

� wzorce projektowe (design patterns)

� wzorce architektoniczne (architecture patterns)

� wzorce aplikacji (application frameworks)

3 Technologie wytwarzania oprogramowania

• strukturalna

• obiektowa

Ogólne zasady (niezale»nie od technologii):

• dekompozycji

• modularyzacji

Podej±cie techniczne (hard approaches)

Cykle »ycia i wytwarzania oprogramowania bazuj¡ce na nast¦puj¡cych zaªo»eniach:

• istnieje dobrze identy�kowalny wycinek rzeczywisto±ci, o pewnym stanie i uporz¡dkowaniu, który mo»eby¢ przedmiotem informatyzacji

• cele analizy i konstrukcji systemu s¡ jasne i znane, a docelowy system jest dobrze okre±lony

• przej±cie od stanu aktualnego do systemu docelowego mo»e by¢ zrealizowane ±rodkami technicznymi

• mo»liwe jest porównanie systemu docelowego z istniej¡cym, przy u»yciu miar technicznych

• procesy analizy i konstrukcji wykonywane s¡ przez ekspertów.

Do podej±¢ technicznych nale»¡ m.in. cykl kaskadowy, model spiralny, prototypowanie wytwórcze, podej±cieprzyrostowe, model fontannowy, ponowne wytwarzanie.

Podej±cia spoªeczne (soft approaches)

• zakªadaj¡ nierozª¡czno±¢ aspektów technicznych systemów informatycznych od aspektów pozatech-nicznych � organizacji, zarz¡dzania, socjologii, psychologii itd.

• jednym z najbardziej znanych podej±¢ spoªecznych jest SSM (Soft Systems Methodology).

3.1 Technologia strukturalna

3.1.1 Ogólna charakterystyka

• wytwarzanie oprogramowania wedªug reguª cyklu klasycznego

• utworzenie logicznego modelu systemu poprzedza modelowanie �zyczne

• dominuje w latach 80-tych i na pocz¡tku lat 90-tych

• notacje gra�czne: diagramy przepªywu danych, diagramy przej±¢ stanów, diagramy zwi¡zków encji,diagramy struktury

11

3.1.2 Podstawowe metody strukturalne:

• Modele zwi¡zków encji (diagramy zwi¡zków encji, diagramy relacyjne danych, Entity RelationshipDiagrams, Entity Relationship Models)

• Diagramy przepªywu danych (diagram b¡bli, DataFlow Diagram)

• Sªownik/Skorowidz danych (Data Dictionary)

• Specy�kacje procesów (Process Speci�cation)

• Diagramy sieci przej±¢ (State Transition Diagram)

• Grafy podej±cia ISAC (Information Systems Work and Analysis of Changes)

• Techniki decyzyjne (tablice, drzewa decyzyjne) Diagramy struktury (Structure Charts)

Konkretnie modele te s¡ opisane na slajdach 29-52.

3.1.3 Wady i zalety technologii strukturalnej

Zalety:

• uwzgl¦dnienie wszystkich podstawowych faz cyklu »ycia oprogramowania, podziaªem na fazy analizy iprojektowania

• intuicyjno±¢ spojrzenia na system poprzez funkcje, procesy i przepªywy danych

• poªo»enie nacisku na modelowanie na poziomie logicznym, i skupienie uwa dopiero w dalszej kolejno±cina szczegóªach implementacyjnych

• wprowadzenie �standardów� w zakresie modeli i notacji gra�cznych

• wykorzystywanie narz¦dzi CASE

Wady:

• wysoka pracochªonno±¢

• trudno±ci w iteracyjnym mody�kowaniu projektu

• stosowanie odmiennych modeli w fazie analizy i w fazie projektowania

3.2 Technologia obiektowa

Podstawowe poj¦cia:

• Obiekt

• To»samo±¢ obiektu, identy�kator

• Atrybuty i metody obiektów

• Polimor�zm

• Przesyªanie komunikatów

• Klasy obiektów, hierarchie klas

• Dziedziczenie

• Enkapsulacja (hermetyzacja)

• Uni�ed Modeling Language

12

Projektowanie systemów informatycznych - LK -...

Documents

Transcript of Projektowanie systemów informatycznych - LK -...