This document discusses software architecture and design testing. It explains that software architecture and design defects can lead to bugs and issues later in development. Some common types of early-stage defects include requirements defects, architectural defects, and design defects. Thorough testing of architecture and design can help reduce later defects by discovering problems early. The document recommends techniques like architecture reviews, modeling, and inspections to test software architecture and design quality before implementation.

1. Why and how should we test
software architecture and
software design?
Zarko Acimovic

2. Software Defects Potentials
As an example for function point measure Win 7 has ~100K Function Points, Microsoft Word has
~5K Function Points. The technology assumptions underlying below table assume CMMI level 1
and a traditional waterfall development method.
Source: Chapter 2. Estimating and Measuring Software Quality. The Economics of Software
Quality, ISBN: 9780132564762 , Pages 40, 41, Capers Jones, Olivier Bonsignour
http://www.amazon.com/Economics-Software-Quality-Capers-Jones/dp/0132582201
http://www.informit.com/store/product.aspx?isbn=0132582201
Defects per Function Point Percent of Total Defects
Requirement Defects 1.15 9.58%
Architectural Defects 0.25 2.08%
Design Defects 1.50 12.50%
Coding Defects 2.00 16.67%
Test Plan and Test Case Defects 1.85 15.42%
User Documentation Defects 0.75 6.25%
Database Defects 2.75 22.92%
Website Defects 1.75 14.58%
TOTAL 12.00 100.00%

3. ms
Te
te
ch
Sys
n ic
DoD Architecture
al
Operational
Framework
Overview
Alessio Mosto
May, 2004
Source:
http://www.disi.unige.it/person/ReggioG/ISII04WWW/DODAF.ppt

4. Architecture Definition
 “The structure of components, their
relationships, and the principles and guidelines
governing their design and evolution over time.”
DoD Integrated Architecture Panel, 1995, based on IEEE STD 610.12
 “An architecture is the fundamental organization
of a system embodied in its components, their
relationships to each other, and to the
environment, and the principles guiding its
design and evolution.”
IEEE STD 1471-2000
Alessio Mosto DoD Architectural Framework 2

5. Architecture vs. Design
 System Architecture is used to:
 Make buy decisions
 Discriminate between options
 “Discover” the true requirements
 Drive one or more systems to a
common “use” or purpose
 System Design is used to:
 Develop system components
 Build the system
 Understand configuration changes
as the system is modified
Alessio Mosto DoD Architectural Framework 3

6. Basic Principles - An Integrated
Architecture with Three Views
Activities/ Operational
Tasks Operational Elements
View
Identifies What Needs To Be
Done And Who Does It
Information Flow
Systems Data Flow Standards Rules
Systems Technical
X View X
Z
Y
Standards View
Y
Relates Systems and Characteristics
Y Prescribes Standards and
to Operational Needs
X
Conventions
Communications Conventions
Alessio Mosto DoD Architectural Framework 4

7. Architecture Views
Alessio Mosto DoD Architectural Framework 5

8. Software Architecture Defects
Source: A Dissertation Presented to the Graduate School of Clemson University
In Partial Fulfillment of the Requirements for the Degree Doctor of Philosophy
Computer Science by Kyungsoo Im December 2010
Links http://etd.lib.clemson.edu/documents/1306855520/
http://etd.lib.clemson.edu/documents/1306855520/Im_clemson_0050D_10926.pdf
ArchStudio and ArchLight !
http://www.isr.uci.edu/projects/archstudio/whatis.html

12. Software Design Defects
Sources
http://www.cslhr.nu.edu.pk/GCCS/Spring2010/papers/Kamran.pdf
http://www.scribd.com/doc/17402321/Software-Design-Defects-2
http://www.ptidej.net/Members/mohanaou/paper/ASE06/Moha06-ASE.pdf
http://www-etud.iro.umontreal.ca/~ptidej/yann-gael/Work/Publications/Documents/ASE06.ppt.pdf

13. 6/24/2009
Software Design Defects
Software Design Defects Design Patterns are “good” solutions to
recurring design problems
◦ Where you want to be in terms of good design
Design Defects are “bad” solutions to
recurring problems
◦ Where you should not find yourself in software
development
Design Defects lessen the quality of OO
architectures and impede their evolution and
their maintenance
Patterns and Software Defects AntiPatterns
To Err Is Human AntiPatterns provide patterns that have
negative consequences on software
2 categories: development effort
◦ High-level (global) problems: AntiPatterns ◦ Reality of a good number of software projects
◦ Low-level (local) problems: Code Smells Help identifying problems in software
“ deviations from specifications or expectations ◦ Bad design results from common mistakes and
misunderstandings
which might lead to failures in operation ” Provide common vocabulary to discuss
They describe in general what not to do problems and their solutions in software
Arise due to lack of knowledge and experience industry
Understanding AntiPatterns provides the
A good form of problem-solving approach knowledge to prevent or recover from them
Well-
Well-known AntiPatterns
AntiPatterns
Root causes
AntiPatterns are all around us. They’re often ◦ Haste
used as tools for social control. Good design is a product of careful study
Trimming budgets, unrealistic committeements
SOCIAL AntiPatterns Leads to compromises in software quality
◦ Apathy
◦ Criminal Not caring about solving known problems
◦ Narrow-mindedness
◦ Drug Addict Refusal to accept widely known solutions
◦ Laziness (Sloth)
◦ Witch Configuration management
◦ Ignorance
◦ PickPocket Failing to seek understanding
◦ Pride
Not-invented-here syndrome: avoids using or buying already existing
products
1

14. 6/24/2009
AntiPatterns The Blob
Blob (Huge Class)
Describe context and causes
“ Procedural-style design
Describe symptoms to detect an leads to one object with a
lion’s share of the
AntiPattern in legacy software responsibilities while most
other objects only hold
Describe their consequences data or execute simple
Describe a roadmap for their solution processes ”
Large controller class
Many fields and methods
with a low cohesion
In this course, we shall only cover Dependent on the data
AntiPatterns related to software code stored in associated data
classes
The Blob
The Blob Causes and Consequences
Library_Main_Control Item
Person
Current_Catalog Title
Typical Causes
Name Current_Item ISBN
User_ID User_ID Author ◦ Lack of proper Object-Oriented architecture
Items_Out Fine_Amount Publisher
Fines Etc.
Cost
Data_In
◦ Prototype software evolves into a product
…
Do_Inventory()
Check_Out_Item(Item)
Qty
…
◦ Lack of architectural enforcement
Check_In_Item(Item)
Add_Item(Item) Consequences
Delete_Item(Item) Catalog
Print_Catalog()
Topic
◦ Modular continuity is compromised
Sort_Catalog()
Search_Catalog(Params)
Inventory
…
◦ Too complex for reuse and testing
Print()
Issue_Library_Card() ◦ Expensive to load into memory even for small
Calculate_Late_Fine()
operations
The Blob
The Blob - Solution
Solution
Library_Main_Control Item
Avoid it Person
Current_Catalog Title
Name Current_Item ISBN
◦ Managers should review program design User_ID User_ID Author
Items_Out Publisher
regularly Fines
Fine_Amount
Etc.
Cost
… Data_In
Refactor it Do_Inventory()
Check_Out_Item(Item)
Qty
…
Check_In_Item(Item)
◦ Move behavior away from the Blob Add_Item(Item)
Delete_Item(Item)
◦ Construct cohesive classes: cohesive set of Print_Catalog()
Catalog
Topic
attributes and methods are encapsulated Sort_Catalog()
Search_Catalog(Params)
Inventory
…
together Print()
Issue_Library_Card()
◦ Remove far-coupling Calculate_Late_Fine()
2

15. 6/24/2009
Spaghetti Code
Spaghetti Code Causes and Consequences
“ Ad hoc software structure makes it difficult Typical Causes
to extend and optimize code.”
Code with very little software structure, ◦ Inexperience with Object-Oriented design
lack clarity technologies
Implementation invokes a process flow ◦ Ineffective code reviews
Lack of structure : no inheritance, no ◦ No initial software design
reuse, no polymorphism
Long methods process oriented with no Consequences
parameters and low cohesion ◦ Code reuse is difficult
Procedural names of classes and methods ◦ Follow-on maintenance efforts contribute to the
Negligible degree of interaction between problem
objects
Use of global variables for processing ◦ Software reaches point of diminishing returns: the
effort involved to maintain existing code exceeds the
cost of developing a new “ground up” solution
public boolean startElement(int, XMLAttrList) if (prefix == -1) {
...
throws Exception {
if (!fValidating && !fNamespacesEnabled) {
return false;
if (elementURI != -1) {
fStringPool.setURIForQName(...);
•No Objects
•Process Flow
Spaghetti Code
}
}
if (contentSpecType == -1 && fValidating) {
}
else {
•Conditionals
•Complexity
Solution
... ...
} if (elementURI == -1) { •Cannot be The best way is to prevent spaghetti code by first
if (... && elementIndex != -1) {
... }
... reused thinking and then developing. To avoid:
}
}
fStringPool.setURIForQName(.elementURI); ◦ Domain model even when it is well-understood
if (DEBUG_PRINT_ATTRIBUTES) {
... if (attrIndex != -1) { ◦ OO Analysis
} int index = attrList.getFirstAttr(attrIndex);
if (fNamespacesEnabled) {
while (index != -1) { ◦ OO Design
int attName = attrList.getAttrName(index);
fNamespacesScope.increaseDepth();
if (attrIndex != -1) {
if (!fStringPool.equalNames(...)) { ◦ Objects should be sufficiently refined
...
int index = attrList.getFirstAttr(attrIndex); if (attPrefix != fNamespacesPrefix) { When adding new features, remove code defects
while (index != -1) { if (attPrefix == -1) {
... ... Write accessor functions for member variables
if (fStringPool.equalNames(...)) { }
... else { Refactor code into methods
} if (uri == -1) {
else {...} … Remove obsolete code
} }
index = attrList.getNextAttr(index); fStringPool.setURIForQName(attName, uri); Rename classes, functions, data types to conform
if (fElementDepth >= 0) {
}
}
fElementDepth++; to industry standards
if (fElementDepth == fElementTypeStack.length) {
int prefix =
...
fStringPool.getPrefixForQName(elementType); } }}}
int elementURI; return contentSpecType == fCHILDRENSymbol; }
Functional Decomposition
Functional Decomposition Causes and Consequences
One main routine that calls several other Typical Causes
subroutines ◦ No use of OO concepts like inheritance or
Invoked subroutines are implemented as polymorphism
classes ◦ Lack of understanding of OO concepts
Classes with single action such as a ◦ Lack of architecture enforcement
function Consequences
Attributes are private and used only ◦ Difficult to reuse
inside the class ◦ Expensive to maintain
The resulting code resembles a structural ◦ no way to clearly document (or explain) how
the system works
language like C and is incredibly complex
3

16. 6/24/2009
Functional Decomposition Functional Decomposition
Solution A customer loan scenario
Find the original Use Cases to ascertain Adding a new customer
features from user view point Updating a customers address
OO reengineering process Calculating a loan to a customer
Find matching OO design model Calculating the interest on a loan
Combine classes which assist each other Calculating a payment schedule for a
Combine classes which try to achieve the customer loan
same design objective Altering a payment schedule
Find similar subsystems (reuse of code)
Functional Decomposition OO Version
Cut-and-
Cut-and-Paste Programming Cut-and-
Cut-and-Paste Programming
Causes and Consequences
“Man, you guys work fast. Over 400,000 lines of Typical Causes
code in just three weeks is outstanding progress.”
◦ Reusable code is difficult to create and organizations prefer
Cut-and-Paste Programming is a short term benefits
very common degenerate form of ◦ Easier to modify existing code than writing from scratch
software reuse that causes
maintenance nightmares. ◦ Lack of abstraction in developers
Less experienced programmers ◦ Lack of knowledge of tools and technologies, hence working
examples are modified to create new components
learn by changing code of
experienced developers ◦ Lack of forward thinking
Presence of several similar Consequences
segments of code ◦ Software defects and bugs are replicated
Creates code duplication ◦ Difficult to locate all instances of a bug
Positive short-term consequences ◦ Code reviews and inspections are needlessly extended
such as boosting line count metrics ◦ Excessive software maintenance costs
◦ Duplication of testing, review, bug fixing efforts
4

17. 6/24/2009
Cut-and-
Cut-and-Paste Programming
Swiss Army Knife
Solution
A Swiss Army knife is a
Three step approach brand of multi-function
◦ Identify Code duplication pocket knife or multi-tool.
Excessively complex class
◦ Refactoring duplicates into libraries or interface
components for black-box reuse Designer attempts to
◦ Configuration management : code inspection, provide for all possible
uses of the class.
reviews and validation efforts in future to Large number of interface
avoid Cut-and-Paste Programming signatures
No clear abstraction or
focus of the class interface
Swiss Army Knife Swiss Army Knife
Causes and Consequences Solution
Causes Describe a profile for the class
◦ No focused responsibility Profile documents the way to use a
◦ Class attempting to provide too much complex technology
functionality
Consequences Profile for an interface describe the
◦ More != Better signatures and parameter values
◦ Confusion
◦ Maintenance problems
◦ Each interface requires implementation of
items on that interface
Conclusions Code Smells
“If it stinks, change it”
AntiPatterns provide patterns that have negative
consequences on software development effort
Each AntiPattern includes a solution + solution pair
Hint that something has gone wrong
◦ AntiPattern Solution Generates mostly negative
consequences Opportunities for improving program
◦ Refactored Solution Generates mostly positive design
benefits
AntiPatterns are useful for refactoring, migration, Code smells indicate the need for the
upgrade, and reengineering application of a possible refactoring
5

18. 6/24/2009
Code Smells - Examples Code Smells – More Examples
Duplicate Code Long Parameter List
◦ Duplication of bugs, tests, reviews
◦ Same (or nearly) code in multiple places
◦ Programs harder to understand
◦ Frequently the result of cut-and-paste coding ◦ Difficult to reuse and change
Long Method ◦ Parameter lists should be shorter in OO
◦ OO puts premium on short methods programs than in traditional programs
◦ Long procedures always harder to understand
Divergent Change
Large Class
◦ Class has poor cohesion ◦ One class commonly changed in different
◦ Too many instance variables or methods means a class is ways for different reasons
doing too much ◦ Some methods changed in one case
◦ Class interface does not provide consistent level of
abstraction ◦ Other methods changed in another
Code Smells – More Examples
Feature Envy
◦ Method seems more interested in a class other
than the one it is in
◦ Most common focus is data (lots of getter calls)
Data Clumps
◦ Same data items in multiple classes
◦ Parameter lists of several methods
◦ If after deleting one from clump the rest wouldn’t
make sense, a clear candidate for refactoring
6

19. ArgoUML !!!

21. ArgoUML Design Critics
Chapter 15. The Critics
Table of Contents
15.1. Introduction
15.1.1. Terminology
15.1.2. Design Issues
15.2. Uncategorized
15.3. Class Selection
15.3.1. Wrap DataType
15.3.2. Reduce Classes in namespace <namespace>
15.3.3. Clean Up Diagram
15.4. Naming
15.4.1. Resolve Association Name Conflict
15.4.2. Revise Attribute Names to Avoid Conflict
15.4.3. Change Names or Signatures in a model element
15.4.4. Duplicate End (Role) Names for an Association
15.4.5. Role name conflicts with member
15.4.6. Choose a Name (Classes and Interfaces)
15.4.7. Name conflict in a namespace
15.4.8. Choose a Unique Name for a model element (Classes and Interfaces)
15.4.9. Choose a Name (Attributes)
15.4.10. Choose a Name (Operations)
15.4.11. Choose a Name (States)
15.4.12. Choose a Unique Name for a (State related) model element
15.4.13. Revise Name to Avoid Confusion

22. 15.4.14. Choose a Legal Name
15.4.15. Change a model element to a Non-Reserved Word
15.4.16. Choose a Better Operation Name
15.4.17. Choose a Better Attribute Name
15.4.18. Capitalize Class Name
15.4.19. Revise Package Name
15.5. Storage
15.5.1. Revise Attribute Names to Avoid Conflict
15.5.2. Add Instance Variables to a Class
15.5.3. Add a Constructor to a Class
15.5.4. Reduce Attributes on a Class
15.6. Planned Extensions
15.6.1. Operations in Interfaces must be public
15.6.2. Interfaces may only have operations
15.6.3. Remove Reference to Specific Subclass
15.7. State Machines
15.7.1. Reduce Transitions on <state>
15.7.2. Reduce States in machine <machine>
15.7.3. Add Transitions to <state>
15.7.4. Add Incoming Transitions to <model element>
15.7.5. Add Outgoing Transitions from <model element>
15.7.6. Remove Extra Initial States
15.7.7. Place an Initial State
15.7.8. Add Trigger or Guard to Transition
15.7.9. Change Join Transitions
15.7.10. Change Fork Transitions
15.7.11. Add Choice/Junction Transitions
15.7.12. Add Guard to Transition
15.7.13. Clean Up Diagram
15.7.14. Make Edge More Visible
15.7.15. Composite Association End with Multiplicity >1
15.8. Design Patterns

23. 15.8.1. Consider using Singleton Pattern for <class>
15.8.2. Singleton Stereotype Violated in <class>
15.8.3. Nodes normally have no enclosers
15.8.4. NodeInstances normally have no enclosers
15.8.5. Components normally are inside nodes
15.8.6. ComponentInstances normally are inside nodes
15.8.7. Classes normally are inside components
15.8.8. Interfaces normally are inside components
15.8.9. Objects normally are inside components
15.8.10. LinkEnds have not the same locations
15.8.11. Set classifier (Deployment Diagram)
15.8.12. Missing return-actions
15.8.13. Missing call(send)-action
15.8.14. No Stimuli on these links
15.8.15. Set Classifier (Sequence Diagram)
15.8.16. Wrong position of these stimuli
15.9. Relationships
15.9.1. Circular Association
15.9.2. Make <association> Navigable
15.9.3. Remove Navigation from Interface via <association>
15.9.4. Add Associations to <model element>
15.9.5. Remove Reference to Specific Subclass
15.9.6. Reduce Associations on <model element>
15.9.7. Make Edge More Visible
15.10. Instantiation
15.11. Modularity
15.11.1. Classifier not in Namespace of its Association
15.11.2. Add Elements to Package <package>
15.12. Expected Usage
15.12.1. Clean Up Diagram
15.13. Methods
15.13.1. Change Names or Signatures in <model element>

24. 15.13.2. Class Must be Abstract
15.13.3. Add Operations to <class>
15.13.4. Reduce Operations on <model element>
15.14. Code Generation
15.14.1. Change Multiple Inheritance to interfaces
15.15. Stereotypes
15.16. Inheritance
15.16.1. Revise Attribute Names to Avoid Conflict
15.16.2. Remove <class>'s Circular Inheritance
15.16.3. Class Must be Abstract
15.16.4. Remove final keyword or remove subclasses
15.16.5. Illegal Generalization
15.16.6. Remove Unneeded Realizes from <class>
15.16.7. Define Concrete (Sub)Class
15.16.8. Define Class to Implement <interface>
15.16.9. Change Multiple Inheritance to interfaces
15.16.10. Make Edge More Visible
15.17. Containment
15.17.1. Remove Circular Composition
15.17.2. Duplicate Parameter Name
15.17.3. Two Aggregate Ends (Roles) in Binary Association
15.17.4. Aggregate End (Role) in 3-way (or More) Association
15.17.5. Wrap DataType