CSE100: Introductory Software Engineering

1
CSE100 Introductory Software Engineering

• Lecture 9 System Design

2
Design in the Software Development Lifecycle
Requirements
Evaluation
tion
Evolu
Validation
Specification
Analysis
Development
Testing
Design
Development
We are still here!
3
Design the story so far

• In lecture 7 we introduced Interface Design
• The visible manifestation of the structure and
  organization of a product or site employing human
  factors and business rules. The user interface
  helps create hierarchy and understanding of the
  content/features of a site or software product.
• www.usefulstudios.com/InteractionGlossary.aspx
• the goal of user interface design is to make the
  user's interaction as simple and efficient as
  possible, in terms of accomplishing user goals

4
What does it involve?
In lecture 7 we focused on

• User analysis working with the users e.g.
  interview, observe) to discover

• How theyd like it to look
• How they would use it
• What type of user are they
• (Novice, intermediate, expert)
• (Regular, sporadic, seldom)
• Interface Design

What do they want the system to do System Design
In other words you must aim to match the
skills, experience and expectations of the users.
5
What else does it involve?

• There are 2 other parts to interface design
• UI Prototyping
• (develop, expose to the users get feedback,
  evolve)
• This is something youll have found out about as
  part of your self study on Process Models
  (prototyping model)
• Interface evaluation
• (formal activity capturing their experience)

6
How to engage in 3.UI Evaluation?

• Monitor the users as they are using it
• How might you do that?

7
Answers

• Observation
• Video record
• Software monitoring (analyses their movements in
  the background e.g. records keystrokes, e.g.
  eyetracking)
• Speak aloud protocol
• Or less direct
• Questionnaire yes/no answers or Likert scale
  (prefer 1-5)

8
What to try to measure in UI Evaluation
Need to evaluate to the following
criteria/attributes
What do you think they mean?
9
UI Evaluation
Need to evaluate to the following
criteria/attributes
10
But how to measure?

• You can use metrics to measure each attribute -
• E.g. Learnability can a user use 80 of system
  after 3 hours training?
• E.g. how else? Think in pairs for a few minutes

11

• User Interface Design Principles
• (Sommerville)

12
(No Transcript)
13

• In thinking about what these might mean, think of
  examples where you think each might go wrong!
• Exercise in pairs
• User familiarity
• Consistency
• Minimal Surprise
• Recoverability
• User Guidance
• User Diversity

14
(No Transcript)
15
Online Usability

• Jakob Nielsens website
• http//www.useit.com/
• Killer Websites resources
• http//www.killersites.com/
• Writing for the web
• http//www.sun.com/980713/webwriting/
• The Mom Test for website usability
• http//uk.youtube.com/watch?vfKru8BK4P58
• Also check out module reading list and resources
  such as http//www.cs4fn.org/
• http//www.rspa.com/
• http//www.angelfire.com/anime3/internet/programmi
  ng.htm
• http//kn.theiet.org/communities/

16
User Interaction

• Think of the different ways you interact with a
  computer ( i.e. the mode of communication)
• See if you can think of 5
• 5 minutes activity
• Write down and compare with your neighbour

17
User Interaction 5 methods (Schneiderman)

• Direct manipulation
• Use mouse, pen, trackerball, touchscreen
• Drag drop i.e. manipulate objects on screen
• Menu selection
• Can coincide with direct manipulation e.g.
  highlight something then delete it
• Form fill in
• Command language
• E.g. SQL to interact with a database (delete all
  people from surname table with surname smith)
• Natural language
• Normal human language (will be translated to
  command language or parsed into a representation
  the computer will understand)

18
User Interaction Methods

• Did you answer similarly?
• Can you think of different types of computer
  system where each type of interaction method
  would be used?

19

• Time for a break!

20
Design should encompass
This is not just true for web design!
21
What else is Design?

• According to Sommerville A software design is a
  description of the structure of
• the software to be implemented,
• the data which is part of the system,
• the interfaces between the system components
• and, sometimes,
• the algorithms used

22
Decomposition

• Remember we talked at the start of the module
  about software engineering problem solving
• And, to solve a problem we said you should break
  it down into sub-problems
• To solve the problem you need to understand (and
  solve) what happens in each sub-part and also
  what passes between each sub-part

23
Specific Design Process Activities (Sommerville)

• Architectural design
• Identify and document sub-systems relationships
  within system
• Abstract specification
• What does each subsystem do under what
  constraints
• Interface design
• Interface between each subsystem must be
  unambiguous as doesnt know each sub-operation
• Component design
• Services allocated to components and their
  interfaces designed
• Data structure design
• Data structures used in implementation are
  designed and specified
• Algorithm design
• Algorithms used to provide services are designed
  and specified
• 5 6 may be part of Implementation (rather
  than design)

24
(No Transcript)
25

• The diagram looks like a very linear, set of
  separate process
• But a better way to think of it may be

Top down! But it could also be Bottom up!
26
Modular programming

• Once specified at a high level (architectural
  design) each component will be given a very
  specific and distinct purpose and the (very
  few) connections to other components will be very
  clear
• Easier to
• Develop especially in a team
• Debug and limit spread of damage
• Test
• Maintain
• Reuse
• Think about other things in life that are modular
  (e.g. kitchens, e.g. your degree programmes, e.g.
  what else?) what are the pros and cons?
• 5 minutes pair discussions

27

• How do you decide how to break down your problem?

28
Component Design

• You can classify the components of your system
  or program by thinking about what they do e.g.
• Does it compute?
• Does it hold data memory?
• Does it manage data e.g. a stack or queue?
• Does it control when/how things happen?
• Does it link/transfer data e.g. a user
  interface, some networking software

29
Component size complexity

• Your programs could be
• A few large components with a few links between
  them
• Many small components with many links between
  them
• Which is best?
• How to decide?
• Length of component code 1 page?
• Length of component code 7 statements?
• What if the 7 statements are all complex if
  statements?

30
Coding (Programming)

• Translating the detailed design of the software
  into a sequence of statements that the computer
  can execute
• Software Engineering is about producing quality
  products that can be easily maintained and this
  means sticking to agreed good practice in terms
  of style, documentation etc when coding

31
(just) some of the common features of programming
languages

• (This module isnt about teaching you programming
  your other module does that but we need to
  make you recognise the link between the two)
• Think about the earlier slide on component
  design.
• Subprograms, subroutines
• FUNCTIONS compute a value and return it to the
  main program
• PROCEDURES perform a simple task

32
Some of the common features of programming
languages

• Control structures
• They control the flow of execution in a program
  (what happens when)
• E.g. iteration while do, repeat until,
• E.g. selection case A, case B, case C
• Data structures
• E.g. arrays, stacks, queues
• File handling
• Input, output

33
Programming style quality

• If coding is done by sticking to good style
  guidelines/rules, then it will be
• Readable
• Understandable
• Structured
• Robust
• Efficient
• Reusable (perhaps)

34
How to ensure good style/quality?

• By following the procedure of
• Reviews
• Inspections
• Code walk-throughs etc
• (remember all those stages in the SimSE game? And
  one game in itself was code inspection)

35
Style Guidelines

• Here are some suggestions (the suggested reading
  will tell you more)
• Keep it simple
• Comment often and clearly (esp. at the start of
  subprograms)
• Indent consistently (for readability)
• Use meaningful names
• Keep local (not global) where possible
• Limit levels of nesting (if-then-else) in
  sub-programs it reduces readability
• The best program isnt the shortest its the
  simplest clearest

36
Guidelines in commenting your code

• Suggestions your programming tutor will guide
  you further on this
• Briefly state what the program does list the
  subprograms, describing their task
• List the important variables and data structures
  describe what they are
• List all required input data
• List output
• List any execution instructions
• List author, data, company/institution, related
  info
• List any exceptions that the program doesnt deal
  with

37

• Next session is about event-action-state paradigm

38
Practical tasks

• Task from week 4 (lecture 7)
• Task from week 5 (Process Models)

39

• (Website) Interface tutorial task from week 4
  (before consolidation week)
• Who did this? What were the outcomes? Did you
  change your mind about any of the interfaces? How
  and Why?

40
Task

• Fill in right hand column, now considering
• Function over Form
• Target Users
• Generality/specificity of users
• Navigability
• Usability speed, interactivity, predictability,
  consistency
• Accessibility
• The other factors we looked at
• Websites on next slide

41
Do these systems have good user interface
design?

• http//www.sunderland.ac.uk/
• http//www.channel4.com/bigbrother/index.jsp
• http//en-gb.facebook.com/
• http//www.monsterlabthegame.com/en/
• http//en.wikipedia.org/wiki/Main_Page
• http//www.nhs.uk/Pages/homepage.aspx
• http//www.elvis.com/
• http//www.hellosoursally.com/

42
Lecture 8Process Models

• Who did this task?
• Tutors to check