1 / 22

Declaratively Codifying Software Architectures Using Virtual Software Classifications

Explore the use of "Reuse contract" approach to automate checking of software evolution conflicts at an architectural level. This study delves into declaratively mapping architectures to source code and automating conformance checks using the SOUL language integrated with Smalltalk.

ryanharris
Download Presentation

Declaratively Codifying Software Architectures Using Virtual Software Classifications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

  13. 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. Example: architecture of a rule interpreter

  16. 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).

  17. 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).

  18. Composite components:sub-architectures

  19. 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>,<>).

  20. 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

  21. ? ? 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/

More Related