1569973863_IC3

IntroductionProposed Work

Conclusion and Future Work

Selecting and Formalizing an ArchitecturalStyle: A Comparative Study

Ashish Kumar Dwivedi & Santanu Kumar Rath

August 8, 2014

Department of Computer Science and EngineeringNational Institute of Technology, Rourkela

Rourkela - 769008, India

Ashish Kumar Dwivedi NIT, Rourkela



Outline

1 IntroductionFormal Methods and Model CheckingMotivation and ObjectiveLiterature Survey

2 Proposed WorkSelecting an Appropriate StyleFormalizing C2 Style using Alloy and PromelaComparison between Alloy and Promela

3 Conclusion and Future Work




Formal Methods and Model CheckingMotivation and ObjectiveLiterature Survey

Formal Methods

Applied Mathematics for modeling and analyzing complexsystems

Mathematical Models for system behaviors.Logical notations for specifying properties of programs.Methods for checking that program meets its desiredspecification.

Formal methods are a set of techniques:

Formal specificationSpecification analysis and proofTransformational developmentFormal verification

Formal = based on rigorous mathematical logic concepts.

It is machine-readable, and hence can be used by averification algorithm.Each complex system: Require precise specifications.





Formal Methods in Computer Science





Model checking

In software and hardware design of complex systems, moretime and effort are spent on verification than onconstruction.

Model checking is an automated technique that, given afinite-state model of a system and a formal property,systematically checks whether this property holds for (agiven state in) that model.

It is a verification technique that explores all possiblesystem states in a brute-force manner.

Even the subtle errors that remain undiscovered usingsimulation and testing can potentially be revealed usingmodel checking.





Model checking Approach

Fig 1: Schematic view of the model-checking approachAshish Kumar Dwivedi NIT, Rourkela




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





Contd..





Objective

The objective of this study to select an appropriate stylefor the case study i.e., Cargo Router System.

After selecting an appropriate style for cargo routersystem, it is formalized using formal modeling languagesAlloy and Promela.

For the model checking of these formal notations,automated verifiers such as Alloy Analyzer and SPIN areused.

At the end of this study, comparison of performancebetween modeling languages Alloy and Promela as well asassociated tools such as Alloy Analyzer and SPIN isperformed.





Modeling and verifying software architectural style

Kim and Garlan [4] have mentioned about mapping of anarchitectural style into a relational model.

They expressed an architectural style using Alloy can bechecked for properties such as whether a style is consistentwhether a style satisfies some logical constraintswhether two styles are compatible for composition

Wong et al. [5] presented a technique to support the designand verification of software architectural models.

Model checking of these architectural notations is done byAlloy Analyzer.They illustrated use of the architecture style library inmodeling and verifying a complex system that utilizesmulti-style structures.




Selecting an Appropriate StyleFormalizing C2 Style using Alloy and PromelaComparison 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 -





Architectural Style C2

A software architecture comprises a set of principal designdecisions that deals with high-level structure of a system.

An architectural style has been characterized by theircontrol-flow and data-flow patterns, as well as allocation offunctionality between components and connectors.

Many ADLs are available for modeling notations tosupport architecture based development.

But these ADLs lack proper tool support in terms offormal modeling and visualization.

C2 is a message-based architectural style for developingflexible and extensible software system.

Communication among components is done by implicitinvocation.





Design of cruise control system using C2





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 }





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





Meta Model generated by AA





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, dataod }

active [4]proctype Receiver() {byte bLevelComp;end :dorequest ! pid , notify[ pid − 2];reply[ pid − 2] ? bLevelComp, data;printf (′′%d%d%d ′′, data, bLevelComp, pid − 2);od }





Verification result generated by SPIN





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




Conclusion

In order to prove the correctness of the systemrequirements, large number of verification techniques suchas reachability analysis, automated theorem proving, modelchecking etc. are available.

Styles are generally used to promote design reuse, codereuse, and support interoperability between two differentstyles.

Hence, formalizing an architectural style provides styleconsistency and validity of configuration.

Formal proof can replace many test cases.

It can increases product quality and reduces themaintenance cost.




Future Work

Our approach can be extended by considering theapplication of different models in other complexarchitectural styles such as CORBA (Common ObjectRequest Broker Architecture), and REST(REpresentational State Transfer) architecture etc.

In future there is a plan to verify basic properties such asreachability and termination of business process.




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. 13thIEEE International Conference on, pages 25–34. IEEE, 2008.








1569973863_IC3

Documents