SYSTEMS ANALYSIS DESIGN PHASE 2 SYSTEMS ANALYSIS Object

SYSTEMS ANALYSIS & DESIGN PHASE 2 SYSTEMS ANALYSIS Object Modeling

Chapter 5 Object Modeling SYSTEMS ANALYSIS & DESIGN 4 E PHASE 2 2

Objectives PHASE 2 3 à Explain how object-oriented analysis can be used to describe an information system à Define object modeling terms and concepts, including objects, attributes, methods, messages, classes, and instances à Explain relationships among objects, including dependency, association, aggregation, and inheritance SYSTEMS ANALYSIS & DESIGN 4 E

Objectives PHASE 2 4 à Draw an object relationship diagram à Describe Unified Modeling Language (UML) tools and techniques, including use cases, use case diagrams, class diagrams, sequence diagrams, state transition diagrams, and activity diagrams SYSTEMS ANALYSIS & DESIGN 4 E

Objectives PHASE 2 5 à Explain the advantages of using CASE tools in developing the object model à Explain how to organize the object model SYSTEMS ANALYSIS & DESIGN 4 E

Introduction PHASE 2 6 à Chapter 5 covers object-oriented analysis à Document, analyze, and model the information system SYSTEMS ANALYSIS & DESIGN 4 E

PHASE 2 7 Object-Oriented Terms and Concepts à Object-oriented analysis is an approach that sees a system from the viewpoint of the objects themselves. à The end product is an object model à Overview à Use Unified Modeling Language (UML) to develop object models à Objects include data and the processes that affect the data à A class is a group of similar objects Click to see Figure 5 -1 SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 5 -2

PHASE 2 8 Object-Oriented Terms and Concepts à Objects à An object can represent a real person, place, event, or transaction à The UML represents an object as a rectangle with the object name on the top, followed by the object’s attributes and methods Click to see Figure 5 -3 Click to see Figure 5 -6 Click to see Figure 5 -4 Click to see Figure 5 -7 Click to see Figure 5 -5 Click to see Figure 5 -8 SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 5 -9

PHASE 2 9 Object-Oriented Terms and Concepts à Attributes are characteristics that describe the object à The number of attributes needed depends on the business requirements of the information system and its users à Attributes are designed during the systems design process à Objects can inherit, or acquire, attributes from other objects à The state of an object is an adjective that describes the object’s current status SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 5 -10

PHASE 2 10 Object-Oriented Terms and Concepts à Methods à A method defines specific tasks that an object can perform à Methods describe what and how an object does something à A constructor method creates a new instance of an object à An update method changes existing data à A query method provides information about an object’s attributes Click to see Figure 5 -11 SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 5 -12 Click to see Figure 5 -13

PHASE 2 11 Object-Oriented Terms and Concepts à Messages à A message is a command that tells an object to perform a certain method à Polymorphism is the concept that the same message to two different objects can produce different results à The black box concept is an example of encapsulation – all data and methods are selfcontained Click to see Figure 5 -14 Click to see Figure 5 -15 SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 5 -16

PHASE 2 12 Object-Oriented Terms and Concepts à Classes à An object belongs to a group or category called a class à Objects within a class can be grouped into subclasses à A class can belong to a more general category called a superclass Click to see Figure 5 -17 Click to see Figure 5 -18 SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 5 -19

Relationships Among Objects and Classes PHASE 2 13 à Relationships enable objects to communicate and interact à Relationships describe what objects need to know about each other à Types of relationships à Dependency à Association à Aggregation à Inheritance SYSTEMS ANALYSIS & DESIGN 4 E

Relationships Among Objects and Classes PHASE 2 14 à Dependency à Occurs when one object must be informed about another SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 5 -20

Relationships Among Objects and Classes PHASE 2 15 à Dependency à Occurs when one object must be informed about another à Association à Stronger than dependency and occurs when certain attributes of one object are determined by its interaction with another object SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 5 -21

Relationships Among Objects and Classes PHASE 2 16 à Dependency à Occurs when one object must be informed about another à Association à Stronger than dependency and occurs when certain attributes of one object are determined by its interaction with another object à Aggregation à Exists when an object forms part of another object SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 5 -22

Relationships Among Objects and Classes PHASE 2 17 à Dependency à Occurs when one object must be informed about another à Association à Stronger than dependency and occurs when certain attributes of one object are determined by its interaction with another object à Aggregation à Exists when an object forms part of another object à Inheritance à Enables an object to derive one of more of its attributes from another object SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 5 -23

Relationships Among Objects and Classes PHASE 2 18 à Object relationship diagram à Provides an overview of the system à Used as a guide to develop additional diagrams and documentation SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 5 -24

Object Modeling with the Unified Modeling Language PHASE 2 19 à Systems analysts use UML to describe object-oriented systems à Uses symbols to represent graphically the various components and relationships within a system à Mainly used to support object-oriented system analysis and to develop object models à Object Management Group adopted the UML as an object modeling standard SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 5 -25

Object Modeling with the Unified Modeling Language PHASE 2 20 à Use case modeling à Use case represents the steps in a specific business function or process à An actor (external entity) initiates a use case by requesting the system to perform a function or process à Use cases can interact with other use cases à A use case description is developed for each use case Click to see Figure 5 -27 SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 5 -28 Click to see Figure 5 -29

Object Modeling with the Unified Modeling Language PHASE 2 21 à Use case diagrams à Visual summary of several related use cases within a system à System boundary shows what is included in the system and what is not included in the system à Use cases can interact with other use cases à A use case description is developed for each use case Click to see Figure 5 -30 Click to see Figure 5 -32 Click to see Figure 5 -31 Click to see Figure 5 -33 SYSTEMS ANALYSIS & DESIGN 4 E

Object Modeling with the Unified Modeling Language PHASE 2 22 à Class diagrams à Represents a detailed view of a single use case à A class diagram is a logical model, which evolves into a physical model and finally becomes a functioning information system à Cardinality describes how instances of one class relate to instances of another class Click to see Figure 5 -34 Click to see Figure 5 -35 Click to see Figure 5 -36 SYSTEMS ANALYSIS & DESIGN 4 E

Object Modeling with the Unified Modeling Language PHASE 2 23 à Sequence diagrams à Dynamic model of a use case à Shows the interaction among classes during a specified time period à Includes symbols that represent classes, lifelines, messages, and focuses Click to see Figure 5 -37 Click to see Figure 5 -38 Click to see Figure 5 -39 SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 5 -40

Object Modeling with the Unified Modeling Language PHASE 2 24 à State transition diagrams à Shows how an object changes from one state to another à All possible states must be documented in the state transition diagram à Includes symbols that represent classes, lifelines, messages, and focuses Click to see Figure 5 -41 SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 5 -42

Object Modeling with the Unified Modeling Language PHASE 2 25 à Activity diagrams à Shows the order in which actions take place and identifies the outcome à Can display multiple use cases in the form of a grid SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 5 -43

Object Modeling with the Unified Modeling Language PHASE 2 26 à CASE tools à Speed up the diagram process à Provide a framework for documenting the system components à Ensure consistency and provide common links à System Architect 2001 is example of a CASE tool SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 5 -44

Organizing the Object Model PHASE 2 27 à Organize use cases and use case diagrams so they can be linked to the appropriate class, state transition, sequence, and activity diagrams à Much easier to prepare a diagram now than to change the software later SYSTEMS ANALYSIS & DESIGN 4 E

SOFTWEAR, LIMITED PHASE 2 28 à Rick and Carla completed a set of DFDs à Rick suggests that he and Carla experiment with object-oriented analysis à Classes àRick and Carla identified the people, events, and transactions that they would represent as classes àDefined attributes àWill include department heads as a subclass of SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 5 -45

SOFTWEAR, LIMITED PHASE 2 29 à Use cases à Rick and Carla defined EMPLOYEE and PAYROLL ACTION use cases à Identified the actors involved in each use case à Created a description for each use case à Created a use case diagram documenting an employee contribution change à Created a use case describing how payroll is generated Click to see Figure 5 -46 Click to see Figure 5 -48 Click to see Figure 5 -47 SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 5 -49

SOFTWEAR, LIMITED PHASE 2 30 à Class diagrams à Carla suggested class diagrams for each use case à Started with GENERATE PAYROLL SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 5 -50

SOFTWEAR, LIMITED PHASE 2 31 à Sequence diagrams à They completed a sequence diagram for the CHANGE CONTRIBUTIONS method in the EMPLOYEE object SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 5 -51

SOFTWEAR, LIMITED PHASE 2 32 à State transition diagrams à Rick explained the principle behind state transition diagrams à Created state transition diagram for changes in employee status caused by actions or events SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 5 -52

SOFTWEAR, LIMITED PHASE 2 33 à Activity diagrams à Rick suggests making an activity diagram showing various situations à The diagram showed the interaction between objects during certain scenarios à Packaged all diagrams in a folder and saved the overall object model for future reference SYSTEMS ANALYSIS & DESIGN 4 E Click to see Figure 5 -53

PHASE 2 34 End Chapter 5 SYSTEMS ANALYSIS & DESIGN 4 E