Developing Dependable Systems Using Aspect-Oriented Modeling Techniques: Promises & ChallengesOutline of talkSlide 3Balancing dependability concernsThe Problem-Implementation GapKey Software Development PrinciplesWhy consider modeling techniques?Going beyond traditional support for separation of concernsOn the importance of understanding interactions across features: An exampleSlide 10Models as System ViewsCrosscutting Design ViewsThe problem with cross-cutting featuresSlide 14Aspect-Oriented Design ModelsAspect Oriented ModelingA simple aspect: a client-server patternProducing a context-specific aspectProducing context-specific aspectsAn ExampleA Banking Application Primary Model: Class Model ViewGeneric RBAC: Class Diagram TemplateGeneric RBAC: Operation Template - OperationGeneric RBAC: Operation Template - CheckAccessA Context-specific RBAC Class DiagramSlide 26Instantiation ChallengesModel CompositionModel CompositionSignature-based CompositionSignature-based compositionDefault composition rulesSlide 33Composed Class ModelProblems with basic composed modelSlide 36Composition DirectivesComposition ProcessSlide 39Slide 40Slide 41Composition MetamodelComposition Meta-model (merge)Composition Meta-model (directives)Element ReferencesCreate directiveChange directivesComposition ChallengesConclusionDeveloping Dependable Systems Using Aspect-Oriented Modeling Techniques: Promises & ChallengesRobert B. FranceDept. of Computer ScienceColorado State [email protected] of talkOn the difficulty of developing dependable softwareAn Overview of Aspect-Oriented Modeling (AOM)AOM ChallengesConclusionDevelopers of mission-critical open distributed software systems need to balance multiple, interdependent design concerns such as availability, performance, survivability, fault tolerance, and security. A concern can be a set of related requirements or a set of related design objectives.Security, safety,robustness concernsQuality assuranceconcernsBusiness valueconcernsRegulatoryconcernsBalancing dependability concernsBalancing requires making trade-offs and assessing risks associated with design features that address the concerns Organizations seldom have all the resources needed to build software systems that have the desired levels of dependabilityNeed to consider and evaluate alternative features to determine the extent theyaddress concerns cost-effectively mitigate product-related risks.Pervasiveness of dependability features complicates their evaluation and evolutionThe Problem-Implementation Gap“I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representations”A problem-implementation gap exists when implementation and problem abstraction levels differwhen the gap is wide significant effort is required to implement solutionsComplexity arises as a result of effort needed to bridge wide problem-implementation gapsBridging the gap using manual techniques introduces accidental complexities in these casesKey Software Development PrinciplesSeparation of concernsAbstractionSeparation of viewsRigour and FormalitySupports development of analysis toolsReducing accidental complexities through automationWhy consider modeling techniques?Software development is a modeling activity!How can we better leverage modeling techniques?Programmers build and evolve mental models of problems and solutions as they develop codeProgrammers express solutions in terms of abstractions provided by a programming languageGoing beyond traditional support for separation of concernsThe Separation of Concerns principle is considered fundamental in software engineeringMuch attention paid to providing support for modularizing descriptions of problems and solutions (separation of parts)Less attention has been paid to providing support for understanding interactions across separated partsOn the importance of understanding interactions across features: An exampleThe first launch of the space shuttle Columbia was delayed because "(b)ackup flight software failed to synchronize with primary avionics software system" (http://science.ksc.nasa.gov/shuttle/missions/sts-1/mission-sts-1.html)Balancing dependability concernsBalancing requires making trade-offs and assessing risks associated with design features that address the concerns Organizations seldom have all the resources needed to build software systems that have the desired levels of dependabilityNeed to consider and evaluate alternative features to determine the extent theyaddress concerns cost-effectively mitigate product-related risks.Pervasiveness of dependability features complicates their evaluation and evolutionModels as System ViewsUML models present different views of systemsEvolution of system effected by evolving models (views)Requires well defined relationships between models requires well defined notions of realization/refinement/abstraction(e.g., see Catalysis Method)Language-defined viewsCrosscutting Design ViewsSubsystem 1Subsystem 4Subsystem 5Subsystem 3Subsystem 2Error Recovery Feature*Access Control Feature**A feature is a logical unit of behaviorThe problem with cross-cutting features… understanding and changing them!Information is distributedMaintaining consistency in the presence of changes is problematicDifficult to consider alternative treatmentsLack of attention to balancing dependability concerns early in the development cycle can lead to major re-architecting in later stages of developmentStakeholder 1View 1Stakeholder 2View 2Stakeholder 3View 3Stakeholder 4View 4The System ModelMerge views, resolveconflicts, maketrade-offsAspect-Oriented Design Models•Separation of Concerns –Primary Model : A model of core functionality; determines dominant structure–Aspect Model : Describes a feature that cross-cuts modules in the dominant design structure•Aspects as Design Patterns–Isolate crosscutting features by capturing their structural and behavioral patternAspect Oriented Modeling NamespaceAspect model 1instantiateinstantiateValues used in the bindingsValues used in the bindingsPrimary modelModel element names+Context-specific aspectsContext-specific aspectscomposeComposition directivesComposed modelAspect model 2A simple aspect: a client-server
View Full Document
Unlocking...