OBJECT-ORIENTED ANALYSIS & DESIGNbvicam.in/sites/default/files/subject/LearningMannuals... · · 2017-11-06Abstraction (from the Latin abs, ... Association Aggregation CitiComposition

OBJECT-ORIENTED ANALYSIS & DESIGN

© Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63, by Anukiran Jain U1. ‹#›

Terms & DefinitionsTerms & Definitions


The Procedural Paradigm• The traditional paradigm had great successes initially

It started to fail with larger products (> 50 000 LOC) It started to fail with larger products (> 50,000 LOC)

• Maintenance problems (today, up to 80% of effort)

• Reason: structured methods are

Action oriented (data flow diagrams/Procedural abstraction); orAction oriented (data flow diagrams/Procedural abstraction); or

Data oriented (entity-relationship diagrams/data abstraction);

But not both


Object Oriented Paradigm

An approach to the solution of problem in which all

t ti f d i th t t f bj tcomputations are performed in the context of objects.

The objects are instances of programming constructs,

normally called classes, which are data abstractions

with procedural abstractions that operate on the objectswith procedural abstractions that operate on the objects.• Data Abstraction + Procedural Abstraction


Object Oriented System

• make use of abstraction in order to help make software

l lless complex

• Combine procedural abstraction with data abstractionp

• Procedural Abstraction

• Functions & Routines

• Data Abstraction• Data Abstraction

• Records & Structure


Abstraction

Abstraction (from the Latin abs, meaning away from and trahere,i t d ) i th f t ki imeaning to draw) is the process of taking away or removing

characteristics from something in order to reduce it to a set ofessential characteristicsessential characteristics

C id ti f “ ti l” d t il l t d t th ti f thConsideration of “essential” details related to the perspective of the

viewer/application/subject and leaving out the rest


Encapsulation

W i d t & d l b t ti Wrapping data & procedural abstraction


Data Hiding

Hidi f i l t ti “d t il ” d h i l th Hiding of implementation “details” and showing only the necessaryinterfaces


Object

• A concrete manifestation of an abstraction

• Instance of a class

• the basic run time entities in an object oriented system.

• match closely with real time objects.

• take up space in memory and have an associated address like a

Record in Pascal and a Structure in C.

• Objects interact by sending Message to one other• Objects interact by sending Message to one other.


Class• a general specification or description for a set of objects that

share common properties & behavior/ relationships.

• In fact, objects are the variables of the type class.

Cl d fi d d t t d b h lik th• Classes are user defined data types and behaves like the

built-in types of a programming language.


Messages and Receivers

• method call is referred to as a message g

• Message a request for action, bundled with whateverMessage a request for action, bundled with whatever objects may be necessary to complete the task

• The Object through which method is called known as receiver of message

• Objects communicate through messages


j g g

Polymorphism and Overloading

• the capability of having methods with the same names

d t t hibit diff t b h iand parameter types exhibit different behavior

depending on the receiver is known as Polymorphism

• the capability of using names to mean different things in

different contexts is called overloadingdifferent contexts is called overloading


Persistence

• Allows the state of an object to be saved to non-volatile

t h fil d t b d l t t dstorage such as a file or database and later restored

even though the original creator of the object no longer

exists


Inheritance• the capability of defining a new class of objects that

inherits from a parent class

• implements "is-a" relationships


Interface• a collection of operations that specify a service of a

class

• Describes the externally visible behavior of that element

• Defines a set of operation specifications but never a set p pof operation implementation


Relationship• General terms covering the specific types of logical

connections within classes or objects• Different Types of Relationships Link Association Aggregation

C iti Composition Generalization Realization Realization Dependency


Association


OBJECT-ORIENTED ANALYSIS & DESIGN

UNIT I


Learning Objectives

• Object Oriented Paradigm• Review of Object Oriented Conceptsj p• Class Modelling Objects and Classesj Links and association Generalization and specialization Inheritance Grouping concepts

A ti Aggregation Composition abstracts classes


abstracts classes

Learning Objectives

Polymorphism Metadata Constraints

• Reuse• Object Oriented Lifecycle Model• Introduction to Object Oriented Methodology


Learning Objectives

• Overview of various object oriented methodologies• OOD• HOOD• OMT• CRC• OOA• OOSA• OOSA• OOSE• OOSDOOSD• OORASS


What is Object OrientationOO is an “approach” to software development which

includes : Requirements Design Programming Testing Metrics Metrics


Object Oriented System

• make use of abstraction in order to help make software

l lless complex

• Combine procedural abstraction with data abstractionp

• Procedural Abstraction

• Functions & Routines

• Data Abstraction• Data Abstraction

• Records & Structure


The Procedural Paradigm• The traditional paradigm had great successes initially

It started to fail with larger products (> 50 000 LOC) It started to fail with larger products (> 50,000 LOC)

• Maintenance problems (today, up to 80% of effort)

• Reason: structured methods are

Action oriented (data flow diagrams/Procedural abstraction); orAction oriented (data flow diagrams/Procedural abstraction); or

Data oriented (entity-relationship diagrams/data abstraction);

But not both


The Object-Oriented Paradigm

• Both data and actions are of equal importance

• Reduce semantics gap between system and reality

• Maintainable testable reusable and able to cope withMaintainable, testable, reusable and able to cope with

large complex systems.


The Object-Oriented Paradigm Cont..

• Heart of OO is representing both problems and

l ti i f i l i t t i “Obj t ”solutions in a fairly consistent way via “Objects”

data which characterize the object

methods which characterize the behavior or functions of the

objectobject

• Organizing procedural abstraction in the context of data

abstraction


The Object-Oriented Paradigm definition

An approach to the solution of problem in which all

t ti f d i th t t f bj tcomputations are performed in the context of objects.

The objects are instances of programming constructs,

normally called classes, which are data abstractions

with procedural abstractions that operate on the objectswith procedural abstractions that operate on the objects.


Traditional vs Modern Object-Oriented Paradigm

• Information hidingInformation hiding • Responsibility-driven design• Impact on maintenance, development


A View of the Two paradigms

mainmain

perform transaction

Accountcreditdebit

compute feesif checking then xxx

compute interestif checking

then xxx

debit

credit SavingsAccountCheckingAccountif savings then xxx

etc.

if savings then xxx

etc.

g

compute interestcompute fees

g

compute interestcompute fees


Object & ClassObject:• A chunk of structured data in a running software system

C t thi ith hi h i t ti• Can represent anything with which you can associate propertiesand behavior

• Any concrete (Customer) or conceptual (Sales Transactiony ( ) p () thing

Class• Units of data abstraction in an object oriented programExample:

B k t Bank accountData: account balanceActions: deposit withdraw determine balance


Actions: deposit, withdraw, determine balance

“Employee” Class

How would you describe an employee ?

Values it may take on: just as “integer” can be any negativeValues it may take on: just as integer can be any negative,

zero, or positive integer whose size is limited by the hardware

d ti t “E l ” tt ib t i l dand operating system. “Employee” attributes may include:

age represented by integer

sex represented by character

name represented by a string (or array of characters)name represented by a string (or array of characters)

address represented by string (or array of characters)


etc.

“Employee” Class..

What behavior or functions can an employee perform ? :

just as “integer” can it be operated on with arithmeticjust as integer , can it be operated on with arithmetic

operations of add, subtract, etc. ? Or rather - - -

thi l ?something else?

“respond to” employee age or address request

“respond to” number of years to eligible retirementetc.


“Employee” Object

• But there is an “individual” employee:

John Thompson

Susan Tang Susan Tang

etc.

• Each of these individual employee (emp_1) is an Object just as

integer variables x, y, or z which are declared as an integer type.


Object

• the basic run time entities in an object oriented system.

• match closely with real time objects.y j

• take up space in memory and have an associated address like a

R d i P l d St t i CRecord in Pascal and a Structure in C.

• Objects interact by sending Message to one other.

• E.g. If “Customer” and “Account” are two objects in a program

then the customer object may send a message to the accountthen the customer object may send a message to the account

object requesting for bank balance without divulging the details

of each other’s data or code


of each other s data or code.

Class• a group of objects that share common properties & behavior/

relationships.

• In fact, objects are the variables of the type class.

Cl d fi d d t t d b h lik th• Classes are user defined data types and behaves like the

built-in types of a programming language.


Some OO Characteristics

Identity : information is organized into “unique” entities called, objects.

Ab t ti ( d d f ll t f d i th d l )Abstraction: (needed for all types of design methodology) a method where only the “essentials” are described.

** Classification:Classification: grouping of “common” attributes and behaviors into an entity called,

classclass.**Encapsulation: Wrapping data & procedural abstractionpp g p

• Information Hiding hiding of implementation “details” and showing only the necessary


interfaces

Some OO Characteristics..

** Inheritance:

providing a structure and mechanism to “share” attributes andp g

functions.

** Polymorphism:** Polymorphism:

capability of providing a different behavior of a function with

same name based on different classes and/or parameters

passed to the function.

Persistence:

bilit f i th bj t’ t t d f ti


capability of a saving the object’s name, state, and functions.

OO Concepts (cont.)Thi ki f bl d l ti i t f “ l ” d “ bj t ”Thinking of problems and solutions in terms of “classes” and “objects”

may not be natural for some people and very natural for other.

Abstraction is an important methodology that plays a key role

here.

In a library system, what may be some classes?

Inheritance is a capability that allows us to think in terms of a “family” ofp y y

classes and perhaps how to “reuse” the higher level classes by the

lower level classeslower level classes

In a library system, what may be a “family” of classes ?

i t ll t l ti di t di k tt t di k


intellectual properties - audio - tapes , diskettes, compact disks

OO Concepts (cont.)Encapsulation is wrapping up of data & functions into a single unit

the notion of “hiding.” What we are hiding is the implementation details.g g p

Why?

t i i i li to minimize coupling

Clear interfaces should be explicitly designed and maintained.

OO has specific facilities that allow us to differentiate the items we

want to hide and those we want to consider as interfaceswant to hide and those we want to consider as interfaces

private


public

OO Concept (cont.)Polymorphism is the ability to respond to similar requests that are askedPolymorphism is the ability to respond to similar requests that are asked

of different objects. Allows the “reuse” of the correct member function or method

based on late binding. Consider the situation where two classes have a similar function.

Depending on hich class the specific object belongs to theDepending on which class the specific object belongs to, theappropriate method is invoked.

Feed ( ) function for Bird class

If animalreferred toBird class

animal . feed( );

Fee ( ) function forIf animalreferred to


Reptiles classreferred toReptiles class

OOAD

• OOADeciding which objects will be important to the users and• Deciding which objects will be important to the users, and

working out the structure, relationship and and behavior of

these objects , is a process of ob ject oriented analysis

• OOD• Consider the implementation issue


Transition From Analysis to Design

Traditional paradigm:Traditional paradigm: Jolt between analysis (what) and design (how)

Object-oriented paradigm:


Objects enter from very beginning

Analysis/Design “Hump”Systems analysis Determine what has to be done

Design Determine how to do it Architectural design—determine modules Detailed design—design each module


Removing the “Hump”

Object-oriented analysis Determine what has to be done Determine the objects

Object-oriented design Determine how to do it Design the objects


In More Detail

Objects enter here


Key Aspects of Object-Oriented Solution

Conceptual independence

EncapsulationEncapsulation

Physical independence

I f ti hidi Information hiding

Impact on development

Physical counterpart

Impact on maintenance

Independence effects


Benefits of OO Approach• To develop complex systems

• Systems that are prone to changeSystems that are prone to change

• System with user interfaces

S t th t b d li t/ d l• Systems that are based on client/server model

• To build E-commerce/web based applications

• For Enterprise Application Integration

• Improved quality, Reusability, Extensibility

• Reduce maintenance burden

• Financial benefits


Drawbacks of OO

• Need to change mindset

• Investment in training and toolsInvestment in training and tools

• Insist on testing

M ti d t t l i d d i• More time and cost to analysis and design

• User involvement

• Provides only long term benefits

• Still the success is greatly depends on people involved


Object Based ProblemP1. For each of the following collections of objects,

describe how they could be distinguished1. All telephones in the world for making telephone call2. All persons in the world for the purpose of criminal

investigation3. All persons in the world for the purpose of sending mail4. All customers with safe deposit boxes in a given bank5. All electronic mail addresses throughout the world6. All employees of a company to restrict access for

security reasons


Object Based Problem..P2. Discuss what the objects in each of the following list

have in common.1. Scanning electron microscope, eyeglasses, telescope,

bomb sight, binoculars2. Bicycle, sailboat, car, truck, airplane, glider,

motorcycle, horse3. Square root, exponential, sine, cosine


Object Based Problem..P3. Suppose your bathroom sink is clogged and you have decided to try to unclog

it by pushing a wire into the drain. You have several types of wire availablearound the house, some insulated and some not. Which of the following wirecharacteristics would you need to consider in selecting a wire for the job?characteristics would you need to consider in selecting a wire for the job?Explain your answers.

1. Immunity to electrical noise2 Color of insulation •To create colorful artwork2. Color of insulation.3. Resistance of the insulation to saltwater4. Resistance of the insulation to fire5 Cost

•To create colorful artwork•Designing a piano•Designing a filament for ali ht b lb5. Cost

6. Stiffness7. Ease of stripping the insulation8 Weight

light bulb

8. Weight9. Availability10. Strength11 Resistance to high temperatures


11. Resistance to high temperatures12. Resistance to stretching

Object Oriented Thinking RethinkingA Case Study

• Every night, Fido barks and barks at the stupid door

til l t hi t id I h t tti t f b d Cuntil we let him go outside. I hate getting out of bed, Can

you help us out?


Object Based Problem..P4 Derive the fundamental Object oriented concept for

Excel application. Identify: Object Class Attributes Methods Static and dynamic attributes Static and dynamic attributes Inheritance


Case Study

• Consider a payroll program that processes employee

records at a small manufacturing firm The company hasrecords at a small manufacturing firm. The company has

several classes of employees with particular payroll

i t d l f i h Thirequirements and rules for processing each. This company

has three types of employees:

Managers receive a regular salary

Office workers receive an hourly wage and are eligible forOffice workers receive an hourly wage and are eligible for

overtime after 40 hrs


Production workers are paid according to a piece rate

Case Study

Update the application for

Temporary office workers ineligible for overtime

Junior production workers who receive an hourly wage plus alower piece rate


OO Concepts

• Object• Class

• Data Abstraction

• Overriding• Object

• Attribute• Method

• Data Hiding• Inheritance

jpersistence

• ContainershipMethod• Message• State

• Polymorphismp

• GeneracityState

• EncapsulationD fi th tDefine the terms


Modelling with Classes

• A model is an abstraction for the purpose understanding it before building.

• Advantage Testing a physical entity before building it

Communication with customer

Vi li ti Visualization

Reduction of complexity


Reduction of complexity

Modelling with Classes..

• Class model describe the structure of objects in a

tsystem

Identity

Relationship with other objects

Attributes Attributes

operation

• Class diagram express the class model


Essentials of UML Class Diagrams

The main symbols shown on class diagrams are: Classes

represent the types of data themselves Associations

represent linkages between instances of classesrepresent linkages between instances of classes Attributes

are simple data found in classes and their instancesp Operations

represent the functions performed by the classes and their i tinstances

Generalizationsgroup classes into inheritance hierarchies


g p

ClassesA l i i l t d b ith th f th l i idA class is simply represented as a box with the name of the class inside The diagram may also show the attributes and operations The complete signature of an operation is: The complete signature of an operation is:

operationName(parameterName: parameterType …): returnType


Associations and Multiplicity

An association is used to show how two classes are related to each other Symbols indicating multiplicity are shown at each end of the

association


Labelling Associations

Each association can be labelled, to make explicit thenature of the association


Analyzing And Validating Associations

Many-to-oneA company has many employees,An employee can only work for one companyAn employee can only work for one company.

This company will not store data about the moonlightingactivities of employees!

A company can have zero employeesE.g. a ‘shell’ company

It is not possible to be an employee unless you work for aIt is not possible to be an employee unless you work for acompany

* worksForEmployee Company1



Many-to-manyAn assistant can work for many managersA manager can have many assistantsAssistants can work in poolsManagers can have a group of assistantsManagers can have a group of assistantsSome managers might have zero assistants. Is it possible for an assistant to have, perhaps temporarily, zero

?managers?

*supervisor

*****1..*Assistant Manager



One-to-oneFor each company, there is exactly one board of directorsA board is the board of only one companyA company must always have a boardA board must always be of some companyA board must always be of some company

Company BoardOfDirectors11



Avoid unnecessary one-to-one associations

Avoid this do this


A More Complex Example A booking is always for exactly one passenger

no booking with zero passengers

a booking could never involve more than one passenger.

A Passenger can have any number of Bookings

a passenger could have no bookings at all

a passenger could have more than one booking


Association Classes Sometimes, an attribute that concerns two associated

classes cannot be placed in either of the classes

The following are equivalent


Reflexive Associations

It is possible for an association to connect a class to itself


Directionality In Associations• Associations are by default bi-directional

• It is possible to limit the direction of an association byadding an arrow at one end


GeneralizationSpecializing a superclass into two or more subclasses

A generalization set is a labeled group of generalizations

with a common superclass

The label (sometimes called the discriminator) describesThe label (sometimes called the discriminator) describes

the criteria used in the specialization


Avoiding Unnecessary Generalizations

Inappropriate hierarchy ofInappropriate hierarchy ofclasses, which should beinstances


Avoiding Unnecessary Generalizations

Improved class diagram, with its corresponding instance


diagram

Handling Multiple Discriminators

Creating higher-level generalization


Handling Multiple Discriminators

Using multiple inheritance


Avoiding Having Instances Change Class

An instance should never need to change class


Aggregation Aggregations are special associations that represent ‘part-

whole’ relationshipswhole relationships.

The ‘whole’ side is often called the assembly or the

aggregateaggregate

This symbol is a shorthand notation association named

isPartOf


When To Use An Aggregation

As a general rule, you can mark an association as an

f faggregation if the following are true: You can state that

the parts ‘are part of’ the aggregate

or the aggregate ‘is composed of’ the parts

When something owns or controls the aggregate, then

they also own or control the partsy p


Composition A composition is a strong kind of aggregation

if the aggregate is destroyed, then the parts aredestroyed as well


Aggregation Hierarchy


Propagation A mechanism where an operation in an aggregate is implemented

by having the aggregate perform that operation on its partsy g gg g p p p

At the same time, properties of the parts are often propagated

back to the aggregateback to the aggregate

Propagation is to aggregation as inheritance is to generalization.

Th j diff iThe major difference is:

inheritance is an implicit mechanism

propagation has to be programmed when required


InterfacesAn interface describes a portion of the visible behaviourof a set of objects. An interface is similar to a class, except it lacks

instance variables and implemented methods


Constraints• To restrict the ways in which a class can operate• OCL is a specification language designed to formally p g g g y

specify constraints in software modules• Three types of constraints• Invariant Must always be true Defined on class attributes

• Precondition Defined on a method Checked before method execution

F tl d t lid t i t t


Frequently used to validate input parameter

Constraints..• Postcondition Defined on a method

Checked after method execution

Frequently used to describe how values were changed by methodmethod


Constraints..Invariant


The Process of Developing Class Diagrams

You can create UML models at different stages and with

diff t d l l f d t ildifferent purposes and levels of details Exploratory domain model:Developed in domain analysis to learn about the domain

System domain model:Models aspects of the domain represented by the system

System model:yIncludes also classes used to build the user interface and system

architecture


a c ec u e

System Domain Model Vs System Model

The system domain model omits many classes that areneeded to build a complete systemCan contain less than half the classes of the system.Should be developed to be used independently of particular sets

ofofuser interface classes architectural classes

The complete system model includesThe system domain modelU i t f lUser interface classesArchitectural classesUtility classes


y

Suggested Sequence Of Activities Identify a first set of candidate classes Add associations and attributes Find generalizations Find generalizations List the main responsibilities of each class Decide on specific operationsDecide on specific operations Iterate over the entire process until the model is satisfactoryAdd or delete classes, associations, attributes,

generalizations, responsibilities or operationsIdentify interfaces

Don’t be too disorganized. Don’t be too rigid either.


Identifying Classes When developing a domain model you tend to discover

classesclasses

When you work on the user interface or the system

hit t t d t i t larchitecture, you tend to invent classes

Needed to solve a particular design problem

(Inventing may also occur when creating a domain model)

Reuse should always be a concern

Frameworks

System extensions


Similar systems

A Simple Technique For Discovering Domain Classes

Look at a source material such as a description of requirements

Extract the nouns and noun phrases

Eliminate nouns that:

are redundantare redundant

represent instances

are vague or highly generalare vague or highly general

not needed in the application

Pay attention to classes in a domain model that represent types Pay attention to classes in a domain model that represent types

of users or other actors


Identifying Associations And Attributes

Start with classes you think are most central and important

Decide on the clear and obvious data it must contain and its

relationships to other classesrelationships to other classes.

Work outwards towards the classes that are less important.

Avoid adding many associations and attributes to a class

A system is simpler if it manipulates less information


Tips About Identifying And Specifying Valid Associations

An association should exist if a classpossesses

t lcontrolsis connected tois related tois a part ofhas as partsis a member of oris a member of, orhas as members

some other class in your modely Specify the multiplicity at both ends Label it clearly.


Actions Versus Associations

A common mistake is to represent actions as if they wereassociationsassociations

Bad, due to the use of associations that are actions

Better: The borrow operation creates a Loan , and the return operation sets the returnedDateattributethat are actions attribute.


Identifying Attributes Look for information that must be maintained about each class

Several nouns rejected as classes, may now becomej y

attributes

An attribute should generally contain a simple valueAn attribute should generally contain a simple value

E.g. string, number


Tips About Identifying And Specifying Valid Attributes

It is not good to have many duplicate attributes

If a subset of a class’s attributes form a coherent group then If a subset of a class s attributes form a coherent group, thencreate a distinct class containing these attributes


Identifying Generalizations And Interfaces

There are two ways to identify generalizations:

bottom-upbottom up

Group together similar classes creating a new superclass

top-downtop down

Look for more general classes first, specialize them if needed

Create an interface instead of a superclass if Create an interface, instead of a superclass if

The classes are very dissimilar except for having a few

operations in commonoperations in common

One or more of the classes already have their own superclasses

Different implementations of the same class might be available


Different implementations of the same class might be available

Case Study 2• Airline Reservation SystemOotumlia Airlines runs sighseeing flights from Java Valley, the

capital of Ootumlia . The reservation system keeps track of

passengers who will be flying in specific seats on vrious

flights, as well as people who will form the crew. For the crew

, the system needs to track what everyone does, and who

supervises whom. Ootumlia Airlines runs several daily

numbered flights on a regular schedule. Ootumlia Airlines

expects to expand in the future so the system needs to be

flexible; in particular, it will be adding a frequent-flier plan.


; p , g q p

An Example (Attributes And Associations)


An Example (Generalization)


Allocating Responsibilities To ClassesA ibilit i thi th t th t i i d t dA responsibility is something that the system is required to do. Each functional requirement must be attributed to one of the classesAll the responsibilities of a given class should be clearly related.If a class has too many responsibilities, consider splitting it into

distinct classesIf a class has no responsibilities attached to it, then it is probablyp , p y

uselessWhen a responsibility cannot be attributed to any of the existing

classes, then a new class should be created,

To determine responsibilitiesPerform use case analysisPerform use case analysisLook for verbs and nouns describing actions in the system

description


Categories Of Responsibilities Setting and getting the values of attributes Creating and initializing new instances Loading to and saving from persistent storage Destroying instances

Addi d d l ti li k f i ti Adding and deleting links of associations Copying, converting, transforming, transmitting or outputting Computing numerical results Computing numerical results Navigating and searching Other specialized workp


An Example (Responsibilities)

• Creating a new regular flight• Searching for a flightSearching for a flight• Modifying attributes of a flight• Creating a specific flight

B ki• Booking a passenger• Canceling a booking


Prototyping A Class Diagram On Paper

As you identify classes, you write their names on small cards

As you identify attributes and responsibilities, you list them ony y p , y

the cards

If you cannot fit all the responsibilities on one card: If you cannot fit all the responsibilities on one card:

this suggests you should split the class into two related classes.

Move the cards around on a whiteboard to arrange them into a Move the cards around on a whiteboard to arrange them into a

class diagram.

D li th d t t i ti d Draw lines among the cards to represent associations and

generalizations.


Identifying OperationsOperations are needed to realize the responsibilities of

each classeach class There may be several operations per responsibility

The main operations that implement a responsibility are

normally declared public

Other methods that collaborate to perform the responsibility

must be as private as possible


An Example (Class Collaboration)


Difficulties And Risks When Creating Class Diagrams

Modeling is particularly difficult skill

Even excellent programmers have difficulty thinking at theEven excellent programmers have difficulty thinking at the

appropriate level of abstraction

Education traditionally focus more on design and programmingEducation traditionally focus more on design and programming

than modeling

Resolution: Resolution:

Ensure that team members have adequate training

H i d d ll t f th tHave experienced modeller as part of the team

Review all models thoroughly


System Development as an Industrial Process

Documented by Spector and Gifford(1986) via an interview with Gerald Fox (experienced bridge designer)


Learning Objectives• The constitute of a rational enterprise philosophy• The constituents of multiple activities of a rational enterprise

Software Industry Direct Analogies with Rational Enterprise• Software Industry Direct Analogies with Rational Enterprise• System development characteristics• Part of a Larger ActivityPart of a Larger Activity• System Development• Transition from Analysis to Constructiony• The System Life Cycle• System Development as a Process of Change


Learning Objectives Cont..

• System Development and Reuse

• Component

• System Development and Methodology

• Process Expresses more than Method

• Process Adaptation According to Organization Need

• Objectory


Constitute of a Rational Enterprise Philosophy

Support for architecture method or

Tools

Support for architecture, method orprocess

ProcessHow to apply the architecture concept(step by

How to scale up the method to industry activity

Architecture

MethodThe selected approach from a universe ofapproaches (Foundation of concepts and

How to apply the architecture concept(step bystep)

pp ( ptechnology)


Constituents of Multiple Activities of a Rational Enterprise

Tools Tools Tools

Method

Process

Method

Process

Method

Process

Architecture Architecture Architecture

iCreative Design Construction Long Term Support


Software Industry Direct Analogies with Rational Enterprise

• Process must yield a forseeable result, irrespective of which

individual performed the jobindividual performed the job

• Volume of output doesn’t effect the process

P ibilit t ll t t f th t l• Possibility to allocate parts of the process to several

manufacturers/subcontractors

• Possible to make use of predefined building blocks and

components

• Possible to plan and calculate the process with great precision.

• Each person trained for an operation must perform it in a similar


p p p

manner

System Development Characteristics

Part of a large activity

System Development

T iti f A l i t C t tiTransition from Analysis to Construction

Requirements are input to system developmentRequirements are input to system development

A system is output system developmenty p y p

Parties interested in system development are customer, comp.


dept., direct users, indirect users`

Part of a Larger Activity

O d Sales ProductionOrders and Requir

Deliverable Products

(Change)

System

ements requirements

yDevelopment


Part of a Larger Activity Cont..

Only person involved in production skilled in duplicating products, assembling and configuring

t d t tisystem and testing To Minimize the development department with customer

contacts.contacts.

Product is described as sets of packages of functionality servicestermed as service packages

S i P k t l t d i t b ildi bl kService Packages are translated into building blocks


System DevelopmentGradual transformation of a sequence of models

Can be viewed as a process of producing model description

C i t f th di ti t h th t f ll h th l lConsist of three distinct phases that follow each other seamlessly-analysis, construction and testing


System Development Cont..

New & System DevelopmentChanged

RequirementsChanged System

C t tiRequir

t SysAnalysis

ConstructionDesign Imple

mentationTesting

ements System


Transition from Analysis to Construction

Guidelines for analysis Analysis must be independent of implementation

Analysis must be application oriented

Described in terms of service packages

Should not be too elaborated


Requirements are Input to System Development

Technical applications Tactical command & control system; process control system;

t l i ti ttelecommunication system The role of system in its environment identified &

requirements formulated in terms of behavior of sensors andrequirements formulated in terms of behavior of sensors andactuators (interfaces to the environment)

Administrative systems Requirements based on a dialogue between customer and

producerproducer


A System is Output System Development

Set of descriptions

Basis for production in production department and forproduct description in sales department


The System Life CycleSystem Development as a process of change

System development and Reuse

S t D l t d th d lSystem Development and methodology

ObjectoryObjectory


System Development as a Process of Change

Delta requirement specification Specifications for desired changes to an earlier version

Each new version is a delta version

Process of progressive changeDelta

Analysis Construction TestingRequirements Delta

System


System Development and Reuse

Not a central issue in other branches as so obvious andpracticed widely

System is a set of application module

A module composed of other modules or componentA module composed of other modules or component

Finest level of granularity of reuse is component

Decrease the product’s life-cycle model

Other descriptions can be reused such as handbooks andeducational material


ComponentAlready implemented unit

Not quantity but quality determines the success of reuse

Li t d i t lListed in catalogue

Browser to access catalogueBrowser to access catalogue Each iteration as a change to an existing system

Currently support for data structures and windows managementsystems in form of macro libraries, subroutine libraries, procedurelib i d


libraries and so on

Changeable ApplicationsMust be designed to permit frequent alteration

Modules must be framed to handle change in requirement in allprobability in few modules


System Development and Methodology

Important to know how the different steps of the method interact andhow they fit into the development process as a whole

Architecture Internal structure key property of a system makes it easy to

understand, change, test and maintain

Analysis model design model and implementation model may Analysis model, design model and implementation model mayform an architecture


System Development and Methodology contd..

Method A planned procedure to approach a specified goal step by step Simplifies the development of system of a particular

architecture

Process Natural scaling up of a methodatu a sca g up o a et od


System Development and Methodology Cont..

Method description and process description

Method presented as starting from nothing and resulting in a firstMethod presented as starting from nothing and resulting in a firstsystem version

Project includes changing an existing system tendering projectProject includes changing an existing system, tendering project,error handling project and others

Process offers to more than one projectProcess offers to more than one project

Activity description should be reusable in different types of systems


System Development and Methodology cont..

Process will continue to exists so long as the developed system is inoperation

A set of interacting sub process

Software factory describe the division of processes and subprocesses

A process presuppose a method which, in turn presuppose anhit tarchitecture


Process Expresses More Than Method

Transition from principles to practice

Describe how different subprocesses should cooperate and to whatextent they should be carried out in parallel

Activity becomes less dependent on individual

System development as process of change


CASE

Support the process it is based on

Part of a greater whole


Process Adaptation According to Organization Need

Heterogeneous projects

Development case description about pros and cons ofdeselecting of subprocess

Process adaptor must have access of development casep pdescription


ObjectoryModern Development Technique Support of iterative development Support the entire chain from changed requirement to the

functioning system

Object Factory for Software Development a development technique

Framework: Design with building blocks


Objectory Cont..

• Essential idea behind the CCIT(Commite Consultatif

I t ti l T l hi t T l h iInternational Telegraphique et Telephonique

• Used in various systems information system, , real time

system, process control system, CASE tools and

graphic presentation systems. Adapted to differentgraphic presentation systems. Adapted to different

programming languages


Objectory Cont..

• and scaled down to small scale projects with Simplified

l j tlarge projects

• Three design techniques: building blocks, conceptualg q g , p

modeling and object oriented programming

• Conceptual modeling extended with OO concepts and

ability to describe dynamic behaviorability to describe dynamic behavior


S ft Lif C l M d lSoftware Life Cycle Model


Summary of Development Process

System ConceptionUsersDevelopersManagers

Generate RequestSystem Conception

Analysis:

ManagersBusiness Experts

User Interviews

Request

Build

Problem Statement

•Domain Analysis•Application Analysis

User InterviewsExperienceRelated Systems

Build Models

Class Model

Design:•System DesignCl D i

ArchitectureUse CasesAlgorithms Elaborate

Class ModelState Model

Interaction Model

•Class Design AlgorithmsOptimization

Elaborate Models


Software Development : A Use Case Model

<<include>><<include>>

<<include>>Software development

System developmentProblem definition System operation

Client End userDeveloperProject manager Administrator


Software Development : Simple Object Model

Software Development

Object DesignDocument

Requirements Analysis Executable system

Problem Statement

DocumentExecutable system

System DesignDocument

Test Manual


Software life cycle

* Object Model of the Process group

Process*

Software Life Cycle

Work Product

Process

Phase**

Activity Task

producesconsumes

*

*

Resource

*

Time

Participant


Money

D i

Life Cycle Model of OOSAD

O

DomainApplication Scenario

OA

Identify Actors

Identify Use cases

Build UseCase Model

i

Test

Do Object Analysis

OOD

Identify Classes

Identify Objects

ExamineReusableObjects

BuildPrototype

Build OOSystem DesignD g

BuildInterfaceObjects

BuildDynamic

Model

Test UsageScenario

(Use Case)

OO

( )

BuildDetail

Use Tools &Program for

Test for QAAcceptance


OI

DetailDesign

Program forImplementation

Acceptance

Post Implementation Hand Over

UNIFIED APPROACHUNIFIED APPROACH


Objectives• The Unified Approach• Best Practices• Object Oriented Analysis• Object Oriented DesignObject Oriented Design• Four phases of UA• UA DisciplinesUA Disciplines


Unified Approachtime

In an iteration,

content

,you walk through all disciplinesdisciplines.

Disciplines group


p g prelated activities.

The Unified Approach

• Based on the best practices• Unify the modeling efforts of Booch, Rumbaugh andy g , g

Jacobson• Revolves around the processes and concepts Use-case driven development Object Oriented Analysis Object oriented Design Incremental development and prototyping

C ti T ti Continuous Testing


RUP Implements Best Practices

Best PracticesProcess Made Practical


D l It ti lD l It ti lDevelop IterativelyManage Requirements

Use Component Architectures

Develop IterativelyManage Requirements

Use Component ArchitecturesUse Component ArchitecturesModel Visually (UML)

Continuously Verify Quality

Use Component ArchitecturesModel Visually (UML)

Continuously Verify QualityCo t uous y e y Qua tyManage Change

Co t uous y e y Qua tyManage Change


Practice 1: Develop Iteratively


Best PracticesProcess Made PracticalProcess Made PracticalProcess Made Practical

Develop IterativelyDevelop IterativelyDevelop IterativelyManage Requirements



Use Component ArchitecturesUse Co po e t c tectu esModel Visually (UML)


Use Co po e t c tectu esModel Visually (UML)

Continuously Verify Qualityy y yManage Change

y y yManage Change


Develop Iteratively

IterationIteration isis thethe repetitionrepetition ofof steps,steps, eacheach timetime improvingimprovingthethe accuracyaccuracy ofof thethe resultresult..

BenefitsBenefitsBenefitsBenefits•• RiskRisk estimationsestimations areare earlierearlier..•• ChangeChange isis moremore manageablemanageable..ChangeChange isis moremore manageablemanageable..•• LearningLearning andand ImprovingImproving..•• BetterBetter overalloverall qualityquality..


Contd. . .

Iterations Mitigate Risks

Waterfall Model

Risk

R i tAnalysis& Design

Requirements

gImplementation

TestThe Project Test

Deployment

j


Time

Iterations Mitigate Risks

Iterative Software Delivery Process

Requirements Requirements Requirements

Risk

Analysis& Design

Requirements

Analysis& Design

Requirements

Analysis& Design

Requirements

Implementation

Test

Implementation

Test

Implementation

Test

Deployment Deployment Deployment


Time

Practice 2: Manage Requirements

Best PracticesP M d P ti l

Best PracticesP M d P ti lProcess Made PracticalProcess Made Practical




Use Component ArchitecturespModel Visually (UML)


pModel Visually (UML)


y y yManage Change


Requirements Management Means…

Making sure you solve the right problem build the right system build the right system

by taking a systematic approach to eliciting

i i organizing documenting managing

the changing requirements of a software application.


Map of the Territory

Problem Problem Space

Solution Space

Needs

Features SpaceFeatures

SoftwareThe

Product So t a eRequirements to Be

Built

Test ScriptsDesign User

Docs


Use Cases as a Basis for Iteration PlanningUse Cases as a Basis for Iteration Planning

Constraints

Project Use-Case Model

Iteration PlanFi i d l f

Project Management

Supplementary

Fine-grained plan for a single iteration

SupplementarySpecifications

During Elaboration, use cases are implemented to validate the

hit t


architecture.

Use Cases as a Basis for System Modeling

Use-Case Model(requirements)

li tiverification

realization influence

Implementation Model(source code)

Test ScriptsDesign Model(classes and objects)


Use Cases as a Basis for Test Planning

The complete behavior of a use case is tested using Test Scripts and Test Suites.

Test Script

Test Suite

T t S it

Test Script


Test Suite

Practice 3: Use Component Architectures


Best PracticesP M d P ti lProcess Made Practical Process Made Practical

Develop IterativelyDevelop IterativelyManage Requirements

Use ComponentArchitectures

Manage RequirementsUse ComponentArchitecturesArchitectures

Model Visually (UML)Continuously Verify Quality

ArchitecturesModel Visually (UML)

Continuously Verify QualityContinuously Verify QualityManage Change

Continuously Verify QualityManage Change


Purpose of a Component-Based Architecture

Basis for reuse Component reuse Architecture reuse Component-basedArchitecture reuse

Basis for project management Planning

Staffing

Component based architecture with layers

Staffing Delivery

Intellectual controlApplicationApplication--specificspecific

Manage complexity Maintain integrity

MiddlewareMiddleware

BusinessBusiness--specificspecific

SystemSystem--softwaresoftware

MiddlewareMiddleware


Practice 4: Model Visually (UML)










y y yManage Change


One Language for All Practitioners

Tecnology M d li

Application ModelingRequirements

M d li

Data Modeling

Modeling

Business Modeling

Modeling

One language – One tool – One team


One language – One tool – One team

Role of UML in RUP• Rational Unified Process was developed hand-in-hand

with the UML.

• Many artifacts in Rational Unified Process have a UML representationrepresentation.

• Rational Unified Process also includes guidelines for• Rational Unified Process also includes guidelines for UML concepts.


Practice 5: Continuously Verify Quality






Use Component ArchitecturesUse Component ArchitecturesModel Visually (UML)

Continuously

Use Component ArchitecturesModel Visually (UML)

ContinuouslyyVerify QualityManage Change

yVerify QualityManage Change


Continuously Verify Your Software’s Quality

Software problems are100 to 1000 times more costly

to find and repair after deployment

Software problems are100 to 1000 times more costly

to find and repair after deployment p p yp p y

Cost to Repair Software Cost to Repair Software

CostCost

p

Cost of Lost Opportunities

Cost of Lost Customers

p

Cost of Lost Opportunities

Cost of Lost CustomersCostCost Cost of Lost Customers Cost of Lost Customers


Development Phases

Testing Dimensions of Quality

UsabilityUsability Test application from the

ti f Test application from the

ti f

ReliabilitReliabilit

FunctionalityFunctionality Test the accurate

workings of each Test the accurate

workings of each

perspective of convenience to end-user.perspective of convenience to end-user.

ReliabilityReliability Test that the application

behaves consistently and predictably

Test that the application behaves consistently and predictably

workings of each usage scenarioworkings of each usage scenario

predictably.predictably.

P fP f

SupportabilitySupportability Test the ability to maintain

and support application Test the ability to maintain

and support application PerformancePerformance Test online response

under average and peak loading

Test online response under average and peak loading

pp ppunder production use

pp ppunder production use


loadingloading

Test Each Iteration

UML Model

Iteration 1Iteration 1 Iteration 2Iteration 2 Iteration 4Iteration 4Iteration 3Iteration 3

UML Model and

Implementation

T t S it 1T t S it 1 T t S it 2T t S it 2 Test Suite 4Test Suite 4T t S it 3T t S it 3

Tests

Test Suite 1Test Suite 1 Test Suite 2Test Suite 2 Test Suite 4Test Suite 4Test Suite 3Test Suite 3

Tests


Need for automated testing increases

Practice 6: Manage Change


Best PracticesP M d P ti lProcess Made PracticalProcess Made Practical








y y yManage Change


Change Request ManagementChange requests come from many sources throughout each iteration of the product lifecycle

Customer and

Req

Customer andUser inputs

MarketingNew Feature

Single Channel

Design

Marketing

NewRequirementApproved

D i i

Single Channel for Approval

Test

CodeBug

DecisionProcess

Coders inputsTesters inputs

Maint

Test Help DeskUser inputs

ChangeRequest (CR)


Unified Change Management


Best Practices Reinforce Each Other: An Example

Best PracticesBest PracticesDevelop IterativelyDevelop Iteratively

Ensures users involved i t l

Develop Iteratively

Manage Requirements

Develop Iteratively

Manage Requirements

Validates architectural decisions early on

as requirements evolveg q


g q

Use Component Architecturesdecisions early on

Addresses complexity of design/implementation incrementallyModel Visually (UML)Model Visually (UML)

Measures quality early and oftenContinuously Verify QualityContinuously Verify Quality


Evolves baselines incrementallyManage Change Manage Change

Object-Oriented Analysis

• Identify the Actors• Develop a simple business process model using UMLp p p g

Activity diagram• Develop the use case• Develop interaction diagrams• Identify classesy


Object-Oriented Design• Designing classes, their attributes, methods,

associations, structures and protocols, apply designaxioms.

• Design the Access layer

• Design and prototype User interface

• Iterate and refine the data


The Unified Approach PhasesHas four phases Inception Understand problem

ElaborationU d t d S l tiUnderstand Solution

ConstructionHave a SolutionHave a Solution

TransitionUse solution efficientlyy


Main Disciplines of R.U.P.

1. Business Modeling

2. Requirements

3. Analysis and Design3. Analysis and Design

4. Implementation

5. Test

6. Deploymentp y


Supportive Discipline of R.U.P.

1. Configuration and Change Management

2. Project Management

3 Environment3. Environment


Business Modeling

To understand current problems in the target organization andidentify improvement potentials.

To assess the impact of organizational change.

To ensure that customers end users developers and otherTo ensure that customers, end users, developers, and otherparties have a common understanding of the organization.

To derive the software system requirements needed to supportthe target organization.

To understand how a to-be-deployed software system fits intothe organization.

© Bharati Vidyapeeth’s Institute of Computer Applications and Management, New Delhi-63, by Anukiran Jain U1. ‹#›Contd. . .

RequirementsT t bli h d i t i t ith th t d•To establish and maintain agreement with the customers and

other stakeholders on what the system should do.

• To provide system developers with a better understanding of thesystem requirements.

• To define the boundaries of the system.•To provide a basis for planning the technical contents of iterations.

•To provide a basis for estimating cost and time to develop thesystem.y

•To define a user-interface for the system, focusing on the needsand goals of the users


and goals of the users.

Contd. . .

Analysis & Design

• To transform the requirements into a design of thesystem-to-be.y

• To evolve a robust architecture for the system.

• To adapt the design to match the implementationenvironmentenvironment.


Implementation

• Defines the organization of the code.

• To test the developed components as units.

• To integrate the results produced by teams into an executablesystem.

• Verify the integration and interaction between objects.

T id if d d f dd d i h• To identify and ensure defects are addressed prior to the deployment.


Deployment•Successfully produce product releases.

D li th ft t it d• Deliver the software to its end users.

• Cover a wide range of activities-Cover a wide range of activities Release of software. Packaging.g g Distributing. Installing.


Configuration & Change Management

•Identifying configuration items.

• Restricting changes to those items.

• Auditing changes made to those items• Auditing changes made to those items.

• Defining and Managing configuration of those items.Defining and Managing configuration of those items.


Project Management

• To provide a framework for managing softwareprojects.p j

• To provide practical guidelines for planning, staffing,executing and monitoring projects.

• To provide a framework for managing risk• To provide a framework for managing risk.


Environment

P id th ft d l t i tiProvide the software development organization

with the software development environment –with the software development environment

both processes and tools that are needed to

support the development team.


Bringing It All Together: The Iterative Approachtime

In an iteration,

content

,you walk through all disciplinesdisciplines.

Disciplines group


p g prelated activities.

Typical Effort and Time Percentages by Phase

People

ConstElab TransInc

Time

ConstElab TransInc

Inc Elab Const TransEffort 5% 20% 65% 10%


Time/Schedule 10% 30% 50% 10%

Conclusion

Combine the best practices, processes, methodologies

d id li ith UML t ti d di fand guidelines with UML notations and diagrams for

better understanding object-oriented concepts and

system development.


Object Oriented Methodologies


Learning Objectives• OO Methodology• Different Methodologiesg• Rumbaugh OMT• Booch OODBooch OOD• Jacobson OOSE


OO Methodology• Software developing methodology based on Object-

Oriented concepts

• World is a collection of collaborating objects

• Software has to be organized according to the structureof our worldof our world Increases understandability and evolve ability of software


Current Object-Oriented Methodologies

Berard [Berard 93] BOOM BON [Nerson 92] Booch [Booch 94] Booch [Booch 94] Coad/Yourdon [Coad 91] Colbert [Colbert 89] d Ch [d Ch 93] de Champeaux [de Champeaux 93] Embley [Embley 92] EVB [Jurik 92] FUSION [Coleman 94] HOOD [HOOD 89]


Current Object-Oriented Methodologies

IBM [IBM 90,91] Jacobson [Jacobson 92] Martin/Odell [Martin 92] Martin/Odell [Martin 92] Reenskaug (OOram, was OORASS) [Reenskaug 91] ROOM [Selic 94] R b h t l [R b h 91] Rumbaugh et al. [Rumbaugh 91] Shlaer and Mellor [Shlaer 88 and 92] Wasserman [Wasserman 90] Winter Partners (OSMOSYS) [Winter Partners] Wirfs-Brock et al. [Wirfs-Brock 90]


Rumbaugh OMTObject Modeling Technique presented by Jim RubaughConsist of four phases

A l i AnalysisObjects, dynamic and functional models

System Design System DesignStructure of basic architecture along with high-level

strategy decisionsstrategy decisionsIdentification of subsystemsChoice of data storage and access strategiesg g


Rumbaugh OMT Object designDetail object’s static, dynamic and functional models

ImplementationProduce reusable, extensible and robust code


Rumbaugh OMT ModelsStatic Object model with attributes, operations and relationships

(extension of E R model)(extension of E-R model)Dynamic State transition diagrams (network of states and events)State transition diagrams (network of states and events)

Functional Based on classical DFD


Booch OOD• Aimed on physical design and programming rather than

requirement and conceptual designD ib t l l f di• Describes two levels of diagram Design levelClass object state transition and interactionClass, object, state transition and interaction

diagrams Implementation levelpModule and process diagrams


Booch OODSuggest two development process

Micro Development ProcessRepresents the daily activities of the individual

developerdeveloper

Macro Development Processac o e e op e t ocessServes as the controlling framework for the micro

process


Booch OOD Micro Development Process

Identify the classesIdentify the classes

and objects

Identify the classes and objects Semantics

Specify class & Identify the classes and objects relationships

Specify class & Objects interface &

Implementation relationships


Booch OOD Macro Development Process

Establishment of Core Requirements

Conceptualization

Developing a model of the desired behavior

AnalysisConceptualization Analysis

Creation of A hit t D i

Evolving the i l t ti Architecture Designimplementation

Evolution

Managing post delivery evolution Maintenance


Jacobson OOSE

• Originated from Objectory (Object Factory for software

development)development)

• Aim to fit the development of large real-time system

• Covers entire life cycle

• Stress traceability among the different phases (Backward &y g p (

forward)

Usecase concept is core• Usecase concept is core


Objectory

• Discipline process for the industrialized development of software,

based on a usecase driven designbased on a usecase driven design

• Built around several different models

U d l Usecase model

Domain object model

Analysis object model

Implementation model

Test model


Usecase Approach

Use Case ModelExpress in

Domain Object M d l Test Model

Express in

Realized byTested in

Model Design Model

Implementation

Test Model

Structure by Implemented by

Analysis ModelImplementation

model


Object Oriented Business Engineering

• Object modeling at the enterprise level

U t l hi l f d li• Use case central vehicle for modeling

• Marjory three phases Analysis

Design and implementationDesign and implementation

Testing


OO Concepts

• Object• Class

• Data Abstraction

• Overriding• Object

• Attribute• Method

• Data Hiding• Inheritance

jpersistence

• ContainershipMethod• Message• State

• Polymorphismp

• GeneracityState

• Encapsulation


Object Based ProblemP1. For each of the following collections of objects,

describe how they could be distinguished1. All telephones in the world for making telephone call2. All persons in the world for the purpose of criminal

investigation3. All persons in the world for the purpose of sending mail4. All customers with safe deposit boxes in a given bank5. All electronic mail addresses throughout the world6. All employees of a company to restrict access for

security reasons


Object Based Problem..P2. There are two lists below. The first is a list of classes that describe

implementation objects. The second is a list of operations. For each class,select the operations that make sense for objects in that class. Discuss thebehavior of each operation listed for each class.behavior of each operation listed for each class.

Classes:Variable length array --- ordered collection of objects, indexed by an integer,

whose size can vary at run time.Symbol table --- a table that maps text key words into descriptorsSet --- unordered collection of objects with no duplicatesOperations:

Append Append Copy Count Delete Delete Index Intersect Insert


Insert Update

Object Based Problem..P3. Discuss what the objects in each of the following list

have in common. You may add more classes1. Scanning electron microscope, eyeglasses, telescope,

bomb sight, binoculars2. Bicycle, sailboat, car, truck, airplane, glider,

motorcycle, horse3. Square root, exponential, sine, cosine


Object Based Problem..P4. Suppose your bathroom sink is clogged and you have decided to try to unclog

it by pushing a wire into the drain. You have several types of wire availablearound the house, some insulated and some not. Which of the following wireh t i ti ld d t id i l ti i f th j b?characteristics would you need to consider in selecting a wire for the job?

Explain your answers.1. Immunity to electrical noise2 Color of insulation2. Color of insulation.3. Resistance of the insulation to saltwater4. Resistance of the insulation to fire5 Cost5. Cost6. Stiffness7. Ease of stripping the insulation8 W i ht8. Weight9. Availability10. Strength


11. Resistance to high temperatures12. Resistance to stretching

Object Based Problem..P5 Derive the fundamental Object oriented concept for

Excel application. Identify: Object Class Attributes Methods Static and dynamic attributes Static and dynamic attributes Inheritance


Very Short QuestionsQ1.Define the following terms with example

Class, Object, Inheritance, Message, Polymorphism, Abstraction, j g y p

Encapsulation, Data Hiding,

Q2. How Class is different from Object?j

Q3. What are the participating parties in system development?

Q4. Define the following terms with exampleQ4. Define the following terms with example

Realization, Delta Requirements, Block, Component, Association,

Aggregation, Composition, Interface, Abstract Class, Class Modeling,Aggregation, Composition, Interface, Abstract Class, Class Modeling,

Service Package

Q5. How Interface is different from Abstract Class


Q5. How Interface is different from Abstract Class

Very Short QuestionsQ6.How Association is different from Dependency?

Q7. How Aggregation is different from Composition?gg g p

Q8. How Process is different from Method

Q9. Can we develop a system using only method (no Process)? Why?Q9. Can we develop a system using only method (no Process)? Why?

Q10. What do you mean by Invariable Constraint? Give Example.

Q11 Differentiate Pre vs Post Constraint with example?Q11.Differentiate Pre vs. Post Constraint with example?

Q12. We can use more than one architecture for a product. Justify


Short QuestionsQ1. Discuss the different types of relationships in class Modelling

Q2. Discuss Objectoryj y

Q3. System Development is a part of Large Activity,

Q4. System Development is the conversion of one Model to next modelQ4. System Development is the conversion of one Model to next model

Q5. Discuss Reusablity.

Q6 What do you mean by Constraint? What are the different types of ConstraintsQ6. What do you mean by Constraint? What are the different types of Constraints.

Q7. Discuss at least three


Long QuestionsQ1. Discuss the different types of relationships in class Modelling

Q2. Discuss the Characteristics of System Development.y p

Q3. What are the participating parties in system development?

Q4. Define the following terms with exampleQ4. Define the following terms with example

Realization, Delta Requirements, Block, Component, Association,

Aggregation, Composition, Interface, Abstract Class, Class Modeling,Aggregation, Composition, Interface, Abstract Class, Class Modeling,

Service Package

Q5. How Interface is different from Abstract ClassQ5. How Interface is different from Abstract Class


Documents

OBJECT-ORIENTED ANALYSIS & DESIGNbvicam.in/sites/default/files/subject/LearningMannuals... · · 2017-11-06Abstraction (from the Latin abs, ... Association Aggregation CitiComposition