Obiektowe modelowanie systemów informatycznych



Pobieranie 8,01 Mb.
Strona16/113
Data23.10.2017
Rozmiar8,01 Mb.
1   ...   12   13   14   15   16   17   18   19   ...   113

Życiowy cykl tworzenia systemu informatycznego


UML jest w zasadzie niezależny od przyjętych procedur projektowych, co oznacza , że nie jest dostosowany do jakiegokolwiek szczególnego cyklu tworzenia oprogramowania. Przynosi jednak największe korzyści w procesie, który jest:

W procesie ukierunkowanym na przypadki użycia systemu, to właśnie one służą do określania pożądanego zachowania systemu, do weryfikacji i atestowania jego architektury oraz do testowania go. Są także wykorzystywane w porozumiewaniu się członków zespołu programistycznego między sobą.

W procesie architekturocentrycznym właśnie architektura jest najważniejszym artefaktem używanym do wyrażenia koncepcji tworzonego systemu, konstruowania go, zarządzania nim i do rozwijania go.

Plonem procesu iteracyjnego jest ciąg kolejnych działających wersji systemu. Proces przyrostowy polega na systematycznym dopełnianiu architektury systemu w celu utworzenia tych wersji, przy czym każda z nich zawiera pewne nowe składniki i ulepszenia, które nie występują w wersji poprzedniej. Proces iteracyjny i przyrostowy zarazem jest jednocześnie procesem sterowanym ryzykiem (Risk – driven), ponieważ przy tworzeniu każdej nowej wersji kładzie się nacisk na wyeliminowanie czynników, które najbardziej zagrażają powodzeniu na danej iteracji.

Proces ukierunkowany na przypadki użycia systemu, architekturocentryczny, iteracyjny i przyrostowy można podzielić na etapy lub fazy (Phase). Etap to jest okres między kolejnymi głównymi kamieniami milowymi procesu, w którym zostały osiągnięty pewne ściśle ustalone cele, ukończone produkty pracy i podjęto decyzje o przejściu do następnego etapu.


Diagramy klas (Class diagram)


Diagram klas obrazuje pewien zbiór klas, interfejsów i kooperacji oraz związki między nimi. Jest grafem złożonym z wierzchołków i krawędzi. Diagramów klas używa się do modelowania statycznych aspektów perspektywy projektowej. Diagramy przypadków użycia to są dynamiczne aspekty. Wiąże się z tym w głównej mierze modelowanie słownictwa systemu(dziedziny problemu), kooperacji lub schematów. Diagramy klas stanowią bazę wyjściową dwóch innych diagramów, a mianowicie diagramów komponentów i diagramów wdrożenia.

Diagramy klas zawierają następujące elementy:



  • klasy,

  • interfejsy,

  • kooperacje,

  • zależności, uogólnienia i powiązania.

Na diagramach klas mogą się znaleźć również pakiety lub podsystemy, używane do grupowania elementów modelu.

Diagramy klas mogą być w dwóch postaci:



  • Diagramy klas konceptualnych dziedziny problemu

  • Diagramy klas modelu projektowania.

UML nie zawiera odrębnych artefaktów dla projektowania tych diagramów. Dla tych dwóch diagramów są wykorzystywane te same narzędzie oraz jeden artefakt „Diagram klas”.

Modelowanie dziedziny problemu


Dziedzina problemu (problem domain) (lub dziedzina przedmiotowa, słownictwo systemu) to jest fragment świata rzeczywistego będący przedmiotem rozważań przy obiektową analizie i projektowaniu systemu informacyjnego. Głównej składnią tej analizy musi być dekompozycja problemu na oddzielnie klasy pojęć lub klasy konceptualne. Modelowanie dziedziny problemu powoduje wszystkim innym etapom modelowania.

Model dziedziny problemu to jest przedstawienie wizualne klas konceptualnych zgodnie z pojęciami tej dziedziny. Klasa konceptualna to jest pojęcie światu rzeczywistego. Te klasy muszą być głównymi wśród wszystkich pojęć i abstrakcji dziedziny modelowania oraz składać się słownictwo systemu. W klasach konceptualnych nie jest wyznaczone zachowanie systemu. Pojęcia, kategorii i abstrakcji tego słownictwa muszą być wykorzystywane w opisu scenariuszy diagramów przypadków użycia oraz innych diagramów dynamicznych. W ten sposób realizują się związki między modelami statycznymi i dynamicznymi.

W odróżnieniu od klas konceptualnych klasy programowe (klasy projektowania) to są specyfikacji lub realizacji komponentów systemu, które odwzorowują zachowanie systemu, np. Okna dialogowe, Interfejs z bazą danych itp.

W UML słownictwo systemu prezentuje się w wyglądu zbioru diagramów klas, na których nie jest koniecznym zdefiniowanie operacji oraz atrybutów. Model dziedziny problemu nie jest diagramem klas lub komponentów programowych, z tego modelu nie można wygenerować kod. Ostatecznie definiowanie atrybutów oraz operacji klas będzie zrealizowano na kolejnych etapach modelowania obiektowego przy projektowaniu diagramów interakcji oraz diagramów klas. Model dziedziny problemu może odwzorować następne elementy:



  • Konceptualne klasy.

  • Związki semantyczne między konceptualnymi klasami.

  • Atrybuty konceptualnych klas.

Przy projektowaniu modelu dziedziny problemu, kolejnej analizie i wyznaczeniu przypadków użycia mogą być realizowano kilka iteracji. Model dziedziny problemu musi być uściślony na każdej z tych iteracji. Przy tym, mogą być zdefiniowane nowe konceptualne klasy, atrybuty, związki semantyczne.

Przykład modelu dziedziny problemu jest pokazany na rys.44 . Ten model jest stworzony dla modelowania systemu informacyjnego sprzedaży artykułów w sklepie. Scenariusz zakupu - sprzedaży może mieć następny wygląd:



  1. Klient(Customer) wchodzi do sklepu (Store), wybiera towary (item) oraz idzie do aparatu kasowego(register).

  2. Kasjer (Cashier) odkrywa nowy zakup (Sale).

  3. Kasjer odczyta identyfikator towaru i wprowadzi go do systemu informacyjnego.

  4. System informacyjny odczyta nazwę odebranego towaru, go opis(description) i cenę(price). Kasjer powtórzy czynności p.3,4 dla każdej pozycji towaru (SalesLineItem).

  5. Kasjer informuje klienta pro wartość wypłaty (Payment) i otrzymuje pieniędzy.

  6. Klient płaci się oraz system modyfikuje dani sklepu zgodnie z rezultatami zakupu.

  7. System rejestruje zakup w rejestrze(Register) sklepu.

  8. System drukuje paragon .


Rys.44


Pomiędzy klasami konceptualnymi mogą być ustalone związki, kiedy niema wątpliwości odnośnie realizacji programowej tych klas. W klasach mogą być ustalone atrybuty, kiedy one są oczywistymi. W przypadkach, kiedy nie do końca jasnym jest zachowanie klasy oraz czy musi być obiekt rzeczywisty klasą lub atrybutem, lepiej zostawić klasy konceptualne w ogóle bez związków oraz obiekty rzeczywiste w postaci klasy.

Na rys. 44 a jest pokazany fragment modelu dziedziny problemu razem ze związkami pomiędzy klasami konceptualnymi.



Rys. 44 a

Klasy konceptualne modelu dziedziny problemowej mogą być wyznaczone różnymi sposobami. Rozpowszechnionymi sposobami wyznaczenia klas konceptualnych są sposoby:


  1. Wydzielenie rzeczowników z opisów scenariuszy przypadków użycia.

  2. Wykorzystanie listy kategorii klas konceptualnych.

  3. Wykorzystanie wzorców analizy dziedziny problemu.

  4. Analiza dziedziny problemu za dopomogą kart CRC.

Przykład wydzielenia rzeczowników z opisu scenariuszu przypadków użycia jest pokazany wyżej. Przez czcionkę grubą są pokazane rzeczowniki. Rzeczowniki z tego opisu mogą być klasami konceptualnymi, ale to nie jest koniecznie. Rzeczowniki w tym opisu mogą wystąpić jako atrybuty konceptualnych klas lub klasami i atrybutami klas z innych podsystemów. Trzeba szczególnie analizować każdego pretendenta klasy konceptualnej. Wadą tego sposobu jest także to, że język naturalny może mieć niejednoznaczne pojęcia w swoich definicjach. Tak, dla opisu tej samej klasy konceptualnej mogą być wykorzystywane różne rzeczowniki oraz niektórzy rzeczowniki mogą mieć wiele różnych wartości. Niemniej ten sposób pozwoli otrzymać informacje dla analizy modelu dziedziny problemu.

Wykorzystanie listy kategorii klas konceptualnych potrzebuje poprzedniego stworzenia listy kategorii. Przykład list kategorii klas konceptualnych dla dziedzin „Sprzedaży – zakupu” oraz „Zarezerwowania biletów lotniczych” jest pokazany w tabeli.


Tabela.

Kategoria klas konceptualnych

Dziedzina problemu „System sprzedaży – zakupu towarów”

Dziedzina problemu „System rezerwowania biletów na samoloty”

Obiekty fizyczne

Register (rejestr), tablica zamówień

Airplane (samolot)

Specyfikacji, opisy obiektów

ProductSpecification (opis towaru)

FightDescription (opis polotu)

Placówki

Store (Sklep)

Airport (lotnisko)

Transakcji

Sale (zakup), Payment (wypłata), Zamówienie

Reservation (rezerwowanie)

Elementy transakcji

SalesLineItem (element zakupu), dostawa




Roli

Cashier (kasjer)

Pilot

Kontenery innych obiektów

Store (Sklep), koszyk, Zamówienie

Bin (bunkier), Airplane(samolot)

Zawartość kontenerów

Item (element)

Passenger (pasażer)

Systemy zewnętrzne

CreditPaymentAutorization System (system autoryzacji wypłaty kredytowych)

AirTrafficControl (system sterowania ruchem samolotów)

Działy, organizacje

SalesDepartment (dział sprzedaż)

ObiectAirline (linii lotnicze)

Zdarzenia

Sale (Sprzedaż), Payment (wypłata)

Flight (polot), Crash (awaria), Landind (lądowanie)

Reguły

RefundPolicy (reguły powrotu towaru)

CancellationPolicy (reguły anulowania zamówienia)

Katalogi

ProductCatalog (katalog towarów), PartsCatalog (katalog części)




Wydruki, notatki, zapisy

Receipt (paragon), Ledger (książka księgowa)

Maintenancelog (dziennik obsługiwania)

Usługi finansowe

LineOfCredit(linia kredytowa)

LineOfCredit(linia kredytowa)

Stworzenie modelu dziedziny problemu zawiera następne czynności:



  1. Wyznaczenia listy pretendentów klas konceptualnych.

  2. Graficzne odwzorowanie klas konceptualnych.

  3. Dodawanie asocjacji, które odwzorowują związki semantyczne.

  4. Dodawanie atrybutów, które wyznaczają wymogi informacyjne.

Przy wyznaczeniu atrybutów modelu dziedziny problemu trzeba postępować zgodnie z następnymi rekomendacjami:

  1. Do modelu dziedziny problemu trzeba dodawać tylko te atrybuty, dla których są wyznaczone wymogi w scenariusze przypadków użycia lub dla których trzeba przechowywać informację. Np. każdy paragon musi zawierać datę oraz czas sprzedaży, dlatego w klasie konceptualną „Sale” są wyznaczone atrybuty „date” i „time”. W ogóle klasy konceptualne mogą nie zawierać atrybutów.

  2. Typy atrybutów muszą być podstawowymi typami danych oraz nie zawierać typów obiektowych. W przypadkach, gdy atrybut klasy konceptualnej jest typem obiektu innej klasy, trzeba do modelu dziedziny problemu dodać nową klasę oraz wyznaczyć związki semantyczne między klasami. Ta rekomendacja jest ilustrowana rys. 45

Rys.45


  1. Liczebność asocjacji nie jest konieczna w modelu dziedziny problemu.

  2. Operacji do klas konceptualnych można dodawać tylko po analizie przypadków użycia.

  3. Nazwy klas konceptualnych muszą odwzorować semantykę dziedziny problemu.


1   ...   12   13   14   15   16   17   18   19   ...   113


©operacji.org 2017
wyślij wiadomość

    Strona główna