The document discusses a model-driven architecture evaluation focusing on the structure of software systems and the relationships among components. It emphasizes the importance of using scenarios to validate design usability and consistency through architecture evaluation, akin to software testing. The evaluation process aims to ensure that the scenarios cover all relationships and interactions within the model.

1. Quick & Dirty
Model Driven
Architecture Evaluation
@SteveBattle
Sysemia

2. Software Architecture
“The software architecture of a
program or computing system is the
structure or structures of the
system, which comprise software
components, the externally visible
properties of those components, and
the relationships among them.”
Software architecture in practice,
Len Bass, Paul Clements, Rick Kazman

3. JetBrains MPS: UML Model
cmp Component Model
Foo
Bar
Baz

4. • “The reviewers brainstorm
scenarios for using the design to
solve problems they expect to
face.”
• “The resulting set of scenarios
operationally defines what it
means for the design to be
usable.”
• “If it performs well under the
adopted scenarios, then the design
has passed the review.”
ARID: Active Reviews for
Intermediate Design
uc Component Model
User
Foobar

5. JetBrains MPS: Use-Cases &
Scenarios

6. Completeness &
consistency evaluation
cmp Component Model
Foo
Bar
Baz



• Consistency:
scenarios exercise only
the relations in the
model
• Completeness:
scenarios exhaust all
the relationships in
the model

7. Scenarios as Unit Tests*
“Architecture evaluation is a form of
artifact validation, just as software
testing is a form of code validation.”
1. Initially, <n1,v1>  bar.data
2. foo receives v1 following baz.get(n1)
3. Following, baz.put(n1,v1), <n1,v1>  baz.data
4. Scenario goal: <n1,v1>  baz.data 
* On my wish list

8. The Last Slide
Thanks 
@SteveBattle
Sysemia