1/25/2003 - Intro to SWE

(perry@ece.utexas.edu

512.471.2050)

 

INQUIRY BASED REQUIREMENTS ANALYSIS (Potts)

 

REQUIREMENTS ELICITATION

DOCUMENTATION - Begin with statment of goals

- Scenarios (end-to-end)

  * use cases (short description)

  * scripts (agents/actions - action table)

  e.g. Bell labs, scripting language for telephony, to allow input of scenarios with output as a graphical representation, that could be stepped through

>>Scenarios are NOT the requirements; they are a way of understanding the requirements

- Stakeholder Views

  * e.g. UT Art Library provides system to look up pieces, but every user has a different "view" of how the lookup should work

  * ask "what-if" questions

 

DISCUSSION

- Questions

- Answers

  * possible solutions

- Reasons

  * justification

 

EVOLUTION

- repeat until done

- "freeze" requirements

 

Example:  Hypertext as a tool

"What we get with hypertext is a very easy way to get lost.  I mean, navigate..."

- traceability

- linking

 

"What you do if you have two million customers is you ignore ALL of them and do what you want to do..."

- more often, you build a "logical construction" of your average customer

- e.g. AT&T had a small group that established a set of telephony services that they identified as representative of the customer base... derived from focus groups, surveys, etc

 

Question: how do you know when you're done?  iterating, that is

- "It's been 3 months"

- you have enough to get started

- you have identified a number of failure modes and exception scenarios

- "You don't want to spend 2 years collecting gathering requirements.  Well, unless they've given you a lot of money, then... well..."

 

 

STATUS REPORT: COMPUTER-AIDED PROTOTYPING (Luqi & Royce)

MEASUREMENT AND EVALUATION

- How well do the requirements satisfy customer needs/wants?

e.g. advertising for prescription drugs... clearly pharmaceutical companies are trying to create the desire in the customer market...

  * written word can be abstract

  * prototyping

    - concrete realization

    - immediacy

    - reifies abstract descriptions ("reify means to make concrete - like the trucks...")

  left turn:  "you guys are in software, but i don't understand, why do you want to keep destroying your stuff?  you're talking about demoing it"

  2nd left:  "look up words... enervate, fulsome, etc"

  ahh, linking computers to philosophy... the study of logic

  u-turn:  fuller's earth - a fuller is someone who cleans cloth, fuller's earth is a diatomaceous clay, one of the strongest cleaning agents for a long time

  dead end:  gary owens made up a word, insigrevious

    - incremental refinement and evaluation

    - assess feasibility and effectiveness

    - effective prototypes must be: rapidly built, iteratively and measurably improved

    - cobble cobble cobble

    Q: how do you measure that improvement?

    A: generally difficult in software, usually has to do with behavior, congnition;

    emprirical studies course covers how to do this (next semester)

 

SYSTEM VS SW PROTOTYPING

- different system context - realtime constraints

- behavioral models

- different hardware context - simulation or test hardware

 

THROWAWAY VS EVOLVING

- Brooks- we should always throw one away

- Perry - we never do, prototype code should require a DNR

- throwaway seems like wasted effort

- necessary for understanding/evaluating requirements - insight=>knowledge=>judgement

- evolving systems must implement with efficiency, performance, and reliability

 

APPROACHES

- languages: quick/dirty hack, functionality without hard work

- reuse/generation - quick assembly

- domain models - consolidated concepts, w/underlying stuff to implement

** Most often, LACKING domain understanding for most prototype needs

- autoretrieval (red herring) - finding the right piece is... important, and difficult

- go beyond keyword attribute approaches

- generation

- decision support systems (data mgmt, graphics user interfaces)

 

- Boehm's Spiral Model : incremental spiral development model,  P=>R

 

>> Guy who invented lithium batteries (John Goodenough) is here, 81-yrs old; just won Japan award recently, doing great.

 

*** B R E A K ***

 

THE WORLD AND THE MACHINE

(Michael Jackson)

 

1. Introduction

We make physical devices to serve practical purpose in the world (Lehman)

Software:  a description of a machine (hardware base + extension in software) in the world

- It is judged not by its internal structure, but by how well it performs

- Requirements are in the WORLD (Problem)

- Solution is in the MACHINE

 

2. Four Facets of Relationship

- Modeling - machine simulating the world

- Interface - world and machine touch

- Engineering - machine controls the behavior of the world

- Problem - shape of the world/problem influences the shape of the machine/solution

 

>> E.g. in the software world, hierarchy is overemphasized, and thus integrated into almost every solution, when a better solution would utilize the concepts of networking, singleton, collaboration, etc.

 

2.1 Modelling

- data, process, object, cooperation

- access to information about the world

- captures only part of truth (because it is impractical to get all of the truth)

- goal is to get the intersection of DM (description of machine) and DW (world)

 

>> "Inanimate objects are great to ascribe blame to... because they don't deny it"

 

2.2 Interface

- Interaction is defined as shared phenomena (between world and machine)

- not equal, not symmetrical

- some initialized in world, some in machine (V=some)

- shared events and states - lock world and machine in partnership

- intersection of phenomena of world PM (phenomena of machine and PW (world)

 

>> www.addall.com is a book search site for amazon, borders, b&n, used books

 

2.3 Engineering

- Requirements:  concerned w/PW

- Programs: concerned w/PM

- Specifications: intersection of PW and PM

 

- Engineering is the refinement of a requirement to a specification

e.g. R: on_runway <-> can_reverse (a plane can engage reverse thrust iff on runway)

 PM-PW: pulsing (sensors) <-> rotating (sensor signal pulses when wheels are rotating)

    PW: rotating <-> on_runway (if wheels are rotating, plane's on the runway)

 

     S: pulsing <-> can_reverse (if sensor pulses, reverse can be engaged)

 

The spec is correct if it is the enabler for the fulfillment of the requirement, based on the phenomena of the world.  There can be problems in the world or machine domain, that can cause breakdown of the specification.  Foreseeing this means having knowledge of the problem domain.

e.g. PW did not hold when the plane landed and began to hydroplane.  Wheels did not rotate, pulsing did not occur, reverse thrust could not be engaged.

 

2.4 Problem

- Problems are often complex, requiring careful structuring and decomposition

>> To him with the hammer, everything is a nail.

>> Neighbors friend from HK sold great wool suits very cheap; problem was the fit was bad, left arm and leg were too short, right arm and leg too long; the HK guy suggests that the customer adjust his walking style to make the suit fit.  Later on a couple of strangers see him hobbling about, and the woman says "oh, the poor guy" and the guy says "yeah, but boy, does he have a great tailor."

- We expect to be able to structure the problem, and then structure the machine based on the structure of the problem (structure of P -> structure of M)

- However, it is difficult to separate P from S (problem from solution), because of distinction between the spec and implementation, because of relationship between machine and world

- Complex problems cannot be effectively structured as a a) hierarchy or b) homogeneous decomposition

>> For every problem, there is a very simple solution that is wrong (or impossible)

>> The indolent programmer (lazy) is somebody who does "just enough"

- A problem should be broken down into known, soluble problems.

 

3.  Denial

- Requirements - elicitation, description, analysis

- Relationship between world and machine create conflicts

- Developers pay more attention to machine

- Developers justify their inclination through denial

 

3.1 Denial by Prior Knowledge

- Problem class has been standardized

 

3.2 Denial by Hacking

- obsessive devotion to interacting with computers

- sense of power to create, build, control

- result - going completely overboard with new things, just because we can

- one-upsmanship

>>"Two hours on speakerphone is... quintessential meaning of boredom, nothing is more mind-numbing"

 

3.3 Denial by Abstraction

- consider machine as mathematical object, previously solved

- machine is NOT in essence mathematics

 

3.4 Denial by Vagueness

 

4.  Description

- von Neumann's

- reductionism

- Shanley's

- Montaigne's

 

4.1 von Neumann's

- clarify concepts and issues - establish vocabulary

  * ground term for PW & PM

  * recognition rule for each term

  * formal term by which we refer to it

 

4.2 Reductionism

- choosing phenomena for which we have exact and reliable recognition rules

  * choose the simplest phenomenon

  * build up other terms from them

 

4.3 Shanley's Principle

- rule for efficient design

- single point of failure - dangerous

- elementary level - not strongly typed

 

4.4 Montaigne's Principle

- indicative mood - assert to be true

- optative mood - desire to be true

- it is best in our structured descriptions to separate the two

 

 

 

*** B R E A K ***

 

FOUNDATIONS FOR THE STUDY OF SOFTWARE ARCHITECTURE

(Perry, Wolf)

 

3.1  Introduction

Software Architecture - components, form, rationale

- Components:  data, processes, connectors

  * Connectors may be data or processes, or appear to be so

  * These days, data+processes => components (hence components and connectors)

- Form:  how components interact with each other

  * interactions

  * constraints

- Rationale:  providing underlying basis for components and interactions/constraints

  * derived from models, from requirements, from phenomena of world/machine

- Architecture can be looked at prescriptively or descriptively

- Prescriptively - essential characteristics... what is specified must be satisfied, everything else is up to the designer

 

3.2 Style

- capture essential characteristics

>> Design patterns are smaller-scale

- codification (?)

 

4.1 Examples - multi-phase architectural style

(Compiler)

- 5 phases:  L, P, SA, O, CG

L => lexer

P => parser

SA => semantor

O => optimizer

CG => code generator

 

- data elements: C, T, P, CP, ACP, OC

C => character

T => token

P => phrases

CP => correlated phrases

ACP => annotated phrases

OPC => object code

 

4.2  Sequential Architecture

- classical multi-phase compiler

- connecting elements: procedure call and parameters

- abstract syntax tree (AST) -

>> Multiple styles are often integrated e.g. Seq + MP, CCP + PC

 

(Hrmm.  I'm lost.  Must re-read paper.)

 

- comparison to building architectural style

Georgian style - symmetry, door in the center, 1st floor has a height > height of 2nd floor, etc, width proportionate to height, but it's up to the builder to actually execute etc

Phase-compiler style - the phases are established, the dependencies are known, but no detail on exactly how these phases and dependencies are implemented; the simplest set of requirements at the solution level

 

 

GOAL of Software Architecture

- to establish a codified set of styles (reference architectures) for a given domain

 

 

HOMEWORK:  Due 2/21, hard copy, 1/2 page, 2 paragraphs

"An important lesson in Parnas/Clements is..."

"It is important because..."