60322: OOAD

1
60-322 OOAD

• Object-Oriented Analysis and Design

2
Course Information

• Instructor
• Randy Fortier
• rfortier_at_uwindsor.ca
• Course website
• http//elvis.csfac8.uwindsor.ca/courses/60-322/

3
Object-Oriented Analysis Design

• An Introduction

4
Analysis and Design

• Analysis build the right thing
• Analysis focuses on user requirements (functional
  or non-functional)
• In other words, we want to decide exactly what
  system the customer wants to have
• Design build the thing right
• Design focuses on how to provide the required
  functionality
• In other words, we want to decide how to
  structure the software that provides the
  (functional and non-functional) requirements
  determined during analysis

5
Analysis

• Usually performed by a systems analyst
• This is a person whose job it is to find out what
  an organization (or person) needs in terms of a
  software system
• Analysis looks at the software as a black box of
  functionality
• An analyst will never care about the internals of
  the system, merely how a user would interact with
  it from the outside

6
Design

• Usually performed by an architect or designer
• An architect looks at overall system structure
  (at a high level)
• For example, an architect on a distributed system
  might decide how the software components will be
  distributed
• An architect also looks at modularity, and
  non-functional requirements (such as performance
  and scalability)
• A designer looks at system structure (at lower
  levels)
• A designer will look at the classes that make up
  a module, and how they will interact to perform
  some function of the system

7
Design Patterns

• Patterns are themes that recur in many types of
  software systems
• It is common for software systems (even those
  whose purpose is quite different) will share some
  common challenges
• Often, the solution for the problem in one
  context can also be used in another context
• Thus, the designs (and even implementations) can
  often be reused from other software systems

8
Why Do We Need Design?

• Architects and designers need jobs
• What are you going to do, fire them?
• Ok, for the real answers lets move into the
  hypothetical world

9
Developing Small-Scale Systems

• Say I ask you to develop a system that asks the
  user for their birth date, and prints out the day
  of week for their next birthday
• How would you design such a system?

10
Developing Small-Scale Systems

• How would you design such a system?
• The answer is you probably wouldnt
• The problem is simple
• You probably wouldnt maintain it per se
• You could probably write the program alone
• It is unlikely to have unsolved bugs in such a
  program
• If the program fails, it is not particularly
  inconvenient to execute it again to achieve the
  results
• The program is not particularly useful

11
Medium-Scale Systems

• Say I ask you to develop a system that stores
  customers and products in a database and provides
  a GUI for browsing these products and customers
• How would you design such a system?

12
Medium-Scale Systems

• How would you design such a system?
• Youd make efforts to reduce the work
• Most likely, you have a team of 4 or 5 developers
• You would modularize the program, so that
  developers could work independently
• You would almost certainly have bugs to fix, as
  well as improvements to make over time
• If code hard to follow, and a new developer wants
  to expand your program or fix bugs, this will be
  very difficult
• Removing bugs and making improvements is
  important, since this program might be sold to a
  customer

13
Large-Scale Systems

• Say I ask you to develop a new operating system?
• How would you design such a system?

14
Large-Scale Systems

• How would you design such a system?
• There are likely hundreds of developers
• People who fix bugs are probably different people
  than those who wrote the code in the first place
• Bugs in such a system are unavoidable
• It is such a large program, that duplicate code
  likely exists all over the place
• New versions of the program are a certainty, so
  expect improvements to be made

15
The Unified Process

• A Structured, Interleaved Software Development
  Process

16
Software Development

• All software development requires the following
  things to occur
• Requirements
• Requirements capture/determination During this
  stage, the needs of the customers are determined,
  including a case-by-case analysis of the
  functionality required.
• Requirements analysis During this stage the
  functionality is described in terms of
  interactions between the user and the system.
  Relationships between related functional
  requirements may also be determined at this stage.

17
Software Development

• Design
• System design The overall system structure is
  determined, including a description of modules
  (subsystems) and sub-modules and their
  interaction
• Class-level design The classes are designed
  which are to make up the modules, etc.
• User interface design The appearance and
  operation of the user interface is determined
• Data design The structure of the database model
  is determined

18
Software Development

• Construction
• Implementation At this stage, the design is
  converted into an implementation using a
  (normally object-oriented) programming language
• Testing At this stage, the implementation is
  tested for coding and integration errors, as well
  as conformity to the requirements and design

19
The Unified Process

• The Unified Process (UP) is a methodology
  proposed by the three amigos (Booch, Jacobson,
  Rumbaugh)
• These three are also the co-developers of the
  Unified Modeling Language (UML)
• The Unified Process is also sometimes called the
  Unified Software Development Process (USDP), as
  it is in the textbook (and also RUP Rational
  Unified Process)
• The UP introduces a way to develop software where
  the phases are not distinct, but instead have
  significant overlap

20
The Unified Process

• The UP reduces risk since it allows you to
  develop the most critical and risky aspects of
  the project before addresses the less risky
• If the risky aspects of the project fail, the
  project was only a small failure since it failed
  so early
• Often you will also develop a prototype or
  skeleton of the user interface
• User interfaces changes can be caught early, and
  modified quickly before it affects very much of
  the rest of the system

21
Iterations

• The UP is an iterative process
• That means we revisit earlier phases and
  add/update components several times
• An iteration usually takes 1-8 weeks
• After an iteration should achieve some minor
  milestone
• Typically, a project 5-10 iterations will take
  place before completion

22
The Waterfall Model An Alternative

• The Waterfall Model for software development is a
  process where each of the phases are mutually
  exclusive and motion between phases is
  unidirectional
• Mutual exclusivity of phases results in poor use
  of human resources, since developers must wait
  for designers, etc.
• Unidirectional motion between phases is
  inadequate since it does not allow changes to be
  made to documents/code created in earlier phases

23
The Waterfall Model An Alternative
Requirements
Analysis
Design
Implementation
Testing
24
Requirements Analysis

• This phase in the software life cycle is when
  developers and customers work together to produce
  a description of the desired system
• Including a list of all features, plus a
  description of how it should work and look

25
Requirements Analysis

• Sometimes, this phase is split into two
• Customer requirements specification
• The customers describe their optimal system,
  including its features (in layperson terminology)
• Developer requirements refinement
• Develops decide that features are impossible, and
  re-describe the ideal system using biz-lingo
• This is where potential feature conflicts or
  ambiguities are discovered and resolved through
  communication with the customers
• It may also be useful to examine various possible
  technologies, and discuss their advantages and
  disadvantages
• The results of these technology choices should be
  reviewed with the customers

26
Design and Architecture

• This is where the structure of the software is
  defined
• This phase is where the majority of this course
  is focused
• However, as we proceed along, I do often include
  implementation details to illustrate concepts
• I will discuss this phase separately

27
Implementation

• In this phase, the design document is turned into
  software
• With object-oriented designs, the software is a
  collection of communicating objects, defined
  through classes
• All classes defined in the design are implemented
  using some OOP language

28
Testing

• In this phase, the software is tested to ensure
  there are as few bugs as possible before the
  software is delivered
• Notice I did not say 'bug free'
• It is a huge mistake made by developers and
  managers in large-scale software to assume that
  it can be 'bug free' in a reasonable amount of
  time

29
Testing

• Aside from design, this is also one of the most
  important phases in the software life cycle
• Obvious and disastrous bugs must be discovered in
  a system, since it affects the customer's initial
  impression of the software
• Object-oriented software is tested in very
  specific ways, which makes it relevant to talk
  about those methods in this course

30
Testing

• Testing in an object-oriented environment occurs
  in four stages (in this order)
• Unit testing
• Each method is tested with all possible
  categories of input
• Class testing
• A 'driver' class is created to test all the
  methods and attributes of a class in a sample use
  test
• Module testing
• A module is tested by accessing all the methods
  in its interface by a 'driver' class
• Integration testing
• The modules are combined, and tested to see if
  the integration created any unforeseen
  bugs/problems

31
Unit Testing

• Consider the special case inputs that are
  possible for a method
• For example, a sort method might have the
  following distinct input categories
• An empty list (with zero elements)
• A list that is already sorted
• A list that is sorted in reverse order
• A list that meets none of the above
  specifications (normal case)
• If we only test the last case, we are missing the
  most common sources of bugs

32
Unit Testing

• All methods in a well-tested system should have
• Pre-condition A set of attributes that are
  assumed to be true before the execution of the
  method
• Post-condition A set of attributes that are
  guaranteed to be true once the method has
  completed
• These conditions represent a contract that the
  method promises to follow

33
Unit Testing

• For example, consider a sort method
• Pre-condition The argument is an initialized
  list of integers with zero or more elements
• More accurately this might be expressed as
• list ! null
• list.length gt 0
• Post-condition The output is a list of
  integers, sorted in ascending order, with the
  same elements (and length) as the input list
• For all i lt list.length, output_listi is a
  member of list
• For all i lt list.length-1, output_listi lt
  output_listi1
• list.length output_list.length

34
Class Testing

• Unit testing ensures that all methods will do
  what they are defined to do
• Class testing ensures that using multiple methods
  together accomplishes the intended task

35
Class Testing

• Consider the following example
• class Invoice
• private String strMonth null
• void setMonth(int month)
• if (month 1)
• strMonth "Jan"
• else if ()

36
Class Testing

• int getMonthIndex()
• if (strMonth.equals("January"))
• return 1
• else if ()

37
Class Testing

• Each method does its job adequately, but when
  used together there would be problems
• The setMonth() method stores the month as "Jan",
  "Feb", "Mar", etc.
• The getMonthIndex() method looks for month names
  such as "January", "February", "March", etc.

38
Class Testing

• In class testing, the tester will create a number
  of 'stub' classes to represent some other classes
  in the system
• These stub classes should be created for every
  class that will interact with this class

39
Module Testing

• Module testing is similar to class testing,
  except that we test the use of a complete module
• Modules are often classes that use a collection
  of related classes
• These classes are wrappers for that module
• In module testing, we ensure that those classes
  work together to accomplish the intended goal
• This is similar to how methods work together in
  class testing

40
Module Testing

• If a system has multiple modules, usually a
  developer will create a number of 'stub' modules
  to represent these other modules
• The stub modules will simulate the interaction
  expected between modules

41
Integration Testing

• Integration testing ensures that modules work and
  communicate with one another properly
• Integration usually involves testing this
  communication
• Since each module was tested individually,
  integration testing is simply a verification that
  communication occurred as expected
• Detailed integration testing is typically done by
  the quality assurance (QA) team

42
Design Phase

• This phase usually consists of the following
  steps
• Identifying classes and objects
• Drawing design class diagrams
• Identifying class states
• Drawing state diagrams
• Specifying behaviour
• Drawing collaboration and sequence diagrams
• Illustrating complex algorithms'
• Drawing activity diagrams

43
Iterative Development Processes

• Software Engineers now agree that an iterative
  model is required to facilitate changes to
  earlier decision-making documents
• This model allows each phase to be visited any
  number of times, so that corrections and
  improvements can be made

44
The Iterative Waterfall Model
Requirements
Analysis
Design
Implementation
Testing
45
The Unified Process

• The UP is an iterative and incremental model
• The UP also allows simultaneous occupation of
  several stages of software development (this is
  what is meant by incremental)
• This means that developers can begin the
  implementation of the software while designers
  have not yet completed their design of the
  software
• This is called an incremental model of development

46
The Unified Process
Requirements
Analysis
Design
Implementation
Testing
47
The Unified Process

• The idea behind an incremental model is that once
  something is produced by a process, it can be
  used as a basis for the next process
• For example, when a part of the software system
  has been designed, the developers can begin the
  implementation for that software unit
• This is true in spite of the fact that the rest
  of the software system has not yet been designed

48
The Unified Process

• The UP was created to be an agile software
  development methodology
• In other words, if requirements, expectations,
  technologies, personnel, etc. change, the project
  should be able to adapt with minimal waste of
  effort
• Another agile methodology is called XP (eXtreme
  Programming)

49
eXtreme Programming (XP)

• XP is similar to UP in the following ways
• Risks are tackled early
• Everyone begins work immediately
• Software is developed incrementally outward from
  the risky or core parts
• XP is different than UP in the following ways
• XP suggests minimal design, and coding begins the
  very first day in some cases
• XP uses peer evaluation and pair programming to
  ensure quality and adherence to
  standards/architecture

50
XP Benefits

• Coding from day 1 is a philosophy many managers
  are willing to accept happily!
• Risky code (that might not be possible) is
  tackled early to mitigate risks
• Test-driven development ensures that bugs are
  found and fixed early
• Automated testing (e.g. JUnit) can be integrated
  into the build cycle (e.g. Ant, make), so bugs
  are never re-introduced
• Deployment-driven development ensures that many
  releases are possible
• Builds can occur daily or even more often, with
  automated building, integration, testing, and
  even remote deployment
• Development occurs in pairs
• Team development mentors newer developers and
  they become productive faster
• Team development can help avoid antipatterns

51
Scrum/Sashimi

• Scrum and Sashimi are other agile methodologies
• Scrum One repeating phase
• Different team members will become leader at
  different times, depending on their expertise and
  experiences
• Meetings are minimized, as people are working
  (developing) as much as possible
• A short status meeting is conducted daily (lt 30
  minutes)
• Sashimi Four overlapping phases
• Requirements, Design, Prototype, Acceptance
• Phases overlap to keep everyone busy and provide
  the opportunity to go back and make changes

52
The Unified Process

• The Unified Process has 4 phases
• Inception Requirements capture and analysis
• Elaboration System and class-level design
• Construction Implementation and testing
• Transition Deployment
• The jobs listed next to each phase are the main
  focus
• However, each job often occurs in multiple phases

53
The Unified Process

• The Unified Process has 4 phases
• Inception Requirements capture and analysis
• Elaboration System and class-level design
• Construction Implementation and testing
• Transition Deployment

54
Inception

• The inception phase is a preparatory stage that
  attempts to answer the following questions
• What is the purpose of the project?
• Is the project feasible (e.g. technologically,
  financially, with current personnel)?
• Should we buy the project, or build it?
• Will it be developed now, or built from an
  existing project?
• What are the estimated costs?
• Should we proceed with the project?
• This phase mostly deals with project planning and
  project management (i.e. 60-393)
• This includes Gantt charts and plans, budgets,
  etc.

55
Inception Timeline

• An important idea with Inception is that we do
  not yet know if a project will take place!
• Often 1 or 2 iterations are required for
  Inception
• Therefore, since a project may be rejected, it
  makes sense that the Inception phase should be
  very short
• Therefore, if the project gets scrapped, little
  time (and money) was wasted
• It is not uncommon for Inception to last a few
  days to a few weeks, maximum

56
Inception

• Since the UP is incremental, the inception phase
  begins some activities and produces some initial
  artifacts
• An artifact is something, such as a UML diagram
  or set of diagrams, that is produced during a
  phase
• However, these activities will be continued in
  later phases and the artifacts modified, and new
  artifacts added

57
Inception Artifacts

• Some inception artifacts include
• Business case Describes high-level goals and
  constraints, in business terminology
• Use-Case model Describes functional
  requirements, and related non-functional req.
• Risk management plan Describes business,
  resource, technical, and schedule risks and how
  to minimize these risks

58
Inception Artifacts

• A business case is a document describing the
  goals of the system
• It can be used for getting budgetary approval,
  for example
• A business case might describe how the software
  will make the company money
• A risk management plan is a document describing
  risks and how to minimize them
• It can be used to determine if the project is too
  risky, as well as how to approach a project while
  avoiding problems
• Since these documents not related to software
  analysis and design, they are not discussed in
  this course

59
Inception Artifacts

• Proof-of-concept code is simply a rough
  implementation of some part of the system, to
  demonstrate that a problem can be solved
• Prototypical data and user interfaces are sample
  database contents and user interfaces for
  analysis by experts (database experts and future
  system users)
• Again, these are not related to analysis and
  design, but they may be discussed from time to
  time

60
Inception Artifacts

• A use-case model is a document outlining the
  system requirements
• In inception, we begin creating this document,
  but do not finish it
• The use-case model describes use cases
• A use case is a single interaction between the
  system and one or more of its users
• A use case represents one way in which the system
  might be used

61
Inception for Managers

• Tangible results can be seen very quickly
• For example, user interface designers might
  develop some prototype user interface elements
  for examination by architects and customers
• Potential technical difficulties can be examined
  early
• For example, a difficult algorithm can be solved
  (perhaps in a limited way) using some
  proof-of-concept code in a programming language
• In other words, inception allows us to examine
  early the potential problems that may make the
  project fail later on in the project life cycle

62
Requirements

• One of the major tasks of inception is to
  determine some of the major requirements of the
  system
• Requirements are capabilities and condition to
  which the proposed system must conform
• However, inception should not examine all of the
  details of system requirements, but only the most
  salient use cases
• A use case is a situation representative of a
  typical interaction between the system and its
  users

63
Use-Case Model

• A use-case model is used to define requirements,
  since it describes how the system is to be used
  and how behaviour should be performed
• One of the major components of a use-case model
  is the use case diagrams
• A use case diagram is a UML diagram used to
  describe use cases in a visual way

64
Use Case Diagrams

• Used in the use case model
• These diagram show the following aspects of the
  system
• Actors Users such as customers, clerks, etc.
• System behaviour Functionality provided by the
  system, such as process sale, do payroll,
  etc.
• Relationships between actors and behaviours

65
Use-Case Model

• A use-case model contains the following
• Descriptions of use cases which describe various
  details about use cases
• Use-case diagrams which describe who is involved
  in a use case
• Use case contracts, which describe pre-conditions
  and post-conditions for the use cases
• System Sequence Diagrams (SSDs) or activity
  diagrams which describe how the system will
  implement the desired behaviour, without showing
  any details of the systems internals (as they
  are unknown at this point)

66
The Unified Process

• The Unified Process has 4 phases
• Inception Requirements capture and analysis
• Elaboration System and class-level design
• Construction Implementation and testing
• Transition Deployment

67
Elaboration

• The purpose of the inception phase is to
  understand the problem
• Often 1-3 iterations are required for Elaboration
• The main purpose of the elaboration phase is to
  begin to understand how the software will solve
  this problem
• In other words, this is where much of the
  architecture and design of the software takes
  place

68
Elaboration

• After Elaboration, project risks are essentially
  eliminated
• The user interface has been approved by customers
  and managers
• Technically difficult software components were
  implemented, or proof-of-concept code was created
  to prove it was possible
• Cost estimates are finalized, so budgets can be
  approved
• Preliminary user manuals have been created and
  analyzed
• Analysis, architecture and design well underway
  after Elaboration
• e.g. Use cases should be about 80 complete

69
Elaboration Artifacts

• The elaboration phase involves
• Continuing work on the use-case model
• In particular, during the elaboration phase is
  when activity diagrams might be added to describe
  how use cases are to operate
• Also, diagrams showing how participants (objects
  and actors) interact during the problem solving
  process (system sequence diagrams)
• Prototypes and proof-of-concepts Some of the
  more difficult system aspects to accomplish are
  solved with GUI prototypes, sample database
  contents, and sample OOPL code for difficult
  algorithms

70
Elaboration Artifacts

• The elaboration phase also involves the initial
  creation of the following artifacts
• Domain model A visualization of domain concepts
  and entities
• Design model A set of diagrams outlining of the
  structure of the software, as well as the user
  interfaces
• Data model Database schemas, including object
  to relational database mappings

71
Elaboration Artifacts

• Software implementation may also take place
  during elaboration
• When the design of a concept is created by
  designers, it can be implemented by developers
• Often, the most mission critical components are
  implemented in Elaboration
• Sometimes, these are proof-of-concept code
  snippets or prototypes

72
Activity Diagrams

• Activity diagrams can be used in the use case
  model
• Similar to flow charts, activity diagrams
  describe algorithms using flow control elements,
  such as
• Conditionals (switch, if)
• Loops (while, do-while, for)
• Etc.

73
System Sequence Diagrams

• SSDs are created for the use case model
• Sequence diagrams describe the interaction
  between objects over time
• System sequence diagrams describe the interaction
  between system objects and users to implement use
  cases
• This is called use case realization, since they
  make the vague descriptions of the use case more
  real

74
Domain Model

• A domain model is a visualization of domain
  concepts and entities
• In other words, a domain model is a number of
  class diagrams describing the classes in the
  problem domain
• A domain model is an attempt to understand the
  problem domain by categorizing its elements

75
Design Model

• A design model is a visualization of the
  structure of the software to be created
• A design model often includes the following
• Class diagrams Describing classes used to
  implement the software, and their relationships
• Sequence and collaboration diagrams Describing
  problem-solving processes
• Statechart diagrams Showing how objects evolve
  (or change state) over time

76
Class Diagrams

• Class diagrams are used in two ways
• In the domain model, they are used to describe
  domain classes (and their relationships)
• Domain classes are classes which describe
  tangible or conceptual objects (or entities) from
  the problem domain
• e.g. Molecule, Refrigerator, Composition, Sale
• In the design model, they are used to describe
  design-level classes (and their relationships)
• Design-level classes are classes created to
  implement the required functionality

77
The Unified Process

• The Unified Process has 4 phases
• Inception Requirements capture and analysis
• Elaboration System and class-level design
• Construction Implementation and testing
• Transition Deployment

78
Construction

• The construction phase involves iterative
  enhancement to previously created artifacts
• Domain model
• Design model
• Implementation
• Obviously, the implementation is the most
  significant body of work enhanced during
  construction

79
Implementation

• Implementation of high-risk problems is done
  during the elaboration phase
• During the construction phase, the lower-risk
  problems are implemented
• Also, the various components (potentially created
  by different teams) are unit tested, integrated,
  and integration tested
• Quality assurance plays an important role in the
  Construction phase

80
Implementation

• Any changes in user requirements are reflected in
  changes to the analysis documents, and
  subsequently in design and architecture documents
• Once complete, implementation can take place
• Typically, these changes are not mission critical

81
The Unified Process

• The Unified Process has 4 phases
• Inception Requirements capture and analysis
• Elaboration System and class-level design
• Construction Implementation and testing
• Transition Deployment

82
Transition

• During this phase, the software produced at the
  end of the construction phase is deployed
• This could involve
• Rigorous complete system testing
• Installation programs being purchased or
  developed
• Software media being developed
• Solutions for support/user training being
  implemented
• Best testing under varied deployment environments
• Verifying that the system meets acceptance
  criteria

83
Transition

• While there are UML diagrams used in this process
  (e.g. Deployment and Component diagrams), they
  are not relevant to analysis and design
• Therefore, they will not be discussed in the
  context of this course
• Typically, managers, administrators, and quality
  assurance persons work with developers to fix
  bugs and deploy the system
• Often these developers are separate from those
  who implemented the software in the first place

84
The Unified Modeling Language

• UML was developed by Jacobson, Rumbaugh, and
  Booch (like the UP)
• It is a visual language (i.e. for drawing
  diagrams) that describes a number of diagram
  types
• owning a hammer does not make you an architect
• Knowing UML does not make you a software engineer
• UML can be used to create poor designs as easily
  as designs that demonstrate best practices
• This course is not about UML per se, we merely
  use it as a tool for learning analysis and design
  concepts

85
UML

• UML can be used as a analysis language or a
  design language (or others)
• It supports object-oriented principles, such as
  inheritance, encapsulation (classes), etc.
• Thus, it serves well as a design language for
  object-oriented software
• It allows you to clearly and concisely define
  behaviour, without implementation specifics

86
UML

• UML is a visual language
• Instead of declarations, you have shapes and
  connectors
• Often, this makes UML easier to understand
• Other languages (including OOPL) require a
  transition to visualize
• Visualization is fundamental to design, since it
  provides an environment where an architect can
  see the complete picture

87
UML Tools

• You can begin working with UML, but you need one
  of the following tools
• Rational Rose (software)
• www.rational.com (15 day demo)
• Visio (software)
• From Microsoft (not free)
• Other software
• A UML editor is available from the course website
• Feel free to use this in this course, and
  continue to use it even after you graduate if you
  wish
• A plastic ruler and neat writing
• Any of these tools will do, so just pick one that
  suits you

88
Design Principles

• Most experts agree on a set of common principles
  of quality software
• Reusability
• Reliability
• Robustness (including security/integrity)
• Extensibility
• Scalability

89
Reusability

• Reusing software was the idea behind creating
  subroutines
• The same idea applies to classes and groups of
  classes
• Classes often do things that might be needed
  elsewhere in the program or in another program
• Classes like these should be written in such a
  way that
• They are easy to reuse in other programs
• They can perform similar functions that differ
  only slightly

90
Reliability

• Code that is written should not fail
• Essentially, the trick is to ensure that the code
  works
• Consistently between executions
• Successfully given a wide range of inputs
• The second point can be simplified by placing
  constraints on the input that can be passed
• For example, a bank should not allow a command to
  operate, such as
• account.withdraw(-500)
• We will learn how to do this later in the course

91
Robustness

• Under extreme conditions, even the best programs
  can fail
• Which operating system would you prefer?
• When the CD-ROM tries to read a CD with a scratch
  in it, the operating system freezes and loses all
  your open files changes
• When the CD-ROM tries to read a CD with a scratch
  in it, the operating system attempts to read the
  part of the CD again
• If it fails, it will report the error to the user
  without affecting the users open files

92
Robustness

• Robustness is about handling problems gracefully
• In the example given, the operating systems were
  not at fault, but clearly one OS handled the
  situation more appropriately than the other
• The important point about the 2nd operating
  system, is that the users files were saved, and
  the users inconvenience was minimized

93
Extensibility

• Sometimes (incorrectly) called scalability
• Lets say you wrote the medium-size program,
  which handles products and customers, and lets
  you browse
• Say I asked you to extend the program so that it
  printed the prices in a user-specified currency,
  given an exchange rate
• If this change takes months or even weeks to
  accomplish, you have a problem

94
Extensibility

• Extensibility is the simplicity of making
  reasonable additions to your program
• For example, we may wish to add the ability to
  store orders made by customers in a new database
  table
• The ideal situation is where the total time (time
  to develop the previous system plus time to make
  the extension) should be approximately the same
  as developing the complete (order-capable) system
  from scratch

95
Scalability

• The ability of an object to handle more
• Requests (in a given time period)
• Data items
• e.g. Consider a class CustomerDatabase that
  represents a list of our customers
• The ability for the class to handle 10 million
  entries as (or nearly as) efficiently as 100
  entries
• e.g. Consider a web server
• Handling 10 million requests per second should
  take time proportional to handling 100 requests

96
Maintenance

• Software maintenance takes longer than all other
  phases of the software life cycle
• Requirements analysis
• Design and architecture
• Implementation
• Testing
• Maintenance
• Including bug fixes and extensions
• Which phase do you think (ideally) takes the
  shortest amount of time?

97
Maintenance

• In most systems, it takes much longer than it
  should because developers did not follow these
  practices
• Keep this in mind
• It is always possible for a customer (or a boss)
  to ask for your program to change, no matter how
  unlikely you think it
• Rather than make the program perfect the first
  time, a more reasonable idea is to make it work
  now, and add to it later
• The person making the changes might not be you

98
A Note on Design

• The design phase is typically shorter than the
  implementation phase
• However, in companies that make large-scale
  products, the opposite is always true
• Consider software development like automobile
  manufacturing
• Which should take longer?
• Designing a car
• Manufacturing a car on an assembly line
• In software, (a little) more design may save
  development time