swe © solomon seifu 2010 1 lesson 3 fundamentals of oo & uml

SWE © Solomon Seifu 2010 1

Lesson 3Fundamentals of OO &

UML


SWE: Principles of OO

Encapsulation The implementation is hidden behind an interface,

and clients only depend on the interface Inheritance/Hierarchy

Different levels of abstraction that can be used to factor out common functionality

Polymorphism The ability of an object to respond appropriately to the

same message based on what kind of an object it is


SWE: Principles of OO (Cont.)

Open/Closed principle says the code should be closed for modification but open for extension

Liskov substitution principle says wherever you use the parent class you can use the child class

Programming to the interface means declaring your variables, parameters, and return types to be of the interface type, rather than of any specific implementation type


SWE: Principles of OO - Encapsulation

Implementation

Interface

Client

Client

Implementation is hidden from client via the interface

SWE © Solomon Seifu 2010

SWE: Principles of OO - Inheritance or Hierarchy

Person

Student Faculty

Part-time Student Full-time Student Instructor Professor

Is there really an IS-A

relationship or a role play?


SWE: Principles of OO - Polymorphism

Shape

computeArea()

Circle

computeArea()

Square

computeArea()

Rectangle

computeArea()

Area = PI * r * r Area = s * s Area = w * l


Fundamentals Of OO Exercise


Fundamentals of OO Exercise Answer


The Unified Modeling Language

(UML)


SWE: Unified Modeling Language (UML )

Almost all successful software systems are built from models

A model is a simple representation of something complex

A model makes it possible for those who want to build a system to visualize it

It is a way to specify what the system is to do and to guide the construction of the system

A model creates a common language, or a common way of understanding


SWE: UML (Cont.) The UML provides a set of elements that allow

you to model software systems It is a general-purpose modeling language It offers a set of diagrams, views, and modeling

elements that help you do the following: Analyze the requirements you have gathered Design software using your requirements Document the software you have developed Develop test cases Plan product releases Discuss and conceptualize software


SWE: UML - Diagrams

Types Use Case Activity Class Object State Chart Sequence Collaboration Component Deployment Package

CommunicationUse case Activity

ObjectDeployment

State Sequence

ComponentClass

Models

Package

Behavior diagram

Interaction Timing

Interaction diagrams

Are of type behavior diagrams

Structure diagram


Use Cases:A use case is a sequence of actions a

system performs that yields an observable result of value to a particular actor.


SWE: UML - Use Cases

Requirements come in all shapes and forms and from a variety of sources

Projects often fail because the requirements were not accurately understood

The first thing to do is to make sure the basic requirements are understood

This is where use cases come in. You can apply use case modeling to develop a precise model of what is required of the system


SWE: UML - Use Cases (Cont.)

Ivar Jacobson et.al., popularized the application of use cases for understanding the functional requirements of a system in the early 1990s

Use Cases are a widely used technique for requirements specification as part of the Unified Modeling Language (UML)

A use case describes things actors want the system to do



According to RUP, a Use Case "…fully describes a sequence of actions performed by a system to provide an observable result of value to a person or another system using the product under development."

Use cases tell the customer what to expect, the developer what to code, the technical writer what to document, and the tester what to test


SWE: UML - Use Cases (Cont.) There are two fundamental concepts in use case

modeling: Actor – An actor represents something (or someone)

outside the system, typically a user of the system. Actors interact with the system, which results in some action by the system. Each distinct role is represented by an actor

Use case – A use case encapsulates a sequence of steps performed by the system on behalf of an actor. Use cases provide something of value to the actor. A use case consists of primary sequence of events and may have one or more alternate sequence of events



Use cases reside inside the system A use case describes the actions the

system takes to deliver to the actor Taken together, all use cases constitute all

ways of using the system Is an abstraction of a set of sequences

that yield some functionality



Represents some user-visible function Is always initiated by an “actor” Describes the interaction between the

actors and the system for a system function

Achieves a discrete goal for the actor


SWE: UML - Purpose of Use Cases

To capture functional requirements of a system To communicate with end users and domain

experts To design test cases for validating system

functionality To provide traceability from requirements into

actual classes and operations To drive the development process To plan iterations and releases


SWE: UML - Use Cases (Identifying the Actors)

As you read the description or gather requirements for a project, ask yourself a few important questions:Who will use this functionality?Who is supplying or obtaining information?Who can change the information?Are there any other systems that interact with

the system being developed?


SWE: UML - Use Cases (Identifying the

Actors) (Cont.) An actor can be a person; but it may also be another

system, or perhaps a device such as a printer An actor may even be a signal or event to which you

must respond. From a component design perspective, you might model the clients of your component as actors, even though those are “the system” from the perspective of the designers of those components. (And conversely, of course, your component is an actor from their perspectives.)


SWE: UML - Use Cases (Identifying the

Actors) (Cont.) Who uses the main functionality of the system? Which hardware devices the system needs to handle? Which other systems does the system need to interact

with? What nouns/subjects are used to describe the

system? For example: The Reservation Clerk makes a booking using the

system, based on the... A user must login in order to save his itinerary


SWE: UML - Use Cases (Finding Use Cases)

What functions does the system perform? What functions do the “actors” require? What input/output does the system need? What verbs are used to describe the system? For

example: The Reservation Clerk makes a booking using the

system, based on the... The Airport Manager can make an entry for a new flight.

He can also modify flight details, provided...


SWE: UML - Use Cases (Finding Use

Cases) (Cont.) Use cases are always expressed from the

perspective of the actor (that is, the user of the system)

The idea is to capture the sequence of events performed by the system at the requests of the actor, such that they yield some observable, valuable results to the actors


Use Case Diagram


SWE: UML - Use Case Diagram

In the UML, actors are represented by a stick figure, and use cases are shown as ellipses

A use case diagram simply shows the structural relationships between the actors and the use cases, not the dynamic relationships

The relationship between actors and use cases is shown via a non-directional association even though indicating source of invocation is always the actor


SWE: UML - Use Case Diagram (Cont.)

Use Case 1

Use Case 2Actor

System BoundaryInvoking a use case


SWE: UML - Use Case Diagram (Inheritance Between Actors)

An actor in a use case diagram can inherit another actor

The standard UML notation for inheritance, the open-headed arrow, is used and the advice presented about the appropriate use of inheritance still applies: it should make sense to say

the inheriting actor is or is like the inherited actor

User

Super User

RegularUser


SWE: UML - Use Case Organization

Organize Related Use Cases in PackagesSemantically related

groupsDevelopment groups

etc.


SWE: UML - Use Case Relationship

The UML notation provides the following relationships, which can be used to model reuse within use cases

They are: IncludeExtend Inherits


SWE: UML - Use Case (Include or Uses)

An include relationship allows you to capture a common piece of functionality in a separate use case, and then “include” the use case in another use case via the include relationship

The include relationship is shown as a dependency relationship stereotyped as <<include>>

Base Use Case

Inclusion Use Case

<<include>>


SWE: UML - Use Case (Include Example)

Borrow copy of book

Extend loan

Check for reservation

Book Borrower

<<include>>

<<include>>


SWE: UML - Use Case (Include yet Another Example)

LogIn

CheckOrderStatus

<<include>>

The following figure illustrates an e-commerce application that provides customers with the option of checking the status of their orders. This behavior is modeled with a base use case called CheckOrderStatus that has an inclusion use case called LogIn. The LogIn use case is a separate inclusion use case because it contains behaviors that several other use cases in the system use. An include relationship points from the CheckOrderStatus use case to the LogIn use case to indicate that the CheckOrderStatus use case always includes the behaviors in the LogIn use case.


SWE: UML - Use Case (Extend)

An extend relationship allows you to model optional behavior for a use case. That is, you can capture some behavior in a separate use case and, within another use case, indicate the exact points (called extension points) where the separate use case may optionally be invoked as part of the use case

An extend relationship is modeled as a dependency and stereotyped as <<extend>>

Base Use Case

ExtensionUse Case

<<extend>>


SWE: UML - Use Case (Extend Example)

Take CustomerOrder

Sales Assistant

Sell Customer-Specific

Product

<<extend>>


SWE: UML - Use Case (Extend yet Another Example)

Place OnlineOrder

Specify Shipping Instructions

<<extend>>

You are developing an e-commerce system in which you have a base use case called Place Online Order that has an extending use case

called Specify Shipping Instructions. An extend relationship points from the Specify Shipping

Instructions use case to the Place Online Order use case to indicate that the behaviors in the Specify Shipping Instructions use case are

optional and only occur in certain circumstances.


SWE: UML - Inheritance Between Use Cases

Use cases can inherit from other use cases

A generalization/specialization relationship exists

The inheriting use case would completely replace one or more of the courses of action of the inherited use case


SWE: UML - Use Case (Generalization Example)

In the example shown, we would be indicating that there are some common steps for all Use Cases that handle customer transactions and that the child Use Cases “Return Faulty Goods” and “Take Customer Order” have additional steps that fit into or around them

Return Faulty Goods

Take CustomerOrder

Handle Customer Transaction

SalesAssistant


Use Case Diagram Exercise


Use Case Diagram Exercise Answer

SWE © Solomon Seifu 2010

SWE: Fundamentals of OO & UML - Wholeness

Encapsulation, Inheritance and Polymorphism are the three corner stones of OOP

The saying “A picture speaks a thousand words” implies that images, figures & models are powerful concepts that enable the conveyance of a complex idea. UML does just that

Use Case modeling is widely used to capture and articulate requirements specifications

swe © solomon seifu 2010 1 lesson 3 fundamentals of oo & uml

Documents

softwareswe solomon

isswe solomon seifu

interfaceswe solomon

use case modeling

principles of oo cont

uml use casesrequirements

unified modeling language

uml cont