User Interface architectureand architecturalpatterns.ppt

User Interface architecture and architectural patterns

1. Module 4& 5
SWE2004
Faculty:Prof.S.SreeDharinya
Software Architecture and Design
SWE2004 Faculty:Prof.S.SreeDharinya

2. Software Architecture for
Shared Information Systems
SWE2004 Faculty:Prof.S.SreeDharinya

3. Introduction
•Logical design levels:
•Architecture
•Combining sub systems into complete systems
•Problem raised : System Integration
•Code
•Executable
•shared information systems: significant class of large
systems is responsible for collecting, manipulating, and
preserving large bodies of complex information.
•Common Pattern
•“shared information systems evolution pattern”
SWE2004 Faculty:Prof.S.SreeDharinya

4. Successful integration requires solution of
both organizational and technical problems:
•understanding the current organizational capabilities and
processes
•re-engineering and simplification of processes with a
system view
•standardizing on common data languages and system
architectures
•automation of processes and systems
SWE2004 Faculty:Prof.S.SreeDharinya

5. Five kinds of issues motivate companies to
invest in systems integration
•Experiences with information technology have not lived up
to expectations.
•The proliferation(creation) of information technology
products and vendors has produced the need for
connectivity and interoperability.
•An installed base of information technology has to
accommodate new technology and new capabilities.
•Advances in technology + growing appreciation of what
can be accomplished with that technology = search for
new applications and sources of competitive advantage.
•In an increasingly global economy, telecommunications
and information technology are needed to stay abreast of
international competitors.
SWE2004 Faculty:Prof.S.SreeDharinya

6. The essential enabling technologies are
of several kinds
•Architecture: System organization; kinds of components,
kinds of interactions, and patterns of overall organization;
ability to evolve; consistency with available modular
building blocks for hardware, software, and databases;
standardization and open systems
•Semantics: Representations; conceptual consistency;
semantic models; means for handing inconsistencies
•Connectivity: Mechanisms for moving data between
systems and initiating action in other systems;
communication platforms with flexible linkages or
interfaces; network management and reliability; security
•Interaction: Granularity; user interfaces; interoperability;
simplicity; underlying consistency of presentation
SWE2004 Faculty:Prof.S.SreeDharinya

7. Three examples of shared
information systems:
•Data processing, driven primarily by the need to build
business decision systems from conventional databases
•Software development environments, driven primarily by the
need to represent and manipulate programs and their
designs.
•Building design, driven primarily by the need to couple
independent design tools to allow for the interactions of
their results in structural design
SWE2004 Faculty:Prof.S.SreeDharinya

8. Evolution of Shared Information Systems
in Business Data Processing
•Batch processing: Standalone programs; results are passed
from one to another on magtape. Batch sequential model.
•Interactive processing: Concurrent operation and faster
updates preclude batching, so updates are out of
synchronization with reports. Repository model with external
control.
•Unified schemas: Information becomes distributed among
many different databases. One virtual repository defines
(passive) consistent conversion mappings to multiple
databases.
•Multi-database: Databases have many users; passive
mappings don't suffice; active agents mediate interactions.
Layered hierarchy with client-server interaction.
SWE2004 Faculty:Prof.S.SreeDharinya

9. SWE2004 Faculty:Prof.S.SreeDharinya

10. SWE2004 Faculty:Prof.S.SreeDharinya

11. SWE2004 Faculty:Prof.S.SreeDharinya

12. SWE2004 Faculty:Prof.S.SreeDharinya

13. Virtual repository
SWE2004 Faculty:Prof.S.SreeDharinya

14. Hierarchial layers
SWE2004 Faculty:Prof.S.SreeDharinya

15. Evolution of Shared Information Systems in
Software Development Environments
SWE2004 Faculty:Prof.S.SreeDharinya

16. SWE2004 Faculty:Prof.S.SreeDharinya

17. SWE2004 Faculty:Prof.S.SreeDharinya

18. SWE2004 Faculty:Prof.S.SreeDharinya

19. SWE2004 Faculty:Prof.S.SreeDharinya

20. Architectural Design
Guidance
Unit 4
SWE2004 Faculty:Prof.S.SreeDharinya

21. 1. Guidance for User-Interface Architecture
1.1. Design Space & Rules
1.1.1. The Utility of Codified Knowledge
1.1.2. The Notion of Design Space
1.2. A Design space for User Interface Architecture
1.2.1. A Basic Structural Model
1.2.2. Sample functional Dimensions
1.2.3. Sample Structural Dimensions
1.3. Design Rules for User-Interface Architecture
1.3.1. Sample Rules
1.4. Applying the Design Space
1.5. A Validation Experiment
1.6. How the Design Space was prepared
SWE2004 Faculty:Prof.S.SreeDharinya

22. 1.1. Design Spaces and Rules
•We can describe and classify the architectural alternatives for
system designer by constructing a design space.
•Formulate design rules that indicates good and bad
combination of choices
•For new software engineers – day –to-day practice.
•Design rules need not to produce perfect or best possible
design.
•The rules should be simple, complete and reliable to achieve a
promising degree of design.
SWE2004 Faculty:Prof.S.SreeDharinya

23. 1.1.2. The Utility of Codified Knowledge
Software design knowledge in a useful form.
Developing vocabulary of well-understood , reusable design
concepts and patterns.
Benefits of Vocabulary :
aids in creating design,
helps to understand or predicting the properties of a design by
offering a context for the creation and application of knowledge,
reduces the effort needed to understand another person’s design by
reducing the number of new concepts to be learned.
SWE2004 Faculty:Prof.S.SreeDharinya

24. 1.1.2 The Notion of a Design Space
SWE2004 Faculty:Prof.S.SreeDharinya

25. •Central concept - multidimensional design space
•Dimension
•Describe the variation in one system characteristic
•Not necessarily independent
•Selected based on evaluation criteriaDesign Space Types –
functional : the above digram -- Structural :
we can choose the models
• Design space Types – functional : the above digram
-- Structural : we can choose the models
SWE2004 Faculty:Prof.S.SreeDharinya

26. 1.2. A Design space for User Interface Architecture
User Interface Management
systems(UIMS), graphic packages, UI tool
kits, window managers, stand alone
applns.,
1.2.1. Basic Structural Model:
Divide UI system into 3 components:
1.An application specific component : codes
2.A shared user interface: codes and I/O devices
specific
3.A device-dependent component: specific code to
particular I/O devices
SWE2004 Faculty:Prof.S.SreeDharinya

27. Application
specific
component
Device
Dependent
Component
Shared user
interface
component
Device Interface Application Interface
SWE2004 Faculty:Prof.S.SreeDharinya

28. 1.2.2. Sample Functional Dimensions for
UIMS
Functional Dimensions fall into 3
categories
1.External requirements: applications, users,
I/O devices, constraints
2.Basic Interactive behavior: key decisions
about UI behavior which influence internal
structure.
3.Practical considerations: covers
development cost considerations ,
adaptability of the system
SWE2004 Faculty:Prof.S.SreeDharinya

29. USER INTERFACE
ARCHITECTURES
SWE2004 Faculty:Prof.S.SreeDharinya

30. USER INTERFACE ARCHITECTURES
•We can describe and classify the architectural alternatives
available to a system designer by constructing a design
phase.
•We can formulate design rules that indicate good and bad
combinations of choices , and use them to select an
appropriate system design based on functional
requirements
SWE2004 Faculty:Prof.S.SreeDharinya

31. A DESIGN SPACE FOR USER-INTERFACE
ARCHITECTURES
•It focus is on providing an interactive user interface for
some function.
•The design space approach is to choose some dimensions
that reflect requirements or evaluation criteria , while other
dimensions reflect structure
SWE2004 Faculty:Prof.S.SreeDharinya

32. The sample Design-space dimension
1.Functional dimension
2.Structural dimension
SWE2004 Faculty:Prof.S.SreeDharinya

33. Basic structural Model
•A useful scheme for user-interface system divides any
complete system into three components , or groups of
modules:
1.An application-specific component::This component
includes the functional core of the application .
2.A Shared interface component::
it supports the user interface of multiple application.
3.A device-dependent component::
This consists of code that is specific to a particular
I/O device. class.
SWE2004 Faculty:Prof.S.SreeDharinya
Device
dependen
t
compone
nt
Shared
user
interface
compone
nt
Applicatio
n specific
componen
t

34. Functional Dimensions
•External event handling
-no external events.
-process events while waiting for input.
-External events preempt user commands.
User customizability
-high
-medium
-low
SWE2004 Faculty:Prof.S.SreeDharinya

35. Functional Dimensions
•User Interface adaptability across devices
-Local behavior changes
-Global behavior change.
-Application semantics changes
SWE2004 Faculty:Prof.S.SreeDharinya

36. Functional Dimensions
•Computer system organization
-uni processing
-multi processing
-distributed processing
SWE2004 Faculty:Prof.S.SreeDharinya

37. Functional Dimensions
•Basic interface class
-menu selection
-form filling
-command language
-natural language
-direct manipulation
SWE2004 Faculty:Prof.S.SreeDharinya

38. Functional Dimensions
•Application portability across user interface styles
-high
-medium
-low
SWE2004 Faculty:Prof.S.SreeDharinya

39. Structural Dimension
•Application interface abstraction level
-Monolithic
-abstract devices
-toolkit
-interaction manager with fixed data types
-interaction manager with extension data types
-Extensible interaction manager
SWE2004 Faculty:Prof.S.SreeDharinya

40. Structural Dimension
•Abstract device variability
-ideal device
-parameterized device
-device with variable operations
-Ad-hoc devices
SWE2004 Faculty:Prof.S.SreeDharinya

41. Structural Dimension
•Notation for user interface definition
-implicit in shared user interface code.
-implicit in application code.
-external declarative notation
-external procedural notation
-internal declarative notation.
-internal procedural notation.
SWE2004 Faculty:Prof.S.SreeDharinya

42. Structural Dimension
•Basic of communication
-Events
-pure state.
-state with hints
-state plus events
SWE2004 Faculty:Prof.S.SreeDharinya

43. Structural Dimension
•Control thread mechanism
-none
-standard process
-lightweight process
-event handlers
-interrupt service routines.
SWE2004 Faculty:Prof.S.SreeDharinya

44. External Requirements
•The requirements of the particular applications, users , and
I/O devices to be supported , as well as constraints imposed
by the surrounding computer system.
SWE2004 Faculty:Prof.S.SreeDharinya

45. Basic Interactive behavior
•The key decision about user-interface behavior that
fundamentally influence internal structure.
SWE2004 Faculty:Prof.S.SreeDharinya

46. Practical Consideration
•This group covers development cost considerations
primarily , the required degree of adaptability of the system
SWE2004 Faculty:Prof.S.SreeDharinya

47. Representation Issues
•Notation for user-interface definition is a representation
dimension . it classifies the techniques used for defining
the appearance and behavior of the user interface.
SWE2004 Faculty:Prof.S.SreeDharinya

48. Representation Issues
•Implict in shared user-interface code : Information “wired
into” shared code . For example , the visual appearance of
a menu might be implicit in the menu routines supplied be
a toolkit.
•Implicit in application code : Information buried in the
application and not readily available to shared user-
interface code..
SWE2004 Faculty:Prof.S.SreeDharinya

49. Representation Issues
•External declarative notation :::A nonprocedural
specification separate from the body of the application
program.
•External Procedural notation::: A procedural specification
separate from the body of the application program ; often
cast in a specialized programming language.
SWE2004 Faculty:Prof.S.SreeDharinya

50. Representation Issues
•Internal declarative notations :::A nonprocedural
specification within the application program. unlike an
implicit representation, this is available for use by the
shared user-interface code
•Internal Procedural notation:: A procedural specification
within the application program .an implicit representation ,
this is available for use by the shared user interface code
SWE2004 Faculty:Prof.S.SreeDharinya

51. Design Rules For User-Interface
Architecture
•If External event handling requires preemption of user
commands, then a preemptive control thread mechanism is
strongly favored.
•High user customizability requirements favor external
notations for user interface behavior.
•Stronger requirements for user-interface adaptability
across devices favor higher levels of application-interface
abstraction
SWE2004 Faculty:Prof.S.SreeDharinya

52. Design Rules For User-Interface
Architecture
•A distributed system organization favors event-based
communication.
•The basic user-interface class effects the best choice of
application-interface abstraction level. EX: menu selection
and for-filling user interface.
•A high requirement for application portability across user-
interface styles favors the higher levels of application
SWE2004 Faculty:Prof.S.SreeDharinya

53. Design Rules For User-Interface
Architecture
Rules all relate functional to structural dimensions . following
are some examples.
The choice of application-interface
abstraction level.
Toolkit systems include implicit and internal
declarative notations.
Interaction managers of all types use
external and/or internal declarative notations.
Extensible interaction managers heavily on
procedural notations.
SWE2004 Faculty:Prof.S.SreeDharinya

54. Architectural Design and
Mapping
SWE2004 Faculty:Prof.S.SreeDharinya

55. An Architectural Design Method
SWE2004 Faculty:Prof.S.SreeDharinya
"four bedrooms, lounge, drawing & dinning,
lots of glass ..."
customer requirements
architectural design

56. Transaction Mapping
a
b
t
g
h
d
e
f
i
k
j
l
m
n
Data flow model x1
b
a
t
x2 x3 x4
d e f g hx3.1l m n
i j
k
mapping
program structure
SWE2004 Faculty:Prof.S.SreeDharinya

57. Isolate Flow Paths
fixture setting
read
command
validate
command
determine
type
read
record
calculate
output
values
format
report
produce
error msg
read
fixture
status
determine
setting
format
setting
send
control
value
command
command
invalid command
error msg
status
combined
status
raw setting
robot control
start/stop
assembly
record
record
values
report
valid command
SWE2004 Faculty:Prof.S.SreeDharinya

58. Map the Flow Model
process
operator
commands
command
input
controller
read
command
validate
command
produce
error
message
determine
type
fixture
status
controller
report
generation
controller
send
control
value
each of the action paths must be expanded further
SWE2004 Faculty:Prof.S.SreeDharinya

59. Architectural Design patterns
•Architectural patterns are proven structural organisation
schemas for software systems
•description of set of predefined subsystems
•specify responsibilities
•rules and guidelines for organizing subsystem relationships
SWE2004 Faculty:Prof.S.SreeDharinya

60. Difference between Pattern and Styles
•A pattern can be seen as a solution to a problem,
•A style is more general and does not require a problem to
solve for its appearance.
•several patterns may belong to the same architectural style
SWE2004 Faculty:Prof.S.SreeDharinya

61. Why pattern are used ?
•By writing a pattern, it becomes easier to reuse the
solution.
•Patterns provide a common vocabulary and understanding
of design solutions.
•Pattern names become part of a widespread design
language. They remove the need to explain a solution to a
particular problem with a lengthy description.
SWE2004 Faculty:Prof.S.SreeDharinya

62. schema
•Patterns are described using a pattern template or schema.
•Components of a template
• Context: the situation giving rise to a problem.
• Problem: the recurring problem in that context.
•Solution: a proven solution for the problem.
SWE2004 Faculty:Prof.S.SreeDharinya

63. Universally used patterns
1.Layered pattern
2.Client – Server pattern
3.Master – Slave pattern
4.Pipe – Filter Pattern
5.Broker pattern
6.Peer to peer pattern
7.Event bus pattern
8.Model-view-controller pattern
9.Blackboard pattern
10.Interpreter pattern
SWE2004 Faculty:Prof.S.SreeDharinya

64. Layered Pattern
•helps to structure applications
that can be decomposed into
groups of subtasks,
•Advantages:
•A lower layer can be used by
different higher layers.
• Layers make standardization
easier: clearly defined and
commonly accepted levels of
abstraction enable the
development of standardized
tasks and interfaces.
•– Dependencies are kept local.
SWE2004 Faculty:Prof.S.SreeDharinya

65. Example: networking protocols
SWE2004 Faculty:Prof.S.SreeDharinya

66. Client-server pattern
•The server component
provides a function or
service to one or many
clients, which initiate
requests for such services.
•a web server serves web
pages
•a file server serves
computer files
SWE2004 Faculty:Prof.S.SreeDharinya

67. Master – Slave pattern
•Master-slave pattern supports
fault tolerance and parallel
computation.
•The master component
distributes the work among
identical slave components,
•and computes a final result
from the results the slaves
return.
SWE2004 Faculty:Prof.S.SreeDharinya

68. Pipe – Filter pattern : provides a structure for
systems that produce a stream of data.
SWE2004 Faculty:Prof.S.SreeDharinya
A compiler

69. Broker pattern
•The Broker pattern is used
to structure
•distributed systems
•with decoupled
components,
•which interact by remote
service invocations.
•Servers publish their
capabilities (services and
characteristics) to a broker.
•Clients request a service
from the broker,
•the broker then redirects
the client to a suitable
service from its registry.
SWE2004 Faculty:Prof.S.SreeDharinya

70. Peer-to-peer pattern
•The Peer-to-peer pattern can be
seen as a symmetric Client-server
pattern.
•peers may function both as a client,
requesting services from other
peers, and as a server, providing
services to other peers.
SWE2004 Faculty:Prof.S.SreeDharinya

71. Event-bus pattern
SWE2004 Faculty:Prof.S.SreeDharinya

72. Event-bus pattern
•The Event-bus pattern is a pattern that deals with events.
•It works as follows:
•Event sources publish messages to particular channels on an
event bus.
•Event listeners subscribe to particular channels.
•Listeners are notified of messages that are published to a channel
to which they have subscribed.
SWE2004 Faculty:Prof.S.SreeDharinya

73. Model-View-Controller pattern
•In MVC pattern an
interactive application is
divided into three parts:
• the model contains the
core functionality and data,
•the view displays the
information to the user
(more than one view may be
defined),
• the controller handles the
input from the user.
SWE2004 Faculty:Prof.S.SreeDharinya

74. Blackboard pattern
•The Blackboard pattern is
useful for problems for
which no deterministic
solution strategies are
known.
•All components have access
to a shared data store, the
blackboard.
•Components may produce
new data objects that are
added to the blackboard.
•Components look for
particular kinds of data on
the blackboard, and may
find these by pattern
matching.
SWE2004 Faculty:Prof.S.SreeDharinya

75. Interpreter pattern
•The Interpreter pattern is used for designing a component
that interprets programs written in a dedicated language.
•.
SWE2004 Faculty:Prof.S.SreeDharinya