Software Design and Engineering using UML

1
Software Design and Engineering using UML

• January 15, 2000

2
Agenda

• Administrivia
• Course Overview
• Failures - Design Manifesto
• System Development
• Modeling
• Analysis - Preliminary Study
• Homework 1 Project

3
Administrivia

• Syllabus
• Doing it in Seven
• Waivers
• Presentations

4
Presentations

• review of the assigned chapter(s)
• review of the profile at the end of the chapter
  (if appropriate)
• example of a "well designed" web site or software
  package
• reasons why you consider it "well designed"

5
Course Overview

• Analysis and Design of Information Systems
• UML (Unified Modeling Language)
• What not How to make
• Core, GSIA course
• Homework (teams)
• Project Final (solo)

6
In Class Exercise

• Groups of 3
• Most Frustrating/Annoying Application
• What makes it that way?
• What would fix it?
• Example Forwarded WebTV mail Mulberry

7
Failures

• Technology Failures
• Kapor - Design Manifesto
• Cost of Changes

8
Technology Failures

• A technology failure occurs when a system fails
  to meet expectations.
• System
• Expectations
• Fails to meet

9
System

• Software
• Hardware/Technology
• Procedures/Business Process

10
Whose Expectations?

• Stakeholders
• Top Management
• Line Management
• IS Management
• Users
• Shareholders - Market
• IS Developers

11
What Expectations?
Explicit Documented
Implicit Unwritten
Expectations can be contradictory Explicit
Expectations can be incorrect
12
Expectations about What?

• Anything
• Cost
• Performance
• Functionality
• Reliability

13
Fails to Meet

• User Survey as Measure of Quality
• Good Idea?
• Range of satisfaction
• Not always binary

14
Causes of Failures

• Numerous
• Right System
• Wrong place or time
• Wrong process
• Missed Expectations

15
Cost of Failures

• Initial, Complete Failure
• Total Development Cost
• Rework/Reengineering
• Retraining
• Minor Failures
• Cost to fix driven by when need for change is
  identified

16
Cost of Changes
17
Preventing Failures

• Correctly capturing and determining how to meet
  everyone's expectations
• Software (System) Designer (Winograd)
• One foot in world of people processes
• One foot in world of technology
• Correctly meeting expectations
• Software (System) Engineer

18
Design Manifesto

• Mitch Kapor
• Founded Lotus
• Designer of 1-2-3
• Need for Design
• What is Design
• Training Designers

19
Need for Design

• Large MIS Departments
• Conspiracy of silence
• Secret shame of the industry
• Systems are hard to use
• Users learn minimum to get by

20
What is Design

• People, Process, Technology
• Not just interface design
• Architects not Construction Engineers
• Creating buildings
• Defining public spaces
• Knowledge of use and function
• Profile 1 (where the analogy falls short)

21
Well Designed

• Firmness - no bugs
• Commodity - useful for intended purpose
• Delight - use is pleasurable

22
Training Designers

• Technical Knowledge
• Human-Computer Interaction
• Design Studio
• Practice
• Apprentice
• Integration of design into development

23
Goals for Course

• What to make not how to make it
• UML - communication tool
• Exposure to design issues and ideas
• Shift focus from technology to understanding
  people and processes

24
System Development

• Goals
• Phases
• Common Characteristics
• Object-Oriented Development

25
Goals

• Build good systems
• Quality
• Cost-effective
• What people want
• What people will pay for

26
Generic Phases

• Analysis
• Design
• Coding
• Testing
• Implementation
• Maintenance

27
Analysis

• Problem definition
• Current state
• Scope
• Description of solution
• Requirements

28
Design

• Model of solution
• Data structure
• Interface design
• System architecture
• Program details

29
Coding

• Write it
• Search for reuse
• Catalog for reuse
• Unit testing

30
Testing

• Does it work?
• Integration/subsystem testing
• System testing
• Usability testing
• User acceptance testing

31
Implementation

• Put the system in place
• Install new hardware/technology
• Install new software
• Training
• Packaging and delivery
• Conversion

32
Maintenance

• Error Correction - fix bugs
• Adaptation
• Hardware or operating system changes
• Network changes
• Legal requirements
• Enhancement

33
Common Characteristics

• Phases ? Activities ? Tasks
• Incremental
• Future builds on past
• Milestones
• Deliverables
• Different skills needed for different development
  tasks

34
Object-Oriented Development - The Unified (?)
Process

• Inception
• Elaboration
• Construction
• Transition

35
Modeling

• What is a model?
• Why use a model?
• Alternative Models
• Liddle - Conceptual Models
• Drawbacks of Models

36
What is a Model?

• Representation
• Simplification
• Abstraction
• Focus/Important Aspects
• Semantic Information vs. Notation

37
Why Model?

• Save Time
• Generate Agreement
• Thinking Tool
• Capture Design Decisions
• Generate Useful Product

• Organize and Simplify
• Explore Alternatives
• Master Complexity

38
Types of Models

• Ideal - complete
• Partial
• Tool-Based

39
Alternative Models

• Different
• Views
• Aspects
• Perspectives
• Contexts
• Levels of Abstraction

• Static Model
• Structure
• Dynamic Model
• Behavior

40
Model Example

• Xerox Star - Users Conceptual Model
• Design Process
• Identify Tasks
• Build Scenarios
• Design Graphical Display
• Display Elements
• Controls
• Users Conceptual Model

41
Users Conceptual Model

• What the user thinks
• How the user responds
• Desktop Metaphor
• abstractions
• recognition over recall
• progressive disclosure

42
Drawbacks of Models

• Understandability
• Over Simplification
• Poor Model Choice
• Over Reliance on Model
• Difficult Conversion
• Model Longer to Develop
• Maintenance

43
Analysis

• Requirements
• Communication
• Activities
• Deliverables

44
Requirements

• Correct and thorough requirements
  specifications is essential to a successful
  project.
• No matter how well designed or well coded, a
  poorly analyzed and specified program will
  disappoint the user and bring grief to the
  developer.
• It is indispensable for analysts to get
  acquainted with the application domain.

45
Requirements

• A desired feature, property or behavior of a
  system
• Expectations - explicit through implicit
• System - software, hardware/technology,
  procedures/business processes
• What not How

46
Types of Requirements

• Business Process
• System Transactions - Users Perspective
• Look and Feel
• System Specific

47
System Specific Requirements

• Limits, Constraints, Priorities
• Reliability and Quality
• Speed and Response Time
• Data Volume
• Error Handling

48
Quality Function Deployment

• Mitsubishi
• Types of Requirements
• Normal - explicit - satisfied user
• Expected - implicit
• Exciting - go beyond

49
Collecting Requirements

• Identify Users/Stakeholders
• Different Ones - Different Needs
• Establish Problem Domain
• What is it? What isnt it?
• How big is it?
• Get to know it
• Workflows - Business Processes
• Current
• Future

50
Collecting Requirements

• Partitioning
• Decompose problem into separate parts
• Understand relationships between the parts
• Way to handle complexity
• Hierarchy
• Increasing detail with depth

51
Collecting Requirements

• Questioning
• Listening
• Discussing

52
Collecting RequirementsPrototyping

• Prototype software model of system
• Closed-Ended - throwaway
• Open-Ended - evolutionary
• Explorative - identify requirements
• Experimental - try options
• Entire System
• Key elements only

53
Candidates for Prototyping

• Dynamic visual displays
• Heavy user interaction
• Complex algorithms or calculations
• Ambiguous or conflicting requirements

54
Prototyping Considerations

• User Resources
• Decision Makers
• IS Resources - Tools, People
• User Understanding of Prototype
• Time to completion
• Full functionality
• Performance requirements
• Closed-ended
• Paper Prototype
• Communication Tool (Model)

55
Analysis Communication Challenges

• Explicit Requirements
• Implicit Requirements
• All Stakeholders
• Shared Knowledge
• Getting Agreement

56
Analysis Communication

• Interviews
• User Documentation
• User Training
• RAD/FAST
• Models
• Project Documentation/Deliverables
• Reviews

57
Interviews

• Questions
• Open-ended questions
• Survey
• One-on-one
• Observation of work in progress
• Follow up
• Thank you
• Minutes - notes
• Questions

58
User Materials

• Training
• New employees
• Manuals
• Documentation
• Procedure manuals
• Exception handling
• Workflow documentation
• Unwritten
• Forms

59
RAD/FAST

• RAD
• Rapid Application Development
• Rapid Analysis and Design
• FAST
• Facilitated Application Specification Technique

60
RAD/FAST

• Structured Workshop
• All stakeholders
• users, developers, support areas, management
• Decision Makers
• Established Rules and Agenda
• Interviews and Other Data Collection First
• Careful Documentation on Decisions
• Multiple Meetings - Several Days/Weeks
• Prototyping Possible
• Review Results

61
Analysis Models

• Communication Tool
• Model drawbacks raised earlier
• User training in understanding modeling method
  and meaning

62
Project Documentation

• Written for user review
• Written for management review
• Written for next development phase
• Everything on paper (disk)
• Glossary technical business
• Outstanding issues

63
Review

• Formal or Informal
• Along the way and after Analysis complete
• Goal is agreement
• Sign offs

64
Preliminary Study

• Overview
• Assumptions/Issues
• Context Diagram
• Business Process Models
• Is-State
• Description of Actors
• Description of Interfaces
• Requirements
• Prioritized List of Use Cases
• Recommendation
• Appendices

65
Preliminary Study

• Overview
• Description of project, goals, benefits, possible
  risks, summary of recommendation
• Assumptions/Issues
• Open issues, unanswered questions, assumptions
  made throughout rest of document
• Recommendation
• Should development proceed? If so, how? What
  decisions need to be made? What is the project
  teams recommendation for those decisions?

66
Context Diagram

• Diagram showing the relationship between the
  system and all external entities
• System - large circle
• External entity - box
• Producer or consumer of information that resides
  outside the system (user or another system)
• Relationship - line with arrow showing direction
  of flow labeled with data

67
Context Diagram
Desired Courses
Available Courses
Dept
Student
Schedule
Student Enrollment System
Roster
Available Courses
Room Assignments
Student Billing
Billing System
Registrar
Unassigned Courses
68
Business Process Model

• Model of existing business processes
• Model of new/changed business processes
• Shows procedure or workflow
• Emphasis is individual activities
• Object state when significant
• Relationship, precedence, timing of activities
• Responsibilities (swim lanes)
• Activity Diagrams (pp. 146-149)

69
Activity Diagrams
Start Finish Activity Condition
cond
cond
70
Activity Diagrams
Synchronization Constraints Splitting Multiple
Transitions
AND
OR
XOR
for each/all
71
Activity Diagrams
Object State To State Required State
Object state
Object state
Object state
72
Register for Courses
Billing paid
AND
ok
Billing due
avail
all courses
each course
full
73
Is-State

• Description of current system
• Business Process Models
• Text Descriptions
• Identify current problems
• Totally New Development
• competitors, alternatives

74
Preliminary Study

• Description of Actors
• Brief description of each actor - who does what
• Actor abstraction for external entities (user
  or system) that interact directly with the system
• Determined by role not person
• Description of Interfaces
• Brief description of external systems that only
  provide data to the system but do not interact
  with it
• External entities that are not actors

75
Documenting Requirements

• Specification - representation (model) of
  requirements (explicit)
• Text description/narrative
• Outline (1, 1.1, 1.1.1, etc)
• Business Process Models
• Prototypes
• Sample forms, reports, screens

76
Documenting Requirements

• Understandable to all
• Format and content relevant to problem
• Information should be nested
• Diagrams should be consistent
• Revisable

77
Prioritized List of Use Cases

• Use Case specification of sequence of actions
  that a system can perform by interacting with
  actors
• Scenarios
• Transactions
• Business Event or Operation
• Comprehensive

78
Prioritizing Use Cases

• Difference between normal and exciting
  requirements
• What must be done right away?
• What can wait?
• Needed versus Desired
• Different users have different priorities
• RAD/FAST to help determine
• Cost/Complexity
• 80/20 Rule

79
Appendices

• Architectural Model
• What hardware, software and other technology will
  be needed for this project?
• How experienced is the team with this technology?
• What special tools or training will be needed to
  develop the project?
• Are there any other technical considerations that
  should be noted?

80
Appendices

• Information Sources
• What were the sources of information used in
  creating the Preliminary Study?
• Alternative Solutions
• What are the alternative solutions to the
  recommended one?
• Why was each alternative not selected?
• Make vs. Buy Decision

81
Appendices

• Technical Glossary
• Definition and description of technical terms or
  terms that have specialized meanings
• technical in technology sense
• technical in business sense

82
Homework

• TVList.com
• Document Assumptions
• Fill in blanks
• Team Effort - Be both user and developer
• Made Consistent
• Homework 1
• Preliminary Study

83
Project

• Individual Effort
• Computing or Technology Failure
• Causes and Prevention
• Books on Reserve - Go Beyond Them
• Three Parts
• Overview - 2/5
• Presentation - 2/26
• Written Report - 2/26