Professional Documents
Culture Documents
Objectives
Creativity
u Enhance your skillset
u Provide new tools
Method
u Focus on highly effective techniques
Develop judgment: when to develop novel solutions, and when to follow established
method
Engineering Design Process
Feasibility stage: identifying a set of feasible concepts for the design as a whole
Preliminary design stage: selection and development of the best concept.
Detailed design stage: development of engineering descriptions of the concept.
Planning stage: evaluating and altering the concept to suit the requirements of production,
distribution, consumption and product retirement.
Potential Problems
If the designer is unable to produce a set of feasible concepts, progress stops.
As problems and products increase in size and complexity, the probability that any one
individual can successfully perform the first steps decreases.
The standard approach does not directly address the situation where system design is at
stake, i.e. when relationship between a set of products is at issue.
à As complexity increases or the experience of the designer is not sufficient, alternative
approaches to the design process must be adopted.
Alternative Design Strategies
Standard
u Linear model described above
Cyclic
u Process can revert to an earlier stage
Parallel
u Independent alternatives are explored in parallel
Adaptive (“lay tracks as you go”)
u The next design strategy of the design activity is decided at the end of a given stage
Incremental
u Each stage of development is treated as a task of incrementally improving the
existing design
Identifying a Viable Strategy
Use fundamental design tools: abstraction and modularity.
u But how?
Inspiration, where inspiration is needed. Predictable techniques elsewhere.
u But where is creativity required?
Applying own experience or experience of others.
Abstraction and the Simple Machines
What concepts should be chosen at the outset of a design task?
u One technique: Search for a “simple machine” that serves as an abstraction of a
potential system that will perform the required task
u For instance, what kind of simple machine makes a software system embedded in a
fax machine?
At core, it is basically just a little state machine.
Simple machines provide a plausible first conception of how an application might be built.
Every application domain has its common simple machines.
Simple Machines
Domain Simple Machines
Graphics Pixel arrays
Transformation matrices
Widgets
Abstract depiction graphs
Word processing Structured documents
Layouts
Process control Finite state machines
Income Tax Software Hypertext
Spreadsheets
Form templates
Web pages Hypertext
Composite documents
Scientific computing Matrices
Mathematical functions
Banking Spreadsheets
Databases
Transactions
Model-View-Controller (MVC)
Objective: Separation between information, presentation and user interaction.
When a model object value changes, a notification is sent to the view and to the controller.
So that the view can update itself and the controller can modify the view if its logic so
requires.
When handling input from the user the windowing system sends the user event to the
controller; If a change is required, the controller updates the model object.
Sense-Compute-Control
Objective: Structuring embedded control applications
The Lunar Lander: A Long-Running Example
A simple computer game that first appeared in the 1960’s
Simple concept:
u You (the pilot) control the descent rate of the Apollo-era Lunar Lander
Throttle setting controls descent engine
Limited fuel
Initial altitude and speed preset
If you land with a descent rate of < 5 fps: you win (whether there’s fuel left
or not)
u “Advanced” version: joystick controls attitude & horizontal motion
Sense-Compute-Control LL
Architectural Styles
An architectural style is a named collection of architectural design decisions that
are applicable in a given development context
constrain architectural design decisions that are specific to a particular
system within that context
elicit beneficial qualities in each resulting system
A primary way of characterizing lessons from experience in software system design
Reflect less domain specificity than architectural patterns
Useful in determining everything from subroutine structure to top-level application structure
Many styles exist and we will discuss them in detail in the next lecture
Definitions of Architectural Style
Definition. An architectural style is a named collection of architectural design decisions that
u are applicable in a given development context
u constrain architectural design decisions that are specific to a particular system
within that context
u elicit beneficial qualities in each resulting system.
Recurring organizational patterns & idioms
u Established, shared understanding of common design forms
u Mark of mature engineering field.
Shaw & Garlan
Abstraction of recurring composition & interaction characteristics in a set of architectures
Taylor
Basic Properties of Styles
A vocabulary of design elements
u Component and connector types; data elements
u e.g., pipes, filters, objects, servers
A set of configuration rules
u Topological constraints that determine allowed compositions of elements
u e.g., a component may be connected to at most two other components
A semantic interpretation
u Compositions of design elements have well-defined meanings
Possible analyses of systems built in a style
Benefits of Using Styles
Design reuse
u Well-understood solutions applied to new problems
Code reuse
u Shared implementations of invariant aspects of a style
Understandability of system organization
u A phrase such as “client-server” conveys a lot of information
Interoperability
u Supported by style standardization
Style-specific analyses
u Enabled by the constrained design space
Visualizations
u Style-specific depictions matching engineers’ mental models
Object-Oriented Style
Components are objects
u Data and associated operations
Connectors are messages and method invocations
Style invariants
u Objects are responsible for their internal representation integrity
u Internal representation is hidden from other objects
Advantages
u “Infinite malleability (flexibility)” of object internals
u System decomposition into sets of interacting agents
Disadvantages
u Objects must know identities of servers
Object-Oriented LL
The object-oriented design of the Lunar Lander game has three encapsulations: the spacecraft, the
user’s interface, and the environment (essentially a physics model that allows calculation of the
descent rate)
Some details of the object-oriented design are apparent in figure which is a Unified Modelling
Language characterization of the objects.
Layered Style
Hierarchical system organization
u “Multi-level client-server”
u Each layer exposes an interface (API) to be used by above layers
Each layer acts as a
u Server: service provider to layers “above”
u Client: service consumer of layer(s) “below”
Connectors are protocols of layer interaction
Example: Operating Systems
Virtual Machine Style results from fully opaque (unclear) layers
Advantages
u Increasing abstraction levels
u Evolvability
u Changes in a layer affect at most the adjacent two layers
Reuse
u Different implementations of layer are allowed as long as interface is preserved
u Standardized layer interfaces for libraries and frameworks
Disadvantages
u Not universally applicable
u Performance
Layers may have to be skipped
Layered Systems/Virtual Machines
Layered LL
A five-level version of the lunar lander game is
shown in Figure 4-11.
The top layer handles inputs received from
the user through the keyboard; it calls the
second layer to service those inputs,
Client-Server LL
In the system shown, three players simultaneously and independently play the game.
All game state, game logic, and environment simulation is performed on the server.
The clients perform the user interface functions.
The connectors in this example are Remote Procedure Calls (RPC), which are procedure call
connectors combined with a distributor,
A distributor identifies network interaction paths and subsequently routes communication
along those paths.
Data-Flow Styles
Batch Sequential
u Separate programs are executed in order; data is passed as an aggregate (collective)
from one program to the next.
u Connectors: “The human hand” carrying tapes between the programs, a.k.a.
“sneaker-net ”
u Data Elements: Explicit, aggregate elements passed from one component to the
next upon completion of the producing program’s execution.
Typical uses: Transaction processing in financial systems.
Batch-Sequential: A Financial Application
Batch-Sequential LL
• GetBurnRate runs continuously on its own, prompting the user for a new burn rate.
• In this design the Compute new values determines how much time has passed.
Shared memory
Blackboard Style
Two kinds of components
u Central data structure — blackboard
u Components operating on the blackboard
System control is entirely driven by the blackboard state
Examples
u Typically used for AI systems
u Integrated software environments (e.g., Interlisp*)
u Compiler architecture
See other PPT file for more …
Black-board LL
A single connector regulates access from the various experts in manipulating the information on the
blackboard.
The blackboard maintains the game state; the experts perform the independent tasks of (1) updating
the descent engine burn rate based upon input from the user, (2) displaying to the user the current
state of the spacecraft and any other aspect of the game state, and (3) updating the game state
based upon a time and physics model.
Rule-Based Style
Inference engine parses user input and determines whether it is a fact/rule or a query. If it is
a fact/rule, it adds this entry to the knowledge base. Otherwise, it queries the knowledge base for
applicable rules and attempts to resolve the query.
Components: User interface, inference engine, knowledge base
Connectors: Components are tightly interconnected, with direct procedure calls and/or
shared memory.
Data Elements: Facts and queries
Behavior of the application can be very easily modified through addition or deletion of rules
from the knowledge base.
Caution: When a large number of rules are involved understanding the interactions between
multiple rules affected by the same facts can become very difficult.
With regard to the user interaction model, the user enters the value of burn rate as a fact:
burnrate(25)
To see what the status of the spacecraft is, the user can switch to the goal mode and asks whether
the spacecraft has landed safely:
landed (spacecraft)
To handle this query, the inference engine queries the database, If the existing facts and other
production rules satisfy the conditions “altitude <= 0” and “velocity < 3 ft/s,” then the engine returns
true to the user interface. Otherwise, it returns false
Interpreter Style
Interpreter parses and executes input commands, updating the state maintained by the
interpreter
Components: Command interpreter, program/interpreter state, user interface.
Connectors: Typically very closely bound with direct procedure calls and shared state.
Highly dynamic behavior possible, where the set of commands is dynamically modified.
System architecture may remain constant while new capabilities are created based upon
existing primitives.
Superb for end-user programmability; supports dynamically changing set of capabilities
Care should be taken to make the interpreter as flexible as possible, so that the
implementation can be changed at later stages without having tight coupling.
Other advantage of Interpreter is that you can have more than one interpreter for the same
output and create the object of interpreter based on the input
Interpreter LL
• When the user enters “BurnRate(50),” the interpreter takes BurnRate as the command and
the parameter as the amount of fuel to burn.
• It then calculates the necessary updates to the altitude, fuel level, and velocity.
• Time is simulated by having t incremented each occasion the user enters a BurnRate
command.
• When the user enters the CheckStatus command, the user receives the current state of
altitude, fuel, time, and velocity.
Mobile-Code Style
It enable code to be transmitted to a remote host for interpretation.
This may be due to a lack of local computing power, lack of resources, or due to large data
sets remotely located.
Mobile code may be classified as: -
u code on demand,
u remote evaluation, or
u mobile agent
depending on where the code is being transmitted, who requested the transmission, and
where the program state resides.
Code on demand is when the initiator has resources and state but downloads code from
another site to be executed locally,
Remote evaluation is when the initiator has the code but lacks the resources (such as the
interpreter) to execute the code, Thus, it transmits code to be processed at a remote host,
such as in grid computing. Results are returned to the initiator.
Mobile agent is when the initiator has the code and the state but some of resources are
located elsewhere. Thus the initiator moves to a remote host with the code, the state, and
some of the resources. Processing need not return to the initiator.
Summary: a data element (some representation of a program) is dynamically transformed
into a data processing component.
Components: “Execution dock”, which handles receipt of code and state; code
compiler/interpreter
Connectors: Network protocols and elements for packaging code and data for transmission.
Data Elements: Representations of code as data; program state
Variants: Code-on-demand, remote evaluation, and mobile agent.
Additional constraints imposed: Data passed in remote procedure calls must be serializable.
Callers must deal with exceptions that can arise due to network or process faults.
Random-access to data
required.
Shared memory
Rule-based Use facts or rules Problem data and queries Number of rules is large.
entered into the expressible as simple rules
knowledge base to over which inference may be Interaction between rules
resolve a query performed. present.
High-performance required.
Interpreter
Interpreter Interpreter parses and Highly dynamic behavior High performance required.
executes the input required. High degree of end-
stream, updating the user customizability.
state maintained by the
interpreter
Mobile Code Code is mobile, that is, it When it is more efficient to Security of mobile code cannot
is executed in a remote move processing to a data set be assured, or sandboxed.
host than the data set to
processing. When tight control of versions of
deployed software is required.
When it is desirous to
dynamically customize a local
processing node through
inclusion of external code
Implicit Invocation
Publish- Publishers broadcast Components are very loosely When middleware to support
subscribe messages to coupled. Subscription data is high-volume data is unavailable.
subscribers small and efficiently
transported.
Peer-to-peer Peers hold state and Peers are distributed in a Trustworthiness of independent
behavior and can act as network, can be peers cannot be assured or
both clients and servers heterogeneous, and mutually managed.
independent.
Resource discovery inefficient
Robust in face of independent without designated nodes.
failures.
Highly scalable.