Transcript Balancing Domain Alternatives

CS 411 - Software
Architecture Design
Roots, Definitions and Rationale
Bedir Tekinerdogan
Billkent University,
Department of Computer Engineering
e:mail - [email protected]
http://www.cs.bilkent.edu.tr/~bedir/
Phone: (290)1258
Room: EA506
© Bedir Tekinerdogan
Table of Contents




History of Structure in Software Engineering
Definitions of Software Architecture
Architecture in Software Development Life cycle
Rationale for Software Architecture Design
© Bedir Tekinerdogan
2
Part I – History of Structure
in Software Engineering
Software Crisis
Software Engineering
Evolution of Structure concept in SE
© Bedir Tekinerdogan
Architecture is ...

The underlying structure of things:





Buildings
Vehicles
Computers
...
Software
© Bedir Tekinerdogan
4
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
© Bedir Tekinerdogan
5
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.
© Bedir Tekinerdogan
6
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
© Bedir Tekinerdogan
7
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


© Bedir Tekinerdogan
elaborate datastructures
record type introduced for the first time
8
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++.
© Bedir Tekinerdogan
9
Early history of computing...



1940s: First computers
Problems: Numerical/algorithmic applications
Method:


1950s: First programming languages


Programming languages, Machine Languages, Assembly Language
Algol, Fortran, LISP, COBOL.
1960s:

Problems got more complex: data intensive business applications…
‘Direct’ mapping of problem to solution,
No systematic method
Problems are simple, algorithmic
© Bedir Tekinerdogan
10
Software Crisis
Software
 Late

Over Budget

Low Quality
© Bedir Tekinerdogan
11
Software Engineering
Software Development
should be based on ENGINEERING!
1968: NATO Conference on Software Engineering
© Bedir Tekinerdogan
12
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...
© Bedir Tekinerdogan
13
Dijkstra - Layered Structures 1968


Operating Systems
Layered Structure



Conceptual integrity


Programs are grouped into layers
Programs in one layer can only
communicate with programs in
adjoining layers
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.
© Bedir Tekinerdogan
14
Parnas – Design principles

Information-hiding modules (1972)




Software Structures (1974)


Identify design decisions that are likely to change
Isolate these in separate modules (separation of concerns)
Different design decisions might require different decompositions.
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
© Bedir Tekinerdogan
15
Structured Design Methods


Aimed to develop structured programs
By applying design principles




Information hiding
Modularization
Stepwise refinement
Etc…
© Bedir Tekinerdogan
16
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.
© Bedir Tekinerdogan
17
Structure in Software

1960s - Structured Programming


1970s - Structured Design


Methodology/guidelines for dividing programs into subroutines.
1980s – Modular programming languages

Modular (object-based) programming


Adopted into programming languages because it’s a better way to
think about 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
© Bedir Tekinerdogan
18
Structure in Software
APPROACH
2010 Programming in-the-world
- software architecture
2000
Programming in-the-large
- object-oriented design
- CASE tools
1980 - libraries
1990
1970 Programming in-the-small
- information hiding, modularization
1960
1950 Programming any-which-way
© Bedir Tekinerdogan
PROBLEMS SOLVED
Mega programs
Large, complex, distributed
Data intensive,
business applications
Simple, algorithmic
19
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.
© Bedir Tekinerdogan
20
Very intuitive notion of software architecture



Software Architecture represents the gross level
structure of a software system.
Design : Implementation =
Software Architecture : Design
© Bedir Tekinerdogan
21
Software Architecture - Example
<<Concept>>
Database
Accesses
Software Architecture Design
for Multi-User
Biological Pathway Knowledge
Acquisition and Inquiry
Environment
Fatih Akgul,
Caglar Gunel,
Erhan Giral
<<Concept>>
<<Concept>>
Database
Manager
Uses
Ontology
Uses
<<Concept>>
Query
Manager
<<Concept>>
Network
Manager
Uses
<<Concept>>
User Manager
Connects Connects
© Bedir Tekinerdogan
Applies to
Adapts
<<Concept>>
Submission
Manager
Adapts
Connects
Uses
<<Concept>>
Editor
22
Software Architecture - Example
Software Architecture
Design for Distributed
Newsgroup System
Ali Çakmak
Duygu Uçar
Eren Aydın
Tankut Barış Aktemur
© Bedir Tekinerdogan
23
Part II - Definitions
What is a Software Architecture?
© Bedir Tekinerdogan
What is Software Architecture?


Evolution of Software Architecture concept
Resulted in different definitions in the history
© Bedir Tekinerdogan
25
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
© Bedir Tekinerdogan
26
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
© Bedir Tekinerdogan
27
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.
© Bedir Tekinerdogan
28
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
© Bedir Tekinerdogan
29
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.
© Bedir Tekinerdogan
30
General definition
Architecture:
Abstractions and their relations, which form a
concept.
abstractions
& relations
concept
Architectures must have a well defined
structure.
© Bedir Tekinerdogan
31
What is a concept?
Concept:
A well-established definition within a given domain.
A concept is an essential abstraction, usable, and
generally corresponds to an inherently complex
structure and/or behavior.
An abstraction of an architecture can also be an
architecture (concept) thereby allowing hierarchical
architectural structures.
© Bedir Tekinerdogan
32
Summary on Definitions

Definition of Software Architecture Design has
evolved together with technical developments




Different definitions but a common agreement on




Gross Structure
Specialization on definition of components
Different structures
Architecture is structure
including components
and connections among these components
Concept of software architecture is important
© Bedir Tekinerdogan
33
Part III –
Architecture in the Software
Development Life Cycle
Problem Solving
Architecture design and implementation
© Bedir Tekinerdogan
Engineering as Problem Solving
Problem
Software engineering
Solution
© Bedir Tekinerdogan
35
Software Engineering=Problem Solving
Phases
Problem
Requirements Analysis
What? (client)
Analysis
What? (domain)
Design
How? (Detailed)
Implementation
Testing
Do
Test
Solution
© Bedir Tekinerdogan
36
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.
© Bedir Tekinerdogan
37
Use Case Diagram
register for course
withdraw from
course
Student
enroll in university
© Bedir Tekinerdogan
38
Student Registration Class Diagram
© Bedir Tekinerdogan
39
States of a Student
Apply [ Must be accepted first ]
Enrolled
EnrollInClass ( Add a Transcript )
Withdraw
Registered
AddCourse
Graduate [ All courses must be completed ]
© Bedir Tekinerdogan
40
Sequence Diagram: Registering for Course
aStudent
theRegistrar
aSection
theTranscript
getSectionsFor:
return sections
enrollInSection:
takenCourse: prerequisite
takenCourse: prerequisite
state of prereq
have prereq
addStudent:
enrolled
© Bedir Tekinerdogan
enrolled
41
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)
{
id = i;
}
©}Bedir Tekinerdogan
42
Software Architecture
Where is
Architecture
Design?
© Bedir Tekinerdogan
43
Software Architecture
Design Phase
Phases
Problem
Requirements Analysis
What? (client)
Software Architecture
What? (domain, gross-level)
Analysis
What? (domain, arch. comp)
Design
Implementation
Testing
How? (Detailed)
Do
Test
Solution
© Bedir Tekinerdogan
44
Design, Realize and Test Architecture
Requirements Analysis
Design
Software Architecture Design
Evaluate (Test)
Realize (Implement)
Analysis & Design
© Bedir Tekinerdogan
45
Design, Realize and Test Architecture
Requirements Analysis
.......
.......
.......
.......
Software Architecture Design
aStudent
theRegistrar aSection theTranscript
getSectionsFor:
return sections
Analysis & Design
enrollInSecti
takenCourse:
on:prerequisite
have
prereq
state of prereq
takenCourse:
addStudent: prerequisite
enroll
ed
enrolled
Implementation
© Bedir Tekinerdogan
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; }
}
46
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.
© Bedir Tekinerdogan
47
Part IV –
Rationale for Software
Architecture
© Bedir Tekinerdogan
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.
© Bedir Tekinerdogan
49
Conveyor/Assembly Line
11000
1100011
1110011
0101111
Shunt
Sorting
Station
© Bedir Tekinerdogan
50
Architecture Design CLSS
Requirements Analysis
Software Architecture Design
Bar
Code
Reader
Actuator/
Shunt
Control
Bar
Code
Decoder
Sorter
Report
Formatting
Database
Analysis & Design
© Bedir Tekinerdogan
51
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.
Bar
Code
Reader
Actuator/
Shunt
Control
Bar
Code
Decoder
Sorter
Report
Formatting
Database
-------------------------------------------------------------C O D E---------------------------------------- -------------------© Bedir Tekinerdogan
52
Abstract Specification
carries
Engine
Chassis
carries
rotates
carries
Break
Wheels
stops
© Bedir Tekinerdogan
53
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.
© Bedir Tekinerdogan
/
54
Guides development process




Architecture is explicit
Focus on Architectural
Components.
Analyse and Design based
on architectural
components.
Can predict performance
/
Software
Architecture
aStudent
theRegistrar aSection theTranscript
getSectionsFor:
return sections
enrollInSecti
takenCourse:
on:prerequisite
have
prereq
state of prereq
takenCourse:
addStudent: prerequisite
enroll
ed
public class Student
{private String name;
private int id;
public String getName
()
return name}
public void setName
(String str){
name = str;}
public int getId()
{
enrolled
Analysis
© Bedir Tekinerdogan
Design
Implementation
55
Refining Architecture
Bar
Code
Reader
Actuator/
Shunt
Control
Bar
Code
Decoder
Sorter
Report
Formatting
Database
Sort
Algorithm
Comparison
Criteria
Updating
Range
© Bedir Tekinerdogan
56
Management of SE activities
Bar
Code
Reader
Actuator/
Shunt
Control
Bar
Code
Decoder
Sorter
Report
Formatting
Database
© Bedir Tekinerdogan
57
Large Scale Reuse

Architectural description can be reused to produce
different systems.
Bar
Code
Reader
Actuator/
Shunt
Control
Bar
Code
Decoder
Sorter
Report
Formatting
Database
Bar
Code
Reader
Actuator/
Shunt
Control
Bar
Code
Decoder
Sorter
Database
© Bedir Tekinerdogan
Report
Formatting
Bar
Code
Reader
Actuator/
Shunt
Control
Bar
Code
Decoder
Sorter
Database
Report
Formatting
Bar
Code
Reader
Actuator/
Shunt
Control
Bar
Code
Decoder
Sorter
Report
Formatting
Database
58
Large Scale Reuse
Car Architecture
carries
Engine
Chassis
carries
rotates
carries
Break
Wheels
stops
© Bedir Tekinerdogan
59
Controls Impact of Change
P
r
o
b
l
e
m
Problem
understanding
© Bedir Tekinerdogan
P
r
o
g
r
a
m
Software
Architecture
Analysis
Design
Implementation
60
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
Requires changes to the analysis,
and program
Problem
understanding
© Bedir Tekinerdogan
Software
Architecture
Analysis
Design
P
r
o
g
r
a
design,
m
2
Implementation
61
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.
© Bedir Tekinerdogan
62
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
© Bedir Tekinerdogan
63
End
Questions…
© Bedir Tekinerdogan