ECE362– Principles of Design
The System Engineering Process
Systems
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
1
Unit Overview
•
•
•
•
The systems challenge
System concepts and terms
Diagrams for systems
Actors, boundaries, interfaces
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
2
>>The Systems Challenge<<
The Man-Made World Is Increasingly Populated by Systems
• Transportation, Energy & Power
Systems
• Manufacturing, Construction
Systems
• Telecommunication Networks
• Man-Made Biological, Health, and
Personal Care Systems
• Facility, Properties
• Business Processes
• Other Man-Made and Natural
Systems
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
3
>>The Systems Challenge<<
These Systems Are Becoming More Complex
• Under pressure of demand & competition
• Enabled by progress in technology
• Becoming more complex at exponentially
growing rates
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
4
>>The Systems Challenge<<
The Growth Of Systems Complexity Eventually Can Outpace
Human Ability To:
•
•
•
•
•
•
Describe
Predict
Manage
Monitor
Configure
Evolve
•
•
•
•
•
•
Understand
Install
Operate
Repair
Maintain
Account For
•
•
•
•
•
•
Communicate About
Design and Implement
Manufacture
Diagnose
Control
Maintain Security Of
Those Systems must be produced . . .
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
5
>>The Systems Challenge<<
. . . At Least Within Reasonable:
• Time
• Cost
• Effort
• Sense of Security from Risk
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
6
Systematica Metaclass
The system perspective
• A System is a collection of interacting Components :
Interaction
Relationships
System
Components
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
7
What does “interact” mean?
• Components are said to interact if one one component
can impact the state of another.
• Components that do not impact each others’ states are
said to be isolated or non-interacting.
Interacting
Interactions Impact
Component States
System
Non-interacting
Components
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
8
What does “state” mean?
• The state of a component helps determine its externally
visible future interactive behavior.
• States are values of component state variables, such as:
•
•
•
•
•
•
•
Temperature, Pressure, Density
Position, Velocity, Acceleration
Happiness, Frustration, Satisfaction
Profitability
Voltage, Current
Asleep, Awake
Empty, Full
Components and systems have states.
System
Components
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
9
Systems may use any technology
•
•
•
•
•
•
•
Mechanical
Electronic
Software
Chemical
Thermodynamic
Human organizations
Biological
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
10
Example system
• System: Semi-trailer truck hauling freight
• Components: engine, power train, suspension,
lubrication system, fuel system, braking system,
electrical system, cab, trailer, navigation system,
communication system, software modules
• Interactions: mechanical support, electrical power
dependency, control interaction, mechanical drive,
thermal interaction
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
11
Example system
• System: Telecommunication services system
• Components: telephones, modems, workstations,
transmission links, circuits, switches, base stations,
communication sessions, software, customer
requests, billing systems, customer analysts
• Interactions: electrical & optical physical
interactions, symbolic trunk status signaling,
mechanical mounting support, power dependency,
fault propagation
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
12
Subsystems
• A Component can itself be a System
• This just means the Component has Components.
• This makes it a Subsystem of the first system.
• This can continue indefinitely.
• Where does it stop?
System
Subsystem
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
13
Where does it stop?
• It does not stop — we do!
• These are modeling constructs—ideas in our heads.
• We are using the System Perspective:
• How we have chosen to think about a system.
System
Subsystem
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
14
Is everything a system?
• Is a rock a system?
– Does it have parts? Interactions?
– If you are a geologist, a rock is a system:
• Strata, crystals, chemical interactions, pressures
– But, if you are using the rock in your slingshot,
this is not useful to know!
– Different people need different models for
different purposes
– Views of models
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
15
What to model?
• In model based systems engineering, it is
not enough for a model to be correct:
– We also have to ask if a model is useful to us.
– We only need to model what is useful, to sort
out requirements, plan designs, communicate
specifications, verify behavior, etc.
– There is a tendency of new modelers to model
too much, to include too much detail …. so
watch out!
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
16
The System Perspective
• Some definitions of the concept of system include not only:
– that there are components,
– and that there is a framework of interaction relationships,
• but also these additions:
– that a system exists for a purpose and has a body of rules about it.
Interaction
Relationships
System
Components
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
17
The System Perspective
• Systematica formally models intelligence and the actual management
of systems, including both man-made and natural systems:
– So, we consider ideas such as “purpose” and “rules” to be part of other
(extended) systems that we will model later in this workshop, including use of
other Metaclasses.
– Thus, we only need to remember that a system is a collection of components and
their interaction relationships:
Interaction
Relationships
System
Components
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
18
Naming and defining systems
• Systems have names and definitions:
– System name: a brief noun phrase
– System definition: one or a few sentences
• Example:
– System name: Acme Model 17 Lawnmower
– System definition: The lawnmower product model sold by
Acme Lawnmower Company for mid-range commercial
applications.
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
19
Logical Systems
• A Logical System is a system identified based solely upon its
required functionality (its behavior as seen by external systems
interacting with it), and not based upon how it achieves that
functionality internally or its identity or physical make-up.
Environment
System
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
20
Logical Systems
• Logical Systems are typically named and defined without
reference to proper names (product, people, organization
names). They are typically defined without reference to their
physical composition (unless--in a few cases--this is a part of
the externally required behavior). General name for a TYPE of
system.
Environment
System
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
21
Logical Systems
• Example of Logical System:
– Engine System: An Engine System converts atmospheric air
and chemical fuel into rotating mechanical power for use by
other machine subsystems.
Environment
System
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
22
Physical Systems
• A Physical System is a system defined based upon its
physical identify or physical composition. Physical
Systems may be given proper names, such as names
of commercial products, corporate systems, people,
organizations, buildings, etc., i.e. a SPECIFIC system.
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
23
Physical Systems
• Examples of Physical Systems:
– Model 3406 Engine
– Building 407
– Program Module 1750
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
24
Physical and Logical Systems
• A Logical System is equivalent to a functional role.
• Physical Systems may be assigned responsibilities to
perform roles that are Logical Systems.
Example of Logical System:
Engine System: An Engine System
converts atmospheric air and
chemical fuel into rotating
mechanical power for use by other
machine subsystems.
Example of Physical Systems:
Model 3406 Engine: The Engine
System sold by Caterpillar Inc.
into the mid-range industrial
market.
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
25
Physical and Logical Systems
• What is are examples of RHIT ECE physical systems?
–
–
–
–
ECE 300 Course
ECE 320 Course
ECE 340 Course
ECE 360 Course
• What are example RHIT ECE logical systems?
–
–
–
–
Communications systems sequence
Control systems sequence
Electromagnetics sequence
Design sequence
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
26
System diagrams
• Formal diagram notation:
– UML subset--UML class/object diagrams
• Frequently used system diagrams:
–
–
–
–
System environment diagram
System domain diagram
System logical architecture diagram
System physical architecture diagram (physical
deployment diagram)
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
27
System diagrams
• System environment diagram: To illustrate
the systems (called “actors”) outside a
“subject system”, with which it interacts.
• System domain diagram: To illustrate the
important relationships between the actors
for a subject system (domain knowledge).
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
28
Actors, boundaries, interfaces
• Actors: The systems external to a subject system, with
which it directly interacts.
• System Boundaries: The set of all actors for a subject
system constitutes its formal boundary. This is often
informally illustrated with a line boundary dividing the
system from its environment:
Environment
System
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
29
Actors, boundaries, interfaces
• System Interfaces: We will formally define
interfaces in a later unit, but show their
graphical appearance for now.
Interfaces
Environment
System
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
30
States
• A State is a system condition, situation, or mode, that has
existence for a length of time. The state of a system
determines in part its future behavior.
• The time history of states of systems can be described using
“trajectories” of states:
– finite state machines, or
– continuous paths in phase space.
State transition diagrams, or
(UML) state charts, can be
used to graphically describe
finite state machines.
State B
causal event 1
causal event 2
State C
State A
causal event 3
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
31
States
• State transitions are graphically illustrated links indicating
the passage of a system from one state to another.
• Events are occurrences in time.
• Events can be modeled as the cause of state transitions, by
labeling state transition lines with event names.
Event Name
State B
causal event 2
State Transition
causal event 1
State
State C
State A
causal event 3
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
32
Lawn mower example
lawnmower started
Starting
Servicing
service complete
Idling
disengage mowing
service request
received
start request received
Shut Down
Normal Mowing
engage
mowing
shut down initiated
normal shut down completed
Shutting Down
overheat recovery complete
overheated shutdown completed
Overheat Recovering
Lawnmower State
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
33
Organizing functions with states
• Functions can be associated with states.
– This is a way to indicate what functional
interactions are required to occur during certain
situations (that is, “when” they should occur in
time)
– This is a way to connect the (software
engineering) “use case method” to state and
function modeling techniques
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
34
Lawnmower example
Starting
Functions:
1. Start (w/i 10 seconds of turning
key)
2.Check Starting Interlocks (blades
must be disengaged)
3. Noise control (conform to ASPE
102.3 noise guidelines)
4.Emission control (conform to EPA
11.2 emission guidelines)
Mowing
Functions:
1.Cut grass (to operator
determined length)
2. Noise control (conform
to ASPE 102.3 noise
guidelines)
4.Emission control
(conform to EPA 11.2
emission guidelines)
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
Shutting Down
Functions:
1. Disengage blades
2. Shut down engine
35
ECE362 Principles of Design
The System Engineering Process
Requirements
Environment
System
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
36
Requirements Overview
• This unit overlaps and utilizes the ideas of the previous
units, to assemble the metaclasses into requirements
supporting structures, emphasizing the HLR Process.
• Content:
–
–
–
–
–
Requirements versus design
High level requirements (HLR) process
Detail level requirements (DLR) process
Analysis: decomposition of functions, states, systems
Assembling specification documents
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
37
Requirements-design iteration
Available
Technologies
Customer/Market
Needs
Design
Specification
(“Design”)
Requirements
Specification
(“Analysis”)
design impacts
requirement structure
refinement
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
refinement
38
Engineering processes
• This section will particularly focus on
model-based methodology for representing
high level requirements and high level
design frameworks.
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
39
Requirements (or PDS)
• Statements at external boundary of subject system
• What we want the system to be or do
Environment
System
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
40
Design
• Statements about internal physical components
and their interaction relationships
• How we are going to meet requirements
Environment
System
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
41
Interfaces
• Connect internal components to external
components or actors
• Help us group attributes and behaviors seen
externally
Environment
System
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
42
Inside vs. outside
Requirement statement
Design statement
Detailed design statement
Detailed requirement statement
More detailed
requirement Requirements
statement
Environment
Design
More detailed
Interfaces design statement
System
Detail does not equal design
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
43
Inside vs. outside, continued
• Reference boundaries
• One person’s design is
another person’s requirement
Environment
System
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
44
An SE benefits “sweet spot”
• The High Level Requirements (HLR) and High Level Design
(HLD) processes require less time and effort than their detailed
counterparts.
– However, there is typically a very high return on this investment.
• Many organizations utilize extensive detailed specifications, but
don’t have HLR and HLD specifications.
– This means that there is not a unifying framework structure, shared
mentally by all concerned, that simplifies and organizes the detailed
specifications.
– HLR/HLD is a “sweet spot” in the SE process, because it can rapidly
begin digging an organization out of problems caused by this lack.
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
45
Generic HLR Process
• Generic (unconfigured) HLR Processes:
–
–
–
–
–
–
–
–
Identify Stakeholder (Customer) Needs Process
Refer to process framework
Identify System Environment Process
drawings in handouts.
Identify Features, Services Process
Identify Use Cases Process
Identify Functions Process
Identify Scenarios Process
Analyze Logical Architecture Process
Repository and Specification Assembly Process
(Validation and verification are associated with most of these processes)
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
46
Identify stakeholder needs
• Stakeholders are people or organizations with an
interest (stake) in the system being specified:
–
–
–
–
–
–
–
Customers
Users
Operators
Maintainers
Company Owners
Regulators
Others
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
47
Identify system environment
• System environment diagram:
– Subject System--system whose
requirements are to be
specified
– Actors--interacting systems
external to the Subject System
• Boundary defines system by
defining what it is not--listing
the external interacting actors
• Often harder than it looks:
– Often skipped as “obvious”
– Later source of confusion
Actor
Actor
Actor
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
Actor
Subject
System
Actor
48
Identify system environment
• Domain diagram identifies
relationships between
actors that are important to
system requirements
• Explicitly models “domain
knowledge” about the
environment
• Establishes the semantics
of the subject system
specification to follow
Actor
Actor
Actor
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
Actor
Subject
System
Actor
49
ECE362 – Principles of Design
The System Engineering Process
High Level Design
Environment
System
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
61
Unit Overview
•
•
•
•
•
•
Inside versus outside
Design decomposition, synthesis
High level design is physical architecture
Tracing requirements to design
Detail design
Host Company standard design architectural
patterns
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
62
Inside versus outside
Requirements
• Statements at the external boundary
– What we want the system to be or do, seen externally
Environment
System
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
63
Inside versus outside
Design
• Statements about internal physical components
and their interaction relationships
– How we are going to meet requirements
Environment
System
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
64
Inside versus outside
Inside versus outside
Requirement statement
Design statement
Detailed design statement
Detailed requirement statement
More detailed
requirement Requirements
statement
Environment
Design
More detailed
Interfaces design statement
I
I
System
Detail does not equal design
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
65
Inside versus outside
Inside vs. outside, continued
• Reference boundaries
• One person’s design is
another person’s requirement
Environment
System
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
66
Inside versus Outside
In the following sections, we will refine our
understanding of the meaning of “inside”
and “outside”, by considering:
– System boundaries and interiors (“who”)
– Function boundaries and interiors (“what”)
– State boundaries and interiors (“when”)
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
67
Uniform bookkeeping language
• There is a tendency to record designs in a different
language from that used to express requirements.
– In particular, to record designs in technology-specific
languages
• This causes problems of communication and
understanding across groups and job functions.
– Technology-specific language can cloud the structure of a
design, and obscure its connection to requirements.
• Remember, what is a design for one person is a
requirement for another, so language ought not shift.
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
68
Uniform bookkeeping language
• A big surprise: High level designs can be recorded in exactly the
same language as requirements:
– Who: who are the internal components?
– What: what are the functional interactions between these components?
– When: when do these interactions occur?
• This is the same language that expressed interactions of the
subject system with its external environment/actors.
• This improves communication and understanding.
• In particular, it makes tracing external requirements to internal
architecture much easier--improving everyone’s understanding.
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
69
Uniform bookkeeping language
• This does not prevent us from recording detail designs in
technology-specific languages--and we should do so; e.g.,
–
–
–
–
electronic schematics
program design
mechanical drawings
hydraulic schematics
• But, it means that each such design should have its high level
design (physical architecture) recorded in the uniform language
of system engineering.
– This expresses high level organization as a framework for later detail
design, and across different technologies that must be integrated.
– It connects design to the requirements it supports.
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
70
Design Decomposition
• System decomposition divides a system into
sub-systems:
– dividing who does things; pulls apart systems
• Functional decomposition divides a function into
sub-functions:
– dividing what gets done; pulls apart functions
• State decomposition divides a state into
sub-states:
– dividing when things happen; pulls apart time
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
71
Function Allocation
• Function Allocation allocates the “whats” to the
“whos” and “whens”:
– which sub-systems perform which function roles (who)
– in which sub-states functions are to occur (when)
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
72
Decomposition: Synthesis and Analysis
• There are infinitely many ways to divide
and allocate these.
• This division process is synthesis--often a
creative act.
– May be viewed as a kind of unfolding of the
structure of the system, in three (or more)
dimensions.
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
73
Decomposition: Synthesis vs. Analysis
We check potential solutions by analysis, to see if they
meet requirements.
Available
Technologies
Customer/Market
Needs
Requirements
Specification
(“Analysis”)
Design
Specification
(“Design”)
design impacts
requirement structure
refinement
refinement
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
74
Synthesis
• Synthesis is challenging when there is no familiar
design pattern (decomposition) that satisfies the given
requirements.
• Known patterns of architecture, or even known useful
components, can help this process.
– This can include analogy
• A family pattern of architecture for the subject system
can help even more:
– Changes the problem from synthesis to re-use, configuration,
and analysis
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
75
Synthesis methods
• More synthesis methods become available constantly:
–
–
–
–
–
–
Design for Six Sigma (DFSS) / IDDOV
Robust Design™, Taguchi Methods™
TRIZ™
Technology specific synthesis methods and tools
Toolbox of design patterns known to work
Legacy architecture and available components
• We are often not free to synthesize “clean sheet”:
– Legacy architecture, available components, existing
manufacturing and support frameworks are constraints
– Incremental evolution and punctuated equilibrium
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
76
Synthesis methods
• While differing in specifics, all these methods have same goals:
– Establish a set of internal physical subsystems and their organizing
framework of interactions
– Allocation of external interactions (functional requirements) to them
– Optimization of trade-offs to meet various objectives and constraints
• So, even though different methods may produce different design
solutions, the form of the information they produce is the same:
– The high level design of the system
– And allocation of requirements onto that architecture
Environment
System
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
77
Functional analysis vs. synthesis
• The term “analysis” is used in two different ways:
– Requirements analysis (or functional analysis):
• Analyzes the functional requirements of a system,
decomposing them into logical architecture that is still short of
a design, but begins to hint at a design.
• This is the logical architecture discussed in the Requirements
unit.
– Analysis of design:
• After a design has been synthesized, this kind of analysis
studies the characteristics of that design
– e.g., by simulation, mathematics, reasoning, constructing
prototypes, etc.
• These are certainly not the same thing!
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
78
Functional requirements
• Functional requirements are the relationship between
system inputs and system outputs :
– In linear systems, this reduces to the system’s transfer function.
– Most systems aren’t linear, but the general statement still holds for
all of them.
– This relationship is therefore encoded in words, tables, graphs,
mathematics, fuzzy statements, and other forms.
– But, it is still the formal relationship of inputs to outputs:
Input 1
Actor A
Actor B
Output X
Output Y
Subject System
Input 3
Actor C
Input 2
Domain Interaction
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
79
Example: PID Controller (proportional, integral, derivative)
– The diagram expresses the external mathematical relationships
of inputs and outputs—equivalent to a differential equation.
– But, this does not say whether the result is to be obtained by
allocation onto analog electronics, a DSP chip, a mechanical
Bush Differential Analyzer, a block oriented simulator, nor the
order of differentiation and integration around the loop.
– It expresses external requirements, not internal design.
Subject System
Proportional
K1
Operator
Differentiator
+
-
K2 * S
+
Controlled
Plant
Integrator
K3 / S
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
80
Implications for creative design solutions
• “Thinking outside the box” has come to mean thinking of solutions to
requirements that are outside of expected paradigms.
• Suppose instead that you let “the box” stand for the boundary of the
Subject System.
• If you draw a logical architecture inside the box, you are really
expressing a way of thinking about the external functional
relationships.
• Different decompositions suggest different design solutions when these
are allocated onto physical components.
• So, you can “think outside the box” (think about external relationships)
by drawing inside the box!
Subject System
Input 1
Actor A
Output X
Logical
Role L
Logical
Role M
Output Y
Input 3
Actor C
Logical Role K
Actor B
Input 2
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
Domain Interaction
81
Functional Decomposition
Functions are pulled apart (decomposed) into sub-functions
for different reasons:
– Design Reasons:
• Creating algorithms to obtain functional results: Allocation of sub-functions to
different states in time.
• Allocation of sub-functions to different system components responsible for
performing them
• Allocation of responsibility for different sub-functions to different engineers
– Non-Design Reasons (during Requirements phase):
• Explanatory: function is too complex to understand/communicate well
• Part of the function is a common requirement to be reused in other functions
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
82
“Pulling Apart” Requirements Into Functional Components
Functional Decomposition
Function
• Functions can be “pulled
apart” into Sub-functions
• Not all functional
decomposition is for design. Actor
(Recall decomposition
of functions in the analysis
process.)
Actor
Function
Actor
Internal View
Component
Subject
System
Sub-Function
• Internal view components
connect sub-functions
There are many different ways to
decompose the same Function
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
83
Functional Decomposition
Function: Calling
Function
• Sub-functions are
“contained in” Functions
• Functions are “composed
Actor
of” sub-functions
Actor
Actor
• Function.Subfunction
Sub-Function
– Calling.Ringing
Subject
System
– Loading.Lifting
• This is a containment hierarchy
• The same function can be contained in more than one function
(re-used as a requirement)
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
84
System Decomposition: “Pulling Apart” Systems
Function
Synthesis of Design Components:
–
–
–
The Subject System is “pulled apart”
into interacting design components
These are assigned to implement the
sub-functions
This is design decomposition
Actor
Function
–
There are infinitely may
different ways to pull the
same system apart into
design components
Allocation of Functions:
–
–
–
Individual roles of
functions are allocated to
design components
The roles are the named
diamond corner connectors
A single role is only
assigned to one component
Actor
Actor
Roles
Subject System
Sub-Systems
(Components)
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
Subject System
85
Allocation of Function Roles
–
–
–
–
–
–
A single role is only assigned to one component
A single function may have its multiple roles
allocated across multiple components
• In this case, the components interact
Or, the function may have all its roles assigned to a
single component
• In this case, the function is internal to the
Actor
component--not visible to components
with which it interacts
One component can implement more than
one role, and more than one function.
All this may revise our original
functional decomposition
Even though we drew the Function diamond
outside the Subject System, its implementing subfunctions are all allocated to components internal to
the Subject System
Function
Actor
Function
Actor
Roles
Subject System
External Roles:
–
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
Sub-function roles associated with Function
external roles connect to external Actors
86
State Decomposition: “Pulling Apart” Time
Function
•
•
•
•
•
•
We started this whole process with a single State, that
was a Use Case (Situation) for the Subject System.
Our original Function(s) described outcome
requirement(s) that must be met in that Use Case
(State).
The Function was decomposed into Subfunctions, and allocated to design components.
That design may also specify an
“algorithm”--that the sub-functions be
allocated to different sequential steps over
time to construct the function outcome.
This “pulls apart” the sub-functions in time
These new steps describe a state machine of
sub-states of the original Use Case state.
Actor
Function
Actor
Actor
Sub-Function
Subject System
Original Use Case State
Original Use Case State
Substate 1
Substate 2
Substate 3
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
87
State Decomposition: “Pulling Apart” Time
•
There are infinitely many different ways to “pull
apart” the original Use Case state into sub-states.
•
This may include concurrent state machines that
communicate by events.
Function
Actor
Original Use Case State
Function
Actor
Actor
Substate 1
Substate 2
Sub-Function
Substate 3
Subject System
Original Use Case State
Substate 4
Substate 5
Original Use Case State
Substate 1
Substate 2
Original Use Case State
Substate 1
Substate 2
Substate 3
Substate 3
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
88
State Decomposition: “Pulling Apart” Time
Allocation of functions to states:
• Remember that the original
State was itself a Use Case for
the whole Subject System.
• Each new sub-state is now
itself a Use Case (Situation)
requirement on an internal
design component.
• So, we have “pulled apart” the
original Use Case state into a
set of related sub-state use
cases--a decomposition in time
coordinated with the
decomposition of functions and
the decomposition of the
system.
Function
Actor
Function
Actor
Actor
Sub-Function
Subject System
Original Use Case State
Substate 1
Substate 2
Function A
Substate 3
Function B, C
Function D
Function E
Substate 4
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
Substate 5
89
Repeating the Cycle
• Since we have new use cases (sub-states) for the new
functions (sub-functions) and new (internal design)
components, we can repeat the cycle again, beginning with
use case requirements on the new components.
• This decomposition cycle repeats until we reach “small
enough” components that we don’t have to design them.
• This results in a containment hierarchy of:
– Use Cases (sub-state containment hierarchy)
– Functions (sub-function containment hierarchy)
– Components (component containment hierarchy)
• Don’t forget that this containment hierarchy is not the
same as the class hierarchy--which can also exist for each.
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
90
High Level Design Is Architecture
• Architecture is a listing of a system’s major
components and relationships
• Simple patterns to reduce complexity
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
91
Architecture: One Perspective
“Have you ever looked at a modern airplane? Have you followed from year to year the
evolution of its lines? Have you even thought, not only about the airplane but about
whatever Man builds, that all of Man’s industrial efforts, all his computations and
calculations, all the nights spent over working draughts and blueprints, invariably
culminate in the production of a thing whose sole and guiding principle is the ultimate
principle of simplicity? In anything at all, perfection is finally attained not when there is
no longer anything to add, but when there is no longer anything to take away, when a body
has been stripped down to its nakedness. Startling as it is that all visible evidence of
invention should have been refined out of (the airplane) and that there should be delivered
to us an object as natural as a pebble polished by the waves, it is equally wonderful that he
who uses this instrument should be able to forget that it is a machine. And thus, the
realities of Nature resume their pride of place. It is not with metal that the pilot is in
contact. Contrary to the vulgar illusion, it is thanks to the metal, and by virtue of it, that
the pilot rediscovers Nature. The machine does not isolate Man from the great problems
of Nature, but plunges him more deeply into them.”
- Antoine de Saint-Exupery, “Wind, Sand, and Stars”
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
92
Architecture: Another Perspective
“Form ever follows function.”
- Louis Sullivan
(Building architect, father of the skyscraper,
teacher of Frank Lloyd Wright.)
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
93
Types of architecture
• A single system has multiple architectures.
• Each architecture is a different view of what
is considered to be the major components
and relationships of a system.
• Each view is from a different perspective:
– Example: Architecture of a building, viewed by
occupant, electrical/mechanical contractor, and
janitorial services contractor.
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
94
Types of architecture
• Examples of types of architecture:
–
–
–
–
–
–
–
Physical architecture
Logical architecture
Manufacturing architecture
Shipping and storage architecture
Service, maintenance, support architecture
Embedded intelligence architecture
Project architecture
• “Views of Systems”
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
95
Architecture
• These different architectures are not
independent of each other.
• When they are treated as independent,
problems follow:
– Conflicts between Engineering, Manufacturing,
Service, Marketing, etc.
• Different architectural views can be resolved
through Correlation of Architectures.
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
96
Correlation and Tracing
• Correlation, or tracing, relates different
architectural views to each other.
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
97
Detail Design
• Decomposition is repeated in successive stages
• Detail Design follows High Level Design
• Technology-specific aspects appear:
–
–
–
–
Electronic parts
Software modules
Mechanical components
etc.
• Where system engineering meets technology specific
engineering disciplines
– The transition in the Systems Engineering “Vee” from systems
engineering to discipline-specific engineering.
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
98
Systematica, Gestalt Rules, Return on Variation are trademarks of System Sciences, LLC.
Copyright © 2003, International Centers for Telecommunication Technology, Inc.
99