CCT102: Object Oriented Analysis & Design

May 2009

 2009 by International Division Informatics International Pte Ltd A Member of Informatics Group

Informatics Campus 12 Science Centre Road Singapore 609080

Object Oriented Analysis & Design Study Guide

First Printing May2009

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted by any form or means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of the publisher.

Every precaution has been taken by the publisher and author(s) in the preparation of this book. The publisher offers no warranties or representations, and does not accept any liabilities with respect to the use of any information or examples contained herein.

All brand names and company names mentioned in this book are protected by their respective trademarks and are hereby acknowledged.

The developer is wholly responsible for the contents, errors and omission.

Published by Informatics Education Ltd

Table of Contents

CHAPTER 1: INFORMATION SYSTEMS ...................................................................................................... 3 1.1 1.2 1.3 1.5 1.6 INTRODUCTION ..................................................................................................................................... 1 INFORMATION SYSTEM ......................................................................................................................... 1 STRATEGIES FOR SUCCESS ................................................................................................................... 7 PROJECT LIFECYCLES ......................................................................................................................... 11 EXERCISE QUESTIONS ........................................................................................................................ 14

CHAPTER 2: OBJECT-ORIENTATION AND MODELING CONCEPTS................................................ 15 2.1 2.2 2.2 2.3 2.4 2.5 INTRODUCTION ................................................................................................................................... 16 WHAT IS OBJECT-ORIENTATED?..................................................................................................... 16 OBJECT-ORIENTATION CONCEPTS ...................................................................................................... 17 MODELLING CONCEPTS ...................................................................................................................... 23 OBJECT-ORIENTED METHODOLOGY ................................................................................................... 27 EXERCISE QUESTIONS ........................................................................................................................ 31

CHAPTER 3: REQUIREMENTS MODELING PART I............................................................................ 32 3.1 INTRODUCTION ................................................................................................................................... 33 3.2 USER REQUIREMENTS ........................................................................................................................ 33 3.3 FACT-FINDING TECHNIQUES .............................................................................................................. 36 3.4 USER INVOLVEMENT .......................................................................................................................... 41 3.5 DOCUMENTING REQUIREMENTS ......................................................................................................... 41 3.6 USE CASES ......................................................................................................................................... 42 3.7 EXERCISE QUESTIONS ................................................................................................................................. 46 CHAPTER 4: REQUIREMENTS MODELING PART II .......................................................................... 47 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 INTRODUCTION ................................................................................................................................... 48 CLASS DIAGRAM ................................................................................................................................ 48 IDENTIFYING CLASSES, ATTRIBUTES, METHODS ................................................................................ 49 MULTIPLICITY / CARDINALITY ........................................................................................................... 52 ADDING ASSOCIATION ....................................................................................................................... 52 ADDING AGGREGATION AND COMPOSITION ....................................................................................... 53 INHERITANCE ..................................................................................................................................... 54 ABSTRACT CLASSES ........................................................................................................................... 55 CLASS RESPONSIBILITY COLLABORATION (CRC) CARDS .................................................................. 56 EXERCISE QUESTIONS ........................................................................................................................ 57

CHAPTER 5: OBJECT INTERACTION ........................................................................................................ 58 5.1 5.2 5.3 INTRODUCTION ................................................................................................................................... 59 OBJECT INTERACTION AND COLLABORATION ..................................................................................... 60 EXERCISES ......................................................................................................................................... 67

i|Page

CHAPTER 6: SPECIFYING OPERATIONS AND CONTROL ................................................................... 68 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 INTRODUCTION ................................................................................................................................... 69 OPERATION SPECIFICATION ................................................................................................................ 69 CONTRACTS ....................................................................................................................................... 70 DESCRIBING LOGIC OF THE OPERATION ............................................................................................. 71 SPECIFYING CONTROL ........................................................................................................................ 72 STATES AND EVENTS .......................................................................................................................... 72 STATE MACHINE ................................................................................................................................ 74 PREPARING A STATE MACHINE .......................................................................................................... 75 EXERCISE QUESTIONS ........................................................................................................................ 76

CHAPTER 7: SYSTEM ARCHITECTURE.................................................................................................... 77 7.1 7.2 7.3 7.4 INTRODUCTION ................................................................................................................................... 78 ARCHITECTURE .................................................................................................................................. 78 ARCHITECTURAL STYLES ................................................................................................................... 81 EXERCISE QUESTIONS ........................................................................................................................ 84

CHAPTER 8: SYSTEM DESIGN AND DESIGN PATTERNS..................................................................... 85 8.1 8.2 8.3 8.4 8.5 8.6 8.7 INTRODUCTION ................................................................................................................................... 86 ANALYSIS VS. DESIGN ........................................................................................................................ 87 DESIGN OF A SYSTEM ......................................................................................................................... 88 CHARACTERISTICS OF GOOD DESIGN .................................................................................................. 89 OBJECT-ORIENTED COHESION AND COUPLING................................................................................... 91 DESIGN PATTERNS ............................................................................................................................. 92 EXERCISE QUESTIONS ........................................................................................................................ 94

CHAPTER 9: HUMAN-COMPUTER INTERACTION AND DATA MANAGEMENT DESIGN ........... 95 9.1 9.2 9.3 9.4 9.5 9.6 9.7 INTRODUCTION ................................................................................................................................... 96 USER INTERFACE ................................................................................................................................ 96 APPROACHES TO USER INTERFACE DESIGN ........................................................................................ 97 PERSISTENCE ...................................................................................................................................... 99 FORMS OF PERSISTENCE ................................................................................................................... 100 OBJECT / RELATIONAL MAPPING...................................................................................................... 102 EXERCISE QUESTIONS ...................................................................................................................... 106

ii | P a g e

Chapter 1: Information Systems

Upon completion of the chapter, you would be able to understand:

System, Information and Information System Roles played by Information Systems in different types of organizations Strategies for successful implementation of Information Systems in an organizations Problems in Information System development Why Information System projects fail? About Iterative and waterfall lifecycles for developing a project Consequences of Business Structure on the Life Cycles

1.1

Introduction

Information system plays an important role with respect to both humans and business. In this chapter, system, information, information system and problems in information system development are discussed. The problems affecting the development of a computerized information system are also discussed followed by the discussion of various approaches (including the objectoriented approach) avoiding the problems to information system development.

1.2

Information System

1.2.1

System

Characteristics of a system A system exists in an environment from which it is separated by a boundary Systems have inputs and outputs and convert their inputs to outputs Systems have interfaces to allow communications with other systems A system may have subsystems Systems have control mechanism System control relies on feedback and feed-forward A system has evolving properties

1|Page

The diagram below shows these characteristics of a system:

Figure 1.1: Parts of a system, and their relationships to each other (adapted from Bennett et al., 3rd edition)

Boundary and environment The first step in understanding a system is to decide about its boundaries. The boundaries of different systems can overlap or coincide. Two systems may be closely related, may have identical boundaries, and yet still be different from each other. The end of one system and beginning of another system should be clearly defined. Also, there might be a subsystem or a system-component that may simultaneously be part of two or more systems.

Input, output, interface and transformation Systems interact with their environments. Each such interaction has some input and output. Inputs (originated outside a system) are processed by the system to generate outputs that act to accomplish a function of the system. There may not be one-to-one correspondence between inputs and outputs.

2|Page

System A student

Inputs Information Exercises Guidance

Outputs New knowledge New ideas Solutions New citizens (i.e., children) Products of family members work

A family

Money Social standards and norms

Purchases Daily news A business Raw materials and labour Investment Information orders) (e.g.,

Social influence Votes in elections Profit and taxes Finished products customer Information company report) (e.g., the

Figure 1.2: System Inputs and Outputs (adapted from Bennett et al., 3rd edition)

The information systems transform inputs to outputs to accomplish their objectives. In general, the systems and subsystems follow blackbox approach where the internal processing of the system / subsystem is hidden, only the inputs and outputs are visible. An output from one system can be an input to another. The two such systems are said to share part of their boundary, across which inputs and outputs pass between them. The shared boundary is defined as an interface. The users interact with the system using the interface. So, it is very important to identify the interfaces during the development of information systems. Subsystems A larger system is broken down into smaller subsystems. For examples, a business system can have Administration, Accounts, Sales etc. as its subsystems. Subsystems communicate with each other through interfaces. Systems and subsystems can be arranged as hierarchy.

3|Page

Control in systems A specialised subsystem acts as the controller of the operations of the system as a whole. Usually, control in systems is based on a comparison between two or more input values, based on which a decision about whether any controlling action is required or not, is taken. Feedback One or more outputs of the system are sampled and are fed back to the control unit of the system for comparing it with a reference value. Based on the outcome of the comparison, the control unit will amend the process of system to bring the difference between the two values within predefined limits.

Feed-forward Feed-forward information relies on sampling the systems inputs. Feed-forward control information helps a system to be quick to respond to environmental fluctuations. It will be difficult to make the changes if the environment changes at a rate faster than the rate at which the business can adapt it.

Emergent properties Emergent properties are the properties / features of the system that are possessed by the system only and not by any of its components. For example, a car is only a form of transport. It then has the property of being a vehicle, but the wheels, windscreen, motor, etc. do not have this property until they are correctly assembled (Bennett et al., 3rd
edition).

1.2.2 Information and Information Systems Important part of developing an information system is to understand about the technology that is to be used, to identify the ways how an information system can support the human activities, the information required by the information system and how the information can be used effectively. 4|Page

Information Information is conveyed by messages and has meaning that depends on the perception of the person who receives a message, i.e., information has a meaning within context. Raw facts (i.e., data) are transformed into useful information through a series of stages.

Information Systems There are various information systems in practice. For example, transaction processing system, management information system decision support system, executive support system are being described by Laudon and Laudon (2002) as some of the main types of information system in business. But todays information systems are more closely integrated with each other. Information systems play role in operational systems and management support systems in organizations.

Operational Systems Operational systems automate the routine, day-to-day record-keeping tasks in an organization. Example: Accounting Systems. The flow of information through an accounting system is based on thousands of similar transactions. Accounting Systems are typically called as Transaction Processing Systems. Other examples of operational systems are the systems that record orders received from customers, the number of items in stock, orders placed with suppliers, the numbers of hours worked by employees, time and cost of mobile telephone calls made by subscribers and so on.

Management Support Systems Information systems that support management typically work at a much higher level of complexity than operational systems. The information that is used by management is generally derived from information stored at operational level. Management support systems are built on top of operational systems. 5|Page

Management information system or MIS is a set of programs that are used to pull out data from existing operational systems, analyse and merge it to give managers more organizational information for their departments. Feedback and / or feed-forward is / are the crucial aspect(s) of a management support system providing , alerting managers to problems and opportunities, and accessing them in the process of fine-tuning the organizations performance.

Difference between operational Systems and Management Support Systems Operational systems state what the system does and management support systems handle the how the system is controlled part of a system. That is, operational systems support the flow of inputs or outputs, and management support systems support the flow of feedback to, or control information from the control unit.

Information Technology Decisions about information technology should be made last in the cycle of development. That is, the activities should be performed in the following order: Understand a human activity system Identify the need for an information system Define the information system requirements Decide about the information technology that will be used to implement the system

6|Page

1.3

Strategies for Success

The information systems are useful if they meet the requirements of the organization in which they are installed. So, first of all, identify the business issue or the problem that is to be solved with the information systems. Then start the information systems analysis and design process. The following three steps in the given order contribute to successful implementation of information systems in an organization: 1. Identifying a business strategy 2. The contribution of information systems 3. Information systems and information technology strategies

1.4

Problems in Information Systems Development

At the start of a project, many different routes are available that may lead to the planned destinations, or wrong destinations, or dead end that lead nowhere. It is the purpose of the analysis and design to filter out the alternatives that lead to wrong destinations or to dead ends. These tasks of analysis and design are carried out before starting to develop the new system. Analysis is a way of understanding what needs to be done and design is a way of checking out how it is to be done. Potential problems that may occur during information systems development, should also be identified/understood before starting the analysis and design.

1.4.1 What are the problems? Information systems development process involves many persons and teams (having important relationships to a project) who can be classified into three categories:

7|Page

1. End-users of the information systems, 2. Clients (i.e., the group of managers) who have control over the initiation, direction or progress of a project. 3. Group of professionals responsible for the development of the information system.

Problems from an end-users perspective Below are the problems that may be faced by end-users: The system is much talked about, but it is never released to the intended end-users. The system might work but is it easy to use? The system looks nice but does it do anything useful?

Problems from a clients perspective A client usually has authority over the approval of the project before it starts. Below are the problems that may be faced by this group: The price of development is more than the initial budget System delivery is too late as compared to the promised delivery dates The installation is too complicated and the support staff do not trust the system The system was not needed in the first place The requirements have changed and the system does not meet them.

8|Page

Problems from a developers perspective The developer acts as the supplier to the customer (i.e., client or end-user). Below are the problems that may be faced by this group: The system was built to meet the requirements indicated to the developers There was not enough time to do it any better The developers are developing using this software for the first time System was developed by another team and we do not know how to fix it The system is fine but the users are the problem

1.4.2 Causes of Information System Project Failure Project failures can be categorized into two types: Quality Problems Productivity Problems

Quality Problems Quality of a project / product is measured in terms of its fitness for purpose. To measure the quality of a software system, it is necessary to know the following: The purpose of the intended system How to measure its fitness

A few of the reasons for a project failure due to quality problems are as follows: Wrong problem is addressed Organization culture is ignored Requirements analysis, design and construction of the project are carried out incorrectly

Productivity Problems 9|Page

Productivity problems are related to the Progress of a project, and The resources used during its development

Following are the questions that are likely to be asked about the productivity of a project: Will the project be delivered? Will the project be delivered in time to be useful? Will the project be reasonably priced?

Reasons for a project failure due to productivity problems are as follows: Change of user requirements Change in environment due to external events Implementation is not viable Poor project management

10 | P a g e

1.5

Project Lifecycles

Strategic information systems planning and business modelling are the activities that are to be performed before starting an information systems development project. Strategic information systems planning Information systems work within an organizations environment. Information systems must satisfy the organizations current requirements as well as provide a basis to deal with the future needs. In order to do this, strategic plans are developed for the organization as a whole and within their perspective a strategic view of information systems is prepared. Business modelling Business modelling activity is performed to understand how a particular business activity is being performed and how it contributes to the objectives of the organization, thereby to determine how an information system can support the business activity.

11 | P a g e

1.5.1 Iterative Life Cycle vs. Waterfall Approach Waterfall Approach The following diagram depicts various stages in the project development using waterfall approach:

System engineering

Requirements Analysis

Design

Construction

Testing

Installation

Maintenance

Figure 1.3: Traditional waterfall lifecycle model

The stages in the waterfall approach are performed only once during the development of the system.

12 | P a g e

The model depicted above is the traditional model. There are few variations of this approach that may also be used for the software development. One example is the waterfall approach with the feedback loop.

Iterative Life Cycle Approach Iterative lifecycle approach can be seen as a variation of the waterfall approach where the analysis, design and implementation steps are performed iteratively in various development cycles. Both approaches can be used for developing a system but are valid and suitable for different circumstances. The iterative life cycle model is more appropriate to use where the system being developed is unclear and /or is prone to changes (e.g., web software).

1.5.2 Effect of Business Structure on choosing the Approach The business structure the project is working under can have a great influence on the type of life cycle to be used for developing the project. Where the project is being built under a fixed price contract, a detailed specification is needed to determine the price so the iterative model would not be usable. If the software is being developed by an outside company (eg: software house) then clients may be reluctant to accept the open cheque book approach that iterative development would bring in.

13 | P a g e

1.6

Exercise Questions

1. Provide five characteristics of a system. 2. Define Information and Information Systems. 3. What are the problems in developing an Information System from a) End-users b) Clients, and c) Developers perspective? 4. What are the two types of project failures? 5. What are the reasons for the two types of project failures identified in the above question? 6. Discuss the activities that should be performed before starting the information system development process. 7. Provide the issues that are to be considered while choosing a project development approach. 8. How does the Business Structure affect the choice of the approach to develop an information system?

14 | P a g e

Chapter 2: Object-Orientation and Modeling Concepts

Upon completion of the chapter, you would be able to understand:

Object-Oriented Concepts Modelling Concepts Unified Modelling Language (UML) Object-Oriented Methodology

15 | P a g e

2.1

Introduction

Object-oriented approach to systems development helps to avoid many of the problems and pitfalls described earlier. In this chapter, object-oriented approach is introduced along with the introduction of important concepts such as object, class, instance, inheritance, message passing and polymorphism. This chapter also introduces the various modelling concepts as well as the development process. The UML notation that is used for the representation of a few concepts is also specified along with the discussions.

2.2

What is Object-Orientated?

The object-oriented approach models a system as a collection of interacting objects like the objects (or things) in the world around us.

The following two concepts are important with respect to these objects or things: These things / objects have certain features, i.e., they have attributes and they can exhibit certain behaviour. Similar objects in a system can be grouped and classified as a specific type of thing or class. These objects interact, i.e., one object tells another object to do something via a message.

Please note that some of the concepts stated above are described in detail in the following section.

16 | P a g e

2.2

Object-Orientation Concepts

2.2.1 Objects An object is an abstraction of something in a problem domain. It has certain attributes to store the information about it and/or to interact with it. These attributes are relevant to the current purpose of the desired system.

Objects are used to model an application domain in an unambiguous manner. Objects are considered to be as parts of the resulting software system. Stated below are the two purposes of objects:

objects help to understand the real world, and objects provide a useful beginning for implementing the system.

Following are the examples of objects: aTable aCat aPerson aBankAccount

An object has a role in the system and is based on the answers to the following questions:

What is the object? What can it do? What does it know?

An object encapsulates the characteristics and behaviour.

17 | P a g e

2.2.2 Classes

A class is a template for defining like objects. As per UML specification, all objects of a class share common features, semantics and constraints. A class is a software entity.

Every object is an instance of a class and is unique.

Below are the examples of class from an application domain: Student Borrower Staff Item Book

2.2.3 Methods and Attributes

An object has a behaviour that is implemented as a method inside the class. The characteristics of an instance of a class are called attributes that are implemented as variables inside the class when defining the software entity.

2.2.4 Inheritance

Assume we are designing a system for a company where the employees are paid both on hourly basis as well as on monthly basis. We may define the following classes: MonthlyPaidEmployee HourlyPaidEmployee

18 | P a g e

MonthlyPaidEmployee employeeName employeeAddress employeeTelephone employeeID monthlySalary getName() getAddress() setName() ...

HourlyPaidEmployee employeeName employeeAddress employeeTelephone employeeID hourlyRate totalHoursWorked getName() getAddress() setName() ...

Figure 2.1: The UML representation of MonthlyPaidEmployee and HourlyPaidEmployee classes

The two classes have some things in common: Common fields Common methods

These similar fields and methods can be taken and put together in another higher level class (Employee). The MonthlyPaidEmployee and HourlyPaidEmployee classes can be made the sub-classes of the higher level class. So, the resulting class-hierachy is as follows:

19 | P a g e

Employee employeeID emplyeeName emplyeeAddress emplyeeTelephone

. . .

MonthlyPaidEmployee monthlySalary

HourlyPaidEmployee hourlyRate totalHoursWorked . . .

. . .

Figure 2.2: UML representation of class hierarchy with Employee as super-class and MonthlyPaidEmployee and HourlyPaidEmployee as sub-classes, i.e., to show Inheritance.

A sub-class inherits everything from the superclass. The process that has been applied above to get the class-hierarchy represented in above figure is called as generalization. Generalization process can be applied to increase the height of the hierarchy and specialization process can be applied to add siblings to the sub-classes.

20 | P a g e

2.2.5 Encapsulation

Encapsulation is the containment of the data behind a software membrane consisting of methods, i.e., the data is hidden behind an interface.

The data can only be accessed through the encapsulated behaviour / through the software membrane. Users cannot access the data directly outside the class / system. For example, the drinks (i.e., the data) cannot be accessed directly by the purchaser directly from the vending machine. He/she has to go through the proper procedure by inserting the coin in the machine and then by clicking the appropriate option available on the machine to buy the drink.

2.2.6 Message Passing

Message passing is one of the key-concepts in object-orientation. Objects communicate with each other by sending messages, in the same way as human communication is made up of messages. Examples of messages, in real-world, are everything we say to our friends and family members, the emails / letters we read, advertising posters on the bus or MRT, game shows and cartoons on TV.

Objects are bundles of data together with some processes that act on this data. The processes are called operations and each operation has a specific signature. An operation signature is a definition of its interface through which the operation is invoked with reference to the particular object.

21 | P a g e

2.2.7 Polymorphism

The term Polymorphism has two parts: Poly and morphism. Poly means many and morphism stands for forms, i.e., Polymorphism means many forms. There can be more than form of the method and the object may behave differently under different situations depending on how that method is called.

Polymorphism can be static or dynamic. Static polymorphism is called Overloading and dynamic polymorphism is called Overriding. Overloading is visible at compilation time and can be applied to methods as well as constructors of the class. Overriding is visible at run-time and can be applied to instance variables as well as methods of the class.

22 | P a g e

2.3

Modelling Concepts

2.3.1 Unified Modelling Language (UML)

The Unified Modelling Language (UML) is a language for specifying, visualising and constructing

the artefacts of software systems, as well as for business modelling.

UML provides notation for graphically representing object-oriented analysis and design models. It allows for: specification of system requirements, capture of design decisions, and the promotion of communication among key persons involved in system development

2.3.2 UML Models

A model provides a view of a physical system. It is an abstraction of the physical system, with a certain purpose, describing the relevant aspects of the system at the relevant level of detail.

Introduced below are the various UML models that can be used during analysis and design process.

23 | P a g e

Class Diagram

Class diagrams show the static structure of data, and the operations that act on the data.

State Diagram

State diagrams represent dynamic models of how objects change their states in response to events.

Use Cases

Use cases represent the functional requirements, or what of the system. Use cases may represent the goals of the users that they want to achieve by running the system under discussion.

Use Case Diagram

Figure 2.3: Sample use case diagram 24 | P a g e

Interaction Diagram

Interaction diagrams represent dynamic models of interactions (i.e., message flow) between objects.

Following are the two types of Interaction Diagrams that are used during analysis and design: sequence diagram, and collaboration diagram.

Activity Diagram

Activity diagrams can be used to model the aspects of a system at high-level as well as at low-level.

At high level, activity diagrams model the business activities of a system. They model a system function, represented by a use case, possibly using object flows to show the objects involved in a use case. Activity diagrams are usually drawn while elaborating the requirements of the system.

At low level, activity diagrams are used to model the detail of how a particular operation is carried out. Activity diagrams at low level are usually drawn during later activities of analysis phase and during design phase.

Purposes of activity diagrams: model a process or task describe a system function that is represented by a use case describe the logic of an operation in operation specification model the activities

25 | P a g e

2.3.3 Class Relationships

Relationships as are defined in E-R modelling, also apply to OO modelling. UML represents relationships with a line, just as in E-R diagrams. Following are the three types of relationships defined in UML: Association Aggregation Composition

Each relationship is represented with distinct symbols at the ends of the lines.

26 | P a g e

2.4

Object-Oriented Methodology

Object-Oriented Methodology is: iterative incremental requirements driven component-based architectural

The main activities involved in the systems development process are: requirements capture and modelling requirements analysis system design class/object design interface design data management design construction testing implementation

These activities are interrelated and dependent upon each other.

27 | P a g e

Requirements capture and modelling Various fact-finding techniques are used to recognize the requirements of the system under discussion. These requirements are documented in use cases.

Requirements Analysis Essentially each use case describes one major user requirement. Functionality offered via a use case is defined in requirements analysis.

Each use case is analysed separately to identify the objects that are required to support it. The use case is also analysed to determine the interaction and relationships among the objects and the attributes and responsibilities of these objects, in order to support the use case. All this information for each use case is gathered and integrated to produce an analysis class diagram.

Employee employeeName employeeAddress employeeTelephone

addEmployee()
updateEmployeeDetails()

getEmployeeDetails()

Figure 2.4: Partly completed sample analysis class

28 | P a g e

System Design The system designer makes high-level decisions about the overall architecture of the system. During system design, the desired system is organized into subsystems based on both the analysis structure and the proposed architecture.

Responsibilities of the system designer:

decide the performance characteristics to be optimized choose a strategy for handling the problem provisional resource allocations

Class/Object Design The focus of object design is the data structures and algorithms needed to implement each class, thereby producing a detailed design class diagram. The following diagram shows the Employee class as the design class:

Employee employeeName : String employeeAddress : String employeeTelephone : Phone

+addEmployee(name:String, address:Address, telephone:Phone)

Figure 2.5: Partly completed sample design class

29 | P a g e

User Interface Design User interface design produces a detailed specification realizing the required functionality. User interface design gives a system its look and feel and determines the style of interaction the user will have. It includes the positioning and colour of buttons and fields, the mode of navigation used between different parts of the system and the nature of online help. Interface design is dependent on class design.

Data Management Design Data management design focuses on the implementation of the use of database management system to store the objects. Data management design is dependent on the class design.

Construction The actual coding of the desired system is done at this stage, using appropriate development technologies. Different parts of the system may be built using different languages. For example, user interface is constructed using Java and MySQL is used to manage data storage.

Testing The system should be tested thoroughly before delivering it to the client. Testing scripts should be derived from the use case descriptions that were previously agreed with the client. Testing should be performed as elements of the system are developed, i.e., the testing process is also the iterative process.

Implementation The final implementation of the system includes its installation on the various computers that will be used. There may also be a need to manage the transition from the old system to the new system for the client. Risk management and staff training are two important activities involved in the implementation of the system.

30 | P a g e

2.5

Exercise Questions

1. What is the UML notation for a class? 2. What is the difference between a class and an object? 3. Define inheritance and polymorphism. 4. Describe the five UML models that you have read in this chapter. 5. What are the characteristics of Object-Oriented methodology for developing a system? 6. Discuss the main activities included in the systems development process using object-oriented methodology.

31 | P a g e

Chapter 3: Requirements Modeling Part I

Upon completion of the chapter, you would be able to understand:

The user requirements and documenting the requirements Various fact-finding techniques User involvement in developing the system To draw the use case diagram How to write the use cases

32 | P a g e

3.1

Introduction

Various types of requirements of a system are discussed. Various fact-finding techniques are used to investigate the requirements of a system. Documenting the requirements is also important for software development process. The second part of the lesson discussed about the use cases, use case diagram and to write the use cases.

3.2

User Requirements

A new information system is produced to meet the requirements of the users of the system. So, the overall objectives of the business and of the individual users of the desired system must be well understood. And also, how the system is operating currently and how the users are carrying out their jobs must be well understood. All this information should be gathered and documented as some of the aspects of the current system may have to be carried forward to the new system. The information gathered from the current system and what does the users want from the new system that they cannot do with the existing system, reflects the requirements of the new system.

3.2.1 Current System The analyst performs the first step in developing a new system that is to gather information. By performing this step, the analyst gets a clear understanding of how the existing system works. The existing system will have shortcomings and defects that must be avoided or overcome in the new system.

33 | P a g e

3.2.2 New Requirements The requirements of the new system may fall into one of the following three categories: Functional requirements Non-functional requirements Usability requirements

Functional Requirements Functional requirements refer to the functionalities of the desired system, i.e., what a system does or is expected to do. Functionality of a system is documented by use cases. The functional requirements of the system must include the following: Descriptions of the processing to be carried out by the system Details of the inputs into the system o from paper forms and documents, o from interactions between people, such as telephone calls, and o from other systems Details of the outputs from the system in the form of o printed documents and reports, o screen displays and o transfers to other systems Details of data stored by the system.

34 | P a g e

Non-functional Requirements Non-functional Requirements describe those aspects of the system that are concerned with how well it provides the functional requirements. Performance, volumes of data and security considerations are the non-functional requirements of a system. Performance criteria refer to the desired response times for updating data in the system or retrieving data from the system. Expected volumes of data is in terms of throughput or of must be stored. Usability Requirements Usability Requirements refer to the match between the system developed and both the users of the system and the tasks undertaken while using the system. The International Standards Organization (ISO) defines the usability of a system as the degree to which specific users can achieve specific goals within a particular environment; effectively, efficiently, comfortably and in an acceptable manner. The following information needs to be gathered to build usability into the system from the beginning: characteristics of the intended users of the system tasks and goals that the users undertake / try to achieve, situational factors that describe the various situations that could arise during system use acceptance criteria used by the user to judge the delivered system.

35 | P a g e

3.3

Fact-Finding Techniques

The following five main fact-finding techniques are used by analysts to explore the requirements of the desired system: Background reading Interviewing Observation Document sampling Questionnaires

3.3.1 Background Reading The background reading or research is part of the process of gaining an understanding of the organization. This technique mainly provides information about the current system. The documents that can be used as the sources of information are: Company reports Organization charts Policy manuals Job descriptions Reports Documentation of existing systems.

36 | P a g e

Advantages Helps the analyst to understand the organization before meeting the staff members. Enables the analyst to get ready for other types of fact finding techniques. Provide properly defined information requirements for the current system.

Disadvantages Written documents may not match to reality Written documents may be outdated Official matters may be dealt with differently from the official policies as are stated in the written documents 3.3.2 Interviewing Interviewing is the most widely used fact-finding technique and requires the most skilfulness and understanding. A systems analysis interview is a well thought-out meeting between the analyst and an interviewee who is typically a member of staff of the organization being investigated. The analyst may have to perform a sequence of interviews to investigate the requirements of the desired system. Advantages Interviews produce high quality information as personal contact enables the analyst to be quick to respond and adapt to what the user says. Interview enables the analyst to explore in greater depth about the persons work than can be achieved with other methods. The interview can be concluded once the interviewee has nothing to say.

37 | P a g e

Disadvantages Interviews are time-consuming and can be the most costly technique of factfinding. The analyst has to work on the interview results after the interview. Interviews can be biased if the interviewer has a closed mind about the problem. Different interviewees may provide differing information.

3.3.3 Observation The analyst will watch the users carrying out their work in a natural sitting. This will provide the analyst with a better understanding of the job than interviews. Observation allows the analyst to observe the information used by users to accomplish their jobs, documents they refer to, whether users have to get up from their desks to get information and how well the existing system handles the users needs.

Advantages Observation of people at work provides first-hand understanding of how the current system works. Data can have high level of validity as are collected in real time. Observation can be used to validate information from other sources. Observation can also be used to find exceptions to the model practice. Observation can help to gather data about the performance of the existing system and of users.

38 | P a g e

Disadvantages Findings can be deformed and validity can be affected as most people do not like to be observed and are likely to behave differently from the way in which they would normally behave. Qualified and skilful observer is essential to make the observation most effective. Observation can have both logical as well as the ethical problems associated with it. For example, the staff to be observed works in shifts (logical problem for the analyst), the person to be observed deals with sensitive and confidential information (ethical problem). 3.3.4 Document Sampling Document sampling can be used in two different manners: The analyst will collect copies of blank and completed documents while conducting interviews and during observation sessions. These copies will be used to determine o information used by people in their work, and o inputs to and outputs from the processes carried out, either manually or using an existing computerised system. The analyst may perform the statistical analysis of documents to find out about patterns of data.

39 | P a g e

Advantages Document sampling can be used to collect quantitative data, such as the average number of lines on an invoice and the range of vehicles. to find out about error rates in paper documents.

Disadvantages If the system is going to alter significantly, existing documents may not reflect the future version of the system. 3.3.5 Questionnaires Questionnaires are a research tool consisting of a series of written questions. The questions can be of various forms such as YES/NO questions Multiple choice type questions Subjective type questions

Advantages It is a cost-effective way of collecting data from a large number of people. If the questionnaire is well designed, the results can be analysed easily, possibly by a computer. Disadvantages It is difficult to create good questionnaires. There is no automatic mechanism for follow-up. Response rate may be low for postal questionnaires.

40 | P a g e

3.4

User Involvement

Stakeholders have an interest in the successful development of the system. Stakeholders may include users, managers and budget holders, i.e., all those people who may gain (or lose) from the implementation of the new system. Analysts deal with all these people at different levels of the organization. Following are the categories of people who are involved in a steering committee to handle the project from the users side: Senior management with responsibility for running the organization Financial managers - with budgetary control over the project Managers of the user department(s) Representatives of the IT department delivering the project Representatives of users

3.5

Documenting Requirements

There are some documents that do not fit into the UML framework. These documents also need to be stored safely and in such a manner that they can be retrieved when required. Below are the examples of such documents: Records of interviews and operations Details of problems Copies of existing documents and where they are used Requirements details Details of users Minutes of meetings.

Use cases are used to model the functional requirements of the system under discussion. 41 | P a g e

Jacobson et al. (1999) suggested that use case model documents the functional requirements of the desired system. Use cases describe units of system behaviour, whereas requirements are rules that govern the behaviour of the system. A use case may handle one or more requirements of the system or alternatively, one or more use cases may handle a requirement of the system.

3.6

Use Cases

Use cases specify the goals of the system that the users want to achieve by running the system. They describe the functionality of the system from the users perspective. Use case diagrams illustrate the functionality to be provided by the system and which users will communicate with the system to use that functionality.

Figure 3.1: Use case diagram

42 | P a g e

Use case diagrams show three aspects of the system: Actors Use cases, and System or subsystem boundary.

Actors represent the roles that people, other systems or devices take on when communicating with the particular use cases in the system. A use case can provide a step-by-step breakdown of the interaction between the user and the system for a particular use case. Withdraw cash Actor Action 1. Customer inserts ATM card into the card reader. System Response 2. ATM reads the bank ID, account number, encrypted PIN from the card, validates the bank ID and account number with the main banking system. 3. Customer enters PIN. 4. The ATM validates it against the encrypted PIN read from the card. 5. Customer selects Fast Cash and withdrawal amount. 6. ATM notifies main banking system for customer account, amount being withdrawn, and receives back

acknowledgement plus the new balance. 7. ATM delivers cash, card, and a receipt showing the new balance. 8. ATM logs the transaction. 43 | P a g e

Each use case description represents the action steps that an actor will perform to do a particular transaction or function from trigger to end. There are two types of use cases: Essential use case Real use case

Essential use cases express the essence of the use case without any technological or implementation details. Real use cases describe the real or actual design of the use case in terms of concrete input and output technology, and its overall implementation. Following are the main components of a use case: Use case name Characteristic information: specifying the

Primary actor Pre-conditions Post-conditions Goal

Main Success Scenario Extensions Variations

Use case name is the name of the use case that generally is the goal that a user may want to achieve by running the system under discussion. Primary actor can be a person, system or subsystem the one who has the goal to be achieved. Pre-conditions are the things that must be true before the use case can take place.

44 | P a g e

Post-conditions are the things that must be true after the use case has taken place. Goal is the goal of the use case. Main Success Scenario specifies the individual steps (generally numbered) of the process of achieving the goal. The use case has a distinct goal. At the end of the success scenario, the goal has been achieved. Extensions specify the actions to be performed when something goes wrong during the success scenario steps. Extensions to a success step have the same number with a letter to indicate the variation. A success step can have zero or more multiple extensions written for it. Extensions have two parts: Failure condition and Failure handling. Failure condition specifies what has gone wrong to cause the extension. Failure handling specifies what to do when the failure condition has occurred. Extensions may either recover from the failure and branch back to the success scenario or finish by failing to reach the goal. Variations specify the action steps that are to be performed when a particular action step of the main success scenario can be performed in more than one way. The component Variations is also called as Technology and Data Variation List. A use case can be at any of the following three levels: Summary level or Strategic level User Level Subfunction level

Summary level use case show the context of multiple user goals showing the life cycle sequencing. These use cases have longer time frames may be days, weeks, months, years. User goal is the goal the primary actor is interested in. Most interesting use cases are at user level describing a business or a computer system. User goal should be achievable in one sitting i.e., approximately 20 minutes. 45 | P a g e

3.7 Exercise Questions

1. List and describe the five fact-finding techniques to investigate a system. 2. Given the following scenario:

EZticket
EZticket is a privately run ticket booking agency having its outlets at several prominent locations in Singapore. The agency handles ticket bookings for various entertainment events and shows held in Singapore. Customers can make ticket bookings either at the EZticket outlets or over phone. For the bookings made at the outlets, the tickets are issued on the spot after the payment has been made. Payment can be made by cash or credit card. For bookings done over phone, the customers details are noted and they are issued with a reference number. For bookings made more than a month in advance, a discount of 5% is given. This is not applicable to phone bookings. All tickets for children between the age of 2-12 are sold on a discount of 30%.

a) Identify the use cases of the above case. b) Draw the use case diagram for the above case. c) Write the following use case: Use case name: Book a ticket Primary Actor : Customer Goal : The customer wants to book a ticket for an event

46 | P a g e

Chapter 4: Requirements Modeling Part II

Upon completion of the chapter, you would be able to:

Identify classes, attributes and methods Identify the relationships between the classes Learn about abstract classes Use inheritance Draw the class diagram

47 | P a g e

4.1

Introduction

Identifying the classes, attributes and relationships among the classes are the initial stages of drawing the class diagram that models the system under discussion. The second part of the chapter introduces and discusses about the abstract classes and CRC cards.

4.2

Class Diagram

The class diagram provides A high-level basis for system architecture, and A low-level basis showing the static structure of data, and the operations that act on the data.

A class diagram is a model of the classes of a system showing the attributes and operations of the classes alongwith the relationships with other class(es) of the system. A class diagram provides for the design of the program code that implements the system.

48 | P a g e

4.3

Identifying Classes, Attributes, Methods

The following procedure can be followed to identify the classes, attributes and methods: Perform the textual analysis of the problem domain, i.e., start with a description of the problem Pick out all the important words such as noun, verb and adjectives.

Noun identifies a prospective class / object and attribute. Doing verb and transitive verb identify a method / operation. Adjective identifies attribute value. Classes Identifying the classes is an iterative process. Below are some examples of the categories of a class: Category Abstraction of people Organization Conceptual thing Physical thing Example Student, Lecturer, Customer Informatics Qualification Table, Chair, Projector

Enduring relationships between Loan, Borrow, Contract, Sale classes of other categories Keep a list of prospective classes, with a brief description for each. This list may grow further as you progress through the problem domain / case. However, some of these classes may also need to be removed from the list after analysing each and every noun whether it is suitable candidate for the class or not.

49 | P a g e

Each item in the list can be checked as per the following criteria: Express classes or objects as singular noun. Synonyms may be describing the same class. So, include only one class. Roles being played by the actors represent the class, not the actors. A class representing the entire system may not need to be included in the model. But this rule may vary with the problem domain under discussion. Classes need to be modelled, not the instances of the class. Eliminate any probable class for which you are unable to write a clear description. An item in the list may be an attribute in one domain and may be a class in another domain depending on the requirements of the system under discussion. An action can be considered a class, e.g., borrow a book from the library in this case borrow is a class that represents the action of borrowing book from the library. The system may need to store details about each borrow transaction to keep a track of all such transactions and books on loan. The action may be included as an operation of a class if there is no need to keep a history of the action. If an association is described in terms of further characteristics (i.e., it has attributes of its own), it should be modelled as a class.

50 | P a g e

Attributes Attributes specify the characteristics of a class describing the values kept in an object and are manipulated by the operations of that class. Each object has its own value for each attribute in its class. To find out the attributes of a class, you may start by answering the following questions: What does the object need to know? What are the different states that an object can be in?

Methods / Operations An operation is a responsibility of a class or the services provided by the class.

51 | P a g e

4.4

Multiplicity / Cardinality

Multiplicity / Cardinality specifies how many instances of one class are related to how many instances of another class. Following are the different categories of Multiplicity: One-to-one One-to-many Many-to-many

4.5

Adding Association

Following are the examples of sentences that may specify the association between the classes: A student registers for a module. In the above sentence, student and module are the two classes that are associated with each other and the word registers specify the association.

Student studentID surname given *

Module moduleCode moduleName

Figure 4.1: Association

52 | P a g e

4.6

Adding Aggregation and Composition

Aggregation and composition are two subcategories of whole-part structure. I.e., they provide the idea of containment. Aggregation is also referred to as the contains, is composed of is part of or consists of relationship. Example: A car contains an Engine. The following figure shows an example of association: Window title position 1 * Button label position

Figure 4.2: Aggregation

Composition is a stronger form of aggregation, where the individual parts depend on the whole for their existence.

Invoice invoiceNumber invoiceDate 1 *

InvoiceItem itemCode itemDescription

Figure 4.3: Composition

53 | P a g e

4.7

Inheritance

Inheritance is referred to as the is a relationship between two classes. Example: Contract contractID contractDate commissionRate

Sale salePrice

Lease numberOfYears monthlyRent

Figure 4.4: Class hierarchy

In the above class hierarchy, Contract is the super-class, Sale and Lease are the two subclasses of the Contract class. Sale and Lease classes will inherit the features (attributes and methods) from the Contract class.

54 | P a g e

4.8

Abstract Classes

An abstract class is just like a normal class except that you cannot instantiate an abstract class, i.e., you cannot create an object of the abstract class. An abstract class can contain the fields and methods in same way as a normal class can have. A class is defined as an abstract class by using the keyword abstract in the definition. Example: public abstract class Student Usually, the superclass is defined as abstract class. You can define abstract methods inside an abstract class. Abstract methods are also defined by using the keyword abstract in the definition of the methods. Example: public abstract double libraryFine(); The abstract method will be defined in the abstract implemented in the subclass of that superclass. superclass. Then it has be

55 | P a g e

4.9

Class Responsibility Collaboration (CRC) Cards

A responsibility is a high-level description of something a class can do. A responsibility may correspond to one or more operations. A collaboration is a group of objects or classes that work together to provide a functionality or behaviour. Class Responsibility Collaboration (CRC) cards provide an effective technique for exploring the possible ways of allocating responsibilities to classes and the collaborations that are essential to accomplish the responsibilities. CRC cards can be used at several different stages of a project for different purposes. The format of the CRC card is as shown below:

Class Name: Responsibilities Responsibilities of a class are listed here Collaborations Collaborations with other classes are list here along with a brief description of the purpose of the collaboration.

Figure 4.5: Format of a CRC Card

56 | P a g e

4.10 Exercise Questions

Answer the following questions for the scenario (EZTicket) given in chapter 3 exercises:

1. Perform the textual analysis of the above case. 2. Draw a class diagram for the above case.

57 | P a g e

Chapter 5: Object Interaction

Note: Diagrams to be updated Upon completion of the chapter, you would be able to understand:

an interaction diagram a sequence diagram a collaboration diagram

58 | P a g e

5.1

Introduction

Communication and collaboration between objects are fundamental to objectorientation. For example, each employee in an organization has specialized tasks. Different employees work together to satisfy a customers request. This involves communication among various parties involved for various purposes such as communicating to request information, to share information and to request help from each other. Similarly, an object oriented application comprises a set of independent objects, each responsible for a small part of the systems overall behaviour. These objects interact with each other to generate the required behaviour of the system under discussion. The objects interact with each other by exchanging messages for the purposes such as to request information, to give information or to ask another object to perform some task.

59 | P a g e

5.2

Object interaction and collaboration

An operation is invoked in an object when it receives a message from another object. System functionality should be distributed appropriately among its classes. A class should be designed to perform only one task, i.e., a class should be highly cohesive. Such a class that is relatively small and self-contained, can be reused.

The object interaction is modelled to determine the most appropriate scheme of passing messages between objects to support a particular user requirement as is documented by the use case. A use case is a dialogue between an actor and the system. It results in objects performing tasks so that the system can respond in the way that is required by the actor.

Interaction diagrams include objects to represent the user interface (boundary objects) and to manage the object interaction (control objects). When such objects are not shown explicitly, it can be assumed in most cases that they will need to be identified at a later stage. The identification and specification of boundary objects is in part an analysis activity and in part a design activity. When we are analyzing requirements, our concern is to identify the nature of a dialogue in terms of the users need for information and his or her access to the systems functionality. Deciding how an interaction should be realized in software will involve the detailed design of boundary objects that manage the dialogue and the introduction of other objects to enable the effective execution of the interaction.

Essentially a collaboration is a group of objects or classes that work together to provide an element of functionality or behaviour. The behaviour mentioned can be that of an operation or a use case. A particular object instance may play different roles in different contexts or interactions and may even play more than one role in a given interaction.

60 | P a g e

The interaction between the objects can be represented pictorially using the interaction diagram in the Unified Modelling Language (UML). An interaction diagram can be: A sequence diagram, and A collaboration diagram

In both the above diagrams, objects are shown as rectangles with naming labels inside. These labels are preceded by colons (:) and are underlined. 5.2.1 Sequence Diagram

A sequence diagram is used to represent the communication amongst a set of objects.

An interaction sequence diagram or a sequence diagram is one of several kinds of UML interaction diagram. The sequence diagram is semantically equivalent to a communication diagram for simple interaction. An interaction specifies the communication patterns against a set of objects or systems that are participating in messages between objects or communicating roles. The definition of an interaction is in terms of communicating roles and highlights the fact that these concepts can be applied in various contexts. Commonly, during requirements analysis or interaction design, object instances are modelled in terms of the roles that they play and communicate by message passing.

A sequence diagram shows an interaction between objects arranged in a time sequence. Sequence diagrams can be drawn at different levels of detail and to meet different purposes at several stages in the development lifecycle. The commonest application of a sequence diagram is to represent the detailed object interaction that occurs for one use case or one operation. When a sequence diagram is used to model the dynamic behaviour of a use case, it can be seen as a detailed specification of the use case. Those drawn during analysis differ from those drawn during design in two major respects. Analysis sequence diagrams normally do not include design objects; nor do they usually specify message signatures in any detail.

Basic concepts and notation 61 | P a g e

Shown below is an example of a simplified sequence diagram that shows the sequence of messages that are being passed from one object to another:

Figure 5.1: A simplified sequence diagram

The vertical dotted line represents the life-line of the object. The objects involved in the interaction are spread horizontally across the diagram. A message is shown by a solid horizontal arrow from one lifeline to another and is labelled with the message name. Each message name may optionally be preceded by a sequence number that represents the sequence in which the messages are sent, but this is not usually necessary on a sequence diagram since the message sequence is already conveyed by their relative positions along the time axis. When a message is sent to an object, it invokes an operation on that object. The message name is usually the same as the operation that is being invoked. Once a message is received, the operation that has been invoked begins to execute. The period of time during which an operation executes is known as an activation or an execution occurrence and is shown on the sequence diagram by a rectangular block laid along the lifeline. The activation period for an operation includes any delay while the operation waits for a response from another operation that it has itself invoked as part of its execution. Usually, a sequence diagram is named the same as the use case for which it has been drawn.

62 | P a g e

The repeated action, i.e., an iteration is represented by enclosing the repeated messages inside a frame with the heading loop. The interaction in this type of frame is known as a combined fragment. Inside the loop frame, the guard condition is written in [...]. A guard condition is an interaction constraint. A combined fragment with an interaction constraint will only execute if the constraint is evaluated as true. The following diagram shows the basic notation for sequence diagrams.

Synchronous messages or blocking calls The messages that have been considered so far are synchronous messages or blocking calls. The sending operation is suspended while the operation invoked by the message is executing. This is a nested flow of control where the complete nested sequence of operations is completed before the calling operation resumes execution. This may be because the invoking operation requires data to be returned from the destination object before it can proceed. Send message event Formally sending the message is an example of send message event. Receive message event Formally receiving the message is an example of receive message event. Execution occurrence start event The execution occurrence starts with the execution occurrence start event. Execution occurrence end event The execution occurrence ceases with the execution occurrence end event. A reply message (with a dashed line) represents a return of control after the execution occurrence has ended. Most use cases imply at least one boundary object that manages the dialogue between the actor and the system.

63 | P a g e

Reflexive message Reflexive message is the message that is sent by an object to itself. It is shown by a message arrow that starts and finishes at the same object lifeline. Example: Check campaign budget use case (adapted from Bennett et al., 3rd edition) the use case description is stated below:
The campaign budget may be checked to ensure that it has not been exceeded. The current campaign cost is determined by the total cost of all the adverts and the overheads

The diagram below shows the sequence diagram for the above use case showing a reflexive message getOverheads sent from a Campaign object to itself. Focus of Control The focus of control indicates times during an execution occurrence when processing is taking place within that object. Parts of an execution occurrence that are not within the focus of control represent periods when , for example, an operation is waiting for a return from another object. The focus of control may be shown by shading those parts of the activation rectangle that correspond to active processing by an operation. Reply A reply is a return of control to the object that originated the message that began the activation. This is not a new message, but is only the conclusion of the invocation of an operation. Replies are shown with dashed arrow, but it is optional to show them at all since it can be assumed that control is returned to the originating object at the end of the activation in a destination object. Replies are often omitted, as in Fig. 9.7. Figure 9.8 explicitly shows all replies for the same interaction.

5.2.1.1 Looping Interaction Constraints In Fig. 9.7 the first loop combined fragment has its interaction constraint specified as
[For all clients campaigns]

64 | P a g e

This interaction constraint can also be written as

[i=1; i=<campaigns.count; i++]

Stating that the loop will iterate from 1 to the value of campaign.count, which holds the number of campaigns associated with that particular client.

Loop Iteration Operator with Parameters The figure shows loop iteration operator with parameters. The first parameter is the minimum number of iterations and the second is the maximum number of iterations. Looping constructs correspond to iteration in the use case. 5.2.1.2 Branching Some interactions have two or more alternative execution pathways. Each reflects a branch in the possible sequence of events for the use case it represents. The notation for branching is illustrated in Fig. 9.11. Branching constructs correspond to decision points in the use case. Example: Add a new advert to a campaign if within budget use case (adapted from Bennett et al., 3rd edition) the use case description is stated below:
A new advertisement is added to a campaign by the campaign manager only if the campaign budget is not exceeded by adding new advert. If adding the advert would cause the budget to be exceeded then a campaign budget extension request is generated. This will be recorded for later reference. The budget extension request is printed and sent to the client at the end of the day.

The keyword alt stands for alternatives. The combined fragment has two or more compartments known as interaction operands. Each operand corresponds to one of the alternatives in the combined fragment and each operand should have an interaction constraint to indicate under what conditions it executes. The sequence of the operands is not significant.

5.2.1.3 Managing Sequence Diagrams

65 | P a g e

On occasions it is necessary to represent complex or large interactions using two or more sequence diagrams. It may be that a single interaction is too complex to represent in a single sequence diagram. There might be interaction fragments that are common to several interactions and it is more effective to model these common interaction fragments only once. Another possibility is that part of the interaction involves complex messaging between members of a group of objects and that this part of the interaction is best shown separately. The first approach to modelling an interaction with more than one sequence diagram is to use interaction occurrences as shown in Figure 9.12.

Here there are two interaction occurrences List client campaigns and Get campaign budget. The keyword ref indicates that they are interaction occurrences and that they are referring to the sequence diagrams List client campaigns and Get campaign budget. These two sequence diagrams are shown in Figs 9.13 and 9.14 respectively. Each of these is an example of an interaction fragment, that is, they can be used as part of one or more larger interactions. The interaction fragment List client campaigns in Fig. 9.13 could easily be reused in any interaction that requires a list of the campaigns for a specific client.

Interaction Operators The following keywords represent the interaction operators that indicate the type of the combined fragment. loop . . .

66 | P a g e

5.2.2 Collaboration Diagram

A collaboration diagram is also called as a communication diagram. The messages between objects are shown as arrows connecting the appropriate rectangles along with labels that define the message sequencing. Arrows and numbers indicate the order in which the messages are sent from one object to another in the course of a use case.

Figure 5.2: Collaboration diagram

5.3

Exercises

1. What is the purpose of an interaction diagram? 2. What are the two different types of interaction diagram in Unified Modelling Language? 3. Differentiate between sequence diagram and collaboration diagram. 4. Draw the following two interaction diagrams for the use case Book a ticket for the EZticket case study given in chapter 3: a. Sequence diagram b. Collaboration diagram

67 | P a g e

Chapter 6: Specifying Operations and Control

Upon completion of the chapter, you would be able to understand:

Operation specifications How to specify the Operation Logic Variations in system as well as object behaviour States and events State machines

68 | P a g e

6.1

Introduction

As part of the development process, you are required to identify the operations, i.e., to introduce the contract for the system under discussion, and to model the application, i.e., how the application responds to various events. The logic of an operation is represented using activity diagram and the application model can be represented using state diagram / state machine.

6.2

Operation Specification

Purposes of operation specification: Operation specification is created during analysis stage when the analyst feedbacks his understanding of an aspect of the application to the user ensuring that the users requirements are met. From design perspective, operation specification is a framework of more detailed design specification that can be used later by the programmer during the construction of the system. An operation specification can also be used to verify that the method meets its specifications from the users requirements perspective. An operation should be clearly defined in terms of its characteristics and logic / rules of the behaviour. If there is any dependency on other classes, that should also be established so as to guide how to package these classes during design and / or implementation.

69 | P a g e

6.3

Contracts

A contract is a set of operations that are required to deliver the services of an object. When describing the contract, following are some of the points that should be considered: The purpose of the operation The operation signature Description of the logic Other operations (whether from the same object or from the other objects) called The response to exceptions, if any Any non-functional requirements that may apply

and so on.

70 | P a g e

6.4

Describing Logic of the Operation

In object-Orientation, both classes as well as the operations can be abstract and / or concrete. Abstract operation will consist of a signature along with the return type, but there will not be an implementation of the operation. Typically, abstract operations are contained inside the abstract classes. These abstract classes are superclasses of an inheritance hierarchy. The abstract operations are overridden by concrete operations in the concrete subclasses. External and visible effects are defined as part of the specification. Any of the following approaches can be used for describing the operation logic: Algorithmic approach Non-algorithmic approach

Algorithmic approach An algorithm, in various small and sequential steps, is written to specify the logic of the process. The level of detail varies depending upon the information available at the time of writing the algorithm. An algorithmic approach is typically, used during method design as the method needs to be implementation in an efficient manner and using the best possible algorithm available. Non-algorithmic approach This approach focuses on describing an operation as a black-box. This is a preferred approach in object-orientation because of the following reasons: Usually, classes are well-encapsulated, thus only the designers and programmers responsible for a particular class, focus on the internal implementation details Generally, the operations are small and dedicated in an object-oriented systems class. This is due to relatively even distribution of effort among the classes. There is no need of complex specification as the processing carried out by any of the operation is simple. 71 | P a g e

6.5

Specifying Control

A real-time application / system responds to an event depending on its state. For example, an Ezlink machine normally does not dispense money unless a customer is either buying a standard ticket or getting refund of deposit for the standard ticket. This variation in behaviour is determined by the state of the machine which depends on the operations that is being chosen by the customer and the amount of money that he has inserted in case of buying the standard ticket. Similarly, objects can also have variation in their behaviour depending on their state. These variations in behaviour represent the constraints on the way the objects act and are dictated by the requirements specifications of the system.

6.6

States and Events

All objects have a state that is determined by the attribute values of the object. There is a change in the objects state as a result of events that lead to change in the attribute values. A state can also be described as a particular condition that an object may occupy for a period of time while waiting for an event or trigger. The possible states that an object can occupy are determined by its classes. A trigger is an event that is relevant to the object and can cause a change in the state. Movement (initiated by a trigger) from one state to another is called a transition. A transition is said to fire when its triggering event occurs. A transition is represented as an open arrow from the source state to the target state. A trigger is implemented by a message and can have parameters and a return value.

72 | P a g e

Triggers are grouped into following different types: Change trigger occurs when a condition becomes true. Call trigger - occurs when an object receives a call for one of its operations, either from itself or from another object. Signal trigger occurs when an object receives a signal. Relative time trigger is caused by the passage of a specific period of time after a specified event.

73 | P a g e

6.7

State Machine

All state machines have a starting state or a starting point (called as initial pseudostate) that is represented by small solid filled circle. A transition from the initial state is usually labelled with the trigger that creates the object. The final state or the end point of a state machine is shown by a bulls eye symbol. All other states are shown as rectangles with rounded corners and are labelled with meaningful names representing the state.

Figure 6.1: State Machine (adapted from Bennett et al., 3rd edition)

74 | P a g e

6.8

Preparing a State Machine

State machines can be prepared from the following two perspectives: A class A use case

State machine for a class is a description of the ways that use cases can affect objects of that class. Interaction diagrams (resulting from use cases) show the messages that an object receives during the execution of the use case, and these can be used a starting point for a state machine. The approach of using interaction diagrams as a starting point for developing a state machine is described as a behavioural approach. An alternative approach to the preparation of state machines is based on the lifecycles of the objects of each class. This approach is called as a lifecycle approach. There should be consistency among the various various models drawn for the system under discussion. Preparing state machines is also an iterative process in the same way as is the objectoriented development process as a whole.

75 | P a g e

6.9

Exercise Questions

1. Discuss the purposes of object specification. 2. Differentiate between algorithmic and non-algorithmic approaches to operation specification. 3. Define the term contract. 4. List five points that should be considered while describing the contract. 5. Define a transaction. 6. Define trigger. 7. Name four different types of triggers.

76 | P a g e

Chapter 7: System Architecture

Upon completion of the chapter, you would be able to understand:

The architecture in information system development Various architectural styles for building an architecture of an information system

77 | P a g e

7.1

Introduction

In information systems, architecture refers to the organization of the desired system in terms of its components, their relationships to each other and to the environment and the principles guiding the design and the development of the system.

7.2

Architecture

The following factors influence the architecture of an information system: The programming language, database and platform chosen to develop the system, and The skills, experience and knowledge of the development team

Stated below are the considerations that should be kept in mind while producing the architecture of the desired system: The non-functional requirements of the system, The context of the system, and How the system and its components may be used and further developed in future. Characteristics of the system architecture are: System architecture helps to understand the customers business and how the business can be supported by an information system. Architecture of an information system provides a high-level view of the system. The architecture models the major components of the system and their interaction with each other. The architecture should be flexible. Information system development process is architecture-centric (to avoid risks), i.e., by concentrating on the architecture and making the architectural decisions early, the risks can be reduced.

78 | P a g e

There are a various views of architecture in the development of information systems. However, our focus is on systems architecture and software architecture. Key terms that are important to know while learning about the architecture of information systems: System System refers to a set of components that comprehend a specific function or set of functions. Architecture Architecture is the fundamental organization of a system in terms of o its components, o their relationships to each other and to the environment, and o the principles guiding its design and evolution [IEEE Standard 1471-2000,
Copyright 2000 IEEE].

Architecture is overall arrangement of the system. Architectural View Architectural view is a depiction of a particular system or a part of a system from a particular viewpoint. Software Architecture Software Architecture refers to the organization of a system in terms of its o software components, and o relationships and interaction among the software components.

79 | P a g e

Four aspects of software architecture according to Soni et al. (1995): Conceptual Architecture Module Architecture Code Architecture Execution Architecture

Conceptual architecture is concerned with the static class model and the relations between the components of the model. Module architecture describes how the system is divided into subsystems and how they communicate with each other. Code architecture defines how the program code is structured into files, directories and libraries. Execution architecture concentrates on the dynamic aspects of the system and the communication between components during operation execution.

A system can be described in terms of: Use cases and the narration of these use cases Static structural relations between the classes and packages Decisions made with respect to the architecture of the system in terms of subsystems, components and relationships among them Explanation of the process and inter-process communication Various components deployed

Development process is said to be architecture-centric, i.e., getting the architecture right is a main concern, thereby reducing the risks in the project.

80 | P a g e

7.3

Architectural Styles

The term Architectural Style refers to the ways of designing systems. Architectural style should match to the well-known standards and fashions in software architecture. Various Architectural Styles of designing systems are: Subsystems Model-View-Controller (MVC) architecture Architecture for Distributed Systems

Subsystems The information system is subdivided into various subsystems depending on the properties of the elements of the system. Each subsystem provides services for other subsystems. Subsystems communicate with each other using client-server and peer-topeer communications the two styles of communication. Advantages: Smaller units of development are produced Reusability in increased at component level Complexity can be handled easily Systems maintainability and portability are enhanced

Layering and partitioning are the two approaches of dividing a system into subsystems: Layering different subsystems represent different layers of service Partitioning each subsystem focuses on a different aspect of the functionality of the system as a whole.

81 | P a g e

Model-View-Controller (MVC) architecture Interactive systems use MVC architecture where the application is divided into following three major types of components: Model comprises the main functionality View presents the user interface Controller manage the updates to views

Advantages: Supports user requirements presented through different interface styles Aids maintainability and portability

Architecture for Distributed Systems An information system may be dispersed over computers at the same location or at different locations. For example, the EZticket system (described earlier in chapter 3) has its outlets at several well-known locations in Singapore. So, the information system for the company should be able to support the outlets at all these locations. A distributed information system may be supported by distributed database management systems. The following simplified broker architecture may be used to depict the architecture for the distributed systems such as the EZticket system described above:

82 | P a g e

<<component>> Server A

<<component>> Server B

<<component>> Server C

<<component>> Broker

<<component>> Client X

<<component>> Client Y

Figure 7.1: A Simplified Broker Architecture for Distributed Systems (adapted from Bennett et al., 3rd edition)

In Broker architecture, the client and server components are decoupled, thereby increasing the flexibility of the system. Broker acts as an intermediary between the client and the server. The client component does not directly communicate with the server component. Instead, the client component sends a request to the server component through Broker. Then broker forwards the request to the appropriate server. A broker may offer services of many servers. So, it is also the responsibility of the broker to identify the server to which the request is to be forwarded. Advantages It is not necessary for a client to know where the service is located. The service can be deployed on either a local or a remote computer. Only the broker needs to know the location of the server on which the service is running / deployed.

83 | P a g e

7.4

Exercise Questions

1. Define architecture in information systems context. 2. Provide four features of system architecture. 3. What are the four aspects of software architecture? 4. What are the advantages of dividing a system into a collection of subsystems? 5. Name the architecture that is usually used for interactive systems. 6. Name and describe the various components of the architecture identified above. 7. Discuss the architecture that is suitable for distributed systems.

84 | P a g e

Chapter 8: System Design and Design Patterns

Upon completion of the chapter, you would be able to understand:

The difference between Analysis and Design About the design of a system Characteristics of good design Coupling and cohesion Design Patterns

85 | P a g e

8.1

Introduction

Analysis is about the What of the problem domain and design is about the solution domain. During design, the focus is on How. Design of a system consists of system design and detailed design. Design can be implementation-independent (called as Logical Design) and implementation-dependent (called as physical design). The second part of the lesson explains about various design patterns. Patterns help to capture awareness about the problems and successful solutions in software development.

86 | P a g e

8.2

Analysis vs. Design

During analysis, the analyst should be able to understand and document the requirements of the system in an unambiguous manner. The system analyst may consider the use cases and other requirements of the system, translate them into draft class diagram representing the classes (along with their attributes and responsibilities) and the relationship among these classes showing how the instances of these classes will interact with each other. Design is concerned about producing a solution based on the requirements that have been analysed. The draft class diagram is translated into design class diagram that can be used for construction of the system. The design class diagram will provide information regarding the type of attributes, return type of the methods (and may also provide information regarding the parameters to be passed to the methods). For example, with reference to the EZticket case study, analysis identifies that Customer has a reference_number as an attribute. This fact is documented in the class diagram. Then following are some of the examples of decisions that will be taken during design (with respect to the attribute reference_number): How will it be entered into the system How will it be displayed on the screen Where will it be stored, and How will it be stored together with the other attributes of the Customer class and other classes

87 | P a g e

8.3

Design of a system

The design itself is also an iterative process. Following are the advantages of using the iterative process for the development of a system: Complexity is not overpowering Early feedback is generated Suitable for systems that are prone to changes

Design of systems takes place at the following two levels: System design Detailed Design

System design refers to the overall architecture of the system and the setting of standards. Detailed design or object design refers to the design of objects and classes. Here, the types of attributes of the objects are defined. The attributes can be of primitive data types, derived data types and/or of type collection class (array, vector or hashtable).

88 | P a g e

8.4

Characteristics of good design

The quality of design depends on the quality of the analysis. To provide good basis for design, the analysis should meet the following four criteria:

Correct scope Completeness Correct content Consistency

Correct scope What is included in the system and what is not should be clearly defined. The required scope of the system should be clearly understood, documented and agreed with the customer. Also, everything that is in the analysis models, is within the scope of the system. Completeness Everything that is within the scope of the system, should be documented in the analysis models. Correct content The analysis document should describe correctly and accurately what it is describing. Consistency The analysis models such as use cases, classes, attributes or operations should be consistent. Quality of design affects the quality of the final system as well as the work of the programmers. Stated below are some characteristics of a good design: Functional the information system should provide all the desirable functionalities of the system.

89 | P a g e

Efficiency the system performs the required functionality efficiently in terms of both time and resources.

Economical the system should be economical in terms of the hardware cost, software cost and the running of the system.

Flexibility the system should be able to adjust to the changes in the business requirements as time passes.

Generality refers to the extent to which the system is general. Maintainability the system should be well-designed and documented so that it can be maintained easily and with lesser cost.

Reliability the system should not be prone to hardware / software failure and it should be able to preserve the integrity of the data reliably.

Manageability the design of the system should be able to provide roughly the correct estimation of the amount of work required in implementing the system.

Buildable the design should be clear and easily understandable so that programmers can easily write the code to build the system.

Satisfying and Productive the system should be satisfying as well as productive. Portal the system should be portable so that it can be run on different machines.

Secure the system should be secure against malicious attack by outsiders and by unauthorized internal users.

Reusability the system should be designed with less coupling and high cohesion so that the various components of the system can be reused easily.

90 | P a g e

8.5

Object-Oriented Cohesion and Coupling

Cohesion is the measure of how much the code in one unit relates to each other. A module is highly cohesive when all code in one module is designed to solve one problem. Coupling is the measure of how much interrelation is there among modules. When a module can be re-used without dragging along the other modules, it is said to be loosely coupled. Inheritance is an example of tight coupling where the super class also needs to dragged along to re-use the subclass. The basic goal is to design the modules that are highly cohesive and loosely coupled. This will enhance the module re-usability.

91 | P a g e

8.6

Design Patterns

Patterns are important aspects of re-use strategy within an organization. A pattern is an explanation of the approach that can be used to solve a type of problem. Related patterns are grouped together in catalogues. Patterns are intended to exemplify good design practice such as maximizing encapsulation wherever possible. Some of the key principles that lie behind patterns are: Abstraction Encapsulation Information hiding Modularization Coupling and cohesion Sufficiency and completeness Separation of interface and implementation

Etc. Patterns address the issues raised by non-functional requirements of a software architecture. The issues are: Efficiency Reliability Testability Reusability Changeability Interoperability

Patterns are categorized into the following three different categories based on their purposes: Creational Structural Behavioural

92 | P a g e

Creational patterns deal with object creation. The operation of an application is separated from how its objects are created. Structural patterns are concerned with how the classes and objects are organized in a class / object hierarchy. Structural patterns offer effective ways of using object-oriented constructs such as inheritance, aggregation to satisfy particular requirements. Behavioural patterns deal with the problems that arise when responsibilities are assigned to classes and in designing algorithms, i.e., behavioural patterns are about the collaboration between objects. Advantages of using patterns Enables reusability Helps in improving the developers communication

Disadvantages of using patterns Use of patterns can limit creativity Developers need to spend time to understand the pattern catalogues when a new approach to software development is introduced.

93 | P a g e

8.7

Exercise Questions

1. Differentiate between analysis and design. 2. What are the characteristics of a good analysis? 3. Discuss ten characteristics of a good design? 4. Define Cohesion and Coupling. 5. Name the two levels of the design of a system. Discuss these two levels. 6. Define patterns. What is the purpose of using patterns? 7. What are the three categories of patterns? Discuss each of these three categories.

94 | P a g e

Chapter 9: Human-Computer Interaction and Data Management Design

Upon completion of the chapter, you would be able to understand:

The importance and characteristics of a good user interface design Different approaches to user interface design Persistence Different ways of persisting objects How to design the relational database with object-oriented map

95 | P a g e

9.1

Introduction

Designing the user interface is important part of a system development as interface is what a user sees. For a user, it is the means of communicating with the system. In other words, interface is the system for users.

Real information systems require data to be stored so that the data can be retrieved later on to work with. Data can be stored or persisted in files, object-oriented database or relational database with object-oriented map.

Design patterns may be used to give an idea about how persistence can be designed into a system.

9.2

User Interface

User interface is designed to be developed for providing an interactive system to support users.

Users of an information system interact with the system to perform one or more of the following tasks:

Read and understand information that guides the users how to use the system Issue commands to the system to specify what the users want to do Input the data into the system Read and understand the output created by the system Respond to errors and correct them

The user interface should be easy to use, reliable and consistent.

96 | P a g e

9.3

Approaches to User Interface Design

Following are the three categories of approaches to user interface design:

Structured approaches Scenario-based approaches Ethnographic approaches

Only the first two categories of approaches are being discussed here.

All these approaches perform the following three steps in human-computer interaction design:

Requirements gathering Interface design Interface evaluation

The choice of the approach to design user interface is affected by the following factors:

nature of task that is being carried out by the user type of user amount of training that will be given to the user frequency of use hardware / software architecture of the system

97 | P a g e

A user-friendly software is essential to gain the confidence of users. The software should be thoroughly tested with respect to usability before deliverying it to the user. The usability refers to the following four criteria:

Learnability Throughput Flexibility Attitude

Learnability

The time and effort needed to achieve a particular level of performance.

Throughput

Speed with which experienced users can accomplish jobs and the number of errors made.

Flexibility

The capability of the system to handle changes to tasks that users carry out and the environment in which they operate.

Attitude

How positive an attitude is created in users of the system.

Structured Approaches

Structured approaches use data flow diagrams to model processes in the system, take a view of the system that involves decomposing it in a top-down manner. Structure charts or structure diagrams are used to design the programs that will implement the system.

98 | P a g e

Benefits of structured approaches

Easy management of projects Improved understanding among the project staff Improved quality of delivered systems

Scenario-based approaches

Design developed using scenario-based approaches less formal than that developed using structured approaches.

Scenarios are step-by-step descriptions of a users actions in the system under discussion. Scenarios are a way of communication between information systems professionals and end users about the design of the users interaction with the system.

Scenarios can be used in conjunction with the use cases. The difference between use cases and scenarios is that the use cases are concerned with the functionality of the desired system, while scenarios focus on the interaction between the user and the system.

9.4

Persistence

Storing the state of object even when the program is not live, i.e., not running, is called as persistence. When storing the state of object, we are not interested in storing the classes (the software construct) instead the focus is to store the values of attributes for the objects, i.e., attribute values form the persisted data. Persisted data is stored in secondary storage.

99 | P a g e

9.5

Forms of Persistence

Data can be persisted using any of the following three forms of persistence: Serialization into files Object Oriented Database Relational Database with object-oriented map

Serialization into files Data, i.e., attribute values are extracted from an object and are stored in a plain file. Advantages It is simple. It is cheap.

Disadvantages Serialization is a single-user solution. No locking or transaction handling.

Object-Oriented Databases Object-oriented databases make the object automatically persist. Upon creation, the objects are stored automatically in the database without the programmers effort. All retrieval and storage are handled transparently to the programmer. Advantages Less effort is required from the programmer. Most databases can provide full multi-user, locking, recovery, etc. OO Databases support the full data model of the language (e.g., inheritance, object reference, etc). Most useful for storing complex class models.

100 | P a g e

Disadvantages Not very common and widely used. Many full featured databases are expensive. Many do not have very good query languages or 4GL environments.

Relational database with object-oriented map Vast majority of databases in use today are relational / SQL based. Many businesses are using relational databases to store their data as well as applications that work with relational databases. Advantages Relational databases are in wide use and well understood.

Disadvantages Considerable programming effort is required for translating between objects and records. Relational model does not support many object-oriented constructs (e.g., inheritance) and so translation mapping is required.

101 | P a g e

9.6

Object / Relational Mapping

To use relational database with object-oriented map to persist objects, the class model needs to be mapped to relational model. A class model can be mapped to a relational model by mapping the classes, attributes, etc. Each object of the class is a record of the table.

Mapping Classes to Tables

Create a table for each class. The name of the table will be the same as is the name of the class. However, as in E-R models, every table in the relational model does not map to a class.

Mapping Attributes

The attributes of the class are mapped as the fields of the table with the same name and usually, type as the attributes of the class/object.

Mapping Relationships

102 | P a g e

A relationship is implemented as a foreign key (same way as is the case in E-R modelling). Consider the following guidelines for mapping relationship:

Implement foreign key on either side for implementing1-1-relationship.

Implement foreign key on the many side to implementing 1-M relationships.

To implement M-N relationships, hash tables can be used.

Mapping Inheritance

Following are the three different options available to implement inheritance:

Keep All Levels

Roll Up

Roll Down

103 | P a g e

Let us consider the following classes for the discussion of the above three methods of mapping inheritance:

Contract contractID contractDate commissionRate

Sale salePrice

Lease numberOfYears monthlyRent

Keep All Levels Represent every class in the inheritance hierarchy as a table. Use a common key to maintain the link between the super and sub-class tables so that objects can be rebuilt from their parts. Contract ContractID ContractDate CommissionRate Sale ContractID SalePrice Lease ContractID NumberOfYears MonthlyRent

104 | P a g e

Roll Up All attributes from the sub-classes are rolled up into the super-class. Then one table is used to represent the combined attributes of both the super as well as the sub-class objects. Usually, an extra field is needed to flag which type of object the row represents (i.e., which sub-class does it belong to). Contract ContractID ContractDate CommissionRate ContractType SalePrice NumberOfYears MonthlyRent

Roll Down All the attributes from the super-class are rolled down into each sub-class. Then a table is used to represent each sub-class. There is no table for thye super-class. Sale ContractID ContractDate CommissionRate SalePrice Lease ContractID ContractDate CommissionRate NumberOfYears MonthlyRent

105 | P a g e

9.7

Exercise Questions

1. Name the three categories of approaches to user-interface design. 2. Discuss and compare structured approaches and scenario-based approaches. 3. What are the three steps in the process of human-computer interaction design? 4. Define persistence. 5. What are the three forms of persistence? 6. Map the class diagram of EZticket to three different relational models using the following methods to map inheritance to relations: a. Keep All Levels b. Roll Up c. Roll Down

106 | P a g e