Software Engineering

Table of Contents

Lecture 1: Syllabus/Class Info

  • CSE 361 Course Syllabus
  • Went over syllabus
  • process of engineering software is much different, involves collectinng requirements, developing specifications and the like

Lecture 2

  • Move to Architecture Hall 127
  • lifecycle/process models
    • abstract representations of the processes
    • provides management a way to avoid mangling
  • early process
    • informal requirements, process, product
    • assumes you know what’s going on
    • interaction with customer is at the start and end
    • limited interaction makes it difficult to correctly understand requirements in a timely manner
  • waterfall – linear
    • big design up front
    • first formalized as an example of a flawed model
    • phases
      1. requirements analysis and specification - what
      2. design and specification - how
      3. development and unit testing
      4. integration and system testing
      5. delivery and maintenance
    • Is simple, structured
    • emphasizes documentation
    • Add feedback, and it becomes more useful
  • reuse – assembled from existing components
    • phases
      1. requirements specification
      2. component analysis
      3. requirements modification
      4. system design with reuse
      5. developmentt and integration
      6. system validation
    • can save time and effort
    • builds on reliability
    • can lead to compromises
    • building with future reuse can slow effort
  • incremental – built in distinct increments
    • phases
      1. define outline requirements
      2. assign requirements to increments
      3. design architecture
      4. develop system increment
      5. validate increment
      6. itegrate increment
      7. validate system, if incomplete GOTO 4
    • user requirements are priorityized
    • once an increment is started, requirements are frozen
  • agile – incrementtal approach to an extreme
    • focus on small increments of functionality
    • teams of 5-10 spend 2-4 weeks per increment
    • needs a clear view of requirements and a sound architecture/design
    • uses validated principles
      • pair programming/reviews
      • revisiting/refactoring/iteration and refinements
      • test first
    • provides functionality quickly
    • fast response to changing requirements
    • early/frequent feedback
    • focuses on working software at the expense of documentation
    • development can get off track if customer is not clear about ultimate goals
    • future maintainability based on how well requirements/architecture can be expressed initially
  • formal model
    • based on transforamtion of mathematical spec through different represenations to an executable program
    • transformations are correctness-preserving – straightforward to show that the program conforms to its specification
    • phases
      1. requirements definition
      2. formal specification
      3. formal transformation
      4. integration and system testing

Lecture 4: Requirements Engineering

  • deciding what to build
  • defining real-world goals, functions of and constraints on software systems
  • effects that the client wishes to be brought about in the problem domain
  • what it needs to do
    • potential needs
      • what the problem is, not how to solve it
    • how software will meet the needs
    • how it will be used
    • how it will fit into the work environment
  • essential factor for ensuring sucess
    • resolves conflicts between stakeholders early
    • starts quality control and assurance early
  • there can be a significcant cost of fixing errors
    • error not found until delivery costs 10x as much to fix than if found during programming
    • requirement error 100x
  • benefits
    • fewer defects
    • reduced dev rework
    • fewer unnecessary features
    • reduced project cost and delay
    • improved system quality and custome satisfaction
  • issues
    • insufficient involment
      • customers not understanding importance
      • developers knowing what users want
    • ambiguous requirements – that can be interpreted in multiple ways
    • minimal specifications
    • gold plating - devs ading functions not in the required spec
    • overlooked classes of users
    • inaccurate planning
  • good specs
    • complete – no missing
    • consistent – no conflicts
    • verifiable – able to verify that res are met
    • traceable – linkable to design and code components
  • task
    • ident problem and scope
    • dev understanding of nneeds
      • who will use
      • why is current situation a problem
      • define erminology
    • characterize a good solution to the problem
      • functions to be provided
      • constraints to be met
  • requirements engineering
    • requirements development
      • elicitation
      • analysis
      • specification
      • validation
    • requirements management


  • most difficult, critical and error prone.
  • most communication-intensive
  • success key: collaborative partnership between customers and development team


  • problems of scope
    • boundary is ill-defined
    • unnecessary design info may be given
    • customers requesting features that are too expensive or that lie outside of intended scope
  • problems of understanding
    • users have incomplete understanding of needs
    • poor understanding of capablities and limitations
    • analysts have poor knowledge of problem domain
    • user and analyst speak differen languages
    • conflicting views of different users
  • problems of volatility
    • requirements that evolve over time


  • application domain understanding
    • adk is knowledeg of general area where the system is applied
    • system for the domain
  • problem understanding
    • the details of the specific problem
  • understanding needs and constraints of system stakeholders
    • understand in detail the specific needs of people who require system support
    • consult with them to discover goals


bg reading
  • sources of information
    • company docs, org charts, docs on systems, technical papers
  • advantages
    • understand the org before meeting people who work there
    • may find detailed requirements for current system
  • disadvantages
    • docs often do not match reality
  • requirements engineer or analyst discusses with different stakeholders to build an understanding of requireuments
  • predominant technique
  • types
    pre-defined questions
    no predefined agenda
  • advantages
    • collect a lot of info
    • can probe in depth
  • disadvantages
    • hard to analyze large amounts of qualitative data
    • hard to compare different respondents
  • tips
    • be prepared
    • take notes
    • don’t make them think
      • My time is more valuable than yours.
      • I don’t know what I’m doing.
      • You don’t know what you’re talking about.
    • be intelligible
    • be receptive
  • questions to ask
    • problem to be addressed
    • process to dev solution
      • who is paying?
      • what are the underlying reasons for wanting a system?
      • what is trade-off between delivery date and cost?
    • elicitation itself
      • do my questions seem relevant?
      • are your answers official?
      • is there anything else I should be asking?
      • is there anything you would like to ask me?
  • Construct and admin a survey
  • advantages
    • can collect info from lots of people quickly
    • can be admined remotely
  • disadvantages
    • simplistic questionns can provide very little context
  • be careful of
    • sample size
    • sample selection method
    • ambiguous questions
  • a pilot run of a questionnaire can help eliminate bugs
  • more natural interaction than formal interviews
  • can increase number of ideas
  • relatively short, intense sessions seem to be most productive
  • selection of personnel is critical
  • don’t allow criticism or debate
  • idea reduction
    • prune ideas that aren’t worthy of further discussion
    • group similar ideas into super topics
  • prioritize remaining ideas
  • used for summarization and feedback
    • to discuss results of info gathering stage
    • to conclude on a set of requirements
  • important manegerial tool
task observation
  • advantages
    • can solve the documented v actual problem
    • reveals details other techniques cannot
  • disadvantages
    • can be time consuming
    • subjective
  • variant of observation
  • people often cannot describe what they do as it’s natural to them, observing them is a very good way to understand work
  • technique from social sciences, valuable for understanding actual work processes
  • actual processes often differ from formal processes
  • ethnographers spend some time observing people at work and building up a picture of how they’re done
  • expensive, may be only useful for extremely large, complex and critical systems
  • more on this one later

which techniques to use in project

  • can use any, depends on the project itself

Lecture 5: Requirements Engineering, Continued


  • discover problem,s incompleteness and inconsistencies
  • fed back to stakeholders to resolve them through the negotiation process
  • analysis is interleaved with elicitation as problems are discovered
  • a checklist may be used, each requirement may be assesed against the requirements


  • premature design
    • premature design/implementation details
  • combined requirements
    • can requirements be broken down?
  • unnecessary requirements
    • is it gold-plating?
  • use of non-standard hardware
    • must know platform requirements
  • conformance with business goals
    • consistent with business goals
  • ambiguity
    • can it be understood differently
  • realism
    • does it make sense given the technology
  • testability and verifiability


  • the invention and definition of a hebavior of a solution system such that it will produce the required effects in the problem domian
  • statement of agreement between producer and consumer of a service
  • may have aspects such as
    • requirements
    • features
    • performance characteristis
    • architecture
    • internal and external behavior of modules

requirements specs

  • statement of user requirements
  • major failures occur through misunderstandings between the producer and the user
  • should have the following qualities
    • consistent
      • shouldn’t be contradictory
      • especially problematic when multiple types of requirements documents are used, nat lang for customers, semi-structured models for engineers
    • complete
      • internal completeness, should define any new concept or terminology that it uses
      • external completeness, must document all needed requirements
      • have a way to mark stuff as TBD
    • verifiable / traceable
      • make sure it’s possible to verify that requirements have been met
      • requirements can be linked to output directly
    • precise, clear and unambiguous
  • guidelines
    • find a standard format, use it for all requirements
    • use language in a consistent manner
    • use text highlighting to identify key parts of the requirements
    • avoid the use of jargon
    • label sections, subsections and requirements consistently
    • use white space liberally
    • use visual emphasis consistently
    • label and index all figures

IEEE standard

  • intro
    • purpose
    • scope
    • definitions, acronyms, abbreviations
    • reference documents
    • overview
  • overall description
    • present a high-level overview of product and environment, anticipated users, known contraints and dependencies
    • product perspective
    • product functions
    • user characteristics
    • constraints
    • assumptions and dependencies
  • specific requirements
    • main body
    • contains
      • interface, external
      • functional requirements
      • performance requirements
      • design constraints
      • softtware system attributes
      • other requirements
    • often organized by feature


  • can be used to help discover problems, and help develop specifications
  • often used for interfaces
  • most often mockups, rather than complete implementations
  • docs and ntraining may need to be provided
  • ask users to evaluate the prototype, particularly those who have different jobs
  • develop test scenarios, with careful planning to broadly cover the requirements
  • execute scenarios, have developers watch
  • document problems, use a form if possible
  • can detect
    • misunderstandings
    • missing services
    • confusing services
  • can be used in requirements analysis
  • prototype may serve as a basis for preparing a precise system spec
  • can lead users to think that system construction will be easier than anticipated
  • there may be temptation to morph the prototype into a final solution, don’t do it!
  • paper prototypes
    • similar to story boards
    • allows the reader to walk through an interface, seeing the different screens and layoutts.
    • use captions to explain what is shown

Lecture 6: Requirements Engineering, Continued


  • certify that the requirements doc is an acceptable description of the system to be implemented
  • check a requirements doc for
    • completeness
    • understanability and organization
    • conformance to standards
    • requierments conflicts, redundancy and ambiguity
    • technical errors
    • Traceability and Verifiability
  • analysis works with raw requirements as elicited
  • validation worsk with a final draft of docs, with negotiated and agreed upon documents
  • will take in req doc, organizational knowledeg and standards
    • will reveal problems and actions to be taken
  • should take in a complete version of the document
  • organizational knowledge would be the knowlede on the part of the organization that may be used to jusdge the realizm of the requirements
  • org standards would be local standards such as those for the structure of the document
  • problems list would be the discovered problems in the requirements doc
  • actions would be the responses to requirements problems
  • inspection can be used, having a group read and analyze the requirements, look for problems, meet and discuss the problems and agree on actions to address these problems
    • teams should have stakeholders from different backgrounds, requirements engineers, design team members, testing team, customers maybe, should include a domain expert and an end-user, incl other representatives of the client
    • checklist
      is it understandable
      is info repeated unnecessarily
      does the checker know of any missing requirements or is there any info missirng
      are the requirement expressed using terms that are clearly defined, could they be read differently
      are the functional requirements testable
      are there contradictions
      is stuff structured in a sensible way
      conformance to standards
      do they conform to rrelevant standards
      can you connect design to requirements to tests to code
  • testing
    • doesn’t occur until later in the lifecycle
    • still, each requirement must be testable
    • an effective validation technique

requirements management

  • managing change to requirements
  • principal concerns
    • managing changes to agreed requirements
    • managing relationships between requirements
    • managing dependencies between things
  • reasons
    • erros and misunderstnandings
    • new requirements emerge, often because of a deeper understanding of the system
    • changing external circumstances
      • changes of strategy or priority of the business
      • new information about the system’s environment
      • new laws or regulations
  • traceability
    • requirements must be traceable, makes it easier to manage
    • can determine why it exists
    • what requuirements are related to it
    • how it relates to other information such as design, code, tests and user docs
    • assesment of impact of change
    • links related requirements and the requirements and other representations
    • traceability matrices and tables may be used to record this information

Lecture 7: Use Cases

Use Cases

  • UML is the Unified Modeling Language – set of unified notaitions for describing OO systems
  • models capture functional requirements
  • identify what users intend to do with system
  • used in elicitation and analysis, can be part of specs
  • actor’s perspective of system
  • two parts
    • diagram
      • visual overview of interactions
      • captures scop – idents external entities
    • text documents the details of t herequiyrements
  • actors are things outside of the system
    • classes
    • not restricted to humans – may be various organizations and other systems
  • use cases
    • what the system should do
    • sequences of interactions between actors and the system, also known as scenarios
  • actors are stick figures
  • system boundaries are rectangles
  • usecases are elipses
  • scenario is an example of what happens when an actor interacts with a system
    • typical scenarios – patient calls clinic to make appt for checkup. receptionist finds nearest epty time slot and schedules the appt for the time slot
    • alternative scenarios – receptionist cannot find patientt in db, scheduled as a new patient
    • exceptional scenarios – pt calls, phone disconnects before the process is complete
  • ex: ATM
    • typical – system promts cust for pin, customer enters pin, commits with Enter, checks pin to see if valid. if valid, sys acks user, use case ends
    • exceptional – customer cancels tx by pressing cancel
    • exceptional – enters invalid pin, uc restarts, 2 attempts cause system to cancel tx, freezes for 60 secs.
  • ex: student info system
    • obtain grant
    • obtain loan
    • pay fees
    • reimburse for fees
    • enroll in class
    • drop class
    • distrib. transcripts
  • actors can be generalized and specialized
    • ex: customer, commercial customer, residential customer
  • usecases can be extended by others or included in others
    • extends describe variation
    • includes are used for repetition
  • hl text
    • have name, actors and description
  • detailed text – expanded
    • includes actor actions and system responces
  • hints
    • start with good scenarios
    • each uc should name a single, identifiable and reasonably atomic behavior
    • use language of the user
    • describes the flow of events clearly enough that an outsider can follow
    • show only actors that relate to use cases
    • specify actor names with specific roles
    • avoid too many implementation details
    • factor common behavior and include
    • factor variants by puting it into extensions
    • show use cases that are important to understand functionality
  • Ex: Point of Sale Systems
    1. ident actors and use cases
      • actors
        • cashier
        • customer
        • manager
        • sys admin
      • use cases
        • log in
        • cash out
        • buy items
        • redund items
        • start up
        • shut down
        • manage users
    2. write HL descriptions
      • buy items
        • customer, cashier
        • cust arrives at checkout w/ items to purchase, cashier records, cust pays, cust leaves w/ items
      • start up
        • manager
        • powers on terminal to prepare for use by cashiers. Checks date and time correctness, system ready for use
    3. draw basic diagram
    4. write expanded uc descriptions
      • Buy items
        • cust, cashier
        • see above
          1. cust arrives with items
          2. cashier records each item, if more than one, cashier enters quantity
          3. system determines price and adds info to transaction, description and price presented
          4. on completion of entry, the cashier indicates that entry is complete
          5. calculates and presents total
          6. cashier tells cust total,
          7. cust chooses payment type
            1. cash
            2. credit
            3. check
          8. logs completed sale
          9. update inventory
          10. generates receipt
          11. cashier gives receipt to cust
          12. cust leaves with purchased items
        • line 2: invalid item entered, indicate error
        • line 7, cust could not pay, cancel sales tx
    5. refine use case diagram

Lecture 8: Software Design

  • takes requirements, acts as a bridge between requirements and implementation
  • gives a structure to an artifact
    • a system must be given a structure that makes it easy to understand and evolve
  • refers to both an activity and the result of the activity
  • decomposes a system into parts, assigns responsibilities and ensures that parts fit together to achieve a global goal
  • process describes views of the system in steps of increasing detail
  • produces a software design document
  • often a software architecture is produced as an overarching frametwork for a software design
    • shows overall structure and orgavisation of the systtem to be defined
    • its description includes description of
      • main components
      • relationships among those components
      • rationale for decomposition into its components
      • constraints that must be respected by any design of the components
      • guides the development of the design
  • design goals
    • design for change
      • often concentrate on current needs
      • special effort is needed to anticpate likely changes
    • product families
      • think of current system under design as a member of a product family
  • changes
    • algorithms
      • replace inefficient sorting algorithm with a more eefficient one
    • change of data representation
      • from array to hashtable
      • non-trivial percentage of maintenance cost are attributed to data representation changes
    • changes in platforms
    • change in underlying abstract machine
      • new os
      • new dbms
    • change of peripheral devices
    • change of social environment
      • new tax regime
      • euro or national currency in EU
    • change due to dev processes (supporting automated testing)
  • product families
    • different versions of the same system
      • family of compilers
      • family of mobile phones – different network standards, end-user languages
      • facility reservation system
    • design whole family first, then modify for individual systems
  • modules
    • well-definde component of a software system
    • part of system that provides services to other modules
      • computation elements that other modules may use
    • when we decompose systems into modules, we specify relations between them
    • categories
      trad form, provides procedural abstraction, encapsulate an algorithm
      group of related procedural abstractions, ex. math libraries
      common data
      data shared by different modules, config constants, c headers, fortarn’s common
      abstract objects
      objects manipulated by interface functions, data structure hidden to clients
      java and c++ classes
    • Modules and Relations
      • \(S = \{M_1, M_2, \ldots, M_n\}\)
      • the relation \(r\) is a subset of \(S \times S\)
      • if \(M_i\) and \(M_j\) are in \(S\), \(\langle M_i, m_j\rangle \in r\) can be written as \(M_i r M_j\)
      • transitive closure \(r^+\) of \(r\)
      • often relations are irreflexive
      • can often be represented as graphs – a hirearchy is a DAG

Lecture 9: Software Design, Continued

  • how parts of the system interact, decomposing the system into component parts
  • high-level – architectural design
  • further decomposed
  • design for change, design for product families
  • relationship ISCOMPONENTOF
    • higher-level module has lower-level modules
    • A is component of B - B includes A
    • \(M_{S,i} = \{M_k \mid M_k \in S \land M_k \mathrm{IS_COMPONENT_OF} M_i\}\)
    • hl modules are used to help ensure that info us understandable
  • interface versus implementation
    • interface is how it’s called
    • implementation is how it’s built
    • let’s stuff be hidden from those that don’t need to know it.

Lecture 10: Software Architecture

  • decomposing the system into modules
  • describes overall organization and structure in terms of major constituents and interactions
  • prompotes independence of modules – which can be deved and tested independently
  • ehances ability to change
  • reduces cost/time to implement, herping to formalize, organize and prioritize decisions
  • models
    • nets and modules
    • layered model
  • follow patterns, common solutions to common problems, codifies specific knowledge collected from experijnce in a domain
  • common patterns
    • repository
      • subsystems exchange data
        • a shared central database or repository can be accessed by all subsystems
        • each subsystem maintains its own database elements and passes data to those for use by other subsystems
      • often used when large amounts of data need to be shared
      • advantages
        • no need to transfer data between sysetms directly
        • transparency – subsystems don’t need to know how data is produced
        • standardized, sharing model is the repo schema
      • disadvantages
        • must agree on repo data model
        • data evolution is difficult and expensive
        • can be difficult to distribute efficiently
    • data-flow
      • functional transformations process their inputs to produce outputs
      • pipe or filter model (the unix shell)
      • when transformations are sequential, this is a batch sequential model, uned extensively in data processing systems
      • not super suitable for interactive systems
      • very good with functional languages
    • centralized control
      • a control subsystem manages the execution of other subsystems
      • call-return
        • top-down suproutine model where control tarts at the top of a hierarchy and moves downward, good for sequential systems
      • manager
        • good for concurrent systems, one component controls the stopping, starting and coordination of other processes, can be implemented in sequential systems as a case statement
      • model-view-controller
        • variant of centralized control architecture
        • controller process user ommands, which manipulate data in model and calls on various views.
    • client-server
      • distributed system model, shows how data and processing is distributed acronss a range of components
      • sets of stand-alone servers provide specific services such as printing, data management, etc
      • set of clients call on these services
      • a network allows clientts to access servers
      • advantages
        • data distribution is straitforwhard
        • makes effective use of networked systems, may require cheaper hardware
        • easy to add new servers or upgrade existing servers
      • disadvantages
        • no shared data model, so subsystems may use different data organization, data interchange may therefore be inefficient
        • redundant management in each server
        • no central register of names and services it may be hard to find out what servers and services and available
    • event driven
      • driven by externally generate d events, where the timing of the event is outside of the control of the subsystems which process the event
      • two main models
      • broadcast models
        • event is broadcast to all sub-systems, any subsystem which can handle the event may do so
      • interrupt driven
        • used in real time systems where interrupts are detected by an interrupt handler and passed to some other component for processing
    • layered systems
      • model the interfacing of sub-systems
      • organises the system into a set of layers o abstract machines each providing a sest of services
      • supports incemental development of the subsystems in different layers, when an interface changes, only the adjacent layer is affected
      • however, it’s often difficult to structure systems in this way
    • object oriented
      • structure the system into a set of loosely coupled objects with well-defined interfaces
      • oo decomp is concerned with identifyixng object classes, their attributes and operations
      • when implemented, objects are created from these classes and some control model is used to coordinatte object operations
    • domain specific
      • often a blend of one or more, or a completely new design
      • compilers often use a blend of repository and data-floow

Lecture 11: UML Class Diagrams

  • many visual modeling techniques
    • use case
    • class
    • object
    • component
    • deployment
    • sequence
    • collaboration
    • statechart
    • activity
  • only 20% are necessary to represent 80% of systems
  • ER Diagrams were often used before UML came into being. Are often still used, though with different visual notation
  • class diagrams are a form of entity relationship diagrams, have relationships, entities and entities have attributes and operations
  • abstractions of elements with common chracteristics at fine grained level
  • classes are related to each other via generalization, association, aggregation
  • generalization
    • inheritance
    • eliminates redundancy
    • supports incrementality
  • association
    • relationships between entities, can be named
    • can specify multiplicity constraints
  • aggregation
    • part-of relationship
    • aggregate is a parent class, components are children classes
    • multiplicity may also be used here
    • the aggregate is a parent class, the components are children classes
  • inheritance, association and aggregation are all forms of USES
  • representation of ISCOMPONENTOF is done via package notation
  • organizing classes into packages to simplify complex class diagrams
  • collection of logically related uml elements
  • visibility can be shown with + for public, # for protected and - for private
  • is format of visibility attributeName: Type = initialValue or visibility methodName(paramList): returnList
  • public means outside can use
  • private means that only the class can use it
  • protected means any descendant can use it
  • aggregation can be imple or composite, simple means it’s just a list of objects, composite means parts may belong to only one whole and live and die together
  • self relations are possible
  • navigabilities
    order must tell which customer it’s for and customer must tell which orders it has
    order must tell which customer it’s for, but the customer does not have to tell which orders it has
  • lack of arrows may bean bidirectional, but others say no known navigabilities
  • levels
    represents concepts in domain
    adds interfaces into picture, what do classes export
    adds all the rest of the elements
  • construction
    • identify objects
      • no magic formula, relices on skill experience and domain knowledeg
      • iterative process
      • use a grammatical approach
      • identify tangible things
      • by participation in behaviours
      • scenario-based analysis
      • domain knowledge for refinements
    • construct conceptual perspective, add concepts in the domain under study
    • refine to specification perspective, add interfaces into the picture, specify relationships more precisely
    • refine to implementation perspective, add other elements

Lecture 12: Implementation

  • formatting and style
  • reducing complexity
  • programming defensively and proactively

formatting and style

  • why do we care
    • the compiler doesn’t
  • the fundamental theorem of formatting – good layout shows logical structure
  • fundamental theorem of style – adopting standards improves maintainability
  • take advantage of representation of code
  • helps comprehension and maintenance
  • issuse such as
    • whitespace
      • helps with understandability
      • 4 space indent is a default
    • grouping
    • blank lines
      • helps group together logically related lines of code
    • alignment
    • braces
      • should be consistent to make it easier to ensure that things are easuly understandable
    • commenting
      • should be done and done consistently
      • must be kept in sync with the code
      • should describe the logic behind the code, not the code itself
      • don’t commennt tricky code, rewrite it
    • naming
      • choose with care
      • choose by either what it means or how it’s represented
      • shorter names for limited scope, longer for lager scope
      • i, j, k are fine for loop counters
      • indicate status of temporary vars
      • boolean names should imply that they’re true or false, and should usually be positive (think -p convention)
      • have a goood convention, and be consistent
      • abbreviations are okay, but should be practical
    • conditionals should be done by order and context
      • switches should have a default for extraordinary and default cases, and make sure that breaks are taken care of
    • loops
      • be careful with loops, always make sure to use the right kind
      • enter from one location only
      • make sure initialization is before the loop
      • don’t use for when while is more appropriate
      • enclose loop statements
      • perform houskeeping at either the start or end
      • make each loop perform only one function
      • make sure that loops exits are dealt with correctly
      • consider the use of breaks
      • be wary of a lop with a lot of breaks
      • use integers for loop variables
      • be wary of off-by-ones, borderline cases and termination failures

Reducing Complexity

  • Modules
    • helps to make code easy to understand
    • avoids duplicate code
    • limits the effect of channges
    • promotes reuse
    • increases readability
    • increases portability
  • variables
    • one purpose per
    • limit and identify global variables
    • limit scope
  • parameters
    • follow consistent order, input mod, output
    • remove those that aren’t used
    • don’t use them as working variables
    • try to limit the number
  • defensive programming
    • not sure what other programmers will do
    • build insfrastructure to test code
    • protect from somebody else’s faults with contracts
    • embed correctness contracts as comments or assertions

key points

  • code must implement design
    • if design not clear, update before changing code
    • don’t use gold plating, extraneous requirements
  • must
    • reduce complexity
    • enhance readability
    • practice defensive programming
    • keep track of changes

Lecture 13: Configuration Management

  • real systems involve many components and many ingineers working simultaneously, raises many problems related to managing components and the work done on them
  • configuration management is used to address these problems
  • configuration is tthe constituent components of a software product, including all versions
  • config management is the discipline of co-ordinating the changes
  • problems
    • sharing of software artefacts
    • support for product families
    • providing mechanisms for over-seeing change
    • providing documentation

Sharing Artefacts

  • two who want to modify a single file
  • if they both do, there could be conflicts
  • if the file is taken, there could be issues with building, security issues, etc.
  • private copies will have to be merged
  • early options
    single writer, many reader
    multiple writers, but heavily policed checkins
  • Both early options require merge abilities, and get more difficult when there are dependencies
  • sharing required heavy co-ordination of effort

Product Families

  • programs have components which have versions and variants
    • versions are new instances
    • variants are concurrent instances
  • versioning schemes help manage product families
    • x.y.z is common
      • x is major
      • y is minor
      • z is bugfix
    • bugfixes have to be taken care of very carefully
  • approaches
    • keep separate copies of all materials for each version and variant
    • keep common code for deltas with variants
  • What to keep

overseeing change

  • must be done using something
  • various levels of ceremony

Providing documentation

  • includes bug reports, change logs, etc.


  • CVS
  • SVN
  • Git
  • things to know
    • read/write policy
    • checkout
    • checkin
    • conflict checking
    • add/delete items
    • getting started
    • merges
    • product family support
    • etc.

Lecture 14: Design Patterns

  • a pattern describes a problem and a solution to solve the issue
  • designs patterns: descriptions of communicating objects and classes
    • reflect common problem and solution
  • provide a shared language of design – increased understanding and reaches wider audience
  • learn from experience, designing is difficult,.
    • design patterns are tested and have known tradeoffs and define what probems it can solve
  • geared towards object oriented languages
    • not exclusive, but makes implementation easier
  • can be implemented in every language
  • architecture, then design, then implementation
  • elements
    • names
    • problem
    • solution
    • consequences
  • categories
    • behavioral – interaction between classes and objects
    • structural – how classe are combined
    • creational – concerned with te creation of objects or classes
  • ex
    • iterator
      • access elements of an object sequentially
      • creates abstract iterator and concrete aggregate classes
      • aggregate creates its own appropriate iteratior
      • supports a variety of traversal types for collections
      • simplifies the interface to the collection
      • supports simultaneous traversals of varying types
    • facade
      • create high-level interface to hide complexity
      • create overarching interface
      • creates classes that use interface
      • facade class will create correct object
      • provides default view of sub-system
      • lessens coupling between subsystem and clients
      • hides complexities of subsystems
    • singleton
      • restricts object creation to a single instance, ex only ever allow one instance
      • create one object and reuse it
      • make constructor private or protected and limit its use to once and only once
      • provide a static method or fields to allow access to the only instance of the class
      • class encapsulates code, no burden to client
      • class can be subclassed if constructor is provided

Lecture 15: Verification and Testing

  • see Ghezzi 6-6.3
  • methods
    • testing
    • inspections/reviews
    • static checking
    • peformance analysis
    • reliability analysis
    • symbolic execution
    • model checking
    • formal proofs
    • user studies
  • software faults cost 60billion to US market, 2003 NIST Report
  • testing
    • dynamically exercising a program to determine if it conforms to certain requirements
    • particularly conformance to specs
    • p is a problem, d is o domain, r is the range, s is the spec
    • tests are intended to find faults that may not have been found
    • test suites expose lots of faults
    • all test suites should include cost effectiveness
    • failure is incorrect behaviour
    • fault is an incorrect portion of code
    • error is something a programmer did wroong
    • bug is an informal term for fault and failure
    • debugging is the process of finding the fault that causes an error
    • testing is the task to find failures
    • oracles are a device or procedure for determining correctness of the output
  • testing versus static checking
    • testing
      • run and see
      • runs test to see whether failures aoccur
      • underilying each failure there are one or more faults
    • static checking
      • examination of code
  • testing types
    groups of units
    software with hardware
    am I satisfied
    after changes
    at specific user sites
  • testing in phases
    requirements phase
    dev test plan and perform review
    design phase
    develop integration tests, perform review
    dev and run unit tests, review
    run integration and system tests
    run regression tests
  • more terms
    test case
    input and expected output
    test suite
    collection of test cases
    written to test a unit module
    module written to allow testing of higher level component
    environment to run programs with stubs and drivers and check the rresults
    description of a process including overall approach and specific tests
  • test case problem does not allow for a perfectly complete and correct program
  • simply look for low probability of failure and sufficient confidence
  • approaches
    • equivalence partitioning
      • input data and output results often fall into different classes
      • each class is an equivalence partition
      • programs behave in an equivalent way for each class member
      • if one member fails, all fail, if one membxer passes, all pass
      • divide into classes of data
      • a test will cover all equivelent elements
      • partitions consist of varlid and invalid sets
    • adequacy criteria
      • partition testing appreaches aim to provide this
      • adequacy criteria are partitiuoning criteaia to select testing classes

Lecture 16: More Testing

  • adequacy criteria
    • black box
      • derived from functional requirements, input output driven
      • no internal nature relevancy
    • white box testing
      • derived from code structure
      • evaluated in terms of coverange of the code structures
    • which is better depends on a situation, but generally a mix of the two is most useful
    • requirements coverage
    • statement coverage
    • branch coverage
    • etc

Requirements based testing

  • Given \(S\) with requirements \(R(S)\) create a test suite \(T\) such that for each requirement \(r \in R(S)\), \(T\) contains at least one case that verifies that \(S\) behaves correctly relative to \(r\)

Lecture 17: Specification testing & the Category Partition Method

  • Steps:
    1. ident units to be tested
    2. ident categories params and environmental factors affecting exec
    3. partition categories into choices
    4. ident constraints
    5. generate test frames
    6. iterate on 3 to 5 until frame set is the right size
    7. generate test cases from test frames
    8. create script to automate
  • be careful when identing functional units
  • be careful with categories
    • often related to the params and the environmental factors
    • length, following other constraints, etc
  • When partitioning, be careful to choose appropriate partitions
    • aim for boundaries
    • try to get errors
    • check default values
    • explore char set
    • check for overflows
    • check for repeated actions, etc
  • use constraints to remove unnecessary test frames
  • test frames describe the choices to make for each category
  • TSL specs provide a way to describe a formal group of testing parameters, and allow for constraints

Lecture 18: White-box testing

  • this is code-based or structural
  • your tests are derived from the code structure

Statement coverage

  • find test cases that ensure coverage of every executable statement in the program
  • greedy way
    • instrument p to report statement coverage
    • repeat
      • create test, execute P with t
      • measure coverage
      • if t adds to cumulative ccoverage, add to T
    • until testing is statement-coverage adequate
  • what about unreachable statements?
  • or hard-to-reach?
  • generating test cases?
    • manually
    • with test case generation tools
    • start with functional, then augment until coverage is achieved
  • code instrumentation:
    • inserting prob statements into code that report data about execution
    • how done, and what issues?
      • can be done with printf debugging
      • can list a few in one printf
      • could use function calls
      • may have effects on runtime and determinism
      • instrumenting source v binary
      • profiling can have drawbacks based on language
  • weakness – may miss some decisions

Decision coverage adequacy

  • should cover all decisions – any and all conditionals and predicates
  • similar algorithm, uses whether or not all are covered
  • similar issues
  • weakness – may not deal with short-circuiting well

Condition coverage

  • find test cases that ensure coverage of every outcome of each decision, under each assignment of truth values to the individual conditions in that predicate

Finding coverage criteria

  • use the control flow graph

Lecture 19: White-box testing – Continued

Coverage and Graph-based Adequacy Criteria

  • entry/exit, merge, branch, etc
  • node coverage is all statements
  • branch coverage is all decisions
  • path coverage – find test cases that ensure coverage of every entry-to-exit path in the program
    • warning, may have problems with loops
    • could only cover acyclic path
    • cover a set basis paths for the program


  • many different studies on criteria – each has their place

Integration Testing and Higher-level Testing

  • higher-level – integration of unit-tested modules to for higehr-level entities
  • primary objective is to discover interface and design errors associated with interactions between elements being integrated
  • once the elements have been integrated, the hl element can be tested more thouroughly
  • unit tests are only in isolation
  • many failures result from faults in interaction
  • many cots components are used and cannot be unit tested
  • filures not discovered are more expensive to fix
  • failures that are not discovered may not be discovered until after deployed
  • be careful with strategy, but understand the concepts of stubs and drivers
  • bread first is often used with top-down

Lecture 20: Regression testing

  • testing in evolving software – testing with new versions
  • test suites can be overly involved, but at the same time, also can be too lean
  • 70+% of dev cost is maintenance, and a large poriton of that is testing
  • as system grow, the tests grow along with it.
  • common approaches
    • retest all – just re-run all the tests
    • regression test selection – find tests testing only affected portions
    • test-case riorityization – run tests that are more likely to find errors or most important tests
    • test suite augumentation – adding tests when needed, and remember to keep old tests too
    • test-suite reduction – analyze tests to remove unnecessary tests permanently

test selection

  • reduce resources required to regression test
  • needed because regression tests grow with each version
  • code changes often cause faults
  • inclusiveness – what may show fault
  • precision – what can’t reveal a fault and weren’t selected
  • safety – just include all
  • techniques
    • retest all is safe (under certain conditions)
    • retest some can be safe and more efficient
    • retest the wrong ones and selection is not safe anymore
    • sampling based, profile based and requirements based are not safe
  • try
    • selecting changes that reach changes in code – don’t include those that don’t
      • use execution traces

Lecture 21: Continuous Integration

  • ensure complete testing as software evolves, and does so quickly
  • continuous integration automatically runs regression tests
  • often involves testcase selection or prioritization
  • development is significantly more incremental now, as resources are cheaper
  • continuous integration is essentially running tests all the time, or at least when changes are made
  • are a stream of continuous tests
  • good continuous integration software will automatically find the relevant tests
  • other options use various windows to automatically select tests to run

Lecture 22: State Diagrams for Modeling Systems

  • diagrams are based on finite state automata
  • these are a mathematical model – 5-tuples containing \((Q,E,D,qo,F)\)
    • \(Q\) finite set of states
    • \(E\) finite alphabet
    • \(qo \in Q\) initial state
    • \(F \subset Q\) final states
    • \(d: Q \times E \to Q\) transition function mapping
    • optionally, outputs on edges or nodes can be added
    • often depicted graphically
  • uses accepts language
  • sufficiently precise fsms can be used to generate code
  • precision however can cause the state explosion problem
  • fsms aren’t good for asynchronous systems

Lecture 23: Agile Methods, An Introduction to Scrum

  • agile process, focuses on delivering the highest business value in the shortest time
  • rapidly and repeatedly inspects actual working software
  • business stes the priorities, teams self-organize to determine the best way to deliver the highest priority features
  • used by many, many businesses
  • has been used for many different applications – including 5 9s projects
  • teams are self-organizing
  • products procgress in month-long sprints
  • requirements are captured as items in a list of “product backlog”
  • no specific practies are prescribed
  • one of several “agile processes”
  • individuals and interactions over processes and tools
  • cares more about working software over comprehensive documentation
  • customer collaboration over contract negotiation
  • responding to change over following a plan
  • has product backlog – list of features needed, often prioritized
  • sprint of 2-4 weeks used to develop the highest priority feature – has sprint backlog
  • after the sprint is hopefully a shippable increment
  • can also add o things to the backlog
  • sprints have daily scrum meetings to discuss what is actually happening
  • constant duration leads to rhythm
  • design coding and testing is done at the same time in the sprint
  • all is done at the same time
  • roles
    • owner – defines features, decides on release date, content, responsible for the profitibality
    • scrum master – go between for owner and team
    • team – 5-9, has many different skils, full time, although there may be some exceptions
  • ceremonies
    • planning – takes all the info into account, analyzes and eval product backlog, select sprint goal, decide achievement, etc, create sprint backlog
    • review – present what accomplished, informal, no lsides, 2 hours of prep, all participates, invites the world
    • retrospective – check and see what’s working, done after every sprint, typically 15-30 minutes
    • daily meeting – daily, short, not for problem solving, stand, don’t sit, open to all, but only the team, and owner may talk, can help to avoid other meetings, answer three qs, what done yesterday, what do today, anything in the way?
  • artefacts
    • product backlog – requirements, list of all desired work, each item ha vaue, priorityized by product owner, reprioritized at the start of each sprint
    • sprint backlog – decides what is done, each team member chooses what to do
    • burndown charts – shows how work is completed over time

Lecture 24: UML State Charts

  • describe how an object’s state changes in response to external events
  • nodes are states
  • arrows are events/actions/stimuli
  • ideal for behavior of a single object
  • key terms
    • state
    • transition
    • activity
      • entry, exit, do, entry
    • action
    • event
  • states are boxes, have name, activities
  • start are filled in circles
  • stop/accepting/final are filled circles with a circle around them
  • transitions are arrows
  • events may have guards and often hav actions
  • actions are with transitions – occur quickly and not interruptible
  • activities are with states, may take longer, can be interrupted, do events iterate, entry happen only on entry to a state
  • superstates contain various other states, and allow stuff to be grouped more easily
  • uml state diagrams allow for concurrency
  • states can have history, the history state, just have an H in the state

Lecture 25: Structured Analysis – Particularly Dataflow analysis

  • data-flow diags
    • semi-formal spec
    • collecion of data manipulated by functions
    • can be persistent
    • can flow
    • has graphical notation
  • identify functions, i/o, data
  • proceed top-down
  • everything should be well described
  • dfd’s don’t show control information
  • remember to recursively refine the diagram

Lecture 26: Dataflow testing

  • criteria subsume others if for a program and test suite, t is a adequate implies that t is b adequate
  • data testing involuves data-use pairs – assocations between definitions and uses of the same variable or memory location
  • covers the use of values
  • data-flow analysis provides information for dataflow testing and other tasks by computing the flow of data to points in the program
  • definitions of a var is a point or statement where var gets values
  • use is where the value is fetched an used
  • definition of v reaches a point p if there exists a path in the cfg from definition to p with no other definitions of v on the path – a definition-clear path – these may exist but not be executable
  • gen set is the set of definitions within the block
  • kill set is the set of definitions that if they reach the start of the block that don’t reach the end
  • in is the set of definitions that reach the beginning
  • out reaches the end

Lecture 27: More Dataflow Testing

  • following the defined algorithm will eventually reach a fixed point
  • can be done as bits and then converted to bit ops
  • exact solutions to most dataflow problems are undecideable

Lecture 28: Project Planning

  • project managers
    • understanding objectives
    • having required resources
    • effective allocation
    • doing well
    • what should be changed
    • controls
      • resources
      • features
      • time
      • risk
    • manages
      • planning
      • scheduling
  • planning
    • ident milestones and deliverables
    • identify work packages – work breakdown structure
    • estimates resources and duration
  • schedule
    • identifies dependencies
    • plans activities in sequence and parallel – using Ganntt or PERT charts
  • monitors progress
    • measures actual work done against the schedule
  • milestones are stages at which deliverables are completed
  • deliverables are the results produced by the work
  • purpose is often the focus
  • final milestones and work backwards
  • Gantt charts can show parallelism
  • PERT charts show dependencies as a DAG
  • pitfalls
    • overly optimistic
    • estimates what we wish, not reality
    • difficult to monitor progress
    • effor does not equal progress
    • slippage is not identified in a timely fashion
    • failing to recognize gold-plate requirements
    • be careful with adding too many people to a project, it may actually slow it down
  • meetings
    • necessary but expensive
    • can help avoid misunderstandings
    • avoid time wasting meetings
      • make purpose clear
      • distribute an agenda
      • identify a chair
      • decisions need to be followed through, naming a person responsible for each todo item
  • uncertainty
    • managing involves assumptions
    • reduce risk
      • through planning
      • respond to variance as it occurs
      • indentify sources
      • determine individual impact
      • select risks with significant impact for further study
      • asses overall impact of significant risks
      • how can likelihood or impact be reduced
      • develop and implement a plan to control risk
    • impact of risk is likelihood times consequence
  • common risks
    • personnel inadequacies
    • unrealistic scope/budgets/schedules
    • developing wrong functionality
    • developing wrong interface
    • underestimation of tech learning curve
  • reducing
    • avoid – replan to eleminate
    • deflect – pass to someone else, like a subcontractor with penalty clauses
    • contingencies – just plan ahead, increase time, budget, or both, adjest scope, or RUN

Lecture 29: Software Evolution

  • change is inevitable
  • use Config management to help build and modify the system
  • changes are implemented by modifying existing components and adding new components
  • corrective maintenance repairs fault
  • adaptive maintenc – adapts software to new environments
  • perfective maintenance modifies functionality
  • often has cost, and usually greater than development costaging software can have particularly high support costs

Licensed under Creative Commons Attribution-ShareAlike 4.0 International License