Architecture and Structure

1
Architecture and Structure
2
About Software Architecture and Process

• Software Architecture design, and the design of
  software development processes, team organisation
  etc., are always context-specific
• Steps used for designing and supporting the
  implementation of a payroll system are radically
  different from those needed for a Switch Manager
  in a high volume throughput, real time, telephone
  network system

3
Complexity and Hierarchy

• In this chapter we review broad issues
• but note, Frequently complexity takes the form
  of a hierarchy. Courtois 1986 and
  Hierarchic systems are usually composed of only
  a few kinds of subsystems in various combinations
  and arrangements Simon 1982

4
What is Software Architecture?

• No standard definition
• According to UML Semantics
• The organisational structure of a system. An
  architecture can be recursively decomposed into
  parts that interact through interfaces,
  relationships that connect parts, and constraints
  for assembling parts (p.148)
• and to Bass et al (Software Architectures in
  Practice)
• The software architecture of a program or
  computing system is the structure or structures
  of a system, which comprise software components,
  the externally visible properties of these
  components, and the relationships among them

5
The System Composite pattern
System Element
(Sub-) System
System Connector
System Component
6
Implications of System Composite

• Description is recursive
• All systems can be described as recursive
  combinations of components
• including a legacy system
• A component is any software element (other than a
  connector) in a composition
• Therefore, all software systems have software
  architectures

7
Layering and Partitioning

• Layering is used when systems are inherently
  hierarchical
• Each layer is a client for services provided by
  the layer immediately below it
• Example network protocols, e.g., the OSI seven
  layer protocol
• Vertical partitioning is most often based on
  business processes
• e.g., Sales, Marketing, Accounting function each
  modelled separately

8
Example 4-Tier Client/Server Software
Architecture
App.1 Objects
App.2 Objects
App.3 Objects
Local Business Objects
Workflow Engine
9
Solve These Puzzles
5
3
8
9
?
11
4
10
1
5
8
6
12
3
?
10
25
1
2
6
10
Problems with Software Architecture (layering,
partitioning) diagrams

• What does the relative positioning of the boxes
  mean?
• Lack of semantic information
• What are the interfaces between the different
  components?
• Provide no guidelines for parallel development

11
UML Package Construct

• UML provides a construct called a package which
  reflects collections
• icon represents a document folder
• The package construct is versatile
• it needs to be stereotyped
• typical packages are
• ltltsubsystemgtgt a collection of files
• ltltcategorygtgt a collection of classes

12
UML Package Construct (continued)
Indicates dependency
13
Layering and Partitioning in Design

• Determine the high-level structure early in
  analysis
• partition/layer according to domains of
  interest
• identify which classes and which associations
  belong to which category
• In early analysis, model known dependencies
  between the categories
• make final allocations of classes later, based on
  high coupling between related classes (e.g.,
  inheritance hierarchies, aggregates, collections,
  one-to-one associations etc.)

14
Layering and Partitioning in Design (continued)

• A possible architecture for a simple graphics
  system

Persistent Store
Graphics Engine
15
Layering and Partitioning in Design (continued)

• Seek to minimise the likely messaging interface
  between the categories
• lower the coupling between categories
• Often common topologies will become apparent
• e.g., star, pipeline etc.
• Buschmann et al., describe seven typical
  architectural styles as architectural patterns

16
Frameworks and Architecture

• A Software Framework is an abstract software
  architecture that can be refined to any one of a
  number of concrete systems in a domain.To refine
  the framework the user inherits this structure
  and adds application-specific code.
• We can use patterns to describe architecture
  Buschmann et al 1996
• Patterns were discovered in frameworks
• How can we use patterns to design architectures
  and frameworks?

17
Wolfgang Prees metapatterns

• Pree describes the points at which a framework
  can be refined (inherited from) as hot spots
  and the methods which can be overriden as hook
  methods (as opposed to the template methods
  which are left alone)
• Analysing the Gamma patterns according to how
  they utilise hook and template methods he
  categorised them into
• Unification patterns (template and hook methods
  in the same class)
• Separation patterns (template and hook methods in
  different classes)
• Recursive combination patterns

18
Unification v Separation patterns

• Unification patterns
• e.g., Template Method
• adaptation possible only by inheritance
• therefore application must be restarted
• Separation patterns
• Abstract Factory, Builder, Command, Interpreter,
  Observer, Prototype, State, Strategy
• separation of classes permits run-time
  adaptations
• Recursive Combination patterns
• e.g., Composite, Chain of Responsibility

TH
H
T
19
Hot-Spot Driven Development

• Utilise hot-spot cards
• variations on CRC cards
• identify hot spots of variability, and their
  nature
• In Analysis
• if flexibility requires run-time, on the fly or
  end-user adaptation use Separation patterns
• if OK to restart application use Unification
• Recursive Combination has no equivalent
  heuristics - left to deep design

20
Using Patterns for Legacy System migration

• DMUs ADAPTOR pattern language combines patterns
  to migrate systems
• Architecture-Driven And Patterns-based
  Techniques for Object Re-engineering
• Patterns used include
• System Composite
• Scenarios Define Problem
• Façade
• Code Ownership
• Semantic Wrapper etc.

21
Organisation and Process
22
Relationship Between Architecture and Organisation

• Conways Law Organisation follows architecture
  or architecture follows organisation!
• E.g., maintenance teams for a layered system are
  often organised per layer
• Conways Law is one of Jim Copliens
  organisational patterns

23
Example of Two Organisational Patterns
24
Relationship Between Architecture and Organisation

• Consider the traditional Waterfall Life Cycle
  development process
• Job descriptions (business analyst, systems
  analyst, designer, programmer etc.) follows the
  life cycle
• The life cycle reflects a software architecture
  based on the separation of process and data
• In Object Orientation
• there are many more topologies available
• new organisational structures and development
  processes needed too??

25
Investigating Organisational Structures

• Copliens technique uses CRC cards
• Development team brainstorms a list of roles in
  the development process
• A 6x4 index card is prepared for each role.
  Each other role with which it collaborates is
  listed, and the collaborations strength graded
  as weak, medium, or strong
• The process is then role-played to validate the
  teams perceptions of roles interactions

26
Investigating Organisational Structure

• The validated information is fed into a Smalltalk
  system at ATT called Pasteur which contains
  similar information from more than 50 projects
• Pasteur generates pictures and metrics
• the pictures are sociometric adjacency diagrams
  and interaction grids
• the metrics show how much communication there is
  over the whole organisation

27
Using OrgPatterns to Design Teams

• Comparison with other projects show that a number
  of patterns are present in highly productive
  software development teams (e.g. Borlands
  Quattro Pro team)
• Architect also implements
• Code ownership
• Developer controls process

28
Process Specification for OO
performed by


Role

Process


performed by
delivered by


Task
performed by
A Process is composed of tasks, which are
composed of techniques, all of which are
performed by roles in a project. A process
delivers work products.

Work products


Technique
29
Software Processes

• Software Processes, as well as organisational
  structures, depend on architecture
• OO permits iterative, incremental software
  development process models
• Utilise JAD/RAD workshops and time-boxing
• OPEN process specification and DSDM are two
  iterative, incremental approaches

30
Workshops

• JAD/RAD (Joint or Rapid Application Development
  workshops)
• Involve commissioning users and end users in
  analysis and design
• CRC cards
• Use cases or task scripts
• GUI prototyping
• And in validation and verification of all phases

31
Time-boxing

• Project is sliced depth-first, and typically
  delivered in 3 -4 increments
• MoSCoW rules applied
• Must have Should have Can have Wish to have
• Early and rapid delivery - even if with cut down
  functionality
• User validated all decisions are reversible

32
Conclusion

• The key to the successful deployment of Object
  Technology...
• for greenfield development
• legacy system migration
• software reuse
• is planned investment in Software Architecture
  Software Development Organisation design
  Software development process
• but remember Architecture shapes everything else!