chapter 1

Object-Oriented Analysis and Design

1. The Unified Modeling Language (UML) is a standard diagramming notation; sometimes referred to
as a blueprint.
It is NOT OOA/OOD or a method
Only a notation for capturing objects and the relationships among objects (dependency; inheritance; realizes;
aggregates.)

2. UML is language-independent
Analysis and design provide software “blueprints” captured in UML.
Blueprints serve as a tool for thought and as a form of communication with others.
But it is far more essential to ‘think’ in terms of objects as providing ‘services’ and accommodating
‘responsibilities.’

3. Object-Oriented Analysis (Overview)

An investigation of the problem (rather than how a solution is defined)
During OO analysis, there is an emphasis on finding and describing the objects (or concepts) in the problem
domain.
For example, concepts in a Library Information System include Book, and Library.
High level views found in the application domain.
Oftentimes called domain objects, entities.

4. Object-Oriented Design
Emphasizes a conceptual solution that fulfills the requirements.
Need to define software objects and how they collaborate to meet the requirements.
For example, in the Library Information System, a Book software object may have a title attribute and a get
Chapter method.
What are the methods needed to process the attributes?
Designs are implemented in a programming language.
In the example, we will have a Book class in Java.

Then too, there are sets of proven design solutions to problems that are considered ‘best practices.’
 – Certain ‘groupings’ of classes with specific responsibilities / interfaces.
– These provide specific solutions to specific problems.
– Called Design Patterns
We will discuss (much later) these standard patterns and how to apply them to develop solutions to common
design problems

Of course, design (solution to requirements) ‘assumes’ a robust requirements analysis has taken place.

Use Cases are often used to capture stories of requirements and are often views as ‘constituting’ the
functional requirements, but NOT the software quality factors (non-functional requirements).

Use Cases are not specifically designed to be object-oriented, but rather are meant to capture how an
application will be used.
Many methods for capturing requirements.
We will concentrate on Use Cases (ahead).

Basic Terms: Iterative, Evolutionary, and Agile

1. Introduction

• Iterative - the entire project will be composed of min-projects and will iterate the same activities
again and again (but on different part of the project AND with different emphases) until completion.
• Evolutionary (or incremental) - the software grows by increments (to be opposed to the
traditional, and somewhat old-fashioned, Waterfall model of software development).
• Agile - we will use a light approach to software development rather than a very rigid one (which may
be needed for a safety-critical system for example)
• This kind of approach seems better at treating software development as a (problem-solving activity);
also, the use of objects makes it amenable.
• We need a Requirements Analysis approach with OOA/OOD need to be practiced in a framework of a
development process.
• We will adopt an agile approach (light weight, flexible) in the context of the Unified Process, which can
be used as a sample iterative development process. Within this process, the principles can be
discussed.
• Please note that there are several other contexts that may be used, such as Scrum, XP, Feature-Driven
Development, Lean Development, Crystal Methods, and others…and we will look at a few of these.
2. What is the Unified Process?
• The UP is very flexible and open and can include other practices from other methods such as Extreme
Programming (XP) or Scrum for example.
– e.g. XP’s test-driven development, refactoring can fit within a UP project; So can Scrum’s daily
meeting.
– Being pragmatic in adapting a particular process to your needs is an important skill : all projects
are different.
We will be studying all the topics found in Fig. 1.1

The Rush to Code

• Critical ability to develop is to think in terms of objects and to artfully assign responsibilities to
software objects.
• Talk at great length in COP 3538 about encapsulation and assigning methods to objects where the data
is defined…
• One cannot design a solution if the requirements are not understood.
• One cannot implement the design if the design is faulty.
• Analysis: - investigate the problem and the requirements.
• What is needed? Required functions? Investigate domain objects.
• Problem Domain
• The What’s of a system.
• Do the right thing (analysis)
• Design:
• Conceptual solution that meets requirements.
• Not an implementation
• E.g. Describe a database schema and software objects.
• Avoid the CRUD activities and commonly understood functionality.
• The Solution Domain
• The ‘How’s’ of the system
• Do the thing right (design)
• OOA: we find and describe business objects or concepts in the problem domain
• OOD: we define how these software objects collaborate to meet the requirements. Attributes and
methods.
• OOP: Implementation: we implement the design objects in, say, Java, C++, C#, etc.
 chapter 2
Modern Systems Analysis and Design

Systems Acquisition: Outsourcing

 Outsourcing: Turning over responsibility of some or all an organization's information systems
applications and operations to an outside firm
 Outsourcing Examples
A company that runs payroll applications for clients
A company that runs your applications at your site
Reasons to outsource
 Cost-effective
 Take advantage of economies of scale
 Free up internal resources
 Reduce time to market
 Increase process efficiencies
 System development is a non-core activity for the organization

Sources of Software
 Information technology services firm
 Packaged software producers
 Enterprise-wide solutions
 Application service providers (ASPs)
 Open source software
 In-house developers

Information Technology (IT) Services Firms

 Help companies develop custom information systems for internal use.
 Develop, host, and run applications for customers.
 Provide other services

Packaged Software Producers

 Serve many market segments.
 Provide software ranging from broad-based packages (i.e. general ledger) to niche packages (i.e.
day care management).
  Software runs on all size computers, from microcomputers to large mainframes.
 Prepackaged software is off-the-shelf, turnkey software (i.e. not customizable).
 Off-the-shelf software at best meets 70 percent of organizations’ needs.

Enterprise Solutions Software

 Enterprise Resource Planning (ERP) systems integrate individual traditional business

functions into modules enabling a single seamless transaction to cut across functional
boundaries.
 SAP AG is the leading vendor of ERP systems
 Open-Source Software

 Freely available including source code

 Developed by a community of interested people
 Performs the same functions as commercial software
 Examples: Linux, mySQL, Firefox

In-House Development
 If sufficient system development expertise with the chosen platform exists in-house, then some or all
of the system can be developed by the organization’s own staff.
 Hybrid solutions involving some purchased and some in-house components are common

Sources of Software Components

Selecting Off-the-Shelf Software

 Cost: comparing the cost of developing the same system in-house with the cost of purchasing or
licensing the software package
 Functionality: the tasks that the software can perform and the mandatory, essential, and desired
system features
 Vendor support: whether or how much support the vendor can provide and at what cost
 Viability of vendor: can the software adapt to changes in systems software and hardware
 Flexibility: how easy it is to customize the software
 Documentation: is the user’s manual and technical documentation understandable and up-to-date
 Response time: how long it takes the software package to respond to the user’s requests in an
interactive session
 Ease of installation: a measure of the difficulty of loading the software and making it operational

Validating Purchased Software Information

Use a variety of information sources:
 Collect information from vendor
 Software documentation
  Technical marketing literature
Request For Proposal (RFP)
Request for proposal (RFP) is a document provided to vendors to ask them to propose hardware and system
software that will meet the requirements of a new system

 Sometimes called a Request For Quote (RFQ)

 Use a variety of information sources
 Based on vendor bids, analyst selects best candidates.

Information Sources For RFP

 Vendor’s proposal
 Running software through a series of tests
 Feedback from other users of the vendor’s product
 Independent software testing services
 Articles in trade publications
Reuse
1. The use of previously written software resources, especially objects and components, in new
applications
2. Commonly applied to two different development technologies:
 Object-oriented development
 Component-based development

3. Object-oriented development
 Object class encapsulates data and behavior of common organizational entities (e.g.
employees)

4. Component-based development
 Components can be as small as objects or as large as pieces of software that handle single
business functions.
5. Object-oriented development
reuse is the use of object classes in more than one application (e.g. Employee).

6. Component-based development reuse is the assembly of an application from many different

components at many different levels of complexity and size (e.g. Currency conversion).

Costs and Benefits of Reuse

Approaches to Reuse
Ad-hoc: individuals are free to find or develop reusable assets on their own.
Facilitated: developers are encouraged to practice reuse
Managed: the development, sharing, and adoption of reusable assets is mandated.
Designed: assets mandated for reuse as they are being designed for specific applications.

chapter3
 The Systems Development Environment
A Modern Approach to Systems Analysis and Design
 1950s: focus on efficient automation of existing processes
 1960s: advent of 3GL, faster and more reliable computers
 1970s: system development becomes more like an engineering discipline
 1980s: major breakthrough with 4GL, CASE tools, object oriented methods
 1990s: focus on system integration, GUI applications, client/server platforms, Internet
The new century: Web application development, wireless PDAs, component- based applications

Application Software
Computer software designed to support organizational functions or processes n Systems Analyst
Organizational role most responsible for analysis and design of information systems

Developing Information Systems

System Development Methodology is a standard process followed in an organization to conduct all the steps
necessary to analyze, design, implement, and maintain information systems.

Systems Development Life Cycle (SDLC)

Traditional methodology used to develop, maintain, and replace information systems.
Phases in SDLC:
 Planning
 Analysis
 Design
 Implementation
 Maintenance

Standard and Evolutionary Views of SDLC

FIGURE 1-3 Evolutionary model

FIGURE 1-2 The systems development life
cycle
Planning – an organization’s total information system needs are identified, analyzed,
prioritized, and arranged

Analysis – system requirements are studied and structured

Design – a description of the recommended solution is converted into logical and then physical system
specifications

Logical design – all functional features of the system chosen for development in analysis are described
independently of any computer platform

Physical design – the logical specifications of the system from logical design are transformed into the
technology-specific details from which all programming and system construction can be accomplished

Implementation – the information system is coded, tested, installed and supported in the organization

Maintenance – an information system is systematically repaired and improved

The Heart of the Systems Development Process

FIGURE 1-7 FIGURE 1-8

The analysis–design–code–test loop The heart of systems development

Current practice combines analysis, design, and implementation into a single iterative
and parallel process of activities.

Traditional Waterfall SDLC

FIGURE 1-9

A traditional waterfall SDLC

One phase begins when another completes, with little backtracking and looping.

Problems with Waterfall Approach

 System requirements “locked in” after being determined (can't change)

 Limited user involvement (only in requirements phase)

 Too much focus on milestone deadlines of SDLC phases to the detriment of sound development
practices
Different Approaches to Improving Development

 Prototyping

 CASE Tools

 Rapid Application Development (RAD)

 Agile Methodologies

 eXtreme Programming

Prototyping

 Prototyping Is a form of Rapid Application Development.

 Building a scaled-down working version of the system

Advantages:

 Users are involved in design

 Captures requirements in concrete form

Computer-Aided Software Engineering (CASE) Tools

 Diagramming tools enable graphical representation.

 Computer displays and report generators help prototype how systems “look and feel”.

 Analysis tools automatically check for consistency in diagrams, forms, and reports.

 A central repository provides integrated storage of diagrams, reports, and project management
specifications.

 Documentation generators standardize technical and user documentation.

 Code generators enable automatic generation of programs and database code directly from design
documents, diagrams, forms, and reports.

Rapid Application Development (RAD)

 Methodology to radically decrease design and implementation time

 Involves: extensive user involvement, prototyping, JAD sessions, integrated CASE tools, and code
generators

RAD life cycle

Service-Oriented Architecture (SOA) (Cont.)
FIGURE 1-12
Illustration of a service, a credit check,

7. Agile Methodologies
Motivated by recognition of software development as fluid, unpredictable, and dynamic
8. Three key principles
Adaptive rather than predictive ̈
Emphasize people rather than roles
Self-adaptive processes
When to use Agile Methodologies
 If your project involves: ̈Unpredictable or dynamic requirements

 ̈Responsible and motivated developers

 ̈Customers who understand the process and will get involved

eXtreme Programming

 Short, incremental development cycles

 Automated tests

 Two-person programming teams

 Coding and testing operate together

Advantages:

 Communication between developers

 High level of productivity

 High-quality code

Object-Oriented Analysis and Design (OOAD)

 Based on objects rather than data or processes

  Object: a structure encapsulating attributes and behaviors of a real- world entity

 Object class: a logical grouping of objects sharing the same attributes and
behaviors

 Inheritance: hierarchical arrangement of classes enable subclasses to inherit

properties of superclasses

Rational Unified Process (RUP)

 An object-oriented systems development methodology

 RUP establishes four phase of development: inception, elaboration, construction, and transition.

 Each phase is organized into a number of separate iterations

 Our Approach to Systems Development

 The SDLC is an organizing and guiding principle in this book.

 We may construct artificial boundaries or artificially separate activities and processes for learning
purposes.

 Our intent is to help you understand all the pieces and how to assemble them.

chapter4

Determining System Requirements

Performing Requirements Determination

The Process of Determining Requirements
n Good Systems Analyst Characteristics:
 Impertinence—question everything
 Impartiality—consider all issues to find the best organizational solution
 Relaxing constraints—assume anything is possible
 Attention to details—every fact must fit
 Reframing—challenge yourself to new ways
Deliverables and Outcomes
n Deliverables for Requirements Determination:
1. From interviews and observations —interview transcripts, observation notes, meeting minutes
2. From existing written documents — mission and strategy statements, business forms, procedure
manuals, job descriptions, training manuals, system documentation, flowcharts
3. From computerized sources — Joint Application Design session results, CASE repositories, reports from
existing systems, displays and reports from system prototype
4. Traditional Methods for Determining Requirements
n Interviewing individuals
n Interviewing groups
n Observing workers
n Studying business documents

5. Interviewing and Listening

One of the primary ways analysts gather information about an information systems project
Interview Guide is a document for developing, planning and conducting an interview
6. Guidelines for Effective Interviewing
n Plan the interview.
n Prepare interviewee: appointment, priming questions.
n Prepare agenda, checklist, questions.
n Listen carefully and take notes (tape record if permitted).
n Review notes within 48 hours.
n Be neutral.
n Seek diverse views
9. Choosing Interview Questions
n Each question in an interview guide can include both verbal and non-verbal information.
¨ Open-ended questions: questions that have no prespecified answers
¨ Closed-ended questions: questions that ask those responding to choose from among a set of
specified responses
10. Interviewing Groups
1-Drawbacks to individual interviews:
¨ Contradictions and inconsistencies between interviewees
¨ Follow-up discussions are time consuming
¨ New interviews may reveal new questions that require additional interviews with those
interviewed earlier
2-Interviewing several key people together
¨ Advantages
n More effective use of time
n Can hear agreements and disagreements at once
n Opportunity for synergies

¨ Disadvantages
n More difficult to schedule than individual interviews

Nominal Group Technique (NGT)

n A facilitated process that supports idea generation by groups Process

¨ Members come together as a group, but initially work separately.
¨ Each person writes ideas.
¨ Facilitator reads ideas out loud, and they are written on a blackboard or flipchart
¨ Group openly discusses the ideas for clarification.
¨ Ideas are prioritized, combined, selected, reduced.
¨ NGT exercise used to complement group meetings or as part of JAD effort.

Directly Observing Users

Direct Observation
¨ Watching users do their jobs
¨ Obtaining more firsthand and objective measures of employee interaction with information
systems
¨ Can cause people to change their normal operating behavior
¨ Time-consuming and limited time to observe

Analyzing Procedures and Other Documents

n Document Analysis
¨ Review of existing business documents
¨ Can give a historical and “formal” view of system requirements
n Types of information to be discovered:
¨ Problems with existing system
¨ Opportunity to meet new need
¨ Organizational direction
¨ Names of key individuals
¨ Values of organization
¨ Special information processing circumstances
¨ Reasons for current system design
¨ Rules for processing data
n Useful document: Written work procedure
 ¨ For an individual or work group
¨ Describes how a particular job or task is performed
¨ Includes data and information used and created in the process
n Potential Problems with Procedure Documents:
¨ May involve duplication of effort.
¨ May have missing procedures.
¨ May be out of date.
¨ May contradict information obtained through interviews.
n Formal Systems: the official way a system works as described in organizational documentation (i.e.
work procedure)

n Informal Systems: the way a system actually works (i.e. interviews, observations)
n Useful document: Business form
¨ Used for all types of business functions
¨ Explicitly indicate what data flow in and out of a system and data necessary for the system to
function
¨ Gives crucial information about the nature of the organization
n Useful document: Report
¨ Primary output of current system
¨ Enables you to work backwards from the report to the data needed to generate it
n Useful document: Description of current information system

Contemporary Methods for Determining System Requirements

n Joint Application Design (JAD)
¨ Brings together key users, managers, and systems analysts
¨ Purpose: collect system requirements simultaneously from key people
¨ Conducted off-site
n Group Support Systems
¨ Facilitate sharing of ideas and voicing of opinions about system requirements
n CASE tools
¨ Used to analyze existing systems
¨ Help discover requirements to meet changing business conditions
n System prototypes
¨ Iterative development process
¨ Rudimentary working version of system is built
¨ Refine understanding of system requirements in concrete terms
Joint Application Design (JAD)
¨ Intensive group-oriented requirements determination technique
¨ Team members meet in isolation for an extended period of time
¨ Highly focused
¨ Resource intensive
¨ Started by IBM in 1970s
JAD Participants:
¨ Session Leader: facilitates group process
¨ Users: active, speaking participants
¨ Managers: active, speaking participants
¨ Sponsor: high-level champion, limited participation
¨ Systems Analysts: should mostly listen
¨ Scribe: record session activities
 ¨ IS Staff: should mostly listen
End Result
¨ Documentation detailing existing system
¨ Features of proposed system
CASE Tools During JAD
¨ Upper CASE tools are used
¨ Enables analysts to enter system models directly into CASE during the JAD session
¨ Screen designs and prototyping can be done during JAD and shown to users
Using Prototyping During Requirements Determination
¨ Quickly converts requirements to working version of system
¨ Once the user sees requirements converted to system, will ask for modifications or will
generate additional requests
Most useful when:
¨ User requests are not clear.
¨ Few users are involved in the system.
¨ Designs are complex and require concrete form.
¨ There is a history of communication problems between analysts and users.
¨ Tools are readily available to build prototype.
Drawbacks
¨ Tendency to avoid formal documentation
¨ Difficult to adapt to more general user audience
¨ Sharing data with other systems is often not considered
¨ Systems Development Life Cycle (SDLC) checks are often bypassed
Radical Methods for Determining System Requirements
¨ Business Process Reengineering (BPR): search for and implementation of radical change in
business processes to achieve breakthrough improvements in products and services
Goals
¨ Reorganize complete flow of data in major sections of an organization.
¨ Eliminate unnecessary steps.
¨ Combine steps.
¨ Become more responsive to future change
Identifying Processes to Reengineer
n Identification of processes to reengineer
¨ Key business processes
n Structured, measured set of activities designed to produce specific output for a
particular customer or market
n Focused on customers and outcome
Disruptive Technologies
¨ Information technologies must be applied to radically improve business processes.
¨ Disruptive technologies are technologies that enable the breaking of long-held business rules
that inhibit organizations from making radical business changes.
Requirements Determination using Agile Methodologies
n Continual user involvement
¨ Replace traditional SDLC waterfall with iterative analyze – design – code – test cycle
n Agile usage-centered design
¨ Focuses on user goals, roles, and tasks
n The Planning Game
¨ Based on eXtreme programming
¨ Exploration, steering, commitment

Agile Usage-Centered Design Steps

¨ Gather group of programmers, analysts, users, testers, facilitator.
¨ Document complaints of current system.
¨ Determine important user roles.
¨ Determine, prioritize, and describe tasks for each user role.
¨ Group similar tasks into interaction contexts.
¨ Associate each interaction context with a user interface for the system, and prototype the interaction
context.
¨ Step through and modify the prototype
The Planning Game from eXtreme Programming

Electronic Commerce Applications: Determining System Requirements

n Determining system requirements for Pine Valley furniture’s Webstore
¨ System layout and navigation characteristics
¨ Webstore and site management system capabilities
¨ Customer and inventory information
¨ System prototype evolution
 chapter5
Structuring System Process Requirements

Process Modeling

n Graphically represent the processes that capture, manipulate, store, and distribute data between a
system and its environment and among system components.
n Utilize information gathered during requirements determination.
n Processes and data structures are modeled.

Deliverables and Outcomes

n Context data flow diagram (DFD)
 ¨ Scope of system
n DFDs of current physical system
¨ Adequate detail only
n DFDs of current logical system
¨ Enables analysts to understand current system
n DFDs of new logical system
¨ Technology independent
¨ Show data flows, structure, and functional requirements of new system
n Thorough description of each DFD component
Data Flow Diagramming Mechanics
n Represent both physical and logical information systems
n Only four symbols are used
n Useful for depicting purely logical information flows
n DFDs that detail physical systems differ from system flowcharts which depict details of physical
computing equipment

Definitions and Symbols

n Process: work or actions performed on data (inside the system)

n Data store: data at rest (inside the system)
n Source/sink: external entity that is origin or destination of data (outside the system)
n Data flow: arrows depicting movement of data

Developing DFDs
n Context diagram is an overview of an organizational system that shows:
¨ the system boundaries.
¨ external entities that interact with the system.
¨ major information flows between the entities and the system.
n Note: only one process symbol, and no data stores shown

Level-0 Diagram
 n Level-0 diagram is a data flow diagram that represents a system’s major processes, data flows, and
data stores at a high level of detail.
¨ Processes are labeled 1.0, 2.0, etc. These will be decomposed into more primitive (lower-
level) DFDs.

Data Flow Diagramming Rules

n There are two DFD guidelines that apply:
¨ The inputs to a process are different from the outputs of that process.
n Processes purpose is to transform inputs into outputs.
¨ Objects on a DFD have unique names.
n Every process has a unique name.
Decomposition of DFDs
n Functional decomposition is an iterative process of breaking a system description down into finer
and finer detail.
¨ Creates a set of charts in which one process on a given chart is explained in greater detail on
another chart.
¨ Continues until no subprocess can logically be broken down any further.
n Primitive DFD is the lowest level of a DFD.
n Level-1 diagram results from decomposition of Level-0 diagram.
Level-n diagram is a DFD diagram that is the result of n nested decompositions from a process on a level-0
diagram
Level-1 DFD

Level-n DFD

Balancing DFDs
n Conservation Principle: conserve inputs and outputs to a process at the next level of decomposition
n Balancing: conservation of inputs and outputs to a data flow diagram process when that process is
decomposed to a lower level
Balanced means:
n Number of inputs to lower level DFD equals number of inputs to associated process of
higher-level DFD
n Number of outputs to lower level DFD equals number of outputs to associated process of
higher-level DFD
 n Data flow splitting is when a composite data flow at a higher level is split and different parts go to
different processes in the lower level DFD.
n The DFD remains balanced because the same data is involved, but split into two parts.

Balancing DFDs: More DFD Rules

Four Different Types of DFDs
n Current Physical
¨ Process labels identify technology (people or systems) used to process the data.
¨ Data flows and data stores identify actual name of the physical media.
n Current Logical
¨ Physical aspects of system are removed as much as possible.
¨ Current system is reduced to data and processes that transform them.
n New Logical
¨ Includes additional functions.
¨ Obsolete functions are removed.
¨ Inefficient data flows are reorganized.
n New Physical
¨ Represents the physical implementation of the new system.
Guidelines for Drawing DFDs
n Completeness
¨ DFD must include all components necessary for system.
¨ Each component must be fully described in the project dictionary or CASE repository.
n Consistency
¨ The extent to which information contained on one level of a set of nested DFDs is also included
on other levels
n Timing
¨ Time is not represented well on DFDs.
¨ Best to draw DFDs as if the system has never started and will never stop.
n Iterative Development
Analyst should expect to redraw diagram several times before reaching the closest approximation to the
system being modeled
n Primitive DFDs
¨ Lowest logical level of decomposition
¨ Decision has to be made when to stop decomposition
n Rules for stopping decomposition
 ¨ When each process has been reduced to a single decision, calculation or database operation
¨ When each data store represents data about a single entity
n Rules for stopping decomposition, cont.
¨ When the system user does not care to see any more detail
¨ When every data flow does not need to be split further to show that data are handled in
various ways
¨ When you believe that you have shown each business form or transaction, online display and
report as a single data flow
¨ When you believe that there is a separate process for each choice on all lowest-level menu
options
Using DFDs as Analysis Tools
n Gap Analysis is the process of discovering discrepancies between two or more sets of data flow
diagrams or discrepancies within a single DFD.
n Inefficiencies in a system can often be identified through DFDs.
Using DFDs in BPR

Electronic Commerce Application: Process Modeling using Data Flow Diagrams

n Process modeling for Pine Valley Furniture’s Webstore
¨ Completed JAD session.
¨ Began translating the Webstore system structure into data flow diagrams.
n Identified six high-level processes.