Presentation is loading. Please wait.

Presentation is loading. Please wait.

Ch 12: Object-Oriented Analysis

Similar presentations

Presentation on theme: "Ch 12: Object-Oriented Analysis"— Presentation transcript:

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

Download ppt "Ch 12: Object-Oriented Analysis"

Similar presentations

Ads by Google