Object-Oriented Analysis and Design

A.1A.1

Learning Objectives Key terms

Association Class diagram Event Object Object class Operation Sequence diagram State State transition Unified Modeling Language (UML) Use case

A.2A.2

The Object-Oriented Modeling Approach

Benefits1. The ability to tackle more challenging problem

domains

2. Improved communication among users, analysts, designers, and programmers

3. Reusability of analysis, design, and programming results

4. Increased consistency among the models developed during object-oriented analysis, design, and programming

A.3A.3

The Object-Oriented Modeling Approach (continued)

Object-Oriented Systems Development Life Cycle Process of progressively developing

representation of a system component (or object) through the phases of analysis, design, and implementation

The model is abstract in the early stages As the model evolves, it becomes more

and more detailed

A.4A.4

The Object-Oriented Systems Development Life Cycle

Analysis Phase Model of the real-world application is developed

showing its important properties Model specifies the functional behavior of the

system independent of implementation detailsDesign Phase Analysis model is refined and adapted to the

environmentImplementation Phase Design is implemented using a programming

language or database management system

A.5A.5

The Object-Oriented Systems Development Life Cycle (continued)

Unified Modeling Language (UML) A notation that allows the modeler to specify,

visualize and construct the artifacts of software systems, as well as business models

Techniques and notations Use cases Class diagrams State diagrams Sequence diagrams

A.6A.6

Use-Case Modeling

Applied to analyze functional requirements of the systemPerformed during the analysis phase to help developers understand functional requirements of the system without regard for implementation detailsUse Case

A complete sequence of related actions initiated by an actor A use case that documents the interaction between the

system user and the system.

Actor An external entity that interacts with the system

A.7A.7

What Is Use-Case Modeling?

A means for capturing the desired behavior for the system under development

A way to communicate the system's behavior

Identifies who or what interacts with the system and what the system should do

A way to verify all requirements are captured

A planning instrument

Relevant Requirements Artifacts

SupplementarySpecification

Glossary

Use-Case Specifications

...

Use-Case Model

Actors

Use Cases

A.10A.10

A Scenario Is a Use-Case Instance

Scenario 1Log on to systemApprove log onEnter subject in searchGet course listDisplay course listSelect coursesConfirm availabilityDisplay final schedule

Scenario 2Log on to systemApprove log onEnter subject in searchInvalid subjectRe-enter subject Get course listDisplay course listSelect coursesConfirm availabilityDisplay final schedule

Student Course Catalog System

Register for Courses

Use Case descriptionA Use Case has:

Name Brief description Primary actor Stakeholders and interest lists Pre-conditions and Post -condition Flow of events

Usually structured in sections One section for ‘Basic flow of events’ Several sections for ‘Alternative flow of events’

Special Requirement Specific requirements on the Use Case (performance, security,

reliability and so on.) that are not expressed in the previous description

Use Case : Process Sale(1/4)Primary Actor: Cashier

Stakeholders and Interests: Cashier: Wants accurate, fast entry, and no payment errors, as

cash drawer short- ages are deducted from his/her salary. Salesperson: Wants sales commissions updated. …..

Preconditions: Cashier is identified and authenticated.

Success Guarantee (Postconditions): Sale is saved. Tax is correctly calculated. Accounting and Inventory are updated. Commissions recorded. Receipt is generated. Payment authorization approvals are recorded.

Use Case : Process Sale(2/4)Main Success Scenario (or Basic Flow): 1. Customer arrives at POS checkout with goods

and/or services to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier. 4. System records sale line item and presents item

description, price, and running total. Price calculated from a set of price rules.

Cashier repeats steps 3-4 until indicates done. ……

Use Case : Process Sale(3/4)Extensions (or Alternative Flows): 3a. Invalid identifier:

1. System signals error and rejects entry. 3b. There are multiple of same item category and tracking

unique item identity not important (e.g., 5 packages of veggie-burgers):1. Cashier can enter item category identifier and the quantity.

3-6a: Customer asks Cashier to remove an item from the purchase:1. Cashier enters item identifier for removal from sale.

2. System displays updated running total. 7b. Paying by credit:

1. Customer enters their credit account information.

2. ….

Use Case : Process Sale(4/4)Special Requirements:

Touch screen Ul on a large flat panel monitor. Text must be visible from 1 meter.

Credit authorization response within 30 seconds 90% of the time. Somehow, we want robust recovery when access to remote

services such the inventory system is failing. Language internationalization on the text displayed. Pluggable business rules to be insertable at steps 3 and 7.

Technology and Data Variations List: 3a. Item identifier entered by bar code laser scanner (if bar code is

present) or keyboard. 3b. Item identifier may be any UPC, EAN, JAN, or SKU coding

scheme. 7a. Credit account information entered by card reader or keyboard. 7b. Credit payment signature captured on paper receipt. But within

two years, we predict many customers will want digital signature capture.

Object Modeling:Class Diagrams

Object An entity that has a well-defined role in the application

domain, and has state, behavior, and identity

State A condition that encompasses an object’s properties and the

values those properties have

Behavior A manner that represents how an object acts and reacts

Object Class A set of objects that share a common structure and a

common behavior

A.17A.17

Object Modeling:Class Diagrams (continued)

Class Diagram Class is represented as a rectangle with

three compartments Objects can participate in relationships with

objects of the same class

A.18A.18

Object Modeling:Object Diagrams

Object Diagram A graph of instances that are compatible with a given class

diagram; also called an instance diagram Object is represented as a rectangle with two compartments

Operation A function or service that is provided by all the instances of a

class

Encapsulation The technique of hiding the internal implementation details

of an object from its external view

A.19A.19

A.20A.20

Representing Associations

Association A relationship between object classes Degree may be unary, binary, ternary or higher Depicted as a solid line between participating

classesAssociation Role The end of an association where it connects to a

class Each role has multiplicity, which indicates how

many objects participate in a given association relationship

A.21A.21

A.22A.22

Finding associations – common association List

Category System

A is a physical part of B Register 一 CashDrawer

A is a logical part of B SalesLinteItem 一 Sale

A is physically contained in/on B Register 一 StoreItem 一 Store

A is logically contained in B ProductSpecification 一 ProductCatalogProductCatalog 一 Item

A is a description for B ProductSpecification 一 Item

A is a line item of a transaction or report B SalesLinteItem 一 Sale

A is logged/recorded/reported/captured in B (completed)Sales 一 Store(current) Sale 一 Register

A is a member of B Cashier 一 Store

A is an organizational subunit of B Not applicable

A uses or manages B Cashier 一 RegisterManager 一 Register

A communicates with B Customer 一 Cashier

A is related to a transaction B Customer 一 PaymentCashier 一 Payment

Representing Generalization

Generalization Abstraction of common features among multiple

classes, as well as their relationships, into a more general class

Subclass A class that has been generalized

Superclass A class that is composed of several generalized

subclasses

A.24A.24

Representing Generalization (continued)

Discriminator Shows which property of an object class is being

abstracted by a generalization relationshipInheritance A property that a subclass inherits the features

from its superclassAbstract Class A class that has no direct instances but whose

descendents may have direct instancesConcrete Class A class that can have direct instances

A.25A.25

A.26A.26

Representing AggregationAggregation A part-of relationship between a

component object and an aggregate object Example: Personal computer

Composed of CPU, Monitor, Keyboard, etc

A.27A.27

Dynamic Modeling:State Diagrams

State A condition during the life of an object during which it

satisfies some conditions, performs some actions or waits for some events

Shown as a rectangle with rounded corners

State Transition The changes in the attributes of an object or in the links an

object has with other objects Shown as a solid arrow Diagrammed with a guard condition and action

Event Something that takes place at a certain point in time

A.28A.28

A.29A.29

Finding and Identifying the Business Objects

1. Find the Potential Objects Use a conceptual class category list Review each use case to find nouns that

correspond to business entities or events.

2. Select the Proposed Objects Not all nouns represent business objects.

Is it a synonym of another object? Is it outside the scope of the system? Is it a role without unique behavior, or an external

role? Is it unclear or in need of focus? Is it an action or an attribute that describes another

object?

Use a conceptual class category list

Category Examples

Physical or tangible objects Register, Airplane

Specifications,designs,or descriptions of things

Product Specification, FlightDescription

Places Store,Airport

Transactions Sale,Payment,Reservation

Roles of people Cashier,Pilot

Containers of other things Store,Airplane

Thing in a container Item,Passenger

Other computer or electro-mechanical systems external to the system

CreditPaymentAuthorizationSystem,AirTrafficControl

Abstract noun concepts Hunger,Acrophobia

Organizations SaleDepartment,ObjectAirline

……………….. ……………….

Partial Use-Case with Nouns Highlighted

DESCRIPTION: This use case describes the event of a member submitting a new order for SoundStage products via the world wide web. The member selects the items they wish to purchase. Once they have completed their shopping, the member’s demographic information as well as their account standing will be validated. Once the products are verified as being in stock, a packing order is sent to the distribution center for them to prepare the shipment. For any product not in stock, a back order is created. On completion, the member will be sent an order confirmation.

PRE-CONDITION: The individual submitting the order must be an active club member. The member must login in to the system (provide identification) to enter an order.

TRIGGER: This use case is initiated when the member selects the option to enter a new order. TYPICAL COURSE Actor Action System Response OF EVENTS: Step 1: The member requests the

option to enter a new order. Step 2: The system responds by displaying the catalogue of the SoundStage products.

Step 3: The Member browses the available items and selects the ones they wish to purchase along with the quantity.

Step 4: Once the member has completed their selections the system retrieves from file and presents the member’s demographic information (shipping and billing addresses).

Step 5: The member verifies demographic information (shipping and billing addresses). If no changes are necessary they respond accordingly (to continue).

Step 6: For each product ordered, the system verifies the product availability and determines an expected ship date, determines the price to be charged to the member, and determines the cost of the total order. If an item is not immediately available it indicates that the product is backordered or that it has not been released for shipping (for pre-orders). If an item is no longer available that is indicated also. The system then displays a summary of the order to the member for verification.

Step 7: The member verifies the order. If no changes are necessary they respond accordingly (to continue).

Step 8: The system checks the status of the member’s account. If satisfactory, the system prompts the member to select the desired payment option (to be billed later or pay immediately with a credit card).

Potential Object List

Cleaning Up List of Candidate Objects

Proposed Object List

Dynamic Modeling:Sequence Diagrams

Sequence Diagram A depiction of the interaction among objects during

certain periods of time

Activation The time period during which an object performs

an operation

Messages Means by which objects communicate with each

other

A.36A.36

Dynamic Modeling:Sequence Diagrams (continued)

Synchronous Message A type of message in which the caller has

to wait for the receiving object to finish executing the called operation before it can resume execution itself

Simple Message A message that transfers control from the

sender to the recipient without describing the details of the communication

A.37A.37

A.38A.38

Dynamic Modeling: Activity Diagram

Activity diagram – a diagram that can be used to graphically depict the flow of a business process, the steps of a use case, or the logic of an object behavior (method).

Activity Diagram Notations1. Initial node - solid circle

representing the start of the process.

2. Actions – rounded rectangles representing individual steps. The sequence of actions make up the total activity shown by the diagram.

3. Flow - arrows on the diagram indicating the progression through the actions. Most flows do not need words to identify them unless coming out of decisions.

4. Decision - diamond shapes with one flow coming in and two or more flows going out. The flows coming out are marked to indicate the conditions.

5. Merge - diamond shapes with multiple flows coming in and one flow going out. This combines flows previously separated by decisions. Processing continues with any one flow coming into the merge.

Activity Diagram Notations (cont.)

6. Fork – a black bar with one flow coming in and two or more flows going out. Actions on parallel flows beneath the fork can occur in any order or concurrently.

7. Join – a black bar with two or more flows coming in and one flow going out, noting the end of concurrent processing. All actions coming into the join must be completed before processing continues.

8. Activity final – the solid circle inside the hollow circle representing the end of the process.

Activity Diagram with Partitions

9. Subactivity indicator – the rake symbol in an action indicates that this action is broken out in another separate activity diagram. This helps you keep the activity diagram from becoming overly complex.

10.Connector – A letter inside a circle gives you another tool for managing complexity. A flow coming into a connector jumps to the flow coming out of a connector with a matching letter.

Guidelines for Constructing Activity Diagrams

Start with one initial node as a starting point.Add partitions if it is relevant to your analysis.Add an action for each major step of the use case (or each major step an actor initiates.Add flows from each action to another action, a decision point, or an end point. For maximum precision of meaning, each action should have only one flow coming in and one flow going out with all forks, joins, decisions, and merges shown explicitly.Add decisions where flows diverge with alternating routes. Be sure to bring them back together with a merge.Add forks and joins where activities are performed in parallel.End with a single notation for activity final.

Moving to DesignStart with existing set of analysis modelProgressively add technical detailsDesign model must be more detailed than analysis modelComponent Diagram A diagram that shows the software components or

modules and their dependencies

Deployment Diagram A diagram that shows how the software

components, processes and objects are deployed into the physical architecture of the system

A.44A.44

A.45A.45