What is Design?What is Design?

Conceptual – covers function of the system. Based on requirements.

Technical – used by system builders to implement the system. Based on tech. spec.

Conceptual Design QuestionsConceptual Design Questions

1) Where does the data come from and where does it go to?

2) What happens to the data?3) System look and feel?4) What kind of UI?5) What parameters are configurable?6) Timing / synchronization

considerations?Answered in requirement document!

Decomposition & ModularityDecomposition & Modularity

Decomposition makes complex task look simple (first tool of abstraction).

Modular – task split into components that are assigned functions

Data-oriented – reflects external data structures

Event-driven – reflects state transitions guided by external events

Black-box – functionality defined by a set of inputs and matching outputs or input transformation rules

Object-oriented – contains classes and relationships

Design StagesDesign Stages

1) Choose decomposition method

2) Come up with software architecture

3) For each module, class or component execute program design (including decomposition and coding considerations)

Pipes and FiltersPipes and Filters

Information-flow oriented design.

Data is organized in streams aka pipes.

Data transformation is accomplished via filters.

Each filter can have multiple inputs and multiple outputs.

Example: media codecs, network services.

Data-OrientedData-Oriented

Applies to data analysis, data retrieval, or data collection tasks.

Requires database system and data modeling. Typically each database entity has a corresponding code-level entity (e.g. class, object, data structure).

Example: most database apps such as student records, simple accounting, data-driven decision making.

Object-Oriented Design (OOD)Object-Oriented Design (OOD)

Entity-oriented design. Works best when the task at hand deals with multiple related entities with sufficient generality or common behavior among them.

Begins with identifying entities. Then constructing use cases. Then class diagrams. Then generalizing abstract / base classes and working out their interfaces.

Example: vector graphics software (each shape an entity), music software (synth modules & tracks can be generalized).

Event Handling (Implicit Invocation)Event Handling (Implicit Invocation)

Applies to asynchronous or event-driven systems (i.e. software service).

The system is decomposed in event sources and event sinks (event handlers). Events are identified and relationships between event sources and event handlers are established (including event conditions and parameters).

Example: embedded software, network / web services, Windows messaging.

Layered DesignLayered Design

Applies to hierarchal processes.Basic task is wrapped in several layers of

specific functionality.Makes sense when various nested levels

required direct access by eligible components.

A subset of OOD in the sense that there is a single base class and a non-branching sequence of derived classes.

Example: OS security – cryptography API file-content encryption key manager access authentication.

Process Control DesignProcess Control Design

Applies when a particular parameter (generally process outputs) must be maintained near a specified reference value aka set point.

Feedback Loop Design

Feed-forward Loop Design

Example: manufacturing / machinery control (including embedded systems).

Client-ServerClient-Server

Traditionally any kind of application that accesses remote data.

More recently – an application involving centralized processing or remote access to computational services.

Application servers – host computational services (applications).

Strictly speaking client-server is a subset of distributed design where all server-side actions happen in one location.

DistributedDistributed

Application is comprised of several components installed on different servers that may or may not belong to the same datacenter.

There are may or may not be users. Technically “users” could be service requests originating from other applications.

Popular interfaces for linking components of distributed applications: XML Web services, COBRA, Java / .NET Remting (RMI), RPC, DCOM (kind of obsolete)

3-Tier3-Tier

Presentation = UIBusiness Logic = all the algorithms and decision makingDatabase = source data

FadsThin client (e.g. HTML, X-Window, Remote Desktop, etc.) -

minimum computing on client side; presentation formed by server; client handles display only (no validation)

Fat client (e.g. Windows Forms, JScript, etc.) some processing happens on client-side to save bandwidth / boost performance (entry data validation, adhoc calculations)

Database everything (‘flat files’ are no longer used)XML everything (binary files are no longer used)Web everything (communications has to occur via HTTP).

5-Tier5-Tier

1) UI InterfacePresentation =

2) UI Façade3) Business Logic

4) Data Mgmt FaçadeData =

5) Data Mgmt Component

The idea is to minimize dependencies between the presentation, business logic and data layers. The goal to achieve total layer interchangeability.

Business logic deals with DM and UI façade via generic interfaces that are DM and UI independent.

DM and UI façades create an extra level of complexity, thus one must evaluate the cost saving benefit of going 5-tier.

In practice, when do we need such interchangeability?

Modularity & Abstraction IssuesModularity & Abstraction Issues

Too many modules?

Use hierarchal module structure

Too many levels of abstraction?

Overkill, reduce

Tools of Abstraction

Grouping related entities, and

Hiding unnecessary detail

Collaborative IssuesCollaborative Issues

Common design principles is a mustPartitioned design compatibility must be

evaluatedCommunication!Prioritization a mustKeeping track of progress & deferred

problemsDevising compatible interfacesIs outsourcing a good idea?

Distributed Project StagesDistributed Project Stages

1) All developers must congregate at one site to form a team

2) Requirements are gathered and analyzed, each regional group receives spec and begins development

3) The team separates into regional groups that keep working on their own delivering generic modules

4) Once modules are complete group representatives get together for integration testing

User Interface DesignUser Interface Design

1) Uncluttered2) Design for short attention span3) Fool-proof4) Eye-catching most important things5) Get to the point quickly and in as little steps as

possible6) Ask only for what’s really needed7) Consistent behavior (including navigation)8) Provide go-back / undo9) User acceptance tests must be scheduled regularly

to validate UI design10) Localization (more important now)11) Customizability (fonts, views, colors)

Concurrency IssuesConcurrency Issues

Concurrency is good, but synchronization is difficult!

Synchronization tools:- mutexes (aka semaphores, used with monitors)- wait handles- locks (on data)- timers- critical sections

Exploit Design PatternsExploit Design Patterns

Common aspect of design / code structure.Examples:

- declaring vars at the top- providing accessor methods for class properties- always initializing database objects in the same way- structuring your code in the same way

Always follow predictable pattern! It will help you (and others) analyze and complete the code by providing consistency and eliminating surprise factors.

Minimize InterdependenceMinimize Interdependence

Component interdependence is a source of complexity and errors linked to unexpected / unpredicted behavior.

• Do not use global variables• Minimize state information (state is

the source of unpredictability)• Pass all necessary data to

subroutines whenever possible• Explicitly declare state (or external)

dependencies

Types of CouplingTypes of Coupling

• Data coupling: when component passes general data to another OK

– Stamp coupling: when component passes complex structured data to another OK

• Control Coupling: when component passes data or flags to control the behavior of another component OK

• Content coupling: when component modifies state of another component, OK when predictable design patterns are followed

• Common coupling: components share global data NO

Coupling IssuesCoupling Issues

Complete uncoupling is impossible.There has to be a balance between stamp

coupling and content coupling: it is inefficient to pass stamp parameters all the time, yet relying on component’s state may be dangerous.

Solution: rely on language means and comments to enforce design pattern and provide means for notifying developer of component state changes. Employ language means to designate state-agnostic (i.e. const) methods.

Cohesion TypesCohesion Types

Grouping related things togetherCoincidental – no reason for grouping BADLogical – logically related entities are grouped

together MAYBETemporal – entities related due to timing of

stepsProcedural – entities related by order of stepsCommunicational – entities operate on the

same dataSequential – output of one entity serves as

input of anotherFunctional – all entities are essential to perform

a certain function

Cohesion TypesCohesion Types

Evil ComplexityEvil Complexity

The root of all evil

Simple designs are reliable designs.

Short code is reliable code.

Number of bugs ~ number of code lines

Reducing ComplexityReducing Complexity

1) Optimizing processes

2) Optimizing algorithms

3) Leveraging modularization

4) Leveraging abstraction

5) Minimizing dependencies

6) Coding efficiently

Defensive DesignDefensive Design

Always check for error codes (no success assumptions)

Exceptions provide cleaner means for handling errors. But these must be caught and processed!

Do not make any assumptions.

Check prerequisites and bounds.

Use Asserts on development phase.

Response to FailureResponse to Failure

1) Ask user: abort, retry or cancel?- Wait for response indefinitely a good

idea? Windows Shutdown- Learn preferred behavior!

2) Continue with diminished functionality (provide warning or log error)

3) Retry timeout balance- Too big – slow system- Too short – unreliable system

Fault Tolerance: PrincipleFault Tolerance: Principle

If a requisite condition not satisfied… can you correct it?

- Yes, then correct it!

- No, but can we continue anyway?

- Yes, then continue!- No, then the fault is critical

Fault Tolerance: PracticeFault Tolerance: Practice

Mutual Suspicion: system components assume that their counterparts may contain faults. Hence all the input data is checked for validity. Good coding practice

Active Fault Tolerance: e.g. ongoing system health check (memory balance, check sums) Status monitor

Diagnostic Transactions: scheduled component tests, Distributed systems

N-Version: multiple processes solve the same problem and the results are compared based on majority principle. Space systems / radiation hazard

HomeworkHomework

1) Perform design on you your individual project

Due October 10th2) Perform design on your team

projectDue October 12th

Be prepared to defend your design