© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Interaction Design Process and Heuristics.

Slides:



Advertisements
Similar presentations
Understand and appreciate Object Oriented Programming (OOP) Objects are self-contained modules or subroutines that contain data as well as the functions.
Advertisements

Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Interaction Design & UML Sequence Diagram
Object-Oriented Application Development Using VB.NET 1 Chapter 5 Object-Oriented Analysis and Design.
Chapter 13 Design Concepts and Principles
Design Phase What’s design?
Design Concepts And Principles Software Design -- An iterative process transforming requirements into a “blueprint” for constructing the software.
Chapter 10 THINKING IN OBJECTS 1 Object Oriented programming Instructor: Dr. Essam H. Houssein.
Solutions to Review Questions. 4.1 Define object, class and instance. The UML Glossary gives these definitions: Object: an instance of a class. Class:
Chapter 3 Data Abstraction: The Walls. © 2005 Pearson Addison-Wesley. All rights reserved3-2 Abstract Data Types Modularity –Keeps the complexity of a.
Design The goal is to design a modular solution, using the techniques of: Decomposition Abstraction Encapsulation In Object Oriented Programming this is.
© 2005 Prentice Hall8-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Chapter 1 Principles of Programming and Software Engineering.
Copyright © 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Starting Out with C++ Early Objects Sixth Edition Chapter 6: Functions by.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
Introduction SWE 619. Why Is Building Good Software Hard? Large software systems enormously complex  Millions of “moving parts” People expect software.
The Design Discipline.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Engineering Design Resolution & Design Principles.
Design Patterns OOD. Course topics Design Principles UML –Class Diagrams –Sequence Diagrams Design Patterns C#,.NET (all the course examples) Design Principles.
1/19 Component Design On-demand Learning Series Software Engineering of Web Application - Principles of Good Component Design Hunan University, Software.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Architectural Design.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Detailed Design Overview and Mid-Level Class Modeling.
GRASP Principles. How to Design Objects The hard step: moving from analysis to design How to do it? –Design principles (Larman: “patterns”) – an attempt.
CSE 303 – Software Design and Architecture
© 2014 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
SOFTWARE DESIGN (SWD) Instructor: Dr. Hany H. Ammar
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Architectural Styles.
SOFTWARE DESIGN.
Copyright © 2012 Pearson Education, Inc. Chapter 6: Functions.
SOFTWARE DESIGN Design Concepts Design is a meaningful engineering representation of something that is to be built It can be traced to a customer’s requirements.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Product Design Finalization; Inspections.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Visibility, Accessibility, and Information Hiding.
Architectural Design Identifying system components and their interfaces.
Systems Analysis and Design in a Changing World, 3rd Edition
Chapter 12: Design Phase n 12.1 Design and Abstraction n 12.2 Action-Oriented Design n 12.3 Data Flow Analysis n Data Flow Analysis Example n
Design Concepts and Principles Instructor: Dr. Jerry Gao.
Chapter 13 Design Concepts and Principles Software Engineering: A Practitioner's Approach, 5/e.
2 Object-Oriented Analysis and Design and the Unified Process Objectives  Explain the purpose and objectives of object- oriented design  Develop design.
Copyright © 2013 Pearson Education, Inc. Publishing as Prentice Hall 5-1 Designing Organizational Structure: Authority and Control.
Software Engineering Principles. SE Principles Principles are statements describing desirable properties of the product and process.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:
9-Dec Dec-15  INTRODUCTION.  FEATURES OF OOP.  ORGANIZATION OF DATA & FUNCTION IN OOP.  OOP’S DESIGN.
 Design goals are derived form the non- functional requirements  Every subsystem is assigned to a team and realized independently  During system design,
© 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.
Software Engineering and Object-Oriented Design Topics: Solutions Modules Key Programming Issues Development Methods Object-Oriented Principles.
Copyright © 2014, 2008 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 6: Functions Starting Out with C++ Early Objects Eighth Edition.
Or how to work smarter when building solutions.  2:30 – 3:30 Mondays – focus on problem solving (with some terminology thrown in upon occasion)  All.
ISBN Chapter 11 Abstract Data Types and Encapsulation Concepts.
Copyright © 2015, 2012, 2009 Pearson Education, Inc., Publishing as Addison-Wesley All rights reserved. Chapter 6: Functions.
Developed by Cool Pictures & MultiMedia PresentationsCopyright © 2004 by South-Western, a division of Thomson Learning. All rights reserved. Fundamentals.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Broker Design Patterns: Façade and Mediator.
Chapter 2 Principles of Programming and Software Engineering.
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 6-1 # Copyright © 2015 Pearson Education, Inc. Organizing the Business 6 Copyright.
Basic Characteristics of Object-Oriented Systems
BUSINESS 7e Copyright 2004 Prentice Hall, Inc.1 CHAPTER 7 Organizing the Business Enterprise.
11 Systems Analysis and Design in a Changing World, Fifth Edition.
Unit - 3 OBJECT ORIENTED DESIGN PROCESS AND AXIOMS
Chapter 12: Collaboration Diagram - PART2
Lecture 9- Design Concepts and Principles
Principles of Programming and Software Engineering
The Object Oriented Approach to Design
Copyright © 2013 Pearson Education, Inc. Publishing as Prentice Hall
CS223: Software Engineering
Software Architecture
Design Model Like a Pyramid Component Level Design i n t e r f a c d s
Lecture 9- Design Concepts and Principles
Introduction to Object-Oriented Programming
Design Yaodong Bi.
Presentation transcript:

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Interaction Design Process and Heuristics

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2 Objectives  To present an overview of the interaction design process  To present alternative control styles and consider their strengths and weaknesses  To present interaction design heuristics

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 3 Topics  Component and interaction co-design and outside-in design  Controllers and control styles Centralized Delegated Dispersed  Interaction design heuristics  The Law of Demeter

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 4 Component and Interaction Co-Design  Components cannot be designed alone because they may not support needed interactions.  Interactions cannot be designed alone because they may rely on missing features of components or missing components.  Components and interactions must be designed together iteratively.

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 5 Outside-In Design  Interaction design should be mainly top- down (from most to least abstract interactions).  The most abstract interactions are specified in the SRS and use case models.  Starting with the interactions between the program and its environment (outside) and designing how interacting components can implement them (inside) is called outside-in design.

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 6 Controllers Controller are important because they are the central figures in collaborations. A controller is a program component that makes decisions and directs other components.

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 7 Control Styles A control style is a way that decision making is distributed among program components. Centralized—A few controller make all significant decisions Delegated—Decision making is distributed through the program with a few controllers making the main decisions Dispersed—Decision making is spread widely through the program with few or no components making decisions on their own

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 8 Centralized Control  Easy to find where decisions are made  Easy to see how decisions are made and to alter the decision-making process  Controllers may become bloated —large, complex, and hard to understand, maintain, test, etc.  Controller may treat other components as data repositories Increases coupling Destroys information hiding

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 9 Centralized Control Form

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 10 Less-Centralized Control Form

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 11 Control Heuristics 1  Avoid interaction designs where most messages originate from a single component.  Keep components small.  Make sure operational responsibilities are not all assigned to just a few components.  Make sure operational responsibilities are consistent with data responsibilities.

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 12 Delegated Control  Controller are coupled to fewer components, reducing coupling.  Information is hidden better.  Programs are easier to divide into layers.  Delegated control is the preferred control style.

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 13 Control Heuristics 2  Have components delegate as many low- level tasks as possible.

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 14 Dispersed Control Style  Characterized by having many components holding little data and having few responsibilities.  It is hard to understand the flow of control.  Components are unable to do much on their own, increasing coupling.  It is hard to hide information.  Cohesion is usually poor.  Few modularity principles can be satisfied.

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 15 Control Heuristics 3  Avoid interactions that require each component to send many messages.

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 16 Law of Demeter An operation of an object obj should send messages only to the following entities: The object obj; The attributes of obj; The arguments of the operation; The elements of a collection that is an argument of the operation or an attribute of obj; Objects created by the operation; and Global classes or objects.

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 17 Consequences of the Law of Demeter  Objects send messages only to objects “directly known” to them.  The Law of Demeter helps to Hide information, Keep coupling low, Keep cohesion high, Discourage an over-centralized control style, and Encourage a delegated control style.

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 18 Remarks on Control Styles and Heuristics  There is a continuum of control styles with centralized and dispersed on the ends and delegated in the middle.  Different levels of centralization may be more or less appropriate depending on the problem.  The control heuristics are in tension.

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 19 Summary 1  Interactions and components cannot be designed independently, so they must be designed together iteratively (component and interaction co-design).  Interaction design should proceed top- down (outside-in).  Controllers are important components in designing interactions.  We can distinguish various control styles on a continuum of centralization versus distribution.

© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 20 Summary 2  A delegated control style in which a few controllers make important decisions but delegate other decisions to subordinates is usually best.  Various heuristics, including the Law of Demeter, encourage control styles that maximize information hiding and cohesion and minimize coupling.