Inżynieria
oprogramowania
UML modelowanie statycznych
aspektów oprogramowania
Rafał Kasprzyk
ędąc świadomym wymagań stawianych sys- " Modelowanie schematu logicznej bazy da-
temowi informatycznemu, kolejnym krokiem nych. Przez schemat rozumiany jest plan
Bjest zaprojektowanie sposobu realizacji tych- projektu koncepcyjnego bazy danych. W wie-
że wymagań. W tym celu buduje się modele pre- lu dziedzinach zachodzi potrzeba trwałe-
zentujące statyczne i dynamiczne aspekty oprogra- go przechowywania informacji w bazach da-
mowania. Modele te budowane są w kontekście re- nych. W tym wypadku diagram klas wykorzy-
alizacji poszczególnych przypadków użycia. Mode- stuje się do modelowania schematów takich
le dynamiki systemu przedstawiają wszelkie możli- baz danych.
we ścieżki realizacji każdego wymagania funkcjonal-
nego (przypadku użycia). Analiza diagramów mode- Diagramy komponentów
lujących dynamikę uwzględniająca wymagania nie- Komponenty, w odróżnieniu od bytów koncep-
funkcjonalne, prowadzi do zbudowania statycznego cyjnych jakimi są np. klasy, to elementy oprogra-
modelu oprogramowania. W artykule przedstawio- mowania istniejące w systemie komputerowym
ne zostaną diagramy UML wykorzystywane do opisu i będące fizyczną realizacją zamysłu projektan-
struktury oprogramowania. ta oprogramowania. Należy tu uchwycić subtelną
granicę rozciągłości definicji klasy w stosunku do
Diagramy klas definicji komponentu, tzn. najważniejszym wyróż-
Diagram klas jest ściśle powiązany z projekto- nikiem odmienności tych dwóch pojęć jest to, iż
waniem obiektowym systemów informatycznych. klasa jest abstrakcyjnym przedstawieniem zbioru
Opisuje wyróżnione w systemie klasy obiektów atrybutów i operacji, podczas gdy komponent jest
i statyczne powiązania między nimi. Zawiera on fizyczną częścią systemu.
również takie elementy jak atrybuty i operacje Analizując zagadnienie projektowania realnych
klas oraz ograniczenia nakładane na klasy obiek- fragmentów oprogramowania (komponentów) moż-
tów i ich powiązania. Modelując statyczne aspek- na dojść do wniosku, że szczególny nacisk powinien
ty perspektywy projektowej, diagramów klas uży- zostać położony na możliwość wyizolowania kompo-
wa się do: nentu i jego wielokrotnego użycia. Zadanie to uła-
twiają dobrze zdefiniowane interfejsy, które są jedy-
" Modelowanie słownictwa systemu. Zadanie to ną drogą przez którą dostępne są operacje kompo-
polega między innymi na podejmowaniu decyzji, nentu - zupełnie jak w przypadku klas - relację tego
które abstrakcje są częścią rozważanego syste- typu nazywamy realizacją. Nie można pominąć zna-
mu, a które nie i jakie zobowiązania ma każda z czenia interfejsu jako swego rodzaju "okna na świat"
tych abstrakcji. dla komponentu, co warunkuje możliwości jego wy-
" Modelowanie prostych kooperacji. Kooperacja miany i wielokrotnego wykorzystania. Należy w tym
jest to zestaw klas, interfejsów i innych bytów miejscu dodać, że w specyfikacji UML 2.0 wyróżnio-
istniejących celem realizacji pewnego zespo- ne zostały dwa typy interfejsów. Jeżeli komponent
łowego zachowania wymagającego współpra- udostępnia jakieś usługi w postaci interfejsu to mó-
cy wszystkich elementów. Nie należy skupiać wimy wówczas o tzw. interfejsie dostarczanym, udo-
się nad jedną klasą, lecz nad zbiorem współ- stępnianym lub eksportowanym (ang. provided inter-
pracujących ze sobą klas, by zrozumieć, o co face). Może jednak zajść przypadek, że komponent,
chodzi. W tym wypadku diagramy klas wyko- aby w pełni realizować swoje usługi, potrzebuje sko-
rzystuje się do zobrazowania i określenia tego rzystać z usług innych komponentów, co obrazuje
zbioru klas i związków między nimi. się za pomocą interfejsu wymaganego, importowa-
nym (ang. required interface). Wyróżniamy 3 podsta-
wowe rodzaje komponentów:
Autor jest absolwentem Wydziału Cybernetyki WAT,
gdzie od 2 lat zajmuje stanowisko asystenta w Instytu-
" wdrożenia - są podstawą oprogramowania wyko-
cie Systemów Informatycznych. Pracuje w firmie ISO-
nywalnego
LUTION będąc odpowiedzialnym za przygotowywa-
" COM+, JavaBeans, EJB, biblioteki DLL, pliki
nie, prowadzenie i audyt szkoleń obejmujących analizę
wykonywalne EXE, ...
i projektowanie systemów informatycznych z użyciem
notacji UML. " procesu wytwórczego komponenty będące ar-
Kontakt z autorem: rafal.kasprzyk@wat.edu.pl
tefaktami powstałymi w procesie wytwarzania, na
ich podstawie generuje się komponenty wdrożenia
72
www.sdjournal.org
Software Developer s Journal 08/2007
UML modelowanie statycznych aspektów oprogramowania
Enrollment
- Marks Received: int[]
+ Get Average To Date(): float
1..* 1..*
+ Get Final Mark(): short
enrolled
in
Student Seminar
- Address: String - Fees: float
1 1
- Average Marks: float - Name: String
- Email Address: String - Seminar Number: int
- Name: String
on waiting list
- Phone Number: String + Add Student(): boolean
- Student Number: int + Drop Student(): boolean
0..* 0..*
0..*
+ Get Seminars Taken(): int
+ IS Eliglible to Enroll(): boolean
instructs
Professor
- Address: String
- Email Address: int 0..1
- Name: String
Some seminars may
- Phone Number: String
not have an instructors
- Salary: float
+ Get Seminars Taken(): void
Rysunek 1. Przykładowy diagram klas
" schemat logiczny bazy danych, skrypty SQL, pliki z ko- związki. Elementy te są ze sobą luzno powiązane najczęściej
dem zródłowym, za pomocą zależności i realizacji.
" komponenty wykonania tworzone jako rezultat działania
systemu Diagramy wdrożenia
" wydruki, raporty. Diagram wdrożenia, obok diagramu komponentów to jeden
z dwóch rodzajów diagramów przedstawiających fizyczne
W końcu dochodzimy do definicji diagramu komponentów, aspekty systemów. Jego zadaniem jest zobrazowanie kon-
który zawiera komponenty, interfejsy oraz ich wzajemne figuracji węzłów w czasie wykonania, na których rozmiesz-
Encryption
DataAccess Access Control
Facilities
Facilities Persistance
<
>
Security
Access Control
<>
DataAccess Access Control
Student
Seminar Management
Student Persistance
<>
Persistence
Persistance
DataAccess Access Control
Seminar
<>
Student Administration
Seminar Persistance
<>
University DB
JDBC
DataAccess Access Control
Schedule
Schedule Persistance
Rysunek 2. Przykładowy diagram komponentów
Software Developer s Journal 08/2007 www.sdjournal.org
73
Inżynieria
oprogramowania
czone będą komponenty. Komponenty reprezentują fizycz-
ne (programowe ang. software), wymienne części syste- Bibliografia
mu, które realizują elementy logiczne, podczas gdy węzły
" Marin Fowler UML Distilled: A Brief Guide To The Standard Ob-
to fizyczne (sprzętowe ang. hardware) składnik systemu
ject Modeling Language, 3rd ed., Addison-Weslay Professional,
na których wdrożone zostają komponenty. Najczęściej ma-
2004;
my do czynienia z sytuacją w której diagramy komponentów
" Grady Booch, James Rumbaugh, Ivar Jacobson, Unified Mo-
umieszczane są na diagramach wdrożenia, aby pokazać,
deling Language User Guide, 2nd ed., Addison-Weslay Pro-
które komponenty działają na których węzłach. Węzły dzie-
fessional, 2005;
lone są na:
" Michał Śmiałek, Zrozumieć UML 2.0. Metody modelowania
obiektowego, Helion, 2005;
" procesowy reprezentują zasoby obliczeniowe
" http://www.holub.com/goodies/uml/;
" posiadają pewną ilość pamięci i zdolność przetwa- " http://www.agilemodeling.com/essays/umlDiagrams.htm.
rzania,
" mogą wykonywać kod komponentu
" urządzenia są interfejsem do świata zewnętrznego na celu parametryzację relacji pomiędzy różnymi programo-
" nie mają zdolności przetwarzania (np. monitor, dru- wymi i sprzętowymi technologiami. Specyfikacja wdrożenia
karka) jest obrazowana za pomocą stereotypu
Ciekawym elementem jest również tzw. środowisko wy-
Diagramy wdrożenia są szczególnie przydatne dla projek- konania. Element ten reprezentuje wybrany rodzaj platformy i
tantów systemów, których sposób funkcjonowania zale- jest obrazowany za pomocą stereotypu
ży równie silnie od oprogramowania wchodzącego w skład
systemu, jak i sprzętu, na którym to oprogramowanie ma Diagramy obiektów
działać. Pozwalają na zobrazowanie infrastruktury wymaga- Diagramy obiektów przedstawiają hierarchię obiektów i ich
nej przez system. wzajemne powiązania w danej chwili. Jako że przedstawia-
Można wyróżnić trzy zasadnicze typy systemów, przy mo- ją instancje klas, a nie same klasy - nazywane są też diagra-
delowaniu których warto wykorzystać diagramy wdrożenia: mami instancji. Na diagramach obiektów umieszczamy spe-
systemy wbudowane, systemy typu klient-serwer oraz syste- cyfikacje instancji, a nie same instancje. Rozwiązanie takie
my rozproszone. umożliwia nienadawanie wartości obowiązkowym atrybu-
Istotną nowością, która została wprowadzona w specyfi- tom lub też obrazowanie specyfikacji instancji klas abstrak-
kacji UML 2.0, jest dodanie elementu będącego specyfikacją cyjnych.
wdrożenia. Element ten odpowiada za opis parametrów po- Diagramy obiektów podobne są do diagramów komunika-
trzebnych do wdrożenia komponentu na danym węzle, co ma cji, jednakże te pierwsze służą do zobrazowania struktury in-
:WebSerwer <> <>
:Application Server DB Server
<> <>
<>
constraints constraints
Student Administration
{OS = Solaris} {OS = Linux}
:EJBContainer
<>
University DB
Student
constraints
{vendor = Oracle}
Seminar
Schedule
<>
Mainframe
<>
<>
constraints
Registration
{OS = MVS}
<>
Persistance
<>
constraints
Course Management
{vendor = Ambysoft}
<>
Course Management
Facade
Rysunek 3. Przykładowy diagram wdrożenia
74
www.sdjournal.org
Software Developer s Journal 08/2007
UML modelowanie statycznych aspektów oprogramowania
stancji, diagramy komunikacji natomiast do pokazania ich za-
Student Seminar
chowań.
prerequites: Seminars sants: int
waitList: Students
Diagramy struktur złożonych
Application Desired Seminar
Diagramy struktur złożonych służą do hierarchicznego opi-
sywania skomplikowanych obiektów. Pozwala to na zajęcie
się skomplikowanym elementem i podzielenie go na części.
Enroll in
Struktury złożone są podobne do pakietów. Aby uświadomić
Seminar
sobie podstawową różnicę najlepiej myśleć o pakietach ja-
ko o sposobie grupowania elementów w czasie kompilacji,
podczas gdy struktury złożone grupują elementy w czasie
Registration Constrainer
wykonania programu.
Enrollment Course
Diagramy struktury swoją notację i zakres stosowa-
nia wywodzą głównie z modeli systemów czasu rzeczywi-
requisites: Courses
stego, gdzie stosowane jest pojęcie tzw. kapsuły, która re-
prezentuje wyraznie wydzielony i hermetyczny wątek ste-
Rysunek 5. Przykładowy diagram struktur złożonych
rowania systemu. Całkowita izolacja kapsuły (w obu kie-
runkach) od jej otoczenia możliwa jest dzięki portom, które tów to diagram składający się z pakietów i zależności między
pełnią rolę obiektów granicznych (interfejsów). Interesują- nimi. Pakiety z reguły tworzy się, aby:
cy jest fakt, że diagramy struktury mogą obrazować aspekt
statyczny i dynamiczny modelowanego systemów, co sta- " W przejrzysty sposób zobrazować zależności pomiędzy
nowi o ich osobliwości. Najczęściej mamy do czynienia z poszczególnymi elementami modelu.
przypadkiem, w którym diagramy struktury ilustrują de- " Efektywniej organizować kod zródłowy.
kompozycję wskazującą z jakich części składa się kapsu- " Zaznaczyć podobieństwa i różnice pomiędzy poszczegól-
ła i w jakie interfejsy jest ona zaopatrzona. Istnieje jednak nymi elementami modelu.
druga forma diagramów struktury umożliwiająca przedsta-
wienie komunikacji, jaka zachodzi pomiędzy wewnętrzny- Na diagramie pakietów wszelkie elementy modelu (klasy, in-
mi elementami kapsuły. Taka forma prezentacji diagramów terfejsy, kooperacje, komponenty) grupowane są w pakie-
struktury została nazwana w UML 2.0 diagramem współ- ty i/lub podpakiety zgodnie z poziomami zawierania. War-
pracy. Należy pamiętać, że gdy diagram struktury przyjmu- to tworzyć tego typu diagramy dążąc do tego, aby elemen-
je pierwszą formę to można użyć na nim portów i interfej- ty modelu połączone relacjami asocjacji, agregacji, czy to
sów. Prezentując natomiast zbiór współpracujących ze so- kompozycji umieszczone były w jednym pakiecie. Z regu-
bą elementów składowych kapsuły nie można wykorzysty- ły naturalnym jest, by w pakiecie umieszczać elementy mo-
wać portów i interfejsów, ale należy skorzystać ze stereo- delu, które w jakikolwiek sposób od siebie zależą. Diagramy
typowych zależności: <>, <>, pakietów można także stosować w celu grupowania przy-
<> padków użycia. Ogólne zasady tworzenia diagramów pakie-
Ponieważ struktury złożone są nowością, to trudno stwier- tów są bardzo proste:
dzić, jak przydatne okażą się w praktyce.
" Zawsze nadawaj pakietom proste, opisowe nazwy
Diagramy pakietów " Stosuj pakiety do upraszczania struktury diagramów
Pakiet jest konstrukcją pozwalającą organizować elementy " Stosuj stereotypy by zaznaczyć warstwy architektury pro-
modelu np. klasy, w logiczne grupy. Natomiast diagram pakie- gramu
" Zależności między pakietami powinny odzwierciedlać fak-
tyczne wewnętrzne relacje w programie
John Smith:
+Student
" Pakiety powinna charakteryzować wysoka zwartość i ni-
Student
skie sprzężenie.
Sally Jones: +Student CSC100a:
Podsumowanie
Student Seminar
Modelując elementy statyczne rozwiązania dążymy do uzy-
skania takiej struktury oprogramowania, która będzie umoż-
+Teaching
:Course
Assistant
Sara McGrath: liwiała realizację wymagań funkcjonalnych przy spełnieniu
Student
+Teaching
wymagań niefunkcjonalnych. W tej perspektywie budowane
Assistant
są diagramy klas, komponentów, wdrożenia i pakietów (for-
malnie pojawiły się dopiero w UML2.0, chodz wykorzysty-
Scott Ambler: CSC100b:
Student Seminar
+Student wane były już wcześniej). Często pomocne okazuje się wy-
korzystanie diagramu obiektów i nowego diagramu struktur
+Wait Listed
złożonych. n
Ed Malorey:
Student
Rysunek 4. Przykładowy diagram obiektów
Software Developer s Journal 08/2007 www.sdjournal.org
75
Wyszukiwarka
Podobne podstrony:
2007 11 UML – modelowanie dynamicznych aspektów oprogramowania [Inzynieria Oprogramowania]
Modelowanie statyczne skomplikowanych konstrukcji inżynierskich
2007 06 UML – potrzeba standaryzacji notacji [Inzynieria Oprogramowania]
2007 08 Podstawy zabezpieczenia serwerów [Bezpieczenstwo]
egzamin 2007 08 rozw
K2 2007 08 zad 2
Egzamin 2007 08
2007 08 Common Colors Creating Icc Color Profiles with Argyll Cms
poprawkowy 2007 08
2007 08 OpenKODE [Programowanie C C ]
I kolokwium 2007 08
II kolokwium 2007 08
2007 08 OpenOffice–narzędzie do konwersji [Open Office]
2007 08 małopolski Ietap
więcej podobnych podstron