Professional Documents
Culture Documents
Abstract
In this paper we discuss the use of an object-oriented approach for
hypermedia applications design, including web-based, based on the Object Oriented
Hypermedia Design Method (OOHDM).
1
Figure 1: OOHDM design models
Abstract Interface Abstract interface Abstract Data Mapping between Model perceptible
Design objects, responses Views navigation and objects,
to external events, Configuration perceptible implementing
interface Diagrams objects. chosen
transformations ADV-Charts Composition and metaphors.
Design Patterns generalization/ Describe interface
specialization for navigational
objects
Define lay-out of
interface objects
2
2. Conceptual Modeling
During Conceptual Design a model of the application domain is built using
well known object-oriented modeling principles, with a notation similar to UML.
The product of this step is a class schema built out of Sub-Systems, Classes and
Relationships. The major differences with UML are the use of multiple-valued
attributes, and the use of directions explicitly in the relations
3
belongs
produces
0..N 0..N
Sponsor Laboratory Personel
Name: string Name: string Name: string
UrlSponsor: string Description: string Degree: string
0..N N Description: [text+, image]
conducted in Equipment belongs Email: string
funds HomePage: string
Name: string
N
N
Research Project N N
Academic Technical Administrative
Name: string participates N
N Description: string 0..N
N
Budget: real N N N N
Professor advises Student produces Students Production
0..N N N
Rank: string N N OnLineContent: string
belongs Degree: string
N
belongs
1
Area of Research teaches
N
N Graduation Thesis
Name: string Course Offering
Description: string attend Project
N
Semester: string 1
N 1
N Schedule: string Evaluation: integer pursues PhD MSc
Classroom: string
1 1
N StudentID: integer
BeginningDate: date
Complementary Material EndingDate: date
related OnLineContent: string
Location: string
belongs offered
requires
Slide WorkBook Exercise
N
N Degree
has elective
N
Name: string
Course N RequiresAmount : integer
1 Name: string ElectivesAmount : integer
0..N N
has required
belongs Description: string
N NumberOfCredits: integer N
N Research Result 1
SuggestedPeriod : string
Title: string Syllabus : text Graduate Undergraduate
PublicationDate: date
Abstract: text 0..N 0..N
Autors: set of string requires
1
MSc PhD requires
1
requires
Book Technical Report Paper Software Hardware
Edition: string Code: string BiblioReference: string OnLineContent: string
Publishing: string OnLineContent: string OnLineContent: string
3. Navigational Design
In OOHDM, an application is seen as a navigational view over the
conceptual model (see Figure 2). This reflects one of the major innovations of
OOHDM, which recognizes that the objects (items) the user navigates are not the
conceptual objects, but other kinds of objects that are built from one or more
conceptual objects. Therefore, node attributes are defined as object-oriented views
of conceptual classes, using a query language similar to the one in [Kim94],
allowing a node to be defined by providing access to attributes of different related
classes in the conceptual schema. This view is oriented towards a certain class of
users and their respective tasks. Nodes generalize the Observer concept from
[Gamma95].
4
For example, in the conceptual model a research project is linked to its
sponsors (a separate class). However, for most classes of users, there is no need to
have a separate node describing the sponsor; it suffices to have their respective
names and URLs to their sites as a reference. Therefore, in the navigational node
corresponding to research project is defined as having two virtual attributes
whose values are respectively a list of sponsors names and URLs, mapped from
the corresponding attributes of the conceptual class sponsor.
5
belongs
conducted in N
N N 0..N
N Students Production
Research Project Laboratory
OnLineContent: string
0..N Name: string Name: string Personel
Description: string Description: string
Budget: real Equipments: set of string Name: string
Degree: string
SponsorNames: list of anchor ( UrlSponsor ) PrfsIdx : index (Professor by Laboratory) Graduation Thesis
Sts : anchor( index (Student by Laboratory) ) Description: image Project
N Bio: text
0..N Prjs : anchor( index (Research Project by Laboratory) )
Email: string 1
0..N HomePage: string PhD MSc
participates
belongs produces 1 1
N N
Professor Student 1
belongs
N Rank: string
1 PrdsIdx: index (Students Production by Student)
belongs ArsIdx : index (Area of Research by Professor) CrsIdx : index(Course Student by Student)
Crs : anchor ( index (Course Offering by Professor) )
1 1 1
N N
Sts : anchor ( index (Supervised Student by Professor) )
1 1
Area of Research supervised took degree
teaches advises requires
Name: string
Description: string N N N N
PrfsIdx : index (Professor by Area of Research)
related Crs : anchor ( index (Course by Area of Research) ) Course Offering Supervised Student Degree Student
Prjs: anchor ( index (Research Project CourseName: string StudentName: string attend StudentName: string
by Area of Research) ) NumberOfCredits: integer ProfessorName: string DegreeName: string
Rsts: anchor ( index (Research Result SuggestedPeriod : string Degree: string StudentID: integer
+ Students Production by Area of Research) ) ResearchArea: string BeginningDate: date
1
Lbs: anchor ( index (Laboratory by Area of Research) ) ProfessorName: string EndingDate: date
N Semester: string
N 1 enrolled N
Schedule: string Course Student
Classroom: string
N StudentName: string N
N Semester: string
Complementary Material CourseName: string
Evaluation: integer
OnLineContent: string
Location: String pursues
belongs offered
1
Course
N N Degree
Name: string has elective
N 1 Description: string Name: string
NumberOfCredits: integer RequiresAmount : integer
N Research Result N
belongs SuggestedPeriod : string has required ElectivesAmount : integer
Title: string N N CrsIdx : index (Course by Degree)
ResearchArea: string
0..N
PublicationDate: date Syllabus : text
Abstract: text RqsIdx : index (Course by Requirement) 1
Autors: set of string Offs : anchor ( index( CourseOfferings by Course) )
Graduate Undergraduate
0..N 0..N
requires
1
Technical Report Paper Software MSc PhD requires
Code: string BiblioReference: string OnLineContent: string 1
OnLineContent: string OnLineContent: string requires
Figure 4 Navigation Class Schema for the Academic Web site. Note the conversion
of relations with attributes into classes (e.g., Professor advises
Students on a Degree)
1- Simple class derived - all objects of a class that satisfy some property;
e.g., professors with rank equal associate. A variant of this type is the
query based context, where the property is defined by the user at
navigation time.
Graphically:
6
2- Class derived group - a set of simple class derived contexts, where the
defining property of each context is parameterized; e.g. professors by
rank (rank can vary).
Graphically:
3- Simple link derived - all objects related to a given object; e.g., courses
taught by professor Smith. Graphically, same as 1.
Graphically:
Associated to the contexts, there are access structures (indices). They are
denoted graphically by:
Index:
Dynamic Index:
In any of the above, if there is an access structure defined for it, the
corresponding graphical notation contains a small black square in the upper left
corner.
7
Supervised Student
by Professor
Personel
Personel Category Professors
Academic
Menu
Professor
Courses
Courses Professors Alphabetic
Menu
by Laboratory
Current by Research Project
Offerings
by Area of Research
Offerings for
Next Semester Student
Students
Students Alphabetic
Currents by Professor
Research Result +
Students Production
by Course
by Author
by Area of Research
Course
To consult
Alphabetic Courses results Results by Query
by Requirement
Research Project
by Area of Research Research Project Research Alphabetic
Projects
by Degree
by Person
by Laboratory
Courses Degree
by Area of Research
Degree Degrees
Alphabetic Degrees Laboratory
Laboratories
Laboratories Alphabetic
by Area of Research
by Professor
The context diagram does not contain all the information needed to specify all
contexts; each context and access structure must be further detailed in a CRC
Card such as the one shown in Figure 6 and Figure 7.
8
Context: Course Offering Enrollment Choices Type: dynamic
Attributes:
Parameters: <period>
Include: co Course Offering | co.inContext(Course Offering by Semester )
Selected(co) not SchedulesConflict(co)
Methods:
RemoveCourseOffering (co)
if Selected(co) not Obligatory(co, <period>) then
Context( Course Offering Enrollment Choices ) =
Context (Course Offering Enrollment Choices ) - co
end_if
end RemoveCourseOffering
Classes in context:
Context changes:
Entry points: (1 node default): Any element of the context.
Path: To index. Ordering: [ (by Time Slot)+, (by Name) ]
Type of context link:
Export / Import:
Use restrictions:
User: Permission:
Comments: Group of courses that has been selected during a session to configure
a enrollment (organized by name or by scheduling -days of week -).
Trace backward: Trace forward:
Once contexts have been defined, it is possible to extend a class definition with a
decorator (see [Gamma 95]), which is called an InContext class. This class adds
attributes to an existing class, when accessed from within a specified context. For
example, the attribute professors name may be included in projects when
9
accessed within research projects by research area, but not when accessed within
context research projects by professor, since the professor's name is implicit.
OOHDM itself does not prescribe any particular procedure to synthesize navigation
designs. To aid the designer, we have developed a method based on user specified
scenarios to guide this process [Gell 98]. According to this method, navigation
design proceeds in the following steps (see Figure 8):
2. Scenario collection
10
Preliminary Navigation
Class Schema
For cada
Para eachcenrio:
scenario: Graphic
Esboo grfico,
Para cada
sketch; cenrio: Alternatives;
Questions; Esboo grfico,
Scenario Argumentos, Questes,
Scenarios Argumentos, Questes,
Cenrios
Cenrios Argumentation; Solutions
Alternativas e Solues
Analysis Alternativas e Solues
Design
Patterns Refined Navigation
Class Schema
Design
Patterns Synthesis of Partial
Navigation Schema
For each
Para cadascenario: Partial
cenrio: Esquema Final Context Schema;
Para cada Context
Navigation cenrio: Esquema Union of partial Final InContext Class
parcial de contextos de
parcialInContext
Schema, de contextos de
Class solutions Schema
navegao, Vises das classes
navegao, Vises das classes
definitions
nosfor contexts in
contextos
nos contextos
the scenario
Revised Navigation
Class Schema
User TASK
Class
Currents Students
Find out the information necessary to select classes for enrollment in the coming
semester
Choose an advisor
Find out the professors that have taught a given course, and look at the material used in
each offering
11
User TASK
Class
Prospective
Find general information about the department
Students
Find out a known professor, in order to get in touch with him or her.
For each category, one must select representative user(s), and ask them to
write a scenario describing how they envisage the system helping them to perform
the task. Figure 9 shown an example.
Task:
Peruse the required courses for obtaining an undergraduate degree in Computer Science
Context:
I am a CS student and I want to study the required courses for my degree credits and
prerequisites in order to plan which courses I will take next semester.
Actions:
1. I look for a Course Structure section, possibly under the Computing Engineering area;
2. I select one course, and I get information on the number of credits, the prerequisite courses and the
suggested semester within the course in which it should be taken.
12
typically omit several types of details, such as access structures, selection attributes
to be used in indexes, orderings, treatment of exceptions, etc The designer can
either supply the missing information out of his own understanding of the
problem domain, or ask the user, or use a previously seen solution for a similar
problem effectively applying a design pattern (see Figure 10 (b)).
Courses {Pre-requisites}
Suggested semester
(a)
(1) Undergratuate
Undergraduate Courses Computing (2)
Courses Engineering Course Course X
Computing Offerings
Engineering Course {Pre-requisites}
Offerings CourseX Suggested
semester
(b)
13
Course Offering
Enrollment
Choices
In OOHDM we use the Abstract Data View (ADV) design approach for
describing the user interface of a hypermedia application [Cowan95]. Abstract Data
Views are formal models of interface objects and they are specified by showing:
b-The way in which they are statically related with navigation objects. We
use Configuration Diagrams [Coleman92] for expressing these relationships. An
ADV is related with a corresponding application object which acts as a behavioral
server for those operations not specific to the interface. This object is called the
ADV owner and it is similar to the model object in the well known model-view-
controller object-oriented interface paradigm.
14
In Figure 12 we show the ADV Professors by Laboratory together with a
mock-up of the actual interface.
Professor ADV
SelectedAnchor()
Laboratory Alfabetic
Back_Lab : anchor ( Laboratory
Alfabetic (<laboratory>) )
SelectedAnchor()
Next_Prof : anchor( next(
Professor by Laboratory ) )
Professor by Laboratory
Personel ADV
Area of
Research
by Professor
SelectedAnchor()
Professor ADV
Academic ADV
PersonelCategoryIdx:list of ( anchor(
Personel) ) Courses: anchor ( index(Course
Offering by Professor) )
Name: string
Degree:string Students: anchor ( index(Supervised
Bio: text Student by Professor) )
Description: Image
Email: anchor(self. Email)
HomePage: anchor(self.UrlHomePage)
See [Schwabe 96, Rossi 96, Schwabe 98b] for further details.
5. Implementation
In this phase, the designer will actually implement the design. Up to now,
all models were deliberately constructed in such a way as to be independent of the
implementation platform; in this phase the particular runtime environment is
taken into account. We will briefly indicate how OOHDM designs can be
implemented in the W W W by looking at one particular approach we have
followed.
15
Although OOHDM is cast in terms of OO models, it does not require an OO
implementation environment; an implementation based on an OODMBS (O2)
(but not on the web) is described in [Milet 96]; Java-based implementations are
under development.
One mapping alternative that can be used maps each class in the OO model
to be implemented onto a table, where each column stores an attribute, and each
row corresponds to an object of that class. The database key can be a distinguished
attribute, or an internal identifier can be generated.
In section 3 it was stated that the Navigation Model is a view over the
Conceptual model. The designer has the option of reflecting this organization in
the databases corresponding to each model. In other words, he may define the
database containing the Navigation objects (nodes, links, etc...) as a view, supported
by the DBMS, of the database corresponding to the Conceptual model. In the case
where the DBMS does not directly support the view mechanism, or for efficiency
reasons, the designer has the option of computing the view by hand. In this case,
he will only implement the Navigation model, since it is the one the user will be
accessing. Implementing views in the DBMS is useful when companies already
have corporate DBs, and want to use it as the basis for sites in the WWW or in
Intranets.
16
5.1.2 Implementing Contexts
To support contexts, the underlying database model or set of files must also
contain the their definitions. With the exception of arbitrary contexts (whose
specification is essentially an enumeration of its members), other types of contexts
include a query or function specification that must be evaluated to compute the
members of the context.
HTTP Server
Browser
17
More details about OOHDM Web can be found in [Pontes 97, Schwabe 98a].
6. Conclusions
We are now pursuing several lines of research, as outgrowth or
continuation of the research reported here:
development of a rich and dense set of design patterns that will allow complete
designs to be expressed almost entirely in terms of pattern compositions and
instantiations;
development of a direct manipulation language that will allow rapid
prototyping of interface specifications for HTML documents;
design and implementation of a set of tools that will constitute a development
environment based on OOHDM, for web-based applications, so that designers
are able to deal with entire sites at the more appropriate level of abstraction; a
first component in this environment is OOHDM-Web;
design and implementation of a Java-based substrate to support direct
implementation of OOHDM designs;
extension of OOHDM to incorporate user models and tasks, a security model
and definition of dynamic contexts; a first definition can be found in [Gell 98].
extension of OOHDM to support groupware, and investigation on support for
distributed group authoring using OOHDM.
Acknowldedgment: We would like to thank Natacha Gell Barroso and Patricia Vilain for their
help in preparing the example. Daniel Schwabe is partially supported by a grant from CNPq;
7. References
[Bieber95] M. Bieber; C. Kacmar, Designing Hypertext Support for Computational
Applications, Comm ACM, August 1995, pp. 99-107.
[Carneiro 94] Carneiro, L.M.F.; Coffin, M.H.; Coewan, D.D.; Lucena, C.J.P.L; ADVCharts: a
Visual Formalism for Highly Interactive Systems, in M.D. Harrison, C. Johnson,
eds, Software Engineering in Human-Computer Interaction, Cambridge University
Press, 1994.
[Gamma95] Gamma, R. Helm, R. Johnson and J. Vlissides: Design Patterns: Elements of reusable
object-oriented software, Addison Wesley, 1995.
[Gell 98] Gell B., N; User centered design of hypermedia applications, MSc thesis, Dept.
of Informatics, PUC-Rio, 1998 (in Portuguese).
[Hester 97] A.M. Hester; R.C.Borges; R. Ierusalimschy; CGILua: A Multi-Paradigmatic Tool for
Creating Dynamic WWW Pages, Proceedings of the XI Brazilian Software
Engineering Symposium (SBES97) pp.347-360, Fortaleza, Brazil, 1997 (available at
18
http://www.tecgraf.puc-rio.br/~anna/cgilua/ cgilua.ps.gz)
[Keller 97] Keller, W.; Mapping Objects to Tables A Pattern Language, Proc. Of European
Conference on Pattern Languages of Programming Conference (EuroPLOP)97,
Bushman, F. and Riehle, D.; (eds), Irsee, Germany, 1997.
(http://www.sdm.de/g/arcus/publicat/index.phtml#Mapping_Objects_To_Tables)
[Krasner 88] G. Krasner, S. Pope. A cookbook for using the model-view-controller user interface
paradigm in Smalltalk-80. Journal of Object-Oriented programming, 1(3), pp. 26-49,
August/September, 1988.
[Rossi 98 a] G. Rossi, A. Garrido and D. Schwabe: Navigating between Objects: Lessons from an
Object-Oriented Framework Perspective, to appear in ACM Computing Surveys.
[Schwabe 95b] D. Schwabe and G. Rossi:, The Object Oriented Hypermedia Design Model, Comm.
of the ACM, Vol. 38, #8, pp45-46 Aug. 1995. (available at
<http://irss.njit.edu:5080/cgi-bin/bin/option.csh?sidebars/schwabe.html>).
[Schwabe96] Schwabe, G. Rossi and S. Barbosa: Systematic Hypermedia Design with OOHDM.
Proceedings of the ACM International Conference on Hypertext (Hypertext'96),
Washington, March 1996.
[Schwabe98a] Schwabe, D.; Pontes, R.A.; Rapid Prototyping of Hypermedia Applications in the
Web, Technical Report MCC 08-98, Dept. de Informtica, PUC-Rio, 1998.
Available at ftp://ftp.inf.puc-rio.br/pub/docs/techreports/98_08_schwabe.pdf.gz
[Schwabe 98b] Schwabe, D.; Rossi, G.; An Object Oriented Approach to Web-Based Application
Design, accepted for publication, Theory and Practice of Object Systems 4 (4), J.
Wiley, 1998
[UML 97] UML Document Set. Version 1.013 January, 1997, Rational, 1997. (available at
19
http://www.rational.com/uml/references/index.html)
20