Software Architecture

Basics of Software Architecture
26-Aug-2010

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

9

ref:www.softforall.com

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
– Typically using a box-and-line diagram – Textual descriptions – Rarely formal
M1 C1

• 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

Now, What is Software Architecture?
• 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

Now, What is Software Architecture?
• 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 • 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
– Thus, it determines the structure of the software

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>> Card Reader (from System Services Layer)

<<subsystem>> ATM Network (from System Services Layer)

<<subsystem>> Customer Interface (from System Services Layer)

19

Arrangement of Structural Elements
<<subsystem>> ATM Network (from System Services Layer)

Are there standard ways of arrangement?
<<subsystem>> ATM (from System Services Layer)

Yes, next lecture discusses about them

<<subsystem>> Customer Interface (from System Services Layer)

20

Agenda
• • • • • • Software Architecture Definition Architectural Forces Role of Software Architecture Benefits of Software Architecture Representation of Architecture Role of Software Architect

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

• Architecture is the simplest solution balancing the forces

– How they influence architecture is explained subsequently

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

Delivers

Determines
System

Architectural Forces Functionality Technology Complexity Quality Skills Organization culture Process Business objectives
Architect

25

ref: Software Architecture in Practice Bass, Clements, Kazman

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

Architectural Requirements
• 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 Usability Availability etc Technology OS Compatibility with other software Design constraints

You can’t talk about these requirements without talking about functionality

• Constraints

27

Architectural Requirements
• 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 – The system shall be continuously available (aka 7 x 24) with 2 hours downtime for maintenance every week

Availability

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.
– An RDBMS will be used for persistence – The RDBMS for the first release will be DB2 V9 – All presentation logic will be written in Visual Basic .Net

Constraints – Design requirements

Constraints – Implementation requirements

28

Architectural Requirements
• 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

Architectural Requirements
• 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
• • • • • • Software Architecture Definition Architectural Forces Role of Software Architecture Benefits of Software Architecture Representation of Architecture Role of Software Architect

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
• • • • • • Software Architecture Definition Architectural Forces Role of Software Architecture Benefits of Software Architecture Representation of Architecture Role of Software Architect

37

Benefits of Architecture
• Communication among stakeholders
• Key design decisions communicated

– Different views communicate different perspectives – Integrity and quality ensured while allowing changes – Evolution easier – Resilient to changes

• Ensure a balance among forces and system integrity
• Enables system longevity

• Manage complexity

• Changes in domain • Changes in technology

– Divide and conquer

• Maximize reuse

• Decomposition • Encapsulation • Separation of concerns

– At component level – low granularity – At subsystem, pattern and framework level – high granularity

38

Benefits of Architecture
• Reduce cost
– Savings from reuse – Savings from optimal use of resources – Savings from better support and maintenance – Early abstractions enable measurements – Risks eliminated
• Schedule metrics • Development metrics

(contd)

• Predictability

• Testability

• Predictions easier

– System componentized

• Provides for early design decisions • Architecture defines constraints on implementation

• Better diagnostics, error detection through traceability

39

Benefits of Architecture
• Guides organizational structure
• Teams organized accordingly
» Inventory » General Ledger

(contd)

– Components used as development units
– Development team » ‘Business Component group’ » ‘UI group’ » ‘Security group’ » ‘Workflow group’ » etc – Testing team – CM team

• Makes change management easier • Provides common architecture for product lines • Helps in evolutionary development
Makes you sleep peacefully!
40

• Enables concurrent development of components

Agenda
• • • • • • Software Architecture Definition Architectural Forces Role of Software Architecture Benefits of Software Architecture Representation of Architecture Role of Software Architect

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 Complete description of a perspective

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
End-user Analysts/Designers Functionality Structure

Implementation View

Programmers Software management

Use-Case View Process View
System integrators Performance Scalability Throughput

Deployment View
System engineering System topology Delivery, installation 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
• • • • • • Software Architecture Definition Architectural Forces Role of Software Architecture Benefits of Software Architecture Representation of Architecture Role of Software Architect

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

56

ref: “The Software Architect”, Philippe Kruchten, TC2 First Working IFIP Conference on Software Architectures, KLUWER ACADEMIC PUBLISHERS, 1999

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 • Understand the domain requirements
– Functional and supplementary
Problem

• Propose an architecture
– Select a style – Define the structure
• Using tradeoffs Solution

• Represent the architecture • Analyze or evaluate the architecture • Design and Implement the system based on the architecture • Verify and validate the implementation

Realization

60

Architect Guides the Entire Project!
Challenging job!

61

Summary
• • • • • • Software Architecture Architectural Forces Role of Software Architecture Benefits of Software Architecture Representation of Architecture Role of Software Architect

62

Enlightenment!

63

References
1. Mary Shaw and David Garlan, 2. Paul Clements and Linda Northrop
Software Architecture. Perspectives on an Emerging Discipline, Prentice-Hall(1996) Software Architecture : An Executive Overview, Technical Report, Software Engineering Institute, CMU/SEI-96-TR-003 (1996) Software Architecture in Practice, Addison-Wesley(2003) Applied Software Architecture, Addison-Wesley(2000) Evaluating Software Architecture, Addison-Wesley, 2002. Evaluating Software Architectures: Methods and Case Studies, Addison-Wesley, 2002 Documenting Software Architectures: Views and Beyond, 2003 The Rational Unified Process: An Introcution, Pearson Education Asia, 2006 A tool for process configuration providing standard libraries of various processes

3. Len Bass, Paul Clements and Rick Kazman

4. Christine Hofmeister, Robert Nord and Dilip Soni 5. Paul Clements, Rick Kazman and Marc Klein

6. Paul Clements, Rick Kazman and Mark Klein
7. Clements et al.

8. Phillipe Kruchten

9. IBM Rational Method Composer

64

sivakumars@ssn.edu.in

65

Sign up to vote on this title
UsefulNot useful