1. Ch 12: Object-Oriented Analysis
CSCI 4320: Software Engineering

2. Workflows in the Unified Process
Requirements
Analysis
Design
Implementation
Test

3. 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

4. Functional Modeling
Present scenarios of all the use cases

5. Use Cases
Model interaction between the software product and the users of the software (actors)
Figure 10.1

6. 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).

7. Use Case: Withdraw Money
UC1
Reference: AC101
Banking Software Product
Withdraw Money
Customer
ATM

8. Use Case Description: Withdraw Money
UC1
Reference: AC101
Brief Description:
The Withdraw Money use case enables a customer to withdraw money.
Step by Step Description:
The Customer inputs ATM card that contains the account number.
The customer inputs pin number.
The software product responds with the current balance in the account.
The customer enters the withdrawal amount.
The software product produces the desired cash.
The software product updates the account balance.

9. Scenarios Normal Scenario Exception Scenario
Users interact with systems as planned
Normal flow of events
Exception Scenario
Designing for user errors
Exceptional flow of events

10. 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

11. 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)

12. 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.

13. Object-Oriented Programming
Inheritance:
BankAccount
+ name
+ balance
+ accountNumber
+widthraw()
CheckingAccount
+ lastCheckNum
Savings Account
+ interest
+widthraw()

14. 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()
CheckingAccount
+ lastCheckNum
Savings Account
+ interest
+widthraw()

15. Object-Oriented Programming
Polymorphism:
BankAccount myAccounts = new BankAccount[2];
myAccounts[0] = new SavingsAccount();
myAccounts[1] = new CheckingAccount();
for (myAccounts: BankAccount)
acct.withdraw(50);

16. Entity class modeling Determine entity classes and attributes
Determine interrelationship and interaction between the classes
Create class diagram

17. 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

18. 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

19. UML Class Diagram
Models the classes needed and relationship associations, inheritance, compositions and dependencies

20. 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

21. Identifying Classes
Create a list of all nouns from the requirement specification

22. 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?

23. 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.

24. 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

25. 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

26. 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

27. 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

28. Relationships Between Classes
Association
Labeled relationship between classes

29. Relationships Between Classes
Dependency
One class depends on another
Changing one class might require the second class also change.
Dashed arrow

30. Relationships Between Classes
Generalization
Inheritance: a class is the parent of another

31. Relationships Between Classes
Aggregation
Composition: a class is made up of another

32. UML Class Diagram
Models the classes needed and relationship associations, inheritance, compositions and dependencies