[PDF] [PDF] Object Oriented System Analysis and Design (OOSAD)

[PDF] Object-Oriented Analysis & Design - Tutorialspoint

About the Tutorial This tutorial will help you understand the basics of object- oriented analysis and design understanding of computer programming and related programming paradigms Copyright Table of Contents About the The main difference between object-oriented analysis and other forms of analysis is that

[PDF] Chapter 5 Object-oriented Analysis and Design

and Design Table of Contents of object-oriented analysis and design, and its mastery is crucial for anyone who intends to use object- oriented techniques form a different standpoint, as will be discussed further below Modelling 

[PDF] OBJECT-ORIENTED ANALYSIS AND DESIGN

However, there are five major differences between this edition and the We first present a graphic notation for object-oriented analysis and design, As with the structure of a computer, the parts of a plant form a hierarchy, In this manner, our implementation encapsulates two secrets: the use of an open hash table

[PDF] Object-Oriented Analysis, Structured - University of Twente

Keywords: Object-oriented analysis and design 1 useful, first, for showing the difference between these models Second Table 1: Objects in the CBM UoD

[PDF] Object Oriented System Analysis and Design (OOSAD)

Chapter 6: Determining How to Build Your System: OO Design The main difference between object-oriented analysis and other forms of analysis is that in To map inheritance, the primary key of the base table(s) is assigned as the primary 

[PDF] Object-oriented and conventional analysis and design

oriented analysis (OOA) and object-oriented design (OOD) methodol- ogies have begun Let there be no doubt that object-oriented design is fundamentally different from traditional Data-structure diagram - Shows data structures in a format appropriate Table 1 Comparison of analysis methodologies Bailin Coad and

[PDF] Object-Oriented Analysis And Design With Applications - Caribbean

27 jan 2021 · Thank you very much for reading Object-Oriented Analysis and Design with Applications use different design notations With UML and the Objects also form the basis for many web Table of Contents 1 Introduction Part 

[PDF] difference between primary and secondary school in india

[PDF] difference between primary and secondary sources

[PDF] difference between primary secondary and tertiary alcohol

[PDF] difference between primary secondary and tertiary health care

[PDF] difference between primary secondary and tertiary sector

[PDF] difference between primary secondary and tertiary sources

[PDF] difference between procedural and object oriented programming

[PDF] difference between school and university

[PDF] difference between secondary and high school

[PDF] difference between secondary education and higher education

[PDF] difference between skills and qualities examples

[PDF] difference between standard and calibrator in biochemistry

[PDF] difference between static and dynamic methods in java

[PDF] difference between static and dynamic variables in java

[PDF] difference between static and instance methods in c#

OOSAD Module Page 1

Ambo University, Woliso Campus

School of Technology and Informatics

Department of Information Systems

Object Oriented System Analysis and Design

(OOSAD)

COMPILED BY: HABTAMU KENO

DEPARTMENT OF INFORMATION SYSTEMS

3, June, 2O

WOLISO, ETHIOPIA

OOSAD Module Page 2

Contents

Chapter 1: Understanding the Basics: Object oriented concepts ................................................................. 4

1.1 A Brief History ................................................................................................................................. 4

1.2. Object-Oriented Analysis ............................................................................................................... 4

1.3. Object-Oriented Design .................................................................................................................... 4

1.4. INTRODUCTION ............................................................................................................................ 5

1.4.1. THE OBJECT MODEL ................................................................................................................. 5

1.4.2.Object-Oriented Programming ....................................................................................................... 5

1.5. Benefits of Object Model ................................................................................................................ 10

3. OBJECT-ORIENTED SYSTEM ........................................................................................................... 10

1.6. OBJECT-ORIENTED PRINCIPLES .............................................................................................. 11

1.7.OBJECT-ORIENTED ANALYSIS ................................................................................................. 13

Chapter Two: Object Orientation the new software paradigm .................................................................. 19

2. Structured vs. Object Orientation paradigm ...................................................................................... 19

2.1. The Potential Benefits of the Object Oriented paradigm ................................................................ 19

2.2. The Potential Drawbacks of OO ..................................................................................................... 20

2.3. Object Standards ............................................................................................................................. 21

Chapter 3: Gathering user requirements .................................................................................................... 22

3. An Overview of Requirements Elicitation ......................................................................................... 22

3.1. Requirements elicitation includes the following activities: ............................................................ 22

3.2. Requirements Elicitation Concepts In this section, we describe the main requirements elicitation

concepts used in this chapter. In particular, we describe ....................................................................... 23

3.3. Functional Requirements ................................................................................................................ 23

3.4. Nonfunctional Requirements .......................................................................................................... 24

3.5. Fundamental requirements gathering techniques ............................................................................ 25

Chapter 4: Ensuring Your Requirements are Correct: Requirement validation Techniques ..................... 26

4. Requirements Validation ................................................................................................................... 26

4.2. The 6 Principles of Validation ........................................................................................................ 26

4.3. Validation Techniques .................................................................................................................... 27

Chapter 5: Determining What to Build: OO Analysis .............................................................................. 29

5.1. Overview of Analysis artefacts and their Relationships ................................................................. 29

5.2. The Unified Modeling Language (UML) ....................................................................................... 31

5.3. UML BASIC NOTATIONS ......................................................................................................... 33

5.4. UML STRUCTURED DIAGRAMS ............................................................................................. 35

5.5. UML BEHAVIORAL DIAGRAMS .............................................................................................. 38

Chapter 6: Determining How to Build Your System: OO Design ............................................................. 42

6.1. System Design ................................................................................................................................ 42

6.2. Object-Oriented Decomposition ..................................................................................................... 42

OOSAD Module Page 3

6.2.1 Identifying Concurrency ........................................................................................................... 42

6.2.2. Identifying Patterns .................................................................................................................. 43

6.2.3. Controlling Events ................................................................................................................... 43

6.2.4. Handling Boundary Conditions ............................................................................................... 43

6.3. Object Design ................................................................................................................................. 43

6.3.1. Object Identification ................................................................................................................ 44

6.3.2. Object Representation .............................................................................................................. 44

6.3.3. Classification of Operations ..................................................................................................... 44

6.3.4. Algorithm Design .................................................................................................................... 44

6.3.7. Packaging Classes .................................................................................................................... 45

6.4. Design Optimization ....................................................................................................................... 46

6.5. IMPLEMENTATION STRATEGIES ............................................................................................ 47

Chapter seven : Software Testing .............................................................................................................. 51

7.1 TESTING AND QUALITY ASSURANCE .................................................................................... 51

7.1.1. Testing Object-Oriented Systems ............................................................................................ 51

7.1.2. Unit Testing ............................................................................................................................. 51

7.1.3. Subsystem Testing ................................................................................................................... 51

7.1.4.System Testing .......................................................................................................................... 51

7.2. Categories of System Testing ......................................................................................................... 51

7.3. Object-Oriented Testing Techniques .............................................................................................. 51

7.4. Techniques for Subsystem Testing ................................................................................................. 52

7.5. The Full-Lifecycle Object-Oriented Testing (FLOOT) .................................................................. 52

7.6.Software Quality Assurance ............................................................................................................ 53

7.6.1. Quality Assurance .................................................................................................................... 54

7.6.2. Quality Factors ......................................................................................................................... 54

Chapter 8: Software Process ...................................................................................................................... 55

8.1. Process ............................................................................................................................................ 55

8.2. Software Process ......................................................................................................................... 55

8. 3. Processes and Process Models ....................................................................................................... 55

8.3.1. Component Software Processes ............................................................................................... 56

8.3.2.ETVX Approach for Process Specification .............................................................................. 57

8.3.3.Characteristics of Software Process .......................................................................................... 57

8.4. Software Development Process Models ......................................................................................... 59

Advantages of Prototyping .................................................................................................................... 61

Limitations of Prototyping ..................................................................................................................... 61

8.4.1. Project Management Process ................................................................................................... 63

8.4.2. Process Management ............................................................................................................... 66

8.5. The Unified Process ........................................................................................................................ 67

OOSAD Module Page 4

Chapter 1: Understanding the Basics: Object oriented concepts

1.1 A Brief History

The object-oriented paradigm took its shape from the initial concept of a new programming approach, while the interest in design and analysis methods came much later. ¾ The first objectoriented language was Simula (Simulation of real systems) that was developed in 1960 by researchers at the Norwegian Computing Center. ¾ In 1970, Alan Kay and his research group at Xerox PARK created a personal computer named Dynabook and the first pure object-oriented programming language (OOPL)-

Smalltalk, for programming the Dynabook.

¾ In the 1980s, Grady Booch published a paper titled Object Oriented Design that mainly presented a design for the programming language, Ada. In the ensuing editions, he extended his ideas to a complete object oriented design method. In the 1990s, Coad incorporated behavioral ideas to object-oriented methods. The other significant innovations were Object Modelling Techniques (OMT) by James Rumbaugh and Object-Oriented Software Engineering (OOSE) by Ivar Jacobson.

1.2. Object-Oriented Analysis

ObjectOriented Analysis (OOA) is the procedure of identifying software engineering ct model, which comprises of interacting objects. The main difference between object-oriented analysis and other forms of analysis is that in object-oriented approach, requirements are organized around objects, which integrate both data and functions. They are modelled after real-world objects that the system interacts with. In traditional analysis methodologies, the two aspects - functions and data - are considered separately. Grady Booch has defined OOA as, -oriented analysis is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary The primary tasks in object-oriented analysis (OOA) are:

¾ Identifying objects

¾ Organizing the objects by creating object model diagram ¾ Defining the internals of the objects, or object attributes ¾ Defining the behavior of the objects, i.e., object actions

¾ Describing how the objects interact

The common models used in OOA are use cases and object models.

1.3. Object-Oriented Design

ObjectOriented Design (OOD) involves implementation of the conceptual model produced during object-oriented analysis. In OOD, concepts in the analysis model,which are onto implementing classes, constraints are identified and

OOSAD Module Page 5

interfaces are designed, resulting in a model for the solution domain, i.e., a detailed description of how the system is to be built on concrete technologies.

The implementation details generally include:

¾ Restructuring the class data (if necessary),

¾ Implementation of methods, i.e., internal data structures and algorithms,

¾ Implementation of control, and

¾ Implementation of associations.

Grady Booch has defined object- a method of design encompassing the process of object-oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the system under design

1.4. Introduction

Object-oriented analysis and design (OOAD) is a software engineering approach that models a system as a group of interacting objects. Each object represents some entity of interest in the system being modeled, and is characterised by its class, its state (data elements), and its behavior. Various models can be created to show the static structure, dynamic behavior, and run-time deployment of these collaborating objects. There are a number of different notations for representing these models, one such model is Unified

Modeling Language (UML).

1.4.1. THE OBJECT MODEL

Object oriented development offers a different model from the traditional software development approach, which is based on functions and procedures. ¾ An Object-Oriented environment, software is a collection of discrete objects that encapsulate ¾ Object are defined, it will perform their desired functions and seal them off in our mind like black boxes. ¾ The object- Oriented life cycle encourages a view of the world as a system of cooperative and collaborating agents. ¾ An objective orientation producers system that are easier evolve, move flexible more robust, and more reusable than a top-down structure approach. ¾ An object orientation allows working at a higher level of abstraction. ¾ It provides a seamless transition among different phases of software development.

¾ It encourages good development practices.

¾ It promotes reusability.

The unified Approach (UA) is the methodology for software development proposed and used and the following concepts consist of Unified Approach

1.4.2.Object-Oriented Programming

Object-oriented programming (OOP) is a programming paradigm based upon objects (having both data and methods) that aims to incorporate the advantages of modularity and reusability. Objects, which are usually instances of classes, are used to interact with one another to design applications and computer programs. The important features of objectoriented programming are:

¾ Bottom up approach in program design

¾ Programs organized around objects, grouped in classes

OOSAD Module Page 6

¾ Interaction between objects through functions ¾ Reusability of design through creation of new classes by adding features to existing classes Some examples of object-oriented programming languages are C++, Java, Smalltalk, Delphi,

C#, Perl, Python, Ruby, and PHP.

Grady Booch has defined objectoriented programming as implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united

OBJECT MODEL

The object model visualizes the elements in a software application in terms of objects. In this chapter, we will look into the basic concepts and terminologies of objectoriented systems.

Objects and Classes

The concepts of objects and classes are intrinsically linked with each other and form the

foundation of objectoriented paradigm.

Object

An object is a real-world element in an objectoriented environment that may have a physical or a conceptual existence. Each object has: ¾ Identity that distinguishes it from other objects in the system. ¾ State that determines the characteristic properties of an object as well as the values of the properties that the object holds. ¾ Behavior that represents externally visible activities performed by an object in terms of changes in its state. Objects can be modeled according to the needs of the application. An object may have a physical existence, like a customer, a car, etc.; or an intangible conceptual existence, like a project, a process, etc. Class

A class represents a collection of objects having same characteristic properties that exhibit

common behavior. It gives the blueprint or description of the objects that can be created from it. Creation of an object as a member of a class is called instantiation. Thus, object is an instance of a class.

The constituents of a class are: ¾ A set of attributes for the objects that are to be instantiated from the class. Generally, different objects of a class have some difference in the values of the attributes. Attributes are often referred as class data. ¾ A set of operations that portray the behavior of the objects of the class. Operations are also referred as functions or methods.

Example

Let us consider a simple class, Circle, that represents the geometrical figure circle in a two dimensional space. The attributes of this class can be identified as follows:

¾ xcoord, to denote xcoordinate of the center

¾ ycoord, to denote ycoordinate of the center

¾ a, to denote the radius of the circle

Some of its operations can be defined as follows:

¾ findArea(), method to calculate area

¾ findCircumference(), method to calculate circumference ¾ scale(), method to increase or decrease the radius

During instantiation, values are assigned for at least some of the attributes. If we create an object

my_circle, we can assign values like x-coord : 2, y-coord : 3, and a :4 to depict its state. Now, if

OOSAD Module Page 7

the operation scale() is performed on my_circle with a scaling factor of 2, the value of the variable a will become 8. This operation brings a change in the state of my_circle, i.e., the object has exhibited certain behavior.

Encapsulation and Data Hiding

Encapsulation

Encapsulation is the process of binding both attributes and methods together within a class. Through encapsulation, the internal details of a class can be hidden from outside. It permits the elements of the class to be accessed from outside only through the interface provided by the class.

Data Hiding

Typically, a class is designed such that its data (attributes) can be accessed only by its class called data hiding or information hiding.

Example

In the class Circle, data hiding can be incorporated by making attributes invisible from outside the class and adding two more methods to the class for accessing class data, namely: ¾ setValues(), method to assign values to x-coord, y-coord, and a ¾ getValues(), method to retrieve values of x-coord, y-coord, and a Here the private data of the object my_circle cannot be accessed directly by any method that is not encapsulated within the class Circle. It should instead be accessed through the methods setValues() and getValues().

Message Passing

Any application requires a number of objects interacting in a harmonious manner. Objects in a system may communicate with each other using message passing. Suppose a system has two objects: obj1 and obj2. The object obj1 sends a message to object obj2, if obj1 wants obj2 to execute one of its methods.

The features of message passing are:

¾ Message passing between two objects is generally unidirectional. ¾ Message passing enables all interactions between objects. ¾ Message passing essentially involves invoking class methods. ¾ Objects in different processes can be involved in message passing.

Inheritance

Inheritance is the mechanism that permits new classes to be created out of existing classes by extending and refining its capabilities. The existing classes are called the base classes/parent classes/super-classes, and the new classes are called the derived classes/child classes/subclasses. The subclass can inherit or derive the attributes and methods of the super-class(es) provided that the super-class allows so. Besides, the subclass may add its own attributes and methods and may modify any of the super-quotesdbs_dbs20.pdfusesText_26