Chapter Three
Sw architecture FBS: Pt1 Real2Design Object
SW ARCH FBS: PT1
REAL2DSGN OBJECT
Module: eBook chapter w/practice
CZ3003 Software System Analysis and Design
by Kevin Anthony Jones
26 May 17
2 of 51
Foreword
(Ch3 Sw arch structure & behaviour, Pt1 D&R Object)
Objective of this lesson is to build new understanding in student for
initial architecture of sw system and its design objects’ structure and
behaviour.
Problem (in reqrs stage), solved by architect’s design (in design stage)
that is implemented and deployed. Architecture is high-level specification
of that solution (sw system) subsequently modeled by architecture diagram.
Architecture comprised of components joined by connectors, altogether
modeling structure, behaviour, and function of sw system. Component is
design object that can represent any real object in sw system. Component
is appreciated in sw system as Façade design pattern for realization of
info hiding in system. Connector directs flow of control and data between
components; eg., comms device, network.
Note: Modeling languages ignored in this lesson; craft in simplest way.
This lesson recalls architecture, structure, behaviour, software components, and Façade (from previous courses 1006, 2002, and 2006).
This lesson ends with a practice case study; let’s begin.
26 May 17
3 of 16
CZ3003
Today’s lesson is organized into …
1. Foreword
2. iLearn is up to you aka., be an independent learner
3. Prepare for incoming!
aka., activate your cognitive foundation
(prior knowledge) for today’s lesson
4. Where does this fit?
lesson
aka., appreciating big picture for today’s
5. You expect me to know what ?
lesson
aka., new knowledge in today’s
6. Practice makes perfect aka., case study
7. What did I just do?
26 May 17
aka., learning wrap-up
4 of 51
CZ3003
How is this
relevant to me?
Science brings discipline to undisciplined
FBS ontology: Design science theory
26 May 17
5 of 51
CZ3003
Science brings discipline to undisciplined
There is recurrent and entrenched disagreement on how designers produce
designs, the common mantra being, “there are many ways of designing”. Nonetheless, there is growing pressure on design-oriented professionals, such as architects
and engineers, to act according to a systematic design form. In 1957 R.B. Fuller
introduced Design Science as a systematic form of designing. It was not to say
design is a science or the acts of designing are in themselves scientific; instead,
that design science is a scientific study of design. Herbert Simon's 1968 book “The
Sciences of the Artificial” proposed a systematic and formalized design theory
called the Rational Model for many disciplines, including computer science.
Premier theory in design science for systems engineering called FunctionBehavior-Structure (FBS) ontology was published by John Gero in 1990. It
proposed a world view of modeling the 1) results of designing (which is the plan) and
2) activities of designing (which is how one came up with the plan), for a number of
design-oriented disciplines, including software design.
The FBS ontology concerns design objects, entities that are to be designed,
and consequently implemented and deployed. Such objects can be physical or
virtual, as long as they have observable properties. The ontology describes and
prescribes the structure, behaviour, and function of these design objects, where
26 May 17
6 of 51
CZ3003
FBS ontology: Design science theory
function is relatable to behaviour which is relatable to structure, but function is
not relatable to structure. Crucially, the design object transforms to an actual
object within some larger process of manufacture.
Structure. This is configuration of the design object, either in quantities or
categories, and depends on the level of abstraction imposed. Structure is oriented
either materially (its anatomy) or mechanistically (its operation), and is modeled at
one of two levels, macro (distinguishable and explicitly representable) or micro (too
fine-grained to be represented explicitly). A variable of structure is its state.
Behaviour. This is the change of that state that may be 1) observable as it is
manifested on/adjacent to the structure’s boundary, and 2) unobservable as it is
internal. Importantly, behaviour cannot truly be known because a design object
cannot be tested. It can only be predicted as a consequential occurrence of the
designed (as opposed to, implemented) structure. The correctness of such prediction depends on the newness of the intended technology, but, since designing is an
inductive process, the designer’s experience is probably most crucial factor.
Function. This is the role (set of observable behaviours) of the design object
ascribed by the designer in accordance with the requirements (reason for its
creation). Unlike behaviour, function is prescriptive not predictive.
26 May 17
7 of 51
CZ3003
FBS ontology: Design science … (cont)
The ontology proposed a generic design result ignoring the context [see right].
Note additional elements of requirements (baseline of expectations of actual
objects), design (created by the designer), expected behaviour (desired by
designer), and derived behaviour (predicted from structure). These are arranged
into eight fundamental processes in designing:
1.
Formulation ─ makes function from
reqrs (R→F), and decomposes
function into expected behaviour
(F→Be).
2. Synthesis ─ makes structure for
expected behaviour (Be→S).
3. Analysis ─ predicts behaviour from
structure (S→Bs).
4. Evaluation ─ compares expected
behaviour with predicted (Be↔Bs).
5. Design ─ makes design from
structure (S→D).
26 May 17
8 of 51
CZ3003
FBS ontology: Design science … (cont)
6.
Reformulation1 ─ modifies structure to reduce difference that its
predicted behaviour has with expected behaviour (S→S’).
7.
Reformulation2 ─ modifies expected behaviour to reduce difference
with predicted behaviour (S→Be’).
8.
Reformulation3 ─ modifies function and reformulate expected behaviour
to reduce difference with predicted behaviour (S→F’ via Be).
Applications of the FBS ontology include, artificial intelligence in engineering
(Umeda et al., 1990), automation of construction industry (Clayton et al., 1999),
software design cast in FBS (Kruchten, 2005), intelligent CAD systems (Colombo,
2007), situated FBS for user-centered software design (Uflacker et al., 2008), and
sales call support application (Eichhoff et al., 2011).
Of particular interest to the instructor of this course, and relevance to the
students, is that the FBS ontology was applied to assist high school students'
system thinking in engineering design (Lammi, 2011), and it was found to be highly
effective by the students and instructor alike in boosting their performance in the
school’s engineering projects.
26 May 17
9 of 51
CZ3003
iLearn is up to
you
aka., be an independent learner
Learning is what you make it: set your sights on the outcome
“Do you want to know more?”1
Bloom’s degree of learning for the lesson
1
26 May 17
“Starship Troopers”, directed by Paul Verhoeven, 1997
10 of 51
CZ3003
Learning is what you make it …
… and to achieve it, it is suggested you come at this from three angles.
1. Imprint your learning outcomes.
2. Flip your classroom (assimilate-seek feedback-reinforce).
3. Consider suitable examination question.
Learning outcome is the new capability that a student is required to
assimilate, and demonstrate it has been done so. Learning outcome is a
convergence between the teacher’s expectation and the students
tangible increase in personal knowledge.
There is a set of high-level learning outcomes for the course. Also,
each lesson has its own low-level learning outcomes. The low-level
learning outcomes may combine into a high-level one, or directly
translate into high level outcomes. With cues from the teacher, the
student must cognitively interconnect outcomes like pieces in a puzzle.
26 May 17
11 of 51
CZ3003
Set your sights on the stated learning outcome
As a student of SSAD course, by end of this session,
you will be able to …
… 1) derive sw design objects to use in model of FBS
in initial architecture, and 2) analyse said
architecture’s FBS.
26 May 17
12 of 51
CZ3003
Do you want to know more?
Several materials are provided in NTULearn to supplement the
topic’s handout. All materials are certified by the teacher as being
suitable and beneficial to the student. All materials are organized into
two categories:
R-series – content relates directly to the core concepts of the
topic; intended for the “inside-the-box” learner.
E-series – content goes beyond the topic into more challenging
and introspective concepts; intended for the “outside-the-box”
learner.
Though ultimately constrained by availability, the references come in
several formats, designated by suffixes, the most prolific being:
A, for article – published; typically words only, no images.
V, for video – usually from youtube, or a customization of same.
B, for brief – unpublished; typically words and images.
26 May 17
13 of 51
CZ3003
Read these refs to supplement your learning
R09B.BldgBlk(S).Explanation of Component Categorization.KAJ
R09B.BldgBlk(S).Explanation of Integrative Component.KAJ
R09B.BldgBlk(S).Explanation of Manager vrs Controller Cmpnt.KAJ
R09V.BldgBlk(S).Sw Architecture wCmpnt & Connect.Georgia Tech
R09V.BldgBlk(S). Collosseum & Space Vehicle Egs.KAJ
E31B.BldgBlk.The What Dimension of Architecture.Arnold
E32K.BldgBlk.SWE with Reusable Components.Sametinger
26 May 17
14 of 51
CZ3003
Bloom’s degree of learning
Final suggested learning consideration: expected depth of learning for the
topic. Eminent educationalist Benjamin Bloom identified six degrees of
assimilation of new knowledge: first is the lowest, most superficial degree, and
sixth is the highest, deepest, most pervasive.
The learning for this topic is third degree, apply : student must glean
design objects (components and connectors) from the real objects of the sw
system, and incorporate them into an initial architecture. Also, the student
must be able to distinguish the function, behaviour, and structure forming in
the initial architecture, and be able to discuss each as they are singled out.
Assessing ‘apply’. How to design or communicate or document… in my
architecture? Adopt… to solve [something]? What would result if… was used
[for something else]? Show several ways… can be applied [for something]?
How would you organize… to solve [something]?
Examination. You are expected to be able to derive design objects for a
given sw system, draw them into an initial architecture, and analyse the initial
architecture’s function, behaviour, and structure (FBS).
26 May 17
15 of 51
CZ3003
Know the degree of learning that is expected of you
Bloom, B.S.; Engelhart, M.D.; Furst, E.J.; Hill, W.H.; Krathwohl,
D.R. (1956). Taxonomy of educational objectives: The
classification of educational goals. Handbook I: Cognitive
domain. New York: David McKay Company.
1
3
3
2
4
5
6
Can the student:
apply ideas & concepts of…?
adapt… for use in new context?
solve some problem using…?
“Derive design objects for a given sw system, draw them into an
initial architecture, and analyse the initial architecture’s FBS1.”
1
26 May 17
function, behaviour, structure
16 of 51
CZ3003
Prepare for
incoming!
aka., activate your cognitive foundation
(prior knowledge) for today’s lesson
Remind me about architecture (common engr)
Issue with sw design level’s existing defs (course 2006)
Remind me, what is ‘information hiding’? (course 2002)
Façade design pattern hides suppliers (course 2006)
26 May 17
17 of 51
CZ3003
Tenet of all fields of engineering
Remind me about architecture
Architecture is a high-level design specification of the consistency, configuration, and composition of a manmade (not naturally occurring) assemblage [recall
“Developing beyond sw product” lesson] comprising building blocks that are not
atomic nor indivisible (otherwise there is nothing to collect or configure). The
specification serves as a plan for the implementation and deployment of the assemblage [see below]. The medium of that plan depends on the engineering discipline
producing it. Due to it being a plan, architecture cannot be tested, only inspected
and evaluated. Finally, if the assemblage has multiple levels of nesting and a high
degree of complexity, then there may an additional specification between architecture and implementation, at a low-level of design, specifying the atomic/indivisible/
base constructs.
low-level
design
high-level
design
26 May 17
Architecture
Possible “atomic” design,
after architecture, before implementation.
18 of 51
CZ3003
Tenet of all fields of engineering
Remind me about architecture (cont)
To illustrate the mapping of high and low levels of design to engineering
architecture, let's take the example of a personal land transportation vehicle
with internal combustion engine, i.e., car [see below]:
High-level
specifies entire
assemblage and
major building
blocks where
interactions are
with environment
& users.
‘Cutaway’ diagram
View anti-lock brake; its building
blocks are fluid, tubing, pump, cylinder,
clamp, disks, release governor, brake line,
and brake pedal; interaction only between
building blocks (none to environment; user
interaction limited to brake pedal).
26 May 17
19 of 51
View entire car with its body,
engine, transmission, and wheels;
environment interactions are with
body (air resistance, centre of gravity) and wheels (road friction, speed
and handling); user interactions are
with body (ingress/egress, visibility,
climate), and engine and transmission
(speed, direction).
Low-level drills down
to the atomic building
blocks, where
interactions are only
with other atomic
building blocks.
‘Cutaway’ diagram
CZ3003
From SCSE core course, CE/CZ2006
Issue with sw design level’s existing defs
Course 2006 “Software Engineering” established these design level
definitions: 1) low-level pertains to the lines of code, and 2) high-level pertains
to the Classes. While there is a UML diagram for modeling high-level design,
namely the Class diagram, there is none for modeling low-level design. Are these
definitions compatible with the definitions of architecture being a holistic
perspective and also a collection of components? No, they are not!
Class diagram is suitable for representing a holistic vantage only for small
programs, but not for large programs. The biggest problem is that classes are a
codification of real world objects, and as such are not divisible. Consider a set
of classes that defined geometric objects, such as lines, circles, points, etc. Can
you deduce the holistic solution? Probably not. In contrast, answer the same
question for these entities: object selector, object sizer, colour selector, object
grouper. You may immediately surmise that it might be a graphics program. Do
you see the issue? Those entities are expansive enough to give a sense of the
whole. They seemed “higher” than classes, divisible, in fact, containers of
classes (such as the geometric object definition classes). In other words,
classes are too small to be building blocks specified in architecture.
26 May 17
20 of 51
CZ3003
From SCSE core course, CE/CZ2002
Remind me, what is ‘information hiding’?
From course 2002 “Object Oriented Programming”, ‘information hiding’ by
David Parnas in "On the Criteria to be Used in Decomposing Systems into
Modules" (1972) is the preclusion of access by external users to internal aspects
of a component, and the segregation of a component’s design decisions. Often,
encapsulation is used interchangeably with information hiding, but the two terms
are distinct. ‘Information hiding’ is the principle of preclusion, encapsulation is
the technique. ‘Information hiding’ is a core principle of good software
architecture; with it …
a software component provides a service integral to the architecture
that contains the component.
a software component can present a stable, well-defined interface to any
and all users needing to access the service of the component.
the implementation of the service provided by a software component can
be enhanced (consistency with original nature of the service maintained)
without necessitating a commensurate change in the users.
a software component can be decomposed into sub-components.
26 May 17
21 of 51
CZ3003
Interface for PC is extensive;
not shown is very common
input interface, namely USB.
Hardware and software examples of information hiding
Physical dimensions necessitate a well-defined
interface for hardware; get these wrong and the
mating parts don’t fit together. For the PC tower
[see left], its interface is more complicated because
there is the added definition of electronic standards
for the input media, such as floppy disk and CD-ROM.
Display
interface
is at
back of
the
tower.
For object-oriented software, the well-defined
interface is the set of 'public’ visibility Properties
and Operations [see right] presented by the Class
for use by others.
By precluding access to its internal aspects,
the component’s design (including composition),
implementation, and maintenance are independent
of all other components; the only stipulation is
that the component strictly fulfill its service
contract. [see right] PC tower has lots of subcomponents, and they can be changed (repaired or
upgraded) as long as the PC operates as expected.
With information hiding,
component is a black box,
that fulfills declared
service.
Supplier
+ property
+ operation
Interface for Class;
if the Operation is
abstract, this is kind
of another interface.
Component has numerous
sub-components hidden by
cover, performing service
anonymously.
This concept is the same for software. Being
hidden, the component’s internals are repaired/
upgraded independent of rest of software.
26 May 17
22 of 51
CZ3003
From SCSE core course, CE2006
Façade design pattern hides suppliers
This highly-used design
pattern offers a single, unified
implementation, ie., “Façade”
Class, through which external
client classes can access a set of
functions in supplier Classes [see
right]. Its purpose is to decouple
Box demarcates
the supplying classes from direct
set of supplier
access by the client, and through
classes; it is not
a codeable container.
the Façade facilitate management, prioritization, and optimization of the services provision.
«class»
Façade
Operation list
«class»
SupplierA
Façade Class strongly
aggregates all supplier
Classes within the box.
26 May 17
UML Classes
[right] An alternate
notation in UML is to
draw all supplier classes
into a compartment
following the last
feature component.
23 of 51
«class»
Façade
Operation list
«class»
SupplierA
CZ3003
From SCSE core course, CE2006
Façade design pattern hides suppliers (cont)
Façade Class’ implementation does not override or repeat the functions of
the supplier classes. Instead, Façade Class delegates the client class’ calls to
the appropriate supplier class, in the same way a wrapper does.
Client classes may
connect to the Façade
Class by Association
or Interface.
«class»
FaçadeA
Opn list
«class»
FaçadeB
«class»
Association
Client
Interface Opn list
UML Class diagrams
As an ordered compo-
Façade Class may sitional hierarchy, each
level is independent of
strongly aggregate
the next.
another Façade Class.
This aggregation of
«class»
another aggregation
FaçadeC
can continue without
Opn list
limit since the complexity is reduceable.
26 May 17
«class»
FaçadeD
Opn list
«class»
Supplier2
«class»
FaçadeE
Opn list
«class»
Supplier1
24 of 51
The complexity of each Facade
is not enlarged/amplified by the
complexity of its nesting Façade.
«class»
Supplier3
«class»
Supplier4
«class»
Supplier5
CZ3003
Where does
this fit?
aka., appreciating the big picture for
today’s lesson
Structure & behaviour for engineering
Primer on collections
Structure & behaviour for sw engineering
Mission, function, role, and service
26 May 17
25 of 51
CZ3003
Tenet of all fields of engineering
Structure & behaviour for engineering
Familiar use of the terms structure and behaviour is strongly associated
with physical entities. A building is probably the first thing that one associates
with the word structure. Perhaps a car or plane is what comes to mind when
asked about describing the behaviour of something. In contrast, it is unlikely
that one would talk about classes or branching, but these are valid examples of
structure and behaviour respectively in sw engineering.
As shown in the treatise on the FBS ontology [see “Relevance” section],
structure and behaviour are meaningful and accepted concepts in design science,
ones which we will rely on in this course. So, lets set the definitions for these
terms to eliminate any misapplication to sw system and its architecture.
Structure. This is an entity, physical or virtual, with an established scope
and size, composed of parts in a configuration specified quantitatively, categorically, or both. It is a specialization of the definition of assemblage “an object
made up of pieces fitted together”, so the term structure may be used in place
of assemblage [recall “Developing beyond sw product” lesson]. Two concepts of
structure that distinguish it from assemblage are: 1) the composition, ie., kinds
of parts, interconnections, and part’s collection, prescribes the structure’s
26 May 17
26 of 51
CZ3003
Tenet of all fields of engineering
Structure & behaviour for engr (cont)
uniqueness, and 2) absence of any part disrupts the integrity and operability of
the whole of the structure. Kind of collection of parts is always set or tuple
[see “Primer on collections” slides immediately following this].
Behaviour. This is the response/reaction of the structure to the detection
of a stimulus from its environment. Behaviour is bound to structure, and cannot
exist without structure. If a stimulus is detectable, then a response/reaction,
even if nil, must occur. In other words, a detectable stimuli cannot be ignored or
lost. The response/reaction may be delayed, or occur immediately upon stimuli.
As per the FBS ontology, behaviour generates a change to the state of the
structure that is either observable (because it is at the boundary of the
structure) or not (because it is internal). Finally, the response/reaction may
include a purposeful output for acceptance by another structure. Complexity of
the behavior is directly related to that of the underlying structure of the
reacting entities. In other words, behaviour is a sequence [see “Primer on
collections” slides] of cause-effect, and the uniqueness of the behaviour is
defined by the state changes it causes.
26 May 17
27 of 51
CZ3003
Tenet of all fields of engineering
Primer on collections
Collection is multiple individual and distinct entities assigned to a group as its
members. This differs from type in that the members need not be valid,
compatible, or similar in purpose. There are four kinds of collections important to
the discussion of structure and behaviour: set, bag, sequence, and tuple.
Set. This is the primary kind of collection, unordered and no duplicate
members. The quantity of members can be zero, ie., a null set, one or any other
finite quantity, and even infinite (although this mathematical concept is not suited
for our purposes). Its membership is immutable, ie., once the set is formed, its
members cannot be changed, leave, or join. Within any context of usage, a set is
handled as an object in itself, ie., it is atomic. Typically, in engineering documents,
the first letter of its name is uppercase, and it members are shown in {…}. The
standard operations associated with sets are:
Union – adding not duplicating members, eg., {1,2} ∪ {2,3} = {1,2,3}.
Intersection – finding common members, eg., {1,2} ∩ {2,3} = {2}.
Compliment – subtracting, {1,2,3,4} \ {1,3} = {2,4}.
Cartesian product – pairing every member of one set with every member of
another, eg., {1,2} × {1,2} = { (1,1), (1,2), (2,1), (2,2) }.
26 May 17
28 of 51
CZ3003
Tenet of all fields of engineering
Primer on collections (cont)
Bag, aka., multiset. This is a set with the exception that its membership has
any combination of duplication of its members; it is still unordered. Duplicated
members can appear adjacent, interleaved, or both. Its operations also allow
duplication in the membership in the solution, eg.,
Union – {1,1} ∪ {1,2} = {1,1,1,2}
Intersection – {1,1,1,3} ∩ {1,1,2} = {1,1}
Cartesian product – {1,1} × {1,2} = { (1,1), (1,2), (1,1), (1,2) }
Sequence. This is a bag that is ordered per one or more rules, such as
ascending or decending. It is essential that the membership be of one type if
the ordering is to be implementable. Strings and lists are examples of finite
sequences; stream is example of unlimited sequences.
Tuple. This is a set where the members are of different types. Consequentially, the standard operations cannot be applied; custom operations must be
defined. The list is typically finite. Once the tuple scheme is set, the position
of the members in the list is immutable. Eg.,
2-tuple (colour, weight) ≠ (weight, colour) where positions reversed.
26 May 17
29 of 51
CZ3003
From SCSE core course CE/CZ2006
Structure & behaviour for SW engineering
It is clear from the “FBS ontology” section, that the structure and behaviour
of the ‘design of an entity’ is compositionally different to that of the ‘entity itself’.
This is because the parts in the former are design objects, and in the latter, implemented/real objects. Accordingly, lets inaugurate the two forms of structure and
behaviour consistent with course 2006 “Software Engineering”.
Car
Structure:
Driver
kind: String =
“sedan”
style: String =
“lefthand”
drive( ): void
op( ): void
UML
Class
diagram
Implementation form
Design form
UML
Activity
diagram
…
Behaviour:
[x>0]
class Car{
string size = “sedan”;
void drive( ) { … }
}
class Driver{
…
then
[x<=0]
…
if (x>0) {then}
else {that}
that
26 May 17
30 of 51
CZ3003
Mission, function, role, and service
There are four terms commonly encountered in the context of sw systems —
mission, function, role, service — that are used interchangeably. These are their
exact definitions.
Mission – a special, unordinary, and significant endeavour that is assigned
to an entity in a particular situation for a particular amount of time.
Function – regular endeavour proper to an entity or for which that entity is
designed. Situation or time has no bearing in the endeavour.
Role – proper and customary responsibilities and empowerments assigned
within an organization for an endeavour in a particular situation for a
particular amount of time.
Service – resources from or work performed by, a providing entity to
satisfy the needs of a recipient entity. The provision may be either regular
(designed for) or special (assigned to).
Can they be used interchangeably, and can they apply appropriately to both
design and real objects? Generally, mission is only used in the context of subsystems, while role is used in the context of communication theory and structure.
For the two other terms, in both questions, for this course, the answer is yes.
26 May 17
31 of 51
CZ3003
You expect me
to know what ?
aka., new knowledge in today’s lesson
Sw system: Essential to have architecture
Architecture is component and connector
Component contains set of classes
Architecture form with its design objects/model-language neutral
Sw system with function, behaviour, structure
FBS in architecture: Two dimensions, structure, & behaviour + function
Relating FBS to design and real objects … and sw engineering
26 May 17
32 of 51
CZ3003
From slides “Remind me about architecture” and “Structure & behaviour for engineering”
Sw system: Essential to have architecture
‘Oil shipment C2 system’ [recall “Sw arch FBS, Pt1 Real2Design object”
lesson] is exemplar of consistency, configuration, and composition of a manmade
assemblage comprised of non-atomic, divisible building blocks (subsystems).
Therefore, if it is to be developed, then it is essential to design its architecture.
Comms infrastructure divides into towers,
terminals, repeaters, cables, and operators.
Satellite subsystem
divides into smaller
parts, terminals,
infrastructure, and
staff.
Email subsystem
divides into
smaller sw apps,
comms connectors,
data, code,
hardware, and
operators.
C2 application divides into smaller
apps, external services, data, code,
hardware, and operators.
Tanker subsystem divides into
operators, smaller parts,
facilities, garages, and staff.
26 May 17
33 of 51
CZ3003
From lesson “Sw arch FBS, Pt1 Real2Design object”; definition of system
Architecture is component and connector
Main parts of a system, ie., subsystems,
[see right top] are heterogeneous [recall that
developed systems are generally singular; no
two are alike]. The subsystem-ness disappears
after a few decompositions, homogeneity sets
in, and continues until the items are reduced to
a set of atomic/indivisible kinds. These items
with differing degrees of homogeneity are
collectively designated as “parts”. Typically,
such level detail would not make it into the
design; instead, the complexity of the real
objects in the system would be suppressed as
much as feasible.
The answer is given by Shaw & Garlan
(1996) and echoed course 1006 [in next lesson].
The design objects of sw architecture are …
components and connectors [see right bottom].
26 May 17
34 of 51
System
System is
generalized
subsystem.
*
System
comprises
many
subsystems.
Subsystem
Parts
are not
dynamic
compositions.
*
Part
UML Class diagrams
SoftwareArchitecture
*
Component
*
Connector
CZ3003
From lesson “Sw arch FBS, Pt1 Real2Design object”, system def
Arch is component and connector (cont)
Components and connectors are design objects in architecture that represent
real objects in the sw system.
Component. This represents subsystems and parts (recall parts emerge from
the decomposition of a subsystem into non-subsystem-ness). The key attribute of a
component is its name. Typically, it is assigned a name that conveys the gist of the
function that the real object is intended to provide to other objects. However, the
component may also be named for the role that it is fulfilling in an architectural
style [see later chapter].
Connector. This represents interactions — an exchange of control or data —
between parts, subsystems, or both. In other words, a connector represents 1) an
action (send, receive, or both) and the entity subjected to that action (control, data
or both). Importantly, the connector cannot have any side effects, ie., the action
completes only what it is specified to do. Any action happening after the connector
is finished, is a new action invoked by the receiving component. The scope of
control passed spans from the object level (in RAM) up to subsystem operations.
Finally, a connector represents dynamic binding that facilitates dynamic composition; eg., an Interface object (the object-oriented programming construct that
directs a behaviour call to an available implementation), network, or even a courier.
26 May 17
35 of 51
CZ3003
From slides “Issue with defs of high-low level sw design” & “cutaway diagram of the car architecture”
Component contains set of classes
Because architecture is high-level design, and course 2006 defines high-level
design as pertaining to classes, the question is whether component is just another
term for class? No! Classes are not divisible, not expansive enough to give a sense
of the whole, especially for large programs (more than 15 classes), and too small to
be the ‘building blocks’ that are specified in architecture definition.
Not convinced? Consider this. The average class is 1250 lines of code (LOC)
[Windows Vista has 50 million LOC for 40K files or 40K classes, since each file is
typically one class.] In a modern car, there are an average of 40 electronic control
units (ECUs) corresponding to its major components, such as engine fuel injection
(hybrid monitoring is an additional component), cruise control, brakes, cabin climate,
airbags, windows, and 4-wheel drive. These ECUs contain over 100 million LOC,
approximating to 80K classes! It is axiomatic that 80K classes is far too many
components in a car. [Study the given car cutaway diagram and come up with 32
more components than what have just been mentioned; 40 would be the reasonable
number of major components, not 80K!] Therefore, components cannot be classes.
Instead, components must be containers of
* Class
Component
classes, in fact many classes [perhaps 2K
each; see right], indeed, a set of classes.
UML Class diagram
26 May 17
36 of 51
CZ3003
From slide “Remind me of architecture”; SDLC
Component contains set of classes (cont)
To recap, a class is
atomic and indivisible. So,
as a member of a component, a class embodies the
‘atomic design’ that is,
“after architecture and
before implementation”; in
other words, the low-level
design [see right top].
(high-level) Architecture
Recall that classes are object-oriented language constructs. However, much of the software
encountered in a sw system is developed in functional-oriented languages. So, we expand the
component containment relationship, to files and
command/shell scripts, as an exclusive-or, ie.,
each component contains only one of each kind
[see right bottom].
26 May 17
37 of 51
class design (low-level)
Component
«xor»
*
Class
*
File
*
Script
CZ3003
Architecture form with its design objects
With only two design objects, components and connectors, the basic form of sw
architecture is simply … [see right top].
no box
ComponentA
26 May 17
38 of 51
connector1
ComponentB
no arrows
The component and connectors are divisible, and
so can be decomposed into their nested parts, and so
on, until only the indivisible entities are reached. At
this point, the notion of architecture ceases and the
perspective changes to class design. The basic form
of the class design becomes … [see right middle].
The “highest” level in the architecture is
… [see right bottom]. Sometimes it is helpful
from the design perspective to highlight this.
However, use of ‘subsystem’ is discretionary;
otherwise, the architecture basic form is
suitable at any and all levels.
binds dynamically
binds statically
ClassA
association1
ClassB
This slide is a model-language
neutral design format. The
objects are represented as
simply as possible.
SubsystemA
connector1
SubsystemB
CZ3003
From slides “Remind me about architecture” and “Structure & behaviour for engineering”
Sw system with function, behaviour, structure
When the ‘Oil shipment C2 system’ is deployed, it will exhibit function, behaviour, and structure (FBS) breadth-wise [see below], whereas depth-wise is hidden to
the current level observer (because of ‘information hiding’ principle). How are these
real object properties represented in the architecture design objects in conformance with the FBS ontology? [Hierarchy will be introduced in later chapter.]
Every part has a function provided when needed.
Stimuli reactions/
responses outputs.
Scope and size
established.
Absent/broken part
disruptive to whole.
Detectable stimuli.
Interconnections
specialized.
Change structure
state.
Behaviours’ collection is sequence.
Parts’ collection is set or tuple.
Parts kinds are vehicle, digital electronics, software
26 May 17
39 of 51
CZ3003
From slides “What is ‘information hiding’?” & “Façade hides suppliers”
FBS in architecture: Two dimensions
Unlike in real world, the two dimensions, breadth-wise and depth-wise, can
(and must) be visible in the architecture form, with their FBS prescriptions, to
the architect and design teams.
My design format, breadth-wise and depth-wise,
are model-language neutral; trying to keep it simple.
Function – Behaviour – Structure
breadth-wise
ComponentA
connector1
depth-wise
ComponentB
ComponentB1
cB1
connector2
ComponentB2
ComponentC
breadth-wise
connector3
ComponentD
Using shading to denote nested cmpts is
my style. Use whatever works for you.
So, the architecture has to incorporate a way that the “all-visible” design
will have the ‘information hiding’ feature that the real objects must exhibit, once
implemented. This is achieved through the ‘Façade design pattern’. Any connection made to a component is only done through the Façade class. The inference is
that an external component knows the called component’s function only, and
nothing of its internal structure and behaviour are revealed. The implementation of the pattern makes the information hiding a reality.
26 May 17
40 of 51
CZ3003
FBS in architecture: Structure
The structure of the design objects is the configuration of all the components,
connected as per the architecture form [see middle]. It is crucial to get the structure right, as the behaviour is its derivative.
ComponentA
ComponentC
connector3
ComponentD
ComponentB
It is evident from the drawing above that the simplicity of the design objects has
its price. It is really not possible to perceive any structure from it. There is
insufficient information about the design, and we need conventions of structure
with which to interpret the configuration. [See bottom] Consider the middle
diagram redrawn with roles and data detail [recall this is associated with
architectural style]. Can you guess the structure now?
ViewA
Model
input condition
Controller
ViewB
26 May 17
41 of 51
CZ3003
From slides “FBS ontology”
FBS in arch: Behaviour + function
Specifying the behaviours in the real objects is even less adequate than the
structure. There is no mechanism in the design objects for this. Instead, the
architect has to specify the behaviours in free text, BNF grammar, or constraint
language such as Object Constraint language.
The forthright approach in this case is to use the FBS ontology as a guideline, where behaviour is either observable (because it is external to the object)
or not observable (because it is internal).
A common external behaviour is the
conduct of communications between the
subsystems [see right]. Common internal
behaviours associated with the communications include creating call object, sending
call object, accepting call object, processing
(this could be many different actions),
packaging data, returning object with
packed data.
Satellite
- reseting position
- transmiting
- receiving
Ku-band
GPS device
- displaying
- requesting
- storing
Function will be discussed in the next lesson.
26 May 17
42 of 51
CZ3003
From lesson “Sw arch FBS, Pt1 Real2Design object”, and slides “FBS”
Relating FBS to design and real objects …
Lets summarize the main learning points in these final slides. Design objects
(architecture which comprises many components and connectors) represent or
model the real objects (sw system which comprises many subsystems and parts;
simplified to just parts). Architecture also models the FBS that the sw system
will own (when deployed). Typically, a part will have a single dedicated structure,
a single public function, and many behaviours (some visible others not). The
component corresponding to the part, models the FBS with the same scheme
[see below].
«models»
Design objects
Software
Architecture
FBS ontology | Sw Engineering
«models»
Structure 1
«owns»
«relates»
Behaviour *
*
Component
26 May 17
Real objects
*
Connector
This is at
any level
of decomp
«relates»
Function 1
43 of 51
Set of
behaviours
SwSystem
*
Part
CZ3003
… and sw engineering
Lets redo the earlier comparison of the design and implementation forms of
structure and behaviour consistent with course 2006 “Software Engineering” with
the FBS consistent with this course.
Do you think the implementation form will change? Of course not! Even sw
system manifests into code; only the design form changes. For the code contract,
recall the concept from course 2006.
Implementation form
Design form
connector1
Structure:
ComponentA
Behaviour:
External: message passing
Internal: suppressed
Function:
Name of component (more
detail in next lesson)
26 May 17
ComponentB
44 of 51
class Car{
string size = “sedan”;
void drive( ) { … }
}
…
if (x>0) {then}
else {that}
code contract (preconditions, postconditions,
and object invariants)
CZ3003
Practice makes
perfect
aka., case study
Task: Craft an initial architecture for the sw powering the device in
the given image. Keep it simple, no modeling language, and don’t
assume too much.
26 May 17
45 of 51
CZ3003
Armour Detect-Defeat-Evade Robot (ADDER)
Imagine a small,
cheap, all-terrain,
all-weather, super
powerful tank
destroyer called
ADDER. Its major
parts are indicated.
Railgun uses
electromagnetic
forces to impart
very high kinetic
energy to depleteduranium projectiles.
You are an architect
in a prestigious firm
that designs armour
warfare software
systems.
26 May 17
Laser ranging
Visual aiming
Railgun
Ammo
Gun elevation
Antenna
Loader
Solar cells & shielding
Computer
Electric
engine Batteries
Steering
Fast and maneuverable
All-terrain
tires
Unmanned, self-propelled, autonomous
46 of 51
CZ3003
Start simple, make clear choices
My system thinking tells me that there will be four major subsystems in ADDER,
ie., weapon, vehicle, power, and operation [see below; structure only], and that they
will be developed by separate vendors, then integrated by a prime. Each subsystem
will supply all the OEM sw for all their hardware. My team will develop the sw system that moves control and data between the subsystems, and the general operations of the platform.
Power needs status data from other packs.
When directed to work, Weapon takes
control from, then returns it to,
Operation.
WeaponPack
data
ctrl + data
PowerPack
data
OperationPack
data
ctrl + data
When directed to work, Movement takes
control from, then returns it to,
Operation.
VehiclePack
WeaponPack loads, aims, and fires the gun. VehiclePack moves the platform to
and from the battlefield, including manoeuvring in and out of firing positions. PowerPack manages platform power, including sleeping. OperationPack plans and directs
all missions, including tactics, target selection, jockeying into position, and firing.
For this case study, I’m only decomposing the OperationPack. I expect the
vendors would decompose the Weapon, Vehicle, and Power Packs, not the prime. The
most effective and reliable approach is for the vendors to provide an entry point (to
their subsystems) for the architect to access all their behaviours.
26 May 17
47 of 51
CZ3003
It should have been crystal clear to you from all your
software development training that you must have
domain knowledge to be successful as a developer. It
so happens, my domain expertise includes armour operations. That aside, for learning, you should be open to
working with as many different domains as possible.
Domain & decompose
My domain experience tells me that a tank destroyer snipe attacks, ie., find a
concealed position to fire from, then kill with a single shot, then freeze while the
enemy scans the area where they think the shot originated, and then move to a new
position after their scanning loses focus. Close into and out of the firing position,
stealth is crucial, whereas redeploying to a new kill zone, its speed.
My system thinking tells me that the sniping operations is best manifested in
the OperationPack by two major components, snipe and zone tactics. Additionally,
there are components for driving, handling the weapon, and power [see below; structure only].
Joins to
previous
diagram.
ctrl + data
data
ctrl + data
Motor
data
Power
Gunner
TacticClose
ctrl
data
data
TacticZone
Synchronize Tactics
data continuously.
Only one tactics in
control at any time.
Each Tactic directs the other Packs through drivers. Also, each Tactic does its
own mission and route planning; this requires maps. This would involve a significant
amount of saved data, such as new and used routes, enemy and friendly lines, and
main and alternate firing positions on maps. Storage in central data-base is most
effective, though each has a repository for immediate decisions.
26 May 17
48 of 51
CZ3003
It is easier to think about and write out small
chunks of architecture than the whole of it.
Grow complexity
My domain experience tells me an effective sniper spends considerable time
observing and learning about the enemy, so a central knowledge base for machine
learning is necessary. Also, making the decision to toggle between close-in and
zone tactics is not simple and requires a lot of intelligence. Plus, there is the
action of withdrawing from action to recharge batteries. Which tactic component handles this? Therefore, a Commander component is added, that takes
control whenever toggling the Tactic components [see below; structure only].
Joins to
previous
diagram.
TacticClose
ctrl
Commander
data
Database
data
TacticZone
Learner
data
KnowledgeBase
The student can carry out further decompositions from here. Hints have
already been provided in the narrative.
Behaviour, as explained earlier, can be annotated to each of the components
in the diagrams. While this is necessary for completeness, behaviour is often
left until later in the architecture crafting process.
26 May 17
49 of 51
CZ3003
Remember, this is model-language neutral design perspective, so
represent the decomposition in the simplest possible fashion.
Redraw into complete architecture
With practice in, system and Sw arch FBS, Pt1 Real2Design object and
applying FBS to the design objects, you too will be able to deftly and quickly
derive this architecture.
data
Vehicle
Pack
Power
Pack
data
ctrl
+ data
OperationPack
Motor
data
TacticClose
Database
data
data
ctrl
Weapon + data
Pack
Other Packs not decomposed.
Power
Gunner
sync
data
Commander
ctrl
TacticZone
data
data
Learner
data Knowledge
Base
Decomposition of OperationPack.
Consider, an experienced architect in this domain would see the functions that
are missing, such as external communications, self-defence, mission assignment,
updating of tactical intel, designation of high priority target, and self-destruct.
26 May 17
50 of 51
CZ3003
What did I just do? aka., learning wrap-up
Essential to have architecture for sw system
Architecture is component & connector
Component contains set of classes
Architecture form with its design objects
Sw system with structure, behaviour, function
FBS in architecture:
Two dimensions, structure, and behaviour + function
Relating FBS to design & real objects … and sw engineering
26 May 17
51 of 51
CZ3003