Informatics 43
Introduction to Software Engineering
Lecture 2
Duplication of course material for any commercial purpose without the explicit written
permission of the professor is prohibited.
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 1
Today’s lecture
•
•
•
•
Programming versus software engineering
Complexity, conformity, changeability, intangibility
Software architecture
Examples
•
Some slides adopted and adopted from “Software Architecture: Foundations,
Theory, & Practice” by Taylor, Medvidovic, and Dashofy
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 2
Today’s lecture
•
•
•
•
SDCL
Programming versus software engineering
Complexity, conformity, changeability, intangibility
Software architecture
Examples
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 3
Essential characteristics
• Software engineering concerns the development of large programs
• The central theme is mastering complexity
• The efficiency with which software is developed is of crucial
importance
• Software evolves
• Regular cooperation between people is an integral part of
programming-in-the-large
• The software has to support its users effectively
• Software engineering is a field in which members of one culture
create artifacts on behalf of members of another culture
• Software engineering is a balancing act
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 4
Programming versus software engineering
Small project
Large to huge project
You
Teams
Build what you want
Build what they want
One product
Family of products
Few sequential changes
Many parallel changes
Short-lived
Long-lived
Cheap
Costly
Small consequences
Large consequences
Programming
SDCL
Software Design and
Collaboration Laboratory
Software engineering
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 5
From programming to software engineering
• People
– who else would do the work?
– range from novice to very experienced
• Processes
– to organize and manage the efforts of individuals
– range from informal to very formal
• Tools
– to support the people and the processes
– range from simple to very advanced
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 6
People
• The single most important factor in the success/failure of a
product
• Scarce resource
– quality
– suitability
– cost
• Many different kinds of people
– managers
– programmers
– technical writers
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 7
Processes
• Essential to achieve a quality product
• Scarce resource
– quality
– suitability
– cost
• Many different kinds of processes
– bug tracking
– change approval
– quality assurance
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 8
Tools
• Needed to support people and processes
• Scarce resource
– quality
– suitability
– cost
• Many different kinds of tools
–
–
–
–
SDCL
drawing
analysis
project management
source code management
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 9
Today’s lecture
•
•
•
•
•
•
•
•
SDCL
Programming versus software engineering
Complexity, conformity, changeability, intangibility
Software architecture
Example #1: Linux
Example #2: iRADS
Example #3: HADOOP
Architectural styles
Principles of software engineering
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 10
Brooks – Mythical Man Month
• Accidental versus essential difficulties
• Accidental difficulties
–
–
–
–
people shortage
not using the right tools
wrong design choice
…
• Essential difficulties
–
–
–
–
SDCL
complexity
conformity
changeability
intangibility
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 11
Complexity
• No two software parts are alike
– if they are, they are abstracted away into one
• Complexity grows non-linearly with size
– e.g., it is impossible to enumerate all states of a program
– except perhaps “toy” programs
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 12
Conformity
• Software is required to conform to its
– operating environment
– hardware
• Often “last kid on block”
• Perceived as most conformable
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 13
Changeability
• Change originates with
– new applications, users, machines, standards, laws
– hardware problems
• Software is viewed as infinitely malleable
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 14
Intangibility
• Software is not embedded in space
– often no constraining physical laws
• No obvious representation
– e.g., familiar geometric shapes
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 15
Drastic consequences
• Deceased patients
– x-ray machine delivered very high doses because of a timing problem
in its control software
• Crashed planes
– software prevented pilots from performing emergency maneuvers
– software had similar codes for different airports
• Decreased national security
– NSA computers down for four days due to a “software problem”
Peter Neumann’s Risks Digest: http://catless.ncl.ac.uk/Risks
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 16
Today’s lecture
•
•
•
•
SDCL
Programming versus software engineering
Complexity, conformity, changeability, intangibility
Software architecture
Examples
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 17
Software architecture
Requirements
Code
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 18
Software architecture
Requirements
Code
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 19
An analogy to building architectures
• We all live in them
• (We think) We know how they are built
–
–
–
–
requirements
design (blueprints)
construction
use
• This is similar (though not identical) to how we build software
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 20
Parallels
• Design before build
• Satisfaction of customers’ needs
• Specialization of labor
• Multiple perspectives of the final product
• Intermediate points where plans and progress are reviewed
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 21
The architect
• A distinctive role and character in a project
• Very broad training
• Amasses and leverages extensive experience
• A keen sense of aesthetics
• Deep understanding of the domain
– properties of structures, materials, and environments
– needs of customers
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 22
Limitations of analogy
• Software serves a much broader range of purposes
• We know a lot about buildings, much less about software
• The nature of software is different from that of building
architecture
• Software is much more malleable than physical materials
• Software is a machine; a building is not
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 23
But still very real power of architecture
• Giving preeminence to architecture offers the potential for
–
–
–
–
–
–
intellectual control
conceptual integrity
effective basis for knowledge reuse
realizing experience, designs, and code
effective project communication
management of a set of variant systems
• Limited-term focus on architecture will not yield significant
benefits!
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 24
Defining software architecture
• A software system’s architecture is the set of principal design
decisions about the system
• Software architecture is the blueprint for a software system’s
construction and evolution
• Design decisions encompass every facet of the system under
development
–
–
–
–
SDCL
structure
behavior
interaction
non-functional properties
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 25
“Principal”
• “Principal” implies a degree of importance that grants a
design decision “architectural status”
– it implies that not all design decisions are architectural
– that is, they do not necessarily impact a system’s architecture
• How one defines “principal” will depend on what the
stakeholders define as the system goals
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 26
Architecture in action: WWW
• This is the Web
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 27
Architecture in action: WWW
• So is this
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 28
Architecture in action: WWW
• And this
29
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 29
WWW in a (Big) Nutshell
• The Web is a collection of resources, each of which has a
unique name known as a uniform resource locator, or “URL”
• Each resource denotes, informally, some information
• URI’s can be used to determine the identity of a machine on
the Internet, known as an origin server, where the value of
the resource may be ascertained
• Communication is initiated by clients, known as user agents,
who make requests of servers.
– Web browsers are common instances of user agents
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 30
WWW in a (big) nutshell (continued)
• Resources can be manipulated through their representations
– HTML is a very common representation language used on the Web
• All communication between user agents and origin servers
must be performed by a simple, generic protocol (HTTP),
which offers the command methods GET, POST, etc.
• All communication between user agents and origin servers
must be fully self-contained (so-called “stateless
interactions”)
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 31
WWW’s architecture
• Architecture of the Web is wholly separate from the code
• There is no single piece of code that implements the
architecture
• There are multiple pieces of code that implement the various
components of the architecture
– e.g., different Web browsers
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 32
WWW’s architecture (continued)
• Stylistic constraints of the Web’s architectural style are not
apparent in the code
– the effects of the constraints are evident in the Web
• One of the world’s most successful applications is only
understood adequately from an architectural vantage point
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 33
Today’s lecture
•
•
•
•
SDCL
Programming versus software engineering
Complexity, conformity, changeability, intangibility
Software architecture
Examples
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 34
Prescriptive versus descriptive architecture
• A system’s prescriptive architecture captures the design
decisions made prior to the system’s construction
– it is the as-conceived or as-intended architecture
• A system’s descriptive architecture describes how the system
has been built
– it is the as-implemented or as-realized architecture
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 35
Linux – prescriptive architecture
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 36
Linux – descriptive architecture
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 37
iRODS – prescriptive architecture
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 38
iRODS – descriptive architecture
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 39
HADOOP – prescriptive architecture
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 40
HADOOP – descriptive architecture
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 41
HADOOP + MapReduce
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 42
HADOOP – complete architecture
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 43
Gap
• A gap remains between the prescriptive architecture, which
concerns decisions, and the descriptive architecture, which
concerns programmatic elements
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 44
Assignment 2
• Will be out on Wednesday
SDCL
Software Design and
Collaboration Laboratory
Department of Informatics, UC Irvine
sdcl.ics.uci.edu 45