Obiektowe modelowanie systemów informatycznych



Pobieranie 8,01 Mb.
Strona13/113
Data23.10.2017
Rozmiar8,01 Mb.
1   ...   9   10   11   12   13   14   15   16   ...   113

Cele tworzenia UML


UML ( Unifed Modeling Language) pojawił się w latach 1994-1999, kiedy znaczne wzrosła liczba metod obiektowych. Wielu użytkowników miało kłopoty ze znalezieniem języka modelowania, który w pełni odpowiadałby ich potrzebom. UML to jest rezultat zjednoczenia metod Boocha, Jacobcona oraz Rumbaugha po modelowaniu systemów obiektowych.

Język to jest zasób wyrazów i form określanych przez reguły gramatyczne, służący ludziom jako narzędzie porozumienia się. Język modelowania to taki język, w którym słownictwo i gramatyka są podporządkowane pojęciowej i fizycznej reprezentacji systemu.

Główne cele stworzenia UML:


  1. Modelować system obiektowo – od opracowania koncepcji do wytworzenia działającego produktu (artefaktu).

  2. Wskazać problemy związane ze zwiększaniem skali złożonych systemów.

  3. Opracować język modelowania wygodny dla ludzi i maszyn.

UML bazuje się na koncepcji modelowania komponentów systemu informatycznego.

Definicja Modelu.


Modelowanie prowadzi do lepszego zrozumienia systemu. Model jest uproszczeniem rzeczywistości. Model udostępnia rzuty systemu; może być planem szczegółowym lub ogólniejszym. W modelu są uwzględnione wszystkie istotne elementy, natomiast są pominięte szczegóły, które nie odpowiadają przyjętemu poziomowi abstrakcji. Każdy system może być opisany z wielu punktów widzenia za pomocą różnych modeli. Każdy model jest zatem znaczeniowo domknięta abstrakcja systemu. Wyróżniamy modele struktury, które odwzorowują statyczną budowę systemu, oraz modele zachowania, które opisują aspekty dynamiczne.

Przez modelowanie osiągamy cztery cele:



  1. Łatwiej możemy wyobrazić sobie system taki, jaki jest, lub taki, jaki chcemy, żeby był.

  2. Modelowanie umożliwia wyspecyfikowanie struktury i zachowania systemu.

  3. W wyniku modelowania otrzymujemy szablony, które ułatwiają sterowanie działaniami w trakcie tworzenia systemu.

  4. Modele stanowią dokumentację podjętych przez nas decyzji.

Modele złożonych systemów trzeba opracowywać dlatego, że nie jesteśmy w stanie ogarnąć tych systemów w całości. Zdolność człowieka do panowania nad złożonością czegoś ma swoje granice. Modelowanie umożliwia zawężenie problemu, który rozwiązujemy. Możemy wtedy skupić się na jednym jego aspekcie.

Budowniczowie, elektronicy i matematycy mają swój powszechnie akceptowany język. Taki wspólny język do modelowania przyda się także twórcom oprogramowania.

Język to zasób wyrazów i form określanych przez reguły gramatyczne, służący ludziom jako narzędzie porozumiewania się. Język modelowania to taki język, w którym słownictwo i gramatyka są podporządkowane pojęciowej i fizycznej reprezentacji systemu. UML jest zatem znormalizowanym językiem zapisywania projektu systemu.

Ogólne cechy UML


UML to graficzny język do:

  • obrazowania,

  • specyfikowania,

  • tworzenia,

  • dokumentowania

elementów systemów informatycznych. Umożliwia standaryzacje sposobu opracowania przekrojów systemu, obejmujących obiekty pojęciowe, takie jak procesy przedsiębiorstwa(procesy biznesowe) i funkcje systemowe, a także obiekty konkretne, takie jak klasy zaprogramowane w ustalonym języku, schematy baz danych i komponenty programowe nadające się do ponownego użycia.

UML stosuje się do klasy języków, opisujących w sposób formalny modele systemów. To oznaczy, że wszystkie statyczne i dynamiczne komponenty realnych systemów są odwzorowane w modelu w sposób formalny. Pojęcie „nieformalne modelowanie” może zawierać np. werbalny opis zadania, widoki programu, raporty poleceń do systemu itp.

Z badań statystycznych wynika, że większość producentów oprogramowania nie wykonuje żadnych formalnych modeli lub wykonuje ich bardzo mało. Im prostsze projekt, tym mniej prawdopodobne podjęcie formalnego modelowania. Niestety nieformalne modele nie mogą stanowić język, który może być zrozumiały projektantom oraz użytkownikom.

Obrazowanie rezultatów projektowania

Z punktu wzoru wielu programistów projekt systemu informatycznego to są tylko skrypty kodów programów. Oczywiście pewne sprawy najlepszej przedstawić w postaci kodu wyznaczonego tekstowego języka oprogramowania, np. C++, JAVA, Pascal, COBOL itd. Jest to najbardziej bezpośredni sposób zapisywania wyrażeń i algorytmów. W takich wypadkach programista buduje jednak pewne modele, często jedynie w swojej głowie. Takie podejście ma wady. Po pierwsze, komunikacja pomiędzy oddzielnymi projektantami całego systemu za pomocą takich modeli jest nieprecyzyjna w wypadkach, kiedy mogą być wykorzystywane różne języki oprogramowania przez tych projektantów. Oprócz tego, istnieją takie aspekty systemu komputerowego, których nie da się opanować bez pomocy modeli, umożliwiających przekroczenie ograniczenia tekstowego języka oprogramowania. Tak, analizując kod wszystkich klas, można dostrzec znaczenie hierarchii, ale nie da się natychmiast zrozumieć wszystkich jej konsekwencji. Po drugie, jeśli programista nie utrwalił w jakiś sposób modeli, które powstały w jego głowie, informacje w nich zawarte przepadają na zawsze. Gdy programista przeniesie się do innej firmy, wymyślone przez niego modele można w najlepszym wypadku odtworzyć częściowo.

Opracowanie modeli systemu w UML rozwiązuje problem, związany z komunikacją między członkami zespołu programistycznego: modele, formalne realizowane w sposób wizualny, wspomagają porozumiewanie pomiędzy projektantami. Pewne aspekty tego projektu najłatwiej modelować za pomocą skryptu, inne – graficzne. W komplikowanych systemach istnieją struktury, których nie da się przedstawić za pomocą języka oprogramowania. UML jest językiem graficznym. Z każdym symbolem graficznym skojarzona jest określona semantyka. Dzięki temu programista może przygotować w UML model, który będzie jednoznacznie zrozumiany przez innego programistę, a nawet przez inne narzędzie.

Specyfikowanie projektu

Specyfikowanie oznacza tu opracowanie modeli, które są precyzyjne, jednoznaczne i pełne. W szczególności UML wspomaga specyfikowanie wszystkich ważnych decyzji analitycznych, projektowych i implementacyjnych, które muszą być podejmowane w trakcie wytwarzania i wdrażania systemu informacyjnego.



Tworzenie skryptów projektu

UML nie jest językiem programowania graficznego, ale modele w nim napisane mogą być wprost powiązane z wieloma językami programowania. Oznacza to, że można przekształcić model UML w taki język, jak JAVA, C++, Visual Basic, PowerBuilder, albo w tabele relacyjnej bazy danych lub trwałą składnicę obiektowej bazy danych. To, co najlepiej wyrazić graficzne, jest właśnie w taki sposób przedstawione w UML, podczas gdy to, co łatwo wyrazić tekstowo, jest zapisywane w języku oprogramowania.

To przekształcenie umożliwia inżynierię do przodu, to znaczy generowanie kodu w języku programowania na podstawie modelu w UML. Odwrotne przekształcenie, czyli rekonstrukcja modelu na podstawie implementacji (inżynieria wstecz) także jest możliwe.

UML umożliwia nie tylko bezpośrednie przekształcanie modeli, ale też wykonywanie ich symulacje systemów oraz dostrajanie elementów wdrożonych systemów.



Dokumentowanie projektu

W poprawnym procesie tworzenia oprogramowania oprócz kodu wykonywalnego powstaje wiele artefaktów. Artefakt to jest dokument, raport lub program, który został utworzony. Są to :



  • wymagania,

  • architektura,

  • projekt,

  • kod źródłowy,

  • plany projektu,

  • testy,

  • prototypy,

  • kolejne wersje.

Zależnie od różnych okoliczności niektóre z tych artefaktów w realnym projekcie mogą być opracowywane mniej lub bardziej formalnie. Wszystkie są przedstawiane na zakończenie kolejnych etapów prac. Odgrywają istotną rolę w kontrolowaniu, ocenianiu i przekazywaniu informacji o systemie między projektantami podczas procesu tworzenia. UML obejmuje dokumentowanie architektury systemu i wszystkich jego szczegółów.

W UML można modelować nie tylko oprogramowanie. Za pomocą UML można projektować systemy nie związane z oprogramowaniem (np. przepływ pracy w ministerstwie, struktura i zachowanie systemu opieki zdrowotnej oraz projektowanie sprzętu komputerowego).


Model pojęciowy UML


Model pojęciowy UML zawiera trzy składniki:

  1. Podstawowe bloki konstrukcyjne.

  2. Regule określające sposób łączenia tych bloków.

  3. Podstawowe mechanizmy językowe w UML.

Bloki konstrukcyjne UML


UML uwzględnia trzy rodzaje bloków konstrukcyjnych:

  1. elementy (lub encji),

  2. związki,

  3. diagramy.

Elementy to jest najważniejsza abstrakcja w modelach UML, a związki to są powiązania między elementami. Diagramy służą do grupowania istotnych elementów.

Elementy

Za dopomogą elementów można tworzyć różne modele. W UML istnieją cztery rodzaje elementów:



  • strukturalne,

  • czynnościowe,

  • grupujące,

  • komentujące.


Elementy strukturalne.

Elementy strukturalne w modelach UML wyrażone rzeczownikami. Stanowią najbardziej statyczne części modelu, reprezentujące składniki pojęciowe albo fizyczne. Istnieją siedem rodzajów elementów strukturalnych.



1.Klasa (Class) to opis zbioru obiektów, które mają takie same atrybuty, operacje, związki i znaczenie. Klasa realizuje jeden lub więcej interfejsów. Na diagramie jest pokazana jako prostokąt, który zwykle zawiera nazwę, atrybuty i operacje. Na rys.28 jest pokazany przykład klasy.

Rys.28


2. Interfejs (Interface) to jest zestaw operacji, które wyznaczają usługi oferowane przez klasę lub komponent. Interfejs definiuje zatem zewnętrznie obserwowalne zachowywanie takiego elementu. Może reprezentować pełne zachowanie klasy lub komponentu lub jedynie część zachowania. Określa zbiór deklaracji operacji(czyli ich sygnatur), ale nigdy zbiór implementacji operacji. Interfejs jest zawsze powiązany z realizującą go klasą lub komponentem. Na diagramie jest przedstawiany jako okrąg, z nazwą obok, lub jako prostokąt, zawierający nazwę oraz metody interfejsu. Przykłady interfejsów są pokazane na rys. 29.

Rys.29

3. Kooperacja (Collaboration) definiuje interakcję. Jest to zestaw ról i innych bytów, współdziałających w celu wywołania pewnego zachowania niemożliwego do osiągnięcia w pojedynkę. Kooperacja wiąże się zatem zarówno ze strukturą, jak i z zachowaniem modelu. Pojedyncza klasa może brać udział w wielu kooperacjach. Kooperacje reprezentują więc implementację wzorców, które składają się na system. Na diagramie są przedstawione jako elipsy o przerwanej linii brzegowej, zazwyczaj tylko z nazwami w środku.

Rys. 30


4 Przypadek użycia (Use case) to opis zbioru ciągów wykonywanych przez system w celu dostarczenia danemu aktorowi (Actor) godnego uwagi wyniku. Służy do określenia w modelu struktury zachowania systemu. Jest urzeczywistniany przez kooperację. Graficzne jest przedstawiany na diagramie jako elipsa o ciągłej linii brzegowej, zazwyczaj tylko z nazwą w środku (rys. 31).

Rys.31


5 Klasa aktywna (Active class) to jest obiekty, w skład których wchodzi co najmniej jeden proces lub wątek (Threads). Takie obiekty mogą samodzielnie rozpocząć przepływ sterowania. Klasa aktywna jest podobna do zwykłej klasy, z tym że jej obiekty reprezentują elementy działające równolegle z innymi. Na diagramie jest przedstawiona jak klasa, z tą tylko różnicą, że obramowanie prostokąta jest pogrubione.

Rys. 32


6. Komponent (Component) to fizyczna, wymienna część systemu, która wykorzystuje i realizuje pewien zbiór interfejsów. W każdym systemie można spotkać wiele rodzajów wdrożonych komponentów (np. COM+ lub Java Beans), a także komponentów , będących rezultatami (artefaktami) w procesie wytwarzania (np. Pliki z kodem źródłowym). Komponent to fizyczne opakowanie elementów logicznych, takich jak klasy, interfejsy i kooperacje. Graficzne jest przedstawiany na diagramie jako prostokąt z bolcami, zazwyczaj tylko z nazwą w środku.

Rys.33


7 Węzeł (Node) to fizyczny składnik działającego systemu. Reprezentuje zasoby obliczeniowe. Ma zwykle pewną ilość pamięci i zdolność przetwarzania. Zbiór komponentów może się znajdować w węźle, a czasem może przemieszczać się między węzłami. Węzeł jest przedstawiony na diagramie jako sześcian, zazwyczaj tylko z nazwą w środku.

Rys.34


Tych siedem omówionych elementów to podstawowe składniki zapisanego w UML modelu struktury. Istnieją także pewne warianty tych pojęć: aktorzy, sygnały i klasy funkcji usługowych (rodzaje klas), procesy i wątki (rodzaje klas aktywnych), programy, dokumenty, pliki, biblioteki, witryny i tabele (rodzaje komponentów).


1   ...   9   10   11   12   13   14   15   16   ...   113


©operacji.org 2017
wyślij wiadomość

    Strona główna