Views

1
Web-based DatabasesAnalysis Design
2
A Few Definitions

• Process
• the series of activities regarding a software
  product from the time the need to which that
  product is to respond is identified until the
  time the product is retired (which may occur
  before installation) (Blum, 1994)
• the sequence of stages (e.g. requirements
  analysis, specification, planning, design,
  implementation, integration, maintenance and
  retirement) through which a software product
  evolves (Wynekoop Russo, 1995)
• Examples Waterfall/SDLC process model, Spiral
  model, RAD process model
• Approach
• a way of going about ones work. They may
  embody a particular style and may employ
  different methods and techniques. Approaches are
  therefore a more generic concept than methods
  (Galliers, 1992)
• a set of goals, guiding principles, fundamental
  concepts, and principles for the ISD process that
  drive interpretations and actions in ISD.
  (Iivari et al, 1998)
• Examples data-driven approach, object-oriented
  approach, user-centred approach, graphic/visual
  design approach, industrial design approach,
  evolutionary/incremental approach,
  component-based approach, socio-technical approach

3
A Few Definitions

• Method
• a systematic approach to conducting at least one
  complete phase (e.g. design or requirements
  analysis) of software production, consisting of a
  set of guidelines, activities, techniques and
  tools, based on a particular philosophy of system
  development and the target system. (Wynekoop
  Russo, 1995)
• Examples SSADM, DSDM, RUP, XP, RAD
• Technique
• Though the terms method and technique are
  sometimes confused, a technique is generally seen
  as something more specific and elementary, being
  a way of executing a particular task or step
  within a method
• Examples E-R modelling, DFD diagrams,
  storyboards, site maps, use cases, normalisation,
  flowcharts, wireframe diagrams, activity
  diagrams, etc.

4
Debate The Case for Method

• Easier to understand systems (decomposition)
• Tiered architecture ? layered methods separate
  presentation (graphic design, interaction
  design), business logic (process design), and
  infortmation (back-end database design)
• Move toward automated design tools and dynamic
  page generation
• Overcome reliance on designers who constructed
  the system
• To reduce risks associated with shortcuts and
  mistakes
• To produce documentation that is consistent from
  one project to the next
• Reduced cycle time and / or reduced maintenance
• Increased productivity
• Higher quality systems
• Improved project management (time and cost
  estimates, task allocation, deliverables,
  tracking, resource utilisation)
• Facilitates knowledge capture and transfer
  (epistemological motive)

5
Debate The Case against Method

• There is not a single-best one-size-fits-all
  method - in practice, most organisations are not
  committed to any single method, and mix and match
  as appropriate (or use hybrid in-house
  approaches)
• Method can be inflexible, bureaucratic, and
  overly rigid
• Method can stifle creativity
• Method may be time-consuming, cumbersome and
  costly
• Method may become an ends in itself (goal
  displacement)
• Method may give a false sense of security
  (Magenot effect)
• Method may create too much paperwork
• Method may not be supported by adequate tools and
  techniques
• Method may lack concrete guidance on how it
  should be applied
• What do you do when you encounter a situation
  that the method has not anticipated???

6
Its all about the Requirements !!!

• The hardest single part of building a software
  system is deciding precisely what to build. No
  other part of the conceptual work is as difficult
  as establishing the detailed technical
  requirements ... No other part of the work so
  cripples the resulting system if done wrong.
  (Brooks, 1987)
• The goal of information systems development is to
  deliver projects
• on time
• at the agreed cost
• that fulfil business needs at the time the system
  becomes operational
• Requirements Management is vital to all three
  goals

7
Requirements Management

• To fulfill these goals, the System Requirements
  Specification (SRS) is of interest to a diverse
  audience of stakeholders, for example
• End User / Customer statement of needs
• Programmer / Software Engineer build-to
  specification
• Project Manager basis of time / cost estimates
• Software Testers basis of test plans
• It is therefore critical that requirements be
  communicated to and understood by all stakeholders

8
Requirements Management

• Communication of Requirements
• development process adopted
• Understanding of Requirements
• specification techniques used
• Communicability has two aspects
• Clarity
• Lack of Ambiguity
• Problem!!?? in general, the least ambiguous
  techniques are also the least understandable, and
  vice versa

9
Communication Understanding
10
Web-based DatabasesDesign Process
11
Traditional SDLC (Waterfall Model)
Requirements Analysis
Design
Coding
Testing
Implementation
12
Traditional SDLC for Interactive Systems ?

• Active consideration of end-users needs is a
  critical factor in the development of interactive
  systems
• The traditional SDLC was originally devised when
  interactive systems were rare
• User involvement is supported only during the
  early stages and at the very end
• The traditional SDLC does not work well for
  many classes of software, particularly
  interactive end user applications - Boehm, 1988
• Ill know it when I see it (IKIWISI) systems
  requirements very difficult to pin down
• The traditional SDLC relies strictly on the
  formal specification document, which freezes
  requirements
• This practice can lead to obsolescence even
  before delivery !!

13
Boehms Spiral Model
14
V - Model
15
Rapid Prototyping Model
Design Derivation
Prototype Iteration
Tuning
User
Rapid Analysis
Approval
Database
Project Plan
Functions
Creation
User Interface
Operation
Maintenance
16
RAD Model
17
Rational Unified Process (RUP)
Traditional Waterfall Model
RUP an iterative approach that also recognises
the value of short sequential processes
18
Generic Agile Process
19
eXtreme Programming (XP)
20
SCRUM
21
User-Centred Design Process

• User-Centred Design is an iterative, evolutionary
  process all design stages are subject to ongoing
  revision
• User Analysis Task Analysis
• Establish System Objectives Priorities
• Construct Evaluate Prototypes
• Conduct Usability Tests
• Conduct Acceptance Tests
• Freeze Design Specification Move to Full
  Production

22
Generic Web Development Process(Atzeni et al)
Requirements Analysis
Conceptual Database Design
Conceptual Hypertext Design
Logical Database Design
Logical Hypertext Design
Presentation Design
Site Generation
Source Database Systems, Atzeni et al.
23
Generic Web Development Process (Lang)

• 0. PROJECT INITIATION Specification of the
  brief, statement of project goals, outline of
  timeplan and budget, kick-off meetings. Output
  Project Initiation Document (signed-off).
  Typical turnaround cycle 1-2 days.
• 1. PLANNING / REQUIREMENTS DEFINITION Review of
  business strategy and IT / digital communications
  strategy, profiling of end-users, analysis of
  competitors, background research, detailed
  functional specification, outline of information
  architecture and search/navigation mechanisms,
  exploration of graphic design concept,
  branding/marketing requirements. Outputs
  eBusiness Plan optional, Requirements
  Specification, and Graphic Design Brief (all
  signed-off). Typical turnaround cycle 3-4
  weeks.
• 2a. USER INTERFACE DESIGN Design of GUI
  look-and-feel, detailed information architecture,
  usability / accessibility considerations, brand
  and logo design. Output Visual templates and
  style sheets, user interface skins
  (signed-off). Typical turnaround cycle 3-5
  days.
• 2b. TECHNICAL DESIGN / PRODUCTION Coding,
  database design, detailed architectural design,
  linkage of front- and back-end, unit and
  integration testing. Typical turnaround cycle
  1-2 weeks.
• 3. DELIVERY Upload of system to Web server,
  entry of content, user training, final testing
  and quality/usability audits, final tweaking,
  full launch. Typical turnaround cycle 1-2
  weeks.
• 4. MAINTENANCE and MARKETING Ongoing support and
  enhancement, promotion of Web site.

24
Web-based DatabasesDesign Methods
25
WWW/Hypermedia Development Methods
26
WWW/Hypermedia Development Methods

• There is a multitude of methods in the literature
  to guide the development of Web-base/hypermedia
  systems
• See list at http//www.nuigalway.ie/bis/mlang/Web_
  design_methods.pdf
• Examples include
• Hypertext Design Method (HDM) Garzotto et al,
  1991 since extended into HDM2, HDM-Lite,
  AutoWeb, Araneus, W2000, WebML
• Enhanced Object-Relationship Model (EORM)
  Lange, 1994
• Relationship Management Methodology (RMM)
  Isakowitz et al, 1995
• Object-Oriented Hypermedia Design Methodology
  (OOHDM) Schwabe Rossi, 1995
• Web Site Design Method (WSDM) De Troyer
  Leune, 1997
• Structured Hypermedia Design Technique (SHDT) /
  World Wide Web Design Technique (W3DT) Bichler
  Nusser, 1996 Scharl, 1999
• OPEN Henderson-Sellers, 1998
• Relationship-Navigation Analysis (R-N A)
  Bieber, 1998 Yoo Bieber, 2000
• Scenario-based Object-oriented Hypermedia Design
  Methodology (SOHDM) Lee et al, 1999
• View-based Hypermedia Design Methodology Lee et
  al, 1999
• UML Hypermedia/Multimedia Extensions Conallen,
  1999 Cervenka, 1998 Koch Mandel, 1999 Sauer
  Engels, 1999
• Fusebox

27
WISDM (Vidgen et al)

• WISDM Web Information Systems Development
  Methodology
• Developed by Richard Vidgen and colleagues
• Vidgen, R. et al (2002) Developing Web
  Information Systems From strategy to
  Implementation, Oxford Butterworth-Heinemann.
  Available in NUI Galway library at class 005.72
  DEV
• See http//www.wisdm.net

28
Elaborated WISDM Framework

• Multiple perspectives
• Technical (T)
• Organizational (O)
• Personal (P)

CHANGE AGENTS
Would-be developers of an information system
Interpretive Schemes
IS DEVELOPMENT METHODS
Interpretive Schemes
Action
ANALYSIS
Organizational Analysis Valuecreation
Information Analysis Requirements specification
WISDM - WebIS DevelopmentMethodology (local,
contingent, emergent)
Envisioning
Rationalizing
SOCIO
TECHNICAL
Championing
Engineering
History
Technical Design Softwaremodel
Work Design Usersatisfaction
HCI
User interface
Aestheticizing
DESIGN
SITUATION
Structure
29
Relationship Management Methodology (RMM)
(Isakowitz et al)
User-Interface
Population
Generation
30
OOHDM (Schwabe Rossi )

• Overview of OOHDM

31
OOHDM
32
HDM-Lite / AutoWeb / WebML
HDM-lite schemas
Content
33
Comparison of Methods

• There are so many methods in the literature is
  it possible for there to be over 60 different
  ways of developing Web-based systems ??!!
• The methodologies jungle !
• In essence, many of these methods are very
  similar
• They may vary in approach (e.g. data-centred,
  object-oriented, user-centred), domain
  applicability (e.g. corporate Web sites,
  electronic catalogues, e-learning), or philosophy
  (e.g. hard versus soft perspective of systems
  development)
• Boiled down, very many of them contain the same
  elements
• For example, RMM, OOHDM, HDM/AutoWeb/WebML and
  WSDM all separate design into database design
  navigation design user interface design.
• All three aspects are mapped onto each other e.g.
  navigation design involves the definition of
  database views and access mechanisms (lists,
  guided tours, conditional indexes, etc.), and
  interface design is the physical implementation
  of navigation design (i.e. how to present the
  system, taking usability, accessibility and
  graphic design considerations into account)

34
Web-based DatabasesDesign Methods(WSDM)
Original slides courtesy of WISE, Vrije
Universiteit Brussels Edited by Michael Lang,
NUI Galway
35
Web Site Design Method (WSDM)

• Pronounced WiSDoM
• Not to be confused with WISDM (Vidgen) or WISDOM
  (Castano, Palopoli Torlone)
• Devised by Olga De Troyer and colleagues within
  the Web Information Systems Engineering (WISE)
  research group at Vrije Universiteit Brussels
• http//wise.vub.ac.be/ (publications, etc.
  see downloadable PDFs from 2000, 2001 onwards)
• http//wsdm.vub.ac.be/ (some broken links when
  last accessed)
• Rather than taking an organisation's data as
  starting point (i.e. the data-driven approach),
  WSDM starts with an assessment of the needs and
  requirements of the intended audience(s) of the
  Web site (i.e. user-centred or
  audience-driven approach)

36
User-Centred Design

• Different types of users have different needs

University Web site
Detailed information on courses facilities
Prospective Student
Enrolled Students
37
WSDM Overview
Mission Statement Specification
38
Mission Statement

• University Example
• Provide general information about the available
  programmes and research activities to (1) attract
  students (2) attract potential research
  partners (3) enhance internal communication
  between students and lecturers by providing
  detailed information about programmes and
  courses
• Purpose
• Attract prospective students
• Enhance internal communication between students
  and lecturers
• Target Audience
• Potential students, existing students,
  lecturers, research bodies, industry partners,
  professional associations
• Subjects
• programmes, courses, research activities,
  university facilities

39
Audience Modelling

• Audience Class
• Users similar in terms of their information
  requirements and functional requirements
• May be specialised/generalised audience class
  types (as in object-orientation)

40
Audience Classification Example

• University example
• Target Audience Prospective students, enrolled
  students, lecturers
• Audience classes
• Prospective Students
• School Leavers
• Graduates
• Enrolled Students
• Undergraduates
• Postgraduates
• Lecturers
• Full-Time
• Part-Time

41
Identifying Audience Classes

• Steps
• Consider the activities of the organisation
  related to the purpose of Web site
• For each activity,
• Decompose the activity, if necessary (e.g.
  provide education may be broken down into
  part-time programmes, full-time programmes,
  lifelong learning, distance education)
• Identify the set of persons involved with that
  activity
• From this set, disregard those who are not within
  the target audience
• Divide this set into audience classes based on
  different information or functional requirements
• (Repeat these steps until activities and
  audience classes cannot be further decomposed)

42
Identifying Audience Classes Example

• Diagrammatic representation rather like a Use
  Case Diagram in UML focuses on users and the
  activities in which they are interested

43
Audience Modelling Output
Audience Class Hierarchy
Audience Modelling
Audience Classification

• Audience Class
• Description
• Requirements
• Information
• Functional
• Usability

Audience Characterisation

• Characteristics

44
Audience Class Hierarchy Example
Visitors
Potential Students
Enrolled Students
Lecturers
Potential Distance Students
Enrolled Distance Students
45
Audience Modelling Example

• Audience Class Enrolled Students
• Information requirements
• Detailed information on programmes, courses,
  university facilities, and lecturers
• Functional requirements
• To be able to enroll for a course, check personal
  timetables, access courseware, participate in
  bulletin boards
• Usability requirements
• Flexible ways to search for courses, lecturers
  and programmes
• Accessibility requirements

46
Audience Characterisation Example

• Audience Class Visitors
• Characteristics
• All ages, may be unfamiliar with the university
  and its jargon
• Experience with WWW may vary
• Language English and Gaelic

Need for Audience Class VariantsEnglish
Speaking and Gaelic Speaking
47
Audience Class Hierarchy Example
Visitors
Potential Students
Enrolled Students
Lecturers
Potential Distance Students
Enrolled Distance Students
48
Next Step Conceptual Design
Mission Statement Specification
Audience Modeling
Conceptual Design
Information Modelling
Navigation Design
49
Information Modelling

• Audience Class Enrolled Students
• Information requirements
• Detailed information on programs, courses and of
  the lecturers

• For each audience class, elaborate the
  information requirements
• Each information requirement gives rise to an
  Object Chunk
• Model data attributes and relationships of Object
  Chunks using ERDs, UML / OMT Class Diagram, or
  other such technique

50
Information Modelling Example
Provide detailed information on courses
Elaborate

• For each course the following information is
  needed
• Name, course code, course objective, ECTS credit
  points, time, venue, prerequisite courses,
  syllabus, means of examination, reading list,
  details of assignments, details of tutorials
• For each lecturer involved in teaching the
  course lecturer name, telephone, room number,
  e-mail address and contact hours

51
Inheritance

• Specialised audience sub-classes inherit the
  information requirements of their parents

Enrolled Students
subclass of
52
Assembling the Object Chunks

• The Object Chunks are then assembled into an
  overall Business Object Model, which shall form
  the basis of the underlying database
• Object Chunks may be regarded as views of the
  Business Object Model

53
Next Navigation Design

• Produce a Navigation Track for each audience
  class. Needs to fulfill all information,
  functional and navigational requirements of its
  audience class. A track comprises a number of
  components
• Components may be Information Components (e.g.
  Contact Information), Navigation Components
  (e.g. Graduate Programmes) or Mixed Components
  (e.g. Programme Information)
• Information Components may contain OCs (Object
  Chunks) and/or TXT content (text, image, etc.)

Top component
Component
Prospective Students Track
Links
Introduction
Contact information
Graduate Programmes
Master Programmes
Programme Information
Introduction TXT
Contact Info OC
General Course Information
Program introduction TXT
ProgramInformation OC
Course Info PotentialStudents OC
54
Components

• Mixed Component
• External Component

Program Information
Program introduction TXT
General Course Information
ProgramInformation OC
Students Track
Conferences
55
Links

• Simple Link

Potential Students Track
Graduate Programmes

• Multiple Link

Programme Information
General Course Information
56
Navigational Model

• The Navigation Tracks must now be linked together
• Here are the steps
• Start with the audience class at the top of the
  hierarchy (e.g. Visitor)
• For each subclass of the audience class
• Add a link between the top component of the
  navigation track of the audience class and of the
  subclass
• Recursively iterate for each subclass of the
  audience class

57
Navigational Model Example
Visitors Track
General Introduction
Prospective Students Track
General Info
Enrolled Students Track
Lecturers Track
General Introduction TXT
General Info OC
Prospective Distance Students Track
Enrolled Distance Students Track
58
Next Step Implementation Design
Mission Statement Specification
Audience Modeling
Conceptual Design
59
Implementation Design

• Page Structure
• Closely based on navigation model, but need not
  necessarily be one-to-one with components of
  navigation model
• Package information in appropriately sized chunks

60
Page Structure Design Example
Enrolled Students Track
Student Introduction
Programmes
Lecturers
Conferences
Programme Information
Student Introduction TXT
Course Information
Programme Introduction TXT
ProgrammeInformation OC
CourseOC
61
Presentation Design
Implementation Design
Page Structure Design
Logical Database Design
Presentation Design

• Presentation Design
• Look-and-feel of the Web Site
• There is a lot of literature on interface design,
  interaction design, graphic design
• Base presentation design on empirically-grounded
  principles and guidelines e.g.
• Use of index page/site map
• Use context and information cues
• Use navigation cues

62
Logical Database Design
Implementation Design
Page Structure Design
Logical Database Design
Presentation Design

• Underlying Database (for structured data)
• Business Object Model acts as the Conceptual
  Schema
• Enhances maintainability (data entry operators
  need not be HTML-literate data integrity means
  no redundant/duplicated information)
• Need not be a fully-fledged content management
  system (e.g. a basic relational database such as
  MySQL, Microsoft Access should suffice)

63
Last Step Implementation
Mission Statement Specification
Audience Modeling
Conceptual Design
Implementation Design
64
Implementation

• Choose implementation environment
• HTML, XML, ...
• (relational) DBMS / content management system
• May be automated using available tools

65
Web-based DatabasesDesign Techniques /
Requirements Specification
66
Specification Techniques

• There are many requirements specification
  techniques in common use, including
• Natural Language
• Structured English
• Pseudocode
• Flowcharts
• Decision Tables
• Decision Trees

67
Natural Language

• In most organisations, software requirements are
  written as paragraphs of natural language
• It is the only means of communication which is
  generally understandable by all potential readers
  of the System Requirements Specification (SRS)
  and for that reason alone should always be used
• There are many shortcomings of natural language
  as a specification technique
• Ambiguity same word used in different contexts
  can have multiple different meanings e.g.
  antonyms, synonyms
• As a systems analyst, dont always assume that
  you have understood the client properly. When you
  think you understand, but if fact you dont,
  errors are introduced
• Communication should be two-way verify your
  understanding by echoing feedback to client
  Correct me if I am wrong

68
Natural Language

• There are many shortcomings of natural language
  as a specification technique
• Variations in scope of vocabulary, and dialects,
  can cause confusion amongst readers
• Inconsistency amongst writers if authoring of
  the SRS is a shared responsibility, there may be
  inconsistent styles / conflicting terminology
• Compound sentences can be confusing
• Compound conditions can be confusing
• Adjectives / adverbs can often be imprecise and
  not quantifiable

69
Natural Language

• The following statements have all featured in
  newspaper headlines
• Safety Experts say School Bus Passengers Should
  be Belted
• Israeli Head Seeks Arms
• Miners Refuse to Work after Death
• Stolen Painting found by Tree
• New Vaccine may Contain Rabies
• In the legal profession, tried and tested phrases
  are constantly re-used in binding documents, but
  disputes over the meanings of terms are
  persistent
• Natural Language must therefore be supplemented

70
Structured English

• Structured English is a language and syntax,
  based on the relative strengths of structured
  programming and natural English, for specifying
  the logic of processes
• It is not pseudocode, but does borrow the
  fundamental control constructs (sequence,
  selection, and iteration) of structured
  programming to overcome the lack of structure and
  precision in the English language
• There is no universal syntax for Structured
  English, so it may be adapted to a form
  appropriate to the reader

71
Structured English

• Structured English insists that
• Only strong, imperative verbs may be used - such
  as GET, FIND, CREATE, READ, UPDATE, DELETE,
  CALCULATE, WRITE, SORT, MERGE etc.
• Only names that have been defined in the project
  repository may be used
• Formulae must be stated using precise
  mathematical notation - e.g CALCULATE GROSS PAY
  HOURS WORKED X HOURLY WAGE
• Undefined adverbs and adjectives are not
  permitted
• Blocking and indentation should be used to
  enhance readibility

72
Example Natural Language

• Convert the following narrative into an
  unambiguous program specification using a program
  flowchart or other appropriate specification
  method
• A program is to take its input from a computer
  file of student names and examination marks, and
  send its output to a printer.
• Initially, the file is opened. Records are
  read one at a time from the file until the last
  record is reached. As each record is read, the
  student's name and mark are printed, as well as
  the outcome. If the mark is less than 40, the
  outcome is "Failure". Otherwise, the outcome is
  "Pass".
• When all records have been processed, the
  file is closed and the program terminates.

73
Example Structured English

• BEGIN
• OPEN FILE
• REPEAT WHILE NOT END-OF-FILE
• READ RECORD
• IF MARK lt 40 THEN
• OUTCOME FAIL
• ELSE
• OUTCOME PASS
• END IF
• PRINT STUDENT_NAME, MARK, OUTCOME
• END LOOP
• CLOSE FILE
• END

74
Example Flowchart
75
Information Systems Modelling

• Models are communication aids often used in
  requirements specification
• In software development, we typically used a
  series of superimposed / interconnected models to
  describe an information system
• Prototyping and simulation tools are often used
  in verifying and validating abstract models
• For effective group communication, all members of
  the group must be familiar with the semantics of
  the modelling notation used
• In Web development, communication is more
  difficult because team members come from greatly
  varied backgrounds (e.g software engineering,
  graphic design)

76
Information Systems Modelling

• Model building is an iterative activity that is
  both top-down (general to specific) and bottom-up
  (specific to general)
• Hence, use of automated tools to generate and
  test models is useful
• A well constructed model should be robust
• Beware analysis-paralysis ! The model is not
  the deliverable!

77
Information Systems Modelling

• Models are built for existing systems as a means
  of communicating and understanding their
  components and workings
• Models are built for proposed systems to document
  business requirements and/or technical designs
• In systems development, it is generally accepted
  that, at least initially, analysis must precede
  design
• this is to avoid a jump-in think-later
  approach, or to prematurely commit to a given
  implementation which may later turn out to be
  impractical, infeasible, or suboptimal
• once initial analysis is complete, design can
  commence, and these two activities can then
  operate in parallel with feedback loops to
  facilitate refinements
• in systems modelling, there are logical and
  physical models ...

78
Logical and Physical Models

• Logical models show what a system does. They are
  implementation-independent - they do not
  consider specific technologies
• however, there may sometimes be a technical
  constraint imposed by the client for example
  this system must run on a UNIX platform and use
  an SQL-compliant database
• logical models must be technically feasible and
  practical
• Technology not only solves problems but also
  creates opportunities. Therefore, there will at
  the very least be subliminal consideration of
  technology
• Physical models show not only what a system does,
  but also aspects of its implementation
• how ? (e.g filing cabinet or database ? central
  repository or distributed files ? networked or
  standalone ? electronic commerce solution or
  paper-based methods ?)
• where ? (e.g where is data stored ? where are
  processes executed ?)
• who ? (human and/or machine ?)

79
Logical and Physical Models

• Systems analysis activities tend to focus on
  logical models for the following reasons
• logical models remove biases that are the result
  of the way the current system is implemented, or
  the way that any one person thinks the system
  might be implemented
• logical models reduce the risk of missing
  business requirements because of preoccupation
  with technical details
• logical models facilitate communication with
  end-users in non-technical, or less technical,
  language

80
Conceptual Modelling Software Design
81
Web-based Systems Modelling

• In the design of Web-based systems, we may need
  to model
• Users
• User Tasks
• Data Structures
• Navigation Structures
• Interface Layout
• Interactive and Real-Time Events
• Process Logic (e.g. e-commerce transactions)
• Security Logic
• Network Models / System Architecture
• Many Web design methods emphasise the need for
  separation of concerns between content and
  presentation

82
User Tasks

• Usability is critical for Web-based systems
• User-centred design approaches are therefore
  recommended
• Traditional software engineering approaches are
  inside-out, whereas user-centred design is
  outside-in
• Focus is on users needs, their work environment,
  the tasks they have to perform
• Commonly used modelling techniques data flow
  modelling (DFDs), scenario analysis, use case
  narratives, use case diagrams

83
Data Flow Diagram (DFD)
84
Limitations of DFDs

• Data flow diagrams are limited in so far as they
  do not model
• the sequence in which processes occur it is
  wrong to customarily assume that processes are in
  order top-to-bottom or left-to-right on a diagram
  !
• the time intervals at which processes occur
• DFDs must at the very least be supplemented by
  ERDs, a data dictionary, and primitive process
  specifications (e.g. Structured English)
• DFDs are more process-centred than user-centred
• The first time (as a rookie systems analyst) that
  I asked an end-user to comment upon a DFD, she
  asked where am I in this diagram?
• Use case diagrams are a more user-friendly
  representation for communicating with clients

85
Functional Decomposition Diagram
Context Level
Second (Systems) Level
Third Level
Process 1 on Systems Level DFD will explode
to 1 Third Level DFD which in this example has
three primitive processes
86
Use Case Modelling (UML)
UML Use Case diagramming notation (example
courtesy of Richard Vidgen www.wisdm.net)
87
Use Case Modelling (UML)
Join the Internet Theatre Club
Make Internet Ticket purchase
Customer
ltltincludegtgt
ltltgeneralizationgtgt
Perform operator ticket sale
Take payment/ make refund
ltltincludegtgt
ltltextendgtgt
Performance full
ltltincludegtgt
Process ticket return
Telephone sales
Dispatch tickets
Update accounts
Accounting system
Use Case diagram for theatre operations (example
courtesy of Richard Vidgen www.wisdm.net)
88
Use Case Modelling -v- Data Flow Diagrams

• Use case models are a more user-centred technique
  than data flow diagrams (DFDs) they explicitly
  focus on actors and the use cases (tasks)
  that they are engaged in
• Data flow diagrams are more process-centred they
  explicitly show the information requirements
  (flows in) and information produced (flows out)
  for any given process (aka task)
• Use case models are supplemented by natural
  language narratives called use case scenarios
  (see next slide)
• Data flow models are supplemented by primitive
  process specifications i.e. descriptions of
  low-level processes. In fact, these can be
  written in natural language, just like use case
  scenarios
• Primitive process specifications can also use
  techniques like Structured English, decision
  trees, decision tables, structure charts, etc.
• Functional decomposition diagrams (FDDs) are used
  to show process hierarchies this is something
  that is missing from UML
• The DFD concept of exploding high-level models
  to lower-level, more detailed models can also be
  done with use case models
• DFDs, FDDs and Use Case Models can be used
  alongside one another

89
Use Case Scenario
Use case description for Make Internet ticket
purchase (example courtesy of Richard Vidgen
www.wisdm.net)
90
User Stories

• User Stories are a technique used in eXtreme
  Programming (XP) to specify functional
  requirements.
• Stories must be understandable to the customer
• Use plain, natural language
• Customers write stories. Developers do not write
  stories
• All proposals by developers must be approved by
  the customer
• The shorter the better. No detailed
  specification!
• A story is nothing more than an agreement that
  the customer and the developer will talk together
  about a feature.
• Each story must provide something of value to the
  customer
• So as to avoid building fancy features that will
  not be used
• A User Story must be testable
• So that we can know when it is implemented

91
User Stories

• Writing stories is an iterative process,
  requiring lots of feedback
• Customers will propose a story to the programmers
• Programmers decide if story can be tested and
  estimated
• Customers may have to clarify or split the story
• Write stories on index cards
• cards are simple, physical devices that invite
  everybody to manipulate them
• A story contains not more than a few sentences
• if the story is too big, write only the essential
  core
• If the story is not quite right, tear the card up
  and write a new one

92
User Stories

• Programmers ask the customer to split a story if
• They cannot estimate a story because of its
  complexity
• Their estimate is longer than two or three weeks
  of effort
• Reasons
• Estimates get fuzzy for bigger stories
• The smaller the story, the better the control
  (tight feedback loop)
• Some rules for splitting stories
• Stories that have an important part and a less
  important part make two stories
• Stories covering several related cases make each
  case a story
• Also Bundle stories with estimates of less than
  a day together avoid cluttering the release plan

93
Data Modelling

• Increasingly, most Web-based systems are somehow
  database-driven, - hence, there is a need for
  data modelling
• Trend toward content management systems (CMS)
• Intelligent adaptive Web-based systems
  (personalised to needs of individual user) use
  database technologies
• Semantic Web XML, XSL, RDF, SMIL, etc.
• Move towards meaningful computer-searchable
  metadata
• Data / information modelling techniques include
• Entity-Relationship Diagrams
• Class Diagrams
• Normalisation
• Jackson Structured Programming (JSP)
• RMDM Diagrams
• Whatever diagramming technique is used (e.g.
  class diagram or ERD), it needs to be resolved
  into a relational database schema
• Many CASE tools exist for automatic generation of
  SQL code from data models (e.g. Oracle Designer,
  Microsoft Visio, DB Designer, Case Studio)

94
Entity-Relationship Diagrams
95
Class Modelling
Class diagram for Theatre Booking System
(example courtesy of Richard Vidgen www.wisdm.net)
96
Process / Entity Matrix (CRUD)

• As earlier mentioned, information systems design
  entails a number of overlapping and inter-related
  aspects e.g. users, data, tasks (aka functions
  or processes), GUI screens
• 2 x 2 matrices are useful tools to show how each
  of these inter-related aspects map onto each
  other
• These help to detect anomalies and oversights
  during design
• A process / entity matrix is simply a
  2-dimensional grid, with all the processes (aka
  tasks), listed along one axis, and all the
  database tables (i.e. entities) listed along
  the other
• Then, in each cell of the body of the grid, it is
  indicated which processes Create (C), Read (R),
  Update (U) and/or Delete(D) which data
• Note that all tables must have at least one
  process capable of performing each of these
  operations (i.e. basic data maintenance of
  adding, deleting and updating records)
• The CRUD matrix can easily be transformed into a
  security matrix e.g. by knowing which users
  perform which tasks, and what data those tasks
  require access to, appropriate privileges can be
  granted

97
Interactive / Real-Time Events

• Web-based system are interactive systems
• Navigation structures / information architecture
  must be designed
• Most popular techniques are informal ones e.g.
  flowcharts, sitemaps, storyboards
• The process logic for interactive / real-time
  tasks must be modeled
• Techniques such as use case scenarios, data flow
  diagrams, state diagrams, collaboration diagrams,
  activity diagrams, etc. can be used here
• Formal or semi-formal techniques are fine
  when communicating with software engineers, or
  working with CASE tools to rigorously
  design/validate/generate software prototypes, but
  are of little use for communicating with clients
  and non-technical team members e.g graphic
  designers

98
Collaboration Diagram (UML)
2.1 getPerformanceDetails()
Performance
Production
1 find()
4.1 getSeatAtPerformanceDetails()
2 listPerformances()
Seat at Performance
Internet user
3 listParts()
4 findSeats()
3.1 getPartDetails()
3.1.1 getPrice()
Theatre
Part Of Theatre
Price List
Collaboration Diagram for Make Internet ticket
purchase (example courtesy of Richard Vidgen
www.wisdm.net)
99
State Transition Diagram (UML)
State transition diagram for SeatAtPerformance
(example courtesy of Richard Vidgen www.wisdm.net)
100
start
Box Office clerk
Box Office Manager
responsibility
Receive order for tickets
activity
Receive ticket return
swim lane
multiple trigger

For each performance requested
Check ticket Order details
Authorize payment
Review wait list
Make refund
payment not authorized
Allocate seats
decision activity
Cancel ticket order
synchronization bar - fork
Allocate seats to wait list
request for performance not satisfied
payment authorized
Put on wait list
guard
synchronization bar - join
all possible wait list satisfied
tickets assigned to All performances and payment
authorized
Send tickets
Make seats re-available
UML Activity Diagram for theatre booking system
(example courtesy of Richard Vidgen www.wisdm.net)
101
Internet user
Production List
Performance List
Price List
Available Seats
Payment
list Productions()
Find production
Display productions
listPerformances(aProduction)
Find performances
Display performances
listPrices(aPerformance)
Find prices
Display prices
Request seats
requestSeats(aPartofTheatre, aNumberOfTickets)
Session
Display seats allocated
makePayment()
Make payment
validate()
GlobalPay
authorize()
Customer receives confirmation of payment and
details of performance and seats
Confirmation
Display booking confirmation
UML Sequence Diagram for Web-based theatre
booking system corresponding to use case Make
Internet ticket purchase (example courtesy of
Richard Vidgen www.wisdm.net)
102
Decision Logic

• The aforementioned techniques may not be fully
  suitable or adequate when modelling the
  intracices of process logic
• many processes are governed by complex
  combinations of conditions that are not easy to
  clearly expressed in natural language
• for logic based on multiple conditions and
  combinations of conditions, decision tables and
  decision trees are far more elegant logic
  modelling tools
• This is most commonly encountered in business
  policies and procedures - for example, a loan
  application in a bank will consider a set of
  criteria (conditions) and arrive at a decision
  which is one of a known set of outcomes
  (accept, reject, defer, etc.)

103
Decision Trees

• A Decision Tree is a model of a discrete function
  in which the value of a variable is determined,
  and then based on that value, a particular course
  is followed
• Example A motor insurance company has a policy
  whereby they do not insure drivers under 20, or
  drivers under 22 who do not possess a full
  licence. Males under 25 with provisional licence
  are charged 1400 with full licence are charged
  1000. Males aged 25 or over with provisional
  licence are charged 800 with full licence 600.
  Females are charged 70 of the appropriate
  premium payable by males of the same age.
• (Solution on next slide)

104
Example Decision Tree
Reject
Yes
Reject
Yes
Male ?
Age lt 20
Age lt 22 ?
Yes
No
No
No
Male ?
No
Full Licence ?
Age lt 25 ?
Yes
Yes
Age lt 25 ?
Male ?
No
Male ?
105
Decision Trees

• A problem with Decision Trees is that there can
  be many different ways of modelling the same
  logic
• Building the tree with the most important
  condition at its roots can lessen the number of
  branches for example, if a driver is aged less
  than 20, none of the other conditions need to be
  evaluated
• Dont infuriate users by getting them to waste
  their time registering for a service on your Web
  site, only to be later told that they are
  ineligible for that service (e.g. age
  constraints, no international shipping, wholesale
  trade only, etc.)
• Decision Trees are easy to convert to program
  flowcharts or directly to code (e.g. nested
  IF-ELSE-ELSEIF statements)

106
Navigation Modelling
107
Navigation Structures

• Web-based systems aim to present information in
  such a way as to readily facilitate its
  identification, assimilation, and manipulation
• Hence, well defined access mechanisms are
  critical for Web-based applications
• For E-Commerce Web sites, navigation structures
  are key strategic decisions
• Common navigation structures are linear, tree,
  hierarchy, matrix, Web, or a hybrid of these
• Trade-off expressive power -v- risk of
  disorientation
• Commonly used techniques flowcharts, storyboards

108
Flowcharts

• A block-diagramming technique in popular use in
  software development since the 1960s
• Traditionally used in programming for specifying
  flow-of-control logic
• Useful for diagramming Web pages and links
  between them (see example next slide)

109
Flowcharts - Example
110
Flowcharts - Example

• IBM Flow Diagram

111
Dynamic Diagrams
Link diagram for a hypermedia encyclopaedia,
showing existing materials and new materials to
be added.
112
Storyboards

• Storyboarding is an informal, loosely-structured
  technique that may be used to model
• Navigation
• Time-based and interactive effects
• Scenarios and transitions
• Storyboarding has been used in film production
  since the 1910s, and refined by Walt Disney when
  producing animated movies in the 1930s

113
Storyboards

• What is a storyboard?
• Inventory and organisation of a Websites pages,
  screen designs, media, and content
• description of page
• text and narration content
• graphics
• video including voice-over script
• 3D/animation
• audio
• links to and from
• Storyboards are mostly hand-drawn (see next
  slide), but some software products exist e.g
  Eastgate Storyspace, SILK, Anecdote, DENIM

114
Storyboards
115
Storyboarding - Universal Template
116
Eastgate Storyspace
117
SILK

• James A. Landay Brad A. Myers (2001). Sketching
  Interfaces Toward More Human Interface Design.
  IEEE Computer. 34(3) March
• SILK (Sketching Interfaces Like Crazy) is an
  interactive UI design tool that supports
  electronic sketching

118
Sitemaps

• Sitemaps show the information architecture /
  navigation structures of a Web site
• Simple 2-D sitemaps resemble functional
  decomposition diagrams
• 3-D pictorial sitemaps present a richer view
• Layout of a site might follow user navigation
  trails (as per WSDM method), tasks,
  organisational divisions, or other logical
  breakdown
• May have more than one sitemap for any given site
  e.g. different ways of finding your way around
• Sitemap must be at appropriate level of
  abstraction
• You dont look up a world atlas to find out how
  to go from Salthill to Renmore ! Nor do you look
  up a street map to see how to get from Westport
  to Kilkenny.
• If a Martian landed in Eyre Square and was given
  a street map of his immediate surroundings, would
  he know that he landed in the right country?
• Can have more detailed sitemaps for sub-sites.
  Always need to be able to find your bearings
  both immediate vicinity, and where you are in the
  overall site

119
Manually Generated Sitemaps

• Apple Corporation Website (c.1996)
• Hand-created map
• Unlike physical space, the shape and layout of
  virtual space is constantly changing hence,
  high overheads of maintaining hand-created maps

120
Automatically Generated Sitemaps

• Many software products to map Web sites are
  available. Examples
• Visio (http//www.microsoft.com/office/visio/)
• Macromedia Dreamweaver (http//www.macromedia.co
  m/software/)
• Microsoft Frontpage (http//www.microsoft.com/of
  fice/visio/)
• Electrum Powermapper (http//www.electrum.co.uk)
  
• Dynamic Diagrams (http//www.dynamicdiagrams.com
  /)
• Astra SiteManager (http//www-svca.mercuryintera
  ctive.com/products/)
• SiteBrain (http//www.thebrain.com/)
• Differences include 2D -v- 3D Types of views
  provided Read-only maps -v- Drag-and-drop
  organisers
• Many use Web crawlers and/or Java applets

121
Visio Web Diagram
122
Macromedia Dreamweaver Site Map

• lang1.nuigalway.ie Web Site
• Automatically generated sitemap
• Limited by 2D hierarchical structures

123
Microsoft Frontpage
124
Electrum Powermapper

• Isometric view
• Automatically generated imagemap
• Levels can be exploded to greater detail
• Improvement on 2D mapping techniques

125
Electrum Powermapper

• Tree view
• Automatically generated imagemap
• Levels can be exploded to greater detail

126
Dynamic Diagrams

• BRITANNICA Online
• Global links defined
• Separation of free pages from
  subscriber-only pages

127
Dynamic Diagrams
Architecture diagram for an on-line product
catalogue
128
Dynamic Diagrams

• Financial Company Intranet
• Symbol distinction between pages, databases, and
  applications
• Colour distinction between departments

129
IA Further Reading

• For further reading on sitemaps, navigation
  design techniques, and information architecture
  (IA), see
• Rosenfeld Morville, Information Architecture
  for the World Wide Web
• If you are interesting in learning more about the
  principles of good interaction design, see
• Preece, Interaction Design
• Nielsen, Designing Web Usability
• Krug, Dont Make Me Think
• Norman, The Design of Everyday Things
• (These subject areas are not part of the syllabus
  for Databases. They will be covered elsewhere. I
  include them here for the sake of those who wish
  to bring together all the various aspects of
  information systems design)

130
Closing Comments

• There is no single best way of designing a
  Web-based system
• Experienced designers follow their own good sense
• Structured processes, methods and techniques have
  benefits (e.g. shared understanding of the way
  we do things round here) but never forget, they
  are just a means to an ends!
• Ultimately, the ends is an operational system.
  Regardless of how you go about it, the
  requirements for that system are the same.
• However, the extent to which you nail the
  requirements can be influenced by the rigour of
  your processes and framed by the implicit
  assumptions of your approach e.g. some engineers
  think only about functionality, not about
  usability
• So the rule is anything goes ! If you find a
  particular method or technique helpful, use it.
  Dont be afraid to mix-and-match, improvise,
  tailor, or deviate. Methods and techniques are
  there to guide and facilitate creative design
  solutions, not to constrain them! Often, the
  best methods are simple ones.