Model-driven Application Design

v
for a Campus Calendar Network

Allison Bloodworth
Project Manager
e-Berkeley Program Office
University of California, Berkeley
abloodworth@berkeley.edu

November 18, 2004

Today’s Talk

 The Generic Problem of Incompatible

Data Models
 Our Case Study Context
 UC Berkeley Calendar Network
 Model-Based Application Design
 Model used for information exchange & to
guide the user interface designer
 Our Approach
 Document Engineering
 User-Centered Design
 Demo of Prototype
The Generic Problem of Incompatible
Models
 Many large organizations struggle with
incompatible models for applications created in
different departments
 Time sheets, contact management systems,
expense forms, project schedules, registrations, etc.

 The problems are also typical of those that

arise between enterprises with incompatible
catalogs and transactional documents like
orders and invoices.
Generic Symptoms

 Can’t share data

 Models aren’t captured, can’t be shared

or reused

 Can’t easily create and maintain

interconnected or similar applications
Case Study: UC Berkeley Calendar
Network
 Goal: Design an enterprise application to
allow web-based event calendars to
share event information

 Challenge: Working in a decentralized

university environment where:
 There are very few formal guidelines on
creating web-based applications
 It is difficult for different departments to
coordinate with one another
 Many departments have very limited technical
resources
Our Case Study Context
 There are numerous calendars on the
Berkeley campus
 The Academic Calendar
 Bancroft Library
 Berkeley Art Museum/Pacific Film Archive
 Boalt Law School
 Cal Performances
 College of Engineering
 College of Letters & Science
 Haas School of Business
 Institute for East Asian Studies
 Lawrence Hall of Science
 Live.berkeley.edu
 UC Berkeley gateway site (www.berkeley.edu)
 …and more than 70 others
U.C. Berkeley Gateway
Calendar
Boalt Law School
Berkeley Natural History
Museums
The Purpose of Web Calendars

 A web calendar is a marketing tool

 Its main purpose is to publicize events,
either within a community, or to the
general public

 Calendars should make it as easy as

possible for users to find information on
events of interest to them
The Problem with calendars at
Berkeley
 It is difficult to get a comprehensive view
of all campus events on a given day

 It can be very difficult for calendar users

to find events of interest to them
 If they really want to do a thorough search,
they must go to many different calendars
Our Challenges

 Because the purpose of a calendar is to

publicize events, many of these
calendars would like to share their events
with each other
 Currently there is no automated way to do this

 Incompatible data models & lack of

technical resources prevent an
automated exchange
The Key to Project Success:

 Convince departments on campus to switch to

our system
 Have to gain “critical mass” of users in order to
obtain enough event information to be useful to the
system’s users

1. Design a shared data model of an event that met

almost everyone’s needs
2. Allow calendars to provide their users with a
customized view of the data
3. Assist users of varying levels of technical skill in
creating a customized calendar that is better than
the one they currently use
Incompatible Data Models
 U.C. Berkeley Gateway Site

 Haas School of Business

The Solution

 A standard data model of an Event

(
http://dream.berkeley.edu/EventCalendar/Event
)
 A centralized repository of Event
information
 A calendar management tool
 Manage events in the repository
 Customize a visually compelling, dynamic web-
based calendar
 A design for a system architecture allowing
XML feeds to and from the repository for
calendars who choose to maintain their own
website & repository
System Architecture
Model-Based Application
Design
 The collection, presentation, and exchange
of data is governed by a formal model

 Application can be generated from model in

limited circumstances (simple forms,
workflow) and when interfaces are only to
other applications (e.g, Web Services)
 In other cases, model can guide the UI
designer
 What information is most important
 How best to group information together
 Co-occurrence constraints
Our Approach

 Document Engineering (DE)

 Help us design the documents that are
interfaces to systems or services
 The data exchange model of an Event

 User-Centered Design (UCD)

 Help us design the applications that are
interfaces for people

 Our context had both service interfaces &

user interfaces
What is Document
Engineering?
 “A new discipline for specifying, designing,
and implementing the electronic documents
that request or provide interfaces to business
processes via web-based services”
- UC Berkeley Center for Document Engineering
website (http://cde.berkeley.edu)
 A document-focused method of analyzing
information from diverse sources and
merging it to create a single, unified data
model of the domain
 End result: a document that “defines a packet
of information needed to carry out a self-
contained logical message”

(from Glushko & McGrath, Document Engineering, MIT Press, 2005)

Document Engineering (DE)
 Context & Business Process Analysis
 Document Analysis
 Inventory of Existing Models and Information Sources
 Component Analysis
 Harvesting and Consolidating data elements
 Component Assembly
 Designing a (Relational) Component Model
 Document Assembly
 Assembling a Document Model
 Implementation
 Encoding Models as Schemas
 Deploying Models in Applications

(from Glushko & McGrath, Document Engineering, MIT Press, 2005)

(from Document Engineering courses taught at UC Berkeley)
Context Analysis – Needs
Assessment
 Interviews
 Student Organizations
 Associated Students of the University of California
 Graduate Assembly
 Academic Departments & Schools
 Boalt Law School
 College of Letters & Science
 College of Natural Resources
 Haas School of Business
 Graduate School of Journalism
 School of Public Health
 School of Information Management & Systems
 University Administration
 Information Systems and Technology
 Centers, Institutes & other campus organizations
 Center for Latin American Studies
 Institute of East Asian Studies
 International House
 Museums
 Berkeley Art Museum and Pacific Film Archive
 Recreational Sports
Interview Findings
 Very important to maintain brand, or “look
and feel” of rest of website
 Ability to update information easily and
quickly
 Share events with other organizations on
campus
 3 levels of users:
 Low level – Static html or no calendar
 Medium level - Willing to try other calendar
applications
 Advanced level – Do not want to replace current
system but want to share events with UCB
community
User-Centered Design Tasks
(UCD)
 Personas & Goals
 Scenarios
 Task Analysis
 Frequency & importance of tasks to each
persona
 Competitive Analysis
 Web Event
 Cal Agenda
 Calendars.net
 Live.berkeley.edu
 iCal
 MS Outlook
 Yahoo Calendar
DE - Document Analysis

 Creation of a “Document Inventory”

 Document guidelines & standards
 Sample document instances
 Web pages
 Other information sources

 Standards Investigated
 iCalendar (RFC 2445)
 Source of our repetition rules
 SKICal
 Influenced our Admission Info section
DE- Document Analysis (con’t)
 Calendar types selected for evaluation
 Academic Departments
 Academic Colleges/Schools
 Research Centers
 Libraries
 Museums
 Athletics
 Personal Calendaring Systems
 Administrative Departments
 Student Groups
 Analyzed 23 calendars in all
 A representative sample of the domain
 Kept analyzing new calendars until “law of
diminishing returns” told us when to stop
 Used 80-20 rule to focus efforts
DE - Component Analysis
 Creation of a “Consolidated Table of
Content Components”
DE - Component Analysis
(con’t)
 Harvesting & Consolidating Components
 Need metadata to capture the meaning &
business rules of each component because the
name is not “self-describing”
 Calendar
 Name of data element in calendar
 Our semantically unambiguous name (glossary)
 Composite Name (groups of related elements, e.g.
DateTime)
 Description
 Data Type
 Possible Value
 Default Value
 Etc.
 Harvesting took on average 2 hours per calendar
DE - Component Analysis
(con’t)
 Glossary
 Our simplified version of a controlled vocabulary
 Ensure that every component is semantically distinct
by weeding out homonyms & synonyms
 Ensure that we break elements down to an
appropriate level of granularity for our context
of use

 Collected average of 16 data elements per

calendar from 23 calendars
 350 total elements from all the calendars
 150 had unique names
 100 had unique semantic meaning
 DE – Component Analysis
(con’t)

Calendar Calendar Element Name of Element

Element Glossary Evaluator Glossary
Name Name ID
Doe Location Location Sara Event
Library Location
Math Dept Location Location Sara Event
Location
IAS Place Location Sara Event
Location

 Look for elements from other

vocabularies to reuse
 AddressType from UBL
 PersonalNameType from BABL
DE - Component Assembly

UML Class Diagram created with Dave Carlson’s “hyperModel” tool

DE - Component Assembly (con’t)
 Strict Normalization
 Functional dependency
 If the value of one component changes when the other
changes
 We may relax our normalization principles for the
sake of efficiency or ease of use

 “Core & Contexts”

 Top down vs. bottom up approach
 Core - set of elements that are common to all
document models
 Context - structures more related to specific
contexts
 Sometimes there are few pre-defined strong semantic
constraints, so we create our own
 Admission Info section in “Add Event” form
DE – Document Assembly
 Document hierarchy imposes an
interpretation on a relational model

Image from Glushko & McGrath, Document Engineering, MIT Press,

DE – Implementation

 Encoding our model in W3C XML Schema

 Creating the application that uses the

Event model to exchange of event
information between calendars
DE – Implementation (con’t)
 Schema Design Issues
 Design for reuse, maybe even in other domains
 Optional vs. Required Elements
 Required: Event Title, Event ID, DateTime
 Minimal “Core” of required elements sets low barrier to
entry
 Allows us to gain the necessary critical mass of users in our
domain
 Allows for reuse in other domains
 “Garden of Eden” style schema – everything’s
global!
 Redefines (types)
 Important for creating enumerated lists
 Substitution Groups (elements)
 Allowed too much flexibility in the instance in our domain
 Wanted to allow them if necessary in other domains
 xsi:Any as opposed to defining an “Open-entry” element
 Codelists (?)
UCD – Iterative Design Process
 Allowed us to refine the way we presented
information to users
 Inject user feedback into the design process

Paper Prototype
UCD – Iterative Design Process

Interactive Prototype
UCD – Iterative Design Process
 Findings from Usability Testing
 Application Layout
Paper prototype

1st Interactive prototype

Latest Design

 Terminology
 Post vs. Publish
 Event Contact
 Features
 Export
Calendar Transforms
 Event Instance
 Institute of East Asian Studies calendar
 Original (http://ieas.berkeley.edu/events/)
 Our transformation
 Letters & Science calendar
 Original (http://ls.berkeley.edu/events/)
 Our transformation

 The use of XML & XSL is critical in

allowing calendars to easily create a
customized view of the data
Demonstration
Questions?
abloodworth@berkeley.edu