Transcript Software Systems Engineering Intro

Requirements
Analysis and
Design
Engineering
Southern Methodist University
CSE 7313
1
Module 3 – Problem Solving
2
Problem Solving
• Course not about programming
• Mainly about how to define a
problem for people to solve by
programming a computer
– must provide all the information that
programmers and interface designers
need to make a computer bring about
effects outside the computer
• This complete statement of the
problem is called requirements
3
Problem Solving
 Writing software requirements is a form of
communication between people
 All lot of stakeholders involved
people who desire effects from the
software
people who want to perform some task
people who design the machine
behavior
people who configure (program) the
machines
4
R
S
Interface design
documents
Pick up cargos
Haul cargos to
destinations
Not programming
Database schemas
subroutines
interfaces
Linked lists
Print reports
5
Introduction
 Goal of any kind of engineering is to give
people ability to do something they
currently can’t do
 Task of the engineer is to build the device
 To write a useful requirements document
we must understand what engineers to in
order to produce a design that meets the
requirements
6
Engineering
 Engineering is essentially bridging the
gap between requirements and available
materials
aeronautical; materials for flight
software engineer; configuring a
computer to perform tasks related to
information, transmitting information
and causing objects to behave in
accordance with specified rules
7
Materials of a Software
Engineer
 Materials are intangible
instructions that a computer is capable
of executing
subroutine libraries
high level programming languages
 Bridging the requirements/materials gap is
not easy
sponge for cleaning easy to see
dishwasher took many years
8
Bridging the Gap
 Once somebody figures out how to bridge
the gap successfully, the design can be
repeated and slightly verified to solve new
problems
9
How to bridge the gap
 Many theories on how to bridge the gap
 Functional decomposition
top-down design
stepwise decomposition
 Steps
engineer identifies function of the
system to be built
if function maps directly to available
parts, allocate function to those parts ->
done
10
Functional Decomposition
otherwise divide the function into
subfunction and repeat steps 2 and 3
until every subfunction is small enough
to map onto the smallest parts of the
design
 Divide and conquer approach
 Problem is that there are many different
ways to divide a high level function into
subfunctions and there is no way to tell if
these divisions are good until into lowest
levels of design
11
Problem solving and design
patterns
 Exhaustive list of all problem solving
techniques (order of decreasing
effectiveness)
Already knowing the solution
Already knowing the solution to a
similar problem
All other techniques
12
Problem solving and design
patterns
 As engineers we are not interested in
giving problems a sporting chance
 Engineering problems are so different
from each other that few of the ideas or
knowledge that enable you to solve one
problem will help you solve a problem
from a different field
 Completely generalized ideas are too
unfocused
13
How engineering really
works
 Engineers apply and slightly vary already
existing, time-tested designs
 Engineers engage in unstructured
exploration of new designs and new ways
to put old designs together
 Both types can occur on the same project
14
Design Patterns
 Despite the importance of standard
designs in all engineering fields, it has
mostly been left implicit
 People learn standard designs for bridges,
D.C. generators, brakes, etc
 What they do not learn is that standard
designs separates professional
engineering from tinkering
15
Design Patterns
 In software this standard design has
become to be know as a design pattern
 The word pattern emphasizes that the
design can be applied a million times over
without ever doing it the same way twice
a brick pattern varies little from
application to application
a suspension bridge pattern is a more
flexible idea that requires additional
intelligence and imagination to apply
16
Design Patterns
 Patterns were applied by Christopher
Alexander in town planning and
architecture
 Patterns found in towns and buildings
street café is a pattern
corner grocery is a pattern
dormer window
 Rich vocabulary of words allows you to
write well - rich vocabulary of design
patterns allows us to design well
17
Design Patterns
 A pattern is not a reusable component
a component is a physical object
two different instances are identical - both
are instances of the same design
a pattern is a reusable idea - no two
instances are quite the same
 The application of patterns is called
design or engineering; the creation of new
instances is called manufacturing
18
Why Software is Hard
 Early in the history of an engineering field,
practices tend to be unstructured
exploration instead of application of timetested ideas
 This is natural - in the early days there are
fewer time-tested ideas
 In the early days there is emphasis on
innovation - the field does not produce
reliable results
 Many untested ideas which often fail
19
Why Software is Hard
 Mature engineering fields
engineers spend most of their time
combining and making slight variations
to time-tested ideas
Solve problems from a well defined set
of problems
building a transformer
this is a standard design in electrical
engineering
ingenuity still required to solve
unexpected problems
20
Why Software is Hard
 Invention of entirely new designs still
continues
space shuttle tiles
 A large vocabulary of time tested ideas
makes for a systematic and reliable
engineering discipline
very few homes collapse from their own
weight
few transformers fail to meet
specification
21
Why Software is Hard
 Orderly engineering; application and
slight variation of time-tested design
patterns
 Exploratory engineering; unstructured
exploration of new kinds of designs
 Major reason software projects fail is
because there is still a large gap between
the system that the customer wants
delivered and the available time-tested
designs
22
Pattern Composition and
Decomposition
 Patterns in software engineering
sorting
searching
many types of data structures
parsing
rendering 3-D images
 Allow experienced programmers to make
design decisions at a higher level than
program code
23
Pattern Composition and
Decomposition
 Pattern decomposition; recognizing a
pattern that is built from smaller patterns
 Difference from function decomposition is
that the patterns have been put together
before
 Function composition is what led the
Wright brothers to succeed where others
failed
24
Pattern Composition and
Decomposition
 Structure of birds versus decomposing
flight into its subfunctions
 Each subfunction then implemented by
further decomposition
 But is this what they really did .. ?
25
Functional decomposition
of Wright brothers airplane
Subfunction
Implementation
Forward
propulsion
Four cylinder engine,
propellers
Lift
Wings
Steering
Rudder, bendable
wingtips
26
Functional decomposition
of Wright brothers airplane
Subfunction
Implementation
Up/down propulsion
?
East/west propulsion
?
North/south propulsion
?
27
Pattern Composition and
Decomposition
 Wright brothers used wings, an engine, a
propeller, rudder was because they had
those things
nobody had components that
implemented up/down propulsion,
east/west propulsion, etc
despite mathematical elegance, nobody
does this!
 If internal combustion engine did not
exist, they would not have deduced one!
28
Pattern Decomposition
 Most of the design came from imitation;
idea of wings came from birds
steering mechanism from observing the
way birds bend their wings to change
direction
engine designed to meet own needs
 Town planner wants to build a bridge to go
across the bay gives requirements to the
engineer who then decomposes the
problems into patterns (girders, etc)
29
Pattern Composition and
Decomposition
 Exploratory engineering works the other
way around
composing patterns
build a solution in search of a problem
early computers went this way
we’re still a long way from determining
everything we can do with a computer
 In orderly engineering pattern
decomposition is the rule
30
Pattern Composition and
Decomposition
 Architecture-driven project; starts with an
implementation idea and looks for ways to
extend it that provide new and
unanticipated benefits to the customer
 Requirements-driven project; starts with
well-defined benefits and draws upon
existing, proven implementation ideas
31