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

UC1Reference: AC101

Use Case Description: Withdraw Money

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

Step by Step Description:

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

2The customer inputs pin number.

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

4The customer enters the withdrawal amount.

5The software product produces the desired cash.

6The software product updates the account balance.

UC1Reference: 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.

•Abstraction

•Polymorphism

•Inheritance

•Encapsulation

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 ProgrammingInheritance:

BankAccount+ name+ balance+ accountNumber+widthraw()

Savings Account+ interest+widthraw()

CheckingAccount+ lastCheckNum

Object-Oriented ProgrammingPolymorphism: “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