Logical Modeling in
Systems Analysis

Table of Contents

Topic Page

Chapter One
Abstract . . . . . . . . . . . . . . . . . . . 3

Chapter Two
Introduction . . . . . . . . . . . . . . . . . . 4
Information Systems . . . . . . . . . . . . . . . 5
IS Analysis Phase . . . . . . . . . . . . . . . . 5
Modeling Definition and Concepts. . . . . . . . . 5
Traditional Approach Logical Models . . . . . . . . 7
Object Oriented Approach Logical Models . . . . . . 9

Chapter Three
Current Topics in Data Modeling . . . . . . . . . . . 12

Bibliography . . . . . . . . . . . . . . . . . . 14

CHAPTER ONE

Abstract

Today’s organizations are utilizing their core competencies while exploiting the core competencies of subcontractors to produce highly differentiated and high quality products at a lower cost. Business process reengineering has played a key role in remaining competitive, enabled through information technology. Existence of the automated information system, developed through Systems Analysis and Design, has become a requirement for survival of today’s companies. Process requirements are identified during the analysis phase and documented through logical modeling. A model is an abstraction that represents some aspect of an IS system to be built and may be high level or low level and include system components and their interactions. Modeling is performed by the systems analyst since it aids in identifying requirements and simplifies the many different views of a new complex system. Models are also an excellent communications tool and they provide documentation for manuals, maintenance, and upgrades. The three types of IS models are mathematical, descriptive, and graphical. Logical models identify new system requirements without committing to specific information technologies. The two general approaches in producing sets of models include the traditional and object oriented. The traditional approach treats the system as

a collection of processes. The entity relationship diagram models data through entities, attributes, and relationships of ISA, aggregation, and cardinality. The dataflow diagram consists of processes, datastores, dataflows, and external entities. The context diagram is the highest-level dataflow diagram. Additional models may be developed using the information engineering approach, a subapproach of the traditional, emphasizing strategic planning and data modeling. In the object-oriented approach, the system is defined as a collection of interacting objects that communicate through message exchange. The class diagram is the equivalent of the entity relationship diagram but also shows logical methods in addition to entities and attributes. The use case diagram is similar to the traditional dataflow diagram, presenting the system overview and defining the scope, while also showing dependency between use cases. The sequence and collaboration diagrams both involve objects that interact through events to support a specific use case. The sequence diagram focuses on messages between objects while the collaboration diagram focuses on a higher level involving the objects. The statechart diagram shows the life cycle of an individual object while providing the individual logic or methods used by the object. Current topics in data modeling included a review of two diagramming tools for the ERD - PowerDesigner and Visio 2000 software. Each tool was similar in concept and notation, though some difference did exist. The author summarized features to look for in a diagramming tool and recommended beginning with a simple software package, eventually purchasing a more complex one. A second current topic reviewed different ERD methodologies and notation including Chen, Information Engineering, and IDEF.

CHAPTER TWO

Introduction

Today’s organizational strategy is to adopt the flexible manufacturing model resulting in extensive use of independently owned suppliers and subcontractors. Organizations are identifying their core competency, what they do best, while exploiting the core competencies of suppliers through subcontracting. Mass production has been replaced by the needs to provide global products and services, while innovating and quickly bringing to market slightly differentiated, high quality products through flexible manufacturing systems. Management of these systems involves coordination. In fact, the organization’s survival depends upon it. This management is accomplished through vision, architecture, strategic and operational planning, and daily management. Specifically, information systems have been an enabler for this reengineering.
Advances in information technology has helped to create an environment more suitable to competitive markets. In today’s competitive environment, organizational automated information systems are becoming less of an option and more of a requirement. On the average, an organizational information system becomes obsolete within three to five years, requiring either upgrades or additions to maintain the current system or development of new information systems. This is completed through Systems Analysis and Design. Business process requirements for a new or upgraded system are identified within the analysis phase of Systems Analysis and Design. The main output from this phase is a series of models, each showing a different view of the new or upgraded system and serving as input into the next phase of design.

Information Systems

By definition, an information system is a collection of interrelated components that function together to achieve some outcome. Information systems today usually consist of automated business processes that solve problems. Examples of operational and strategic systems within an organization are transaction processing systems, management information systems, executive information systems, decision support systems, and communication support systems. The planning, analysis, and design phases of these systems are performed primarily by systems analysts, applications specialists, and internal decision-makers.

IS Analysis Phase

Upon initial project approval by a decision makers committee, the IS analysis phase is initiated. The major activities within this phase are (1) gathering information on the current and new system requirements; (2) defining the new system requirements; (3) prioritizing requirements and determining levels of automation; (4) prototyping for feasibility and discovery; and (5) generation and evaluation of alternatives. The output from defining new system requirements specifically is a series of mathematical, descriptive, and graphical models.
Modeling Definition and Concepts
By definition, a model is an abstraction that represents some aspect of an IS system to be built. The model scope may be high-level general overview or low level specific. In addition, the model may represent different components of an information system - for example, processes, data, people, inputs, and/or outputs. Models may also show interaction between these and other components. The main purposes of modeling by the systems analyst include the following: (1) Modeling is useful in better defining the problem and proposing a solution through process requirements; (2) Modeling breaks down the new system into manageable views since information systems can be very complex; (3) Modeling serves as an excellent communications tools with decision-makers, other analysts, and end-users and; (4) Modeling provides documentation for system manuals and future maintenance and upgrades. Modeling includes not only graphical, but also mathematical and descriptive models. By definition, a mathematical model is a series of formulas that describe technical aspects of a system. An example of this might be a finance function interest calculation. Descriptive models, by definition, include narrative memos, reports, or lists that describe some aspect of the new system. An example might be a summary of user interviews or questionnaires during information gathering. Graphical models, by definition, are diagrams and schematic representations of some aspect of a system. Many different examples exist, including process and data diagrams. It is important to differentiate between logical models and physical models in our discussion of documenting new system requirements. Logical models, sometimes referred to as “what” models, document system requirements – what is required without committing to any specific technologies. The logical models become the input into the design phase of systems analysis and design. During the design phase, the “how” of the new system is identified – meaning how the process requirements will be met through application of specific information technologies. Our discussion here will focus on logical models created from two different systems development approaches – the traditional approach and object-oriented approach.

Traditional Approach Logical Models
In the traditional approach to modeling, the system is defined as a collection of processes. These processes interact with data entities, accept inputs, and produce outputs. In summary, the traditional view is mainly process-oriented with some data modeling. Note that a third methodology serves as a component of the traditional approach, known as information engineering, which specifically focuses on strategic planning and data modeling. Traditional approach logical models include the following:

Entity Relationship Diagram

Our CIS512 course Data Modeling text defines data modeling in Chapter One as the process of modeling and formalizing data requirements with a conceptual modeling tool. The author further notes that the primary tool used in conceptual data modeling is the entity relationship diagram (ERD). More specifically, a conceptual database design includes completion of the ERD. Logical database design includes schema mapping, the conversion of the ERD into the logical data model - the tables, attributes, and relationships that comprise relational databases. In the ERD (CIS512 Data Modeling text, Chapter Two), box symbols represent data entities, while attributes may be shown as connected to them. Relationships between entities and attributes or entities and other entities are referred to as aggregations. Other relationships between entities include ISA (inheritance) and association. Cardinality also describes relationships between entities and is described as the maximum number of records in one file that are linked to a single record in another file and visa versa. In the conversion from conceptual to logical data models (CIS512 Data Modeling text, Chapter 3), the Optimal-Max method may be employed to achieve database normalization and specifically, minimization of nulls.
Generally, the mentioned entities become tables, the attributes are the columns within each table. The cardinality relationships are achieved through the use of unique primary keys that link related tables together.
Context Diagram and Data Flow Diagrams
A context diagram is a highest-level data-flow diagram. The entire system is viewed as one process with external entities and data inputs and outputs diagrammed. The context diagram is useful for defining system scope – the boundaries of the system. Data flow diagrams are simply lower level decomposed views of the context diagram. Generally, the data flow diagram shows how people and processes convert data into information. Labeled arrows depict data flows between processes and data stores. (Note that data stores are the equivalent of entities in the ERD). Further decomposition of data flow diagrams continue until either decomposition is no longer required or subprocesses can no longer be decomposed. At that point, the simplest specific tasks may be modeled through structured English and/or decision tables or trees.
Data Flow and Element Definitions
A data flow definition is a textual description of a data flow’s contents – the individual data elements and the internal structure. The individual data elements from each data flow are synonymous with attributes belonging to entities in the ERD. Data element definitions describe the element format and restrictions - for example data type, description, maximum character length, numeric range, etc.
Information Engineering Models
As mentioned, the information engineering approach focuses on strategic planning and data requirements of a system. Systems analysts often combine information engineering models with the previously described structured models for additional new system views. Information Engineering models include the following: (1) Process decomposition diagram - this model represents the hierarchical relationship among processes at different levels of abstraction – essentially decomposed DFDs, but all appearing on one diagram; (2) Process dependency diagram - this model describes the ordering of processes and their interaction with stored entities. Similar to a DFD, but shows dependency of processes among each other; (3) Location Diagram - a diagram or map that identifies all of the processing locations of a system. This is more physical than logical, but very useful to the systems analyst during the analysis phase; (4) Activity-Location matrix - a table that describes the relationship between processes and the locations in which they are performed; (5) Activity-Data matrix - a table that describes stored data entities, the locations from which they are accessed, and the nature of the accesses; and (6) Workflow diagram - this diagram shows the flow of control through a processing activity as it moves among people, organizations, computer programs, and specific processing steps.

Object Oriented Approach Logical Models

In the object-oriented approach to modeling, the system is defined as a collection of interacting objects that react with people and each other. The objects send and respond to messages.
Class Diagram
The class diagram is the equivalent of the ERD developed for the traditional approach and is also similar in symbols and conveyed information. The class diagram specifically shows hierarchies of superclasses, classes, and subclasses, depicts class name, attributes, but also methods. Aggregation between class objects is shown by arrows and a diamond symbol. A triangle shows inheritance (Note that our CIS512 Data Modeling text also shows a triangle shape for inheritance on the ERD). Cardinality is shown on the class diagram through a “*” symbol (meaning many) and numbers (0,1, etc). For example, “0..*” means zero to many. In summary, the main difference between the ERD and class diagram is that the class diagram shows behavior as well as attributes. While the class diagram by itself identifies the system objects, the remaining OO diagrams describe the behavior or actions of these objects.
Use Case Diagram
A use case diagram is a functional one similar in some ways to the traditional DFD. The process fragments from the DFD become “use cases” within the use case diagram. The objectives of a use case diagram are to present a system overview and define the system scope. A system boundary is identified and “actors” outside the boundary participate in these use cases, replacing the external entities of the DFD. Within each use case exists a scenario – a particular sequence of activities. Dependency between use cases is also shown on the use case diagram through “>” placed between use cases.
Sequence Diagram
A sequence diagram involves objects that interact through events to support one specific use case. In other words, it relates objects defined in each use cases. The four symbols used on a sequence diagram are (1) the previously mentioned actor, depicted by a stick figure; (2) the object symbol, represented by a rectangle with object name in center underlined; (3) a lifeline symbol, represented by a dashed line or narrow vertical rectangle (a lifeline shows the passage of time for the object); and a message symbol consisting of a directional arrow and message descriptor.
Collaboration Diagram
The collaboration diagram basically shows the same information as the sequence diagram, but the focus is on a higher level emphasizing the objects rather than the messages. The symbols are identical to those used with the sequence diagram, with the exception of the lifeline symbol. A new symbol, the link, appears on the collaboration diagram. A link, by definition, is a relationship between two objects rather than between object classes.
Statechart Diagram
The statechart diagram explains the internal logic, methods, or behavior for each object of the system and is constructed primarily from the class diagram and sequence diagram. Specifically, the statechart shows state changes within an object’s lifecycle. The two main symbols in the statechart diagram are the state symbol, a rectangle with rounded corners, and transition symbol, an arrow to show transition between the states. Objects may exhibit concurrency, meaning being in more than one state at a time or be a composite, a higher-level state that has other states nested within it. The action-expression, a statement placed over the transition arrow to describe the action to be performed, is also an important component of the statechart, as it will become the behavioral methods for the programmer during code development.

CHAPTER THREE

Current Topics in Data Modeling

Entity Relationship Diagrams in RDBMSs: Steve Franklin, author for Webreview.com (“Planning your Site with Entity Relationship Diagrams”, July 20, 2001) discussed application of the ERD as a tool for development, management, and changes of web accessible RDBMSs. Diagramming tools used for the article were PowerDesigner and Visio 2000 software. For data modeling of larger database sites, the author recommends use of CASE tools, diagrams, and a central repository, while the ASCII SQL approach may be optimal for smaller projects. In choosing a data modeling tool, the main challenges are learning modeling notation, capture of data into the data model, and finding a tool that is compatible with the database. For ERD notation, the author adopted Martin’s Information Engineering notation (used in PowerDesigner software and also Oracle’s Designer product). Each of the tools reviewed by the author had different methods for entry, but the ERD concepts generally remained the same. Data modeling tools will allow specification of table properties (descriptions, titles, columns, formats, primary keys, index, etc.) and provide reverse engineering through automatic update of the ERD. Important information to capture for table relationships includes parent and child, mandatory relationships, cardinality, and notes or comments. In both PowerDesigner and Visio, diagrams show table relationships using similar notation. The author also emphasizes the importance of planning the diagrams for readability. For example, children entities should be to the right or below the parent entities, minimal line crossing should exist, and the most significant tables should appear in the upper left corner of the diagram with tables of decreasing significance appearing to the right and bottom of the diagram. The author concludes by pointing out tools that can generate SQL code directly for the database are extremely convenient and recommends starting small with simple data modeling tools, eventually working toward more complex applications.
Data Modeling Methodologies and Notation: Duncan Dwelle, in his Modeling Methodologies article from Applied Information Science, August 17, 2000, reviews the various forms of symbolic notations in data modeling. One of the earliest models was Chen’s ER model, which was simple in shapes and lines, but offered much information in a diagram. Dwelle notes that “Chen allowed relationships to have attributes of their own, thus making them look a lot like entities and giving rise to heated debate over just what is an entity versus a relationship”. The author supports this statement with quotes from other well-known data modelers, specifically quoting from modeler Date, “the ER approach is seriously flawed because the very same object can quite legitimately be regarded as an entity by some users and a relationship by others”. James Martin’s Information Engineering refines data modeling by discarding the complex relationship. Each relationship is either binary (or possibly unary). An additional common technique for modeling is referred to as IDEF, developed in the late 70’s and early 80’s. This method, though semantically weaker, is thought to be easily learned and workable. The author mentions that while early data modeling practice was to use a bottom-up approach beginning with lower level specifics, currently applied methodologies, like those mentioned use a top-down entity based approach, first beginning with entities at a higher-level and then moving into the specifics.

Bibliography

Brown, C.V., DeHayes, D. W. Managing Information Technology, Upper Saddle River, New Jersey: Prentice Hall, 1999.

Dwelling, D. “Modeling Methodologies”, Applied Information Science, August 17, 2000. http://www.aisintl.com/case/method.html

Franklin, S. “Planning Your Site With Entity Relationship Diagrams”, WebReview.com, July 20, 2001. http://webreview.com/2001/07_20/developers/index01.shtml

Lawrence Sanders, G. Data Modeling, Danvers, Massachusetts: boyd & fraser, 1995.

Satzinger, J.W., Jackson, R.B., Burd, S.D. Systems Analysis and Design in a Changing World, Cambridge, and Massachusetts: Course Technology, 2000.