ࡱ> s Ejbjb kkE]~~~~~~~f f f f f $ df /B X X X X X X X i/k/k/k/k/k/k/,Z2N4f/~X X X X X /`(~~X X B `(`(`(X :~X ~X i/|~~~~X i/`(`(.-.|~~]/ TFf f  M/Foundations Dijkstra: Go To Considered Harmful [Dij68] E.W. Dijkstra. "Go to Statement Considered Harmful" (letter to the Editor), Communications of the ACM, 11(3):147-148, March 1968. Go To forces us to analyze the dynamic behavior of the system rather than playing to human strength (static, textual analysis). Definition of the program spreads out in space (program text) and time (execution states). Go To makes them incomparable, since there is no definite point in between each statement. As of 1968, it was NOT proven in terms of unclear preconditions -- that was a later rerationalization. But, there was an operational translation technique: Jacopini proved the superflousness of the goto statement in 1966. McCarthy invented the case statement. Has reemerged in principled form for exception handling. Hoare69: Axiomatic Proof [Hoa69] C.A.R. Hoare. "An Axiomatic Basis for Computer Programming", Communications of the ACM, 12(10):576-583, October 1969. Introduced pre and post conditions. Inductive proof. Mapping axioms to programming language constructs. Previous work only used axioms to prove equivalence (Irigashi's PhD). Already knew that 1/2 time in test; 2/3 of cpu cost. FM will help with "reliability, documentation, and compatibility". Axioms let you prove program independent of representation and layout. Footnote: Validity of three integer arithmetic rules: halt, fix to floor/ceil of range, and modulo wrapping all work; just pick one. Wirth71: Refinement (8-Queens) [Wir71] N. Wirth. "Program Development by Stepwise Refinement", Communications of the ACM, 14(4):221-227, April 1971. 8-Queens. No analytic solution. Start with the 2^64 and reduction in state space through several heuristics (preselection, auxilliary state). Using the formal specification for insight (data structure, enumeration order). Refine prog and data (and proof) in parallel. Liskov & Zilles: Spec Tech / ADTs [LZ75] B.H. Liskov and S.N. Zilles. "Specification Techniques for Data Abstraction", IEEE Transactions on Software Engineering", SE-1(1):7-19, March 1975. An eminently readable defense of 1) abstraction/ADTs and 2) then-nascent specification techniques. Presented a stack using v-graphs, vienna DL, algebra, (those were the abstraction; next ones are operational) stack machine, algebra, axioms Criteria: Formality, Constructability, Comprehensibilty, Minimality, Range, Extensibility. Footnote: the same Zilles at Adobe I knew from W3C DeRemer & Kron: MILs for Programming-in-the-Large [DK76] F. DeRemer and H.H. Kron. "Programming-in-the-Large versus Programming-in-the-Small", IEEE Transactions on Software Engineering, SE-2(2):80-86, June 1976. Argues that scale is a difference in quality, not quantity: need new languages to address new concerns (mirrors CKI88 in a way). Modules reflect "surface consensus" of the team. Introduced MIL 75, Module Interconnection Language. Belief that LPSs do a different job than MILs. Requires a hierarchical uses relationship ("system tree"). Analogy to conventional 'linkers'. Enforced hiding/accessibility rules -- security mindset! Used for: project management, design, coordination, and documenting large projects. Leaves dynamism -- evolving interconnections -- for future research. Theirs was purely static. Useful for identifying cohesion and coupling -- not just which components use each other, but which don't. Ghezzi: The Blue Book [GJM91] C. Ghezzi, M. Jazayeri and D. Mandrioli. Fundamentals of Software Engineering. Prentice Hall, Englewood Cliffs, NJ, 1991. Best part of the book is the bibliographic notes. Anyway, the only thing really worth taking home is the comprehensive list of internal/external, product/process ilities: Correctness (specification agreement) Reliability (MBTF on 'valid' input) Robustness (reaction to 'invalid' input) User Friendliness (tied with Ease of Use) Verifiability (separate from Testability) Maintainability Reusability Portability Understandability (tied with Ease of Learning) Interoperability Productivity Timeliness Visibility Parnas93: Out-of-bounds Predicates are False, Dammit! [Par93] D.L. Parnas. "Predicate Logic for Software Engineering", IEEE Transactions on Software Engineering, 19(9):856-862, September 1993. Key is distinguishing all the [Par]s -- the Blue book does that well. This is fine acerbic Parnas, rubbing everyone's face in perceived errors only he can see. It *is* a blow for common sense, though key point: conciseness is a hugely important criteria for practical formality, even more than well-foundedness for analysis, potentially. Example: sqrt(x) -- undefined for x<0, obviously Brooks: Silver Bullet [Bro95] F.P. Brooks. The Mythical Man-Month, 25th Anniversary Edition. Addison-Wesley, Reading, MA, 1995. Accident/essence. Old bullets: HLL, Timesharing, IDEs. Probably not: Ada, AI, verification, graphical langs, OO, environments. Maybe: Reuse (buy), requirements, incremental dev, design training. Why? The classic refrain that SW invisible and malleable -- and expected to be continually changed. "where is next November?" After 20 years, what holds: consistency, architect. What doesnt? Open-book (Parnas was right); 1-2-throw-away; user-testing moves to head of the waterfall. MMM: 1/3 planning, 1/6 coding, 1/2 testing. Owise, a rediscovery of PERT charts Requirements & Specifications Peterson: Petri Nets [Pet77] J.L. Peterson. "Petri Nets", ACM Computing Surveys, 9(3):223-252, September 1977. The basics. Petri wrote his thesis in Germany in '62. You can add token colors, values; add preconditions to transitions. Petri nets are tractable for analysis, but face the same ultimate decision-power limits as FSMs or anything else sufficiently expressive. Model's success = modeling power (ease) + decision power (utility). Heninger: A-7 Requirements (SCR) [Hen80] K.L. Heninger. "Specifying Software Requirements for Complex Systems: New Techniques and Their Application", IEEE Transactions on Software Engineering, SE-6(1):2-13, January 1980. 500-page reverse engineered spec. Textual Markup of inputs, outputs, conditions. Critical importance of specification in maintenance and evolution. Rigor paid off in detecting errors. *External* observables only. Wing: Specifier's Guide [Win90] J.M. Wing. "A Specifier's Introduction to Formal Methods", IEEE Computer, 23(9):8-24, September 1990. A guide to types of specification languages: Behavioral and Structural. Abstract Data Types: Z, Vienna VDM, Larch for a symbol table. Concurrency: Temporal logic, CSP, Lamport's transition axioms for unbounded async buffer. The abstraction of specifications. Specificands@@ Student of Liskov's, went to CMU. LW98: Temporal-logic inference of scenarios [LW98] A. van Lamsweerde and L. Willemet. "Inferring Declarative Requirements Specifications from Operational Scenarios", IEEE Transactions on Software Engineering, 24(12):???-???, December 1998. The kind of paper that gives European CS its reputation. There's an idea in there, but damned if they don't bury it under stultifying formalism (for more of the same, see ILL75). Compare to "US" starting point, Rumbaugh's OOAD. Collect example/counterexample scenarios. Partition by domains of concern (safety, security, performance, etc). From each slice extract candidate temporal models, then merge to preserve/eliminate the behavior from the tentative formula. Then generalize, prompt further questions. Claims lots of case studies, but little dramatic evidence of what the tool can do. Meyer ("the Eiffel guy"): Formalism is good [Mey85] B. Meyer. "On Formalism in Specifications", IEEE Software, 2(1):6-26, January 1985. "The benefits of formal specification". Surfacing errors in even the simplest line-breaking problem: Wirth got it incomplete; Goodenough and Gearheart screwed it up by overdetermining it (in natural language). Formal spec is indeed more concise, more verifiable. 7 Sins: Real contribution is a checklist of all the myriad ways natural language fails: Noise, Silence, Overspecification, Contradiction, Ambiguity, Forward reference, Wishful thinking. Kemmerer: Integrating Formal Methods / SRT [Kem90] R.A. Kemmerer. "Integrating Formal Methods into the Development Process", IEEE Software, 7(5):37-50, September 1990. Secure Release Terminal. 1Kloc, developed through successive refinement of Ima Jo specs. Start with the abstract terminal, delay all possible design decisions (e.g screens, lines appear way after "review document"). (is he still at UC SB?) Design Grady: OO in Ada [Boo86] G. Booch. "Object-Oriented Development", IEEE Transactions on Software Engineering, SE-12(2):211-221, February 1986. The most basic sort of introduction: joint operation/data encapsulation: but it's more than an ADT because of inheritance (not strictly required, though). Decomposes a cruise control, first functionally then into objects (@@agents?). Second, a weatherradio buoy. Usual claims, a la modularity: increases changeability through locality. Applied as a development style for using Ada packages. Booch was an Air Force Academy grad. 9 yrs in uniform. Parnas79: Extension and Contraction [Par79] D.L. Parnas. "Designing Software for Ease of Extension and Contraction", IEEE Transactions on Software Engineering, SE-5(2):128-138, March 1979. Minimal subset/minimal increment style of development. What is mutable should be hidden (aka module-secret, also due to Parnas). The address-database example. The virtual machine construct: modules add commands to the basic machine set. (but basic term due to Dij68, the THE multiprogramming system) Risk factors: information spread; uses chains; modules too-large "Almost" is a synonym for "not". Competing with mathematicians, for whom a more general result is more desirable (vs. dividing into families). Module use must become strictly hierarchical to be tractable. Uses relation establishes hierarchy. "circular" reference is resolved by slicing/sandwich. Parnas86: Faking it [PC86] D.L. Parnas and P.C. Clements. "A Rational Design Process: How and Why to Fake It", IEEE Transactions on Software Engineering, SE-12(2):251-257, February 1986. The ideal is strictly forward-determined: reqts, spec, design, inter- and intra-module design, coding. Faking it is going back and maintaining the required document even though you hop back and forth between stages. Why? Because the ideal process is fundamentally disconnected from reality. (but in the paper trail, the only difference should be extra pages documenting design choices not taken). Write from the perspective of an outsider. Must be implementation independent, live reference document, involve users, never redundant. Instead, it's poorly organized, boring, inconsistent, myopic. Process tells us: what to work on next, what it will do, who will do it, other enabling info. His milleu is very much real-time mathematical process control, to the point of insisting everything else fits this paradigm. FGNR92 (Redmiles): Knowledge-Based SE/ Critics [FGNR92] G. Fischer, A. Girgensohn, K. Nakakoji, and D.F. Redmiles. "Supporting Software Designers with Integrated Domain-Oriented Design Environments", IEEE Transactions on Software Engineering, 18(6):511-522, June 1992. CatalogExplorer, Explainer, Modifier. Multiple perspectives. Chaining inferences. Critics. Agendas. Charting domain, but also for other KB-SE's. Hard-to-memorize content-free title Integrated LISP-style of environment, much influenced by interlisp/symbolics document examiner tricks for DWIM and hyperdocumentation. One of the few examples in the phase II of AI applied (Simon, Tichy were in favor; Dijkstra, Parnas argued against?). They're proud of simultaneously exploring what and how. Perry & Wolf: Foundations of SW Architecture [PW92] D.E. Perry and A.L. Wolf. "Foundations for the Study of Software Architecture". ACM Software Engineering Notes, 17(4):40-52, October 1992. . Architecture= Form, Elements, Rationale. Compiler example (sequence, vs shared-store concurrent). No real understanding of 'materials' analogy. Fatal confusion of 'style'. Erosion and Drift. They invert style and architecture: I'd argue that their two examples are *different* architectures. @@arrogance of defining a 'field'. The true foundations are rooted in field study, hence patterns. Vitruvius instead, if they read any real architecture: firmness, commodity, and delight. Real benefit may be the *professional* model of practicing architects (& their studio-driven training). Song & Osterweil: Design-Method Comparisons [SO92] X. Song and L.J. Osterweil. "Toward Objective, Systematic Design-Method Comparisons", IEEE Software, 9(3):43-53, May 1992. . It describes how to build a base framework/metalanguage to study the problem yet still manages to avoid saying anything about Jackson System Design/Booch/Rational/Data-SSD/Logical Construction/Structured Design/etc Concept, Artifact, Representation, Action. I asked why it's even in the phase II: it was the first attempt to bring *any* systematization to the task. In fact, could (was) applied to other methodologies and indeed revealed missing details. The meta-meta-process, after all, is isomorphic to the scientific method. Validation DeMillo, Lipton, & Perlis: 'Social Proofs' [DLP79] R.A. DeMillo, R.J. Lipton and A.J. Perlis. "Social Processes and Proofs of Theorems and Programs", Communications of the ACM, 22(5):271-280, May 1979. Could be seen as opposing Dijkstras testing-can-only-prove-bugs! view, because proofs are merely socially constructed, too. Automation failed Russell, it will fail SE. Mathematicians pour lots of institutional and personal capital into this dialogue. [there is rarely continuity in verification: unit test doesnt scale to the integrated whole. Inspiration for the opensource movement?: is it easier to review 300 lines than a thousands? Cant trust a million-line proof, either (link to 4-color theory)] Demillo and Lipton are real testers: (?invented?) mutation testing. Perlis wasnt (Tarjan's student, as in the lipton-tarjan planarity test) Weyuker: Axiomatizing Test Data [Wey86] E.J. Weyuker. "Axiomatizing Software Test Data Adequacy". IEEE Transactions on Software Engineering, SE-12(12):1128-1138, December 1986. Static text: branch adequacy. Axioms for dynamic: monotonicity, composition, nonempty etc. Point is to be able to analyze the ideal test sets for "closely related" programs (edit distance). Potentially speaks to the utility of mutation testing. Statement, branch, path, mutation, modified size x 12 axioms. GHM87 (Harlan Mills): Modules [GHM87] J.D. Gannon, R.G. Hamlet, and H.D. Mills. "Theory of Modules". IEEE Transactions on Software Engineering, SE-13(7):820-829, 1987. The Box. (RepFun o AbsOp) implies (ConOp o RepFun). "denotational semantics" on the abstract side. Modular proof (opposes DLP79). Their "module" is an ADT. No side effects allowed Clarke (Richardson): Lattice of dataflow path selection criteria [CPRZ89] L.A. Clarke, A. Podgurski, D.J. Richardson and S.J. Zeil. "A Formal Evaluation of Data Flow Path Selection Criteria", IEEE Transactions on Software Engineering, 15(11):1318-1332, November 1989. Formalization of dataflow paths across a control flow graph G with def and uses/predicate, uses/compute to classify a dozen different selection techniques. All-paths, all-def, all-use, all- Point: software engineering means bringing a formal basis to all phases. Meta-validation of testing support tools/processes. Good example of checks-and-balances upon the literature Young & Taylor: Taxonomy of Fault Detection [YT89] M. Young and R.N. Taylor. "Rethinking the Taxonomy of Fault Detection Techniques", in Proceedings of the 11th International Conference on Software Engineering, pp. 53-62, Pittsburgh, PA, May 1989. Old way of static vs dynamic useless except for stage-of-applicability Folding and Sampling. Peak of the pyramid is infeasible. Hybrid techniques reach the interior of the simplex. exact ranking along the perimeter, ranked by power/cheapness: Testing: exhaustive, path coverage, mutation, Branch, Node Validation: auto-proof, reachability, dataflow, structural Atlee & Gannon: State-based Model-checking of Event-driven Requirements [AG93] J.M. Atlee and J.D. Gannon. "State-Based Model Checking of Event-Driven System Requirements", IEEE Transactions on Software Engineering, 19(1):24-40, January 1993. Translate SCR models into CTL models (a hardware FSM language) with a series of tricks (enumerate all the 'unchanged' SCR inputs, represent modes as states with predicates on transitions. Instantaneous transitions become new states. Weaken/strengthen exit conditions with loops back to self). Use CTL model checker to find deadlocks, races, broken assertions. Examples: ventilation, cruise, water level. @@map back onto SCR modes naturally? STATEMATE does much of the same analysis, perhaps more easily. [ILL75] (Luckham): Auto-Verification (???) [ILL75] S. Igarashi, R.L. London and D.C. Luckham, "Automatic Program Verification I: A Logical Basis and its Implementation", Acta Informatica, 4:145-182, 1975. Three caballeros from SAIL write very early mlisp program to read in simplified pascal, annotated with entry/exit assertions, and mechanically map the assertions via Hoare/Wirth's Pascal semantics to spit out 'final' versions of corresponding verification propositions (then to be passed to Luckham's eventual theorem prover). Point: we once had dreams of automation. Examples ranged from factorial (recursive and procedural) up to a mini-compiler. Debra: TAOS [Ric94] D.J. Richardson. "TAOS: Testing with Analysis and Oracle Support", in Proceedings of the 1994 International Symposium on Software Testing and Analysis, pp. 138-153, Seattle, WA, August 1994. Vision of specification-based testing integrated into the development environment and development process. Tests could be automated, generated by random grammars up through custom harnesses; then checked against oracles (as simple as diff against known-good output to 'interpreted' specifications). Metapoint: testing is as ineffective as human testers' vigilance. ProDAG to visualize what parts of the program tests exercise. @@metrics?? Reliability & Safety Goel: Reliability Models [Goe85] A.L. Goel. "Software Reliability Models: Assumptions, Limitations, and Applicability", IEEE Transactions on Software Engineering, SE-11(12):1411-1423, 1985. Mini statistical primer on models of stochastic processes -- Gaussian (large N) and Poisson (rare event) distributions. Also choose model of 'decay': there's no 'wearout' like hardware, but errors are flushed out sooner than later. Expose assumptions about the timing of error fixes. Result: clarify various definitions of reliability, once you step at all away from Dijkstran manicheanism. Assumptions: faults are independent; fixes are faultless; faults decline with testing (users adapt); testing reflects operations; reliability proportional to remaining faults; equal probability of detection. MTBF, Count, Seeding, and random Testing models. MBTF seemed to be his abstraction of choice. Mills gets credit for fault seeding, per ecosystem population estimation. Leveson: Safety [Lev86] N.G. Leveson. "Software Safety: What, Why, and How", ACM Computing Surveys, 18(2):125-163, June 1986. Lots of vivid examples. Safety is like security, in that hard invariants must be maintained: except safety conditions must be avoided instead of provided. But safety is traded off against reliability (and robustness): safe thing may be to fail-safe at the slightest provocation, for example. Risk displacement, if not elimination. Point: different development processes. Zero-defect safe systems need a minimal number of chefs; open-source zoo better for security software. Don't forget definitions of fault (causes failure) and hazard (?unanticipated? conditions leading to mishap). Traditional SE doesn't work well: often no chance of run-time patching, and failures too harmful. Hazard analysis by fault-trees, propagating risks back to modules. Common mode analysis: think what faults could affect several modules. Cites RTL, timed Petri Nets. Hints at ergonomic/UI failures. Integrity: need for self-diagnostics and 'malicious' threats. Solution techniques much as for formal program proof -- but 1) must scale up and 2) then-seen as especially socially urgent in the Cold War/SDI age of nuclear threats/CPSR activism. [Parnas, again, acerbically out front] Paper says little about additional network threats. @@the exam really ought to include Neumann Environments Teitelman & Masinter: Interlisp [TM81] W. Teitelman and L. Masinter. "The Interlisp Programming Environment", IEEE Computer, 14(4):25-33, April 1981. Pros and cons of sustained expert activity in a single-language system/environment. Version control, masterscope cross-references, do-what-I-mean, multilateral extensibility, file packages. Experimental programming. Evolving environment. Was started in 1966, and was popular by 1974. Awarded the ACM "Software System Award" in 1994. PS83: Transformational Programming [PS83] H. Partsch and R. Steinbrueggen. "Program Transformation Systems", ACM Computing Surveys, 15(3):199-236, September 1983. Extensive review of different programming environments which use transformation steps. Transformations must be reflexive, transitive (for composition) and monotonic (for correctness). A lot of then-interesting techniques seem to be in optimizing compilers now. Mostly helps with 'accident', imho, except to the degree it's a selection from a reuse library of "paradigmatic" (archetypal) programs. Dynamic programming credited to Dragon book. Irvine SPECIALIST tuned running matrix codes [Kibler+77]. Central dreams were: auto-proof and auto-parallelizing. Reiss: Field [Rei90] S.P. Reiss. "Connecting Tools Using Message Passing in the Field Environment", IEEE Software, 7(4):57-66, July 1990. Broadcast message server to achieve same level of user-friendliness and integration as the PC. Pure-text marshalling of requests/notifications (printf/scanf, in fact). Message filtering was also based on text. "active servers". Events, rather than files, ide, or progbase. Remarkable results: he actually built most of the environment he envisioned -- and he got network access "for free". Became commercial Softbench product from HP (grudgingly credited). Arcadia [Kad92] R. Kadia. "Issues Encountered in Building a Flexible Software Development Environment: Lessons Learned from the Arcadia Project", in Proceedings of ACM SIGSOFT '92: Fifth Symposium on Software Development Environments, pp. 169-180, Washington, DC, December 1992. Crosscutting issues: heterogeneity, components, type systems, dynamism, concurrency, event-based integration. Just memorize the whole damn paper.@@ Reps & Teitelbaum: SynthGen [RT84] T. Reps and T. Teitelbaum. "The Synthesizer Generator", in Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering Symposium on Practical Software Development Environments, pp. 42-48, Pittsburgh, PA, April 1984. If it's anything like the earlier Cornell Program Synthesizer project (RT84 is also described in a sidebar to Field), it's a pure ADT editor, with a mixed mode for typing in "expressions" directly (which are immediately parsed and checked), but otherwise limited to filling in slots (see PS83). TN92: Definition of Tool Integration [TN92] I. Thomas and B.A. Nejmeh. "Definitions of Tool Integration for Environments", IEEE Software, 9(2):29-35, March 1992. presentation: appearance and behavior, interaction model control: provision, use data: interoperability, exchange, consistency, nonredundancy, sync process: process step, event definition Framework due to Tony Wasserman. 1990. Tichy: RCS [Tic85] W.F. Tichy. "RCS-A System for Version Control", Software - Practice and Experience, 15(7):637-54, July 1985. The usual. Technical difference was storing reverse-deltas (and fwds for branched), optimizing the 'usual case' of access. Well-integrated. Tichy also advocated AI's role in SE, but does not bear on this paper. Process Harlan Mills: Cleanroom [MDL87] H.D. Mills, M. Dyer and R.C. Linger. "Cleanroom Software Engineering", IEEE Software, 4(5):19-25, September 1987. "Pencil and paper were good enough for my grandfather, dammit!" Reported significant gains in quality by forcing all design work to proceed directly before writing a line of code and firing up a machine. Overblown analogy to defect-prevention through controlled environments in semiconductors. An intellectual (and commercial) heritor of Fag76. That's why you can't prove the benefits aren't just from putting 90% thinking upfront (mathematical or otherwise). Osterweil: Processes are Software, too [Ost87] L.J. Osterweil. "Software Processes Are Software Too", in Proceedings of the 9th International Conference on Software Engineering, pp. 2-13, Monterey, CA, March 1987. It's process all the way down. Keep refining until you have rules so small they can be fully programmed for automated enactment. Put programmers in their place -- call them like subroutines when creativity is called for. Double indirection of process programming: indicates new languages, etc. APPL/A Value of process description: externalizable, rigorizable, analyzable, publishable, storable, executable. @@ Are internet virtual-organizations enacted process programs? "process descriptions are one of the most valuable resources which we as a society have" -- whoa, Nellie! Boehm: Spiral Model [Boe88] B.W. Boehm. "A Spiral Model of Software Development and Enhancement", IEEE Computer, 21(5):61-72, May 1988. Call Off Your Old Tired Documents: the real reason we write them is to manage risk, so surface that requirement and go after successive elaboration -- and early detection of high-risk parts. Determine-objectives, evaluate-alternatives, implement, plan cycle repeated as needed. Vs. code-n-fix, waterfall, evolution, transformation (and he claims to subsume all of 'em). Could have been called a risk-refinement model: produces a hierarchical concretization. TRW success story, but where else? Tied to lots of USC output on cost models, but not clearly dominant in industry at present. [BFG93] Fuggetta & Ghezzi: SPADE [BFG93] S. Bandinelli, A. Fuggetta and C. Ghezzi. "Software Process Model Evolution in the SPADE Environment", IEEE Transactions on Software Engineering, 19(12):1128-1144, December 1993. Wow. And they wonder why process didn't take off A stupefyingly complex process model masquerading as a simple one -- in the interest of reducing everything to nodes and (weighted!) arcs (so that all higher-order concepts like 'type' would be fully mutable), they kept extending and extending Petri nets into ER nets until they ablated off any possibility of analysis assitance -- and for no gain in comprehensibility. SPADE process engines fork off activities as tokens enter new tasks, but unlike other systems, can be paused, have their models scrambled, and restarted. Offers concurrency after an initial boot loader. Tool wrapping better handled in Marvel. There is a very general-purpose distribution language struggling to get out here. Whether it makes the process engineer's life easier is an open question. 3 approaches to meta-process: the process program is 1) ignored (APPL/A) 2) encoded as choices in the same language 3) self-modifying (reflexive). Bolcer & Taylor: Endeavors [BT96] G.A. Bolcer and R.N. Taylor. "Endeavors: A Process System Integration Infrastructure", in Proceedings of the IEEE Computer Society Fourth International Conference on the Software Process, pp. 76-89, Brighton, UK, December 1996. Just the usual promotion of its PlasticMan extensibility: that unlike its predecessors almost every detail has an open interface (hence replaceable). This paper per se does not discuss any sample processes of significance (except Endeavors-in-Endeavors). Fagan: Inspection trumps Walkthrough [Fag76] M.E. Fagan. "Design and Code Inspections to Reduce Errors in Program Development", IBM Systems Journal, 15(3):182-211, 1976. Walk-throughs are too informal -- and too much under the control of the original coder -- to show the kind of sustained results (20-25% lifecycle reductions) of Fagan's formal interventions. Culture is key: trained moderators and retribution-free enlightened management. 2-4 person teams, armed with checklists of likely errors (tuned to error distributions from the same project's earlier days, ideally) do their homework, then get together to focus solely on finding errors (not solving them). The use of metrics for management -- for costing, predicting lines of code, and improving personal quality -- all presage the SEI CMM a decade later. A fine example of modernist 70's graphic design: IBM systems journal has always been slicker than the academic stuff (and IEEE, in particular, feels stuck in 1958!) Kaiser: Marvel/Oz [KFP88] G.E. Kaiser, P.H. Feiler and S.S. Popovich. "Intelligent Assistance for Software Development and Maintenance", IEEE Software, 5(3):40-49, May 1988. Marvel's rule-based forward and backward chaining connects basic software process tasks. Some emphasis on namespace management: it can attempt to infer the module of interest and, say, automatically check it out, lock the whole module, analyze, compile, and test as it's edited. Wolf & Rosenblum: (Balboa?) [WR93] A.L. Wolf and D.S. Rosenblum. "A Study in Software Process Data Capture and Analysis", in Proceedings of the Second International Conference on the Software Process, pp. 115-124, Berlin, Germany, February 1993. An observer with a form rode shotgun with a build manager (the hub of activity). Coupled with the automated data collection on the process, they ran several inference rules to measure times for periodic (DO) and nested events (editing code, leaving voice mail, etc). The results of automatic classification identified hotspots in the architecture. Reuse Boehm & Scherlis: Megaprogramming [BS92] B.W. Boehm and W.L. Scherlis. "Megaprogramming", in Proceedings of the DARPA Software Technology Conference 1992, pp. 63-82, Los Angeles, CA, April 1992. Now-completely-conventional arguments for reuse-driven development. The buzzword never caught on. The economic arguments are straightforward: it costs 10% extra to design for reuse in this project; 30% in this family; 50% for external users. But reused code is 10x cheaper-- if you don't have to poke around inside. 4 necc features: Product line approach, domain-specific arch, reuse tools, *management role for reuse*. 5 elements: architecture (design), descriptions (spec), component construction (write), composition (read), interchange (sell) Hinted at IPR issues for a component marketplace. Didn't mention that vendors hate commodification. No mention of configuration management. Reuse reminds customers of extravagant requirements ($50M to shave 3 sec). Krueger: Reuse [Kru92] C. W. Krueger. "Software Reuse", ACM Computing Surveys, 24(2):131-184, June 1992. Survey paper of factors inhibiting and supporting reuse since 1968. "Cognitive distance" of what's-available from desired-construct. Naming, metadata. Has Altavista changed the component marketplace? Open Source? 8 levels: HLL, scavenging, components, schemas (templates, archetypes), app/report generators, VHLL (executable specs), transformational (spec->impl), architectures. Footnote: the MacIlroy marketplace proposed at Garmisch *really succeeded* -- we *do* have libraries for maths, graphics, IO, etc -- at the level of granularity he discussed, it completely came to pass. Batory: GenVoca [BG97] D. Batory and B.J. Geraci. "Composition Validation and Subjectivity in GenVoca Generators", IEEE Transactions on Software Engineering, 23(2):67-82, February 1997. They have a model for composing what I'd call the innards of a component. The real contribution is not just their toolset for specifying program-parts and grammar-driven synthesis of 'stacks', but in the design-rule checking. They have a shallow model that declared bitmaps of 'attributes' required or expressed by layers of the stack; since values are propagated, there can be conformance 'at a distance' (e.g. vs. pep hop-by-hop or end-to-end only). The remaining semantic compatibility is assumed to lie in the grammar. To me, subjectivity very similar to categories/protocols/subject-oriented programming, though Batory takes such pains to differentiate their mechanism. Shorn of the code-generator, their model of components is indeed a collection of perspectives, projecting different interfaces (OLE Monikers) to different requestors. XML ignore rules. #define propagation in classic C. The realm model just plain doesn't make sense. Measurement Curtis: Measurement in SE [Cur80] B. Curtis. "Measurement and Experimentation in Software Engineering", Proceedings of the IEEE, 68(9):1144-1157, September 1980. validity of a mathematical construct: understand statistics before you use it (to measure and control the process, of course). Types of things we measure: control structures, interconnectedness, size. Introduced Halstead's software science [bad@@], McCabe cyclomatic (indep-paths) metric [good@@]. These actually had explanatory power back then. Cited evidence gotos-bad, structure & indentation-good. (Selby): Empirically Guided SW Dev [SPSB91] R.W. Selby, A.A. Porter, D.C. Schmidt, and J. Berney. "Metric-Driven Analysis and Feedback Systems for Enabling Empirically Guided Software Development", in Proceedings of the Thirteenth International Conference on Software Engineering, pp. 288-298, Austin, TX, May 1991. Amadeus helps identify the 80/20 -- classification models isolate risk. Supports multiple metric paradigms: SEI process maturity level Basili/Weiss goal/question/metric Selby/Porter classification paradigm etc Collection agents triggered on wallclock, on APPL/A events. Scripting language for filtering. Classification tree for predicting. Scalable? Evolvable (process)? Organization-specific calibration. Gould: Usability Checklist [Gou88] J.D. Gould. "How to Design Usable Systems" (excerpt), revision of Chapter 35 in M. Helander (Ed.), Handbook of Human Computer lnteraction, pp. 757-779 and 784-789, North-Holland, 1988. See my review for Grudin's class, usable-systems-gould. @link to Brooks' conceptual integrity. Write the manual first. Early focus on users, empirical study, iterative, integrated. Capability Maturity Model [PCCW93] M.C. Paulk, B. Curtis, M.B. Chrissis, and C.V.Weber. "Capability Maturity Model, Version 1.1", IEEE Software, 10(4):18-27, July 1993. What can one say? It's the CMM. They're wrapped up in their own world, dancing angels on the head of SEI all Process capability, performance, maturity: Initial, Defined, Repeatable, Managed, Optimizing Not scalable down; gap between it and PSP [Humphrey@@?]. Not based on empirical data. No guarantee of product quality -- ISO 9000 all over. Basili/Selby/Hutchens: the big paper with the little template [BSH86] V.R. Basili, R.W. Selby, and D.H. Hutchens. "Experimentation in Software Engineering", IEEE Transactions on Software Engineering, SE-12(7):733-743, July 1986. A survey of experimental designs for software engineering, and a survey of some classic results in the field to date. Inspection as effective as debugging; more cost-effective. SS and cyclomatic complexity related to difficulty [Curtis]. Slicing happens. Design langs better than flowcharts. Static typing increases reliability. Shneiderman found no edu. benefit to flowcharts. Indentation significantly improves comprehension. N-version invalidated fault-independence. Reuse is 80% cheaper [NASA]. When to ship/install patches. definition: [motivations] [objects] [purpose] planning: [design] [measurement] operation: [preparation] [execution] [analysis] interpretation: [domain] [extrapolation] [impact] Roots of UM College Park's current reputation were sown long ago. NASA SEL. UI / CSCW / Hypertext Brad Myers: UIST sota [Mye93] B.A. Myers. "State of the Art in User Interface Software Tools", in H.R. Hanson and D. Hix (eds.), Advances in Human-Computer Interaction, volume 4, Ablex, 1993, pp. 110-150. UI is hard because: iteration, concurrency, real-time, robustness, untestable, high coupling, complexity, language support. Specification techniques: state-transition, cf grammars, events, declarative, constraints. Frameworks. Automatic IDL-driven generation. Graphical: prototypers, cards, IBuilders, prog-by-demo. Krasner& Pope: Model-View-Controller [KP88] G.E. Krasner and S.T. Pope. "A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-89", Journal of Object-Oriented Programming, 1(3):26-49, August 1988. detailed implementation notes (e.g. view invalidation scheduling) but little of fundamental novelty. Notification is a responsibility of the Controller object, which essentially manages a list of listeners in a global (Object-class-variable) mapping dictionary. Chiron separated this out, as well as synthetic views connected to multiple Ms, Cs. Curtis-Krasner-Iscoe: SW Design Process for 'Large Systems' [CKI88] B. Curtis, H. Krasner and N. Iscoe. "A Field Study of the Software Design Process for Large Systems", Communications of the ACM, 31(11):1268-1287, November 1988. 'exceptional designers', nee 'superconceptualizers' (in "software process models under the lamppost", an earlier draft). Argued that domain knowledge -- as embodied in key personnel (coalition) -- was a dominant factor, trumping even process. Customers unwilling to pay for education up-front. "ecological" model of field studies. Layered model of processes suitable for individual, team, project, organization. 3 problems: thin knowledge, fluctuating requirements, communication breakdown Grudin: History of CSCW [Gru94] J. Grudin. "CSCW: History and Focus", IEEE Computer, 27(5):19-27, May 1994. See review in irvine/classes/hci and 221. Roots in several fields. US small systems/commercial focus; European theoretical/large-organization focus. Traditional 3x3 of (fixed, defined, arbitrary) x {place, time} matrix classification. Evolution over the years outward from personal systems to small-group and inward from organization-wide IS/IT to departmental servers. Halasz: Dexter HM [HS94] F. Halasz and M. Schwartz. "The Dexter Hypertext Reference Model", Communications of the ACM, 37(2):30-39, February 1994.  HYPERLINK http://wwwis.win.tue.nl/2L690/cgi/get.cgi/siegel/dexter.html http://wwwis.win.tue.nl/2L690/cgi/get.cgi/siegel/dexter.html storage/runtime/within-component virtual machine. Very overdetermined in light of the Web: genuinely aimed at a subset known as 'real' hypertext with 'real' link models, 'real' security, 'real' consistency enforcement, etc. Had UUIDs, IIDs, garbage collection, 'PATCH', referential members: all very hard to retrofit, would have inhibited Web adoption. Jarczyk :Hypermedia Design Rationale ?? [JLS92] A. Jarczyk, P. Loeffler and I.F. Shipman. "Design Rationale for Software Engineering: A Survey", in Proceedings of the 25th Annual IEEE Computer Society Hawaii Conference on System Sciences, pp. 577-586, January 1992. Models of argumentation: IBIS, Toulmin (so,since,unless; 1958) variants. Other rhetorical models. As reified into support software (implicit argument it should converge with hypermedia systems). Some experience reports: 3-6x cost-effective b/c of early bug detection. Interoperability MHO96 (Heimbinger/Osterweil): Multilingual integration [MHO96] M.J. Maybee, D.M. Heimbigner and L.J. Osterweil. "Multilanguage Interoperability in Distributed Systems", in Proceedings of the 18th International Conference on Software Engineering, pp. 451-463, Berlin, Germany, March 1996. The Q IPC system. A great example of evolutionary narrative. First: a small wrapper above ONC RPC: essentially multi-lingual stubbers over standard XDR/RPC model. V2: multithreading required abandoning select() for signals (and thus implemented in separate process spaces from Ada, in particular) to break synchrony-blocking cycles. V3: further exposing it as a general message interface, breaking the dependency link of 'procedure' call. They're trying to hide marshalling; much as Waldo attacks hiding latency, Internet-scale and Internet-diversity requires rethinking marshalling. Not always a canonical format (e.g. negotiable byte order exception), exquisitely sensitive to latency and data packing (e.g. perceived time to render; "materialization"). Link to a fun Heimbinger rebuttal to CORBA based on negative experiences at Colorado in the references. Purtillo: Polylith [Pur94] J.M. Purtillo. "The Polylith Software Bus", ACM Transactions on Programming Languages and Systems, 16(1):151-174, January 1994. The abstraction helps defer all configuration/topology/"connector" issues to design (and hopefully, eventually) run time. Ideally suited for scientific distributed computing, to experiment with new mappings to processors/threads. Handled multilanguage marshalling if you asked it to. Its MIL (IDL) was pure method signatures (no classes). Started in 1985. No concern for Internet-scale (latency, partition, recovery). Understanding Weiser: Program Slicing [Wei84] M. Weiser. "Program Slicing", IEEE Transactions on Software Engineering, SE-10(4):352-357, July 1984. Applied the 'obvious' insight that you want to focus only on the statements that could possibly include the fault. Take a (set of) variable of interest and subset the block of code. Minimal slices are incomputable in general (turing-complete), but hey, his entire research project could be run in 30 seconds on a modern Alpha -- why don't we have his tool in today's debuggers? One answer: modern OSes make any system call equivalent to havoc(). But still, there's lots of 'real algorithms' still being developed or is it that pointer arithmetic screws things up (and Weiser was too polite to rub that in) -- but then shouldn't Java be revitalizing interest here (or is that what metamata's about already?) Factoids flowchart [H. Goldstine and J. von Neumann47] annotated flowchart proof [Floyd67] survey of testing methods' role throughout lifecycle [ABC82] Even proven programs require testing [Goodenough & Gearheart 75] 'Termination condition' (added to 'partial correctness') [Dij76] 7 Myths of FM: perfection, only by proving, only for nukes, hard, expensive, opaque, req training, nobody uses [Hall90] Butler Lampson: "all problems in Computer Science can be solved by another level of indirection." "A distributed system is one on which I cannot get any work done because a machine I have never heard of has crashed."-- Leslie Lamport Notes diffusion requires cultural alignment and training. [Orlikowski 92] Agents must earn competency and trust by machine learning [Maes 94] Human performance model [Card, Moran, and Newell 83] C2 [TMA+96] Presence of bugs , not absence [DHL72] definition of abstraction? @@ 4-color proof Appel & Haken 76 @@"Cigarette Smoker's Problem can't be solved with P and V" Weg92: inherent incompatibility between reactiveness and deductive reasoning -- OO call chains not tractable analytically. Alexander64 was cited as early as Naur68! "Middleware" was in the Garmisch report, too! Separation of Concerns, [Dij77] "A Discipline of Programming" Midevalism: "on the cruelty of really teaching CS" "On the design and development of program families," [Par76] IEEE TSE. Conway's Law: "How Do Committees Invent", April 1968, Datamation "Global Variables Considered Harmful", Bill Wulf and Mary Shaw, 1973 von Parais on Evolution@@ Cobbler's Children [FWA+98] "Web-Based Development of Complex Information Products". First-class links, OHS, annotation, versioning, access control. Event notification missing. Taylor's "Important Things To Condiser" ========================================= So what Who cares Technical contribution Critical aspect or key problem solved Enabiling technologies Useful legacies Scalability Performance  /6FM  1 ~ e (QQX Gp.5CY 55^jqP\JP!!!!##&$3$A%G%Y%`%%%'' (4(*+Y++////12U2s255o5|57777V8o82;65B*b /:-F-3 N \ ~  e m o;Q!@&@& /:-F-3 N \ ~  e m o;Q~E¿~ulcZ   J  s      h !*y, !gSC !k !Gi !>S !"~EUam2.[vUY@&!@& & FEUam2.[vUY|Rj~{uqmgc_[WWz !v# !) !? !? !0v                Y|RjJ^!!!"##Q$A%H%Y%%_'''S((@&!@&J^!!!"##Q$A%H%Y%%_'''S(())Q***+2--X..//0112[334}ztpmievA !p< !jE !WEC !r !X !px !j+ !&())Q***+2--X..//0112[33455y6677789@&!@&455y6677789:;2;;<==!>S>>_?@AABBB6C~C)DE"FMFF6HHHI;Kyuqkgc- !3 !y  ! ! !bX !O !<:6 !AmR ![&9:;2;;<==!>S>>_?@AABBB6C~C)DE"FMFF6HHHI;K!@&2;9;t;;==\==>>?p>qcqqsotu&uuvvw~ztplfb !eR !+fV ! !$ !x !QK) !n ! !%jjokmnn8oSo>p>qcqqsotu&uuvvw,y2yTyy1{{||}@&!@&uuvvWww,y1yTyZyyy1{|g|k|}})}>}> 18pxdSZN[ jǐܐ^ dkҕ@M6OmnFq.vEz=J0J*jU jUB*56\w,y2yTyy1{{||}Z}/~~\h܃ 19Mpt8S̊u@͌ ď~zvrlhe !>W !?$ ! !^ !:F ! !;= ! '}Z}/~~\h܃ 19Mpt8S̊u@͌ @&!@& ď{ǐݐ' ˓1(dZfڙmYc!@&@&ď{ǐݐ' ˓1(dZfڙmYcqY=K}ysokh~e !s) ! !nm !i !| ! !3 !R &cqY=KcѥLͨ.o(]!@&@&KcѥLͨ.o(]֫ 'FVȭQbcǯޯÿzqha         34E@Po9 n'hz !&JcjFPEB*65 ֫ 'FVȭQbcǯޯ-9E & F & F & F-9E]  i  z    / =!"#$%|,,  c yg(,,(d'`iDyK =http://wwwis.win.tue.nl/2L690/cgi/get.cgi/siegel/dexter.htmlyK zhttp://wwwis.win.tue.nl/2L690/cgi/get.cgi/siegel/dexter.html+ [H@HNormal 1$ddB*CJOJPJQJmH nH @@ Heading 1$@&5CJKHOJQJ:: Heading 2$@&56OJQJ44 Heading 3$@&OJQJ88 Heading 4$@& 5OJQJ.. Heading 5@&CJ22 Heading 6@&6CJ<A@<Default Paragraph Font..Address 64Y@4 Document Map-D CJ:E:List Continue 2 x0"0 Blockquote hhO1CITE6"OA"Comment<(OQ( Definition6>r>Definition Listh:b:Definition Term \\ Preformatted% {@ 6!v% CJOJQJ0O0 Typewriter CJOJQJ,O, HTML Markup<B*$O$CODE CJOJQJ4Z4 Plain Text CJOJQJ&X@&Emphasis6>*22H1$@&5CJ0KH$OJ QJ .O.H2$@&5CJ$OJ QJ 00H3 $@&56CJOJ QJ *O*H4!$@& 5OJ QJ ,,H5"@&5CJOJ QJ ..H6#@&56CJOJ QJ 0OA0Keyboard5CJOJQJ$OQ$SampleOJQJ W@a Strong5$Oq$Variable6NNz-Bottom of Form ($$d<CJOJ QJ HH z-Top of Form )$&d<CJOJ QJ (U@( Hyperlink>*B*E!                   \v#J+3_;~CKSSd[b*k=szB qŨE$ u L x GHv92;uJEYcipY(9;K[j} cEZ\^`befhklnqE4;K`wďKE[]_adgjmormEX <DDUUZblmp|37\beky}IM . 0 @ B L x ~ ` d } ; A \ b g o w u|6:EH&,af*.?JXcXbjrKPdns|Vg H!M!U!X!d!i!""##P#S#_#d#####$$$$c%f% '''"'''\*b***+(+-+5+@+H+++,,,,- -`-e-u-}---. .......$0-000*1311152:2n333333334444445666666667777'7?7F7I7U7789!9"9(9;9?99999999999s:{:::::::::p;x;;; < <g<k<==??!?)?>?D?????+B2BwB~BBBBBBBC C?CECCCCCDD-D3DDDnFrFFFFFPGTGqGuGvGzGKHSHHH~IIIIKK,K3KKKNNOOtP{PPPPPPPPPPPPPQQRRRR7T;T1U>UAUFUVUZU[U`U[VaVbVgVVVVVdWmWWW8Y@YHYRYTY\YsY}Y[[[[\\\\\\]]]]]]U^^^g^k^^^__``````bbbbccccffffffffffffgghhhhjj8k>kZk^k_kek!l)l^lhlmm9n>n.q2q@qFqKqOqPqXqrrrrrsss2u7u:uBuDuSu`ueuouwuzuu3w7wwwlx{xyyyyzz{ {?{D{{{{{{{{{||||~~āƁˁہ#(NSlo~"DI 8=[_`eم&.EJ "ku͈ӈԈوڈ%*045=jtRUSUŎΎ׎َݎ Ґؐ(<z,@#tzڕ.<ۗY`ƚ̚ΚҚӚݚ'&-5KQnt_c {T^aj/6 NX5:=B)3@HFP} G7E:_N[8<NWXm{U c V X 3 9 Y w{Ct9DdsIU;?U`ceTWF 9 < j p *!,!a!j!!!####9$;$$$B%E%%%&&'#'''''(((())**+I++++ , , ,6,>,?,G,,,..z.}...,/G/H/Z///1411134v4z4445 5"51555 6 666:7G7779F9999999::D;I;= =>>!?)???@@N@Y@AAAAHBKBDD1G8GqG{GGGHHII'K4KxK|K8M9MMM?OOPPSPVPPP QQQQRRRRUVUaUUU*VrVVVWWWWYY=Y@YdY~Y[[[[\\\\\]V]Z]j]t]]]^^_1````` ccc$cVc]ccc5d8dffTgYggi*iiZkvkkmvmmm.qYqqqrs[uxuu8vxx}xxyyEyIyyy{{E|H|9C}y7[f/5MQ#be~ QRˈ>(b‹ċ΋ƌ/ˏӏl5?$TW˔̔ VYYlޛls';kuD֤ͤ E`~G Rohit Khare1Kaleidoscope:BBEdit Backups:Word Work File A 3182 Rohit Khare1Kaleidoscope:BBEdit Backups:Word Work File A 3182 Rohit Khare2Kaleidoscope:Rohit:ICS:Phase II:Phase II Checklist Rohit Khare2Kaleidoscope:Rohit:ICS:Phase II:Phase II Checklist Rohit Khare0Kaleidoscope:BBEdit Backups:Word Work File A 542 Rohit Khare0Kaleidoscope:BBEdit Backups:Word Work File A 542 Rohit Khare0Kaleidoscope:BBEdit Backups:Word Work File A 542 Rohit Khare0Kaleidoscope:BBEdit Backups:Word Work File A 542 Rohit Khare2Kaleidoscope:Rohit:ICS:Phase II:Phase II Checklist Rohit Khare*Kaleidoscope:Rohit:ICS:Phase II:rk-p2.html}~  .88. OJQJo( hhOJQJo( hhOJQJo(}~ @xxxx8E`@ GTimes New Roman5Symbol3 Arial3Times? Lucida Sans;Helvetica7CourierU  Lucida Sans Typewriter? Courier NewCLucida Bright5 Geneva"pHhK4K4(4 H/* C$0dq5Ec[AG93] J Rohit Khare Rohit Khare Oh+'0t  $ 0 < HT\dl' [AG93] Jt AG9 Rohit KhareohiNormalh Rohit Khare2hiMicrosoft Word 8.0d@F#@@B捾@B捾  ՜.+,D՜.+,< hp  ' UC Irvinew/Hq  [AG93] J Title 8@ _PID_HLINKS'A T=http://wwwis.win.tue.nl/2L690/cgi/get.cgi/siegel/dexter.htmlx  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrsuvwxyz{}~Root Entry FH\Data t1Table|4WordDocumentSummaryInformation(DocumentSummaryInformation8CompObjX FMicrosoft Word DocumentNB6WWord.Document.8