Software architecture for reactive systems (introduction) Lus - - PowerPoint PPT Presentation

software architecture for reactive systems introduction
SMART_READER_LITE
LIVE PREVIEW

Software architecture for reactive systems (introduction) Lus - - PowerPoint PPT Presentation

Software architecture for reactive systems (introduction) Lus Soares Barbosa Jos Proena HASLab - INESC TEC Universidade do Minho Braga, Portugal February 2018 Software Engineering revisited Software Architecture The Courses


slide-1
SLIDE 1

Software architecture for reactive systems (introduction)

Luís Soares Barbosa José Proença

HASLab - INESC TEC Universidade do Minho Braga, Portugal

February 2018

slide-2
SLIDE 2

Software Engineering revisited Software Architecture The Course’s Approach Revisions

For today

Overview of Software Architecture Its view by MFES profile Pragmatics (evaluation, etc.)

http://arca.di.uminho.pt/ac-1718

2 / 16

slide-3
SLIDE 3

Software Engineering revisited Software Architecture The Course’s Approach Revisions

Software Engineering

Software development as one of the most complex but at the same time most effective tasks in the engineering of innovative applications:

  • Software drives innovation in many application domains
  • Appropriate software provides engineering solutions that can

calculate results, communicate messages, control devices, animate and reason about all kinds of information

  • Actually software is becoming everyware ...

3 / 16

slide-4
SLIDE 4

Software Engineering revisited Software Architecture The Course’s Approach Revisions

Software Engineering

Informal requirements formalisation

S

Formalized system requirements

S1 S2 S4 S3

R 1 R2 R R

architecture realization deliver

R1 R2 R4 R3

Requirements Engineering Validation Architecture design Architecture verification S = S1⊗S2⊗S3⊗S4

Component implementation verification R1 ⇒ S1 R2 ⇒ S2 R3 ⇒ S3 R3 ⇒ S4

Integration R = R1⊗R2⊗R3⊗R4

R

integration

System delivery System verification R ⇒ S

(illustration from [Broy, 2007])

4 / 16

slide-5
SLIDE 5

Software Engineering revisited Software Architecture The Course’s Approach Revisions

Software Engineering

So, ... yet another module in the MFES profile? Software architecture for reactive systems characterised by

  • a methodological shift: an architectural perspective
  • a focus: on reactive systems

5 / 16

slide-6
SLIDE 6

Software Engineering revisited Software Architecture The Course’s Approach Revisions

Challenges

Such trends entails a number of challenges to the way we think about SA

  • new target: need for an architectural discipline for reactive

systems (often complex, time critical, mobile, cyber-physical, etc ...)

  • from composition to coordination (orchestration)
  • relevance of wrappers and component adapters: integration vs

incompatible assumptions about component interaction

  • reconfigurability
  • continued interaction as a first-class citizen and the main form
  • f software composition

6 / 16

slide-7
SLIDE 7

Software Engineering revisited Software Architecture The Course’s Approach Revisions

Reactive systems

Reactive system

system that computes by reacting to stimuli from its environment along its overall computation

  • in contrast to sequential systems whose meaning is defined by the

results of finite computations, the behaviour of reactive systems is mainly determined by interaction and mobility of non-terminating processes, evolving concurrently.

  • observation ≡ interaction
  • behaviour ≡ a structured record of interactions

7 / 16

slide-8
SLIDE 8

Software Engineering revisited Software Architecture The Course’s Approach Revisions

Reactive systems

Concurrency vs interaction

x := 0; x := x + 1 | x := x + 2

  • both statements in parallel could read x before it is written
  • which values can x take?
  • which is the program outcome if exclusive access to memory and

atomic execution of assignments is guaranteed?

8 / 16

slide-9
SLIDE 9

Software Engineering revisited Software Architecture The Course’s Approach Revisions

Our approach

There is no general-purpose, universally tailored, approach to architectural design of complex and reactive systems Therefore, the course

  • introduces different models for reactive systems
  • discusses their architectural design and analysis
  • with (reasonable) tool support for modelling and analysis

9 / 16

slide-10
SLIDE 10

Software Engineering revisited Software Architecture The Course’s Approach Revisions

Syllabus

  • Introduction to software architecture
  • Background
  • Introduction to transition systems (mCRL2)
  • Introduction to modal, hybrid and dynamic logic (mCRL2)
  • Models and calculi of reactive systems
  • Timed (with real time constraints) (Uppaal)
  • Architecture for reactive systems
  • Coordination-oriented architectural design
  • Paradigm: The Reo exogenous coordination model
  • Method: Compositional specification of the glue layer
  • Resource analysis of concurrent systems
  • Analysis of a Java-based language (ABS tool-set)

10 / 16

slide-11
SLIDE 11

Software Engineering revisited Software Architecture The Course’s Approach Revisions

Pragmatics ...

  • Assessment:
  • Test in June - 70 %
  • Group projects (2x) - 40 % (10+20)

http://arca.di.uminho.pt/ac-1718

  • Research context: Projects
  • Dali — 2016-18
  • n Dynamic logics for cyber-physical systems
  • Trust — 2016-18
  • n Trustworthy Software Design with Alloy

possible GRANTS available! (with INL, U. Aveiro, CWI, INESC TEC)

11 / 16

slide-12
SLIDE 12

Software Engineering revisited Software Architecture The Course’s Approach Revisions

Model checking

Recall “Especificação e Modelação”:

  • Modelling reactive systems – Kripke structures and NuSMV
  • Specification – Temporal logics (LTL and CTL/CTL∗)
  • Verification – Check if a formula holds in a system

SMV model checker

12 / 16

slide-13
SLIDE 13

Software Engineering revisited Software Architecture The Course’s Approach Revisions

What we will see

  • Labelled transition systems (LTS) as Kripke structures
  • Process algebra (not Petri Nets SMV) to define LTS
  • mCRL2 toolset to model (not SMV)
  • Equivalence of LTS
  • Modal logics – generalising temporal logics (CTL∗,CTL,LTL)
  • Using mCRL2 toolset to verify properties
  • Later: Timed-automata and UPPAAL model checker (CTL)

13 / 16

slide-14
SLIDE 14

Software Engineering revisited Software Architecture The Course’s Approach Revisions

Model

M, w | = φ – what does it mean? Model definition

A model for the language is a pair M = F, V , where

  • F = W , {Rm}m∈MOD

is a Kripke frame, ie, a non empty set W and a family Rm of binary relations (called accessibility relations) over W , one for each modality symbol m ∈ MOD. Elements of W are called points, states, worlds or simply vertices in directed graphs.

  • V : PROP −

→ P(W ) is a valuation.

Kripke structures from last semester

  • MOD = {1}
  • (S, I, R, L)

where S = W , I = {w}, R = R1, L = V

  • F = W , R

instead of F = W , {Rm}m∈MOD

14 / 16

slide-15
SLIDE 15

Software Engineering revisited Software Architecture The Course’s Approach Revisions

Example

M = 1p

a

  • a
  • 2q

b

3p,q

b

  • W = {1, 2, 3}

MOD = {a, b} Ra = {(1, 2), (1, 3)} Rb = {(2, 3), (3, 3)} V ={1 → {p} , 2 → {q} , 3 → {p, q}}

  • M, 1 |

= p means p holds in state 1

  • M, 2 |

= [b] p means p holds in every state reachable with b from 2.

15 / 16

slide-16
SLIDE 16

Software Engineering revisited Software Architecture The Course’s Approach Revisions

Key differences

Before

1p

  • 2q

3p,q

  • emphasize on states -

desired/forbidden states

  • SMV language to generate

models

  • M, 1 |

= p , M, 1 | = F G p

Now

1

a

  • a
  • 2

b

3

b

  • emphasize on actions -

desired/forbidden sequences

  • Process algebra to generate

models

  • M, 2 |

= [a] false

16 / 16