Docstoc

SE

Document Sample
SE Powered By Docstoc
					Software
Engineering

          Young S. Cho
 Department of Computer Science
              and
     Multimedia Engineering
Software Engineering
I. Introduction
II. Software Processes
III. Project Planning
IV. Software Requirements
V. Design
VI. Development
VII. Verification and Validation
VIII.Testing and Debugging
IX. Project Management

                                   1
Chapter 1:
Introduction

       Software, Program, and System
               Program vs. Software
                 What is Software?
                What is a System?
                Software Crisis
            Software Engineering
             Systems Engineering
 Software Engineering vs. Systems Engineering
           Software Characteristics


                                                2
Software, Program, and System

       Program vs. Software
         Program: an ordered set of
          instructions to solve a specific problem.
         Software: Computer programs and
          associated documentation such as
          requirements, design models and user
          manuals.




                                                 3
What is Software?
   Software products may be developed for a
    particular customer or may be developed for a
    general market.
   Software products may be
  •    Generic - developed to be sold to a range of
       different customers e.g. PC software such as
       Excel or Word.
  •    Bespoke (custom) - developed for a single
       customer according to their specification.
   New software can be created by developing new
    programs, configuring generic software systems
    or reusing existing software.
   Computer programs and associated
    documentation such as requirements, design
    models and user manuals.                        4
What is a system?
   A purposeful collection of inter-related
    components working together to achieve
    some common objective.
   A system may include software,
    mechanical, electrical and electronic
    hardware and be operated by people.
   System components are dependent on
    other system components.
   The properties and behaviour of system
    components are inextricably inter-mingled.

                                            5
Software Crisis
   The size of software has grown explosively.
   The complexity of software applications has
    expanded.
   The nature of software applications has
    become more critical.
   The demand for qualified software
    professionals has increased.
   As the result, software cost has highly
    increased.
   Software development tools and
    methodologies have not continued to
    dramatically improve the ability to develop
    software.

                                                  6
Software Engineering
   Software engineering is an engineering
    discipline that is concerned with all
    aspects of software production.
   Software engineers should adopt a
    systematic and organised approach to
    their work and use appropriate tools and
    techniques depending on the problem to
    be solved, the development constraints
    and the resources available.
   The economies of ALL developed nations
    are dependent on software.
                                               7
Software Engineering (cont’d)

   More and more systems are software
    controlled.
   Software engineering is concerned with
    theories, methods and tools for professional
    software development.
   Expenditure on software represents a
    significant fraction of GNP in all developed
    countries.
   The aim is to improve both software
    development productivity and software
    quality.

                                                   8
Systems Engineering
   Specifying, designing, implementing,
    validating, deploying and maintaining
    socio-technical systems.
   Concerned with the services provided
    by the system, constraints on its
    construction and operation and the
    ways in which it is used.




                                            9
Software Engineering vs.
       Systems Engineering
       Systems engineering is concerned with all
        aspects of computer-based systems
        development including hardware, software
        and process engineering.
         System engineers are involved in system
          specification, architectural design, integration
          and deployment.
       Software engineering is part of this process
        concerned with developing the software
        infrastructure, control, applications and
        databases in the system.

                                                         10
Software Characteristics

   Software is engineered.
   Software doesn‘t wear out.
   Software is complex.




                                 11
Wear vs. Deterioration




                         12
    Attributes of Good Software

       The software should deliver the required functionality
        and performance to the user and should be
        maintainable, dependable and acceptable.
         Maintainability: Software must evolve to meet
          changing needs.
         Dependability: Software must be trustworthy.
         Efficiency: Software should not make wasteful
          use of system resources.
         Acceptability: Software must accepted by the
          users for which it was designed. This means it
          must be understandable, usable and compatible
          with other systems.


                                                         13
 Chapter 2:
 Software Processes


Software Process, Models, and Tools
     Software Process Models


                                      14
The Software Process
       A structured set of activities required to
        develop or to maintain a software system
         Specification;
         Design and implementation;
         Validation;
         Evolution.
       A software process model is an abstract
        representation of a process. It presents a
        description of a process from some
        particular perspective.
                                                15
Software Specification
       The process of establishing what
        services are required and the
        constraints on the system‘s operation
        and development.
       Requirements engineering process
    •     Feasibility study;
    •     Requirements elicitation and analysis;
    •     Requirements specification;
    •     Requirements validation.

                                               16
Software Design and Implementation

  The process of converting the system
   specification into an executable system.
  Software design
  • Design a software structure that
     realises the specification;
  Implementation
  • Translate this structure into an
     executable program;
  The activities of design and
   implementation are closely related and
   may be inter-leaved.
                                              17
Programming, Testing,
       and Debugging
   Programming: Translate a design into a
    program.
   Testing: Uncover (discover) errors.
   Debugging: Remove errors from the
    program.
   Programming is a personal activity - there is
    no generic programming process.
   Programmers carry out some program
    testing to discover faults in the program and
    remove these faults in the debugging
    process.
                                               18
Software Validation
   Verification and validation (V & V) is
    intended to show that a system conforms to
    its specification and meets the requirements
    of the system customer.
   Involves checking and review processes and
    system testing.
   System testing involves executing the
    system with test cases that are derived
    from the specification of the real data to be
    processed by the system.


                                                19
Testing Stages
       Component or unit testing
         Individual components are tested
          independently;
         Components may be functions or objects or
          coherent groupings of these entities.
       System testing
         Testing of the system as a whole. Testing of
          emergent properties is particularly important.
       Acceptance testing
         Testing with customer data to check that the
          system meets the customer‘s needs.

                                                    20
Software Evolution
   Software is inherently flexible and can
    change.
   As requirements change through
    changing business circumstances, the
    software that supports the business
    must also evolve and change.
   Although there has been a demarcation
    between development and evolution
    (maintenance) this is increasingly
    irrelevant as fewer and fewer systems
    are completely new.
                                              21
Software Process Model
       A simplified representation of a software process,
        presented from a specific perspective.
       Examples of process perspectives are
    •      Workflow perspective - sequence of activities;
    •      Data-flow perspective - information flow
    •      Role/action perspective - who does what.
       Generic process models:
    •      The Waterfall model
    •      Iterative development models
    •      Component-based software engineering


                                                        22
Software Process Models
I.        The waterfall model
            Separate and distinct phases of specification and
             development.
II.   Component-based software engineering: The system is
      assembled from existing components.
III. Prototyping Model
IV.   RAD Model
V.    Evolutionary Software Process Models: Specification,
      development and validation are interleaved.
        Evolutionary Development
        Throw-away Prototyping
            Incremental Model
            Spiral Model
VI.       Agile Process
            XP (Extreme Programming)
VII. Reuse-oriented Model
VIII. Formal Method Model
                                                                 23
Waterfall Model




                  24
Waterfall Model Phases
   Requirements analysis and definition
   System and software design
   Implementation and unit testing
   Integration and system testing
   Operation and maintenance
   The main drawback of the waterfall model is
    the difficulty of accommodating change
    after the process is underway. One phase
    has to be complete before moving onto the
    next phase.

                                              25
Waterfall Model Problems
   Inflexible partitioning of the project into
    distinct stages makes it difficult to respond
    to changing customer requirements.
   Therefore, this model is only appropriate
    when the requirements are well-understood
    and changes will be fairly limited during the
    design process.
   Few business systems have stable
    requirements.
   The waterfall model is mostly used for large
    systems engineering projects where a
    system is developed at several sites.
                                                26
Component-Based
       Software Engineering
 Based on systematic reuse where
  systems are integrated from existing
  components or COTS (Commercial-off-
  the-shelf) systems.
 Process stages
 • Component analysis;
 • Requirements modification;
 • System design with reuse;
 • Development and integration.
 This approach is becoming increasingly
  used as component standards have
  emerged.                                 27
Prototyping Model
       Throw-away prototyping
         Objective is to understand the system
          requirements. Should start with poorly
          understood requirements to clarify what is
          really needed.
       Prototyping as an Evolutionary Model:
         Communication
         Quick Plan
         Modeling and Quick Design
         Construction of Prototype
         Deployment Delivery and Feedback
         Go to 1 until Finish

                                                       28
Prototyping
   For some large systems, incremental
    iterative development and delivery
    may be impractical; this is especially
    true when multiple teams are working
    on different sites.
   Prototyping, where an experimental
    system is developed as a basis for
    formulating the requirements may be
    used. This system is thrown away
    when the system specification has
    been agreed.                           29
Rapid Software Development
   Because of rapidly changing business
    environments, businesses have to
    respond to new opportunities and
    competition.
   This requires software and rapid
    development and delivery is not often
    the most critical requirement for
    software systems.
   Businesses may be willing to accept
    lower quality software if rapid delivery
    of essential functionality is possible.
                                           30
Rapid Application Development

   Agile methods have received a lot of
    attention but other approaches to
    rapid application development have
    been used for many years.
   These are designed to develop data-
    intensive business applications and
    rely on programming and presenting
    information from a database.


                                           31
RAD Environment Tools
   Database programming language
   Interface generator
   Links to office applications
   Report generators




                                    32
Evolutionary Development
       Exploratory development
    •     Objective is to work with customers and to
          evolve a final system from an initial outline
          specification. Should start with well-
          understood requirements and add new
          features as proposed by the customer.
       Throw-away prototyping
    •     Objective is to understand the system
          requirements. Should start with poorly
          understood requirements to clarify what is
          really needed.
                                                    33
Evolutionary Development (cont’d)




                                34
Evolutionary Development (cont’d)

   Problems
  •   Lack of process visibility;
  •   Systems are often poorly structured;
  •   Special skills (e.g. in languages for rapid
      prototyping) may be required.
   Applicability
  •   For small or medium-size interactive systems;
  •   For parts of large systems (e.g. the user
      interface);
  •   For short-lifetime systems.

                                               35
Incremental Model
   Rather than deliver the system as a
    single delivery, the development and
    delivery is broken down into increments
    with each increment delivering part of the
    required functionality.
   User requirements are prioritised and the
    highest priority requirements are included
    in early increments.
   Once the development of an increment is
    started, the requirements are frozen
    though requirements for later increments
    can continue to evolve.
                                                 36
Incremental Development




                          37
Incremental Development

 Advantages
  •   Customer value can be delivered with
      each increment so system
      functionality is available earlier.
  •   Early increments act as a prototype to
      help elicit requirements for later
      increments.
  •   Lower risk of overall project failure.
  •   The highest priority system services
      tend to receive the most testing.
                                           38
Spiral Model
   Process is represented as a spiral
    rather than as a sequence of activities
    with backtracking.
   Each loop in the spiral represents a
    phase in the process.
   No fixed phases such as specification
    or design - loops in the spiral are
    chosen depending on what is required.
   Risks are explicitly assessed and
    resolved throughout the process.
                                         39
Spiral Model: Software Process




                                 40
Spiral Model Sectors
       Objective setting
    •     Specific objectives for the phase are
          identified.
       Risk assessment and reduction
    •     Risks are assessed and activities put in place
          to reduce the key risks.
       Development and validation
    •     A development model for the system is
          chosen which can be any of the generic
          models.
       Planning
    •     The project is reviewed and the next phase of
          the spiral is planned.
                                                       41
Agile Process
   Is driven by customer descriptions
    of what is required (scenarios)
   Recognizes that plans are short-
    lived
   Develops software iteratively with a
    heavy emphasis on construction
    activities
   Delivers multiple ‗software
    increments‘
   Adapts as changes occur
                                           42
What is Agility?

    Effective (rapid and adaptive) response to
     change
 Effective communication among all
     stakeholders
 Drawing the customer onto the team
 Organizing a team so that it is in control of
     the work performed
Yielding …
 Rapid, incremental delivery of software

                                            43
Manifesto for
    Agile Software Development

“We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
   •Individuals and interactions over processes and
   tools
   •Working software over comprehensive
   documentation
   •Customer collaboration over contract negotiation
   •Responding to change over following a plan
That is, while there is value in the items on the right,
we value the items on the left more.”

               Kent Beck et al
                                                       44
Agile Modeling
    Originally proposed by Scott Ambler
    Suggests a set of agile modeling principles
    • Model with a purpose
    • Use multiple models
    • Travel light
    • Content is more important than
       representation
    • Know the models and the tools you use
       to create them
    • Adapt locally
                                              45
Extreme Programming (XP)
   An approach to development based
    on the development and delivery of
    very small increments of functionality
   Relies on constant code improvement,
    user involvement in the development
    team and pairwise programming.




                                         46
Extreme Programming (cont’d)

       The most widely used agile process,
        originally proposed by Kent Beck
    •     XP   Planning
    •     XP   Design
    •     XP   Coding
    •     XP   Testing




                                              47
Extreme Programming (cont’d)
       XP Planning
    •     Begins with the creation of ―user stories‖
    •     Agile team assesses each story and assigns a cost
    •     Stories are grouped to for a deliverable increment
    •     A commitment is made on delivery date
    •     After the first increment ―project velocity‖ is used
          to help define subsequent delivery dates for other
          increments
       XP Design
    •     Follows the KIS principle
    •     Encourage the use of CRC cards
    •     For difficult design problems, suggests the creation
          of ―spike solutions‖—a design prototype
    •     Encourages ―refactoring‖—an iterative refinement
          of the internal program design
                                                             48
Extreme Programming (cont’d)

   XP Coding
  •   Recommends the construction of a unit
      test for a store before coding commences
  •   Encourages ―pair programming‖
   XP Testing
  •   All unit tests are executed daily
  •   ―Acceptance tests‖ are defined by the
      customer and executed to assess
      customer visible functionality


                                             49
Reuse-Oriented Model




                       50
Formal Methods
       Formal specification is part of a more
        general collection of techniques that are
        known as ‗formal methods‘.
       These are all based on mathematical
        representation and analysis of software.
       Formal methods include
    •     Formal specification;
    •     Specification analysis and proof;
    •     Transformational development;
    •     Program verification.


                                                    51
Problems with
Conventional Specification

   Contradictions
   Ambiguities
   Vagueness
   Incompleteness
   Mixed levels of abstraction

                                  52
Formal Specification
     Desired properties—consistency, completeness, and
      lack of ambiguity—are the objectives of all
      specification methods.
     The formal syntax of a specification language enables
      requirements or design to be interpreted in only one
      way, eliminating ambiguity that often occurs when a
      natural language (e.g., English) or a graphical
      notation must be interpreted.
    •     The descriptive facilities of set theory and logic
          notation enable clear statement of facts
          (requirements).
      Consistency is ensured by mathematically proving
      that initial facts can be formally mapped (using
      inference rules) into later statements within the
      specification.                                         53
Development costs with formal
specification




                                54
    Formal Specification Example

     List Specification (part)

Tail (Cons (L, v)) = if L = Create then Create
                         else Cons (Tail (L), v).

    Cons ([5, 7], 9) = [5, 7, 9]
    Tail ([5, 7, 9])
    = Tail (Cons ( [5, 7], 9))
    = Cons (Tail ([5, 7]), 9)
    = Cons (Tail (Cons ([5], 7)), 9)
    = Cons (Cons (Tail ([5]), 7), 9)
    = Cons (Cons (Tail (Cons ([], 5)), 7), 9)
    = Cons (Cons ([Create], 7), 9)
    = Cons ([7], 9)
    = [7, 9]                                        55
Chapter 3:
Project Planning

       Project Planning
      Feasibility Studies
      Risk Management
          Estimation
      Project Scheduling
       Software Quality
  Configuration Management


                             56
Software Project Planning

   The overall goal of project planning is
    to establish a pragmatic strategy for
    controlling, tracking, and monitoring
    a complex technical project.
   Why?
   So the end result gets done on time,
    with quality!



                                          57
Project Planning Task Set

       Establish project scope.
       Determine feasibility.
       Analyze risks.
       Define required resources.
    •     Determine require human resources.
    •     Define reusable software resources.
    •     Identify environmental resources.



                                                58
Project Planning Task Set (cont’d)

       Estimate cost and effort
    •     Decompose the problem
    •     Develop two or more estimates using size,
          function points, process tasks or use-cases
    •     Reconcile the estimates
       Develop a project schedule
    •     Establish a meaningful task set
    •     Define a task network
    •     Use scheduling tools to develop a timeline
          chart
    •     Define schedule tracking mechanisms
                                                       59
Project Planning Task Set (cont’d)

       Software Quality Assurance
         Quality Concepts
         Software Quality Assurance
         Reviews
         Statistical Quality Assurance
         Formal Approaches
         Software Reliability
         Configuration Management


                                          60
What is Scope?
     Software scope describes
    • the functions and features that are to
        be delivered to end-users
    • the data that are input and output
    • the ―content‖ that is presented to
        users as a consequence of using the
        software
    •    the performance, constraints,
        interfaces, and reliability that bound
        the system.
                                            61
What is Scope? (cont‘d)

       Scope is defined using one of
        two techniques:
    •    A narrative description of software
         scope is developed after
         communication with all
         stakeholders.
    •    A set of use-cases is developed by
         end-users.


                                               62
To Understand Scope ...
   Understand the customers needs
   understand the business context
   understand the project boundaries
   understand the customer‘s motivation
   understand the likely paths for change
   understand that even when you
    understand, nothing is guaranteed!



                                        63
Feasibility Studies
       A feasibility study decides whether or
        not the proposed system is
        worthwhile.
       A short focused study that checks
         If the system contributes to
          organisational objectives;
         If the system can be engineered using
          current technology and within budget;
         If the system can be integrated with
          other systems that are used.
                                              64
Feasibility Study Implementation

       Based on information assessment (what is
        required), information collection and report
        writing.
       Questions for people in the organisation
         What if the system wasn‘t implemented?
         What are current process problems?
         How will the proposed system help?
         What will be the integration problems?
         Is new technology needed? What skills?
         What facilities must be supported by the
          proposed system?

                                                       65
Risk Management
   Software Risks
   Risk Identification
   Risk Projection
   Risk Migration, Monitoring, and
    Management
   Safety Risks and Hazards




                                      66
    Risk Components
    performance risk—the degree of uncertainty
     that the product will meet its requirements and
     be fit for its intended use.
    cost risk—the degree of uncertainty that the
     project budget will be maintained.
    support risk—the degree of uncertainty that
     the resultant software will be easy to correct,
     adapt, and enhance.
    schedule risk—the degree of uncertainty that
     the project schedule will be maintained and
     that the product will be delivered on time.

                                                 67
    Risk Identification
    Product size—risks associated with the overall
     size of the software to be built or modified.
    Business impact—risks associated with
     constraints imposed by management or the
     marketplace.
    Customer characteristics—risks associated with
     the sophistication of the customer and the
     developer's ability to communicate with the
     customer in a timely manner.
    Process definition—risks associated with the
     degree to which the software process has been
     defined and is followed by the development
     organization.


                                                 68
Risk Identification (cont’d)
   Development environment—risks
    associated with the availability and
    quality of the tools to be used to build
    the product.
   Technology to be built—risks associated
    with the complexity of the system to be
    built and the "newness" of the
    technology that is packaged by the
    system.
   Staff size and experience—risks
    associated with the overall technical and
    project experience of the software
    engineers who will do the work.
                                            69
Risk Projection
       Risk projection, also called risk
        estimation, attempts to rate each risk
        in two ways:
         the likelihood or probability that the risk
          is real
         the consequences of the problems
          associated with the risk, should it occur.




                                                        70
Risk Projection (cont’d)
   The are four risk projection steps:
      establish a scale that reflects the
        perceived likelihood of a risk
      delineate the consequences of
        the risk
      estimate the impact of the risk on
        the project and the product,
      note the overall accuracy of the
        risk projection so that there will
        be no misunderstandings.
                                         71
Risk Mitigation, Monitoring,
       and Management
mitigation—how can we avoid the risk?
monitoring—what factors can we track
 that will enable us to determine if the
 risk is becoming more or less likely?
management—what contingency plans
 do we have if the risk becomes a
 reality?



                                           72
Resources
       Human Resources
         Number
         Skills
         Location
       Reusable Software Resources
       Environmental Resources
         Software Tools
         Hardware
         Network Resources
                                      73
Estimation
 Estimation of resources, cost, and
  schedule for a software engineering
  effort requires
  experience
  access to good historical information
     metrics
  the courage to commit to quantitative
     predictions when qualitative
     information is all that exists
 Estimation carries inherent risk and this
  risk leads to uncertainty
                                          74
Project Estimation
   Project scope must be understood
   Elaboration (decomposition) is
    necessary
   Historical metrics are very helpful
   At least two different techniques
    should be used
   Uncertainty is inherent in the process



                                             75
Estimation Techniques

       Past (similar) project experience
       Conventional estimation techniques
         task breakdown and effort estimates
         size (e.g., FP) estimates
       Empirical models
       Automated tools




                                                76
Conventional Methods:
LOC/FP Approach

   compute LOC/FP using estimates
    of information domain values
   use historical data to build
    estimates for the project




                                     77
Typical Size-Oriented Metrics

errors per KLOC (thousand lines of code)
defects per KLOC
$ per LOC
pages of documentation per KLOC
errors per person-month
Errors per review hour
LOC per person-month
$ per page of documentation


                                       78
Typical Function-Oriented Metrics


   errors per FP (thousand lines of code)
   defects per FP
   $ per FP
   pages of documentation per FP
   FP per person-month




                                             79
Function-Based Metrics

   The function point metric (FP), first
    proposed by Albrecht [ALB79], can be
    used effectively as a means for
    measuring the functionality delivered
    by a system.
   Function points are derived using an
    empirical relationship based on
    countable (direct) measures of
    software's information domain and
    assessments of software complexity
                                        80
Function-Based Metrics (cont’d)

    Information domain values are defined in
     the following manner:
     number of external inputs (EIs)
     number of external outputs (EOs)
     number of external inquiries (EQs)
     number of internal logical files (ILFs)
     Number of external interface files (EIFs)



                                           81
Function Points


     Information                                      Weighting factor
    Domain Value                    Count       simple average complex

 External Inputs ( EIs)                     3     3          4            6   =

 External Outputs ( EOs)                    3     4          5            7
                                                                              =

 External Inquiries ( EQs)                  3     3          4            6   =

 Internal Logical Files ( ILFs)             3     7         10           15   =

                                            3     5          7           10   =
 External Interface Files ( EIFs)

 Count total




                                                                                  82
Why Opt for FP?
   Programming language independent
   Used readily countable characteristics
    that are determined early in the
    software process
   Does not ―penalize‖ inventive (short)
    implementations that use fewer LOC
    that other more clumsy versions
   Makes it easier to measure the impact
    of reusable components

                                         83
Object-Oriented Metrics
   Number of scenario scripts (use-cases)
   Number of support classes (required to
    implement the system but are not
    immediately related to the problem domain.)
   Average number of support classes per key
    class (analysis class)
   Number of subsystems (an aggregation of
    classes that support a function that is visible
    to the end-user of a system)



                                                 84
WebE Project Metrics
   Number of static Web pages (the end-user has
    no control over the content displayed on the
    page)
   Number of dynamic Web pages (end-user
    actions result in customized content displayed
    on the page)
   Number of internal page links (internal page
    links are pointers that provide a hyperlink to
    some other Web page within the WebApp)
   Number of persistent data objects
   Number of external systems interfaced
   Number of static content objects
   Number of dynamic content objects
   Number of executable functions
                                                     85
Tool-Based Estimation

I. Input to the tool:
    1. project characteristics
    2. calibration factors
    3. LOC/FP data
II. Output from the tool:
    1. Estimation



                                 86
Empirical Estimation Models

Effort =
    Tuning Coefficient * Size   Exponent

•   Effort: Usually derived as person-
    months of effort required
•   Tuning Coefficient: Either a constant
    or a number derived based on
    complexity of project
•   Size: Usually LOC but may also be FP
•   Exponent: Empirically derived

                                           87
    COCOMO-II
    COCOMO II is actually a hierarchy of estimation
     models that address the following areas:
        Application composition model. Used during the
         early stages of software engineering, when
         prototyping of user interfaces, consideration of
         software and system interaction, assessment of
         performance, and evaluation of technology
         maturity are paramount.
        Early design stage model. Used once
         requirements have been stabilized and basic
         software architecture has been established.
        Post-architecture-stage model. Used during the
         construction of the software.

                                                        88
The Software Equation

A dynamic multivariable model
    E = [LOC x B0.333/P]3 x (1/t4)
    where
    E = effort in person-months or
         person-years
    t = project duration in months or
         years
    B = ―special skills factor‖
    P = ―productivity parameter‖        89
Estimation for OO Projects
    Develop estimates using effort decomposition, FP
     analysis, and any other method that is applicable for
     conventional applications.
    Using object-oriented analysis modeling, develop use-
     cases and determine a count.
    From the analysis model, determine the number of key
     classes (called analysis classes).
    Categorize the type of interface for the application and
     develop a multiplier for support classes:

      Interface type              Multiplier
       No GUI                       2.0
       Text-based user interface    2.25
       GUI                          2.5
       Complex GUI                  3.0
                                                            90
Estimation for OO Projects (cont’d)

    Multiply the number of key classes (step 3)
     by the multiplier to obtain an estimate for
     the number of support classes.
    Multiply the total number of classes (key +
     support) by the average number of work-
     units per class. Lorenz and Kidd suggest 15
     to 20 person-days per class.
    Cross check the class-based estimate by
     multiplying the average number of work-
     units per use-case


                                                   91
Estimation for Agile Projects

     Each user scenario (a mini-use-case) is considered
      separately for estimation purposes.
     The scenario is decomposed into the set of software
      engineering tasks that will be required to develop it.
     Each task is estimated separately. Note: estimation can
      be based on historical data, an empirical model, or
      ―experience.‖
        Alternatively, the ‗volume‘ of the scenario can be
         estimated in LOC, FP or some other volume-oriented
         measure (e.g., use-case count).
     Estimates for each task are summed to create an
      estimate for the scenario.
        Alternatively, the volume estimate for the scenario is
         translated into effort using historical data.
     The effort estimates for all scenarios that are to be
      implemented for a given software increment are
      summed to develop the effort estimate for the increment.
                                                          92
    Project Scheduling
    Split project into tasks and estimate time and
     resources required to complete each task.
    Organize tasks concurrently to make optimal
     use of workforce.
    Minimize task dependencies to avoid delays
     caused by one task waiting for another to
     complete.
    Dependent on project managers intuition and
     experience.



                                                  93
Project Scheduling Process




                             94
Scheduling Problems
   Estimating the difficulty of problems
    and hence the cost of developing a
    solution is hard.
   Productivity is not proportional to the
    number of people working on a task.
   Adding people to a late project makes
    it later because of communication
    overheads.
   The unexpected always happens.
    Always allow contingency in planning.
                                          95
Bar Charts and Activity Networks

   Graphical notations used to illustrate
    the project schedule.
   Show project breakdown into tasks.
    Tasks should not be too small. They
    should take about a week or two.
   Activity charts show task
    dependencies and the the critical path.
   Bar charts show schedule against
    calendar time.

                                         96
Task Durations and Dependencies


     Activity   Duration (days)   Dependencies
       T1             8
       T2             15
       T3             15            T1 (M1)
       T4             10
       T5             10          T2, T4 (M2)
       T6             5           T1, T2 (M3)
       T7             20            T1 (M1)
       T8             25            T4 (M5)
       T9             15          T3, T6 (M4)
       T10            15          T5, T7 (M7)
       T11            7             T9 (M6)
       T12            10           T11 (M8)
                                                 97
Activity network
                               1 4/7 /03    15 d a ys
                                                                          15 d a ys
                                 M1               T3
            8 d ays                                                         T9
              T1                                5 d ays       4/8 /0 3                2 5/8 /0 3
                          2 5/7 /03
4/7 /03                                           T6            M4                      M6
                                M3
   s tart                                   2 0 d ays                                         7 d ays
              15 d ays
                                           T7                                                T1 1
                   T2
                             25/7 /03                         11/8 /0 3                             5/9 /0 3
  10 d a ys                                     10 d ays
                                M2                               M7                                M8
     T4                                           T5                        15 d a ys

                                                                               T1 0     10da ys
                   1 8/7 /03
                                                                                                   T12
                        M5
                                                  2 5 d ays
                                                       T8                                      Fin is h
                                                                                  19/9 /0 3                    98
Activity Timeline
       4/7       11/7           18/7        2 5/7   1/8    8/8   1 5/8   22/8     2 9/8   5/9        12/9   1 9/9

             Start
  T4
  T1
   T2
                     M1
                      T7
                     T3
                       M5
                           T8
                                       M3
                                       M2
                                       T6
                                       T5
                                                           M4
                                                      T9
                                                           M7
                                                           T10
                                                                                  M6
                                                                         T11
                                                                                                M8
                                                                                T12
                                                                                                               Fin is h   99
Staff Allocation

        4/7    1 1/7   18/7      2 5/7   1/8   8/8   15/8   2 2/8   2 9/8   5/9      1 2/9   19/9

Fred      T4
                            T8                                      T11
                                                                              T1 2
Jane      T1
                       T3
                                               T9
An ne     T2
                                    T6               T10

Jim                    T7

Mary                                T5


                                                                                                    100
Why Are Projects Late?
   an unrealistic deadline established by someone outside
    the software development group
   changing customer requirements that are not reflected
    in schedule changes;
   an honest underestimate of the amount of effort and/or
    the number of resources that will be required to do the
    job;
   predictable and/or unpredictable risks that were not
    considered when the project commenced;
   technical difficulties that could not have been foreseen in
    advance;
   human difficulties that could not have been foreseen in
    advance;
   miscommunication among project staff that results in
    delays;
   a failure by project management to recognize that the
    project is falling behind schedule and a lack of action to
    correct the problem                                    101
Scheduling Principles
   compartmentalization—define distinct tasks
   interdependency—indicate task
    interrelationship
   effort validation—be sure resources are
    available
   defined responsibilities—people must be
    assigned
   defined outcomes—each task must have an
    output
   defined milestones—review for quality
                                           102
Effort and Delivery Time



 Ef fort
 Cost
                                 Ea = m ( t d 4 / t a 4 )

            Impossible                 Ea = eff ort in person-months
              region                   t d = nominal deliv ery time for schedule
                                       t o = optimal development time (in terms of cost)
                                       t a = actual delivery time desir ed
    Ed



     Eo


                            td                          to                         development time
           Tmin = 0.75T d




                                                                                                      103
The Make-Buy Decision




                        104
Software Quality Assurance

   Quality Concepts
   Software Quality Cost
   Reviews
   Statistical Quality Assurance
   Formal Approaches
   Software Reliability
   Configuration Management


                                    105
    Quality
  The American Heritage Dictionary defines
   quality as
   ―a characteristic or attribute of something.‖
  For software, two kinds of quality may be
   encountered:
   Quality of design encompasses requirements,
     specifications, and the design of the system.
   Quality of conformance is an issue focused
     primarily on implementation.
   user satisfaction = compliant product + good
     quality + delivery within budget and
     schedule
                                               106
Software Quality


Conformance to explicitly stated functional and
performance requirements, explicitly documented
development standards, and implicit characteristics
that are expected of all professionally developed
software.




                                                      107
Cost of Quality

     Prevention costs include
        quality planning
        formal technical reviews
        test equipment
        Training
     Internal failure costs include
        rework
        repair
        failure mode analysis
     External failure costs are
        complaint resolution
        product return and replacement
        help line support
        warranty work                    108
    What Are Reviews?

    a meeting conducted by technical
     people for technical people
    a technical assessment of a work
     product created during the software
     engineering process
    a software quality assurance
     mechanism
    a training ground

                                           109
What Reviews Are Not

   A project summary or progress
    assessment
   A meeting intended solely to impart
    information
   A mechanism for political or personal
    reprisal!




                                            110
Statistical Quality Assurance

   Collect information on all defects.
   Find the causes of the defects.
   Move to provide fixes for the
    process.
   Example: Six-Sigma for
    Software Engineering



                                     111
Six-Sigma for Software Engineering

     The term ―six sigma‖ is derived from six standard
      deviations—3.4 instances (defects) per million
      occurrences—implying an extremely high quality standard.
     The Six Sigma methodology defines three core steps:
        Define customer requirements and deliverables and
         project goals via well-defined methods of customer
         communication
        Measure the existing process and its output to
         determine current quality performance (collect defect
         metrics)
        Analyze defect metrics and determine the vital few
         causes.
        Improve the process by eliminating the root causes of
         defects.
        Control the process to ensure that future work does not
         reintroduce the causes of defects.
                                                           112
Formal Approaches
   Rigorous syntax for programming
    languages
   Rigorous semantics for programming
    languages
   Rigorous approach to the specification
    of software requirements
   Then, the application of mathematical
    proof of correctness to demonstrate
    that a program conforms exactly to
    its specifications is possible.

                                        113
Software Reliability
   A simple measure of reliability is mean-
    time-between-failure (MTBF), where
           MTBF = MTTF + MTTR
   The acronyms MTTF and MTTR are mean-
    time-to-failure and mean-time-to-repair,
    respectively.
   Software availability is the probability that a
    program is operating according to
    requirements at a given point in time and is
    defined as
    Availability = [MTTF/(MTTF + MTTR)] x
    100%
                                                 114
Software Safety
   Software safety is a software quality
    assurance activity that focuses on the
    identification and assessment of
    potential hazards that may affect
    software negatively and cause an
    entire system to fail.
   If hazards can be identified early in
    the software process, software design
    features can be specified that will
    either eliminate or control potential
    hazards.                              115
Configuration Management

   Version Control
   Content Management




                           116
    Version Control
     Version control combines procedures and tools to
      manage different versions of configuration objects that
      are created during the software process
     A version control system implements or is directly
      integrated with four major capabilities:
         a project database (repository) that stores all
         relevant configuration objects
         a version management capability that stores all
         versions of a configuration object (or enables any
         version to be constructed using differences from past
         versions);
         a make facility that enables the software engineer to
         collect all relevant configuration objects and construct
         a specific version of the software.
         an issues tracking (also called bug tracking)
         capability that enables the team to record and track
         the status of all outstanding issues associated with
         each configuration object.
                                                              117
    Content Management
    The collection subsystem encompasses
     all actions required to create and/or
     acquire content, and the technical
     functions that are necessary to
     convert content into a form that can
        be represented by a mark-up language
        (e.g., HTML, XML
     organize content into packets that can
        be displayed effectively on the client-
        side.

                                            118
    Content Management (cont’d)
       The management subsystem implements a
        repository that encompasses the following
        elements:
         Content database—the information structure that
          has been established to store all content objects
         Database capabilities—functions that enable the
          CMS to search for specific content objects (or
          categories of objects), store and retrieve objects,
          and manage the file structure that has been
          established for the content
         Configuration management functions—the
          functional elements and associated workflow that
          support content object identification, version
          control, change management, change auditing,
          and reporting.                                 119
    Content Management (cont’d)

   The publishing subsystem extracts from the
    repository, converts it to a form that is
    amenable to publication, and formats it so that
    it can be transmitted to client-side browsers.
    The publishing subsystem accomplishes these
    tasks using a series of templates.




                                                 120
    Content Management (cont’d)

       Each template is a function that builds a
        publication using one of three different
        components [BOI02]:
         Static elements—text, graphics, media, and
          scripts that require no further processing are
          transmitted directly to the client-side
         Publication services—function calls to specific
          retrieval and formatting services that
          personalize content (using predefined rules),
          perform data conversion, and build appropriate
          navigation links.
         External services—provide access to external
          corporate information infrastructure such as
          enterprise data or ―back-room‖ applications. 121
Chapter 4:
Software
Requirements
       Requirements Analysis
      Types of Requirements
    Requirements Engineering
Requirements Engineering Processes
    Requirements Specification
         Analysis Modeling


                                     122
Requirements Analysis
    Requirements analysis
     specifies software‘s operational
       characteristics
     indicates software's interface with other
       system elements
     establishes constraints that software
       must meet




                                           123
Requirements Analysis (cont’d)

    Requirements analysis allows the software
     engineer (called an analyst or modeler in
     this role) to:
     elaborate on basic requirements
        established during earlier requirement
        engineering tasks
     build models that depict user scenarios,
        functional activities, problem classes and
        their relationships, system and class
        behavior, and the flow of data as it is
        transformed.

                                                 124
What is a requirement?
  It may range from a high-level abstract
   statement of a service or of a system
   constraint to a detailed mathematical
   functional specification.
  This is inevitable as requirements may serve
   a dual function
   May be the basis for a bid for a contract -
      therefore must be open to interpretation;
   May be the basis for the contract itself -
      therefore must be defined in detail;
   Both these statements may be called
      requirements.

                                             125
Software Requirements
   User Requirements
   Functional Requirements
   Non-functional Requirements
   Domain Requirements
   System Requirements




                                  126
Types of Requirement
  User requirements
   Statements in natural language plus
     diagrams of the services the system
     provides and its operational constraints.
     Written for customers.
  System requirements
   A structured document setting out
     detailed descriptions of the system‘s
     functions, services and operational
     constraints. Defines what should be
     implemented so may be part of a
     contract between client and contractor.
                                                 127
User Requirements
   Should describe functional and non-
    functional requirements in such a way
    that they are understandable by
    system users who don‘t have detailed
    technical knowledge.
   User requirements are defined using
    natural language, tables and
    diagrams as these can be understood
    by all users.

                                       128
User Requirements (cont’d)

   Functional requirements
   Non-functional requirements
   Domain requirements




                                  129
Functional and Non-functional
Requirements
       Functional requirements
         Statements of services the system should
          provide, how the system should react to
          particular inputs and how the system should
          behave in particular situations.
       Non-functional requirements
         constraints on the services or functions
          offered by the system such as timing
          constraints, constraints on the development
          process, standards, etc.
       Domain requirements
         Requirements that come from the application
          domain of the system and that reflect
          characteristics of that domain.
                                                        130
Functional Requirements
   Describe functionality or system
    services.
   Depend on the type of software,
    expected users and the type of
    system where the software is used.
   Functional user requirements may be
    high-level statements of what the
    system should do but functional
    system requirements should describe
    the system services in detail.
                                      131
Non-functional Requirements

   These define system properties and
    constraints e.g. reliability, response time
    and storage requirements. Constraints are
    I/O device capability, system
    representations, etc.
   Process requirements may also be specified
    mandating a particular CASE system,
    programming language or development
    method.
   Non-functional requirements may be more
    critical than functional requirements. If
    these are not met, the system is useless.

                                              132
Domain Requirements
   Derived from the application domain
    and describe system characteristics
    and features that reflect the domain.
   Domain requirements be new
    functional requirements, constraints
    on existing requirements or define
    specific computations.
   If domain requirements are not
    satisfied, the system may be
    unworkable.
                                            133
Domain Requirements Problems

       Understandability
         Requirements are expressed in the
          language of the application domain;
         This is often not understood by
          software engineers developing the
          system.
       Implicitness
         Domain specialists understand the
          area so well that they do not think of
          making the domain requirements
          explicit.                              134
System Requirements
   More detailed specifications of system
    functions, services and constraints
    than user requirements.
   They are intended to be a basis for
    designing the system.
   They may be incorporated into the
    system contract.
   System requirements may be defined
    or illustrated using system models.

                                        135
Problems with Natural Language

       Lack of clarity
         Precision is difficult without making
          the document difficult to read.
       Requirements confusion
         Functional and non-functional
          requirements tend to be mixed-up.
       Requirements amalgamation
         Several different requirements may be
          expressed together.

                                                  136
Requirements Documents
   The requirements document is the
    official statement of what is required
    of the system developers.
   Should include both a definition of
    user requirements and a specification
    of the system requirements.
   It is NOT a design document. As far
    as possible, it should set of WHAT the
    system should do rather than HOW it
    should do it
                                         137
Problems of Requirements Analysis

   Stakeholders don‘t know what they really
    want.
   Stakeholders express requirements in their
    own terms.
   Different stakeholders may have conflicting
    requirements.
   Organisational and political factors may
    influence the system requirements.
   The requirements change during the
    analysis process. New stakeholders may
    emerge and the business environment
    change.

                                              138
Requirements Imprecision
       Problems arise when requirements are
        not precisely stated.
       Ambiguous requirements may be
        interpreted in different ways by
        developers and users.
       Consider the term ‗appropriate viewers‘
         User intention - special purpose viewer
          for each different document type;
         Developer interpretation - Provide a text
          viewer that shows the contents of the
          document.
                                                  139
Requirements and Design
  In principle, requirements should state what
   the system should do and the design should
   describe how it does this.
  In practice, requirements and design are
   inseparable
   A system architecture may be designed
      to structure the requirements;
   The system may inter-operate with other
      systems that generate design
      requirements;
   The use of a specific design may be a
      domain requirement.

                                             140
Requirements Engineering

   The process of establishing the
    services that the customer requires
    from a system and the constraints
    under which it operates and is
    developed.
   The requirements themselves are the
    descriptions of the system services
    and constraints that are generated
    during the requirements engineering
    process.
                                      141
Requirements Engineering
  Inception—ask a set of questions that establish
   basic understanding of the problem
   the people who want a solution
   the nature of the solution that is desired, and
   the effectiveness of preliminary
      communication and collaboration between
      the customer and the developer
  Elicitation—elicit requirements from all
   stakeholders
  Elaboration—create an analysis model that
   identifies data, function and behavioral
   requirements
  Negotiation—agree on a deliverable system that
   is realistic for developers and customers
                                               142
Requirements Engineering (cont’d)

    Specification—can be any one (or more)
     of the following:
     A written document
     A set of models
     A formal mathematical specification
     A collection of user scenarios (use-
        cases)
     A prototype



                                         143
Requirements Engineering (cont’d)

       Validation—a review mechanism
        that looks for
        errors in content or interpretation
        areas where clarification may be required
        missing information
        inconsistencies (a major problem when
         large products or systems are engineered)
        conflicting or unrealistic (unachievable)
         requirements.
       Requirements management

                                               144
    Inception
       Identify stakeholders
         ―who else do you think I should talk to?‖
       Recognize multiple points of view
       Work toward collaboration
       The first questions
         Who is behind the request for this work?
         Who will use the solution?
         What will be the economic benefit of a
          successful solution
         Is there another source for the solution
          that you need?
                                                  145
Eliciting Requirements
       meetings are conducted and attended by both software
        engineers and customers
       rules for preparation and participation are established
       an agenda is suggested
       a "facilitator" (can be a customer, a developer, or an
        outsider) controls the meeting
       a "definition mechanism" (can be work sheets, flip
        charts, or wall stickers or an electronic bulletin board,
        chat room or virtual forum) is used
       the goal is
          to identify the problem
          propose elements of the solution
          negotiate different approaches, and
           specify a preliminary set of solution requirements
                                                                 146
Requirements Elicitation & Analysis

    Interviewing
    Scenarios
    Use Cases
    Observation




                                147
Interviewing
       In formal or informal interviewing,
        the RE team puts questions to
        stakeholders about the system that
        they use and the system to be
        developed.
       There are two types of interview
         Closed interviews where a pre-defined
          set of questions are answered.
         Open interviews where there is no
          pre-defined agenda and a range of
          issues are explored with stakeholders.
                                              148
 Scenarios
 Scenarios are real-life examples of how a
  system can be used.
 They should include
  A description of the starting situation;
  A description of the normal flow of
    events;
  A description of what can go wrong;
  Information about other concurrent
    activities;
  A description of the state when the
    scenario finishes.                      149
Use Cases
   Use-cases are a scenario based
    technique in the UML which identify
    the actors in an interaction and which
    describe the interaction itself.
   A set of use cases should describe all
    possible interactions with the system.
   Sequence diagrams may be used to
    add detail to use-cases by showing
    the sequence of event processing in
    the system.
                                         150
Observation
 •   Analyze copies of input/output forms.
 •   Study existing system documentation.
 •   Observe the current procedures.




                                         151
 Observation (cont’d)
Analyze copies of input/output forms.
1. Obtain copies of all input forms – both filled in
   and blank.
2. Obtain copies of output reports.
3. Analyze the forms.
   1)   Where the form/report originate
   2)   How often it is produced
   3)   How many copies are generated
   4)   Who receives those copies
4. Organize the forms/reports so that they are easy
   to reference through out the project.

                                                       152
Observation (cont’d)
 Study existing system documentation.
 1.   Look at the deliverables from the last
      analysis.
 2.   Look at the design that was performed on
      the system.
      1)   Manuals
      2)   Specification of procedures
      3)   Programs
      4)   Data
      5)   Interfaces
      6)   All phase of user ducumentation
      7)   Help files

                                                 153
Observation (cont’d)

Observe the current procedures.
1.     Obtain permission both from the person to be observed and the
       person‘s supervisor.
2.     Plan the observation.
3.     Explain the purpose to the people we are observing. - NOT an
       evaluation
4.     Solicit for their opinions, both good and bad of the current
       procedures.
5.     Do not interrupt or disturb the activities in progress.
      1) They may be nervous or self-conscious.
      2) They may do more consciously or may do more carelessly.
※    Shows how the system really operates.
※ Can understand procedures more quickly and thoroughly by observing
      than we could by having someone explain them to us.


                                                                154
Elaboration –
    Building the Analysis Model

       Elements of the analysis model
            Scenario-based elements
              Functional—processing narratives for
               software functions
              Use-case—descriptions of the interaction
               between an ―actor‖ and the system
            Class-based elements
              Implied by scenarios
            Behavioral elements
              State diagram
            Flow-oriented elements
              Data flow diagram                      155
      Analysis Modeling

              Data Modeling
Functional Modeling and Information Flow
          Behavioral Modeling
Structured Models - Structured Analysis
             Context Models
              Object Models



                                      156
Data Modeling

 Data Dictionaries
 Data Structure Diagrams




                            157
Data Dictionaries




                    158
 Data Dictionary Symbols
Symbol           Meaning
         =       Is equivalent to
         +       And

      OPTION1
      OPTION2     Only one of the options is used at a given
         •       time.
         •
         •
                  Iteration of the component :
max
                    min = lowest possible number of iterations
min{COMPONENT}
                    max = highest possible number of
                 iterations
  (COMPONENT)    Component is an optional one.
      *comment   Item is a comment.                        159
 Data Dictionary Symbols (cont’d)

Name of a data entry:
   usually in uppercase
      Match the way they appear on the Data Flow Diagram
       (DFD), Process Description, and Design documents. (ex)
       ADDRESS
   Hyphens(-) separate the individual words within each name.
    (ex) STUDENT-NAME
      Or, InvoiceAmount = ItemPrice + ShippingCharges
   Name data entry names as descriptive as possible:
      So that readers are able to recognize the meaning of the
       data entry.
   Data entry names should be in a singular form, except the
    names of data stores (files).
      Data store names are always plural.
      Because a data store consists of records.
                                                         160
Data Dictionary Symbols (cont’d)

        =
            is equivalent to, breaks down into
            LHS consists of the concatenation of
             RHSs.
            INVOICE-AMOUNT
             = ITEM-PRICE + SHIPPING-CHARGES
            INVOICE-AMOUNT is broken down
             into ITEM-PRICE followed by
             SHIPPING-CHARGES

                                                161
Data Dictionary Symbols (cont’d)

       +
           and, concatenation, chaining together
           INVOICE-AMOUNT
            = ITEM-PRICE + SHIPPING-CHARGES
            =* INVOICE-AMOUNT is equivalent to
                  the concatenation of
                  ITEM-PRICE and SHIPPING-
            CHARGES.
            =* does NOT mean 25 = 20 + 520 5
            =* instead, INVOICE-AMOUNT =

                                                 162
Data Dictionary Symbols (cont’d)

       [] (square brackets)
         Denote a choice between two or more
          options.
         The choices are mutually exclusive.
         Must choose one, and only one option.
         VENDOR-FILE-UPDATE-TRANSACTION
            = ADD-NEW-VENDOR-TRANSACTION
              DELETE-VENDOR-TRANSACTION
              CHANGE-VENDOR-TRANSACTION
         Option for a typing convenience:
          [option1 | option2 | … | optionn]       163
Data Dictionary Symbols (cont’d)

Max                                           Max
                          or
Min                                           Min
       (braces)
            Represents iterations or repetitions of
             a component or a group of
             components.
            Max: maximum number of iterations
            Min : minimum number of iterations
            Option for a typing convenience:
              Min { Component } Max

                                                       164
Data Dictionary Symbols (cont’d)

{} (cont‘d)
(ex)
VENDOR-INVOICE
= INVOICE-NUMBER + VENDOR-NAME +
  INVOICE-AMOUNT + INVOICE-DUE-DATE +
20
     INVOICE-ITEM-DETAIL-LINE
1

               ∞
           =
               0

                                        165
 Data Dictionary Symbols (cont’d)

( … ): exactly one or none

VENDOR-INVOICE
= INVOICE-NUMBER + VENDOR-NAME +
  INVOICE-AMOUNT + INVOICE-DUE-DATE +
  (SHIPPING-DATE) +
20

     INVOICE-ITEM-DETAIL-LINE
1




=* SHIPPING-DATE may be omitted
                                        166
Data Dictionary Symbols (cont’d)

=*: a line of comment

VENDOR-INVOICE
= INVOICE-NUMBER + VENDOR-NAME +
  INVOICE-AMOUNT + INVOICE-DUE-DATE +
  (SHIPPING-DATE) +
20

     INVOICE-ITEM-DETAIL-LINE
 1

= *at least two copies received of each invoice
                                                  167
Data Dictionary Symbols (cont’d)

VENDOR-INVOICE = INVOICE-NUMBER + VENDOR-NAME +
     INVOICE-AMOUNT
              + INVOICE-DUE-DATE + 1 { INVOICE-ITEM-
     DETAIL-LINE } 20

                                      Invoice                                 page 1



            Invoice Number :
            Vendor Name          :
            Invoice Amount : $
            Invoice Due Date : 2007. .           .

              Item Price   Item Total Amount    Item    Item Description    Item
                                               Number                      Quantity




 20 lines

                                                                                       168
Data Structure Diagrams




                      169
Creating Data Structure Diagrams

       Step 1. Identify entity sets.
          In the Data Dictionary and on the DFDs
       Step 2. Identify or create key attributes for
        each of the entities.
       Step 3. Assign the nonkey attributes to the data
        stores to which they seem to apply.
       Step 4. Create logical pointers to show the directions
        of data access in the database, and assign cardinality
        symbols to those logical pointers.
       Step 5. Put the database in First Normal
        Form :
          Each entity should have only single-valued, or
           nonrepeating, attributes.

                                                            170
Creating Data Structure
Diagrams (cont’d)
       Step 6. Put the database in Second Normal
        Form :
        Each nonkey attribute in an entity set with a
         concatenated key must depend upon the entire
         concatenated key, not just a part of it.
     Step 7. Put the database in Third Normal Form :
        The values of all nonkey attributes are
         independent of all other nonkey attributes.
     Step 8. Remove any foreign keys that are not a
      part of the concatenated key of the entity.
     Step 9. Go back and revise your Data Dictionary and
      DFDs to reflect this newer, more logical structure of
      the database.


                                                         171
Data Structure Diagram
                                   COURSES                  Entity Set
                                                     (or Object, Entity Type)
               Key             DEPARTMENT
           (underlined)        COURSE-NUMBER
                               CREDIT-HOURS

                                             1



                                             M
   INSTRUCTORS        1   M     CLASS-SECTIONS   M       N           STUDENTS

SOCIAL-SECURITY-              DEPARTMENT
                                                             SOCIAL-SECURITY-
NUMBER                        COURSE-NUMBER
                                                             NUMBER
NAME                          SECTION-NUMBER
                                                             NAME
ADDRESS                       CLASSROOM-NUMBER
                                                             ADDRESS
OFFICE-NUMBER                 DAYS-TAUGHT
                                                             GRADE-IN-COLLEGE
                              TIME-TAUGHT
                                                             GRADE-POINT-AVERAGE




Data Structure Diagram for Class Enrollments                                    172
Creating a Data Structure Diagram

PURCHASE-ORDERS                M                                    1   VENDORS

                                                                        VENDOR-NUMBER
PURCHASE-ORDER-NUMBER
                                                                        VENDOR-NAME
VENDOR-NUMBER
                                                                        VENDOR-ADDRESS
INVOICE-NUMBER
PAYMENT-CHECK-NUMBER
  INVENTORY-ITEM-NUMBER
  INVENTORY-ITEM-DESCRIPTION
  ORDERED-ITEM-QUANTITY
  ORDERED-ITEM-PRICE
  ORDERED-ITEM-TOTAL-AMOUNT
PACKING-SLIP-NUMBER
                               1                                    1
  INVENTORY-ITEM-NUMBER
  RECEIVED-ITEM-QUANTITY
                                   1                            M

                                       PENDING-INVOICES

                                       PENDING-INVOICE-NUMBER
                                       PURCHASE-ORDER-NUMBER
                                       INVOICE-TOTAL-AMOUNT
                                       VENDOR-NUMBER
                                       INVOICE-DUE-DATE
                                       INVOICE-DISCOUNT-CODE



 Data Structure Diagram for Accounts Payable                                             173
  Creating a Data Structure Diagram

                                              PACKING-SLIP-ITEM-DETAILS

   PURCHASE-ORDERS-ITEM-DETAILS               PACKING-SLIP-NUMBER
                                              INVENTORY-ITEM-NUMBER
   PURCHASE-ORDER-NUMBER
                                              RECEIVED-ITEM-QUANTITY
   INVENTORY-ITEM-NUMBER
   INVENTORY-ITEM-DESCRIPTION                               M
   ORDERED-ITEM-QUANTITY                                    1
   ORDERED-ITEM-PRICE
                                              PACKING-SLIP-DETAILS
   ORDERED-ITEM-TOTAL-AMOUNT
                                         M
                      M
                      1                       PACKING-SLIP-NUMBER
    PURCHASE-ORDERS               1

   PURCHASE-ORDER-NUMBER
                                              VENDORS
   VENDOR-NUMBER
                                  M      1
   INVOICE-NUMBER
                                              VENDOR-NUMBER
   PAYMENT-CHECK-NUMBER
                                              VENDOR-NAME
                      1                       VENDOR-ADDRESS
                      1
   PENDING-INVOICES                      1

   PENDING-INVOICE-NUMBER
                                  M
   PURCHASE-ORDER-NUMBER
   INVOICE-TOTAL-AMOUNT
   VENDOR-NUMBER
   INVOICE-DUE-DATE
   INVOICE-DISCOUNT-CODE
                                                                       174
Data Structure Diagram for Accounts Payable   (1st   normal form)
    Creating a Data Structure Diagram

           INVENTORY-ITEMS                        PACKING-SLIP-ITEM-DETAILS
                                          1   M
           INVENTORY-ITEM-NUMBER                  PACKING-SLIP-NUMBER
           INVENTORY-ITEM-DESCRIPTION             INVENTORY-ITEM-NUMBER
                             1                    RECEIVED-ITEM-QUANTITY
                            M
                                                                 M
           PURCHASE-ORDERS-ITEM-DETAILS                          1
           PURCHASE-ORDER-NUMBER                  PACKING-SLIP-DETAILS
           INVENTORY-ITEM-NUMBER              M
           ORDERED-ITEM-QUANTITY
           ORDERED-ITEM-PRICE                     PACKING-SLIP-NUMBER
           ORDERED-ITEM-TOTAL-AMOUNT
                            M
                            1             1
           PURCHASE-ORDERS                        VENDORS
           PURCHASE-ORDER-NUMBER
                                          M   1   VENDOR-NUMBER
           VENDOR-NUMBER
                                                  VENDOR-NAME
           INVOICE-NUMBER
                                                  VENDOR-ADDRESS
           PAYMENT-CHECK-NUMBER
                            1
                            1                 1
           PENDING-INVOICES
           PENDING-INVOICE-NUMBER
           PURCHASE-ORDER-NUMBER          M
           INVOICE-TOTAL-AMOUNT
           VENDOR-NUMBER
           INVOICE-DUE-DATE
           INVOICE-DISCOUNT-CODE


Data Structure Diagram for Accounts Payable (2nd normal form) 175
    Creating a Data Structure Diagram

       INVENTORY-ITEMS                                 PACKING-SLIP-ITEM-DETAILS
       INVENTORY-ITEM-NUMBER           1           M
                                                       PACKING-SLIP-NUMBER
       INVENTORY-ITEM-DESCRIPTION                      INVENTORY-ITEM-NUMBER
                         1                             RECEIVED-ITEM-QUANTITY
                         M
                                                                      M
        PURCHASE-ORDERS-ITEM-DETAILS                                  1
       PURCHASE-ORDER-NUMBER                           PACKING-SLIP-DETAILS
       INVENTORY-ITEM-NUMBER                       M
       ORDERED-ITEM-QUANTITY
       ORDERED-ITEM-PRICE                              PACKING-SLIP-NUMBER
                         M
                          1            1
       PURCHASE-ORDERS
                                                       VENDORS
       PURCHASE-ORDER-NUMBER
       VENDOR-NUMBER
                                       M           1   VENDOR-NUMBER
       INVOICE-NUMBER
                                                       VENDOR-NAME
       PAYMENT-CHECK-NUMBER
                                                       VENDOR-ADDRESS
                        1
                        1
       PENDING-INVOICES                            1

       PENDING-INVOICE-NUMBER
       PURCHASE-ORDER-NUMBER
       INVOICE-TOTAL-AMOUNT            M   Foreign Keys
       VENDOR-NUMBER
       INVOICE-DUE-DATE
       INVOICE-DISCOUNT-CODE



Data Structure Diagram for Accounts Payable (3rd normal form) 176
  Creating a Data Structure Diagram

       INVENTORY-ITEMS                        PACKING-SLIP-ITEM-DETAILS
       INVENTORY-ITEM-NUMBER          1   M
                                              PACKING-SLIP-NUMBER
       INVENTORY-ITEM-DESCRIPTION             INVENTORY-ITEM-NUMBER
                        1                     RECEIVED-ITEM-QUANTITY
                        M
                                                             M
       PURCHASE-ORDERS-ITEM-DETAILS                          1
       PURCHASE-ORDER-NUMBER                  PACKING-SLIP-DETAILS
       INVENTORY-ITEM-NUMBER
                                          M
       ORDERED-ITEM-QUANTITY
       ORDERED-ITEM-PRICE                     PACKING-SLIP-NUMBER
                        M
                        1             1
        PURCHASE-ORDERS
                                              VENDORS
       PURCHASE-ORDER-NUMBER          M   1
       PAYMENT-CHECK-NUMBER                   VENDOR-NUMBER
       INVOICE-NUMBER                         VENDOR-NAME
                       1                      VENDOR-ADDRESS
                       1
                                          1
        PENDING-INVOICES

       PENDING-INVOICE-NUMBER
       INVOICE-TOTAL-AMOUNT           M
       INVOICE-DUE-DATE
       INVOICE-DISCOUNT-CODE




                                                                          177
Data Structure Diagram for Accounts Payable ( Final Form)
Entity-Relationship Diagram
   Diagrams on the next slide are Entity-
    Relationship Diagram (ERD) that corresponds to
    the Data Structure Diagram.
   The rectangles represent entities and entity-
    sets.
   The diamonds represent relationships, which
    are associations between entities.
   A relationship corresponds to logical pointers
    on the Data Structure Diagram but, in contrast
    to a logical pointer, doesn‘t attempt to show
    direction of data access.
   A relationship can be explicitly named with a
    verb.
   Two entities and a connecting relationship can
    be interpreted as a sentence.                  178
The Entity-Relationship
Diagram (cont`d)
                    1                   M       PACKING-SLIP-
 INVENTORY-ITEMS            receives
                                                 ITEM-DETAILS
           1                                           M

      orders                                       itemizes
          M
                                                        1
 PURCHASE-ORDER
   ITEM-DETAILS                                 PACKING-SLIP-
                                                   DETAILS
          M
                                            M
                            includes
     itemizes

           1            1
                        M   purchases       1
 PURCHASE-ORDERS                                    VENDORS
                              from
           1
                                            1
       bills
       for                   owed to
           1        M

 PENDING-INVOICES

                                                                179
Entity-Relationship Diagram for Accounts Payable
Functional Modeling
   and Information Flow:

Data Flow Diagrams (DFDs)


                            180
Elements of the DFD
     DFD Symbols

         NAME              SYMBOL        ALTERNATE FORMS

    Terminator symbol
                          TERMINATOR-      TERMINATOR-
                             NAME             NAME

    Data store symbol        FILE-         File         File
                             NAME         Name
                                                  or   Name

     Process symbol
                        PROCESS-NAME      PROCESS-NAME

    Data flow symbol
                        DATA-FLOW-NAME



                                                               181
Elements of the DFD (cont’d)

       The Terminator Symbol : or External
        Entity
         TERMINATOR –
            NAME

         Represents a person or organization that
          is outside the boundaries of a system.
         Either supplies data to or receives data
          from the system.
         NOT a part of the system with which the
          DFD in concerned
         BUT simply communicate with the
          system
                                                 182
Elements of the DFD (cont’d)

       The Terminator Symbol: (cont‘d)
         Source : When a terminator is
          primarily an originator of data, feeding
          data into a system
         Sink : When a terminator is primarily
          a receiver of data
         A terminator may be both a source
          and a sink.



                                                183
Elements of the DFD (cont’d)


       The Data Store symbol :
          FILE-
          NAME



         A repository for data




                                  184
Elements of the DFD (cont’d)

       The Data Store symbol : (cont‘d)
         Data Stores are named by making the data
          record name plural.
        ex) STUDENT-RECORD : a record
           STUDENT-RECORDS : a file (data store)
          consists of STUDENT-RECORDs

                            PROCESS-
                            STUDENT-
                             RECORD
                   add,
                  change,              read
                   delete

        STUDENT-RECORD                 STUDENT-RECORD

                   STUDENT-RECORDS
                                                        185
Elements of the DFD (cont’d)

       The Process Symbol :

    PROCESS-
      NAME



         Work that must be alone, that is,
          some task or function that must be
          completed.
         the transformation of data.


                                               186
Elements of the DFD (cont’d)

    The Process Symbol : (cont‘d)
     Black Box : high level of abstraction
       Some task for which we know the
         inputs and outputs and the general
         function, without knowing any details
         about how the function is
         accomplished
       A Black Box behaves predictably :
         given a particular input, it always
         produces the some output.

                                             187
Elements of the DFD (cont’d)


        Black Box : (cont‘d)
          The concept of a Black Box is highly
           useful, since it allows us to follow what
           is happening generally without being
           overwhelmed by details.
        The name of a process tells its
         general function.
          The first word of a process name should
           be a precise, active verb.
          Verbs such as ―process‖ and ―update‖
           are too vague and should be avoided.
                                                       188
Elements of the DFD (cont’d)

       The Data Flow Symbol :
        DATA-ENTRY-IN


         A Data flow, defined in the Data
          Dictionary, moves between processes,
          data stores, and terminators.
         Data flows serve as communication
          channels between processes.



                                            189
Elements of the DFD (cont’d)

       The Data Flow Symbol : (cont‘d)
      While a Data Store represents data at rest,
       a Data Flow indicates data in motion.
     A Data Flow may consist of a data element,
       or a record.
     Use a separate arrow for each data element.
       If more then one data element has to be
          passed, use one arrow for each data
          element.


                                              190
Elements of the DFD (cont’d)

    The Data Flow Symbol : (cont‘d)
     Do not show any kind of reiteration on
       a DFD.
       Never use loops.
       Do not use GET-NEXT-CUSTOMER,
         instead, use GET-CUSTOMER.
     Do not show flags on a DFD.
     Do not show control on a DFD, only
       the movement of the data.

                                          191
Elements of the DFD (cont’d)

    The Data Flow Symbol : (cont‘d)
     All data flows must either begin or end
       at a process symbol.
       A data flow can NOT be used to
         connect two terminators, two data
         stores, or a terminator to a data
         store.




                                           192
Example: A Context DFD for
Accounts Payable

                                       CASH-
                                   REQUIREMENTS-
                                      REPORT
         INVOICE     PAY-
VENDOR                                                 MANAGEMENT
                   INVOICE

         PAYMENT                         PAYMENT-
                                       AUTHORIZATION

                           CASH-
                       REQUIREMENTS-
                          REPORT




                   ACCOUNTING




                                                             193
Overview Data Flow Diagram
                                 PURCHASE-
                                  ORDERS




                  1
   INVOICE   COMPARE-           VALID-                        4
              INVOICE-         INVOICE-                    RETIRE-
                WITH-          DETAILS                    PURCHASE-
             PURCHASE-                                     ORDERS
               ORDER                                                      CASH-
                                                                      REQUIREMENTS
                                      2                                 -REPORT
                                 DETERMINE-
                                  INVOICE-
                               AUTHORIZATION-       VENDOR-
             PENDING-
                                   STATUS            NAME
             INVOICES

                                                VENDORS
                                                                      PAYMENT-
                                                                       DETAILS

                          PAYMENT-
                        AUTHORIZATION
                                                   3
                                                PRODUCE-         PAYMENT
                                                PAYMENT



                               Convergence

   Example : An Overview DFD for Accounts Payable
                                                                                     194
     Lower-Level Data Flow Diagrams

     Diagram 1 for Accounts Payable
               PURCHASE-
                ORDERS


                                                                                                          PURCHASE-
                                                                                                           ORDERS



INVOICE              1.1
             MATCH-INVOICE-
             WITH-PURCHASE          PURCHASE-
                 ORDER               ORDER-                                  INVOICE        1
                                     RECORD                                             COMPARE-          VALID-
                                                                                                                                       4
                                                                                         INVOICE-        INVOICE-                   RETIRE-
                                                                  PENDING-
                                                                  INVOICES                 WITH-         DETAILS                   PURCHASE-
                                                                                        PURCHASE-                                   ORDERS
                       PACKING-                                                           ORDER                                                   CASH-
                      SLIP-DETAIL                                                                                                              REQUIREMENTS
                                                                                                               2                                 -REPORT
          INVOICE-                                                                                        DETERMINE-
           WITH-                                                                                           INVOICE-
          MATCH             INVOICE-WITH-                                                               AUTHORIZATION-       VENDOR-
                              CORRECT-        1.3       VALID-                         PENDING-
                     1.2       ITEM-                                 1.4                                    STATUS            NAME
             MATCH-INVOICE-             MATCH-INVOICE- INVOICE-                        INVOICES
                                                                  FORMAT-
             ITEM-QUANTITY- QUANTITY      ITEM-PRICE-   DETAILS
                                                                  PENDING-                                               VENDORS
              WITH-PACKING-            WITH-PURCHASE-             INVOICE-
                SLIP-ITEM-                ORDER-ITEM-                                                                                          PAYMENT-
                                                                  RECORD
                QUANTITY                     PRICE                                                                                              DETAILS

                                                                                                    PAYMENT-
                                                                                                  AUTHORIZATION
                                                                                                                            3
                                                                                                                         PRODUCE-          PAYMENT
                                                                                                                         PAYMENT




                                                                                                                                                     195
 Lower-Level Data Flow Diagrams

     Diagram 2 for Accounts Payable
                                     VENDORS                                                                        PURCHASE-
                                                                                                                    ORDERS


                                         VENDOR-
                                          NAME

 VALID-                  DETAILS-              FORMATTED-                                       1
                                                                                  INVOICE
INVOICE-                                          CASH-              CASH-                  COMPARE-             VALID-
                           OF-                                                                                                                 4
DETAILS                   LARGE-              REQUIREMENTS- 2.5   REQUIREMENTS-                                 INVOICE-
              2.1                       2.4                                                  INVOICE-                                        RETIRE-
                         INVOICE                 REPORT WRITE-CASH- REPORT                                      DETAILS
             CHECK-                 FORMAT-CASH-                                               WITH-                                        PURCHASE-
            INVOICE-                REQUIREMENTS        REQUIREMENTS                                                                         ORDERS
                                                                                            PURCHASE-
            AMOUNT                    -REPORT             -REPORT
                                                                                              ORDER                                                        CASH-
                                                                                                                                                        REQUIREMENTS
                              PAYMENT-AUTHORIZATION-FOR-SMALL-INVOICE                                                2                                    -REPORT
                                                                                                                 DETERMINE-
               DETAILS-OF-                                                                                        INVOICE-
                MEDIUM-                                                                                         AUTHORIZATION-       VENDOR-
                                                                                            PENDING-
                INVOICE                                                                     INVOICES
                                                                                                                   STATUS             NAME

                              PAYMENT-AUTHORIZATION-FOR-INVOICE-
               2.2            WITH-DISCOUNT
                                                                                                                                 VENDORS
           CHECK-EARLY-                                                                                                                                 PAYMENT-
            PAYMENT-                                                                                                                                     DETAILS
            DISCOUNT
                                                                                                          PAYMENT-
                                                                                                        AUTHORIZATION
                 DETAILS-OF-                                                                                                        3
                INVOICE-WITH-                                                                                                    PRODUCE-           PAYMENT
                NO-DISCOUNT                                                                                                      PAYMENT



                              PAYMENT-AUTHORIZATION-FOR-OLD-INVOICE
               2.3
             CHECK-
           INVOICE-AGE



                                                                                                                                                          196
   Lower-Level Data Flow Diagrams

   Diagram 3 for Accounts Payable
                                 PENDING-
                                 INVOICES                                             PURCHASE-
                                                                                       ORDERS



  PAYMENT-         3.1        PENDING-
                                                  3.2
AUTHORIZATION     EDIT-    INVOICE-RECORD
                                              DELETE-                  1
                PAYMENT-                                           COMPARE-           VALID-
                                              PENDING-   INVOICE                                                   4
                AUTHOR-                                             INVOICE-         INVOICE-                   RETIRE-
                                               INVOICE
                 IZATION                                              WITH-          DETAILS                   PURCHASE-
                                                                   PURCHASE-                                    ORDERS
   INVALID-
  PAYMENT-                                                           ORDER                                                    CASH-
                       PENDING-                                                                                            REQUIREMENTS
AUTHORIZATION
                    INVOICE-RECORD                                                                                           -REPORT
                                                                                           2
                                                                                      DETERMINE-
                                                                                       INVOICE-
                                                                                    AUTHORIZATION-       VENDOR-
                                                                   PENDING-
                   3.3                                                                  STATUS            NAME
                                                                   INVOICES
                FORMAT-             PAYMENT-DETAILS
                PAYMENT                                                                              VENDORS
                                                                                                                           PAYMENT-
                                                                                                                            DETAILS

                    FORMATTED-                                                  PAYMENT-
                     PAYMENT                                                  AUTHORIZATION
 VENDORS                                                                                                3
                                                                                                     PRODUCE-         PAYMENT
                                                                                                     PAYMENT

                   3.4
                                       PAYMENT
                 WRITE-
                PAYMENT                                                                                                    197
Behavioral Modeling
   Data Flow Model
   State Machine Model


                         198
Behavioural Models
 Behavioural models are used to describe
  the overall behaviour of a system.
 Two types of behavioural model are:
  Data processing models that show
    how data is processed as it moves
    through the system;
  State machine models that show the
    systems response to events.
 These models show different
  perspectives so both of them are
  required to describe the system‘s
  behaviour.
                                        199
Data Flow Model
   Refer to Functional Modeling and
    Information Flow: DFD




                                       200
State Machine Model
   These model the behaviour of the system in
    response to external and internal events.
   They show the system‘s responses to stimuli
    so are often used for modelling real-time
    systems.
   State machine models show system states
    as nodes and events as arcs between these
    nodes. When an event occurs, the system
    moves from one state to another.
   Statecharts are an integral part of the UML
    and are used to represent state machine
    models.
                                             201
State Machine Model Example:
   Microwave Oven Model




                           202
Structural
Modeling


  Structured Analysis



                        203
Structured Methods
   Structured methods incorporate
    system modelling as an inherent part
    of the method.
   Methods define a set of models, a
    process for deriving these models and
    rules and guidelines that should apply
    to the models.
   CASE tools support system modelling
    as part of a structured method.

                                        204
Method Weaknesses
   They do not model non-functional
    system requirements.
   They do not usually include
    information about whether a method
    is appropriate for a given problem.
   The may produce too much
    documentation.
   The system models are sometimes
    too detailed and difficult for users to
    understand.
                                              205
 Structured Method Example
              1                             2                         3
  INPUT-A
             GET-         VALID-INPUT   COMPUTE-       SOLUTION    PRODUCE-    REPORT
  INPUT-B    VALID-                     SOLUTION                    REPORT
             INPUT



DFDs are transformed into Structure Charts.
   They must be revised later.

                                          APPLY
                                          INPUT




                          VALID-INPUT                   SOLUTION



             GET                        COMPUTE                      PRODUCE
            VALID                       SOLUTION                      REPORT            206
            INPUT     1                            2                            3
Context Models




                 207
Context Models
   Context models are used to illustrate
    the operational context of a system -
    they show what lies outside the
    system boundaries.
   Social and organisational concerns
    may affect the decision on where to
    position system boundaries.
   Architectural models show the system
    and its relationship with other
    systems.
                                       208
The Context of an ATM System


                    Security
                     s ys tem

     Branch
                                  Acco un t
   accoun tin g
                                  da tabas e
     s ys tem

                   Auto -teller
                    s ys tem

     Branch
                                   Us age
     coun ter
                                  datab as e
     s ys tem

                  Main tenance
                    s ys tem


                                               209
   Object Models

    Inheritance models
Object models and the UML
      Class hierarchy
    Object aggregation
Object behaviour modelling


                             210
Object Models
       Object models describe the system in terms
        of object classes and their associations.
       An object class is an abstraction over a set
        of objects with common attributes and the
        services (operations) provided by each
        object.
       Various object models may be produced
         Inheritance models;
         Aggregation models;
         Interaction models.


                                                   211
Object Models (cont’d)
   Natural ways of reflecting the real-
    world entities manipulated by the
    system
   More abstract entities are more
    difficult to model using this approach
   Object class identification is
    recognised as a difficult process
    requiring a deep understanding of the
    application domain
   Object classes reflecting domain
    entities are reusable across systems
                                         212
Inheritance Models
   Organise the domain object classes into a
    hierarchy.
   Classes at the top of the hierarchy reflect
    the common features of all classes.
   Object classes inherit their attributes and
    services from one or more super-classes.
    these may then be specialised as necessary.
   Class hierarchy design can be a difficult
    process if duplication in different branches is
    to be avoided.


                                                 213
    Object Models and the UML
   The UML is a standard representation devised by
    the developers of widely used object-oriented
    analysis and design methods.
   It has become an effective standard for object-
    oriented modelling.
   Notation
      Object classes are rectangles with the name at
       the top, attributes in the middle section and
       operations in the bottom section;
      Relationships between object classes (known
       as associations) are shown as lines linking
       objects;
      Inheritance is referred to as generalisation and
       is shown ‗upwards‘ rather than ‗downwards‘ in a
       hierarchy.                                     214
Library Class Hierarchy
                                                     ary
                                                  Libr item

                                          Catalogu e n umber
                                          Acqu is ition d ate
                                          Co st
                                          yp
                                          T e
                                          Status
                                          Nu mber o f co pies
                                                      e
                                              Acqu ir ()
                                              Catalogu e ()
                                              Disp os e ()
                                              Iss ue ()
                                              Retu rn ()




                   Pu blis hed item                                     Reco rded item
                 Title                                                 Title
                 Pu blis her                                           Medium




         Bo ok                    Magazin e                     Film                 Co mpu ter
                                                                                      pro gram
   A or
     uth                       Year                      Director
   Ed ition                                              Date of releas e         ers
                                                                                 V io n
                               Iss ue
   Pu blicatio n da te                                   Distributo r                 or
                                                                                 Platf m
   ISBN


                                                                                                  215
User Class Hierarchy

                         ary
                      Libr u ser

                   Name
                   Address
                   Ph on e
                   Reg istratio n #

                   Reg ister ()
                   De-reg ister ()




         Read er                                    Bo rrower
   Af
    filiatio n                                Items o n loan
                                              Max. lo an s




                                      Staff                       Stu den t
                             Depar tment                   Majo r s ub ject
                             Depar tment p ho ne           Ho me ad dress



                                                                              216
Object Aggregation
   An aggregation model shows how
    classes that are collections are
    composed of other classes.
   Aggregation models are similar to the
    part-of relationship in semantic data
    models.




                                        217
Object Aggregation




                     218
Object Behaviour Modelling

   A behavioural model shows the
    interactions between objects to
    produce some particular system
    behaviour that is specified as a use-
    case.
   Sequence diagrams (or collaboration
    diagrams) in the UML are used to
    model interaction between objects.


                                            219
Issue of electronic items




                            220
Negotiating Requirements

       Identify the key stakeholders
         These are the people who will be
          involved in the negotiation
       Determine each of the stakeholders
        ―win conditions‖
         Win conditions are not always obvious
       Negotiate
         Work toward a set of requirements
          that lead to ―win-win‖

                                              221
Requirements Specification Documents


    Natural Language Specification – Example
    Problems with NL specification
    Structured language specifications
    Structured language specifications –
     Example I
    Structured language specifications –
     Example II
    Decision Trees
    Decision Tables
    Requirements completeness and
     consistency
                                                222
Natural Language Specification -
Example
First, if the amount of the invoice is over $1,000, it can’t be paid until I
receive authorization, so the invoice appears on the cash requirements report.
If the amount is less than $100, I always authorize payment immediately,
since it is costly for us to delay payment, only to process the invoice again in
a few days. If the invoice amount is between $100 and $1,000, inclusive, I
always authorize payment unless it is 10 days old or less and there is no early
payment discount. For the latter cases, I don’t authorize payment yet, since it
would tie up capital without giving a return. Those invoices are set aside until
the next time I check for authorization.


                                                                               223
Problems with NL Specification

       Ambiguity
         The readers and writers of the requirement
          must interpret the same words in the same
          way. NL is naturally ambiguous so this is very
          difficult.
       Over-flexibility
         The same thing may be said in a number of
          different ways in the specification.
       Lack of modularisation
         NL structures are inadequate to structure
          system requirements.

                                                      224
Structured Language Specifications

    The freedom of the requirements
     writer is limited by a predefined
     template for requirements.
    All requirements are written in a
     standard way.
    The terminology used in the
     description may be limited.
    The advantage is that the most of the
     expressiveness of natural language is
     maintained but a degree of uniformity
     is imposed on the specification.
                                        225
Structured Language
Specifications – Example I
First Version
For each VENDOR-INVOICE:
          Case:TOTAL-INVOICE-AMOUNT is less than $100
                  Create PAYMENT-AUTHORIZATION
          Case:TOTAL-INVOICE-AMOUNT is from $100 to 1,000, inclusive
           If INVOICE-AGE is 10 days or less and no early discount
                  Set VENDOR-INVOICE aside
           Else
                  Create PAYMENT-AUTHORIZATION
          Case:TOTAL-INVOICE-AMOUNT is greater than $1,000
            Put VENDOR-INVOICE on CASH-REQUIREMENTS-REPORT
End_For
                                                                       226
 Structured Language
 Specifications – Example II
Secnod Version
For each VENDOR-INVOICE:
          If INVOICE-AGE is 10 days or less
             If no early discount
                If TOTAL-INVOICE-AMOUNT is from $100 to $1,000, inclusive
                      Set VENDOR-INVOICE aside
                Else
                      If TOTAL-INVOICE-AMOUNT is less than $100
                         Create PAYMENT-AUTHORIZATION
                      Else
                         Put VENDOR-INVOICE on CASH-REQUIREMENTS-REPORT
             Else
                 If TOTAL-INVOICE-AMOUNT is less than or equal to $1,000
                      Create PAYMENT-AUTHORIZATION
                 Else
                      Put VENDOR-INVOICE on CASH-REQUIREMENTS-REPORT
           Else
                 If TOTAL-INVOICE-AMOUNT is less than or equal to $1,000
                      Create PAYMENT-AUTHORIZATION
                 Else
                      Put VENDOR-INVOICE on CASH-REQUIREMENT-REPORT         227

End_For
DECISION TREES


  INVOICE AMOUNT            INVOICE AGE          PAYMENT DISCOUNT           ACTION
   less than $100                                                      authorize payment

                                                 payment discount      authorize payment
                         less than or equal
                             to 10 days


                                                 no payment discount   set invoice aside
 $100 to $1,000,
    inclusive




                          greater than 10 days                         authorize payment


                                                                           put on Cash
   greater than $1,000                                                 Requirements Report
                                                                                           228
Complete Decision Tree for Determining Payment Authorization
    DECISION TABLES


                    1        2       3        4          5      6        7       8        9       10       11       12
   Invoice        <100     <100    <100     <100    100-      100-     100-    100-    >1,000    >1,000   >1,000   >1,000
                                                    1,000     1,000    1,000   1,000
   Amount

   Invoice        10 or    10 or   >10      >10     10 or     10 or    >10     >10     10 or     10 or    >10      >10
                  less     less                     less      less                     less      less
   Age

   Payment
                     Y       N       Y        N          Y      N        Y       N        Y         N        Y        N
   Discount

   Authorize
                     X       X       X        X          X               X       X
   Payment

   Set Invoice
                                                                 X
   Aside

   Put Invoice
                                                                                          X         X        X        X
   On CRR


                 Key
                 <100 = less than $100                       10 or less = less than or equal to 10 days
                 100-1,000 = $100 to $1,000, inclusive       >10 = greater than 10 days
                 >1,000 = greater than $1,000                 Y = yes
                 CRR = cash requirements report              N = no



                                                                                                                     229
Limited Entry Format of Decision Table for Determining payment Authorization
DECISION TABLES (cont’d)

                1       2       3       4           5     6        7       8        9       10        11       12
              <100    <100    <100    <100     100-      100-    100-    100-    >1,000    >1,000    >1,000   >1,000
Invoice                                        1,000     1,000   1,000   1,000
 Amount

              10 or   10 or   >10     >10      10 or     10or    >10     >10     10 or     10 or     >10      >10
 Invoice
              less    less                     less      less                    less      less
  Age

Payment
                Y       N       Y        N          Y      N       Y       N        Y        N         Y        N
 Discount

 Action         A       A       A       A           A      S       A       A        P        P         P        P


            Key
            <100 = less than $100                       10 or less = less than or equal to 10 days
            100-1,000 = $100 to $1,000, inclusive       >10 = greater than 10 days
            >1,000 = greater than $1,000                 Y = yes
            CRR = cash requirements report              N = no




             Extended Entry Format of Decision Table                                                          230
  DECISION TABLES                                      (cont’d)
                     1-4                 5                  6                  7-8                  9-12
   Invoice                             100-                100-               100-
                     <100                                                                           >1,000
    Amount                             1,000               1,000              1,000

    Invoice                            10 or               10 or
                      -                                                        >10                    -
     Age                               less                less

   Payment
                      -                  Y                   N                   -                    -
    Discount

    Action            A                  A                   S                  A                     P




               Key
                    <100 = less than $100              10 or less = less than or equal to 10 days
               100-1,000 = $100 to $1,000, inclusive         >10 = greater than 10 days
                  >1,000 = greater than $1,000                  Y = yes
                       A = Authorize payment                   N = no
                       S = set invoice aside
                       P = put invoices on cash
                           requirements report




                                                                                                             231
Fully Condensed Decision Table for Determining Payment Authorization
Requirements Completeness and
Consistency
  In principle, requirements should be both
   complete and consistent.
  Complete
   They should include descriptions of all
      facilities required.
  Consistent
   There should be no conflicts or
      contradictions in the descriptions of the
      system facilities.
  In practice, it is impossible to produce a
   complete and consistent requirements
   document.
                                                  232
Requirements Validation
       Concerned with demonstrating that
        the requirements define the system
        that the customer really wants.
       Requirements error costs are high so
        validation is very important
         Fixing a requirements error after
          delivery may cost up to 100 times the
          cost of fixing an implementation error.



                                               233
    Validating Requirements

    Is each requirement consistent with the overall
     objective for the system/product?
    Have all requirements been specified at the proper
     level of abstraction? That is, do some requirements
     provide a level of technical detail that is
     inappropriate at this stage?
    Is the requirement really necessary or does it
     represent an add-on feature that may not be
     essential to the objective of the system?
    Is each requirement bounded and unambiguous?
    Does each requirement have attribution? That is, is
     a source (generally, a specific individual) noted for
     each requirement?
    Do any requirements conflict with other
     requirements?
                                                       234
Validating Requirements (cont’d)

    Is each requirement achievable in the technical
     environment that will house the system or product?
    Is each requirement testable, once implemented?
    Does the requirements model properly reflect the
     information, function and behavior of the system to
     be built.
    Has the requirements model been ―partitioned‖ in a
     way that exposes progressively more detailed
     information about the system.
    Have requirements patterns been used to simplify
     the requirements model. Have all patterns been
     properly validated? Are all patterns consistent with
     customer requirements?



                                                        235
Validating Requirements
   Requirements checking
   Requirements validation techniques
   Requirements reviews
   Review checks




                                         236
Requirements Checking
   Validity. Does the system provide the
    functions which best support the customer‘s
    needs?
   Consistency. Are there any requirements
    conflicts?
   Completeness. Are all functions required by
    the customer included?
   Realism. Can the requirements be
    implemented given available budget and
    technology
   Verifiability. Can the requirements be
    checked?

                                             237
Requirements Validation Techniques


        Requirements reviews
          Systematic manual analysis of the
           requirements.
        Prototyping
          Using an executable model of the
           system to check requirements. Test-
           case generation
          Developing tests for requirements to
           check testability.

                                                  238
Requirements Reviews
   Regular reviews should be held while
    the requirements definition is being
    formulated.
   Both client and contractor staff should
    be involved in reviews.
   Reviews may be formal (with
    completed documents) or informal.
    Good communications between
    developers, customers and users can
    resolve problems at an early stage.
                                         239
Review Checks
       Verifiability
          Is the requirement realistically testable?
       Comprehensibility
          Is the requirement properly understood?
       Traceability
          Is the origin of the requirement clearly stated?
       Adaptability
          Can the requirement be changed without a
           large impact on other requirements?



                                                        240
Requirements Management
       Requirements management is the process
        of managing changing requirements during
        the requirements engineering process and
        system development.
       Requirements are inevitably incomplete and
        inconsistent
         New requirements emerge during the process
          as business needs change and a better
          understanding of the system is developed;
         Different viewpoints have different
          requirements and these are often
          contradictory.
                                                  241
Requirements Management (cont’d)

   Requirements change
   Requirements management planning
   Requirements change management




                                       242
Requirements Change
   The priority of requirements from
    different viewpoints changes during
    the development process.
   System customers may specify
    requirements from a business
    perspective that conflict with end-
    user requirements.
   The business and technical
    environment of the system changes
    during its development.
                                          243
Requirements Management Planning

       During the requirements engineering process,
        you have to plan:
       Requirements identification
           How requirements are individually identified;
       A change management process
          The process followed when analysing a
           requirements change;
       Traceability policies
          The amount of information about requirements
           relationships that is maintained;
       CASE tool support
          The tool support required to help manage
           requirements change;
                                                       244
Requirements Change Management

       Should apply to all proposed changes
        to the requirements.
       Principal stages
         Problem analysis. Discuss
          requirements problem and propose
          change;
         Change analysis and costing. Assess
          effects of change on other
          requirements;
         Change implementation. Modify
          requirements document and other
          documents to reflect change.
                                                245
Chapter 5:
Design

   Design Principles
  Design and Quality
  Quality Guidelines
    Design Concept



                       246
Design Principles
   The design process should not suffer
    from ‗tunnel vision.‘
   The design should be traceable to the
    analysis model.
   The design should not reinvent the
    wheel.
   The design should ―minimize the
    intellectual distance‖ between the
    software and the problem as it exists in
    the real world.
   The design should exhibit uniformity
    and integration.


                                               247
Design Principles (cont’d)

   The design should be structured to
    accommodate change.
   The design should be structured to degrade
    gently, even when aberrant data, events, or
    operating conditions are encountered.
   Design is not coding, coding is not design.
   The design should be assessed for quality as
    it is being created, not after the fact.
   The design should be reviewed to minimize
    conceptual (semantic) errors.


                                              248
Design and Quality
   the design must implement all of the explicit
    requirements contained in the analysis
    model, and it must accommodate all of the
    implicit requirements desired by the
    customer.
   the design must be a readable,
    understandable guide for those who
    generate code and for those who test and
    subsequently support the software.
   the design should provide a complete
    picture of the software, addressing the data,
    functional, and behavioral domains from an
    implementation perspective.                249
Quality Guidelines

       A design should exhibit an architecture that
         (1) has been created using recognizable
          architectural styles or patterns,
         (2) is composed of components that exhibit good
          design characteristics and
         (3) can be implemented in an evolutionary
          fashion
          For smaller systems, design can sometimes be
          developed linearly.
       A design should be modular; that is, the
        software should be logically partitioned into
        elements or subsystems
       A design should contain distinct
        representations of data, architecture,
        interfaces, and components.                     250
Quality Guidelines (cont’d)
   A design should lead to data structures that are
    appropriate for the classes to be implemented and
    are drawn from recognizable data patterns.
   A design should lead to components that exhibit
    independent functional characteristics.
   A design should lead to interfaces that reduce the
    complexity of connections between components and
    with the external environment.
   A design should be derived using a repeatable
    method that is driven by information obtained during
    software requirements analysis.
   A design should be represented using a notation that
    effectively communicates its meaning.



                                                      251
Fundamental Design Concepts

    Abstraction—data, procedure, control
    Architecture—the overall structure of the
     software
    Patterns—‖conveys the essence‖ of a
     proven design solution
    Modularity—compartmentalization of data
     and function
    Information hiding—controlled interfaces
    Functional independence—single-minded
     function and low coupling
    Refinement—elaboration of detail for all
     abstractions
    Refactoring—a reorganization technique
     that simplifies the design                252
Abstraction
   For a solution to any problem, many
    levels of abstraction can be posed.
   At the highest level of abstraction, a
    solution is stated in broad terms.
   At lower levels of abstraction, a more
    detailed description of the solution is
    provided.



                                          253
Abstraction - Data Abstraction

   A named collection of data that
    describes a data object
   (EX) Door
     Manufacturer,
     Model Number,
     Type,
     Weight,
     Heights,
     Swing Direction, …
   Implemented as a data structure
                                      254
Abstraction - Procedural Abstraction

   A procedural abstraction refers to a
    sequence of instructions that have a
    specific and limited function.
   (EX) Open:
    Details of enter algorithm
      Walk to the door,
      Reach out and grasp knob,
      Turn knob and pull door,
      Step away from moving door, …
    implemented with a "knowledge" of the
      object that is associated with enter
                                             255
Software architecture
   The design process for identifying the
    sub-systems making up a system and
    the framework for sub-system control
    and communication is architectural
    design.
   The output of this design process is a
    description of the software
    architecture.


                                        256
Design Patterns
       The best designers in any field have an uncanny
        ability to see patterns that characterize a problem
        and corresponding patterns that can be combined
        to create a solution
       A description of a design pattern may also
        consider a set of design forces.
          Design forces describe non-functional requirements
           (e.g., ease of maintainability, portability) associated
           the software for which the pattern is to be applied.
       The pattern characteristics (classes,
        responsibilities, and collaborations) indicate the
        attributes of the design that may be adjusted to
        enable the pattern to accommodate a variety of
        problems.

                                                                257
 Design Patterns
Design Pattern Template
Pattern name—describes the essence of the pattern in a short but expressive
name
Intent—describes the pattern and what it does
Also-known-as—lists any synonyms for the pattern
Motivation—provides an example of the problem
Applicability—notes specific design situations in which the pattern is applicable
Structure—describes the classes that are required to implement the pattern
Participants—describes the responsibilities of the classes that are required to
implement the pattern
Collaborations—describes how the participants collaborate to carry out their
responsibilities
Consequences—describes the ―design forces‖ that affect the pattern and the
potential trade-offs that must be considered when the pattern is implemented
Related patterns—cross-references related design patterns
                                                                            258
Design Pattern - Example I

Glyph Hierarchy




                             259
    Design Pattern - Example II

   Composite Pattern – Generalization of
    Glyph




                                            260
Frameworks
  A framework is not an architectural pattern,
   but rather a skeleton with a collection of
   ―plug points‖ (also called hooks and slots)
   that enable it to be adapted to a specific
   problem domain.
  Gamma et al note that:
   Design patterns are more abstract than
      frameworks.
   Design patterns are smaller architectural
      elements than frameworks
   Design patterns are less specialized than
      frameworks
                                              261
Modular Design
       Modularity:
         Software is divided into separately
          named and addressed components, or
          Modules, that are integrated to satisfy
          problem requirements.
         The single attribute of software that
          allows a program to be intellectually
          manageable.



                                               262
Modular decomposition styles

   Styles of decomposing sub-systems
    into modules.
   No rigid distinction between system
    organisation and modular
    decomposition.




                                          263
Modular decomposition
 Another structural level where sub-
  systems are decomposed into modules.
 Two modular decomposition models
  covered
  An object model where the system is
     decomposed into interacting object;
  A pipeline or data-flow model where the
     system is decomposed into functional
     modules which transform inputs to
     outputs.
 If possible, decisions about concurrency
  should be delayed until modules are
  implemented.

                                             264
Modularity: Trade-offs
  What is the "right" number of modules
  for a specific software design?

                    module development cost

   cost of
  software

                                                module
                                              integration
                                                  cost




  optimal number                    number of modules
    of modules
                                                            265
Information Hiding

       Modules should be specified and designed so
        that information (algorithms and data)
        contained within a module is inaccessible to
        other modules that have no need for such
        information.
       Why Information Hiding?
         reduces the likelihood of ―side effects‖
         limits the global impact of local design
          decisions
         emphasizes communication through controlled
          interfaces
         discourages the use of global data
         leads to encapsulation—an attribute of high
          quality design
         results in higher quality software          266
Information Hiding

                module          • algorithm
                 controlled
                 interface      • data structure
                                • details of external interface

                                • resource allocation policy

  clients            "secret"




  a specific design decision

                                                                  267
Functional Independence


    COHESION - the degree to which a
    module performs one and only one
    function.

    COUPLING - the degree to which a
    module is "connected" to other
    modules in the system.



                                       268
COHESION

   Cohesion is a measure of how
    well the individual tasks are
    unified within a module.
   We say a module is highly
    cohesive if it accomplishes one
    and only one indivisible task.



                                      269
        COHESION (cont’d)
        Seven Types of Cohesion, from Best to Worst


        Type               Desirability       Description

        Functional         Acceptable         One task

        Sequential         Acceptable         Common data, order
                                              important
        Communicational    Acceptable         Common data, order not
                                              important
best
        Procedural         Occasionally       No common data, done at
worst                      Acceptable         same time

        Temporal           Not acceptable     No common data, done at
                                              same time
        Logical            Not acceptable     Parallel but mutually
                                              exclusive tasks
        coincidental       Not acceptable     Activities with no
                                              relationship            270
 COHESION - FUNCTIONAL COHESION

          Functional cohesion exists whenever a
           module carries out exactly one function.




               FORMAT         WRITE
One Task        PRINT         PRINT
                                          CALCULATE
                                          SOLUTION
                 LINE          LINE




           Functional Cohesion (Acceptable)

                                                      271
COHESION - SEQUENTIAL COHESION

     The output of one task immediately serves
      as the input to the next.
     GET VALID TRANSACTION has sequential cohesion,
      and both of its subordinates have functional cohesion.



Common Data                  GET VALID   Sequential
                                         Cohesion
Order Important            TRANSACTION



                           TRANSACTION

    Functional  READ                         EDIT    Functional
    Cohesion TRANSACTION                 TRANSACTION Cohesion


         Sequential Cohesion (Acceptable)                         272
COHESION - COMMUNICATIONAL COHESION

       Several modules use the same inputs, but their
        order of execution is irrelevant.




Common Data                    APPLY    Communicational
                            TRANSACTION cohesion
Order NOT Important

                            TRANSACTION

                    WRITE
      Functional                             WRITE        Functional
                     FILE
      Cohesion                              REPORT        Cohesion
                   RECORD


      Communicational Cohesion (Acceptable)                            273
    COHESION - PROCEDURAL COHESION

          Procedural cohesion is present when control, rather
           than data, is passed from one module to the next.
          Order is important but there are no shared or passed
           data.

NO Common Data
                                     CLEAN           Procedural
Order Important                       UP             Cohesion
               LAST-TRANSACTION
                                                             FLAG


                                                      COUNTER
                                  NEXT-TRANSACTION




        WRITE                GET                                                 Functional
                                                INITIALIZE          INITIALIZE
        LAST                NEXT
                                                COUNTER                FLAG      Cohesion
     TRANSACTION         TRANSACTION                                             (all)


         Procedural Cohesion (Not Acceptable)                                        274
COHESION - TEMPORAL COHESION

       Activities are traditionally done at the
        same time but have no other
        meaningful relationship; there are no
        data in common, and order is not
        important.


     NO Common Data      OPEN FILE, GET DATE,
                         WRITE PAGE HEADERS,
     Done at Same Time       SET TOTALS




                                                275
    COHESION - LOGICAL COHESION

      Several related but mutually exclusive functions are
       in the same module, with a downward-flowing flag
       that notifies that module of which function to
       perform.
      On any given call, only the selected portion of code
       is executed.
Parallel but
                                   TRANSACTION
Mutually Exclusive Tasks
                           PROCESS ADD,
                           CHANGE, OR
                           DELETE
                           TRANSACTION


               Logical Cohesion (Not Acceptable)       276
    COHESION (cont’d)
     Coincidental cohesion exists when a module
      consists of totally unrelated activities. Modules
      with coincidental cohesion turn out to be
      ―garbage routines‖; they have no place in a
      carefully designed system.




                       OPEN FILES,
    Activities with    WRITE NEXT
                       TRANSACTION,
    NO Relationship    CALCULATE PAY


           Coincidental Cohesion ( not Acceptable)    277
COUPLING

   Coupling is an indication of the types of
    couples passed between two modules
    and of how dependent the modules are
    on each other.
   When we have independent modules,
    the ideal situation, we say, we have low
    or loose coupling.
   In contrast, modules that are dependent
    on each other are said to be highly or
    tightly coupled.

                                           278
COUPLING (cont’d)

           Type     Desirability        Description

                                     Simple or single-field
           Data      Acceptable
                                     parameter
                                     Multiple fields in one
           Stamp     Acceptable
                                     data structure
best
          Control   Not acceptable       Control flag
worst
          Common    Not acceptable      Common area

                                     Internal change to a
          Content   Not acceptable
                                     module



        Five Types of Coupling, from Best to Worst
                                                              279
 COUPLING - Data Coupling

    Data coupling involves couples that
     consist of single-field parameters
                                                   Multiple Fields in
Simple Parameters
                               APPLY
                             CUSTOMER              One Data Structure
                              PAYMENT
             OLD-CUSTOMER-                  CUSTOMER
             BALANCE                        RECORD
             PAYMENT-        NEWCUSTOMER-
             AMOUNT          BALANCE
                                                            DC : Data
           DC   CALCULATE                UPDATE        SC        Coupling
                CUSTOMER                CUSTOMER            SC : Stamp
                 BALANCE                 RECORD
                                                                 Coupling

     Data Coupling on Left (Acceptable) and
                                                                            280
     Stamp Coupling on Right (Acceptable)
COUPLING - Stamp Coupling
Stamp coupling involves a data structure, or composite data,
such as a customer record or a payment transaction.
                                                 Multiple Fields in
Simple Parameters
                               APPLY             One Data Structure
                             CUSTOMER
                              PAYMENT
             OLD-CUSTOMER-                  CUSTOMER
             BALANCE                        RECORD
             PAYMENT-        NEWCUSTOMER-                   DC : Data
             AMOUNT          BALANCE                             Coupling
                                                            SC : Stamp
                CALCULATE                UPDATE        SC
           DC
                CUSTOMER                CUSTOMER
                                                                 Coupling
                 BALANCE                 RECORD




      Data Coupling on Left (Acceptable) and
      Stamp Coupling on Right (Acceptable)                              281
     COUPLING - Control Coupling
       Stamp coupling involves a data structure, or
        composite data, such as a customer record or a
        payment transaction.
    Stamp Coupling                                   Control Coupling
    Multiple Fields in                               Control Flag
                                    APPLY
    One Data Structure           TRANSACTION
                                                    PRINT-TRAN-ERROR-
                ERROR-FLAG
                                                    MESSAGE-FLAG
                                 TRAN-TYPE-FLAG


                                 TRANSACTION


                       GET                          PROCESS
                   TRANSACTION                    TRANSACTION



         Stamp Coupling on Left (Acceptable) and
         Control Coupling on Right (Not Acceptable)                     282
COUPLING - Control Coupling (cont’d)


    A descriptive flag describes what has happened,
     but a control flag makes an order about what
     will happen.

                INTENT    DESCRIPTIVE         CONTROL
    DIRECTION
    UPWARD-FLOWING        Data coupling     Control coupling

       DOWNWARD-         Control coupling   Control coupling
        FLOWING


    Only satisfactory flag is an upward-flowing
     descriptive flag, which is considered to indicate
     data coupling.                                283
COUPLING - Control Coupling (cont’d)

   All other flags indicate control
    coupling and should be avoided.
   In figure on slide 273, the left-hand
    connection has an upward-flowing
    descriptive flag, and thus shows data
    coupling.
   The right-hand connection has a
    stamp couple and two control flags,
    resulting in control coupling.

                                        284
    COUPLING - Control Coupling (cont’d)

     Control coupling occurs when one module is made
      to control the internal logic of another, usually by
      means of a flag.
Stamp Coupling
                                                             Control Coupling
Multiple Fields in                                           Control Flag
One Data Structure                    APPLY
                                   TRANSACTION
                                                      PRINT-TRAN-ERROR-
                 ERROR-FLAG
                                                      MESSAGE-FLAG
                                   TRAN-TYPE-FLAG


                                   TRANSACTION


                         GET                          PROCESS
                     TRANSACTION                    TRANSACTION



            Stamp Coupling on Left (Acceptable) and
            Control Coupling on Right (Not Acceptable)                     285
    COUPLING - Common Coupling

    When two or more modules refer to the same
     common or global area, common coupling exists
     between those modules.



                   SAVE           GET
                   DATA           DATA




     Common Data          DATA


             Common Coupling (Not Acceptable)        286
     COUPLING - CONTENT COUPLING

       Content coupling occurs when one module directly
        refers to the inside of another module in any way.
       Unstructured branching into another module and
        using the COBOL verb ALTER are examples of
        content coupling.

                                   DO
                                  STUFF
    Internal Change to a Module


                           GET            SAVE
                           DATA           DATA



              Content Coupling (Not Acceptable)          287
    Refinement - FACTORING
     Factoring is partitioning a module into two or more
      lower-level modules.
     Reasons why modules should be factored down to very
      small, single-function ones:
    1. Module size and complexity are reduced, thereby
         simplifying both implementation and maintenance.
    2. The system is rendered easier to understand.
    3. The same function is not carried out by more than one
         modules.
    4. Work is separated from the management of that work;
         management modules should only manage.
    5. When creating a structure chart, we may decide that a
         module is too small to be practical, and we may
         include the code for it within its supervisor.
                                                           288
    Refinement - FACTORING (cont’d)

    Fan-out is the count of the number of
     subordinates under a module.
    Generally try to limit the fan-out to
     seven or fewer for any given supervisor.
    One notable exception is with a
     transaction-center module; in that case,
     fan-out may be equal to the number of
     transaction types.


                                           289
    Refinement - FACTORING (cont’d)

    Fan-in is the count of the number of
     supervisors above a module.
    High fan-in turns out to be the systems
     designer‘s ―reward for intelligent factoring.‖
    When fan-in is greater than one, the
     subordinate module must have good cohesion
     and should be given the same parameters
     regardless of which supervisor calls it.
    Otherwise, the subordinate will display logical
     cohesion, since it must examine the
     parameters before deciding what to do.

                                                  290
Refinement - Refactoring
   Fowler defines refactoring in the following manner:
      "Refactoring is the process of changing a
       software system in such a way that it does
       not alter the external behavior of the code
       [design] yet improves its internal structure.‖
   When software is refactored, the existing design is
    examined for
      redundancy
      unused design elements
      inefficient or unnecessary algorithms
      poorly constructed or inappropriate data
       structures
      or any other design failure that can be
       corrected to yield a better design.
                                                    291
Design Methods
   Data Design
   Architectural Design
   Transform Mapping
   Transaction Mapping
   Interface Design
   Structured Design
   Object-Oriented Design


                             292
Data Design -
Architectural Level
 Design of one or more databases to
  support the application architecture
 Design of methods for ‗mining‘ the content
  of multiple databases
  navigate through existing databases in
     an attempt to extract appropriate
     business-level information
  Design of a data warehouse—a large,
     independent database that has access to
     the data that are stored in databases
     that serve the set of applications
     required by a business                293
Data Design –
   component level
   refine data objects and develop a
    set of data abstractions
   implement data object attributes
    as one or more data structures
   review data structures to ensure
    that appropriate relationships
    have been established
   simplify data structures as
    required
                                        294
Architectural Design
       The software must be placed into context
         the design should define the external entities
          (other systems, devices, people) that the
          software interacts with and the nature of the
          interaction
       A set of architectural archetypes should be
        identified
         An archetype is an abstraction (similar to a
          class) that represents one element of system
          behavior
       The designer specifies the structure of the
        system by defining and refining software
        components that implement each archetype           295
Architectural Styles

   Data-centered architectures
   Data flow architectures
   Call and return architectures
   Object-oriented architectures
   Layered architectures




                                    296
Data-Centered Architecture




                         297
Data Flow Architecture




                         298
Call and Return Architecture




                           299
Transform Mapping

              b                             g            h
          a                  e    f
                       d
              c                             i
                                                     j
                       data flow model

                  x1                                "Transform" mapping
     x2           x3                   x4

 b        c   d        e     f     g            i

     a                            h             j
                                                                          300
Transaction Mapping
                                                              e           f
                    a                             d
                         b
                                 t                                    i
                                                  g
                                                          h                   k
                                     l                                j
     data flow model
                                             m
                    x1                                n
                                                                                   Mapping
 b                                       t

 a         x2                            x3                                   x4

       d   e    f            g           h        x3.1            l           m      n

                                              i           j
                                                                                             301
                                                      k
Interface Design
   Easy to learn?
   Easy to understand?
   Easy to use?




                          302
Interface Design (cont’d)

       Typical Design Errors
         lack of consistency
         too much memorization
         no guidance / help
         no context sensitivity
         poor response
         Arcane/unfriendly


                                   303
Interface Design (cont’d)


     Golden Rules
      Place the user in control
      Reduce the user‘s memory
       load
      Make the interface consistent



                                       304
User Interface Design Models

   User model - a profile of all end users of
    the system
   Design model - a design realization of the
    user model
   Mental model (system perception) - the
    user‘s mental image of what the interface
    is
   Implementation model - the interface ―look
    and feel‖ coupled with supporting
    information that describe interface syntax
    and semantics
                                           305
Interface Design Steps

   Using information developed during
    interface analysis, define interface
    objects and actions (operations).
   Define events (user actions) that will
    cause the state of the user interface to
    change. Model this behavior.
   Depict each interface state as it will
    actually look to the end-user.
   Indicate how the user interprets the
    state of the system from information
    provided through the interface.
                                               306
Interface Design Patterns

        Patterns are available for
          The complete UI
          Page layout
          Forms and input
          Tables
          Direct data manipulation
          Navigation
          Searching
          Page elements
          e-Commerce                 307
Interface Design Issues

   Response time
   Help facilities
   Error handling
   Menu and command labeling
   Application accessibility
   Internationalization



                                308
Structured Design

          objective: to derive a
           program architecture that
           is partitioned
          approach:
            the DFD is mapped into a
             program architecture
            the PSPEC and STD are
             used to indicate the
             content of each module
          notation: structure chart
                                        309
Structured Design (cont’d)

       Structured Analysis/Structured
        Design
       3 major conceptual tools for modeling
            data flow diagrams
              functional specifications
            data dictionaries
              centralized definitions
            Structured English
              to describe transformation of terminal
               bubbles
                                                        310
Structured Design (cont’d)

   A DAG (Directed Acyclic Graph) of functional modules
 (Direction of the arrow: implicitly downward)


                     M




      M1                 M2              M3

                                                     311
Structured Programming
for Procedural Design
   uses a limited set of logical constructs:
    sequence
    conditional — if-then-else, select-case
    loops — do-while, repeat until
   leads to more readable, testable code
   can be used in conjunction with ‗proof
    of correctness‘
   important for achieving high quality,
    but not enough

                                          312
A Structured Procedural Design

                             add a condition Z,
               a             if true, exit the program

               x1

      b             x2   c

      x3            d

           f        e

                    x4


               g

               x5

                                                         313
Program Design Language (PDL)

                        if condition x
                          then process a;
                          else process b;
                        endif
     if-then-else             PDL
   easy to combine with source code

   machine readable, no need for graphics input

   graphics can be generated from PDL

   enables declaration of data as well as procedure

   easier to maintain
                                                      314
Why Design Language?

    can be a derivative of the HOL of choice
    e.g., Ada PDL

    machine readable and processable

    can be embedded with source code,
    therefore easier to maintain

    can be represented in great detail, if
    designer and coder are different

    easy to review
                                               315
Object-Oriented Design
   Object-Oriented Development
   Characteristics of OOD
   Advantages of OOD
   Object models
   OO Design Concepts
   Design Classes
   Objects and object classes
   The Unified Modeling Language (UML)

                                      316
Object-Oriented Development
   Object-oriented analysis, design and
    programming are related but distinct.
   OOA is concerned with developing an object
    model of the application domain.
   OOD is concerned with developing an
    object-oriented system model to implement
    requirements.
   OOP is concerned with realising an OOD
    using an OO programming language such as
    Java or C++.


                                            317
Characteristics of OOD
   Objects are abstractions of real-world or
    system entities and manage themselves.
   Objects are independent and encapsulate
    state and representation information.
   System functionality is expressed in terms
    of object services.
   Shared data areas are eliminated. Objects
    communicate by message passing.
   Objects may be distributed and may
    execute
    sequentially or in parallel.
                                                 318
Advantages of OOD
   Easier maintenance. Objects may be
    understood as stand-alone entities.
   Objects are potentially reusable
    components.
   For some systems, there may be an
    obvious mapping from real world
    entities to system objects.



                                          319
Advantages of OOD (cont’d)

   Objects are loosely coupled so their
    implementation can be modified without
    affecting other objects.
   The objects may reflect real-world entities.
   OO implementation languages are widely
    used.
   However, object interface changes may
    cause problems and complex entities may
    be hard to represent as objects.



                                                   320
Object Models
   Structure the system into a set of
    loosely coupled objects with well-
    defined interfaces.
   Object-oriented decomposition is
    concerned with identifying object
    classes, their attributes and
    operations.
   When implemented, objects are
    created from these classes and some
    control model used to coordinate
    object operations.                 321
OO Design Concepts
  Design classes
   Entity classes
   Boundary classes
   Controller classes
  Inheritance—all responsibilities of a
   superclass is immediately inherited by all
   subclasses
  Messages—stimulate some behavior to
   occur in the receiving object
  Polymorphism—a characteristic that
   greatly reduces the effort required to
   extend the design
                                            322
Design Classes
 Analysis classes are refined during
  design to become entity classes.
 Boundary classes are developed
  during design to create the interface
  (e.g., interactive screen or printed
  reports) that the user sees and
  interacts with as the software is used.
  Boundary classes are designed with
     the responsibility of managing the
     way entity objects are represented
     to users.
                                       323
Design Classes (cont’d)
     Controller classes are designed to manage
     the creation or update of entity objects;
        the instantiation of boundary objects as
        they obtain information from entity objects;
        complex communication between sets of
        objects;
        validation of data communicated between
        objects or between the user and the
        application.



                                                324
Objects and Object Classes

   Objects are entities in a software
    system which represent instances of
    real-world and system entities.
   Object classes are templates for
    objects. They may be used to create
    objects.
   Object classes may inherit attributes
    and services from other object classes.


                                        325
Unified Modeling Language

   UML, UML 2.0
   Several different notations for describing
    object-oriented designs were proposed in
    the 1980s and 1990s.
   The Unified Modeling Language is an
    integration of these notations.
   It describes notations for a number of
    different models that may be produced
    during OO analysis and design.
   It is now a de facto standard for OO
    modelling.
                                                 326
Object Communication
       Conceptually, objects communicate by
        message passing.
       Messages
         The name of the service requested by the
          calling object;
         Copies of the information required to execute
          the service
          and the name of a holder for the result of the
          service.
       In practice, messages are often
        implemented
        by procedure calls
         Name = procedure name;
         Information = parameter list.
                                                      327
Message Examples
 // Call a method associated with a buffer
 // object that returns the next value
 // in the buffer
         v = circularBuffer.Get () ;

 // Call the method associated with a
 // thermostat object that sets the
 // temperature to be maintained
        thermostat.setTemp (20) ;

                                             328
Generalization and Inheritance

   Objects are members of classes that define
    attribute types and operations.
   Classes may be arranged in a class
    hierarchy
    where one class (a super-class) is a
    generalisation of one or more other classes
    (sub-classes).
   A sub-class inherits the attributes and
    operations from its super class and may add
    new methods or attributes of its own.
   Generalisation in the UML is implemented as
    inheritance in OO programming languages.

                                             329
    Inheritance
     Design options:
       The class can be designed and built from scratch. That
        is, inheritance is not used.
       The class hierarchy can be searched to determine if a
        class higher in the hierarchy (a superclass)contains
        most of the required attributes and operations. The
        new class inherits from the superclass and additions
        may then be added, as required.
       The class hierarchy can be restructured so that the
        required attributes and operations can be inherited by
        the new class.
       Characteristics of an existing class can be overridden
        and different versions of attributes or operations are
        implemented for the new class.
                                                          330
Generalisation Hierarchy
                                 Employee




               Mana ger                          Prog rammer

       bu dg ets Con trolled                   pro ject
                                               pro gLang uages
      dateAp po in ted




   Project                  Dept.              Strateg ic
   Mana ger                Mana ger            Mana ger

   pro jects              dept              res po ns ib ilities




                                                                   331
Advantages of Inheritance

   It is an abstraction mechanism which
    may be used to classify entities.
   It is a reuse mechanism at both the
    design and the programming level.
   The inheritance graph is a source of
    organisational knowledge about
    domains and systems.



                                       332
Problems with Inheritance

   Object classes are not self-contained.
    they cannot be understood without
    reference to their super-classes.
   Designers have a tendency to reuse
    the inheritance graph created during
    analysis. Can lead to significant
    inefficiency.
   The inheritance graphs of analysis,
    design and implementation have
    different functions and should be
    separately maintained.               333
 Polymorphism
Conventional approach …
 case of graphtype:
         if graphtype = linegraph then DrawLineGraph (data);
         if graphtype = piechart then DrawPieChart (data);
         if graphtype = histogram then DrawHisto (data);
         if graphtype = kiviat then DrawKiviat (data);
 end case;
All of the graphs become subclasses of a general class called
graph. Using a concept called overloading, each subclass
defines an operation called draw. An object can send a draw
message to any one of the objects instantiated from any one of
the subclasses. The object receiving the message will invoke
its own draw operation to create the appropriate graph.

       graphtype draw                                            334
Architectural Design
       Once interactions between the system and
        its environment have been understood, you
        use this information for designing the
        system architecture.
       A layered architecture is appropriate for the
        weather station
         Interface layer for handling communications;
         Data collection layer for managing
          instruments;
         Instruments layer for collecting data.
       There should normally be no more than 7
        entities in an architectural model.

                                                     335
Object Identification
   Identifying objects (or object classes)
    is the most difficult part of object
    oriented design.
   There is no 'magic formula' for object
    identification. It relies on the skill,
    experience
    and domain knowledge of system
    designers.
   Object identification is an iterative
    process. You are unlikely to get it
    right first time.                       336
Approaches to Identification

   Use a grammatical approach based on a
    natural language description of the system
    (used in Hood OOD method).
   Base the identification on tangible things in
    the application domain.
   Use a behavioural approach and identify
    objects based on what participates in what
    behaviour.
   Use a scenario-based analysis. The objects,
    attributes and methods in each scenario are
    identified.

                                               337
Further Objects and Object Refinement

        Use domain knowledge to identify more
         objects and operations
          Weather stations should have a unique
           identifier;
          Weather stations are remotely situated so
           instrument failures have to be reported
           automatically. Therefore attributes and
           operations for self-checking are required.
        Active or passive objects
          In this case, objects are passive and collect
           data on request rather than autonomously.
           This introduces flexibility at the expense of
           controller processing time.

                                                           338
Design Models
   Design models show the objects and
    object classes and relationships
    between these entities.
   Static models describe the static
    structure of the system in terms of
    object classes and relationships.
   Dynamic models describe the
    dynamic interactions between objects.


                                       339
Examples of Design Models
   Sub-system models that show logical
    groupings of objects into coherent
    subsystems.
   Sequence models that show the sequence of
    object interactions.
   State machine models that show how
    individual objects change their state in
    response to events.
   Other models include use-case models,
    aggregation models, generalisation models,
    etc.

                                            340
Subsystem Models
   Shows how the design is organised
    into logically related groups of objects.
   In the UML, these are shown using
    packages - an encapsulation
    construct. This is a logical model. The
    actual organisation of objects in the
    system may be different.




                                          341
Sequence Models
    Sequence models show the sequence of
     object interactions that take place
     Objects are arranged horizontally across
       the top;
     Time is represented vertically so models
       are read top to bottom;
     Interactions are represented by labelled
       arrows, Different styles of arrow
       represent different types of interaction;
     A thin rectangle in an object lifeline
       represents the time when the object is
       the controlling object in the system.

                                               342
Data Collection Sequence




                       343
Statecharts
       Show how objects respond to different
        service requests and the state transitions
        triggered by these requests
         If object state is Shutdown then it responds
          to a Startup() message;
         In the waiting state the object is waiting for
          further messages;
         If reportWeather () then system moves to
          summarising state;
         If calibrate () the system moves to a
          calibrating state;
         A collecting state is entered when a clock
          signal is received.
                                                           344
Weather Station State Diagram




                                345
Object Interface Specification

   Object interfaces have to be specified so
    that the objects and other components can
    be designed in parallel.
   Designers should avoid designing the
    interface representation but should hide this
    in the object itself.
   Objects may have several interfaces which
    are viewpoints on the methods provided.
   The UML uses class diagrams for interface
    specification but Java may also be used.


                                               346
Weather Station Interface

  interface WeatherStation {

        public void WeatherStation () ;

        public void startup () ;
        public void startup (Instrument i) ;

        public void shutdown () ;
        public void shutdown (Instrument i) ;

        public void reportWeather ( ) ;

        public void test () ;
        public void test ( Instrument i ) ;

        public void calibrate ( Instrument i) ;

        public int getID () ;

  } //WeatherStation

                                                  347
Design Evolution
   Hiding information inside objects means
    that
    changes made to an object do not affect
    other
    objects in an unpredictable way.
   Assume pollution monitoring facilities are to
    be
    added to weather stations. These sample
    the
    air and compute the amount of different
    pollutants in the atmosphere.
   Pollution readings are transmitted with
    weather
    data.

                                                348
Changes Required
   Add an object class called Air quality
    as part of WeatherStation.
   Add an operation reportAirQuality to
    WeatherStation. Modify the control
    software to collect pollution readings.
   Add objects representing pollution
    monitoring instruments.



                                          349
Basic Design Principles

Souce: Martin, R., ―Design Principles and Design
    Patterns,‖ downloaded from
    http:www.objectmentor.com, 2000.
   The Open-Closed Principle (OCP).
         “A module [component] should be open for
          extension but closed for modification.
       The Liskov Substitution Principle (LSP).
         “Subclasses should be substitutable for their
          base classes.
       Dependency Inversion Principle (DIP).
         “Depend on abstractions. Do not depend on
          concretions.”

                                                          350
Basic Design Principles (cont’d)

       The Interface Segregation Principle (ISP).
         “Many client-specific interfaces are better
          than one general purpose interface.
       The Release Reuse Equivalency Principle
        (REP).
         “The granule of reuse is the granule of
          release.”
       The Common Closure Principle (CCP).
         “Classes that change together belong
          together.”
       The Common Reuse Principle (CRP).
         “Classes that aren’t reused together should
          not be grouped together.”

                                                        351
Design Guidelines
   Components
      Naming conventions should be established for
       components that are specified as part of the
       architectural model and then refined and
       elaborated as part of the component-level
       model
   Interfaces
       Interfaces provide important information
       about communication and collaboration (as
       well as helping us to achieve the OPC)
   Dependencies and Inheritance
      it is a good idea to model dependencies from
       left to right and inheritance from bottom
       (derived classes) to top (base classes).
                                                 352
    Cohesion
     Conventional view:
        the ―single-mindedness‖ of a module
     OO view:
        cohesion implies that a component or class
         encapsulates only attributes and operations that are
         closely related to one another and to the class or
         component itself
     Levels of cohesion
        Functional
        Layer
        Communicational
        Sequential
        Procedural
        Temporal
        utility                                            353
Coupling
       Conventional view:
          The degree to which a component is connected
           to other components and to the external world
       OO view:
          a qualitative measure of the degree to which
           classes are connected to one another
       Level of coupling
          Content
          Common
          Control
          Stamp
          Data
          Routine call
          Type use
          Inclusion or import
          External

                                                      354
Component Level Design-I
   Step 1. Identify all design classes that
    correspond to the problem domain.
   Step 2. Identify all design classes that
    correspond to the infrastructure domain.
   Step 3. Elaborate all design classes that
    are not acquired as reusable
    components.
   Step 3a. Specify message details when
    classes or component collaborate.
   Step 3b. Identify appropriate interfaces
    for each component.
   Step 3c. Elaborate attributes and define
    data types and data structures required
    to implement them.
                                                355
Component-Level Design-II
   Step 3d. Describe processing flow within
    each operation in detail.
   Step 4. Describe persistent data sources
    (databases and files) and identify the
    classes required to manage them.
   Step 5. Develop and elaborate
    behavioral representations for a class or
    component.
   Step 6. Elaborate deployment diagrams
    to provide additional implementation
    detail.
   Step 7. Factor every component-level
    design representation and always
    consider alternatives.
                                                356
Algorithm Design
       the closest design activity to
        coding
       the approach:
         review the design description for
          the component
         use stepwise refinement to
          develop algorithm
         use structured programming to
          implement procedural logic
         use ‗formal methods‘ to prove
          logic

                                              357
Algorithm Design Model

       represents the algorithm at a level of
        detail that can be reviewed for quality
       options:
         graphical (e.g. flowchart, box diagram)
         pseudocode (e.g., PDL) ... choice of many
         programming language
         decision table
         conduct walkthrough to assess quality


                                                358
Chapter 6:
Development




              359
Development
       Rapid Software Development
         Agile Methods
         Extreme Programming
         Rapid Application Development
         Prototyping
       Software Reuse
       Component-based Software
        Engineering
       Software Evolution
                                          360
Rapid Software Development
   Because of rapidly changing business
    environments, businesses have to
    respond to new opportunities and
    competition.
   This requires software and rapid
    development and delivery is not often
    the most critical requirement for
    software systems.
   Businesses may be willing to accept
    lower quality software if rapid delivery
    of essential functionality is possible.
                                          361
Requirements

   Because of the changing
    environment, it is often impossible to
    arrive at a stable, consistent set of
    system requirements.
   Therefore a waterfall model of
    development is impractical and an
    approach to development based on
    iterative specification and delivery is
    the only way to deliver software
    quickly.
                                          362
Characteristics of RAD processes

   The processes of specification, design and
    implementation are concurrent. There is no
    detailed specification and design
    documentation is minimised.
   The system is developed in a series of
    increments. End users evaluate each
    increment and make proposals for later
    increments.
   System user interfaces are usually
    developed using an interactive development
    system.

                                            363
Advantages: Incremental Development


       Accelerated delivery of customer
        services.
         Each increment delivers the highest
          priority functionality to the customer.
       User engagement with the system.
         Users have to be involved in the
          development which means the system
          is more likely to meet their
          requirements and the users are more
          committed to the system.
                                                364
Problems with incremental development

     Management problems
        Progress can be hard to judge and problems hard to
         find because there is no documentation to
         demonstrate what has been done.
     Contractual problems
        The normal contract may include a specification;
         without a specification, different forms of contract
         have to be used.
     Validation problems
        Without a specification, what is the system being
         tested against?
     Maintenance problems
        Continual change tends to corrupt software structure
         making it more expensive to change and evolve to
         meet new requirements.
                                                          365
Prototyping
   For some large systems, incremental
    iterative development and delivery
    may be impractical; this is especially
    true when multiple teams are working
    on different sites.
   Prototyping, where an experimental
    system is developed as a basis for
    formulating the requirements may be
    used. This system is thrown away
    when the system specification has
    been agreed.                           366
Incremental development and
prototyping




                              367
Conflicting objectives
   The objective of incremental
    development is to deliver a working
    system to end-users. The development
    starts with those requirements which are
    best understood.
   The objective of throw-away prototyping
    is to validate or derive the system
    requirements. The prototyping process
    starts with those requirements which are
    poorly understood.

                                          368
Agile methods
       Dissatisfaction with the overheads involved
        in design methods led to the creation of
        agile methods. These methods:
         Focus on the code rather than the design;
         Are based on an iterative approach to
          software development;
         Are intended to deliver working software
          quickly and evolve this quickly to meet
          changing requirements.
       Agile methods are probably best suited to
        small/medium-sized business systems or PC
        products.
                                                      369
Principles of agile methods

Principle              Description
Customer involvement   The customer should be closely involved throughout the
                       development process. Their role is provide and prioritise new
                       system requirements and to evaluate the iterations of the system.
Incremental delivery   The software is developed in increments with the customer
                       specifying the requirements to be included in each increment.
People not process     The skills of the development team should be recognised and
                       exploited. The team should be left to develop their own ways of
                       working without prescriptive processes.
Embrace change         Expect the system requirements to change and design the system
                       so that it can accommodate these changes.
Maintain simplicity    Focus on simplicity in both the software being developed and in
                       the development process used. Wherever possible, actively work
                       to eliminate complexity from the system.

                                                                                           370
Problems with agile methods

   It can be difficult to keep the interest of
    customers who are involved in the process.
   Team members may be unsuited to the
    intense involvement that characterises agile
    methods.
   Prioritising changes can be difficult where
    there are multiple stakeholders.
   Maintaining simplicity requires extra work.
   Contracts may be a problem as with other
    approaches to iterative development.


                                              371
Extreme programming (XP)
   Perhaps the best-known and most widely used
    agile method.
   Extreme Programming (XP) takes an ‗extreme‘
    approach to iterative development.
      New versions may be built several times per
       day;
      Increments are delivered to customers every 2
       weeks;
      All tests must be run for every build and the
       build is only accepted if tests run successfully.



                                                     372
The XP Release Cycle




                       373
XP and Agile Principles
   Incremental development is supported
    through small, frequent system releases.
   Customer involvement means full-time
    customer engagement with the team.
   People not process through pair
    programming, collective ownership and a
    process that avoids long working hours.
   Change supported through regular system
    releases.
   Maintaining simplicity through constant
    refactoring of code.
                                               374
Requirements Scenarios
   In XP, user requirements are expressed
    as scenarios or user stories.
   These are written on cards and the
    development team break them down
    into implementation tasks. These tasks
    are the basis of schedule and cost
    estimates.
   The customer chooses the stories for
    inclusion in the next release based on
    their priorities and the schedule
    estimates.
                                         375
XP and Change
   Conventional wisdom in software
    engineering is to design for change. It
    is worth spending time and effort
    anticipating changes as this reduces
    costs later in the life cycle.
   XP, however, maintains that this is
    not worthwhile as changes cannot be
    reliably anticipated.
   Rather, it proposes constant code
    improvement (refactoring) to make
    changes easier when they have to be
    implemented.                         376
Testing in XP
   Test-first development.
   Incremental test development from
    scenarios.
   User involvement in test development
    and validation.
   Automated test harnesses are used to
    run all component tests each time
    that a new release is built.


                                      377
Test-First Development
   Writing tests before code clarifies the
    requirements to be implemented.
   Tests are written as programs rather than
    data so that they can be executed
    automatically. The test includes a check that
    it has executed correctly.
   All previous and new tests are automatically
    run when new functionality is added. Thus
    checking that the new functionality has not
    introduced errors.


                                               378
Pair Programming
   In XP, programmers work in pairs, sitting
    together to develop code.
   This helps develop common ownership of
    code and spreads knowledge across the
    team.
   It serves as an informal review process as
    each line of code is looked at by more than
    1 person.
   It encourages refactoring as the whole team
    can benefit from this.
   Measurements suggest that development
    productivity with pair programming is
    similar to that of two people working
    independently.
                                             379
Rapid Application Development

   Agile methods have received a lot of
    attention but other approaches to
    rapid application development have
    been used for many years.
   These are designed to develop data-
    intensive business applications and
    rely on programming and presenting
    information from a database.


                                           380
RAD Environment Tools
   Database programming language
   Interface generator
   Links to office applications
   Report generators




                                    381
RAD Environment




                  382
Interface Generation
       Many applications are based around
        complex forms and developing these forms
        manually is a time-consuming activity.
       RAD environments include support for
        screen generation including:
         Interactive form definition using drag and
          drop techniques;
         Form linking where the sequence of forms to
          be presented is specified;
         Form verification where allowed ranges in
          form fields is defined.

                                                    383
Visual Programming
   Scripting languages such as Visual
    Basic support visual programming
    where the prototype is developed by
    creating a user interface from
    standard items and associating
    components with these items
   A large library of components exists
    to support this type of development
   These may be tailored to suit the
    specific application requirements
                                           384
Problems with Visual Development

   Difficult to coordinate team-based
    development.
   No explicit system architecture.
   Complex dependencies between parts
    of the program can cause
    maintainability problems.




                                     385
Software Prototyping
       A prototype is an initial version of a
        system used to demonstrate concepts
        and try out design options.
       A prototype can be used in:
         The requirements engineering process
          to help with requirements elicitation
          and validation;
         In design processes to explore options
          and develop a UI design;
         In the testing process to run back-to-
          back tests.                           386
Benefits of Prototyping
   Improved system usability.
   A closer match to users‘ real needs.
   Improved design quality.
   Improved maintainability.
   Reduced development effort.




                                           387
Prototyping Process




                      388
Throw-Away Prototypes
    Prototypes should be discarded after
     development as they are not a good basis
     for a production system:
     It may be impossible to tune the system
        to meet non-functional requirements;
     Prototypes are normally undocumented;
     The prototype structure is usually
        degraded through rapid change;
     The prototype probably will not meet
        normal organisational quality standards.



                                               389
Software Reuse
   In most engineering disciplines, systems
    are designed by composing existing
    components that have been used in
    other systems.
   Software engineering has been more
    focused on original development but it is
    now recognised that to achieve better
    software, more quickly and at lower cost,
    we need to adopt a design process that
    is based on systematic software reuse.

                                           390
 Reuse-Based Software Engineering

  Application system reuse
   The whole of an application system may be
     reused either by incorporating it without
     change into other systems (COTS reuse) or
     by developing application families.
  Component reuse
   Components of an application from sub-
     systems to single objects may be reused.
  Object and function reuse
   Software components that implement a
     single well-defined object or function may be
     reused.
                                               391
 Reuse Benefits

Increased dependability        Reused software, that has been tried and tested in working systems,
                               should be m ore dependable than new software. The initial use of the
                               software reveals any design and implementation faults. These are then
                               fixed, thus reducing the number of failures when the software is reused.
Reduced process risk           If software exists, there is less uncertainty in the costs of reusing that
                               software than in the costs of development. T his is an important factor
                               for project management as it reduces the margin of error in project cost
                               estimation. This is particularly true when relatively large software
                               components such as sub-systems are reused.
Effective use of specialists   Instead of application specialists doing the same work on different
                               projects, these specialists can develop reusable software that
                               encapsulate their knowledge.




                                                                                                       392
    Reuse Benefits (cont’d)

Standards compliance      Some standards, such as user interface standards, can be
                          implemented as a set of standard reusable components. For
                          example, if menus in a user interfaces are implemented using
                          reusable components, all applications present the same menu
                          formats to users. The use of standard user interfaces improves
                          dependability as users are less likely to make mistakes when
                          presented with a familiar interface.
Accelerated development   Bringing a system to market as early as possible is o ften more
                          important than overall development costs. Reusing software can
                          speed up system production because both development and
                          validation time should be reduced.



                                                                                  393
    Reuse Problems 1

Increased maintenance   If the source code of a reused software system or component is n ot
costs                   available then maintenance costs may be increased as the reused
                        elements of the system may become increasingly incompatible with
                        system changes.
Lack of tool support    CASE toolsets may not support development with reuse. It may be
                        difficult or impossible to integrate these tools with a component
                        library system. T he software process assumed by these tools may not
                        take reuse into account.
Not-invented-here       Some software engineers sometimes prefer to re-write components as
syndrome                they believe that they can improve on the reusable component. This is
                        partly to do with trust and partly to do with the fact that writing
                        original software is s een as more challenging than reusing other
                        peopleÕs software.




                                                                                          394
    Reuse Problems 2

Creating and maintaining a     Populating a reusable component library and ensuring the software
component library              developers can use this library can be expensive. Our current techniques
                               for classifying, cataloguing and retrieving software components are
                               immature.
Finding, understanding and     Software components have to be discovered in a library, understood and,
adapting reusable components   sometimes, adapted to work in a n ew environment. Engineers must be
                               reasonably confident of finding a component in the library before they will
                               make routinely include a component search as part of their normal
                               development process.




                                                                                                395
Reuse Approaches

Design patterns    Generic abstractions that occur across applications are
                   represented as design patterns that show abstract and concrete
                   objects and interactions.
Component-based    Systems are developed by integrating components
development        (collections of objects) that conform to component-model
                   standards. This is covered in Chapter 19.
Application        Collections of abstract and concrete classes that can be
frameworks         adapted and extended to create application systems.
Legacy system      Legacy systems (see Chapter 2) that can be Ō  wrappedÕ b  y
wrapping           defining a set of interfaces and providing access to these
                   legacy systems through these interfaces.
Service-oriented   Systems are developed by linking shared services that may be
systems            externally provided.




                                                                                    396
Reuse Approaches (cont’d)

Application product     An application type is generalised around a common
lines                   architecture so that it can be adapted in different ways for
                        different customers.
COTS integration        Systems are developed by integrating existing application
                        systems.
Configurable vertical   A generic system is designed so that it can be configured to
applications            the needs of specific system customers.
Program libraries       Class and function libraries implementing commonly-used
                        abstractions are available for reuse.
Program generators      A generator system embeds knowledge of a particular types
                        of application and can generate systems or system fragments
                        in that domain.
Aspect-oriented         Shared components are woven into an application at different
software development    places when the program is compiled.



                                                                                       397
Concept Reuse
       When you reuse program or design components, you
        have to follow the design decisions made by the
        original developer of the component.
       This may limit the opportunities for reuse.
       However, a more abstract form of reuse is concept
        reuse when a particular approach is described in an
        implementation independent way and an
        implementation is then developed.
       The two main approaches to concept reuse are:
          Design patterns;
          Generative programming.




                                                         398
Design Patterns
   A design pattern is a way of reusing
    abstract knowledge about a problem and
    its solution.
   A pattern is a description of the problem
    and the essence of its solution.
   It should be sufficiently abstract to be
    reused in different settings.
   Patterns often rely on object
    characteristics such as inheritance and
    polymorphism.

                                           399
Generator-Based Reuse
   Program generators involve the reuse of
    standard patterns and algorithms.
   These are embedded in the generator and
    parameterised by user commands. A
    program is then automatically generated.
   Generator-based reuse is possible when
    domain abstractions and their mapping to
    executable code can be identified.
   A domain specific language is used to
    compose and control these abstractions.



                                               400
Types of Program Generator
   Types of program generator
       Application generators for business data
          processing;
       Parser and lexical analyser generators for
          language processing;
       Code generators in CASE tools.
   Generator-based reuse is very cost-effective but its
    applicability is limited to a relatively small number
    of application domains.
   It is easier for end-users to develop programs using
    generators compared to other component-based
    approaches to reuse.


                                                       401
    Aspect-Oriented Development

    Aspect-oriented development addresses a
     major software engineering problem - the
     separation of concerns.
    Concerns are often not simply associated with
     application functionality but are cross-cutting
     - e.g. all components may monitor their own
     operation, all components may have to
     maintain security, etc.
    Cross-cutting concerns are implemented as
     aspects and are dynamically woven into a
     program. The concern code is reuse and the
     new system is generated by the aspect
     weaver.                                        402
Application Frameworks
   Frameworks are a sub-system design
    made up of a collection of abstract
    and concrete classes and the
    interfaces between them.
   The sub-system is implemented by
    adding components to fill in parts of
    the design and by instantiating the
    abstract classes in the framework.
   Frameworks are moderately large
    entities that can be reused.
                                        403
Model-View Controller
   System infrastructure framework for
    GUI design.
   Allows for multiple presentations of
    an object and separate interactions
    with these presentations.
   MVC framework involves the
    instantiation of a number of patterns
    (as discussed earlier under concept
    reuse).

                                            404
Application System Reuse

    Involves the reuse of entire
     application systems either by
     configuring a system for an
     environment or by integrating
     two or more systems to create a
     new application.
    Two approaches covered here:
     COTS product integration;
     Product line development.
                                   405
COTS Product Reuse
   COTS - Commercial Off-The-Shelf
    systems.
   COTS systems are usually complete
    application systems that offer an API
    (Application Programming Interface).
   Building large systems by integrating
    COTS systems is now a viable
    development strategy for some types of
    system such as E-commerce systems.
   The key benefit is faster application
    development and, usually, lower
    development costs.

                                         406
COTS Products Reused
  On the client, standard e-mail and web
   browsing programs are used.
  On the server, an e-commerce platform has
   to be integrated with an existing ordering
   system.
   This involves writing an adaptor so that
      they can exchange data.
   An e-mail system is also integrated to
      generate e-mail for clients. This also
      requires an adaptor to receive data from
      the ordering and invoicing system.

                                             407
COTS System Integration
Problems
   Lack of control over functionality and performance
      COTS systems may be less effective than they
       appear
   Problems with COTS system inter-operability
      Different COTS systems may make different
       assumptions that means integration is difficult
   No control over system evolution
      COTS vendors not system users control
       evolution
   Support from COTS vendors
      COTS vendors may not offer support over the
       lifetime of the product

                                                  408
Software Product Lines
       Software product lines or application
        families are applications with generic
        functionality that can be adapted and
        configured for use in a specific context.
       Adaptation may involve:
         Component and system configuration;
         Adding new components to the system;
         Selecting from a library of existing
          components;
         Modifying components to meet new
          requirements.
                                                    409
Product Line Architectures

   Architectures must be structured in
    such a way to separate different sub-
    systems and to allow them to be
    modified.
   The architecture should also separate
    entities and their descriptions and the
    higher levels in the system access
    entities through descriptions rather
    than directly.

                                         410
ERP Systems
   An Enterprise Resource Planning (ERP)
    system is a generic system that supports
    common business processes such as
    ordering and invoicing, manufacturing,
    etc.
   These are very widely used in large
    companies - they represent probably the
    most common form of software reuse.
   The generic core is adapted by including
    modules and by incorporating knowledge
    of business processes and rules.

                                          411
Component-Based Development

   Component-based software
    engineering (CBSE) is an approach to
    software development that relies on
    software reuse.
   It emerged from the failure of object-
    oriented development to support
    effective reuse. Single object classes
    are too detailed and specific.
   Components are more abstract than
    object classes and can be considered
    to be stand-alone service providers.
                                         412
Components
 Components provide a service without
  regard to where the component is
  executing or its programming language
    A component is an independent
     executable entity that can be made up
     of one or more executable objects;
    The component interface is published
     and all interactions are through the
     published interface;



                                         413
Component Definitions
       Councill and Heinmann:
         A software component is a software element
          that conforms to a component model and can
          be independently deployed and composed
          without modification according to a
          composition standard.
       Szyperski:
         A software component is a unit of
          composition with contractually specified
          interfaces and explicit context dependencies
          only. A software component can be deployed
          independently and is subject to composition
          by third-parties.

                                                     414
Components and Objects
   Components are deployable entities.
   Components do not define types.
   Component implementations are
    opaque.
   Components are language-
    independent.
   Components are standardised.



                                          415
Component Models
       A component model is a definition of
        standards for component implementation,
        documentation and deployment.
       Examples of component models
         EJB model (Enterprise Java Beans)
         COM+ model (.NET model)
         Corba Component Model
       The component model specifies how
        interfaces should be defined and the
        elements that should be included in an
        interface definition.
                                                  416
CBSE Essentials
   Independent components specified by
    their interfaces.
   Component standards to facilitate
    component integration.
   Middleware that provides support for
    component inter-operability.
   A development process that is geared
    to reuse.


                                       417
CBSE and Design Principles

       Apart from the benefits of reuse,
        CBSE is based on sound software
        engineering design principles:
         Components are independent so do
          not interfere with each other;
         Component implementations are
          hidden;
         Communication is through well-
          defined interfaces;
         Component platforms are shared and
          reduce development costs.
                                            418
CBSE Problems
   Component trustworthiness - how can a
    component with no available source code be
    trusted?
   Component certification - who will certify
    the quality of components?
   Emergent property prediction - how can the
    emergent properties of component
    compositions be predicted?
   Requirements trade-offs - how do we do
    trade-off analysis between the features of
    one component and another?

                                            419
Component Development for Reuse

   Components developed for a specific
    application usually have to be
    generalised to make them reusable.
   A component is most likely to be
    reusable if it associated with a stable
    domain abstraction (business object).
   For example, in a hospital stable
    domain abstractions are associated
    with the fundamental purpose -
    nurses, patients, treatments, etc.

                                          420
Component Development for Reuse

 Components for reuse may be specially constructed
  by generalising existing components.
 Component reusability
    Should reflect stable domain abstractions;
    Should hide state representation;
    Should be as independent as possible;
    Should publish exceptions through the
      component interface.
 There is a trade-off between reusability and usability
    The more general the interface, the greater
      the reusability but it is then more complex
      and hence less usable.

                                                      421
Changes for Reusability
   Remove application-specific methods.
   Change names to make them general.
   Add methods to broaden coverage.
   Make exception handling consistent.
   Add a configuration interface for
    component adaptation.
   Integrate required components to
    reduce dependencies.

                                      422
Legacy system components

   Existing legacy systems that fulfil a
    useful business function can be re-
    packaged as components for reuse.
   This involves writing a wrapper
    component that implements provides
    and requires interfaces then accesses
    the legacy system.
   Although costly, this can be much
    less expensive than rewriting the
    legacy system.
                                        423
Reusable components
   The development cost of reusable
    components may be higher than the
    cost of specific equivalents. This extra
    reusability enhancement cost should
    be an organization rather than a
    project cost.
   Generic components may be less
    space-efficient and may have longer
    execution times than their specific
    equivalents.
                                          424
The CBSE process
       When reusing components, it is
        essential to make trade-offs between
        ideal requirements and the services
        actually provided by available
        components.
       This involves:
         Developing outline requirements;
         Searching for components then
          modifying requirements according to
          available functionality.
         Searching again to find if there are
          better components that meet the      425
          revised requirements.
The CBSE process




                   426
Component Composition
   The process of assembling
    components to create a system.
   Composition involves integrating
    components with each other and with
    the component infrastructure.
   Normally you have to write ‗glue code‘
    to integrate components.



                                        427
Types of composition
   Sequential composition where the composed
    components are executed in sequence. This
    involves composing the provides interfaces
    of each component.
   Hierarchical composition where one
    component calls on the services of another.
    The provides interface of one component is
    composed with the requires interface of
    another.
   Additive composition where the interfaces of
    two components are put together to create
    a new component.

                                              428
Composition trade-offs
       When composing components, you may find
        conflicts between functional and non-functional
        requirements, and conflicts between the need
        for rapid delivery and system evolution.
       You need to make decisions such as:
         What composition of components is effective for
          delivering the functional requirements?
         What composition of components allows for
          future change?
         What will be the emergent properties of the
          composed system?

                                                      429
Chapter 7:
Verification vs.
Validation




                   430
Verification vs Validation

   Verification:
     "Are we building the product right‖.
   The software should conform to its
    specification.
   Validation:
      "Are we building the right product‖.
   The software should do what the user
    really requires.


                                         431
The V & V process
       Is a whole life-cycle process - V & V
        must be
        applied at each stage in the software
        process.
       Has two principal objectives
         The discovery of defects in a system;
         The assessment of whether or not the
          system is useful and useable in an
          operational situation.

                                              432
V & V goals
   Verification and validation should
    establish confidence that the software
    is fit for purpose.
   This does NOT mean completely free
    of defects.
   Rather, it must be good enough for
    its intended use and the type of use
    will determine the degree of
    confidence that is needed.

                                        433
Static and dynamic verification

       Software inspections. Concerned with
        analysis of the static system representation
        to discover problems (static verification)
         May be supplement by tool-based document
          and code analysis
       Software testing. Concerned with exercising
        and observing product behaviour (dynamic
        verification)
         The system is executed with test data and its
          operational behaviour is observed


                                                     434
Chapter 8:
Testing and
Debugging




              435
Testing and Debugging
   Defect testing and debugging are distinct
    processes.
   Verification and validation is concerned with
    establishing the existence of defects in a
    program.
   Debugging is concerned with locating and
    repairing these errors.
   Debugging involves formulating a
    hypothesis
    about program behaviour then testing these
    hypotheses to find the system error.

                                               436
Software Testing


Testing is the process of exercising a
program with the specific intent of finding
errors prior to delivery to the end user.




                                              437
Program testing
   Can reveal the presence of errors
    NOT their absence.
   The only validation technique for non-
    functional requirements as the
    software has to be executed to see
    how it behaves.
   Should be used in conjunction with
    static verification to provide full V&V
    coverage.

                                         438
What Testing Shows

1.   errors
2.   requirements conformance
3.   performance
4.   an indication of quality



                                439
Who Tests the Software?

       Developer
         Understands the system
         but, will test ―gently‖
         and, is driven by ―delivery‖
       independent tester
         Must learn about the system,
         but, will attempt to break it
         and, is driven by quality

                                          440
    Testability

    Operability—it operates cleanly
    Observability—the results of each test case are
     readily observed
    Controllability—the degree to which testing can
     be automated and optimized
    Decomposability—testing can be targeted
    Simplicity—reduce complex architecture and
     logic to simplify tests
    Stability—few changes are requested during
     testing
    Understandability—of the design

                                                441
What is a “Good” Test?


   A good test has a high probability of
    finding an error
   A good test is not redundant.
   A good test should be ―best of breed‖
   A good test should be neither too
    simple nor too complex



                                        442
Testing Strategies
  We begin by ‗testing-in-the-small‘ and move
   toward ‗testing-in-the-large‘
  For conventional software
   The module (component) is our initial focus
   Integration of modules follows
  For OO software
   our focus when ―testing in the small‖
     changes from an individual module (the
     conventional view) to an OO class that
     encompasses attributes and operations and
     implies communication and collaboration
                                            443
    Strategic Issues
    State testing objectives explicitly.
    Understand the users of the software and develop a
     profile for each user category.
    Develop a testing plan that emphasizes ―rapid cycle
     testing.‖
    Build ―robust‖ software that is designed to test itself
    Use effective formal technical reviews as a filter
     prior to testing
    Conduct formal technical reviews to assess the test
     strategy and test cases themselves.
    Develop a continuous improvement approach for the
     testing process.
                                                       444
Testing approaches
       Architectural validation
         Top-down integration testing is better at
          discovering errors in the system architecture.
       System demonstration
         Top-down integration testing allows a limited
          demonstration at an early stage in the
          development.
       Test implementation
         Often easier with bottom-up integration
          testing.
       Test observation
         Problems with both approaches. Extra code
          may be required to observe tests.

                                                      445
    Testing process goals
     Validation testing
        To demonstrate to the developer and the system
         customer that the software meets its requirements;
        A successful test is one that shows that a
         requirements has been properly implemented.
     Defect testing
        The goal of defect testing is to discover defects in
         programs
        To discover faults or defects in the software where its
         behaviour is incorrect or not in conformance with its
         specification;
        A successful test is a test that makes the system
         perform incorrectly and so exposes a defect in the
         system.
        Tests show the presence not the absence of defects
                                                             446
Software Testing
       Component testing
         Interface Testing
       System testing
         Integration Testing
         Release Testing
         Performance Testing
       Test case design
         Requirements-based Testing
         Partitioning Testing
         Structural Testing
         Path Testing
       Test automation

                                       447
Testing Process
       Component testing
         Testing of individual program components;
         Usually the responsibility of the component
          developer (except sometimes for critical
          systems);
         Tests are derived from the developer‘s
          experience.
       System testing
         Testing of groups of components integrated to
          create a system or sub-system;
         The responsibility of an independent testing
          team;
         Tests are based on a system specification.


                                                        448
Component Testing
 Component or unit testing is the process of
  testing individual components in isolation.
 It is a defect testing process.
 Components may be:
  Individual functions or methods within
     an object;
  Object classes with several attributes
     and methods;
  Composite components with defined
     interfaces used to access their
     functionality.                        449
Interface Testing
   Objectives are to detect faults due to
    interface errors or invalid
    assumptions about interfaces.
   Particularly important for object-
    oriented development as objects are
    defined by their interfaces.




                                         450
System Testing
 Involves integrating components to create
  a system or sub-system.
 May involve testing an increment to be
  delivered to the customer.
 Two phases:
  Integration testing - the test team have
     access to the system source code. The
     system is tested as components are
     integrated.
  Release testing - the test team test the
     complete system to be delivered as a
     black-box.
                                        451
Integration Testing
  Involves building a system from its
   components and testing it for problems that
   arise from component interactions.
  Top-down integration
   Develop the skeleton of the system and
      populate it with components.
  Bottom-up integration
   Integrate infrastructure components then
      add functional components.
  To simplify error localisation, systems
   should be incrementally integrated.

                                            452
Incremental Integration Testing


                                                 A             T1

                                            T1
                          A
                     T1                                        T2
   A                                             B
                                            T2

                     T2   B                                    T3

                                            T3
   B                                             C
                     T3                                        T4
                          C
                                            T4

                                                 D             T5


        est
       T sequence1             est
                              T sequence2        est
                                                 T sequence3

                                                                    453
Release Testing
  The process of testing a release of a system
   that will be distributed to customers.
  Primary goal is to increase the supplier‘s
   confidence that the system meets its
   requirements.
  Release testing is usually black-box or
   functional testing
   Based on the system specification only;
   Testers do not have knowledge of the
      system implementation.



                                             454
Performance Testing
   Part of release testing may involve
    testing the emergent properties of a
    system, such as performance and
    reliability.
   Performance tests usually involve
    planning a series of tests where the
    load is steadily increased until the
    system performance becomes
    unacceptable.

                                           455
Test Case Design
       Involves designing the test cases
        (inputs and outputs) used to test the
        system.
       The goal of test case design is to
        create a set of tests that are effective
        in validation and defect testing.
       Design approaches:
         Requirements-based testing;
         Partition testing;
         Structural testing.

                                               456
Requirements-Based Testing

   A general principle of requirements
    engineering is that requirements
    should be testable.
   Requirements-based testing is a
    validation testing technique where
    you consider each requirement and
    derive a set of tests for that
    requirement.


                                          457
Partition Testing
   Input data and output results often
    fall into different classes where all
    members of a class are related.
   Each of these classes is an
    equivalence partition or domain
    where the program behaves in an
    equivalent way for each class
    member.
   Test cases should be chosen from
    each partition.
                                            458
Structural Testing
   Sometime called white-box testing.
   Derivation of test cases according to
    program structure. Knowledge of the
    program is used to identify additional
    test cases.
   Objective is to exercise all program
    statements (not all path
    combinations).


                                         459
Path Testing
   The objective of path testing is to
    ensure that the set of test cases is
    such that each path through the
    program is executed at least once.
   The starting point for path testing is a
    program flow graph that shows nodes
    representing program decisions and
    arcs representing the flow of control.
   Statements with conditions are
    therefore nodes in the flow graph.

                                          460
Binary Search Flow Graph




                           461
Independent Paths
   1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14
   1, 2, 3, 4, 5, 14
   1, 2, 3, 4, 5, 6, 7, 11, 12, 5, …
   1, 2, 3, 4, 6, 7, 2, 11, 13, 5, …
   Test cases should be derived so that
    all of these paths are executed
   A dynamic program analyser may be
    used to check that paths have been
    executed
                                           462
Testing Strategies (cont’d)
       Strategic Approach
             Conventional Software
                   Unit Testing
                   Integration Testing
                •       Top-Down Integration
                •       Bottom-Up Integration
                •       Regression Testing
                •       Smoke Testing
             Object-Oriented Software
                   Unit Testing
                   Integration Testing
       Validation Testing
             Test Criteria
             Configuration Review
             Alpha and Beta Testing
       System Testing
             Recovery Testing
             Security Testing
             Stress Testing
             Performance Testing
       Debugging
                                                463
Unit Testing

   Focuses on the smallest unit of
    software design – the software
    component or module.
   Using the component-level design
    description as a guide, control paths
    are tested to uncover errors within
    the boundary of the module.
   Focuses on the inter processing logic
    and data structures .
   Can be conducted in parallel for
    multiple components.
                                            464
Unit Testing

    module
     to be
    tested
                interface
                local data structures
                boundary conditions
                independent paths
                error handling paths



             test cases
                                        465
Unit Testing
       Normally considered as an adjunct to the
        coding step.
       Because a component is not a stand-alone
        program, driver and/or stub software must
        be developed for each unit test.
         Driver: a main program that accepts test
          case data, passes such data to the
          component to be tested, and prints relevant
          results.
         Stub: serves to replace modules that are
          called by the component to be tested.

                                                        466
Unit Test Environment

                 driver
                             interface
                             local data structures

      Module                 boundary conditions
                             independent paths
                             error handling paths

   stub   stub


                          test cases

          RESULTS                                    467
Testing Strategies
      “Big Bang” approach
         All components are combined in advance.
         The entire program is tested as a whole.
         Chaos usually results.
           A set of errors is encountered.
           Correction is difficult because isolation of
            causes is complicated.
           Once these errors are corrected, new ones
            appear and the process continues in a
            seemingly endless loop.
      an incremental integration strategy
         The program is constructed and tested in
          small increments.
         Errors are easier to isolate and correct.
         Interfaces are more likely to be tested
          completely.
         A systematic test approach may be appolied.
                                                           468
Integration Testing Strategies

       Top-down Integration Testing
         Depth-first integration
         Breadth-first integration
       Bottom-up Integration
       Sandwich Testing
       Regression Testing
       Smoke Testing



                                       469
Top Down Integration

                       A
                              top module is tested with
                              stubs


               B       F       G

                   stubs are replaced one at
                   a time, "depth first"
       C
                   as new modules are integrated,
                   some subset of tests is re-run
   D       E



                                                          470
Bottom-Up Integration
                      A




               B       F      G

                   drivers are replaced one at a
                   time, "depth first"
       C

                   worker modules are grouped into
                   builds and integrated
   D       E


   cluster
                                                     471
Sandwich Testing
                      A
                              Top modules are
                              tested with stubs

               B       F      G



       C

                   Worker modules are grouped into
                   builds and integrated
   D       E


   cluster
                                                     472
Regression Testing
      Each time a new module is added as part of integration
       testing, the software changes.
          New data flow paths are established,
          New I/O may occur, and
          New control logic is invoked.
      These changes may cause problems with functions that
       previously worked flawlessly.
      Regression testing is the re-execution of some subset of
       tests that have already been conducted to ensure that
       changes are not propagated unintended side effects.
      Three classes of test cases
    1.     A representative sample of tests that will exercise all
           software functions.
    2.     Additional tests that focus on software functions that
           are likely to be affected by the change.
    3.     Tests that focus on the software components that have
           been changed.

                                                                473
    Smoke Testing
     A common approach for creating ―daily builds‖ for product
      software
     Smoke testing steps:
        Software components that have been translated into
         code are integrated into a ―build.‖
              A build includes all data files, libraries, reusable modules,
               and engineered components that are required to
               implement one or more product functions.
           A series of tests is designed to expose errors that will
            keep the build from properly performing its function.
              The intent should be to uncover ―show stopper‖ errors
               that have the highest likelihood of throwing the software
               project behind schedule.
           The build is integrated with other builds and the entire
            product (in its current form) is smoke tested daily.
              The integration approach may be top down or bottom up.
                                                                     474
Object-Oriented Testing
   Begins by evaluating the correctness and
    consistency of the OOA and OOD models.
   Testing strategy changes.
      The concept of the ‗unit‘ broadens due to
       encapsulation.
      Integration focuses on classes and their
       execution across a ‗thread‘ or in the context
       of a usage scenario.
      Validation uses conventional black box
       methods
   Test case design draws on conventional
    methods, but also encompasses special features.
                                                  475
    OOT Strategy
  Class testing is the equivalent of unit testing.
   Operations within the class are tested.
   The state behavior of the class is examined.
  Integration applied three different strategies.
   thread-based testing: Integrates the set of
      classes required to respond to one input or
      event.
   use-based testing: Integrates the set of
      classes required to respond to one use case.
   cluster testing: Integrates the set of classes
      required to demonstrate one collaboration.
                                                476
High Order Testing
       Validation testing: Focus is on software requirements.
          Alpha/Beta testing: Focus is on customer usage.
       System testing: Focus is on system integration.
          Recovery testing: Forces the software to fail in a
           variety of ways and verifies that recovery is properly
           performed.
          Security testing: Verifies that protection mechanisms
           built into a system will, in fact, protect it from
           improper penetration.
          Stress testing: Executes a system in a manner that
           demands resources in abnormal quantity, frequency, or
           volume.
          Performance Testing: Test the run-time performance of
           software within the context of an integrated system.


                                                             477
Stress Testing
   Exercises the system beyond its maximum
    design load. Stressing the system often
    causes defects to come to light.
   Stressing the system test failure behaviour..
    Systems should not fail catastrophically.
    Stress testing checks for unacceptable loss
    of service or data.
   Stress testing is particularly relevant to
    distributed systems that can exhibit severe
    degradation as a network becomes
    overloaded.

                                               478
Testing vs. Debugging

   Software Testing: an action that can
    be systematically planned and
    specified.
   Debugging: Occurs as a consequence
    of successful testing.
   When a test case uncovers an error,
    debugging is an action that results in
    the removal of the error.


                                         479
    Debugging
       Why is debugging so difficult? - a few characteristics of bugs:
         The symptom and the cause may be geographically
          remote.
         The symptom may disappear (temporarily) when another
          error is corrected.
         The symptom may actually be caused by nonerrors (e.g.,
          round-off inaccuracies).
         The symptom may be caused by human error that is not
          easily traced.
         The symptom may be a result of timing problems, rather
          than processing problems.
         It may be difficult to accurately reproduce input
          conditions
         The symptom may be intermittent. This is particularly
          common in embedded systems that couple hardware and
          software inextricably.
         The symptom may be due to causes that are distributed
          across a number of tasks running on different processors.
                                                                  480
 Symptoms & Causes
                  symptom and cause may be
                  geographically separated

                  symptom may disappear when
                  another problem is fixed

                  cause may be due to a
                  combination of non-errors

                  cause may be due to a system
                  or compiler error

symptom           cause may be due to
                  assumptions that everyone
          cause   believes

                  symptom may be intermittent
                                                 481
Debugging Tactics
       Brute force category of debugging:
         probably the most common and least efficient
          method for isolating the cause of a software error.
         Apply brute force debugging methods when all else
          fails.
         Using a ― let the computer find the error ‖ philosophy,
          memory dumps are taken, run-time traces are
          invoked, and the program is loaded with output
          statements.
         We hope that somewhere in the morass of
          information that is produced we will find a clue that
          can lead us to the cause of an error.
         Although the mass of information produced may
          ultimately lead to success, it more frequently leads to
          wasted effort and time.
         Thought must be expended first!                    482
Debugging Tactics (cont’d)

       Backtracking:
         is a fairly common debugging approach that
          can be used successfully in small programs.
         Beginning at the site where a symptom has
          been uncovered, the source code is traced
          backward (manually) until the site of the
          cause is found.
         Unfortunately, as the number of source lines
          increases, the number of potential backward
          paths may become unmanageably large.



                                                     483
Debugging Tactics (cont’d)
       Cause elimination:
         is manifested by induction or deduction and
          introduces the concept of binary partitioning.
         Data related to the error occurrence are
          organized to isolate potential causes.
         A ― cause hypothesis ‖ is devised, and the
          aforementioned data are used to prove or
          disprove the hypothesis.
         Alternatively, a list of all possible causes is
          developed, and tests are conducted to eliminate
          each.
         If initial tests indicate that a particular cause
          hypothesis shows promise, data are refined in
          an attempt to isolate the bug.
                                                        484
Correcting the Error
      The correction of a bug can introduce other errors and therefore do
       more harm than good.
      3 questions that should be asked before making the ―correction.‖
    1.     Is the cause of the bug reproduced in another part of the program?
              A program error is caused by an erroneous pattern of logic that
               may be reproduced elsewhere.
              Explicit consideration of the logical pattern may result in the
               discovery of other errors.
    2.     What ―next bug‖ might be introduced by the fix that I am about to
           make?
              Before the correction is made, the source code (or, better, the
               design) should be evaluated to assess coupling of logic and data
               structures.
              If the correction is to be made in a highly coupled section of the
               program, special care must be taken when any change is made.
    3.     What could we have done to prevent this bug in the first place?
              This question is the first step toward establishing a statistical
               software quality assurance approach.
              If we correct the process as well as the product, the bug will be
               removed from the current program and may be eliminated from
               all future programs.
                                                                           485
Chapter 9:
Testing Techniques

   White-Box Testing
   Black-Box Testing
 Object-Oriented Testing

                           486
White-Box Testing Techniques

        White-Box (Glass-Box) Testing
             Basis Path Testing
               Flow Graph Notation
               Independent Program Paths: Cyclomatic
                Complexity -V(G)
               Deriving Test Cases: V(G) cases
               Graph Matrices
             Control Structure Testing
               Condition Testing
               Data Flow Testing
               Loop Testing

                                                    487
White-Box Testing


... our goal is to ensure that all
statements and conditions have
been executed at least once ...



                                     488
Cyclomatic Complexity: Flow Chart




                              489
Cyclomatic Complexity: Flow Graph




                               490
    Cyclomatic Complexity: V(G)
    V(G) is computed in one of three ways:
    1.  The number of regions corresponds to the
        cyclomatic complexity.
      (ex) V(G) = 4, ∵ Flow graph has 4 regions.
    2. Cyclomatic complexity V(G), for a flow graph G,
        is defined as V(G) = E – N + 2,
              where E is the number of flow graph edges,
              and N is the number of flow graph nodes.
      (ex) V(G) = 11 edges – 9 nodes + 2 = 4
    3. Cyclomatic complexity V(G), for a flow graph G,
        is defined as V(G) = P + 1,
              where P is the number of predicate nodes
              contained in the flow graph G.
        (ex) V(G) = 3 predicate nodes + 1 = 4.
              predicate nodes: (1), (2,3), (6)
                                                     491
Deriving Test Cases
1.   Using the design or code as a
     foundation, draw a corresponding
     flow graph.
2.   Determine the cyclomatic complexity
     of the resultant flow graph.
3.   Determine a basis set of linearly
     independent paths.
4.   Prepare test cases that will force
     execution of each path in the basis
     set.
                                       492
Cyclomatic Complexity: Flow Chart

                        path 1 :
                           1-11
                        path 2 :
                           1-2-3-4-5-10-1-11
                        path 3 :
                           1-2-3-6-8-9-10-1-11
                        path 4 :
                           1-2-3-6-7-9-10-1-11
                        Path 1-2-3-4-5-10-1-2-3-
                         6-8-9-10-11 is not
                         considered to be an
                         independent path.
                           Because it is simply a
                            combination of already
                            specified paths and
                            does not traverse any
                            new edges.

                                              493
Cyclomatic Complexity: V(G)

   A number of industry studies have indicated
   that the higher V(G), the higher the probability
   or errors.



 modules




                               V(G)

           modules in this range are
           more error prone
                                                      494
    Graph Matrices
       a square matrix whose size is equal to the number of nodes on the
        flow graph.
       Each row and column corresponds to an identified node, and
        matrix entries correspond to connections (an edge) between nodes.
       Each node on the flow graph is identified by numbers, while each
        edge is identified by letters.
       To this point, the graph matrix is nothing more than a tabular
        representation of a flow graph.
       By adding a link weight to each matrix entry, the graph matrix can
        become a powerful tool for evaluating program control structure.
       The link weight provides additional information about control flow.
       In its simplest form, the link weight is 1 (a connection exists) or O
        (a connection does not exist).
       But link weights can be assigned other, more interesting properties:
            The probability that a link (edge) will be executed.
            The processing time expended during traversal of a link.
            The memory required during traversal of a link.
            The resources required during traversal of a link.

                                                                       495
    Graph Matrices - Example


         1
                              Connected to Node
             a                1    2      3      4   5

         3                1               a

             b
     e                N   2

5    f   4        d   o
                          3        d             d
                      d
             c
    g                 e   4        c                 f
         2
                          5        g      e

     Flow graph                   Graph matrix           496
Control Structure Testing

       Condition testing: a test case design
        method that exercises the logical conditions
        contained in a program module
         Simple condition
         Compound condition
       Data flow testing: selects test paths of a
        program according to the locations of
        definitions and uses of variables in the
        program
       Loop Testing: a white-box testing that
        focuses exclusively on the validity of loop
        construct.

                                                      497
Loop Testing




Simple
 loop
         Nested
         Loops

                  Concatenated
                     Loops       Unstructured
                                                498
                                    Loops
Loop Testing: Simple Loops

  Minimum conditions—Simple Loops
    1. skip the loop entirely
    2. only one pass through the loop
    3. two passes through the loop
    4. m passes through the loop m < n
    5. (n-1), n, and (n+1) passes through
    the loop
    where n is the maximum number
    of allowable passes
                                            499
Loop Testing: Nested Loops

 Nested Loops
      Start at the innermost loop. Set all outer loops to their
      minimum iteration parameter values.
     Test the min+1, typical, max-1 and max for the
     innermost loop, while holding the outer loops at their
     minimum values.
     Move out one loop and set it up as in step 2, holding all
     other loops at typical values. Continue this step until
     the outermost loop has been tested.
 Concatenated Loops
      If the loops are independent of one another
         then treat each as a simple loop
         else* treat as nested loops
      endif*
      for example, the final loop counter value of loop 1 is
      used to initialize loop 2.                                  500
Black-Box Testing
   How is functional validity tested?
   How is system behavior and performance
    tested?
   What classes of input will make good test cases?
   Is the system particularly sensitive to certain
    input values?
   How are the boundaries of a data class isolated?
   What data rates and data volume can the
    system tolerate?
   What effect will specific combinations of data
    have on system operation?

                                               501
Black-Box Testing Techniques

       Black-Box (Behavioral) Testing
         Graph-Based Testing Methods
         Equivalence Partitioning
         Boundary Value Analysis
         Comparison Testing
         Orthogonal Array Testing




                                         502
Graph-Based Methods
       The first step is to understand the objects
        that are modeled in software and the
        relationships that connect these objects.
         Create a graph of important objects and their
          relationships.
         ―Object‖ encompasses data objects,
          traditional components (modules), and
          object-oriented elements of computer
          software.
       The next step is to define a series of tests
        that verity ―all objects have the expected
        relationship to one another.‖
         Devise a series of tests that will cover the
          graph so that each object and relationship is
          exercised and errors are uncovered.
                                                       503
Graph-Based Methods (cont’d)

       Graph includes:
         Nodes: represent objects
         Links: represent the relationships
          between objects.
         Node weights: describe the properties of
          a node. e.g., a specific data value
         Link weights: describe some
          characteristic of a link.



                                                504
    Graph-Based Methods (cont’d)
Object # l = newFile (menu selection)
                                          object              Directed link                    object
Object #2 = documentWindow                  #1                (link weight)                      #2
Object #3 = documentText
                                                                                               Node weight
                                          Undirected link                                        (value
A menu select on newFile generates a                                                                )
                                                                              Parallel links
document window. The node weight of                               object
documentWindow provides a list of the                               #
                                                                    3
window attributes that are to be
expected when the window is                                         (a)

generated.
The link weight indicates that the         new           menu select generates            document
window must be generated in less than       file       (generation time  1.0 sec)         window

1.0 second.
                                                                   allows editing
An undirected link establishes a        is represented as                       of             Attributes:
symmetric relationship between the                                             contains
newFile menu selection and                                      document                       background color: white
                                                                                               text color: default color
documentText.                                                      tex
                                                                     t                                      or preferences
Parallel links indicate relationships
                                                                    (b)                                         505
between documentWindow and
documentText.
Equivalence Partitioning
   Input data and output results often
    fall into different classes where all
    members of a class are related.
   Each of these classes is an
    equivalence partition or domain
    where the program behaves in an
    equivalent way for each class
    member.
   Test cases should be chosen from
    each partition.
                                            506
Equivalence Classes (cont’d)

  Valid data
      user supplied commands
      responses to system prompts
      file names
      computational data
         physical parameters
         bounding values
         initiation values
      output data formatting
      responses to error messages
      graphical data (e.g., mouse picks)

   Invalid data
       data outside bounds of the program
       physically impossible data
      proper value supplied in wrong place
                                             507
Equivalence Classes (cont’d)
    Equivalence classes may be defined
     according to the following guidelines.
    1.   If an input condition specifies a range, one
         valid and two invalid equivalence classes are
         defined.
    2.   If an input condition requires a specific value,
         one valid and two invalid equivalence classes
         are denned.
    3.   If an input condition specifies a member of a
         set, one valid and one invalid equivalence
         class are denned.
    4.   If an input condition is Boolean, one valid and
         one invalid class are defined.

                                                       508
Equivalence partitions




      Equivalence Partitions
                               509
    Boundary Value Analysis
       A greater number of errors occurs at the
        boundaries of the input domain rather than in
        the ―center.‖
       Boundary value analysis (BVA) leads to a
        selection of test cases that exercise bounding
        values.
       BVA is a test case design technique that
        complements equivalence partitioning.
         Rather than selecting any element of an
          equivalence class, BVA leads to the selection of
          test cases at the ―edges‖ of the class.
         Rather than focusing solely on input conditions,
          BVA derives test cases from the output domain
          as well.                                      510
Boundary Value Analysis (cont’d)

      Guidelines for BVA are similar in many respects to those
       provided for equivalence partitioning.
    1.    If an input condition specifies a range bounded by
          values a and b, test cases should be designed with
          values a and b as well as just above and just below a
          and b.
    2.    If an input condition specifies a number of values,
          test cases should be developed that exercise the
          minimum and maximum numbers. Values just above
          and below minimum and maximum are also tested.
    3.    Apply guidelines 1 and 2 to output conditions. Test
          cases should be designed to create an output report
          that produces the maximum (and minimum)
          allowable number of entries.
    4.    If internal program data structures have prescribed
          boundaries (e.g., an array has a defined limit of 100
          entries), be certain to design a test case to exercise
          the data structure at its boundary.
                                                            511
Boundary Values Example



                    Boundary
                     Values




                         512
Comparison Testing
       Used only in situations in which the
        reliability of software is absolutely critical
        (e.g., human-rated systems)
         Separate software engineering teams
          develop independent versions of an
          application using the same specification
          Each version can be tested with the
          same test data to ensure that all provide
          identical output
         Then all versions are executed in parallel
          with real-time comparison of results to
          ensure consistency                       513
Orthogonal Array Testing

   Used when the number of input
    parameters is small and the values that
    each of the parameters may take are
    clearly bounded


                  Z                          Z

         Y                              Y
                       X                            X
             One input item at a time       L9 orthogonal array

                                                                  514
Orthogonal Array Testing (cont’d)

   Can be applied when the      L9 Orthogonal Array
    input domain is relatively
    small but too large to        Test Case
                                               Test Parameters

    accommodate exhaustive                  P1    P2    P3     P4

    testing.                          1      1     1     1     1

   Example: 4 parameters, each       2      1     2     2     2

    takes 3 discrete values           3      1     3     3     3

      Exhaustive testing cases:      4      2     1     2     3

       34 = 81 cases                  5      2     2     3     1


      L9 orthogonal array:           6      2     3     1     2


       provides good test             7      3     1     3     2


       coverage with fewer test       8      3     2     1     3

       cases.                         9      3     3     2     1

                                                                    515
Object-Oriented Testing
        Methods
                Test Case Design
Applicability of Conventional Test Case Design
                    Methods
              Fault-Based Testing
        Test Cases and Test Hierarchy
            Scenario-Based Testing
       Testing Surface/Deep Structure
                                                 516
 OOT: Test Case Design
Berard proposes the following approach:
1.    Each test case should be uniquely identified and should
      be explicitly associated with the class to be tested,
2.    The purpose of the test should be stated,
3.    A list of testing steps should be developed for each test
      and should contain:
   1.     a list of specified states for the object that is to be
          tested
   2.     a list of messages and operations that will be
          exercised as a consequence of the test
   3.     a list of exceptions that may occur as the object is
          tested
   4.     a list of external conditions
          (i.e., changes in the environment external to the
          software that must exist in order to properly conduct
          the test)
   5.     supplementary information that will aid in
          understanding or implementing the test.                517
Testing Methods
     Fault-based testing
         The tester looks for plausible faults (i.e., aspects
         of the implementation of the system that may
         result in defects). To determine whether these
         faults exist, test cases are designed to exercise
         the design or code.
     Class Testing and the Class Hierarchy
        Inheritance does not obviate the need for
         thorough testing of all derived classes. In fact, it
         can actually complicate the testing process.
     Scenario-Based Test Design
        Scenario-based testing concentrates on what the
         user does, not what the product does. This means
         capturing the tasks (via use-cases) that the user
         has to perform, then applying them and their        518

         variants as tests.
OOT Methods at the Class Level

       Random testing
            identify operations applicable to a class
            define constraints on their use
            identify a minimum test sequence
              an operation sequence that defines the
               minimum life history of the class (object)
            generate a variety of random (but valid)
             test sequences
              exercise other (more complex) class
               instance life histories

                                                        519
OOT Methods at the Class Level

        Partition Testing
        reduces the number of test cases required to
         test a class in much the same way as
         equivalence partitioning for conventional
         software
        state-based partitioning
           categorize and test operations based on
            their ability to change the state of a class
        attribute-based partitioning
           categorize and test operations based on
            the attributes that they use
        category-based partitioning
           categorize and test operations based on
            the generic function each performs
                                                     520
OOT Methods: Inter-Class Testing


       Inter-class testing
         For each client class, use the list of class
          operators to generate a series of random test
          sequences. The operators will send messages to
          other server classes.
         For each message that is generated, determine
          the collaborator class and the corresponding
          operator in the server object.
         For each operator in the server object (that has
          been invoked by messages sent from the client
          object), determine the messages that it
          transmits.
         For each of the messages, determine the next
          level of operators that are invoked and
          incorporate these into the test sequence
                                                       521
Chapter 10:
Project Management

      Managing People
  Software Cost Estimation
    Quality Management
   Process Improvement
 Configuration Management

                             522
Managing People
   Selecting staff
   Motivating people
   Managing groups
   The people capability maturity model




                                       523
People management factors
       Consistency
         Team members should all be treated in a
          comparable way without favourites or
          discrimination.
       Respect
         Different team members have different skills
          and these differences should be respected.
       Inclusion
         Involve all team members and make sure
          that people‘s views are considered.
       Honesty
         You should always be honest about what is
          going well and what is going badly in a
          project.                                    524
Selecting staff
       An important project management
        task is team selection.
       Information on selection comes from:
         Information provided by the
          candidates.
         Information gained by interviewing
          and talking with candidates.
         Recommendations and comments
          from other people who know or who
          have worked with the candidates.
                                               525
Motivating people
       An important role of a manager is to
        motivate the people working on a
        project.
       Motivation is a complex issue but it
        appears that their are different types
        of motivation based on:
         Basic needs (e.g. food, sleep, etc.);
         Personal needs (e.g. respect, self-
          esteem);
         Social needs (e.g. to be accepted as
          part of a group).
                                                  526
Managing groups
       Most software engineering is a group
        activity
         The development schedule for most non-
          trivial software projects is such that they
          cannot be completed by one person working
          alone.
       Group interaction is a key determinant of
        group performance.
       Flexibility in group composition is limited
         Managers must do the best they can with
          available people.

                                                      527
Factors influencing group working

   Group   composition
   Group   cohesiveness
   Group   communications
   Group   organisation




                              528
Group composition
   Group composed of members who share the
    same motivation can be problematic
      Task-oriented - everyone wants to do their own
       thing;
      Self-oriented - everyone wants to be the boss;
      Interaction-oriented - too much chatting, not
       enough work.
   An effective group has a balance of all types.
   This can be difficult to achieve software engineers
    are often task-oriented.
   Interaction-oriented people are very important as
    they can detect and defuse tensions that arise.

                                                    529
Group communications
   Good communications are essential
    for effective group working.
   Information must be exchanged on
    the status of work, design decisions
    and changes to previous decisions.
   Good communications also
    strengthens group cohesion as it
    promotes understanding.


                                           530
Group communications (cont’d)

   Group size
     The larger the group, the harder it is for people
      to communicate with other group members.
   Group structure
     Communication is better in informally structured
      groups than in hierarchically structured groups.
   Group composition
     Communication is better when there are
      different personality types in a group and when
      groups are mixed rather than single sex.
   The physical work environment
     Good workplace organisation can help encourage
      communications.
                                                   531
Group organisation
   Small software engineering groups
    are usually organised informally
    without a rigid structure.
   For large projects, there may be a
    hierarchical structure where different
    groups are responsible for different
    sub-projects.




                                         532
People Capability Maturity Model

    Intended as a framework for
     managing the development of people
     involved in software development.




                                      533
P-CMM Objectives
   To improve organisational capability
    by improving workforce capability.
   To ensure that software development
    capability is not reliant on a small
    number of individuals.
   To align the motivation of individuals
    with that of the organisation.
   To help retain people with critical
    knowledge and skills.


                                         534
P-CMM levels
       Five stage model
         Initial. Ad-hoc people management
         Repeatable. Policies developed for capability
          improvement
         Defined. Standardised people management
          across the organisation
         Managed. Quantitative goals for people
          management in place
         Optimizing. Continuous focus on improving
          individual competence and workforce
          motivation

                                                      535
Management of Object-
Oriented Software Projects
   Common Process Framework for OO
   Object-Oriented Project Metrics and
    Estimation
   OO Estimating and Scheduling
    Approach
   Progress for an OO Project




                                          536
Measures, Metrics and
Indicators
   A measure provides a quantitative indication
    of the extent, amount, dimension, capacity,
    or size of some attribute of a product or
    process
   The IEEE glossary defines a metric as ―a
    quantitative measure of the degree to which
    a system, component, or process possesses
    a given attribute.‖
   An indicator is a metric or combination of
    metrics that provide insight into the
    software process, a software project, or the
    product itself

                                              537
Measurement Principles
   The objectives of measurement should be
    established before data collection begins;
   Each technical metric should be defined in an
    unambiguous manner;
   Metrics should be derived based on a theory
    that is valid for the domain of application
    (e.g., metrics for design should draw upon
    basic design concepts and principles and
    attempt to provide an indication of the
    presence of an attribute that is deemed
    desirable);
   Metrics should be tailored to best
    accommodate specific products and processes.
                                            538
Measurement Process
   Formulation. The derivation of software
    measures and metrics appropriate for the
    representation of the software that is being
    considered.
   Collection. The mechanism used to accumulate
    data required to derive the formulated metrics.
   Analysis. The computation of metrics and the
    application of mathematical tools.
   Interpretation. The evaluation of metrics results
    in an effort to gain insight into the quality of the
    representation.
   Feedback. Recommendations derived from the
    interpretation of product metrics transmitted to
    the software team.
                                                      539
    Metrics Attributes
    simple and computable. It should be relatively easy to
     learn how to derive the metric, and its computation
     should not demand inordinate effort or time
    empirically and intuitively persuasive. The metric should
     satisfy the engineer‘s intuitive notions about the product
     attribute under consideration
    consistent and objective. The metric should always
     yield results that are unambiguous.
    consistent in its use of units and dimensions. The
     mathematical computation of the metric should use
     measures that do not lead to bizarre combinations of
     unit.
    programming language independent. Metrics should be
     based on the analysis model, the design model, or the
     structure of the program itself.
    an effective mechanism for quality feedback. That is,
     the metric should provide a software engineer with
     information that can lead to a higher quality end
     product                                               540
Analysis Metrics

   Function-based metrics: use the
    function point as a normalizing factor
    or as a measure of the ―size‖ of the
    specification
   Specification metrics: used as an
    indication of quality by measuring
    number of requirements by type




                                         541
Function-Based Metrics
     The function point metric (FP), first proposed by
      Albrecht [ALB79], can be used effectively as a means
      for measuring the functionality delivered by a system.
     Function points are derived using an empirical
      relationship based on countable (direct) measures of
      software's information domain and assessments of
      software complexity
     Information domain values are defined in the
      following manner:
         number of external inputs (EIs)
         number of external outputs (EOs)
         number of external inquiries (EQs)
         number of internal logical files (ILFs)
         Number of external interface files (EIFs)
                                                         542
Architectural Design Metrics

  Architectural design metrics
   Structural complexity = g(fan-out)
   Data complexity =
           f(input & output variables, fan-out)
   System complexity =
           h(structural & data complexity)
  HK metric: architectural complexity as a
   function of fan-in and fan-out
  Morphology metrics: a function of the
   number of modules and the number of
   interfaces between modules
                                                  543
    Metrics for OO Design
       Whitmire describes nine distinct and measurable characteristics
        of an OO design:
       Size
          Size is defined in terms of four views: population, volume,
           length, and functionality
       Complexity
          How classes of an OO design are interrelated to one
           another
       Coupling
          The physical connections between elements of the OO
           design
       Sufficiency
          ―the degree to which an abstraction possesses the
           features required of it, or the degree to which a design
           component possesses features in its abstraction, from the
           point of view of the current application.‖
       Completeness
          An indirect implication about the degree to which the
           abstraction or design component can be reused       544
    Metrics for OO Design (cont’d)

   Cohesion
      The degree to which all operations working
       together to achieve a single, well-defined
       purpose
   Primitiveness
      Applied to both operations and classes, the
       degree to which an operation is atomic
   Similarity
      The degree to which two or more classes are
       similar in terms of their structure, function,
       behavior, or purpose
   Volatility
      Measures the likelihood that a change will occur
                                                     545
Component-Level Design Metrics

   Cohesion metrics: a function of data
    objects and the locus of their
    definition
   Coupling metrics: a function of input
    and output parameters, global
    variables, and modules called
   Complexity metrics: hundreds have
    been proposed (e.g., cyclomatic
    complexity)

                                        546
Code Metrics
    Halstead‘s Software Science: a
     comprehensive collection of metrics all
     predicated on the number (count and
     occurrence) of operators and operands
     within a component or program
     It should be noted that Halstead‘s ―laws‖
        have generated substantial controversy,
        and many believe that the underlying
        theory has flaws. However, experimental
        verification for selected programming
        languages has been performed.

                                              547
Metrics for Testing
       Testing effort can also be estimated using
        metrics derived from Halstead measures
       Binder suggests a broad array of design
        metrics that have a direct influence on the
        ―testability‖ of an OO system.
         Lack of cohesion in methods (LCOM).
         Percent public and protected (PAP).
         Public access to data members (PAD).
         Number of root classes (NOR).
         Fan-in (FIN).
         Number of children (NOC) and depth of the
          inheritance tree (DIT).
                                                      548

				
DOCUMENT INFO