0707.321 Principles of Software Engineering

Chapter 9: Formal Specification

Algebraic specification

Where the system is specified in terms of its operations and their relationships.

Model-based specification

Where the system is specified in terms of a state model (in mathetmatical terms) and modifications to that state.

Chapter 10: Architectural Design

System Architecture

High-level description (in diagrams and text) of complex software system. Answers questions like:

• What are the primary subsystems?
• How will the subsystems communicate?
• What will the subsystems communicate?

Subsystem

A system in its own right whose operation does not depend on services provided by other systems.

• Composed of modules
• Have defined interfaces used for communication with other subsystems
• Often reused in design/implementation of multiple software systems

Repository (Structural Model)

Shared data stored in centralized location (repository); other subsystems access data there, and communicate indirectly through it.

Passive Repository

Control is responsibility of subsystems. Look to repository for data only.

Active Repository / Blackboard model

Repository is in control, subsytems triggered when particular data becomes available

Pipeline (Structural Model)

Simplification of repository; each subsystem passes its result data into the next one in the pipeline

Client/Server (Structural Model)

Subsystems viewed as independent processes; shared communication medium; server provide services; clients communicate only with servers; servers can service other servers.

Abstract Machine or Layered Model (Structural Model)

Each subsystem defines an abstract layer; each subsystem implemented in terms of subsystem in the layer "below".

Centralized Control Model

One subsystem (system controller) responsible to managing execution of system as a whole. Two subclassifications:

Call-Return Model

Traditional top-down subroutine model. (Sequential execution implied.)

Manager Model

Subsytems runs as separate processes; managing subsystem starts/suspends/stops others. (Concurrent execution implied, but can be adapted for sequential execution as well.) Managing subsystem can poll subsystems (sensors, etc.) for event or state changes.

Event-based Control Model

No master controller; subsystems react to external events (eg. other subsytems). Two subclassifications:

Broadcast Model

Event broadcast to all process/subsytems; or (if supported), special event handler process forwards event notice to appropriate (registered) subsystem

Interrupt-driven Model

Hardware-supported; real-time application; triggering of interrupt event causes control to pass to the interrupt handler registered in appropriate slot of interrupt vector.

Generalized Domain-specific Models

Abstracted from a number of real systems in domain, encapsulating common, principal characteristics of these systems.

Reference Models

Idealized architecture for a target domain. Often a basis for a system implementation. (eg. OSI (7-layer) network model)

Chapter 11: Distributed System Architectures

Distributed Systems

Software system running on multiple computers. Computers may be:

• close or distant
• homogeneous or heterogeneous (hardware and software)
• collectively or separately managed

Features

• Resource sharing
• Openness
• Concurrency
• Scalability
• Fault tolerance
• Transparency

Disadvantages (increased...)

• Complexity
• Security
• Manageability
• Unpredictability

Client/Server (C/S) Architectural Layers

• Presentation (to user)
• Application processing
• Data management
  2-Tier C/S - Thin Client
  Server does data management and application processing; client only does presentation
  2-Tier C/S - Fat Client
  Server does data management; client does application processing and presentation
  3-Tier C/S
  Separate servers for application processing and data management

Distributed Object Architectures

System viewed as collection of distributed objects; no client/server distinction among processes; each process represented as an object; communication is via an "software bus", an existing component (middleware) that can be acquired. (Eg. CORBA, Java Remote Method Invocation, MS DCOM, MS .NET.)

Chapter 12: Object-Oriented Design

Information Hiding

Implementation details unimportant at "next highest level"

Generalization and Inheritance

Identifying what different classes of objects have in common. Putting common functionality (state) in superclasses.

Chapter 14: Design with Reuse

Function reuse

Eg. code libraries

Application reuse

Incorporating applications wholesale into larger system

Component reuse

Can occur at various (component) granularities

Benefits of component reuse

1. Increased reliability
2. Reduced process risk
3. Effective use of programmer specialists
4. Accelerated development
5. Standards compliance

Problems/Tasks

1. Risk of increased maintenance costs
2. Lack of CASE tool support
3. "Not-invented-here" problem
4. New task: maintaining component library
5. New task: finding and adapting resuable components

Guidelines for developing reusable components

1. Should reflect stable domain abstractions
2. Should hide state representation
3. Should be as independent of other components as possible
4. Should publish exceptions

Code Generators

Programs that take user input (via form completion or instructions in "mini-language") and generate compilation units. Reusable knowledge encoded in programs. Domain-limited. Best examples: parser generators (eg. lex & yacc), CASE tool code generators (UML <-> class definitions)

Application Families (a.k.a. product line)

A related set of applciation sharing a domain-specific architecture. Common core reused during development of new specialized application.

• Platform specialization
• Configuration specialization (eg. localization, different peripheral devices)
• Functional specialization (eg. restricting functionality for cheaper produce releases)