OOAD-Ali Bahrami

MCA(DISTANCE MODE)

DMC 1753

OBJECT ORIENTED ANALYSIS AND DESIGN

IV SEMESTER

COURSE MATERIAL

Centre for Distance EducationAnna University Chennai

Chennai – 600 025

Author

DrDrDrDrDr.G.G.G.G.G.V.V.V.V.V.Uma.Uma.Uma.Uma.UmaAssistant Professor

Department of Computer Science and EngineeringAnna University Chennai

Chennai - 600 025

Reviewer

DrDrDrDrDr.K.S.K.S.K.S.K.S.K.S.Eas.Eas.Eas.Eas.Easwwwwwararararara Ka Ka Ka Ka Kumarumarumarumarumar Professor


Chennai - 600 025

DrDrDrDrDr.T.T.T.T.T.V.V.V.V.V.Geetha.Geetha.Geetha.Geetha.GeethaProfessor


Chennai - 600 025

DrDrDrDrDr.H.P.H.P.H.P.H.P.H.Peereereereereeru Mohamedu Mohamedu Mohamedu Mohamedu MohamedProfessor

Department of Management StudiesAnna University Chennai

Chennai - 600 025

DrDrDrDrDr.C.C.C.C.C. Chella. Chella. Chella. Chella. ChellappanppanppanppanppanProfessor


Chennai - 600 025

DrDrDrDrDr.A.K.A.K.A.K.A.K.A.KannanannanannanannanannanProfessor


Chennai - 600 025

Copyrights Reserved(For Private Circulation only)

Editorial Board

ACKNOWLEDGEMENT

The author is deeply indebted to many people who, directly or indirectly are responsible for this course

material coming into being. The author is most grateful for the Director & Deputy Directors of Centre for Distance

Education, Anna University, Chennai. The author thanks the reviewer for critical comments for the betterment of

the course material.

The author thanks the following resources for course material preparation.

1. Ali Bahrami, “Object Oriented System Development” McGraw Hill International edition, 1999.

2. Craig Larman, “Applying UML and Patterns”, 2nd edition, Pearson, 2002.

3. Grady Booch, James Rambaugh, Irar Jacobson, “The Unified Modeling Language User guide, Addison

Wesley Longman, 1999.

Dr.G.V.Uma

Author

DMC 1753 OBJECT ORIENTED ANALYSIS AND DESIGN

I. INTRODUCTION

An overview – Object basics – Object state and properties – Behavior – Methods – Messages – Information

hiding – Class hierarchy – Relationships – Associations – Aggregations- Identity – Dynamic binding – Persistence

– Metaclasses – Object oriented system development life cycle.

II. METHODOLOGY AND UML

Introduction – Survey – Rumbugh, Booch, Jacobson methods – Patterns – Frameworks – Unified approach –

Unified modeling language – Static and Dynamic models – UML diagrams – Class diagram – Usecase diagrams

– Dynamic modeling – Model organization – Extensibility.

III. OBJECT ORIENTED ANALYSIS

Identifying Usecase – Business object analysis – Usecase driven object oriented analysis – Usecase model –

Documentation – Classification – Identifying object, relationships, attributes, methods – Super-sub class – A part

of relationships Identifying attributes and methods – Object responsibility

IV. OBJECT ORIENTED DESIGN

Design process – Axions – Colollaries – Designing classes – Class visibility – Refining attributes – Methods and

protocols – Object storage and object interoperability – Databases – Object relational systems – Designing

interface objects – Macro and Micro level processes – The purpose of a view layer interface

V. SOFTWARE QUALITY

Quality assurance – Testing strategies – Object orientation testing – Test cases – Test Plan – Debugging principles

– Usability – Satisfaction – Usability testing – Satisfaction testing

TEXT BOOKS

1) Ali Bahrami, “Object Oriented System Development”, McGraw Hill International Edition, 1999.

REFERENCES

1) Craig Larman, “Applying UML and Patterns”, 2nd Edition, Pearson, 2002.

2) Grady Booch, James Rumbaugh, Ivar Jacobson, “The Unified Modeling Language User Guide”, Addison

Wesley Long man, 1999.

3) Bernd Bruegge, Allen H. Dutoit, “Object Oriented Software Engineering using UML, Patterns and Java”,

Pearson, 2004.

i

CONTENTS

UNIT IINTRODUCTION

1.1 THE OBJECT MODEL 1

1.2 THE ELEMENTS OF AN OBJECT MODEL 2

1.3 OBJECTS CAN HAVE THE FOLLOWING PROPERTIES 2

1.4 COMPLEXITY AND CLASSIFICATION OF CLASSES AND

OBJECTS 4

1.5 CLASS INTERFACE NOTATION 7

1.5.1 Binary Association Notation 7

1.5.2 Qualifier 9

1.5.3 Binary and Entity Relationship 9

1.5.4 Ex Diagram Notation 10

1.6 ENTITY-RELATIONSHIP DIAGRAM 10

1.7 AN EXPANDED ERD 12

1.8 OBJECT ORIENTED SYSTEM DEVELOPMENT LIFE CYCLE 14

1.8.1 The software development process 14

1.9 THE WATERFALL SOFTWARE DEVELOPMENT PROCESS 16

1.10 BUILDING HIGH – QUALITY SOFTWARE 17

1.11 OBJECT – ORIENTED ANALYSIS USE CASE DRIVEN 19

1.12 COMPONENT BASED DEVELOPMENT 20

1.13 RAPID APPLICATION DEVELOPMENT 20

UNIT IIMETHODOLOGY AND UML

2.0 OVERVIEW OF OBJECT ORIENTED ANALYSIS –

SHALEER AND MELLOR 23

2.1 THE OOA MODELS 23

2.2 THE DYNAMIC MODEL 25

2.3 THE FUNCTIONAL MODEL 26

2.4 INTERACTION BETWEEN THE MODELS 27

2.5 ANALYSIS PROCESS 28

2.6 BALANCE SHEET FOR OOA 30

2.7 OBJECT – ORIENTED ANALYSIS/DESIGN 30

2.8 OOA/OOD PROPOSED A MODELING PROCESS BASED

ON FIVE LEVELS OF SPECIFICATION 31

2.9 BALANCE SHEET FOR OOA/OOD 32

2.10 OBJECT ORIENTED ANALYSIS – RUMBAUGH 33

2.11 GENERAL METHODOLOGICAL PROCEDURE 37

2.12 BALANCE SHEET FOR OMI 38

2.13 OOD – (G. BOOCH) 38

2.14 THE DESIGN PROCESS 42

2.15 UML- UNIFIED MODELING LANGUAGE 43

2.16 RELATIOPNSHIPS IN THE UML 48

2.17 RULES OF UML 50

2.18 EXTENSIBILITY MECHANISMS 52

2.19 OVERVIEW OF UML 58

UNIT –IIIOBJECT ORIENTED ANALYSIS

3.0 OBJECT ORIENTED DESIGN METHODS 61

3.1 STRUCTURAL DIAGRAMS 61

3.2 BEHAVIOR DIAGRAMS 62

3.3 STRUCTURE AND BEHAVIOR 64

3.4 COMMON MODELING TECHNIQUES 65

3.5 MODELING THE REALIZATION OF AN OPERATION 65

3.6 SEQUENCE 65

3.7 COMMON MODELING TECHNIQUES 71

3.8 MODELING DESIGN PATTERNS 72

3.8.1 Modeling Architectural Pattern 72

3.9 DESIGN THE VIEW LAYER CLASSES 74

3.10 OBJECTS ORIENTED DESIGN AXIOM 74

UNIT IVOBJECT ORIENTED DESIGN

4.0 MANAGING ANALYSIS AND DESIGN 77

4.1 USE CASES 77

4.2 APPROACHES FOR IDENTIFYING CLASSES 79

4.2.1 Noun Phrase Approach 79

ii

4.2.2 Selecting classes from the relevant and fazzy categories 80

4.3 COMMON CLASS PATTERNS APPROACH 80

4.4 OBJECT RELATIONSHIPS, ATTRIBUTES, AND METHODS 81

4.5 ASSOCIATION PATTERNS 81

4.6 ELIMINATION OF UNNECESSARY ASSOCIATION 81

4.7 RELATIONSHIPS 82

4.8 CLASS AND OBJECT RESPONSIBILITIES 83

4.9 CHARACTERISTICS OF CLASSES AND OBJECT 84

4.10 OBJECT-ORIENTED DESIGN PROCESS 85

4.11 AXIOMS OF OBJECT-ORIENTED DESIGN 86

4.12 COUPLING 87

4.13 DESIGN PATTERNS 88

4.14 CLASS VISIBILITY 89

4.15 UML ATTRIBUTES PRESENTATION 90

UNIT VSOFTWARE QUALITY

5.0 QUALITY ASSURANCE TESTS 93

5.1 TESTING STRATEGIES 93

5.2 SYSTEM TESTING 94

5.3 UNIT TESTING 94

5.4 INTEGRATION TESTING 95

5.5 VALIDATION TESTING 97

5.6 TEST PLANS 97

5.7 STEPS TO CREATE A TEST PLAN 98

5.8 TEST CASE 99

5.9 DEBUGGING PRINCIPLE 100

5.10 CODING 101

5.11 MAINTENANCE 102

5.12 TYPICAL CATEGORIES IN THE FOLLOWING PHASES 104

5.13 SOFTWARE CONTINUATION MANAGEMENT 104

5.14 THE DISTINGUISHING CHARACTERISTIC 105

iii


NOTES

1 ANNA UNIVERSITY CHENNAI

UNIT I

INTRODUCTION

Object-oriented analysis and design (OOAD) is a software engineering approachthat models a system as a group of interacting objects. Each object represents some entityof interest in the system being modeled, and is characterised by its class, its state (dataelements), 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 anumber of different notations for representing these models, one such model is UnifiedModeling Language (UML).

1.1 THE OBJECT MODEL

• Object oriented development offers a different model from the traditional softwaredevelopment approach, which is based on functions and procedures.

• An Object-Oriented environment, software is a collection of discrete objects thatencapsulate their data and the functionality to model real world “Objects”.

• Object are defined, it will perform their desired functions and seal them off in ourmind like black boxes.

• The object- Oriented life cycle encourages a view of the world as a system of co-operative and collaborating agents.

• An objective orientation producers system that are easier evolve, move flexiblemore 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 proposedand used and the following concepts consist of Unified Approach

DMC 1753

NOTES


1. Uses-case driven development.2. Utilizing the unified modeling language for modeling.3. Object-Oriented analysis where it utilizing we case and object modeling.4. Object-Oriented design5. Responsibilities of reusable classes and maximum reuse.6. The layered approach.7. Incremental development and prototyping.8. Continuous testing.

1.2 THE ELEMENTS OF AN OBJECT MODEL

The elements of an object model are classes and objects, attributes, operations andmessages.

Classes and Objects

Class: A class is the definition of the behavior and properties of one or more objectswithin the system. A class binds the data (attributes) of an object to the behavior (operations)that it can perform.

Objects: An object is an instance or specific example of a class. The attributes of theclass have specific values within an object of that class; and the operations of a classoperate on the attributes of individual objects.

Attributes: An attribute is a data value or state that describes an object and helpsyou to tell one object from another of the same class.

Operations: An operation is a behavior or function that an object can perform

1. If the objects are required to implement a solution, then it is part of the solutionspace.

2. If the object is necessary only to describe a solution, it is part of the problemspace.

1.3 OBJECTS CAN HAVE THE FOLLOWING PROPERTIES

1. External Entities

That produces or consumes information to be used by a computer-based system.E.g. Other systems, devices, people.

2. Things

Those are part of the information domain for the problem. E.g. Reports, Displays,Letters and Signals.

3. Occurrences

• It is otherwise known as events.

• That occurs within the context of system operation.

• E.g A property transfer or the completion of series of robot movement


NOTES


4. Roles

It played by people who interact with the system.

Ex. Manager, Engineer, Sales Person.

5. Organization units

Those are relevant to an application. Ex. Division, Group, Team.

6. Places

That establishes the context of the problem and the overall function of the system.E.G. Manufacturing floor

7. Structures

That defines a class of objects (or) in the extreme, related classes of objects.

In which coad and Yourdon suggest six selection characteristics that should be usedby an analyst. Each potential object for inclusion in the analysis model is given below:

1. Retained Information

The potential object will be useful during analysis only if information about it must beremembered so that the system can function.

2. Needed Services

The potential object must have a set of identifiable operations that can change thevalue of its attributes in some way.

3. Multiple Attributes

• During requirement analysis, the focus should be on “Major” Information.

• An object with a single attribute may in fact be useful during design.

• But is probably better represented as an attribute of another object during theanalysis activity.

4.Common Attribute

A set of attributes can be defined for the potential object and these attributes apply toall occurrences of the object.

5.Common Operations

A set of operations can be defined for the potential object and these operations applyto all occurrences of the object.

6. Essential requirements:

External entities that appear in the problem space and produce (or) consumeinformation that is essential to the operation of any solution for the system will almostalways be defined as objects in the requirements model.

DMC 1753

NOTES


1.4 COMPLEXITY AND CLASSIFICATION OF CLASSES AND OBJECTS

1. The object is utilized in the similar language2. The object typically existed in similar programs to stimulate some aspect of reality.3. The term object means a combination of data and logic that some real world

entity.4. The data is the part of this object.5. The Logic part of the object could be a collection of programs.

Notation

Object Properties

1. Classes are used to distinguish one type of object form another.

2. In the context of object – oriented systems a class is a set of objects that share acommon structure and a common behavior.

3. A single object is simply an instance of a class.

4. A class is a specification of structure is instances variables.

5. Behavior is methods and instances variables.

6. Classes are an important mechanism for classifying objects.

7. Class is to define the properties and procedures.

8. In an object – its class defines oriented system, a method or behavior of an object.

9. Every object of a given class has the same data format and responds to the sameinstructions.

Attributes: Object state and properties

1. Properties represent the state of an object.

2. Example: The properties of a car, such as color, manufacturer and cost, are abstractdescriptions.

The attributes of a car object is given in the Fig1.1

Fig1.1 Attributes of the car

Car

Cost Color Make Model


NOTES


The importance of this distinction is that an object’s abstract state can be independentof its physical representation. The Object Behavior and Methods are discussed below:Each of the statements is a description of the object’s behavior. In the object model,object behavior is described in methods or procedures. E.g. we can drive a car, we canride an elephant (or) elepthant can eat a peanut. A method implements the behavior of anobject. Basically a method is a function (or) procedure that is defined for a class. Typicallywe can access the internal state of an object of that class to perform some operation.Behavior denotes the collection of methods that abstractly describes what an object iscapable of doing. Each procedure defines and describes a particular behavior of an object.The office, called the receiver, is that on which the method operates. Methods encapsulatethe behavior of the objects provide interfaces to the object and hide any of the internalstructures and states maintained by the object. Procedures provide us the means tocommunicate with an object and access its properties.

The Object Process is given below:

1. Object’s capabilities are determined by the methods.

2. Objects perform operations in response to message.

3. For example, when you press on the brake pedal of a car. You send a stop messageto the car object.

4. The car object knows how to responds to the stop message.

5. Sending the dame stop message to a different object, such as tree, however, wouldbe meaningless and could result in an unanticipated response.

6. Messages essentially are nonspecific function calls.

7. A message is different from a subroutine call.

8. Since different objects can respond to the same message objects can respond tothe same message in different ways.

9. For example: Cars, Motorcycles and bicycles will all respond to a stop messagebut actual operations performed are object specific.

10. For examples: We send a brake message to the case object is top example.

11. We send a multiplication to 5 objects following by the number by which we wantto multiply.

12. Compute payroll message is sent to the Employee objects, where the employeeobjects know show to respond to the payroll message.

13. If the different object can responds to the same message in different ways. This isknown as polymorphism.

Encapsulation

Encapsulation is the containment of the object inside a “Capsule”. The termencapsulation is often used interchangeably with information hiding and the user cannot

DMC 1753

NOTES


see inside the capsule but they can use the object by calling the program part of it. Acommon use of information hiding is to hide the physical storage layout for data so that if itis changed, the change is restricted to a small subset of the total program.

Encapsulation Leakage

1. It occurs when details is about a class’s internal implementation are disclosedthrough the interface.

2. An object is said to encapsulate the data and a program.

3. This means that the user cannot wee inside of the object “Capsule”.

4. Encapsulation (or) information hiding is a design goal of an object-oriented system.

5. Allowing an object direct access to another object’s data, a message is sent to metarget object requesting information.

6. Data abstraction is a benefit of the object-oriented concept that incorporatesencapsulation and polymorphism.

Notation:

Class Notation:

The Fig 1.2 shows the sample class with attributes and methods.

• A class is drawn as a rectangle with three components separated by horizontallines and for example , name of the class is Boeing 737.

• In class notation, either or both the attributes and operation components may besuppressed.

• The top name compartments hold the class name, other general properties of theclass. Such as attributes are in the middle compartment.

• The bottom compartment holds a list of operation.

• Either (or) both the attribute and operation compartments may be suppressed.

• A separator line is not drawn for a missing compartments it a compartment issuppressed.

• No inference can be drawn about the presence or absence of elements in it.

• A static object diagram is an instance of a class diagram.

• Notation is the same for an object diagram and a class diagram.

• Class diagrams can contain objects. They are Length , Fuel etc.Lift() , Break() aremethods used in the class.

• A class diagram with object and no classes is an object diagram.


NOTES


Fig 1.2 Sample class

1.5 CLASS INTERFACE NOTATION

• Class interface notation is used to describe the externally visible behavior of aclass.

• Example, an operation with public visibility.

• Identifying class interfaces is a design activity of object-oriented system development

• The UML notation for an interface is a small circle with the name of the interfaceconnected to the class.

• A class that requires the operations in the interface may be attached to the circleby a dashed arrow.

The dependent class is not required to actually use all of the operation

Fig 1.3 Class interface notation

1.5.1 Binary Association Notation

• A binary association is drawn as a solid path connecting two classes or both endsmay be connected to the same class which is represented in Fig 1.4.

An association may have an association name.

Boeing 737 Boeing 737

Boeing 737

Length meter

Fuel capacity

Gold works

Ink

Length meter

Fuel capacity

Galdoors:

Lift ()

Break ()

Ink;

Person

Bank Account

DMC 1753

NOTES


Association Notation

• The association name may have an optional back triangle in it, which is illustratedin Fig1.5.

• The point of the triangle indicating the direction in which to read the name.

• The end of an association, where it connects to a class is called the associationrole.

• Each object is an instance of the class.

• Classes are organized hierarchically in a class tree, and subclasses inherit thebehavior of their super classes.

• Good object oriented programming uses encapsulation and polymorphism, whichwhen used in the definition of classes.

• Objects have a lifetime.

• They are explicitly created and exist for a period of time.

• That traditionally, has been the duration of the process for which they were created.

• A file (or) a database can provide support for objects having a longer lifetimelonger than the duration of the process for which they well created.

BankAccount Person

Fig 1.5 – Association notation

Company PersonworksFor

employer employee

Person

marriedTo

Fig 1.4 – Binary association notation


NOTES


1.5.2 Qualifier

• Qualifier is an association attribute. For example, a person object may beassociated to a Bank object.

• An attribute of this association is the account#.

• The account# is the qualifier of this association

1.5.3 Binary and Entity Relationship

• The entity – relationship diagram focuses solely on data, representing a “datanetwork” that exists for a given system.

• The ERD is especially useful for application in which data and the relationshipsthat given a data are complex.

• Unlike the data flow diagram, data modeling considers data independently of theprocessing that transforms the data.

• The Object-relationship pair is the cornerstone of the data model.

• These pairs can be represented graphically using the entity relationship diagram(ERD).

• The ERD was originally proposed for the design of relational database system andhas been extended by others.

• A set of primary components is identified for the ERD. Data objects, attributes,relationships and various types indicators.

• The primary purpose of the ERD is to represent data objects and their relationships.

*

0..1

Bank

Account#

person

Fig 1.6 Qualifier notation

DMC 1753

NOTES


1.5.4 Ex Diagram Notation

1.6 ENTITY-RELATIONSHIP DIAGRAM

Entity-relationship model (ERM) is an abstract conceptual representation of structureddata. Entity-relationship modeling is a relational schema database modeling method,used in software engineering to produce a type of conceptual data model (or semanticdata model) of a system, often a relational database, and its requirements in a top-downfashion. Diagrams created using this process are called entity-relationship diagrams, orER diagrams or ERDs for short.

Symbol description Entity Attribute Key attribute Multivalued Composite attribute Weak Entity Relationship N 1 Many to one relationship Total Participation of E2 iNR

Student

Lab assistant

day mon

n year

Date

smark Student

LAB

Student Reg.no

E1 R E2


NOTES


• The object-relationship pair is the cornerstone of the data model.

• These pairs can be represented graphically using the entity relationship diagram(ERD).

• The ERD was originally proposed by peter Chen for the design of relational databasesystems and has been extended by others.

• A set of primary components are identified for the ERD data Objects, attributes,relationships and various type indicators.

• The primary purpose of the ERD is to represent data objects and their relationships.

Cardinality and modality

The Fig 1.7 shows the cardinality and modality ration of the entity and relation diagram.

Fig1.7 cardinality and modality relation

Cordiality

The Figure 1.7 shows that single customer awaits repairs actions.

Modality

Mandatory implies that in order to have a repair action(s). We must have a customer.

Cardinality: Implies that there may be many repair action(s).

Modality: Optional implies there many be a situation in which a repair action is notnecessary

Manufacturer Buy Car

Decision box object Object

Fig 1.8 Relationship diagram

Cardinality Cardinality

Is provided with

Modality Modality

Customer Repair action

DMC 1753

NOTES


• Data objects are represented by a labeled rectangle.

• Relationships are indicated with a labeled line connecting objects.

• In some variations of the ERO, the connecting line contains a diamond that islabeled with the relationship.

• Connections between data objects and relationships are established using a varietyof special symbols that indicate cordiality and modality.

• The relationship between data objects car and manufacture.

• One manufacturer builds one or many cars.

• The context implied by the ERD, the specification of the data objects car.

• The symbols at the end of the connection live between objects.

• It can be seen that the modality of both occurrences is mandatory.

• Expanding the model, we represent a grossly oversimplifies ERD of the distributionelement of the automobile business.

• In many instances, a data objects may actually represent a class (or) category ofinformation.

1.7 AN EXPANDED ERD

License

Dealership

Stocks

Builds

Contract Transp

ort

Manufacture

Car

Shipper

Fig1.8 Entity relationship diagram


NOTES


• ERD notation also provides a mechanism that represent the associatively betweenobjects.

• An associative data object is represents the associatively between objects.

• The data objects that model individual subsystems are each associates with thedata object car.

• Data modeling and the entity – relationship diagram provide the analyst with aconcise notation for examining data within the context of a data processingapplication.

• The data modeling approach is used to create one piece of the analysis model.

• It can also be used for database design ad to support any other requirementsanalysis method.

• Information flow that is gathered or produced on a time continuous basis.

• Control information passed throughput the system and associated controlprocessing.

• Multiple instances of the same information, which are sometimes encountered inmultitasking situations.

• System states and the mechanism that causes transition between states.

• A data object that is input or output from a process on a “continuous” basis.

Control Process

• A transformer of control (or) “events” accepts control and input and producescontrol as output

• The arrowhead indicates the direction of data flow

Control Item

• A repository of control items that are to be stored for use by one (or) moreprocesses.

DMC 1753

NOTES


• Multiple equivalent instances of the same process used when multiple processesare create in multitasking system.

A control item (or) event; takes on a Boolean (or) discrete value; the arrowheadindicates the direction of data flow.

• The vertical bar is a reference to a control specification (CSPED) that describesthe behavior of a system.

• Defines how processes are activated as a consequence of events.

• Using entity relationship diagrams the software engineer creates a representationof all data objects that all-important for the system.

• Data and control flow diagrams are used as a basis for representing thetransformation of data and control.

1.8 OBJECT ORIENTED SYSTEM DEVELOPMENT LIFE CYCLE

Objectives

• The software development process.• Building high-quality software.• Object-Oriented systems development.• Use-case driven system development• Prototyping.• Component – based development.• Rapid application development.

1.8.1 The software development process

• It consists of analysis, design, implementation, testing and retirement is to transformusers’ needs into a software solution that satisfies needs.

• It is tempting to ignore the process and plunge into the implementation andprogramming phases of software development.

• Programmers have been able to ignore the counsel of systems development is abuilding a system.

Process


NOTES


• The development itself in essence is a process of change, refinement, transformationto the existing product.

• The object-oriented approach provides us a set of rules for describing inheritancesand specialization in a consisted way when a sub process changes the behavior ofits parent process.

• The process can be divided into small, interacting phases sub process.

• Each sub process have following

1. A description in terms of how it works.

2. Specification of the input required for the process.

3. Specification of the output to be produced.

• The software development process can be viewed in Fig 1.9 as a series oftransformations where the output of one transformation becomes the input of thesubsequent transformation.

• Transformation 1

1. It is analysis translates the users’ needs into system requirements and responsibilities.

2. The way they use the system can provide insight into the user’s requirements.

3. For example, one use of the system might be analyzing an incentive payroll system.

4. Which will tell us that this capacity must be included in the system requirements.

Software process reflecting transformation from needs to a software product that

Fig1.9 Software life cycle diagram

Transformation 2

1. It comes and explains about the design part.2. It begins with a problem statement and ends with a detailed design that can be

transformed into an operational system.3. This transformation includes the bulk of the software development activity.4. It also includes the design descriptions, the program and the testing materials.

Transformation 1

Transformation 2

Transformation 3

What are the uses of the system?

Problem Statements Analysis

Design Implementation

Detail

System software production

DMC 1753

NOTES


Transformation 3

1. In this discuss about the implementation part.

2. Implementation refines the detailed design into the system deployment that willsatisfy the users needs.

3. This takes into account the equipment, procedures, people and the like.

4. It represents embedding environment product with its operational environment.

5. For example, the new compensation method is programmed, new forms are putto use and new reports now can be printed.

6. In the real world, the problems are not always well-defined and that is why thewaterfall model has utility.

7. For example, it a company has expenses in building accounting system, then buildinganother such product based on the existing design is best managed with the waterfallmodel.

8. This model assumes that the requirements are known before the design begins.

9. But one may need experience with the product before the requirements can befully understood.

10. It also assumes that the requirements will remain static over the development cycle.

11. That a product delivered months after it was specified will meet the delivery timeneeds.

1.9 THE WATERFALL SOFTWARE DEVELOPMENT PROCESS

Software development is the translation of a user need or marketing goal into a softwareproduct. The waterfall model is a sequential software development model (a process forthe creation of software) in which development is seen as flowing steadily downwards(like a waterfall) through the phases of requirements analysis, design, implementation, testing(validation), integration, and maintenance as shown in Fig 1.10.

Fig1.10 Waterfall life cycle model

What

How

Dolt

Test

Use


NOTES


.Even when three is a clear specification, it assumes that sufficient design knowledgewill be available to build product. The waterfall model is the best way to mange a projectwith a well-understood product. It is based on well-established engineering principles.The system is installed in the real world the environment frequently changes. Altering theaccuracy of the original problem statement and consequently generating revised softwarerequirements. As each such request is processed system and programming changes makethe process increasingly complex. Since each request must be considered regard to theoriginal statement of needs as modified by other request.

1.10 BUILDING HIGH – QUALITY SOFTWARE

1. Once system (Programs) exists, we must test it to see if it is tree of bugs.

2. High quality produces must meet user’s needs and expectations.

3. The products should attain this with minimal (or) no defects, the focus being onimproving products prior to delivery rather than correcting them after delivery.

4. To achieve high quality in software we need to be able to answer the followingquestions.

5. How do we determine when the system id reading for delivery?

6. Is it now an operational system that satisfies user’s needs?

7. Is it correct and operating as we thought it should?

8. Does it pass an evaluation process?

9. There are two basis approaches to system testing.

10. This means of system evaluation in terms of four quality measures. They are:

• Correspondence

• Correctness

• Verification

• Validation

Correspondence

It measures how well the delivered system matches the needs of the operationalenvironment, as described in the original requirements statements.

Validation:

• It is the task of predicting correspondence.• True correspondence cannot be determined until the system is in place.

Correctness

It measures the consistency of the product requirements with the respect to the designspecification.

DMC 1753

NOTES


Verification:

• It is the exercise of determining correctness.• Correctness always is objective.

The Figure 1.11 shows the four quality measures (Correspondence, Correctness,Validation and Verification) for software evaluation

Fig1.11 Quality measures

High – quality software provides users with an application that meets their needsand expectations.

Four quality measures have been described correspondence measures how wellthe delivered system corresponds to the needs of the problem.

Correctness determines whether (or) not the system correctly computes theresults based on the rules created during the system analysis and design, measuring theconsistency of product requirements with respect to the design specification.

Verification is the task of determining correctness.

Eg: Am I building the product right?

Validation is the task of predicting correspondence.

Eg: Am I building the right product?

Object – Oriented software development life cycle (SDLC)

It consists e.g. three macro processes.

1. Object – oriented analysis.

2. Object - Oriented design.

3. Object – Oriented implementation.

The object oriented system development approach is shown in the Fig 1.12.

Object oriented analysis corresponds to transformation 1;

Object oriented design to transformation 2.

Object oriented implementation to transformation 3.

Validation Verification Correctness

Correspondence

Needs Requirements Design Software


NOTES


Fig1.12 Object oriented system approach

Design

1. Object oriented system development includes these activities2. Object oriented analysis use case driven3. Object oriented design4. Prototyping5. Component – based development6. Incremental testing

1.11 OBJECT – ORIENTED ANALYSIS USE CASE DRIVEN

1. The object oriented analysis phase of software development is concerned withdetermining the system requirements and identifying classes and their relationshipto other classes in the problem domain.

2. The object-oriented programming community has adopted use cases to a remarkabledegree.

3. The intersection among objects roles to achieve a given goal is called collaboration.

Using tools case and/or oo programming

User satisfaction

Design classes method

Build object dynamic model

Build user interface prototype

User satisfaction test, usability test equality

Build a use – case model

Validate test

Object Analysis

DMC 1753

NOTES


4. Expressing these high level processes and interactions with customers in a scenarioand analyzing it is referred to use-case modeling.

5. For example, the objects in the incentive payroll system might include the followingexamples.

a. The employee, worker, supervisor, office administrator.

b. The paycheck.

c. The process used to make the product.

Design

1. Object-Oriented design requires move rigor up front to do things right.

2. You need to spend move time gathering requirements developing a requirementsmodel and an analysis model, and then turning them into the design model.

3. Object-Oriented design centers on establishing design classes and their protocol.

4. Building class diagrams, user interfaces and usability based on usage and use cases.

5. The use-case concept can be employed through most of the activities of softwaredevelopment.

1.12 COMPONENT BASED DEVELOPMENT

1. Component based development (CBD) is an industrialized approach to softwaredevelopment.

2. Software components are functional units or building block offering a collection ofreusable services.

3. A CBD developer can assemble components to construct a complete softwaresystem.

4. Components themselves may be constructed form other components and so andown to the level of prebuilt components (or) written in a language such as C,COBOL.

5. The object-oriented concept addressed analysis, design and programming;

Whereas component-based development is concerned with the implementation andsystem integration aspects. Eg. Software development.

1.13 RAPID APPLICATION DEVELOPMENT

Rapid application development (RAD) is a term originally used to describe asoftware development process introduced by James Martin in 1991. Martin’s methodologyinvolves iterative development and the construction of prototypes. More recently, the termand its acronym have come to be used in a broader, generic sense that encompasses avariety of techniques aimed at speeding application development, such as the use of webapplication frameworks and other types of software frameworks. RAD approaches mayentail compromises in functionality and performance in exchange for enabling fasterdevelopment and facilitating application maintenance.


NOTES


1. The rapid application development (RAD) approach to system development rapidlydevelops software to quickly.

2. Incrementally implement the design by using tools such as case.

Reusability

1. Reusability is a major benefit of object-oriented system development.2. It is also the most difficult promise to deliver.3. To develop reusability in the objects.

Exercises

1. Define objects2. Define attributes3. Explain about encapsulation and how it is required for object oriented analysis?4. Explain about the design notation for any information system of your choice5. Briefly discuss about the ER diagram?6. Discuss about the waterfalls model7. List out the major types of the process models and explain about the RAD8. Explain component based development model

DMC 1753

NOTES



NOTES


UNIT II

METHODOLOGY AND UML

2.0 OVERVIEW OF OBJECT ORIENTED ANALYSIS – SHALEER ANDMELLOR

• OOA is a design method invented by s. shaleer and s.j mellor and arising from areal-time project started in the US Lawrence berkely laboratory in 1979.

• Although intended for real-time applications, and so concentrating on I currencyand parallelism.

• It has subsequently been applied in other fields including business applications.

• The first part of this method published (shaleer and mellor, 1988) was devotedmainly to relational modeling of data with some extensions to include generalizationand inheritance.

• The second part (shaleer and mellor, 1992) covers dynamic and functional aspects.

• This method is distributed by the authors through the company project technology,which has issued license for distribution by companies outside be USA.

2.1 THE OOA MODELS

• OOA is based on 3 models

Static

Dynamic

Functional

• The static model is in classical relational model that recognizes neither complexattributes nor operations.

• But for which a generalization relationship has been added, enabling an inheritancehierarchy to be established between tables.

• The dynamic model is based on state transition diagrams.

• The functional model, called the process model.

• The process model based on DFD’s.

DMC 1753

NOTES


The static models

This model, also called the information model, is a relationship model is the firstnormal form, possible normalized to the 3rd or 4th normal form.

Fig 2.1 Sample object oriented model

• It also includes the concepts of generalization and binary association latterrepresented by references in rational base.

• Objects are identified by means of keys composed of attributes as in the relationalmodel.

• Thus a conceptual object corresponds to a tuple in a relation.

• The concepts of data and type or not distinguished and both are represented bypre concept of object.

• No methods are attached to the objects and therefore objects are not encapsulated.

• Objects are categorized according to their nature, going from tangible objectswhich are physical objects, appearing the same to all the actors involved to thehigh-level abstractions that defines roles, incidents and interactions.

has

Consists of consists of Consists of Issued by

Item Send to

Consists of

1. Site number

12. Employee name *Period

Date 3. Workstation reference type

2. Server power

6.Trash site

5. Office

4. Menu bar

6.Item 7. Folder “designation” no. of

elements

8. Office tolls * name

10. Document processing

11. Services Document”name” created

14.Mail

15.message

13. Account*. Address


NOTES


• OOA does not have the distinct concept of class, and the term object representseither or type pr a specific instance.

• Among associations only binary are recognized with the usual cordialities of 1:N,1:N and M:N.

• The 1:1 and 1:N associations are represented by reference attributes, M:N byintermediary object called associative objects.

• The concepts of type and subtype have been added to be basic relational model.

• To enable factorization of attributes or associations common to several object.

• This leads to the usual properties of simple and multiple inheritance.

• The graphical representation used is a synthesis of Bachmann’s diagrams and theentity-relationship model.

• The boxes represents objects and the arcs

• Cordialities are shown single or double arrows according to whether they aremono or multi valued respectively.

• Arcs are labeled with roles to improve case or reading.

• The objects are numbered and the attributes are preceded by the symbols * andto denote candidate keys and descriptive attributes respectively.

2.2 THE DYNAMIC MODEL

• OOA uses State – transition diagrams to represent the dynamic of objects.

• The life style of an object is described by a succession states and transition fromone state to another is triggered by same event.

• An action can be represented by one or more operations.

• It can be an arithmetical calculation, Date creation, deletion or modification.

• An action is assumed to be atomic, meaning that it is either executed completely orignored.

• Apart from the details of the graphical representation this model resembles that ofthe Remora methodology.

• A state model is the set object life cycles, grouped by sub domain.

• An object communication model (OCM) is a graphical synthesis of the commonevents. It different state diagrams belonging to the same sub domain.

• These communication diagrams also include the external factors that are the sourcesof destination of external events.

• A Subsystem communication model is a graphical synthesis of the vents commonto different OCMs.

DMC 1753

NOTES


Fig 2.2 Object Communication model

2.3 THE FUNCTIONAL MODEL

• The OOA functional model specifies the content of each activity associated with astate of an object.

• It describes the procedure that defines each activity by organizing its elementaryoperations.

• Specifying its data flows and possible giving a time limit of must not exceed.

• The OOA functional model, also called the process model.

• It is supported by a form of DFD called an action data-flow diagram (ADFD).

• The model includes the concepts of process, data flow and data store, the lastcorresponding the relations tables containing instances of the objects.

• Control flows are added, so that an ordering of process executions can be created.

Class Di Click windowcorner select Dj

click icon click window corner Click window click office clickwindow Click office Open Dj Select Dj

Closed Active

Inactive Open


NOTES


Fig 2.3 Functional model

2.4 INTERACTION BETWEEN THE MODELS

• The three models interact, having in common the objects, the events, the dataflows or the operations.

• Thus the state diagrams are detailed descriptions of the object of the informationmodel.

• Process diagrams are detailed specifications of the actions of these objects whenthey reach a certain state.

• Each state diagram is associated with an object, each process diagram with anobject.

• Another level of interaction is provided by the inter object communication model(OCM) and the inter object access models (OAMs)

• The inter object communication model is in fact a model of the communicationbetween the state diagrams associated with the objects.

Document name Document already open Document Documents catalogue Description document name, access not allowed

Applications Catalogue

Not found Document name

office Applications Catalogue

Document status

Document Loading

Application launching

Application

name Document window

Check document

Check access

Find application

Error message2

Error message1

Open second copy

Rights Application

Type

DMC 1753

NOTES


• The communication is made trough the medium of events common to the differentdiagrams.

Fig 2.4 Information model

The Methodological Process

• Two complementary phases characteristic OOA’s approach.

• One phrase for problem analysis and one phase for model construction or design.

2.5 ANALYSIS PROCESS

• OOA recommends separating an application into four types of domains, whichalthough distinct, are complementary.

• Application domains who definition depends on the real world to be considered,these can themselves be broken into sub domains, in OOA called subsystems.

Serve domains

Architecture domains

Implementation domains

• These domains represent a hierarchy of abstraction corresponding to the integrationof successive technological elements until the implementation is achieved.

Information model Dynamic diagram of object O1 Process diagram activity A3

E2

E4

E3 E1

O1

O3 O2

P1

P2

P3


NOTES


Fig 2.5 Design process

The Design Process

• OOA’s design consists of producing in a certain order the different modelsinformation, dynamic and process models.

• The method is based on the life cycle of the figure shown.

• Which starts with the definition of the static (information) model and continuesthrough the dynamic (state) model to the functional (process) model?

• The conceptual design is followed by a logical design curiously called the recursivedesign state.

Fig 2.6 Logical design process

Applications domain

domain

Architectural domains

Implementation

domains

Workstation management Site management

Client-server

N/w Connection

Office services

Object mgmt

Graphics environment

Man machine dialogue

Transaction mgmt

Operating system

Languages

Object life cycle definitions (state transition diagrams) Specification of the activity of each state (Data Flow Diagram)

Logical design Definitions of classes and associated machines

Information model

State model

Process model

DMC 1753

NOTES


2.6 BALANCE SHEET FOR OOA

• OOA is closer to the classical methods than to the object approach.

• There is no concept of the complex object, objects do not have an identify of theirown, identification being linked to value.

• Objects are characterized only by static attributes.

• The difficulty here is that some objects can have a very long life cycle, giving a veryextensive state diagram.

• OOA is strongly influenced by real-time applications even though it is recommendedfor applications of all types.

• Its main advantage lies in its detailed and exhaustive study of object life cycles andits specification of the actions associated with object states.

• Although the method enables the dynamics of a real-time or an interactive systemto be described correctly.

• It does not seem to be well suited to batch applications.

• Finally, one might say that OOA seems more like an old method in modern dress

2.7 OBJECT – ORIENTED ANALYSIS/DESIGN

• Yourdon was already known for a structured analysis method that carries his name,based on DFDS.

• The Yourdon method has been criticized as concentrating too much on the functionsat the expense of the data.

• OOA OOD, which disassociates itself from the classical Yourdon method.

• It is described in tow works published in succession covering respectively and theconceptual modeling (OOA) and the logical design (OOD).

• It is distributed by object international, a company formed by load and yorn.

General Methodological Process

• The process goes in two phases

Analysis

Design

• As far as methodology is concerned, no distinction is made between the analysislevel and the design level.

• The general process and the normal model are the same, but at the design levelfurther technical subjects are bought in, such as interfaces, task management anddata management.

• These latter are called the technical domains of the methodology.


NOTES


2 Description of workstation Assignment of

employees to site

1 2 1

Site

Employee

Server

Workstation

Trash

Office

Menu bar

1 1,n assigned to 1 1 directs 0,1 1 2 1

Site

Server

Employee

Office

Trash

Menu bar

Workstation

Fig 2.8 Interaction diagram

Fig 2.7 Package diagram

2.8 OOA/OOD PROPOSED A MODELING PROCESS BASED ON FIVELEVELS OF SPECIFICATION

1. Subject level, determining the themes or the sub domains that constitute theapplication domains.

2. Object level, identifying by subject the virtual classes or the instantiated classes.3. Structural level, defining the associations between object classes.4. Attribute level, describing for each class or objects and possibly for each type or

association, the list of attributes by which it is characterized.5. Service level, specifying the operations that can be performed on each object, and

the messages exchanged between objects; each operation is specified by an

algorithm that defines its semantics.

DMC 1753

NOTES


• The above figure shows the successive results of working through this sequence ofresults.

• The procedure starts by identifying the two subjects of the application, assignmentof employees to a life and description of a workstation.

• The objects of which each subject is composed are determined.

• The objects are described in detail, in terms of attributes, operations and messages.

• The procedure can be applied equally at the analysis and the design levels, withthe same representation and notation.

• The mapping from one to the other involves only supplementary object techniquesto meet the needs of the implementation.

• At the design level, in addition to the subjects considered at the analysis level andgrouped as constituting the domain of the application.

• Three complementary domains are

Man-machine interaction, concerning interfaces, and protocol’s for communicationbetween the users and the application.Task management, specifying and co-coordinatingthe different tasks of the system.Data management, describing the various ways of storing,accessing and handling data.The shown figure summarizes the four main levels associatedwith these.

2.9 BALANCE SHEET FOR OOA/OOD

• OOA/OOD is an object-oriented method based on a single model that describesthe objects and their behavior.

• This is an entity-relationship, extended to include the fundamental object conceptsof class, inheritance, operation and message.

• Operations on the objects are specified at the analysis level by a functional approachusing diagrams.

• The model is used at the analysis and design levels successfully.

• At the design level it adds man-machine interfaces and management of tasks anddata.

• Mapping from analysis to design may introduce new objects into the applicationdomain.

• The concepts of composite attributes and multi-valued attributes are left unclear.

• Only binary relations are considered general and are not allowed.

• Finally, not much emphasis is placed on consistency and interaction between thedifferent domains.

• However, the method is an object method, clearly distinguished from classicalmethods.

• Its graphical representation is clear and user-friendly and it provided a set of supporttools.


NOTES


Fig 2.9 Level diagram

2.10 OBJECT ORIENTED ANALYSIS – RUMBAUGH

• Object - (object modeling technique) was developed in the late 1980s at thegeneral electric research and development.

• The method has had a certain amount of success in Europe generally and in theUSA.

• A project is running to unify OMT notations and methodology with those of Booch’sOOD.

• In its general approach OMI takes note of the static, dynamic and functionaldimensional.

Target System

Service Level

Architecture Level

Application domain Interaction

domain

Task management

domain

Data management

Domain

Subject Level

Object Level

Structure Level

DMC 1753

NOTES


The models

• Omi uses main models, to describe the static, dynamic, and functional aspectsrespectively.

• The static model is entity-relationship, extended to provide the object concepts ofclass, inheritance operation aggregation and generalization.

• The dynamic model is based on state transition diagrams with the specifications ofevents that trigger the changes.

• The functional model is based on classical SFDS used to specify the global functionsthat operate on the objects.

The static models

• This is an extension of an entity-relationship model.

• Each entity or relationship is seen as a class of objects described by two lists, oneof attributes and the other of operations.

• Thus relationships, like entities can be described equally in terms of attributes andof operations, but there are relationships, binary in particular which have neitherattributes nor operations of their own.

• Operations defined on entities and relationships are either computational functionsor any other transformation procedure.

Representations in OMT of a class of entities and instances of an entity.

• Relationships link two or more entities, not necessarily distinct; they have rolesand cardinalities from entities to relationships.

• Constraints can also be applied to hierarchal classes, for example constraints suchas intersection or disjunctions can be defined between subclasses of a givengeneralized hierarchy.

• Among other concepts that are provided are meta classes, abstract classes, derivedclasses and derived relationships.

The dynamic model

• The aim of this model is to describe the object life cycles, that is to list their possiblestates and events that change these states.

Class Entity Name Attributes Operations

(Entity name) instance

Instances


NOTES


• The dynamic model is described by state transition diagrams, labeled with therelevant triggering events and the operations that they instigate.

a) Events (attributes)/action

[Conditions]State 2

Events (attributes)/action

[Conditions]

a) Element of a state-change diagramb) State change, with activity.

According to OMT,

• An event is a means for transmitting information from one object to another.

• Events are grouped into classes; they can be linked in sequence by casual chainsor can occur simultaneously.

• A transition is defined as the occurrence of an event together with the resultingeffect.

• This is to say the action to be performed; this action is considered to be atomic(“all or nothing”).

• Static is the value that an object has during a particular time internal or between theoccurrences of two successive events.

• During this interval the object can perform some activity that does not change itsstate.

• As a help identifying events and generating state-transition diagrams of a set ofclasses, omi provides an information representation, called a scenario.

• The concept of scenario is similar to that of subject in OOA/OOD and of use casein OOSE.

• With each scenario representing in some way the functions of the systems, the setof all scenarios.

• Putting them all together enables events to be early identified and the object lifecycle to be derived.

State 1

State 2

State 1

State 2 Do activity 2

DMC 1753

NOTES


Fig 2.10 Functional model represents the transformation process

The functional model

• The functional model describes the transformation process performed by anapplication.

• Each of these processes is an operational formalization of a scenario.

• In contrast to OOA, this uses DFD’s to specify the logic of the elementary operationsassociated with the objects.

• OMI uses them to describe the functions of the systems as a whole.

• An OMI DFD is based on actors, processes, data stores and data flows.

• The given example that describes a session of office works, consisting of openinga folder, selecting a document in this folder. Opening this document, making somechange and closing it after possibly saving the change.

• The external events are made to occur by the user checking with the mouse.

Clickwindowcorner (Dj)close

Clickicon(Di) clickwindow (Di)/select

clickwindowcorner (Dj)close

clickwindow(Di)/select clickOffice (Dj)/select

closed

Inactive do: mask(Di)

Open do: call application

do: display

Active do: display (Di)

ClickOffive (Dj)/Select


NOTES


Fig 2.11 Functional model represents the interaction process

2.11 GENERAL METHODOLOGICAL PROCEDURE

• The OMT development cycle is a cascade into which the concepts of system andcomponent are introduced, as in the V model, but iterations are allowed only asfar back as the previous stage.

• In the analysis stage the three models

Static

Dynamic

Functional are constructed

• This level describes what the system is to do, now how it is do it.

Fig 2.12 OMT development Life cycle

Click

Click Folders

Documents

Documents

User Open folder

Open document

Update document

Close document Save

document

Analysis

System Design

Object Design

Implementation

DMC 1753

NOTES


• Designing the static model is relatively intuitive.

• The design of dynamic model is guided by the scenarios for the interactions betweenthe objects.

• The functional model proceeds by successive retirements of the DFD’s.

• The object design stage is a detailed specification of object implementation,independent of any environment but compatible whatever technology has beenchosen.

• This is the level at which the set of operation on the objects completely identifiedand specified.

• The system-design stage allows the system architecture with its components andresources to be defined.

• The complete system can be broken into subsystems, enabling identification ofconflict elements, and the choice of data storage and access strategies.

2.12 BALANCE SHEET FOR OMI

• OMI is one of the most complete and most fully documented object methods.

• Its development cycle goes from formal specification top physical implementation.

• The method is a judicious combination of the object and the more classical functionalapproaches.

• It enables the architecture of the application system to be defined and providesmany technical aids to implementation in object oriented environments.

• The object model is rich and the geographical system user friendly with a wellchosen set of symbols.

• Definition of objects by their attributes acts against the evolution of structures.

• The link between the functional and object models is made at the level of theoperation.

• But there is no formal correspondence between the functional model concepts ofactor, flows and data store on the one hand and the objects of the state model onthe other.

2.13 OOD – (G. BOOCH)

• This methodology was developed by G. Booch in the early 1980’s.

• It is probably the first methodology to use the object approach in industrialapplications.

• It was commissioned originally by the US departments of defense.

• To rationalize the development Ada programs and later extended to CTT andsmall talk programming languages.

• The main contribution of OOD is its bringing out the importance of objectdecomposition as compared with functional decomposition.


NOTES


• Programmers can thus be encouraged to use Ada packages not just to hold anyprocedure or Type definitions.

• But to implement classes in the sense of the object approach.

• Every object class in the system is thus represented by a package.

• The methodology is concerned essentially with the state model.

• The dynamic model is constructed for only a few aspects and the functional modelenters in only a very partial fashion, through the concept of time diagram.

• Booch recommended using the SADT method for the analysis, but now, withOOD – OMI is preferred for analysis.

OOD Models

• OOD concentrates on the static model.

• It completes the definition of this by adding a number of state diagrams to representthe dynamic aspects of the object.

Tools for static modeling

• These tools consist of diagrams that enable the object classes to be described atthe design and implementation levels.

• They constitute one of the forms of the basic OOD notation.

• The definition of the object diagrams is rather surprising in view of the fact that thenumber of objects can be very great.

The basic concepts of the object and class diagram are as follows:

• Object - In addition to its definition in forms of identifier, attributes, and operationsan object has a state or set of states that determine its evolution ever time.

• Relationships – The static model has, an addition to the inheritance, instantiationand metaclass relationships.

• Protocol of an object – The list of operations that the object in question can performon other objects that is the set of OSE relationships originally from the object.

• Behavior of an object – The protocol of the object together with the list of operationswith which other objects can out on it.

• Role of an object – An object can be client when it operators on others, or aserver, when it is used by others. It can be both client and server it a then called anagent.

• Concurrency of objects – the behavior of an object can be either sequential orconcurrent, when it is said to be sequential or a concurrent object respectively

• Persistence of objects – OOD mentions persistence but says nothing about thekind of system that can manage this.

DMC 1753

NOTES


• An object diagram describes the objects and the messages that key send to oneanother.

• The object is represented by small ‘clouds’ with continuous outline, and the userelations by heavy lines.

• A class diagram describes the hierarchies of classes of objects with links betweenclasses, including inheritance links, instantiation, meta class and message sending.

• Classes of objects are represented by small clouds with dotted outlines.

• Relations between these by lines carrying different MO types corresponding todifferent semantics of the relations

• The textual notation corresponding to these diagrams enables the following to bespecified for each class.

The types that characterize it

The associated operations

The encapsulation

Its super class and meta class

Properties such as concurrency and persistence

The finite state machine which controls object life cycles

• OOD uses the concept of category to simplify diagrams that have become solarge and complicated as to be difficult to read.

• A category is a set of classes grouped together by subject or theme.

• This is similar to database views, which are defined in terms of base classes or byother defined views.

• A category thus corresponds to a diagram of classes or of other categories

The Dynamic Model

• There is no dynamic model – the emphasis is always on the analysis of the objectand the state diagram is only optional complements to the specification of these.

• A state transition diagram will be constructed for any object whose life cycle is ofinterest for the programmer

• Each are of the state diagram is labeled with the event that brings about thecorresponding transition

The Functional Model

• There is no functional model as the object model is itself a particular functionaldecomposition

• This model, however, is static and does not enable a task sequence to be realized.


NOTES


• Booch has made a variety of proposals for meeting this need, from numbering themessages in the object diagrams to providing algorithms or introducing time-stepdiagrams

• The Figure 2.13 time step diagram represents the interactions between behaviorsof different objects.

• It is a simple step-by-step graph showing the order in which the operations areperformed on the various objects.

• Its usefulness restricted to small scenarios without iterations

Fig 2.13 Time step diagram

The implementation level models

• The module and process diagrams describe the implementation of the class andobject diagrams

• The module diagrams implements the class diagram, whereas the process diagramis more like architecture, displaying the main processes and their interconnections.

Fig 2.14 Implementation level diagram

paste

clipboard enlarge

Window open

Folder

Document open copy close

Office open clipboard

Clipboard time

Site

Workstation employee Office tools Documents

• • •

DMC 1753

NOTES


• The nodes of the module are usually made in Ada or c++ programming languages,but there are examples of others, including object Pascal, small talk and CLOSE.

2.14 THE DESIGN PROCESS

• Design phase - OOD recommends an incremental approach, based on stepwiserefinement and a high level modularity.

Fig 2.15 Object oriented development life cycle

The OOD development cycle

• The evolution phase- not a well chosen name, but the one used concerns codingand testing and integration

• The modification phase – corresponds to the maintenance of the system and theincorporation of any changes required in the course of its evolution

• The design process is what common dense would suggest, a state by stage studyas follows

o Identify the classes and objects.

o Identify the semantics of the classes and objects.

o Identify the relationships between classes and objects

o Implement the classes and objects

• This can be applied recursively, alternating top down with bottom up approach.

Balance sheet for OOD

• OOD is one of the oldest object methods

• It has been used in many applications and there are many references to it in theliterature

• It has certainly contributed to the rationalizing of Ada and OTT applications andhas provided a large amount of valuable experiments

Design

Analysis

Evolution

Modification


NOTES


2.15 UML- UNIFIED MODELING LANGUAGE

Use case

A use case is a description of a set of sequences of actions, including variants, that asystem performs to yield an observable result of value of an actor

• Graphically a use case is rendered as eclipse• Names

Use cases and Actors

• An actor represents a wherent set of roles that users of use cases play wheninteracting with these use cases.

Use cases and flow of events

• A use case describes what a system does but it does not specify how it does it

• To do this you can specify the behavior of a we case be describing a flow of events

Use cases and scenarios

• Use case includes interaction diagrams to specify these flows graphically

Use cases and collaborations

• The society of elements including both its static and dynamic structure is modeledin the UML as a collaboration Common modeling techniques of use case modelingthe behavior of an element

To model the behavior of an element

• Identify the actors that interact with the elemen

• Organize actors by indentifying general and more specialized roles

• For each actor, consider also interactions that change the state of the element or itsenvironment or that involve a response to some event

• Consider also the exceptional ways in which each actor interacts with the element

• Organize these behaviors as use cases, applying included and extend relationshipsto faller common behavior and distinguished exceptional behavior.

User name

DMC 1753

NOTES


Fig 2.15 Interaction diagram

Conceptual model of the UML

• To understand UML you need to form a conceptual model of the language, andthis requires learning three major elements

1. Building blocks of UML

2. Rules that dictate how these building blocks may be put together

3. Some common mechanism

Building blocks of UML

• The vocabulary of the UML encompasses three kinds of building blocks

1. Things

2. Relationships

3. Diagrams

Things:

• Things are the abstraction that are first class citizens in a model

Things in UML:

1. Structural things

2. Behavioral things

3. Grouping things

4. Annotational things

• These things are the basic object-oriented building blocks of the UML.

Place order

Track Order

Ship order Ship place/order

Validate Customer

Bill Customer


NOTES


STRUCTURAL THINGS

Structural things are the nouns of UML models these are the mostly static parts of themodels, representing elements that are either conceptual or physical.

• Seven kinds if Structural things

a. Class

b. Interface

c. Collaboration

d. Use case

e. Active Class

f. Component

g. Node

Class

• It is a description of a set of object that share the same attributes, operations,relationships and semantics.

• A class implements one or more interfaces, graphically a class is rendered as arectangle, including all names, attributes and operations.

INTERFACE

• An interface is a collection of operations that specify a service of a class orcomponent.

• Graphically interfaces are rendered as a mode together with its name.

Interface

Window

Origin size

Open()

Close()

More()

Display()

Uspelling

DMC 1753

NOTES


Collaboration

• Collaboration defines an interaction and is a society of roles and other elementsthat work together to provide some cooperative behavior that’s bigger than thesum of all elements.

• Graphically, collaboration is rendered as an ellipse with dashed lines.

Collaboration

Use Case

• A use case is a description of set of sequence of actions that a system performsthat yields an observable result of value to a particular actor.

• Graphically, use case is rendered as an ellipse with solid line.

ACTIVE CLASS

• An active class is a class whose objects own one or more processes or threadsand therefore can initiate control activity.

• Graphically, H is rendered just like class with heavy lines.

Component

• A component is a physical and replaceable park of a system that conforms to andprovides the realization of a set of interfaces.

• Graphically, a component is rendered as a rectangle with tabs.

Uspelling

Event Manager

Suspend()

Flush()


NOTES


NODE

• A node is a physical element that exists at runtime and represents a computationalresources generally having least memory and processing capabilities.

• Graphically a node is rendered as a cube.

Behavioral Things

• Behavioral things are the dynamic parts of unit models. These are the verbs ofmodels.

• Two primary kinds of behavioral things

o Interaction

o State machine

Interaction

• It is a behavior that comprises a set of messages exchanged among a set of objectswithin a particular context to accomplish a specific purpose.

• An interaction involves a number of elements including messages, action sequences.

Display

State Machine

It is a behavior that specifies the sequences if states an object or an interaction goesthrough during its lifetime in response to events together with its response to those events.

Grouping Things

• Grouping things are the organizational parts of UML models. These are the boxesinto which or model can be decomposed.

• One primary kind of grouping is package.

Package

• A package is a general-purpose mechanism for organizing elements into groups.All other grouping things can be placed in package. It includes only its name andsometimes its contents.

DMC 1753

NOTES


Annotational Things

• Annotations things are the explanatory parts of UML models. These are thecomments you may apply to describe, illuminate and remark about any elements ina model.

• A node is a simply a symbol for rendering constraint and comments attacked to anelement or a collection of elements.

2.16 RELATIOPNSHIPS IN THE UML

semantic connection among elements. There are four kinds of relationships in theUML.

• Dependency

• Association

• Generalization

• Realization

Dependency

A dependency is a semantic relationship between two things in which a change to onething may affect the semantics of other thing.

. . . . . . . . . . . . . . . . . . . . . . . . . .

Association

• An association is a structural relationship that describes a set of links, a link beinga connection among objects.

• Aggregation is a special kind of association representing a structural relationshipbetween whole and its parts.


NOTES


GENERALIZATION

A generalization is a specification / generalization relationship in which objects of thespecified element are substitutable of the generalized element.

REALIZATION

• A realization is a semantic relationship between classifiers, where in one classifiersspecifies a contract that another classifier guarantees to carry out.

• You will encounter realization relationship in two places

o Between interfaces

o The classes or components.

…………………………….

Diagrams in the UML

• A diagram is the graphical representation of a set of elements, most often renderedas a connected graph of verifies and perspectives.

• Diagram is a projection into a system.

• A diagram may contain any combination of things and relationships.

• UML includes nine diagrams:

o Class diagram

o Activity diagram

o Object diagram

o Use case diagram

o Sequence diagram

o Collaboration diagram

o State chart diagram

o Component diagram

o Deployment diagram

DMC 1753

NOTES


Class Diagram

• A structural diagram that shows a set of classes, interfaces, collaborations andtheir relationships.

Object Diagram

• A structural diagram that shows a set of objects and their relationships.

Use case Diagram

• A behavior diagram that shows a set of use cases and actors and their relationships.

Sequential Diagram

• A behavior diagram that shows an interaction emphasizing the structural organizationof the object that send and receive messages.

Collaboration Diagram

• A behavioral diagram that shows a state machine emphasizing the event-orderedbehavior of an object.

Activity Diagram

• A behavioral diagram that shows a state machine emphasizing the flow from activityto activity.

Component Diagram

• A structural diagram that shows a set of components and their relationships.

Deployment Diagram

• A structural diagram that shows a set of nodes and their relationships.

2.17 RULES OF UML

Semantic rules

• Names

• Scopes

• Visibility

• Integrity

• Execution

Well-Forms Build Models

• Elided

• Incomplete


NOTES


• Inconsistent

• Common Mechanisms in the UML

• There are four common mechanisms in UML

o Specifications

o Adornments

o Common Divisions

o Extensibility mechanisms.

Specifications

• The UML specifications provide a semantic back pane that contains all the partsof all the models of a system, each part related to one another in a consistentfashion.

• The UML’s diagrams are thus simply visual projections into the back pane, eachdiagram revealing a specific interesting aspect of the system.

Adornments

• Details from an elements specification added to its basic graphical notation.

• For example the notation of class has private, public and protected operation.

• It can be representing with adornments.

• Notation starts with basic symbols.

Common Divisions

• In modeling object-orients systems, the systems get divided in at couple of ways.

• Divisions of class and object and interfaces and implementations in a diagram.

Transaction

+ execute ()

+ Rollback ()

# Priority ()

– Hm stamp ()

DMC 1753

NOTES


2.18 EXTENSIBILITY MECHANISMS

• The UML’s extensibility mechanisms include

o Stereotypes

Extends the vocabulary of the UML, allowing you to create new kinds of buildingblocks that are desired from existing ones but that are specific to your problem.

• Tagged values

Extend the properties of a uml building block. Allowing you to create new informationin the elements specification

• Constraints

Extend the semantics of a UML building block allowing you to add rules or modifyexisting ones

Behavioral Model

Interactions

• An information is a behavior that comprises a set of messages exchanged among aset of objects within a context to accomplish a purpose

• A message is a specification of a communication between objects that conveysinformation with the o\expectation that activity will ensure

• An interaction may also be found in the representation of a component, node, oruse case, each of which in the UML, is really a kind of classifier.

Chan: Customer

: Customer

Customer

Name

Address

“Execution overflow”

Event Queue {V=3.2 a = eg}

Add(), remove(), flush()


NOTES


Use cases

• A use case is a description of a set of sequences of actions, including variants, thata system performs to yield an observable result of value to an actor

• Graphically a use case is rendered as eclipse

• Names

Use case diagrams

• A use case diagram shows a set of use cases and actors and their relationships.

Use case diagram commonly contains

• Use cases

• Actor

• Dependency, generalization and association

• Relationship

Interaction diagrams

• Interaction diagrams are used when you want to model the behavior of severalobjects in a use case.

• It contains objects, links, messages

• Sequence diagrams, collaboration diagrams, or both diagrams can be used todemonstrate the interaction of objects in a use case.

Sequence diagrams

• Sequence diagrams generally show the sequence of events that occur

• A sequence diagram emphasis the some ordering of messages

• Sequence diagrams describe interactions among classes in terms of an exchangeof message over time

• Features

Object lifeline

Focus control

Collaboration diagrams

Collaboration diagrams show the relationship between the objects and otherorder of messages

DMC 1753

NOTES


The object is listed as icons and indicate the messages passed between them.The numbers next to be messages are called sequence number

Features

Path – indicate how are object is linked to another

Sequence number =indicate the time order of a message

Activity diagrams

• Activity diagrams describe the workflow behavior or system

• The diagrams describe the state are of activities by showing the sequence ofactivities performed

• Activity diagrams can show activities that are activities that are conditional orparallel

• Activity diagrams illustrate the dynamic nature of a system o\by modeling the flowof control from activity to activity

• An activity represents an operation on some class in the system that result in achange in state of the system

Event

• An event is the specification of a significant occurrence that has a location in timeand space

• Events may be external or internal

• External events are more that parts between that system and its actors

• Internal events are those that pass among objects that the inside the system.

Signals

• A signal is a kind of event that represents the specification of an asynchronousstimulus communicated between instances

• A signal represents a named object that is thrown asynchronously by one objectand then received by another

State machines

• A state machine is behavior that specifies the sequences of states an object goesthrough during its lifetime in response, together with its response to those events.

Activity


NOTES


Processes and threads

• A process specifies a heavy weight flow that can execute concurrently with otherprocesses.

• Thread specifies lightweight flow that can execute concurrently with other threadswithin the same process.

Time and space

• A time mark is a denotation for the time at which an event occurs

• A time expression is an expression that evaluates to an absolute or relative value oftime.

• A time constraint is a semantic statement about the relative or absolute value oftime

• Location is the placement of component on a mode.

Diagram

• A diagram is just a graphical into the elements that make up a system

• For example you might have several hundred classes in the design of a corporatehuman resources system

• You could never visualize the structure of behavior of that system by starting at onelarge diagram containing all these classes and their relationships

• A diagram of a graphical presentation of a set of elements it a connected graph ofvertices and ones

• To view static part of a system using one of the four following diagrams

Class diagrams

Object diagrams

Component diagrams

Deployment diagram

• To view dynamic part of a system using five additional diagrams

o Use case diagram

o Sequence diagram

o Collaboration diagram

o State chart diagram

o Activity diagram

There are 2 types of diagrams:

• Structural diagrams

• Behavioral diagrams

DMC 1753

NOTES


Structural diagrams

• The UML’s four structural diagrams exist to visualize, specify, construct, anddocument the static aspects of a system

• The uml’s structural diagrams are roughly organized around the major groups ofthings you will find modeling a system

o Class diagram – classes, interfaces and collaborations

o Object diagram – objects

o Component diagram - components

o Deployment diagram – nodes

Behavioral diagrams

• The uml’s five behavioral diagrams are used to visualize, specify, construct anddocument the dynamic aspects of a system

• You can think of the dynamic aspects of a system as representing its changingparts

• The uml’s behavioral diagrams are roughly organized around the major ways youcan model the dynamic of in system

1. Use case diagram – organizes the behavior of the system.

2. Sequence diagram – focused on the time ordering of message

3. Collaboration diagrams – focused on the structural organization of objectsthat send and receive messages

4. State chart diagram – founded on the changing state of a system driven byevents.

5. Activity diagram – focused on the flow of control from activity to activity

Class

• A class is a description of objects that store the same attributes, operations,relationships, and semantics it is rendered as rectangle

Names

• Name is a features string to differentiate from other classes. Each class have uniquename

• The name alone is known as simple name, a path name is the class name prefixedby the name of the package in which class lines

Example:

Simple name path name

Student info Java and rectangle


NOTES


Attributes

• An attribute is named property of a class that describes a range of values thatinstances of the property may hold.

• An attribute represents some property of the thing you are modeling that is sharedby all objects of that class.

Example

OPERATIONS

• An operation is the implementation of a service that can be requested from anyobject of the class to affect behavior.

• In other words, an operation is an abstraction of something you can do to anobject and that is shared by all objects of that class.

Example

Analysis patterns

• A pattern is a common solution to a common problem in a given context.

• A mechanism is a design patterns that applies to a society of classes.

• Modeling design Patterns

Emp

Name

Address

Age

Phone

Window

Origin

Size

Open()

Close()

Move()

Display()

DMC 1753

NOTES


• Identify the common solution to the common problem and verify it as a mechanism.

• Model the mechanism as collaboration, provides its structural as well as behavioralaspects.

• Identify the elements in a specific of the design pattern that must be bound toelements in a specific context and render them as parameters to the collaboration.

2.19 OVERVIEW OF UML

The UML is a language for

• Visualizing

• Specifying

• Constructing

• Documenting

The artifacts of a software intensive system

1. The UML is a Language for visualizing

• First, commutating those conceptual models to others is error-prone unlesseveryone involved speaks the same language.

• Typically projects and organizations develop their own language, and different tounderstand what’s going on if you are an outside or new to me group.

• Second, There are some things about a software system you can’t understandunless you build models the transcend the textual programming language.

• Third, if the developer who cut the code never wrote down the models that are inhas or her head that information would be lost forever or, at best, only partiallyrecreatable from the implementation.

• To address these problems

o Models should be written in UML. The UML is such as graphical language.

2. The UML is a Language for specifying

• In this context, specifying means building models that are precise, unambiguousand complete.

• In particular, the UML addresses the specification of all the important analysis,design and implementation decisions that must be made in developing and deployingsoftware intensive system.

3. The UML is a Language for Contraction

• The UML is not a usual programming language but models can be directly connectedto a variety of programming languages.

• This means that it is possible to map from model in the UML to a programminglanguage such as java, C++ or Visual Basic, or Event to tables in a relationaldatabase to the persistent store of an object-oriented database.


NOTES


Mapping - Mapping permits forward engineering. The generation of ode from a UMLmodel into a programming language. The reverse is also possible. You can reconstruct amodel from an implementation back into the UML.

4. The UML is a language for Documentation

• A healthy software organization produces all sorts of object in addition to rawexecutable code. These artifacts include

o Requirementso Architectureo Designo Source Codeo Perfect Planso Testso Prototypeso Releases

1. The UML addresses the documentation of a system is architecture and all of itsdetails.

2. The UML also provides a language for expressing requirements for tests.

3. Finally, the UML provides a language for modeling the activities of project planningand release management.

Aggregation

• A plan association between two classes represents a structural relationship betweenpeers, meaning that both classes are conceptually at the same level, no one moreimportant than the other.

• Sometimes, you will want to model a “Whole/part” relationship, which one classrepresents a larger thing, which consists of smaller things.

• This kind of relationship is called aggregation, which represents a “has=a”relationship.

• Aggregation is really just a special kind of association and is specified by adoringa plain association with an open diamond at the whole end.

Company

Whole Aggregation

Part

Aggregation

Department

DMC 1753

NOTES


Other Features

• The meaning of this sample form of aggregation is entirely conceptual.

• The open diamond distinguished the “whole” form the “Part” no more, no less.

• Dependencies, generalization and associations are all the static things define at thelevel of classes. In the UML, these relationships are usually visualized in classdiagrams.

Exercises

1. Prepare a portion of a class diagram for library checkout system that shows thelate charges for an overdue book as a derived attribute

2. Discuss the importance of UML?

3. Discuss about the patterns? And how far it is efficiently utilized?

4. Write the use of Collaboration diagram? Discuss the merits and demerits?

5. Discuss the various models of ooad?

6. Briefly discuss the OOA/OOD proposed a modeling process?

7. Write a note on functional model?

8. Discuss about the static model?

9. Write a note on dynamic model?

10. Differentiate the static and dynamic model?


NOTES


UNIT III

OBJECT ORIENTED ANALYSIS

DIAGRAMS

There are two types of diagrams:

1. Structural Diagrams.

2. Behavioral Diagrams

3.1 STRUCTURAL DIAGRAMS

The UML’s four structural Diagrams exist to visualize, specify, construct and documentthe static aspects of a system.

Class Diagram:

In the Unified Modeling Language (UML), a class diagram is a type of staticstructure diagram that describes the structure of a system by showing the system’sclasses, their attributes, and the relationships between the classes

• A class diagram shows a set of classes, Interfaces and collaborations andtheir relationships.

• Class diagrams are the most commons diagram found in modeling objects-oriented systems.

Example:

Class Name Attribute: Type = Initial Value Operation Large List:

Return type

DMC 1753

NOTES


1. Object Diagram

• An object diagram shows a set of objects and their relationships.

• You use object diagrams to illustrate data structures pre static snapshots if instancesof the things found in class diagrams.

Syntax:

Object name: Class name

2. Components Diagram

• A component diagram shows a set of component diagrams to illustrate the staticimplementation view of a system.

• You use component diagrams to illustrate the static implementation view of a system.

• A component diagram describes the organization of the physical components in asystem.

3. DEPLOYMENT DIAGRAM:

• Deployment diagrams depict the physical resources in a system including nodes,components and connections.

• A deployment diagram shows a set of nodes and their relationships.

• You use deployment diagrams to illustrate the static deployment view of architecture.

3.2 BEHAVIOR DIAGRAMS

The UML’s Five behavioral diagrams are used to visualize, specify, construct anddocument the dynamic aspects of a system.

You can think of the dynamic aspects of a systems as representing it changingparts.

Component

Node Node


NOTES


The UML’s behavioral diagrams are roughly organized around the major waysyou can model the dynamic of a system.

1 USE CASE DIAGRAM:

• Use case diagram shows a set of use cases and actors and their relationships.

• You apply use case diagrams to illustrate the static use case view of a system.

2 SEQUENCE DIAGRAM:

• A sequence diagrams an interaction diagram that emphasizes the time ordering ofmessages.

• A sequence diagram shows a set of object and the messages sent ad received sentand received by more objects.

3 COLLABORATION DIAGRAM:

• A collaboration diagrams are interaction diagrams that emphasizes the structuralorganization of the objects that send ad receive messages.

• A collaboration diagram shows a set of objects links among those objects, andmessages sent and received by those objects.

4. STATE CHART DIAGRAM:

• A state chart diagrams shows a state machine constituting of states, transitions,events and activities.

• You use state chart diagrams to illustrate the dynamic view of a system.

5. ACTIVITY DIAGRAM:

• An activity diagram shows the flow form activity to activity within a system.

• An activity shows a set of activity, the sequential or branching flow from activity toactivity, and objects that act and are acted upon.

Collaborations

Collaboration is society of classes, interfaces and other elements that work togetherto provide some co operate behavior that’s bigger than the sum of all its parts.

Collaboration is also the specifications of how an element, such as s classifier or anoperation is realized by a set of classifies and associations playing specific roles used in aspecific ways.

Especially, collaboration is rendered as a ellipse with based lines.

E.G:

DMC 1753

NOTES


3.3 STRUCTURE AND BEHAVIOR

Two aspects of Collaboration

• A structural part that specifies the classes, interfaces and other elements that worktogether to carry out the named collaboration.

• A behavioral part specifies the dynamics of how those elements interact.

3.4 COMMON MODELING TECHNIQUES

Modeling Realization of a use case.

Identify those structural elements necessary and sufficient to carry and the semantics of theuse case.

Capture the organization of these structural elements in class diagrams.

Consider the individual scenarios that represents this use case.

Each scenario represents a specific path through the use case.

Capture the dynamics of these scenarios in interaction diagrams.

Use sequence diagrams if you want to emphasis the time ordering of messages.

Use collaboration diagrams if you want to emphasis the structural relationships amongthese objects as they collaborated.

Organize these structural and behavior elements as a collaboration that you can connectto the use case via realization.

Name

Place order

Track Order

Shop Order

Bill Customer

Validate Customer

Shop place Order


NOTES


3.5 MODELING THE REALIZATION OF AN OPERATION

• Identify the parameters, return value, and other objects visible to the operation.

• If the operation is trivial, represent its implementation directly in code, which youcan kept in the back plane of your model.

• If the operation is algorithmically intensive, model its realization using an activitydiagram.

• If the operation is complex or otherwise requires some detailed design work,represent its implementation as collaboration; you further expand the structuraland behavioral parts of this collaborations using class and interaction diagrams,respectively.

To model a mechanism

• Identify the major mechanisms that shape your system’s architecture.

• These mechanisms are driven by the overall architectural state you choose toimprove op your implementations, along with the style appropriate to your problemdomain.

• Represent each of these mechanisms as a collaboration.

• Expand on the structural and behavioral part of each collaboration, look for sharing,where possible.

• Validate these mechanisms early in the development life cycle, but cycle them witheach new release, as you learn more about the details of your implementation.

3.6 SEQUENCE

Sequence is a stream of messages from different messages for sending and receivingto one object to another. Each process and thread within a system defines a distinct ofcontrol and with each flow, messages are ordered in sequence by time.

Render Name Return Set contents

Render progress Active class and attached with node

Pav have

DMC 1753

NOTES


There are two different types of sequence flat and procedures. To better visualize thesequence of a message. You can explicitly model the order of the message relative to thestart of the sequence by prefixing the message with a sequence number set apart by acolon separator.Most commonly, You can specify a procedural or nested flow of control,rendered using a filled solid arrow head.

In this case, the message finds at is specified as the first message nested in thesecond message of the sequence (2:1)

• The distinction between flat and procedural sequences subtle and is really anadvanced modality issue.

• In the UML, you can also model more complex forms of sequence, such as iteration,branching and guarded messages.

Sequence Number Message

2: Clidk At (p) 2.2 = Put Recent Pick

Nested flow of control

2:1:1 – Find At(P)

View C: Controller

:Lacte

SN Message SN =Lyt handset () 2=assert call () Flat flow of control

Caller :Telephone : Exchange


NOTES


• In addition to model timing constraints such as you might find in relative systems.You can associate timing marks with a sequence.

Class

• A class is a description of objects that share the same attributes, operations,relationships and scenarios is rendered as rectangle.

Names

Names are a textual string to differentiate from other classes. Each class have uniquenames.

That name alone is known as simple name.

A path name is the class name prefixed by the name of the package in which classlives.

Attributes

An attribute is named properly of a class that describes a range of values that instancesof the property may hold. An attribute represents some properly of the thing you aremodeling that is shared by all objects if that class.

Operations

An operation is the implementation if of a service that can be requested from anyobject of the class to affect behavior.In order words, an operation is an abstraction ofsomething you can do to an object and that shared by all objects of that class.

Simple Name Pathname

Student Felwa :AWT : Square

Emp

Name

Address attribute

Phone

DMC 1753

NOTES


Advances Classes

Classifiers

A classifier is a mechanism that describes structural and behavioral features. Classifiersinclude classes, interfaces, data types, signals, components, nodes, use cases and subsystems.

The most important kind of classifier to the UML is the class.

A class is a description of a set of objects that share the same attributes,operations, relationships and semantics.

Interface – A collection of operators that are used to specify a serviceof a class or a component.

Data type – A type whose values have no identified including primitive built intypes, as well as enumeration types.

Signal – The specification if an asynetmnous stimulus communicated between instances.

Component – A physical and replaceable part of a system that conforms to andprovides the realization of a set of interfaces.

Node – A physical element that exists at runtime and that represents acomputational resource, generally having at least some memoryand often processing capability.

Use Case – A description of a set of a sequence of actions including variants,that or system performs that yields an observable result of valueto a particular actor.

Subsystems – A grouping of elements of which some constitute a specificationof the behavior offered by the order-contained elements.

windows

Origin Size

Open ( )

Close ( )

Move ( )

Display ( )


NOTES


Visibility:

• One of the most important details you an specify for a classifiers attributes andoperations is its visibility.

• The visibility of factors specifies whether other classifiers use it.

• In the UML, you can specify any of three levels of visible.

Public Symbol +

Protected Symbol #3

Private Symbol –

Scope

• Another important detail you can specify for classifiers attributes and operations isits owner scope.

• In the UML, you can specify two kinds of owner scope

Instance

Classifier

Multiplicity

• Whenever you use a class, it’s reasonable to assure that there may be any numberof instances of that class.

• Multiplicity applies to attributes, as well-you can specify the multiplicity of an attributeby writing a suitable expression is brackets just after the attribute name.

+Public Class name -Private -attribute #protected -attribute +operator -operator

1.. X

Company

Person

DMC 1753

NOTES


Attributes

• At the most abstract level, when you model a class is structural feature; you simplywrite each attributes name.

• There are three defined properties that you can use with attributes.

Changeable-There are no restrictions an modifying the attribute’s value.

Add only – For attributes with a multiply greater than one, additional valuesmay be added but once created, a value may not be removed or altered.

Frozen – the attributes value may not be changes after the object areinitialized.

• Unled otherwise specified, attributes are always changeable.

• You will mainly want to use frozen when modeling constant or write once attribute.

Operating

In an operation at the most abstract level, when you model class’s behavioral features,you will simply write each operation’s name.

• In the full form, the syntax of an operation in the UML is [Visibility] name[(Parameter-list)] [rectangle] [{property-string}]

• In an operation’s signature, you may provide zero or more parameters, each ofwhirch following the syntax

[Direction] name: type [=default-value]

• Direction may be any of the following values:

In-An input parameter

Out- An output parameter

In out- An input parameter

Template classes

• A template is a parameterized element. In such languages as C++ and ada, youcan write template classes, each of which defines family of classes.

• A template includes slots for classes, objects and values and these slots serve asthe template’s parameters.

• For a template class the result is a concrete class that can be used fust like anyordinary class.

• The most common use of template classes is to specify containers that can beinstantiated for specific elements making them type safe.

Standard Elements

• All of the UML’s extensibility mechanisms apply to classes.

• Most often you will use togged values to extend class properties.


NOTES


• The UML defines four standard stereotypes that apply to classes.

1. Metaclass –Specifies a classifiers whose objects are children of a given parent.

2. Power type - Specifies a classifier whose objects are children of a given parent.

3. Utility – Specifies a class whose attributes and operations are all class scoped.

3.7 COMMON MODELING TECHNIQUES

Modeling the semantics of a class:

• To model the semantics of a class chose among the following possibilities arrangedfrom informal to formal.

• Specify the responsibilities of the class. A responsibility is a contract or obligationof a type or class and is rendered in a note attacked to a class, or in an extracompartment in the class room.

• Specify the semantics of the class as a whole using structured text, rendered in anote attacked to the class.

• Specify the pre and post conditions of each operation plus the invariants of theclass as a whole, using structured text. These elements are rendered in notes attackedto the operation or class by a dependency relationship.

• Specify a state machine for the class. A state machine is a behavior that specifiesthe sequence of states an object goes through during its response to events, togetherwith its responses to those events.

• Specify collaboration has a structural part, as well as dynamic part, so you can usecollaboration to specify all dimensions of a class’s semantics.

• Specify the pre and post conditions of each operation, plus the invariants of theclass as a whole, using a formal language such as OCL.

Design patterns and Frameworks

In software engineering, a design pattern is a general reusable solution to a commonlyoccurring problem in software design. A design pattern is not a finished design that can betransformed directly into code. It is a description or template for how to solve a problemthat can be used in many different situations. Object-oriented design patterns typicallyshow relationships and interactions between classes or objects, without specifying the finalapplication classes or objects that are involved. Algorithms are not thought of as designpatterns, since they solve computational problems rather than design problems. Effortshave also been made to codify design patterns in particular domains, including use ofexisting design patterns as well as domain specific design patterns.

• A pattern is a common solution to a common problem in a given context.

• A mechanism is a design pattern that applies to a society of classes.

• A framework is an architectural pattern that provides an extensive template forapplications within a domain.

DMC 1753

NOTES


• It is rendered as a stereotyped package.

3.8 MODELING DESIGN PATTERNS

Identify the common solutions to the common problem and verify it as a mechanism.Model the mechanism as collaboration, providing its structural, as well as its behavioralaspects. Identify the elements of the design patterns that must be bound to elements in aspecific context and render them as parameters to the collaborations.

3.8.1 Modeling Architectural Pattern

To model an architectural pattern

Harvest the framework from an existing, proven architecture.

Model the framework as a stereotyped package, containing all the elements that arenecessary and sufficient to describe the various views of that framework.

Expose the slofs, tabs, knobs and dials necessary to adapt the framework in the formof design pattern and collaborations.

For the most part, this means making it clear to the user of the pattern which classesmust be extended, which operations must be handled.Modeling an architectural pattern.

Client command invoker receiver

Application Document

Command Paste command

Open command

Menu item


NOTES


Modeling an architectural pattern.

Comparison with other design methods

• The design of object-oriented software requires the definition of multi layeredsoftware architecture.

• The specification of subsystems that perform required functions and provideinfrastructure support.

• A description of objects that form the building blocks of the system and a descriptionof the communication mechanisms that allows data to flow between layers,subsystems and objects.

Activities of Object- Oriented Design Process

• Apply design axioms to design classes, their attributed, methods, associations,structures and protocols.

• Refine and complete the static UML class diagram.

• Define attributes.

• Design methods and protocols by utilizing a UML activity diagram.

• Define association between classes

• Define class hierarchy and design with inheritance.

• Iterate and refine again.

• Design the access layer

Create mirror classes: For every business class identified and created,create one access.

Identify access layer class relation ships.

Frame work Black Board

Black Board

Knowledge source Black board Control

Reasoning Ensire

Apply new knowledge source

Knowledge Source

DMC 1753

NOTES


Simplify classes and their relationships: It is used to eliminate redundantclasses and structures.

• Redundant Classes: Select one an eliminate the other classes, which has two similaroperations.

• Method Classes: Revisit the classes that consist of only one or two methods to seeif they can be eliminated or combined with existing classes.

• Literate and refine again

3.9©© DESIGN THE VIEW LAYER CLASSES

• Design the macro level user interface identifying view layer objects.

• Design the micro level user interface, which includes the following activities.

Design the view layer objects by applying the design Axions.

Build a prototype of the view layer interface.

• Test usability and user satisfaction.

• Iterate and refine.

• Iterate and refine the whole design.

• Reapply the design axions and, if needed, repeat the preceding steps.

3.10 OBJECTS ORIENTED DESIGN AXIOM

An axiom is a fundamental truth that always is observed to be valid and for whichthere is no counter example or exception.

A theorem is a proposition that may not be self-evident but can be proven fromaccepted axions.

A corollary is a proposition that from an axions or another proposition that has beenproven.

Axioms of Object-Oriented Design Axiom1:

• The independence axiom deals with relationships between system components.

• The components are such as classes, requirements and software components.

• It maintains the independence of components.

• It applies during design process of a system.

• Each component must satisfy that requirements without other requirements.

Axiom: 2

• The information axiom, which deals with the complexity of design.

• It minimizes the information content of the design.


NOTES


• Minimizing complexity should be goal, because that produces the most easilymaintained and enhanced application.

• It can implement through inheritance and the systems built in classes.

Exercises

1. What are the design attribute2. What do you meant by design pattern3. Explain about the multiplicity in OO design4. Differentiate the super class and subclass?5. Discuss the necessity for documentation6. Write a note on modeling techniques7. discuss about the object modeling techniques8. How do you design the design pattern for the object-oriented software?

DMC 1753

NOTES



NOTES


UNIT IV

OBJECT ORIENTED DESIGN

4.0 MANAGING ANALYSIS AND DESIGN

USE-CASE MODEL

• Use case is used to identify system requirements. A use-case model can beinstrumental in project development, planning and documentation of systems.

Example: Library system

Library system – The system provides functions like

• Add , remove, Find , edit books

• Add , remove, find edit borrowers

• Lend a book to a borrower

• Return a book by a borrower

The system keeps information about:

• Books – Author , title, subject , ISBN, Number of copies

• Borrower – Name , address , phone number

4.1 USE CASES

• Introduce by I.Jacabson (early 1990s).

• Document the behavior of the system from the user’s point of view.

• A use case is a narrative document that describes the sequence of event an actorperforms using a system to complete a process.

Use case diagrams contains

• Use cases (systems components): Wherent unit of functionality or task; it isrepresented by a named oval.

• Actors (user of the system): Anything external to the system – not only people: it isrepresented by a stick person.

• Communication associations: Links between actors and use cases; or representedby a solid lines.

DMC 1753

NOTES


The icon represents set of elements (similar to a class) and possible interactions (similarto class associations)

Use cases – named ovals; Borrow book , return book Actors – Stick person –borrower.

• The icons may represent a communication “ saran” (Borrower “ “ borrowing OOAD“ (Borrow book); an instance of the communication association linking borrowerand borrow book.

ACTORS

• An actor represents a role played by someone; the same member of library mayequally be borrower and administrator.

• An actor denoted a user interacting directly with the system.

• An actor identification = identifying roles played in the system.

• An actor may be external device or system.

OBJECTS ANALYSIS

• If the process to identify classes to achieve system goals and requirements.

CLASSIFICATION THEORY

• Classification is the process of identify the instantiation of object belongs to a classor to a category.

• Class is used to define the attributes , methods and applicability of its instance.

Example

• The class named “ Student” consists of attributes like roll no , name , class anddepartment.

• Each attribute is define by the property values such as

Use cases

Actor

Communication association

Borrow Book

Return Book


NOTES


Roll No = 20000

Name = Saran

Class = A

Department = Computer

• A class is also a specification of structure , behaviour, and the description of anobject.

• In object oriented programming, classification is used to define the classes theirdata structures.

• Object types provide an index for system process.

Example

• Operations like admit, rank, total are tied to the object type (class) student bywhich they the change the state of a student.

• Object can be categorized into more than one way.

4.2 APPROACHES FOR IDENTIFYING CLASSES

4.2.1 Noun Phrase Approach

• It was proposed by Rebacca Wrips – broak, brain willerson and Lausen wiener.

• Nouns in the textual description are considered to be classes and verbs to bemethods of the class.

• In this approach iterative process is implemented.

• Classes may be added or removed from the model dynamically.

• Use cases are used to identify requirements.

• Candidate classes are divided into three categories

o Relevant classes

o Fuzzy classes

o Irrelevant classes

Identifying Tentative classes

• Choose class name and define it carefully.

• Some classes are taken from built in classes for implementation ifa specific operation

• All classes must make sense in the application domain.

• Look for nouns and noun phrases.

• These are implemented in design phrase itself.

DMC 1753

NOTES


4.2.2 Selecting classes from the relevant and fazzy categories

a) Redundant classes

• Eliminate duplication of classes having some information.

• Select any one, which is more meaningful by comparing it in all manners.

• Choose appropriate vocabulary.

b) Adjective classes

• It is relevant.

• Choose whether the object represented by the noun behave differently when theadjective is applied to it.

c) Attribute classes

• Each class must have a purpose and every class should be clearly defined.

• Formulate a statement of purpose for each candidate.

• Identifying relevant classes and eliminating irrelevant classes is an incrementalprocess.

4.3 COMMON CLASS PATTERNS APPROACH

The following patterns are used to find the candidate class and object.

Concept class

• The concept class encompasses principles that are not tangible but used to organizeor keep back of business activities or communications.

• To communicate with others, store concephons and arrive at agreed concepts.

Events class

• It must be recorded in time.

• Attributes such as who, what, when, where, how, or why are associated withevent class.

Organization class

• It is a collection of people, resources, facilities, or groups to which the users belong.

Places Class:

• Places are physical locations that the system must keep information about.

Tangible things and devices class

• It includes physical objects or groups or objects that are tangible and devices withthe application interact.


NOTES


4.4 OBJECT RELATIONSHIPS, ATTRIBUTES, AND METHODS

Associations

• it represents a physical or conceptual connection between two or more objects.

• The association name can be omitted if the relationship if default. e.g: Companyhas a name, ACCn number.

Operations (methods)

• Operations are actions / function / transformations on an object. e.g: withdrawmight be an operation on a bank account.

Identifying Associations

• Examine the responsibilities to determine dependencies.

• Determine the capability of class and it needs with their relationships.

Guidelines for identifying association

• A dependency between two or more classes may be an association. Itcorrespondents to a verb or promotional phrase

• A reference from one class to another is an association.

4.5 ASSOCIATION PATTERNS

Location Association

• It includes next to, past of, contained in the definition of object relationships.

• An Example- Student object fee is a part of it.

Communication association

• It includes takes to, order to.

• It used to communicate with other classes and objects.

• Example: A customer places an order with an operation person.

4.6 ELIMINATION OF UNNECESSARY ASSOCIATION

Implementation association

• Actor implementation- specific association to the design place.

• It is not relationship among objects.

• It is concerned with implementation or design or the class.

Ternary Association

• X-ray association is an association among more than two classes.

• Restate ternary association as binary associations.

DMC 1753

NOTES


Directed actions

• It is also called as derived associations.

• It can be defined in terms of other associations.

• Avoid this association because theses are redundant terms.

4.7 RELATIONSHIPS

• A relationship exists between any two classes that are connected.

• Making the relationship between two classes can be useful to interface to shareattributes rough objects.

Super – sub class relationships

Guidelines for identifying super-sub relationships, a generalization.

Top-down approach

• Point out mean phrases composed of various adjectives in a class name.

• Specialize only when the subclasses have significant behavior.

• Example: a machine operator can be represented as a clerk, as a manager, or as acook.

Bottom up approach

• Point out classes with similar attributes methods.

• Group then by moving common attributes and methods to an abstract class.

Re usability

• Group common attributes and behavior as high as possible in the hierarchy.

• Inherit it by creating new class with their own attributes and methods.

Multiple Inheritances

• Avoid more multiple inheritances because it results in complication of access anddetermination of the behavior.

• It also more difficult to understand programs written is a multiple inheritance.

A-Part-of Relationships-Aggregation

• A-part-of relation (aggregation) represents the situation where a class consists ofseveral component classes.

• Behavior each is unique.

• Properties of aggregation.


NOTES


• Transitivity

If a part of B and B is a part of C, then A is part of C.

• A tube is part of wheel and wheel is a part of bicycle; therefore tube is part of abicycle.

• Anti symmetry

If A is part of B; then B is not part of A.

• Wheel is a part of bicycle, but bicycle is not part of wheel.

Propagation

The state of the whole is determined by the state of the parts.

A-part-of Relationship patterns

To identify a-part-of structures.

Assembly

An assembly is constructed from its parts and an assembly part situation physicallyexists.

Example

A bicycle is an assembly of wheel, frame, bell, chain and so on.

Container

• A physical whole encompasses but its not constructed from physical parts.

Example: A fridge can be container for fruits, drinks, other eatable items.

Collection-member

A conceptual whole encompasses parts that may be physical or conceptual.

Example: A correct team is a collection of players.

4.8 CLASS AND OBJECT RESPONSIBILITIES

• Class responsibility – collaborates (CRC) provides a simple means for identifyingand organizing the classes that are relevant to system or product requirement.

• It is a collection of standard index cards that represent classes.

• The cards are divided into three sections.

o Along the top of the card you write the name of the class.

o In the body of the card you let the class responsibilities on the left.

o The collaborations on the right.

DMC 1753

NOTES


Classes

Identifying classes and object responsibilities

4.19 CHARACTERISTICS OF CLASSES AND OBJECT

• Retained Information

• Needed Services.

• Multiple attributes

• Common attributes

• Common operations

• Essential requirements

• Revue Classes

• Property classes

• Interaction classes

• Tangibility

• Inclusiveness

• Sequentially

• Persistence

• Integrity

Responsibilities

Guidelines for allocating responsibilities to classes:

• System intelligence should evenly distributed.

• Each responsibility should be stated as generally as possible.

• Information and the behavior related to it should reside within the same class.

• Information about are thing should be localized with a single class, not distributedacross multiple classes.

• Responsibilities should be shared arrows related classes when appropriate.

CRC Forms

• You may find it useful to organize the details of classes with CRC (Classresponsibility collaboration) forms to record the information, using one for eachclass.

• The idea is to organize the relationships between the classes on the basis of fulfillinga scenario.

• The CRC forms provide a mechanism for following through a scenario, identifyingrelationships from the scenario, and allocating attributes and operations to classesin a review process.


NOTES


Note: CRC formed can also be used early in the design process as a discovery aid.

When the operations and responsibilities of a class identified through design reviews,details are added to the form.

Class name:

Super class:

Role:

Attributes:

Responsibilities:

Example CRC Forms

Class name: Bank

Super class: Nil

Role: Validates transactions is customers communicate with the Bank’s central

account database.

Attributes: Customers, accounts.

Responsibilities: Validate a customer card, PIN validate a withdraw transaction card.

Account.

Class name: With drawl

Super class: Transaction

Role: Store withdraws transaction information.

Attributes: Data, time, account, card ID, Aim Id and Amount.

Responsibilities: Knowing date, time, amount, and card transactions.

4.10 OBJECT-ORIENTED DESIGN PROCESS

• The design of object oriented software requires the definition of multi layeredsoftware architecture.

• The specification of subsystems that perform required functions and provideinfrastructure support.

• A description of object (Classes) the form the building clocks of the system.

• Description of the communication mechanisms that allow data to flow layers, subsystems and objects.

Activities of Object-Oriented design process

• Apply design options to design classes, their attributes, methods, associations,structures, and protocols.

o Define and complete the static UML utility a UML activity diagram.

o Define associations between classes.

DMC 1753

NOTES


o Define class hierarchy and design with inheritance.

o Literate and refine again

Design the access layer

o Create mirror classes: For every Business class identified and created, create areaccess.

o Identifying access layer class relationships.

o Simplify classes and their relationships it is used to eliminate redundant classes andstructures.

o Redundant classes – select one and eliminate the other classes, which have twosimilar operators.

o Method classes – Revisit the classes that consist of only one or two methods tosee to they can be eliminated or combined with existing classes.

o Iterate and refine again.

Design the view layer classes

• Design the macro level user interfaces, identifying view layer objects.

• Design the micro level user interface, which includes the following activities.

o Design the view layer objects by applying the design opioms.

o Build a prototype of the view layer interface.

• Test usability and user satisfaction.

• Iterate and refine.

• Iterate and refine the whole design. Reapply the design axioms and, if needed,repeat the preceding steps.

Object Oriented Design Axioms

• An axiom is a fundamental much that always is observed to be valid and for whichthere is no counter example or exception.

• A theorem is a preposition that may not be key-orient but can be proven fromaccepted ascoms.

• A corollary is a preposition that follows from an axioms or another propositionthat has been proven.

4.11 AXIOMS OF OBJECT-ORIENTED DESIGN

Axiom – 1

• The independence axiom deals with relationships between system components.

• The components are such as classes, requirements and software components.

• It maintaining the independence of components.


NOTES


• It applies during design process of a system.

• Each component must satisfy that requirement without other requirements.

Axiom – 2

• The information axiom, which deals with the complexity of design.

• It minimum the information content of the design.

• Minimizing complexity should be goal, because that produces the most easilymaintained and enhanced application.

Corollaries

• The corollaries can be derived as a direct consequence of the axioms from the twodesign axioms.

• These will useful in making specific design decisions.

• Corollary can be called as design rules

Corollary 1

Uncoupled – design with less information content:

• Highly cohesive objects can improve coupling because only a minimal amount ofessential information need be passed between objects.

• In this rule the main goal is to maximize object. Whensivenets among objects andsoftware components in order to improve coupling.

• It is because a minimal amount of essential information needed to be passes betweencomponents.

4.12 COUPLING

• Coupling is a measure of interconnection among modules in a software structure.

• It depends on the interface complexity between modules, the point at which entryor reference is made to a module, and what data pass across the interface.

• It is a measure of the strength or association established by a connection from oneobject or s/w component to another.

Types of coupling

• Common coupling

o It is highly coupling occurs when a number of modules (objects) reference aglobal data ones.

o The objects will access a global data area. For both to read and write operationof attributes.

DMC 1753

NOTES


Content Coupling

• It is the highest degree of coupling. It occurs often on object or module makes useof data or control information maintained within the boundary of another object ormodule.

• It refers to attributes or methods of another object.

Control Coupling

• It is characterized by passage of control between modules or objects.

• It is very common in most software designs.

• It involves explicit control of the processing logic of one object by another.

Stamp coupling

• The connection involves passing an aggregate data structure to another object,which uses only a portion of the component of the data structure.

Data coupling

• It is very low degree of coupling

• The connection involves either simple data items or aggregate structure all of whoseelements are used by the receiving object.

• This should be the goal of an architectural design.

• IT is exhibited in the portion of structure.

Cohesion

• Cohesion is an interaction with in a single object of software component.

• It refers the single purposes ness of an object.

• Coincidentally cohesion is a cohesion that performs tasks that are related logicallyeach other objects.

• Method cohesion like function cohesion means that a method should carry onlyone function.

• Inheritance cohesion concerned with interrelation of classes with attributes.

4.13 DESIGN PATTERNS

• A design patterns are devices that allows system to share knowledge about theirdesign, by describing commonly recurring structures of communicative componentsthat share a general design problem within a particular content.

Describing a design pattern

The information to be specified while designing pattern

• The name of the pattern


NOTES


• The intent of the pattern

• The design forces that motivate the pattern.

• The solution that motivates these forces.

• The classes that are required to implement the solution classes.

• Guidance that leads to effective implementation

• Example source code or source code templates.

• Cross-reference to related design patterns.

Class Design

Class is a single unit that encapsulates attributes and methods and accessed by thecreated object.

Activities to designing class

Design class with the UML class diagram by adding the defants to the diagram suchas

• Refining attributes.

• Design methods ad the protocols by utility a UML activity diagram to representthe method’s algorithm.

• Define the class hierarchy and design with inheritance.

Iterate and refine the class system.

4.14 CLASS VISIBILITY

Visibility

• Use visibility markers to signify who as access the information contained within aclass

• Private visibility hides information from anything outside the class information.

• Public visibility allows all other classes to view the marked information.

• Protected visibility allows child classes to accesses information they inherited froma parent class.

Designing well-defined public, private and protected protocols

• Protocols or interface operation or the messages that a class understands is usedto define the rules to access the attributes of another class from one class usingprotocols specified.

• The private protocols of the class includes message that normally should not besend from other objects.

• It is accessible only to operations of the class.

DMC 1753

NOTES


• In private protocol, only the class itself can use the method.

• The public, only the class itself can use the method.

• The public protocol defines the stated behavior of the class as global and it isaccessible to all classes.

o It is accessible to operation of all classes in a module.

o It used to access with external message of other object.

• In a protected protocol, the methods or attributes can be used by the class itself orits subclasses.

Refining Attributes

• Attribute identified in object-oriented analysis must be refined with implementedduring design phrase.

• In the analysis phrase, the name of the attribute was sufficient.

• In the design phrase, detailed information must be added to the model.

Attribute Types

1. Single value attributes

• It has only one value or state.

• Example name, address or salary.

2. Multiplicity or multi value attributes

• It can have a collection of many values at any point in time.

• To list the student who have scored above 805 marks.

3. Instance connection

• It is reference to reference to another object

• It provides the mapping needed by an object to fulfill its responsibilities.

• Example a person can have more than one account.

4.15 UML ATTRIBUTE PRESENTATION

Syntax:

Visibility name : Type – expression = initial – value

Where visibility may be

+ Public visibility

# protected visibility

- Private visibility


NOTES


EXERCISE

1. Design a Railway reservation system with object oriented approach

2. How to perform the association between objects and classes in detail

3. Represent the ex,1 in the design diagram

4. Identify the super class and sub class in the above design

5. Analyze the railway system in detail?

6. What do you meant by Class Visibility?

DMC 1753

NOTES



NOTES


UNIT V

SOFTWARE QUALITY

5.0 QUALITY ASSURANCE TESTS

• Quality assurance is a conformance to explicitly stated functions and performancerequirements, explicitly documented standards, and implicit characteristics thatare of all professionally developed software.

• Quality assurance is an essential activity for any business thay producer productsto be used by others. Quality Assurance makes sure the project will be completedbased on the previously agreed specifications, standards and functionality requiredwithout defects and possible problems. It monitors and tries to improve thedevelopment process from the beginning of the project to ensure this. It is oriented to“prevention”.

• Three kinds of error:

o Language (syntax) error

o Runtime error

o Logic error

Elimination of these errors is called as debugging. Debugging is a methodical processof finding and reducing the number of bugs, or defects, in a computer program or a pieceof electronic hardware thus making it behave as expected. Debugging tends to be harderwhen various subsystems are tightly coupled, as changes in one may cause bugs to emergein another.

• Quality assurance test are divided into two categories• Error – based testing• Scenario – based testing (usage based testing)

5.1 TESTING STRATEGIES

• Testing is a process of executing a program with the intent of sending an error. Amethod to evaluate whether learners can demonstrate abilities and skills relatedto content being taught.

• A deliberate attempt by people to acquire information about themselves or others.”

DMC 1753

NOTES


Types of Testing

• System Testing

o Recovery Testing

o Security Testing

o Stress Testing

o Performance Testing

• Unit Testing

• Integration Testing

o Top-down Testing

o Bottom-up Testing

o Regression Testing

o Smoke Testing

• Validation Testing

• Black box Testing

• White box Testing

5.2 SYSTEM TESTING

It is a series of different tests whose primary purpose, all work to verify that systemelements have been properly integrated and perform allocated functions. System testing ofsoftware or hardware is testing conducted on a complete, integrated system to evaluatethe system’s compliance with its specified requirements.

System testing falls within the scope of black box testing, and as such, should requireno knowledge of the inner design of the code or logic. System testing is performed on theentire system in the context of a Functional Requirement Specification(s) (FRS) and/or aSystem Requirement Specification (SRS).

System testing is an investigatory testing phase, where the focus is to have almost adestructive attitude and test not only the design, but also the behavior and even the believedexpectations of the customer. It is also intended to test up to and some suggest beyond thebounds defined in the software/hardware requirements specification(s) - although how thisis meaningfully possible is undefined.

5.3 UNIT TESTING

In computer programming, unit testing is a test (often automated) that validatesthose individual units of source code is working properly. A unit is the smallest testable partof an application. In procedural programming a unit may be an individual program, function,procedure, etc., while in object-oriented programming, the smallest unit is a method, whichmay belong to a base/super class, abstract class or derived/child class.


NOTES


• It focuses verification effort on the smallest unit of software-design the softwaremodule or component.

• It tests the coding step by step.• Individual component are tested to ensure that they operate correctly.

5.4 INTEGRATION TESTING

Integration testing takes as its input modules that have been unit tested, groups themin larger aggregates, applies tests defined in an integration test plan to those aggregates,and delivers as its output the integrated system ready for system testing.

1. Top-down Testing

Top-down software testing is an incremental unit testing method which begins bytesting the top level module, and progressively adds in lower level modules, one at atime.

• It involves starting at the sub-system level with modules represented byships.

• Stabs are simple components, which have the same interface as the module.

• Top-down testing should be used with top-down program developmentso that a module is tested as soon as it is coded.

ADVANTAGES

o All the advantages listed for incremental testing apply. As well:o There is less overhead than with the big bang method:o No drivers need to be written when top-down testing is used.o Top-down testing provides an early working model of the program.

This model can be presented to the user for an early test of the system. Design flawscan thus be detected early and corrected.

DISADVANTAGES

Stubs still have to be written. While automated tools do exist which ease the writingof both stubs and drivers, stub tools are harder to find. As well, stubs are difficult to writesince they must simulate the setting of output parameters in a way meaningful enough toavoid introducing new errors yet simple enough to be a stub and not the real thing.

2. Bottom-up testing

Bottom-up approach is essentially piecing together systems to give rise to grandersystems, thus making the original systems sub-systems of the emergent system. In a bottom-up approach the individual base elements of the system are first specified in great detail.These elements are then linked together to form larger subsystems, which then in turn are

DMC 1753

NOTES


linked, sometimes in many levels, until a complete top-level system is formed. This strategyoften resembles a “seed” model, whereby the beginnings are small but eventually grow incomplexity and completeness. However, “organic strategies” may result in a tangle ofelements and subsystems, developed in isolation and subject to local optimization asopposed to meeting a global purpose

• It involves testing the modules at the lower levels in the hierarchy, and then workingup the hierarchy of modules until the final module is tested.

• In bottom-up testing, you start with the methods and classes that call or rely on noothers.

3. Regression testing

Regression testing is any type of software testing which seeks to uncover regressionbugs. Regression bugs occur whenever software functionality that previously worked asdesired, stops working or no longer works in the same way that was previously planned.Typically regression bugs occur as an unintended consequence of program changes. Effectiveregression tests generate sufficient code execution coverage to exercise all meaningfulcode branches.

• It is conducted manually, by re-executing a subset of all test cases or using automatedcapture / play back tools.

• The subset of test to be executed contains three different classes of test cases.• A representative sample of tests.• Additional tests that focus on s/w functions.• Tests that focus on s/w components that have been changed.

4. Smoke testing

Smoke testing is a term used in plumbing, woodwind repair, electronics, and computersoftware development. It refers to the first test made after repairs or first assembly toprovide some assurance that the system under test will not catastrophically fail. After asmoke test proves that the pipes will not leak, the keys seal properly, the circuit will notburn, or the software will not crash outright, the assembly is ready for more stressfultesting.

In software engineering, a smoke test generally consists of a collection of tests thatcan be applied to a newly created or repaired computer program. Sometimes the tests areperformed by the automated system that builds the final software. In this sense a smoketest is the process of validating code changes before the changes are checked into thelarger product’s official source code collection. Next after code reviews, smoke testing isthe most cost effective method for identifying and fixing defects in software; some evenbelieve that it is the most effective of all.


NOTES


• It is an approach that is commonly used when “shrink wrapped” softwareproducts are being developed.

• It is deigned for time – critical projects.

5.5 VALIDATION TESTING

Validation is a process of finding out if the product being built is right?

i.e. whatever the software product is being developed, it should do what the user expectsit to do. The software product should functionally do what it is supposed to, it shouldsatisfy all the functional requirements set by the user. Validation is done during or at the endof the development process in order to determine whether the product satisfies specifiedrequirements.

Validation and Verification processes go hand in hand, but visibly Validation processstarts after Verification process ends (after coding of the product ends). Each Verificationactivity (such as Requirement Specification Verification, Functional design Verification etc.)has its corresponding Validation activity (such as Functional Validation/Testing, CodeValidation/ Testing, System/Integration )

All types of testing methods are basically carried out during the Validation process.Test plan, test suits and test cases are developed, which are used during the various phasesof Validation process. The phases involved in Validation process are: Code Validation/Testing, Integration Validation/Integration Testing, Functional Validation/Functional Testing,and System/User Acceptance Testing/Validation

• Validation involves checking that the program as implemented meets the expectationsof the software procurer.

• It is the task of predicting correspondence; ok? True correspondence cannot bedetermined until the system is in place.

• Verification involves checking that the program conforms to its specification.

• Statistical testing and defect testing are used to meet the dual objective of thevalidation verification process.

5.6 TEST PLANS

• Test planning is concerned with setting out standards for the testing rather thandescribing product tests.

• It should included significant amounts of contingency so that pages in design andimplementation can be accommodated and staff allocated to testing can be deployedin other activities.

• Test plan is not a static document. It should be revised as testing is an activity,which is dependent on implementation being complete.

DMC 1753

NOTES


Test plan documents the strategy that will be used to verify and ensure that a hardwareproduct or system meets its design specifications and other requirements. A test plan isusually prepared by or with significant input from Test Engineers.

Depending on the product and the responsibility of the organization to which the testplan applies, a test plan may include one or more of the following:

• Design Verification or Compliance test - to be performed during the developmentor approval stages of the product, typically on a small sample of units.

• Manufacturing or Production test - to be performed during preparation orassembly of the product in an ongoing manner for purposes of performanceverification and quality control.

• Acceptance or Commissioning test - to be performed at the time of delivery orinstallation of the product.

• Service and Repair test - to be performed as required over the service life of theproduct.

A complex system may have a high level test plan to address the overall requirementsand supporting test plans to address the design details of subsystems and components.

Test plan document formats can be as varied as the products and organizations towhich they apply, but there are three major elements of a test strategy that should bedescribed in the test plan: Test Coverage, Test Methods, and Test Responsibilities.

Test coverage in the test plan states what requirements will be verified during whatstages of the product life. Test Coverage is derived from design specifications and otherrequirements, such as safety standards or regulatory codes, where each requirement orspecification of the design ideally will have one or more corresponding means of verification.Test coverage for different product life stages may overlap, but will not necessarily beexactly the same for all stages. For example, some requirements may be verified duringDesign Verification test, but not repeated during Acceptance test.

5.7 STEPS TO CREATE A TEST PLAN

1. Objective of the test: create the objectives and describes how to achieve them.2. Development of a test case: develop test data, both input and expected output

based on the domain of the data and the expected behaviors that must be tested.3. Test analysis: it involves the examination of the test output and the documentation

of results.

Guidelines and Test plan components

• Requirement specification• System specification


NOTES


• System design• Detailed design• Acceptance test• System integration test• Sub-system test.• Module and unit code test• Service

Test plan Contents

• The testing process• Requirements baveability• Tested items• Testing schedule• Test recording procedures• Hardware and software requirements.• Constraints

Guidelines

• You should have requirements.• The test plan should contain a schedule and list of required resources.• Determine type of testing.

5.8 TEST CASE

Test case in software engineering is a set of conditions or variables under which atester will determine if a requirement or use case upon an application is partially or fullysatisfied. It may take many test cases to determine that a requirement is fully satisfied.

Test cases are often incorrectly referred to as test scripts. Test scripts are lines ofcode used mainly in automation tools.

Continuous Testing

Continuous testing uses excess cycles on a developer’s workstation to continuouslyrun regression tests in the background, providing rapid feedback about test failures assource code is edited. It reduces the time and energy required to keep code well-tested,and prevents regression errors from persisting uncaught for long periods of time.

• Software is tested to determine whether it conforms to the specification ofrequirements.

• S/w is maintained when errors are found and corrected, and s/w is extended whennew functionally is added to an already existing program.

DMC 1753

NOTES


• A common practice among development is to turn over application to a qualityassurance (QA) group for testing only after development is completed.

Steps to Successful Testing

• Understand and communicate the business case for improved testing.• Develop an interval infrastructure to support continuous testing.• Look for leaders who will commit to and own the process• Measure and document your findings in a defect recording system.• Public improvements as they are made and let people know what they are doing

better.

5.9 DEBUGGING PRINCIPLE

Debugging occurs as a consequence of successful testing.

Characteristics of bugs provide some dues:

• The symptom and the cause may be geographically remote.• The symptom may disappear.• The symptom may actually be caused by no errors.• The symptom may be result by human error that is not easily braved.• The symptom may be a result a turning problems, rather than processing problems.• It may be difficult to accurately reproduce input conditions.• The system may be due to causes that are distributed across a number of tasks

running on different processors.• The symptom may be intermittent.

User Satisfaction Test

User satisfaction testing is the process of quantifying the usability test with somemeasurable attribute of the test, such as functionality, test or case of use.

Objectives of the user satisfaction test

• As a communication vehicle between designers as well as between users anddesigners.

• To detect and evaluate changes during the design process• To provide a periodic changes during the design process• To provide a periodic indication of divergence of opinion about the current design.• To enable pinpointing specific indication areas of dissatisfaction for remedy.• To provide clear understanding of completed design is to evaluate.


NOTES


Measure user Satisfaction

• Commercial off-the-salary (OTS) s/w tools are used for analyzing and conductinguser satisfaction tests.

• The user satisfaction test spreadsheet (USIS) automates many book keeping tasksand can assets in analyzing the user satisfaction level.

• It shoes pattern in user satisfaction level

• The user satisfaction test can be a tool for finding out what attribute are importantor unimportant.

User satisfaction Cycle

1. Create a user satisfaction test for you’re a project.

2. Create a custom form that fits the prefect’s needs and the culture of your organization.

3. Make sure to involve the user in creation of the test.

4. Conduct the test regularly and frequently

5. Read the comments very carefully, especially if they express a strong feeling.

6. Use the information from user satisfaction test, usability test, reactions to prototypes,interviews recorded and other comments to improve the product.

5.10 CODING

• The implementation phase of software development is concerned with translatingdesign specification into source code.

• The pr5imary goal of implementation is to write source code and internal documentso that conformance of the code to its specification can be easily verified, and sothat debugging, testing and modifying are eased.

• Source code clarity is enhanced by structured coding techniques.

Dos of good coding style

• Use a few standard agreed upon control construct.

• Use in a disciplined way.

• Introduce user-defined data types to model entities in the problem domain.

• Hide data structure behind access functions.

• Provide standard documentation prologues for each sub program and/orcomplication unit.

• Carefully examine routines having fewer than 5 or more 25 executives statements.

• Use indentation, parenthesis, black spaces, blank lines and borders around commentblocks to enhance readability.

DMC 1753

NOTES


Don’t of good coding style

• Don’t be two clever

• Avoid null then statement.

• Avoid then.. if statements

• Don’t nest deeply

• Avoid assume side effects

• Don’t sub optimistic

• Carefully examine routines having more than five formal parameters.

• Don’t use an identifies to multiple purpose.

Programming standard right specify items such as

• Go to statements will not be used.

• The nested depth of program constructs will not exceed five levels.

• Subroutines length will not exceed 30 lines.

A guideline rephrases these specifications in the following manner.

1. The use of goto statement should be avoided in normal circumstances.

2. The nesting depth of program constructs should be five or loss in normalcircumstances.

The number of executable statement in a sub program should not exceed 30 in normalcircumstances.

3. Parture from normal circumstances requires approval by the project leader.

5.11 MAINTENANCE

In software engineering, software maintenance is the modification of a softwareproduct after delivery to correct faults, to improve performance or other attributes, or toadapt the product to a modified environment

This international standard describes the 6 software maintenance processes as:

1. The implementation process contains software preparation and transition activities,such as the conception and creation of the maintenance plan, the preparation forhandling problems identified during development, and the follow-up on productconfiguration management.

2. The problem and modification analysis process, which is executed once theapplication has become the responsibility of the maintenance group. Themaintenance programmer must analyze each request, confirm it (by reproducingthe situation) and check its validity, investigate it and propose a solution, document


NOTES


the request and the solution proposal, and, finally, obtain all the requiredauthorizations to apply the modifications.

3. The process considering the implementation of the modification itself.

4. The process acceptance of the modification, by checking it with the individual whosubmitted the request in order to make sure the modification provided a solution.

5. The migration process (platform migration, for example) is exceptional, and is notpart of daily maintenance tasks. If the software must be ported to another platformwithout any change in functionality, this process will be used and a maintenanceproject team is likely to be assigned to this task.

6. Finally, the last maintenance process, also an event which does not occur on adaily basis, is the retirement of a piece of software

Way of maintenance

1. All of these programs all of these sources statements have to be corrected whenfaults were detected modified as user requirements changed purchased. Theseactivities were collectively called software maintenance.

2. The maintenance phase focuses on change that is associated with error correction,adaptation required as the software’s environment evolves.

3. The changes due to enhancements brought about changing customer requirements.

4. The maintenance phase reapplies the steps of the definition and development phases.

5. There are four types of phases

• Correction

• Adaptation

• Enhancement

• Prevention

a.Correction

1. Even with the best quality assurance activities, it is likely that the customer willuncover defects in the software.

2. Corrective maintenance changes the software to correct defects.

b. Adaptation

1. Adaptive maintenance results in modification to the software to accommodatechanges to its external environmental.

c. Enhancement

1. As software is used. The customer/ user will recognize additional function that willprovide benefit.

DMC 1753

NOTES


2. Perceptive maintenance extends the software beyond its original functionalrequirements

d. Prevention

1. Computer software detevotes due to change, and because of this preventivemaintenance often called software reengineering.

2. it must be conducted to enable the software to serve the needs of its and user.

5.12 TYPICAL CATEGORIES IN THE FOLLOWING PHASES

They are

1. Software project tracking and control.2. Formal technical reviews.3. Software quality assurance.4. Software configuration management.5. Document preparation and production.6. Reusability management7. measurement8. Risk management.

Brief about maintenance in models

1. Maintenance is software will undoubtedly undergo change after it is delivered tothe customer.

2. Change will occur because errors have been encountered, because the softwaremust be adopted to accommodate changes in its external environment.

3. Real project rarely follow the sequential flow that the model proposes.

4. although the linear model can accommodate iteration, it does so indirectly

5. Change can cause confusion as the project beam proceeds.

6. Its often difficult for the customer to state all requirements explicitly.

7. The linear sequential model requires thus an has difficulties accommodating thenatural uncertainness that exists at the beginning of many projects.

8. The customer must have patience.

9. Developers are often delayed unnecessarily.

10. In an interesting analysis of actual project

11. In fact, the times spent waiting can exceed the time spend on productive work.

12. The blocking starts at beginning and end of linear sequential process.

5.13 SOFTWARE CONTINUATION MANAGEMENT

In software engineering, software configuration management (SCM) is the taskof tracking and controlling changes in the software. Configuration management practicesinclude revision control and the establishment of baselines


NOTES


1. Maintenance is a set off software engineering activities that occur after softwarehas been delivered so the customer.

2. Software configuration management is a set of tracking and control activities thatbegin when a software projects begins.

3. It terminates only when the software is taken out of operation.

Software Maintenance

1. The maintenance of existing software can account of over 60% of all effort expendedby a development organization.

2. The ubiquitous nature of change underlies all software work.

3. Change is inevitable when computer based system are built.

4. Their external environment, making enhancement requested by user andreengineering an application.

5. When maintenance is considered to encompasses all of these activities. It is relativelyeasy to see and absorbs.

Metrics

The primary objectives for object-oriented metros are the same as those metric derivedfor conventional software.

• To better understand the quality of the product.

• To assess the effectiveness of the process.

• To improve the quality of work performed at a perfect level.

5.14 THE DISTINGUISHING CHARACTERISTIC

Localization

Localization is a characteristic of software that indicates the manner in which informationis concentrated within a program.

Encapsulation

• Berard defines encapsulation as “the packaging of a collection of items, low levelexamples of encapsulation include records and array, sub program or mid-levelmechanism for encapsulation”.

• For OO systems, encapsulation encompasses the responsibilities of a class, includingits attributes and operations, and the states of the class, as defined by specifyingattribute values.

• Encapsulation influences metris by changing the focus of measurement from a singlemodule to a package of data and processing modules.

DMC 1753

NOTES


Information hiding

• Information hiding suppresses the operational details of a program component.

• Only the information necessary to access the component is provided to thoseother components that wish to access it.

• A well-designed oo system should encourage information hiding.

Inheritance

• Inheritance is a mechanism that enables the responsibilities of one object to bepropagated to other objects.

• Inheritance occurs throughout all levels of a class hierarchy.

• In general conventional S/w does not support this characteristic.

• Because inheritance is a petal characteristics many OO system, many OO Metrisfocus on it.

Abstraction

• Abstraction is a mechanism that enables the designees to focus on the essentialdetails of the program component without concern for lower- level details.

• Oo metrics represent abstraction in terms of measures of a class.

Merits for the OO design model

• An objective view of design should have a quantitative component and that leadsto OO metrics.

• In really, technical metric for OO system can be applied not only to the designmodel, but also to the analysis model.

OOPs oriented metrics

• The class is the fundamental unit of an Oosystem.

• Therefore, measures and metrics for an individual class, the class hierarchy andclass collaboration will be invaluable to a S/W engineer who must assist designquality.

Operation-oriented metrics

• There are however, some insights that can be gained by examining averagecharacteristics for class operations.

• Three simple metrics, proposed by Lorenz and led are noted below

o Average operation size (OSANG)

o Operation complexity (OC)

o Average number of parameters per operation (NPARS)


NOTES


Metrics for object-oriented testing

• Binder [BN94] suggests a broad array of design. Metris that have direct influenceon the ‘testability’ of an oo system.

• The metric are organized into categories that reflect important design characteristics.

o Encapsulation

• Lack of cohesion in methods [LCOM]

• Percent public and protected [PAP]

• Public access to data members [PAP]

Inheritance

Number of root classes (NOR)

Fon in [FIN] fan in indication of multiple inheritances.

Number of children (NOC) and depth of inheritance the (DIT)

Merits for co-projects

Number of scenario scripts (NSS) -> the number of scenario scripts or use cases isdirectly proportional to the number of classes required to meet requirements. NSS is thestrong indication for program six.

Number of key classes (NKC) -> A key class focuses directly on the business domainfor the problem and will have a lower probability of being implemented the reuse.

Number of sub system (NSUB) -> the number of subsystem provides insight intoresources allocation, scheduling and overall integration effort.

Exercise

1. What is software testing?2. What are the different types of testing?3. Explain the validation testing with an example?4. Differentiate the validation and verification testing?5. Explain about white box and black box testing?6. Explain about the smoke testing?7. Why do we maintenance?8. What is software configuration management?9. Define object oriented metrics?10. Justify the testing helps for the software improvement?

DMC 1753

NOTES


NOTES


NOTES


NOTES

DMC 1753

NOTES


NOTES

Date post:	14-Apr-2015
Category:	Documents
Upload:	andrew-walls
View:	3,422 times
Download:	289 times