CS 2340 Exam 1

Fault (bug)

Related to the code.

Necessary (not sufficient!) condition for the occurrence of a failure

Use Cases

a collection of related success and failure scenarios that describe actors using a system to support a goal

Types: brief, casual, fully-dressed

UP iteration length

The UP recommends that an iteration should be 2 to 6 weeks

Inspection (Verification)

systematic group review of program text to detect faults

Testing Granularity

Unit Testing

Integration Testing

System Testing

Acceptance Testing

Regression Testing

Scenario (Use Cases)

specific sequence of actions and interactions between actors and the system under discussion

Supporting Actor

provides a service to the system under discussion

Offstage actor

has an interest in the behavior of the use case

Entity Class (robustness diagram)

a class from the domain model

Controller Class (robustness diagram)

a class representing business logic

Unified Modeling Language (UML)

A language based on object-oriented concepts that provides tools such as diagrams and symbols to graphically model a system. Helps create software "blue-prints"

Object Oriented Analysis

Focus on the problem and finding and describing objects in the problem domain

Object Oriented Design

Focus on finding a conceptual solution that fulfills the requirements - define software objects and how they collab to fufill requirements

Designs are implemented in a programming language

Unified Process (UP)

An object-oriented system development methodology

goal: enable the production of software that meets user needs within predictable schedules and budgets

software development process

an approach to building, deploying, and maintaining software

iterative development

Development is organized into a series of short fixed-length mini-projects called iterations

iteration

represents a complete development cycle; includes its own treatment of requirements, analysis, design, implementation and testing activities.

The outcome of each iteration is a tested, integrated and executable system

Embracing change

Stakeholders have changing requirements.

Iterations lead to rapid feedback and an opportunity to modify design.

Timeboxing

Iterations are fixed in length

Phases of the Unified Process

Inception, Elaboration, Construction, Transition

Inception

Define the scope of the project

determine initial vision & feasibility

What happens in Inception?

requirements workshop, most actors, goals, and use cases named, and plan for first iterations, etc.

Artifacts started in inception

vision, business case, Use Case model, supplementary specification, glossary, risk management plan, proof-of-concept

Use Case model

describes functional requirements and related non-functional requirements, set of typical scenarios of using a system

Black-box use cases

describe system responsibilities - i.e. what the system must do

Use case formality types

Brief (one paragraph summary), Casual (informal paragraph), Fully dressed (elaborate, detailed)

Supporting actors (use cases)

they provide a service

Primary actors (use cases)

have user goals

Elaboration

Plan project, specify features, baseline/risky architecture

What happens during elaboration?

core, risky architecture is programmed, majority of requirements are discovered, major risks are mitigated

Construction

Build the product

Transition

Transition the product into end user community

Milestone

Each phase and iteration concludes with a well-defined milestone

The UP Disciplines (process)

Business modeling, requirement, analysis & design, implementation, test, and deployment

The UP Disciplines (supporting)

Configuration management, management, environment

Disciplines

In an iteration, you will walk through all disciplines - relative effort and emphasis changes over time

Advantages of an iterative process

reduce risks, get a robust architecture, handling evolving requirements, allows for changes, attain early learning

System Sequence Diagram (SSD)

a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order, and possible inter-system events

System behavior

All systems are treated as a black box; the diagram places emphasis on events that cross the system boundary from actors to systems

Domain Models

illustrates meaningful concepts in a problem domain.

It is a representation of real-world things, not software components.

has conceptual classes in UML, associations, and attributes

Conceptual Classes (Domain models)

has a symbol, intention, and extension

Attribute (Domain models)

Logical data value of an object

If we do not think of some conceptual class as a number or text in the real world, it is probably a conceptual class (else an attribute)

Description Classes (Domain models)

contains information that describes something else

added when there needs to be some description about an item independent of the current existence of those items

Association (Domain models)

a relationship between classes that indicates some meaningful and interesting connection

Naming Associations (Domain Models)

ClassName-VerbPhrase-ClassName

Association Roles and Multiplicity (Domain Models)

Each end of an association is called a role.

Roles may have multiplicity, name, and navigability

Multiple association

Two classes may have multiple associations between them in UML class diagrams

What happens during the construction phase?

Builds the remainder of the system

testing during constructions is referred to as "alpha testing" - performed at developer's site

What happens during the transition phase?

purpose is to put the system into production use

testing during transition is referred to as "beta testing" - performed at a client's site

Waterfall lifecycle

Sequential stages, each stage must be completed for the next to follow

Problems with waterfall lifecycle

tackling high-risk or difficult problems late, requirement inflexibility

What are requirements?

System capabilities and condition to which the system must conform

Functional require

Features and capabilities, recorded in Use Case model

Non-functional requirements

Usability, Reliability, Performance, Supportability, recorded in the Use Case model or in the Supplementary Specifications

How are requirements organized in the UP artifacts?

Use Case Model, Supplementary Specification, Vision, Business rules, and Glossary

Where do requirements come from?

Stakeholders, application domain, documentation

requirement elicitation

Thin spread of domain knowledge, knowledge is tacit, limited observability, bias

Traditional techniques for finding requirements

background reading, hard data and samples, interviews, surveys, and meetings

Analyzing Requirements

Verification, validation, and risk analysis

Requirements prioritization

limited resources, inability to satisfy all the requirements, need to prioritize them

Requirements engineering iterative process

elicitation, negotiation, modeling, and analysis

Failure

Observable incorrect behavior of a program.

Conceptually related to the behavior of the program, rather than its code.

Error

Cause of a fault.

Usually a human error (conceptual, typo, etc.)

Testing (Verification)

exercising software to try and generate failures

Static verification (Verification)

identify (specific) problems statically, that is, considering all possible execution

Formal proof (verification)

proving that the program text implements the program specification

Testing

To execute a program with a sample of the input data

Alpha v. Beta testing

Alpha testing happens with in the organization and Beta testing is outside of the organization

TDD

Write test code, write functional code, and refactor

Structure of tests

Set fixture, invoke, check, and cleanup

Actor (Use Cases)

something with behavior

Use Case Model

set of all written use cases

includes the optional Use Case Diagram

Primary Actor

has user goals fulfilled through using services of the system under discussion (SuD)

Elementary Business Processes (EBPs)

a task performed by one person in one place at one time which adds measurable business value and leaves the data in the consistent state

Focus on the use cases at the level of EBP

Essential Style (Use Cases)

Focus is on intent; avoid making UI decisions

Concrete Style (Use Cases)

UI decisions are embedded in the use case text

Robustness diagram

bridge the "What/How" gap

Boundary Class (robustness diagram)

a user interface or API class to external system

represent potential screens

UI Designers

UI designers create prototypes of potential screens

create flow diagram to show how screens flow in application

When are Sequence scenario diagrams created?

Most created during elaboration

Sequence Diagrams

Can manage complex interactions with sequence fragments - loop (iteration), alt (alternatives), opt (option), and ref (reference)

Robustness object interactions

Entity, Boundary - nouns; Controller - verb

1. Nouns & Verbs can talk

2. Verbs & Verbs can talk

3. Nouns & Nouns cannot talk