Transcript Requirements Engineering Processes

UML – Unified Modeling
Language (1)
Bartosz Baliś,
Na podstawie, m.in.:
Introduction to UML: Structural and Use Case
Modeling, Cris Kobryn
 Projektowanie Obiektowe, Ian Sommerville
 Agile modeling: http://www.agilemodeling.com

Wstęp



UML – Unified Modeling Language
 Graficzny język do analizy i projektowania obiektowego
 Standaryzuje kilka metod graficznej reprezentacji
UML jest językiem – posiada składnię (notacja graficzna)
i semantykę (znaczenie symboli graficznych)
Diagramy




4 strukturalne (klas, obiektów, komponentów, wdrożeń)
5 do modelowania zachowania (przypadków użycia, sekwencji,
aktywności, współpracy / kolaboracji, stanów)
3 do zarządzania modelem (pakiety, podsystemy, modele)
Historia





UML 1.1 – 1997
UML 1.3 – listopad 1999
UML 1.4
UML 1.5
Obecnie – UML 2.0 – znaczne zmiany
Zasadnicze składniki UML



Elementy modelu (klasy, interfejsy, komponenty,
przypadki użycia, etc.)
Relacje pomiędzy nimi (powiązania, generalizacja,
zależności, etc.)
Diagramy (diagramy klas, diagramy przypadków
użycia, diagramy interakcji, etc.)
Przykład diagramu klas
Element
<<covalent>>
C
Carbon
Hydrogen
C
<<covalent>>
C
H
Przykład diagramu obiektów
(instancji klas)
:Hydrogen
:Hydrogen
:Hydrogen
:Carbon
:Carbon
:Hydrogen
:Hydrogen
:Hydrogen
Modele struktury
Modelowanie struktury


Model systemu, który podkreśla strukturę
obiektów, powiązania między klasami, ich
atrybuty i operacje
Rodzaje diagramów:

Statyczne diagramy struktury


Klas, obiektów
Diagramy implementacji

Komponentów, wdrożeń
Model struktury – zasadnicze elementy
Nazwa
Opis
klasa
Opis zbioru obiektów, które
posiadają te same atrybuty,
operacje, powiązania i semantykę
Zbiór operacji, które określają
zachowanie się elementu
interfejs
Notacja
«interface»
Moduł kodu, który zawiera
implementację i udostępnia zbiór
interfejsów
węzeł (node) Fizyczny zasób obliczeniowy, na
którym działa system.
komponent
ograniczenie Komentarz, warunek, ograniczenie
(constraint)
{constraint}
Model struktury – podstawowe relacje
Construct
Description
powiązanie /
skojarzenie
(association)
agregacja
Relacja pomiędzy klasami
generalizacja
relacja określająca, że dany element
jest generalizacją innego (który jest
jego specjalizacją)
Relacja określająca, iż zmiana w
jednym elemencie wpływa na element
zależny
Relacja pomiędzy specyfikacją i jej
implementacją
zależność
realizacja
Powiązanie całość-część
Syntax
Statyczne diagramy struktury


Diagram klas
Diagram obiektów – instancji klas
Klasy: przykład
Pracownik
nazwisko : string
adres : string
dataUrodzenia : Date
numerPracownika : integer
PESEL : string
dział : Dział
przełożony : Pracownik
wynagrodzenie : integer
tatus:
{current,
left, retired}
stan : {zatrudniony,
zwolniony,
emerytowany}
taxCode: integer
NIP : integer
. ..
...
dołącz()
join ()
leave ()
opuść()
retire ()
przejdźNaEmeryturę()
changeDetails (
zmieńSzczegóły()
Diagram klas – przykład
Hierarchia uogólnień – przykład
Pracownik
Kierownik
Programista
zarządzaneBudżety
dataPrzyjęcia
przedsięwzięcie
językiProg
Kierownik
Przedsięwzięcia
Kierownik
Działu
Kierownik
Strategiczny
przedsięwzięcie
dział
obowiązki
Powiązania – przykład
Pracownik
jest-członkiem
Dział
jest-zarządzany-przez
zarządza
Kierownik
Powiązania – jedno i dwukierunkowe
http://www.agilemodeling.com
Agregacja i kompozycja




Agregacja i kompozycja – obiekt
składa się z innych obiektów
Agregacja – zespół składa się
z pracowników
Kompozycja – samolot składa się
z części
Reguła: kompozycja jest "silniejszą"
formą agregacji – jeśli całość jest
niszczona, to jej części także, w
przypadku agregacji tak nie jest.
Generalizacja-specjalizacja – przykład:
taksonomia obiektów
Interfejsy: notacja skrótowa
StoreHome
Store
-storeId: Integer
-POSlist: List
POSterminalHome
POSterminal
<<use>>
POSterminal
Store
Fig. 3-29, UML Notation Guide
+create()
+login(UserName, Passwd)
+find(StoreId)
+getPOStotals(POSid)
+updateStoreTotals(Id,Sales)
+get(Item)
Interfejsy: notacja rozszerzona
StoreHome
-storeId: Integer
-POSlist: List
POSterminalHome
POSterminal
<<use>>
POSterminal
Store
<<interface>>
Store
+getPOStotals(POSid)
+updateStoreTotals(Id,Sales)
+get(Item)
Fig. 3-29, UML Notation Guide
+create()
+login(UserName, Passwd)
+find(StoreId)
+getPOStotals(POSid)
+updateStoreTotals(Id,Sales)
+get(Item)
Diagram obiektów
Diagramy implementacji


Pokazują takie aspekty implementacji
jak struktura kodu źródłowego, oraz
struktura podczas wykonywania się
systemu
Rodzaje
Diagram komponentów
 Diagram wdrożeń (deployment)

Komponenty i wdrożenia: przykład
Komponenty – przykłady
ShoppingSessionHome
<<Session>>
ShoppingSession
ShoppingSession
<<Entity>>
030303zak:Order
OrderHome
<<auxiliary>>
:OrderPK
OrderHome
<<focus>>
:Order
Order
OrderPK
OrderInfo
<<auxiliary>>
:OrderInfo
Order
Fig. 3-99, UML Notation Guide
Diagram komponentów – przykład
ShoppingSessionHome
ShoppingSession
<<EJBSession>>
ShoppingSession
<<EJBEntity>>
Catalog
CatalogHome
CatalogPK
<<auxiliary>>
CatalogPK
CatalogHome
<<focus>>
Catalog
CatalogInfo
<<auxiliary>>
CatalogInfo
Catalog
Catalog
<<file>>
CatalogJAR
ShoppingCartHome
ShoppingCart
<<EJBEntity>>
ShoppingCart
Fig. 3-95, UML Notation Guide
Diagram wdrożeń – przykład
:Client
<<browser>>
:OpenSourceBrowser
videoStoreServer:AppServer
<<Container>>
VideoStoreApplication
<<Session>>
ShoppingSession
<<Focus>>
ShoppingSession
<<Entity>>
Catalog
<<Focus>>
Catalog
<<Entity>>
ShoppingCart
<<Focus>>
ShoppingCart
:DBServer
<<database>>
:VideoStoreDB
Fig. 3-97, UML Notation Guide
Projektowanie oparte o interfejsy
Projektowanie oparte o interfejsy
(interface-based design)



Skupia się na specyfikacji interfejsów systemu
Oddziela się specyfikację operacji jakiejś usługi
(interfejsy) od ich realizacji (implementacja)
Przykład: CORBA IDL (Interface design
language) jako projektowanie aplikacji
rozproszonych oparte o interfejsy



IDL definiuje interfejsy obiektów bez nakładania
ograniczeń na ich implementację
Definiuje strukturę aplikacji rozproszonej
Nie pozwala na specyfikowanie zachowania obiektów
lub relacji pomiędzy klasami poza generalizacją
Przykład: punkt sprzedaży (point of sale)
module POS
{
typedef long
POSId;
typedef string Barcode;
interface InputMedia
{
typedef string OperatorCmd;
void
void
barcode_input(in Barcode item);
keypad_input(in OperatorCmd cmd);
};
interface OutputMedia
{
boolean
output_text(in string string_to_print );
};
...
Generic IDL Point of Sale (POS) example. [Siegel 00]
Przykład punkt sprzedaży (c.d.)
...
interface
{
void
void
void
void
void
void
};
POSTerminal
login();
print_POS_sales_summary();
print_store_sales_summary();
send_barcode(in Barcode item);
item_quantity(in long quantity);
end_of_sale();
};
#endif /* _POS_IDL_ */
From [Kobryn 00].
Point-of-Sale
«IDLinterface»
IinputMedia
«IDLinterface»
IPOSterminal
+storeRef : Store
+storeAccessRef : StoreAccess
+outputMediaRef : OutputMedia
+taxRef : Tax
+POSid : Integer
+itemBarcode : Integer
+itemQuantity : Integer
+itemInfo : ItemInfo
+itemPrice : Currency
+itemTaxPrice : Currency
+itemExtension : Currency
+saleSubtotal : Currency
+taxableSubtotal : Currency
+saleTotal : Currency
+saleTax : Currency
+POSlist : List
+initialization()
+login()
+printPOSsalesSummary()
+printStoreSalesSummary()
+setItemQuantity()
+sendBarcode()
+endSale()
+POSref : POSterminal
InputMedia
+initialization()
+barcodeInput()
+keypadInput()
«IDLinterface»
IOutputMedia
OutputMedia
+outputText()
POSterminal
+totals : Totals
+POSlist : List
+initialization()
+login()
+getPOStotals()
+updateStoreTotals()
Store
«IDLinterface»
IStoreAccess
«IDLinterface»
ITax
Tax
«IDLinterface»
IStore
+rate : float
+initialization()
+calculateTax()
+findTaxablePrice()
StoreAccess
+depotRef : Depot
+taxRef : Tax
+storeMarkup : float
+storeId : Integer
+initialization()
+findPrice()
Przypadki użycia
Diagram przypadków użycia
T el ep hon e Ca ta log
C he c k
s ta tus
P la ce
or de r
S al es pe r so n
F ill or de r s
S hip pin g C le r k
C us tom er
E sta bl is h
c re di t
S upe r vi so r
Fig. 3-53, UML Notation Guide
Relacje pomiędzy przypadkami użycia

Generalizacja (uogólnienie)


Dołączanie (include)


Jeden przypadek użycia jest uogólnieniem
innego
Zachowanie dołączanego przypadku użycia jest
dołączane do podstawowego przypadku użycia
Rozszerzenie (extend)

<<include>>
Zachowanie rozszerzającego przypadku użycia
jest dołączane do podstawowego przypadku
użycia w ściśle określonym miejscu (określanym
przez tzw. extension point)
<<extend>>
Extend vs. include

<<include>>


Używa się wtedy, gdy dołączany przypadek
użycia musi być wykonany
<<extend>>


Używa się, gdy rozszerzający przypadek użycia
może lecz nie musi być wykonany
Przez zdefiniowanie tzw. extension points określa
się w którym dokładnie miejscu może być
wykonany rozszerzający przypadek użycia
Diagram przypadków użycia – przykład
Update Medical
Plan
<<include>>
Update Dental
Plan
<<include>>
Update
Insurance Plan
<<include>>
Update Benefits
Employee
______________
Extension points
benefit options:
after required enrollments
<<extend>>
employee requests
reimbursement option
Elect
Reimbursement
for Healthcare
extension point
name and
location
<<extend>>
employee requests
stock purchase option
Elect Stock
Purchase
extension
condition
Relacje pomiędzy aktorami
1
*
Place
Order
Salesperson
1
*
Establish
Credit
Supervisor
Fig. 3-55, UML Notation Guide
Opis przypadku użycia
Actors:
traveler, client account db, airline reservation system
Preconditions:
Traveler has logged on to the system and selected ‘change flight
itinerary’ option

Basic
course (podstawowy przebieg)
System retrieves traveler’s account and flight itinerary from client
account database
 System asks traveler to select itinerary segment she wants to
change; traveler selects itinerary segment.
 System asks traveler for new departure and destination
information; traveler provides information.
 If flights are available then
 …
 System displays transaction summary.

Alternative

courses (gdy wystąpi jakaś sytuacja wyjątkowa)
If no flights are available then …
Opis przypadku użycia – tabela
Dalsza lektura


Ian Sommerville, Inżynieria oprogramowania,
r. 12
http://www.agilemodeling.com  Artifacts,
UML 2