Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 CMPT 275 Software Engineering Phase: Design High level design activity.

Similar presentations


Presentation on theme: "1 CMPT 275 Software Engineering Phase: Design High level design activity."— Presentation transcript:

1 1 CMPT 275 Software Engineering Phase: Design High level design activity

2 Janice Regan, Objectives of Design  The design phase takes the results of the requirements analysis phase and evolves these results further  The results of the design phase feeds directly into the implementation phase  Requirements analysis → WHAT the system must do  Next Goal: determine HOW the software system is to accomplish what it must do

3 Janice Regan, Basis of System Design  The design phase uses the analysis model  Non-functional requirements / constraints  Use case model: (from users point of view)  Use cases and use case diagrams  state diagrams  Object model:  Context diagram, class diagrams

4 Janice Regan, Objectives of System Design  The design phase produces a system model  That is based on specific design goals for the designers  That defines architecture and Subsystem desig n  Identifying subsystems/modules (manageable parts)  Identifying architecture (hardware/software)  Data management / mapping  Access control, flow control (sequencing operations)  That describes boundary use cases:  Initialization, termination, configuration, exception handling

5 Janice Regan, System design activities Analysis System design Object design Functional requirements Non Functional requirements Analysis object model Analysis dynamic model Design goals Subsystem decomposition

6 Janice Regan, Objectives of system design  Transforms analysis model (from requirements analysis) into a system design model  Identify, model system architecture  Develop an efficient system decomposition  Identify boundary use cases describing configuration, startup, shutdown, exceptional conditions.

7 Janice Regan, Design goals, System decomposition  Identify design goals (choose aspects of the system to be optimized) Design goals are often derived from non-functional requirements.  Guide designers in assessing trade offs  Develop and refine a subsystem decomposition that satisfies the maximum number of design goals and or the most critical design goals  Refine the decomposition to better satisfy the design goals

8 Janice Regan, Design goals  When assessing design goals consider  Selection of existing components (off the shelf modules or components )  Hardware / software mapping,  Are there multiple nodes or systems  What is each node responsible for  selecting solutions for managing persistent data  Access control policies  Control flow on a solution wide basis  Boundary conditions (startup, error, shutdown)

9 Janice Regan, Map of design phase DESIGN HIGH LEVEL (system)DESIGN Modularization User Interface Module Interfaces Data Persistence Subsystem User Manual architecture LOW LEVEL (object) DESIGN Classes Class Interfaces Interaction Diagrams Implementation

10 Janice Regan, Why a User Interface Module?  Making the GUI a module  Easy replacement/expansion of interface  Can easily replace without changing functionality of the system ( What if you wanted a command line interface, or a modified version of the GUI)

11 Janice Regan, User Interfaces  Facilitate two-way communication with user  It is a good idea to keep the user interface and the functionality of software system separate  Functionality of software system determines what information is to be communicated (content) and user interface determines how that information is to be communicated (form)

12 Janice Regan, Guidelines for User Interface Design A user interface should:  Be simple  Speak the user’s language  Maximize user’s prior knowledge & minimize memorization  Be intuitive  Be consistent  Provide feedback  Give control to the user  Prevent errors  Accommodate multiple skill levels

13 Janice Regan, Guidelines for UI Design  Be simple  Reduce clutter, make UI transparent  Minimize number of mouse clicks / keyboard characters, levels of navigation  Maximize user’s prior knowledge & minimize memorization  Use interfaces similar to those a user will be familiar with from other applications on his/her platform

14 Janice Regan, Guidelines for UI Design  Speak the user’s language  Use terms from the users application domain where appropriate  Be intuitive  Combine logically related options  Use meaningful labels, names, icons

15 Janice Regan, Guidelines for UI Design  Be consistent  Don’t make a labeled button do different things in different places  Use the same approaches throughout  Accommodate multiple skill levels  Have multiple ways to complete a task (e.g. mouse click or keyboard shortcut)

16 Janice Regan, Guidelines for UI Design  Provide feedback  Clear error messages. Include instructions on how to recover from the problem  Explain what acceptable input is and if necessary why it is acceptable  Indicate when the system is busy, the user should know if the system is working or has crashed (stopped)  Context sensitive help

17 Janice Regan, Guidelines for UI Design  Give control to the user  Allow the user to undo, redo, confirm, cancel, exit … as appropriate  Warn the user if an operation cannot be undone  Prevent errors  Anticipate and disallow user actions that could lead to errors

18 Janice Regan, What’s the Problem?

19 Janice Regan, What’s the Problem?

20 Janice Regan, What’s the Problem?

21 Janice Regan, What’s the Problem?

22 Janice Regan, What’s the Problem? The company claims this was just a joke and never meant to be seen by users. The programmer who did it no longer works for the company, and many thousands of letters of apology were sent to customers.

23 Janice Regan, What’s the Problem?

24 Janice Regan, What’s the Problem? Outlook actually has found the Calendar folder, it just lacks permission to read it.

25 Janice Regan, What’s the Problem?

26 Janice Regan, What’s the Problem?

27 Janice Regan, What’s the Problem?

28 Janice Regan, What’s the Problem?

29 Janice Regan, What’s the Problem?

30 Janice Regan, What is the problem?

31 Janice Regan, What is the problem?

32 Janice Regan, What is the problem? This window appears when you attempt to disconnect the secure file transmission tool during an file transfer

33 Janice Regan, What’s the Problem?

34 Janice Regan, What’s the Problem?

35 Janice Regan, What’s the Problem?

36 Janice Regan, User Interface Design  The User interface is how your user interacts with your program  Specifying which actions it should perform  Evaluating, viewing, and saving results  It should not be tied to how your program determines the results  When designing your interface think in terms of how the user will see the system, make the system easy for the user (not the designer) to use and understand.

37 Janice Regan, User-Centered Design  1. Analyse: who are the users, how are tasks currently performed, steps presently taken while doing task, how user knows if task was successful …  2. Design: draft your user interfaces using…  UI descriptions from your SRS  Guidelines for User Interface Design

38 Janice Regan, User-Centered Design  3. Evaluate: Run your user interfaces by the users  Do users know what to do at each step  Do users know how to accomplish each step  4. Iterate: Goto step 1.  Our goal -> User satisfaction,  To the user the interface is the system

39 Janice Regan, Users view of a system  The users view of a system is the UI. The user does not know or need to know or care how the internals of the system functions.  The users understanding of the system is based on their interaction with the UI and their knowledge of the application area  Requirements analysis defines what the system does and collects information about how those tasks are normally done in the application area.  Incorporate how it is done in the design of your UI.

40 Janice Regan, UI Descriptions  Describe the interaction between software system and actors  Start with UI descriptions and use cases in requirements (remember these should contain only enough detail to be able to explain the behavior of the system)  Refine use cases, add the ‘how’ to the UI descriptions

41 Janice Regan, UI Descriptions  Guideline: 1 interface per actor  Each actor has their own initial screen  That screen may lead to a series of screens performing all required tasks  Later screen in the sequence may be common to multiple actors

42 Janice Regan, User Interface Design: Project  For requirements analysis UI screens were functional  focused on purpose of screen, not its layout  In Design, focus on screen layout.  Many functions may be incorporated into one window. Multiple screens from requirements may be merged for simplicity  Consider various types of widgets, select the best for each purpose (simplest?)


Download ppt "1 CMPT 275 Software Engineering Phase: Design High level design activity."

Similar presentations


Ads by Google