SHARKADI 2007
Architecture and Design Intent:
An Experience Report
Paul S Grisham, Matthew J. Hawthorne,
& Dewayne E. Perry
May 20, 2007
© 2007, Paul S Grisham, Matthew J. Hawthorne & Dewayne E Perry
1
SHARKADI 2007
Introduction
Î What
is Design Intent?
ªSet of decision-making factors
¾ Rationale
¾ Best-Practices
¾ Patterns, Styles, Idioms
¾ Naturalistic Decision-making
¾ Situational Analysis
Î Graduate
Topics Course on Design Intent
ªTeach theory, history, and current practices of AK and DI
ªGoal: Use the project as a prototype study on DI modeling
¾ Gain preliminary results for hypothesis forming
¾ Improve methods for future studies
© 2007, Paul S Grisham, Matthew J. Hawthorne & Dewayne E Perry
2
SHARKADI 2007
Overview of the Project
Î
Project overview:
ª Add features to an existing software project
¾ Evolutionary design
Î
Project Phases:
Î
Problem Domain:
1. Infer DI/AK from unstructured documentation
2. Perform decision modeling without decision process
3. Perform decision modeling with decision process
ª Document management system
ª Extensive documentation covering all aspects of the system
¾
¾
¾
¾
¾
Executive summaries and white papers
Informal architecture documentation
User manuals
Wikis / mailing list archives
Source code (open-source)
ª Mature, suitably complex
ª Easy to understand domain
© 2007, Paul S Grisham, Matthew J. Hawthorne & Dewayne E Perry
3
SHARKADI 2007
Phase 1 – Using Existing Knowledge
Î Read
documentation and answer specific questions
ªWhere can certain knowledge be found?
¾ Functional requirements
¾ Architectural design
¾ Architectural rationale
ªHow was rationale explicitly and implicitly represented?
Î Results:
ªDocs were suitably thorough to find basic functional and
architectural design
¾ Relevant information was spread throughout multiple sources
¾ Subject to interpretation
¾ Difficult to terminate search without exhaustive reading
ªRationale present, but subtle coding
¾ Students used content analysis
ªSearches were disorganized
¾ Reflected immaturity of architects
¾ Lack of structure in documents
© 2007, Paul S Grisham, Matthew J. Hawthorne & Dewayne E Perry
4
SHARKADI 2007
Phase 2 – Decision Modeling w/out process
Î Treat
requirements structuring as a design activity
Î Use QOC to:
ªformalize requirements (questions, constraints) and
ªconsider early design alternatives (options)
Î Students
felt that the process helped them discover
alternatives and hidden assumptions
ªBut they couldn’t identify anything specific
Î Students
felt that it helped coordinate their group
ªMore or less than other collaborative systems?
© 2007, Paul S Grisham, Matthew J. Hawthorne & Dewayne E Perry
5
SHARKADI 2007
Phase 3 – Decision modeling with Process
Î Use
CBSP to structure requirements and map to arch
elements
ªTreats requirement structuring as a design activity
ªDistinct steps with input and output artifacts
ªOther architecture design processes not suitable for
evolutionary design
ªOther arch+rationale systems do not provide a design
method
Î Students
found CBSP difficult to use
ªSteps were incompletely defined or too vague
ªCategories and classifications were too ambiguous
ªLack of tool support and method guidance
© 2007, Paul S Grisham, Matthew J. Hawthorne & Dewayne E Perry
6
SHARKADI 2007
Analysis of Problem Domain
Î DSpace
was a good domain choice
ªCan be used for repeatable, controlled experiments
ªHalf- to full-day observation studies with individuals or
teams
ªQuestion: How do experienced architects approach existing
documentation for evolving domains?
ªWe can “fake” AK or DI for DSpace to perform specific
tests
© 2007, Paul S Grisham, Matthew J. Hawthorne & Dewayne E Perry
7
SHARKADI 2007
Analysis of Method
Î Decision-Support
is useful
ªAK as process by-product
ªMany decision support processes are for initial design
¾ CBSP or Preskriptor (e.g.) not suitable for evolving designs
Î General
rationale modeling for architectural design is
not that useful
ªGeneral rationale systems have been studied more thoroughly
and better in the past
ªWe should be focusing on systems of integrating arch. design
with AK
Î Missed
Opportunity – Round Trip
ªIntegrate semiformal DI/AK into unstructured documentation
as a comparison for the next iteration
© 2007, Paul S Grisham, Matthew J. Hawthorne & Dewayne E Perry
8