FOOM methodology

This research endeavors to investigate the process of eliciting data flow by employing both data flow diagrams and user case diagrams. Through an in-depth analysis of existing literature and comprehensive comparisons between these two diagrammatic representations, the study concludes that the most effective approach for systems analysts involves the concurrent utilization of both types of diagrams. These two diagrams will enhance the understanding of data flow dynamics within the system, encompassing the data flow between system functions and the seamless flow of data among those engaged with the system. By leveraging the strengths of both data flow diagrams and use case diagrams, analysts can achieve a more holistic and nuanced comprehension of the intricate data flow relationships inherent in complex systems.

Functional and Object Oriented Methodology (FOOM) combines two essential software-engineering paradigms: the functional (process-oriented) approach and the object-oriented (OO) approach. The two main products of FOOM's analysis phase are two models: a data model in the form of an initial class diagram and a functional model in the form of OO-DFDs (a hierarchy of data flow diagrams including data classes). We evaluate the quality of these models by comparing them with the quality of equivalent analysis models products by Object-Process Methodology (OPM), which also combines the functional and object-oriented approaches, using a unified diagrammatic notation. The comparison is based on a controlled experiment which measured the correctness of the analysis models (specifications) produced by the two methodologies. The results reveal that the quality of models produced by FOOM is better than those produced by OPM.

We propose a methodology for information systems analysis and design which is a hybrid of two main streams in software engineering, the functional (or process-oriented) approach and the object-oriented (OO) approach. System analysis, which aims at eliciting and defining user requirements, continues to be carried out in the functional approach, utilizing data flow diagrams (DFD). System design, which aims at designing the software, is carried out in the OO approach, yielding an object model that consists of an object schema and a behavior schema (i.e., methods and messages). The transition from the functional model (in the analysis stage) to the OO model (in the design stage) is enabled by the use of ADISSA methodology, which facilitates design of the object schema from DFD data stores, and design of the behavior schema from transactions, which by themselves are derived from the DFDs.

Product or company names used in this book are for identification purposes only. Inclusion of the names of the products or companies does not indicate a claim of ownership by IGI of the trademark or registered trademark. Shoval, Peretz. Functional and object oriented analysis and design : an integrated methodology / Peretz Shoval. p. cm. Summary: "The main objective of this book is to teach both students and practitioners of information systems, software engineering, computer science and related areas to analyze and design information systems using the FOOM methodology. FOOM combines the object-oriented approach and the functional (process-oriented) approach"-Provided by publisher.

Security in general and database protection from unauthorized access in particular, are crucial for organizations. While functional requirements are defined in the early stages of the development process, non-functional requirements such as security tend to be neglected or dealt with only at the end of the development process. Various efforts have been made to address this problem; however, none of them provide a complete framework to guide, enforce and verify the correct design of security policies, and eventually generate code from that design. We present a novel methodology that assists developers, in particular database designers, to design secure databases that comply with the organizational security policies that are related to access control. The methodology is applied in two main levels: organizational level and application development level. At the organizational level, which takes place before the development of a specific application, organizational policies are defined in the form of security patterns. These patterns encapsulate accumulated knowledge and best practices on security related problems. At the application development level, the datarelated security requirements are defined as part of the data model. The security patterns, which have been defined at the organizational level, guide the definition and implementation of the security requirements. The correct implementation of the security patterns is verified during the design stage of the development process, before the automatic generation of the database code. The methodology is supported by a CASE tool that assists its implementation in the various stages.

Information systems analysis and design (ISAD) arguably lies in the core of the Information Systems (IS) discipline. Although ISAD is central to the IS curriculum, it remains somewhat at the periphery of research in leading journals. A recent study (Vessey, Ramesh, and Glass 2002) showed that few of the articles published in five leading IS research journals from 1995 to 1999 deal with these topics. This special issue is the outcome of a special joint initiative between the Journal of the Association for Information Systems (JAIS) and the Communications of the Association for Information Systems (CAIS), with the purpose of beginning to fill this void and to attract the attention of researchers to this important area. The papers in this issue illustrate a range of ISAD topics-conceptual modeling, database design, and the role of knowledge management in systems development project performance.

During the requirements analysis phase of information systems development, the user and analyst attempt to come to an agreement on the purpose of the system and the needs of the future users. When completed effectively, this process leads to the cre-ation of an information system that fulfills the intended purpose and meets the needs of users and their organization, on time and within budget [3]. This, of course, is dependent on the successful completion of the rest of the development process including the designing, coding, and testing of the system. Problems unsolved in the requirements elicitation phase may worsen during the remainder of the systems development project. As over 50 % of the errors in systems design and development are a result of inaccurate requirements, it is imperative this phase be completed accu-rately [6]. Often, information systems are designed and created that do not meet the needs of the users or fulfill their intended purpose [3, 6]. The deficiencies of t...

During the requirements analysis phase of information systems development, the user and analyst attempt to come to an agreement on the purpose of the system and the needs of the future users. When completed effectively, this process leads to the creation of an information system that fulfills the intended purpose and meets the needs of users and their organization, on

Users' requirements of an information system are modeled in the analysis phase of the development process. The requirements can be modeled with various modeling methods. In this study, we compare two alternative methods for modeling the functional requirements: one is the UML Use Case (UC) model; the other is OO-DFD transaction (Object-Oriented DFD is a variant of DFD that includes data classes rather than ''traditional'' data stores). Each of these modeling methods consists of diagrams accompanied with narrative, semi-structured descriptions explaining their details. We conducted a controlled experiment that compared the comprehension of the two models (i.e., the diagrams and their descriptions) of a certain system and the quality of models created for a certain system with each of the two modeling methods. The main results of the experiment are that models created with the UC method are of better quality than models created with the OO-DFD transaction method because the former are simpler and less detailed; creating highly detailed models are error prone. Interestingly, in spite of the difference in the level of detail and structure, the experiment reveals no significant difference in comprehension of models of the two methods. The results call for improvement of the modeling methods in a way that considers the advantages of each of them, and thus we propose an improved method sketch that we call Enhanced Use Case, which will be evaluated in future work.

Users' requirements of an information system are modeled in the analysis phase of the development process. The requirements can be modeled with various modeling methods. In this study, we compare two alternative methods for modeling the functional requirements: one is the UML Use Case (UC) model; the other is OO-DFD transaction (Object-Oriented DFD is a variant of DFD that includes data classes rather than ''traditional'' data stores). Each of these modeling methods consists of diagrams accompanied with narrative, semi-structured descriptions explaining their details. We conducted a controlled experiment that compared the comprehension of the two models (i.e., the diagrams and their descriptions) of a certain system and the quality of models created for a certain system with each of the two modeling methods. The main results of the experiment are that models created with the UC method are of better quality than models created with the OO-DFD transaction method because the former are simpler and less detailed; creating highly detailed models are error prone. Interestingly, in spite of the difference in the level of detail and structure, the experiment reveals no significant difference in comprehension of models of the two methods. The results call for improvement of the modeling methods in a way that considers the advantages of each of them, and thus we propose an improved method sketch that we call Enhanced Use Case, which will be evaluated in future work.

Modeling of functional requirements of an information system is an important task, and there are numerous methods for doing so. We compared two alternative modeling methods for defining functional requirements in object-oriented information system development process: one is OO-DFD transactions-part of FOOM methodology; the other is Use Cases (UC)-part of the UML. The two methods consist of diagrams followed by descriptions that add explanations to the diagrams.

This paper identifies four problems with UML activity diagramming that have implications for teaching and practice. Solutions to each of the four problems are provided. The proposed solutions are borrowed from existing modeling paradigms, specifically structured systems analysis and design methods (SSAD). We did not see the need to reinvent solutions when adequate remedies exist. The proposed solutions help to improve the syntax, semantics, and consistency of activity diagramming in UML.

Modeling of functional requirements of an information system is an important task, and there are numerous methods for doing so. We compared two alternative modeling methods for defining functional requirements in object-oriented information system development process: one is OO-DFD transactions-part of FOOM methodology; the other is Use Cases (UC)-part of the UML. The two methods consist of diagrams followed by descriptions that add explanations to the diagrams.

Users' requirements of an information system are modeled in the analysis phase of the development process. The requirements can be modeled with various modeling methods. In this study, we compare two alternative methods for modeling the functional requirements: one is the UML Use Case (UC) model; the other is OO-DFD transaction (Object-Oriented DFD is a variant of DFD that includes data classes rather than “traditional” data stores). Each of these modeling methods consists of diagrams accompanied with ...

Users' requirements of an information system are modeled in the analysis phase of the development process. The requirements can be modeled with various modeling methods. In this study, we compare two alternative methods for modeling the functional requirements: one is the UML Use Case (UC) model; the other is OO-DFD transaction (Object-Oriented DFD is a variant of DFD that includes data classes rather than ''traditional'' data stores). Each of these modeling methods consists of diagrams accompanied with narrative, semi-structured descriptions explaining their details. We conducted a controlled experiment that compared the comprehension of the two models (i.e., the diagrams and their descriptions) of a certain system and the quality of models created for a certain system with each of the two modeling methods. The main results of the experiment are that models created with the UC method are of better quality than models created with the OO-DFD transaction method because the former are simpler and less detailed; creating highly detailed models are error prone. Interestingly, in spite of the difference in the level of detail and structure, the experiment reveals no significant difference in comprehension of models of the two methods. The results call for improvement of the modeling methods in a way that considers the advantages of each of them, and thus we propose an improved method sketch that we call Enhanced Use Case, which will be evaluated in future work.

Data flow diagrams (DFDs) reveal relationships among and between the various components in a program or system. DFDs are an important technique for modeling a system's high-level detail by showing how input data is transformed to output results through a sequence of functional transformations. DFDs consist of four major components: entities, processes, data stores, and data flows. The symbols used to depict how these components interact in a system are simple and easy to understand; however, there are several DFD models to work from, each having its own symbology. DFD syntax does remain constant by using simple verb and noun constructs. Such a syntactical relationship of DFDs makes them ideal for object-oriented analysis and parsing functional specifications into precise DFDs for the systems analyst.

Users' requirements of an information system are modeled in the analysis phase of the development process. The requirements can be modeled with various modeling methods. In this study, we compare two alternative methods for modeling the functional requirements: one is the UML Use Case (UC) model; the other is OO-DFD transaction (Object-Oriented DFD is a variant of DFD that includes data classes rather than ''traditional'' data stores). Each of these modeling methods consists of diagrams accompanied with narrative, semi-structured descriptions explaining their details. We conducted a controlled experiment that compared the comprehension of the two models (i.e., the diagrams and their descriptions) of a certain system and the quality of models created for a certain system with each of the two modeling methods. The main results of the experiment are that models created with the UC method are of better quality than models created with the OO-DFD transaction method because the former are simpler and less detailed; creating highly detailed models are error prone. Interestingly, in spite of the difference in the level of detail and structure, the experiment reveals no significant difference in comprehension of models of the two methods. The results call for improvement of the modeling methods in a way that considers the advantages of each of them, and thus we propose an improved method sketch that we call Enhanced Use Case, which will be evaluated in future work.

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.

Users' requirements of an information system are modeled in the analysis phase of the development process. The requirements can be modeled with various modeling methods. In this study, we compare two alternative methods for modeling the functional requirements: one is the UML Use Case (UC) model; the other is OO-DFD transaction (Object-Oriented DFD is a variant of DFD that includes data classes rather than ''traditional'' data stores). Each of these modeling methods consists of diagrams accompanied with narrative, semi-structured descriptions explaining their details. We conducted a controlled experiment that compared the comprehension of the two models (i.e., the diagrams and their descriptions) of a certain system and the quality of models created for a certain system with each of the two modeling methods. The main results of the experiment are that models created with the UC method are of better quality than models created with the OO-DFD transaction method because the former are simpler and less detailed; creating highly detailed models are error prone. Interestingly, in spite of the difference in the level of detail and structure, the experiment reveals no significant difference in comprehension of models of the two methods. The results call for improvement of the modeling methods in a way that considers the advantages of each of them, and thus we propose an improved method sketch that we call Enhanced Use Case, which will be evaluated in future work.

Abstract. In most UML-based methodologies, the analysis tasks include mainly modeling the functional requirements using use cases, and modeling the problem domain using a class diagram. Different methodologies prescribe different orders of carrying out these tasks, and there is no commonly agreed order for performing them. In order to find out whether the order of these analysis activities makes any difference, and which order leads to better results, we carried out a comparative experiment. Subjects were asked to create the two ...

A guiding premise of academic scholarship is that knowledge gained from first-hand research experience is disseminated to students via the classroom. However, that valuable connection is lost when professors are not researching what they teach. In this paper, we explore issues of mismatch between teaching and research in the Information Systems (IS) discipline. Specifically, while systems analysis and design (SA&D) is an integral topic in IS curricula, this topic is the research specialty of few IS professors. This situation is reflected by the low number of research publications in this area; particularly in the leading mainstream IS journals. We characterize the gap between teaching and research in SA&D, offer possible explanations for this gap, suggest avenues to better understand and enhance SA&D research via the design science paradigm, list a number of areas in SA&D in which there is ample need and opportunity for high quality research, and show through an example how a research mindset can be incorporated in a graduate level SA&D course.

Assignment 2: Use Cases 2 ATM transactions are probably one of the most frequent transactions taking place throughout the world. Probably second only to debit card purchases. With new technologies coming into use, like being able to deposit a check using your phone, ATM transactions will probably decrease but will still be a major player for a very long time. As an intern software developer for a retail bank, I have been asked to develop several use cases to support the ATM

The main aim of this article is to discuss how the functional and the object-oriented views can be inter-played to represent the various modeling perspectives of embedded systems. We discuss whether the object-oriented modeling paradigm, the predominant one to develop software at the present time, is also adequate for modeling embedded software and how it can be used with the functional paradigm. More specifically, we present how the main modeling tool of the traditional structured methods, data flow diagrams, can be integrated in an object-oriented development strategy based on the unified modeling language. The rationale behind the approach is that both views are important for modeling purposes in embedded systems environments, and thus a combined and integrated model is not only useful, but also fundamental for developing complex systems. The approach was integrated in a model-driven engineering process, where tool support for the models used was provided. In addition, model transformations have been specified and implemented to automate the process. We exemplify the approach with an IPv6 router case study.

The task of this final report is to create the use case model of ‘rice cooker’ use this following requirement:
1. Describe the analysis model of the rice cooker with timer.
2. The rice cooker finishes cooking at the time specified by the timer.
3. The rice cooker can start cooking immediately if the user want to do so.
4. The rice cooker has a buzzer to tell completion of cooking.
5. The rice cooker can keep the rice warm after cooking.
6. The user can stop heating of the cooked.
The task includes:
• Use case diagram.
• Use case description.
• Class diagram.
• Communication diagram.
• State machine diagram.
• Explanation of the diagram.

The Data Flow Diagram (DFD) is a graphical representation of the flow of data through an information system. It enables you to represent the processes in your information system from the viewpoint of data. The DFD lets you visualize how the system operates, what the system accomplishes and how it will be implemented, when it is refined with further specification.

Abstract The software analysis process consists of two main activities: data modeling and functional modeling. While traditional development methodologies usually emphasize functional modeling via dataflow diagrams (DFDs), object-oriented (OO) methodologies emphasize data modeling via class diagrams. UML includes techniques for both data and functional modeling which are used in different methodologies in different ways and orders. This article is concerned with the ordering of modeling activities in the analysis stage.

The tutorial will provide an overview of FOOM methodology, which integrates the functional and object-oriented approaches. It will start with a rationale and need for the integrated approach, in light of the traditional methodologies on one hand, and the object-oriented and UML-based methodologies on the other hand. The main part of the tutorial will be devoted to a description of the analysis and design stages and sub-stages of FOOM, and their products. The description will be accompanied by a running example.

A method for designing the class methods of an information system is described. The method is part of FOOM–Functional and Object-Oriented Methodology. In the analysis phase of FOOM, two models defining the users' requirements are created: a conceptual data model–an initial class diagram; and a functional model–hierarchical OO-DFDs (object-oriented dataflow diagrams). Based on these models, a well-defined process of methods design is applied.

Abstract We propose FOOM (Functional and Object-Oriented Methodology), an integrated methodology for information systems analysis and design, which combines two essential software-engineering paradigms: the functional/data approach (or process-oriented) and the object-oriented (OO) approach. System analysis phase, where user requirements are set and defined, includes functional analysis and data modeling activities.

ABSTRACT In this paper, we describe a teaching approach that evolved from our experience teaching in both the traditional database and systems analysis classes as well as a number of semesters spent team-teaching an object-oriented systems development course. Fundamentally, we argue that existing knowledge of structured systems development can and should inform our teaching processes when teaching object-oriented systems development techniques.

Abstract In the analysis phase of the information system development (ISD), the users' requirements are studied and defined. In most ISD methodologies, the requirements are defined by two models: a conceptual data model in form of eg an entity-relationship (ER) diagram or a class diagram; and a functional model in form of eg data flow diagrams (DFD) or use cases. Different ISD methodologies prescribe different orders of carrying out these modeling activities but there is no commonly agreed order for performing them.

Abstract. In most UML-based methodologies, the analysis tasks include mainly modeling the functional requirements using use cases, and modeling the problem domain using a class diagram. Different methodologies prescribe different orders of carrying out these tasks, and there is no commonly agreed order for performing them. In order to find out whether the order of these analysis activities makes any difference, and which order leads to better results, we carried out a comparative experiment.

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).

Users' requirements of an information system are modeled in the analysis phase of the development process. The requirements can be modeled with various modeling methods. In this study we compare two alternative methods for modeling the functional requirements: one is the UML Use Case (UC) model; the other is OO-DFD transactions (Object-Oriented DFD is a variant of DFD that includes data classes rather than "traditional" data stores). Each of these modeling methods consists of diagrams accompanied with narrative, semi-structured descriptions explaining their details. We conducted a controlled experiment that compared the comprehension of the two models (i.e., the diagrams and their descriptions) of a certain system, and the quality of models created for a certain system with each of the two modeling methods. The main results of the experiment are that models created with the UC method are of better quality than models created with the OO-DFD transactions method because the former are simpler and less detailed; creating highly-detailed models are error-prone. Interestingly, in spite of the difference in the level of detail and structure, the experiment reveals no significant difference in comprehension of models of the two methods. The results call for improvement of the modeling methods in a way that considers the advantages of each of them; and thus we propose an improved method sketch that we call Enhanced Use Case (EUC), which will be evaluated in future work.

Functional and Object Oriented Analysis and Design: An Integrated Methodology teaches students of information systems, software engineering, computer science, and related areas how to analyze and design information systems using the FOOM methodology. FOOM combines the object-oriented approach and the functional (process-oriented) approach. It makes a clear distinction between the analysis and design phases, and enables a smooth transition from the former to the latter.
The FOOM methodology is very well structured, providing step-by-step guidelines on what to do and how to do each of the analysis and design activities. Many examples make the learning and utilization of the methodology easy.

Table of Contents:
Section I: The Objects Model and Class Diagrams
Chapter I: Introduction to the Objects Approach in Software
Chapter II: The Objects Model and the Class Diagram
Chapter III: Creating Class Diagrams
Chapter IV: Mapping Entity Relationship Diagrams to Class Diagrams
Chapter V: Mapping Class Diagrams to Relational Schemas
Section II: Functional and Object Oriented Analysis
Chapter VI: Object-Oriented Methodologies and the UML
Chapter VII: Combining the Functional and OO Approaches - Intro. to FOOM
Chapter VIII: Information Systems Analysis with FOOM
Chapter IX: Data Dictionary
Section III: Information Systems Design with FOOM
Chapter X: Transactions and Their Top-Level Design
Chapter XI: Design of the Man-Machine Interface: Menus, Inputs, and Outputs
Chapter XII: Detailed Design of Transactions and Class Methods

In the analysis phase of the information system development, the user requirements are studied, and analysis models are created. In most UML-based methodologies, the analysis activities include mainly modeling the problem domain using a class diagram, and modeling the user/functional requirements using use cases. Different development methodologies prescribe different orders of carrying out these activities, but there is no commonly agreed order for performing them. In order to find out whether the order of analysis activities makes any difference, and which order leads to better results, a comparative controlled experiment was carried out in a laboratory environment. The subjects were asked to create two analysis models of a given system while working in two opposite orders. The main results of the experiment are that the class diagrams are of better quality when created as the first modeling task, and that analysts prefer starting the analysis by creating class diagrams first.

FOOM (Functional and Object-Oriented Methodology) is an integrated methodology for information systems analysis and design, which combines two essential software-engineering paradigms: the functional/data approach (or process-oriented) and the object-oriented (OO) approach. System analysis phase, where user requirements are set and defined, includes functional analysis and data modeling activities. This phase produces a hierarchy of data flow diagrams (DFD) and an initial OO schema, which can be created directly or from an entityrelationship diagram (ERD). The design phase is performed according to the OO approach, producing a complete OO schema and a behavior schema. The seamless transition from analysis to design is enabled thanks to ADISSA methodology, which facilitates the design of the menus, forms and reports classes, and the system behavior schema, from the DFDs and the application transactions. The paper introduces the motivation for the combined approach,outlines the methodology, and presents an example that demonstrates it.

The software analysis process consists of two main activities: data modeling and functional modeling. While traditional development methodologies usually emphasize functional modeling via dataflow diagrams (DFDs), object-oriented (OO) methodologies emphasize data modeling via class diagrams. UML includes techniques for both data and functional modeling which are used in different methodologies in different ways and orders. This article is concerned with the ordering of modeling activities in the analysis stage. The main issue we address is whether it is better to create a functional model first and then a data model, or vice versa. We conduct a comparative experiment in which the two opposing orders are examined. We use the FOOM methodology as a platform for the experiment as it enables the creation of both a data model (a class diagram) and a functional model (hierarchical OO-DFDs), which are synchronized. The results of the experiment show that an analysis process that begins with data modeling provides better specifications than one that begins with functional modeling.