Abstract
The chapter provides an overview of FOOM–Functional and Object-oriented Methodology–for analysis and design of information systems. FOOM integrates the functional and object-oriented approaches. In the analysis phase, two main models are created: a) a conceptual data model, in the form of an initial class diagram; and b) a functional model, in the form of OO-DFDs (object-oriented data-flow diagram). In the design phase, the above models are used to design the following products: a) a complete class diagram, including Data, Menus, Forms, Reports and Transactions classes, including their attributes, relationships and methods; b) the user interface–a menus tree; c) the input and output form and report; and d) detailed descriptions of the class methods, expressed in pseudo-code or message charts.
TopBackground
Many paradigms for system analysis and design have been proposed over the years. Early approaches have advocated the functional approach. Common methodologies that support this approach are SSA and SSD (DeMarco, 1978; Yourdon & Constantine, 1979). SSA is based on the use of data flow diagrams (DFDs), which define the functions of the system, the data stores within the system, the external entities, and the data flows among the above components. Early SSA and similar methodologies emphasized the functional aspects of system analysis, neglecting somehow the structural aspects, namely the data model. This was remedied by enhancing those methodologies with a conceptual data model, usually the entity-relationship (ER) model (Chen, 1976), that is used to create a diagram of the data model, which is later mapped to a relational database schema.
SSD is based on the use of structure charts, which describe the division of the system to program modules as well as the hierarchy of the different modules and their interfaces. Certain techniques have been proposed to create structure charts from DFDs (Yourdon & Constantine, 1979). The main difficulty of an approach where functional analysis is followed by structured design lies in the transition from DFDs to structure charts. In spite of various guidelines and rules for conversion from one structure to the other, the problem has not been resolved by those methodologies (Coad & Yourdon, 1990).
Shoval (1988, 1991) developed the ADISSA methodology that solved this problem. It uses hierarchical DFDs during the analysis stage (similar to other functional analysis methodologies), but the design centers on transactions. A transaction is a process that supports a user who performs a business function, and is triggered as a result of an event. Transactions will eventually become the application programs. Transactions are identified and derived from DFDs: A transaction consists of elementary functions (namely, functions which are not decomposed into subfunctions) that are chained through data flows, and of data-stores and external-entities that are connected to those functions. A transaction includes at least one external-entity, which serve as its trigger. The process logic of each transaction is defined by means of structured programming techniques, for example, pseudo-code.
Based on the hierarchical DFDs and the transactions, ADISSA provides structured techniques to design the user-system interface (a menus-tree), the inputs and outputs (forms and reports), the database schema, and detailed descriptions of the transactions, which will eventually become the application programs. The menus-tree is derived from the hierarchy of DFDs in a semi-algorithmic fashion, based on functions that are connected to user-entities. The design of the forms and reports is based on data flows from user-entities to elementary functions and from elementary functions to user-entities. The design of the relational database schema is based on the analysis of dependencies among the data elements within the data-stores. The data flows from elementary functions to data-stores and from data-stores to elementary functions serve as a basis for defining access-steps, namely update and retrieval operations on the relations. Access-steps are expressed as SQL statements that will be embedded in the program code of the respective transactions. The products of the design stages can be easily implemented using various programming environments.
Key Terms in this Chapter
ADISSA – Architectural Design of Information Systems based on Structured Analysis: A systems analysis and design methodology which follows the functional- (process) oriented approach ( Shoval, 1988 ). In the analysis phase of development it utilizes hierarchical DFDs. In the design phase the DFDs are used to design the various components of the system. These include: a) top-level descriptions of the transactions, which eventually become detailed descriptions of the applications programs; b) the user interfaces (menus); c) the input and output screens and reports; and d) the database schema, or normalized relations, and SQL commands for retrieving and updating the database.
FOOM – Functional and Object-Oriented Methodology: A systems analysis and design methodology which integrates these two approaches, as described in this chapter ( Shoval, 2007 ; Shoval & Kabeli, 2001 ).
SSA - Structured System Analysis: A traditional, functional-oriented methodology for analyzing information systems, which utilized data flow diagrams.
OO-DFD – Object-Oriented DFD: A variant of DFDs introduced in FOOM methodology, which include object (data) classes rather than data stores.
UML – Unified Modeling Language: An “industrial standard” notation for object-oriented development. It consists of a several types of (mostly) diagrams that enable describing systems from different perspectives, including structural, behavioral (functional) and managerial.
SQL – Structured Query Language: A standard language for querying and updating a relational database.
ER - Entity-Relationship: A conceptual data model which defines the domain in terms of entities, attributes and relationships ( Chen, 1976 ). ERD is an ER diagram, in which entities are represented as rectangles, attributes as ellipses and relationships between entities as diamonds.
DFD - Data Flow Diagram: A diagram used in functional analysis which specifies the functions of the system, the inputs/outputs from/to external (user) entities, and the data being retrieved from or updating data stores. There are well-defined rules for specifying correct DFDs, as well as for creating hierarchies of interrelated DFDs.
SSD - Structured System Design: A traditional methodology for designing information systems, which utilized structure charts.