Automatic Inclusion of Middleware Performance Attributes into Architectural UML Software Models

1
Automatic Inclusion of Middleware Performance
Attributes into Architectural UML Software Models

• by Tom Verdickt, Bart Dhoedt, and Piet Demeester
• Senior Member,IEEE

Presented byAYSEGÜL TÜYSÜZ CmpE 550 Advanced
Topics in Software Engineering
2
Outline

• Introduction
• UML for Schedulability, Performance and Time
• Model Driven Architecture (MDA)
• CORBA
• Input to the Transformation
• The Model Transformation
• Conclusion

3
Motivation of the article

• Development of a framework for the automatic
  modeling of the impact of the middleware on the
  architecture and the performance of distributed
  systems
• Software Modeling Language ? UML
• System Design ? MDA
• Middleware ? CORBA

4
UML a cocktail of well-known ingredients
State Diagrams
Use cases
Activity Diagrams
Class Diagrams
Deployment Diagrams
Collaboration Diagrams
etc.
5
MDAs Y cycle
PIMs (Platform Independent Models)
PDMs (Platform Description Models)
Merging/binding phase (TRANSFORMATION ALGORITHM)
PSMs (Platform Specific Models)
Model Driven Architecture (MDA)
6
The middleware war is over

• There is no clear winner nor loser
• The next battlefield will be model transformation
• The MDA initiative is aimed at using modelling to
  drive the design and implementation of
  distributed systems.

HTTP HTML
COM DCOM
Additional CORBA services - Naming Service
(NS) - Security Service - Event Service
Sun's Java EJB
CORBA IIOP
Microsoft C DotNet
XML SOAP
Sun's reaction to C DotNet?
7
Approach MDAs cycle
High-level PIM
Lower-level PSM
8
Input to the Transformation

• UML Deployment Diagram

• UML Collaboration Diagram

9
Input to the Transformation

• UML Activity Diagram

10
Input to the Transformation

• Middleware usage description
• The specifics of the middleware (its type, some
  performance information, etc.) are given in a
  seperate XML input file to the transformation

Describes middleware instances
Type of middleware
Initialization time
Time needed to clean up and destroy
describes groups of calls between a client and a
server
specifies server and client side overhead of
using the middleware
All communication between the components should
use the middleware
ltmiddlewaregt ltmw_instance idorb1
typeCORBA inittime36.549
destroytime3.3646 /gt ltlink idlink1
mwreforb1gt ltcall crefG.11
stubtime1.8413 skeletontime0.1021 /gt
lt/linkgtlt/middlewaregt
ltmiddlewaregt ltmw_instance idorb1
typeCORBA inittime36.549
destroytime3.3646 /gt ltlink idlink1
mwreforb1gt ltendpoints clientS1
serverS2 stubtime1.8413
skeletontime0.1021 /gt
lt/linkgtlt/middlewaregt
11
The Model Transformation

• Locating the involved components
• The deployment diagram
• The collaboration diagram
• The activity diagram Performance attributes
• Additional middleware (CORBA) services

12
Locating the involved components

• function find involved components
• for each ltlinkgt element in Middleware Usage
  Description XML
• if ltlinkgt has ltendpointsgt child
• find partitions by looking client
  and server attributes of
  ltendpointsgt
• else
• take first ltcallgt element
• find transition referenced by
  cref
• get names of source and target
  partitions
• //end else
• //end for
• // end function

13
Transformation of the Deployment Diagram

• function transform deployment diagram
• for each ltlinkgt element
• find nodes that contain source and
  target
• add corba_client and stub to source
  node
• find orb referenced in mwref
  attribute
• if orb not yet added to source node
• add orb to source node
• //end if
• add skeleton to target node
• //end for
• // end function

14
Transformation of the Collaboration Diagram

• function transform collaboration diagram
• for each ltlinkgt element
• find source and target roles
• find collaboration between source and
  target roles
• create roles corba_client, stub and
  skeleton
• find orb referenced in mwref
  attribute
• if orb not yet added create role orb
  //end if
• create clientserver collaboration
  between corba-client and orb,
• 
  corba-client and
  client,
• 
  client and stub,
• 
  stub and skeleton,
• 
  skeleton and
  server
• //end for
• delete collaborations between orijinal source
  and target roles
• // end function

15
Transformation of the Activity Diagram
(synchronous)
Middleware Usage Descriptionltmiddlewaregt
ltmw_instance typeCORBA inittime36.549
destroytime3.3646 /gt ltlink idlink1
mwreforb1gt ltcall crefG.11
stubtime1.8413 skeletontime0.1021 /gt
ltuse_service sref NS1gt lt/linkgt
ltservice idNS1 typeNS hostspcgt
ltoverheadgt ltinitialization client0.3
host0.1 /gt ltinvocation client0.46
host0.53 /gt lt/overheadgt
ltservice/gtlt/middlewaregt
16
Transformation Limitations

• Naming convention Model elements that occur in
  different diagrams need to have the same name
  which should be unique in the model
• No handling of interactions
• (e.g forwarding servers)

17
Conclusion

• MDA Transformation includes
• structural impact of the middleware
• overhead generated by the middleware
• The resulting UML model contains information for
• modeling and analyzing the performance of the
  system
• how the performance is affected by the middleware
• Combination of MDA and SPE allows
• obtaining performance estimates as early as
  possible
• redesigning the system without excessive costs

18
Questions ???