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