Unified Modeling Language: Past, Present and Future

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 39

Unified

 Modeling  Language:    
Past,  Present  and  Future  
Ivar  Jacobson  
With  most  slides  from  Steve  Cook  
SoBware  Architect,  MicrosoB  Visual  Studio  
Architecture  Board  and  Board  of  Directors,    
Object  Management  Group  
Agenda  
•  History  
•  UML  today  
•  UML  dilemmas  
•  Future  of  UML  
Agenda  
•  History  
•  UML  today  
•  UML  dilemmas  
•  Future  of  UML  
The  Three  Amigos  and  the  Unified  Method  

Ivar  Jacobson  et  al:  


Grady  Booch:     Object  Oriented  SoBware  Engineering  (1992)  
Object  Oriented  Design  (1991)  
Object  Oriented  Analysis  and  Design  (1994)  

James  Rumbaugh  et  al:  


Object  Oriented  Modeling  and  Design  (1991)  
The  OMG:  Analysis  and  Design  
Object  Analysis  and  Design:  Survey  of  
Methods  1992  
[Andrew  HuX,  ICL]  

1995/95-­‐09-­‐35:  Analysis  &  Design  RFI  


[Mary  Loomis,  HP]  

ad/96-­‐05-­‐01:  Object  Analysis  and  Design  PTF  -­‐  RFP  1  


[Mary  Loomis,  HP]  

ad/97-­‐08-­‐02:  UML  1.1    


RaZonal  SoBware,  MicrosoB,  HewleX-­‐Packard,  
Oracle,  Sterling  SoBware,  MCI  Systemhouse,  Unisys,  
ICON  CompuZng,  IntelliCorp,  i-­‐Logix,  IBM,  ObjecTime,  
PlaZnum  Technology,  Ptech,  Taskon,  Reich  
Technologies,  SoBeam  
UML  1.1  diagrams  
Models,  Views,  and  Diagrams  
A model is a complete
description of a system
from a particular
State
perspective State
Diagrams
Class
Diagrams
Use Case Diagrams
Use Case
Diagrams State
Use Case Use Case
Diagrams State
Diagrams
Use Case Diagrams Object
Diagrams
Diagrams
Sequence Diagrams
Diagrams
Diagrams

Scenario State
Scenario
Diagrams State
Diagrams
Collaboration
Diagrams Models Component
Diagrams
Diagrams Diagrams

Scenario Component
Scenario
Diagrams
Component
Diagrams
Deployment
Statechart
Diagrams Diagrams
Diagrams Diagrams
Activity
Diagrams
Use  Case  Diagram  
•  Captures  system  funcZonality  as  seen  by  users    
•  Visualize  the  interacZon  of  the  system  with  
the  outside  world  

Request  Course  Roster  

Student Professor

Register  for  Courses  

Billing  System Maintain  Course  InformaZon  

Registrar
Use  Case  Diagram  
•  Built  in  early  stages  of  development  
•  Purpose  
–  Specify  the  context  of  a  system  
–  Capture  the  requirements  of  a  system  
–  Validate  a  system’s  architecture  
–  Drive  implementaZon  and  generate  test  cases  
•  Developed  by  analysts  and  domain  experts  
Class  Diagram  
•  Captures  the  vocabulary  of  a  system    
•  Shows  the  structure  of  your  soBware  

RegistraZonForm ScheduleAlgorithm

0..*
1 RegistraZonManager
addStudent(Course,  Student)
1 Course
RegistraZonUser 0..*name
numberCredits
name Student
open()
addStudent(StudentInfo)
major
1
3..10
Professor 1..*
4 CourseOffering
tenureStatus locaZon
1
0..4
open()
addStudent(Student)
The  Physical  World  
•  Component  diagrams  illustrate  the  
organizaZon  and  dependencies  among  
soBware  components  
•  They  capture  the  physical  structure  of  the  
implementaZon  
Billing.exe Register.exe
Billing  
System  

People.dll
User  
Course.dll
Course  
Deploying  the  System  
•  The  deployment  diagram  visualizes  the  
distribuZon  of    components  across  the  
enterprise  
•  They  capture  the  topology  of  a  system’s  
hardware  
RegistraZon Database

Main  
Library Building

Dorm
Sequence  Diagram  
•  A  sequence  diagram  shows  step-­‐by-­‐step  what  
has  to  happen  to  accomplish  a  piece  of  
funcZonality  provided  by  the  system  

 :  Student registraZon   registraZon   math  101 math  101  


form manager secZon  1

1:  fill  in  info

2:  submit

3:  add  Joe  to  Math  101


4:  add  Joe
5:  are  you  open?

6:  add  Joe
CollaboraZon  Diagram  
•  A  collaboraZon  diagram  displays  object  
interacZons  organized  around  objects  and  
their  links  to  one  another  
course  form  :  
1:  set  course  info CourseForm
2:  process

 :  Registrar 3:  add  course

aCourse  :   theManager  :  
Course CurriculumManager

4:  new  course
The  State  of  an  Object  
•  A  state  transiZon  diagram  shows  the  lifecycle  
of  a  single  class    

Add  student[  count  <  10  ]


Add  Student  /  
IniZalizaZon Set  count  =  0
Open
do:  IniZalize  course entry:  Register  student
exit:  Increment  count
Cancel
Cancel [  count  =  10  ]
Canceled
do:  NoZfy  registered     Closed
                 students Cancel
do:  Finalize  course
AcZvity  Diagram  
Create    
curriculum  
Select  courses    
to  teach  
Create    
catalog  

Place  catalog     Mail  catalog    


in  bookstore   to  students  

Open    
registraZon  
[  RegistraZon  Zme  period  expired  ]  
Close    
registraZon  
Swimlanes  
Registrar Professor
Create    
curriculum  

Select  courses    
Create     to  teach  
catalog  

Place  catalog     Mail  catalog    


in  bookstore   to  students  

Open    
registraZon  
[  RegistraZon  Zme  period  expired  ]  
Close    
registraZon  
UML  1.x  Development  
•  V1.1  November  1997  
•  [V1.2  was  an  internal  beta  release  never  
issued  as  a  formal  specificaZon]  
•  V1.3  March  2000  
•  V1.4  September  2001  
•  V1.5  March  2003  –  combines  V1.4  and  AcZon  
SemanZcs  –  a  step  towards  Executable  UML.  
 
UML  2  –  “we  want  more”  
•  UML  2.0  RFI  (Request  for  InformaZon)  issued  August  1999.  
•  RFP  (Request  for  Proposals)  issued  September  2000.  
 
  Mee#ngs,  mee#ngs,  mee#ngs  …  
•  UML  2.0  July  2005.  
–  No  machine-­‐readable  specificaZon  due  to  structural  inconsistencies  in  the  
spec.  
•  V2.1.1  August  2007  ==  V2.1.2  November  2007  
–  The  first  version  available  in  machine-­‐readable  form  
•  V2.2  February  2009  
–  Fixes  bugs  
•  V2.3  May  2010  
–  Fixes  bugs   Where  next?  
•  V2.4  beta  April  2011  
–  Focus  on  fixing  interoperability  bugs  
UML  2  diagrams  
The  Ball  of  Mud  
“A  successful  response  to  these  challenges  will  require  that  the  
OMG  adopt  a  sculp#ng  approach  (where  less  is  more)  rather  
than  a  mudpacking  approach  (some#mes  associated  with  a  
“ball-­‐of-­‐mud”  paFern)  to  refine  and  extend  the  UML  
architecture.”  
 
Cris  Kobryn,  UML  2001:  A  Standardiza#on  Odyssey,  
CommunicaZons  of  the  ACM,  vol.  42,  no.  10,  October  1999  
hXp://www.omg.org/spec/UML/20100901/Infrastructure.xmi  hXp://
www.omg.org/spec/UML/20100901/Superstructure.xmi  hXp://
www.omg.org/spec/UML/20100901/L0.xmi  hXp://www.omg.org/spec/
UML/20100901/L1.xmi  hXp://www.omg.org/spec/UML/20100901/L2.xmi  
hXp://www.omg.org/spec/UML/20100901/L3.xmi    hXp://www.omg.org/
spec/UML/20100901/LM.xmi    hXp://www.omg.org/spec/UML/20100901/
PrimiZveTypes.xmi    hXp://www.omg.org/spec/UML/20100901/UML.xmi  
hXp://www.omg.org/spec/UML/20100901/StandardProfileL2.xmi  hXp://
www.omg.org/spec/UML/20100901/StandardProfileL3.xmi    
Agenda  
•  History  
•  UML  today  
•  UML  dilemmas  
•  Future  of  UML  
How  UML  is  defined  
Model   Visualizes   Diagram  
and  edits  

Defined  using  concepts  from   Defined  


UML  MetaModel   informally  

UML  Constructs  
(class,  property,  
associaZon,  etc)   Defined  using  concepts  from  

MOF  Model  

Defined  using  concepts  from  


XMI:  how  UML  is  interchanged  
<?xml  version="1.0"  encoding="UTF-­‐8"  ?>    
Model   <uml:Model  xmi:version="2.1"  xmlns:xmi=…  
…  
…  
</uml:Model>  
 

hXp://www.omg.org/spec/UML/20090901/Superstructure.cmof    
UML  MetaModel   <?xml  version="1.0"  encoding="UTF-­‐8"  ?>    
<cmof:Package  xmi:version="2.1"  xmlns:xmi=…  
UML.xsd  
…  
…    
</cmof:Package>  
 

<?xml  version="1.0"  encoding="UTF-­‐8"  ?>    


MOF  Model   <cmof:Package  xmi:version="2.1"  xmlns:xmi=…  
…  
…  
</cmof:Package>  
 
The  Model  Interchange  Working  
Group  
•  hXp://www.omgwiki.org/model-­‐interchange/
doku.php    
•  Primarily  moZvated  by  government  and  
defence  agencies  
•  CreaZng  UML  and  SysML  interoperability  test  
cases  
UML  is  now  at  the  centre  of  a  Family  
of  Languages  
C#  
UML  
MOF   java  

But  is  it  really   a  


Executable  
language   UML  
SysML   SoaML   plaSorm?  
TesZng   Real-­‐Zme  &  
Embedded  

UPDM  
BPMN  
Agenda  
•  History  
•  UML  today  
•  UML  dilemmas  
•  Future  of  UML  
Dilemma  1:  UML  Value  ProposiZons  
•  Sketching?  
•  DocumentaZon?  
•  Executable  UML?  
•  MDA  (Model  Driven  Architecture)?  
•  Round  Trip  Engineering?  
•  Code  VisualizaZon  and  Architecture  VerificaZon?  
•  A  Modelling  Language  Plaworm?  
•  Test  generaZon?  
•  All  of  the  above?  
Dilemma  2:  UML  and  Domain  Specific  
Languages  
•  DSLs  address  domains  that  UML  does  not.  
–  UI  design  
–  VerZcal  domains:  mobile  phones;  soBware  radio;  
insurance  claim  processing;  gesture  processing;  ...  
–  Plaworm-­‐specific  domains:  “code  in  diagrams”  
–  LiXle  DSLs  as  “lifecycle  glue”:  e.g.  config  files  
•  Should  DSLs  be  constructed  from  scratch,  or  by  
extending  UML,  or  by  extending  a  subset  of  UML?  
–  UML  does  not  provide  effecZvely  reusable  subsets  
–  UML  (surprisingly)  does  not  have  well-­‐defined  notaZon  
•  How  to  integrate  UML  with  DSLs?  
–  E.g.  use  BPMN  for  process  modelling  and  UML  for  data  
modelling  
Dilemma  3:  UML  and  Non-­‐SoBware  
•  Is  UML  supposed  to  be  used  to  model  domains  that  are  
not  soBware?  
•  AcZvity  diagrams  can  be  used  for  business  processes  
–  But  what  is  the  relaZonship  between  them  and  BPMN?  
•  Use  case  diagrams  are  used  to  model  requirements.  
•  Many  aspects  of  UML  are  an  imperfect  match  to  
concepts  in  modern  OO  programming  languages.  
–  Should  we  endeavour  to  make  this  match  beXer  or  worse?  
•  Many  concepts  in  UML  have  no  meaning  outside  the  
domain  of  soBware  
–  E.g.  visibility  {public,  private,  protected}  
Dilemma  4:  UML  SemanZcs  
•  Is  UML:  
–  A  reusable  syntax  that  can  map  into  different  programming  
languages  
•  [Wikipedia]:  “Perhaps  the  most  common  form  of  round-­‐trip  
engineering  is  synchronizaZon  between  UML  (
Unified  Modeling  Language)  models  and  the  corresponding  source  
code.”  
–  An  executable  notaZon  with  its  own  execuZon  semanZcs  
•  [Wikipedia]:  Executable  UML  supports  MDA  through  specificaZon  of  
plaworm-­‐independent  models,  and  the  compilaZon  of  the  
plaworm-­‐independent  models  into  plaworm-­‐specific  models.  
–  Both?  
•  “SemanZc  VariaZon  Points”  
–  Single  vs  MulZple  Inheritance  
–  Rules  for  type  conformance  
–  Many  others  
Agenda  
•  History  
•  UML  today  
•  UML  dilemmas  
•  Future  of  UML  
UML  2  –  too  Large  and  Complex  
“Typically  a  project  that  uses  UML  only  uses  20%  of  the  
specifica#on  to  help  build  80%  of  the  code  and  other  
deliverables.”  
Ivar  Jacobson  
UML  roadmap  
•  Complete  Diagram  DefiniQon  capability.  
•  UML  SpecificaQon  SimplificaQon  RFP.    Asks  to  keep  
the  UML  definiZon  the  same,  but  reorganize  the  
specificaZon  so  that  it  is  consumable  and  manageable  
–  Remove  redundancy  (“package  merge”),  consolidate,  and  
define  notaZon  
–  Eliminate  Infrastructure/Superstructure  split  
–  Generate  specificaZon  from  metamodel  
–  In  progress  now;  planned  compleZon  2012  
•  Improve  OMG  “modelling  architecture”  
–  Improve  profile  mechanism  and  integrate  with  MOF/SMOF  
–  Enable  UML  to  be  refactored,  unbundled,  and  reused  
Unbundling  UML  

Smaller,  standard  languages  


Loosely-­‐coupled  
Extensible  
Backwards  compaZble  
The  evolving  modelling  language  
landscape  

BPMN  

UML  
Integrate  &  Correlate  

DSLs  
SysML  
The  End  
Thank  you  

You might also like