Object-Oriented Analysis and Design Introduction Topics and

Object-Oriented Analysis and Design Introduction

Topics and skills covered Principles & Guidelines Sample Activities OO Analysis & Design Topics and Skills UML notation Patterns Case Study

OO Technology ä Owning a hammer does not make one an architect ä Knowing an OO language and access to a rich library is a necessary but insufficient first step in creating object systems ä Analyzing and designing a system from an object perspective is also critical

Analysis and Design Analysis Design Investigation of the Problem Logical Solution

OO Analysis and Design ä Emphasis on finding and describing the objects or concepts in the problem domain ä Emphasis on defining logical software objects that will ultimately be implemented in an OO programming language

Activities in A&D ä ä 2 most important The most single important ability in OO is to skillfully assign responsibilities to software components Must be performed (inescapable) and it has the most profound effect on the robustness, maintainability, and reusability of software components. Next is finding suitable objects

OO emphasizes objects Domain Concept Representation in analysis of concepts Book title Representation in an OO programming language Public class Book { public void print(); private String title; }

OO Versus Function Oriented Analysis and Design The Library Information System OO A/D Structure A/D System Catalog Librarian Record Loans Book Library Add Resources Report Fines

Is it Analysis or is it Design? The division between analysis and design is fuzzy! Some methods classify an activity at varying points on the continuum.

Use cases: -expanded essentials Use case diagrams Conceptual Model Glossary System sequence diagrams Operation Contracts State diagrams Use cases: -real Window & reports Interaction diagrams Methods Design class diagrams Class & Interface definitions Architectural package diagrams dependency on Database schema SQL Test Cases

An Example of OO Analysis and Design A dice game in which a player rolls two die. If the total is seven, they win; otherwise they lose

Defining Use Cases of the Dice Game Define use cases Define conceptual collaboration model diagrams Define design class diagrams For example, in the dice game, here is the Play a Game use case. Use Case: Play a game Actors: Player Description: This use case begins when the player picks up the dice and rolls the dice. If the dice total seven, they win; otherwise, they lose

Conceptual Model of the Dice Game Define use cases Player name 1 Define conceptual collaboration model diagrams 1 Rolls Plays 1 Dice. Game 1 Includes 2 Define design class diagrams Die face. Value 2

Collaboration Diagram Illustrating Messages Between Software Define use cases Play() Define conceptual collaboration model diagrams : Player 1: r 1 : =roll() 2: r 2 : =roll() Define design class diagrams D 1 : Die D 2 : Die

Design class diagram of software components Define use cases Define conceptual collaboration model diagrams Player Dice Rolls name Define design class diagrams 1 2 play() 1 Dice. Game 1 Plays face. Value roll() 1 2 Includes initialize()

What is Visual Modeling? Order “Modeling captures essential parts of the system. ” Item Dr. James Rumbaugh Ship via Business Process Visual Modeling is modeling using standard graphical notations Computer System

Visual Modeling Captures Business Process Use Case Analysis is a technique to capture business process from user’s perspective

Visual Modeling is a Communication Tool Use visual modeling to capture business objects and logic Use visual modeling to analyze and design your application

Visual Modeling Manages Complexity

Visual Modeling Defines Software Architecture User Interface (Visual Basic, Java) Business Logic (C++, Java) Database Server (C++ & SQL) Model your system independent of implementation language

Visual Modeling Promotes Reuse Multiple Systems Reusable Components

Key Ingredients ä notation UML ä modeling tool Rational Rose ä process Rational Objectory Process

What is the UML? ä Unified Modeling Language ä a modeling language for object-oriented analysis and design ä It is not a methodology ä standard notation (v 1. 1 11/97) ä metamodel (model of a model)

What is the UML? ä The UML combines the best of the best from ä ä ä Data Modeling concepts (Entity Relationship Diagrams) Business Modeling (work flow) Object Modeling Component Modeling The UML is the standard language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system It can be used with all processes, throughout the development life cycle, and across different implementation technologies

Rumbaugh Jacobson Meyer Pre- and postconditions Booch Odell Harel Classifications State Charts Wirfs-Brock Shlaer-Mellor Object Life Cycles Gamma et al. Responsibilities Embly Singleton Classes Frameworks, patterns, notes Fusion Operation descriptions, message numbering

History of the UML Industrialization Standardization Unification UML 1. 0 UML Partner’s Expertise UML. 9 and. 91 Unified Method 0. 8 Booch ‘ 93 OMT-2 Fragmentation Other methods Booch ‘ 91 OMT-1 OOSE

Goals of UML ä Provide users a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models ä Be independent of particular programming languages and development processes ä Provide a formal basis for understanding the modeling

Goals of UML ä Provide a formal basis for understanding the modeling language ä Encourage the growth of the OO tools market ä Support higher-level development concepts such as collaborations, frameworks, patterns, and components ä Integrate best practices

Process ä constrained versus. creativity ä discipline versus bureaucracy ä well managed iterative and incremental life cycle provides the necessary control without affecting creativity ä UML focuses on a modeling language, NOT a standard processes

Define iteration to Initial risks address the highest Initial project risk scope Plan and develop the iteration Assess the iteration Revise project plan Revise risk assessment Risks Eliminated

Modeling Language - Method ä Language ä ä ä Syntax Notation Semantics ä Method ä ä ä what to do how to do it why to do it Objectory Coad/Yourdon Shlaer/Mellor OMT Fusion

Views of the UML Logical Component Design Use Case Deployment External Agents Jacobson Class & Package Sequence & State Diagrams Concurrency

UML categories Relationships Things Diagrams

UML Things Structural Behavioral Groups Annotational

Structural Things ä Nouns of the UML models ä Mostly the static parts of a model, representing elements that are either conceptual or physical

UML Things Classes Interfaces Collaborations Use Classes Components Nodes Structural Behavioral Groups Annotational

Class ä Description of set of object that share the same attributes, operations, relationships and semantics Window Origin Size Open() Close() Move() Display()

Interface ä Collection of interfaces ISpell operations that specify a service of a class or component. IUnknown IThesaurus Wordsmith. dll component

Collaboration ä Defines an interaction and is a society of roles and other elements that work together to provide some cooperative behavior that is bigger that the sum of all the elements. Chain of responsibility

Use case ä Description of a set of sequence actions that a systems performs that yields an observable result of value to a particular actor Place Order

Component ä ä A physical and replaceable part of the system that conforms to and provide the realization of a set of interfaces. Typically represents the physical package of otherwise logical elements, such as classes, interfaces and collaborations. Orderform. java

Node ä Physical element that exists at run time and presents a computational resource server

UML Things Structural Behavioral Groups Annotational Interaction State machine

Behavioral Things ä Dynamic parts of UML models ä Represent behavior over time and space

Interaction ä Behavior that comprises a set of messages exchanged among objects within a particular context to accomplish a specific purpose display

State Machine ä Behavior that specifies the sequences of states an object Waiting

UML Things Structural Behavioral Groups Annotational Package

Package ä General-purpose mechanism for organizing elements into groups. ä Unlike components, which exist at run time, a package is purely conceptual Business rules

UML Things Structural Behavioral Groups Annotational

Annotational ä Explanatory parts Return copy of self

UML Relationships Dependency Generalization Association Aggregation

UML Diagrams Object Class Statechart Collaboration Sequence Activity Use Case Component Deployment

Diagrams ä ä ä ä Class - Set of classes, interfaces and collaborations and their relationships Object – represents static snapshots of instances of things found in class diagrams Use case – set of use cases and actors Interaction – shows an interaction consisting of a set of objects and their relationships (sequence and collaboration are isomorphic) Statechart – shows a state machine Activity – special kind of statechart that shows the flow from activity to activity within a system Component – organization and dependencies among a set of components Deployment – configuration of run-time processing nodes and the components that live on them

Case Study Plan and Elaborate Phase

Case Study: Point-of-Sale The main case study is a point-of-sale terminal (POST) system. A point-of-sale terminal is a computerized system used to record sales and handle purchases. It includes hardware components such as a computer and a bar code scanner and software to run the system We create the software!

Understanding the Requirements ä Create requirement phase artifacts, such as function specifications ä Identify and categorize system functions ä Identify and categorize system attributes and relate them to functions

Basic Functions

Understanding the Requirements ä Need to grasp ä the domain process ä users/surroundings

Grasping the Domain Process ä Use cases (Jacobson) ä a narrative description of a domain process ä a typical interaction between a user and a computer system ä captures some user-visible function Borrow Books ä may be small or large from the Library ä achieves a discrete goal for the user ä the use case diagram is now part of the UML

High-level and Expanded Use Cases ä UML does not specify a rigid format ä High Level Use Case: Buy Items Actors: Customer, Cashier Type: Primary Description: A Customer arrives at a checkout with the items to purchase. The Cashier records the purchase items and collects payment. On completion, the Customer leaves with the items.

ACTORS Someone or something that interacts with the system

Actors ä ä ä Not part of the system may initiate interaction with the system are autonomous from the system can be people can be other systems ä ä ä Electrical or mechanical device Is a role can be played by more than one user can play more than one role documented in the Actor Catalog

Actor Catalog ä ä ä Actor Customer Cashier Customer ä ä ä Role Description buys/returns items Process transactions Cashier UML icon for a user case actor

Expanded Use Case (Top section) Use Case: Buy Items with Cash Actors: Customer (initiator), Cashier Purpose: Capture a sale and its cash payment Overview: A Customer arrives at a checkout with items to purchase. The Cashier records the purchase items and collects a cash payment. One completion, the Customer leaves with the items. Type: primary and essential Cross Refs: R 1. 1, R 1. 2, R 1. 3, R 1. 7, R 1. 9, R 2. 1

Explaining Expanded Use Case (Top section) Use Case: Actors: Name of the use case. List of actors(external agents), indicating who initiates the use case. Purpose: Intention of the use case Overview: Repetition of the high-level use case, or some similar summary Type: 1. primary, secondary or optional (later) 2. essential or real Cross Refs: Related use cases and system functions

Expanded Use Case Remaining Sections ä Typical contents - middle section ä how the use case starts and ends ä normal flow of events ä Typical contents - Final section ä alternative flow of events ä exceptional flow of events

Expanded Use Case (middle section) Typical Course of Events Actor Action System Response 1. This use case begins when a Customer arrives at a POST checkout with items to purchase. 2. The Cashier records the identifier 3. Determines the item price for each item. and adds the item information to the running sales transaction. If there is more than one of the same item, the Cashier can enter the The description and price quantity as well. of the current item are presented.

Expanded Use Case (middle section continued) Typical Course of Events Actor Action System Response 4. On completion of item entry, the 5. Calculates and presents the Cashier indicates to the POST sale total. that item entry is complete. 6. The Cashier tells the Customer the total. 7. The Customer gives a cash payment -- the “cash tendered” -possibly greater than total. 8. The Cashier records the cash 9. Shows the balance due back received amount. to the Customer. Generates a receipt.

Expanded Use Case (middle section continued) Typical Course of Events Actor Action System Response 10. The Cashier deposits the cash 11. Logs the completed sale. received and extracts the balance owing. The Cashier give the balance owing and the printed receipt to the Customer. 12. The Customer leaves with items purchased

Expanded Use Case (final section) Alternative Courses Event 2: Invalid identifier entered. Indicate error. Event 7: Customer didn’t have enough cash. Cancel sales transaction.

Decision Points and Branching ä Use cases may contain decision points. ä Example: in Buy Items, the customer may choose to pay via cash, credit, or check or payment time ä If one of these decisions overwhelmingly represents the typical case and the others are rare, then the others should be mentioned in the alternatives section

Buy Items Section: Main Typical Course of Events Actor Action … 7. Customer chooses payment type: a. If cash payment, see section Pay by Cash b. If credit payment, see section Pay by Credit c. If check payment, see section Pay by Check … Section: Pay by Cash System Response

A Common Mistake in Use Cases ä Represent individual steps, operations or transactions as use cases. ä Example: Printing the Receipt - the printing operation is merely a step in much larger use case process Buy Items ä can break down activities or portions in subuse cases (abstract use cases) but this is not the norm

Identifying Use Cases ä Actor-based ä Identify the actors related to a system or organization. ä For each actor, identify the processes they initiate or participate in. ä Event-based ä Identify the external events that a system must respond to. ä Relate the events to actors and use cases.

Notation - Naming Use Cases ä Name a use case starting with a verb in order to emphasize that it is a process. ä Buy Items ä Enter an Order

Examples Actor-based Event(process)-based Cashier Withdraw cash from ATM Order a product Register for courses at a school Check the spelling of a document in a word processor Handle a telephone call Log In Cash Out Customer Buy Items Refund Items Manager Start Up Sys-Admin Manage Users

Use Case Diagrams Buy Items POST Cashier Customer Log In Refund Items Start Up Manage Users System Administrator Manager

Essential versus Real Use Cases ä Essential ä free of technology and implementation details ä design decisions are deferred and abstracted especially related to the user interface ä Real ä concretely describes the process in terms of its real current design, committed to specific input and output technologies

Buy Items Use Case (essential) ä The expanded Buy Items use case already shown tends towards being an essential use case. Note, it is very non-committal with respect to the technical realization. ä Example. The Cashier records the identifier for each item.

Buy Items Use Case (real) Real Actor Action System Response 1. For each item, the Cashier 2. Displays the item price and types in the Universal Product and adds the item infor. Code (UPC) in the UPC input mation to the running sales field of Window 1. They then transaction, press the “Enter Item” button with the mouse or by pressing The description of the price <Enter>. of the current item are displayed in Textbox 2 of Window 1. 3. Etc.

Ranking and the Scheduling of Use Cases ä Completed the artifacts of Requirements Spec and Use Cases ä transition to the build phase of the iterative development life-cycle ä development cycles are organized around use cases - a development cycle is assigned to implement one or more use cases or simplified version of use cases

Ranking Use Classes ä High ranking use classes are tackled early ä Qualities that increase the ranking are: ä significant impact on architectural design ä risky, time-critical, or complex functions ä involve significant research, or new technology ä represents the primary line-of-business ä directly support increased revenue or decreased cost

POST Scheduling ä Buy Items should be tackled first. Also a simple version of Start Up to support other use cases ä Buy Items - v 1 (cash payments, no inventory updates) ä Buy Items - v 2 ( allow for all payment types) ä Buy Items - v 3 ( complete version including the handling of inventory updates)

Allocation of Use Cases Development Cycle 1 Development Cycle 2 Development Cycle 3 Development Cycle 4 Buy Items Version 1. . . Buy Items Version 2. . . Buy Items Version 3. . . Log in. . . Refund Items. . .

Case Study Analysis Continued