+ All Categories
Home > Documents > MELJUN CORTES SAD ch18

MELJUN CORTES SAD ch18

Date post: 18-Oct-2014
Category:
View: 492 times
Download: 4 times
Share this document with a friend
Description:
MELJUN CORTES SAD ch18
74
Chapter 18 Object-Oriented Systems Analysis and Design Using UML Systems Analysis and Design MELJUN CORTES MELJUN CORTES
Transcript
Page 1: MELJUN CORTES SAD ch18

Chapter 18Object-Oriented SystemsAnalysis and Design Using UML

Systems Analysis and Design

MELJUN CORTESMELJUN CORTES

Page 2: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-2

Major Topics•Object-oriented concepts and

terminology•CRC Cards•Unified Modeling Language•Use case and other UML diagrams•Relationships

Page 3: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-3

Object-Oriented Overview•Object-oriented (o-o) techniques

work well in situations where complicated systems are undergoing continuous maintenance, adaptation, and design.

•The Unified Modeling Language (UML) is an industry standard for modeling object-oriented systems.

Page 4: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-4

Goals of O-O Analysis•Reusability is the main goal.•Maintaining systems is an

important goal.•Making a change in one object has a

minimal impact on other objects.

Page 5: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-5

Object-Oriented Concepts Definitions and concepts:

•An object, represents a real-world thing or event.

•Objects may be customers, items, orders and so on.

•Objects may be GUI displays or text areas on a display.

Page 6: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-6

Object-Oriented Concepts Definitions and concepts (continued):

• Objects are represented by and grouped into classes.

• A class, or group of related objects has a set of shared attributes and behaviors.• Instantiate is a term used when an object is

created from a class.•Attributes are properties of a class possessed by

all objects.•A method is an action that can be requested from

any object in the class.

Page 7: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-7

Class Symbol

Page 8: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-8

Inheritance• Inheritance is when a new class is

created from another class.•The original class is the parent or

base class.•The new class is the child or derived

class.•The child class receives the

attributes and methods of the parent class.

Page 9: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-9

CRC Cards Class, responsibilities, and

collaborators (CRC) cards are used to represent the responsibilities of classes and the interaction between the classes.

Page 10: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-10

Creating CRC Cards Analysts create CRC cards by:

•Finding all the nouns and verbs in a problem statement.

•Creating scenarios that are actually walkthroughs of system functions.

•Identifying and refining responsibilities into smaller and smaller tasks, if possible.

Page 11: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-11

Creating CRC Cards Analysts create CRC cards by

(continued):•Determining how tasks are fulfilled by

objects or interact with other things.•Identifying responsibilities that evolve

into methods or operations.

Page 12: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-12

The Unified Modeling Language (UML) UML has three categories:

•Things, the objects.•Relationships, the glue that holds

things together.•Diagrams, categorized as either

structure or behavioral.

Page 13: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-13

Two General Groupings of Things There are two general groupings of

things in UML:• Structural things that define the conceptual

and physical structures of an O-O system and are described by nouns.

• Behavioral things, the verbs of a UML model that represent the behavior of the system and the states of the system before, during, and after the behaviors occur.

Page 14: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-14

Structural Things Structural things are the most

common and include:•Classes. •Use cases.•Interfaces.

Page 15: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-15

Behavioral Things/Diagrams Behavioral things include:

•Interactions.•State machines.

Page 16: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-16

Types of Relationships There are two types of

relationships that hold things together:•Structural relationships tie things

together in structural diagrams.•Behavioral relationship are used in

behavioral diagrams.

Page 17: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-17

Structural Relationships Structural relationships are:

•Dependencies.•Aggregations.•Associations.•Generalizations.

Page 18: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-18

Behavioral Relationships•Behavioral relationships are:

•Communicates.•Includes.•Extends.•Generalizes.

Page 19: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-19

Structural Diagrams Structural things are the most

common and include:•Class and object diagrams.•Use case diagrams.•Component diagrams.•Deployment diagrams.

Page 20: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-20

Behavioral Things/Diagrams Behavioral things include:

•Use case diagrams.•Sequence diagrams.•Collaboration diagrams.•Statechart diagrams.•Activity diagrams.

Page 21: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-21

Commonly Used UML Diagrams

The most commonly used UML diagrams are:•Use case diagram, describing how the

system is used.•The starting point for UML modeling.

•Use case (not a diagram).•Activity diagram.

•Each use case may create one activity diagram.

Page 22: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-22

Commonly Used UML Diagrams

The most commonly used UML diagrams (continued):

•Sequence diagram, showing the sequence of activities and class relationships.•Each use case may create one or more

sequence diagrams.•A collaboration diagram is an alternative

to a sequence diagram.

Page 23: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-23

Commonly Used UML Diagrams

The most commonly used UML diagrams (continued):

•Class diagram, showing classes and relationships.•Sequence diagrams and CRC cards are

used to determine classes.•Statechart diagram.

•Each class may create a statechart diagram, useful for determining class methods.

Page 24: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-24

Overview of UML Diagrams

Page 25: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-25

Use Case Diagram• A use (yoos) case describes what the

system does, not how it does the work.• The use case model reflects the view of

the system of the user outside of the system.

• Symbols are:• Actor, a stick figure.• Use case, an oval.• Connecting lines.

Page 26: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-26

Actors• Represent role played by one or more users• Exist outside of the system• May be a person, another system, a device,

such as a keyboard or Web connection• Can initiate an instance of a use case• May interact with one or more use cases

and a use case may involve one or more actors

Page 27: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-27

Actors (Continued)•Actors may be divided into two

groups:•Primary actors supply data or receive

information from the system•Secondary actors help to keep the

system running or provide help•Help desk, analysts, programmers, etc.

Page 28: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-28

Use Case•Consists of three things:

•An actor (user) that initiates an event.•An event that triggers a use case.•The use case that performs the

actions triggered by the event.

Page 29: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-29

Use Case (Continued)•Better to create fewer use cases•20 use cases for a large system•50 use cases would be the

maximum for a large system•Can nest use cases, if needed

Page 30: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-30

Use Case Relationships•Communicates

•Connect an actor to a use case• Includes

•Use case contains a behavior that is common to more than one use case.

•The common use case is included in other use cases.

•Dotted arrow points toward common use case.

Page 31: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-31

Use Case Relationships (Continued)•Extends

•A different use case handles variations or exceptions from the basic use case.

•Arrow goes from extended to basic use case.

•Generalizes•One thing is more general than

another thing.•Arrow points to the general thing.

Page 32: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-32

Use Case Relationships

Page 33: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-33

Steps for Creating a Use Case Model The steps required to create a use

case model are:•Review the business specifications and

identify the actors within the problem domain.

•Identify the high-level events and develop the primary use cases that describe the events and how actors initiate them.

Page 34: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-34

Steps for Creating a Use Case Model•The steps required to create a use

case model are (continued): •Review each primary use case to

determine possible variations of flow through the use case.

•Develop the use case documents for all primary use cases and all important use case scenarios.

Page 35: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-35

Use Case Scenario•A use case scenario may be created

for the standard flow through the use case.

•Other scenarios may be created for variations on the main flow.

•A use case includes:•Use case identifiers and initiators.•Steps performed.•Conditions, assumptions, and questions.

Page 36: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-36

Activity Diagrams•Activity diagrams show the

sequence of activities in a process, including sequential and parallel activities.

•Symbols are used for activities, decisions and so on.

•Arrows represent events that connect the activities.

Page 37: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-37

Activity Diagram Symbols

Page 38: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-38

Creating Activity Diagrams•Ask what happens first, second,

and so on.•Determine if the activities happen

in sequence or parallel.•Examine all the scenarios for a use

case.

Page 39: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-39

Swimlanes• Included on activity diagrams to show

partitioning• Show which activities:

• Occur on a browser• Occur on a server• Happen on a mainframe• Are done by external partners

• Help to divide tasks among team members

Page 40: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-40

Swimlane Boundaries When an event crosses swimlane

boundaries, data must be transmitted.•A Web form is sent to a server.•Data are placed into middleware to

transmit it between a server and a mainframe.

•Data are transmitted to and from an external partner.

Page 41: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-41

Sequence Diagrams•Sequence diagrams show a

succession of interactions between classes or object instances over time.

• It also shows the processing described in a single scenario.

•The leftmost object is the starting object.

•Time sequence is from top to bottom.

Page 42: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-42

Sequence Diagrams (Continued)•Horizontal arrows represent

messages or signals sent between classes.•Solid arrowheads represent

synchronous calls, the sending class waits for a response.

•Half or open arrowheads represent asynchronous calls, those sent without waiting for a returning signal.

Page 43: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-43

Message Name Formats Message names may be in the

following formats:

messageName()messageName(parameter1, parameter2, …)messageName(parameterType:parameterName)

(defaultValue)

Page 44: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-44

Sequence Diagram Example

Page 45: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-45

Collaboration Diagrams•Collaboration Diagrams show the

same information as a sequence diagram.

•The emphasis is on the organization of the objects.

•Sequence is shown by including a sequence number on the message.

Page 46: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-46

Collaboration Diagram Example

Page 47: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-47

Class Diagrams•Class diagrams show classes,

attributes, and operations or methods.

•A class is shown as a rectangle.

Page 48: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-48

Class Diagram Attributes•Attributes are either:

•Private (the norm), indicated by a minus sign.

•Public, indicated by a plus sign.•Protected, indicated by a pound sign (#).•Attributes may include the type of data

and any initial value.•Methods are usually public.

Page 49: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-49

Method Overloading•Method overloading is including

the same method several times in a class.

•The method signature, its name and parameters, and type of parameters, must be different.

Page 50: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-50

Types of Classes•Classes fall into several categories:

•Entity classes.•Boundary or interface classes.•Abstract classes.•Control classes.

•Each class may use a special symbol, called a UML stereotype.

Page 51: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-51

Entity Classes•Entity classes represent real-world

items.•Attributes are those stored for the

entity.•Methods work with the entity.

Page 52: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-52

Boundary or Interface Classes•Provide a means for users to work

with the system.•Display screens, windows, dialogue

boxes, touch-tone telephone, external systems.

•Methods required to send or reset the display screen, or to produce a report.

Page 53: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-53

Abstract Classes•Abstract classes are the parent or

general class in a generalization/specialization relationship.

•Abstract classes may not be directly instantiated.

•Only the child classes can create objects.

Page 54: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-54

Control or Active Classes•Control or active classes are used

to control the flow of activities.•Many small control classes may be

included to achieve reuse.•Attributes are those needed

temporarily by the control class.•Methods are those used in control

activities .

Page 55: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-55

Sequence Diagram Example Using Class Stereotype Symbols

Page 56: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-56

Relationships on a Class Diagram

•Relationships are the connections between classes and include:•Associations, showing the one-to-

many relationships between classes.•An asterisk (*) is used to represent many.

•Association classes are used to break up a many-to-many association between classes.

Page 57: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-57

Association Class Example

Page 58: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-58

Whole/Part Relationships•One class represents the whole,

other classes represent the parts contained in the whole.

•Three types of whole/part relationships:•Aggregation.•Collection.•Composition.

Page 59: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-59

Aggregation•Aggregation is a “has a” relationship.•The whole is composed of the sum of

the parts.• If the whole is removed, the part

may still exist.•The diamond at the end of the line is

not filled in.

Page 60: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-60

Collection•Consists of a whole and its

members•Examples are a library with books

or a voting district with voters• If the part is removed, the whole

retains its identity•A weak association

Page 61: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-61

Composition•The whole has a responsibility for the

parts, and is a stronger relationship.• If the whole is removed, the parts are

removed•Shown with a filled-in diamond on the

line•Example: an insurance policy with

riders

Page 62: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-62

Whole/Part Example

Page 63: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-63

Generalization/Specialization Diagrams• Generalization/specialization or gen/spec

diagrams show the relationship between a more general thing and a specific kind of thing.

• This relationship is described as an “is a” relationship.

• For example: a car is a vehicle, a truck is a vehicle.

• Generalization relationship is used to model inheritance.

• General class is a parent, base, or superclass.• Specialized class is a child, derived, or subclass.

Page 64: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-64

Polymorphism•Polymorphism or method overriding is

when a method is defined in several classes in a gen/spec relationship.

•The subclass overrides the parent class attributes and/or methods.

• If a number of classes are involved, the most specific class is used.

Page 65: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-65

Gen/Spec Example

Page 66: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-66

Finding Classes Classes may be discovered:

•During interviews or JAD sessions.•During brainstorming sessions.•By using CRC cards.•By examining use cases, looking for

nouns.•Each noun may lead to a candidate or

potential class.

Page 67: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-67

Determining Class Methods Class methods may be determined

by:•Using a CRUD matrix.•Looking at messages sent between

classes.•The receiving class must have the

message name as a method.•Using statechart diagrams.

Page 68: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-68

Statechart Diagrams• Statechart diagrams show class states

and the events that cause them to transition between states.

• It is also called a state transition diagram• An event happens at a specific time and

place.• They cause a change of state, or the

transition “fires”

Page 69: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-69

Statechart Diagrams (Continued)•Each time an object changes state,

some of its attributes must change.

•There must be a method to change the attributes.

•Often there is a display screen or Web form to enter the attributes.

Page 70: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-70

Statechart Diagrams (Continued)• Statechart diagrams are not created for all

classes.• They are created when:

• A class has a complex life cycle.• An instance of a class may update its attributes

in a number of ways through the life cycle.• A class has an operational life cycle.• Two classes depend on each other.• The object’s current behavior depends on what

happened previously.

Page 71: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-71

Statechart Example

Page 72: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-72

Packages•Containers for other UML things•Show system partitioning• Indicate which use cases or classes

are grouped into a subsystem•Can show component packages•Can be physical subsystems•Use a folder symbol

Page 73: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-73

Package Example

Page 74: MELJUN CORTES SAD ch18

Kendall & Kendall

© 2005 Pearson Prentice Hall 18-74

Steps Used in UML The steps used in UML are:

• Define the use case model.• Continue UML diagramming to model the

system. during the systems analysis phase.• Develop the class diagrams.• Draw statechart diagrams.• Begin systems design by refining the UML

diagrams.• Document your system design in detail.


Recommended