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:

czas Faza strategiczna Faza specyfikacji i analizy wymagań -->

projektowanie (modelowanie) pojęciowe

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:

pojęciowy modelowanie pojęciowe

(conceptual modeling) (conceptual model) odnoszą się do procesów myślowych, do wyobrażeń towarzyszących pracy nad oprogramowaniem.

oraz

model

 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 wspierających proces konstruowania systemu (realizacji projektu).

Metodyka jest wykorzystywana zarówno do

logicznego czy fizycznego

.

projektowania pojęciowego, jak i Metodyka ustala fazy realizacji projektu, a ponadto dla każdej z faz projektu wyznacza:

      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ć.

E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 5 marzec 2001

Metodyka (2)

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ęć wyobraźnię, a także jako środek ułatwiający komunikację zarówno między członkami zespołu i 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

z

alety 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

Język do modelowania

Język do modelowania, jak każdy inny język, oprócz posiada jeszcze jeden ważny aspekt:

pragmatykę

.

semantyki, składni

i

notacji 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.

języka jest sprawą podstawową.

W metodykach pragmatyka stosowanego

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, styczeń 1995 - wrzesień 1996 UML 1.0, styczeń 1997, przesłany do OMG UML 1.1, UML 1.3, koniec 1997, zatwierdzony jako składnik standardu OMG kwiecień 1999 UML 1.4 listopad 2000

Połączone siły trzech znanych metodologów oprogramowania: Grady Booch Ivar Jacobson James Rumbaugh

E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 8 marzec 2001

Zalecana literatura

 E. Stemposz, K.SUBIETA: Slajdy do wykładu “Projektowanie systemów informacyjnych”  K. SUBIETA: Obiektowość w projektowaniu i bazach danych, Akademicka Oficyna Wydawnicza PLJ, 1998  K. SUBIETA: Słownik terminów z zakresu obiektowości, Akademicka Oficyna Wydawnicza PLJ, 1999  M. Fowler, K. Scott: UML Distilled, Addison-Wesley 1997  J. Rumbaugh, I. Jacobson, G. Booch: The Unified Modeling Language Reference Manual, Addison-Wesley, 1999  OMG Unified Modeling Language. Specification, Version 1.4, The Object Management Group, September 2001, http://www.omg.org

 T. Quatrani: Visual Modeling with Rational Rose 2000 and UML, Addison-Wesley, 2000  C.Larman: Applying UML and Patterns. An Introduction to Object-Oriented Analysis and Design, Prentice-Hall, Inc., 1998 E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 9 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: "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 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.

E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 10 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 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 pakietów Diagramy te zapewniają uzyskanie wielu perspektyw projektowanego systemu w trakcie jego budowy.

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łego użytkownika (za pomocą

diagramów przypadków użycia

), 

model obiektowy

pomocą przedstawiający statyczną budowę, czyli strukturę systemu (za

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 diagramu klas metodami

modelu dynamicznego (zachowań)

jest wypełnienie 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

struktura

Model

model obiektowy model przypadków użycia model implementacji

Diagramy

diagram klas diagram obiektów

Podstawowe pojęcia

klasa, obiekt, asocjacja, generalizacja, zależność, realizacja, interface diagramy przypadków użycia aktor, przypadek użycia, «include», «extend», generalizacja diagramy komponentów komponent, interface, zależność, realizacja diagramy wdrożeniowe 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

dynamika, c.d.

Model Diagramy

model dynamiczny, c.d.

diagramy aktywności

Podstawowe pojęcia

stan, aktywność, fork, join, romb decyzyjny diagramy interakcji interakcja, współpraca, komunikat, aktywacja zarządzanie model zarządzania diagramy pakietów pakiet, podsystem rozszerzalność wszystkie modele wszystkie diagramy stereotyp, własność etykietowana, ograniczenie E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 15 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 16 marzec 2001

Stereotypy (2)

Przykłady stereotypów: P1

« include »

P2 P3

« extend »

P4

« aktor »

Klient

jest równoważne

Klient

E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 17 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 18 marzec 2001