Presentation is loading. Please wait.

Presentation is loading. Please wait.

Object-Oriented Analysis

Similar presentations

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

1 Object-Oriented Analysis

2 Traditional and OO Approach

3 Object -Oriented = Object + Class + Inheritance
Object-orientation is an engineering principle used to create a representation of the real-world problem domain and to map it into a software solution domain

4 Object-Oriented Concepts
Figure 11.7 OO Summary: Object Characteristics 25

5 Object An object is an abstract representation of a real-world entity that has a unique identity, embedded properties, and the ability to interact with other objects and itself. In object -oriented approach, any real-world entity must be uniformly modeled as an object Examples of object: user, account, machine, window, mouse, game character…

6 Object Each object consists of three parts:
Object identifier -- uniquely identifies the object State (Properties) -- Set of values specifying the attributes of the object Behavior (Methods) -- The set of methods (program code) that operate on the state of the object


8 Object Identifier (OID)
Objects can have a unique identity (OID) independent of the values that they contain Is not the same as key Automatically created by the system References an object elsewhere: in association with another object or in an application program Usually is not visible to user Improves efficiency of access

9 Attributes Objects are described by their attributes, referred to as Instance variables Each attribute has a unique name and a data type associated to it. Base or conventional data type (real, integer, ..etc), Abstract data type (ADT). Object attributes may reference one or more other objects At the implementation level, the OID of the referenced object is used to link both objects

10 An example of Object Oriented Approach
Account Owner Name Address Account owned -Open Account request -Close Account -Found transfer Account Account number Account owner Balance Rate -Deposit -Withdraw -Check Saving account Super class: Account -Check Error message to Account Owner Bonus Savings Super class: Savings Period Deposit date -Withdraw Check maturity Checking account Super class: Account

11 Methods Every operation to be performed on an object must be implemented by a method Methods are used to change the object’s attribute values or to return the value of selected object attributes Methods represent the object’s behavior Every method is identified by a name and has a body

12 Message Objects, classes and their instances communicate with each other by message passing. The state and behavior encapsulated in an object can only be accessed or invoked from outside the object through an explicit message. The ability to hide the object’s internal details (attributes and methods) is known as encapsulation

13 An example of Object Oriented Approach
Account Owner Name Address Account owned -Open Account request -Close Account -Found transfer Account Account number Account owner Balance Rate -Deposit -Withdraw -Check Saving account Super class: Account -Check Error message to Account Owner Bonus Savings Super class: Savings Period Deposit date -Withdraw Check maturity Checking account Super class: Account

14 Practice: A fitness center service system

15 Identify the Classes in a fitness center
Name ? Attributes ? Methods ?




19 Class A class is a collection of similar objects with shared structure (attributes ) and behavior (methods). The class defines the attributes and procedures; the objects are the instances of the class definition The domain (type) of a class’ attribute can be a class in itself.

20 Class Hierarchy Class hierarchy (“is a” relation) -- All the classes must be organized into a rooted directed acyclic graph or a hierarchy A class inherits all the attributes and methods from its immediate and remote ancestors


22 Class Hierarchy The class hierarchy must be dynamically extensible; that is, new sub-classes can be derived from one or more existing classes (allow more than one superclasses) Class-composition hierarchy (“has” relation) -- The aggregation relationship between a class and its attributes (the domain of an attribute can be a class)

23 Inheritance Inheritance is the innate ability of an object within the hierarchy to inherit the data structure and behavior of the classes above it. It is through inheritance that OO system can deliver code reusability

24 An example of Object Oriented Approach – Class Hierarchy
Account Account number Account owner Balance Rate -Deposit -Withdraw -Check Saving account Super class: Account -Check Error message to Account Owner Bonus Savings Super class: Savings Period Deposit date -Withdraw Check maturity Checking account Super class: Account

25 The Essence of Object-Orientation
Classification -- The ability to group associated objects according to common properties. Encapsulation -- The grouping together of various properties associated with an identifiable entity (the object) to which access is restricted by a well-defined interface. Flexible sharing -- The ability for an object to belong to more than one classification. Interpretation -- The resolution of the precise semantics of the shared item of behavior (Polymorphism)


27 UML: Object-Oriented Modeling Standard
Object-oriented modeling notation is Unified Modeling Language (UML 2.0) UML was accepted by Object Management Group (OMG) as standard modeling technique Purpose of Object Management Group Promote theory and practice of object-oriented technology for development of distributed systems Provide common architectural framework for OO


29 http://atlas. kennesaw. edu/~dbraun/csis4650/A&D/UML_tutorial/index

30 UML Diagrams


32 Object-Oriented Requirements Modeling
Object-oriented system requirements are specified and documented through process of building models Modeling process starts with identification of use cases and problem domain classes (things in users’ work environment) Business events trigger elementary business processes (EBP) that new system must address as use cases Use cases define functional requirements

33 Traditional and OO Approach

34 Relationships Between OO Requirements Models

35 The Class Diagram Domain model class diagram Design class diagram
Models things in the users’ work domain Used to define requirements for OO (very similar to entities in ERD) Design class diagram Models software classes Adds methods as behaviors Used in the design activity

36 UML Class Symbol

37 Multiplicity of Associations



40 Expanded Course Enrollment Design Class Diagram

41 Object-Oriented Requirements Models
Use case diagrams – identify actors and their use cases (goals) Use case descriptions – include details of a use case and how actors use the system Systems sequence diagrams (SSDs) – define inputs and outputs and sequence of interactions between user and system for a use case Activity diagrams – describe user and system activities for a use case State machine diagrams – describe states of each object

42 The System Activities— A Use Case/Scenario View
Use case analysis used to identify and define all business processes that system must support Use case – an activity a system carried out, usually in response to a user request Actor Role played by user Outside automation boundary

43 Simple Use Case with an Actor


45 Techniques for Identifying Use Cases
Identify user goals Each goal at the elementary business process (EBP) level is a use case EBP – task performed by one user in one place and in response to business event that adds measurable business value, and leaves system and data in consistent state Event decomposition technique (event table) CRUD analysis technique (create, read/report, update, delete) to ensure coverage

46 Information about Each Event in an Event Table

47 Use Case Diagram Graphical UML diagram that summarizes information about actors and use cases Simple diagram shows overview of functional requirements Can have multiple use case diagrams By subsystem By actor

48 Use Case Diagram with Automation Boundary and Alternate Actor Notation

49 Use Cases of an Order Entry Subsystem

50 <<Includes>> Relationship
Documents situation in which one use case requires the services of a common subroutine Another use case is developed for this common subroutine A common use case can be reused by multiple use cases

51 Example of Order-Entry Subsystem with <<Includes>> Use Cases



54 CRUD Analysis for Identifying/Confirming Use Cases
CRUD – create, read/report, update, delete Information Engineering (IE) technique to identify event table or directly develop use case diagram Compares identified use cases with domain model class diagram Every class in class diagram must have use cases to support creating, reading, reporting, updating, and deleting object instances Confirms system integration requirements

55 Use Case Description Use case description provides details of preconditions, postconditions, sequence of activities, and exception conditions in use case Describes actor interacting with computer system step-by-step to carry out business activity May have several scenarios for a use case, each a specific use case instance Three levels of detail: brief, intermediate, and fully developed description Many analysts prefer to write narrative descriptions of use cases instead of drawing activity diagrams

56 Brief Description of Create New Order Use Case

57 Use Case Description Components
Use case name/scenario name Actors/stakeholders Related use cases Preconditions – set of criteria that must be true prior to initiation of the use case Postconditions – set of criteria that must be true upon completion of the use case Flow of activities (steps in one column or two) Exception conditions

58 Fully Developed Use Case Description

59 Practice Describe a use case of searching house

60 Activity Diagrams Used to document workflow of business process activities for each use case or scenario Can support any level of use case description; a supplement to use case descriptions Helpful in developing system sequence diagrams


62 Activity Diagram: Telephone Order Scenario

63 Activity Diagram: Web Order Scenario

64 Practice Draw a activity diagram for a landlord register and enter housing advertisement.

65 Identifying Inputs and Outputs— The System Sequence Diagram
System sequence diagram (SSD) is type of UML 2.0 interaction diagram Used to model input and output messaging requirements for a use case or scenario Shows actor interacting with system Shows sequence of interactions as messages during flow of activities System is shown as one object: a “black box”

66 Sequence Diagram

67 System Sequence Diagram (SSD) Notation

68 Repeating Message

69 Developing a System Sequence Diagram
Begin with detailed description of use case from fully developed form or activity diagram Identify input messages Describe message from external actor to system using message notation Identify and add any special conditions on input message, including iteration and true/false conditions Identify and add output return messages

70 Activity Diagram and Resulting SSD for Telephone Order Scenario

71 SSD of the Web Order Scenario for the Create New Order Use Case

72 Identifying Object Behavior— The State Machine Diagram
State machine diagram is UML 2.0 diagram that models object states and transitions Complex problem domain classes can be modeled State of an object A condition that occurs during its life when it satisfies some criterion, performs some action, or waits for an event Each state has unique name and is a semipermanent condition or status Transition The movement of an object from one state to another state

73 Simple State Machine Diagram for a Printer

74 State Machine Diagram is also called as State Transition Diagram

75 State Machine Terminology
Pseudo state – the starting point of a state machine, indicated by a black dot Origin state – the original state of an object from which the transition occurs Destination state – the state to which an object moves after the completion of a transition Message event – the trigger for a transition, which causes the object to leave the origin state Guard condition – a true/false test to see whether a transition can fire Action expression – a description of the activities performed as part of a transition

76 State Machine Diagram for OrderItem Problem Domain Class

77 Rules for Developing State Machine Diagram
Review domain class diagram, select important ones, and list all state and exit conditions Begin building state machine diagram fragments for each class Sequence fragments in correct order and review for independent and concurrent paths Expand each transition with message event, guard-condition, and action-expression Review and test each state machine diagram

78 First-Cut State Machine Diagram for Order

79 Second-Cut State Machine Diagram for Order


81 Integrating Object-Oriented Models
Complete use case diagram is needed to understand total scope of new system Domain model class diagrams should also be as complete as possible for entire system With iterative approach, only construct use case descriptions, activity diagrams, and system sequence diagrams for use cases in iteration Development of a new diagram often helps refine and correct previous diagrams

82 Summary Object-oriented approach has complete set of diagrams that define system requirements Requirements specified using following models Domain model class diagram Use case diagrams Use case detailed models, either descriptive formats or activity diagrams System sequence diagrams State machine diagrams

Download ppt "Object-Oriented Analysis"

Similar presentations

Ads by Google