Collaborative Software Design & Development. *Design Intent*

Collaborative Software Design &

Development

*Design Intent*

Background

Â

Architecture and Design Intent in Component/COTS

Based Systems

ªKeynote talk for ICCBSS 2006

ªContinues in the vein of my previous research at Bell Labs

¾ Inscape

¾ Software architecture

ªCurrent, important, emerging topic in software architecture

¾ Eg, see Bosch 2004, Duenas 2005

ªReflects some of the initial thinking for Matt Hawthorne’s

Basic Issues

 In creating systems we make choices because we have some

intent

ªSome requirements over others

ªOne architecture instead of another

ªA specific algorithm or data structure over others

 When we create a product or component we have some idea of

how we

intend

ªMay be specific or it may be general

 We use products or components with specific

intent

ªIf a specialized product or component may still use only a part of it  In evolving systems

ªWe often have to divine the original intent to understand how to make changes

Basic Facts about COTS/Components

Â

Integrating COTS and components often results in

disasters from architectural mismatch [Garlan et al]

ªLack of understanding of the intent (or assumptions) of

components with respect to

¾ Resources

9Who controls them, who uses them, how they are used, etc

¾ Interactions with other components

9Who they interact with, their characteristics, their data models, etc 9How they interact, eg, synchronously or asynchronously, etc

¾ Global architecture

9Topology, control flow, etc

¾ System Construction

Basic Facts

Â

Spend 80% of our time in (re)discovery to understand

legacy systems [Bell Labs Study]

ªA large part of that is trying to determine the original

intent of the architecture, design and code

Â

Rarely a problem in small group projects

ªBut even there can be forgotten or misunderstood

Â

Coordination of multiple developers a major problem

ªIntent critical in choreographing multiple developers in initial

development

Basic Problems & Benefits

Â

Traditionally, intent conveyed by documentation

ªOS360 documentation

¾ 6 months project workbook: 5 feet

¾ Daily changes: 2 inches

Â

One release of Lucent’s 5ESS system

ª11.8% of design and implementation faults due to ambiguous

requirements

ª30.6% of design and implementation faults due to incomplete

or omitted requirements or design

ª42.4% - due to traditional problems of documentation

Â

Documentation as a shared model of intent

ªRequirements – a shared model of the problem

ªArchitecture – a shared model of the basic solution structure ªDesign and code – shared model of the machine in more

Intent and Evolution

Â

Everything changes

ªWorld changes: uses and requirements change ªTechnology changes

ªOperating context changes

ªSystem itself changes: improvements, faults fixed

Â

What persists in the face of evolution: CODE

ªRequirements, architecture, design documents out of date ªCode is only thing up to date

ªCode: desiccated relic of a long intellectual process

¾ Difficult to reconstruct the intent and reasoning

¾ Too many ways to backtrack

Â

Difficulties result:

ªNot clear how requirements changes impact the system ªNot clear how structural changes impact the system

ªNot clear how code changes impact the architecture or the

Some Basic Distinctions

Â

Decisions – is at best a description of what is

decided

ªMay indicate alternatives

ªMay have some considerations about the alternatives ªMay go further and evaluate the alternatives

ªMay indicate why the decision was made

Â

Intent – why decisions were made the way they were

ªWhy alternatives were not chosen

ªWhat effect the evaluations had on the design choices ªWhat expectations result from the choice

Some Prior Approaches

ªGeneric model for delineating generic elements of a design rationale

¾ Artifacts, issues, alternatives, justifications, etc ¾ Relationships among these elements

ªDesign deliberation: issue, set of alternatives, and a justification for the decision

ªResult: a design history that can be used in the face of changing requirements

 Perry/Wolf 1989/1992

ªCalled for rationale in addition to elements and form  Gruenbacher, Egyed and Medvidovic 2001/4

ªComponent, bus, system, property model

ªCaptures enumerated design decisions in terms of dimensions

¾ C, B, S, CP, BP, SP, etc

¾ Eg, bus properties (BP): synch, asynch, local, distributed, secure

Recent Complaints

Â

Bosch 2004

ªLaments general lack of support for architecture rationale ªDesign decisions are not first class entities

ªDesign decisions often cross cutting and intertwined ªDesign rules easily violated

ªObsolete design decisions and artifacts rarely removed ªHigh maintenance costs

Â

Duenas and Capilla 2005

ªPropose a set of

¾ Elements

¾ Information

¾ Graphical notations

to record design decisions

Intent and Uncertainty

Â

Uncertainty a fundamental fact of development life

ªChange and uncertainty interdependent ªEach causing the other

Â

Changes often have far reaching effects

ªEspecially if persist until later states of a project ªTechnology changes can simplify or complicate

ªBusiness changes can create significant uncertainty

Â

Attempts to cope

ªDelayed binding to create dynamically adaptable systems ªStill, deferred design decisions can cause significant

problems

Â

Need methods, techniques, processes and tools

ªTo support design decisions

ªConvey architecture and design intent

Intent and Evolution

ªTraditional planned developments

¾ Often large projects ¾ Heavyweight processes

¾ Highly concurrent, heavily coordinated ¾ Dominated by project plans and milestones

ªAgile developments

¾ Often small projects, or small parts of larger projects ¾ Lightweight processes, customer focused

¾ Test driven, immediate solution, refactored evolution ¾ Concurrent, lightly coordinated

 Two ideas to explore

ªPlanned: rationale reification

¾ Formal and semi-formal representations of rationale

¾ In the context of formal models of requirements and architecture ¾ Basis for self-managing and self-adaptive systems

ªAgile: Intent-first design

¾ Analogous to test-first design

¾ Embedding light-weight, maintainable requirements models into source

Earlier work

Â

The Inscape Environment

ªConstructive approach based on

¾ Formal interface specifications

¾ Semantic interconnections determined during construction

¾ Set of propagation rules

ªBasic rule: all preconditions and obligations must be satisfied

or propagated to the interface

ªPreconditions or obligations unpropagated and unsatisfied

represent faults

¾ Called precondition ceiling and obligations floors

ªSpecification contributions

¾ Obligations

¾ Multiple results, some of which are considered as exceptions

9Set of rules for handling them

9Useful for fault tolerance and reliability

Earlier Work

Â

Perry/Wolf Architecture model

ªArchitecture = (elements, form, rationale)

ªComponents and connectors the basic elements

ªForm is properties and relationships (ie, interactions) and

constraints on those properties and relationships

ªRationale is the justification for the elements and form

¾ The primary carrier of architectural intent

ªArchitecture styles codify basic aspects of intent to be

applied to elements and form

Earlier Work

Â

Architectural Prescriptions

ªTransforming software requirements into architecture

prescriptions

ªKAOS Æ Preskriptor

¾ Goals Æ constraints

¾ Architect has freedom to chose how goals are distributed

among architectural elements as constraints

¾ Goals as a means of expressing requirements intent

¾ Prescriptions as a means of expressing architectural intent

ªArchitectural styles important as a form of constraint

codification

¾ Incomplete architecture prescriptions

¾ Applied to specific elements, collections of elements of the

entire system

Earlier Work

Â

Intent-based Architectures

ªIntroduces architecture intent as a key concept

ªIntent of an element encapsulates its functional purpose ªIntent associated with roles in architecture

¾ Elements with similar intent can be substituted for each other

¾ Based on higher levels of abstraction

¾ Direct link between requirements and architecture

ªEnables reification of an architecture in one or more

functionally equivalent implementations

ªBasis for self-configuring adaptive systems

¾ Respond to changes in environmental or operational conditions

¾ By reconfiguring – subject to functional and nonfunctional

Rationale Reification

Â

Basic idea:

ªBegin with formally specified requirements and architecture

¾ Eg, KAOS requirements specifications and architecture

prescriptions

ªRequirements are in problem domain terms; architecture

often in solution domain terms

¾ Systems drivers such as user needs, business goals, strategies

are incorporated in requirements

ªCurrently no connection between the two

¾ No rationale, even informally

¾ Mapping from problem domain to solution is problematic

ªCurrent focus of architecture:

¾ Elements and form

¾ Rationale, if treated at all, is informal and general

ªRationale reification

¾ Capture refinements and transformations used by architects in

Rationale Reification

 Basis for systematic requirements and architecture based

evolution

ªChanging requirements lead to changes in rationale and associated changes in the architecture

ªRequirements become an integrated part of the system structure rather than something separate and apart

 Rationale determines the mapping between the functional and

non-functional requirements and the architecture

ªAbstract architecture in terms of problem domain (ala Preskriptor) and models functional intent

ªConcrete architecture then related to abstract via intent

ªRefinement used to decompose functinality into smaller functional elements

ªTransformations used functional structure into an architecture that satisfies the non-functional requirements

ªRequirements Æ (rationale) Æ architecture

Rationale Reification –

Tool Support

Â

Requirements modeling support

ªSuch as the KAOS System of Axel van Lamsweerde

Â

Rationale modeling support

ªCreate and evolve mappings and transformations

Â

Architecture modeling support

ªCreate, edit and view the architecture models

Â

Intent modeling and visualization support

ªTies everything together

Â

Self-managing/adaptive support

Agile Intent

Â

Agile context

ªSet of methods, techniques and processes to cope with

changing and uncertain requirements. Eg,

¾ Feature oriented milestones

¾ sort iterations with frequent deliveries

¾ Close interactions with customers

¾ Deferred design decisions

ªMost popular: extreme programming (XP)

¾ Requirements captured as acceptance and unit test cases

9Written from customer stanpoint

¾ Test-first design

9Written before code

9Can determine if requirements already satisfied

¾ Code written to meet minimum needs of requirements

9Just sufficient, complex as needed – simple as possible

Agile Intent

Â

Test cases an integral part of the project

ªLiving active artifacts, rather than separate informal

document

Â

Downside: maintaining test cases just as difficult as

maintaining any artifact (eg, requirements document)

ªEspecially where problem and design intent are missing

ªUnit tests are not semantically rich enough by themselves to

capture design decisions

ªNo way to determine which goals and intentions are still valid

Agile Intent

Â

Proposed approach:

Intent-First Design

ªSemi-formal intent annotations

ªLight-weight, maintainable documentation of requirements ªGet benefits without extra-process burdens

¾ Sufficiently comprehensible intentional models

¾ Sufficiently usable support tools

¾ Should meld easily with agile processes

Â

Underlying ideas

ªIntent expressed in terms of goals is appropriate abstraction

¾ Help maintain both requirements (test cases) and code

ªProgrammers assistant

¾ Interactive feedback on how

9To model intent

9To write code to meet requirements in intent model

¾ Build on top of Inscape work

9Capturing semantic intent 9Coordinating developers

Agile Intent

Â

Intent-First Integrated Development Environment

(IDE)

ªLanguage aware editor

ªPlug-in tools to manage and evolve intent model ªAutomated support for testing and validation

¾ Integrated with version management

ªVisualization support

ªTeam support and coordination ªEvolution support (ala Inscape)

¾ Changes in requirements model Æ revisions notices in intent

model

¾ Changes in intent model Æ notification of potential consistency

problems between code and intent model

¾ Similarly backward consistency of code to requirements

Agile Intent

Â

IF-IDE (continued)

ªMultiple views into the code

¾ Code view: view into the traditional program editor environment,

annotated with intent

9Explicitly or abstracted thru graphical and visual cues

¾ Intent view: more comprehensive view

9Includes use stories, features, non-functional goals, etc 9Code elements abstracted to appropriate levels

¾ (Both navigable thru hypertext links)

¾ Status view: represents intent model relative to the current

level of implementation and correctness

9Use requirements prioritized

¾ Change view: code and requirements addressed in terms of

intent

9Identify uncertain requirements, unstable code

Conclusions

Â

Architecture and design intent are critical in creating

and evolving software systems

Â

Need shared understanding of Intent, else

ªToo easy to introduce faults ªToo easy to fail

Â

Problem exacerbated with COTS and other

components that must be treated as a black box

ªContext of intent unavailable

ªHence cannot (re)discover and (re)construct architectural and

design intent from internal details

ªHence, explicit intent descriptions all the more critical for