What is Design

1
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.

2
Conceptual Design Questions

• Where does the data come from and where does it
  go to?
• What happens to the data?
• System look and feel?
• What kind of UI?
• What parameters are configurable?
• Timing / synchronization considerations?
• Answered in requirement document!

3
Decomposition 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

4
Design Stages

• Choose decomposition method
• Come up with software architecture
• For each module, class or component execute
  program design (including decomposition and
  coding considerations)

5
Pipes 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.

6
Data-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.

7
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).

8
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.

9
Layered 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.

10
Process 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).

11
Client-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.

12
Distributed

• 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)

13
3-Tier

• Presentation UI
• Business Logic all the algorithms and decision
  making
• Database source data
• Fads
• Thin 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).

14
5-Tier

• 1) UI Interface
• Presentation
• 2) UI Façade
• 3) Business Logic
• 4) Data Mgmt Façade
• Data
• 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?

15
Modularity 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

16
Collaborative Issues

• Common design principles is a must
• Partitioned design compatibility must be
  evaluated
• Communication!
• Prioritization a must
• Keeping track of progress deferred problems
• Devising compatible interfaces
• Is outsourcing a good idea?

17
Distributed Project Stages

• All developers must congregate at one site to
  form a team
• Requirements are gathered and analyzed, each
  regional group receives spec and begins
  development
• The team separates into regional groups that keep
  working on their own delivering generic modules
• Once modules are complete group representatives
  get together for integration testing

18
User Interface Design

• Uncluttered
• Design for short attention span
• Fool-proof
• Eye-catching most important things
• Get to the point quickly and in as little steps
  as possible
• Ask only for whats really needed
• Consistent behavior (including navigation)
• Provide go-back / undo
• User acceptance tests must be scheduled regularly
  to validate UI design
• Localization (more important now)
• Customizability (fonts, views, colors)

19
Concurrency Issues

• Concurrency is good, but synchronization is
  difficult!
• Synchronization tools
• - mutexes (aka semaphores, used with monitors)
• - wait handles
• - locks (on data)
• - timers
• - critical sections

20
Exploit 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.

21
Minimize 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

22
Types 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

23
Coupling 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
  components 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.

24
Cohesion Types

• Grouping related things together
• Coincidental no reason for grouping BAD
• Logical logically related entities are grouped
  together MAYBE
• Temporal entities related due to timing of
  steps
• Procedural entities related by order of steps
• Communicational entities operate on the same
  data
• Sequential output of one entity serves as input
  of another
• Functional all entities are essential to
  perform a certain function

25
Cohesion Types
26
Evil Complexity

• The root of all evil
• Simple designs are reliable designs.
• Short code is reliable code.
• Number of bugs number of code lines

27
Reducing Complexity

• Optimizing processes
• Optimizing algorithms
• Leveraging modularization
• Leveraging abstraction
• Minimizing dependencies
• Coding efficiently

28
Defensive 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.

29
Response to Failure

• Ask user abort, retry or cancel?
• Wait for response indefinitely a good idea?
  Windows Shutdown
• Learn preferred behavior!
• Continue with diminished functionality (provide
  warning or log error)
• Retry timeout balance
• Too big slow system
• Too short unreliable system

30
Fault 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

31
Fault 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

32
Homework

• Perform design on you your individual project
• Due October 10th
• Perform design on your team project
• Due October 12th
• Be prepared to defend your design