Systems Analysis and Design with UML Version 2.0

Systems Analysis and Design with UML Version 2.0
Alan Dennis , Barbara Haley Wixom , David Tegarden

Table Of Contents 1. Introduction to Systems Analysis and Design 2.Introduction to Object-Oriented Systems Analysis & Design with Unified Modeling Language, Version 3: Project Initiation 4: Project Management 5: Requirements Determination 6: Functional Modeling 7: Structural Modeling 8: Behavioral Modeling

9: Moving on to Design 10: Class and Method Design 11: Data Management Layering 12: Human Computer Interaction Design 13: Physical Architecture Layer Design 14: Construction 15: Installation and Operations

Systems Analysis and Design With UML 2
Systems Analysis and Design With UML 2.0 An Object-Oriented Approach, Second Edition Chapter 1: Introduction to Systems Analysis and Design Alan Dennis, Barbara Wixom, and David Tegarden

INTRODUCTION Chapter 1

Key Ideas Many failed systems were abandoned because analysts tried to build wonderful systems without understanding the organization. The primarily goal is to create value for the organization.

Key Ideas The systems analyst is a key person analyzing the business, identifying opportunities for improvement, and designing information systems to implement these ideas. It is important to understand and develop through practice the skills needed to successfully design and implement new information systems.

THE SYSTEMS DEVELOPMENT LIFE CYCLE

Major Attributes of the Lifecycle
The project Moves systematically through phases where each phase has a standard set of outputs Produces project deliverables Uses deliverables in implementation Results in actual information system Uses gradual refinement

Project Phases Planning Analysis Design Implementation System delivery
Why build the system? Analysis Who, what, when, where will the system be? Design How will the system work? Implementation System delivery

A “Simple” Process for Making Lunch

Planning Identifying business value Analyze feasibility
Develop work plan Staff the project Control and direct project

Analysis Analysis Information gathering Process modeling Data modeling

Design Physical design Architectural design Interface design
Database and file design Program design

Implementation Construction Installation

Processes and Deliverables
Product Planning Analysis Design Implementation Project Plan System Proposal System Specification New System and Maintenance Plan

SYSTEM DEVELOPMENT Methodologies

What Is a Methodology? A formalized approach or series of steps
Writing code without a well- thought-out system request may work for small programs, but rarely works for large ones.

Structured Design Projects move methodically from one to the next step
Generally, a step is finished before the next one begins

Waterfall Development Method

Pros and Cons of the Waterfall Method
Identifies systems requirements long before programming begins Design must be specified on paper before programming begins Long time between system proposal and delivery of new system

Parallel Development

Alternatives to the SDLC
Rapid Application Development (RAD) Phased Development Prototyping Throw-Away Prototyping

Rapid Application Development
Critical elements CASE tools JAD sessions Fourth generation/visualization programming languages Code generators

Rapid Application Development Categories
Phased development A series of versions Prototyping System prototyping Throw-away prototyping Design prototyping Agile Development Extreme Development

How Prototyping Works

Throwaway Prototyping

Selecting the Appropriate Methodology
Clarity of User Requirements Familiarity with Technology System Complexity System Reliability Short Time Schedules Schedule Visibility

Criteria for Selecting a Methodology

Project Team Roles and Skills

Information Systems Roles
Business analyst System analyst Infrastructure analyst Change management analyst Project manager

Project Team Roles

Summary -- Part 1 The Systems Development Lifecycle consists of four stages: Planning, Analysis, Design, and Implementation The major development methodologies: Structured design the waterfall method Parallel development RAD development Prototyping (regular and throwaway) Agile development XP streamline SDLC

Summary -- Part 2 There are five major team roles: business analyst, systems analyst, infrastructure analyst, change management analyst and project manager.

Systems Analysis and Design With UML 2.0 An Object-Oriented Approach, Second Edition Chapter 2: Introduction to Object-Oriented Systems Analysis and Design with the Unified Modeling Language, Version 2.0 Alan Dennis, Barbara Wixom, and David Tegarden © 2005 John Wiley & Sons, Inc.

Unified Modeling Language, Version 2.0
Chapter 2

Objectives Understand the basic characteristics of object-oriented systems. Be familiar with the Unified Modeling Language (UML), Version 2.0. Be familiar with the Unified Process. Understand a minimalist approach to object-oriented systems analysis and design.

Basic Characteristics of Object Oriented Systems
Classes and Objects Methods and Messages Encapsulation and Information Hiding Inheritance Polymorphism and Dynamic Binding

Classes and Objects Class – Template to define specific instances or objects Object – Instantiation of a class Attributes – Describes the object Behaviors – specify what object can do

Classes and Objects

Methods and Messages Methods implement an object’s behavior
Analogous to a function or procedure Messages are sent to trigger methods Procedure call from one object to the next

Messages and Methods

Encapsulation and Information Hiding
combination of data and process into an entity Information Hiding Only the information required to use a software module is published to the user Reusability Key Use an object by calling methods

Inheritance Superclasses or general classes are at the top of a hierarchy of classes Subclasses or specific classes are at the bottom Subclasses inherit attributes and methods from classes higher in the hierarchy

Class Hierarchy

Inheritance

Polymorphism and Dynamic Binding
A message can be interpreted differently by different classes of objects Dynamic Binding Sometimes called late binding Delays typing or choosing a method for an object until run-time Static Binding Type of object determined at compile time

Polymorphish & Encapsulation

The Unified Modeling Language, Version 2.0
Structure Diagrams Behavior Diagrams Extension Mechanisms Developers Grady Booch Ivar Jacobson James Rumbaugh

Structure Diagram Structure Diagrams include Class Object package
Deployment Component Composite structure diagrams

UML 2.0 Diagram Summary

Structure Diagrams Class Object Package relationship between classes
Relationships between objects Package Group UML elements together to form higher level constructs

Structure Diagrams Cont.
Deployment Shows the physical architecture and software components of system Component Physical relationships among software components Composite Structure Illustrates internal structure of a class

Activity Diagrams Activity Sequence Communication
Illustrates business workflows Sequence Time-based ordering Behavior of objects activities in a use case Communication Communication among a set of collaborating objects of an activity Interaction Overview Timing Overview of flow of control of a process

State Machines Behavioral State Machine Protocol State Machine
Examines behavior of one class Protocol State Machine Shows dependencies of different interfaces of a class Use-Case Captures business requirements Illustrates interaction between system and environment

Use Case Diagrams Captures Business requirements
Illustrates interaction between a system and its environment Includes end user Any external system that interacts with its information system Documents and clarifies requirements of system being modeled

Extension Mechanisms Stereotypes Tagged Values Constraints Profiles
Gives ability to incrementally extend UML Tagged Values Add new properties to base elements Constraints Place restrictions on use of model elements Profiles Group model elements into a package

Object Oriented Systems Analysis and Design
Use-case driven Architecture Centric Iterative and Incremental The Unified Process

Engineering Workflows

Supporting Workflows

A Minimalist Approach Benefits of Object-Oriented Systems Analysis and Design Extensions of the Unified Process The Minimalist Object-Oriented Systems Analysis and Design Approach

Benefits of the Object Approach

MOOSAD Approach

Basic Characteristics of Object Oriented Systems
Identifying business value Analyze feasibility Develop workplan Staff the project Control and direct project Requirements determination Functional modeling Structural modeling Behavioral modeling Moving on to design

UML Summary Class and method design Data management layer design
Human computer interaction layer design Physical architecture layer design Construction Installation Operations and support

Summary Basic characteristics of an object oriented system
Unified modeling system Object oriented Systems Analysis and Design Minimalist approach to Object oriented systems analysis and design with UML

Chapter 3: Project Initiation
Systems Analysis and Design with UML Version 2.0 An Object-Oriented Approach, Second Edition Chapter 3: Project Initiation Alan Dennis, Barbara Wixom, and David Tegarden John Wiley & Sons, Inc.

PROJECT INITIATION Chapter 3

Key Ideas Projects being when someone sees an opportunity to create business value from using information technology. Feasibility analysis is used to aid in the decision of whether or not to proceed with the IS project.

Key Ideas The project sponsor is a key person proposing development or adoption of the new information technology . The approval committee reviews proposals from various groups and units in the organization and decides which to commit to developing.

IDENTIFYING BUSINESS VALUE

System Request Lists key elements of the project Project name
Project sponsor Business need Functionality Expected value Special issues or constraints

An ongoing-case study used to illustrate concepts presented in the text

Your Turn If you were building a web- based system for course enrollment -- What would be the functionality? What would be the expected value? What special issues or constraints would you foresee?

FEASIBILITY ANALYSIS

Feasibility Analysis Detailing Expected Costs and Benefits
Technical feasibility Economic feasibility Organizational feasibility 76

Technical Feasibility: Can We Build It?
Familiarity with application Knowledge of business domain Familiarity with technology Extension of existing firm technologies Project size Number of people, time, and features

Economic Feasibility Should We Build It?
Development costs Annual operational costs Annual benefits Intangible costs and benefit

Expected Value Costs Benefits Tangible Intangible *

Cash Flow Method for Cost Benefit Analysis

Return on Investment Calculation
RETURN ON INVESTMENT EQUALS Total (benefits - costs) Divided by Total costs

Net Present Value Calculation
(1 + interest rate)n Some amount of money NET PRESENT VALUE EQUALS Divided by Where “n” equals the number of periods

Organizational Feasibility If we build it, will they come?
Stakeholder analysis considers Project champion(s) Organizational management System users

APPLYING THE CONCEPTS AT CD SELECTIONS

What technical, economic, and organizational issues will developers of this system need to be aware of?

Summary Project initiation involves creating and assessing goals and expectations for a new system Identifying the business value of the new project is a key to success The system request describes an overview of the proposed system. The feasibility study is concerned with insuring that technical, economic, and organizational benefits outweigh costs and risks

Expanding the Domain For an excellent source of information on IT management see:

Alan Dennis, Barbara Wixom, and David Tegarden John Wiley & Sons, Inc.
Systems Analysis and Design with UML Version 2.0 Chapter 4 Project Management Alan Dennis, Barbara Wixom, and David Tegarden John Wiley & Sons, Inc. PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.

Project Management Chapter 4
PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.

Objectives ■ Become familiar with estimation.
■ Be able to create a project workplan. ■ Understand why project teams use timeboxing. ■ Become familiar with how to staff a project. ■ Understand how computer-aided software engineering, improve the efficiency of a project. ■ Understand how to reduce risk on a project.

Key Definitions Project management is the process of planning and controlling the development of a system within a specified timeframe at a minimum cost with the right functionality. A project manager has the primary responsibility for managing the hundreds of tasks and roles that need to be carefully coordinated.

Estimating a Project Based on Industry Information
Planning Analysis Design Implementation Industry Standard For Web 15% % % % Applications Time Required in Person Months

Function Points Estimate System Size
A function point is a measure of program size that is based on the system’s number and complexity of inputs, outputs, queries, files, and program interfaces Estimate effort required Person Months Estimate time required Months to complete

Time Estimation Using a More Complex Approach

Getting the Right Numbers for Estimation
Prior projects Past experience Industry standards Detailed analysis

Estimation Trade-offs
Size Function points Lines of code Effort Person-months People available Time Months

Calculate Function Points
List major elements of system Determine total number of each element Specify complexity index of each component (low, med., high) Total index multiplied by number of components (TUFP)

Function Point Estimation -- Step One
Complexity Description Low Medium High Total Inputs __x 3 __x 4 __x 6 ____ Outputs __x 4 __x 5 __x 7 ____ Queries __x 3 __x 4 __x 6 ____ Files __x 7 __x 10 __x 15 ____ Program __x 5 __x 7 __x 10 ____ Interfaces TOTAL UNADJUSTED FUNCTION POINTS ____

Adjusted Processing Complexity -- Step 2

Function Points Estimation -- Step Four
Adjusted Project Complexity = (0.01 * Project Complexity) Total Adjusted Function Points = Adjusted Project Complexity * TUFP

Function Point Estimation
Processing Complexity (PC): __7______ (From Step 2) Adjusted Processing Complexity (PCA) = (0.001 * __7_ ) Total Adjusted Function Points: _0.72 * _338_ = 243 (TUFP -- From Step 1)

Converting Function Points to Lines of Code
Language LOC/Function Code Point C COBOL JAVA C++ Turbo Pascal Visual Basic PowerBuilder HTML Packages (e.g., Access, Excel) 130 110 55 50 30 15 10-40 Source: Capers Jones, Software Productivity Research

Final Step Multiply function points
Approximate lines of code per function point in the chosen language If you chose C, then 243 function Points times 130 lines of code = 31,590 total lines of code

Estimating Effort Function of size and production rate COCOMO model
converts a lines-of-code estimate into a person-month estimate For moderate-size projects multiply thousands of lines of code by 1.4 to get the number of people to assign to the project

COCOMO Estimation Calculation
Effort = 1.4 * thousands-of- (in Person- lines-of-code Months) Example: If LOC = Then... Effort = (1.4 * 2000) = Person Months

Estimating Schedule Time
Rule of thumb for estimation Schedule Time (months) = 3.0 * person-months1/3

Staffing Attributes Staffing levels will change over a project’s lifetime Adding staff may add more overhead than additional labor Using teams of 8-10 reporting in a hierarchical structure can reduce complexity

Increasing Complexity with Larger Teams

Developing a WorkPlan Identify tasks in the project Estimate task length Determine task dependencies Specify to whom task will be assigned List deliverables PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.

A Workplan Example Work Plan Information Example Name of task Perform economic feasibility Start date ` Jan 05, 2001 Completion date Jan 19, 2001 Person assigned Mary Smith, sponsor Deliverable(s) Cost-benefit analysis Completion status Open Priority High Resources needed Spreadsheet Estimated time 16 hours Actual time hours PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.

Identifying Tasks Top-down approach Identify highest level tasks as phases in the project Break them into increasingly smaller units Methodology Using standard list of tasks Similar previous projects PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.

Top Down Task Identification
Phases with high level steps Phases Work Plan Deliverables Estimated Assigned hours To * PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.

Work Breakdown Structure
Specify high level tasks Break down each step into smaller tasks and number them in a hierarchical fashion WBS can be done in two ways SDLC phase Product PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.

WBS Problems They tend to be specific to the design of the information system being developed Too many levels of detail too early on in the SDLC for large projects or too few for small projects. Since they are project specific, they are very difficult to compare across projects.

Evolutionary WBS organize in a standard manner across all projects
create in an incremental and iterative manner first evolutionary WBS done with initial aspects of the project Later on more details are added to the WBS. Comparable to earlier projects based on cost and schedule estimation

Project WorkPlan

Key Definitions The staffing plan describes the kinds of people working on the project The project charter describes the project’s objectives and rules A functional lead manages a group of analysts A technical lead oversees progress of programmers and technical staff members

Motivation Use monetary rewards cautiously Use intrinsic rewards
Recognition Achievement The work itself Responsibility Advancement Chance to learn new skills

Conflict Avoidance Strategies
Clearly define roles and project plans Hold individuals accountable Project charter listing norms and groundrules Develop schedule commitments ahead of time Forecast other priorities and their possible impact on the project

Possible Reporting Structure

CONTROLLING AND DIRECTING THE PROJECT

The Hurricane Model Time Project Stage

Margins of Error in Cost and Time Estimates
Typical margins of Error for Well-done Estimates Phase Deliverable Cost (%) time (%) Planning System Request Project Plan Analysis System Proposal Design System Specification Source: Boehm et al. (1995) PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.

PERT Charts Project Evaluation and Review Technique (PERT) PERT uses three time stimates: Optimistic, O Most likely, M Pessimistic, P Time Estimate = O + 4 * M + P PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.

CASE Tools Upper CASE Lower CASE Integrated CASE (I-CASE)
Initiation Analysis Design Implementation Upper CASE Lower CASE Integrated CASE (I-CASE)

CASE Components CASE Repository Diagrams Screen Designs
Procedural Metadata Logic

Standards Examples Formal rules for naming files
Forms indicating goals reached Programming guidelines Can you think of more examples? The book lists a long set of examples on page 81. If you have a lot of students with their books open, you might pass up spending time having the students come up with examples. Otherwise, this is a valuable exercise. You might also ask whether there are times when it is better NOT to use standards.

Documentation Project binder Table of contents Continual updating

Managing Scope Scope creep -- a major cause of development problems
JAD and prototyping Formal change approval Charging for changes The smaller points here suggest some methods for limiting scope creep and are worth pointing out to the students. The last in the list allows users to make changes -- but adds to the costs that they must allocate to the project.

Timeboxing Fixed deadline Make deadline possible
Set by development group Reduced functionality, if necessary Fewer “finishing touches”

Timeboxing Steps 1. Set the date for system delivery.
2. Prioritize the functionality that needs to be included in the system. 3. Build the core of the system (the functionality ranked as most important). 4. Postpone functionality that cannot be provided within the time frame. 5. Deliver the system with core functionality. 6. Repeat steps 3 through 5, to add refinements and enhancements.

Managing Risk Risk assessment Actions to reduce risk
Revised assessment

Classic Mistakes Overly optimistic schedule
Failing to monitor schedule Failing to update schedule Adding people to a late project

Summary Project management is critical to successful development of new systems Project management involves planning, controlling and reporting on time, labor, and costs.

Expanding the Domain For more detail on project management, visit the project management institute and its special interest group on information systems:

Requirements Determination
Chapter 5

Objectives ■ Understand how to create a requirements definition.
■ Become familiar with requirements analysis techniques. ■ Understand when to use each requirements analysis technique. ■ Understand how to gather requirements using interviews, JAD sessions, questionnaires, document analysis, and observation. ■ Understand when to use each requirements- gathering technique.

Key Ideas The goal of the analysis phase is to truly understand the requirements of the new system and develop a system that addresses them. The first challenge is collecting and integrating the information The second challenge is finding the right people to participate.

Analysis Phase This phase takes the general ideas in the system request and refines them into a detailed requirements definition (this chapter), functional models (Chapter 6), structural models (Chapter 7), and behavioral models (Chapter 8) This becomes the system proposal Includes revised project management deliverables, feasibility analysis (Chapter 3) and workplan (Chapter 4).

Requirement Specification
a statement of what the system must do or characteristics it must have Written from businessperson perspective (“what” of system) Later requirements become more technical (“how” of system)

Functional vs. Nonfunctional
A functional requirement relates directly to a process the system has to perform or information it needs to contain. Nonfunctional requirements refer to behavioral properties that the system must have, such as performance and usability.

Functional Requirements

Nonfunctional Requirements

Requirements Analysis Techniques
Business process automation (BPA) Doesn’t change basic operations Automates some operations BPA Techniques Problem Analysis Root Cause Analysis

Business Process Improvement
Business process improvement (BPI) changes How an organization operates Changes operation with new techniques Can improve efficiency Can improve effectiveness

BPI Components Duration Analysis Activity-Based Costing
Time to perform each process Activity-Based Costing Examines major process costs Informal Benchmarking Studies how other organizations perform business processes

Business Process Reengineering
Changes how the organization does certain operations Consists of Outcome Analysis Technology analysis Activity Elimination

Select Appropriate Technique
Assess Potential Business Value Determine Project Cost Specify Breadth or Scope of Analysis Determine Risk of Failure

Analysis Characteristics

Requirements Gathering

Interviews -- Five Basic Steps
Selecting interviewees Designing interview questions Preparing for the interview Conducting the interview Post-interview follow-up

Selecting Interviewees
Based on information needed Often good to get different perspectives Managers Users Ideally, all key stakeholders

Types of Questions Types of Questions Examples Closed-Ended Questions
* How many telephone orders are received per day? * How do customers place orders? * What additional information would you like the new system to provide? Open-Ended Questions * What do you think about the current system? * What are some of the problems you face on a daily basis? * How do you decide what types of marketing campaign to run? Probing Questions * Why? * Can you give me an example? * Can you explain that in a bit more detail?

Designing Interview Questions
Unstructured interview Broad, roughly defined information Structured interview More specific information

Questioning Strategies

Interview Preparation Steps
Prepare general interview plan List of question Anticipated answers and follow-ups Confirm areas of knowledge Set priorities in case of time shortage Prepare the interviewee Schedule Inform of reason for interview Inform of areas of discussion

Conducting the Interview
Appear professional and unbiased Record all information Check on organizational policy regarding tape recording Be sure you understand all issues and terms Separate facts from opinions Give interviewee time to ask questions Be sure to thank the interviewee End on time

Conducting the Interview Practical Tips
Don’t worry, be happy Pay attention Summarize key points Be succinct Be honest Watch body language

Post-Interview Follow-Up
Prepare interview notes Prepare interview report Look for gaps and new questions

Interview Report INTERVIEW REPORT
Interview notes approved by: ____________ Person interviewed ______________ Interviewer _______________ Date _______________ Primary Purpose: Summary of Interview: Open Items: Detailed Notes:

Your Turn You are interviewing the director of the PC lab at your school regarding a new program to support keeping track of students’ borrowing software With a partner, write 5 questions you would ask the PC lab director Take turns having one pair of students posing the questions to another pair of students Be sure to take notes and write up the results when you have finished.

JOINT APPLICATION DESIGN (JAD)

JAD Key Ideas Allows project managers, users, and developers to work together May reduce scope creep by 50% Avoids requirements being too specific or too vague

Joint Application Design (JAD) Important Roles
Facilitator sets the meeting agenda and guides the discussion Scribe assist the facilitator by recording notes, making copies, etc. Project team, users, and management

Joint Application Design (JAD) Setting
U-Shaped seating Away from distractions Whiteboard/flip chart Prototyping tools e-JAD

JAD Meeting Room JPEG Figure 5-5 Goes Here

The JAD Session Tend to last 5 to 10 days over a three week period
Prepare questions as with interviews Formal agenda and groundrules Facilitator activities Keep session on track Help with technical terms and jargon Record group input Help resolve issues Post-session follow-up

Managing Problems in JAD Sessions
Reducing domination Encouraging non-contributors Side discussions Agenda merry-go-round Violent agreement Unresolved conflict True conflict Use humor

Questionnaire Steps Selecting participants
Using samples of the population Designing the questionnaire Careful question selection Administering the questionnaire Working to get good response rate Questionnaire follow-up Send results to participants

Good Questionaire Design
• Begin with nonthreatening and interesting questions. • Group items into logically coherent sections. • Do not put important items at the very end of the questionnaire. • Do not crowd a page with too many items. • Avoid abbreviations. • Avoid biased or suggestive items or terms. • Number questions to avoid confusion. • Pretest the questionnaire to identify confusing questions. • Provide anonymity to respondents.

Document Analysis Provides clues about existing “as-is” system
Typical documents Forms Reports Policy manuals Look for user additions to forms Look for unused form elements

Observation Users/managers often don’t remember everything they do
Checks validity of information gathered other ways Behaviors change when people are watched Careful not to ignore periodic activities Weekly … Monthly … Annual

Selecting the Appropriate Techniques

Suggest how CD Selections should proceed in eliciting requirements.
Consider steps, techniques and goals, who and how.

How would you identify possible improvements?
What possible improvements would you suggest?

Summary First Step is to determine requirements
Systems analysts use these techniques Interviews, JAD, Questionnaires, Document Analysis, and Observation.

Expanding the Domain Additional resources regarding Joint Application Development can be found at:

Objectives ■ Understand the rules and style guidelines for activity diagrams. ■ Understand the rules and style guidelines for use cases and use case diagrams. ■ Understand the process used to create use cases and use case diagrams. ■ Be able to create functional models using activity diagrams, use cases, and use case diagrams. ■ Become familiar with the use of use case points.

Business Process Modeling with Activity Diagrams
Elements of an Activity Diagram Guidelines for Creating Activity Diagrams

BPM With Activity Diagrams
A number of activities support a business process across several departments Activity diagrams model the behavior in a business process Sophisticated data flow diagrams Addresses Parallel concurrent activities and complex processes

Activity Diagram Example

Creating Activity Diagrams
1. Since an activity diagram can be used to model any kind of process, you should set the context or scope of the activity being modeled. Once you have determined the scope, you should give the diagram an appropriate title. 2. You must identify the activities, control flows, and object flows that occur between the activities. 3. You should identify any decisions that are part of the process being modeled. 4. You should attempt to identify any prospects for parallelism in the process. 5. You should draw the activity diagram.

USE-CASE DESCRIPTIONS

Key Ideas A use case illustrates the activities that are performed by users of a system. Use cases are logical models -- they describe the activities of a system without specifying how the activities are implemented.

What are Use-Case Descriptions?
Describe basic functions of the system What the user can do How the system responds Use cases are building blocks for continued design activities.

How Are Use-Cases Created?
Two steps: Write text-based case descriptions Translate descriptions into diagrams Describes one and only one function, but may have multiple paths. Developed working with users for content.

Types of Use-Cases Overview versus detail
■ The use case represents an important business process. ■ The use case supports revenue generation or cost reduction. ■ Technology needed to support the use case is new or risky and therefore will require considerable research. Essential versus real

Elements of a Use-Case Description
Use Case Name: ID: Importance Level: Primary Actor: Use Case Type: Stakeholders and Interests: Brief Description: Trigger: Relationships: (Association, Include, Extend, Generalization) Normal Flow of Events: Subflows: Alternate/Exceptional Flows:

Guidelines for Creating Use-Case Descriptions
Write each step in “SVDPI” form Clarify initiator and receivers of action Write from independent observer perspective Write at same level of abstraction Ensure a sensible set of steps Apply KISS principle liberally Write repeating instructions after the set of steps to be repeated.

Your Turn How would you make requirements gathering (interviews, questionnaires, observation, and document analysis) more effective by knowing that eventually you will be creating use-case descriptions and diagrams?

USE-CASE DIAGRAMS

Syntax for Use-Case Diagram

The Use-Case Diagram for Appointment System

Use-Case Diagram with Specialized Actor

Extend and Include Relationships

CREATING USE-CASE DESCRIPTIONS AND USE-CASE DIAGRAMS

Major Steps in Writing Use-Cases
Case Diagrams Identify the major use-cases Expand the major use-case Confirm the major use-cases Create the use-case diagram As can be seen by comparing this list to figure 6-7, it is a very high level summary. Teachers of this material might want to spend significant time reviewing what happens in each of these steps.

Identifying the Major Use-Cases
Identify the system’s boundaries List the primary actors List the goals of each primary actor Identify and write the major use- cases Carefully review use-cases

Writing Effective Use-Case Descriptions

Expand the Major Use-Cases
Choose one major use-case to expand Fill in details on the use-case template Fill in the steps of the normal flow of events Normalize the size of each step Describe alternate or exceptional flows Simplify and organize as necessary

Confirm the Major Use Cases
Review the current set Consider semantics and syntax Helpful to involve the users Iterate the entire set of steps until all use cases are defined

Create the Use-Case Diagram
Start with system boundary Place elements in order to be easy to read Place actors on the diagram Conclude by connecting actors to use cases by lines

Selecting the Appropriate Techniques
Interviews JAD Questionnaires Document Observation Analysis Type of As-Is As-Is As-Is As-Is As-Is Information Improve Improve. Improve. To-Be To-Be Depth of High High Medium Low Low Information Breadth of Low Medium High High Low Integration Low High Low Low Low of Info. User Medium High Low Low Low Involvement Cost Medium Low Low Low Low- Medium Medium

Refining Project Size with Case Points
Create essential use cases and use case diagram Determine Unadjusted Actor Weighting Table Obtain Unadjusted Use Case Weight Total Compute value of Unadjusted Use Case Points

Identify the major use-cases
Expand the major use-case Confirm the major use-cases Create the use-case diagram

Your Turn Create a set of use cases for campus housing. Consider the steps in registering for campus housing, in being assigned to a particular unit, to being matched with roommates, to moving in.

Expanding the Domain Additional resources regarding use-cases and many other object-oriented development topics can be found at:

Summary Use-case descriptions are the basis for further analysis and design. They are created based on 7 guidelines and 13 steps. Use-case diagrams present a graphical overview of the main functionality of a system.

Structural Modeling Chapter 7

Key Ideas A structural or conceptual model describes the structure of the data that supports the business processes in an organization.. The structure of data used in the system is represented through CRD cards, class diagrams, and object diagrams.

STRUCTURAL MODELS

Purpose of Structural Models
Reduce the “semantic gap” between the real world and the world of software Create a vocabulary for analysts and users Represent things, ideas, and concepts of importance in the application domain

Classes Templates for creating instances or objects Typical examples:
Concrete Abstract Typical examples: Application domain, user interface, data structure, file structure, operating environment, document, and multimedia classes

Attributes Units of information relevant to the description of the class Only attributes important to the task should be included

Operations Action that instances/objects can take
Focus on relevant problem- specific operations (at this point)

Relationships Generalization Aggregation Association
Enables inheritance of attributes and operations Aggregation Relates parts to wholes Association Miscellaneous relationships between classes

Your Turn What classes, attributes, and operations that would be required to describe the process of registration for campus housing?

CLASS-RESPONSIBILITY-COLLABORATION CARDS

Responsibilities and Collaborations
Knowing Doing Collaboration Objects working together to service a request

A CRC Card

Back of CRC Card

CLASS DIAGRAMS

Example Class Diagram

Class Diagram Syntax A CLASS Class 1 -attribute +operation ()
AN ATTRIBUTE AN OPERATION AN ASSOCIATION Class 1 -attribute +operation () Attribute name/ derived attribute name operation name () 1..* 0..1 ______verb phrase____

More on Attributes Derived attributes
/age, for example can be calculated from birth date and current date Visibility Public Protected Private

More on Operations Constructor Creates object Query
Makes information about state available Update Changes values of some or all attributes

Generalization and Aggregation
Generalization shows that a subclass inherits from a superclass Doctors, nurses, admin personnel are kinds of employees Aggregation classes comprise other classes Health team class comprised of doctor, nurses, admin personnel classes

More on Relationships Class can be related to itself (role)
Multiplicity Exactly one, zero or more, one or more, zero or one, specified range, multiple disjoint ranges Association class

Simplifying Class Diagrams
The view mechanism shows a subset of information Packages show aggregations of classes (or any elements in UML)

Object Diagrams

CREATING CRC CARDS AND CLASS DIAGRAMS

Object Identification
Textual analysis of use-case information Nouns suggest classes Verbs suggest operations Creates a rough first cut Common object list Incidents Roles

Patterns Useful groupings of classes that recur in various situations
Transactions Transaction class Transaction line item class Item class Location class Participant class

Steps for Object Identification and Structural Modeling
1. Create CRC cards by performing textual analysis on the use-cases. 2. Brainstorm additional candidate classes, attributes, operations, and relationships by using the common object list approach. 3. Role-play each use-case using the CRC cards. 4. Create the class diagram based on the CRC cards. 5. Review the structural model for missing and/or unnecessary classes, attributes, operations, and relationships. 6. Incorporate useful patterns. 7. Review the structural model.

Create CRC cards. Examine common object lists. Role-play the CRC cards. Create the class diagram. Review the class diagram. Incorporate patterns. Review the model.

Summary CRC cards capture the essential elements of a class.
Class and object diagrams show the underlying structure of an object-oriented system. Constructing the structural model is an iterative process involving: textual analysis, brainstorming objects, role playing, creating the diagrams, and incorporating useful patterns.

Expanding the Domain A quirky and interesting tutorial regarding CRC cards can be found at: butler/tutorials/winter96/crc_b/

Behavioral Modeling Chapter 8

Key Ideas Behavioral models describe the internal dynamic aspects of an information system that supports business processes in an organization Key UML behavioral models are: sequence diagrams, collaboration diagrams, and statechart diagrams

Objectives ■ Understand the rules and style guidelines for sequence and communication diagrams and behavioral state machines. ■ Understand the processes used to create sequence and communication diagrams and behavioral state machines. ■ Be able to create sequence and communication diagrams and behavioral state machines. ■ Understand the relationship between the behavioral models and the structural and functional models.

BEHAVIORAL MODELS

Purpose of Behavioral Models
Show how objects colaborate to support each use case in the structural model Depict the internal view of the business process To show the effects of varied processes on the system

Interaction Diagram Components
Objects Instantiation of a class Has attributes that describe an object Operations Send and receive messages Messages Tell object to execute a behavior

Sequence Diagrams Illustrate the objects that participate in a use-case Show the messages that pass between objects for a particular use-case

Sequence Diagram Syntax
AN ACTOR AN OBJECT A LIFELINE A FOCUS OF CONTROL A MESSAGE OBJECT DESTRUCTION anObject:aClass aMessage() x

Building a Sequence Diagram
Determine the context of the sequence diagram Identify the participating objects Set the lifeline for each object Add messages Place the focus of control on each object’s lifeline Validate the sequence diagram

Normal Flow of Events: 1. Customer submits a search request to the system. 2. The system provides the customer a list of recommended CDs. 3. The customer chooses one of the CDs to find additional information. 4. The system provides the customer with basic information & CD Reviews 5. The customer calls the maintain order use case. 6. The customer iterates over 3 through 5 until finished shopping. 7. The customer executes the checkout use case. 8. The customer leaves the website.

Collaboration Diagrams
Essentially an object diagram that shows message passing relationships instead of aggregation or generalization associations. Emphasize the flow of messages among objects, rather than timing and ordering of messages

Example Collaboration Diagram

Example Sequence Diagram
Actor Object Association Message Frame

Communication Diagrams
1. Set the context. 2. Identify which objects (actors) and the associations between the objects participate in the collaboration. 3. Layout the communication diagram. 4. Add messages. 5. Validate the communication diagram.

“CRUD” Analysis Example

Building a Collaboration Diagram
Determine the context of the collaboration diagram Identify the participating objects and their associations Layout objects and associations Add messages Validate the sequence diagram

Behavioral State Machines
The behavioral state machine is a dynamic model that shows the different states of the object and what events cause the object to change from one state to another, along with its responses and actions.

Elements of a Behavioral State Machine
States Events Transitions Actions Activities

Example Behavioral State Machine Diagram

Behavioral State Machine Diagram Syntax
A STATE AN INITIAL STATE A FINAL STATE AN EVENT A TRANSITION A Frame

Building Behavioral State Machine Diagrams
Set the context Identify the initial final, and stable states of the object Determine the order in which the object will pass through stable states Identify the events, actions, and guard conditions associated with the transitions Validate the statechart diagram

Your Turn What distinguishes the sequence diagram, the collaboration diagram, and the behavioral state machine diagram? For what sort of new applications might you need to develop all of these? Are there any new applications that would not need all of these diagrams for full development?

Summary Sequence diagrams illustrate the classes that participate in a use case and the messages that pass between them. Collaboration diagrams provide a dynamic view of the object-oriented system and accentuate message passing between collaborating actors and objects. Behavioral State Machine diagrams show the different states that a single class passes through in response to events.

Expanding the Domain Each year the Association for Computing Machinery (ACM) sponsors a conference on object oriented programming. For details about future conferences and other ACM programs check:

Moving On To Design Chapter 9

Key Ideas The purpose of the analysis phase is to figure out what the business needs. The purpose of the design phase is to figure out how to provide it. The steps in both analysis and design phases are highly interrelated and may require much “going back and forth”

Objectives ■ Understand the transition from analysis to design.
■ Understand the use of factoring, partitions, and layers. ■ Be able to create package diagrams. ■ Be familiar with the custom, packaged, and outsource design alternatives. ■ Be able to create an alternative matrix.

REVISITING THE OBJECT-ORIENTED APPROACH TO ANALYSIS AND DESIGN

OO Analysis and Design Foundation
Use-case driven Architecture centric Iterative and incremental

Combining Three Views Functional Static Dynamic

A “Minimalist” Approach
Planning Gathering requirements Perform a series of “builds” Use results of each build as feedback for design and implementation

EVOLVING THE ANALYSIS MODELS INTO DESIGN MODELS

Avoid Classic Design Mistakes
Reducing design time Feature creep Silver bullet syndrome Switching tools in mid-project

Factoring Creating modules that account for similarities and differences between units of interest New classes Generalization Aggregation Abstracting Refinement

Partitions and Collaborations
Creating “subsystems” or larger units Grouping units that collaborate May have collaboration among units or partitions The more messages or contracts between objects, the more likely they are in the same partition

Purpose of Layers Model-view-controller (MVC) architecture
Models implement application logic Views and controllers do user interfaces Separating application logic from user interface logic

Layers

PACKAGES AND PACKAGE DIAGRAMS

Packages Logical grouping of UML elements Simplifies UML diagrams
Groups related elements into a single higher-level element Dependency relationships Shows a dependency between packages

Syntax for Package Diagram
A PACKAGE Package A DEPENDENCY RELATIONSHIP

Package Diagram of Dependency Relationships Among Layers

Modification Dependency
Indicates that a change in one package could cause a change to be required in another package. Example: A change in one method will cause the interface for all objects of this class to change. Therefore, all classes that have objects that send messages to the instances of the modified class could have to be modified.

Package Diagram of Appointment System

Steps for Identifying Packages and Building Package Diagrams
Set the context Cluster classes together based on shared relationships Model clustered classes as a package Identify dependency relationships among packages Place dependency relationships between packages

Package Diagram of the PD Layer for the Appointment System

DESIGN STRATEGIES

Custom Development Allows for meeting highly specialized requirements
Allows flexibility and creativity in solving problems Easier to change components Builds personnel skills May tax firm’s resources May add significant risk

Packaged Software Software already written May be more efficient
May be more thoroughly tested and proven May range from components to tools to whole enterprise systems Must accept functionality provided May require change in how the firm does business May require significant “customization” or “workarounds”

System Integration The process of combining packages, legacy systems, and new software Key challenge is integrating data Write data in the same format Revise existing data formats Develop “object wrappers”

Outsourcing Hire external firm to create system May have more skills
May extend existing resources Never outsource what you don’t understand Carefully choose vendor Prepare contract and payment style carefully

Outsourcing Guidelines
Keep lines of communication open with outsourcer Define and stabilize requirements before signing a contract View outsourcing relationship as partnership Select outsource vender carefully Assign person to manage relationship Don’t outsource what you don’t understand Emphasize flexible requirements, long-term relationships, and short-term contracts

Selecting a Design Strategy
Business need In-house experience Project skills Project management Time frame

Your Turn Suppose that your university is interested in creating a new course registration system that can support Web-based registration? What should the university consider when determining whether to invest in a custom, packaged, or outsourcing system solution?

DEVELOPING THE ACTUAL DESIGN

The Alternative matrix
Combines several feasibility analyses into one grid Revisits technical, economic, and organizational feasibility

Request for Proposals Description of the system you propose to be built Vendors, developers, service providers respond with proposals including how they will address needs as well as stating cost and time requirements.

Summary When evolving analysis into design models, it is important to review the analysis models then add system environment information. Packages and package diagrams help provide structure and less complex views of the new system. Custom building, packages, and outsourcing are alternative ways of creating the new system. The alternative matrix can help with the selection of a design strategy.

Expanding the Domain Smalltalk is an object-oriented programming language with many very loyal adherents. For more information check the site at: html

REVISITING THE BASIC CHARACTERISTICS OF OBJECT-ORIENTATION

Levels of Abstraction

Elements Classes Objects Attributes States Methods Messages

Encapsulation Hiding the content of the object from outside view
Communication only through object’s methods Key to reusability

Polymorphism Same message triggers different methods in different objects Dynamic binding means specific method is selected at run time Implementation of dynamic binding is language specific Need to be very careful about run time errors Need to ensure semantic consistency

Inheritance Single inheritance -- one parent class
Multiple inheritance -- multiple parent classes Redefinition and inheritance conflict Most inheritance conflicts are due to poor classification

Rumbaugh’s Rules Query operations should not be redefined
Methods that redefine inherited ones should only restrict the semantics of the inherited ones The underlying semantics of the inherited method should never be changed The signature (argument list) of the inherited method should

Additional Inheritance Conflicts
Two inherited attributes or methods have same name and semantics Two inherited attributes or methods have different name, but same semantics Two inherited attributes or methods have same name and different semantics

Inheritance Conflicts with Multiple Inheritance

Design Criteria Chapter 10

Coupling Indicates the interdependence or interrelationships of the modules Interaction coupling Relationships with methods and objects through message passage

Interaction Coupling

Types of Method Cohesion

Ideal Class Cohesion Contain multiple methods that are visible outside the class Have methods that refer to attributes or other methods defined with the class or its superclass Not have any control-flow coupling between its methods

Types of Class Cohesion

Connascence Two modules (classes or methods) are so intertwined, that if you make a change in one, it is likely that a change in the other will be required

Connascence and Encapsulation Levels
Minimize overall connascence by eliminating any unnecessary connascence throughout the system, Minimize connascence across any encapsulation boundaries, such as method boundaries and class boundaries, Maximize connascence within any encapsulation boundary.

Object Design Activities

Types of Connascence

Additional Specification
Ensure the classes are both necessary and sufficient for the problem Finalize the visibility of the attributes and methods of each class Determine the signature of every method of each class Define constraints to be preserved by objects

Identifying Opportunities for Reuse
Analysis patterns Design patterns Frameworks Libraries components

Sample Design Pattern

Restructuring the Design
Factoring Separate aspects of a method or class into a new method or class Normalization Identifies classes missing from the design Challenge inheritance relationships to ensure they only support a generalization/specialization semantics

Optimizing the Design Review access paths between objects
Review each attribute of each class Review fan-out of each method Examine execution order of statements Create derived activities

Map Problem Domain Classes to Implementation Languages
Single-Inheritance Language Convert relationships to association relationships Flatten inheritance hierarchy by copying attributes and methods of additional superclass(es)

Implement in Object-Based Language
Factor out all uses of inheritance from the problem domain class design

Your Turn Dentist office appointment system
Assume that you now know that the system must be implemented in Visual Basic 6, which does not support implementation inheritance. As such, redraw the class diagram factoring out the use of inheritance in the design by applying the above rules.

Implement in a Traditional Language
Stay away from this! But if necessary, factor out all uses of Polymorphism Dynamic binding Encapsulation Information hiding

Constraints and Contracts

Types of Constraints Pre-Conditions Post-condition Invariants
A constraint to be met to allow a method to execute Post-condition A constraint to be met after a method executes Invariants Constraints that must be true for all instances of a class

Invariants

Elements of a Contract

Your Turn Using the CRC card in Figure , the class diagram in Figure 10-12, and the sample contract format in Figure as guides, create contracts for the Calculate subtotal, Calculate tax, Calculate shipping, and Calculate total methods.

Method Specification

Method Specification General information Events Message passing
Algorithm specification Structured English Pseudocode UML activity diagram

Applying the Concepts at CD Selections

Revised CD Selections Class Diagram

Back of CD CRC Card

Get Review Method Contract

Revised Package Diagram

Systems Analysis and Design With UML 2.0 An Object-Oriented Approach, Second Edition Chapter 11: Data Management Layer Design Alan Dennis, Barbara Wixom, and David Tegarden © 2005 John Wiley & Sons, Inc.

Data Management Layer Design
Chapter 11

Objectives Become familiar with several object-persistence formats.
Be able to map problem domain objects to different object-persistence formats. Be able to apply the steps of normalization to a relational database. Be able to optimize a relational database for object storage and access. Become familiar with indexes for relational databases. Be able to estimate the size of a relational database. Be able to design the data access and manipulation classes.

Data Management Layer Choose object-persistence format to support the system Problem domain objects drive object storage design Design of Data Storage Must optimize processing efficiency Data access and manipulation Separate problem domain classes from storage format Handle all communication with the database

Object Persistence Formats
Files (Sequential and Random) Relational databases Object-relational databases Object-oriented databases

Customer Order File

Sequential and Random Access Files
Sequential access files allow sequential operations Read, write, and search Efficient for report writing Searches are not efficient because an average of 50% of records have to be accessed Two versions Ordered unordered

Random Access Files Allow only random or direct file operations
Good for finding and updating a specific object Inefficient report writing

Application File Types
Master Files Look-up files Transaction files Audit file History file

Relational Databases Collection of tables Tables related to each other
Comprised of fields that define entities Primary key has unique values in each row of a table Foreign key is primary key of another table Tables related to each other Primary key field of a table is a field of another table and called a foreign key Relationship established by a foreign key of one table connecting to the primary key of another table

Customer Order Database
Please Eliminate this line

Database Management System (DBMS)
Software that creates and manipulates a database RDBMS is a DBMS for a relational database RDBMS usually support Referential Integrity

Referential Integrity
the idea of ensuring that values linking the tables together through the primary and foreign keys are valid and correctly synchronized.

Referential Integrity Example
Cust. ID is a primary key for the customer table Cust. ID is a foreign key for the order table A violation of referential integrity would happen if an order was entered in the order table for a Cust. ID that had not been entered into the customer table first An RDBMS prevents such a record from being entered

Example of Referential Integrity

Structured Query Language (SQL)
Standard language for accessing data in tables SQL Commands Create, edit, and delete tables Add, edit, and delete data Display data from one or more related tables Display data computed from data in one or more related tables

Object-Relational Databases
Relational database management systems with extensions that handle object storage in the relational table structure This is done by user defined types Example: Create a map data type

Vendors Support ORDBMS
SQL designed for simple data types Vendors extend SQL to handle user data types in Object Relational Databases Usually they don’t support most object oriented features e.g. inheritance

Object-Oriented Databases (OODBMS)
Add persistence extensions to an object-oriented programming language Create a entirely separate database management system

OODBMS Terminology Extent is a collection of objects
Set of instances associated with a particular class (RDBMS table) Each instance of a class has a unique identifier called an object ID Referential integrity still important Supports a form of inheritance

OODBMS Support Allow repeating groups or multivalued attributes
Supports multimedia or other complex data applications CAD/CAM Financial services Geographic information systems Health care

Major Strengths & Weaknesses
Files Very efficient for given task Manipulation done by OOPL Redundant data usually results RDBMS Proven commercial technology Handle diverse data No support for object orientation

More Strengths and Weaknesses
ORDBMS Inherit RDBMS strengths Support complex data types Limited support for object-orientation (vendor dependent) OODBMS Support object-orientation directly Still maturing (lacks skilled labor and may have a steep learning curve)

Criteria for Object Persistence Formats
Data types supported Types of application systems (transaction processing, DSS, …) Existing Storage Formats Future Needs Other miscellaneous Criteria (cost, concurrency control, …)

Mapping Objects to Object-Persistence Formats

Multiple Inheritance Effect Rules
Results when you have more than one super class Rule 1a. Add an attribute(s) to the OODBMS class to represent the additional super class Rule 1b. Flatten the inheritance hierarchy and remove additional super classes from the design

Mapping to Single I-B OODBMS

Using Rule 1a Added an attribute to Class1-OODBMS that represents an association with Super-Class2-OODBMS, Added attributes to Class2-OODBMS that represents an association with Super-Class2-OODBMS, Added a pair of attributes to SuperClass2-OODBMS that represents an association with Class1-OODBMS and Class2-OODBMS, for completeness sale, and Added associations between Class2-OODBMS and SuperClass2-OODBMS and Class1-OODBMS and SuperClass2-OODBMS that have the correct multiplicities and the XOR constraint explicitly shown.

Mapping PDO to ORDBMS

Mapping Table to PD Classes

Mapping PD Objects to RDBMS Schema
Rule 1: Map all concrete problem domain classes to the RDBMS tables. Rule 2: Map single valued attributes to columns of the tables. Rule 3: Map methods to stored procedures or to program modules. Rule 4: Map single-valued aggregation and association relationships to a column that can store the key of the related table Rule 5: Map multi-valued attributes and repeating groups to new tables and create a one-to-many association from the original table to the new ones. Rule 6: Map multi-valued aggregation and association relationships to a new associative table that relates the two original tables together. Copy the primary key from both original tables to the new associative table Rule 7: For aggregation and association relationships of mixed type, copy the primary key from the single-valued side (1..1 or 0..1) of the relationship to a new column in the table on the multi-valued side (1..* or 0..*) of the relationship that can store the key of the related table Rule 8a: Ensure that the primary key of the subclass instance is the same as the primary key of the superclass.. OR Rule 8b: Flatten the inheritance

Mapping RDBMS Tables to Problem Domain Classes

Optimize RDBMS Object Storage
No redundant data Wastes space Allow more room for error Few null values in tables Difficult to interpret

Example of Non-normalized Data

Normalization

Normalization Example
Original Model

3NF Normalized Model

Problems with RDBMS To access data in multiple tables, the tables must be joined This can result in many database operations and lead to huge tables and slow processing

Speeding up access Denormalization – Adds data from one table to another in order to speed processing and eliminate a join operation Example: Add customer last name to order table to avoid joining order to customer to get just last name

Example

Denormalization Candidates
Lookup Tables one-to-one relationships include a parent entity’s attributes in its child entity on the physical data model

Clustering Interfile clustering
Arrange records on storage media so that similar records are stored close together inter-file cluster would be similar to storing peanut butter, jelly, and bread next to each other in a grocery store since they are often purchased together.

Indexing An index in data storage is like an index in the back of a textbook; it is a mini table that contains values from one or more columns in a table and the location of the values within the table. A query can use an index to find the locations of only those records that are included in the query answer, and a table can have an unlimited number of indexes but too many can add overhead

Indexing Example

Estimating Data Storage Size
sum the values of the average width of each column (field) to find total record size Add overhead (vendor may provide an estimate) Estimate the number of records you plan to have in the database

Data Sizing Example

DESIGNING DATA ACCESS AND MANIPULATION CLASSES
Design data access and manipulation classes Prevent data management functionality from creeping into the problem domain classes

Mapping PD Objects

CD Selections Example Most of the data would be text and numbers
Thus a relational database would be able to handle the data effectively However, images for the catalog require complex data objects for sound and video

Looking at the Data Needs

Object Persistent Design

Optimizing Application

Problem Domain Layer

Summary Choose an object-persistent format
Files (sequential or Random Access) Databases (RDBMS, ORDBMS, OODBMS) Map problem domain objects to Data Optimizing object storage Normalization Denormalization, clustering, Indexes Design Data Access and Manipulation Classes

Systems Analysis and Design
Alan Dennis, Barbara Wixom, and David Tegarden John Wiley & Sons, Inc. Slides by Fred Niederman PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.

Objectives ■ Understand several fundamental user interface design principles. ■ Understand the process of user interface design. ■ Understand how to design the user interface structure. ■ Understand how to design the user interface standards. ■ Understand commonly used principles and techniques for navigation design. ■ Understand commonly used principles and techniques for input design. ■ Understand commonly used principles and techniques for output design. ■ Be able to design a user interface.

Principles for User Interface Design

Principles

Key Definitions The navigation mechanism provides the way for users to tell the system what to do The input mechanism defines the way the system captures information The output mechanism defines the way the system provides information to users or other systems

Key Definitions The graphical user interface (GUI) is the most common type of interfaces most students are likely to use personally and for developing systems.

Use Scenario Development

Window Navigation Diagram

Interface Standards Design
The interface standards are the basic design elements that are common across the individual screens, forms, and reports within the system.

Interface Design Prototyping
Storyboard HTML Prototype Language Prototype Interface Evaluation Heuristic Walkthrough Interactive Formal Usability Testing

Basic Principles Assume users Have not read the manual
Have not attended training Do not have external help readily at hand All controls should be clear and understandable and placed in an intuitive location on the screen.

Basic Principles Prevent mistakes Limit choices
Never display commands that can’t be used (or “gray them out”) Confirm actions that are difficult or impossible to undo Simplify recover from mistakes Use consistent grammar order

Types of Navigation Control
Languages Command language Natural language Menus Generally aim at broad shallow menu Consider using “hot keys” Direct Manipulation Used with icons to start programs Used to shape and size objects May not be intuitive for all commands

A Traditional Menu in a UNIX System

Common Types of Menus

Example of an Image Map

Types of Menus When Would You Use Each of These Menu Types?
Menu bar Drop-down menu Pop-up menu Tab menu Toolbar Image map When Would You Use Each of These Menu Types?

Message Tips Should be clear, concise, and complete
Should be grammatically correct and free of jargon and abbreviations (unless they are the users) Avoid negatives and humor

Types of Messages When Would You Use Each of These Message Types?
Error message Confirmation message Acknowledgment message Delay message Help message When Would You Use Each of These Message Types?

An Example of Crafting an Error Message

Your Turn Pretend that you are designing the new interface to a career services system at your university. How would you incorporate the basic principles of input design into your interface design?

Basic Principles The goal is to simply and easily capture accurate information for the system Reflect the nature of the inputs Find ways to simplify their collection

Online versus Batch Processing
Online processing immediately records the transaction in the appropriate database Batch processing collects inputs over time and enters them into the system at one time in a batch Batch processing simplifies data communications and other processes, but means that inventory and other reports are not accurate in real time

Capture Data at the Source
Reduces duplicate work Reduces processing time Decreases cost Decreases probability of error

Source Data Automation
Can be obtained by using the following technologies: bar code readers optical character recognition magnetic stripe readers smart cards How can internet be used for source data automation?

Minimize Keystrokes Never ask for information that can be obtained in another way List selection is more efficient than entering information Use default values where possible

Types of Inputs Data items linked to fields Text Numbers
Selection boxes

Types of Input Boxes

Types of Selection Boxes
Types of Boxes Check box Radio button On-screen list box Drop-down list box Combo box Slider When Would You Use Each of These Box Types?

Types of Input Validation
Types of Validation Completeness check Format check Range check Check digit check Consistency check Database checks When Would You Use Each of These Validation Methods?

Your Turn Consider a Web form that a student would use to input student and resume information into a career services application. Sketch out how this form would look and what data fields would be used What validity checks would you need? Note to faculty using these slides: The essence of function point analysis is that even when you start with purely arbitrary numbers, as you continue to apply function points project after project, your estimation should become more and more accurate. At some point more accurate estimation lets you allocate the correct amount of resource -- not being too wasteful, nor experiencing staffing “stock-outs”. It also helps the IT department show that it is performing according to reasonable historic estimates rather than arbitrary deadlines and price allocations.

Basic Principles Understand report usage Reference or cover-to-cover?
Frequency? Real-time or batch reports? Manage information load All needed information, no more Minimize bias

Bias in Graphs

Types of Reports When Would You Use Each of These Report Types?
Detail reports Summary report Turnaround document Graphs When Would You Use Each of These Report Types?

Report Media Electronic Versus Paper

Your Turn Under what conditions would you be most likely to replace reports on paper with ones delivered electronically? When might you NOT want to make the change? Note to faculty using these slides: The essence of function point analysis is that even when you start with purely arbitrary numbers, as you continue to apply function points project after project, your estimation should become more and more accurate. At some point more accurate estimation lets you allocate the correct amount of resource -- not being too wasteful, nor experiencing staffing “stock-outs”. It also helps the IT department show that it is performing according to reasonable historic estimates rather than arbitrary deadlines and price allocations.

Summary The fundamental goal of navigation design is to make the system as simple to use as possible The goal of input mechanism is to simply and easily capture accurate information The goal of the output mechanism is to provide accurate information to users that minimize information overload and bias

Expanding the Domain For many years, the University of Maryland has been a leader in research for ideas in human-computer interfaces. For more information investigate:

Systems Analysis and Design With UML 2.0 An Object-Oriented Approach, Second Edition Chapter 13: Physical Architecture Layer Design Alan Dennis, Barbara Wixom, and David Tegarden © 2005 John Wiley & Sons, Inc.

Physical Architecture Layer Design
Chapter 13

Objectives Understand the different physical architecture components.
Understand server-based, client-based, and client server physical architectures. Be familiar with distributed objects computing. Be able to create a network model using a deployment diagram. Understand how operational, performance, security, cultural, and political requirements affect the design of the physical architecture layer. Be familiar with how to create a hardware and software specification.

Physical Architecture
Software Components Data Storage Data Access Logic Application logic Presentation logic Hardware Components Client computers Servers Connecting network

Server Based Architecture
Client is a terminal Server has functions of Presentation logic Application logic Data access logic Data storage

Server Based Architecture

Client-Server Architectures
Thin Client/Fat Server Client is little more than a terminal Server handles all processing Fat Client/Thin Server Client does all processing Server may just store data

Thick Client

Server has Data 2-Tiered Architecture

Client has Presentation Logic
3-tiered Architecture

N-tiered Architecture

Client-Server Benefits
Scalable Support multiple clients and servers Using Internet Standards Presentation logic can be separated Multiple servers make for a generally more reliable network

Middleware Middleware is a type of system software designed to translate between different vendors’ software. Middleware is installed on both the client computer and the server computer. The client software communicates with the middleware that can reformat the message into a standard language that can be understood by the middleware that assists the server software

Client-Server Limitations
Complexity Updating the network computers is more complex

Distributed Objects Computing
This is commonly called middleware DOC allows the developer to simply concentrate on the users, objects, and methods of an application instead of worrying about which server contains which set of objects. The client object simply requests the “network” to locate and execute the server object’s method.

Competing Approaches Object Management Group Sun Microsoft
Common Object Request Broker Architecture (CORBA) Sun Enterprise JavaBeans (EJB) Java 2 Enterprise Edition (J2EE) Microsoft Distributed Component Object Model (DCOM) .net initiative

Selecting a Physical Architecture
Cost of Infrastructure Cost of Development Ease of Development Interface Capabilities Control and Security Scalability

Characteristics

Deployment Diagram Components
Nodes Any piece of hardware in the model Artifacts Piece of the information system such as software component, database table, … Communication paths Links between nodes of the network

Deployment Diagram

Deployment Diagram (cont.)

Diagram Examples

The Network Model The network model is a diagram that shows the major components of the information system (e.g., servers, communication lines, networks) and their geographic locations throughout the organization.

Network Model Example

NonFunctional Requirements
Operational Specify the operating environment Technical Environment Type of hardware and software System Integration Interaction with other systems Portability Response to changing environments Maintainability Expected business requirement changes

Performance Requirements
Speed Response time of the system Transaction update time Capacity Number of users Volume of data Availability and Reliability Specify available times Permissible failure rate Security Protect from disruption and data loss

Security

Cultural and Political
Multilingual Customization Making unstated norms explicit Legal requirements

Cultural and Political Rqrts.

Synopsis

Sample Specifications

CD System –Op. Rqrts.

CD Systems - Performance

CD Systems – Security/Cultural

Summary Physical Architecture Layer Infrastructure design
Choose server vs. client-server Middleware Assess strengths and weaknesses Infrastructure design Various clients Network equipment Nonfunctional Requirements Operational Performance Security Hardware and software specification

Alan Dennis, Barbara Haley Wixom, and David Tegarden Chapter 14: Construction Copyright 2005 John Wiley & Sons, Inc. PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved.

Key Concepts ■ Be familiar with the system construction process.
■ Understand different types of tests and when to use ■ Understand how to develop documentation.

Managing Programming Assigning Programmers Coordinating Activities
Managing the Schedule 492

Coordinating Activities
Regular Project Meetings Follow standards File naming Forms to be completed Programming guidelines Coordinate traceability of implementation to requirements

Managing the Schedule Control scope creep Manage schedule slippage
Create a risk assessment

Avoid Implementation Mistakes
Research-oriented development Using low-cost personnel Lack of code control Inadequate testing

Designing Tests Unit tests Integration tests System tests
Acceptance tests

Testing and Object Orientation
Encapsulation and information hiding Polymorphism and dynamic binding Inheritance reuse

Unit or Class Tests Focus on a single unit – the class
Black-box Testing White-box Testing Develop tests for each contract of a class Test for initial conditions Possibly test for random inputs

Integration Tests How a set of classes work together
Classes pass unit tests first Interface testing Use-Case Testing Interaction Testing System Interface Testing

System Testing Requirements Usability Security Performance
Documenation

Acceptance Testing Alpha Beta
Conducted by users to ensure they accept the system Beta Users use real data, not test data

Developing Documentation
System Documentation Produced by systems analysis and design process Automate documentation for classes and methods User Documentation User Manuals Training Manuals Online Help Systems

Online Documentation Strengths
Facilitates searching Same information can be presented in different formats Provide interaction with users using links or “tool-tips” Less expensive to distribute

Designing Documentation Structure
Table of Contents Navigation Controls lead user to Documentation topics How to perform certain tasks Definitions of important terms

Online Documentation Example

Documentation Writing
Use Active Voice E-prime Style Consistent terms Simple language Friendly language Parallel grammatical structures Correct use of steps Short paragraphs

Applying Concepts at CD Selections
Managing Programming 3 programmers Testing Unit Test – Blackbox tests Integration – User Interfaces System – Requirements, security, performance, and Usability Acceptance – Alpha and Beta

Develop User Documentation
Reference Documents for web interface and system management components Help topics Documentation Component Table of Contents Index Find or search Links to definitions

Summary Assign programmers and coordinate their activities
Plan for the testing of all aspects of the application Write the documentation for both the systems side and the user aspect

Installation ■ Be familiar with the system installation process.
■ Understand different types of conversion strategies and when to use them. ■ Understand several techniques for managing change. ■ Be familiar with post-installation processes.

Key Ideas Transitioning to new systems involves managing change from pre-existing norms and habits. Change management involves: Unfreezing -- loosening up peoples’ habits and norms Moving -- transition from old to new systems Refreezing -- institutionalize and make efficient the new way of doing things

Implementing Change

Key Ideas Post-implementation activities include providing:
System support, such as help desks Systems maintenance, fixing bugs and providing improvements Project assessment, learning how to improve from project experiences

CONVERSION

Migration Planning What activities will be performed when and by whom
Technical aspects Installing hardware and software Converting data Organizational aspects Training users on the system Motivating employees to use the new system to aid in their work

Elements of a Migration Plan

Conversion Styles Direct conversion Parallel conversion
The new system instantly replaces the old Parallel conversion For a time both old and new systems are used. The old is abandoned when the new is proven fully capable

Conversion Location Pilot conversion Phased conversion
One or more locations are converted to work out bugs before extending to other locations Phased conversion Locations are converted in sets Simultaneous conversion All locations are converted at the same time

Conversion Modules Whole system conversion Modular conversion
All modules converted in one step Modular conversion When modules are loosely associated, they can be converted one at a time

Conversion Strategies

Key Factors in Selecting a Conversion Strategy
Risk Seriousness of consequences of remaining bugs Cost Parallel requires paying for two systems for a period of time Simultaneous requires more staff to support all locations Time Parallel, phased, and modular require more time

Characteristics of Conversion Strategies

Your Turn Suppose you are leading the conversion from one word processor to another at your university. Which conversion strategy would you use? Suppose you are converting to a new web-based course registration system? Which conversion strategy would you use for this?

CHANGE MANAGEMENT

Key Roles in Change Management
The sponsor is the business person who initiated the request for the new system The change agent is the person(s) who lead the change effort The potential adopter(s) are the people who must change.

Change Management Actors

Understanding Resistance to Change
What is good for the organization, is not necessarily good for the individuals who work there Cost versus benefit of transition as well as of to-be system Adapting to new work processes requires effort, for which there may be no additional compensation

Costs and Benefits of Change

Revising Management Policies
No computer system will be successfully adopted unless management policies support its adoption Management tools for supporting adoption Standard operating procedures (SOPs) Measurements and rewards Resource allocation

Your Turn Identify and explain three standard operating procedures for the course in which you are using this book Discuss whether they are formal or informal

Assessing Costs and Benefits
Factors in Successful Change Benefits of to-be system Certainty of benefits Costs of transition Certainty of costs What Actions Will Encourage the Fullest Measure of Each Factor?

Motivating Adoption The information strategy aims to convince adopters that change is better The political strategy uses organizational power to motivate change Differentiate between ready adopters, reluctant adopters, and resistant adopters

Training Every new system requires new skills
New skills may involve use of the technology itself New skills may be needed to handle the changed business processes

What to Train Should focus on helping users accomplish their tasks
Use cases provide an outline for common activities and a basis to plan training

Types of Training When Would You Use Each of These Training Methods?
One-to-One Classroom Computer-Based When Would You Use Each of These Training Methods?

Selecting a Training Method

POST-IMPLEMENTATION ACTIVITIES

Institutionalization of the System
Provide support Assistance in using the system Provide maintenance Repair or fix discovered bugs or errors Add minor enhancements to provide added value Assess the project Analyze what was done well Discover what activities need improvement in the future

Types of System Support
On-demand training at time of user need Online support Frequently asked questions (FAQ) Help desk Phone service for known issues Level 2 Support

System Maintenance System maintenance is the process of refining the system to make sure it continues to meet business needs

Sources of Change Requests
Operations group problem reports User requested enhancements Other system development projects Changes in underlying systems Organization strategy changes

Processing a Change Request

Project Assessment Important for continued project improvement
Especially important for junior personnel to improve quickly

Project Team Review Each member prepares 2-3 page document regarding her or his actions during the project Focus on improvement not penalties Excellent behaviors are acknowledged and diffused to others Team leader summarizes and distributes lessons learned

System Review Examine the extent to which the costs and benefits of the system are realized Use this information to help in more accurately estimating costs and benefits for future projects

How did the conversion go at CD Selections?
What did CD Selections do to aid change management processes? What were the post-implementation activities at CD Selections?

Summary Conversion is the technical process of replacing the old system with the new one. Designers select the method, timing, and location of the conversion process. Change management is aimed at helping system users to adopt the new system and use it productively

Summary Post implementation activities provide on-going support to users, include training people to use the system and provide participants in the development process the opportunity to learn and grow from their experiences

Expanding the Domain http://www.astd.org/
An excellent source of information all aspects of training Computer- Based, web-based, and classroom is the American Society for Training and Development:

Systems Analysis and Design with UML Version 2.0

Similar presentations

Presentation on theme: "Systems Analysis and Design with UML Version 2.0"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Systems Analysis and Design with UML Version 2.0

Similar presentations

Presentation on theme: "Systems Analysis and Design with UML Version 2.0"— Presentation transcript:

Similar presentations

About project

Feedback