The%20Role%20of%20Architecture

1

• The Role of Architecture
• in Understanding Software

Rick KazmanHausi MüllerJeromy Carrière
2

• Software Architecture
• What is it and How to Represent It

Rick Kazman kazman_at_sei.cmu.edu www.sei.cmu.edu/sta
ff/rkazman
3
A Software Architecture (?)
4
What is Wrong with this Diagram?

• Many things are left unspecified
• What kind of components?
• What kind of connectors?
• What do the boxes and arrows mean?
• What is the significance of the layout?
• Why is control process on a higher level?
• ? Box and arrow drawings alone are not
  architectures rather, they are a starting point.

5
Whats Wrong with the Diagram?

• Which structure? Software is composed of many
  structures.
• modules
• tasks
• functions
• hardware
• classes
• Thus, when seeing boxes and lines, we must ask
• What do the boxes represent?
• What do the arrows mean?

6
What is Software Architecture?

• The software architecture of a program or
  computing system is the structure or structures
  of the system, which comprise software
  components, the externally visible properties of
  those components, and the relationships among
  them.

7
Implications of this Definition

• Architecture is an abstraction of systems.
• Architecture defines components and how they
  interact.
• Architecture suppresses purely local information
  private component details are not architectural.
• Systems have many structures (views).
• No single view can be the architecture.
• The set of candidate views is not fixed or
  prescribed whatever is useful for analysis or
  communication.

8
More Implications

• Every system has an architecture.
• Every system is composed of components and
  relationships among them.
• In the simplest case, a system is composed of a
  single component, related only to itself.
• Having an architecture is different from having
  an architecture that is known. Issues
• precise specification of the architecture
• architecture recovery and conformance
• rationale for the architecture

9
Why Is Architecture Important?

• Architecture is important for (at least) three
  reasons.
• It provides a vehicle for communication among
  stakeholders.
• It is the manifestation of the earliest
  designdecisions about a system.
• It is a transferable, reusable abstraction of
  asystem.

10
Communication Vehicle

• Architecture provides a common frame of reference
  in which competing interests may be exposed and
  negotiated.
• negotiating requirements with users
• keeping the customer informed of progress and
  cost
• implementing management decisions and allocations

11
Result of Early Design Decisions -1

• An architecture constrains an implementation.
• implementations must conform to architecture
• (global) resource allocation decisions constrain
  implementations of individual components
• system tradeoffs are manifested in the
  architecture

12
Result of Early Design Decisions -2

• The architecture dictates organizational
  structure for development/maintenance efforts,
  e.g.
• division into teams
• units for budgeting, planning
• basis of work breakdown structure
• organization for documentation
• organization for CM libraries
• basis of integration, test plans, testing
• basis of maintenance
• ? Once committed to, an architecture is extremely
  hard to change!

13
Result of Early Design Decisions-3.

• Architecture permits/precludes the achievement of
  a systems desired quality attributes
  (modifiability, performance, security, etc.).
• The architecture influences qualities, but does
  not guarantee them.
• An architecture helps with evolutionary
  prototyping.
• Architecture serves as a skeletal framework into
  which components can be plugged.
• By segregating functionality into appropriate
  components, experimentation is easier.

14
Reusable Model

• An architecture forms a reusable model. It
• provides a vocabulary of design
• enables template-based component development
• enables product lines
• enables systems to be built from externally
  developed components
• separates functionality from packaging and
  interconnection mechanisms

15
Architectural Structures - 1

• In a house, there are plans for rooms, electrical
  wiring, plumbing, ventilation, . . .
• Each of these constitutes a view of the house.
  These views are
• used by different people
• used to achieve different qualities in the house
• used as a description and prescription
• So it is with software architecture.

16
Architectural Structures - 2.
? Similar to Kruchtens 41 View Model
17
Functional View

• Components
• functions, key system abstractions, domain
  elements
• Connectors
• dependencies, data flow
• Users
• domain engineers, product-line designers, end
  users
• Reasoning
• functionality, modifiability, product
  lines/reusability, tool support, work allocation

18
Functional View Example
19
Code View

• Components
• classes, objects, procedures, functions
• subsystems, layers, modules
• Connectors
• calls, invokes
• is-a-sub-module-of
• Users
• programmers, designers, reusers
• Reasoning
• modifiability/maintainability, portability,
  subsetability

20
Code View Example
WindowKit
CreateScrollBar()
CreateWindow()
OpenLookWindowKit
return
CreateScrollBar()
new OpenLookWindow
CreateWindow()
return
new MotifWindow
21
Development View

• Components
• files, directories
• Connectors
• contains
• Users
• managers, programmers, configuration managers
• Reasoning
• modifiability/maintainability
• testing
• configuration management/version control

22
Development View Example
23
Concurrency View

• Components
• processes, threads
• Connectors
• synchronization, data flow, events
• Users
• performance engineers, integrators, testers
• Reasoning
• performance, availability

24
Concurrency View Example
25
Physical View

• Components
• CPUs, sensors, storage
• Connectors
• networks, communication devices
• Users
• hardware engineers, system engineers
• Reasoning
• system delivery and installation, performance,
  availability, scalability, security

26
Physical View Example
27
Scenarios

• What are scenarios?
• use cases sequences of responsibilities
• change cases changes to the system
• Why use scenarios?
• to understand and validate the design
• to communicate the design
• to tie the views together
• to animate the design
• to understand the limits of the design

28
What Are Views Used For?

• Each view provides an engineering handle on
  certain quality attributes.
• Views are an engineering tool to help achieve
  desired system qualities.
• In some systems, distinct views collapse into
  one. (E.g., the concurrency and physical views
  may be the same for small systems.)

29
What Are Views Used For?

• Documentation vehicle for
• current development and future development
• managers and customers
• Thus, views must be annotated to support
  analysis.
• Scenarios aid in annotating views with design
  rationale.

30
Hierarchical Views

• Every view is potentially hierarchical, e.g.
• functional functions contain sub-functions
• development directories contain files
• code modules contain sub-modules systems
  contain sub-systems
• concurrency processes contain threads
• physical clusters contain computers contain
  processors
• Because views are complex and hierarchical, they
  need to be navigable.

31
View Navigability - 1

• A skilled software engineer with some domain
  knowledge should be able to read the
  documentation and navigate through it.
• There should be an obvious starting point,
  portraying the system as a collection of
  interconnected subsystems.
• Subsystems should be named, with their
  responsibilities, functionality, and
  interconnections identified.

32
View Navigability - 2.

• Pointers should direct the reader to more
  detailed documentation of sub-structures.
• Tool support can and should aid in navigation.
• At every stage, the nature of the connections
  among the parts should be clearly identified.

33
Architectural Representation Summary

• Architectural views are related to each other in
  complicated ways.
• Lesson Choose the views that are useful to the
  system being built and to the achievement of
  qualities that are important to you.
• The architectural views should be hierarchical
  (where needed) and navigable.
• The views should contain enough annotated
  information to support desired analyses.

34
Part IISoftware ArchitecturePatterns and
AntiPatterns

• Hausi A. Müller

35
Outline

• Architecture Patterns
• Motivation
• Software patterns
• Pattern formats
• Shaws architecture patterns
• Qualities of a pattern
• Architecture AntiPatterns

36
Motivation

• Vehicle for reasoning about design or
  architecture at a higher level of abstraction
• gain design confidence
• Mining design patterns in legacy systems
• identify product lines
• Software architecture
• dissemination of good design, design reuse
• Engineering Handbooks
• contain a wealth of experience

37
Software Patterns

• Programming patterns or idioms Coplien95
• Programming language specific
• Design patterns GoF95
• Class and object level
• Creational, structural, behavioral
• Architectural patterns Shaw95
• Subsystem level
• Pattern languages Coplien95, Vlissides96
• All levels
• Reflective patterns Buschmann95
• Metaprogramming

38
Software Patterns ...

• Analysis patterns Fowler97
• AntiPatterns Brown98
• Frameworks
• STL (C Template Library)
• Algorithms and data structures
• Conceptual patterns
• Generative patterns
• Organizational patterns

39
Pattern Definitions

• A pattern is a named nugget of insight that
  conveys the essence of a proven solution to a
  recurring problem within a certain context amidst
  competing concerns
• A pattern is the abstraction from a concrete form
  which keeps recurring in specific non-arbitrary
  contexts.

40
Pattern Definitions ...

• Description of communicating objects and classes
  that are customized to solve a general design in
  a particular context GoF95.
• Design patterns capture the static and dynamic
  structures of solutions that occur repeatedly
  when producing applications in a particular
  context Coplien95.

41
Historical Perspective

• 1979
• Alexanders Timeless Way of Building
• 1987
• OOPSLA workshop by Beck Ward
• 1994
• First PLoP (Pattern Languages on Programming)
  conference
• 1995
• GoF (Gamma, Helm, Johnson, Vlissides)
• Design Patterns Elements of Reusable
  Object-Oriented Software

42
A Good Pattern

• It solves a problem
• Patterns capture solutions, not just abstract
  principles or strategies
• It is a proven concept
• Patterns capture solutions with a track record,
  not theories or speculation
• The solution isnt obvious
• The best patterns generate a solution indirectly
  normal for many design problems

43
A Good Pattern ...

• It describes a relationship
• Patterns describe more than black boxes system
  structures and mechanisms
• The pattern has a significant human component
• The best patterns explicitly appeal to aesthetics
  and utility

44
Pattern Formats

• Alexandrian form (canonical form)
• GoF format GoF95
• Shaws format Shaw94
• Essential components of a pattern format
• Name, problem, context, forces
• Solution, examples, context,
• Rationale, related patterns, known uses

45
Canonical Pattern Format ...

• Name
• meaningful phrase
• Problem
• a statement of the problem which describes its
  intent the goals and objectives it wants to
  reach within the given context and forces

46
Canonical Pattern Format ...

• Context
• preconditions under which the problem and its
  solutions seem to occur
• the patterns applicability
• may change over time
• Forces
• relevant forces and constraints and their
  interactions and conflicts
• motivational scenario for the pattern

47
Canonical Pattern Format ...

• Solution
• Static and dynamic relationships describing how
  to realize the pattern
• instructions on how to construct the work
  products
• pictures, diagrams, prose which highlight the
  patterns structure, participants, and
  collaborations

48
Canonical Pattern Format ...

• Examples
• one or more sample applications to illustrate
• a specific context
• how the pattern is applied
• Resulting context
• the state or configuration after the pattern has
  been applied
• consequences (good and bad) of applying the
  pattern

49
Canonical Pattern Format ...

• Rationale
• justification of the steps or rules in the
  pattern
• how and why it resolves the forces to achieve the
  desired goals, principles, and philosophies
• how are the forces orchestrated to achieve
  harmony
• how does the pattern actually work

50
Canonical Pattern Format ...

• Related patterns
• the static and dynamic relationships between this
  pattern and other patterns
• Known uses
• to demonstrate that this is a proven solution to
  a recurring problem

51
Shaws Architecture Pattern Format

• Problem
• What in the application requirements leads the
  designers to select this pattern?
• Context
• What aspects of the setting constrain the
  designer in the use of this pattern?
• Solution
• The system model captured by the pattern,
  together with the components, connectors, and
  control structure that make up the pattern.

52
Shaws Format ...

• Diagram
• A figure showing a typical pattern, annotated to
  show the components and connectors
• Significant variants
• For some patterns, major variants of the basic
  pattern are noted.
• Examples
• References to examples or more extensive
  overviews of systems that apply this pattern.

53
Shaws Architecture Patterns

• Pipeline
• Defined series of independent computations
• Mapping data streams into data streams
• Data abstraction
• Protection of related bodies of information
• Localized state maintenance (info hiding)
• Communicating processes
• Collection of distinct, independent processes
• Message passing
• Simple messages, broadcast

54
Shaws Architecture Patterns ...

• Implicit invocation
• Loosely coupled collection of components
• Independent reactive processes
• Without knowing the recipients (registered procs)
• Repository
• Maintaining a complex body of information
• Centralized data, richly structured
• Blackboard
• Interpreter
• Extensibility, end-user programming, portability
• Virtual machine (e.g., Java)

55
Shaws Architecture Patterns ...

• Main program and subroutines
• Hierarchy of procedure definitions
• Forward call tree
• Modularity
• Layered architecture
• Distinct layers of services
• Hierarchy of transparent or opaque layers

56
Qualities of a Pattern

• Encapsulation and abstraction
• encapsulates a well-defined and its solution in a
  particular domain
• provides crisp, clear boundaries to crystallize
  the problem and solution spaces
• serves as an abstraction which embodies domain
  knowledge and experience
• may occur at different levels of abstraction

57
Qualities of a Pattern ...

• Openness and variability
• is open for extension and parameterization by
  other patterns
• is able to solve larger problems in concert with
  other patterns
• can be realized by a variety of implementations
  (variants)

58
Qualities of a Pattern ...

• Generativity and composability
• applying a pattern once provides a context for
  further applications
• patterns are easier to apply in another context
  than C code
• can evolve into Golden Hammer AntiPattern

59
Qualities of a Pattern ...

• Equilibrium
• realizes a balance among its forces and
  constraints
• realizes an invariant, heuristics, or a policy
  which minimize conflict within the solution space
• an invariant characterizes the problem solving
  philosophy

60
Outline

• Patterns
• AntiPatterns
• Motivation
• Pattern and AntiPattern relation
• AntiPattern and program comprehension
• AntiPattern format
• Selected software Architecture AntiPatterns
• Summary

61
Reference

• Brown, Malveau, McCormick III, MowbrayAntiPattern
  s Refactoring Software, Architectures, and
  Projects in CrisisJohn Wiley Sons, 1998

62
Origins of AntiPatterns

• The majority of published works in software
  sciences have focused on positive and
  constructive solutions
• AntiPatterns are derived by looking at the
  negative solutions
• Def. An AntiPattern describes a commonly
  occurring solution to a problem that generates
  decidedly negative consequences.

63
Origins of AntiPatterns

• A manager or developer
• does not know any better
• does not have sufficient knowledge or experience
  solving a particular problem
• applied a perfectly good design pattern in the
  wrong context

64
Essence of an AntiPattern

• Two solutions instead of a problem and a solution
• Problematic solution which generates negative
  consequences
• Refactored solution, a method to resolve and
  reengineer the AntiPattern
• A pattern in an inappropriate context

65
Pattern AntiPattern Relation

• Design patterns often evolve into an AntiPattern
• Procedural programming was a great design pattern
  in the 60s and 70s
• Today it is an AntiPattern
• Object-oriented programming is today a practiced
  pattern ...

66
Pattern AntiPattern Relation
AP99
Context change over time
67
AntiPatterns Comprehension

• AntiPatterns are particularly prevalent during
  long-term software maintenance and evolution
• A software reengineer needs to assess the
  presence or absence of AntiPatterns in a legacy
  system to be able to implement the best
  reengineering strategy

68
AntiPatterns and Reengineering ...

• Premise
• Recognition of AntiPatterns will make you a
  better software engineer
• Refactoring AntiPatterns present in a legacy
  systems project will result in a better, more
  successful, less risky software reengineering
  project

69
State of Affairs

• Five out of six software projects are considered
  unsuccessful
• One third of all software projects are canceled
• For delivered systems the actual budget and time
  is double than expected
• Silver bullets ...

70
Old Silver Bullets

• Structured programming
• Top-down design
• Open systems
• Client/server architectures
• Quality code generation from models
• Object orientation
• GUI builders
• Frameworks

71
New Silver Bullets

• Component technologies
• Distributed objects
• Business objects
• Patterns
• Software reuse
• Scripting languages
• Software agents
• Network-centric computing
• Web interface

72
AntiPattern Structure

• Description of the general form
• Symptoms on how to recognize the general form
• Causes that led to the general form
• Consequences of the general form
• Refactored solution on how to change the
  AntiPattern into a healthier situation

73
AntiPatterns

• A method for efficiently mapping a general,
  problematic situation to a specific class of
  solutions
• Provide real-world experience in recognizing
  recurring problems in the software industry and
  provide a detailed remedy for the most common
  predicaments
• Provide a common vocabularyfor identifying
  problems anddiscussing solutions

74
AntiPattern Categories

• Development AntiPatterns
• Situations encountered by programmers
• Architectural AntiPatterns
• Common problems in system structure
• Managerial AntiPatterns
• Affect people in all software roles
• AntiPatterns apply to software construction as
  well as software evolution

75
AntiPattern Format

• Root causes
• provide fundamental context for the AntiPattern
• Primal forces
• are the key motivators for decision making
• Software design-level model
• define architectural scales each pattern has a
  most applicable scale

76
Root Causes

• Haste
• hasty decisions compromise quality
• code that appears to work is acceptable
• testing is ignored
• Apathy
• lack of partitioning
• ignoring the separation of concerns (e.g., stable
  vs. replaceable design)

77
Root Causes ...

• Narrow-mindedness
• refusal of known or accepted solutions
• reluctance to use metadata
• Sloth
• poor decision based on an easy answer
• frequent interface changes
• lack of configuration control
• reliance on generating stubs and skeletons

78
Root Causes ...

• Avarice
• architectural avaricemodeling of excessive
  details
• excessive complexity due to insufficient
  abstraction
• overly complex systems are difficult to develop,
  integrate, test, maintain, extend

79
Root Causes ...

• Ignorance
• failing to seek understanding
• antonym of analysis paralysis
• focussing on code interfaces rather than system
  interfaces
• no layering
• no wrapping to isolate details

80
Root Causes ...

• Pride
• not-invented-here syndrome
• unnecessary invention of new designs
• reinventing the wheel
• rewrite from scratch
• ignoring requirements
• ignoring COTS, freeware, existing legacy system

81
Forces

• Forces or concerns that exist within a
  decision-making process
• Forces that are addressed lead to benefits
• Forces that remain unresolved lead to
  consequences
• For any given software problem there are a number
  of forces that can influence a given solution

82
Forces ...

• Vertical forces
• Domain specific
• Unique to a particular situation
• Ignored in AntiPatterns
• Horizontal forces
• Applicable across multiple domains
• Influence design and reengineering choice across
  several software modules and components
• Choices made elsewhere may impact local choices

83
Primal Forces ...

• Horizontal forces are called primal forces
• Present in nearly all design or reengineering
  situations
• Keep architecture and development on track or
  synchronized
• A fundamental value system for software architects

84
Primal Forces ...

• Management of functionality
• Meeting the requirements
• Management of performance
• Meeting required speed and operation
• Management of complexity
• Defining abstractions
• Management of change
• Controlling the evolution of the software

85
Primal Forces ...

• Management of IT resources
• People and IT artifacts
• Management of technology
• Controlling technology evolution

86
Architecture AntiPatterns

• The Blob
• Cut-and-Paste Programming
• Stovepipe Enterprise
• Design By Committee
• Swiss Army Knife
• Reinvent the Wheel

87
The Blob

• Problem
• Procedural style design leads to one object with
  a lions share of the responsibilities
• Most other objects only hold data
• This is the class that is really the heart of our
  architecture
• One class monopolizes the processing and the
  others encapsulate data

88
The Blob ...

• Causes
• Lack of an object-oriented architecture
• Lack of architecture enforcement
• Procedural design expert are chief architects
• Wrapping a legacy system resultsin a Blob
  acceptable

89
The Blob ...

• Solution
• Distribute responsibilities more uniformly
• Isolate the effect of changes
• Identify or categorize attributes and operations
• Find natural homes for the identified classes
• Remove outliers

90
Cut-and-Paste Programming

• Problem
• Software clones
• Hey, I thought you fixed that bug already, so
  why is it doing this again?
• Wow, you guys work fast. Over 400KLOC in three
  weeks is amazing!
• Degenerate form of reuse
• Very common in COBOL

91
Cut-and-Paste Programming ...

• Solution
• Clone detection
• Parameterize types
• Introduce an additional level of indirection
• Exploit polymorphism
• Dynamic schemas

92
Stovepipe Enterprise

• Problem
• Stovepipe System is characterized by a software
  structure that inhibits change
• Must be constantly repaired
• Brittle, monolithic system architectures (usually
  undocumented)
• Inability of systems to interoperate

93
Stovepipe Enterprise ...

• Solution
• Coordination of technologies at several levels
• Identify common standards and migration direction
  with a standard reference model
• Usage conventions across systems
• Detailed interoperability conventions across
  systems
• Product lines (SEI)

94
Design by Committee

• Problem
• Gold Plating, Standards Disease, Make Everybody
  Happy, Political Party
• Project team are egalitarian everyone has equal
  say decisions are democratic
• The majority rule leads to diffusion of
  abstraction and excess complexity
• A camel is a horse designed by a committee.

95
Design by Committee ...

• Symptoms
• Design documentation is voluminous
• The requirements do not converge and are unstable
• Design meetings are slow, concentrate on details,
  and avoid big picture discussions
• Decisions are only made in meetings
• No prioritization of design features

96
Design by Committee ...

• Causes
• No designated project architect
• Ineffective meeting facilitation
• The suggestions of all committee members are
  incorporated to keep everybody happy
• No separation of concerns

97
Design by Committee ...

• Refactored solution
• Reform the meeting process
• Why are we here?
• What outcomes do we want?
• Assign explicit roles
• Owner, facilitator, architect, developer, tester,
  domain expert
• My specialty is being right when other people
  are being wrong. George Bernard Shaw

98
Design by Committee ...

• Employ Spitwads meeting process
• Ask questionHow can we improve performance?
• Write down answer silently
• Toss spitwads à la Michael Jordan
• Redistribute, read, and record spitwads
• Reach common understanding
• Eliminate duplicates
• Prioritize by voting
• Discuss highest priority selections

99
Design by Committee

• SQL example
• SQL89115 pages
• SQL92580 pages
• SQL3still not complete may never be fully
  implemented a dumping ground for advanced
  database features
• Better solutions
• Open Database Connectivity (ODBC)
• Java Database Connectivity (JDBC)

100
Reinvent the Wheel

• Problem
• Our problem is unique
• Developers have minimal knowledge of each others
  code
• Building systems from the ground up even though
  related legacy systems exist
• The existence of legacy systems is the norm
  rather than the exception
• Lack of program families or product lines

101
Reinvent the Wheel ...

• Symptoms
• Closed system architecturesno provision of
  reuse, interoperability, or change management
• Replication of COTS components
• Inability to deliver desired features on time and
  within budget
• Corporate knowledge is not leveraged

102
Reinvent the Wheel ...

• Causes
• No communication and technology transfer among
  software development projects
• Corporate knowledge is not leverage
• No explicit architecture process
• Lack of enterprise management

103
Swiss Army Knife or Kitchen Sink

• Problem
• Excessively complex class interface
• Designer attempts to provide for all possible
  uses of the class
• Complicated interface
• Many overloaded names
• Excessive regression test suites
• Several Swiss Army Knifes in a single design

104
Swiss Army Knife ...

• Refactored solution
• Provide guidelines for using complicated
  standards or interfaces
• Provide a template for exception handling
• Contract interfaces

105
Summary

• During program comprehension and evolution one
  should be particularly aware of the potential
  presence of AntiPatterns
• Awareness of AntiPatterns is critical for
  reengineering projects
• Consider AntiPatterns next time you sign on to a
  new project
• Invest in reading the AntiPatterns book

106
Part IIISoftware Architecture Reconstruction

• S. Jeromy Carrière

107
Outline

• Introduction and Philosophy
• Motivation
• Software Architecture Reconstruction Tools
• Extraction and Storage
• Manipulation
• Presentation
• Reconstruction Methodologies
• Examples

108
Another Definition of Architecture

• A set of design decisions
• Typically documented as a set of views
• Realized in an implementation via mappings
• Mappings are almost invariably informal(i.e. not
  explicitly recorded in any implementation
  artifact)
• The implementation is the consequence of the
  application of the mappings

109
Example Layers

• Question What is a layer?
• Answers
• At worst a delusion.
• At best a convention.
• Nothing that exists in what we actually build
  (e.g. no layer construct in a programming
  language).
• Nothing that is enforceable.

110
And Yet . . .

• Architectures use these abstractions regularly.
• Architects think and plan and analyze in terms of
  these abstractions.
• So,
• we should support these abstractions and connect
  them to what we do build.

111
So What Is Architecture Reconstruction?

• A process in which cultural hypotheses are
  generated and tested ? anthropological
• These hypotheses are ideally the inverse of the
  mappings developed during design
• The reconstructor must add information during the
  reconstruction process
• This depends on the reconstructors available
  information and bias

112
Outline

• Introduction and Philosophy
• Motivation
• Software Architecture Reconstruction Tools
• Extraction and Storage
• Manipulation
• Presentation
• Reconstruction Methodologies
• Examples

113
But Why Reconstruct?

• We frequently need to reason architecturally
  about existing systems.
• We need to be able to
• analyze architectures
• (re)document architectures
• identify architectural dependencies

114
Architectural Conformance - I

• Question If my architecture was designed with a
  particular property in mind, does the property
  hold for my target system?
• (Probable) Answer Who knows?

115
Architectural Conformance - II

• The architecture of the implemented system must
  conform to the architectural design.
• Otherwise, architectural drift and erosion are
  inevitable.
• But conformance (by hand) is a dreary task.

116
Outline

• Introduction and Philosophy
• Motivation
• Software Architecture Reconstruction Tools
• Extraction and Storage
• Manipulation
• Presentation
• Reconstruction Methodologies
• Examples

117
Tools for Software Architecture Reconstruction

• Groups working on tools/toolsets
• University of Victoria (Hausi Müller)
• Software Engineering Institute
• MITRE (Penny Chase)
• University of Waterloo (CSER project)
• Philips (René Krikhaar)

118
Tools for Software Architecture Reconstruction
Extraction
Repository
119
Dali A Software Architecture Reconstruction
Workbench (SEI)
120
Software Bookshelf/PBS (Holt et al)
Extraction
Parsing
.
.
.
Fact Files
Layout
121
Outline

• Introduction and Philosophy
• Motivation
• Software Architecture Reconstruction Tools
• Extraction and Storage
• Manipulation
• Presentation
• Reconstruction Methodologies
• Examples

122
Extracting Information

• Most approaches are opportunistic. In common use
  are
• parsers (SNiFF, cfx, CIA, rigiparse, EDG)
• CBMS systems (Reasoning SDK)
• lexical analyzers (LSME)
• profilers (gprof)
• code instrumentation
• ad hoc (grep, perl)

123
Extracting Information - 2

• Source code analysis is insufficient
• late binding
• system topology information
• This information is available only in artifacts
  other than source models.

124
Repositories

• Use of attributed relational models (E/R/A) is
  almost universal
• simple
• flexible
• sufficiently expressive
• well supported by existing tools

125
Example Repository Contents (Dali)

• Some relations relevant to software architecture
• function calls function
• file contains function
• class has_subclass class
• class has_friend class
• process communicates_with process
• process writes file
• . . .

126
A Repository Schema (Bowman)
SourceArtifact
TypeElement
Data Element
Functional Element
Module
Entity Classes
Relation Classes
typeRef
declaredIn
TypeElement
SourceArtifact
Module
functionRef
typeRef
typeRef
FunctionalElement
DataElement
declaredIn
dataRef
127
A Repository Schema (Bowman)
128
A Schema for Procedural Languages (Bowman)
129
Dalis Repository

• Dali uses an SQL database with a philosophy of
  openness and lightweight tool integration via
  text formats (RSF - Rigi Standard Format).
• The database and tools are ignorant of each
  other.
• The tools extract, modify, manipulate, and store
  architectural artifacts in the database.
• Integration is controlled via Rigis RCL and
  scripts.

130
PBS Repository

• PBS uses a file-based approach to storing
  facts
• TA (Tuple-Attribute) format - based on RSF
• This approach improves exchangeability but
  potentially involves more run-time overhead.
• Integration is accomplished via scripts.

131
Philips Repository

• Based on the concepts of
• InfoPacks information extracted from a system
• ArchiSpects representation of an architectural
  structure or analysis
• Both include a description of the steps to
  construct the model.
• Integration is achieved via a variety of
  scriptsand tools.

132
Information Interchange

• Its important to be able to exchange facts and
  models.
• We need two things to do this properly
• an agreed-upon syntax, including a schema
• an agreed-upon semantic model for describing the
  facts and their manipulations

133
Outline

• Introduction and Philosophy
• Motivation
• Software Architecture Reconstruction Tools
• Extraction and Storage
• Manipulation
• Presentation
• Reconstruction Methodologies
• Examples

134
Manipulation - Motivation

• Architectural elements are not explicitly
  represented in source code.
• user interface, repository, cache, etc. are
  usually tangled collections of objects
• architectural constructs are realized by many
  mechanisms in an implementation
• Therefore, we need to reconstruct architectural
  elements.

135
Manipulation in Dali View Fusion

• Motivation
• Extractors will frequently produce incomplete and
  partially overlapping data
• A complete view of a system requires views to be
  fused
• different views provide complementary information
• one view can improve another

136
Manipulation in Dali Aggregation

• Primary mechanism for manipulation is the
  application of patterns for aggregation,
  constructed using SQL.
• Examples
• aggregate local variables with functions
• aggregate members with classes
• compose architecture-level elements

137
Manipulation in PBS

• Manipulation of facts in PBS is performed using
  Grok
• Grok is a relational calculator based on Tarski
  relational algebra (with extensions)
• abstraction is the key transformation of the
  model
• input for abstraction comes from containment
  hierarchies specified by the reconstructor

138
Manipulation in Philips Toolset

• Manipulation of models is performed via the
  Relational Partition Algebra (RPA)
• RPA is also based on Tarski algebra
• Computation is carried out using a variety of
  implementations of RPA
• ArchiSpects specify the creation of abstracted
  views

139
Outline

• Introduction and Philosophy
• Motivation
• Software Architecture Reconstruction Tools
• Extraction and Storage
• Manipulation
• Presentation
• Reconstruction Methodologies
• Examples

140
Presentation

• The end goal of architecture reconstruction is
  generation of architectural views that
• improve understanding of the system
• provide (improved) documentation
• improve maintainability
• facilitate analysis

141
Presentation in Dali

• Presentation in Dali is done using Rigi
• Rigi provides useful graph editing functionality
• layout
• direct manipulation
• hierarchical navigation
• extensibility
• Examples coming up...

142
Presentation in Bookshelf/PBS

• The software landscape presentation approach
• hierarchical
• PBS is Web-based (Java)
• incorporates architectural visualizations within
  a framework of documentation

143
PBS Example
144
Outline

• Introduction and Philosophy
• Motivation
• Software Architecture Reconstruction Tools
• Extraction and Storage
• Manipulation
• Presentation
• Reconstruction Methodologies
• Examples

145
Reconstruction Methodologies

• A predictable, repeatable method is important for
  management of reconstruction activities
• Because the process is primarily one of
  hypothesis formulation and test, we need
  structured methods for information collection
• Methods are universally semiautomatic (shouldnt
  be a surprise!)

146
A Reconstruction Method Sketch (SEI)
Developinformationmodel
Populateinformationmodel
Developarchitecturalrules
Applyarchitecturalrules
Extractinformation
Identifyarchitecturalcomponents
Developrepresenta-tion template
Mapmodels totemplate
Evaluate
147
The Hybrid Approach (Tzerpos Holt)

• Hybrid Combine extracted information with
  information collected from developers.
• Iterative steps at multiple levels of
  granularity
• Choose domain model
• Extract facts from source code
• Cluster into subsystems
• Refine clustering using live information
• Refine layout using live information

148
The Architecture Reconstruction Method (Guo)

• Pattern- and style-oriented approach to
  reconstruction
• Four primary phases
• Developing a concrete pattern recognition plan
• Extracting a source model
• Detecting and evaluating pattern instances
• Reconstructing and analyzing the architecture

149
Outline

• Introduction and Philosophy
• Motivation
• Software Architecture Reconstruction Tools
• Extraction and Storage
• Manipulation
• Presentation
• Reconstruction Methodologies
• Examples

150
Example VANISH (using Dali)
As-designed Architecture
151
Extract Information
White noise a typical extracted model.
152
Apply Generic Patterns
Aggregate functions and local variables classes
and members classes and files.
153
Apply Application-Specific Patterns

• Identify the layers
• from the Arch model.

154
The Final Product
As designed
As implemented
155
Analysis - 1

• Architectural conformance via RMTool (Murphy)

156
Analysis - 2

• If we believe in pattern-based simplicity . . .
• . . . we should be able to measure this in an
  architecture.
• IAPR is an analysis tool to do this.
• Approach pattern matching as sub-graph
  isomorphism a search task (NP-hard).

157
Coloring an Architecture (Kazman Burth)