Parnas and Clements: A Rational Design Process: How and Why to Fake It

1
Parnas and ClementsA Rational Design Process
How and Why to Fake It

• Presented byJeremy Bowers, Alireza Namvar
• IEEE TSE, vol SE-12, no. 2, Feb. 1986
• The Goal of Software Software Engineering A
  Rational Design Process
• What is a rational agent?
• Considers all choices thoroughly and correctly
• Perfectly documents all results
• Sounds great, but

2
There Is No Rational Agent

• Lots of reasons
• Customers dont know what they want,
• dont know everything we need in advance,
• were only human,
• external change,
• preconceived notions,
• economic limitations
• the list goes on
• We abandon rational design. . .

3
Why Document?

• Requirements User lt-gt Developer communication,
  estimation, turnover insurance, establishing
  desired behavior
• Module Work assignments, cross-module-implementer
  communication, module connection overview
• Future Maintainers need a way to learn the
  system
• Others, too

4
Whats Wrong With Most Documentation?

• Poor Organization (mostly stream of
  consciousness or stream of execution)
• Both nearly impossible to find anything when you
  look for something
• Boring prose
• Confusing/inconsistent terminology
• Myopic viewpoint (too close to system when
  written)
• . . . wouldnt it be nice to have the rational
  documentation?

5
Fake It!

• Imagine yourself as the ideal agent, and write
  the documentation you would have produced
• Design the documentation
• Separation of concerns One system aspect for one
  section, no more, no less
• Document what is important, with the addition of
  rejected design decisions
• Justification Even Mathematics, the very
  definition of rational, works this way Results
  preferred over precise history of an idea

6
Conclusions

• Result Useful documentation that can be produced
  in the real world
• Unlike other papers presented, these ideas are
  still revolutionary
• Unfortunately, few people do this. (In fact,
  people are often shocked if you do.)
• Tells us what we want, but not how to get it

7
Related 1 Users Manual as Requirements
Specification

• Berry, Daudjee, et al. May 2001
• Summary The desirable properties of a users
  manual are the same as the desirable properties
  of a requirements specification.
• So write the Requirements Specification in the
  form of a Users Manual

8
What Properties?

• Requirements elicitation
• Communication
• Client can understand users manuals where they
  may not understand other standard requirements
  documents
• Programmers can see exactly what the requirements
  are calling for
• Validation
• Customers ideas versus designers ideas
• Code versus features

9
Why Users Manual?

• To write one, one must have
• A complete understanding of each use the system
  will be put to (use cases)
• We can write one for each type of user, to ensure
  feature coverage (developer vs. user vs.
  administrator)
• Provides scenarios which can be used as test
  cases
• Enforces user-centered design (cant write manual
  to the developers)
• Exposes ambiguities

10
Related 2 Software Documents Concepts and Tools

• Jim Welsh, Jun Han in Software - Concepts and
  Tools (vo15, no. 1, 1994)
• Summary all results of the software engineering
  process can be considered as documents.
• Source Code a carefully specified formal
  document that can be executed by a computer.

11
Ideal Development Environment

• Set of Documents focusing on required features.
• Set of Tools help us maintain the documents (i.e.
  consistency across versions)
• starting with the loosest, informal
  specifications.
• moving toward fully formal specifications.
• ending up with actual source code (literate
  program)

12
(No Transcript)
13
(No Transcript)
14
(No Transcript)
15
(No Transcript)
16
Tools Rational Assistants

• verification of code
• tie together the original specification, the
  formal specification, and the actual code.
• improve the ease of formally validating code.
• Improve level of connectivity
• automated consistency checks e.g. propagate a
  variable name change across all code.
• analyze certain changes.

17
Extending Parnas and Clements work

• A concrete way to achieve the goals Parnas
• and Clements lay out.
• By improving our tools, we improve our ability to
  create coherent documents.
• contain all of the information we may be
  interested.
• from the start through to the finish.
• If the proposed "Software Documents" existed, it
  would be much easier to produce "Rational
  Documentation."

18
Related 3 A Development Method for Multiagent
Systems

• J. Lind 2000
• Summary a pragmatic process model for the
  development of multiagent systems based on the
  combination of standard SE techniques using 7
  views.
• The approach applied and refined successfully in
  various industrial research projects.

19
MASSIVE view

• MASSIVE MultiAgent SystemS Iterative View
  Engineering

20
View-oriented Modeling?

• View" is a projection of the root model of the
  system with only a certain type of information in
  it.
• Projection is analogous with geometric
  projection of multi-dimensional objects into
  lower dimensions.
• A Model for the creation of multiagent systems
  based on the idea of creating and using seven
  "views" on the system.

21
Iterative View Engineering

• How to create the views and models?
• Combines
• Roundtrip Engineering
• (Balzert 98)
• Iterative Enhancement
• (Basili and Turner 75)
• Using IE as a repeated subprocess to extend RE
• Adding IE steps to the creation of the model, the
  implementation
• Adding trips around the whole process

22
Extending Parnas and Clements work

• adding to the corpus of work on abstract
• documentation processes.
• using the observations Parnas and Clements made
  about rational design processes.
• any specification is initially incomplete
• Parnas and Clements provided useful ideas for the
  difficult problem of developing documentation,
  and software.

23
Uncited A Pragmatic Approach to Software
Documentation

• Klaus Didrich, Torsten Klein 1996
• Summary The author extends Literate Programming
  to work in more situations then traditional
  Literate Program

24
Quick Sidebar What is Literate Programming?

• Developed by Knuth in his paper Literate
  Programming, The Computer Journal, 27(2)97-111,
  1984
• Principle Focus on documentation over code,
  write both in same file
• Uses a tool to construct source code files from
  the doc/code hybrid files

25
Dosfop Diagram

26
Problems

• A language on top of a language increases
  complexity and learning time
• Languages have changed
• Need for code re-ordering reduced by increased
  granularity of OO and functional programming
• More real programming modules work across
  multiple files, which original Literate
  Programming specs handled poorly

27
Why Should This Paper Cite Parnas and Clements
work?

• It must be possible to integrate quick-and-dirty
  code and only later document it
• This is a way of faking a rational design process