sw-1.pdf

Software Engineering Vinaya Sathyanarayana Architecture https://c4model.com/ Context, Containers, Components, and Code System Context diagram A System Context diagram is a good starting point for diagramming and documenting a software system, allowing you to step back and...

Software Engineering Vinaya Sathyanarayana Architecture https://c4model.com/ Context, Containers, Components, and Code System Context diagram A System Context diagram is a good starting point for diagramming and documenting a software system, allowing you to step back and see the big picture. Draw a diagram showing your system as a box in the centre, surrounded by its users and the other systems that it interacts with. Detail isn't important here as this is your zoomed out view showing a big picture of the system landscape. The focus should be on people (actors, roles, personas, etc) and software systems rather than technologies, protocols and other low-level details. It's the sort of diagram that you could show to non-technical people. Container diagram Once you understand how your system fits in to the overall IT environment, a really useful next step is to zoom-in to the system boundary with a Container diagram. A "container" is something like a server-side web application, single-page application, desktop application, mobile app, database schema, file system, etc. Essentially, a container is a separately runnable/deployable unit (e.g. a separate process space) that executes code or stores data. The Container diagram shows the high-level shape of the software architecture and how responsibilities are distributed across it. It also shows the major technology choices and how the containers communicate with one another. It's a simple, high-level technology focussed diagram that is useful for software developers and support/operations staff alike. Component diagram Next you can zoom in and decompose each container further to identify the major structural building blocks and their interactions. The Component diagram shows how a container is made up of a number of "components", what each of those components are, their responsibilities and the technology/implementation details. Code diagram Finally, you can zoom in to each component to show how it is implemented as code; using UML class diagrams, entity relationship diagrams or similar. This is an optional level of detail and is often available on-demand from tooling such as IDEs. Ideally this diagram would be automatically generated using tooling (e.g. an IDE or UML modelling tool), and you should consider showing only those attributes and methods that allow you to tell the story that you want to tell. This level of detail is not recommended for anything but the most important or complex components. Unit 9 Design Concepts  Software Design Encompasses the set of principles, concepts, and practices that lead to the development of a high quality system or product. Design principles establish and overriding philosophy that guides the designer as the work is performed. Design concepts must be understood before the mechanics of design practice are applied. Software design practices change continuously as new methods, better analysis, and broader understanding evolve. 8 Software Engineering Design Data/Class design – transforms analysis classes into implementation classes and data structures. Architectural design – defines relationships among the major software structural elements. Interface design – defines how software elements, hardware elements, and end-users communicate. Component-level design – transforms structural elements into procedural descriptions of software components. 9 Mapping Requirements Model to Design Model Access the text alternative for slide images. 10  Design and Quality 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 should 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. 11 Quality Guidelines 1. A design should exhibit an architecture (a) created using recognizable architectural styles or patterns, (b) composed of well designed components (c) implemented in an evolutionary fashion. 2. A design should be modular. 3. A design should contain distinct representations of data, architecture, interfaces, and components. 4. A design should lead to data structures that are drawn from recognizable data patterns. 5. A design should contain functionally independent components. 6. A design should lead to interfaces that reduce the 12 complexity of connections between components and Common Design Characteristics Each new software design methodology introduces unique heuristics and notions – yet they each contain: 1. A mechanism for the translating the requirements model into a design representation. 2. A notation for representing functional components and their interfaces. 3. Heuristics for refinement and partitioning. 4. Guidelines for quality assessment. 13 Design Concepts 1 Abstraction – data (named collection of data describing data object), procedural (name sequence of instructions with specific and limited function). Architecture - overall structure or organization of software components, ways components interact, and structure of data used by components. Design Patterns - describe a design structure that solves a well-defined design problem within a specific context. Separation of concerns - any complex problem can be more easily handled if it is subdivided into pieces. Modularity—compartmentalization of data and function. 14 Modularity and Software Cost Access the text alternative for slide images. 15 Design Concepts 2 Information Hiding - controlled interfaces which define and enforces access to component procedural detail and any local data structure used by the component. Functional independence - single-minded (high cohesion) components with aversion to excessive interaction with other components (low coupling). Stepwise Refinement – incremental elaboration of detail for all abstractions. Refactoring—a reorganization technique that simplifies the design without changing functionality. Design Classes—provide design detail that will enable analysis classes to be implemented. 16 Design Class Example Access the text alternative for slide images. 17 Design Class Characteristics Complete - includes all necessary attributes and methods) and sufficient (contains only those methods needed to achieve class intent). Primitiveness – each class method focuses on providing one service. High cohesion – small, focused, single-minded classes. Low coupling – class collaboration kept to minimum. 18 Information Hiding Reduces the likelihood of “side effects.” Limits the global impact of local design decisions. Emphasizes communication through controlled interfaces. Discourages the use of global data. Leads to encapsulation—an attribute of high quality design. Results in higher quality software. 19 Architecture Properties Structural properties. This aspect of the architectural design representation defines the components of a system (for example, modules, objects, filters) and the manner in components are packaged and interact with one another. Extra-functional properties. The architectural design description should address how the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and other characteristics. Families of related systems. The architectural design should draw upon repeatable patterns (building blocks) often encountered in the design of similar systems. 20 Design Pattern Template Pattern name - describes the essence of the pattern in a short but expressive name Intent - describes the pattern and what it does Also-known-as - lists any synonyms for the pattern Motivation - provides an example of the problem Applicability - notes specific design situations in which the pattern is applicable Structure - describes the classes that are required to implement the pattern Participants - describes the responsibilities of the classes that are required to implement the pattern Collaborations - describes how the participants collaborate to carry out their responsibilities Consequences - describes the “design forces” that affect the pattern and the potential trade-offs that must be considered when the pattern is implemented Related patterns - cross-references related design patterns 21 Design Model Access the text alternative for slide images. 22 Design Modeling Principles 1 Principle #1. Design should be traceable to the requirements model. Principle #2. Always consider the architecture of the system to be built. Principle #3. Design of data is as important as design of processing functions. Principle #4. Interfaces (both internal and external) must be designed with care. Principle #5. User interface design should be tuned to the needs of the end-user and stress ease of use. 23 Design Modeling Principles 2 Principle #6. Component-level design should be functionally independent. Principle #7. Components should be loosely coupled to each other than the environment. Principle #8. Design representations (models) should be easily understandable. Principle #9. The design should be developed iteratively. Principle #10. Creation of a design model does not preclude using an agile approach. 24 Data Design Elements Data model – data objects and database architectures. Examines data objects independently of processing. Focuses attention on the data domain. Creates a model at the customer’s level of abstraction. Indicates how data objects relate to one another. Data object can be an external entity, a thing, an event, a place, a role, an organizational unit, or a structure. Data objects contain a set of attributes that act as an quality, characteristic, or descriptor of the object. Data objects may be connected to one another in many different ways. 25 Architectural Design Elements Architectural design for software - equivalent to the floor plan for a house. The architectural model is derived from three sources: Information about the application domain for the software to be built. Specific requirements model elements such as data flow analysis classes and their relationships (collaborations) for the problem at hand, and Availability of architectural patterns and styles. 26 Interface Design Elements Interface is a set of operations that describes the externally observable behavior of a class and provides access to its public operations. Important elements: User interface (UI). External interfaces to other systems. Internal interfaces between various design components. UI or User Experience (UX) is a major engineering action to ensure the creation on usable software products. Internal and external interfaces should incorporate both error checking and appropriate security features. 27 Interface Model for Control Panel Access the text alternative for slide images. 28 Component-Level Design Elements Describes the internal detail of each software component. Defines: Data structures for all local data objects. Algorithmic detail for all component processing functions. Interface that allows access to all component operations. Modeled using UML component diagrams. 29 Deployment Design Elements Indicates how software functionality and subsystems will be allocated within the physical computing environment. Modeled using UML deployment diagrams. Descriptor form deployment diagrams - show the computing environment but does not indicate configuration details. Instance form deployment diagrams - identify specific hardware configurations and are developed in the latter stages of design. 30 UML Deployment Instance Diagram Access the text alternative for slide images. 31  Unit 10 Architectural Design What is Software Architecture? The architecture is not the operational software, 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. Reduce the risks associated with the construction of the software. 33 Why is Software Architecture Important? Software architecture provides a representation that facilitates communication among all stakeholders interested in the development of a computer-based system. 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 mode of how the system is structured and how its components work together. 34 Architectural Descriptions The IEEE Computer Society has proposed IEEE-Std-42010-2011, Systems and Software Engineering – Architecture Description. Describes the use of architecture viewpoints, architecture frameworks, and architecture description languages as a means of codifying the conventions and common practices for architectural description. The IEEE Standard defines an architectural description (AD) as a “a collection of products to document an architecture.” An architecture description shall identify the system stakeholders having concerns considered fundamental to the architecture of the system-of-interest. These concerns shall be considered when applicable and identified in the architecture description: system purpose, suitability of the architecture, feasibility of constructing and deploying the system, risks and impacts of the system, and the maintainability and evolvability of the system. 35 Architecture Decision Documentation 1. Determine information items needed for each decision. 2. Define links between each decision and appropriate requirements. 3. Provide mechanisms to change status when alternative decisions need to be evaluated. 4. Define prerequisite relationships among decisions to support traceability. 5. Link significant decisions to architectural views resulting from decisions. 6. Document and communicate all decisions as they are made. 36 Agility and Architecture To avoid rework, user stories are used to create and evolve an architectural model (walking skeleton) before beginning any coding. Use models which allow software architects to add user stories to the evolving storyboard and works with the product owner to prioritize the architectural stories as “sprints” (work units) are planned. Well run agile projects include delivery of architectural documentation during each sprint. After the sprint is completed, the architect reviews the working prototype for quality before the team presents it to the stakeholders in a formal sprint review. 37 Architectural Styles Each style describes a system category that encompasses: 1. set of components (for example: a database, computational modules) that perform a function required by a system. 2. set of connectors that enable “communication, coordination 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 by analyzing the known properties of its constituent parts. 38 Data Centered Architecture Access the text alternative for slide images. 39 Data Flow Architecture Access the text alternative for slide images. 40 Call Return Architecture Access the text alternative for slide images. 41 Object-Oriented Architecture Access the text alternative for slide images. 42 Layered Architecture Access the text alternative for slide images. 43 Model View Controller Architecture Access the text alternative for slide images. 44 Architectural Organization and Refinement 1 Control. How is control managed within the architecture? Does a distinct control hierarchy exist, and if so, what is the role of components within this control hierarchy? How do components transfer control within the system? How is control shared among components? What is the control topology (that is, the geometric form that the control takes)? Is control synchronized, or do components operate asynchronously? 45 Architectural Organization and Refinement 2 Data. How are data communicated between components? Is the flow of data continuous, or are data objects passed to the system sporadically? What is the mode of data transfer? Do data components exist, and if so, what is their role? How do functional components interact with data components? Are data components passive or active? How do data and control interact within the system? 46 Architectural Considerations Economy – software is uncluttered and relies on abstraction to reduce unnecessary detail. Visibility – Architectural decisions and their justifications should be obvious to software engineers who review. Spacing – Separation of concerns in a design without introducing hidden dependencies. Symmetry – Architectural symmetry implies that a system is consistent and balanced in its attributes. Emergence – Emergent, self-organized behavior and control are key to creating scalable, efficient, and economic software architectures. 47 Architectural Design The software must be placed into context. The design should define the external entities (other systems, devices, people) that the software interacts with and the nature of the interaction. A set of architectural archetypes should be identified. An archetype is an abstraction (similar to a class) that represents one element of system behavior. The designer specifies the structure of the system by defining and refining software components that implement each archetype. 48 Architecture Context Diagram Access the text alternative for slide images. 49 SafeHome Security Function Archetype Access the text alternative for slide images. 50 SafeHome Top-Level Component Architecture Access the text alternative for slide images. 51 SafeHome Refined Component Architecture Access the text alternative for slide images. 52 Architectural Tradeoff Analysis 1. Collect scenarios. 2. Elicit requirements, constraints, environment description. 3. Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements using one of these views: module, process, data flow. 4. Evaluate quality attributes by considering each one in isolation. 5. Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style. 6. Critique candidate architectures (developed in step 3) using the sensitivity analysis (conducted in step 5). 53 Architectural Reviews Assess the ability of the software architecture to meet the systems quality requirements and identify potential risks. Have the potential to reduce project costs by detecting design problems early. Often make use of experience-based reviews, prototype evaluation, and scenario reviews, and checklists. 54 Pattern-based Architectural Reviews 1. Identify and discuss the quality attributes by walking through the use cases. 2. Discuss a diagram of system’s architecture in relation to its requirements. 3. Identify the architecture patterns used and match the system’s structure to the patterns’ structure. 4. Use existing documentation and use cases to determine each pattern’s effect on quality attributes. 5. Identify all quality issues raised by architecture patterns used in the design. 6. Develop a short summary of issues uncovered during the meeting and make revisions to the walking skeleton. 55  Unit 11 Component Level Design What is a component? OMG Unified Modeling Language Specification defines a component as “… a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.”” Object-Oriented view: a component contains a set of collaborating classes. Traditional view: a component contains processing logic, internal data structures that are required to implement the processing logic, and an interface that enables the component to be invoked and data to be passed to it. Process-related view: building systems out of reusable software components or design patterns selected from a catalog (component-based software engineering). 57 Class-based Component-Level Design Access the text alternative for slide images. 58 Traditional Component-Level Design 1 Access the text alternative for slide images. 59 Basic Component Design Principles Open-Closed Principle (O C P). “A module [component] should be open for extension but closed for modification. Liskov Substitution Principle (L S P). “Subclasses should be substitutable for their base classes. Dependency Inversion Principle (D I P). “Depend on abstractions. Do not depend on concretions.” Interface Segregation Principle (I S P). “Many client-specific interfaces are better than one general purpose interface. Release Reuse Equivalency Principle (R E P). “The granule of reuse is the granule of release.” Common Closure Principle (C C P). “Classes that change together belong together.” Common Reuse Principle (C R P). “Classes that aren’t reused together should not be grouped together.” 60 Component-Level Design Guidelines Components - Naming conventions should be established for components that are specified as part of the architectural model and then refined and elaborated as part of the component-level model. Interfaces - provide important information about communication and collaboration (as well as helping us to achieve the O P C). Dependencies and Inheritance – For readability, it is a good idea to model dependencies from left to right and inheritance from bottom (derived classes) to top (base classes). 61 Cohesion Traditional view - the “single-mindedness” of a module. Object-Oriented view - cohesion implies that a component encapsulates only attributes and operations that are closely related to one another and the component itself. Levels of cohesion: Functional - module performs one and only one computation. Layer - occurs when a higher layer accesses the services of a lower layer, but lower layers do not access higher layers. Communicational - All operations that access the same data are defined within one class. 62 Coupling Traditional view - degree to which a component is connected to other components and to the external world. Object-Oriented view - qualitative measure of the degree to which classes are connected to one another. Levels of coupling. Content - occurs when one component “surreptitiously modifies data that is internal to another component. Control – occurs when control flags a passed to components to requests alternate behaviors when invoked. External - occurs when a component communicates or collaborates with infrastructure components. 63 Component-Level Design 1 Step 1. Identify all design classes that correspond to the problem domain. Step 2. Identify all design classes that correspond to the infrastructure domain. Step 3. Elaborate all design classes that are not acquired as reusable components. Step 3a. Specify message details when classes or component collaborate. Step 3b. Identify appropriate interfaces for each component. 64 Collaboration Diagram with Message Detail Access the text alternative for slide images. 65 Define Interfaces Access the text alternative for slide images. 66 Component-Level Design 2 Step 3c. Elaborate attributes and define data types and data structures required to implement them. Step 3d. Describe processing flow within each operation in detail. Step 4. Describe persistent data sources (databases and files) and identify the classes required to manage them. Step 5. Develop and elaborate behavioral representations for a class or component. Step 6. Elaborate deployment diagrams to provide additional implementation detail. Step 7. Factor every component-level design representation and always consider alternatives. 67 Describe Processing Flow Access the text alternative for slide images. 68 Elaborate Behavioral Representations Access the text alternative for slide images. 69 Component-Level Design for WebApps WebApp component is: 1. a well-defined cohesive function that manipulates content or provides computational or data processing for an end-user, or. 2. a cohesive package of content and functionality that provides end-user with some required capability. Component-level design for WebApps often incorporates elements of content design and functional design. 70 WebApp Content Design Focuses on content objects and the manner in which they may be packaged for presentation to a WebApp end-user Consider a Web-based video surveillance capability within SafeHomeAssured.com potential content components can be defined for the video surveillance capability: 1. the content objects that represent the space layout (the floor plan) with additional icons representing the location of sensors and video cameras; 2. the collection of thumbnail video captures (each an separate data object), and 3. the streaming video window for a specific camera. Each of these components can be separately named and manipulated as a package. 71 WebApp Functional Design Modern Web applications deliver increasingly sophisticated processing functions that: 1. perform localized processing to generate content and navigation capability in a dynamic fashion; 2. provide computation or data processing capability that is appropriate for the WebApp’s business domain; 3. provide sophisticated database query and access, or. 4. establish data interfaces with external corporate systems. To achieve these (and many other) capabilities, you will design and construct WebApp functional components that are identical in form to software components for conventional software. 72 Component-Level Design for Mobile Apps Thin web-based client. Interface layer only on device. Business and data layers implemented using web or cloud services. Rich client. All three layers (interface, business, data) implemented on device. Subject to mobile device limitations. 73 Traditional Component-Level Design 2 Design of processing logic is governed by the basic principles of algorithm design and structured programming. Design of data structures is defined by the data model developed for the system. Design of interfaces is governed by the collaborations that a component must effect. 74 Component-Based Software Engineering (CBSE) The software team asks: Are commercial off-the-shelf (COTS) components available to implement the requirement? Are internally-developed reusable components available to implement the requirement? Are the interfaces for available components compatible within the architecture of the system to be built? Access the text alternative for slide images. 75 CBSE Benefits Reduced lead time. It is faster to build complete applications from a pool of existing components. Greater return on investment (ROI). Sometimes savings can be realized by purchasing components rather than redeveloping the same functionality in-house. Leveraged costs of developing components. Reusing components in multiple applications allows the costs to be spread over multiple projects. Enhanced quality. Components are reused and tested in many different applications. Maintenance of component-based applications. With careful engineering, it can be relatively easy to replace obsolete components with new or enhanced components. 76 CBSE Risks Component selection risks. It is difficult to predict component behavior for black-box components, or there may be poor mapping of user requirements to the component architectural design. Component integration risks. There is a lack of interoperability standards between components; this often requires the creation of “wrapper code” to interface components. Quality risks. Unknown design assumptions made for the components makes testing more difficult, and this can affect system safety, performance, and reliability. Security risks. A system can be used in unintended ways, and system vulnerabilities can be caused by integrating components in untested combinations. System evolution risks. Updated components may be incompatible with user requirements or contain additional undocumented features. 77 Component Refactoring Most developers would agree that refactoring components to improve quality is a good practice. It is hard to convince management to expend resources fixing components that are working correctly rather than adding new functionality to them, Changing software and failing to document the changes can lead to increasing technical debt. Reducing this technical debt often involves architectural refactoring, which is generally perceived by developers as both costly and risky. Developers can make of tools to examine change histories to identify the most cost effective refactoring opportunities, 78  Unit 12 User Experience Design  User Experience Design Elements 1 User experience design tries to ensure that no aspect of your software appears the final product without the explicit decision of stakeholders to include it. Strategy. Identifies user needs and customer business goals that form the basis for all UX design work. Scope. Includes both the functional and content requirements needed to realize a feature set consistent with the project strategy. Structure. Consists of the interaction design [For example, how the system reacts in response to user action] and information architecture. Skeleton. Comprised of three components: information design, interface design, navigation design. Surface. Presents visual design or the appearance of the finished project to its users. 80 User Experience Design Elements 2 Access the text alternative for slide images. 81 Information Architecture Information architecture structures lead organization, labeling, navigation, and searching of content objects. Content architecture focuses on the manner content objects are structured for presentation and navigation. Software architecture addresses the manner the application is structured to manage user interaction, effect navigation, and present content. Architecture design is conducted in parallel with interface design, aesthetic design, and content design. Decisions made during architecture design action will influence work conducted during navigation design. 82  User Interaction Design Interaction design focuses on interface between product and user. Modes of user input and output include voice input, computer speech generation, touch input, 3D printed output, immersive augmented reality experiences, and sensor tracking of users. User interaction should be defined by the stakeholders in the user stories created to describe how users can accomplish their goals using the software product. User interaction design should also include a plan for how information should be presented within such a system and how to enable the user to understand that information. It is important to recall that the purpose of the user interface is to present just enough information to help the users decide what their next action should be to accomplish their goal and how to perform it. 83  Usability Engineering Usability engineering is part of UX design work that defines the specification, design, and testing of the human-computer interaction portion of a software product. This software engineering action focuses on devising human-computer interfaces that have high usability. If developers focus on making a product easy to learn, easy to use, and easy to remember over time, usability can be measured quantitatively and tested for improvements in usability. Accessibility is the degree to which people with special needs are provided with a means to perceive, understand, navigate, and interact with computer products. Accessibility is another aspect of usability engineering that needs to be considered during design. 84  Visual Design Visual design (aesthetic design or graphic design) is an artistic endeavor that complements the technical aspects of the user experience design. Without it, a software product may be functional, but unappealing. With it, a product draws its users into a world that embraces them on an emotional as well as an intellectual level. Graphic design considers every aspect of the look and feel of a web or mobile app. Not every software engineer has artistic talent. If you fall into this category, hire an experienced graphic designer to help. 85 Golden Rule 1: Place User in 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 screen objects. 86 Golden Rule 2: Reduce 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. 87 Golden Rule 3: Make 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. 88 User Interface Design Models User model — a profile of all end users of the system. Design model — a design realization of the user model. Mental model (system perception) — the user’s mental image of what the interface is. Implementation model — the interface “look and feel” coupled with supporting information that describe interface syntax and semantics. An interface designer needs to reconcile these models and derive a consistent representation of the interface. 89 User Interface Design Process Access the text alternative for slide images. 90  User Interface Analysis and Design Interface analysis focuses on the profile of the users who will interact with the system. Interface design defines 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. Interface construction normally begins with the creation of a prototype that enables usage scenarios to be evaluated. Interface validation focuses on: 1. The ability of the interface to implement every user task correctly. 2. The degree to which interface is easy to use and easy to learn. 3. The user’s acceptance of the interface as a tool in her work. 91 User Experience Analysis In the case of user experience design, understanding the problem means understanding: 1. the people (end users) who will interact with the system through the interface. 2. the tasks that end users must perform to do their work. 3. the content that is presented as part of the interface. 4. the environment in which these tasks will be conducted. 92  Using Customer Journey Map 1. Gather stakeholders. 2. Conduct research. Collect all information you can about all the things users may experience as they use the software product and define your customer phases (touchpoints). 3. Build the model. Create a visualization of the touch points. 4. Refine the design. Recruit a designer to make the deliverable visually appealing and ensure touchpoints are identified clearly. 5. Identify gaps. Note any gaps in the customer experience or points of friction or pain (poor transition between phases). 6. Implement your findings. Assign responsible parties to bridge the gaps and resolve pain points found. 93 Customer Journey Map Access the text alternative for slide images. 94  Creating and Using Personas in UX Design Data collection and analysis. Stakeholders collect information about proposed product users and determine the user group needs. Describe personas. The developers need to decide how many personas to create and decide which persona will be their focus. Develop scenarios. Scenarios are user stories about how personas will use the product being developed. They may focus on the touchpoints and obstacles described in the customer journey. Acceptance by stakeholders. Often this is done by validating the scenarios using a review technique or demonstration called cognitive walkthrough (stakeholders assume the role defined by a persona and work through a scenario using a system prototype). 95 Persona Example Access the text alternative for slide images. 96 Task Analysis Goal of task (scenario) analysis is to answer the following questions: What work will the user perform in specific circumstances? What tasks and subtasks will be performed as the user does the work? What specific problem domain objects will the user manipulate as work is performed? What is the sequence of work tasks—the workflow? What is the hierarchy of tasks? 97 Iterative UX Design Process Access the text alternative for slide images. 98  Google 5-Day UX Design Sprint 1 Understand. User research activities (user needs and business goals) for the software product. This information is posted on whiteboards (For example, customer journey maps, personas, user task workflow) for easy reference throughout the sprint. Sketch. Individual stakeholders are given the time and space needed to brainstorm solutions to the problems discovered in the understand phase. Paper drawings and notes are easy to generate, easy to modify, and quite inexpensive. Decide. Each stakeholder presents his solution sketch and the team votes to determine the solutions that should be tackled in the prototyping activities that will follow. If there is not a clear consensus following the voting, the development team may decide to consider assumptions that involve project constraints and resources. 99 Google 5-Day UX Design Sprint 2 Prototype. May be a minimally viable product based on the solution selected from the sketch phase, or it may be based on the portions of the customer journey map or storyboard you want to evaluate with potential users in the validate phase. This means the team should be developing test cases based on the user stories as the prototype is being built. Validate. Every developer watching users try out the prototype this is the best way to discover major issues with its UX design, which in turn lets you start iterating immediately. This is critical to capturing potential learning opportunities by exposing product decision makers to user feedback in real time. 100 Interface Design Evaluation Cycle Access the text alternative for slide images. 101  User Interface Design Evaluation Criteria The design model (user stories, storyboard, personas, etc.) of the interface can be evaluated during early design reviews: 1. Length and complexity of the requirements model or written specification of the system and its interface provide an indication of the amount of learning required by users of the system. 2. 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. 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. 102  Usability Guidelines 1 Anticipation. An application should be designed so that it anticipates the user’s next move. Communication. The interface should communicate the status of any activity initiated by the user. Consistency. The use of navigation controls, menus, icons, and aesthetics (For example, color, shape, layout) should be consistent throughout. Controlled Autonomy. The interface should facilitate user movement throughout the application, but it should do so in a manner that enforces navigation conventions that have been established for the application. Efficiency. The design of the application and its interface should optimize the user’s work efficiency. 103  Usability Guidelines 2 Flexibility. The interface should be flexible enough to enable some users to accomplish tasks directly and others to explore the application in a somewhat random fashion. Focus. The interface (and the content it presents) should stay focused on the user task(s) at hand. Human Interface Objects. A vast library of reusable human interface objects has been developed for both Web and mobile apps. Use them. Latency Reduction. Rather than making the user wait for some internal operation to complete (for example, downloading a complex graphical image), the application should use multitasking in a way that lets the user proceed with work as if the operation has been completed. 104  Usability Guidelines 3 Learnability. An application interface should be designed to minimize learning time and, once learned, to minimize relearning required when the app is revisited. Metaphors. An interface that uses an interaction metaphor is easier to learn and easier to use, as long as the metaphor is appropriate for the application and the user. Readability. All information presented through the interface should be readable by young and old. Track State. When appropriate, the state of the user interaction should be tracked and stored so that a user can log off and return later to pick up where he left off. Visible Navigation. A well-designed interface provides the illusion that users are in the same place, with the work brought to them. 105  Accessibilty Guidelines 1 Application Accessibility. Software engineers must ensure that interface design encompasses mechanisms that enable easy for people with special needs. Response Time. System response time has two important characteristics: length and variability. Aim for consistency to avoid user frustration. Help Facilities. Modern software should provide online help facilities that enable a user to get a question answered or resolve a problem without leaving the interface. Error Handling. Every error message or warning produced by an interactive system should: use user understandable jargon, provide constructive error recovery advice, identify negative consequences of errors, contain an audible or visual cue, and never blame user for causing the error. 106  Accessibilty Guidelines 2 Menu and Command Labeling. The use of window-oriented, point- and-pick interfaces has reduced reliance on typed commands. How every it is important to: ensure every menu option has a command version, make commands easy for users to type, make commands easy to remember, allow for command abbreviation, make sure menu labels are self-explanatory, make sure submenus match style of master menu items, and ensure command conventions work across the family of applications. Internationalization. Software engineers and their managers invariably underestimate the effort and skills required to create user interfaces that accommodate the needs of different locales and languages. 107 Unit 13 Mobile Design Mobile Development Challenges Mobile devices have many features in common with each other, but often provide very different user experiences. Some users expect the same features provided on their laptops. Other users like freedom that portable devices give them and accept reduced functionality in a mobile software product version. Some users expect unique experiences not possible on traditional computing or entertainment devices. The user’s perception of “goodness” might be more important than any of the technical quality dimensions of the mobile product itself. Software engineers should craft a user experience that takes advantage of device characteristics and context-aware applications. Testing mobile software products provides additional challenges. 109 Mobile Technical Considerations Multiple hardware and software platforms. Many development frameworks and programming languages. Many app stores with different rules and tools. Very short development cycles. User interface limitations and complexities of interaction with sensors and cameras. Effective use of context. Power management. Security and privacy models and policies. Computational and storage limitations. Applications that depend on external services. Testing complexity. 110 Mobile Development Life Cycle Inception. Goals, features, and functions of the mobile product are identified to determine the scope and the size of the first increment. Design. Developers define the app user experience using screen mockups and paper prototypes to help a user interface design that will take different screen sizes and capabilities into account. Development. Mobile software is coded, test cases are created. Usability and accessibility tests conducted as the product evolves. Stabilization. Most mobile products go through a series of prototypes: feasibility (one logic path ); alpha prototype (minimum viable product); beta prototype (largely complete); and release candidate (all required functionality) ready for product owner review. Deployment. Once stabilized a mobile product is reviewed by a commercial app store and made available for sale and download. 111 Useful Mobile User Interface Design Models A platform model describes the constraints imposed by each platform to be supported. A presentation model describes the appearance of the user interface. The task model is a structured representation of the tasks a user needs to perform to meet her task goals. 112 Mobile User Interface Design Considerations Define user interface brand signatures. Focus the portfolio of products. Identify the core user stories. Optimize user interface flows and elements. Define scaling rules. User performance dashboard. Champion-dedicated user interface engineering skills. 113 Mobile User Interface Evaluation In trying to meet stakeholder usability expectations, mobile developers should attempt to answer these questions to assess the out-of-the-box readiness of the device: Is the user interface consistent across applications? Is the device interoperable with different network services? Is the device acceptable in terms of stakeholder values in the target market area? 114 Mobile Design Approaches Usage Scenarios. Must consider context variables (location, user, and device) and transitions between contextual scenarios (locations and settings, movement and posture, devices and usages, workloads and distractions, user preferences). Ethnographic Observation. Used method to gather information about representative users of a software product by observing them as they use the product in a natural setting. Can be tricky to observe them without interfering with their product use. Low-Fidelity Paper Prototypes (for example: cards or Post-it notes). Cost-effective usability assessment approach in user interface design that can be used before any programming takes place. It is important for these prototypes to be similar in size, weight, appearance to allow their use in a variety of contexts. 115 Mobile Design Mistakes Kitchen sink. Avoid adding too many features to the app and too many widgets on the screen. Inconsistency. Set standards for page navigation, menu use, buttons, tabs, and other UI elements. Stick to uniform look and feel. Overdesigning. Remove unnecessary elements and wasteful graphics. Do not be tempted to add things without thinking. Lack of speed. Users do not care about device constraints—they want to view things quickly. Preload what you can. Verbiage. Unnecessarily long, wordy menus and screen displays Nonstandard interaction. Take advantage of the user’s experience with the way things are done on the platform. Help-and-FAQ-itis. Adding online help is not the way to repair a poorly designed user interface. 116 Services Computing Focuses on architectural design and enables application development through service discovery and composition. Allows mobile app developers to avoid the need to integrate service source code into the client running on a mobile device. Runs out of the provider’s server and is loosely coupled with applications that use it via messaging protocols. Provides an API (application programming interface) to allow service to be treated like an abstract black box. 117 Cloud Computing Cloud architecture has three service layers Software as service layer consists of software components and applications hosted by third-party service providers. Platform as service layer provides a collaborative development platform to assist with design, implementation, and testing by geographically distributed team members. Infrastructure and service provides virtual computing resources (storage, processing power, network connectivity) on the cloud. 118 Context-Aware Apps Context allows the creation of apps based on the location of the mobile device and the device functionality to be delivered. Context helps tailor personal computer apps for mobile devices. Mobile computing merges real and virtual worlds by allowing devices to be aware of other objects and its surroundings. Device must detect the presence and identity of a user, as well as the attributes of the context that are relevant for that user. Extracting relevant context information from several sensors is challenging (for example: noise, miscalibration, wear and tear, weather). Event-based communication is preferable to the management of continuous streams of high-abstraction-level data in context-aware applications. 119 Web Design Pyramid Access the text alternative for slide images 120 Objectives of Web Interface Design Establish a consistent window into the content and functionality provided by the interface. To achieve a consistent interface, you should use visual design to establish a coherent “look.” Guide the user through series of WebApp interactions. You may draw on an appropriate metaphor that enables the user to gain an intuitive understanding of the interface. Organize navigation options available to the user. It is important to note that one or more navigation mechanisms should be provided at every level of the content hierarchy. 121 Aesthetic Design Don’t be afraid of white space. Emphasize content. Organize layout elements from top-left to bottom right. Group navigation, content, and function geographically within the page. Don’t extend your real estate with the scrolling bar. Consider resolution and browser window size when designing layout. 122 Content Design Content design develops a representation for content objects. A content object has attributes that include content-specific information and implementation-specific attributes that are specified as part of design. For WebApps, a content object is more closely aligned with a data object for conventional software. 123 Architecture Design Architecture design is conducted in parallel with interface design, aesthetic design and content design. Content architecture focuses on the manner in which content objects (or composite objects such as Web pages) are structured for presentation and navigation. Information architecture is also used to connote structures that lead to better organization, labeling, navigation, and searching of content objects. WebApp architecture addresses ways the application is structured to manage user interaction, handle processing tasks, effect navigation, and present content. 124 Model View Controller (MVC) Access the text alternative for slide images 125 WebApp MVC Architecture The model contains application specific content and processing logic: all content objects. access to external data/information sources, all processing functionality that are application specific. The view contains all interface specific functions and enables presentation of content and processing logic. access to external data/information sources, all processing functionality required by the end-user. The controller manages access to the model and the view and coordinates the flow of data between them. 126 Navigation Design Begins with a consideration of the user hierarchy and related use-cases Each actor may use the WebApp somewhat differently and therefore have different navigation requirements. As each user interacts with the WebApp, she encounters a series of navigation semantic units (NSUs) NSU—“a set of information and related navigation structures that collaborate in the fulfillment of a subset of related user requirements”. 127 Creating NSU Access the text alternative for slide images 128 Mobile Component Design Mobile apps deliver sophisticated processing functions that: 1. Perform localized processing to generate content and navigation capability in a dynamic fashion. 2. Provide computation or data processing capability that are appropriate for the app’s business domain. 3. Provide sophisticated database query and access, and 4. Establish data interfaces with external corporate systems. To achieve these (and many other) capabilities, you must design and construct program components that are identical in form to software components for traditional software. 129 Mobility and Web Quality Access the text alternative for slide images 130 Mobility and Design Quality 1 Security Rebuff external attacks. Exclude unauthorized access. Ensure the privacy of users/customers. Availability Percentage of time that an is available for use. Scalability Can the app and the systems with which it is interfaced handle significant variation in user or transaction volume. 131 Mobility and Design Quality 2 Time to Market Measure of quality from a business point of view. First mobile product to address a specific market segment often captures the most end users. Content Quality Lots of competition on the web. How does the user assess the quality (for example: veracity, accuracy, completeness, timeliness) of the content that is presented within a mobile product? This is part of what data science tries to address. 132 Mobility Product Quality Checklist 1 Can content and/or function and/or navigation options be tailored to the user’s preferences? Can content and/or functionality be customized to the bandwidth at which the user communicates? Does the app account for weak or lost signal in an acceptable manner? Can content and/or function and/or navigation options be made context aware according to the user’s preferences? Has adequate consideration been given to the power availability on the target device(s)? Have graphics, media (audio, video), and other web or cloud services been used appropriately? 133 Mobility Product Quality Checklist 2 Is the overall page design easy to read and navigate? Does the app take screen size differences into account? Does the user interface conform to the display and interaction standards adopted for the targeted mobile device(s)? Does the app conform to the reliability, security, and privacy expectations of its users? What provisions have been made to ensure app remains current? Has the mobile product been tested in all targeted user environments and for all targeted devices? 134 Mobility Design Best Practices Identify the audience. Design for context of use. There is a fine line between simplicity and laziness. Use the platform as an advantage. Make scrollbars and selection highlighting more salient. Increase discoverability of advanced functionality. Use clear and consistent labels. Cleaver icons should never be developed at the expense of user Understanding. Support user expectations for personalization. Long scrolling forms trump multiple screens on mobile devices. 135 Unit 14 Design Patterns Design Patterns Design pattern can be thought of as a three-part rule which expresses a relation between a certain context, a problem, and a solution. Context allows the reader to understand the environment in which the problem resides and what solution might be appropriate within that environment. Requirements, including limitations and constraints, acts as a system of forces that influences how: The problem can be interpreted within its context. The solution can be effectively applied. 137 Effective Design Pattern Solves a problem: Patterns capture solutions, not just abstract principles or strategies. Proven concept: Patterns capture solutions with proven track records, not theories or speculation. Solution isn't obvious: The best patterns generate a solution to a problem indirectly--a necessary approach for the most difficult problems of design. Describes a relationship: Patterns don't just describe modules, but describe deeper system structures and mechanisms. Elegant in its approach and utlity: describes simple solutions to specific problems; the best patterns explicitly appeal to aesthetics and usefulness. 138 Kinds of Patterns 1 Architectural patterns describe broad-based design problems that are solved using a structural approach. Data patterns describe recurring data-oriented problems and the data modeling solutions that can be used to solve them. Component patterns (design patterns) address problems associated with the development of subsystems and components, the manner in which they communicate with one another, and their placement within a larger architecture. 139 Kinds of Patterns 2 Interface design patterns describe common user interface problems and their solution with a system of forces that includes the specific characteristics of end-users. WebApp patterns address a problem set that is encountered when building WebApps and often incorporate many of other patterns categories. Mobile patterns describe solutions to problems commonly encountered when developing solutions for mobile platforms. 140 Kinds of Patterns 3 Creational patterns focus on “creation, composition, and representation of objects” Abstract factory pattern: centralize decision of what factory to instantiate. Builder pattern: separates the construction of a complex object from its representation. Structural patterns focus on problems and solutions associated with how classes and objects are organized and integrated to build a larger structure: Adapter pattern: 'adapts' one interface for a class into one that a client expects. Container pattern: create objects for the sole purpose of holding other objects and managing them. Behavioral patterns address problems associated with the assignment of responsibility between objects and the manner in which communication is effected between objects: Chain of responsibility pattern: Command objects are handled or passed on to other objects by logic-containing processing objects. Command pattern: Command objects encapsulate an action and its parameters. 141 Frameworks Patterns themselves may not be sufficient to develop a complete design. In some cases it may be necessary to provide an implementation-specific skeletal infrastructure, called a framework, for design work. You can select a reusable architecture that provides the generic structure and behavior for a family of software abstractions along with their context which specifies use within a given domain. A framework is not an architectural pattern, but rather a skeleton with a collection of “plug points” (hooks or slots) that enable it to be adapted to a specific problem domain. Plug points enable you to integrate problem specific classes or functionality within the skeleton. Collection of cooperating classes. 142 Pattern Description 1 Pattern name—describes the essence of the pattern in a short but expressive name Problem—describes the problem that the pattern addresses Motivation—provides an example of the problem Context—describes the environment in which the problem resides including application domain Forces—lists the system of forces that affect the manner in which the problem must be solved; includes a discussion of limitation and constraints that must be considered Solution—provides a detailed description of the solution proposed for the problem 143 Pattern Description 2 Intent—describes the pattern and what it does Collaborations—describes how other patterns contribute to the solution Consequences—describes the potential trade-offs that must be considered when the pattern is implemented and the consequences of using the pattern Implementation—identifies special issues that should be considered when implementing the pattern Known uses—provides examples of actual uses of the design pattern in real applications Related patterns—cross-references related design patterns 144 Pattern-Based Design A software designer begins with a requirements model (either explicit or implied) that presents an abstract representation of the system. The requirements model describes the problem set, establishes the context, and identifies the system of forces that hold sway. If you discover you are faced with a problem, context, and system of forces that have solved before then use that solution. If it is a new problem then use the methods and modeling tools available for architectural, component-level, and interface design to create a new solution (pattern). 145 Pattern-Based Design in Context Access the text alternative for slide images. 146 Thinking in Patterns 1. Be sure you understand big picture (requirements model) - the context in which the software to be built resides. 2. Examining the big picture, extract the patterns that are present at that level of abstraction. 3. Begin your design with ‘big picture’ patterns that establish a context or skeleton for further design work. 4. Work inward from the context, look for patterns at lower levels of abstraction that contribute to design solution. 5. Repeat steps 1 to 4 until complete design is fleshed out. 6. Refine the design by adapting each pattern to the specifics of the software you’re trying to build. 147 Design Tasks 1 1. Examine the requirements model and develop a problem hierarchy. 2. Determine if a reliable pattern language has been developed for the problem domain. 3. Beginning with a broad problem, determine whether one or more architectural patterns are available for it. 4. Using the collaborations provided for the architectural pattern, examine subsystem or component level problems, and search for patterns to address them. 148 Design Tasks 2 5. Repeat steps 2 through 5 until all broad problems have been addressed. 6. If user interface design problems have been isolated, search the user interface design pattern repositories for appropriate patterns. 7. Regardless of its level of abstraction, if a pattern language and/or patterns repository or individual pattern shows promise, compare the problem to be solved against the existing pattern(s) presented. 8. Be certain to refine the design as it is derived from patterns using design quality criteria as a guide. 149 Pattern Organizing Table Access the text alternative for slide images. 150 Common Mistakes Not enough time has been spent to understand the underlying problem, its context and forces, and as a consequence, you select a pattern that looks right, but is inappropriate for the solution required. Once the wrong pattern is selected, you refuse to see your error and force fit the pattern. In other cases, the problem has forces that are not considered by the pattern you’ve chosen, resulting in a poor or erroneous fit. Sometimes a pattern is applied too literally and the required adaptations for your problem space are not implemented. 151 Architectural Patterns Example: every house (and every architectural style for houses) employs a Kitchen pattern. Kitchen pattern and patterns it collaborates with address problems associated with storage and preparation of food, tools required to accomplish these tasks, and rules for placement of these tools relative to workflow in the room. The pattern might address problems associated with counter tops, lighting, wall switches, a central island, flooring, and so on. Obviously, there is more than a single design for a kitchen, but every design can be conceived within the context and system forces of the ‘solution’ suggested by the Kitchen pattern. 152 Component-Level Design Patterns 1 Component-level design patterns provide a proven solution that addresses one or more sub-problems extracted from the requirement model. In many cases, design patterns of this type focus on some functional element of a system. For example: the SafeHomeAssured.com application must address the following design sub-problem: How can we get product specifications and related information for any SafeHome device? 153 Component-Level Design Patterns 2 Having enunciated the sub-problem that must be solved, consider context and the system of forces that affect the solution. Examining the appropriate requirements model use case, the specification for a SafeHome device (for example: a security sensor or camera) is used for informational purposes by the consumer. However, other information that is related to the specification (for example: pricing) may be used when e-commerce functionality is selected. The solution to the sub-problem involves a search. Since searching is a very common problem, it should come as no surprise that there are many search-related patterns. 154 Search Patterns HelpWizard. Users need help on a certain topic related to the website or when they need to find a specific page within the site. SearchArea. Users must find a page. SearchTips. Users need to know how to control the search engine. SearchResults. Users must process a list of search results. SearchBox. Users must find an item or specific information. 155 Anti-Patterns Anti-patterns describe commonly used solutions to design problems that usually have negative effects on software quality. Anti-patterns can provide tools to help developers recognize when these problems exist and may provide detailed plans for reversing the underlying problem causes and implementing better solutions to these problems. Anti-patterns can provide guidance to developers looking for ways to refactor software to improve its quality. Anti-patterns can be used by technical reviewers to uncover areas of concern. 156 Selected Anti-Patterns Blob. Single class with large number of attributes, operators, or both. Stovepipe system. A barely maintainable assemblage of ill-related components. Boat anchor. Retaining a part of system that no longer has any use. Spaghetti code. Program whose structure is barely comprehensible, especially because of misuse of code structures. Copy and paste programming. Copying existing code several times rather than creating generic solutions. Silver bullet. Assume that a favorite technical solution will always solve a larger process or problem. Programming by permutation. Trying to approach a solution by successively modifying the code to see if it works. 157  User Interface (UI) Patterns Whole UI. Provide design guidance for top-level structure and navigation throughout the entire interface. Top-level Navigation. Provides a top-level menu, often coupled with a logo or identifying graphic, that enables direct navigation to any of the system’s major functions. Page layout. Address the general organization of pages (for Websites) or distinct screen displays (for interactive applications). E-commerce. Specific to Web sites, these patterns implement recurring elements of e-commerce applications. Shopping cart. Provides a list of items selected for purchase. 158 Mobility Design Patterns Check-in screens. How do I check in from a specific location, make a comment, and share comments with friends and followers on a social network? Maps. How do I display a map within the context of an app that addresses some other subject? Popovers. How do I represent a message or information that arises in real time or as the consequence of a user action? Sign-up flows. How do I provide a simple way to sign in or register for information or functionality? Custom tab navigation. How do I represent a variety of different content objects in a manner that enables user to select one? Invitations. How do I inform the user that he must participate in some action or dialog? 159