0707.321 Principles of Software Engineering

Chapter 7: System Models

System model

Diagrams that help in the specification of system requirements

Context model

Identifies the boundary between the system and its environment (typically, other systems)

Architectural model

Identifies the principal sub-systems of the system

Behavioral models

Descriptions of system behavior

• Data-processing model (Data-flow diagrams)
  System as "assembly line", processing data at different stages
• State machine models (aka statecharts)
  System as single machine moving from state to state

Data models

Descriptions of data organization

• Semantic Data Model
  Describes logical structure of data (Eg., entity-relationship-attribute model)
• Object model
  Object-oriented perspective, includes:
  • Inheritance models (class hierarchy)
  • Aggregation models ("object is composed of these other objects")

Chapter 8: Prototyping

Throw-away prototype

A tool to help with the development of system requirements, the concrete artifact complementing the mental visualization. It is useful when the requirements are (initially) poorly understood.

Evolutionary prototype

Prototype developed quickly and modified as requirements are refined, ultimately becoming the production system.

Component Assembly

Prototype is built out of pre-existing components which are integrated using a common control and communications framework

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

Client/Server (C/S) Architectural Layers

1. Presentation (to user)
2. Application processing
3. 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

Peer-to-peer (P2P) Model

Clients can communicate with each other without involving server

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

Object-Oriented Development

Integrated process featuring:

• Object-Oriented analysis (requirements analysis in terms of interacting objects)
• Object-Oriented design
• Object-Oriented programming

Object-Oriented design

Stages of design:

1. Define context and modes of use
2. Design system architecture
3. Identify principle objects
4. Design/model principal objects
5. Specify object interfaces

Information Hiding

Reduces complexity; 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

Components implementing a single function (Eg. mathematical functions, standard program libraries)

Application reuse

Incorporating applications wholesale into larger system; application families

Component reuse

Can occur at various (component) granularities

Assumptions for software development based around reusable components

• Must be possible to find appropriate reusable components
• The reuser of the component must be confident that the components will be reliable and will behave as specified
• The components must be documented so that they can be understood and, where appropriate, modified

Guidelines for developing reusable components

• Should reflect stable domain abstractions
• Should hide state representation
• Should be as independent of other components as possible
• 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)

Design Patterns

Predefined abstract designs for components. Leverage object-oriented language principles.