Obiektowe modelowanie systemów informatycznych



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

Reguły UML


Bloki konstrukcyjne UML nie mogą być połączone pomiędzy sobą na chybił trafił. Jak w każdym innym języku, tak w UML obowiązują pewne reguły określające, jak poprawny model ma wyglądać. Poprawny model powinien być wewnętrznie spójny oraz zgodny z innymi powiązanymi z nim modelami.

W UML istnieją reguły semantyczne (znaczeniowe) dotyczące:



  • Nazw – jak można nazywać elementy (encji) związki i diagramy;

  • Zasięgu – jaki jest kontekst, który nadaje nazwie specyficzne znaczenie;

  • Widoczności – w jaki sposób nazwy mogą być widziane i używane;

  • Spójności – jak elementy są ze sobą logicznie powiązane i czy są właściwe.

  • Wykonywania – co oznacza działanie lub symulowanie modelu dynamicznego.

Stereotypy w UML


Język UML zapewnia standardowe środki wyrazu przydatne do zapisywania projektu systemu. Należy jednak pamiętać, że nie ma tak uniwersalnego języka, w którym dałoby się wyrazić wszystkie możliwe niuanse każdego modelu dowolnego systemu w każdej dziedzinie zastosowania i w każdym czasie. Z tego właśnie powodu UML jest językiem otwartym. Można go rozszerzać, ale w kontrolowany sposób. Takim sposobem mogą wystąpić stereotypy.

Stereotyp umożliwia rozszerzanie słownictwa UML. Można tworzyć nowe bloki konstrukcyjne, wywodzące się z tych już istniejących, ale specyficzne dla danego zadania. Stereotyp to jest mechanizm kategoryzacji elementów. W językach C++ oraz JAVA wykorzystują się wyjątki. W tych językach są one klasami, choć traktowanymi w szczególny sposób. Wyjątki muszą być zgłaszane i obsługiwane. Dla obrazowania elementów wyjątków w modelu mogą być wykorzystywane standardowe bloki konstrukcyjne klas stereotypem <>.



Przykładem wykorzystania stereotypu jest interfejs. Interfejs obejmuje tylko operacje, bez atrybutów. Jest to zestaw operacji, które można wielokrotnie wykonywać w modelu. Zamiast wymyślać nowy element reprezentujący interfejs, można użyć ikony klasy z napisem <> umieszczonym nad nazwą klasy.

Architektura systemu informatycznego


Obrazowanie, specyfikowanie, tworzenie i dokumentowanie systemu informatycznego wymaga podejścia do niego z kilku punktów widzenia. Różni uczestnicy procesu projektowania patrzą na zadanie z innej perspektywy i na innym etapie jego życia. Można wyznaczyć następne kategorii projektantów: użytkownicy, analitycy, programiści, specjaliści od integracji systemu, osoby wykonujące testy, autorzy dokumentacji technicznej, kierownicy projektu. Każdy z tych kategorii projektantów ma swój punkt widzenia oraz może wnieść do projektu nowe decyzji.

Architektura systemu to jest najważniejszy artefakt, jaki może być wykorzystany do zapanowania nad wszystkimi punktami widzenia. Umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura to zbiór znaczących decyzji dotyczących:

  • Organizacji systemu komputerowego,

  • Wyboru elementów strukturalnych i ich interfejsów, z których system jest zbudowany,

  • Zachowania tych elementów, opisanego w kooperacjach,

  • Składania elementów strukturalnych i czynnościowych w coraz większe podsystemy,

  • Stylu architektonicznego, według którego tworzy się konstrukcję systemu, to znaczy charakterystycznych elementów statycznych, i dynamicznych oraz interfejsów, kooperacji i składania.

Architektura oprogramowania dotyczy nie tylko jego struktury i zachowania, ale także stosowania go, jego funkcjonalności, efektywności, odporności, możliwości ponownego użycia, ograniczeń ekonomicznych i technologicznych oraz estetyki. Na rys.43 jest przedstawiony sposób zobrazowania architektury systemu informatycznego – pięciu powiązanych ze sobą perspektyw. Każda z nich dotyczy organizacji i struktury systemu, ale w każdej z nich kładzie się nacisk na pewien ustalony aspekt systemu.

Rys.43


W Perspektywie przypadków (Use case view) użycia bierze się pod uwagę zachowanie systemu widziane oczyma użytkowników, analityków i osób wykonujących testy. Nie definiuje się rzeczywistej organizacji systemu, a opisuje się czynniki wpływające na kształt architektury systemu. W UML aspekty statyczne tej perspektywy wyraża się za pomocą diagramów przypadków użycia, a dynamiczne za pomocą diagramów interakcji, diagramów stanów i diagramów czynności.

W Perspektywie projektowej (Design view) kładzie się nacisk na klasy, interfejsy i kooperacje, które razem składają się na słownictwo danego zadania i na rozwiązania tego zadania. Perspektywa ta pomaga w zapisywaniu wymagań funkcjonalnych, czyli usług, które system powinien udostępniać swoim użytkownikom. W UML aspekty statyczne tej perspektywy wyraża się za pomocą diagramów klas i diagramów obiektów, a dynamiczne za pomocą diagramów interakcji, diagramów stanów i diagramów czynności.

W Perspektywie procesowej (Process view) zwraca się uwagę na wątki i procesy, które kształtują mechanizmy współbieżności i synchronizacji w systemie. Dotyczy ona głównie efektywności, skalowalności i przepustowości systemu. W UML aspekty statyczne i dynamiczne tej perspektywy są przedstawiane na takich samych rodzajach diagramów jak w wypadku perspektywy projektowej, z tą tylko różnicą, że główny nacisk kładzie się na klasy aktywne, które reprezentują procesy i wątki.

W Perspektywie implementacyjnej (Implemetation view) znaczenie mają komponenty i pliki, użyte do scalenia i udostępnienia systemu fizycznego. Wiąże się ona z zarządzaniem konfiguracją poszczególnych wersji systemu, złożonych z rozmaitych niezależnych komponentów i plików, które można zespolić na wiele sposobów, aby otrzymać działający system. W UML aspekty statyczne tej perspektywy wyraża się za pomocą diagramów komponentów, a dynamiczne za pomocą diagramów interakcji, diagramów stanów i diagramów czynności.

W Perspektywie wdrożeniowej (Deployment view) kładzie się nacisk na węzły, składające się na sprzęt, na którym system będzie uruchamiany. Wiąże się ona głównie z rozmieszczeniem, dostarczeniem i instalacją części systemu fizycznego. W UML aspekty statyczne tej perspektywy wyraża się za pomocą diagramów stanów i diagramów czynności.

Każda z tych pięciu perspektyw jest autonomiczna. Poszczególni uczestnicy projektowania systemu informatycznego mogą skoncentrować się na tym fragmencie architektury systemu, który ich najbardziej interesuje. Perspektywy ściśle się ze sobą wiążą. Np. Węzły w perspektywie wdrożeniowej zawierają komponenty z perspektywy implementacyjnej, które z kolei reprezentują fizyczną realizację klas, interfejsów, kooperacji i klas aktywnych z perspektywy projektowej i procesowej. UML umożliwia zatem wyrażenia każdej z tych perspektyw i ich wzajemnych oddziaływań.




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


©operacji.org 2017
wyślij wiadomość

    Strona główna