MIS 161 Systems Development Life Cycle II Lecture 2: Design Issues and OO Design

1
MIS 161Systems Development Life Cycle IILecture
2Design Issues and OO Design
2
DESIGN CRITERIA

3
Principles of Well Designed Systems

• Decoupling
• Separate modules are relatively independent
• loose coupling
• allow one module to be repaired with minimum
  disruption to others
• overlapping/duplicate functions
• independence

4
Principles of Well Designed Systems

• Cohesion
• How well activities within a single module are
  related to one another
• Functional cohesion
• containing all, and only, those tasks
  contributing to the generation of a single
  information function/ product
• Method cohesion
• Class cohesion
• Generalization/specialization cohesion

5
Principles of Well Designed Systems

• Modularity
• design of a system in relatively small chunks
• allows assignment of developers to different
  tasks
• sections of system can be developed independently
• maintenance can occur without disturbing other
  modules
• User involvement
• throughout SDLC
• sense of ownership
• real, not simulated

6
Principles of Well Designed Systems

• Satisficing
• better not best solution
• best solution not feasible
• resource constraints
• Human Interface
• human factors
• ergonomics

7
Connascence

• How closely modules are related
• Literally means having been born together OR
• having intertwined destinies in life
• Changing one module creates the need to change
  another module as a result of changing one
• Minimize overall connascence
• Minimize across encapsulation boundaries
• Maximize within encapsulation boundary

8
Design Coordination

• Project Scheduling
• e.g., Gantt Chart
• deliverables/milestones
• User Participation
• Design Teams
• Structured Walkthrough

9
Structured WalkThroughs

• A way of using peer reviews to monitor the
  systems development, point out problems, and
  allow the analyst responsible to make suitable
  changes
• Can be done when any portion of the system is
  complete
• Normally have at least four individuals
• Each person has a special role for example
• Person responsible for that part of the system
• Walkthrough coordinator
• Programmer or anlayst peer
• A note taker

10
Avoid Classic Design Mistakes

• Reducing design time
• Reducing time spent on design in order to jump
  directly into programming
• Feature creep
• Additional features added to the system during
  design
• Dont add any unless they are vital
• Silver bullet syndrome
• No one tool can solve all the problems and
  magically reduce time and costs.
• Switching tools in mid-project
• Switching design tools only adds more time the
  project due to the time it takes to learn the new
  tool

11
Selecting a Design Strategy

• Business need
• In-house experience
• Project skills
• Project management
• Time frame

12
Design Strategies
Use Custom Development When Use a Packaged System When Use Outsourcing When
Business need The business need is unique The business need is common The business need is not core to the business
In-house experience In-hours functional and technical experience exists Un-house functional experience exists In-house functional or technical experience does not exist
Project skills There is a desire to build in-house skills The skills are not strategic. The decision to outsource is a strategic decision
Project management The project has a highly skilled project manager and a proven methodology The project has a project manager who can coordinate the vendors efforts The project has a highly skilled project manager at the level of the organization that matches the scope of the outsourcing deal
Time Frame The time frame is flexible The time frame is short The time frame is short or flexible
13
Custom Development

• Allows for meeting highly specialized
  requirements
• Allows flexibility and creativity in solving
  problems
• Easier to change components
• Builds personnel skills
• May tax firms resources
• May add significant risk

14
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

15
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

16
Outsourcing

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

17
Infrastructure Considerations

18
Realities of Infrastructure Design

• Most often the infrastructure will be in place
• Coordination of infrastructure components is very
  complex
• The application developer will need to coordinate
  with infrastructure specialists

19
Selecting an Architecture

• Cost of infrastructure
• Cost of development
• Ease of development
• Interface capabilities
• Control and security
• Scalability

20
Hardware and Software Specification

• Used if new hardware or software must be
  purchased
• Actual acquisition of hardware and software
  usually left to a purchasing department --
  especially in larger firms

21
Steps in Hardware and Software Specification

• Describe equipment in as much detail as possible
• Consider whether increased processing and traffic
  will absorb unused hardware capacity
• Note all software running on each hardware
  component

22
Object-Oriented Design
23
OBJECT DESIGN ACTIVITIES

24
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

25
Additional Specification

• Review the current set of models
• Signatures for each method
• Define constraints
• Identify Opportunities for Reuse
• Restructure the Design

26
Optimizing the Design

• Review access paths
• Review attributes of each class
• Consider execution order of statements in
  often-used methods
• Avoid recomputation by creating derived
  attributes and triggers

27
OO Life Cycle Using UML

• Planning
• High level (project identification and selection)
• Low level (project initiation and planning)
• Analysis
• Determine system requirements
• Use cases
• Structure requirements
• Preliminary class diagram
• State diagrams
• Preliminary interaction diagrams
• Activity diagrams
• Package diagrams
• Design
• Logical
• screens, reports, etc.
• Physical
• Detailed interaction diagrams
• Add layers
• data management

28
Iterations and Workflow
Requirements
Analysis
Design
Implementation
Test
29
From OO Analysis Models to Design Models

30
The Problem Domain

• The term "problem domain" refers to the area that
  encompasses real-world things and concepts
  related to the problem that the system is being
  designed to solve.
• Domain modeling is the task of discovering
  "objects" (classes, actually) that represent
  those things and concepts.
• This was your focus in MIS 160.
• Now we move away from this and into the logical
  design.

31
From Analysis Classes to Design Classes

• Analysis classes captured some physical aspects
  of the system
• A design class diagram shows the data types of
  the attributes, the return types and arguments of
  the operations, and the visibility specifications
  for all attributes and operations.
• From physical to logical

32
Design Classes

• Each design class should specify
• Each attribute
• Type
• Visibility
• Responsibilities translated into specific
  operations

33
PACKAGES AND PACKAGE DIAGRAMS

34
Package

• UML Packages are a grouping of objects into sets
  of objects that provide related services.
• The package has responsibilities that are
  strongly related.
• The package has low coupling and low cohesion
  with respect to interfacing with other packages
  in the system.

35
Sample Package Diagram
36
Syntax for Package Diagram
37
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.

38
In UML, packages are represented as rectangles
with tabs in the top left corner.
39
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

40
Example Class Diagram
41
Package Diagram of the PD Layer for the
Appointment System
42
METHOD SPECIFICATION

43
Structured English
44
Pseudocode Example