Declaratively Codifying Software Architectures Using Virtual Software Classifications

1. Declaratively Codifying Software Architectures Using Virtual Software Classifications Kim Mens, Roel Wuyts, Theo D’Hondt Programming Technology Lab Vrije Universiteit Brussel Brussels, Belgium TOOLS Europe 1999, June 7-10, Nancy, France

2. Research motivation • We are interested in software evolution • “Reuse contract” approach supports automated checking of evolution conflicts • Reuse contracts have been applied to implementation and design level • Can reuse contracts be applied to architectural level? • …

3. Research motivation • ... • Can reuse contracts be applied to reason about conflicts in between levels? • Ph.D. thesis: • Assess impact of an evolving design or implementation on an existing architecture • Assess impact of an evolving architecture on an existing design or implementation

4. First step: conformance checking to architectures • Architectural mismatch and erosion • architectural models do not match their actual realization in source code • source code “drifts away” from architecture • A formalism is needed to • codify software architecture at a sufficiently abstract level • automatically check conformance of source code to the software architecture

5. Followed approach • Architectural model • components (primitive and composite) • connectors (relations between components) • declarative mapping to source code • Automated conformance checking of source code to architectural model • Medium = SOUL, a reflective declarative language implemented in Smalltalk

6. Followed approach: SOUL • Smalltalk Open Unification Language • PROLOG-like declarative programming language • Implemented in Smalltalk (because of its good reflective capabilities) • Logic inferencing over Smalltalk code • Integrated with Smalltalk development environment

7. SOUL Syntax:facts, rules and queries Fact isArchitectureName(ruleInterpreter). Rule usesMM(?Method1,?Method2)if methodName(?Method2,?MethodName2), isSend(?MethodName2,?Method1). Query isArchitectureName(compiler). Query usesMM(?Method1,?Method2). Query checkArchitecture(ruleInterpreter).

8. SOUL Syntax:symbiosis with Smalltalk Fact defaultTransitiveClosure([3]). Rule class(?C) ifconstant(?C),[SOULExplicitMLI current isClass: ?C]. Rule class(?C) ifvariable(?C),generate(?C,[ SOULExplicitMLI current allClasses ]). Query method([String],?M), methodName(?M,[#asText]).

9. SOUL: Layered framework of rules • Core layer • primitive facts and rules of the logic language • facts and rules that reify Smalltalk source code artifacts: class(?Class) method(?Class,?Method) • Basic layer • implement language-independent predicatesusesMM(?M1,?M2) hierarchy(?Super,?Sub) • Design layer • Architectural layer

10. Followed approach: architectural model • Components: • Primitive components • defined in terms of virtual classifications • Composite components • defined in terms of a sub-architecture • Connectors • high-level logic relationships among components • Declarative mapping to source code

11. Architecture of a rule interpreter

12. Primitive components:virtual classifications • Software classification • is a set of related software artifacts • can contain artifacts spread throughout code • one artifact can belong to many classifications • “Virtual” software classifications • are special software classifications that “compute” their elements • map architectural components to source-code artifacts and dependencies

14. Connector = relationship among virtual classifications • Describe high level logic relationship such as: “uses”, “creates”, “accesses”, … • Relationships over sets of software artifacts • simple: based on source code dependencies • more complex: transitive closures, programming conventions, design styles, … • combinations of more primitive relationships • Have a source and target cardinality (,)

15.  

16. Example: architecture of a rule interpreter

17. Primitive components:virtual classifications Rule methodIsClassifiedAs(?M,ruleSelection) ifclassIsClassifiedAs(?C, soulClass),classImplements(?C,[#unifyingClauses:],?M). Rule classIsClassifiedAs(?C,input) ifclassIsClassifiedAs(?C,soulApplication),methodIsClassifiedAs(?M,ruleInterpreter),usesCM(?Class,?Method).

18. Followed approach:conformance checking • Query checkArchitecture(ruleInterpreter). • uses(all,input,some,queryInterpreter). • classification(input,?I),classification(queryInterpreter,?Q) •  ?A1  ?I : ?A2  ?Q : uses(?A1,?A2) • Rule uses(?A1,?A2) if method(?A1), method(?A2), usesMM(?A1,?A2).

19. Composite components:sub-architectures

20. Architectural patterns Rule architecture(pipeAndFilter,?Filters,?Pipes)if isFiniteList(?Filters),pipeAndFilter(?Filters,?Pipes). Rule pipeAndFilter( <?Filter1,?Filter2|?Filters>, <uses(?Filter1,?Filter2)|?Pipes>)if pipeAndFilter(<?Filter2|?Filters>,?Pipes). Fact pipeAndFilter(<?LastFilter>,<>).

21. Future work • More experiments / case-studies needed. • Reuse contracts for architectures • Ph.D. on unanticipated architectural evolution • SOUL as a general medium to express design as an explicit abstraction of implementation

22. ? ? Questions? ? • E-mail: • kimmens@vub.ac.be • rwuyts@vub.ac.be • tjdhondt@vub.ac.be • URLs: • Reuse contracts:progwww.vub.ac.be/pools/rcs/ • SOUL:progwww.vub.ac.be/pools/soul/