1. Introduction
Proposed Work
Conclusion and Future Work
Selecting and Formalizing an Architectural
Style: A Comparative Study
Ashish Kumar Dwivedi & Santanu Kumar Rath
August 8, 2014
Department of Computer Science and Engineering
National Institute of Technology, Rourkela
Rourkela - 769008, India
Ashish Kumar Dwivedi NIT, Rourkela

2. Introduction
Proposed Work
Conclusion and Future Work
Outline
1 Introduction
Formal Methods and Model Checking
Motivation and Objective
Literature Survey
2 Proposed Work
Selecting an Appropriate Style
Formalizing C2 Style using Alloy and Promela
Comparison between Alloy and Promela
3 Conclusion and Future Work
Ashish Kumar Dwivedi NIT, Rourkela

3. Introduction
Proposed Work
Conclusion and Future Work
Formal Methods and Model Checking
Motivation and Objective
Literature Survey
Formal Methods
Applied Mathematics for modeling and analyzing complex
systems
Mathematical Models for system behaviors.
Logical notations for specifying properties of programs.
Methods for checking that program meets its desired
specification.
Formal methods are a set of techniques:
Formal specification
Specification analysis and proof
Transformational development
Formal verification
Formal = based on rigorous mathematical logic concepts.
It is machine-readable, and hence can be used by a
verification algorithm.
Each complex system: Require precise specifications.
Ashish Kumar Dwivedi NIT, Rourkela

4. Introduction
Proposed Work
Conclusion and Future Work
Formal Methods and Model Checking
Motivation and Objective
Literature Survey
Formal Methods in Computer Science
Ashish Kumar Dwivedi NIT, Rourkela

5. Introduction
Proposed Work
Conclusion and Future Work
Formal Methods and Model Checking
Motivation and Objective
Literature Survey
Model checking
In software and hardware design of complex systems, more
time and effort are spent on verification than on
construction.
Model checking is an automated technique that, given a
finite-state model of a system and a formal property,
systematically checks whether this property holds for (a
given state in) that model.
It is a verification technique that explores all possible
system states in a brute-force manner.
Even the subtle errors that remain undiscovered using
simulation and testing can potentially be revealed using
model checking.
Ashish Kumar Dwivedi NIT, Rourkela

6. Introduction
Proposed Work
Conclusion and Future Work
Formal Methods and Model Checking
Motivation and Objective
Literature Survey
Model checking Approach
Ashish Kumar Dwivedi NIT, Rourkela

7. Introduction
Proposed Work
Conclusion and Future Work
Formal Methods and Model Checking
Motivation and Objective
Literature Survey
Motivation
1 Functionality Issues: Growing Size & Complexity
2 Non-functional Requirement issues: Availability,
Reliability, Safety, Security
3 Functional requirement Issues: Time-to-delivery, Costs
4 Maintenance Issues: Requirements change over time
Ashish Kumar Dwivedi NIT, Rourkela

8. Introduction
Proposed Work
Conclusion and Future Work
Formal Methods and Model Checking
Motivation and Objective
Literature Survey
Contd..
Ashish Kumar Dwivedi NIT, Rourkela

9. Introduction
Proposed Work
Conclusion and Future Work
Formal Methods and Model Checking
Motivation and Objective
Literature Survey
Objective
The objective of this study to select an appropriate style
for the case study i.e., Cargo Router System.
After selecting an appropriate style for cargo router
system, it is formalized using formal modeling languages
Alloy and Promela.
For the model checking of these formal notations,
automated verifiers such as Alloy Analyzer and SPIN are
used.
At the end of this study, comparison of performance
between modeling languages Alloy and Promela as well as
associated tools such as Alloy Analyzer and SPIN is
performed.
Ashish Kumar Dwivedi NIT, Rourkela

10. Introduction
Proposed Work
Conclusion and Future Work
Formal Methods and Model Checking
Motivation and Objective
Literature Survey
Modeling and verifying software architectural style
Kim and Garlan [4] have mentioned about mapping of an
architectural style into a relational model.
They expressed an architectural style using Alloy can be
checked for properties such as whether a style is consistent
whether a style satisfies some logical constraints
whether two styles are compatible for composition
Wong et al. [5] presented a technique to support the design
and verification of software architectural models.
Model checking of these architectural notations is done by
Alloy Analyzer.
They illustrated use of the architecture style library in
modeling and verifying a complex system that utilizes
multi-style structures.
Ashish Kumar Dwivedi NIT, Rourkela

11. Introduction
Proposed Work
Conclusion and Future Work
Selecting an Appropriate Style
Formalizing C2 Style using Alloy and Promela
Comparison between Alloy and Promela
Selecting an Appropriate Style
Table: Categorization and evaluation of architectural styles
QPs / Styles BS PF VM CS PS EB PP C2 CORBA
Efficiency 0 0 - - 0 0 + + -
Complexity 0 0 0 0 + + ++ + ++
Scalability 0 + + + 0 + + + 0
Heterogeneity - - + - + + 0 ++ ++
Adaptability 0 - 0 0 + 0 0 + ++
Portability 0 0 ++ 0 ++ + 0 ++ +
Reliability 0 0 0 - - - ++ + 0
Security 0 0 0 ++ + 0 + 0 -
Ashish Kumar Dwivedi NIT, Rourkela

12. Introduction
Proposed Work
Conclusion and Future Work
Selecting an Appropriate Style
Formalizing C2 Style using Alloy and Promela
Comparison between Alloy and Promela
Architectural Style C2
A software architecture comprises a set of principal design
decisions that deals with high-level structure of a system.
An architectural style has been characterized by their
control-flow and data-flow patterns, as well as allocation of
functionality between components and connectors.
Many ADLs are available for modeling notations to
support architecture based development.
But these ADLs lack proper tool support in terms of
formal modeling and visualization.
C2 is a message-based architectural style for developing
flexible and extensible software system.
Communication among components is done by implicit
invocation.
Ashish Kumar Dwivedi NIT, Rourkela

13. Introduction
Proposed Work
Conclusion and Future Work
Selecting an Appropriate Style
Formalizing C2 Style using Alloy and Promela
Comparison between Alloy and Promela
Design of cruise control system using C2
Ashish Kumar Dwivedi NIT, Rourkela

14. Introduction
Proposed Work
Conclusion and Future Work
Selecting an Appropriate Style
Formalizing C2 Style using Alloy and Promela
Comparison between Alloy and Promela
Formalizing C2 style using Alloy
abstract sig CargoRouter { comps : set Component,
conns : set Connector, c2cons : set C2Connector }
sig Component { ports : set Port }
sig Connector { roles : set Role,
attach : Role one − > one Port }
sig C2Connector { c2port : set Port }
sig Port { component : one Component,
owner : one (Component + C2Connector) }
sig Role { connector : one Connector,
owner : one Connector, attachTo : lone Port }
fact { ∼ports = component && ∼roles = connector }
fact { all c1, c2 : Connector |
some role1, role2 : Role |
some port1, port2 : Port |
role1 − > port1 in c1.connect
&& role2 − > port2 in c2.connect }
Ashish Kumar Dwivedi NIT, Rourkela

15. Introduction
Proposed Work
Conclusion and Future Work
Selecting an Appropriate Style
Formalizing C2 Style using Alloy and Promela
Comparison between Alloy and Promela
Contd..
fact { all role1, role2 : Role |
all port1, port2 : Port |
all c1, c2 : Component |
roleConnectPort[role1, port1] &&
roleConnectPort[role2, port2] &&
holder[port1] = c1 => holder[port2] ! = c2 }
pred roleConnectPort [role : Role, port : Port]
{ role − > port in Connector.connect }
pred compConnectC2Conn [comp : Component,
c2con : C2Connector]
{ some role1, role2 : Role | some port1, port2 : Port |
disj[role1, role2] && roleConnectPort[role1, port1]
&& holder[port1] = comp
&& roleConnectPort[role2, port2]
&& holder[port2] = c2con }
run compConnectC2Conn for 3
Ashish Kumar Dwivedi NIT, Rourkela

16. Introduction
Proposed Work
Conclusion and Future Work
Selecting an Appropriate Style
Formalizing C2 Style using Alloy and Promela
Comparison between Alloy and Promela
Meta Model generated by AA
Ashish Kumar Dwivedi NIT, Rourkela

17. Introduction
Proposed Work
Conclusion and Future Work
Selecting an Appropriate Style
Formalizing C2 Style using Alloy and Promela
Comparison between Alloy and Promela
Formalizing C2 style using Promela
chan request = [0] of {byte};
chan notify = [0] of {byte};
mtype data = welcome to CargoRouter;
active [2]proctype Sender() {
byte topLevelComp;
chan replyChannel;
end :
do
:: request ? topLevelComp, replyChannel − >
printf ( %d%d , topLevelComp − 2, pid);
replyChannel ! pid, topLevelComp, data
od }
active [4]proctype Receiver() {
byte bLevelComp;
end :
do
request ! pid, notify[ pid − 2];
reply[ pid − 2] ? bLevelComp, data;
printf ( %d%d%d , data, bLevelComp, pid − 2);
od }
Ashish Kumar Dwivedi NIT, Rourkela

18. Introduction
Proposed Work
Conclusion and Future Work
Selecting an Appropriate Style
Formalizing C2 Style using Alloy and Promela
Comparison between Alloy and Promela
Verification result generated by SPIN
Ashish Kumar Dwivedi NIT, Rourkela

19. Introduction
Proposed Work
Conclusion and Future Work
Selecting an Appropriate Style
Formalizing C2 Style using Alloy and Promela
Comparison between Alloy and Promela
Comparison between Alloy and Promela
Table: Comparison on the basis of verification process
S. No. Attributes Alloy/Alloy Analyzer Promela/SPIN
1. Application scope Specification and Verification Specification and Verification
2. Time elapsed 265 ms 0.123 second
3. Memory used Pre-Defined 9.032
4. Reachable state space User defined Automatically generated
5. Automated reasoning High Medium
6. Temporal logic Not support Support LTL
7. State structure Very good Displayed poorly
8. Traces Explore short traces Explore all traces
9. Closeness to Implementation Medium Medium
10. Soundness Good Good
Ashish Kumar Dwivedi NIT, Rourkela

20. Introduction
Proposed Work
Conclusion and Future Work
Conclusion
In order to prove the correctness of the system
requirements, large number of verification techniques such
as reachability analysis, automated theorem proving, model
checking etc. are available.
Styles are generally used to promote design reuse, code
reuse, and support interoperability between two different
styles.
Hence, formalizing an architectural style provides style
consistency and validity of configuration.
Formal proof can replace many test cases.
It can increases product quality and reduces the
maintenance cost.
Ashish Kumar Dwivedi NIT, Rourkela

21. Introduction
Proposed Work
Conclusion and Future Work
Future Work
Our approach can be extended by considering the
application of different models in other complex
architectural styles such as CORBA (Common Object
Request Broker Architecture), and REST
(REpresentational State Transfer) architecture etc.
In future there is a plan to verify basic properties such as
reachability and termination of business process.
Ashish Kumar Dwivedi NIT, Rourkela

22. Introduction
Proposed Work
Conclusion and Future Work
References I
1 Jim Woodcock, Peter Gorm Larsen, Juan Bicarregui, and John Fitzgerald.
Formal methods: Practice and experience.
ACM Comput. Surv., 41(4):19:1–19:36, October 2009.
2 Daniel Jackson.
Software Abstractions: Logic, Language, and Analysis.
The MIT Press, 2006.
3 M. Ben-Ari, Principles of the Spin model checker. Springer, 2008.
4 Jung Soo Kim and David Garlan.
Analyzing architectural styles.
Journal of Systems and Software, 83(7):1216–1235, 2010.
5 Stephen Wong, Jing Sun, Ian Warren, and Jun Sun.
A scalable approach to multi-style architectural modeling and verification.
In Engineering of Complex Computer Systems, 2008. ICECCS 2008. 13th
IEEE International Conference on, pages 25–34. IEEE, 2008.
Ashish Kumar Dwivedi NIT, Rourkela

23. Introduction
Proposed Work
Conclusion and Future Work
Ashish Kumar Dwivedi NIT, Rourkela

24. Introduction
Proposed Work
Conclusion and Future Work
Ashish Kumar Dwivedi NIT, Rourkela