Software Design and Engineering using UML

Software Design and Engineering using UML

January 15, 2000

Agenda

AdministriviaCourse OverviewFailures - “Design Manifesto”System DevelopmentModelingAnalysis - Preliminary StudyHomework 1 & Project

Administrivia

SyllabusDoing it in SevenWaiversPresentations

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 packagereasons why you consider it "well

designed"

Course Overview

Analysis and Design of Information Systems

UML (Unified Modeling Language)“What” not “How” to makeCore, GSIA courseHomework (teams)Project & Final (solo)

In Class Exercise

Groups of 3Most Frustrating/Annoying ApplicationWhat makes it that way?What would fix it?

Example: Forwarded WebTV mail & Mulberry

Failures

Technology FailuresKapor - “Design Manifesto”Cost of Changes

Technology Failures

A technology failure occurs when a system fails to meet expectations.

SystemExpectationsFails to meet

“System”

SoftwareHardware/TechnologyProcedures/Business Process

Whose Expectations?

“Stakeholders” Top Management Line Management IS Management Users Shareholders - Market IS Developers

What Expectations?

Explicit

Documented

Implicit

Unwritten

Expectations can be contradictory

Explicit Expectations can be incorrect

Expectations about What?

Anything

Cost Performance Functionality Reliability ……

“Fails to Meet”

User Survey as Measure of Quality Good Idea?

Range of satisfaction Not always binary

Causes of Failures

Numerous

Right System Wrong place or time Wrong process

Missed Expectations

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

Cost of Changes

0

10

20

30

40

50

60

70

Analysis Design Code Test After Release

x E

xpen

se

Preventing Failures

Correctly capturing and determining how to meet everyone's expectations Software (System) Designer (Winograd)

One foot in world of people & processesOne foot in world of technology

Correctly meeting expectations Software (System) Engineer

Design Manifesto

Mitch Kapor Founded Lotus Designer of 1-2-3

Need for DesignWhat is DesignTraining Designers

Need for Design

Large MIS Departments“Conspiracy of silence”“Secret shame of the industry”Systems are hard to useUsers learn minimum to get by

What is Design

People, Process, TechnologyNot just interface designArchitects not Construction Engineers

Creating buildings Defining public spaces Knowledge of use and function

Profile 1 (where the analogy falls short)

Well Designed

Firmness - no bugsCommodity - useful for intended

purposeDelight - use is pleasurable

Training Designers

Technical KnowledgeHuman-Computer InteractionDesign Studio

Practice Apprentice

Integration of design into development

Goals for Course

What to make not how to make itUML - communication toolExposure to design issues and ideasShift focus from technology to

understanding people and processes

System Development

GoalsPhasesCommon CharacteristicsObject-Oriented Development

Goals

Build good systems Quality Cost-effective

What people wantWhat people will pay for

Generic Phases

AnalysisDesignCodingTestingImplementationMaintenance

Analysis

Problem definitionCurrent stateScopeDescription of solutionRequirements

Design

Model of solutionData structureInterface designSystem architectureProgram details

Coding

Write itSearch for reuseCatalog for reuse“Unit” testing

Testing

Does it work?

Integration/subsystem testingSystem testingUsability testingUser acceptance testing

Implementation

Put the system in placeInstall new hardware/technologyInstall new softwareTrainingPackaging and deliveryConversion

Maintenance

Error Correction - fix bugsAdaptation

Hardware or operating system changes Network changes Legal requirements

Enhancement

Common Characteristics

Phases Activities TasksIncremental

Future builds on pastMilestonesDeliverablesDifferent skills needed for different

development tasks

Object-Oriented Development - The Unified (?) Process

InceptionElaborationConstructionTransition

Modeling

What is a model?Why use a model?Alternative ModelsLiddle - Conceptual ModelsDrawbacks of Models

What is a Model?

RepresentationSimplificationAbstractionFocus/Important Aspects

Semantic Information vs. Notation

Why Model?

Save TimeGenerate

AgreementThinking ToolCapture Design

DecisionsGenerate Useful

Product

Organize and Simplify

Explore Alternatives

Master Complexity

Types of Models

Ideal - completePartialTool-Based

Alternative Models

Different Views Aspects Perspectives Contexts Levels of

Abstraction

Static Model Structure

Dynamic Model Behavior

Model Example

Xerox Star - User’s Conceptual Model

Design Process Identify Tasks Build Scenarios Design Graphical Display

Display ElementsControlsUser’s Conceptual Model

User’s Conceptual Model

What the user thinksHow the user responds

Desktop Metaphor abstractions recognition over recall progressive disclosure

Drawbacks of Models

UnderstandabilityOver SimplificationPoor Model ChoiceOver Reliance on ModelDifficult ConversionModel Longer to DevelopMaintenance

Analysis

RequirementsCommunicationActivitiesDeliverables

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.”

Requirements

A desired feature, property or behavior of a system

Expectations - explicit through implicitSystem - software, hardware/technology,

procedures/business processes

“What” not “How”

Types of Requirements

Business ProcessSystem Transactions - User’s

Perspective“Look and Feel”System Specific

System Specific Requirements

Limits, Constraints, PrioritiesReliability and QualitySpeed and Response TimeData VolumeError Handling

Quality Function Deployment

Mitsubishi

Types of Requirements Normal - explicit - satisfied user Expected - implicit Exciting - “go beyond”

Collecting Requirements

Identify Users/Stakeholders Different Ones - Different Needs

Establish Problem Domain What is it? What isn’t it? How big is it? Get to know it

Workflows - Business Processes Current Future

Collecting Requirements

Partitioning Decompose problem into separate parts Understand relationships between the

parts Way to handle complexity Hierarchy

Increasing detail with depth

Collecting Requirements

QuestioningListeningDiscussing

Collecting RequirementsPrototyping

Prototype: software model of system

Closed-Ended - throwaway Open-Ended - evolutionary

Explorative - identify requirements Experimental - try options

“Entire” System Key elements only

Candidates for Prototyping

Dynamic visual displaysHeavy user interactionComplex algorithms or calculationsAmbiguous or conflicting

requirements

Prototyping Considerations

User ResourcesDecision Makers IS Resources - Tools, PeopleUser Understanding of Prototype

Time to completion Full functionality Performance requirements Closed-ended

“Paper Prototype”Communication Tool (Model)

Analysis Communication Challenges

Explicit RequirementsImplicit RequirementsAll StakeholdersShared KnowledgeGetting Agreement

Analysis Communication

InterviewsUser DocumentationUser TrainingRAD/FASTModelsProject Documentation/DeliverablesReviews

Interviews

Questions Open-ended questionsSurveyOne-on-oneObservation of work in progressFollow up

Thank you Minutes - notes Questions

User Materials

Training New employees Manuals

Documentation Procedure manuals Exception handling Workflow documentation “Unwritten” Forms

RAD/FAST

RAD Rapid Application Development Rapid Analysis and Design

FAST Facilitated Application Specification

Technique

RAD/FAST

Structured WorkshopAll stakeholders

users, developers, support areas, managementDecision MakersEstablished Rules and Agenda Interviews and Other Data Collection FirstCareful Documentation on DecisionsMultiple Meetings - Several Days/WeeksPrototyping PossibleReview Results

Analysis Models

Communication ToolModel drawbacks raised earlierUser training in understanding

modeling method and meaning

Project Documentation

Written for user reviewWritten for management reviewWritten for next development phaseEverything on paper (disk)Glossary: technical & businessOutstanding issues

Review

Formal or InformalAlong the way and after Analysis

“complete”Goal is agreementSign offs

Preliminary Study

OverviewAssumptions/IssuesContext DiagramBusiness Process Models Is-StateDescription of ActorsDescription of InterfacesRequirementsPrioritized List of Use CasesRecommendationAppendices

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 team’s recommendation for those decisions?

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

Context Diagram

Student Enrollment System

Student

Billing System

Registrar

DeptDesired Courses

Available Courses

RosterAvailable Courses

Student Billing

Room Assignments

Unassigned Courses

Schedule

Business Process Model

Model of existing business processesModel of new/changed business processes

Shows procedure or workflowEmphasis is individual activities

Object state when significant

Relationship, precedence, timing of activitiesResponsibilities (swim lanes)Activity Diagrams (pp. 146-149)

Activity Diagrams

Start

Finish

Activity

Condition[cond]

[cond]

Activity Diagrams

Synchronization

Constraints

Splitting

Multiple Transitions

{AND} {OR} {XOR}

* for each/all

Activity DiagramsObject State

To State

Required State

Object

[state]

Object

[state]

Object

[state]

Register for Courses

Sign On Enter Courses

Sign Off

Check Preqs

Check Avail

Add to Waitlist

Add Student

Billing

[paid]

Billing

[due]

* each course

* all courses

Display Schedule

[ok]

[avail]

[full]

{AND}

“Is-State”

Description of current “system”Business Process ModelsText DescriptionsIdentify current problems

Totally New Development competitors, alternatives

Preliminary Study

Description of Actors Brief description of each actor - who does

whatActor: abstraction for external entities (user or

system) that interact directly with the systemDetermined 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

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

Documenting Requirements

Understandable to allFormat and content relevant to

problemInformation should be nestedDiagrams should be consistentRevisable

Prioritized List of Use Cases

Use Case: specification of sequence of actions that a system can perform by interacting with actors

ScenariosTransactionsBusiness Event or OperationComprehensive

Prioritizing Use Cases

Difference between “normal” and “exciting” requirements

What must be done right away?What can wait?Needed versus DesiredDifferent users have different priorities

RAD/FAST to help determineCost/Complexity

80/20 Rule

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?

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

Appendices

Technical Glossary Definition and description of technical

terms or terms that have specialized meanings

“technical” in technology sense “technical” in business sense

Homework

TVList.comDocument AssumptionsFill in “blanks”Team Effort - Be both user and

developerMade Consistent Homework #1

Preliminary Study

Project

Individual EffortComputing or Technology FailureCauses and PreventionBooks on Reserve - Go Beyond ThemThree Parts

Overview - 2/5 Presentation - 2/26 Written Report - 2/26