Week 1. Object-Oriented Analysis and Design with the Unified Process 2 The Analyst as a Business...

Week 1

Object-Oriented Analysis and Design with the Unified Process 2

The Analyst as a Business Problem Solver

Analyst background: computer technology, object-oriented analysis and design, curiosity

Chief task: define problem and outline solution Challenge: develop alternatives consistent with

corporate strategic Develop system requirements and design models Systems design models: databases, user interfaces,

networks, operating procedures, conversion plans, and, software classes


Figure 1-1 The Analyst’s Approach to Problem Solving

Fig 1-1A Fig 1-1B


Information Systems

Information system: collects, processes, stores, and outputs information

Subsystem: components of another system

Components: hardware, software, inputs, outputs, data, people, and procedures

Supersystem: collection of systems

Automation boundary: separates automated part of system from manual (human)


Figure 1-3Information Systems and Component Parts


Types of Information Systems

There are many types of information systems

Six common systems are found in most businesses

Business systems center around transactions

Systems must adapt to changing technology


Figure 1-5Types of Information Systems


Required Skills of the Systems Analyst

Analysts manage issues ranging from technical to interpersonal

Analyst must commit to lifelong learning


Figure 1-6Required Skills of the Systems Analyst


Technical Knowledge and Skills

Analysts should grasp many types of technology

Analysts should be informed of tools and techniques

Common software tools: IDEs and CASE

Common techniques

Project planning

Cost-benefit analysis

Architectural Analysis


Business Knowledge and Skills

Analysts should understand organizational structure

Analysts should understand business concern

Many analysts formally study business administration

CIS and MIS majors often included in business colleges


People Knowledge and Skills

Knowledge of people centers around thinking and feeling

People knowledge used to adapt systems to users

Most critical skill: ability to listen empathetically


The Environment Surrounding the Analyst

Occupational environment is not fixed

Analysts will encounter many types of technology

Analysts will work in many locations

Analysts are assigned a variety of job titles


Types of Technology

Wide range: from desktops to large scale information systems

Variety of computers connected by complex networks

Technology change is continuous

Innovation often drives information system change

Regular upgrades of knowledge and skills essential


A Few Words about Integrity and Ethics

Sense of personal integrity and ethics essential

Analysts often encounter personal information

Analysts encounter confidential proprietary information

Keep confidential and sensitive information private

Improprieties can ruin an analyst’s career


The Traditional Predictive SDLC Approaches

Five activities or phases in a project Planning, analysis, design, implementation, support

Pure waterfall approach (predictive SDLC) Assumes project phases can be sequentially executed Project drops over the “waterfall” into the next phase

Modified waterfall approach Tempers pure waterfall by recognizing phase overlap Informs many current projects and company systems


Figure 2-3SDLC Phases and Objectives


Figure 2-4The Waterfall Approach to the SDLC


The Newer Adaptive Approaches to the SDLC

The spiral model: early form of adaptive SDLC Activities radiate from center starting point Prototypes are artifacts of each phase

Iterative problem solving: repeats activities Several approaches to structuring iterations

Define and implement the key system functions Focus on one subsystem at a time Define by complexity or risk of certain components Complete parts incrementally


Figure 2-6The Spiral Life Cycle Model


The Unified Process Life Cycle

UP life cycle

Includes (4) phases which consist of iterations

Iterations are “mini-projects”

Inception: develop and refine system vision

Elaboration: define requirements and core architecture

Construction: continue design and implementation

Transition: move the system into operational mode


Unified Process


Figure 2-8The Unified Process System Development Life Cycle


Figure 2-9UP Phases and Objectives


Methodologies and System Development Processes

System development methodology

Provides guidelines every activity in system development

Includes specific models, tools, and techniques

UP is a system development methodology

Process is a synonym for methodology

Methodologies supported with documentation


Models Model abstract (separate) aspects of the real world

Models come in many forms

Physical analogs, mathematical, graphical

System development models are highly abstract

Depict inputs, outputs, processes, data, objects, interactions, locations, networks, and devices

Unified Modeling Language (UML): standard notation

PERT or Gantt charts: model project itself


Figure 2-10Some Models used in System Development


Tools

Tool: software used to create models or components

Example tools

Project management software tools (Microsoft Project)

Integrated development environments (IDEs)

Code generators

Computer-aided system engineering (CASE)


Techniques Technique

Collection of guidelines

Enables an analyst to complete an activity or task

Example techniques

Domain-modeling , use case modeling, software-testing, user-interviewing techniques, relational database design techniques

Proven techniques are embraced as “Best Practices”


Figure 2-13Relationships of Models, Tools, and Techniques in a System

Development Methodology


The Unified Process as a System Development Methodology

UP: object-oriented system development methodology

UP should be tailored to organizational and project needs

Project will be use case driven


The Unified Process as a System Development Methodology

(continued) Use case

Activity that the system carries out Basis for defining requirements and designs

UP defines disciplines within each phase Discipline: set of functionally related activities Iterations concatenate activities from all disciplines Activities in each discipline produce artifacts; models,

documents, source code, and executables


Figure 2-15UP Life Cycle with Phases, Iterations, and Disciplines


The UP Disciplines Six main UP development disciplines

Business modeling, requirements, design, implementation, testing, and deployment

Each iteration Similar to a mini-project Results in a completed portion of the system

Three additional support disciplines Project management, configuration and change

management, and environment


Business Modeling

Purpose: understand business environment

Three major activities part of business modeling

Understand surroundings

Create the system vision

Create business models


Requirements

Objective: document business requirements Key drivers of activities: discovery and understanding Requirements discipline and business modeling map

to traditional systems analysis Activities list

Gather detailed information Define functional and nonfunctional requirements Develop user interface dialogs Evaluate requirements with users


Design Objective: design system based on requirements Six major activities in the design discipline

Design support services architecture and deployment environment

Design the software architecture Design use case realizations Design the database Design the system and user interfaces Design the system security and controls


Implementation

Objective: build or acquire needed system components

Implementation activities

Build software components

Acquire software components

Integrate software components


Testing Testing is critical discipline

Testing activities

Define and conduct unit testing

Define and conduct integration testing

Define and conduct usability testing

Define and conduct user acceptance testing

In UP, acceptance testing occurs throughout the building phase


Deployment

Goal: conduct activities to make system operational

Deployment activities

Acquire hardware and system software

Package and install components

Train users

Convert and initialize data

Deployment activities prominent in transition phase


Project Management Most important support discipline

Project management activities

Finalize the system and project scope

Develop the project and iteration schedule

Identify project risks and confirm feasibility

Monitor and control the project’s plan

Monitor and control communications

Monitor and control risks and outstanding issues


Configuration and Change Management

Configuration and change discipline pertains to: Requirements

Design

Source code

Executables

The two activities in this discipline Develop change control procedures

Manage models and software components


Environment Development environment includes

Available facilities

Design of the workspace

Forums for team communication and interaction

Environment discipline activities Select and configure the development tools

Tailor the UP development process

Provide technical support services


Overview of Object-Oriented Concepts

OOA views system as a collection of objects

Object: entity capable of responding to messages

Languages: Simula, C++, Java, C#, Visual Basic .NET

Object-oriented design (OOD) Defines additional types of communication objects

Shows how the objects interact to complete tasks

Refines definition of objects for implementation

Object-oriented programming (OOP): object coding


Characteristics of Object-Oriented Systems

Classes and Objects – A class is a template used to define and create objects. Every object is associated with a class. An object has attributes that describe the information about the object. Each object has behaviors that specify what the object can do.

Methods and Messages – Methods implement an object’s behavior. A method is nothing more than an action that an object can perform. Messages are information sent to objects to trigger methods. Basically, a message is a function or procedure call from one object to another object.


Encapsulation and Information Hiding – The ideas of encapsulation and information hiding are interrelated in OO systems. Encapsulation is the combination of process and data into a single entity. Information hiding suggests that only the information required to use a software module be published to the user of the module. Exactly how the module implements the required functionality is not relevant.

Inheritance – This is used to identify higher-level or more general classes of objects. Common sets of attributes and methods can be organized into superclasses or parent classes. The relationship between the class and its superclass is known as a “Is A” relationship. For example, a heart surgeon “Is A” doctor. Subclasses or child classes inherit appropriate attributes and methods from the superclass above them in the class hierarchy.


Polymorphism and Dynamic Binding – Polymorphism means that the same message can be interpreted differently by different classes of objects. Because we are not concerned with “how” something is done, we can simply send a message to an object and that object will be responsible for interpreting the message appropriately. Polymorphism is made possible through dynamic binding. Dynamic, or late binding, is a technique that delays typing the object until run-time. As such, the specific method that is actually being called is not chosen by the OO system until the system is running. This is in contrast to static binding where the object type is determined at compile time.


Recognizing the Benefits of OO

Development Original application of object-oriented technology

Computer simulations

Graphical user interfaces

Rationale for use in information systems

Benefits of naturalness

Reusability


Objects Are More Natural OO approach mirrors human perception: objects

moving through space OOA, OOD, and OOP imitate perceptual processes by

modeling classes of objects Some system developers resist OO development New programmers are more receptive to OO approach System users appreciate object-orientation

They discuss the objects involved in their work Hierarchies are common tools for organizing knowledge


Classes of Objects Can Be Reused

Classes of objects have a long shelf life

Example: Customer class adaptability

Reused in systems where customer objects needed

Extended through inheritance to a new subclass

Reused during analysis, design, or programming

Classes may be stored, with implementation hidden, in class libraries


Understanding Object-Oriented Concepts

Object: thing with attributes and behaviors

Types of objects

User interface

Problem domain objects

Attributes are associated with data

Behaviors are associated with methods, functions, and procedures


Figure 2-18Attributes and Methods in Problem Domain Objects


Understanding Object-Oriented Concepts (continued)

Class: defines what all objects of class represent

Objects are instances of a class

Customer object is an instance of a customer class

Objects interact through messages

Objects retain memory of transactions


Figure 2-20Order-processing system where objects interact by sending messages


Understanding Object-Oriented Concepts (continued)

Objects maintain association relationships Encapsulation: combining attributes and methods

into one unit Information hiding: separating specification from

implementation Inheritance: extending the characteristics of a class Polymorphism: ability for dissimilar objects to

respond to the same message


Figure 2-22Superclasses and Subclasses


Tools to Support System Development

CASE (Computer Aided System Engineering) Database repository for information system

Set of tools that help analysts complete activities

Sample artifacts: models, automatically generated code

Variations on CASE Visual modeling tools

Integrated application development tools

Round-trip engineering tools


Figure 2-24A Case Tool Repository Contains All Information About the System


Tools to Support System Development (continued)

Microsoft Visio: emphasizes technical drawing Rational Rose

CASE tool supporting object-oriented approach Strongly identified with UP methodology

Together Pioneers round-trip engineering

◘ synchronizes graphical models with generated program code

Leverages UML diagrams


Actor Generalization Actor generalization factors out behavior common to two or

more actors into a parent actor. In order to determine if you have a situation that can use

actor generalization, look for a high degree of commonality between actors.

Do two actors communicate with the same set of use cases in the same way?

If there is, you can factor out common actor behavior into a more generalized actor.

You will have a parent actor and one or more descendent actors.

The descendant actors inherit the roles and relationships to use cases held by the parent actor. You can substitute a descendent actor anywhere the parent actor is expected.


Actor Generalization


Use-Case Generalization

Use-case generalization factors out behavior common to one or more use cases into a parent use case.

It is used when you have one or more use cases that are really specializations of a more general use case.

The child use cases represent more specific forms of the parent. The children may: inherit features from their parent use case; add new features; override (change) inherited features.


Use-Case Generalization

Week 1. Object-Oriented Analysis and Design with the Unified Process 2 The Analyst as a Business...

Documents

Transcript of Week 1. Object-Oriented Analysis and Design with the Unified Process 2 The Analyst as a Business...