Chapter 6 : Formal Models and

Specifications
Content
The Value of Architectural Formalism - Formalizing the
01
Architecture of a Specific System

02 Formalizing an Architectural Style

03 Formalizing an Architectural Design Space - Toward a Theory

of Software Architecture

04 What Next ? - Z Notation Used in This Chapter

 01
The Value of Architectural
Formalism - Formalizing the
Architecture of a Specific System
The Value of Architectural
Formalism
It is generally agreed that formal models and techniques for
formal analysis are cornerstones of a mature engineering
discipline, but engineering disciplines use them in many
different ways. Formalisms can be used to provide precise,
abstract models and to provide analytical techniques based on
these models. They can be used to provide notations for
describing specific engineering designs. They are also useful
for simulating behavior.
 The Value of Architectural
Formalism
1. The architecture of a specific
system. Formalisms of this kind
allow the software architect to plan
a particular system. Such
formalisms can become part of the
specification of the system,
augmenting the informal
characterizations of the system's
architecture, and perhaps
permitting specific analyses of the
system.
2. An architectural style.
Formalisms of this kind can be used
to describe architectural
abstractions for families of
systems. Such formalisms have at
least two purposes: (1) to make
precise the common idioms,
patterns, and reference
architectures now used informally
by designers; and (2) to elucidate a
portion of the architectural space
by showing how different
architectures can be treated as
specializations of a common
 The Value of Architectural
Formalism
3. A theory of software architecture. 4. Formal semantics for
Formalisms of this kind can clarify architectural description languages.
the meaning of generic architectural This kind of formalism treats
concepts, such as architectural architectural description as a
connection, hierarchical architectural language issue and applies
representation, and architectural traditional techniques for
style. Ideally such formalisms would representing the semantics of
provide a deductive basis for languages.
analyzing systems at an architectural
level. For example, such a theory
might provide rules for determining
when an architectural description is
well formed.
Formalizing the Architecture of a
Specific System
Starting with Architectural Design:
Many software systems commence with architectural design.
Descriptions are typically informal due to challenges in expressing
abstractions at this design level.

Challenge with Current Languages and Tools:

Module interconnection languages and programming language modularization
facilities often fall short.
They necessitate system designers to translate architectural abstractions into
low-level primitives provided by the programming language.

Problem Resolution:
Utilize a formal specification language to describe the architecture of a
specific system.
 Illustration with a Specific Object:
Describe the precise architecture of an oscilloscope developed at
Tektronix, Inc.
Objective: Provide an accurate characterization of the system-level
functions determining the overall product functionality.

Challenges in Designing Complex Systems:

Current instrumentation systems, like digital oscilloscopes, involve
complex software systems with multiple processors, sophisticated user
interfaces, and interfaces to external computing networks.

System Architecture:
Developed an architectural framework decomposing overall processing
into a graph of transformations.
System viewed as an instance of a pipe-and-filter architecture style
(refer to Section 3.2).
 User Interface and Data Processing Details:
Each individual transformer has an interface for user adjustment through
parameter settings.
Example: The transformation determining how a waveform is displayed
is parameterized by scaling and positioning factors.

Specific System Architecture Description:

Specify each component transformation (or filter), their
interconnections, and the communicated data between them.
Figure 6.1 illustrates the architecture of a small (and greatly simplified)
portion of an oscilloscope, akin to informal diagrams an engineer might
draw to describe a specific system's architecture.
 To formalize this, we begin by characterizing the data that the system
manipulates. We model signals, waveforms, and traces as functions over the
primitive domains of time, volts , and screen coordinates. Signals (S) represent the
inputs to the oscilloscope, wave- forms (W) the data as it is stored internally, and
traces (T) the pictures shown to a user.

Signal == AbsTime → Volts

Waveform == AbsTime → Volts
Trace == Horiz→ Vert
 02
Formalizing an
Architectural Style
Drawbacks
Drawbacks and problems associated with a previously outlined specification

Leaving questions about possible design

1 Implicit Underlying Style
elaborations.

2 High Abstraction Level This can lead to overlooking critical aspects

3 Implicit Architectural Connection Making it challenging to examine

Formalizing architecture styles
Address problems by formalizing Pipe-and-filter architecture style.

Step 1 Define filters The basic components of the architecture.

Step 2 Define pipes The basic connectors between filters.

Combining
Show how pipes and filter are combine to form a complete
Step 3 filters and
system.
pipes

For each of these three aspects of the architecture, we characterize both its static and its dynamic
properties.
Filters
○ Definition: A filter is characterized by its name, ports (input and output), and program.
○ Program: The program defines the filter's behavior as a state machine with legal states, a start
state, and a transition function that maps inputs to outputs while potentially changing the state.
○ State: The state of a filter includes the current program state, internal state, and data waiting to
be read or written.
○ Computation Step: A computational step involves reading data from inputs, performing
transformations based on the program and internal state, and writing data to outputs.
Pipes

● Definition: A pipe is a typed connection between two filter ports, one output and one input.
● State: The state of a pipe consists of two parts: delivered data and data waiting for delivery.
● Properties: Pipes are self-contained and independent of filters. Data is not altered or reordered during
transmission.
● Computation Step: A computational step involves delivering some data from the source port to the
sink port.
Pipe-and-Filter system
○ Definition: Composed of a collection of filters and pipes.
○ Consistency requirements:
■ Each filter has a unique name.
■ No "dangling" pipes (every pipe connects two ports).
■ Ports connect to at most one pipe.
■ Not all ports need to be connected (allows open systems and hierarchical composition).
○ State: Defined by the states of its filters and pipes, including port and pipe states.
○ Computation step: Either a filter computation step (executing a single filter) or a pipe
transmission step.
○ System computation: A sequence of steps starting from a defined start state.
■ Start state: all filters in start state, pipes empty, output ports empty (unconnected ports
not required to be empty).
03
Formalizing an
Architectural Design
Space - Toward a Theory
of Software Architecture
 Formalizing an Architectural Design Space

The challenge of varying

interpretations of architectural
idioms in software architecture
and missed opportunities for
knowledge sharing.
 Formalizing an Architectural Design Space

It uses implicit invocation systems as

an example and proposes starting
with a basic set of events, methods,
and component names to refine the
abstraction for specific systems,
making relationships between
architectures more precise and
enabling designers to learn from each
other's experiences.
Formal model for architectural components, emphasizing
implicit invocation mechanisms in software .

1 Abstract Architectural Model

2 Event System

3 Specialization for MVC

4 Specialization for Field System

5 Benefits of Formalization
1.Abstract Architectural Model

The model represents architectural

components as entities with names,
interfaces (methods and events), and
relationships between events and
methods.
2.Event System

It defines an event system

consisting of components and an
event manager. The event manager
associates events with methods to
be invoked when the event occurs.
3.Specialization for MVC

The Model-View-Controller (MVC)

paradigm is used as an example to
specialize the abstract model. In MVC,
objects can register as dependents of
other objects, and when a change event
occurs, the update method is invoked in
each dependent. This specialization
limits events to "changed" and
associates them with corresponding
update methods.
4.Specialization for Field System
Another example of specialization is provided
for the Field System, where tools
communicate by broadcasting events and
other tools can register patterns to indicate
which events to react to and which methods
to invoke. This is achieved through a pattern
matching mechanism.
5.Benefits of Formalization:

The formalization allows for:

+Identifying common architectural abstractions across
different systems.
+Showing similarities between different systems by
demonstrating how they are elaborations of the same
basic architecture.
+Providing a template for making comparisons between
different architectural styles.
+Serving as a basis for further specializations and
computational models.
+Abstracting general patterns to provide a framework
for specifying architectural styles.
Overall
the approach provides a structured way to
analyze and compare various architectural
styles and systems, demonstrating how
different systems can be understood within
a unified formal framework.
 Toward a Theory of Software Architecture

Researchers seek to define software

architecture fundamentals, including
components and connectors. Section
8.3 introduces WRIGHT, a formal
language for precise characterization of
connectors and verification of
architectural consistency, addressing
complex interactions and
decomposition.
 04
What Next ? - Z
Notation Used in This
Chapter
What Next ?
1. Benefits of Architectural Formalism:
■ Specific system formalism precisely documents designs.
■ Architectural style formalism characterizes common abstractions.
■ Formal theory aids in understanding architectural composition.
1. Beyond Computational Aspects:
■ Concerns extend to performance, accuracy, security, and reliability.
1. Extension of Specifications:
■ Formal techniques should include diverse properties while maintaining functional specification qualities.
1. Alignment with Modular Structure:
■ Generalized specifications should mesh with program modularity.
1. Flexible Precision:
■ Specifications should allow variable precision levels to avoid excessive constraints.
1. Precision and Tractability:
■ Specifications must be both precise and mathematically tractable for reliable analysis.
1. Unified Methodology:
■ Desire for a unified methodology to extend existing methods for new properties.
1. Ongoing Development:
■ Formal underpinnings for software architecture are a multifaceted and evolving endeavor.
Notation Used in This Chapter
1. Z Notation Overview:
■ Z notation is a mathematical language developed at the University of Oxford for software
engineering.
■ Rooted in first-order logic and set theory, it uses standard logical and set-theoretic operations.
1. Z Specification Structure:
■ A Z specification includes mathematical text and prose.
■ Mathematical text consists of types, predicates, and given types (primitive types).
1. Type Construction in Z:
■ Z introduces types using primitive and given types.
■ Elements of a type are declared using a colon (:), and set membership is denoted by E.
1. Type Constructors and Relations:
■ Z employs type constructors like powerset, cross-product, sequences, and bags.
■ Special subsets, including relations and functions between types, are defined for use in
specifications.
1. Schema and Modular Specification:
■ Z has a schema type constructor for defining bindings between identifiers and values.
■ Schemas can include invariants and facilitate a modular approach to specifications through
inclusion.
Thanks
Do you have any questions?
hoai.2174801030136@vanlanguni.vn

CREDITS: This presentation template was created by

Slidesgo, and includes icons by Flaticon, infographics &
images by Freepik and content by Sandra Medina