The

 Role  of  the  Architect  

requirements solutions
client,
architect developers
users

assess creates assess

visualises prescribes

appearance, architectural construction,

behaviour design co-operation

1
The  Architecture?  Is  art?  science?  
 
 
 Architecting  a  house  

Built most efficiently and timely by a team

Requires
Modeling
Well-defined process
Power tools

Kruchten!
 Architecting  a  high  rise  

Kruchten!
Mac  OS  X  Component  
Architecture  

AQUA

CLASSIC CARBON COCOA JAVA

QUARTZ OPENGL QUICKTIME

DARWIN
Mac  OS  X  Component  
Architecture  

AQUA
IMAGING LAYER

CLASSIC CARBON COCOA JAVA

QUARTZ OPENGL QUICKTIME

BSD SUBSYSTEM

MACH KERNEL
Mac  OS  X  Component  
Architecture  
API LAYER

AQUA

CLASSIC CARBON COCOA JAVA

QUARTZ OPENGL QUICKTIME

BSD SUBSYSTEM

MACH KERNEL
Mac  OS  X  Component  
Architecture   USER INTERFACE LAYER

AQUA

CLASSIC CARBON COCOA JAVA

QUARTZ OPENGL QUICKTIME

BSD SUBSYSTEM

MACH KERNEL
 Today  

• Why  So'ware  Architecture?  

• What’s  So'ware  Architecture?  
Software  Architecture  is?  
So'ware  architecture  is  about  structural  proper,es:  
ØComponents  
ØInterrela<onships  
ØPrinciples  
ØGuidelines  
It  is  one  of  the  earliest  stages  in  so'ware  system  design  
Structural  Issues?  
ØGross  organisa<on  and  global  control  structure  
ØProtocols  for  communica<on,  synchronisa<on  and  data  access  
ØAssignment  of  func<onality  to  design  elements  
ØPhysical  distribu<on  
ØComposi<on  of  design  elements  
ØScaling  and  performance  
Why  Is  Architecture  Important?  

SE, Software Architecture, Hans van Vliet, ©2008

• Architecture  is  the  vehicle  for  stakeholder  
communica<on  
• Architecture  manifests  the  earliest  set  of  design  
decisions  
• Constraints  on  implementa<on  

12
• Dictates  organiza<onal  structure  
• Inhibits  or  enable  quality  aHributes  
• Architecture  is  a  transferable  abstrac<on  of  a  system  
• Product  lines  share  a  common  architecture  
• Allows  for  template-­‐based  development  
• Basis  for  training  
Three  Basic  Reasons:  
ØMutual  communica<on  
l A  common  high-­‐level  abstrac<on  that  can  be  used  by  all  the  
system’s  stakeholders  
ØEarly  design  decisions  
l Ones  that  will  be  important  throughout  the  lifecycle  
(development,  service  and  maintenance)  
ØTransferable  abstrac<on  of  the  system  
l Rela<vely  small,  intellectually  graspable  model  of  the  system  
Transferable  Model  
ØReuse  at  the  architectural  level  for  systems  with  
similar  requirements  
lEn<re  product  lines  can  share  a  common  architecture  
ØFacilitates  use  of  externally-­‐developed  
components  
lArchitecture  constrains  how  components  interact  with  
their  environment  
lHow  they  receive  and  relinquish  control  
lThe  data  they  work  with  and  produce  
lThe  protocols  they  use  for  communica<on  and  
resource  sharing  
Architecture  deCined  
Formal  DeCinition  
• IEEE  1471-­‐2000  
•  So'ware  architecture  is  the  fundamental  organiza7on  of  a  
system,  embodied  in  its  components,  their  rela7onships  to  
each  other  and  the  environment,  and  the  principles  
governing  its  design  and  evolu<on
Component  SpeciCications  
n Component  specifica<ons  supply  the  details  needed  to  provide  
a  complete  system  descrip<on  at  this  par<cular  level  of  
abstrac<on  
n interface  syntax  
n interface  seman<cs  
n The    structural  and  behavioral  proper<es  captured  by  the  
component  specifica<ons  must  be  consistent  with  the  design  
diagram  
 
Component  
n Sample  component  types   Heater  
procedure        Methods  
Heat
n Controller

n object   turn  on,  turn  off  

n process  (threaded  object)   failed,  hea<ng  
n Interface  depends  on        State   Heater

component  type  and   ac<ve  (T/F)  

language—but  it  is  real   failed  (T/F)  
n Behavior  reflects  the   turn off

component  type  but  must   failed

be  abstract  
inactive turn on active
 Architecture  deCined  
Another  Go  
• So'ware  architecture  encompasses  the  set  of  
significant  decisions  about  the  organiza<on  of  a  
so'ware  system  
• Selec<on  of  the  structural  elements  and  their  interfaces  
by  which  a  system  is  composed  
• Behavior  as  specified  in  collabora<ons  among  those  
elements  
• Composi<on  of  these  structural  and  behavioral  
elements  into  larger  subsystems  
• Architectural  style  that  guides  this  organiza<on  

Booch, Kruchten, Reitman, Bittner, and Shaw!

 Architecture  deCined  
 
•  Perry  and  Wolf,  1992  
•  A  set  of  architectural  (or  design)  elements  that  have  a  par<cular  form  

•  Boehm  et  al.,  1995  

•  A  so'ware  system  architecture  comprises    
• A  collec<on  of  so'ware  and  system  components,  connec<ons,  and  constraints      
• A  collec<on  of  system  stakeholders'  need  statements  
• A  ra<onale  which  demonstrates  that  the  components,  connec<ons,  and  constraints  define  a  
system  that,  if  implemented,  would  sa<sfy  the  collec<on  of  system  stakeholders'  need  
statements  

•  Clements  et  al.,  1997    

•The  so'ware  architecture  of  a  program  or  compu<ng  system  is  the  structure  or  
structures  of  the  system,  which  comprise  so'ware  components,  the  externally  visible  
proper<es  of  those  components,  and  the  rela<onships  among  them

http://www.sei.edu/architecture/definitions.html"
Common  elements  1/2  
• Architecture  defines  major  components  
• Architecture  defines  component  rela<onships  (structures)  and  
interac<ons  
• Architecture  omits  content  informa<on  about  components  that  does  
not  pertain  to  their  interac<ons    
• Behavior  of  components  is  a  part  of  architecture  insofar  as  it  can  be  
discerned  from  the  point  of  view  of  another  component  
Common  elements  2/2  
• Every  system  has  an  architecture  (even  a  system  composed  of  one  
component)  
• Architecture  defines  the  ra<onale  behind  the  components  and  the  
structure  
• Architecture  defini<ons  do  not  define  what  a  component  is  
• Architecture  is  not  a  single  structure  -­‐-­‐  no  single  structure  is  the  
architecture    
Architecture  is  Early  

• Architecture  represents  the  set  of  earliest  design  

decisions  
• Hardest  to  change  
• Most  cri<cal  to  get  right  
• Architecture  is  the  first  design  ar<fact  where  a  
system’s  quality  aHributes  are  addressed  
 
Architecture  Drives  
• Architecture  serves  as  the  blueprint  for  the  system  but  also  the  
project:  
• Team  structure  
• Documenta<on  organiza<on  
• Work  breakdown  structure  
• Scheduling,  planning,  budge<ng  
• Unit  tes<ng,  integra<on  
• Architecture  establishes  the  communica<on  and  coordina<on  
mechanisms  among  components  
Architecture  vs.  Design  
Architecture: where non-functional decisions are cast, and functional
requirements are partitioned
Design: where functional requirements are accomplished

non-functional requirements architecture

(“ilities”)

functional requirements
(domains) design

Important : this is a general guideline – sometimes the borders are blurred

 System  Quality  Attribute  
• Performance  
" Time To Market
• Availability   " Cost and Benefits
• Usability   " Projected life time
" Business
End User’s view Targeted Market
• Security   " Community
Integration with Legacy view
System
" Roll back Schedule

" Maintainability
" Portability
" Reusability
" Testability Developer’s view

A list of quality attributes exists in

ISO/IEC 9126-2001 Information Technology – Software Product Quality
 What  Constitutes  “Functional”?  
n Type  as  input,  value  as  output  
n E.g.,  towards  constructors  and  ini<aliza<on  methods  

n Type  as  input  and  output  

n E.g.,  towards  allowed  polymorphism  and  type  conversions  

n Value  as  input  and  output  

n E.g.,  towards  func<ons  and  operators  

n Value  as  input,  type  as  output  

n E.g.,  towards  classifiers  and  type  iden<fiers  

n …  combina<ons  of  these  kinds  of  domains/ranges  

Non-­‐Functional  Requirements  
n Non-­‐func<onal  requirements  place  restric<ons  on  the  
range  of  acceptable  solu<ons  
n Non-­‐func<onal  requirements  cover  a  broad  range  of  
issues  
n interface  constraints  
n performance  constraints  
n opera<ng  constraints  
n life-­‐cycle  constraints  
n economic  constraints  
n poli<cal  constraints  
n manufacturing  
 
Software  Architecture  as  
Artifact  
n The  architecture  of  a  system  is  an  abstract  descrip<on  of  its  
structure  and  behavior  
n The  level  of  abstrac<on  is  chosen  such  that  all  cri<cal  design  
decisions  are  apparent  and  meaningful  analysis  is  feasible  
n A  complete  so'ware  architecture  is  usually  specified  by  a  
combina<on  of  
n design  diagrams  
n component  specifica<ons  
Types  of  Architectures  
• Business  Architectures  
• Technical  Architectures  
• Solu<ons  Architectures  
• Enterprise  Architectures  
• Product  Line  Architectures  
Business  Architecture  
• Concerned  with  the  business  model  as  it  relates  to  an  automated  
solu<on.    
• E-­‐business  is  a  good  candidate  
• Structural  part  of  requirements  analysis.  
• Domain  Specific    
Technical  Architecture  
• Specific  to  technology  and  the  use  of  this  technology  to  structure  the  
technical  points  (Technology  Mapping)  of  an  architecture  
• .NET  
• J2EE  
•  Hardware  architects  
Solutions  Architecture  
• Specific  to  a  par<cular  business  area  (or  project)  but  s<ll  reliant  on  
being  a  technical  focal  point  for  communica<ons  between  the  
domain  architect,  business  interests  and  development.    
Enterprise  Architecture  
• The  organizing  logic  for  a  firm’s  core  business  processes  and  IT  
capabili<es  captured  in  a  set  of  principles,  policies  and  technical  
choices  to  achieve  the  business  standardiza<on  and  integra<on  
requirements  of  the  firm’s  opera<ng  model.    
• Concerned  with  cross  project/solu<on  architecture  and  
communica<on  between  different  prac<ces  in  architecture.    
 
Product  Line  Architecture  
• Common  Architecture  for  a  set  of  products  or  systems  developed  by  
an  organiza<on

 
Product  Line  -­‐  Initiation  
• Evolu<onary  
• Product  line  architecture  and  components  evolve  with  the  requirements  
posed  by  new  product  line  members.  
• Revolu<onary  
• Product  line  architecture  and  components  developed  to  match  requirements  
of  all  expected  product-­‐line  members