Dziedzina problemu. System. Model. Uzytkownik. Przewoznik. Zleceniodawca Wydawanie opinii. Zarzadzanie pojazdami

Podobne dokumenty
Inżynieria oprogramowania

Inżynieria oprogramowania

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Zagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)

UML a kod w C++ i Javie. Przypadki użycia. Diagramy klas. Klasy użytkowników i wykorzystywane funkcje. Związki pomiędzy przypadkami.

Inżynieria oprogramowania

UML w Visual Studio. Michał Ciećwierz

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

INŻYNIERIA OPROGRAMOWANIA. laboratorium

Zalety projektowania obiektowego

Cel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2

Podstawy inżynierii oprogramowania

Specyfikacja klas. Opis Lista pól Lista metod Ograniczenia. Szacowana lub dokładna liczba obiektów tej klasy Trwałość

Podstawy programowania III WYKŁAD 4

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 2 Ćwiczenia w narzędziu CASE diagram klas. Materiały dla nauczyciela

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram czynności. Materiały dla nauczyciela

Inżynieria oprogramowania

Podstawy języka UML2 w realnych projektach

Michał Adamczyk. Język UML

UML a kod. C++, Java i C#

Określanie wymagań. Cele przedsięwzięcia. Kontekst przedsięwzięcia. Rodzaje wymagań. Diagramy przypadków użycia use case diagrams

MODELOWANIE OBIEKTOWE

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 1 Wprowadzenie do narzędzia CASE. Materiały dla nauczyciela

Podstawy projektowania systemów komputerowych

ZARZĄDZANIU. Wykład VI. dr Jan Kazimirski

Język UML w modelowaniu systemów informatycznych

Zasady organizacji projektów informatycznych

TECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek

Diagramy klas. WYKŁAD Piotr Ciskowski

Zagadnienia Semestr IV Inżynieria Oprogramowania WSZiB

Analiza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji

Diagramy przypadków użycia

WPROWADZENIE DO UML-a

Inżynieria oprogramowania

Wprowadzenie do UML, przykład użycia kolizja

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 5 Ćwiczenia w narzędziu CASE diagram przypadków uŝycia. Materiały dla nauczyciela

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI

Informatyzacja przedsiębiorstw WYKŁAD

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD

Spis treści. Analiza i modelowanie_nowicki, Chomiak_Księga1.indb :03:08

Inżynieria oprogramowania II

UML cz. I. UML cz. I 1/1

IX Konferencja Informatyki Stosowanej

TECHNOLOGIE OBIEKTOWE. Wykład 3

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 3 Ćwiczenia w narzędziu CASE diagram sekwencji. Materiały dla nauczyciela

Diagramy UML, przykład problemu kolizji

Modelowanie obiektowe - Ćw. 3.

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

Procesowa specyfikacja systemów IT

Modelowanie danych, projektowanie systemu informatycznego

Podstawy języka UML2 w realnych projektach

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram czynności. Materiały dla studenta

Spis treúci. 1. Wprowadzenie... 13

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA

Diagramy czynności Na podstawie UML 2.0 Tutorial

Analiza i projektowanie obiektowe 2017/2018. Wykład 3: Model wiedzy dziedzinowej

Inżynieria oprogramowania

Modelowanie i analiza systemów informatycznych

Diagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji

Technologie obiektowe. Plan. Ewolucja technik wytwarzania oprogramowania

Modelowanie obiektowe - Ćw. 6.

Ćwiczenie 1. Modelowanie prostego procesu

Techniki modelowania programów Kod przedmiotu

Modelowanie diagramów klas w języku UML. Łukasz Gorzel @stud.umk.pl 7 marca 2014

1 Projektowanie systemu informatycznego

Identyfikacja i modelowanie struktur i procesów biologicznych

Analiza biznesowa a metody agile owe

UML. dr inż. Marcin Pietroo

Inżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia

KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH

Podstawy modelowania programów Kod przedmiotu

Faza analizy (modelowania) Faza projektowania

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Diagramy przypadków użycia

Podstawy języka UML UML

Rysunek 1: Przykłady graficznej prezentacji klas.

Modelowanie obiektowe

Dariusz Brzeziński. Politechnika Poznańska, Instytut Informatyki

Wykład 1 Inżynieria Oprogramowania

Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation)

Modelowanie obiektowe - Ćw. 1.

Modelowanie klas i obiektów. Jarosław Kuchta Projektowanie Aplikacji Internetowych

MAS dr. Inż. Mariusz Trzaska

12) Wadą modelu kaskadowego jest: Zagadnienia obowiązujące na egzaminie z inżynierii oprogramowania: 13) Wadą modelu opartego na prototypowaniu jest:

Projekt systemu informatycznego

Systemy informatyczne. Modelowanie danych systemów informatycznych

Projektowanie Graficznych Interfejsów Użytkownika Robert Szmurło

Język UML w modelowaniu systemów informatycznych

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym

Kompozycja i dziedziczenie klas

Diagramy klas. dr Jarosław Skaruz

Faza Określania Wymagań

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017

Inżynieria oprogramowania. Jan Magott

Fazy analizy (modelowania) oraz projektowania FAZA ANALIZY:

Modelowanie i analiza systemów informatycznych

Laboratorium 5 - Projektowanie programów zorientowanych obiektowo. Indywidualny projekt programistyczny

INFORMATYKA GEODEZYJNO- KARTOGRAFICZNA. Modelowanie danych. Model związków-encji

Podstawy modelowania biznesowego w inżynierii oprogramowania

Transkrypt:

Analiza/modelowanie Dziedzina problemu Opracowanie logicznego modelu dziedziny problemu Cele: Lepsze zrozumienie dziedziny problemu i lepsze określenie wymagań Podstawa przyszłego projektu Przewoznik Zarzadzanie pojazdami System Uzytkownik Zleceniodawca Wydawanie opinii Zarzadzanie Zarzadzanie Optymalizacja uzytkownikami ladunkami Model Dziedzina problemu Administrator Specyfikacja wymagań Dyrektor ds. hiperzapadalnościowej analizy strategicznej blokuje kumulanty, jak są quasiopcje, to blokuje dziesięć. Żona do informatyka: Kup parówki, jak będą jajka, to kup dziesięć. Informatyk w sklepie: Są jajka? Są. To poproszę dziesięć parówek. Jak to wyjaśnić? Kup parówki, jak będą ładne, to kup dziesięć Kup parówki, jak będzie padało, to kup dziesięć Kup parówki, jak przed sklepem będzie stał czarny mercedes, to kup dziesięć Specyfikacja wymagań Dyrektor ds. hiperzapadalnościowej analizy strategicznej blokuje kumulanty, jak są quasiopcje, to blokuje dziesięć.

Rola semantyki i kontekstu Inżynieria oprogramowania, pierwszy wykład, nudy, brak czasu, nudy, brak czasu, koniec semestru, zaliczenie, zaskoczenie, pustka, dwója, kucie, kucie, kucie, poprawka, trója, radość, Stary Rynek, impreza, ból głowy Analiza/modelowanie Nie zaszkodzi ;-) rozumieć dziedzinę problemu Projektowanie Czy oprogramowanie jest zawsze projektowane? Projektowanie to nie rysowanie diagramów, to podejmowanie decyzji Znaczenie projektowania dla sukcesu produktu Projektowanie jest jak planowanie Średnio rzecz biorąc, ten kto planuje/projektuje wychodzi na tym lepiej Projektowanie Wartościowy jest sam proces planowania/projektowania Np. pozwala odrzucić nierealne pomysły Nigdy: żaden program nie został napisany w 00% zgodnie z projektem ale też nigdy żaden program nie został napisany w 00% bez wykorzystania projektu Podstawowa zasada projektowania Program powinien mieć naturalną strukturę Projektowanie a wyniki fazy analizy Nazwa Adres REGON Koszt() Klient Pojazd Typ pojazdu Nazwa Ladownosc Pojemnosc Cena kilometra Cena godziny class CPojazd {... public: double Koszt (double Czas, double Droga); };... double CPojazd::Koszt (double Czas, double Droga) {... }; lass Cklient {... }; class CTypPojazdu {... }; Klient +Nazwa : char #Adres : char Typ pojazdu #REGON : char +Nazwa : char +Dodaj samochod(){sequential} +Ladownosc : double +Pojemnosc : double +Cena kilometra : double +Cena godziny : double +Edytuj(){polymorphic,sequential} Pojazd +Nazwa : char #Cena kilometra : double -Cena godziny : double +Koszt(in Czas : double, in Droga : double) : double{polymorphic,sequential} 2

Dlaczego notacje graficzne w modelowaniu Ogromny wzrost precyzji Ogromna poprawa efektywności Zapis modelu Analiza modelu Wprowadzanie zmian Łatwe przejście do projektowania Unified Modeling Language - UML Obiektowa notacja graficzna służąca do modelowania, projektowania i specyfikacji oprogramowania Następca licznych notacji obiektowych z lat 80-tych i 90-tych Powstał na bazie metod Boocha, Rumbaugh (OMT) i Jacobsona stworzony przez tych właśnie autorów Unified Modeling Language - UML Standard Object Management Group (OMG) Wspierany przez firmę Rational De facto standard przemysłowy Pierwsza wersja w 997 Notacja, a nie metodyka Diagramy przypadków użycia use case diagrams modelowanie wymagań Użytkownik, klasa użytkowników, system zewnętrzny (ang. actor) Grupa użytkowników wykorzystujących system w podobny sposób Przypadek użycia, wymaganie funkcjonalne, funkcja (ang. use case) Korzystanie z funkcji (ang. actor flow) Związki używania (uses)) i rozszerzania (extends) 3

Przykład i związek generalizacji (generalization) Diagramy klas Model statyczny Uzytkownik Przewoznik Wydawanie opinii Zleceniodawca Zarzadzanie pojazdami Optymalizacja Zarzadzanie uzytkownikami Zarzadzanie ladunkami Administrator Obiekt Składowa dziedziny problemu posiadająca: tożsamość dane go opisujące zachowanie Klasa Wzorzec, uogólnienie grupy obiektów opisywanych za pomocą podobnych danych i mających podobne zachowanie Samochody Obiekty wewnętrzne systemu, dane np. wektor, plik, raport, drzewo binarne, okno, dokument elektroniczny Obiekty zewnętrzne, metadane osoba, samochód, dokument papierowy, projekt Nazwa Operacje Samochód Nazwa Stan Dodaj ladunek() Podaj nazwe() Pola Związek generalizacji specjalizacji (generalization-specialization link/association) Pojazd Wiele generalizacji Samochod Samochod osobowy Pojazd Samochod ciezarowy Samochód Samochód ciężarowy Samochód osobowy 4

Związek klas (class link/assciations) Uogólnienie możliwych powiązań obiektów Osoba.. Artykul Krotności związków (multiplicity) 0.. zero lub jeden, opcjonalny dokładnie jeden, wymagany - dowolna liczba.. - jeden lub więcej N..M od N do M N dokładnie N Przykłady Opisy związków Osoba.. Artykul Rola Nazwa Pracownik.. 0.. Przelozony Osoba Autor Autorstwo Artykul.. Bank Konto Student 0-9 Grupa laboratoryjna Różne związki pomiędzy tymi samymi klasami Związek pomiędzy obiektami tej samej klasy Osoba Wykonawca Projekt Kierownik Dziecko Rodzic Osoba 0-2 5

Ograniczenia dotyczące związków Związek kompozycji (composition) Rysunek Figura {ordered} Wydzial 0.... Instytut {Dziecko.Data urodzenia > Rodzic.Data_urodzenia} Osoba Dziecko 0-2 Rodzic Przykład - giełda usług przewozowych Przykład grafika wektorowa Nazwa Rysunek Rysuj() Nacisniecie przycisku(in Polozenie kursora) Ruch myszy() Zaznacz figury() Figura {ordered} {ordered} W obszarze() : bool Warstwa Rysuj() W obszarze figur() Linia Punkty Kolor Styl Rysuj() Wielokat Punkty Kolor linii Styl linii Kolor wype³nienia Styl wype³nienia Polozenie Rysuj() Punkt Przykład czasopismo naukowe Diagramy stanów Model dynamiczny Zastosowania: Modelowanie zmian stanów (grup) obiektów Modelowanie reakcji na zdarzenia Modelowanie algorytmów 6

Zdarzenie (event) Zjawisko, które zachodzi w pewnym punkcie czasu, np.: odjazd pociągu do Gdańska, wprowadzenie danych, wybranie polecenia z menu, przekroczenie temperatury 50 o C. Zdarzenia Zdarzenie zewnętrzne zachodzi poza systemem, np.: wprowadzenie danych, wybranie polecenia z menu, przerwanie przez użytkownika wykonywania operacji. Zdarzenie wewnętrzne zachodzi w ramach systemu, np.: zakończenie wykonywania metody, błąd arytmetyczny, przekroczenie czasu. Stan (state) Okres czasu ograniczony przez dwa zdarzenia System (fragment systemu) znajdując się w różnych stanach reaguje w sposób jakościowo różny na zachodzące zdarzenia. (Stan artykułu w czasopiśmie naukowym) Stany początkowy i końcowy Początkowy Końcowy Przejście (transition) Zmiana stanu w wyniku zdarzenia Może być obwarowane warunkami Zachodzi natychmiastowo (w przybliżeniu) Zdarzenia Warunek Akcja (action) Czynność wykonywana (w przybliżeniu) natychmiastowo w momencie zajścia zdarzenia 7

Aktywność (activity) Działanie wykonywane w czasie kiedy system jest w pewnym stanie Może zostać przerwana w momencie zajścia zdarzenia, które powoduje wyjście ze stanu Jeżeli kończy się samoczynnie, to generuje zdarzenie, które powoduje przejście do innego stanu. Akcje wejściowe i wyjściowe i wewnętrzne / Wlacz monitorowanie U recenzenta entry/wlacz monitorowanie exit/wylacz monitorowanie do/ Monitoruj Przekroczony limit czasu/ Ponaglenie = / Wylacz monitorowanie U recenzenta Przekroczony limit czasu/ Ponaglenie do/ Monitoruj / Wlacz monitorowanie / Wylacz monitorowanie Stan złożony (superstate) Przykład stany artykułu Przykład zaznaczanie i przesuwanie obiektów w programie graficznym Diagramy sekwencji (sequence) Przepływ komunikatów pomiędzy elementami dziedziny problemu 8

: ::Klient Lina życia Czas Obiekt Nazwa obiektu:nazwa klasy : Osoba - nieokreślony obiekt klasy Osoba, Jan Nowak : Osoba - obiekt Jan Nowak klasy Osoba, Jan Nowak : - obiekt Jan Nowak nieokreślonej klasy. Komunikaty : ::Klient : ::Bankomat Synchroniczny Wlozona karta Podaj PIN Asynchroniczny Przykład korzystanie z bankomatu : ::Klient : ::Bankomat : ::Bank Wlozona karta Podaj PIN Wprowadzony PIN Wybierz rodzaj transakcji Wyplata gotowki Podaj kwote Kwota do wyplaty Sprawdz dostepne srodki Dostepne srodki Odbierz karte Karta odebrana Specyfikacja modelu UML jest językiem graficznym Na diagramach można umieszczać szereg dodatkowych informacji ograniczenia, stereotypy, komentarze W praktyce diagramy często wspiera się dodatkową specyfikacją wspiera to szereg narzędzi CASE Gotowka do odbioru Specyfikacja klas Opis Lista pól Lista metod Ograniczenia Np. Wzrost > 0 Płaca minimalna < Płaca maksymalna Szacowana lub dokładna liczba obiektów tej klasy Trwałość Specyfikacja metod opis specyfikacja deklaratywna dane wejściowe dane wyjściowe algorytm warunki wstępne warunki końcowe wyjątki złożoność czasowa złożoność pamięciowa 9

Specyfikacja pól i parametrów typ przechowywanych wartości jednostka miary zakres dopuszczalnych wartości lista możliwych wartości wymagana precyzja wartość domyślna czy pole może być puste ograniczenia metody, które mogą czytać, ustawiać i modyfikować wartości tego pola. Specyfikacja algorytmów - pseudocode Algorytm klasyfikacji na podstawie reguł decyzyjnych Dane wejściowe Uporządkowana (wg. ważności) lista reguł decyzyjnych w postaci: Jeżeli (A =...) i... i (A n...) to Decyzja =... Reguła domyślna z pustą częścią warunkową Obiekt do zaklasyfikowania opisany atrybutami A do A n Algorytm klasyfikacji na podstawie reguł decyzyjnych powtarzaj od reguły najważniejszej do najmniej ważnej jeżeli obiekt spełnia warunki reguły, to podejmowana jest decyzja wskazywana przez regułę dopóki nie podjęto decyzji lub nie sprawdzono wszystkich reguł jeżeli nie podjęto decyzji, to podejmij decyzję wskazywaną przez regułę domyślną Budowa statycznego modelu klas Identyfikacja klas Identyfikacja związków klas Identyfikacja pól Identyfikacja metod Identyfikacja klas Typowe klasy: przedmioty namacalne (np. samochód, czujnik), role pełnione przez osoby (np. pracownik, wykładowca, polityk), zdarzenia, o których system przechowuje informacje (np. lądowanie samolotu, zamówienie, dostawa), interakcje pomiędzy osobami i/lub systemami, o których system przechowuje informacje (np. pożyczka, spotkanie, konferencja), lokalizacje, tj. miejsca przeznaczone dla ludzi lub przedmiotów, Identyfikacja klas Typowe klasy grupy przedmiotów namacalnych (samochody, czujniki), organizacje (np. firma, wydział, związek), koncepcje (np. miara jakości, zadanie), dokumenty (np. prawo jazdy, faktura), klasy będące interfejsami dla systemów zewnętrznych, klasy będące interfejsami dla urządzeń sprzętowych. 0

Identyfikacja klas Analiza dziedziny problemu (problem domain analysis) wykorzystanie wiedzy dziedzinowej literatura seminaria prezentacje rysunki inne modele np. modele procesów biznesowych Analiza opisu w języku naturalnym Rzeczowniki - potencjalne klasy, obiekty lub pola Czasowniki - potencjalne operacje lub związki klas Ma, posiada, obejmuje, składa się, jest częścią, - związki kompozycji Rzeczowniki odczasownikowe związki klas Rzeczowniki mogą oznaczać role pełnione w związkach Przykład Przykład Każdy projekt jest realizowany przez konsorcjum złożone z co najmniej trzech organizacji. Organizacja może być firmą komercyjną, jednostką badawczą lub organizacją publiczną. Organizacja może realizować wiele projektów badawczych.. Każdy projekt ma jednego koordynatora. Identyfikacja klas Wykorzystanie związków klas i obiektów Czy klasa ma potencjalne specjalizacje i/lub generalizacje? Czy klasa ma części składowe i/lub jest częścią większej całości? Czy klasa pozostaje w związkach z innymi klasami? Identyfikacja klas Analiza funkcji Jakie obiekty, jakich klas będą niezbędne do realizacji poszczególnych funkcji

Weryfikacja klas Nieobecność pól i operacji Nieliczne (pojedyncze) pola i operacje Brak związków z innymi klasami Tylko jeden obiekt w klasie Dobrą klasą jest klasa Samochód, złymi Samochód Kowalskiego i Samochód Nowaka. Identyfikacja krotności związków Analiza przykładowych (rzeczywistych lub wymyślonych) powiązań obiektów Weryfikacja związków obligatoryjnych, np. lub.. Czy instytut musi mieć pracowników? Identyfikacja związków kompozycji Zwroty pojawiające się w słownym opisie systemu jak: zawiera, składa się, obejmuje Klasy posiadające części składowe Klasy będące zbiorami pewnych elementów Części składowe Uczelnia Zespol.. 0.... Wydzial Instytut Grupa studencka Podatnicy Zbiory.. Student Podatnik Samochod.. Silnik 2

Identyfikacja związków generalizacji- specjalizacji Dziedziczenie pól i metod Identyfikacja związków generalizacji-specjalizacji Nazwy zawierające się w sobie pracownik i pracownik naukowy samochód i samochód osobowy Wspólne części nazw pracownik naukowy i pracownik techniczny -> generalizacja pracownik Pola, którym nie zawsze można przypisać wartości Metody, które nie zawsze mają sens Związki, które mogą dotyczyć tylko pewnych obiektów Opiekun Pracownik Kolo naukowe Pracownik Kolo naukowe Opiekun Pracownik techniczny Pracownik naukowy Pola służące do rozróżniania obiektów Student zaoczny lub dzienny Rodzaj Student Identyfikacja pól Co jest potrzebne do opisu danej klasy w ramach dziedziny problemu? Jakie dane będą potrzebne operacjom danej klasy do realizacji ich zadań? Jakie pola należy wprowadzić, aby opisać stany w jakich mogą znajdować się obiekty danej klasy? Klasa czy pole? Student dzienny Student zaoczny 3

Weryfikacja związków Czy sensownie brzmi zdanie "A jest rodzajem B" (jeżeli klasa A jest specjalizacją klasy B)? Czy sensownie brzmi zdanie "A [czasownik] B" (jeżeli klasy A i B są związane związkiem klas)? Czy sensownie brzmią zdania "A jest częścią B" lub "B składa się (zawiera) A" (jeżeli obiekty klasy A są składowymi obiektów klasy B)? 4