Introduction to Software Engineering

General Format and Scope

Format. The exam will consist primarily of short answer questions along with a few true/false or multiple choice questions.

Scope. The exam will focus on the lecture notes and in-class discussion. This is backed-up by your readings in Schach and Brooks as well as your preparation and learning experiences from all assignments and the basic material on UML in Fowler.

NOTE: this review sheet is not a substitute for looking at the notes or reading the book!

Specific Materials Covered
The material covered before the midterm exam,which is summarized in the midterm study guide, is "fair game" for he final, although the emphasis will be on the material covered after the midterm. Be aware, however, that this more recent material depends on the earlier material, and synergizing the relationships between topics is an important aspect of understanding the discipline of software engineering.

1. Lecture Notes: topics 8 through 14.

2. Assignments four, five, and six.

3. Schach text (sections as indicated in the schedule): chapters 2, 3, 5, 6, 10, 11, 12, 13, 14

4. Brooks, The Mythical Man-Month: complete

5. Fowler, UML Distilled: chapters 1, 3, 4, 6, 8

Design

Goal is to develop a coherent representation of software that will satisfy requirements and provide a blueprint for implementation

Design should be uniform, complete, rigorous, confirmable, desensitized to change, flexible, independently developable

Design starts when how is specified and continues until coding assignments can be made

Design must include a review plan for yielding confidence in design

Design must include a test plan for determining whether implementation is consistent with design and providing further assurance in design

Design process moves from informal design to formal design

Design process develops several model of the system at different levels of abstraction

Design Guidelines

Structure based on hierarchy and abstraction

Information hiding and abstraction are key

Modular decomposition is the result of architectural design

What is a module?

Design Methods

Most methods follow same basic steps

Function-oriented design considers system as interacting functions

Object-oriented design considers system as objects with state and methods to inspect and modify objects

Architectural Design

Architectural design is the decmposition of large systems into sub-systems that provide related services; the architecture provides the framework for sub-system control and communication

System structuring: three standard structures

Control modeling: two general models

Modular decomposition: two basic approaches

An integration test plan should be devloped as part of achitectural design for exercising module and sub-system interactions

Object-Oriented Design

Object-Oriented Analysis and Design

Class defines a set of objects along with common operations and attributes

Object-oriented concepts: instantiation, aggregation (consists of), generalization and inheritence, polymorphism

Object Modeling Technique

OMT phases: object-oriented analysis, system design, object design, implementation

OMT Models: object model, dynamic model, functional model

Object Model: identify objects, associations and links, class attributes and operations, inheritence relationships (as well as a d ata dictionary of sorts)

Dynamic Model: identify scenarios and events between objects, event trace diagrams, state diagrams

Functional Model: identify inputs & outputs, data flow diagrams, function descriptions, object constraints

What are the model relationships?

Formal Methods and Specifications

Formal specification can be used from requirements specification through preliminary and detailed design

Formal specification languages have precise syntax and semantics

Benefits include verifiability, comprehensibility, automatability, analyzability, testability

Hesitation due to lack of experience, high learning curve, lack of automated support

Formal specification languages define syntax, semantics, exceptions

Formal specifications are either behavioral or structural

Approaches to behavioral specification include algebraic, abstract model, state transition, axiomatic specifications

Algebraic Specifications

Objects specified as sorts (types) in terms of relationships between associated operations

Sorts can be hierarchically composed

Specification includes signature (syntax of the sort and the operations) and axioms (semantic relationships between the operations)

State is concealed in objects, operations include access and constructor (destructor) operations

Axioms are usually needed for each access operation over each constructor operation

Abstract ModelSpecifications

System modelled in terms of well-defined mathematical entities, where objects and operations specified in terms of effect on the model

Objects and operations can be hierarchically composed

Specification includes signature (syntax of the entities in terms of model), and predicates (describing properties in terms of model operations)

State is made explicit

Verification and Validation

Critical need to produce high quality software, where quality is a many-attributed property

Verification vs. validation - what is the difference?

Proof of correctness has many deficiencies (some of which testing can address)

Testing's primary goal is failure detection via execution on selected test data and comparison with test oracle (but also provides quality assurance if done properly)

Testing is typically capable of assessing many requirements-based qualites simultaneously

Some qualitites require other sorts of analysis

Verification, validation and testing must permeate the lifecycle and require planning and documentation

Testing

Testing selects subsets of test cases likely to reveal failures by an activity akin to "equivalence classing"

Testing has four fundamental questions: what should we test? are the test results correct? when can we stop testing? what approach and techniques shall we use?

these correspond to test criteria, test oracles, test adequacy, and test process

Functional testing is black-box

Structural testing is white box

Software Process

Quality products require formalized process

Process is a means of deriving product, where a process description represents many processes and each process instance derives a product instance

Software Process is a means of developing and evolving software products

Software development process is software, too, and should be developed by a "process" development process (as opposed to a product development process)

Software process consists of requirements, design, code, test cases, analyses

Process Models have changed with the development of the discipline of software engineering and no process is suitable for all development efforts

What is the ICS 121 Software Development Process?

The CMM (capability maturity model) is a strategy for improving the software process (irrespective of the process model) based on improving technology and management

ISO 9000 is an attempt to improve software quality by stressing documenting the process, committing to quality, training developers, and measuring the process and product

Mythical Man-Month

Large programming projects suffer management problems, whereas smaller ones do not, due to the division of labor involved

Must preserve conceptual integrity of the product through exceptional design (lead and team)

Primary "myths"/problems:

There's no silver bullet, but great designers help