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