Ch 12: Object-Oriented

processroguishSoftware and s/w Development

Nov 18, 2013 (3 years and 11 months ago)

67 views

Ch 12: Object
-
Oriented
Analysis

CSCI 4320: Software Engineering

Workflows in the Unified Process


Requirements


Analysis


Design


Implementation


Test

Analysis Workflow


Analyze and refine requirements for detailed
understanding


Written in language of developer



more precise.


Specifications produced are
essential

for testing
and maintenance


OO Architectural Design:

UML diagrams and
descriptions are given to client for confirmation
(Use Cases and Class Diagrams)


Detailed planning and estimating:
Software
Project Management Plan

with deliverables,
milestones and budget


GOAL: Spell out
what

the project is to do

Functional Modeling


Present scenarios of all the use cases

Use Cases


Model interaction between the software product
and the users of the software (
actors
)

Figure 10.1

Use Case Diagrams


A
use case

is description of a scenario in
which the system to be developed interacts
with the users of the system


Create several
use case

diagrams with
annotated descriptions to represent all of
the acceptance criteria listed in the
specification report.


Each
Use Case diagram

should be label
with the corresponding
Acceptance
Criteria Number
(s).

Use Case: Withdraw Money

Banking Software Product

Withdraw Money

Customer

ATM

UC1

Reference: AC101

Use Case Description: Withdraw Money

Brief Description:

The Withdraw Money use case enables a customer to withdraw money.

Step by Step Description:

1
The Customer inputs ATM card that contains the account number.

2
The customer inputs
pin
number.

3
The software product responds with the current balance in the account.

4
The customer enters the withdrawal amount.

5
The software product produces the desired cash.

6
The software product updates the account balance.

UC1

Reference: AC101

Scenarios


Normal Scenario


Users interact with systems as planned


Normal flow of events


Exception Scenario


Designing for user errors


Exceptional flow of events

Object
-
Oriented Programming

Instead of writing a program in one long file,
separate code into classes each with their
own data and logic.



A
bstraction


P
olymorphism


I
nheritance


E
ncapsulation

Object
-
Oriented Programming

Abstraction:



Focus on the essential qualities rather than
the details.


This is what we are doing when we are
making a class.


We don’t create a separate bank account
class for Joe and Mary
--

just one bank
account class that contains common
attributes (name, address, account
number)

Object
-
Oriented Programming

Encapsulation:


Taking attributes and behaviors and
bundling them together.


Data hiding: We are able to make things
private and users to use our public
methods.
Attributes can’t be directly
changed from outside object.


Reduce dependencies on different parts of
the application. An object is responsible for
changing itself.

Object
-
Oriented Programming

Inheritance:





BankAccount

+ name

+ balance

+
accountNumber

+
widthraw
()

Savings Account

+ interest

+
widthraw
()

CheckingAccount

+
lastCheckNum

Object
-
Oriented Programming

Polymorphism: “
Many forms”








A
SavingsAccount

subclass may override as
super class,
BankAccount

withdraw

method.


When you create an array of
BankAccount

objects, you determine at runtime which method is
called.

BankAccount

+ name

+ balance

+
accountNumber

+
widthraw
()

Savings Account

+ interest

+
widthraw
()

CheckingAccount

+
lastCheckNum

Object
-
Oriented Programming

Polymorphism:


BankAccount myAccounts =
new

BankAccount[2];

myAccounts[0] =
new

SavingsAccount();

myAccounts[1] =
new

CheckingAccount();


for (myAccounts: BankAccount)

acct.
withdraw
(50);

Entity class modeling


Determine entity classes and attributes


Determine interrelationship and interaction
between the classes


Create class diagram

Class Diagrams


Model the composition of classes


Static perspective of the system


Objective: portray the elements that are a
part of the class and the essential
relationships that exist between classes

Class Diagrams


A class may be portrayed in various class
diagrams with varying levels of detail



Analysis Phase
: specify the class name


Design Phase
: specify the class name,
attributes and methods

UML Class Diagram


Models the classes needed and relationship
associations, inheritance, compositions and
dependencies

Classes

Chapter 12 describes 3 types of classes


Entity Class


Models Information that is long lived.


Boundary Class


Models the interaction between the software
product and actors (input and output)


Control Class


Models complex computations and algorithms

Identifying Classes




Create a list of all nouns from the
requirement specification

Is This a Class?


Retained information


Potential classes require information to be
stored about them


Are there certain attributes that must be
stored in the system?


Class
System User



Does the system allow for
multiple concurrent users or does it maintain a
history of individual user?

Is This a Class?


Needed Services


Does the potential class have a set of
operations that provide services to other
classes?


Is there a set of information to be manipulated
or retrieved by methods in order to protect the
integrity of this data?


Game

class: In a game you allow each user to
inquire the current score of opposing player,
amount of time elapsed.

Is This a Class?


Multiple Attributes


Does the potential class have more than a
single attribute?


If not, this noun should be an attribute of
another class


Balance

is more likely an attribute

Account

is more likely a class

Is This a Class?


Common Attributes


Do all instances of this noun share the same
attributes?


If not, this noun should probably not be a
class

Is This a Class?


Common operations


Do the operations defined for this noun apply
to all other instances of the noun?


Customer

class has a common set of a
methods like
getName
,
getAddress

Is This a Class?


Essential Requirements


Are there external entities known to the system that
produce or consume information


A
Database

class, has a set of easy to learn
methods so developer would not need to be
familiar with the technical details utilizing the
database.

The type of underlying database could be switched
and the methods of the
Database

class need not
change

Relationships Between Classes


Association


Labeled relationship between classes


Relationships Between Classes


Dependency


One class depends on another


Changing one class might require the second
class also change.


Dashed arrow

Relationships Between Classes


Generalization


Inheritance: a class is the parent of another


Relationships Between Classes


Aggregation


Composition: a class is made up of another


UML Class Diagram


Models the classes needed and relationship
associations, inheritance, compositions and
dependencies