Improve Your Technology

Just another blog for techology

Architecture Design

Architecture Design

 

Architecture design represents the structure of data and program components that are required to build a computer-based system. It considers the architectural style that the system will take, the structure and properties of the interrelationships that occur among all architectural components of a system. Architectural design begins with data design and then proceeds to the derivation of one or more representations of the architectural structure of the system. Alternative architectural styles or patterns are analyzed to derive the structure that is best suited to customer requirements and quality attributes. Once an alternative has been selected, the architecture is elaborated using an architectural design method.

 

Definition: Software architecture provides a holistic view of the system to be built. It depicts the structure and organization of software components, their properties, and the connections between them. Software components include program modules and the various data representations that are manipulated by the program. Therefore, data design is an integral part of the derivation of the software architecture. Architecture highlights early design decisions and provides a mechanism for considering the benefits of alternative system structures.

 

1. Software Architecture

 

1.1     What is architecture?

 

The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them. The architecture is not the operational software. Rather, it is a representation that enables a software engineer to

(1)     analyze the effectiveness of the design in meeting its stated requirements,

(2)     consider architectural alternatives at a stage when making design changes is still relatively easy, and

(3)     reducing the risks associated with the construction of the software.

 

The definition emphasizes the role of “software components” in any architectural representation. In the context of architectural design, a software component can be something as simple as a program module, but it can also be extended to include databases and “middleware” that enable the configuration of a network of clients and servers. The properties of components are those characteristics that are necessary to an understanding of how the components interact with other components. At the architectural level, internal properties can be as simple as a procedure call from one module to another or as complex as a database access protocol.

 

1.2. Why Is Architecture Important?

 

ü        Representations of software architecture are an enabler for communication between all parties interested in the development of a computer-based system.

ü        The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity.

ü        Architecture “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together”

 

The architectural design model and the architectural patterns contained within it are transferable. That is, architecture style and patterns can be applied to the design of other systems and represent a set of abstractions that enable software engineers to describe architecture in predictable ways.

 

2. Data Design

 

Data design creates a model of data and/or information that is represented at a high level of abstraction. This data model is then refined into progressively more implementation-specific representations that can be processed by the computer-based system. The structure of data has always been an important part of software design. The design of data structures and the associated algorithms required to manipulate them is essential to the creation of high-quality applications.

 

2.1 Data Modeling, Data Structures, Databases, and the Data Warehouse

 

The data objects defined during software requirements analysis are modeled using entity/relationship diagrams and the data dictionary. The data design activity translates these elements of the requirements model into data structures at the software component level and, when necessary, a database architecture at the application level.

 

Data mining technique also called as Knowledge discover in databases that navigates through existing databases in an attempt to extract appropriate business-level information.

 

A data warehouse is a separate data environment that is not directly integrated with day-to-day applications but encompasses all data used by a business. A data warehouse is a large, independent database that encompasses some, but not all, of the data that are stored in databases that serve the set of applications required by a business.

 

2.2 Data Design at the Component Level

Data design at the component level focuses on the representation of data structures that are directly accessed by one or more software components. The design of data begins during the creation of the analysis model. Recalling that requirements analysis and design often overlap, we consider following set of principles for data specification:

 

ü        The systematic analysis principles applied to function and behavior should also be applied to data.

ü        All data structures and the operations to be performed on each should be identified.

ü        A data dictionary should be established and used to define both data and program design.

ü        Low-level data design decisions should be deferred until late in the design process.

ü        The representation of data structure should be known only to those modules that must make direct use of the data contained within the structure.

ü        A library of useful data structures and the operations that may be applied to them should be developed.

ü        A software design and programming languages should support the specification and realization of abstract data types.

 

3. Architectural Styles

 

The software that is built for computer-based systems also exhibits one of many architectural styles. Each style describes a system category that encompasses

(1)     a set of components that perform a function required by a system;

(2)     a set of connections that enable “communication, coordination and cooperation” among components;

(3)     constraints that define how components can be integrated to form the system; and

(4)     semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.

 

3.1 A Brief Taxonomy of Styles and Patterns

 

Data-centered architectures: A data store resides at the center of this architecture and is accessed frequently by other components that update, add, delete, or otherwise modify data within the store. Data-centered architectures promote integrability i.e. existing components can be changed and new client components can be added to the architecture without concern about other clients.

 

Data-flow architectures: This architecture is applied when input data are to be transformed through a series of computational or manipulative components into output data. A pipe and filter pattern has a set of components, called filters, connected by pipes that transmit data from one component to the next. Each filter works independently of those components upstream and downstream, is designed to expect data input of a certain form, and produces data output of a specified form.

 

Call and return architectures: This architectural style enabled a software designer to achieve a program structure that is relatively easy to modify and scale.

 

Object-oriented architectures: The components of a system encapsulate data and the operations that must be applied to manipulate the data. Communication and coordination between components is accomplished via message passing.

 

Layered architectures: The basic structure of layered architectures is “A number of different layers are defined, each accomplishing operations that progressively become closer to the machine instruction set.

 

These architectural styles are only a small subset of those available to the software designer. Once requirements engineering uncovers the characteristics and constraints of the system to be built, the architectural pattern or combination of patterns that best fits those characteristics and constraints can be chosen.

 

4. Analyzing Alternative Architectural Design

 

4.1 An Architecture Trade-off Analysis Method

 

An architecture trade-off analysis method establishes an iterative evaluation process for software architectures. The design analysis activities that follow are preformed iteratively:

ü        Collect Scenario. A set of use-case is developed to represent the system from the user’s point of view.

ü        Elicit requirements, constraint, and environment description. The information is required as part of requirements engineering and is used to be certain that all customer, user, and stakeholder concerns have been addressed.

ü        Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements.

o         Module view for analysis of work assignments with components and the degree to which information hiding has been achieved.

o         Process view for analysis of system performance.

o         Data flow view for analysis of the degree to which the architecture meets functional requirements.

ü        Evaluate quality attributes by considering each attribute in isolation.

ü        Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style.

ü        Critique candidate architectures using the sensitivity analysis.

 

4.2 Quantitative Guidance for Architectural Design

 

Once an architecture has been derived, it is elaborated and the analyzed against quality criteria.

 

One of the many problems faced by software engineer during the design process is a general lack of quantitative methods for assessing quality of proposed designs. Work in the area of quantitative analysis of architectural design is still in its formative stages. Asada and his colleagues suggest a number of pseudo quantitative techniques that can be used to complement the ATAM approach as a method for the analysis of architectural design quality.

 

Asada proposes a number of simple models that assists a designer in determining the degree to which a particular architecture meets predefined “goodness” criteria.

 

The first model, called spectrum analysis, assesses an architectural design on a “goodness” spectrum from the best to worst possible designs. Once the software architecture has been proposed, it is assessed by assessing by a “score” to each of its design dimensions.

 

Design selection analysis is another model that requires a set of design dimensions to be defined. The proposed architecture is then assessed to determine the number of design dimensions that it achieve when compared to an ideal system.

 

Contribution analysis “identified the reasons that one set of design choices gets a lower score than another”. Recalling our discussion of quality function deployment value analysis is conducted to determine the relative priority of requirements determine during function deployment.

 

5. Mapping Requirements into a Software Architecture

 

Structured design is often characterized as a data flow-oriented design method because it provides a convenient transition from a data flow diagram to software architecture. The transition as part of six-step process:

(1)     the type of information flow is established;

(2)     flow boundaries are indicated;

(3)     the DFD is mapped into program structure;

(4)     control hierarchy is defined;

(5)     resultant structure is refined using design measuring and heuristics; and

(6)     the architectural description is refined and elaborated.

 

5.1 Transform Flow

 

Recall the fundamental system model information must enter and exit software in an “external world” form. 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.

 

5.2 Transaction Flow

 

The fundamental system model implies transform flow. It is possible to characterize all data flow in this category. Information is often characterized by a single data item called a transaction that triggers other data flow along one of 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 is evaluated and, based on its value, flow along one of many action paths in initiated.

 

Architectural design encompasses the initial set of design activities that lead to a complete design model of the software.

Advertisements

September 14, 2008 Posted by | Architecture Design, Design, Software Engineer, Technology | | 1 Comment

User Interface Design

User Interface Design

 

1. The Golden rule

 

These golden rules actually form the basis for a set of user interface design principles that guide this important software design activity.

 

1.1     Place the User in control

 

Most interface constraints and restriction that are imposed by a designer are intended to simplify the mode of interaction. The designer might introduce constraints and limitations to simplify the implementation of the interface. The result may be an interface that is easy to build, but frustrating to use.

 

Design principles:

 

ü        Define interaction modes in a way that does not face 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.

 

1.2     Reduce the User’s Memory Load

 

A well designed user interface does not tax the user’s memory. Whenever possible, the system should “remember” pertinent information and assist the user with an interaction scenario that assists recall.

 

Design principles to reduce the user’s memory load:

 

ü        Reduce demand on short-term memory. The interface should be designed to reduce the requirements to remember past actions and results.  This can be accomplished by providing visual cues that enable a user to recognize past actions, rather than having to recall them.

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

 

1.3     Make the Interface consistent

 

The interface should present and acquire information in a consistent fashion. This implies that

(1)     all visual information is organized according to a design standard that is maintained throughout all screen displays,

(2)     input mechanisms are constrained to a limited set that are used consistently throughout the application, and

(3)     mechanism for navigating from task to task are consistently defined and implemented.

 

Design principles to Make the Interface consistent:

 

ü        Allow the user to put the current task into a meaningful context. It’s important to provide indicators that enable the user to know the context of the work at hand.

ü        Maintain consistency across a family of applications. A set of applications should all implement the same design rules so that consistency is maintained for all interaction.

ü        If past interactive models have created user expectation, do not make changes unless there is a compelling reason to do so.

 

2. User Interface Design

 

The overall process for designing a user interface begins with the creation of different models of system function. The human and computer oriented tasks that are required to achieve system function are then delineated; design issues that apply to all interface designs are considered; tools are used to prototype and ultimately implement the design model; and the result is evaluated for quality.

 

2.1 Interface Design Models

 

Four different models come into play when a user interface is to be designed. The software engineer creates a design model, a human engineer establishes a user model, the end-user develops a mental image that is often called the user’s model or the system perception, and the implementers of the system create a system image.

 

A design model of the entire system incorporates data, architectural, interface, and procedural representations of the software. The requirements specification may establish certain constraints that help to define the user of the system, but the interface design is often only incidental to the design model. The user model establishes the profile of end-user of the system. Users can be categorized as:

ü        Novices. No syntactic knowledge of the system and little semantic knowledge of the application or computer usage in general

ü        Knowledgeable, intermittent users. Reasonable semantic knowledge of the application but relatively low recall of syntactic information necessary to use the interface.

ü        Knowledgeable, frequent users. Good semantic and syntactic knowledge that often leads to the “power-user syndrome”; that is individuals who look for shortcuts and abbreviated modes of interaction.

 

The system perception is the image of the system that end-users carry in their heads. The system image combines the outward manifestation of the computer-based system, coupled with all supporting information that describes system syntax and semantics. The mode described “abstractions of what the user is doing or thinks he is doing or what somebody else thinks he ought to be doing when he uses an interactive system”.

 

2.2 The User Interface Design Process

 

The design process for user interfaces is iterative and can be represented using a spiral model. The user interface design process encompasses four distinct framework activities.

1.        User, task, and environment analysis and modeling

2.        Interface design

3.        Interface construction

4.        Interface validation

 

The initial analysis activity focuses on the profile of the users who will interact with the system. Once general requirements have been defined, a more detailed task analysis is conducted. Those tasks that the user performs to accomplish the goals of the system are identified, described, and elaborated. The analysis of the user environment focuses on the physical work environment.

 

ü  Where will the interface be located physically?

ü  Will the user sitting, standing, or performing other tasks unrelated to the interface?

ü  Does the interface hardware accommodate space, light, or noise constraints?

ü  Are there special human factors consideration driven by environment factors?

 

The information gathered as part of the analysis activity is used to create an analysis model for the interface. Using this model as a basis, the design activity commences.

The goal of interface design is to define a set of interface objects and actions that enable a user to perform all defined tasks in a manner that meets every usability goal defined for the system. The implementation activity normally begins with the creation of a prototype that enables usage scenarios to be evaluated.

 

3. Interface Design Activities

 

Once task analysis has been completed, all tasks required by the end-user have been identified in detail and the interface design activity commences.

 

ü  Establish the goals and intentions for each task.

ü  Map each goal and intention to a sequence of specific actions.

ü  Specify the action sequence of tasks and subtasks, also called a user scenario, as it will be executed at the interface level.

ü  Indicate the state of the system; i.e. what does the interface look like at the time that a user scenario is performed?

ü  Define control mechanisms; i.e. the objects and actions available to the user to alter the system state.

ü  Show how control mechanisms affect the state of the system.

ü  Indicate how the user interprets the state of the system from information provided through the interface.

 

3.1 Defining Interface Objects and Actions

 

Once the objects and actions have been defined and elaborated iteratively, they are categorized by type. A Source object is dragged and dropped onto a target object. The implication of this action is to create a hard –copy report. An application object represents application-specific data that is not directly manipulated as part of screen interaction. When the designer is satisfied that all important objects and actions have been defined. Screen layout is performed. Like other interface design activities, screen layout is an interactive process in which graphical design and placement of icons, definition of descriptive screen text, specification and titling for windows, and definition of major and minor menu items is conducted.

 

3.2 Design Issues

 

The design of a user interface evolves, four common design issues almost always surface; system response, user help facilities, error information handling, and command labeling. System response time is primary complaint for many interactive applications. System response time is measured from the point at which the user performs some control action until the software response with desired output or action.

System response time has two important characteristics: length and variability. If the length of system response is too long, user frustration and stress is the inevitable result. A very brief response time can also be detrimental if the user is being paced by the interface. A rapid response may force the user to rush and therefore make mistakes.

 

Variability refers to the deviation from average response time, and in many ways, it is the most important response time characteristic. Low variability enables the user to establish an interaction rhythm, even if response time is relatively long.

September 3, 2008 Posted by | Design, Software Engineer, User Interface Design | | Leave a comment