Overview of Object Oriented Concepts Bridge between users’ requirements and new

system’s programming

Object-oriented design is process by which detailed object-oriented models are built.

Programmers use design to write code and test new system

Overview of Object Oriented… User interface, network, controls, security, and

database require design tasks and models

Set of objects that cooperate to accomplish result

Object contains program logic and necessary attributes in a single unit

Objects send each other messages and collaborate to support functions of main program

Overview of Object Oriented… OO systems designer provides detail for programmers

A system is viewed as a collection of entities that interact with each other.

Key Concepts:

Abstraction: selective examination of certain aspects of the problem while ignoring the remaining aspects of the problem.

Encapsulation: the property of an object by which it interface with the outside world only through messages.

Overview of Object Oriented… Key Concepts…

Polymorphism: capability to

Genericity: Generic classes and function.

Basic Mechanism:

Objects: represents a tangible real world entity.

Class: collection of similar objects

Methods and messages: operations supported by an object are called methods. The methods of an objects are invoked by sending message to it.

Overview of Object Oriented… Inheritance: this feature allows us to define a new class

by extending or modifying the existing classes.

Advantages of OOD:

Code and design reuse.

Increased productivity.

Ease of testing and maintenance.

Better code and design understandability.

Steps in OOD Review of objects identified in the analysis phase.

Refine the objects in terms of their attributes.

Specification of class dependency.

Analysis of relationship among the classes. Major relationships are:

Inheritance relationship: is_a

Containment relationship: use of an object of a class as a member of another class. has_a

Steps in… Use relationship :

A reads a member of B.

A calls a member of C.

A creates B using new operator.

Organization of class hierarchies.

Create a class hierarchy so that we can reuse as much data/function as possible.

Identify the common attributes and function among the group of related classes and then combining them to form a new class.

Steps in … Design of classes.

Concentrate on the complete details that each class represents.

In addition to the service function a class must have the following functions:

Class management functions: Constructors and destructors.

Class implementation functions: operations performed on the data type of the class.

Class access functions

Class utility functions: exception handling.

Steps in … Other issues:

Access control for the base class Virtual functions/base classes Library classes Design of individual classes.

Guide lines: Public part should contain only functions of the class. Functions should be declared public only when it is required to be

used by the objects of the class. A class should be dependent on as few other classes as possible. Each subordinate class should be designed as a specialization of the

base class with sole purpose of adding additional features. The top class should represent the abstract model of the target

concept.

Steps in … Design of member functions:

Top down functional decomposition technique.

Design of driver program.

The main() function.

Resposibilities:

Receiving data values from the user.

Creating objects from class definitions.

Arranging communication among the objects.

Displaying output results.

Modeling Modeling is a way of thinking about the problems

using models organized around the real world ideas.

A modeling method comprises a language and also a

procedure for using the language to construct models.

modeling is the only way to visualize your design and

check it against requirements before your crew starts

to code.

What is UML Several different notations for describing object-

oriented designs were proposed in the 1980s and 1990s

The Unified Modeling Language is an integration of these notations

It describes notations for a number of different models that may be produced during OO analysis and design

It is now a de facto standard for OO modelling

What is UML.. • Is a language. It is not simply a notation for drawing

diagrams, but a complete language for capturing knowledge(semantics) about a subject and expressing knowledge(syntax) regarding the subject for the purpose of communication.

• Applies to modeling and systems. Modeling involves a focus on understanding a subject (system) and capturing and being able to communicated in this knowledge.

• It is the result of unifying the information systems and technology industry’s best engineering practices (principals, techniques, methods and tools).

UML Diagrams: Nine different diagrams to capture diferent views.

UML diagrams can capture the following views of the system:

User’s View:

Defines the functionalities available to the users by the system.

Black-box view.

Central view-all other views must conform with this view.

Structural view:

Static model

Defines the objects important to the understanding of the working of the system.

Captures relationships among the objects

Behavioural View:

Captures object interaction

Implementation View:

Important components of the system and their dependencies

Environmental View:

How diferent components are implemented on diferent hardware

User’s View -Use Case Diagram

Structural View -Class Diagram -Object Diagram

Behavioural View -Sequence -Collaboration -State chart -Activity

Implementation View -Component Diagram

Environmental View -Deployment Diagram

Use case model describes what the user expects the system to do

functional requirements

may describe only the functionalities that are visible to the user requirements view

consists of use case diagrams and textual descriptions

C-S 546 21

Elements of a Use Case diagram

C-S 546 22

actor

Use case

Use case

Use case Use case

generalization

dependency

dependency

System

actor

Definitions System

a black box that describes the system or subsystem that is modeled

example: ATM system, account verification subsystem

represented optionally as a rectangle in the use case diagram, but generally not shown

Actor a role played by an external entity that interacts with

the system

One object may play multiple roles in a context in which case there will be multiple actors example: bank manager as a customer

C-S 546 23

Definitions (continued) Primary actor

an actor who initiates the major, main or important use cases in the system

example : a customer in a banking system

Secondary actor an actor who is involved with one or more use cases but

does not initiate the use cases

example : database

The concepts of primary and secondary actors will be useful in ranking the roles played by the actors

C-S 546 24

Definitions (continued) Generalization between actors

one actor can be a specialization of another actor

based on the same concept as the specialization relationship between classes

example : preferred customer in a bank is a specialization of a customer

C-S 546 25

Definitions (continued) Use case

an important functionality to be implemented and is visible to the actors

an interacting behavior between an actor and the system

Must yield an observable result to the actor

example: “deposit” in a banking system

C-S 546 26

Definitions (continued) Association

an interaction between an actor and a use case

represented by an arrow between an actor and a use case

unidirectional associations must be represented by arrows direction of arrow indicate information flow

bi-directional associations can be represented by double-sided arrows or straight lines

C-S 546 27

Definitions (continued) Generalization between use cases

based on the same concept as generalization between classes; uses the same symbol

one use case can be designated as a specialization of another use case

example: “withdraw with overdraft protection” is a specialization of “withdraw”

C-S 546 28

Definitions (continued) “include” dependency

one use case may include another use case

if use case A includes a use case B, B must be implemented in order to implement A

based on the same concept as modular programming

represented as a dashed arrow from A to B with a label “<<include>>”

example : “withdraw” includes “update account”

C-S 546 29

Definitions (continued) “extend” dependency

one use case may be extended by another use case if use case A is extended by a use case B, then both A

and B can be independently implemented and used A will occasionally use B depending on some constraints

based on the same concept as modular programming represented as a dashed arrow from B to A with a

label “<<extend>>” Notice that the arrow is reversed

example : “withdraw” is extended by “check for privileged customer”

C-S 546 30

Use case Packaging When too many use cases are present at the top level

then we can package the related use cases so that as most 6-7 packages are present at the top level.

Accounts

Query balance

Receive grant

Make payment

Print balance sheet

Constraints in a Use Case model every use case must be connected to an actor or be

included in another use case or extends another use case

every use case connected to an actor must return an observable result to the actor

may be data or confirmation of termination of an action

C-S 546 33

How to find actors? those that interact with the system (provide input,

observe results, provide control information, …) primary actors

those that are used by the system but external to the system secondary actors such as data stores

information about actors can be found in the problem description

generally, users of the system are primary actors

C-S 546 34

How to find use cases? Every requirement is a use case

Every functionality that supports the implementation of a requirement is a use case

design issue

found when the first (abstract) use case model is refined to express a design

C-S 546 35

How to find use case relationships? extracted from the application domain

must be justifiable from the application domain or from the designer’s choice

examples “withdraw” includes “update account” is justifiable from

application domain

“withdraw” is extended by “withdraw with overdraft protection” is a designer’s choice designer can always implement two different versions of

withdrawals

C-S 546 36

Case Study - ATM Model only the transactions

Customer accounts assumed to exist Opening and closing of accounts is handled by another

portion of the system

Include operations “deposit”, withdraw”, “check balance”, “transfer”

If balance is zero or less than the amount to be withdrawn, then withdrawal should fail

C-S 546 37

Tic-Tac-Toe

Play Move

Tic-tac-toe Game

Player

CLASS DIAGRAMS: Represents static behaviour of the system.

Main constituents are classes and their relationships such as generalization, aggregation, association etc.

Representation of class: Solid outline rectangles with compartment.

Mandatory name compartment.

Name starts with an uppercase.

Library Member

Member Name Membership Number Books Issued . .

issueBook(); returnBook(); . .

Attributes name can be folllowed by square brackets, indicating the number of attributes per instances of the class. Eg. Marks[3]

Marks[3]:Float

X:int=0

X=0

issueBook(in bookname):Boolean

Associations and Links Connection between classes.

Relation between two objects are called links.

Links are instances of objects.

Library Member Book 1 * borrowed by

Amit C++ borrowed by 1 *

Usually associations are binary relations.

A class can have association with itself.

Association is represented by drawing a line.

Name of the association is written along the side of the line.

Arrowhead represents the reading directions.

Multiplicity represents how many instances of one classes are associated with other.

Aggregation: Special type of association where the involved classes

represent a whole part relationship.

If an instance of one object contains the instances of the other objects then aggregation relation ship exist between them.

Not reflexive, transitive.

Document Paragraph Line

1 * 1 *

Composition: Stricter form of aggregation.

The parts are existence dependent on the whole.

Life time of each part is tied closely with the life of the whole.

Order Item * 1

Inheritance: Represented by arrow pointing from subclass to super

class.

The combine arrow emphasize the collectivity of the of the subclass.

The set of subclasses of a class having same discriminator is called partition.

Library Boook

Reference Book Set

Reference Single Volume

Book

Issuable Book Set

Issuable Single Volume

Book

Issuable Reference

Dependency: A form of association between two classes which

shows that change in the independent class requires changes in the dependent class.

Dependent Class Independent Class - - - - - - - - - - - - - ->

Constraints Conditions or integrity rule.

Permissible set of values etc.

Enclosed within braces.

Object Diagrams Snapshot of the marks.

(Library Member)

Amit Jain Csm07003 . .

issueBook(); . .