CMPT 275 Software Engineering

1
CMPT 275Software Engineering

• Requirements Analysis Phase
• Requirements Analysis activity (state diagrams)

2
State Diagrams

• Used to understand the states in which a
  particular entity can exist, and the events that
  cause transitions between these states
• Class diagrams show the static structure of the
  system
• State diagrams show the dynamic behavior of
  entities within the system
• Most commonly a State diagram is used to describe
  the dynamic behavior of a class, use case, or
  entire system

3
State Diagrams

• Most useful in modeling dynamic behavior in an
  event-driven system or object (otherwise use
  activity diagrams, more on this later). An event
  driven system
• Responds to events from outside the system
  (outside the context of the object or system),
• Is often idle while waiting for such events
• Focus on stable states and the events that cause
  transitions between them

4
UML Notation for State Diagram
Initial State (start of lifetime, creation)
Final State (end of lifetime, destruction)
State Name
Intermediate State
Trigger
State transition with event trigger
Unconditional state transition
5
What is a state?

• A state is a particular condition a system (use
  case or object) can be in at some times during
  it's lifetime.
• While in a state a system
• waits for an event
• satisfies a condition
• performs some activity.

6
States may have

• A name (a state may be anonymous, and have no
  name)
• Entry/exit actions Actions that are executed on
  entry or exit from the state.
• Internal transitions Transitions that occur
  without a change of state
• Substates Nested states (occurring within a
  main state)

7
What is an event?

• An event is a significant occurrence within the
  system.
• An external event is an event passing between the
  system and its actors (like pushing a button)
• An internal event is an events that occur among
  the objects within the system

8
What is an event?

• An event is a stimulus that can trigger
  transition between states within a state machine.
  Such stimuli include
• Signals "A signal represents a named object that
  is dispatched (thrown) by one object and received
  (caught) by another". Signals are asynchronous.
• Calls Similar to signals but invoke methods
  rather than send signals
• Time and Change represent passage of time (like
  30 seconds after entering state A) or a change in
  condition (like satisfying a condition or moving
  between states.

9
What is a transition?

• A transition is a relationship between two
  states. An object in the first state will move
  through the transition to the second state after
• a specified set of events occur
• And a specified set of conditions are satisfied
• And certain actions are performed

10
What is a transition?

• A transition has
• A source state the state affected by the
  transition
• An event trigger The event which makes the
  transition fire.
• A guard condition Condition that must be
  satisfied before the transition can occur. A
  event trigger occurring before the guard
  condition is true will not result in a transition
• A target state the state after the transition

11
Thermostat example

• (After Booch Jacobsen and Rumbaugh, The UML User
  Guide)

Final state
IDLE
Initial state
Event
state
tooCold(desiredTemp)
tooHot(desiredTemp)
Transition
HEATING
atTemp
state
state
COOLING
atTemp
Event
ACTIVATING
ready
tooCold(desiredTemp)
Event Parameter
Nested substates
ACTIVE
tooHot(desiredTemp)
12
CMPT 275Software Engineering

• Phase Design
• High level design activity

13
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

14
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

15
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 design
• 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

16
System design activities
Functional requirements
Non Functional requirements
Analysis
Analysis dynamic model
Analysis object model
System design
Design goals
Subsystem decomposition
Object design
17
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.

18
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

19
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)

20
Map of design phase
DESIGN
LOW LEVEL (object) DESIGN
HIGH LEVEL (system)DESIGN
Data Persistence Subsystem
Classes Class Interfaces Interaction Diagrams
Module Interfaces
Modularization
architecture
User Interface
User Manual
Implementation
21
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)

22
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)

23
Guidelines for User Interface Design

• A user interface should
• Be simple
• Speak the users language
• Maximize users prior knowledge minimize
  memorization
• Be intuitive
• Be consistent
• Provide feedback
• Give control to the user
• Prevent errors
• Accommodate multiple skill levels

24
Guidelines for UI Design

• Be simple
• Reduce clutter, make UI transparent
• Minimize number of mouse clicks / keyboard
  characters, levels of navigation
• Maximize users prior knowledge minimize
  memorization
• Use interfaces similar to those a user will be
  familiar with from other applications on his/her
  platform

25
Guidelines for UI Design

• Speak the users language
• Use terms from the users application domain where
  appropriate
• Be intuitive
• Combine logically related options
• Use meaningful labels, names, icons

26
Guidelines for UI Design

• Be consistent
• Dont 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)

27
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

28
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

29
Whats the Problem?
30
Whats the Problem?
31
Whats the Problem?
32
Whats the Problem?
33
Whats 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.
34
Whats the Problem?
35
Whats the Problem?
Outlook actually has found the Calendar folder,
it just lacks permission to read it.
36
Whats the Problem?
37
Whats the Problem?
38
Whats the Problem?
39
Whats the Problem?
40
Whats the Problem?
41
What is the problem?
42
What is the problem?
43
What is the problem?
This window appears when you attempt to
disconnect the secure file transmission tool
during an file transfer
44
Whats the Problem?
45
Whats the Problem?
46
Whats the Problem?
47
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.

48
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

49
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 -gt User satisfaction,
• To the user the interface is the system

50
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.

51
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

52
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

53
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?)