Software Design and Development Techniques

1
Software Design and Development Techniques
2
Acknowledgment

• Some of the slides are adapted from Geoff
  Sutcliffe, JETT Workshop II, Department of
  Computer Science, University of Miami.

3
What is Software Engineering?

• Process of developing maintaining large
  software systems.
• Uses techniques from the discipline of
  engineering.
• Different people could be working on the software
  (problem analysers, solution designers,
  programmers, managers)
• Systems are expected to be
• Reliable
• Economical
• Flexible
• User-friendly
• Efficient
• Documentation and communication are very
  important

4
Software Engineering?

• Software development is quite different from the
  traditional engineering disciplines. At best, it
  is an immature engineering discipline. For
  software development to become a true engineering
  discipline, software developers must have
  mechanism to carry out the analysis of design,
  ensure no recurrence of known failures, and
  codify design knowledge."

5
Things to Avoid

• Lack of Planning
• Do not type in code "off the top of your head"
  (hacking).
• Develop algorithms to a stage where it is easy to
  translate them into code
• Lack of Time Scheduling
• Do not expect to produce the entire solution
  quickly
• During program development, several revisions of
  algorithms are likely
• Lack of attention to detail
• Program code must be VERY precise
• Note it is extremely frustrating to search for
  errors in pages of code

6
Things to Do

• Plan well, program development is an art form
• Start early, don't waste time
• Be patient, don't expect to get it right the
  first time
• Handle frustration, take regular breaks

7
Software Life Cycle

• Requirement Analysis
• Design
• Implementing and Component Testing
• Integration and System Testing
• Maintenance

8
Analysis

• Describe the problem yourself, as clearly as
  possible
• Problems must be clearly understood before
  attempting solutions
• Figure out exactly what is required of the
  solution
• Problem statements may not express all relevant
  information
• To be determined
• Information provided (Input data, and its format)
  
• Expected results (Output data, and its format)
• How to handle data entry errors
• Things that may be assumed
• How to structure/record solution information (the
  kind of information, and its quantity)
• How end users will interact with the program
  (user interface)

9
Analysis - continued

• Top-down analysis
• Divide the overall problem into smaller
  sub-problems
• If a sub-problem is still complex, then repeat
  this process. This creates sub-sub-problems, and
  so on.
• When a sub-problem becomes trivial, then the
  process stops.
• The lowest level sub-problems should have
  singular objectives.
• Results in a structure chart

10
Design

• Results in a very detailed specification of the
  software
• Developing an Algorithm
• Algorithm A sequence of clear steps for solving
  a problem
• Algorithms have a unique starting point, and one
  or more unique ending points
• Each step must have only one meaning
• The sequence of steps must be clear

11
Coding and documentation

• Given a clear solution, translate the algorithm
  into code
• Should be easy, assuming the design is good
  enough
• Good/precise solutions mean easy translation into
  code
• Common mistake Coding too early in software
  development
• Documenting the program is vital
• Documenting the solution (problem analysis,
  algorithm, design)
• Comments in the program code
• End user information (how to use the program)
• This aids future development of the solution or
  program

12
Testing/Verification

• Vital, if software reliability is to be obtained
• May require re-development of solution/algorithm/p
  rogram
• Testing the program involves
• Testing individual modules
• Testing entire software on a large amount of data
  
• Field Testing
• Allow selected users to experiment with the
  software to help discover any problems

13
Test cases

• Trying a set of inputs
• Observing the outputs of the program
• If they are not what is expected, there are
  "bugs" in the program
• Choosing test cases
• Use known input/output situations
• Use extremes of data
• Test valid and invalid inputs

14
Maintenance

• Activities after delivery of the software system
  to improve the performance,
• fixing the bugs, service enhancements and
  adapting to the new technologies and
  environments.
• Good documentation and program comments aid this
  task greatly

15
Example A Metric Conversion Problem

• Initial statement of the problemA fabric store
  requires a program to help them convert
  measurements in square metres to square yards.
• ClarificationThe required program must allow
  the user to enter a real number representing
  square metres, and calculates the equivalent real
  number representation in square yards, and
  displays both values in a readable way on the
  computer screen.
• It must be obvious which value is in square
  metres and which is in square yards.

16
Example A Metric Conversion Problem
17
Example -design

• Gather data
• 1.1 Prompt user for square metres
• 1.2 Get the value in square metres from the user
• Perform calculation
• 2.1 square yards is 1.196 times the square metres
  
• Display results
• 3.1 Display on the monitor the value in square
  metres
• 3.2 Display on the monitor the value in square
  yards

18
Example A Pizza Place Problem

• Initial statement of the problemWrite a program
  to find the unit price for a given pizza. The
  size of the pizza will be provided in inches. The
  result must be cost/inch.
• ClarificationThe program must obtain
  information about the pizza
• a real number representing its size in inches,
• and a real number representing its total cost.
• The result is a unit cost (a real number
  representing price per square inch).

19
Example A Pizza Place Problem
20
Programming Style

• Identifiers
• Start with a letter, and contain letters and
  digits. Letters are case sensitive.
• Use meaningful names
• By convention
• Class identifiers are nouns, and start with upper
  case.
• Data value identifiers (including object
  identifiers) start with lower case.
• Object identifiers are often named after their
  class.
• Method identifiers are verbs, and start with
  lower case.
• New words within identifiers start with upper
  case.
• Initialized final variables (constants) are all
  upper case with _ as the word separator.

21
Indentation and Lines

• By convention
• Indent blocks 2-4 characters consistently
• Use space (NOT tabs) for indenting (portability
  law)
• No line longer than 80 characters Continuations
  against the left margin
• Use a consistent style ...

22
Programming Style - Comments

• Comments
• Code must be documented using comments.
• On a single line starting with //, e.g., //----
• In / / pairs
• ...

23
Object Oriented Software Design

• Object-Oriented Design
• Concepts
• Focussed on the data rather than the manipulation
  
• Larger software components are constructed from
  smaller software components (objects)
• Objects can be customized and combined in many
  situations
• Benefits
• The analysis, design, and coding phases merge.
  Software objects represent the "real" objects
  being modelled.
• Objects are reusable, which avoids "re-inventing
  the wheel"
• Development is incremental
• Note Not all problems are "best" solved with one
  technique or another

24
Object Oriented Design Process

• Analysis
• Domain
• Identify entities in the problem domain (these
  often correspond to classes or objects for the
  design phase)
• Actors are things that do stuff in the reality
• Function points
• List what things are done by actors
• List what things are done by non-actors (can be
  none)
• Scenarios
• Walk through typical sequences of events
• Ensure all entities and functions are identified
• Study existing systems - it may be possible to
  reuse or adapt an existing solution

25
Object Oriented Design Process

• Design
• Classes and objects
• List all things (actors and other) that appear in
  the analysis - these correspond to classes.
• List all things that appear in the scenarios -
  these correspond to objects - and ensure that
  classes are listed for them.
• Data of classes and objects
• For each class list the data that needs to be
  stored
• Differentiate between class and instance data
• Methods of classes and objects
• For each class list what actions it must be able
  to perform
• Differentiate between class (static) and instance
  methods

26
What Is an Object?

• Objects are key to understanding object-oriented
  technology. Look around right now and you'll find
  many examples of real-world objects your desk,
  your television set, your bicycle.
• Software objects are conceptually similar to
  real-world objects they too consist of state and
  related behaviour. An object stores its state in
  fields (variables in some programming languages)
  and exposes its behaviour through methods
  (functions in some programming languages).

27
What Is a Class?

• In the real world, you'll often find many
  individual objects all of the same kind.
• There may be thousands of other bicycles in
  existence, all of the same make and model. Each
  bicycle was built from the same set of blueprints
  and therefore contains the same components.
• In object-oriented terms, we say that your
  bicycle is an instance of the class of objects
  known as bicycles.
• A class is the blueprint from which individual
  objects are created.

28
Example- Bicycle class
29
Example- Bicycle object