Transcript No Slide Title

Projektowanie systemów informacyjnych
Wykład 3
Wprowadzenie do UML
Ewa Stemposz, Kazimierz Subieta
Instytut Podstaw Informatyki PAN,
Warszawa
Polsko-Japońska Wyższa Szkoła
Technik Komputerowych, Warszawa
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 1
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 2
marzec 2001
Cykl życiowy produktu informatycznego
Fazy cyklu życiowego produktu informatycznego:
Faza strategiczna
Faza specyfikacji i analizy wymagań --> projektowanie (modelowanie)
pojęciowe
czas
Faza projektowania --> projektowanie logiczne
Faza konstrukcji (implementacji) --> projektowanie fizyczne
Faza testowania
Faza konserwacji
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 3
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, itp. 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 4
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 służących
do modelowania dziedziny problemowej stanowiącej przedmiot projektowanego
systemu.
Metodyka jest wykorzystywana zarówno do projektowania pojęciowego, jak i
logicznego czy fizycznego.
Metodyka ustala fazy realizacji projektu, a ponadto dla każdej z faz projektu
wyznacza:






E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 5
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ć,
notację, którą należy używać.
marzec 2001
Metodyka (2)
Notacja, czyli
zbiór oznaczeń, jest tu
wykorzystywana do dokumentowania wyników
poszczególnych faz projektu - pośrednich i
końcowych. Notacja służy więc 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.
Rodzaje
notacji:
 tekstowa
 specyfikacje - ustrukturalizowany zapis tekstowy i numeryczny
 notacje graficzne
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 i mechanika.
Dana notacja może być wykorzystywana w innych metodykach.
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 6
marzec 2001
Pragmatyka języka do modelownia
Język do modelowania, jak każdy inny język, oprócz semantyki i składni posiada
jeszcze jeden ważny aspekt: pragmatykę.
Semantyka określa, co należy rozumieć pod przyjętymi oznaczeniami (notacją).
Składnia określa, jak wolno łączyć ze sobą przyjęte oznaczenia.
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.
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 7
marzec 2001
Unified Modeling Language (UML)
RATIONAL SOFTWARE CORPORATION http://www.rational.com/uml
(dokumentacja on line)
UML 0.8-0.9,
UML 1.0,
UML 1.1,
UML 1.3,
styczeń 1995 - wrzesień 1996
styczeń 1997, przesłany do OMG
koniec 1997, zatwierdzony jako składnik standardu OMG
kwiecień 1999 (mówi się o wersji 1.4, ale brak danych)
Połączone siły trzech znanych metodologów oprogramowania:
Grady Booch
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 8
Ivar Jacobson
James Rumbaugh
marzec 2001
UML: Krótka charakterystyka (1)
 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 [http://www.rational.com/uml] : "The Unified
Modeling Language (UML) is a language for specifying, constructing, visualizing,
and documenting the artifacts of a software-intensive system."
 Notacja UML, która opiera się o podstawowe
wykorzystana w dowolnej metodyce.
pojęcia obiektowości
może być
 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.
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 9
marzec 2001
UML: Krótka charakterystyka (2)
Wady i zalety metodyk, których autorami są twórcy UML:
OMT (Rumbaugh): dobry do modelowania dziedziny przedmiotowej. Nie przykrywa
dostatecznie dokładnie zarówno aspektu użytkowników systemu, jak i aspektu
implementacji (konstrukcji).
OOSE (Jacobson): dobrze podchodzi do kwestii modelowania użytkowników i cyklu
życiowego systemu. Nie przykrywa dokładnie modelowania dziedziny przedmiotowej
jak i aspektu implementacji (konstrukcji).
OOAD (Booch): dobrze podchodzi do kwestii projektowania, konstrukcji i związków
ze środowiskiem implementacji. Nie przykrywa dostatecznie dobrze fazy rozpoznania i
analizy wymagań użytkowników.
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 10
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 pakietów
Diagramy te zapewniają uzyskanie wielu perspektyw projektowanego
systemu w trakcie jego budowy.
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 11
marzec 2001
Model a diagram; modele w UML
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łego użytkownika (za pomocą diagramów przypadków użycia),
 model obiektowy przedstawiający statyczną budowę, czyli 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 12
marzec 2001
Stereotypy (1)
Stereotypy stanowią jeden z mechanizmów rozszerzalności UML. Jak każdy
mechanizm rozszerzalności, dają możliwość definiowania nowych elementów, co
ułatwia przystosowanie UML do modelowania specyficznego procesu, 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 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 (ograniczenia).
Notacja: «nazwa stereotypu» lub ikona.
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 13
marzec 2001
Stereotypy (2)
Przykłady stereotypów:
«extend»
«include»
P1
«aktor»
Klient
P2
P3
P4
jest równoważne
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 14
Klient
marzec 2001
Wartości etykietowane
 Wartości etykietowane są następnym z mechanizmów rozszerzalności UML
 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.
Przykłady list wartości etykietowanych:
{autor = “Jan Nowak”, termin zakończenia = “31 Maja 1999”, status = analiza}
{abstract = TRUE}
można skrócić do
{abstract}
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).
E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 15
marzec 2001