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 UC1 Reference: AC101 Banking Software Product Withdraw Money Customer ATM

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.

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

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 Programming Inheritance: BankAccount + name + balance + accountNumber +widthraw() CheckingAccount + lastCheckNum Savings Account + interest +widthraw()

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()

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