Date post: | 20-Dec-2015 |
Category: |
Documents |
View: | 215 times |
Download: | 1 times |
Chapter 1
Software Development
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-2
Chapter Objectives• Discuss the goals of software development
• Identify various aspects of software quality
• Examine several development life cycle models
• Explore the notation of the Unified Modeling Language (UML)
• Examine issues related to error handling
• Introduce the concept of algorithm analysis
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-3
Software Development
• Software Engineering is the study of the techniques and theory that support the development of high-quality software
• The focus is on controlling the development process to achieve consistently good results
• We want to:– satisfy the client – the person or organization who
sponsors the development
– meet the needs of the user – the people using the software for its intended purpose
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-4
Goals of Software Engineering
• Solve the right problem– more difficult than it might seem
– client interaction is key
• Deliver a solution on time and under budget– there are always trade-offs
• Deliver a high-quality solution– beauty is in the eye of the beholder
– we must consider the needs of various stakeholders
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-5
FIGURE 1.1 Aspects of software quality
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-6
Development Models
• A development life cycle defines a process to be followed during product development
• Many software development models have been introduced
• All of them address the following fundamental issues in one way or another:– problem analysis
– design
– implementation
– evaluation
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-7
Problem Analysis
• We must specify the requirements of the software system
• Must be based on accurate information
• Various techniques:– discussions and negotiations with the client
– modeling the problem structure and data flow
– observation of client activities
– analysis of existing solutions and systems
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-8
Design
• We must specify the solution
• You wouldn't consider building a bridge without a design
• Design involves determining:– the overall software structure (architecture)
– the key objects, classes, and their relationships
• Alternatives should be considered
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-9
Implementation
• We must turn the design into functional software
• Too many people consider this the primary act of software development
• May involve the reuse of existing software components
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-10
Evaluation
• We must verify that the system conforms to the requirements
• This includes, but goes way beyond, testing code with test cases
• It is possible to build a system that has no bugs and yet is completely wrong
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-11
Maintenance
• After a system is initially developed, it must be maintained
• This includes:– fixing errors
– making enhancements to meet the changing needs of users
• The better the development effort, the easier the maintenance tasks will be
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-12
The Waterfall Model
• One of the earliest development models
• Each stage flows into the next
• Driven by documentation
• Advantages:– Lays out clear milestones and deliverables
– Has high visibility – managers and clients can see the status
• Disadvantages:– late evaluation
– not realistic in many situations
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-13
FIGURE 1.2 The waterfall software development model
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-14
The Spiral Model
• Developed by Barry Boehm in the mid '80s
• Embraces an iterative process, where activities are performed over and over again for different aspects of the system
• Designed to reduce the risks involved
• Continually refines the requirements
• Each loop through the spiral is a complete phase of the development
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-15
FIGURE 1.3 The spiral model of software development
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-16
The Evolutionary Model
• Like the spiral model, an evolutionary approach embraces continual refinement
• Intermediate versions of the system are created for evaluation by both the developers and the client
• May be more difficult to maintain depending on the attention given to the iterations
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-17
FIGURE 1.4 The evolutionary development model
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-18
The Unified Modeling Language
• The Unified Modeling Language (UML) has become a standard notation for software design
• It is unified in the sense that it is the synthesis of three separate notations
• It is language independent
• It includes various types of diagrams which use specific icons and notations
• However, it is flexible – the details you include in a given diagram depend on what you are trying to capture and communicate
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-19
UML Class Diagrams• UML class diagrams include:
– The classes used in the system
– The static relationships among classes
– The attributes and operations of each class
– The constraints on the connections among objects
• An attribute is class level data, including variables and constants
• An operation is essentially equivalent to a method
• May include visibility details
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-20
FIGURE 1.5 LibraryItem class diagram
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-21
FIGURE 1.6 A UML class diagram showing inheritance relationships
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-22
FIGURE 1.7 A UML class diagram showing an association
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-23
FIGURE 1.8 One class shown as an aggregate of other classes
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-24
FIGURE 1.9 A UML diagram showing a class implementing an interface
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-25
FIGURE 1.10 One class indicating its use of another
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-26
Error Handling
• How problems are handled in a software system is a key design element
• In Java, an error generally represents an unrecoverable situation
• An exception is an unusual situation that might be handled various ways
• Design questions include:– how are problems identified?
– where are exceptions thrown and caught?
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-27
Analysis of Algorithms
• An aspect of software quality is the efficient use of resources, including the CPU
• Algorithm analysis is a core computing topic
• It gives us a basis to compare the efficiency of algorithms
• Example: which sorting algorithm is more efficient?
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-28
Growth Functions
• The analysis is defined in general terms, based on:– the problem size (ex: number of items to sort)
– key operation (ex: comparison of two values)
• A growth function shows the relationship between the size of the problem (n) and the time it takes to solve the problem
t(n) = 15n2 + 45 n
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-29
Growth Functions
• It's not usually necessary to know the exact growth function
• The key issue is the asymptotic complexity of the function – how it grows as n increases
• Determined by the dominant term in the growth function
• This is referred to as the order of the algorithm
• We often use Big-Oh notation to specify the order, such as O(n2)
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-30
FIGURE 1.11 Some growth functions and their asymptotic complexity
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-31
FIGURE 1.12 Increase in problem size with a ten-fold increase in processor speed
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-32
FIGURE 1.13 Comparison of typical growth functions
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-33
Analyzing Loop Execution
• A loop executes a certain number of times (say n)
• Thus the complexity of a loop is n times the complexity of the body of the loop
• When loops are nested, the body of the outer loop includes the complexity of the inner loop
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-34
Analyzing Loop Execution
• The following loop is O(n) because the loop executes n times and the body of the loop is O(1):
for (int i=0; i<n; i++)
{
x = x + 1;
}
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-35
Analyzing Loop Execution• The following loop is O(n2) because the loop
executes n times and the body of the loop, including a nested loop, is O(n):
for (int i=0; i<n; i++)
{
x = x + 1;
for (int j=0; j<n; j++)
{
y = y - 1;
}
}
Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-36
SE and Data Structures
• The data structures examined in this book lay the foundation for developing complex software
• Software Engineering techniques are needed as our software grows more complex
• As we discuss data structures, we will also practice good software engineering