CS 411 - Software Architecture Design Roots, Definitions and Rationale

1
CS 411 - Software Architecture DesignRoots,
Definitions and Rationale

• Bedir TekinerdoganBillkent University,
• Department of Computer Engineeringemail -
  bedir_at_cs.bilkent.edu.tr
• http//www.cs.bilkent.edu.tr/bedir/Phone
  (290)1258Room EA506

2
Table of Contents

• History of Structure in Software Engineering
• Definitions of Software Architecture
• Architecture in Software Development Life cycle
• Rationale for Software Architecture Design

3
Part I History of Structure in Software
Engineering

• Software Crisis
• Software Engineering
• Evolution of Structure concept in SE

4
Architecture is ...

• The underlying structure of things
• Buildings
• Vehicles
• Computers
• ...
• Software

5
Early Computers

• Evolved during the Second World War.
• Basically needed for mathematical calculations
  and code breaking.
• Setting switches and plugging cables into
  sockets.
• Von Neumann Architecture program set of
  instructions, stored in memory

www.computerhistory.org
6
First Programming Languages 1951-1960

• Machine language (written in binary), machine
  specific
• Assembly languages, symbolic instructions
• Use of a translator to translate the assembly
  language into machine language.
• Problem Concern Computing and algorithms
• Solution Concern Basic applications include
  calculations calculations are based on
  algorithms algorithm is a step-by-step process
  that manipulates data.

7
Fortran, ALGOL and LISP

• FORTRAN (FORmula TRANslator), 1957
• high-level language
• introduced variables, procedures, statement
  labels etc
• ALGOL 60 (ALGOrithmic Language), 1958
• Block structure, recursion, and a formal
  definition.
• ancestor of most contemporary languages
• LISP (LIST Processor), 1960
• symbolic processing for AI
• symbolic differentiation, integration and theorem
  verification

8
Evolution of applications

• More powerful computers
• transistor
• IC
• High Level Programming Languages
• Normal business started to use computer
• Need for data processing applications in business
• COBOL COmmon Business Oriented Language, 1960
• elaborate datastructures
• record type introduced for the first time

9
Abstract Data Types / Objects

• Simula 67
• An extension of Algol 60 for simulation of
  concurrent processes.
• Introduced the concept of classes and
  encapsulation forerunner of Smalltalk and C.

10
Early history of computing...

• 1940s First computers
• Problems Numerical/algorithmic applications
• Method
• Programming languages, Machine Languages,
  Assembly Language
• 1950s First programming languages
• Algol, Fortran, LISP, COBOL.
• 1960s
• Problems got more complex data intensive
  business applications

11
Software Crisis

• Software
• Late

12
Software Engineering
Software Development should be based on
ENGINEERING!
1968 NATO Conference on Software Engineering
13
Dijkstra Parnas Structure Matters

• Dijkstra, 1968
• ...Correct arrangement of the structure of
  software systems before simple programming...
• Parnas, 1972
• ...selected criteria for the decomposition of
  the system impact the structure of the programs
  and several design principles must be followed to
  provide a good structure...

Edsger Dijkstra 1930-2002
Focused on Structure of Programming...
14
Dijkstra - Layered Structures 1968

• Operating Systems
• Layered Structure
• Programs are grouped into layers
• Programs in one layer can only communicate with
  programs in adjoining layers
• Conceptual integrity
• Each layer has its own goal
• with easier development and maintenance

E.W. Dijkstra, The structure of
"THE"-multiprogramming system. Comm. ACM 11, 5
(May 1968), 341-346.
15
Parnas Design principles

• Information-hiding modules (1972)
• Identify design decisions that are likely to
  change
• Isolate these in separate modules (separation of
  concerns)
• Different design decisions might require
  different decompositions.
• Software Structures (1974)
• Hierarchical structures (stepwise refinement) in
  programs
• Program Families (1975)
• A program family is a set of programs for which
  it is profitable or useful to consider as a
  group.

D. Parnas, "On the Criteria to Be Used in
Decomposing Systems into Modules., Comm. ACM
15, 12 (December 1972), 1053-1058. 1972.
D. Parnas, On a Buzzword Hierarchical
Structure IFIP Congress 74. North Holland
Publishing Company, 1974 pp. 336-339
D. Parnas, On the design and development of
program families IEEE Trans. On SE., vol. SE-2,
pp.1-9, Mar. 1976
16
Structured Design Methods

• Aimed to develop structured programs
• By applying design principles
• Information hiding
• Modularization
• Stepwise refinement
• Etc

17
Object-Orientation

• In the beginning software was written without any
  structure
• data and procedures were separated
• data and procedures that belonged together were
  put into subsystems (modules)
• these subsystems were layered
• and finally objects encapsulated data for the
  sake of structure.

18
Structure in Software

• 1960s - Structured Programming
• Adopted into programming languages because its a
  better way to think about programming
• 1970s - Structured Design
• Methodology/guidelines for dividing programs into
  subroutines.
• 1980s Modular programming languages
• Modular (object-based) programming
• Grouping of sub-routines into modules with data.
• 1990s Towards Software Architectures
• Object-Oriented Analysis/Design/Programming
  started being commonly used
• Software Architecture Design

19
Structure in Software
APPROACH
PROBLEMS SOLVED
2010
Programming in-the-world - software architecture
Mega programs
2000
Programming in-the-large - object-oriented
design - CASE tools - libraries
Large, complex, distributed
1990
1980
Data intensive, business applications
1970
Programming in-the-small - information hiding,
modularization
1960
Programming any-which-way
Simple, algorithmic
1950
20
Summary on Structure in History

• Increased consciousness on structure of software
• Structure idea did not stop at programming level
  but moved up to design methods.
• This has finally culminated in Software
  Architecture
• Successfully applied in industry which have
  specific architecture design teams/divisions.
• Software Architecture is a logical step in the
  evolution of structure concept.
• Is one of the most fundamental concepts in
  software engineering.

21
Very intuitive notion of software architecture

• Software Architecture represents the gross level
  structure of a software system.
• Design Implementation
• Software Architecture Design

22
Software Architecture - Example
Software Architecture Design for Multi-User
Biological Pathway Knowledge Acquisition and
Inquiry Environment Fatih Akgul, Caglar Gunel,
Erhan Giral
23
Software Architecture - Example
Software Architecture Design for Distributed
Newsgroup System Ali Çakmak Duygu Uçar Eren
Aydin Tankut Baris Aktemur
24
Part II - Definitions

• What is a Software Architecture?

25
What is Software Architecture?

• Evolution of Software Architecture concept
• Resulted in different definitions in the history

26
Booch 1991

• The Logical and physical structure of a system,
  forged by all the strategic and tactical design
  decisions applied during development
• Architecture is high level structure of software
  system

27
Perry and Wolf 92

• We distinguish three different classes of
  architectural elements processing elements data
  elements and connection elements. The processing
  elements are those components that supply the
  transformation on the data elements the data
  elements are those that contain the information
  that is used and transformed the connecting
  elements (which at times may be either processing
  or data elements, or both) are the glue that
  holds the different pieces of the architecture
  together.
• explicitly considers the interpretation on the
  elements of software architecture

28
Garlan and Shaw 1993

• ...beyond the algorithms and data structures of
  the computation designing and specifying the
  overall system structure emerges as a new kind of
  problem. Structural issues include gross
  organization and global control structure
  protocols for communication, synchronization, and
  data access assignment of functionality to
  design elements physical distribution
  composition of design elements scaling and
  performance and selection among design
  alternatives. This is the software architecture
  level of design.
• This definition provides additional
  specializations of the structural issues.

29
Garlan 1995

• The structure of the components of a
  program/system, their interrelationships, and
  principles and guidelines governing their design
  and evolution over time.
• design information in the architectural
  specification

30
Bass et al 98

• 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.
• more than one structure and includes the behavior
  of the components as part of the architecture.
  The term component here is used as an abstraction
  of varying components.

31
General definition
Architecture Abstractions and their relations,
which form a concept.
relations
Architectures must have a well defined structure.
32
What is a concept?
Concept A well-established definition within a
given domain. A concept is an essential
abstraction, usable, andgenerally corresponds to
an inherently complexstructure and/or
behavior. An abstraction of an architecture can
also be an architecture (concept) thereby
allowing hierarchicalarchitectural structures.
33
Summary on Definitions

• Definition of Software Architecture Design has
  evolved together with technical developments
• Gross Structure
• Specialization on definition of components
• Different structures
• Different definitions but a common agreement on
• Architecture is structure
• including components
• and connections among these components
• Concept of software architecture is important

34
Part III Architecture in the Software
Development Life Cycle

• Problem Solving
• Architecture design and implementation

35
Engineering as Problem Solving
Problem
Software engineering
36
Software EngineeringProblem Solving
Phases
Problem
37
Example Student Registration System

• Application Student Registration System
• University consists of several departments. If
  students fulfill the requirements, students can
  enroll in the university. Every student can
  register/withdraw for/from a course.

38
Use Case Diagram
register for course
withdraw from course
enroll in university
39
Student Registration Class Diagram
40
States of a Student
EnrollInClass ( Add a Transcript )
AddCourse
Withdraw
41
Sequence Diagram Registering for Course
42
Example Java Implementation

• public class Student
• private String name
• private int id
• public String getName ()
• return name
• public void setName (String str)
• name str
• public int getId()
• return id
• public void setId(int i)

43
Software Architecture
44
Software Architecture Design Phase
Phases
Problem
45
Design, Realize and Test Architecture
Requirements Analysis
Software Architecture Design
Analysis Design
46
Design, Realize and Test Architecture
Requirements Analysis
....... ....... ....... .......
Software Architecture Design
Analysis Design
Implementation
public class Student private String
name private int id public String getName
() return name public void setName (String
str) name str public int getId() return id
public void setId(int i) id i
47
Software Architecture

• Architecture is at a higher abstraction level of
  software development than analysis and design.
• To comprehend the gross level structure of the
  system it is necessary to design the architecture
• Realizing architecture implies mapping it to
  detailed design.

48
Part IV Rationale for Software Architecture
49
Example Conveyor Line Sorting System

• Design the software for a conveyor sorting line
  system (CLSS) which sorts boxes moving along a
  conveyor line. Each box is identified by a bar
  code and is sorted into one of six bins at the
  end of the line. The boxes pass by a sorting
  station that contains a bar code reader and a PC.
  The sorting station PC is connected to a shunting
  mechanism that sorts the boxes into the bins.

50
Conveyor/Assembly Line
11000
1100011
1110011
0101111
Shunt
Sorting Station
51
Architecture Design CLSS
52
Abstract Specification

• Architecture represents a common high level
  abstract specification.
• Abstraction helps to cope with complexity
• Abstraction improves understanding of the
  software system.
• Question is how to define the right architectural
  abstractions.

--------------------------------------------------
------------C O D E-------------------------------
---------- --------------------
53
Abstract Specification
54
Stakeholder Communication

• Stakeholder is any person who has interest in the
  architecture, i.e. analyst, designers,
  implementers, managers, testers etc.
• Software architecture provides a common medium
  for communication among stakeholders
• This will improve understanding/ development and
  maintenance of the system.

55
Guides development process

• Architecture is explicit
• Focus on Architectural Components.
• Analyse and Design based on architectural
  components.
• Can predict performance

Software Architecture
56
Refining Architecture
57
Management of SE activities
58
Large Scale Reuse

• Architectural description can be reused to
  produce different systems.

59
Large Scale Reuse
60
Controls Impact of Change
P r o b l e m
P r o g r a m
Design
Software Architecture
Analysis
Implementation
Problem understanding
61
Controls Impact of Change
P r o g r a m
P r o b l e m
P r o b l e m 2
P r o g r a m 2
Requires changes to the analysis, design, and
program
Design
Software Architecture
Analysis
Implementation
Problem understanding
62
Control Impact of Change

• Architecture is at the higher abstraction level
• and includes the earliest design decisions
• Getting the right architecture will help to cope
  with impact of changes.

63
Rationale for Software Architecture

• Improved understanding because of a higher level
  abstract specification
• Guides construction since it embodies earliest
  design decisions
• Supports stakeholder communication
• Support for large-grained reuse
• Enables to evaluate system before it is
  implemented
• Controls impact of change
• Management of software development activities

64
End

• Questions