You are on page 1of 25

Architectural Design,

User Interface Design


• After requirements are gathered i.e. context is modeled and all
external software interfaces have been described, a set of
architectural archetypes are identified.

• An archetype is an abstraction (similar to a class) that represents one


element of system behavior.
• The set of archetypes provides a collection of abstractions that must
be modeled architecturally if the system is to be constructed.

• Therefore, the designer specifies the structure of the system by


defining and refining software components that implement each
archetype.

• This process continues iteratively until a complete architectural


structure has been derived
Representing the System in Context

• At the architectural design level, a software architect uses an


Architectural Context Diagram (ACD) to model the manner in which
software interacts with entities external to its boundaries.
Defining Archetypes

• An archetype is a class or pattern that represents a core abstraction


that is critical to the design of an architecture for the target system.

• In general, a relatively small set of archetypes is required to design


even relatively complex systems.
ACD
UML relationships for SafeHome security function archetypes
Mapping Requirements into Software
Architecture Transform and Transaction Mapping
Two types of information flow:
a) Transform Flow.
b) Transaction Flow.
Transform Flow:
• Information must enter and exit software in an “external world” form.
External data (like data typed on keyboard, tones on a telephone line
and video images in multimedia application) must be converted into
an internal form for processing.
• Information enters the system along paths that transform external
data into an internal form.
• These paths are identified as incoming flow. At the kernel of the
software, a transition occurs.
• Incoming data are passed through a „transform center‟ and begin to
move along paths that now lead “out” of the software.
• Data moving along these paths are called outgoing flow.
• The overall flow of data occurs in a sequential manner and follows
straight line paths.
• When a segment of a DFD exhibits these characteristics, “transform
flow” is present
Transaction Flow:
• The fundamental system model implies transaction flow; therefore, it
is possible to characterize all data flow by a single data item, called a
transaction that triggers other data flow along one of the many paths.
• Transaction flow is characterized by data moving along an incoming
path that converts external world information into a transaction.
• The transaction is evaluated and based on its value; flow along one of
many action paths is initiated. “The hub of information flow from
which many actions path originate is called a transaction center”
Transform Mapping:
• Transform mapping is a set of design steps that allow a DFD with
transform flow characteristics to be mapped into a specific
architectural style.
• Structural design provides two strategies to guide transformation of a
DFD into a structure chart:
Transform Analysis
Transaction Analysis
• Transform Analysis : It identifies the primary functional components
(modules) and the high level input and output of these components.

• Transaction analysis : It is an alternative to transform analysis and is


useful while designing transaction processing programs.
Architectural Complexity
• Sharing dependencies
• Flow dependencies
• Constrained dependencies
User Interface Design
Three golden rules

1. Place the user in control.


2. Reduce the user’s memory load.
3. Make the interface consistent.
Design principles that allow the user to
maintain control:
• Define interaction modes in a way that does not force a user into
unnecessary or undesired actions.
• Provide for flexible interaction.
• Allow user interaction to be interruptible and undoable.
• Streamline interaction as skill levels advance and allow the interaction
to be customized.
• Hide technical internals from the casual user.
• Design for direct interaction with objects that appear on the screen.
Reduce the User’s Memory Load
• Reduce demand on short-term memory.
• Establish meaningful defaults.
• Define shortcuts that are intuitive.
• The visual layout of the interface should be based on a real-world
metaphor.
• Disclose information in a progressive fashion.
Make the Interface Consistent
• Allow the user to put the current task into a meaningful context.
• Maintain consistency across a family of applications.
• If past interactive models have created user expectations, do not
make changes unless there is a compelling reason to do so.
USER INTERFACE ANALYSIS AND
DESIGN
• Interface Analysis and Design Models
• The Process
INTERFACE ANALYSIS
• User Analysis
• Task Analysis and Modeling
• Analysis of Display Content
• Analysis of the Work Environment
WebApp interface design:
• Review information contained in the requirements model and refine
as required
• Develop a rough sketch of the WebApp interface layout.
• Map user objectives into specific interface actions.
• Define a set of user tasks that are associated with each action.
• Storyboard screen images for each interface action.
• Refine interface layout and storyboards using input from aesthetic
design.
• Identify user interface objects that are required to implement the
interface.
• Develop a procedural representation of the user’s interaction with the
interface.
• Develop a behavioral representation of the interface.
• Describe the interface layout for each state.
• Refine and review the interface design model.

You might also like