UCI Research Forum

A Systems Engineering Perspective ofAspect-oriented Software Architectural Analysis

Phillip Schmidt, Ph.D.Phillip.P.Schmidt@aero.org

UCI Research Forum

Agenda

n Our Worldn Why a Systems Engineering Perspective?n REACTn Architectural Representation Challengesn Evolving REACTn Closing Remarks

UCI Research Forum

Our World is Rocket Science!n Space system architectures growing

increasingly complexn Highly interdependent legacy subsystemsn Manual inspection of hardcopy designs

ineffective in finding subtle design flawsn Increasingly difficult to make technical

tradeoff decisions based solely onqualitative judgments (e.g. withinIntegrated Product Teams)

n Architectural representation issues, object-oriented design technologies applied tolegacy RT embedded systems not wellunderstood

n Space system architectures exhibitpressure to evolven Desire to improve performance,

functionality, and program successn New environmentsn New servicesn New contexts

n Complexity and evolution raise risk

How do we managearchitectural risk?

UCI Research Forum

Challenges(Early Discovery of Architectural Risks)

Tools

Actual Intended

Weakarchitectural

tools

Unconventional,inconsistent tool

usage

DesignIncompleteness

AmbiguousInterpretation of

design intentIncompatibledesign

Limitedperformance

insight; flawedimplementation

Designevolution

errors

Ascertainingderived

architecturalinformation

On-boardfailure

Tools

Incompletetesting

Built-to

UCI Research Forum

Why a System Engineering Perspective?

n Disconnect between Vision and Reality:n Vision: Architecture is central to supporting program evolutionn Reality: Software architectural representations often

incomplete and inconsistent

n A systems engineering perspective is needed torecognize and deal with the disconnect

n Architecture is more thann what UML is todayn what Aspect-oriented programming is today (and will likely

become)n questions about code

n Architectural representation challenges awaitn Aspect-oriented architectural analysis is being used to

tackle these challenges

UCI Research Forum

Real-time Embedded Architecture-Centric Testbed(REACT)

n Architecture-Centricn Recognize importance of architectural representation

n Many formsn Frequent access

n Early discovery/feedback

n Aspect-Oriented Architectural Assessmentn Architectural development exhibits concerns that cut

across object decomposition boundariesn Support for automated management of concerns

UCI Research Forum

Architecture-Centric

n Receive contractor-provided architecture artifactsn Unified Modeling Language (UML)n Other electronic representations

n Automatically extract architectural informationn Conduct architectural assessments

n Prior to code developmentn Static Assessment

n consistency/completenessn Compare “as-designed” to “as-built” representations

n Dynamic Assessmentn Focus on critical execution issues (synchronization, priority tasking, sizing)n Create simulations of well-formed modelsn Understand logical execution behavior of architecturen Refine/re-parameterize models

n Work closely with program office/contractorn Work closely with UML vendors

UCI Research Forum

Aspect-Oriented Architectural Analysis

n Idea: Apply aspects over UML architectural domain

Architectural domain(e.g. UML and otherartifacts)

Programming languagedomain (e.g. Java)

Architecturally non-intrusive; separable viasimulation

Solutions architecturallyintrusive (completeness)

Address static ordynamic aspects

Address dynamic,execution impacts

Leverage expression ofcross-cutting concerns

Leverage expression ofcross-cutting concerns

AOAAAOP

UCI Research Forum

Architectural Aspect Types

Log all raisedexceptions;evaluate pre/postconditons

Define cross-cuttingconcerns that needto be monitored

Dynamic AssessmentAspects

Supply modelinformation basedon ICDs, otheranalysis

Add newarchitecturalinformational detail

AugmentationAspects

Collect all eventrelated information

Derive new orcustomizedarchitecturalinformation fromUML space

Derivation Aspects

Find all examplesof destroy objectusages

Perform integrity,consistency checksover UML space

Static AnalysisAspects

ExampleDescriptionAspect Type

UCI Research Forum

Real-time Embedded Architecture-Centric Testbed (REACT)Aspect-Oriented Architectural Assessment

ModelExtractor

UML ArchitecturalInformation

ModelGenerator

Architectural Representation

DynamicAssessment

ModelConfiguration

Architectural Representation

Architectural Representation

Architectural Representation

Model Executor

Static AnalysisAspects

DerivationAspects

AugmentationAspects

Dynamic AnalysisAspects

UML ArchitecturalInformationUML Architectural

Information

UML Model Evolution

Dynamic Assessment

ResultsStatic

AssessmentResults

AspectTranslator

UCI Research Forum

Aspects useful in exploring quality concerns

Sequence Diagram X-Y sizes

0

200

400

600

800

1000

1200

1400

0 500 1000 1500 2000

X size

Y s

ize

Message interactionsets too large for

manual inspection

UCI Research Forum

Dynamic Architectural Analysis

UML/XMI REACTREP

Model Configuration File

Sample Model OutputsAnimated State Execution

Simulation Model

UCI Research Forum

There still are problems…

Improve trust, education, tools,methodologies, research

Human factors, Architecture-Centricphilosophy not always embraced

Better modelrepresentation/analysis techniques.Aspects

Architectural Evolution,Cross-cutting concern analysis, etc

Multi-level modeling techniquesDynamic Assessment

Augmentation, auto-generation, re-parameterization

Behavioralincompleteness

Early discovery, Static analysisInconsistency

UML profile, improved architecturalsemantics

UML Usages

Solution ApproachesProblem Areas

Ignoring these does not reduce architectural risk

UCI Research Forum

Different UML Usages

xXHigh-level sequence diagramsHigh-level state/activity diagramsClass/actor as subsystemsRole relationships between components

Conceptual system-levelmodels (goals, objectives,system dependencies,constraints)

XxClass diagrams as SW classesDetailed sequence diagrams(messages/methods, classparticipants)State behavior (class, method)Deployment info

Architectural/detaileddesign Level(active/passive objectsinterfaces, tasks, OSmodels, concurrency,)

xXUse case/functional requirementdescriptions (nominal, alternative,exception, preconditions,postconditions, triggers)

Requirements analysisand traceability (reqtids, subsystem, build,test info)

PSMPIMUML ArtifactsFocus

UCI Research Forum

REACT Example:Class Coverage in Sequence Diagrams

41%

59%

Classes referenced insome sequencediagram

Classes referenced inno sequence diagram

UCI Research Forum

Usage of Class Diagrams

49% 35%

4%1% 3%

2%

4%0%0% 2%

Unnamed Classes insequence diagram

Null Classes in sequencediagram

Data structure Classes insequence diagram

Actor Classes in sequencediagram

Other Classes in sequencediagram

Unnamed Classes in nosequence diagram

Null Classes in no sequencediagram

Data structure Classes in nosequence diagram

Actor Classes in nosequence diagram

Other Classes in nosequence diagram

UCI Research Forum

REACT Early Discovery Example:Consistency and Completeness

Non-standard

UML usage

InconsistentClasses,methods Traceability

incomplete

Less than50%

methodsdescribed

UCI Research Forum

Dynamic Assessment

n Goal: Perform dynamic assessment whenmodel behavioral information is missing

n Approach:n Multiple levels of modeling abstractionn Augmentation aspectsn Monitoring aspects

UCI Research Forum

Architectural Evolution

n Representations must support frequent change(mandatory/optional components)

n Not all features will be preplanned and separablen Need to look backward, forward, and elsewhere! (e.g. old design

decisions, new usage scenarios, other ICDs, changingrequirements)

n Expand features to study concerns we don’t want! (e.g. designconflicts, deadlocks, unreachable states)

n Architectural complexities/dependencies will make featureinteractions difficult to manage

n Separation/integration of multiple UML modelsn Any given OO decomposition will eventually be reexaminedn There are cross cutting concerns that the programming domain

alone cannot answer (e.g. version impacts, requirementsevolution changes, workload)

UCI Research Forum

Evolving REACT

n Improve Architectural Representationn Improve Assessment Techniques

UCI Research Forum

Expanding Architectural Representations

Aspects

Requirement Representation

Architecture Representation

Environment Representation

Workload Representation

Aux Reports

UMLModel Model

Generator

ModelConfiguration

DynamicAssessment

Model Executor

ProfileInterpreter

ModelGenerator

Aspects

UMLProfile

AspectsAspects

ReverseEngineer

CodeAnalyzer

xmlxml

Code

Artifacts

AspectProcessor

Dynamic Assessment

Results

StaticAssessment

AspectProcessor

AspectProcessor

ModelConfiguration

ModelConfiguration

Dynamic Assessment

Results

Dynamic Assessment

Results

Use cases

PrepTools

PrepTools

Use casesICDsDeployment

Info

PrepTools

Use cases

Artifacts

ModelGenerator

ExtractorExtractor

UCI Research Forum

Expanding Assessment Techniques

n Develop tools/techniques to improve context and semanticsn XML schemas represent/share architectural artifactsn Support augmentation from various sourcesn Support interpretation aspects (e.g. UML profiles of use)

n Augment representations with parameters derived from reverse-engineered coden Capture missing behaviors to improve evolution success

n Manage planned scenarios as analyzable use casesn Manage planned features as aspects over entire representation

spacen Dependencies too difficult otherwise

n Move toward automating analysis and aspect-oriented impactanalysis

n Develop architectural analysis techniques to discover designpatterns and refactoring opportunities

UCI Research Forum

Closing Comments

n The holy grail of architecture is not efficient softwarecode generation but managing architectural riskduring its evolution

n A systems engineering perspective supportingarchitectural assessments and impacts to change isdesired

n Architecture is a core asset that goes beyond UMLand AOP.

n Architectural representation challenges remainn UCI is a meeting the challenge!

UCI Research Forum

Backup Charts

UCI Research Forum

References

n Scenario-basedn R. Kazman, G. Abowd, L. Bass, P. Clements, “ Scenario-Based Analysis of

Software Architecture,” IEEE Software, 13 (6):47-56, 1996n R. Kazman, M. Klein, M Barbacci, T. Longstaff, H Lipson, J. Carriere, “The

Architecture Tradeoff Analysis Method,” in Proceedings of the 4th

International Conference on Engineering of Complex Computer Systems(ICECCS98), Monterey, CA, IEEE CS Press, pp68-78, 1998

n P. Bengtsson, N. Lassing, J. Bosch, H. vanVliet, “Analyzing SoftwareArchitectures for Modifiability,” May 2000

n Feature-orientedn M. Svahnberg, J. Van Gurp, J. Bosch, “On the Notion of Variability in

Software Product Lines” Proceedings of the Working IEEE/IFIP Conferenceon Software Architecture (WICSA 2001), pp 45-55, August 2001

n Architecture-centric Designn T. Mens, C. Lucas, P. Steyaert, “Supporting Disciplined Reuse and

Evolution of UML Models,” First International Workshop on UML,Mulhouse, France, June 1998

n Xadl, an XML architecture description languagehttp://www.isr.uci.edu/projects/xarchuci/

UCI Research Forum

References (cont’d)

n Aspect-oriented Programmingn See Communications of ACM, October 2001, Vol 44, No 10.

n Aspect-oriented Architectural Analysisn P. Schmidt, R. Duvall, G. Mulert, J. Milstein, J. Rivera, “Aspect-Oriented

Architectural Analysis using Multi-level Modeling of Complex Systems,”Proceeding of 2003 International Information Resources ManagementConference, May 2003

n Maintenance/Product Line Studiesn J.Bosch “Product-Line Architectures in Industry,” Proceeding of the 21st

International Conference on Software Engineering, Nov 1998n J. van Grup, J. Bosch, “Design Erosion: Problems and Causes,” Journal of

Systems and Software, November 2001.n M. Lindvall, K. Sandahl, “How well do Experienced Software Developers

Predict Software Change?”, Journal of Systems and Software, vol 43, no 1, pp19-27, 1998

n M. Lindvall, M. Runesson, “The Visibility of Maintenance in Object Models: AnEmpirical Study,” Proceedings of International Conference on SoftwareMaintenance, Los Alamitos, IEEE CS Press, pp 54-62, 1998

n B. Lientz, E Swanson, Software Maintenance Management, Reading, MA,Addison-Wesley, 1980.

UCI Research Forum

Definitions

n Architectural variability, refers to the ability toidentify and flexibly reshape aspects of anarchitecturen Aspects identify points of variation

n Program evolution refers to the ability of anarchitecture, over its lifecycle, to undergochange

UCI Research Forum

Augmentation Aspects

n Example: Initially model missing informationas a “black box”n An aspect identifies

n Area/context of interest (e.g. methods with no statebehavior)

n Some action to be taken (associate some default blackbox action state with that method)

n Later another aspect could replace/revise theblack box behavior

n Example: Identify all COTS tool interfaces

UCI Research Forum

Monitoring Aspects

n Monitor defines an action to take and thecondition under which to enable it.

n Currently monitoring is independent ofsystem under study. E.g. monitoring does notforce adaptive behavior

n Augmentation aspects can tag areas andenable monitoring. E.g. All interrupt handlermethods.

n Monitoring can provide directives to thesimulator (e.g. report Task msg queue size)

UCI Research Forum

Multi-Level Modeling Types

n Method-level Modelingn Participant-level Modelingn Use-case level Modeling