[CSUSB]
>> [CNS]
>> [Comp Sci Dept]
>> [R J Botting]
>> [Monograph]
>>
01_3
3.1 Programming Language Development
Some projects started by writing a compiler or interpreter. The developers experimented, changed their minds, and failed to record what the change was. Semi-functional prototypes got loose. Incompatibilities developed between existing usage and improved versions. Different people observe what the language looks like and write their own versions. There is no record of what the language "really" is. Before long there are many incompatible versions(eg. BASIC, MS BASIC, True BASIC, GW BASIC,...Quick BASIC, Visual BASIC, ...). Apparently FORTRAN I..IV developed this way. C was saved a similar fate because two high quality, low cost, and machine independent versions became available. C++ may or may not avoid death by a thousand versions [Allman90]. Moreover, similar processes are found for non-language software:
It is possible to specify the language first. The software can be produced next. Early projects used a natural language to specify the language. COBOL's specifications had a formal syntax but informal semantics. Since ALGOL 60 a formal meta-language is used to define syntax. Algol 60's "BNF" grammar exposed problems before code was written. The informal parts had problems. Even Pete Naur's clear English was not good enough to stop Algol 60's "own" arrays from having a changeable but fixed length [Naur64]. Over-formal English contributed to the death of ALGOL 68{8}. Commentators asked for formal semantics to clarify imprecise wording in the Ada LRM (page 5, "Ada 9X Requirements Rationale"(May 91) [Ada9X]. Formal semantics would have exposed a problem in POOL(Vaandrager, pp172-236 of [Baetan90]).
LISP [McCarthyetal.62] had both its syntax and semantics formally defined from the beginning. Pure LISP is highly portable as a result. However LISP's semantics are "operational semantics." Operational semantics map a program into a specified behavior but do not expose misfeatures like LISP's FUNARG problem or dynamic scoping. Later versions of LISP fix these problems, but are not compatible with each other.
The University of Toronto project that developed Turing showed that software can be produced on time [HoltCordy88]: "Software project schedules are a private joke with me because I've drawn them for many projects but I've never seen one followed. With Turing it is different. Each piece falls into place at its prescribed time." [Holt84] The Turing project did something right but it is hard to sure what. They gave a formal specification of the syntax and defined axiomatic semantics for the language. Yet they also used "the sharpest tools" (yacc[UNIX], and S/SL [HoltCordyWortman82]). They were also a small highly motivated team who claim they didn't have any "management protocols" [Holt84]. Perhaps
Here is a similar recipe from outside of programming languages:
==============================
______________________________
==============================
Leveson points out that the development of formal theories of grammars, parser generators etc eliminates the need to invent a new parser for each new compiler [Leveson94] p70. I will later argue that there are similar theories for other problem domains with associated generic cliches/solutions/patterns.
This process has been modified for other text processing tasks(formatting and translation) - and proved highly effective [AhoUllman7273], ... , [MamrakBarnesO'Connell93].
From syntax directed programming we can harvest:
==============================
______________________________
==============================
These methods first define the data in some notation equivalent to EBNF and then use the definition as the structure of the program. I call this class of methods Data Directed Design(DDD) They help the designer to document information that determines a structure of the program that fits the specification closely. They are mandatory in some European countries [references in Chapter 9 under „LCP, „JSP, and „DDD]. These methods stress the difference between the physical data structure and the logical structure but each method handles multiple structures differently - details in chapter 6.
Data Directed Design--(DDD) has many examples (See chapter 9 for bibliography: „DDD ) but is not recognized as a general method. DDD methods are not generally accepted because
Parallelism comes from clashes - Jackson, Floyd, Knuth and others separate clashing structures into separate processes.
Non-determinism enters because DDD maps from regular expressions to program structures. Knuth noted the mapping but dismissed it because a program was thought to be deterministic in those days [Knuth74]. Jackson's backtracking technique derive the structured GOTOs that Knuth discusses from the non-deterministic regular expression of the programs structure [see appendix 2 and Jackson 75]. Later versions of SP are non-deterministic [Dijkstra76].
Efficiency is another straw man: in practice DDD usually produces code that is fast enough [JalicsHeines83]. Only in rare cases - typically NP-complete problems like the traveling-salesperson problem - does it fail to give a satisfactory solution. Instead it prompts the designer to use a cliche (typically a sort routine, data structure, or data base)[see section 3.4 next].
The next step, therefore, is to look at a processes that design suitable data structures to enable effective processing.
==============================
______________________________
==============================
In projects like this DoD project the current systems were the source of information about the environment that is fed into the above process. Re-engineering an existing data base should be easy - if there is a record kept of the data and processes in the above diagram. However, if these are not available then the processes above must be reversed so that the data structure yields a specification and the specification yields a model. The reverse engineering of data is full of surprises and can not be automated [PremerlaniBlaha94] [BrayHess95].
Research has formulated a hybrid of Data Engineering with the Syntax Directed Compilation of sections 3.1 and 3.2 above [MarkCochrane92]. The result is close to a DDD methodology. Similarly there are now Object-Oriented Data Base Management systems that combine the advantages of the objects and data bases [HursonPakzadCheng93].
Data Base theory and practice points out a way to improve the attractive Linda model and Gelernter's "Mirror Worlds" [Gelernter91]: He presumes that data is encoded like this: (birth, "Baby Doe", 12, 30, (12,01,1994)). Databases use labeled records: (Event=>birth, name=>"Baby Doe", weight=>12, mother_s_age=>30, date=>(day=>12, month=>1, year=>1994)). This is longer. But it is less error prone - a script is less likely to misread the date as the 1st of December or the mother's age as 12! This is the kind of data already in use.
We can extract the following processes and ideas from data engineering:
==============================
______________________________
==============================
The "Inference Engine" does not vary much from project to project. The data base has elementary facts and is kept up-to-date by traditional data processing methods. The "Knowledge Base" has rules that connect facts. The rules are developed iteratively with the help of one or more experts in the area being automated. In some systems(eg Prolog) the data base and the knowledge base are integrated by making the elementary facts propositions that have no presuppositions. When this kind of software drives a distributed object - then we get a "Software Agent" - in the limit, the environment includes the Internet and any private data accessible to the user.
In this kind of software engineering the engineer is focused on modeling the real word (Data+Knowledge) not coding the inference engine or helping the user directly [Keller87] [PayneMcArthur90] [Deville90]. Notice that
==============================
______________________________
==============================
Dynamic Analysis and Design(DAD) has many published examples (See chapter 9 for bibliography under „DAD ) but are not recognized as general methods. DAD complements Structured Analysis and Design[„SSADM], Entity-Relationship-Attribute models(ERA) [Botting86a], DFDs [Hulletal91], and expert systems (Section 3.5 above). Jackson notes that JSD is best used for problems where there is an environment to be monitored and reported on [Jackson94]. Policies and business rules may be better expressed using a rule-based design [Poo91]. All DADs document the patterns of change in the software's environment before planning the software.
First Wave Methods
Early methods started with an informal strategy to solve the problem and used this as the source of objects
etc.
[Abbott83]
[Booch83]
[Booch86] etc, hence BOOD, compare Chapter 3 of
,See [Goldstein & Alger 92 ]. Thus, instead of
refining of steps in algorithms the early methods refine the objects in an algorithm. Experience teaching this
method lead to the following conclusion:
The Booch method has been improved since this time [AppelbeAbowd95]. Song & Osterweil note that a reality directed method like JSD provides actions that help get this "BOOD" started [SongOsterweil94].
Meanwhile others extended Structured Design(SD) methods to incorporate objects [Coad88] [ [Bailin 89, ...] , [McGregorKorson90] [ShlaerMellor92] [AndleighGretzinger92]. Instead of coupling and cohesion the idea of inter-object dependency has been defined and can be measured automatically [WildeHuitt92]. Peter Coad calls this "conascence" [CoadP92]. Simple dynamic objects or finite state systems are the heart of the latest version of "Cleanroom Software Engineering" [Hevneretal92] and other object-based methodologies [ShlaerMellor92] [Fayadetal93] [Lang93] [BalawskiIndurkhya94]. These typically use state transition diagrams or Harel State Charts to document dynamics. These don't take advantage of the insight that objects are easier to design if conceptually parallel structures are designed as concurrent processes[„JSP, Robinson 79, ELH's in „SSADM, „JSD, Smith CU & Williams LG 93, Embley et al 94 p27]. Other "objectivists" [GoldsteinAlger92] incorporate parts of Data Engineering(see section 3.5 above) - such as some form of entity-relationship conceptual model [Embleyetal94]. Inheritance, generics and other object-oriented techniques tend to appear late in these methods.
Second Wave Methods
Others methodologists recommend using scenarios
[Gladden82] or use cases
[Jacobson] that are analyzed into
the services needed to fulfill them. Depending on the methodologist, scenario may be (1) a DFD like picture
showing a number of objects collaborating to fulfill a responsibility, (2) a script listing user actions, (3) a time-line
diagram showing messages being passed between object
[Jacobsen]
[GoldsteinAlger92], (4) a tree
[Hsiaetal94],
(5) a grammar
[Hsiaetal94] or even (6)a video film
[Gladden82]. A narrative scenario or script is a natural
language paragraph, conversation, or piece of text that states the services that are required by a user Object Behavior
Analysis (OBA)
[RubinGoldberg92]. Scripts are like the Logical Function Descriptions and `Logical Data
Access Paths` used in the SSADM[See sources for „SSADM in Chapter 9, also cf Lustman 94]. Even without
objects, scenarios have proved an effective way of provoking discussion and development of requirements
[PottsTakahashiAnton94] and have been an informal but vital part of design documentation for many years
[Carroll94]. Propagation patterns serve a similar purpose
[LieberherrXiao9394]. In this book I will often write one
or more narrative scenarios underneath a DFD to help explain some the possible ways it could be scheduled.
The services that appear in the scenarios or requirements are classified into responsibilities. A responsibility is a piece of intelligence that will be encapsulated in an object. An object's "intelligence" is (1) the knowledge it maintains and (2) the actions it can perform [Wirfs-BrockWilkersonWiener90] p61. An object has responsibilities to provide services to its clients, by using its servers. Together the clients and servers are known as collaborators. A collaboration in some methods is developed into a mutually beneficial and constraining contract between client and server [Wirfs-BrockWilkersonWiener90] [Meyer92]. Responsibilities and collaborations are often allocated to CRC(Class-Responsibility-Collaboration) cards that describe possible classes (Samples in figure 2, page 65 of [McGregorKorson94]. These are modified until a stable structure emerges [Wirfs-BrockWilkersonWiener90] [Jacobsonetal92] [GoldsteinAlger92] [McGregorKorson94], and so on.
Architectural Patterns?
Slowly it has been admitted that a higher level of structure than that of classes and objects is needed as the unit of
reuse. These tend to be families of collaborating classes (specific or generic). Some call these "object-oriented
frameworks"[Talligent]. Others call them "design patterns"
[Coad92]
„PATTERNS in bibliographies. Gamma's
work has lead to a significant paradigm shift
[Gammaetal94]. Most of the patterns improve reuse by using more
code. Like the functional methodologists, the Pattern Community have turned to architects(Christopher Alexander, in
this case) to guide their thinking and so are developing "A Pattern Language" for objects
[Booch94]. There is a
therefore a new research field in software architecture[see „ARCHITECTURE in the bibliography] that hopes to
improve productivity by aiding the reuse of all the materials prepared in a software process. Meanwhile, quietly,
with and without objects, computer aided code reuse is starting(1993-95) to pay off for some early adopters
[Adhikari95b].
Comparisons
Several comparisons of the leading traditional and object oriented ideas and methods have been published
[Bucken93]
[FichmanKemerer92]
[MonarchiPuhr92]. Song and Osterweil include non-traditional JSD in their comparisons
[SongOsterweil9294]. Smith & Williams compare a functional design, a DAD design [Sanden89b], and their own object-oriented design(based on ERDs, DFDs, STDs, and performance engineering) - they conclude that: (1) All three designs are free of performance problems, (2) the DAD approach gives results like Smith and Williams's Domain Analysis, and (3) Smith & Williams's design has more generic components [SmithCUWilliamsLG93]. Another experiment showed that a simpler design, as measured by a half-a-dozen metrics, was produced by using responsibilities rather than using DFDs and ERDs to guide design [SharbleCohen93]. None of seven leading methods provide full support for all the ideas used to describe objects [Bucken93]. The methods have introduced contradictory and unintuitive notations (introduction to chapter 6 of [GoldsteinAlger92)] [Embleyetal95] p20, examples: [Nerson92] and [Coad92]. The notions represented are not clearly defined or standardized [BalawskiIndurkhya94] Apparently most object oriented methods rely on intuition and back-tracking to design large systems of objects [MonarchiPuhr92]pp40-41. According to Dedene & Snoek none of eight methods they report on check for deadlocks or other problematic behaviors [DedeneSnoek94].
The proponents of object-oriented methods are aware of the contradiction between the view of a problem given by structured methods and the views as seen by objects [FichmanKemerer92] [Kramer93]. Some see object-based methods as an alternative to earlier methods [Henderson-SellersEdwards90](p145) and some reject all parts of older methods [Berard89] + Bowles comments on p42 of [Kramer93]. Practitioners with long memories notice that Object Oriented Methods were in use before the invention of "Structured Programming".
"Remarkably enough, the abstract data type has reappeared 25 years after its invention under the heading 'object oriented'." [Wirth95] p66.
[FichmanKemerer92], Figure 2 page 52 of [DedeneSnoek94]. Perhaps, the clashing views(Objects vs Flows) need to be documented separately and connected by some linking mechanism. Gary Simmons & John Thomson have extended Smalltalk so that the objects encapsulate their own documentation of the problem domain and the user's needs for example [Rettig93].
Object-oriented methods and tools are still(1995) evolving p38 of [FichmanKemerer92] [Kramer93] and even breeding (see the unification of Booch, Rumbaugh, Jacobson et al in 1994-1996, and HP's FUSION method]. Intuition, experience, and/or backtracking are needed in current versions. Catalogs of standard patterns are being developed [Gammaetal94] [Nerson9??]. Finally there seems to be several concepts used in object-oriented thinking that have no agreed meaning - leading to practical confusions and philosophical debates [BaclawskiIndurkhya94]. One point is clear - all recent object-oriented methods start by modeling ideas surrounding the software and this model is mapped into the program design:
==============================
______________________________
==============================
According to Goldstein & Alger this approach works best when
==============================
______________________________
==============================
Note 1:
This idea for this process dates back to Descartes [Grabiner95]. The more precisely the formulae and rules are stated and applied, the more rigorous the process becomes. However this may not increase the odds that the model fits reality! Rigor (in this sense) reduces the chance of errors in solving or simulating the model. This reduces the error proneness of the whole process however. It can be combined with other techniques that reduce the chances of unreal models of the problem or situation.
Imre Lakatos's little book "Proofs and Refutations" makes it clear that rigorous formal models of a problem area do not come first. His case study of the development of ideas and models concerned with a single formula about polyhedra over a 100 year period indicates that proposing a mathematical model is an invitation to search for counter examples as well as proofs. Further each counter-example can be used (along with a proof) to further improve the model. Ultimately one gets a more certain statement that is expressed in more rarefied terms. I believe that useful formal models will also follow much creative and critical thinking. Once formulated they can be taught.
Several well known techniques are all applied mathematics: BNF(section 3.3 above) was formal. Codd's n-tuples(section 3.4 above) are from set theory. Logic (section 3.5), regular expressions(section 3.6), and finite state machines(section 3.7) are all formal models. Modern mathematics has many non-numerical systems ready to be used [Mills75] [WoodcockLoomes88] [Ince88a] [Spivey89] [Millsetall89], . . ..
It is difficult for a non-mathematician to find ready-made, useful mathematical systems. However the formal systems needed are simple: Symbolic logic and "discrete mathematics" are taught to Computer Scientists and others interested in programming [MannaWaldinger85] [Millsetall89] [Denningetal.89a], . . . [Zelkowitz90] [Gries91] [Fekete93a]. Set theory is even appearing in books on Analysis and Design [Yourdon93]. The SSADM Logical Data Structure (LDS) is a picture of a collection of sets and mappings[„SSADM]. It can be used to model paradigmatic problems such as the "lift" problem [Botting85b]. Automata theory has been proposed as a way improve Structured Analysis and Design for transaction based systems [Lustman94] and scenario analysis [Hsiaetal94]. Ideas from formal linguistics turn up in $DDD, $DAD, and OOD(see previous sections). Even Lotfi Zadeh's fuzzy logic is itself formal, not fuzzy [Zadeh94] [MunakataJani94]. Wand and Weber have proposed the mathematical modeling of information systems{10} [WandWeber90]. Some call data-directed and structured methods "semi-formal" [Wing90a] [Fraseretal94](Table 2 p79). MERODE integrates regular expressions, data engineering and objects into a formal method [DedeneSnoek94]. There is clear evidence that only sophomore level mathematics and logic is needed [Jordahl91b] p100 [Saiedian93] [Hayes93]. Computer science is developing formulae to model systems, requirements, specifications and programs better [Hoare93] [GriesScheidner93] [Hehner93] [Parnas93].
Using formulae plus text and diagrams leads to some important advantages:
Formal methods have been used in practice for nearly 30 years: In the 1960's IBM used VDM/VDL to define Algol 60 and PL/I. In the 80's IBM used Z to re-engineer CICS(part IV of [Hayes93]). UNITY has been used to formulate the I/O subsystem of the GCOS operating system [Staskauskas93]. Combining DFDs+Data Dictionaries+VDM is effective [Fraseretal91]. Another effective mix is DFDs+Data Dictionaries+Prolog [Keller87]. A frame-based logic(FRORL) has been shown to be sound and complete way to formalize object-oriented ideas [TsaiWiegertJang92].
Indeed some formal methods have undergone the precise process that Robert Glass promotes: "A researcher working alongside a practitioner, being open to adjusting and improving ideas" [Glass94b] p46. As part of a joint university (Oxford University) and industry (IBM Hursley) project sponsored and rewarded by a government. Anthony Hall and later Bowen and Hinchey listed the following facts gathered from such joint projects:
Another survey [GerhartCraigenRalston94] suggests that formal models can be used successfully in Domain Analysis and in Re-engineering to provide better assurance, better communication, and evidence of best practice. The methods also support reuse[chapters 4 and 5 of Schafer 94].
Later experiences on real projects (successful and unsuccessful) shows that formal methods are best used along with traditional methods (including quality control, testing, estimation, documentation, reuse,human-computer interface design, ...) [BowenHinchey95a] and [BowenHinchey95b] but compare with [Kemmerer90]. SAZ is the result of combining SSADM(see later and chapter 9) with Z for example. Successful projects have little dogmatism, have access to expertise, and avoid over-formalization [BowenHinchey95], but compare with [Zelkowitz95].
One question that must be answered is why it might be worth moving from concrete models to abstract ones. Concrete models are either computer oriented ( like "programs", "logical data structures" or "object hierarchies") or natural language "surface structure". It might be thought that the use of abstract models is an academic affectation. However, many methodologies that have been and are used in practice explicitly ask their users to abstract the essence of a situation from any accidental details. Data engineering, SSADM, SADT, OMT,... and so on all stress the importance of moving away from current implementation and thinking before looking for new solutions.
Recent papers take abstraction this further and suspend the traditional distinction between program and data. One proves that this lead to a significant reduction in complexity and the cost of maintenance [LongDenning95]. In another case a complex and evolving game was implemented this way [Sanders95]. Evidence for the value of abstraction as a cost saving device will be given in most of the later chapters in this monograph.
Formal models have not yet affected most programmers - one study turned up only one programmer that used them [Lammers86]. Indeed when a formal model is developed for existing software it raises questions that can only be answered by testing the software - the answers have never been documented(pp 191 & 218 of [Hayes93].
It is time consuming to prepare mathematical documents (See introductions to [MannaWaldinger85] [WoodcockLoomes88] [Ince88a] [Spivey89]. Also papers: [Rous90] [RushbyHenke91] [FieldsElvang-Goranson92]. The notations need to be chosen with care] [BowenHinchey95a] [CreveuilRoman94]. Formalists who try to apply their ideas in practice usually are forced to develop graphical and/or tabular formats[See „GRAPHIC and „TABLE in Bibliography in Chapter 9]. This book describes a way to make such mathematics less expensive, more accessible, "look and feel" more like programming, and graphical/tabular for clients.
These are therefore reality directed methods. Formal models, EBNF, Data Directed Design, Dynamic Analysis and Design, Expert Systems/Knowledge Engineering, Data Engineering/Information Engineering, and the later Object-Oriented methods all force the practitioner to think about the problem domain in ways that are close to the user and client. For example Berzins et al show a context DFD of a user checking the spelling of a document(Fig 6) and instantly interpret it as a software design: the user interface is in one module and the spell checking logic is in the other module [BerzinsLuqiYehudai93] p446. Many think this desirable [Paulson89] [Lawson90] [Sharon91] [Tayntor90] [Nielsen92] [Aranow92] [Bachman92] [SlaterCarness92] [Zave93] [Rettig93](p23). Alan Davis notes that this is what Dijkstra calls "minimizing the Intellectual Distance" [DavisA94c].
Importantly, a focus on the real world that contains the problem answers the key problem: That it is unlikely that a single method will fit all problem domains [Jackson94] [GalssVessey95]. The above picture shows that one always has to look at the domain and then can choose suitable design methods. Any of the specialized reality directed methods could be used. Indeed there is nothing to stop the designer from recognizing a simple top down cliche and using it.
Focussing on reality generates systems where
==============================
______________________________
==============================
A change in the system and/or the user leads to a change in the model. The design process uses the model to solve new problems or simplify the system by using available technology giving an updated specification. Implementation refines the specification changes into changes in the system. A good software engineer can restart and/or redo any of the processes as demanded by the situation. The parts of the DFD can be distributed to different people/teams, but then effort is needed to avoid deadlock and/or inconsistencies between the model, specification, or system(configuration management, documentation, SCCS/RCS,... [Haque95]). As in all DFDs in this section, the parts can all be active and all can encapsulate some intelligence(artificial or real).
Scenario 2. Incremental development means that the DFD can have several threads of execution running at one time as long as the system, model, and specification are modularized so that changes made by one thread do not disrupt the rest.
Scenario 3. "The MS Process" When developing a mass marketed product then a set of partial models, designs and systems- each set forming a single release, are rapidly developed to get fast feedback from a sample of users (often the developers themselves). Features are added and subtracted from the model, design, and implementation within a day. Bugs are acceptable in new features. Slowly, as the product evolves, the pool of users expands: The developers, the beta testers, the early adopters, the mass market, the die-hards,... [Bond95] [Keuffel95b] [Sanders95a].
Scenario 4. The system has been running for 10 years. Every now and then the user requests a change. The request is analyzed and compared to the model. If the request leads to a structural change then parts of the model may be modified, normally however the request fits the model's structure and is rapidly mapped (by restarting the design process) into a change in a part of the specification, which in turn triggers the implementation of the change in the System itself. Notice that this proceeds rapidly because the "overhead" of documenting a model and specifications guide the process.
Scenario 5. The MIS department in a large corporation that manufacturers widgets is asked to produce software to help the acceptance of orders from customers, the preparation of invoices, picking lists, deliveries, and the extraction of payments using a new client/server LAN system. The initial analysis ("feasibility study") constructs a model that has many unknowns in it - the user interface and the platform are not clearly defined. This triggers of the need for risk management: The model documents the risks and the development team proposes three strategies to handle the risks. (1) Part of the model will include a running "mock up" of the user interface and the client managers and users will review and help develop it. (2) The clients will spend some time with the development team brainstorming scenarios of how the system will be used. (3) The logic of the business will be in the model and the design of this part of system will be specified in an platform independent (abstract) form that the client can understand and review vs the scenarios. Thus analysis and design will proceed in parallel, but the implementation can be delayed until the platform is chosen - this may even be outsourced.
Scenario 6. I was working with a friend and colleague who did DP consulting. He was working with a small manufacturer of floor coverings. Their needs were simple: the sales clerk would be taking in orders, and printing them out,etc. while in a different room the CEO kept an eye on inventories and the like. The model was simple and design obvious since there was a standard order/billing/inventory program available for reuse Implementing the simple program to let the CEO get his data was a matter of hours. However, this was in the 1970's when timesharing was a new technology. It took three weeks to get past computer company's management and sales-force to the engineer who could give us the right version of the operating system. The computer company has since been absorbed by other companies.
Scenario 7. The customer hot line gets 200 calls asking how to change the "hour glass" cursor to some other form in your new GUI based OS. Analysis shows that the model has no mention of the cursor at all - it appears that it was never discussed in the focus groups and never appeared in the prototype screens. The model is changed. In this organization Design is ad hoc and out of control. The specifications mentions a "the WFSTH cursor" - this apparently means "Waiting For Something To Happen" . Tracing this into the implementation takes time but it appears as a hard coded void function called "FunHG()". The implementation is changed, and crashes the system... because one part of the OS does not uses the function.... Ultimately the system is debugged and released but nobody bothers to update the specifications.
Scenario 7 shows some problems with this DFD! It will be revised after detailed study of (yet) more methodologies.
The wise engineer usually constructed a model of the problem separately from a specification of the solution. The model is about "what is" and so includes "Requirements" because these are a part of the client's world [LindlandSundreSolvberg94]. By calling it a model we can distinguish it from specifications and designs [ayadetal94] [Embleyetal95]. As a model of the problem (and its domain) is clearly more than a set of abstract functions [Siddiqi94] or an initial design of a solution. Will Tracz calls this the problem space and distinguishes it from the solution space] [Tracz95]. Solution: Design and Implementation are technology driven rather than problem or domain driven] [Feijs93] [RomanWilcox94], ....
Some believe that the application of non-sequential construction methods and the idea of reflecting the "real world" will lead to a way to use computers that will completely change the way software is developed. Michael Jackson's methods (JSP, JSD) have always included implicit or explicit concurrency and lately he has made this even clearer: "My conclusion is that we should work towards the kinds of implementation infrastructure that would support multiple, superimposed, architectures" [Jackson95a]. Gelernter's vision of "Mirror Worlds" is a popular account of what becomes possible with concurrent systems [Gelernter91].
My next step is to apply the above model to software engineering itself. The IEEE has a task force developing a new discipline and a common conceptual model for computer-based systems engineering [JacksonKLavi93].
In section 4.1 (next) [ 01_4.html ] I search for models for a "Software Life Cycle". Then I look for the data that is used in modeling software(section 4.2). This leads to a detailed DFD of the processes and data in an idealized software engineering system(section 4.3 ... ). This lets us (1) revise the figure above, so (2)propose improvements to software engineering. At a future time the revised system, should be itself re-applied - bootstrap fashion - to current practice, and so on...