CSE 361 Course Syllabus

Went over syllabus

process of engineering software is much different, involves collectinng requirements, developing specifications and the like

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

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

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

  functional

  trad form, provides procedural abstraction, encapsulate an algorithm

  libraries

  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

  adts

  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

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 IS_COMPONENT_OF

• 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.

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

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 IS_COMPONENT_OF 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

bi-directional

order must tell which customer it's for and customer must tell which orders it has

uni-directional

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

conceptual

represents concepts in domain

specification

adds interfaces into picture, what do classes export

imlpmentation

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

formatting and style

reducing complexity

programming defensively and proactively

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

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

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

unit

modules

integration

groups of units

system

software with hardware

acceptance

am I satisfied

regression

after changes

beta

at specific user sites

testing in phases

requirements phase

dev test plan and perform review

design phase

develop integration tests, perform review

implementation

dev and run unit tests, review

integration

run integration and system tests

maintenance

run regression tests

more terms

test case

input and expected output

test suite

collection of test cases

driver

written to test a unit module

stub

module written to allow testing of higher level component

harness

environment to run programs with stubs and drivers and check the rresults

plan

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

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

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

this is code-based or structural

your tests are derived from the code structure

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

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

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

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

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

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

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

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

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

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