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, 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 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 innych 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 i 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 semantyki,
składni i notacji 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

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

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
10

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
11

marzec 2001

UML: Krótka charakterystyka (2)

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.

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
12

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
13

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 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
14

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
15

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
16

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
17

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
18

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.

{autor = “Jan Nowak”, termin zakończenia = “31 Maja 1999”, status = analiza}

Przykłady list wartości etykietowanych:

{abstract = TRUE}

{abstract}

można skrócić do

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