Information Systems Analysis with FOOM

This chapter elaborates on the activities and products of the analysis stage with functional and object oriented methodology (FOOM). The products of this stage include a data/objects model in the form of an initial class diagram, and a functional model in the form of hierarchical object oriented Data flow diagram (OO-DFDs). The two diagram types are synchronized in order to guarantee the correctness and completeness of the two models. The chapter presents various examples of diagrams of both types.

Creating Class Diagrams

This chapter discusses considerations and rules for identifying classes, attributes, relationships, and functions; and presents case study examples (problems), that is, descriptions of users’ data requirements; along with their class diagram solutions.

The Objects Model and the Class Diagram

The objects model (or object oriented [OO] model) is a conceptual-application model that is used to define a database schema representing a certain reality. The model views the world as consisting of objects belonging to classes. The objects of these classes have attributes, behavior (i.e., functions), and various relationships with other objects. The objects model can be presented as a class diagram (also termed OO diagram or objects diagram). Like an entity relationship diagram (ERD), the class diagram has two main goals: 1. To serve as a communication medium between the developers (analysts/ designers) and the users or their representatives. The diagram is created as a result of the interactions between the two parties, during which they discover and define the users’ information needs; the diagram serves like a contract between these two sides which summarizes the users’ needs. 2. To be the basis for further development of the information system (IS). Based on the diagram, it should be possible to design the database schema of the application, and (partially) the functions that it will have to perform. For that, it is necessary to transform the class diagram into an equivalent verbal description—an objects schema. This is done using an object definition language (ODL), similar to data definition language (DDL) in the relational model. In principle, all components of the class diagram are mapped to the objects schema. However, the objects schema includes more details which are not included in the diagram. For example, in the diagram each attribute has a name, and some attributes may have specific constraint definitions (e.g., key, unique); in the objects schema there are more detailed definitions, including the attributes’ domains or data types (e.g., numeric, char., real, etc.) and lengths. Another example, in the class diagram, we only write the names of the classes’ functions, while in the objects schema we specify the parameters of the functions. As aforementioned, there is a great deal of similarity between the OO and ER models and diagrams, since the ER model is one of the sources from which the objects model originated. But there are differences between the two models, which we will review later on. One of these differences is that the ER model is “static,” that is, it only deals with the data structure, while the objects model also includes “behavior,” that is, the functions that operate on the data. The rest of this chapter is dedicated to describing the components of the objects model and the class diagram. The description is organized in four main categories: objects and classes, attributes, relationships, and functions.

Introduction to the Objects Approach in Software

The term “object oriented” spread in the last decade and a half, throughout many fields of computing, including the analysis and design of information systems (IS). The use of the OO approach began in the early 1970s in fields such as computers architecture, operating systems, and artificial intelligence. But the main field to which the approach penetrated was programming languages, beginning with Simula and then with Smalltalk. Some years passed by until the approach became popular in the programming field. Reasons for the vigorous penetration of the approach include the emergence of the windows-based graphical interfaces technology, the desire to economize development costs by reusing existing software, and the transition from centralized computing to distributed- and Internet-based computing. As aforesaid, the approach penetrated into other fields of computing due to its success in the field of programming, including the field of analysis and design of IS.

Detailed Design of the Transactions and Class Methods

This chapter describes how to map a top-level description of a transaction into a detailed description, and then how to “decompose” a detailed description of a transaction into various methods which are then attached to proper classes. Two equivalent techniques for describing methods are provided: pseudo code and message charts. The chapter ends with a review on the products of the design phase, which serve as input to the system construction (programming) phase.

Transactions and TheirTop-Level Design

This chapter starts with an overview of the design phase according to the functional and object oriented methodology (FOOM) and presents the subphases and their products. Then, the chapter focuses on the design of transactions. First it describes what transactions are and how they can be identified and extracted from the object oriented data flow diagrams (OO-DFD). Afterwards, it explains how to map transaction diagrams to top-level descriptions, which detail their components and process logic. The transactions’ top-level descriptions will eventually become detailed descriptions of respective class methods. The chapter ends with additions to the data dictionary (DD) the class diagram due to the definition of the transactions.

Data Dictionary

This chapter explains the roles of a data dictionary (DD) in the development of the information system (IS) and describes its components. The chapter presents a possible implementation of the data dictionary both with the relational and the object oriented (OO) models. A DD is a database or repository of data on the products of the analysis and design phases. It is initially created during the analysis phase, containing details about the components of the object oriented data flow diagram (OO-DFD) and the data elements carried by their various dataflows. But it will be updated and extended throughout the design phase to include details about the products of that phase too. The DD is essential in the development of large-scale systems because it enables its users (analysts and designers) to define, save, and retrieve, in a standard manner, various details of the analysis and design products, details which are not included in those products. A DD can be implemented as a relational database consisting of tables, or as an OO database consisting of object classes. This chapter describes the components of a DD using both models. Obviously, at this stage we only describe the components which are created at the analysis phase.

Combining the Functional and Object Oriented Approaches

This chapter starts with a brief discussion on approaches to system development methodologies and the motivation for the development of the integrated methodology FOOM. Then it presents the stages and products of FOOM.

Object Oriented Methodologies and the UMI

This chapter reviews the evolution of object oriented (OO) methodologies and unified modeling language (UML). Most of the chapter is dedicated to presenting and demonstrating the various techniques and diagrams which make up UML, and then it provides a detailed example of information system (IS) modeling using a UML-based methodology.

Mapping Class Diagrams to Relational Schemas

This chapter first explains the need to map a class diagram to a relational schema. Then, most of the chapter is dedicated to presenting and demonstrating the mapping rules based on which a relational schema (made of normalized relations) is created. The mapping process is demonstrated with several comprehensive examples.