Object Oriented Design & Analysis - Introduction

Overview of Key Concepts

• Object & Classes

• Abstraction, encapsulation, and interface

• Introduction to UML

Objects & Classes

• An object is anything that a system is interested in

• Objects have attributes and behavior

• A class is a blueprint for creating objects having the same set of attributes and behavior

• Characteristics of OO Systems– Abstraction

– Encapsulation

– Interface

Abstraction, Encapsulation, and Interface

• ABSTRACTION = what an object is/ what an object does– Example: ATM device

• Dispenses cash to valid customer• Reports current balance of a customer• Allows fund transfer from one account to another

• ENCAPSULATION = how an object does what it does– Example: ATM device

• How it connects to the bank’s database to verify balance• How it counts currency to dispense

• INTERFACE = how the clients of an object talk to it– Example: ATM device

• The slot for inserting the ATM card• The buttons for the users to specify their options

EXERCISE

• What is the abstraction of a car?

• What is encapsulated?

• What is the interface?

More Formally

• Abstraction = externally visible behavior of an object

• Encapsulation = the internal data structure and implementation that gives rise to the externally visible behavior of an object

• Interface = set of public functions of a class

The Unified Modeling Language (UML)

• What is modeling?– Understanding, visualizing, specifying, and documenting

the requirements of a software system and the way we plan to fulfill them

– The UML provides a rich notation for visualizing our models. This includes a number of key diagrams, such as:• Use case diagrams, to illustrate user interaction with the system

• Class diagram, to illustrate logical structure

• Component diagrams, to illustrate physical structure of the software

• Sequence diagrams, to illustrate behavior of various collaborating classes in a part of the system

Benefits of Visual Modeling

• System requirements can be communicated clearly.

• Models capture the software design unambiguously

• Flaws in architecture and inconsistencies in design can be detected early and more easily

• Unnecessary details are hidden when appropriate, making the handling of complexity easier

• Computerized tools for visual modeling can be used to automate many tasks of analysis and design

• The full specification of UML can be downloaded from the OMG website: www.omg.org

UML Diagrams

• Activity diagram• Use case diagram• Class diagram• Object diagram• State machine diagram• Sequence diagram• Communication diagram• Component diagram• Deployment diagram• Package diagram• Composite structure diagram• Timing diagram• Interaction overview diagram

UML Tools

• IBM Rational: Rational Rose, Rational Software Architect

• Borland: Together Software Architect

• Sparx Systems: Enterprise Architect

• Sybase: PowerDesigner

• Microsoft: Visio

Software Development Life Cycle

• Requirement determination

• Analysis (problem domain)

• Design (solution domain)

• Implementation

• Deployment

Requirement Determination

• Activity diagram

• Actors and use cases

• Use case diagram

• Use case specification

Activity diagram

• Used for modeling– A business process

– Logic for single use case

– Logic for a business rule

• Particularly useful in the early stages of requirements determination to visualize and document our understanding of the overall process of the system. They can also be used to elaborate specific aspects of the workflow in more detail further.

• The activity diagram emphasize the flow of control from one activity to another activity.

Activity digram

Customer places purchase order

Debit customer’s bank account

Place an order on the stock exchange

Deal executed on the stock exchange

Payment to the stock exchange

Delivery of shares (demat) directly to customer’s account

Refund balance amount, if any, to the customer

Customer places/ modifies an order

Stores department dispatches the goods

Ask the customer to modify the order

Accounts department sends the invoice

Customer receives the goods

Customer receives the invoice

Customer makes the payment

Customer Sales Stores Accounts

Customer places/ modifies an order

Ask the customer to modify the order

Customer receives the goods

Customer receives the invoice

Customer makes the payment

Stores department dispatches the goods

Accounts department sends the invoice

Accounts Dept issues receipt for payment

Actors

• Anyone/ anything that interacts with a system is an actor

• Types of actors:

– Human actors (users of the system)

– External applications

– External devices

Use cases

• Functionality provided by the system

• Consist of a series of steps which collectively add value to the user of the system

• Examples– Issue a book to a member

– Receive a book back from a member

– Query the current location of a book

– Maintain member’s information

– Maintain book’s information

Identifying use cases for a system

• What are the tasks of each actor?

• Will any actor create, store, change, remove, or read the information?

• Will any actor need to inform the system about the sudden, external changes?

• Does any actor need to informed about certain occurrences in the system?

• What use cases will support and maintain the system?

• Can all functional requirements be performed by the use cases?

Use case diagram

• Graphical view of some or all of the actors, use cases, and their interactions identified for a system. Each system typically has a main use case diagram, which is a picture of the system boundary (actor) and the major functionality by the system (use cases). Other use case diagrams may be created as needed.

Use case diagrams

Use case diagrams

Generalization of Actors

Generalization of use cases

The Include Relationship

The Include Relationship

Variations in a Use Case

The Extend relationship

Use case specification

• Description of the desired behavior of a use case• Should describe what the system should do, rather than how it will

do it• The specification for a use case should be documented to clearly

describe the events needed to achieve the required behavior of the use case. The use case specification should be written in terms of what the system is supposed to do, not how the system does it. The specifications should include:– When and how the use case starts and ends– What interaction the use case has with the actors– What data is needed by the use case– The normal sequence of events for the use case– The description of alternate or exceptional flows

Thank you