Session 1

Software Architecture
26-Aug-2010
Basics of Software Architecture
Dr S Sivakumar
SSN School of Advanced Software Engineering
Agenda
• Software Architecture
• Architectural Forces
• Role of Software Architecture
• Benefits of Software Architecture
• Representation of Architecture
• Role of Software Architect
1
2
Software Architecture
• First, why are we bothered about it?
• Consider the following examples from construction industry
– Building a cattle shed
– Building an independent house
– Building a skyscraper
• What do these examples tell us?
3
Building A Cattle Shed
• Building a cattle shed
– Nobody thinks twice
– Nail some asbestos sheets together
– Simple tools, simple process, single person
4
Independent House
• Building an independent house
– Now we need to pause and think
– How many rooms are needed?
– How many windows are needed?
– How do we move from one room to another?
– We need a larger process, several people, more tools
5
Skyscraper
• Building a skyscraper
– Things are getting complex
– How many floors needed?
– How many people will be there at peak time?
– What would be the maximum wind speed to withstand?
– How do we lay out the air-conditioning ducts?
– How do we lay out the electrical wirings?
– How many people needed to construct?
– We need answers to a lot of similar questions
– Architects and engineers provide those answers
– They also come up with several Blueprints
6
Differences
• Scale
• Process
• Tools used
• Cost
• Schedule
• Skills and development teams
• Materials and technologies
• Stakeholders
• Risks
7
Consider Software Development
• A small program to print the date and hostname
– Just type the code to call an API (Java Servlet)
protected void processRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
PrintWriter out = response.getWriter();
try {
String greet, name;
greet = getServletConfig().getInitParameter("greeting");
name = getServletContext().getAttribute("name").toString();
out.println("<html>");
out.println("<head>");
out.println("<title>" + greet+"</title>");
out.println("</head>");
out.println("<body>");
out.println("<h1>" + greet + name + "</h1>");
out.println("<h3>Transaction time: " + new java.util.Date() + "</h3>");
out.println("<h3>Transaction made at: " + request.getRemoteHost() + "</h3>");
out.println("</body>");
out.println("</html>");
} finally {
out.close();
}
}
Welcome! Sivakumar
Transaction time: Wed Aug 25 22:58:47 IST 2010
Transaction made at: 127.0.0.1
8
A Small Application
• Build an order management program for your neighborhood shop
– We definitely need to think before rushing to code
– What are the actual requirements?
– What entities need to be programmed?
– How to decide what entities are needed?
– We now have to first document our ideas
ref:www.softforall.com
9
A Distributed Application
10
A Distributed Application
• Build a distributed application
– How many people will be using it?
– Will they be able to access it through their PDAs?
– How to ensure that the application is secure and available 24x7?
– How to ensure performance and reliability of the application?
– What application is to run where?
– We definitely need a Blueprint here!
That Blueprint is Software Architecture!
11
Now, What is Software Architecture?
• People describe it informally M1
C1
– Typically using a box-and-line diagram
– Textual descriptions
– Rarely formal
• Making it an engineering discipline
– Need formal definition
– Need formal representation and documentation
– Need assurance that the final system confirms to the
architecture
– Need to use existing knowledge
12
• Software architecture talks about the structure of applications
• What is meant by structure of applications?
– Similar to an apartment consisting of interconnected rooms
– Applications consist of smaller applications, called modules or
components, arranged in a specific fashion
• What is a module? What is a component?
– Modules or components are built by programs
13
Components and Modules
• Component
– A ‘constituent part’ of the system
– Non-trivial, nearly independent and replaceable
– Fulfils a clear function in the context of an architecture
• Module
– A software unit of storage and manipulation
– Includes
• Source code modules
• Binary code modules
• Executable code modules
14
• Software architecture now deals with the following:
– What do the modules do?
– How big are the modules?
– How the modules are interconnected?
– How to identify the modules first of all? and so on . .
15
Formal Definition
• IEEE Standard 1471-2000
– 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.
• CMU 1[2]
– The structure of the components of a program/system, their
interrelationships, and principles and guidelines governing their
design and evolution over time.
• CMU 2 [3]
– A software architecture for a system is the structure or
structures of the system, which comprise elements, their
externally-visible properties, and the relationships among them.
• Check the SEI site for more definitions
• http://www.sei.cmu.edu/architecture/published_definitions.html
16
RATIONAL Definition of Architecture
• Software architecture encompasses the set of significant
decisions about the organization of a software system
– Selection of the structural elements and their interfaces by which
a system is composed
– Behavior as specified in collaborations among those elements
– Composition of these structural and behavioral elements into
larger subsystems
– Architectural style that guides this organization
Ref: IBM Rational Unified Process
17
All Definitions have Something in Common
• Architecture talks about major modules or components (these are
also called structural elements)
• Architecture talks about how these structural elements are
interconnected
– Thus, it determines the structure of the software
• Architecture specifies the behaviour of these structural elements
• Architecture does not bother about content of these structural
elements that is not relevant to the interactions
• Architecture defines the rationale behind identifying the structural
elements and their interactions
In general, architecture helps determine the

structure using specific structural elements and
provides a reasoning for having that structure
18
Arrangement of Structural Elements
<<subsystem>>
Dispenser
<<subsystem>> <<subsystem>>
Card Reader ATM Network
(from System Services Layer) (from System Services Layer)
<<subsystem>>
Customer Interface
(from System Services Layer)
19
Arrangement of Structural Elements
<<subsystem>>
ATM Network
Are there standard

ways of arrangement?
<<subsystem>>
ATM Yes, next lecture
(from System Services Layer) discusses about them
<<subsystem>>
Customer Interface
20
Agenda
• Software Architecture Definition
21
What determines the structure?
• Functional requirements
• But, more importantly, requirements from the perspectives of
– Business objectives
– Complexity
– Required quality
– Technology
– Available skills
– Comprehension
– Economic and Technological trade offs
– Organizational culture
– Development process
– And, many more . . .
• These are collectively known as architectural forces
– How they influence architecture is explained subsequently
• Architecture is the simplest solution balancing the forces
22
Architecture is a Trade-off
• Architecture represents a trade-off of the forces
– Complex architecture may pull down quality
– Use of technology is limited by available skills
– The amount of features to be provided is determined by business needs
– Stakeholders have their own sphere of influence
– An architect has to balance all these forces and arrive at the optimal
structure!
– Architect goes through many cycles before arriving at the optimal
structure
23
Architecture Business Cycle (ABC)
• Architecture is the result of a balance among architectural forces
• The existence of architecture affects these forces in turn
• This cycle is called Architecture Business Cycle
– Business objectives determine the requirements
– Requirements determine the architecture
– Architecture provides the system
– System suggests new business capabilities and requirements
– And, back to architecture!
• Architecture should be designed to survive this cycle longer
– Especially for products!
24
Architecture Business Cycle
Architecture
Architectural Forces
Delivers Functionality
Technology
Complexity
Quality
Determines
Skills
System
Organization culture
Process
Business objectives
Architect
ref: Software Architecture in Practice

Bass, Clements, Kazman
25
Architectural Requirements
• Architectural requirements determine the structure
• Functional
– Features, use cases
• Non-functional
– Referred as ‘supplementary specifications’ in Rational Unified
Process
– Referred as ‘quality attributes’ by Software Engineering Institute,
CMU
26
• Supplementary Specifications
– Capture the system requirements that are not readily captured
in the use cases
• Legal and regulatory requirements
• Quality attributes of the system to be built
– Performance
– Security You can’t talk about these
– Usability requirements without
– Availability talking about functionality
– etc
• Constraints
– Technology
– OS
– Compatibility with other software
– Design constraints
27
• Supplementary Specifications
• Supportability
– The product will support multiple human languages
– The system must support 200,000 users with 50,000 users using
the system at any point in time
• Availability
– The system shall be continuously available (aka 7 x 24) with 2
hours downtime for maintenance every week
• Reliability
– If the system fails during check-in, an option to abort the
unfinished transaction shall be provided next time when the user
logs in.
• Constraints – Design requirements

– An RDBMS will be used for persistence
– The RDBMS for the first release will be DB2 V9
• Constraints – Implementation requirements

– All presentation logic will be written in Visual Basic .Net
28
• Elicit requirements and document
– Elicitation techniques
– Quality attribute workshops
– Document
• Supplementary Specifications Document
– Template from RUP
• Six parts scenario for each quality attribute
– Refer Bass, Clements and Kazman [3]
29
• Balance needed
• Make stake holders understand
– Cost / effort implications
– All requirements are not of equal importance
– Unambiguous requirements
• System shall be modifiable
– Meaningless.
– Every system is modifiable for some changes and not for other
changes.
» It should take less than 1 PD to implement any changes in the
check-in business rules
– Measurable requirements
• System shall be easy to modify
– Again, meaningless
– Refer above
30
Supplementary Specifications Interlinked
• System failure
– An aspect of availability, reliability and Fault Tolerance
• Performance
– Affected by security, modifiability, fault tolerance, reliability
• Complex relations among supplementary specifications
– Elicit as much details as possible
– Keep questioning the need
– Prioritize
– Involve stakeholders
31
Agenda
32
Role of Software Architecture
• Bridges requirements and design/implementation
• Guides design and implementation
• Provides a rationale for having a specific structure
• Provides the required properties for the system
– Performance, scalability, reliability, reusability etc
33
Influence of Architecture
Requirements
Architecture
Design
Implementation
Testing
Delivery
Maintenance
Enhancement
Next generation
34
Influence of Architecture
Architecture has the single largest

effect on the cost and quality of the
application
35
Architecture is/isn’t Many Things
• Design
• Static structure
• Single blueprint
• Architecture is abstract
• Architecture can’t be measured
• It is an art
• It is engineering
36
Agenda
37
Benefits of Architecture
• Communication among stakeholders
– Different views communicate different perspectives
• Key design decisions communicated
• Ensure a balance among forces and system integrity
– Integrity and quality ensured while allowing changes
• Enables system longevity
– Evolution easier
– Resilient to changes
• Changes in domain
• Changes in technology
• Manage complexity
– Divide and conquer
• Decomposition
• Encapsulation
• Separation of concerns
• Maximize reuse
– At component level – low granularity
– At subsystem, pattern and framework level – high granularity
38
Benefits of Architecture (contd)
• Reduce cost
– Savings from reuse
– Savings from optimal use of resources
– Savings from better support and maintenance
• Predictability
– Early abstractions enable measurements
• Schedule metrics
• Development metrics
– Risks eliminated
• Predictions easier
• Testability
– System componentized
• Better diagnostics, error detection through traceability
• Provides for early design decisions
• Architecture defines constraints on implementation
39
Benefits of Architecture (contd)
• Guides organizational structure

– Components used as development units
• Teams organized accordingly
– Development team
» ‘Business Component group’
» Inventory
» General Ledger
» ‘UI group’
» ‘Security group’
» ‘Workflow group’
» etc
– Testing team
– CM team
• Enables concurrent development of components
• Makes change management easier
• Provides common architecture for product lines
• Helps in evolutionary development
Makes you sleep peacefully!
40
Agenda
41
Architectural Representation
• How to represent architecture?
• What level of details is needed?
42
Use of Representations
• Documentation
– Provides the rationale behind the decisions
• Communication
– Need to involve stakeholders
• Analysis
– A measure of realization
43
Representation of Architecture
• Software architecture specified using models
– Visual with textual annotations
– Formal using Architectural Description Language (ADL)
44
Visual
• Box-and-line diagram
– Descriptions about what those boxes and lines mean
• Using standard notation
– UML
• Constraints specified using OCL (Object Constraint Language)
45
UML Based Representation
• Views
– Projections of models
– Views provide perspectives
– A view depicts a few elements and relations of interest to the
stakeholder
• What information is of interest to the stakeholder?
46
View
• Projection of model information
A projection of a model, which

is seen from a given
perspective, and omits entities
that are not relevant to this
perspective Complete description of a
system at a specific level of
View
abstraction Model
Stakeholder
Views are projections of a model for a particular stakeholder
47
How do we arrive at the views?
• What types of stakeholders are there?
– Roles
• Analyst
• Architect
• Designer
• Implementer
• Tester
• System integrator
• System administrator
• Need to provide a view for each role
48
Visual Descriptions
– Kruchten’s 4+1 Views: basis of RUP
• Logical, Implementation, Process, Deployment, Use cases
– Siemens Four views
• Conceptual, Module, Code, Execution
– ANSI/IEEE 1471-2000
• More of a view framework
49
Software Architecture: The “4+1 View”
Model
Logical View Implementation View
End-user
Analysts/Designers Programmers
Functionality
Structure Software management
Use-Case View
Process View Deployment View

System integrators System engineering
Performance System topology
Scalability Delivery, installation
Throughput communication
Ref : Kruchten (1995)
50
Other View: From Siemens
Ref: “Applied Software Architecture”, Hofmeister, C. et al. (2000).
51
Architecture Description Language
− An ADL is a language that provides features for modeling a
software system’s conceptual architecture.
− Essential features: explicit specification of
– components
– interfaces
– connectors
– configurations
− Desirable features
– specific aspects of components, connectors, and configurations
– tool support
52
ADL – ACME Example
System simple_cs = {
Component client = { Port send-request }
Component server = { Port receive-request
}
Connector rpc = { Roles {caller, callee} }
Attachments : {
client.send-request to rpc.caller;
server.receive-request to rpc.callee
}
}
53
Architectural Description Languages
• Acme
• Rapide
• UniCon
• Wright
• Aesop
• ArTek
• SADL
• Meta-H
54
Agenda
55
Software Architect
• Capability in abstract thinking
– And handling abstractions
– Envision the big picture
– Stay at the appropriate level of abstraction
• Communication
– Writing, presenting ideas
– Negotiating skill
ref: “The Software Architect”, Philippe Kruchten,

TC2 First Working IFIP Conference on Software Architectures,
KLUWER ACADEMIC PUBLISHERS, 1999
56
Software Architect
• Ability to handle ambiguities and contradictions
– Handle multiple, concurrent issues
– Adapt to changes
• Reevaluate priorities
– Strong conviction
• Understand the technology
– Not the details
– Ability to understand and review the technical artifacts
• Design, code, test artifacts etc
– Must have been a programmer, designer, leader in earlier lives!
• Understand the domain
– Need not be an expert
– Ability to understand and identify the problem and potential
57
Software Architect
• Expertise to be acquired
– Not solely by reading books
• Training is necessary
– But by doing projects
• Practical experience
• Learning from masters
58
Goals of Software Architect / Architecture
Team
• Defining the architectural drivers
• Defining the architecture of the system
• Assessing technical risks
• Working out risk mitigation strategies/approaches
• Maintaining the architectural integrity of the system
• Participation in project planning
• Proposing order and content of development iterations
• Consulting with design, implementation, and integration teams
• Assisting product marketing and future product definitions
ref: Applied Software Architecture

Hofmeister, Nord, Soni
59
Development Process
• Create the business case Problem
• Understand the domain requirements
– Functional and supplementary
• Propose an architecture
– Select a style
– Define the structure
Solution
• Using tradeoffs
• Represent the architecture
• Analyze or evaluate the architecture
• Design and Implement the system based on the
architecture Realization
• Verify and validate the implementation
60
Architect Guides the Entire Project!
Challenging job!
61
Summary
• Software Architecture
62
Enlightenment!
63
References
1. Mary Shaw and David Garlan,
Software Architecture. Perspectives on an Emerging Discipline, Prentice-Hall(1996)
2. Paul Clements and Linda Northrop
Software Architecture : An Executive Overview, Technical Report, Software Engineering
Institute, CMU/SEI-96-TR-003 (1996)
3. Len Bass, Paul Clements and Rick Kazman
Software Architecture in Practice, Addison-Wesley(2003)
4. Christine Hofmeister, Robert Nord and Dilip Soni
Applied Software Architecture, Addison-Wesley(2000)
5. Paul Clements, Rick Kazman and Marc Klein
Evaluating Software Architecture, Addison-Wesley, 2002.
6. Paul Clements, Rick Kazman and Mark Klein
Evaluating Software Architectures: Methods and Case Studies, Addison-Wesley,
2002
7. Clements et al.
Documenting Software Architectures: Views and Beyond, 2003
8. Phillipe Kruchten
The Rational Unified Process: An Introcution, Pearson Education Asia, 2006
9. IBM Rational Method Composer
A tool for process configuration providing standard libraries of various processes
64
sivakumars@ssn.edu.in
65

Session 1

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Session 1

Uploaded by

Copyright:

Available Formats

Software Architecture

That Blueprint is Software Architecture!

Ref: IBM Rational Unified Process

In general, architecture helps determine the

Are there standard

ref: Software Architecture in Practice

• Constraints – Design requirements

• Constraints – Implementation requirements

Architecture has the single largest

• Guides organizational structure

Makes you sleep peacefully!

A projection of a model, which

Views are projections of a model for a particular stakeholder

Logical View Implementation View

Process View Deployment View

Ref : Kruchten (1995)

Ref: “Applied Software Architecture”, Hofmeister, C. et al. (2000).

ref: “The Software Architect”, Philippe Kruchten,

ref: Applied Software Architecture

You might also like