7
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 duso (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

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

  • Upload
    lediep

  • View
    213

  • Download
    0

Embed Size (px)

Citation preview

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”