E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 1
marzec 2001
Projektowanie systemów informacyjnych
Ewa Stemposz, Kazimierz Subieta
Instytut Podstaw Informatyki PAN,
Warszawa
Polsko-Japońska Wyższa Szkoła
Technik Komputerowych, Warszawa
Wprowadzenie do UML
Wykład 3
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 2
marzec 2001
Zagadnienia
Cykl życiowy produktu informatycznego
Modelowanie pojęciowe
Metodyka
UML:
Krótka charakterystyka
Modele i diagramy
Mechanizmy rozszerzalności
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 3
marzec 2001
Cykl życiowy produktu
informatycznego
Faza strategiczna
Faza specyfikacji i analizy wymagań --> projektowanie (modelowanie)
pojęciowe
Faza projektowania --> projektowanie logiczne
Faza konstrukcji (implementacji) --> projektowanie fizyczne
Faza testowania
Faza konserwacji
czas
Fazy cyklu życiowego produktu informatycznego:
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 4
marzec 2001
Modelowanie pojęciowe
Pojęcia: modelowanie pojęciowe (conceptual modeling) oraz
model pojęciowy (conceptual model) odnoszą się do procesów
myślowych,
do
wyobrażeń
towarzyszących
pracy
nad
oprogramowaniem.
Projektant, programista, itd. muszą dokładnie wyobrazić sobie
problem oraz metodę jego rozwiązania. Zasadnicze procesy
tworzenia oprogramowania zachodzą więc w ludzkim umyśle i
nie są związane z jakimkolwiek językiem programowania czy
jakimkolwiek narzędziem w ogóle.
Modelowanie pojęciowe może być (i powinno być) wspomagane
przez środki wzmacniające ludzką pamięć i wyobraźnię, służące
do opisu odwzorowywanej rzeczywistości w postaci: struktur
danych, operacji na danych czy zachodzących procesów.
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 5
marzec 2001
Metodyka (1)
Metodyka (metodologia) – w inżynierii oprogramowania – jest
zestawem pojęć, oznaczeń, języków, modeli, diagramów, technik i
sposobów postępowania wspierających proces konstruowania
systemu (realizacji projektu).
Metodyka jest wykorzystywana zarówno do projektowania
pojęciowego, jak i logicznego czy fizycznego.
role uczestników projektu,
scenariusze postępowania,
reguły przechodzenia do następnej fazy,
modele, które powinny być wytworzone,
dokumentację, która powinna powstać,
język/notację, którą należy używać.
Metodyka ustala fazy realizacji projektu, a ponadto dla
każdej z faz projektu wyznacza:
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 6
marzec 2001
Metodyka (2)
Dana notacja może być wykorzystywana w wielu metodykach.
Szczególne znaczenie mają notacje graficzne, ich zalety
potwierdzają
badania
psychologiczne.
Inżynieria
oprogramowania wzoruje się tu na innych dziedzinach techniki,
takich jak np. elektronika czy mechanika.
Rodzaje
notacji:
tekstowa
specyfikacje - ustrukturalizowany zapis tekstowy i numeryczny
notacje graficzne
Notacja, czyli zbiór oznaczeń, jest
wykorzystywana do dokumentowania
wyników poszczególnych faz projektu –
pośrednich i końcowych. Notacja służy
jako
środek
wspomagający
ludzką
pamięć i wyobraźnię, a także jako środek
ułatwiający komunikację zarówno między
członkami zespołu projektowego, jak i
między zespołem projektowym a
klientem.
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 7
marzec 2001
Język do modelowania
Język do modelowania, jak każdy inny język, oprócz notacji,
semantyki i składni posiada jeszcze jeden ważny aspekt:
pragmatykę.
Semantyka określa, co należy rozumieć pod przyjętymi
oznaczeniami (notacją).
Pragmatyka określa, w jaki sposób należy używać przyjętych
oznaczeń, jak do konkretnej sytuacji dopasować pewien wzorzec
notacyjny – zgodnie z intencją autorów języka.
Składnia określa, jak wolno łączyć ze sobą przyjęte
oznaczenia.
Język niewiele znaczy bez znajomości sposobów wykorzystywania go
w procesie wytwarzania produktu programistycznego. W
metodykach pragmatyka stosowanego języka jest sprawą
podstawową. Jest ona zazwyczaj trudna do objaśnienia: można to robić
wyłącznie na przykładach przypominających realne sytuacje. Niestety,
realne sytuacje są zazwyczaj bardzo skomplikowane, czego efektem jest
pewien infantylizm przykładów zamieszczanych w podręcznikach.
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 8
marzec 2001
RATIONAL SOFTWARE CORPORATION
UML 0.8-0.9, styczeń 1995 - wrzesień 1996
UML 1.0,
styczeń 1997, przesłany do OMG
UML 1.1,
koniec 1997, zatwierdzony jako składnik standardu OMG
UML 1.3,
kwiecień 1999
UML 1.4 listopad 2000
UML 1.5
2003
UML 1.6 ? UML 2.0 ?
Połączone siły trzech znanych metodologów
oprogramowania:
Grady Booch Ivar Jacobson
James Rumbaugh
http://www.rational.com/uml
(dokumentacja on line)
Unified Modeling Language (UML)
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 9
marzec 2001
UML: Krótka charakterystyka (1)
Notacja UML, która opiera się o podstawowe pojęcia obiektowości
może być wykorzystana w dowolnej metodyce.
Pojęcia UML, wynikające z doświadczenia jej twórców, mają w
założeniu przykrywać większość istotnych aspektów modelowanych
systemów.
UML jest składową standardu OMG (CORBA).
Nie wszyscy są zachwyceni UML. Niektórzy specjaliści uważają go za
twór przereklamowany: niestabilny, zbyt ciężki, źle
zdefiniowany. UML ma konkurentów w postaci metodyki i notacji
OPEN, “design by contracts” oraz innych.
UML cieszy się aktualnie bardzo dużą popularnością.
Prawdopodobnie przez wiele najbliższych lat będzie dominował w
obszarze analizy i projektowania.
UML jest metodyką projektowania ?
Definicja podana przez Rational: "The Unified Modeling
Language (UML) is a language for specifying, constructing,
visualizing, and documenting the artifacts of a software-
intensive system."
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd
10
marzec 2001
UML: Krótka charakterystyka (2)
OOSE (Jacobson): dobrze podchodzi do kwestii modelowania
użytkowników i cyklu życiowego systemu. Nie przykrywa dokładnie
ani aspektu modelowania dziedziny przedmiotowej ani aspektu
implementacji (konstrukcji).
OMT (Rumbaugh): dobry do modelowania dziedziny przedmiotowej.
Nie przykrywa dostatecznie dokładnie ani aspektu użytkowników
systemu, ani aspektu implementacji (konstrukcji).
OOAD (Booch): zajmuje się kwestią modelowania dziedziny
przedmiotowej, implementacją (konstrukcją) i związkami ze
środowiskiem implementacji. Nie przykrywa dostatecznie dobrze fazy
rozpoznania i analizy wymagań użytkowników.
Wady i zalety metodyk, których autorami są twórcy UML:
Istnieje wiele aspektów projektowania systemów, które nie zostały
przykryte przez żadną z wyżej wymienionych metodyk, np. włączenie
prototypowania w cykl życiowy, rozproszenie i komponenty,
przystosowanie notacji do preferencji projektantów i inne. Celem UML
jest przykrycie również tych aspektów.
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd
11
marzec 2001
Diagramy definiowane w UML
Diagramy przypadków użycia (use case)
Diagramy klas
Diagramy dynamiczne (behavior):
Diagramy stanów
Diagramy aktywności
Diagramy interakcji:
Diagramy sekwencji
Diagramy współpracy (collaboration)
Diagramy implementacyjne:
Diagramy komponentów
Diagramy wdrożeniowe (deployment)
Diagramy te zapewniają uzyskanie wielu perspektyw
projektowanego
systemu w trakcie jego budowy.
Diagramy pakietów
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd
12
marzec 2001
Model a diagram; modele w UML (1)
Model: pewna abstrakcja projektowanego systemu, widziana z
określonej perspektywy, na określonym poziomie szczegółowości.
Diagram: środek służący do opisu modelu. Dany model może być
opisany przy pomocy wielu diagramów. Dany element modelu może
pojawiać się na wielu diagramach jednego modelu.
Dwa najważniejsze modele w UML, wykorzystywane w fazie analizy, to:
Model przypadków użycia opisujący system widziany z
perspektywy
jego
przyszłych
użytkowników
(za
pomocą
diagramów przypadków użycia).
Model obiektowy przedstawiający statyczną budowę (strukturę
systemu) za pomocą diagramów klas i diagramów obiektów.
Diagram klas może zawierać obiekty. Diagram obiektów nie
zawiera klas, ale wyłącznie obiekty.
Głównym
zadaniem
pomocniczego
modelu
dynamicznego
(zachowań) jest wypełnienie diagramu klas metodami wynikłymi z
analizy zachowania systemu w trakcie wykonywania zadań, gdzie
zadaniem może być np. realizacja przypadku użycia czy też jednego
konkretnego scenariusza danego przypadku użycia.
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd
13
marzec 2001
Model a diagram; modele w UML (2)
Główny obszar
działania
Model
Diagramy
Podstawowe
pojęcia
struktura
model obiektowy
diagram klas
diagram obiektów
model przypadków
użycia
diagramy przypadków
użycia
klasa, obiekt, asocjacja,
generalizacja, zależność,
realizacja, interface
aktor, przypadek użycia,
«include», «extend»,
generalizacja
model
implementacji
diagramy
komponentów
diagramy
wdrożeniowe
komponent, interface,
zależność, realizacja
węzeł, komponent,
zależność, lokacja
dynamika
model dynamiczny
diagramy stanu
stan, zdarzenie, przejście,
akcja, aktywność
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd
14
marzec 2001
Model a diagram; modele w UML (3)
Główny obszar
działania
Model
Diagramy
Podstawowe
pojęcia
dynamika, c.d.
model dynamiczny,
c.d.
diagramy aktywności
diagramy interakcji
stan, aktywność, fork,
join, romb decyzyjny
interakcja, współpraca,
komunikat, aktywacja
model
zarządzania
diagramy
pakietów
pakiet, podsystem
rozszerzalnośćwszystkie modelewszystkie diagramy
stereotyp, własność
etykietowana,
ograniczenie
zarządzanie
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd
15
marzec 2001
Stereotypy (1)
Stereotypy
stanowią
pierwszy
z
trzech
mechanizmów
rozszerzalności UML. Jak każdy mechanizm rozszerzalności, dają
możliwość
definiowania
nowych
elementów,
co
wspomaga
przystosowanie UML do modelowania specyficznych procesów, do
specyficznych
preferencji
użytkownika
czy
też
pozwala
na
uszczegóławianie semantyki modelu:
Stereotypy są wyrażeniami językowymi umożliwiającymi
metaklasyfikację elementów modelu.
Istnieje lista stereotypów dla każdego rodzaju elementów modelu w
UML.
Element modelu może mieć co najwyżej jeden stereotyp (?).
Są stereotypy predefiniowane, ale użytkownicy mogą też definiować
własne stereotypy.
Stereotypy mogą mieć implikacje semantyczne (podobnie jak
ograniczenia).
Notacja:
«
nazwa stereotypu
»
lub ikona.
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd
16
marzec 2001
Stereotypy (2)
Przykłady stereotypów:
P1
P2
«include»
P3
P4
«extend»
«aktor»
Klient
Klient
jest równoważne
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd
17
marzec 2001
Wartości etykietowane
Wartości etykietowane stanowią kolejny mechanizm
rozszerzalności UML.
Pojedynczą wartość etykietowaną stanowi ciąg znaków o postaci:
słowo kluczowe = wartość.
Listę wartości etykietowanych (oddzielonych przecinkami)
umieszcza się w {}.
Dowolny element modelu może być skojarzony z listą wartości
etykietowanych.
{autor = “Jan Nowak”, termin zakończenia = “31 Maja 1999”, status = analiza}
Przykład listy wartości etykietowanych:
W ten sposób można na diagramach umieścić dowolną dodatkową
informację. Zakłada się, że narzędzia CASE umożliwią odszukanie
odpowiedniego elementu na podstawie słowa kluczowego i
skojarzonej z nim wartości.
Uwaga! Wartości etykietowane służą raczej do opisu
pojedynczego elementu modelu niż do metaklasyfikcji (patrz:
stereotypy).