Systems Analysis and Design: Alan Dennis, Barbara Haley Wixom, and Roberta Roth John Wiley & Sons, Inc

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 53

Systems Analysis and Design

Alan Dennis, Barbara Haley Wixom, and Roberta Roth


John Wiley & Sons, Inc.

Slides by Candace S. Garrod


Red Rocks Community College
The Movement To Objects

Chapter 15
Key Definitions
Object-oriented techniques view a system as
a collection of self-contained objects which
include both data and processes.
The Unified Modeling Language (UML)
the object modeling standard
adds a variety of techniques to the field of
system development.
BASIC CHARACTERISTICS OF
OBJECT-ORIENTED SYSTEMS
Object Concepts
An object is a person, place, event, or thing about
which we want to capture information.
Each object has properties (or attributes).
The state of an object is defined by the value of its
properties and relations with other objects at a
point in time.
Objects have behaviors -- things that they can do
-- which are described by methods (or
operations).
Objects do not use primary or foreign keys, instead
each instance is assigned a unique identifier
Classes and Objects
Class

A class is a general template we use to


define and create specific instances or
objects.
Object

An object is an instantiation of a class.


An object is a person, place, event, or thing
about which we want to capture information.
Messages and Methods
Messages are information sent to objects to trigger
methods
Encapsulation and Information Hiding

Encapsulation is simply the combination of process


and data into a single entity.

The principle of information hiding suggests that


only the information required to use a software module
be published to the user of the module.
Inheritance

Classes are arranged in a hierarchy


Superclasses or general classes are at the top
Subclasses or specific classes are at the bottom
Subclasses inherit attributes and methods from
the superclasses above them
Classes with instances are concrete classes
Abstract classes only produce templates for
more specific classes
Class Hierarchy
Inheritance
Polymorphism and Encapsulation
Benefits of an Object Approach
Unified Modeling Language – UML

Defines a set of fourteen object diagramming


techniques
The key building block is the use case
Diagrams are tightly integrated syntactically
and conceptually to represent an integrated
whole
Application of UML can vary among
organizations
UML 2.0 Diagram Summary
Integration of four UML Diagrams
Adaptation of the Unified Process Phased
Development Methodology
USE CASE DIAGRAM
Use Case Diagram Concepts

Summarizes all use cases (for the part of the


system being modeled) together in one picture
Typically drawn early in the SDLC
Shows the associations between actors and use
cases
Use Case Diagram for Appointment System
Syntax for Use Case Diagram
Use Case Diagram for Specialized Actor
Extends and Includes Associations
Steps in Creating the Use Case Diagram
1. Identify Use Cases
2. Draw the system boundary
3. Place Use Cases on the diagram
Group Use Cases into packages
Add special Use Case associations
4. Identify the actors
5. Add associations
CLASS DIAGRAM
Elements of a Class Diagram
A static model that shows the classes and
relationships among classes that remain
constant in the system over time
Resembles the ERD, but depicts classes
which include both behaviors and states,
while entities in the ERD include only
attributes
Scope not system wide, but pertaining to a
single Use Case
Class Diagram for Manage Appointment
Class Diagram Syntax
Operation Types

Constructor operation: create new instances of a


class
Similar to relationships in ERDs
Multiplicity shows how an instance of an object
can be associated with other instances
Multiplicity
Steps in Creating a Class Diagram
1. Identify classes
2. Identify attributes and operations
3. Draw associations between classes
Initial Attributes for Class Diagrams
Revised Attributes and Associations
Final Class Diagram
SEQUENCE DIAGRAM
Sequence Diagram Concepts
Illustrates the classes that participate in a use case
Shows the messages that pass between classes
over time for one Use Case
Can be a generic sequence diagram, but more
frequently one is drawn for a single scenario
within the use case
Design diagrams are implementation specific --
database objects or specific GUI components serve
as classes
Sequence Diagram
Steps in Creating a Sequence Diagram
1. Identify classes
2. Add messages
3. Place lifeline and focus of control
Syntax for Sequence Diagram
Steps of the Customer Places Order Scenario
Sequence Diagram for Customer Places Order
Scenario
BEHAVIORAL STATE MACHINE
DIAGRAM
Behavioral State Machine Concepts
A dynamic model showing changes of state of a single
class over time in response to events along with its
responses and actions
Typically not used for all classes, but just to help
simplify the design of algorithms for methods of
complex classes
Behavioral State Machine Diagram for a
Hospital Patient
Behavioral State Machine Syntax
The Life of an Order
Steps for Creating a Behavioral State
Machine Diagram
1. Identify the states
2. Identify the transitions
Behavioral State Machine Diagram for a
Special Order
Summary
Many organizations are moving to the use
of object-oriented techniques
Objects are grouped into classes that share
common properties and methods and
arranged in a hierarchy
Objects communicate by sending messages
which trigger methods
Summary
Major object-oriented modeling techniques
include:
Use Case diagrams
Class diagrams
Sequence diagrams
Statechart diagrams
Copyright © 2006
John Wiley & Sons, Inc.
 All rights reserved. Reproduction or translation of this
work beyond that permitted in Section 117 of the 1976
United States Copyright Act without the express written
permission of the copyright owner is unlawful.
 Request for further information should be addressed to the
Permissions Department, John Wiley & Sons, Inc.
 The purchaser may make back-up copies for his/her own
use only and not for redistribution or resale.
 The Publisher assumes no responsibility for errors,
omissions, or damages, caused by the use of these
programs or from the use of the information contained
herein.

You might also like