UML - ce.unipr.itaferrari/SE/SE/UML.pdf · 2 Tipidirequisi • Funzionali" – descrivono"le"funzionalitàche"il"sistemarende"disponibili" all’utente"" (normalmente"interazione"utenteUsistema)"

1  

UML  

Unified  Modeling  Language  

Cos’è  UML  

•  E’  un  linguaggio  di  proge&azione,  da  non  confondere  con  i  linguaggi  di  programmazione  (C,  C++,  Java,…)  

•  Fornisce  una  serie  di  diagrammi  per  rappresentare  ogni  Cpo  di  modellazione  

•  Alcuni  ambienC  di  programmazione  sono  in  grado  di  converCre  diagrammi  UML  in  codice  e  viceversa  

Diagrammi  UML  

•  diagramma  dei  casi  d’uso  (use  case)  •  diagramma  delle  classi  (class)  •  diagramma  di  sequenza  (sequence)  •  diagramma  di  collaborazione  (collaboraCon)  •  diagramma  di  stato  (statechart)  •  diagramma  delle  aJvità  (acCvity)  •  diagramma  dei  componenC  (component)  •  diagramma  di  distribuzione  (deployment)  

Analisi  di  un  problema  

Diagramma  dei  casi  d’uso  

Definizione  dei  requisiC  •  RequisiC:  insieme  delle  funzionalità  che  il  sistema  deve  rendere  disponibili  agli  utenC  (non  necessariamente  persone)  

•  Si  definisce    –  “cosa”  fa  il  sistema  –  non  “come”  lo  fa  

•  L’insieme  dei  requisiC  descrive  il  comportamento  esterno  del  sistema  (black  box)  

•  In  UML  -­‐>  diagramma  dei  casi  d’uso  –  aWori  –  casi  d’uso      

Un  esempio  

2  

Tipi  di  requisiC  

•  Funzionali  –  descrivono  le  funzionalità  che  il  sistema  rende  disponibili  all’utente    (normalmente  interazione  utente-­‐sistema)  

–  sono  gli  unici  che  compaiono  nei  diagramma  dei  casi  d’uso  •  Non  funzionali  –  descrivono  caraWerisCche  del  sistema    (per  esempio  prestazionali)  

•  Tecnologici  –  descrivono  aspeJ  tecnologici  (esempio  Cpo  di  linguaggio  uClizzato)  

Priorità  dei  requisiC  

•  Must  –  indispensabile  

•  Should  – desiderabile  

•  May  – opzionale  

Diagramma  UML    dei  casi  d’uso  

•  AWori  –  EnCtà  che  non  fanno  parte  del  sistema  ma  interagiscono  con  esso  

–  rappresentaC  da  icone  con  la  denominazione  del  ruolo  •  Casi  d’uso  –  ovali  con  all’interno  la  descrizione  (verbo/complemento)  

•  Linee  –  di  collegamento  fra  aWori  e  casi  d’uso  –  è  possibile  aWribuire  un  nome  per  chiarire  il  ruolo  che  svolge  l’aWore  

Relazione  fra  casi  d’uso  •  Inclusione  

–  Il  caso  d’uso  puntato  è  necessariamente  compreso  nel  caso  d’uso  da  cui  parte  la  freccia  

•  Estensione  –  Il  caso  d’uso  puntato  è  

facoltaCvamente  compreso  nel  caso  d’uso  da  cui  parte  la  freccia  

•  Generalizzazione  –  Il  caso  d’uso  da  cui  parte  la  

freccia  è  un  caso  parCcolare  di  quello  puntato  

Esempio   Rappresentazione  alternaCva  

3  

Indicazioni  

•  Individuare  gli  aWori  – chi  usa  il  sistema?  – chi  oJene  informazioni  dal  sistema?  – chi  fornisce  informazioni  al  sistema?  – quali  altri  sistemi  interagiscono  con  questo?  

•  Individuare  i  casi  d’uso  – per  quale  scopo  gli  aWori  usano  il  sistema?  – quali  funzioni  sono  richieste?  – quali  informazioni  sono  elaborate  dal  sistema?  

Specifica  dei  casi  d’uso  

•  Nome  del  Caso  d’Uso  •  Precondizioni  – condizioni  che  devono  essere  verificate  prima  di  eseguire  il  caso  d’uso  

•  Postcondizioni  – stato  in  cui  il  caso  d’uso  lascia  il  sistema  

Un  esempio  

•  Negozio  di  noleggio  DVD:  informaCzzazione  della  gesCone  presCC  

•  Il  cliente  uClizza  il  sistema  per  ricercare  e  richiedere  in  presCto  un  film  

•  Il  negoziante  uClizza  il  sistema  per  registrare  i  presCC  e  i  rientri  dai  presCC:  –  richiede  i  daC  del  cliente  prima  di  effeWuare  il  presCto  –  verifica  la  disponibilità  del  film  di  cui  sono  presenC  più  copie  

Diagramma  dei  casi  d’uso  

Maggior  deWaglio   Specifica  di  un  caso  d’uso  

4  

OOAD  

Object-­‐oriented  analysis  and  design  

Diagramma  delle  classi  

•  Rappresenta  le  classi  che  compongono  il  sistema,  cioè  le  collezioni  di  oggeJ,  ciascuno  con  il  proprio  stato  e  comportamento  (aWribuC  ed  operazioni)  

•  Specifica,  mediante  associazioni,  le  relazioni  fra  le  classi.  

Un  esempio  

Nome

Attributi (proprietà)

Operazioni (metodi)

Classe  Metodi  e  AWribuC  

SchedaAnagrafica

-nome:String-cognome:String

+getNome():String+setNome(nome:String):void+getCognome():String+setCognome(cognome:String):void

public class SchedaAnagrafica {!! private String nome;!! private String cognome;!! public String getNome() {! return nome;! }! public void setNome(String nome) {!

! this.nome = nome;! }! public String getCognome() {! return cognome;! }! public void setCognome(String cognome) {! this.cognome = cognome;! }!}!

Modificatori  

•  +Public:  Libero  Accesso  •  #Protected:  Accessibile  dalle  SoWoclassi  

•  -­‐Private:  Accessibile  solo  all’interno  della  classe  

•  StaCc:  Accessibili  anche  senza  creare  istanze  

Ereditarietà  

5  

Classi  AstraWe  e  Metodi  AstraJ  

•  Una  Classe  AstraWa  conCene  metodi  privi  di  implementazione  

•  Per  questa  ragione  non  può  essere  istanziata  •  Il  corsivo  permeWe  di  disCnguere  le  parC  astraWe  da  quelle  concrete  

Interfacce  

•  Insieme  di  operazioni  che  la  classe  offre  ad  altre  classi  

•  Rappresentata  come  una  classe  con  specifica  <<interface>>  

•  Non  ha  aWribuC  ma  solo  la  dichiarazione  di  metodi  

Interfaccia:  esempio  

public interface Pesabile {

public int getPeso();

}

Ereditarietà  mulCpla  

interfaceMediaRecorder

+record:void

VideoRegistratore

LettoreDVD

interfaceMediaPlayer

+play:void+stop:void+pause:void+fastForward:void+rewind:void

RegistratoreDVD

"   In  Java  per  esempio  non  è  ammessa  l’ereditarietà  mulCpla  (possibile  in  C++)  

"   Le  interfacce  permeWono  di  ovviare  a  questo  problema:  una  classe  può  ereditare  da  una  sola  classe  ma  implementare  varie  interfacce  

Associazione  •  Un’Associazione  rappresenta  la  possibilità  che  un’istanza  ha  di  inviare  un  messaggio  ad  un’altra  istanza  

•  In  UML  viene  rappresentata  con  una  freccia,  in  Java  viene  implementata  Cpicamente  con  un  reference  

Associazione:  esempio  

public class Automobile { private Motore motore; public void accendi() { motore.inserisciMiscela(); motore.accendiCandele(); } }

public class Motore { public void inserisciMiscela() {…}; public void accendiCandele() {…}; }

6  

Dipendenza  •  La  Dipendenza  indica  che  un  determinato  oggeWo  può,  in  certe  circostanze,  chiamare  i  metodi  di  un  altro  pur  senza  possederne  un’istanza  

•  La  classe  dipendente  presuppone  l’esistenza  della  classe  da  cui  dipende.  

•  Non  vale  il  viceversa  •  In  UML  la  dipendenza  viene  rappresentata  con  una    freccia  traWeggiata.  In  java  Cpicamente  l’oggeWo  dipendente  riceve  un’istanza  dell’oggeWo  da  cui  dipende  come  argomento  di  una  chiamata  a  metodo  

Aggregazione  •  L’Aggregazione  rappresenta  un’associazione  uno  a  molC  

•  Esprime  conceWo  “è  parte  di  ”  (part  of),  che  si  ha  quando  un  insieme  è  relazionato  con  le  sue  parC  

•  In  UML  l’aggregazione  viene  rappresentato  con  una  freccia  con  la  punta  a  diamante  

Esempio  di  Aggregazione   Composizione  

•  Una  Composizione  è  una  relazione  uno  a  molC  che  implica  una  forma  di  esclusività  

•  E’  un  caso  parCcolare  di  aggregazione  in  cui:  –  la  parte  (componente)  non  può  esistere  da  sola,  cioè  senza  la  classe  composto  

–  una  componente  apparCene  ad  un  solo  composto  •  La  distruzione  dell’oggeWo  che  rappresenta  il  “tuWo”  provoca  la  distruzione  a  catena  delle  “parC”    

•  Il  diamante  si  disegna  pieno  

Esempio  di  Composizione  

7  

aggregazione  /  composizione  •  Per  disCnguere  l’aggregazione  dalla  composizione  

possiamo  chiederci  che  desCno  devono  avere  gli  oggeJ-­‐parte  al  momento  che  viene  distruWo  l’oggeWo-­‐tuWo  

•  Se  non  ha  senso  che  gli  oggeJ-­‐parte  sopravvivano  all’oggeWo-­‐tuWo,  allora  siamo  di  fronte  a  una  relazione  composiCva  (la  cancellazione  del  rombo  pieno  che  la  rappresenta  graficamente  richiede  la  cancellazione  del  bordo  e  dell’area  interna)  

•  Se  ha  invece  senso  che  gli  oggeJ-­‐parte  sopravvivano  autonomamente  all’oggeWo-­‐tuWo,  allora  si  ha  una  relazione  aggregaCva  (la  cancellazione  del  rombo  vuoto  che  la  rappresenta  graficamente  avviene  cancellando  il  bordo,  ma  non  richiede  la  cancellazione  dell’area  interna)  

Esempio  

Standard  UML  

•  Molteplicità  –  1    esaWamente  una  istanza  –  N  esaWamente  N  istanze  –  1..*  una  o  più  istanze  –  0..*  zero  o  più  istanze  –  1..N  una  o  più  istanze  (massimo  N)  –  0..N  zero  o  più  istanze  (massimo  N)  

•  Il  nome  dell’aWributo  che  realizza  un’associazione  staCca  tra  classi  non  deve  essere  compreso  nell’elenco  degli  aWribuC,  ma  deve  essere  indicato  sull’estremita  della  rappresentazione  grafica  dell’associazione  

Esempio  “correWo”