Architecture & User Interface Design

1. Architecture & User Interface Design

2. Software Architecture • “The software architecture of a program or computing system is the structure or structures of the system, which comprise the software components, the externally visible properties of those components, and the relationships among them.” • It is not operational software but it is representation that enables software engineer to • Analyze the effectiveness of design in meeting its stated requirement. • consider architectural alternatives at a stage when making design changes is still relatively easy, • reduce the risks associated with the construction of the software.

3. Importance of Software Architecture • Representations of software architecture are an enabler for communication between all parties (stakeholders) interested in the development • Architecture highlights early design decisions that will have a profound impact on all software engineering work that follows. • Architecture “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together”

4. Data Design • The structure of data has always been an important part of software design. • Component level – the design of data structures and the associated algorithms required to manipulate them is essential to the creation of high-quality applications. • Application level – the translation of a data model into a database design

5. Data Design at architectural design • Today, business (i.e. irrespective of its size large or small) have dozens of database serving many applications encompassing hundreds of gigabytes of data. • Challenge is to extract useful information from its data environment, particularly when the information desired is cross-functional. • To solve this challenge, developed technique called • Data Mining (also called knowledge discovery in databases (KDD)), • Data Warehouse • Data mining that navigate through existing databases in an attempt to extract appropriate business-level information

6. However, the existence of multiple databases, their different structures, the degree of detail contained with the databases, and many other factors make data mining difficult within an existing database environment. • 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.

7. Data design at the component level • Component level focuses on the representation of data structures that are directly accessed by one or more software components. Principles are applicable to data design • 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 (operations) • Low-level data design decisions should be deferred until late in the design process.

8. 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 language should support the specification and realization of abstract data types.

9. Architectural Style • Style describes a system category that encompasses • A set of components (e.g., a database, computational modules) that perform a function required by a system; • a set of connectors that enable “communication, co-ordinations and cooperation” among components; • constraints that define how components can be integrated to form the system • semantic models that enable a designer to understand the overall properties of a system It can be represent by • Data-centered architecture • Data flow architecture • Call and return architecture • Object oriented architecture • Layered architecture.

10. Data-centered architecture

11. Data-centered architecture • A data store (e.g., a file or database) 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. • Client software accesses a central repository which is in passive state (in some cases). • client software accesses the data independent of any changes to the data or the actions of other client software. • So, in this case transform the repository into a “Blackboard”. • A blackboard sends notification to subscribers when data of interest changes, and is thus active. • Data-centered architectures promote integrability. • Existing components can be changed and new client components can be added to the architecture without concern about other clients. • Data can be passed among clients using the blackboard mechanism. So Client components independently execute processes

12. Data Flow architecture Pipes and filters Batch Sequential

13. Data Flow architecture • 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 (Fig .1) has a set of components, called filters, connected by pipes that transmit data from one component to the next. • Each filter works independently (i.e. upstream, downstream) and is designed to expect data input of a certain form, and produces data output (to the next filter) of a specified form. • the filter does not require knowledge of the working of its neighboring filters. • If the data flow degenerates into a single line of transforms, it is termed batch sequential.

14. Call and return architecture

15. Call and return architecture • Architecture style enables a software designer (system architect) to achieve a program structure that is relatively easy to modify and scale. • Two sub-styles exist within this category: • Main/sub program architecture: • Program structure decomposes function into a control hierarchy where a “main” program invokes a number of program components, which in turn may invoke still other components. • Remote procedure Call architecture: • The components of a main program/subprogram architecture are distributed across multiple computers on a network

16. Object-oriented architecture

17. Object-oriented architecture • The object-oriented paradigm, like the abstract data type paradigm from which it evolved, emphasizes the bundling of data and methods to manipulate and access that data (Public Interface). • Components of a system summarize data and the operations that must be applied to manipulate the data. • Communication and coordination between components is accomplished via message passing.

18. Layered Architecture

19. A number of different layers are defined, each accomplishing operations that progressively become closer to the machine instruction set. • At the outer layer, components examine user interface operations. • At the inner layer, components examine operating system interfacing. • Intermediate layers provide utility services and application software functions.

20. User Interface Design • User interface design creates an effective communication medium between a human and a computer. • Following a set of interface design principles, design identifies interface objects and actions and then creates a screen layout that forms the basis for a user interface prototype.

21. Design Evaluation user interface evaluation cycle

22. After the design model has been completed, a first-level prototype is created. • The prototype is evaluated by the user, who provides the designer with direct comments about the efficiency of the interface. • In addition, if formal evaluation techniques are used (e.g., questionnaires, rating sheets), the designer may extract information from these data. • Design modifications are made based on user input and the next level prototype is created. • The evaluation cycle continues until no further modifications to the interface design are necessary. • The prototyping approach is effective, but is it possible to evaluate the quality of a user interface before a prototype is built? • If potential problems uncovered and corrected early, the number of loops through the evaluation cycle will be reduced and development time will shorten.

23. Evaluation criteria can be applied during early design reviews: • The length and complexity of the written specification of the system and its interface provide an indication of the amount of learning required by users of the system. • The number of user tasks specified and the average number of actions per task provide an indication of interaction time and the overall efficiency of the system. • The number of actions, tasks, and system states indicated by the design model imply the memory load on users of the system. • Interface style, help facilities, and error handling protocol provide a general indication of the complexity of the interface and the degree to which it will be accepted by the user.

24. Once the first prototype is built, the designer can collect a variety of qualitative and quantitative data that will assist in evaluating the interface. • To collect qualitative data, questionnaires can be distributed to users of the prototype. • Questions can be all • simple yes/no response, • numeric response, • scaled (subjective) response, • percentage (subjective) response. • Likert scale (e.g. strongly disagree, somewhat agree). • Open-minded.

25. Example

26. If quantitative data desired, a form of time study analysis can be conducted. • Users are observed during interaction, and data such as • number of tasks correctly completed over a standard time period, • frequency & sequence of actions, • time spent "looking" at the display, • number and types of errors, • error recovery time, • time spent using help, and number of help references per standard time period.

27. Design Engineering

28. Design Engineering • It covers the set of principles, concepts, and practices that lead to the development of a high quality system or product. • Goal of design engineering is to produce a model or representation that depict: • Firmness – program should not have any bug that inhibits its functions. • Commodity – suitable to its intended use. • Delight - pleasurable to use • The design model provides detail about software data structures, architecture, interfaces, and components that are necessary to implement the system.

29. Software Design • Software design model consists of 4 designs: • Data/class Design • Architectural Design • Interface Design • Component Design

30. Translating Analysis  Design

31. Data/class design - Created by transforming the analysis model class-based elements into classes and data structures required to implement the software • Architectural design - defines the relationships among the major structural elements of the software, it is derived from the class-based elements and flow-oriented elements of the analysis model • Interface design - describes how the software elements, hardware elements, and end-users communicate with one another, it is derived from the analysis model scenario-based elements, flow-oriented elements, and behavioral elements • Component-level design - created by transforming the structural elements defined by the software architecture into a procedural description of the software components using information obtained from the analysis model class-based elements, flow-oriented elements, and behavioral elements

32. Why design is so important? • It is place where quality is fostered. • It provides us with representation of software that can be assessed for quality. • Only way that can accurately translate a customer’s requirements into a finished software product. • It serves as foundation for all software engineering activities. • Without design difficult to assess: • Risk • Test • Quality

33. Design Process and Design Quality • S/w design is an iterative process through which requirements are translated into a “blueprint” for constructing the s/w. • As design iteration occur, subsequent refinement leads to design representation at much lower levels of abstraction.

34. Goal of design process • The design must implement all of the explicit requirements contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer. • The design must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software. • The design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.

35. Quality Guidelines Characteristics of good design • A design should exhibit an architecture that • as been created using recognizable architectural styles or patterns, • is composed of components that exhibit good design characteristics and • can be implemented in an evolutionary fashion • A design should be modular; that is, the software should be logically partitioned into elements or subsystems • A design should contain distinct representations of data, architecture, interfaces, and components. • A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recognizable data patterns. • A design should lead to components that exhibit independent functional characteristics

36. Quality Guidelines (contd.) • A design should lead to interfaces that reduce the complexity of connections between components and with the external environment. • A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis. • A design should be represented using a notation that effectively communicates its meaning.

37. Design Principles • S/W design is both a process and a model. • Design process - sequence of steps that enable the designer to describe all aspects of the software to be built. • Design model - created for software provides a variety of different views of the computer software

38. The design process should not suffer from ‘tunnel vision.’ - Designer should consider alternative approaches. • The design should be traceable to the analysis model - a single element of the design model often traces to multiple requirements, it is necessary to have a means for tracking how requirements have been satisfied by the design model. • The design should not reinvent the wheel- use already exists design pattern because time is short and resource are limited. • The design should “minimize the intellectual distance” between the software and the problem as it exists in the real world. – design should be self-explanatory

39. The design should exhibit uniformity and integration – before design work begins rules of styles and format should be defined for a design team. • The design should be structured to accommodate change • The design should be structured to degrade gently, even when unusual data, events, or operating conditions are encountered. • Design is not coding, coding is not design. • The design should be assessed for quality as it is being created, not after the fact • The design should be reviewed to minimize conceptual (semantic) errors.

40. Design concepts • Design concepts provide the necessary framework for “to get the thing on right way”. • Abstraction • Refinement • Modularity • Architecture • Control Hierarchy • Structural Partitioning • Data Structure • Software Procedure • Information Hiding

41. Abstraction • At the highest level of abstraction – a solution is stated in broad terms • At lower level of abstraction – a more detailed description of the solution is provided. • Two types of abstraction: • Procedural abstraction: Sequence of instructions that have a specific and limited function. Ex. Open a door open implies long sequence of activities (e.g. walk to the door, grasp knob, turn knob and pull the door, etc). • Data abstraction: collection of data that describes a data object. Ex. Open a door. – door is data object. • Data abstraction for door would encompass a set of attributes that describe the door. (E.g. door type, swing direction, opening mechanism, etc.)

42. Refinement • Refinement is actually a process of elaboration. • begin with a statement of function (or description of information) that is defined at a high level of abstraction. • That is, the statement describes function or information conceptually but provides no information about the internal workings of the function or the internal structure of the information. • Refinement causes the designer to elaborate on the original statement, providing more and more detail as each successive refinement (elaboration) occurs. • Abstraction and refinement are complementary concepts. Abstraction enables a designer to specify procedure and data and yet suppress low-level details. • Refinement helps the designer to expose low-level details as design progresses.

43. Modularity • Architecture and design pattern embody modularity. • Software is divided into separately named and addressable components, sometimes called modules, which are integrated to satisfy problem requirement. • modularity is the single attribute of software that allows a program to be intellectually manageable • It leads to a “divide and conquer” strategy. – it is easier to solve a complex problem when you break into a manageable pieces. • Refer fig. that state that effort (cost) to develop an individual software module does decrease if total number of modules increase. • However as the no. of modules grows, the effort (cost) associated with integrating the modules also grows.

44. Modularity and software cost

45. Undermodularity and overmodularity should be avoided. But how do we know the vicinity of M? • We modularize a design so that development can be more easily planned. • Software increments can be defined and delivered. • Changes can be more easily accommodated. • Testing and debugging can be conducted more efficiently and long-term maintained can be conducted without serious side effects.

46. Architecture • Software architecture suggest “ the overall structure of the software and the ways in which that structure provides conceptual integrity for a system. • No. of different models can use to represent architecture. • Structural Model- represent architecture as an organized collection of components • Framework model – Increase level of design abstraction by identifying repeatable architectural design framework. • Dynamic model – address behavior of the program architecture and indicating how system or structure configuration may change as a function. • Process Model – focus on design of the business or technical process that the system must accommodate. • Functional models – used to represent the functional hierarchy of a system.

47. Control Hierarchy • Control hierarchy, represents the organization of program components (modules) and implies a hierarchy of control. • Different notations are used to represent control hierarchy for those architectural styles that are amenable to this representation. • The most common is the treelike diagram that represents hierarchical control for call and return architectures.

48. Control Hierarchy

49. In fig. depth and width provide an indication of the number of levels of control and overall span of control. • Fan-out is a measure of the number of modules that are directly controlled by another module. Fan-in indicates how many modules directly control a given module. • A module that controls another module is said to be superordinate to it, and conversely, a module controlled by another is said to be subordinate to the controller. Ex. Module M is superordinate to modules a, b, and c. Module h is subordinate to module e

50. Structural Partitioning