Development Methods
 A System and Software (Sys/SW) Design Methodology*


Links: Resume | Papers | Courses | Consulting | ContEd | HW/SW | Tech Interests (Professionalism and Best Practice)
Terminology | Organizations | Certifications | Standards | Methods | Companies | Tools | Schools | Conferences

Viewpoint: ad hoc | Object Oriented | Domain Engineering Methods | Enterprise Arch |
Functional | Data-Structured | Modeling | Formal | See also related Quotes

* "methodology" = study, history, and classification of methods

ad hoc Methods   'ad-'häk -- Latin, "for this";
for the particular end or case at hand without consideration of wider application [Merriam-Webster]

  • method-less, undefined, high-risk
  • "Hurry up and code so we can test"
  • "PDR until the noise dies down"
  • "Program it, then generate the design"
  • "Burry them in documentation!"

ad hoc | Object Oriented | DE | Enterprise Arch | Functional | Data-Structured | Modeling | Formal

Object Oriented [OO] Methods
See also: OO_Links, Macintosh, and Domain Engineering

  • Description: Using High-Order Languages (HOL) expands the capability for the developer to define "abstractions" that model the real-world. The "things" in the world are objects, which can be grouped in to "classes" and class-relationships, which define the similarities and differences between classes and subclasses. Objects can be manipulated through "methods" or "operations". Operations can interrogate the state of an object (selector, usually implemented with a function) or change the state of an object (constructor, usually implemented with a procedure). This approach to decomposition builds on the history of the other development methods below...
    • Extends the concepts of data abstraction and information hiding [used with a number of  Formal approaches]
    • Localizes data (the state, attributes, input, and output, etc.) with the the object, similar to Data-Structured and Modeling approaches
    • Borrows some concepts from Modeling approaches and Formal Communicating Sequential Processes to model dynamic (living, concurrent) objects
    • Builds on the Functional approaches, by making the Operations (within an object/class) functionally cohesive
  • General Notations:
    • The "Booch Notation" was one of the first to be applied in commercial/defense applications, evolving out of the Ada community and Grady Booch's work at the Air Force college. Grady later went to work for Rational Software, and their Ada compilation system written entirely in Ada. See short history on OO Page.
    • From this work, other notations have evolved, some language-specific
    • Today there are two predominant notations: UML (plus SysML) and OPEN
  • Examples: Alphabetical listing of OO methods and links, where known

ad hoc | Object Oriented | DE | Enterprise Arch | Functional | Data-Structured | Modeling | Formal

Domain Engineering [DE] 

  • For DE, Systematic Reuse, or Product-Line Development methods, see DE Links.

ad hoc | Object Oriented | DE | Enterprise Arch | Functional | Data-Structured | Modeling | Formal

Enterprise or System Architecture Notations 

  • DoDAF or DODAF -- DoD Architecture Framework
    • Used for the definition of enterprise or system architectures
    • DODAF is eclectic [composed of elements drawn from various sources]:
      • It appears that the "bulk" of the notation is descended from SADT (and IDEF)
      • However, other notations are allowed, borrowed from a mixture of Functional and Object Oriented notations: SA, SD, and UML/Use Cases
    • DODAF appears to be fairly "loose" as standards go -- i.e., "mileage may vary"
      • Defining the purpose, and the intended use of the enterprise or system architecture, is critical in "managing" the method (and the customer)
      • Therefore, the level of detail (legitimately) will vary greatly depending on that use and scope
      • Not all views are required
      • Alternative representations can be used for the same view, and at different abstraction levels
      • Some views are purely pictorial with no defined notation syntax or semantics (e.g., OV-1, which is a type of context diagram, but is called a "High-Level Operational Concept")
      • The relationships (semantics) between the all options, combinations, or representations are:
        • not fully defined by the standard
        • nor fully supported by available tools
      • The defined views were not adequate and may need to be extended to capture information critical to the enterprise architecture:
        • Extend OV-6 Operational Rules model to also include State Transition Diagrams, Event-Trace Description Diagrams, and Operational Process Models (with "swimming" lanes defined by role and time-ordered tasks)
        • Create a Systems Evolution Description and Business Capabilities as supplemental information (not standard DoDAF)
        • Manage requirements outside the DoDAF and related tools [e.g., using DOORS]
  • FEAF -- Federal Enterprise Architecture Framework (IEEE P1471)
  • ISO RM-ODP --
  • MDA -- Model-Driven Architecture, from OMG
  • MVC -- Model-View-Controller, from OMG
  • SysML -- Systems Modeling Language (SysML), from OMG
  • UML -- Unified Modeling Language™ (UML®), from OMG (see OO Standards)
  • Zachman Framework --

ad hoc | Object Oriented | DE | Enterprise Arch | Functional | Data-Structured | Modeling | Formal

Functional Decomposition and Structured Methods

  • Description: The methods which are based on functional decomposition and stepwise refinement; the breaking down of complex systems into single-function tasks and subtasks. These techniques were the first to evolve. The analysis part (data flows) tended to concentrate on the business flow (which was generally manual in the beginning). The data was simple (integers, float/real, and characters), but the processing was typically complex. The early methods were used both for MIS and real-time systems. Extensions of these methods (e.g., Structured Analysis of Real-Time Systems) gave more support for real-time systems and concurrent processing.
  • General Notations:
    • Structured Analysis used dataflow diagrams (DFDs), circles or rounded rectangles connected by arrows and noted with the data that "flowed" between processes.
    • Structured Design used structured charts which showed the decomposition of functions and their allocation to "units."
    • Data dictionaries were added later to keep track of all the data, to control the "name space," and to define the composition of each data item indicated on a data flow or structure chart.
  • Examples:
    • Buhr Machine Charts
    • Composite Structured Design [Myers, 1976]
    • CORE, COntrolled Requirements Expression - a requirements analysis technique frequently used with MASCOT
    • DARTS, Design Approach for Real-Time Systems
    • DoDAF or DODAF -- DoD Architecture Framework.
      • DCDS, Distributed Computing Design Systems
      • ESML, Extended Systems Modeling Language - A combination of techniques from SDRTS and Hatley/Pirbhai
      • Gane/Sarson, see SSA
      • Hatley/Pirbhai, from Boeing
      • IDEF, Integrated Computer Aided Manufacturing (ICAM) Definition, a version of SADT (and related tool). See:
      • MASCOT, Modular Approach to Software Construction Operation and Test - Can use CORE, SA, or JSD as a front end.
      • Myers, see Composite Structured Design
      • Page-Jones
      • Pseudo Code, step-wise refinement using
        • ADL - Ada Design Language
        • PDL = Program Design Language
        • See Anna
        • The use of a programming language (or other formalized natural language) to specify system components, architectures, or algorithms in a human-readable form [may also be parsed, elaborated, executed, or compiled]
        • Attempt is to achieve some language independence to prevent over-constraining the solution
      • SA, Structured Analysis (DeMarco)
      • SD, Structured Design (Constantine)
      • SA/SD [one of the first functional methods, which was published individually (SA and SD) and combined  by Yourdon Press], see also Myers
      • SADTTM Structured Analysis and Design Technique, is a graphical language for describing systems, developed in the early 1970s at SofTech, Inc. The methodology was devised to produce a specification that can be fed into other standard methodologies. See [Dickover, et al, 1977], [Ross, 1985], and [Marca & McGowan, 1988]. The US Air Force later revised SADT to create IDEF.
      • SDRTS, Structured Design of Real Time Systems - An extension of SA/SD, by Ward & Mellor, to include control flows and state diagrams for real time systems
      • SSA, Structured Systems Analysis -  a variant of SA/SD) developed by Gane/Sarson
      • STRADIS = SSA when used by McDonnell Douglas
      • Ward & Mellor, see SDRTS
      • Yourdon method -- see SA, SD, and SA/SD

    ad hoc | Object Oriented | DE | Enterprise Arch | Functional | Data-Structured | Modeling | Formal

    Data-Structured Methods

    • Description: The methods which are based on decomposition of complex data; also called Data-Centric Methods. Used for systems that tend to be mostly databases and the modification of how that data was presented to the user. These techniques evolved early in the history of software engineering and overlapped with Functional Methods. Techniques tend to start with the desired output and work backwards to the desired input. The architecture defines the "processes" which  transform the input data into the needed output data. These techniques are favored by developers of Management Information Systems, where data is more complex than the processing on the data.
    • General Notations:
      • hierarchical trees
      • Entity diagrams, Chen Diagrams, ERDs (Entity-Relationship Diagrams)
    • Examples:
      • DSSD - Data Structured System Design - Warnier/Orr, uses entity diagrams
      • JSP - Jackson Structured Programming, hierarchical trees
      • LCP, Logical Construction of Programs - Warnier Method, hierarchical trees
      • Database Design
        • Hierarchical
        • Network
        • Relational - Chen Method
        • Object

    ad hoc | Object Oriented | DE | Enterprise Arch | Functional | Data-Structured | Modeling | Formal

    Modeling Methods

    • Description: These techniques treat all system functions as parallel processes (i.e., they could potentially occur the same time). These techniques were first developed for controlling trains, elevators, and other controlling devices and were most widely accepted in Europe. Originally, the techniques created a concurrent conceptual model, which then had to be converted into a sequential implementation model (to simulate concurrency), since computers at that time were more costly. The implementation became easier as computers began to support multiprocessing (2+ programs running in the same box) and multiprocessors (2+ CPUs in a single box) and computer languages began to support concurrent processes (e.g., Ada tasking).
    • General Notations:
      • varies by method
    • Examples:
      • JSD - Jackson System Development
      • PAMELA and PAMELA II
      • Rate Monotonic (Realtime) Scheduling [see Cont-Ed]

    ad hoc | Object Oriented | DE | Enterprise Arch | Functional | Data-Structured | Modeling | Formal

    Formal (or Mathematical or Logic-Based) Methods

    Key: italic supports encapsulation; bold supports concurrency; italics-bold supports both
    • Description: These techniques build on the early math foundations of computer science. Mathematical proofs are used as a form of verification of the system. These techniques are frequently used on safety critical or security critical systems (e.g., nuclear power plant, life support systems, national security systems, etc.).
    • General Notations:
      • varies by method, but typically based on predicate calculus or set theory
    • Examples:
      • Anna (Annotated Ada), developed by Stanford University
      • CCS, Calculus of Communication Systems
      • "Cleanroom" software development process
        • Named after the hardware "cleanrooms" used for assembling space systems
        • Proposed by Harlan Mills from FIT and SET
        • emphasized top-down design and formal specification
      • COSY, COncurrent SYstems
      • CSP (Communicating Sequential Processes), originally devised by C.A.R. Hoare.
      • Gypsy - method/language used for secure systems
      • HDM, Hierarchical Development Method
      • HOS, Higher Order Software, used on Apollo program
      • RAISE - Rigorous Approach to Industrial Software Engineering http://dream.dai.ed.ac.uk/raise/
      • SARA, Structured ARchitect's Apprentice
      • VDM - Vienna Development Method (originally developed by IBM, Vienna)
      • WELLMADE
      • Z ("zed," the British pronunciation zee)
      • See http://www.comlab.ox.ac.uk/archive/formal-methods.html for more methods

    ad hoc | Object Oriented | DE | Enterprise Arch | Functional | Data-Structured | Modeling | Formal

    Return to Electronic Resume

    		©1994-2007 Gregory M. Bowen, CSDP