Parnas and Clements A Rational Design Process How

Parnas and Clements: A Rational Design Process: How and Why to Fake It • IEEE TSE, vol SE-12, no. 2, Feb. 1986 • The Goal of Software Engineering: A Rational Design Process • What is a rational agent? – Considers all choices thoroughly and correctly – Perfectly documents all results • Sounds great, but… Parnas and Clement 86

There Is No Rational Agent • Lots of reasons: – – – – Customers don’t know what they want, don’t know everything we need in advance, we’re only human, external change, preconceived notions, economic limitations… the list goes on • We abandon “rational” design. . . Parnas and Clement 86

Why Document? • Requirements: User <-> Developer communication, estimation, turnover insurance, establishing desired behavior • Module: Work assignments, cross-moduleimplementer communication, module connection overview • Future: Maintainers need a way to learn the system • Others, too Parnas and Clement 86

What’s 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) • . . . wouldn’t it be nice to have the “rational” documentation? Parnas and Clement 86

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 Parnas and Clement 86

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 Parnas and Clement 86

Related 1: User’s 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 User’s Manual Berry, Daudjee, et al. 2001

What Properties? • Requirements elicitation • Communication – Client can understand user’s manuals where they may not understand other standard requirements documents – Programmers can see exactly what the requirements are calling for • Validation – Customer’s ideas versus designer’s ideas – Code versus features Berry, Daudjee, et al. 2001

Why User’s 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 (can’t write manual to the developers) • Exposes ambiguities Berry, Daudjee, et al. 2001

Related 2: Software Documents: Concepts and Tools • Jim Welsh, Jun Han in Software - Concepts and Tools (vo 15, 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. Welsh and Han 94

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) Welsh and Han 94

Welsh and Han 94

Parnas and Clement 86

Parnas and Clement 86

Parnas and Clement 86

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. Welsh and Han 94

Extending Parnas’s 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. " Welsh and Han 94

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. J. Lind 2000

MASSIVE view • MASSIVE: Multi. Agent System. S Interative View Engineering J. Lind 2000

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. J. Lind 2000

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 J. Lind 2000

Extending Parnas’s 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. J. Lind 2000

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 Didrich Klein 1996

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 Didrich, Klein 1996

Dosfop Diagram Didrich Klein 1996

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 Didrich Klein 1996

Why Should This Paper Cite Parnas? • It must be possible to integrate quickand-dirty code and only later document it • This is a way of faking a rational design process Didrich Klein 1996