An Aspect-Oriented Strategy for Evaluating Software Architectures ...

An Aspect-Oriented Strategy for Evaluating Software Architectures that Evolve 2 March 2005

Phillip Schmidt [email protected]

© 2004-2005. The Aerospace Corporation. All Rights Reserved.

GSAW 2005

1

Agenda z z z z z

Motivation Some current strategies New aspect-oriented (AO) strategy Comparison with scenario-based approaches Experiences applying the strategy

© 2004-2005. The Aerospace Corporation. All Rights Reserved.

GSAW 2005

2

Architectural Value z

Your architectural value will be reflected in how you perceive architecture: „ „ „ „ „ „ „

z z

Strategic tool? Something in the minds of competent people? General preliminary design only, to be discarded after coding Merely drawings or documentation? An accurate, evolving reflection of the design? Something analyzable Something executable

Perceptions have consequences and risks Choose wisely

© 2004-2005. The Aerospace Corporation. All Rights Reserved.

GSAW 2005

3

Architectural Needs z

Do your architectural values address your problems?

z

Do you know you have problems?

z

Is there an architectural value gap between you and your architectural provider?

z

Architectural values are stressed when: „ „ „

Managing complex, evolving architectural relationships Architectural modeling practices are unclear Unexpected concerns arise © 2004-2005. The Aerospace Corporation. All Rights Reserved.

GSAW 2005

4

Architectural Artifact Relationships Use Cases Requirements Requirements Requirements Requirement Specification

Course of action Course of action Course of action COA step Course of action COA step COA COA step step COA COA step step COA step COA step

Test Test Procedure Test Procedure Test Procedure Procedure Code Code Code Code Test Test Procedure Test Procedure Procedure Unit Test

Unified Modeling Language Unified Modeling Language Unified (UML) Modeling (UML) Language (UML)

… … …

Class Sequence State Diagrams Diagrams Class Diagrams Sequence State Diagrams Diagrams Class Diagrams Sequence State Diagrams Diagrams Class Diagrams Sequence State Diagrams Diagrams Class Diagrams Sequence State Diagrams Diagrams Diagrams Sequence Diagrams

ICD ICD SW ICD © 2004-2005. The Aerospace Corporation. All Rights Reserved.

GSAW 2005

5

Architectural Artifacts Use Cases Requirements Requirements Requirements Requirement Specification

Allocation

Coverage Test Test Procedure Test Procedure Test Procedure Procedure

Course of action Course of action Course of action COA step Course of action COA step COA COA step step COA COA step step COA step COA step

Behavioral Integrity

Traceability

Code Code Code Code

Unified Modeling Language Unified Modeling Language Unified (UML) Modeling (UML) Language Consistency (UML)

… … …

Test Test Procedure Test Procedure Procedure Unit Test

Architecture artifacts are ICD life cycle concerns ICD SW

Class Sequence State Diagrams Diagrams Class Diagrams Sequence State Diagrams Diagrams Class Diagrams Sequence State Diagrams Diagrams Class Diagrams Sequence State Diagrams Diagrams Class Diagrams Sequence State Diagrams Diagrams Diagrams Sequence Diagrams

Completeness

ICD © 2004-2005. The Aerospace Corporation. All Rights Reserved.

GSAW 2005

6

Complexity of Requirement Evolution

Course of action dependency

Course of action steps

16 months later

© 2004-2005. The Aerospace Corporation. All Rights Reserved.

Problematic references

GSAW 2005

7

Architectural Modeling Practices (What we think we want) System Engineering Activities

Software Engineering Activities

Define assumptions Identify simplifications, tradeoffs Identify limitations Define system constraints Identify preferences Identify, analyze and manage requirements, specifications

Evaluate design tradeoffs Define concrete classes, interactions, relationships, states, activities Identify infrastructure Develop prototypes, deployment views Identify product constraints, timing Ensure traceability to requirements Integrate and Test

Analysis Model

Architectural Design (system in context) (styles, views, patterns, relationships) Design Engineering (classes, data structures) Component Layering

Design Model

What How

System Modeling (abstracted world view use cases) Informational models (data flow) Functional models (activity flow) Behavioral models (events, sequences)

Coherent, thorough, well planned representations

Abstract

Completeness, correctness

Problem domain oriented

Concrete realizations

Traceable to requirements,

Solution domain oriented © 2004-2005. The Aerospace Corporation. All Rights Reserved.

GSAW 2005

8

Architectural Modeling Practices (What tends to happen)

Software Engineering Activities

System Engineering Activities

Evaluate design tradeoffs Define concrete classes, interactions, relationships, states, activities Identify infrastructure Develop prototypes Identify preferences Ensure traceability to requirements Integrate and Test

Define assumptions Identify simplifications Identify limitations Define constraints Identify preferences Identify, analyze and manage requirements, specifications

Architectural Design (system in context) (styles, views, patterns, relationships) Design Engineering (classes, data structures) Component Layering

Analysis Model

What

Design Model

How

© 2004-2005. The Aerospace Corporation. All Rights Reserved.

GSAW 2005

9

Architectural Modeling Practices (Blurring of models)

Analysis Model Design Model

What

How

© 2004-2005. The Aerospace Corporation. All Rights Reserved.

GSAW 2005

10

Architectural Modeling Practices (What we usually get)

Architecture Model

Huh?

© 2004-2005. The Aerospace Corporation. All Rights Reserved.

GSAW 2005

11

Level of Architectural Detail z

Architectural models tend to be a mix of conceptual and implementation based information

© 2004-2005. The Aerospace Corporation. All Rights Reserved.

GSAW 2005

12

Impact Assessment of Crosscutting Concerns Use Cases Requirements Requirements Requirements Requirement Specification

ICD ICD ICD

Unified Modeling Language Unified Modeling Language Unified (UML) Modeling (UML) Language (UML)

Concern

ECP

Test Test Procedure Test Procedure Test Procedure Procedure

Course of action Course of action Course of action COA step Course of action COA step COA COA step step COA COA step step COA step COA step

Code Code Code Code

… … …

Class Sequence State Diagrams Diagrams Class Diagrams Sequence State Diagrams Diagrams Class Diagrams Sequence State Diagrams Diagrams Class Diagrams Sequence State Diagrams Diagrams Class Diagrams Sequence State Diagrams Diagrams Diagrams Sequence Diagrams

Point of interest © 2004-2005. The Aerospace Corporation. All Rights Reserved.

GSAW 2005

13

Good Intentions z

Even the “best” of architectural values can be overwhelmed by the complexity of our problems

© 2004-2005. The Aerospace Corporation. All Rights Reserved.

GSAW 2005

14

Software Architecture Realities z

We don’t know everything „ „ „

z

We can’t predict everything „ „

z

What we know may be correct, but irrelevant What we do know, may not be represented clearly Scalability of manual techniques Things change unexpectedly Unplanned feature interactions

We tend to ignore the hard stuff „ „ „ „

Non-functional requirements Conflicting operational concepts/goals Domain-specific details within commercial tools Subtle software-hardware real-time dependencies

Space architectures are handicapped by their complexity © 2004-2005. The Aerospace Corporation. All Rights Reserved.

GSAW 2005

15

Strategies for Managing Handicapped Architectures z

Ignore It: „

z

Contract It „

z

Have contractor develop the appropriate level of architectural granularity

Evangelize It „

z

Just put the required level of detail on contract

Enforce It „

z

It’s the contractor’s problem.

Motivate best practices through conferences, tutorials

Analyze It „

Stakeholder collaboration for effective automated analysis © 2004-2005. The Aerospace Corporation. All Rights Reserved.

GSAW 2005

16

Strategic Advice z

Develop analyzable architectures

z

An aspect-oriented strategy can help with assessing evolving, handicapped architectures that might not be natively analyzable.

z

Reduce architectural value gaps through aspectoriented augmentation

© 2004-2005. The Aerospace Corporation. All Rights Reserved.

GSAW 2005

17

Aspect-Oriented Assessment Periodic Deliveries of Evolving Artifacts

UML Model UML Model UML Model

Use Use Cases Use Cases Cases

Sizing, Test Reqts Sizing, Timing, Test Reqts Sizing, Procedures Allocations Timing, Test Constraints Reqts Procedures Allocations Timing, Procedures Allocations Constraints Constraints

Code Code Code

Other Other Other

… Use case Meta info info Use case UML MetaAs-designed Model UML Meta Model UML (multi-viewpoint Metamodel)

Allocation Allocation info info

Project/tool-specific Profiles Project/tool-specific Project/tool-specific Profiles Profiles

Test Procedure info Test Procedure Testinfo Procedure info

UML Meta Model UML MetaAs-built Model UML Model

…

Profiles Profiles

XML

Augmentation Support

Constraint Constraint info info

Architectural handles (augmented) Re-augmentation Aspects Re-augmentation Aspects Re-augmentation Aspects

Extraction Aspects Concern Management/ Extraction Aspects Extraction Aspects

Architectural handles (native) COTS translation

Rule Sets Rule Sets

Other Assessment Tools

© 2004-2005. The Aerospace Corporation. All Rights Reserved.

Project-specific and reusable translations

GSAW 2005

18

Comparison of Scenario-based and Aspect-Oriented SW Assessments Scenario-based Strategy

Aspect Oriented Strategy

Quality attributes, prior to development interpreted in context of pre-planned provided scenarios. Feature management in terms of planned change.

Planned or unplanned concerns described as aspects of interest over an architecture. Crosscutting concerns support unplanned changes

Predictive strategy. E.g. quality attributes depend on some pre-defined scenario context.

Corrective strategy. Some quality attributes do not have a scenario context that can be predicted. Concern evaluation assumes an architectural representation.

Questioning technique with reliance on human consultation for completeness of scenario interactions; qualitative metric formulation. Good for conceptual overview of whole system

Managing complex interactions require measurement and evaluation. Quantitative emphasis on completeness. Good for investigating issues raised from questioning techniques

Use of taxonomic hierarchies to define quality attributes

Uses architectural profiles to support augmentation, derivation, monitoring, and evaluation of architectural aspects of interest.

Phased application

Periodic application during life cycle

© 2004-2005. The Aerospace Corporation. All Rights Reserved.

GSAW 2005

19

Applying an Aspect-Oriented Strategy z z

Periodic assessment more costly Concern management more general than feature management „

z

Aspect mining helpful in investigating potential problems „ „

z

Not everything is preplanned

Multiple inter-related representation spaces A code-centric viewpoint was inadequate for addressing unexpected change impacts, subsystem test dependencies, schedule/resource dependencies

UML2 profiles/XML schemas as a framework for architectural augmentation „ „ „

Requirements evolution Constraint enforcement Parameterizing real-time embedded systems for analysis

© 2004-2005. The Aerospace Corporation. All Rights Reserved.

GSAW 2005

20

References z

Aspect-Oriented Architectural Assessment „

„ z

Related UML Approaches „ „

z

Schmidt, P., Milstein, J., Alvarado, S., “An Analysis of Aerospace Software Architectures Using Aspect-Oriented Programming Principles,” ATR2004(8343)-1, 28 May 2004. Schmidt, P. “Representing and Evaluating Software-Intensive Architectures that Evolve,” ATR-2004(8343)-3, 30 Sep 2004. Selonen,P., Xu, J. “Validating UML Models against Architectural Profiles,” ESEC/FSE 2003, September 1-5, 2003, Helsinki, Finland Hakala,M.,et al. “Annotating Reusable Software Architectures with Specialization Patterns,” http://practice.cs.tut.fi

Scenario-Based Approaches „ „ „

Bass, L., Clements, P., Kazman R., Software Architecture in Practice, Addison Wesley, 1998. Bosch J., Design and use of Software Architectures: Adopting and evolving a product-line approach, Addison Wesley, 2000. Clements, P., Kazman, R., Klein, M. Evaluating Software Architectures: Methods and Case Studies, Addison Wesley, 2001.

© 2004-2005. The Aerospace Corporation. All Rights Reserved.

GSAW 2005

21

Backup Charts

© 2004-2005. The Aerospace Corporation. All Rights Reserved.

GSAW 2005

22

REACT Implementation Elements Analysis Results

REACT Plug-ins

Eclipse

REACT Augmentation

UML 2.0 Model

Model Extractor

Derivation/Analysis Aspects Project-Specific Aspects REACT Profile Augmentation Aspects Project-Specific Profile Augmentation Aspects Sequence-State Diagram Support Aspects

Project-Specific Augmentation

Model Execution and Dynamic Assessment Tools

UML Profiles UML 2.0 Reflexive Editor

UML 2.0 Metamodel

RTPS Profile

Analysis Results

OMG Based: Schedulability, performance Timing, Resources, etc.

REACT Profile

REACT Representation

Environment Dynamic Assessment Requirements Other Augmentation

Eclipse Modeling Framework

Project-Specific Profiles

Contractor-provided

Sequence Diagram

Domain-Specific

State Diagrams Other Schemas

Ecore XML schemas

Requirements

Use cases

Eclipse Environment Eclipse Support

REACT Data REACT-Implementation REACT-generated

Model Generator Requirement Visualization

UML 1.x Models

Config Config Files Config Files Files

RTPS Augmentation

Project Data

Code

Other

© 2004-2005. The Aerospace Corporation. All Rights Reserved.

GSAW 2005

23