1 Chapter : Architecture & User Interface Design.

Slides:



Advertisements
Similar presentations
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Advertisements

Design Concepts and Principles
Chapter 14: Design Method --- data and architectural design Design -- A multistep process in which representations of data structure, program structure,
Software Architecture Design Instructor: Dr. Jerry Gao.
Architectural Design Principles. Outline  Architectural level of design The design of the system in terms of components and connectors and their arrangements.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Objectives The key roles an architecture description plays in a software project. The key roles an architecture description plays in a software project.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 2 Overview of Database Languages and Architectures.
Course Instructor: Aisha Azeem
Chapter 10: Architectural Design
1 User Interface Design CIS 375 Bruce R. Maxim UM-Dearborn.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Architectural Design.
What is Software Architecture?
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Chapter 7 Requirement Modeling : Flow, Behaviour, Patterns And WebApps.
Chapter 10 Architectural Design
1 Chapter 14 Architectural Design. 2 Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a.
1 COSC 4406 Software Engineering COSC 4406 Software Engineering Haibin Zhu, Ph.D. Dept. of Computer Science and mathematics, Nipissing University, 100.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.1.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
1 Chapter 14 Architectural Design 2 Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a.
Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a software engineer to: (1) analyze the.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 07. Review Architectural Representation – Using UML – Using ADL.
Lecture 9: Chapter 9 Architectural Design
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Architecture styles Pipes and filters Object-oriented design Implicit invocation Layering Repositories.
SOFTWARE DESIGN.
1 Software Design Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13, 5 th edition and Ch. 10, 6 th edition.
RELATIONAL FAULT TOLERANT INTERFACE TO HETEROGENEOUS DISTRIBUTED DATABASES Prof. Osama Abulnaja Afraa Khalifah
Chapter 13 Architectural Design
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Developing Component- Based Systems X LIU, School of Computing, Napier University TIP This chapter discusses the techniques to develop component-based.
Unit 2 Architectural Styles and Case Studies | Website for Students | VTU NOTES | QUESTION PAPERS | NEWS | RESULTS 1.
ARCHITECTURAL DESIGN. Why is Architecture Important? Representations of software architecture are an enabler for communication between all parties (stakeholders)
SOFTWARE DESIGN. INTRODUCTION There are 3 distinct types of activities in design 1.External design 2.Architectural design 3.Detailed design Architectural.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:
1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,
CSC480 Software Engineering Lecture 10 September 25, 2002.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
Architectural Design Introduction Design has been described as a multistep process in which representations of data and program structure,
Software Engineering B.Tech IT/II Sem-II Term: Unit-4 PPT SLIDES Text Books:1.Software Engineering, A practitioner’s approach Roger s. Pressman.
Lecture VIII: Software Architecture
Chapter : 9 Architectural Design
Chapter 13 설계 개념 Architectural Design 임현승 강원대학교 Revised from the slides by Roger S. Pressman and Bruce R. Maxim for the book “Software Engineering: A Practitioner’s.
Chapter : 9 Architectural Design. Software Architecture What Is Architecture? The software architecture of a program or computing system is the structure.
Unit 5 - S. S. Deshmukh. Architectural design Architectural design represents the structure of data and program components that are required to build.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
SOFTWARE DESIGN & SOFTWARE ENGINEERING Software design is a process in which data, program structure, interface and their details are represented by well.
Chapter 9 Architectural Design. Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a software.
1 Chapter 2: Architectural Design. 2 Introduction Structure or structures of the system, which comprise software components, the externally visible properties.
Chapter 13 Architectural Design
Software Design and Architecture
Chapter 13 Architectural Design
Part 3 Design What does design mean in different fields?
CHAPTER 2 CREATING AN ARCHITECTURAL DESIGN.
Ch > 28.4.
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 2 Database System Concepts and Architecture.
Ch 15 –part 3 -design evaluation
Chapter 9 Architectural Design
Software Architecture
Design Model Like a Pyramid Component Level Design i n t e r f a c d s
Chapter 13 Architectural Design
Chapter 9 Architectural Design.
Call and return architectures
Software Engineering: A Practitioner’s Approach, 6/e Chapter 10 Architectural Design copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For.
Presentation transcript:

1 Chapter : 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 1. The systematic analysis principles applied to function and behavior should also be applied to data. 2. All data structures and the operations to be performed on each should be identified. 3. A data dictionary should be established and used to define both data and program design (operations) 4. Low-level data design decisions should be deferred until late in the design process.

8 5. The representation of data structure should be known only to those modules that must make direct use of the data contained within the structure. 6. A library of useful data structures and the operations that may be applied to them should be developed. 7. 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 1. A set of components (e.g., a database, computational modules) that perform a function required by a system; 2. a set of connectors that enable “communication, co- ordinations and cooperation” among components; 3. constraints that define how components can be integrated to form the system 4. 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: 1. 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. 2. 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: 1. 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. 2. 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. 3. The number of actions, tasks, and system states indicated by the design model imply the memory load on users of the system. 4. 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.