[CSUSB]>> [CNS]>> [CSE]>> [R J Botting]>> bib
|| [News] || [Research]

Bibliography Retrieval Engine(Beta)

Items in bibliography identified by a string matching Jackson.*9

AbowdDix93
.Open AbowdDix93
 Gregory D Abowd & Alan J Dix
 Integrating status and event phenomena in formal specifictions of interactive systems
 SIGSOFT'94 Proc 2nd ACM SIGSOFT Symp on Foundations of Software Engineering & ACM SIGSOFT Software Engineering Notes V19n5(Dec 1994)pp44-52. See 
.See [ZaveJackson94]
 =MATHEMATICAL HCI/USER SPECIFICATION
.Box
Signature+Events+formulae+ interstitial behavior.

Nothing that Ross Ashby and JSD didn't know about already

looks a little like hypertalk, but notation not of the essence.
.Close.Box
.Close

Borgidaetal95
.Open Borgidaetal95
 Alex Borgida & John Mylopoulos & Raymond Reiter
 The frame problem in procedure specifications
 IEEE Trans on Software Eng VSE-SE-21n10(Oct 1995)pp785-798
 =CRITIQUE LOGIC Set Theory SPECIFICATION METHODS circumscription
.See [BorgidaMylopoulosReiter93]
.Find JacksonD9
.See [McCarthy87]
.See [Delgrande98]
.Close

BorgidaMylopoulosReiter93
.Open BorgidaMylopoulosReiter93
 A Borgida & J Mylopoulos & R Reiter
 "And Nothing Else Changes":The frame problem in procedure specifications
 In Proc of the 15th Int Conf on Software Engineering
 IEEE Computer Society(May 1993)pp303-314
 Ref from ZaveJackson93
.See [Borgidaetal95]
.See [BicarreguiRitchie95]
.Close

DamonJacksonJha96
.Open DamonJacksonJha96
 Craig A Damon & Daniel Jackson & Somesh Jha
 Checking Relational Specifications With Binary Descision Diagrams
 Proc 4th ACM SIGSOFT 96 Symp on the Foundns of Software Eng: ACM SIGSEN V21n6(Nov 1996)pp70-80
 =DEMO MODEL CHECKING BDDs
 Z-like specs checked via testrolog-type diagrams
 BDDs::=Binary Decision Diagrams
.Close

DeLineZelesnikShaw97
.Open DeLineZelesnikShaw97
 Robert DeLine & Gregory Zelesnik & Mary Shaw
 Lessons on Converting Batch Systems to Support Interactions
.See [ICSE'97]
 =Experience architecture evolution
 8 rules on page 203
 no ref to Jackson's work in 1975.
.Close

Erdogmus10
.Open Erdogmus10
 Hakan Erdogmas
 Can all sequential processed grow up to be iterative and incremental
 IEEE Software Magazine V27n4(Jul/Aug 2010)pp2-5
 =ESSAY NONSEQUENTIAL PROCESSES Kanban scrumban LEAN stage-gate v-model
 Refers to 
.See [Beck99]
Break process down into parts and apply sequence to parts many times. 
 Refers to 
.See [Ladas08] 
(Scrumban).
 Divisibility of work.  Unravelling principles:  ( pipelining, workflow-schedule independence). 
 Split up, make parallel, add buffers, and add integration steps. 
 Compare with "Pipe and Filter" architecture and Jackson's methods in the 1970s and 1980s.
.Close

GlassVessey95
.Open GlassVessey95
 Robert L Glass & Iris Vessey
 Contemporary application Domain Taxonomies
 IEEE Software Magazine V12n4(July 1995)pp63-76
.See [VesseyGlass98]
.Box
 Suggests we don't need theories for all possible problems (which will be weak) but strong ones for for particular domains.
 Argues for application tasonomies,
as distinct from solution taxonomies.
 Survey and critique of several taxonomies.
notes confusions.
 Provides a meta taxonomy.
 States it is going to take a lot of work.
 Ref to 
.See [Jackson95]
.Close.Box
.Close

GunterGunterJacksonZave00
.Open GunterGunterJacksonZave00
 Carl A Gunter & Elsa L Gunter & Michael A Jackson & Pamela Zave
 A Reference Model for Requirements and Specifications
 IEEE Software Magazine V17n3(May/Jun 2000)pp37-43
 =THEORY REQUIREMENTS SPECIFICATION REALITY WRSPM
 W, R, S refer to the environment. S, P, M refer to the system.
 Actual expression of descriptions can take many forms.
 Designated terms -- typically designate states, events, and/or individuals.
`e` -- controled by environment, `s` -- controled by system.
 Shared terminology.
 Three properties of adequacy and consistency define a contract between the
buyer and seller of the software.
 Similar, relative, properties constrain the specification and imply the
three fundamental properties.

.See http://www/dick/notes/GunterGunterJacksonZave00.html
 See also 
.See [ZaveJackson97b]
.Close

HaleyLaneyMoffettNuseibeh08
.Open HaleyLaneyMoffettNuseibeh08
 Charles B Haley & Robert Laney & Jonathon Moffett & Bashar Nuseibeh 
 Security Requirements engineering: A Framework for Representation and Analysis
 IEEE Trans Software Engineering  V34n1(Jan/Feb 2008)pp133-153
 =CASESTUDY SECURITY REQUIREMENTS METHOD  
 Describes a complex process and set of languages that work from security goals, to assets that are to be protected
(compare
.See [Stoneburner06]
), to requirements, thence to arguments for a particular system design satisfying the requirements, and so to the assumptions that can be rebutted, and the mitigation of the rebuttals and so forth.
 Security requirements are non-functional requirements and are closely related to the context of the machine being designed.
 Must expose assumptions about the machine and its context.
 Arguments that the system satisfies the requirements lead to lists of assumptions that can be challenged (WHY?) and rebutted.
 Rebuttals lead to mitigators that change the context and/or the requirments.
In turn the mitigators can be rebutted, and so on.
 Hence an iterative process making the design more secure.
 Uses Jackson Problem Frames
(
.See [Jackson95c]
.See [Jackson01]
), simplified
.See [Toulmin79]
arguments, Propositional logic, and a causal logic based on
 `Event1` shall cause `Event2`.
 Outer_argument::=`Formal logic showing the design satisfies the requirement and exposing assumptions`
 Inner_argument::=`Explores assumptions in terms of rebuttals and mitigators`.
 Process involves engineers and stakeholders in intense and fruitful discussion.
 (dick)|- Compare
.See [Lakatos76]
model of the mathematical process.  Also methods used to achieve safety.
.Close

ICSE'97
.Open ICSE'97
 ACM & IEEE CS
 Proceedings of the 1997 International Conference on Software Engineering
 May 17..23 Boston MA USA
 ISBN 0-89791-914-9 ACM Order #592970 IEEE CS Order #0270-5257 also bound and on microfiche
 =PROCEEDINGS ICSE
.Box
Selected papers;

.See [Baker97]

.See [BaresiOrsoPezze97]

.See [Botting97a]

.See [BriandDevanbuMelo97]

.See [Cohenetal97]

.See [DeLineZelesnikShaw97]

.See [FaulkHietmeyer97]

.See [FriesenJahnichenWeber97]

.See [HeitmeyerKirbyLabaw97]

.See [Kiczalesetal97]

.See [LindigSnelting97]

.See [NuseibehRobertson97]

.See [OCallahanJackson97]

.See [PodorozhnyOsterweil97]

.See [PorterSiyVotta97]

.See [ReeseLeveson97]

.See [Sullivan97]

.See [SullivanSocha]
Marchukov97

.See [VernerCerpa97]

.See [Wile97]

.See [WilsonRosenberg]
Hyatt97

.Close.Box
.Close

Jackson91
.Open Jackson91
 Michael A Jackson (101 Hamilton Terrace London NW8 9QX UK)
 Description is our Business
 pp1-8 in VDM Europe 91 (1991)
 =ESSAY Reality
.Box
  "effort devoted to describing a domain pays off by producing at least a 
partial description of the machine as a by-product" "Let us, sometimes at 
least, look outward.  The point at which formalisms meet informal realities
seems to be like the junction of two dissimilar metals: there is a 
difference of temperature, and an electromotive force is generated.  I 
think this force could be a source of real intelectual energy"

.Close.Box
.Close

Jackson94
.Open Jackson94
 Michael A Jackson
 Problems & Methods and Specializations
 IEEE Software Magazine V11n6(Nov 1994)pp57-62(advert  p93)
 See IEEE Software Engineering Journal 1994
 =ESSAY PROBLEMS vs SOLUTIONS Engineering JSD Refs to Polya Parnas ADTs
.Box
Note. original cited in GlassVessey95, overlaps Jackson95c
p57: "Software engineering is hard", "lack of proffessionalism",
  "There are no casual builders of cars or bridges", "Many theorists and practitioners, even the most proffessional are naive."
p58: "The prerequisites for a more mathematical approach are not yet in place...an automotive engineer [...]a repetoire of standard designs[...]the design space is very narrow."
"Understanding the problem and structuring the solution is the primary need"[...]"general computational paradigms[DFDs, objects,...] gives a design space that is too wide for comfort."

architectural styles, types of problem.  focussing on the problem and not the technique.
refers to Polya...
Problems in context, understand problem::=mapped into set of frames, solutions within and to frames, recombined solutions.

Need for specialisms within engineering.

Three frames:
 JSD, Workpiece->ADT, Controlled environment
  JSD::=Net{Real_World, Information_outputs, Requests, System, Function}
  Workpiece::=Net{Workpieces, Operation requests, Operations, machine}
  Environmane-Effect::=Net{Environment, Connection, Machine, Requirement}

->>Engineering disciplines should  not focus on a material so much as a network of connected sets of problems and solutions: Personal transport<net>automobiles.  MassTransit<net>railway engines.

See also session at ICSE95
.Close.Box
.Close

Jackson95a
.Open Jackson95a
 Michael Jackson(MAJ Consulting Ltd.  London) <jackson@acm.org>
 Multi-view Implementations(abstract of position paper at the Dagstuhl Workshop on Software Architecture)
 ACM SIGSOFT Software Engineering Notes V20n3(Jul 1995)pp70
 =ABSTRACT PROBLEMFRAMES
.Box
Note, see 
.See [Jackson95c]
"The problems we  tackle are multi-faceted, and must be decompsoed into may
parallel subproblems, parallel architectures, parallel views, parallel 
patterns.  These parallel abstarctions are pinned together by common 
phenomena, of which each abstraction requires a different description.

Quite separately, it has been observed that architecture, and patterns, 
should explicitly be preserved in the implementation.

My conclusion is that we should work towards the kinds of implementation 
infrastructure that would support multiple, superimposed, architectures, 
and multiple, superimposed, typing of elementary phenomen that pin these 
architectures together"

Answer to questions: No notation for info not in "the diagram",  "There is
no calculus.  Different and parallel abstractions of the problem exist and
in each of these abstractions you are concerned with some subset".  "There
is no need to put the problem frame back together in any sense at all.  
That is, problem frames are not hierrchical.  Furthermore, the 
decomposition into a hierarchy of procedures is a very poor way to about 
solving a problem."  "Decomposition into subproblems that are not solvable
is pointless".  "You are making the assumption that you make a chunk of 
software for each of the boxes, but it is not like that.  Implementation as
a hierarchy of procedures in *not* the right way.  Procedures can't be 
combined with conjunctions."
.Close.Box
.Close

Jackson95b
.Open Jackson95b
 Michael Jackson(MAJ Consulting Ltd.  London) <jackson@acm.org>
 Problem Frames
 Proc of the 1st Int Workshop on Software architecture CMU-CS-TR-95-151<reports@cs.cmu.edu>
 =ADVERT PROBLEMFRAMES
 See
.See [Jackson95c]
.Close

Jackson95c
.Open Jackson95c
 Michael Jackson(MAJ Consulting Ltd.  London) <jackson@acm.org>
 Requirements & Specifications: a Lexicon of Software Practice Principles and Prejudice
 Addison-Wesley Redwood City CA 1995 ISBN 0-201-87712-0 CR9607-0459 D.2.1
 Excerpt IEEE Software Magazine V12n6(Nov 1995)pp103-104 and
.See [Jackson94]
.Box
 No one method.
 Context diagrams/problem frames reality driven.
 Predicates for precision, composition by "and".
 Designations, definitions, assumptions.
 Moods: indicative(NAT) vs optative(REQ).
 Shared phenomena connect domains.
 Individuals.
 Danger of vagueness (especially at top level)
 Describes some risks+limits of: JSP, Z, DFDs, ERDs, top-down, hierarchies, solutions not problems.
 Ref to Phillip Kraft: "Deskilling".
 Examples: Dekker, elevators, kohnigsberg, packages, ...
 Aboricide
 Importance of critical reading
 Sent  EMail July 23rd 1996
.Close.Box
.Close

Jackson98
.Open Jackson98
 Michael Jackson<jackson@acm.org>
 Will There ever be Software Engineering?
 IEEE Software Magazine V15n1(Jan/Feb 1998)pp36-39
 =ESSAY ECONOMICS ENGINEERING
.Box
 rush to market + dollars for upgrades leave little reason for engineering
 entrenched interest of practitioners in what they are doing
 complexity: writing a macro vs no do-it-yourself kit for building suspension bridges
 variety of products+projects: bridge engineers don't design ships
 professors of unsolved problems?
 specialization by product and requirement
 we will get the software we deserve.
.Close.Box
.Close

Jackson98a
.Open Jackson98a
 Michael Jackson<jackson@acm.org>
 Defining a Discipline of Description
 =ESSAY
 IEEE Software Magazine V18n5(Sep/Oct 1998)pp14-18
.Box
 Formal computers in an informal world.
 It is hard to make sense of a specification of an interface if their is no information about what is inside at least one side of the interface.
 Designations vs Definitions, may have to bypass some "real" terms because too unclear
 Must analyse the effects of designation errors: where the formal system can come adrift from reality.
 Dangers of badly structured descriptions, for example confusing things that are true because of the system with things that are true without the new system.
.Close.Box
.Close

Jackson99
.Open Jackson99
 Michael A Jackson
  Specializing in Software Engineering
 IEEE Software Magazine V16n6(Nov/Dec 1999)pp120-121+119
 =ESSAY ENGINEERING
 SPECIALITIES are good
 1.more knowledge accumulates, 2 sound theories in standard practice, 3 know what is possible, 4 stronger sense of professional responsibilities
 better learning from failures
 necessary but not sufficient
 one size does not fit all
.Close

JacksonD95a
.Open JacksonD95a
 Daniel Jackson(CMU)
 Aspect: Detecting Bugs with abstract Dependencies
 ACM TOSEM V4n2(Apr 1995)pp109-145
 assert dependencies middel ground between type checking and program proving. Good for ommitted statements
.Close

JacksonD95b
.Open JacksonD95b
 Daniel Jackson <mailto:dnj@cs.cmu.edu><http://www.cs.cmu.edu/~dnj/>
 Structuring Z specifications with Views
 ACM TOSEM V4n4(Oct 1995)pp365-389
 CR99611-0903
.Box
Frame conditions decomposition specifications
 interlocking partial specifications(partial state+some ops) with shared
ops+operations of whole are combinations of partial ops, conflicts with Z
refinement  model, needs (guard and if disclaimer then postcondition)
synchronized ops plus intersecting invariants on states, one view ND other
makes deterministic, good views are simple with complex connections, needs
implicit spec and preconditions+ explicit framing and uniform types like Z,
needs guards+ indexing+semantic actions not in Z,

Not whole+part decomposition, no master representation, no need to reconcile multplie viewpoints/perspectives
.See [ZaveJackson94]
.Close.Box
.Close

JacksonD98
.Open JacksonD98
 Daniel Jackson
 An Intermediate Design Language and its Analysis
 ACM SIGSOFT Software Engineering Notes V23n6(Nov 1998)pp121-130 & Proc 6th Int Symp on the Foundations of Software Engineering(Nov 1998)
 =DEMO NP/Nitpick Language/Tool of RELATIONS
 related to more complex Z.
 model sets as relations with a singleton range Unit:={unit}. compar 
.See [Maddux99]
 analysis by building model semantics
.Close

JacksonD09
.Open JacksonD09
 Daniel Jackson
 A Direct Path to Dependable Software
 Commun ACM V52n4(Apr 2009)pp78-88
.See http://doi.acm.org/10.1145/1498765.1498787
.See http://sdg.csail.mit.edu/publications.html
 =ESSAY RISKS COSTS not PROCESSES CRITICAL PROPERTIES CLAIMS QUALITIES REQUIREMENTS
 Based on a study done for NRC lead to 
.Key Dependability Cases.
 Lots of examples of RISKS and how they occurred and how the effect reasoning about the dependability od a system.
 A dependability case provides evidence, in the form of claims, that certain critical properties will hold.
 The analysis of the critical properties and the claims that support them starts on day one of a project,
and guides architectural decisions.
Well chosen architecture -- modular, decoupled, simple -- 
makes it cheaper to establish a dependability case.
 Dependability cases should develop "hand-in-hand" with the product.
The developers chose techniques and technology to support the claims.
 Critical properties should be close to the user/client/real world.
 All claims depend on assumptions about the client's world: an air traffic control system can not stop a pilot
deliberately crashing into another aeroplane.
 Claims connect the developing system, via assumptions, to the critical properties.
 A dependability case must be auditable, complete, and sound.
 A rigorous process can help establish a dependability case -- but need not be burdensome.
 A risk-averse and meticulous culture will help.
 Need robust platforms and tools -- language design.
 The correctness of code is not the weakest link in the chain -- only 3% of the time...
 Testing and analysis contribute as well.
 Credible tools -- example of a broken proof: binary search when bounds > largest integer!
 See also
.See [JacksonD06]
.See [Jackson01]
.See [Jackson04]
(Outer vs inner requirements)
.Close

JacksonDDamon96
.Open JacksonDDamon96
 Daniel Jackson (mailto:daniel.jackson@cs.cmu.edu) & Craig A Damon(mailto: craig.damon@cs.cnu.edu)
 Elements of Style: Analyzing a Software Design Feature with a Counterexample Detector
 Proc 1996 Int Symposium on Software Testing & Analysis(ISSTA) & ACM SIGSOFT SENotes V21n3(May 1996)pp239-249 & IEEE Trans Soft Eng VSE-22n7(Jul 1996)pp484-495
 Jackson's home page
.See http://www.cs.cmu.edu/~dnj/
.Box
V&V Z Specifications formal  Demo on style sheets for wordprocessor example. TOOL(Macintosh)Nitpick

Checks properties by enumerating possibilitis(within bounds) and displaying first counterexample.  Not animation so no constructive description of transitions but is completely automatic and can cover enormous numbers of cases by using reduction mechanisms

.Close.Box
.Close

JacksonDJacksonM95
.Open JacksonDJacksonM95
 Daniel Jackson & Michael Jackson
 Problem Decomposition for Reuse
 Tech Rep CMU-CS-TR-95-108
 School of Computer Science Carnegie Mellon University Pittsburgh PZ Jan
 to appear in Software Engineering Journal
.Close

JacksonDWaingold99
.Open JacksonDWaingold99
 Daniel Jackson & Allicon Waingold
 Lightweght Extraction of Object Models from Bytecode
 ICSE'99, Proceeedings of the 21st International Conference on Software Engineering (May 1999)pp194-202
 =DEMO Womble reverse engineers object-oriented model using Alloy from JAVA Bytecode
 Not perfect but still useful to programmers, does not find n-ary relations.
.Close

JacksonDWaingold01
.Open JacksonDWaingold01
 Daniel Jackson & Allison Waingold
 Lightweight extraction of Object Models from Bytecode
 IEEE Trans Software Engineering  V27n2(Feb 2001)pp156-169 also in ICSE'99 
.See [JacksonDWaingold99]
 =DEMO TOOL TECHNICAL Java bytecode MODEL Alloy Womble Superwomble Rose
 * := zero or more, ? := zero or one, ! := exactly one.   ---|-> := static.
 Womble::=http://sdg.lcs.edu/womble.
.Close

JacksonDWing96
.Open JacksonDWing96
 Daniel Jackson & Jeanette Wing
 Lightweight Formal Methods
 IEEE Computer Magazine V29N4(Apr 1996)pp21-22
 more like a surgical lazer than a light bulb. Partial languages: models and analysis
.Close

JacksonK89
.Open JacksonK89
 Ken Jackson
 Providing for the Missing Steps
 UNIX Review v6n11(Nov 1988) pp55-63
 SAD DFD DDD DAD Mascot
.Close

JacksonKLavi93
.Open JacksonKLavi93
 Ken Jackson & Jonah Z Lavi
 "CBSE Task Force seeks standard conceptual models for new discipline"
 IEEE Computer magazine V26n5(May 1993)pp98-99
 =CFP
 CBSE::="Computer-Based Systems Engineering"
.Close

JacksonTwaddle97
.Open JacksonTwaddle97
 Michael Jackson & Graham Twaddle
 Business Process Implementation: Building Workflow Systems,
 Addison Wesley ACM Press 199? ISBN 0-201-17768-4 3rd hd58.87.j32 1997
 =EXPERIENCE SPECIFICATION MODEL OFFICE WORKFLOW PEOPLE DATA PROCESS FLEXIBLE vs BUSINESS RULES TABULAR GRAPHIC METADATA
 workflow_problem_frame ::= following,
.Net
 |-(minimal_workflow_frame):The machine supports an office that interacts with an outside world.
 |-The prime business need is to keep track of long term commitments, contracts, and obligations.
 |-There  are rigid business rules and flexible activities.
 |- activities are multitasked error correcting that proceed at a human pace.
 |- not safety critical.
.Close.Net
  theoretical_method:= data; process; tasks; workflow.
 In practice incremental and iterative delivery is feasible.
 data:=`simple ERD`, like SSADM.
 task_types:=initiated performed content 
.See [task_details].
   initiated:=X | T | P | I.  X=eXternal, T=Time, P=follows Preceeding, I=Internally.
   performed= A | M, A=Automatically, M=not A, `Manually`,
   content:= E | K| U | D | O, E=dataEntry, K=checK, U=Update, D=Decision, O=Output.
  Tasks involve entities.  
 LC:=" life cycle".
 An entity life cycle is a defined sequence of stages but an entity may not progress thru the stages in such a simple way.  Office work may backtrack, hang up, fail, or multitask parts of stages at one time.  Stages may not be omitted.  Backtracking (a `setback`) means handling side-effects: beneficent, neutral, and intolerable. cf 
.See [JSP].
   In a stage contains a task that fails then the current life cycle fails and initiates a different one instead.
   Stages determine states:  State = ("In" | "Failed" | "Awaiting" | "Halted" ) stage.
    Within a Stage many tasks can execute in parallel.  some can spawn (one|many (inclusive | exclusive)) subtasks (sometimes). One subtask can be spawned by many tasks, and a subtasks can restart their parent tasks (in a loop).
    Task states = null; start; (n/a | run | failed | passed).  passed states do not spawn subtasks, run states must start their subtasks.  Task states determine life-cycle states.
  There are rules for assigning tasks to stages.
  One life cycle can depend on another one.  Changing stage depends on one(or all) other linked entities of a given type is|are past a certain stage.  Tasks can start and halt other life cycles.
  Entities are placed in classes. Classes form a `heterarchy` -- multiple inheritance.  Also classification entities -- classes of objects each defining a class of object!
  Entities play roles in entity life cycles.  roles require only a subset of the attributes,  Also several types of entity can play the part in a single role.
  Datasets are structured  navigation paths between entity types.  `from A access one B and many Cs`.  They are chosen to fit tasks.
 Programs support tasks - within task context and using task content. actions include SET_RESULT, START_LC, SUSPEND_LC, RESUME_LC, CANCEL_LC, SETBACK_LC, WAIT..., SIMPLE_CHECK, COMPLEX_CHECK, SIMPLE_SET, APPLICABLE_WHEN.  Some tasks must not be repeated, others may be repeated when backtracking.
 Decision Tables!
 Tasks and life cycle work mainly define wrong sequences.  Work flows help get good things done.   Work flows are about scheduling, options, menus, and efficiency.  Work flows are based on a relational data base:
 task_details:=Net{
 Each task is in a stage of a life cycle of an entity.
 Each task has a task_type that has a program, data set, and a set of skills.
 Tasks are related to users who can/should do them by Skills and by stages and departments for example. 
}.
  Detailed reporting and so tuning of the workflows.
 Life cycle definitions and the office workflow are also held in the data base. "Process representations become data".  Process data is PLANs and FEATUREs. 
 The only purpose of documentation is understanding.... but if documentation is in a data base is also useful to the software.
 dick:`the office workflow frame fits agile software development process.`
.Close

LawrenceJacksonD96
.Open LawrenceJacksonD96
 Brian Lawrence & Daniel Jackson
 Point  Counterpoint: Do You Really Need Formal Requirements? vs Requrements need Form and Maybe Formality
 IEEE Software magazine V13n3(Mar 1996)pp20-22
 =DEBATE FORMALISM REQUIREMENTS
.Close

OCallahanJackson97
.Open OCallahanJackson97
 Robert O'Callahan & Daniel Jackson
 Lackwit: A Program Understanding Tool Based on Type Inference
.See [ICSE'97]
 =DEMO TOOL CODE ANALYSIS TYPES BUGS
 signatures recover "real" types from "int" etc. Finds memory leaks and such.
.Close

RE'97
.Open RE'97
 IEEE
 Proceedings of the Third IEEE International Symposium on Requirements Engineering(Annapolis MD Jan 1997)
 IEEE CS 1997 ISBN 0-8186-7740-6 IEEE Order Number PR07740
 =PROCEEDINGS REQUIREMENTS 1997
.Box

.See [Ben-AbdallahEtal97]
.See [DanoBriandBarbier97]
.See [EasterbrookCallahan97]
.See [Hall97]
.See [HeimdahlKeenan97]
.See [HunterNuseibeh97 ]
.See [LeiteEtal97]
.See [MassonetLamsweerde97]
.See [ModugnoEtal97]
.See [PottsNewstetter97]
.See [RoscaEtal97]
.See [Rushby97]
.See [YenTiao97]
.See [Yu97]
.See [ZaveJackson97a]
.See [ZowghiOffen97]
.Close.Box
.Close

Saiedian95
.Open Saiedian95
 Hossein Saiedian
 An invitation to Formal methods(introduction to a round table)
 IEEE Computer Magazine V29N4(Apr 1996)pp16-17
 =EDITORIAL MATHEMATICS
 "In essence formal methods offer the same advantages for software (or even
hardware) design that many other engineering disciplines have exploited - 
namely mathematical analysis using a mathematically based model".
 See 
.See [BowenHinchey96]
.See [Glass96]
.See [JonesCB96]
.See [JacksonDWing96]
.See [Hall96]
.See [DillRushby96]
.See [HollowayButler96]
.See [Zave96]
.See [Lutz96]
.See [Parnas96]
.See [Gries96]
.Close

SiddiqiShekaran96
.Open SiddiqiShekaran96
 Jawed Siddiqi(Sheffield Hallam U UK) & M Chandra Shekaran(MS)
 Requirements Engineering: The Emerging Wisdom
 IEEE Software magazine V13n3(Mar 1996)pp15-19
 =EDITORIAL REQUIREMENTS ENGINEERING
 introduction to special theme articles pp20-64
 RE::=systems analysis with engineering orientation
 effect of context+need to handle changing context+questioning what.vs.how
and the functional.vs.nonfunctional + problem frames and repetoire of 
methods( Jackson95)+anthopological approach + non-contractual forms of 
requirements(no one-size)
.Close

VesseyGlass98
.Open VesseyGlass98
 Iris Vessay & Robert Glass
 Strong vs Weak Approaches to Systems Development
 Comm ACM V41n4(Apr 1998)pp99-102
 =ESSAY ONE-SIZE WEAK METHODS
 See
.See [GlassVessey95]
 Weak methods fit many problems loosely but strong methods fit fewer problems and solve them better. Ref to Jackson95
 Unified methodologies vs techniques
 Matching method to application domain and technique to task
 cognitive fit
 multiparadigm approaches
 disaggreagte methodologies into collection of techniques
.Close

ZaveJackson93
.Open ZaveJackson93
 Pamela Zave<pamela@research.att.com> & Michael A Jackson
 Conjunction as Composition
 ACM Trans on Softw Eng & Meth V2n4(Oct 1993)pp379..411 CR9408-0546
 =DEMO FORMAL REQUIREMENTS SPECIFICATION
.Box
Note Multi-paradigm specifications, more in Jackson95x

Must have common semantics.  So assume first order logic. Model types as one-place predicates. Kleene's notation..., Z , prolog,....

Renaming to couple and instanciate specifications.

Distinguish defined from undefined terms.
 ?? Problem with recursive predicate definitions
Must form a DAG

statements equivalent to
.As_is 		for all p:Projects, one m:EMPLOYEE(m leads p).
member(x,y) := x \in y

sequences modeled as totally order sets of events.

Net{member::@event, preceeds::@(event,event)... initial, final,...}
.Close.Box
.Close

ZaveJackson96
.Open ZaveJackson96
 Pamela Zave<pamela@research.att.com> & Michael A Jackson
 Where Do Operations come From? A Multiparadigm Specification Technique
 IEEE Trans Soft Eng VSE-22n7(Jul 1996)pp508-528
 =DEMO specification methods logic std Z
 better than 
.See [ZaveJackson9X]
 
.See [ZaveJackson93]
.Close

ZaveJackson97a
.Open ZaveJackson97a
 Pamela Zave<pamela@research.att.com> & Michael A Jackson
 Requirements for Telecommonications Services: An Attack on Complexity
 RE'97
.See [RE'97] pp106-117
 =CASE-STUDY TABULAR FSM/STD FORMAL REQUIREMENTS
 
.See [ZaveJackson96]
 effective techniques based on general principles:  define the environment not the new system + leave out unnecessary + formalize only when effecive and helpful+combine and specialize languages + parallel state decomposition + uniform event semantics with no internal events(no vars if can refer to attributes of most recent events)
.Close

ZaveJackson97b
.Open ZaveJackson97b
 Pamela Zave<pamela@research.att.com> & Michael A Jackson
 Four Dark Corners of Requirements Engineering
 ACM TOSEM V6n1(Jan 1997)pp1-30
 =ESSAY REQUIREMENTS REALITY PURPOSE
.Close

ZaveJackson98
.Open ZaveJackson98
 Pamela Zave & Michael A Jackson
 A Component-Based Approach to Telecommunication Software
 IEEE Software Magazine V18n5(Sep/Oct 1998)pp70-78
 =DEMO DFC system
 Applies the pipe-and-filter archtectural style to describing complex telecommunications systems.
.Close

ZaveJackson9X
.Open ZaveJackson9X
 Pamela Zave & Michael A Jackson
 Where Do Operations come From? Specification of Event Properties
 Preprint received Pamela Zave 1993 - Submitted for publication 1993.  Published as 
.See [ZaveJackson96]
 =DEMO Multiparadigm specification GRAPHIC Z STDs Jackson diagrams predicate LOGIC
 sequences input events occurring at multiple events need to be mapped into central operations in a central specification
 incomprehensible graphical notation for case analysis(fig 4) is not  in 
.See [ZaveJackson96]
.Close

Search for bibliographic items containing a matching string.


(Search uses POSIX regular expressions and ignores case)

To see the complete bibliography (1Mb+) select:[Bibliography]