if you can fill this hole]
Nothing that Ross Ashby and JSD didn't know about already
looks a little like hypertalk, but notation not of the essence.
-ve: some small Z errors -ve: Includes filter's state as part of model of filter. amow: should use IO relations
Event-System style: invoked, announced, methods, events, states, start,... NOT classes
Analysis, special cases,....
| Old\New | Alive | Null | Out of scope |
|---|---|---|---|
| Alive | * new | NULL | } |
| Null | new | NULL *X | } |
| Out of scope | 0 | 0 | declare |
| Old\New | Alive | Null | Out of scope | Dead |
|---|---|---|---|---|
| Alive | * new Z | NULL Z | } Z | delete ε |
| Null | new | NULL *X delete | } | 0 |
| Out of scope | 0 | 0 | 0 | declare |
| Dead | new | NULL | } | * X delete X |
1986..87: Logical Data base Design
1992: First technologically independent logical data model
1993: LDM has 362 entities and 1318 data elements
| User | X | 0 | 0 | 0 | |
| X | Interface | 1 | 0 | rare | |
| 0 | 0 | 0 | Business | OOCRUD | some |
| 0 | 0 | 0 | 0 | Persistence | often |
| 0 | 2 | 2 | 2 | 2 | System |
system & persistence: wrap well defined technical features, so mostly code and debug
Business: analysis, understand first
Interface: prototyping... coding trivial
[...]
Engineering methodologies are much more methodical than development methodologies. Consideration of past, present, and future, as well as adherence to standards and practices are all core principles of software engineering. Although not perfect, these methodologies facilitate the design of systems with intent and that embody the characteristics of reliability, maintainability, and scalability. Such results come at a price however.
Claims experience shows that process control loops need to be replaced by OO designs(SEI Teh report CMU/SEI-93-TR-14 Aug 1993)
People help in the retrieval via newsgroups. "self appointed intelligent librarians".
Products and services.
informations borkers/librarians on the net.
Willl need to keep a software technology watch over assets standards services trends.
NEED: standards and Processes... like the news eg.
A is_a_kind_of B that does V in a special way
A has_a B class A:... { ... B name; ...} A refers_to_a B class A:...{ B* name; ...} A implemented_using B class A: private B {....} Don't!
A is_like_a B For some C, A and B come from a template C
Good objects are difficult to write because: behaviors and components are sometimes complex + likely to be used in unimagined contexts + depend on non-OO software with nonencapsulated sideeffects + C++ object model does not expand (without care) across client-server or peer-peer environments
Testing is easier: hierarchies reuse code - reexercise + public interfaces defined early allowing earlysimilar test drivers -> automation
Clashes: C++ vs DCE exceptions + extant non-thread-safe libraries + thread support in C++ practically non-existant
Reccommend: Use code analysis tools to aid code review, self-istrumenting tools to detect bugs, prepare to develop in house tools, make development environment that encourage cosistent testing.
Convergence is a liveness property: If faults stop occuring then the system eventually reaches an OK state
OK state = legal.
atomic commitment (two-phase commit), data transfer, Byzantyne agreement, sliding window, delay insensitivity, impossible requirements, design methods.
if you can fill this hole]
p97: "The 'cowboy' or 'big magic' model. In this view, gifted people create software through apparent magical means, with no particular guidance or support"
Can integrate process and heroism by taking a people centred view and seeing software production as a dynamic, complex, etc. system for solving problems.
Reply: John Henry or Pecos Bill, trial by cold pizza,...
Risk management - prevent failure vs Goals - maximize success
Risk{identification<=>planning<=>resolution}.
V^ V^ V^
Goal setting<=>Task Planning<=> Task completion
Risk based evolution.
[Grosberg93] [ArnoldK94] (C++ advice)
Class of objects without actions<>class of objects with some actions.
Failure to find epistomological foundations of the IS-A link - six different generic-generic and four kinds of generic-individual relation
"The point here is that the concepts in the real world, which programs attempt to model, do not come in neatly packaged hierarchies." (cf GoldsteinAlger92)
"There are no standard conceptual hierachies. Given a domain and a specific PURPOSE, certain concept hierarchies would be clearly preferable than others, but such policy decisions are best left to the USER of the programming language[...] What a PL provides is a set of mechanisms [...] restrict what can be implemented[but] they do not themselves validate some view of inheritance or other[...]" these are also just implemented concepts and do not not have a universal objective meaning....upto the designers to choose suitable mechanisms.
Two modes: asynchronous- after sending the sender does not wait, semi-synchronous - the sender will not send a message of the same type to the same receiver before the first message has been acknowledged by the receiver.
Assumes arbitrary delays and that messages can get out of order.
TLA formalization via send[a](M)::=net:| a><M.... Conclusions Now need to investigate inheritance. must spec both components and protocols...
[Hall96a]
[Barlas96]
Includes Floating point IEEE TSE paper -- where is it?
[ schwartz ]
Examples Booch C++(400 distinct DSs) and Gnu C++...
The GenVoca Model [Bat92b: BatoryO'Malley92, "The design and Implementtion of hierarchical software systems with reusable components", ACM Trans Softw Eng Methodol October 1992] , not OOP. Layered software components.
Analyse libg++: does not use inheritance to capture similar algorithms..
BoochC++: 18 varieties of deques! But can not use inheritance because need to carefully integrate concurrency guards and deque algorithms.
layered, high level, standardized abstraction
example P1 The P2 generator: the typex statement, container cursor,...
Results. on spell checking Decl Indep... Using Booch C++,libg++, P1,P2.... on 4 structures: Unordred linked list, unordered array, sorted array, binary tree P1 P2 had smaller LOC. P1 and P2 faster on all but sorted array.
Modification of P1/P2 easier.
software template
Example: Data Structures in terms of containers, cursors, and links.
[ paper.html ]
Walking through a scenario: tracing an "application assigning each activity to some component". each CRC card held by a different member of the team Often a cycle of What/Who questions: #(what_next; who_does_it).
[ http://www.math.utah.edu/ftp/pub/tex/bib/toc/ ] Nelson H. F. Beebe Center for Scientific Computing University of Utah Department of Mathematics, 322 INSCC 155 S 1400 E RM 233 Salt Lake City, UT 84112-0090 USA beebe@math.utah.edu [ http://www.math.utah.edu/~beebe/ ]
Ithaca Project,
Basic problm is identifying matching components.
"Final document contains the set of graphical representations, the component documentation, and a trace of the steps."
150 people almost all coding, feb92..94, 2MLOC C++ 14K classes, 142Kattributes 90K methods, 10K children, 5k overloaded method names. Use R/6000AIX/Motif. two days to compile and link. 10 minutes per class. Used Booch (all but one S_M team) increased functionallity and flexibillity heightened management. LOC tracked project but quality and delivery-on-time rewarded developers.
Iterative and incremental life cycle. Used a weekly build cycle. encouraged defensive coding and defect avoidance and preserving interface stability. Should have had recesses every three months when work is frozen and reveiwed. Wanted more incentives for code reviews, detailed documentation, internal consistency checks, and separate est teams.
classroom training: 120 hours OOA, design, patterns, programming + 50% design sessions with mentor. Spread out and reinforced. it takes application to learn to do inheritance correctly. 6 to 9 months before they get fully proficient in the new paradigm: 80% ok coders, 15% respectable journeyman designers, 5% top performaers at analysis and design. Biggest culture shift was from code to design.
Put best talent to work on tuning RAM and speed.
Systems requirements should include explicit flexibillity/extensibility criteria: Requirements Mutation Analysis. Use lowtech tools first, when design session ideas slow down then use computer-based tools to capture the ideas. Keep a strong link between requirements and design decisions.
Code bloat and instruction count goals. Each path through code had a goal of so many instructions.
Multiple inheritence not used much.
Integration with old upper level code because it made numerous undocumented assumptions about entry points into new code.
if you can fill this hole]
[WileRaming99] pp347-362
pp458-459 distinguishing extention, contraction, refining, abstracting, relaxing, constraining by comparing Vocabulary, Granularity and Behavior.
pp447-448: The derivation Lattice/poset to explain designs -- configuration management for specs?
General
[Oman94] [MaddenRhone84] [ Billingsetal94.html ]
if you can fill this hole]
Mentions levels of abstraction, virtual machines, SWR, functional decomposition, structured design, coupling, cohesion, structure chart, information hiding, structured programming, proofs of correctness, algebraic specification, ADTs, structured analyisi, DFDs PSL/PSA, ERM(ERD), STD. petrie nets, warnier LCS (not LCP), JSP, JSD, VDM (not Z), OOP, OOA, Modern structured analysis, no silver bullets. ?? mathematical means top-down? isomorphism between problem and solution tension in development between need for subjective designs and formal programs.... top-down vs outside in, data flow vs data structure.
[JazayeriSchauer97] pp20-39
[SCI2002] V1(Jul 2002)
| Artifact | Syntax | Semantics | Pragmatics |
|---|---|---|---|
| Use Case Diagram | bad notation | bad extends | cases too small? |
| Use Case Description | mismatch name with diagram | MIssing and ambiguous steps, invalid extension | steps too small and implementation dependent |
| Class Diagrams | not listing operations in sequence diagram or listing implicit operations | wrong multiplicity, mislocated attributes and operations, unrealizable operation | Subclasses not distinguished, showing inherited attributes |
| Sequence Diagram | missing "found" signal, return to wrong object, class not on class diagram | missing parameters, parameters used before set, missing classes | Responsibility misallocated to wrong object [Larman05] |
OO{programming, methods, infrastructure}
Increasing focus on architectures rather than just classes
Includes RDBMSs as OO.
if you can fill this hole]
systematic documentation of results and structure of arguments
The usefulness of diagrams...systematic diagrams.
[SCI2002] V1(Jul 2002)pp23-27
[Parnas93]
FMs mentioned in standards: CCS(2), CSP(2), HOL(2), LOTOS(2), OBJ(2), Temporal Logic(2), VDM(3), Z(4)
"Ten Commandments of Formal Methods" by J.P. Bowen and M.G. Hinchey is scheduled for the April (1995) issue of IEEE Computer. "Ten Commandments of Formal Methods" is available as a University of Cambridge Computer Laboratory Technical Report (no. 350). The IEEE Computer version will not differ significantly. http://www.cl.cam.ac.uk/users/mgh1001/TECHREPORTS/10cs.ps.Z (warning: even compressed it's 230K)
Notes problems:
p38: Notes resources: internet forums for Z, VDM, Larch, OBJ. FTP archives, Periodicals. Courses.
p40: Quotes BBC Interview: "If you want to build systems with ultra-high reliability whcih provide complaxe functionallity and you want to guarantee that they are going to work with very high reliability...you can't do it"
apply to get increased cofidence, to conuer complexity, to satisfy standards few tools
not enough education and training(apply math to practical problems)
| Then | Now |
|---|---|
| I. Thou shalt Choose an Appropriate Notation. | More now. Hybrids. |
| II. Thou shalt Formalize but not Overformalize. | 3 levels: specs, Proofs, machine checked. |
| III. Thou shalt Estimate Costs. | |
| IV. They shalt have a Formal Methods Guru On Call. | Plus a domain expert early on. |
| V. Thou shalt not Abandon Traditional methods. | |
| VI. Thou shalt Document Sufficiently. | Iterative. Including why & when decided. |
| VII. Thou shalt not Compromise thy QUALITY Standards. | Notation & method. |
| VIII. Thou shalt not be Dogmatic. | Gap between analysis & specification. |
| IX Thou shalt Test, Test, and Test again. | |
| X. Thou Shalt Reuse. |
reinvention of LDST
[ICSE'97]
The Law of Fallibility
The Law of Intellectual Gravity
The Law of Permannence
[McCarthyJ95a] MS Process: Jim McCarthy of Microsoft power of teams owning a set of features and controlling define+biuld+ship. 4..5 specialities: testing, writing, building. Settle own squabbles. Effect not reported.
[ ysmhist.pdf ]
if you can fill this hole]
[Harandi97] pp182-189
Multiple{languages, platforms(IBM), uses, data/tools}
ISEA Integrated SoftwareEngineering Applications tools platform OS/2 + VM + MVS, Distributed client &/| server
CodeNavigator helps programmers {undertand software, analying change requests, Diagnosis} {what, where, how}-used, flows{logic, calling,...}, annotations, source code brousing
p369 "Program analysis can create databases that may grow to many times the size of the original source library"
500KLOC -> too big for wkstn DB
Staged analysis, raw vs derived data
flexible USER interfaces
linking program data - HIPO | lexical afinity |Data model attributes
p389: "Lost in Hyperspace" - "loosing track of what they are looking at or how they got there"