Design and Architecture Notes, Lecture notes of Computer System Design and Architecture

Download Design and Architecture Notes and more Lecture notes Computer System Design and Architecture in PDF only on Docsity!

Overview - Design

• Introduction to Design
• Architectural Design
• Modules
• Structured Design
• Objects
• Object-Oriented Design
• Detailed Design
• Integration Testing

Goals and Objectives

• Develop a coherent representation of a software

system that will satisfy the requirements

• Identify inadequacies in the requirements
• Can develop review plan that demonstrates

coverage of the requirements

• yields confidence in design
• Can develop test plan that covers design
• yields confidence in both design and implementation

Relationship to other lifecycle phases

• Requirements
  • Specifies the “app domain” not the “machine”
  • Provides conceptual boundaries € keeps design focused
• Implementation
  • When design specifications are sufficient for coding

assignments (now it can be “executable” on a machine

€ each assignment, theoretically, can be given to a programmer unaware of the overall system architecture

• and the code will satisfy the associated requirements

Basic Design Process

• The design process develops several models of the software

system at different levels of abstraction

• Trial and Error in many ways
• Starting point is an informal “boxes and arrows” design
• Add information to make it more consistent and complete
• Provide feedback to earlier designs for improvement Informal design outline Informal design More formal design Finished design

Design Activities

• Architectural design
  • Subsystem identification € services and constraints are specified
  • Module design € modular decomposition is performed; relationships specified
• Detailed design
  • Interface design € module interfaces are negotiated, designed and documented
  • Data structure and algorithm design € module details (data structures and algorithms) to provide system services are specified

Design Products

• Refined requirements specification
• Description of systems to be constructed
  • software architecture (diagrams and rationale)
  • modular decomposition (hierarchy)
  • abstract module interface specifications
  • detailed module designs
• Documentation of decisions and rationale
• Data dictionary of all defined objects
• Validation review plan
• Integration test plan

Architectural Design

• Architectural Design
  • decomposition of large systems that provide some related set of services + establishing a framework for control and communication
• Architectural styles establish guidelines
  • a relatively new area of research
• No generally accepted architectural design process (Well,

maybe UML, Rational Unified Process…)

• some important sub-processes € System structuring: structuring of the system into a number of subsystems, where a subsystem is an independent software unit € Control modeling: establishing a general model of control relationships between the parts of the system € Modular decomposition: decomposing each identified subsystem into modules

Architecture, Subsystems and Modules

• Architecture consists of interacting subsystems € describes the subsystem decomposition in terms of subsystem responsibilities, dependencies among subsystems, subsystem mapping to hardware, and major policy decisions such as control flow, access control and data storage. (Bruegge)
• Subsystems
  • a component whose operation does not depend on the

services provided by other subsystems

• communicates with other subsystems via defined

interfaces

• is further decomposed further into modules during design

Software Architecture

• Components (subsystems)
  • The elements out of which the system is built
  • Examples: filters, databases, objects, ADTs
• Connectors
  • The interaction or communication mechanisms
  • The glue that combines the components
  • Examples: procedure calls, pipes, event broadcast,

messages, secure protocols

• Constraints
  • Limitations on the composition of components and

connectors

Architectural Style

• Example architectural styles
  • Batch sequential
  • Pipe and filter
  • Main program and subroutines
  • Blackboard
  • Interpreter
  • Client-server
  • Communicating processes
  • Event systems
  • Object-oriented
  • Layered Systems

Families of systems defined by patterns of composition

Architectural Design:

Control Modeling

• Control of subsystems so that services are delivered

to the right place at the right time

• Two general approaches
  • Centralized control € One subsystem has overall responsibility for control and starts/stops other subsystems - call-return model (sequential) - manager model (concurrent)
  • Event-based control € each subsystem responds to externally generated events (from other subsystems or the environment) - broadcast model - interrupt-driven model

Simple Overview (very basic Architecture)

• Design major subsystems
  • use UML, class diagrams, event trace or sequence

diagrams

€ don’t forget the error handling subsystem

• keep #subsystems small (5 to 9 rule of thumb)
• keep communication between subsystems to a minimum
• explain what each subsystem does
• Traceability matrices
• show allocation of requirements to subsystems
• show subsystems and the requirements they handle € assign a requirement to to as few subsystems as possible
• why? (coupling and cohesion, covered later in modules…)

Architecture should address:

• external interfaces, user interface
• db if needed, other data storage issues
• key algorithms
• memory management, key string storage (such as error

messages)

• concurrency
• security
• localization
• networking
• portability
• programming language
• error handling

Architecture Documentation

• System Overview
• Architectural Goals and Constraints
• Subsystems and Organization
  • diagrams and rationale
• Can find templates on line if you wish