|







 








 2


ë   |




ë   |
 

ë   |




ë   |



  |



 2 


aDesign Smell
aThe Odours of Rotting Software

aWhy software Rots

aUML based Object Oriented Design

aActivity Diagram

aState machine diagram

aUse Cases

aSequence Diagram

aClass Diagram

aComponent Diagram

aDeployment Diagram
 3



º Design of system ± its importance

º Getting it right the first time

º Enhancements or Night mares??

º Can redesigns succeed?

 2
 3



We know that a particular software is rotten if the following

behaviour is exhibited.

ºÔ
 
º
 

  

º  

º
 

ºÔ  

º 
   

Rigidity
Ô
    

 


  Ô
 
   


‰ragility
‰ragility is the tendency of a program to break in many
places when a single change is made.

Discussion on ‰ragility
   

mmobility
A design is immobile when it contains parts that could be
useful in other systems, but the effort and risk involved with
separating those parts from the original system are too great.

Discussion on mmobility
     

—iscosity
—iscosity comes in two forms: viscosity of the software and
viscosity of the environment. When faced with a change,
developers usually find more than one way to make that
change. Some of the ways preserve the design; others do not
(i.e., they are hacks). When the design-preserving methods
are more difficult to use than the hacks, the viscosity of the
design is high. t is easy to do the wrong thing but difficult to
do the right thing. We want to design our software such that
the changes that preserve the design are easy to make.

Discussion on —iscosity
   





Needless Complexity
A design smells of needless complexity when it
contains elements that aren't currently useful.

Discussion on Needless Complexity

   






Needless Repetition
Cut and paste may be useful text-editing operations, but
they can be disastrous code-editing operations. All too often,
software systems are built on dozens or hundreds of repeated
code elements.

Discussion on Needless Repetition

   


Opacity
      
  
    

     
 

 !

º Designs and Changing Requirements

º —iolation of Design Philosophy

º Non-Agile and Agile environments

º An example discussion of how Software Rots.



 
 



This session is to refresh UML based Object

Oriented Design concepts and not a primer.

"
 




#

X 






!
" "

 #

"



  

 



#  "
 
$
"
%
X &"
   
 


   
"

# 
 


"  ""
   
 #'

%
(




"


  


  


 "
# "' %
 
 2
3



X 

 "

X  

 "

X   
 "

 `

$ 3



X |  
 "  




 


"



 

%
X 






 "




 "

#
 

 

 "
%
 |$3


X 


) 



 





  # " 

" (
#



"
X "#

|


 "

 )
 $
 #

 )#
 "
*+
,%

 (  
-
ë |" ( 

ë |" (




ë |

 


ë  



ë |



 


ë  # 

 |$3

 %




G


 



3



X 

 "

 "
"

  
 "



  "


 






  

#
 # 


  

 
 
 
  
   



%
X . 

 "

 " -
ë è(  " (



 


""  %
ë )
"

"
%
 






%



G

 
 


3



X |


 "

/
 "  

#
 



"  




#



"%0



 "
 
 -
ë 
 
#   
 
$
"


" 
!

 
"


"



"
ë .""
  
   " 

ë 



 $
"


 "

"

"
 


3

 %



G

 
 

3



X |

 

 "
#

" 

! 
 

%
X 



""


 

 
#
$
"
 
 "
%
 
&

3



X 

$
 "
 


 
ë 
 
  

 


%
ë è( 


ë    '
#

 )
 


%
ë 1
#





 

 
  " (
 
&

3

 %



G


  
3



X |  
 "  


 
"




  




"%
X 





" 


 
"   "  
' 
 "
%
 
3



X 



 "

# 





" 

 )




 

 
 
 



%.


 "
 


     -
ë è( "


 "
"
"
ë |!$
"

 "
 2


"
ë 
   


 )
 
 )

 #
 
3

 %



G


 
3


X ."  )
  " *., )

   "  )
)



 
!     

 

"#
 

" 
%
X 

 
 
  *
,


"  
 "  
#
  


" 
 #" 


  




  

 "*(" 

" " 



, 

  

" "  "3








( 




 
%
 
3

 %



G

 
 3

3


X |
 " 
 "




# 
)
"

#
 
 #
" 
   

% " 

 "

# #

" 
 #
 



  # "
#

  

 "

  %&
  " " -
ë è(  



  #



 

"

  
%
ë è(   

  

"
#

 

"
   
 


" %
ë 
 " " 






 

%
ë 

 #
 #


"

"%
ë 
  #2 #'

 
 
!
%
 3

3

 %



G

 
 



"



á
 
aUML diagrams are more useful in communicating the software design to the

rest of the team.

aUML is a cheaper way to test the software design (idea!)

aCan be used for simple and cleaner code

aCan be useful for creating road maps for larger software structures

Limitations
aUML can be misused and can become counterproductive

aBuilding comprehensive UML design may not be cost-effective

aUML is not good at communicating the algorithmic detail

aUML diagrams need not be drawn at one go ± need iterative improvement

 

 

The following are the best practices in using

UML as part of Agile Design
aterative refinement
aBehaviour first

aEnvisioning the code

aEvolution of the diagrams

a Exercise on UML
 è(



Option : Please take an existing problem from your current project

Option : Consider a library and design a system for borrowing of the
books by students from the library
è +
4
"
|
  |




2'|()