Systems Analysis and Systems Analysis and Systems Analysis and Systems Analysis and Design with UML Version Design with UML Version 2.0, Second Edition2.0, Second Edition

Alan Dennis, Barbara Wixom, and David Tegardenega de

Chapter 9: Moving on to Design

John Wiley & Sons, Inc.Copyright 2005Slide 1

Copyright 2005

Copyright © 2005J h Wil & S IJohn Wiley & Sons, Inc.

All rights reserved. Reproduction or translation of this All rights reserved. Reproduction or translation of this work beyond that permitted in Section 117 of the 1976 United States Copyright Act without the express written permission of the copyright owner is unlawful. p py gRequest for further information should be addressed to the Permissions Department, John Wiley & Sons, Inc. The purchaser may make back-up copies for his/her own The purchaser may make back up copies for his/her own use only and not for redistribution or resale. The Publisher assumes no responsibility for errors, omissions, or damages, caused by the use of these omissions, or damages, caused by the use of these programs or from the use of the information contained herein.

Slide 2

Moving On To Design

Chapter 9

Slide 3

K IdKey Ideas

The purpose of the analysis phase is The purpose of the analysis phase is to figure out what the business needs The purpose of the design needs. The purpose of the design phase is to figure out how to provide itprovide it.The steps in both analysis and d i h hi hl design phases are highly interrelated and may require much “ i b k d f th”Slide 4

“going back and forth”

Obj tiObjectives■ Understand the transition from ■ Understand the transition from

analysis to design.■ Understand the use of factoring, g,

partitions, and layers.■ Be able to create package diagrams.■ Be familiar with the custom,

packaged, and outsource design alternativesalternatives.

■ Be able to create an alternative matrix.Slide 5

matrix.

REVISITING THE OBJECT-ORIENTED APPROACH TO ORIENTED APPROACH TO ANALYSIS AND DESIGN

Slide 6

OO Analysis and Design F d tiFoundation

Use case drivenUse-case drivenArchitecture centricIterative and incremental

Slide 7

C bi i Th ViCombining Three Views

FunctionalFunctionalStaticDynamic

Slide 8

A “Mi i li t” A hA “Minimalist” Approach

PlanningPlanningGathering requirementsPerform a series of “builds”Use results of each build as Use results of each build as feedback for design and implementation

Slide 9

EVOLVING THE ANALYSIS MODELS INTO DESIGN MODELS INTO DESIGN MODELS

Slide 10

Avoid Classic Design Mi t kMistakes

Reducing design timeReducing design timeFeature creepSilver bullet syndromeSwitching tools in mid projectSwitching tools in mid-project

Slide 11

F t iFactoring

Creating modules that account for Creating modules that account for similarities and differences between units of interestunits of interestNew classes

GeneralizationAggregationgg g

AbstractingRefinementSlide 12

Refinement

P i i d C ll b iPartitions and Collaborations

Creating “subsystems” or larger Creating subsystems or larger unitsG i it th t ll b tGrouping units that collaborateMay have collaboration among units or partitionsThe more messages or contracts gbetween objects, the more likely they are in the same partition

Slide 13

y p

P f LPurpose of Layers

Model view controller (MVC) Model-view-controller (MVC) architecture

Models implement application logicViews and controllers do user interfaces

Separating application logic from Separating application logic from user interface logic

Slide 14

LLayers

Slide 15

PACKAGES AND PACKAGE PACKAGES AND PACKAGE DIAGRAMS

Slide 16

P k Packages

Logical grouping of UML elementsLogical grouping of UML elementsSimplifies UML diagrams

Groups related elements into a single higher-level elementsingle higher level element

Dependency relationshipsSh d d b t Shows a dependency between packages

Slide 17

Syntax for Package DiDiagram

A PACKAGE Package

A DEPENDENCY RELATIONSHIPA DEPENDENCY RELATIONSHIP

Slide 18

Package Diagram of Dependency Relationships Among Layers

Slide 19

M difi ti D dModification Dependency

Indicates that a change in one package Indicates that a change in one package could cause a change to be required in another package.p gExample:

A change in one method will cause the 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

ld h t b difi dSlide 20

could have to be modified.

Package Diagram of A i SAppointment System

Slide 21

Steps for Identifying Packages and Building Package Diagrams

Set the contextSet the contextCluster classes together based on shared relationshipsrelationshipsModel clustered classes as a packageIdentify dependency relationships among Identify dependency relationships among packagesPlace dependency relationships between Place dependency relationships between packages

Slide 22

Package Diagram of the PD Layer for the Appointment System

Slide 23

Slide 24

Slide 25

DESIGN STRATEGIES

Slide 26

C t D l tCustom Development

Allows for meeting highly Allows for meeting highly specialized requirementsAll fl ibilit d ti it i Allows flexibility and creativity in solving problemsEasier to change componentsBuilds personnel skillspMay tax firm’s resourcesMay add significant riskSlide 27

May add significant risk

P k d S ftPackaged SoftwareSoftware already writtenSoftware already writtenMay be more efficientMay be more thoroughly tested and proveny g y pMay range from components to tools to whole enterprise systems

f l d dMust accept functionality providedMay require change in how the firm does businessbusinessMay require significant “customization” or “workarounds”

Slide 28

S t I t tiSystem Integration

The process of combining packages The process of combining packages, legacy systems, and new softwareK h ll i i t ti d tKey challenge is integrating dataWrite data in the same formatRevise existing data formatsDevelop “object wrappers”Develop object wrappers

Slide 29

O t iOutsourcing

Hire external firm to create systemHire external firm to create systemMay have more skillsMay extend existing resourcesNever outsource what you don’t yunderstandCarefully choose vendorCarefully choose vendorPrepare contract and payment style carefullySlide 30

carefully

O t i G id liOutsourcing GuidelinesKeep lines of communication open with Keep lines of communication open with outsourcerDefine and stabilize requirements before signing a contractsigning a contractView outsourcing relationship as partnershipSelect outsource vender carefullyAssign person to manage relationshipDon’t outsource what you don’t understandEmphasize flexible requirements long-term Emphasize flexible requirements, long term relationships, and short-term contracts

Slide 31

Selecting a Design St tStrategy

Business needBusiness needIn-house experienceProject skillsProject managementProject managementTime frame

Slide 32

Y TYour Turn

Suppose that your university is Suppose that your university is interested in creating a new course registration system that can support registration system that can support Web-based registration?Wh t h ld th i it id What should the university consider when determining whether to invest i t k d in a custom, packaged, or outsourcing system solution?

Slide 33

DEVELOPING THE ACTUAL DEVELOPING THE ACTUAL DESIGN

Slide 34

Th Alt ti t iThe Alternative matrix

Combines several feasibility Combines several feasibility analyses into one gridRevisits technical, economic, and organizational feasibilityand organizational feasibility

Slide 35

R t f P lRequest for Proposals

Description of the system you Description of the system you propose to be builtVendors, developers, service providers respond with providers respond with proposals including how they will address needs as well as will address needs as well as stating cost and time eq i ements

Slide 36

requirements.

Slide 37

SSummaryWhen evolving analysis into design When evolving analysis into design models, it is important to review the analysis models then add system environment informationenvironment information.Packages and package diagrams help provide structure and less complex views f th tof the new system.

Custom building, packages, and outsourcing are alternative ways of outsou c g a e a te at e ays ocreating the new system.The alternative matrix can help with the selection of a design strategySlide 38

selection of a design strategy.

E di th D iExpanding the Domain

Smalltalk is an object oriented Smalltalk is an object-oriented programming language with

l l dhmany very loyal adherents. For more information check the site at:http://www smalltalk org/mainhttp://www.smalltalk.org/main.html

Slide 39