A Senario-Based Object-Oriented Methodology for Developing ... · This paper proposes an object-oriented methodology for developing hypermedia information systems. The ... zero level

A Scenario-Based Object-Oriented Methodologyfor Developing Hypermedia Information Systems

Heeseok Lee, Choongseok Lee, and Cheonsoo YooGraduate School of Management,

Korea Advanced Institute of Science and TechnologyE-mail: [email protected]

o

ysgreahtwuind

c)

n g m

a e

oo

er e

toves,].

rchive

eisgesme

ctdofnI)l)cesesesn,

gn,g.nptsign,ndgn al. ofg

they ofs inl

oftlyetptnts.

Abstract

This paper proposes an object-oriented methodolfor developing hypermedia information systems. Tmethodology consists of six phases: domain analobject modeling, view design, navigation desiimplementation design, and construction. Userequirements are analyzed with a responsibility-drivtechnology using scenarios. Object-oriented views generated as the result of object modeling, and tused for the subsequent navigation and implementadesign. The implementation design phase deals database schema, page structure and flow, and interface. This methodology is effective for integratenterprise databases with distributed hypermesystems via Internet or Intranet.

1. Introduction

Hypermedia information systems enable usersshare information through a variety of media suchtext, video, image, and voice. Hypermedia systemsbe widely used for World Wide Web (WWWapplications via Internet or Intranet [6].

Hypermedia extend the hypertext paradigm imultimedia. Hypertext is a nonsequential mannerlooking at text-based information. Even thoumanuals, books, reports, or some other documentsbe stored within a computer system in a sequenmanner, hypertext provides an interface so that number of nonsequential links may allow a useraccess an item of interest even if it is not the nsequentially-stored item. Instead of navigation amtext objects, hypermedia offer links among the whspectrum of multimedia information [26].

Hypermedia development, especially on commercial scale, often involves teams of developwho need to be managed and coordinated oveextended period of time. Formal systems developm

1060-3425/98 $10.

gyheis,

n,s’nreenionithsergia

toasan

toofhay

tialnytoxt

ngle

arsannt

and project management techniques are neededensure that the hypermedia product meets its objectiand is completed on time and within budget [14Therefore, it is not surprising to note that the reseafor hypermedia development methodologies is act(e.g. HDM [8], EORM [18], RMM [14], and OOHDM[24]).

HDM (Hypermedia Design Method) provides thfirst formal model for hypermedia applications. It based on an object-oriented technique that encourathe use of different perspectives in presenting the saconceptual entity. EORM (Enhanced ObjeRelationship Model) is the first object-orientehypermedia design methodology. EORM consists three frameworks: class framework, compositioframework, and graphical user interface (GUframework. RMM (Relationship Management Modeuses Entity-Relationship (E-R) abstractions; it enhanHDM by the use of additional access structur(conditional indexes and guided tours). RMM phasinclude E-R design, slice design, navigation desigconversion protocol design, user-interface desiruntime behavior design, and construction/testinOOHDM (Object Oriented Hypermedia DesigModel), another object-oriented methodology, adofour design phases such as conceptual desnavigation design, abstract interface design, aimplementation. A view based hypermedia desimethodology (VHDM) has been proposed by Lee et[20]. Views are used to represent users’ perceptionhypermedia requirements. VHDM facilitates explorinthe functionality of views in hypermedia applications.

Previous studies have several weaknesses. First, employ relationships among data for determinationnavigational paths. These data-oriented relationshipisolation may not reflect users’ navigationarequirements satisfactorily. Second, the integrationhypermedia with enterprise database is not sufficienemphasized, in view of its importance for Intranimplementation. Third, research in the past adoconceptual data models to capture users’ requireme

00 (C) 1998 IEEE

s

i

s

i

i

ipsSD)edws

ssN Forrex.wss

led berly,, atsUI

erheturek isndia

theatate.penk as

ntem

iaity.tossesific isryingonion

Those models may not provide the flexibility thahypermedia systems require.

To solve the above problems, this paper developscenario-based object-oriented hypermedia desmethodology (SOHDM). The paradigm of objecorientation should extend to the hypermeddevelopment environment as a whole [26]. SOHDMhas several new features. SOHDM identifierequirements for hypermedia applications from thbeginning of system development. Scenarios are uto enhance the expressive capability of modeling. particular, object-oriented views are used anavigational units as well as logical user views.

2. Methodology Architecture

SOHDM consists of six phases: domain analysobject modeling, view design, navigation designimplementation design, and construction. Thframework of SOHDM is depicted in Figure 1. Fothe purpose of clearer presentation, feedback amophases is not depicted in Figure 1. However, feedbais important for refining analysis or design outputs each phase.

Construction

Implementation Design

Domain Analysis

UI Specification PhysicalDatabase Schema

Logical DatabaseDesign

CRC

Context DiagramEvent ListScenarios

CRCCSD

OO Views

Navigational Link

Object Modeling

Navigation Design

OO ViewsOO Views

CRCCSD

Scenarios

Page Design User Interface Design

Page Schema

View Design

Figure 1. Architecture of SOHDM

In the domain analysis phase, a context diagramdrawn to represent the system boundary. In additioscenarios are employed to identify users’ requiremenThe scenarios result in an object model within thframework of Class Responsibilities Collaboratio

1060-3425/98 $10.

t

aignta

seedIns

s,,erngckn

isn,ts.en

(CRC) [30]. For better representation of relationshamong object classes, a Class Structure Diagram (Cis drawn. In the view design phase, object-orient(OO) views are extracted from CRC cards. OO vieare navigational units in the navigation design.

The navigation design phase defines AcceStructure Nodes (ASNs) and navigational links. AScontains the access structure and path to OO views.the sake of convenience, navigational links apresented in the form of a navigational link matriImplementation design phase defines users’ windo(e.g., a set of HTML pages) and navigational flowfrom one page to another page. In addition, detaiuser interfaces (UIs) are designed. OO views maytransformed into relational database schema. Cleadatabase independence is guaranteed [4]. Finallyhypermedia information system is built which depicthe resulting physical database schema and specifications.

3. Methodology Details

Here we explain each phase of SOHDM in furthdetails, by using a real-life application system. Tapplication has operated on a client/server architecfor one of the largest banks in South Korea. The bancurrently interested in an Intranet infrastructure, athus SOHDM is applied for building a hypermedsystem for this application.

3.1 Domain Analysis

First, a system scope diagram is drawn to delimit hypermedia system to be developed. A well known dflow diagram (DFD) [31] is used. Typically, a contexdiagram (e.g., zero level DFD) is a good alternativFor our IS (Bank Account System), the system scodiagram is drawn as shown in Figure 2. The baaccounting system has three external entities, suchmanagement, customer, and branch.

Events are identified for each external entity. Aevent is defined as the trigger which starts the sys[15]. Four events are found, as shown in Table 1.

SOHDM uses scenarios to identify hypermedapplications requirements from the earliest opportunScenario activity charts (SACs) are developed describe scenarios. SAC describes business proceaccording to actors. An actor is an operator of specactivities, i.e., a creator of events. Notation of SACsgiven in Figure 3. External entities are the primacandidates for actors in SACs. An event is a startpoint, a trigger of a scenario. An activity is an operatiby which an actor completes a scenario. An alternat

00 (C) 1998 IEEE

thf

o itht.

d

.fey

)r,

n.fs

is an activity which enables for an actor to choose next activity. An activity flow is a sequence oactivities. Termination is the end of a scenario.

Customer

CustomerInformation

Bank AccountingSystem

CustomerId.

Account No.

Account Information

Branch Name

Branch Information

Management

Branch

Figure 2. System Scope Diagram

Table 1. Event ListEvent NameSource Entity

Identify Banking Product Type

Check AccountCustomer

Request Customer InformationBranch

Request Total Information*

Management Request Total Information*

* The Same Event

Event Activity

Activity Flow

Alternation

Termination

Figure 3. Notation of SAC

Actor/System SAC Details

Customer

System

RequestAccount No

and Password

Check Account

No

InputAccount No.

and Password

BalanceInformation

Yes

ShowTransaction

ValidatePassword

TransactionInformation

Yes

No

Figure 4. “Check Account” Scenario

RequestCustomer

Information

CategorizeRequest

RequestCustomer

Type CurrentCustomer

ProspectiveCustomer

Refer toProspective

Customer Data

SelectSearchType

Search Customer Id

CustomerList

ConditionalSearch


Management

System

ProduceInformation

ReportRequest

Trace List

Yes

RequestId

RequestCondition

ContinueNo

CategorizeCurrent

CustomerSearch

Input Id

Trace List

Input Condition

Figure 5. “Request Customer Information” Scenario

Four SACs are generated from the four events. Fthe sake of simplicity, three scenarios are illustratedFigures 4, 5, and 6. For example, Figure 5 depicts SAC for “Request Customer Information” evenCustomers are grouped into two categories, such

1060-3425/98 $10.0

e

rne

as

current customers and prospective customers, ancustomer information is provided for each category.

ReportTotal

Calculate Branch Total

CalculateTotal per

Account Type


Management/Branch

System

RequestTotal

Information

BranchTotal

Total perAccount Type

RequestInformation

Type

CategorizeRequest

Figure 6. “Request Total Information” Scenario

3.2 Object Modeling

Scenarios in SACs are used for object modelingScenarios are transformed into objects in the form oCRC cards. The CRC cards are adopted because thhave attractive informal appeal that helps makecomplex modeling tractable. Objects are generatedfrom scenarios as follows.

First, actors are primary candidates for objects; thenactivities are considered. Scenarios (Figure 4,5, and 6generate object candidates such as current customeprospective customer, account, branch, and transactioIn particular, another object, customer, a superset ocurrent customer and prospective customer object, iobtained.

Class : Customer Superclass :

Subclass : Current_Customer Prospective_Customer

Responsibilities : Know_Credit Know_Customer_Information

Collaborators:

Components :

Attributes : Customer_Id Customer_Name Customer_Address Customer_Phone Customer_Credit

Associators:

Class : Branch Superclass :

Subclass :

Responsibilities : Check_Account_Type_Total Check_Current_Customer Check_Prospective_Customer Know_Branch_Total

Collaborators: Account Current_Customer Prospective_Customer

Components :

Attributes : Branch_Code Branch_Name Branch_Address Branch_Phone

Associators: Account (N) Current_Customer (N) Prospective_Customer (N) Transaction (N)

Class : Transaction Superclass :

Subclass :

Responsibilities : Know_Transaction

Collaborators:

Components :

Attributes : Transaction_Code Transaction_Date Transaction_Type Transaction_Amount

Associators: Account (1) Branch (1)

Class : Prospective_Customer Superclass : Customer

Subclass :

Responsibilities : Know_Meeting_Memo

Collaborators:

Components :

Attributes : Meeting_Memo

Associators: Branch (1)

Class : Account Superclass :

Subclass :

Responsibilities : Check_Transacton Know_Balance

Collaborators: Transaction

Components :

Attributes : Account_No Account_Balance Account_Register_Date Account_Type

Associators: Branch (1) Current_Customer (1) Transaction (N)

Class : Current_Customer Superclass : Customer

Subclass :

Responsibilities : Check_Account_Balance Check_Account_Transaction Know_Current_Customer

Collaborators: Account Transaction

Components :

Attributes : Current_Customer_Initial_Date

Associators: Account (N) Branch (N)

Figure 7. CRC Cards

0 (C) 1998 IEEE

tedl.’san isfie

en C

iter. an a

Cao

fanonp

ntse

esdianab

r

t

a

Next, objects identified are documented in formatindex cards, CRC cards. Here, Wirfs-Borck et aoriginal CRCs are extended to include attribute lists associators. In addition, cardinality of associationdepicted in a bracket. The cards may be specirepeatedly for refinement. Six object classes (CustomCurrent_Customer, Prospective_Customer, AccouBranch, and Transaction) are modeled as shownFigure 7. For example, in the Current_Customer CRit is noted that its superclass is Customer andsubclass does not exist. Current_Customer class inhattributes and responsibilities from Customer classhas Current_Customer_Initial_Date as an attribute Check_Account_Balance and Check_Transactionresponsibilities.

Four types of relationships are depicted in CR(superclass/subclass, collaborators, components, associators). To present these relationships meffectively, a CSD shown in Figure 8 is prepared.

Account

Branch

Branch_Code...

Check_Account_Type_TotalCheck_Prospective_Customer

Check_Current_Customer

Prospective_Customer

Meeting_Memo..

Know_Meeting_Memo

Account_No....

Know_BalanceCheck_Transaction

Transaction

Transaction_Code...

Know_Transaction

Collaboration Relationship

Association Relationship 1:1

N:N1:N

Superclass/Subclass Relationship

Customer

Customer_Id...

Know_Credit

Current_Customer

Current_Customer_Initial_Date..

Check_Account_BalanceKnow_Current_Customer

Figure 8. Class Structure Diagram

3.3 View Design

In the view design phase, objects are reorganizednavigational units. A navigational unit represents OO view. The use of views in hypermedia applicatidesign has several advantages. First, views can supa number of users who have different requiremeSecond, cognitive overhead can be effectively reducbecause heterogeneous attributes and responsibilitiobjects are grouped into views. Third, hypermeapplications are easily extendable, since additiorequirements of presentation or navigation can accommodated.

1060-3425/98 $10.0

d

dr,t,in,sitsItds

sndre

or

ort.

d, of

le

We can extract OO views on the basis ofresponsibilities and attributes in CRC cards as well astheir relationship in CSD. OO views are categorizedinto three types: base view, association view, andcollaboration view. A base view is generated from asingle object class. An association view is extractedfrom an association relationship. Similarly, acollaboration view is generated from a collaborationrelationship.

Account

Account_No...


Account

Account_No...


i) Base View

Current_Customer

Current_Customer_Id..

Check_Account_BalanceCheck_Account_Transaction

Know_Credit

Current_Customer_View

Current_Customer_Id...

Check_Account_BalanceCheck_Account_Transaction

Know_Credit

iii) Collaboration View

Branch

Branch_Code...

Check_Prospective_CustomerCheck_Account_Type_Total

Check_Bank_Total

Branch_Account_View

Branch_Code..

Account_No..

Check_Prospective_CustomerCheck_Account_Type_Tota

....Check_Transaction

Transaction

Transaction_Code...

Know_Transaction

Account_Transaction_View

Account_No...

Transaction_Code..

Know_Balance....

Know_Transaction

ii) Association View

Branch_Prospective_Customer_View

Branch_Code..

Prospective_Customer_Id..


....Know_Customer_Information

Branch

Branch_Code...


Check_Bank_Total


Prospective_Customer_Id...

Know_CreditKnow_Meeting_Memo

Know_Customer_Information

Figure 9. Generating Object Oriented Views

In Figure 9, the Current_Customer_View, a baseview, is a subset of attributes and responsibilities in theCurrent_Customer class. Branch_Prospective_Customer_View, an association view, uses attributesand responsibilities in Branch class andProspective_Customer class. The origin ofresponsibilities for association views differs from thatfor collaboration views. In an association view, theresponsibilities related with attributes are extracted.However, in case of a collaboration view, theresponsibilities required for collaboration are ofimportance.

3.4 Navigation Design

The navigation design phase deals with the mannein which users gather and use information on the basisof scenarios. In well-designed hypermedia applications,the way users explore the hypermedia is an importandesign issue, in order to avoid redundant informationand prevent them from getting lost in the hyperspace[24]. Past studies base the navigation design on datmodels in isolation. However, we suggest that the use

0 (C) 1998 IEEE

th

ur iikrtsseia

triarntynyebe

n”eS

eSNr”

SssuawarN

t

y

e

of scenario as well as data model should improve quality of the navigation design.

In navigation design, OO view and access structnode (ASN) are adopted for navigational units. ASNused to implement the grouping, which is a menu-lmechanism that enables users to access other pahypermedia documents in RMM [14]. ASN provideusers the access structures which users can usnavigate to different or detailed part of hypermedapplication.

ProspectiveCustomer ASN

Customer ASN

Search Customerwith Id ASN

List Customer ASN

CurrentCustomer ASN



Branch_Account_View

Search Customerwith Condition ASN

Account ASN


Transaction ASN

Branch Account ASN

Account_View

Current_Customer_Account_Transaction

_View

Figure 10. Navigational Link

The first step in the navigation design phase isdetermine ASNs by using scenarios. In a scenaactivity flows that start from the system to the actor the primary concern for determining ASN. Aalternation or activity includes two types of activiflows such as activity inflow and activity outflow. Aactivity inflow may become an ASN. An activitoutflow from an activity may be input fields of thASN, and activity outflows from an alternation may the menu of the ASN.

For example, in “Request Customer Informatioscenario (Figure 5), the activity flow from “CategorizRequest” to “Request Customer Type” may be an Aentitled “Customer.” The activity outflows from“Request Customer Type,” such as “Current Customand “Prospective Customer” may be menus of the A“Customer” ASN has two menus, “Current Customeand “Prospective Customer.”

Next, navigational links are built. In SOHDM, OOviews and ASNs are navigational units. The ANdiffers from OO view in that ASN contains only accepaths to OO views, but OO view contains the actinformation that users want to obtain. These OO vieand ASNs correspond to nodes. HTML pages implemented on the basis of these OO views and AS

1060-3425/98 $10.0

e

ese of

to

oo,e

N

r”.

lses

in the subsequent implementation design. A linkdenotes the relationship between source and targenode. This source and target node may be OO view orASN.

From scenarios in Figures 4, 5, and 6, eight ASNsare found and then navigational links are determined, asshown in Figure 10.

Figure 10 shows that the navigational units arecategorized into three separate groups, as indicated bdotted lines. Each group is separated from othersbecause it has no related information, i.e., does not havany navigational link that leads to other groups. For thesake of convenience, links may be summarized in aform of a navigational link matrix. This matrix is shownin Figure 11.

If the navigational unit in the first column is source, and the navigational unit in the first row is target.

If the navigational unit in the first row is source, and the navigational unit in the first column is target.

If the navigational unit in the first column and the navigational unit in the first row are bi-directional.

Customer ASN

CurrentCustomer

ASN

Search Customer

with Id ASN

List Customer

ASN

Search Customer

with ConditionASN

ProspectiveCustomer

ASN

Current_Customer_

View

Branch_Prospective_Customer_

View

ProspectiveCustomer ASN

Customer ASN

Search Customerwith Id ASN

List Customer ASN

Search Customer with Condition ASN

CurrentCustomer ASN



Current_Customer_Account_

Transaction_View

Current_Customer_Account_Transaction_

View

Navigational Unit

Navigational Unit

Figure 11. Navigational Link Matrix

3.5 Implementation Design

The implementation design phase generates pagestructure, page flow, user interface, and logicaldatabase schema for construction in a particulardevelopment environment. Hypermedia application canbe developed under a variety of system environments,including different DBMSs, and development toolssuch as CGI, HTML, Java [10], or Shockwaves.However, it is noted that our implementation designphase is independent of different environments.

First, the HTML page schema is designed by theorganization of OO views, ASNs, and descriptiondetails (text, image, sound, etc.). Figure 13 shows anexample of the page schema. For example, the page“Current_Customer_001” entitled “Current_Customer” is based on two views, Current_ Customer_View and Account_Transaction_View. It has twoanchors that lead to “Main_001” and “Prospective_Customer_001” pages.

Page schema in Figure 12 is enhanced to UIspecifications by the use of UI components. Figure 13summarizes the notation for UI components. A captionis a text displayed in a component. An action is an

0 (C) 1998 IEEE

hl

res orst.ns

r

l notfefuljectesa

nd,ne

interactive procedure. An action is executed whencomponent is clicked. Items are a set of data includeda component. The key-based transition refers to tcurrent state of the components, while the simptransition does not.

yAnchor Current Customer / Current_Customer_001 Prospective Customer / Prospective_Customer_001 Management Information / MIS_001

PID :Main_001 Title : Main Menu

yViews

y Description Description of Main Menu

y Other Component Logo

yAnchor Main Menu / Main_001

PID : MIS_001 Title : Management Information

yViews Branch_Account_View

y Description Description of Management Information


y Anchor Main Menu / Main_001 Prospective Customer / Prospective_Customer_001

PID : Current_Customer_001 Title : Current Customer

yViews Current_Customer_View Account_Transaction_View

y Description Description of Current Customer, and Help Message.


y Anchor Main Menu / Main_001 Current Customer / Current_Customer_001

PID : Prospective_Customer_001 Title : Prospective Customer

yViews Branch_Prospective_Customer_View

y Description Description of Prospective Customer, and Help Message.


Figure 12. Page Schema

B : caption

actionButton

Image:event:

actionImage

L : caption

items &actionListC : caption

items &actionChoice

F : caption

items &actionSearch Input Text

S : caption

actionSlide bar

Desc : caption

items &actionOthers caption/targetHTML Anchor

Components

Transitions

(a) Key-based (b) Simple

Figure 13. Notation of User Interface Component

1060-3425/98 $10.0

a inee

Current Customer

Customer Attributes

C: Cust_ID

cust_id : matched item

B : Search with Key

Show

F : Key

Cust_ID : matched

C : Key

Cust_ID : matched

B : Cust List

Show

B : Special Cust

Show

B : Search with con

Show

F : Credit

Cust_Credit : matched

F : Asset

Cust_asset : matched

Cust_ID Cust_Name Cust_JobCust_Title Cust_Pdate Cust_BdateCust_Phone Cust_Addr Cust_Zip

B : Asset

Asset Window

B : Transaction

Transaction Window

B : Credit

Credit Window

•Main Menu•Prospective Customer

Asset Status

Cust_ID, Real Estate, Contents, Evaluation Year

Transaction

Account_No, Transaction_Code, Date, Transaction_Amount

Credit

Cust_Id, Credit, Evaluation_year

Figure 14. User Interface Design Specification

ASNs determine the UI components. ASNs atransformed into HTML pages or anchors. Direct linkcorrespond to buttons or images. Index, direct query,indexed query is transformed into a choice or a liGuided tour is transformed into a slide bar or buttowith “Next” or “Previous.” Figure 14 shows theresulting UI specifications for the “Current_Custome_001” page schema.

Next, object model is transformed to logicadatabase schema. Note that the transformation maybe necessary if OODBMS is used. In many real-licases, however, relational DBMS are the most usesystems. Here, designers need rules that map obmodel into relational schema. The transformation rulcan be found in [3] or [5]. We adapt Blaha’s rule. Blahsuggests three rules, as follows:

Branch

Branch_CodeBranch_Name

.

.

Check_Account_Type_TotalCheck_Bank_Total

Check_Prospective_Customer


Meeting_Memo...

Know_Meeting_Memo

Branch (Branch_Code, Branch_Name, ...)

Prospective_Customer(Pros_Cust_Id, Meeting_Memo, … , Pros_Cust_Branch_Code)

Branch_Prospective_Customer_View (Branch_Code, Branch_Name, , Pros_Cust_Id, Pros_Cust_Name, Meeting_Memo, ...)

Figure 15. A Collaboration Relationship Transformation

First, each class maps directly to one table. Secoa generalization relationship is transformed into o

0 (C) 1998 IEEE

irdnepe. Inuleurisip.is

es

t in

he tcasia diaa.

ner

n

e

s

.n

superclass table and multiple subclass tables. Thmany-to-many relationships map to distinct tables. Oto-one and one-to-many relationships may be mapto distinct tables or merged with a participating classaddition to these four rules, another transformation ris considered for collaboration relationships of oCRCs. An additional view or stored procedure required in case of the collaboration relationshCollaboration relationship transformation to view depicted in Figure 15.

Transforming CRCs in Figure 7 results in ten tablas shown in Table 2.

Table 2. Relational Table


Branch

Table Name

Current_Customer


Branch_Account_View


Customer

Account

Transaction

Cust_Id , Meeting_Memo,Branch_Code

Branch_Code , Branch_Name , Branch_Address

Acct_No , Acct_Type , Acct_Reg_Date , Acct_Balance ,Cur_Cust_Id , Branch_Code

Tran_Code , Tran_Date , Tran_Type , Tran_Amount , Acct_No , Branch_Code ,

Attribute Name

Cust_Id , Cur_Cust_Init_Date

Branch_Name , Branch_Code , Cust_Id , Pro_Cust_Name, Meeting_Memo

Branch_Name ,Branch_Code ,Acct_No , Acct_Type , Acct_Balance

Acct_No , Tran_Code , Tran_type , Tran_Amount

Cust_Id , Cust_Name, Cust_Addr , Cust_Credit

Type

Table

Table

Table

View

View

View

Table

Table

Table

Current_Customer_View Cust_Id , Cust_Name, Cust_Addr , Cust_Credit, Cur_Cust_Init_DateView

3.6 Construction

In the construction phase, developers implemenphysically running hypermedia application system target environments. All of the products during timplementation design phase should be mappedphysical elements, as shown in Figure 16. A logidatabase schema generated in implementation dephase is transformed into physical database schemtarget DBMS. User interfaces in running hypermeare implemented by the use of user interface schem

Logical DBSchema Design

User InterfaceDesign

Target System

Physical DB Schema

UI Specification

EnterpriseDatabase

---------- ---

---------- --------

----- ---

---------- ---

HTMLDocuments

Gatew

ay

Figure 16. Construction Process of SOHDM

1060-3425/98 $10.0

,-d

,

a

olgnon

4. Prototype

A prototype is built by the use of Oracle RDMBS,Java, and HTML for the Bank Accounting System. Theprototype has a TCP/IP LAN based client/serverconfiguration as shown in Figure 17. Oracle CallInterface (OCI) is used as an interface gateway betweeJava and Oracle. The system is based on three-tiarchitecture, the first-tier for WWW clients, the secondfor the web server in Windows NT, and the third forOracle database in UNIX.

WWWClientTCP/IP Network

Oracle

Windows NT

HTTPD

Java-OracleGateway

HTML Document Java

Web Server Database Server

UNIX

Figure 17. Target Hypermedia System Architecture

Figure 18 is the main menu screen. From the maimenu icon (left side in Figure 18), “CustomerInformation System,” one can navigate amongsubmenus like “Current Customer,” “ProspectiveCustomer,” “MIS,” and “Service & Products.” Themain menu refers to Main_001 page schema in Figur12.

Figure 19 is the HTML page for current customers.This page is implemented for the Figure 20 showsresults from retrieving prospective customerinformation. Prospective customers to be interviewedare listed for each branch. This page screen iimplemented for “Prospective_Customer _001” pageschema. Clicking the “Branch” button and thenselecting the branch name provides a new windowProspective customers in the branch selected are showin this window.

Figure 18. Main Menu Screen

0 (C) 1998 IEEE

”is

ers,

as

ton

Figure 19. Current Customer Page Screen

Figure 20. Prospective Customer Page Screen

1060-3425/98 $10.0

Clicking the “MIS” anchor in the left side ofprospective customer page screen results in the “MISpage screen as shown in Figure 21. This page implemented as “MIS_001” schema. It shows thdeposit amounts (today and yesterday) by headquarteor branches.

Figure 21. Customer MIS Page Screen

“Current_ Customer_001” page schema. It has scrolled text field which highlights the current page, awell as four buttons -“Search with Id,” “Search withList,” “Special Customer,” and “Conditional Search.”The buttons act as anchors which lead users embedded applications. If the “Search with Id” buttois clicked, then the “Customer Search with Id”

Table 3. Comparison of Hypermedia Design Methodologies MethodologyCriteria

Phases

Source of Navigation

Approach to IdentifyingUsers’ View

Semantic Richness

Key Modeling Technique

Documentation

RMM(Isakowitz et al. 1995)

1. E-R Design2. Slice Design3. Navigational Design4. Conversion Protocol Design5. UI Screen Design6. Run-time Behavior Design7. Construction

E-R Relationship

None

Relatively Poor

E-R

E-R DiagramSlice DiagramRMDM Diagram

SOHDM

1. Domain Analysis2. OO Modeling3. View Design4. Navigational Design5. Implementation Design6. Construction

EORM(Langel. 1993)

1. Class Framework2. Composition Framework3. GUI Framework

OO Relationship

None

Relatively Rich

OO

OOHDM(Schwabe et al. 1995)

1. Conceptual Design2. Navigational Design3. Abstract Interface Design4. Implementation

OO Relationship

View

Relatively Rich

OO

Class StructureGUI Design

OMT’s OO Model Navigational Class Abstract Interface Design Model

VHDM(Lee et al. 1995)

1. Requirement Analysis2. E-R Design3. View Design4. Navigational Design5. Mapping6. Implementation

E-R Relationship

View

Relatively Poor

E-R

E-R SchemaView SchemaNavigational Schema.

System Scope DiagramEvent ListScenario SetsCRC CardClass Structure DiagramOO ViewNavigation Link SchemaPage SchemaUI Specification

Scenario and OO Views

Scenario and OO Views

Relatively Rich

CRC CardsScenarios

0 (C) 1998 IEEE

ns

sla

se

d

Mg-et

ca

cnoatd

h

dl

ec

lysis

ng

hr,gsn

xtn.

E. an,

s,

ipD2.s,

i,ont

Aion,

i,s”,al70-

ges

er,

-

an,gsn

application is initiated. This application has aadditional input field for search with customer Id. It hathree buttons, “Asset,” “Transaction,” and “Credit” foradditional information on the related customers.

5. Methodology Comparison

We compare features of SOHDM with those of fouother major hypermedia design methodologies. Thcomparison is summarized in Table 3.

RMM and VHDM are based on E-R model and thurelatively simple to use. In contrast, SOHDM, as weas EORM and OOHDM adopt OO technologies to dewith rich semantics. Accommodating semantics maimprove user satisfaction even with the price of analyscomplexity.

In SOHDM, scenarios and CRCs are used foanalyzing and modeling users’ requirementSpecifying scenarios helps to capture ensure systflexibility from the earliest phase in the developmenprocess. In addition, the structure of CRC carpromotes a behavioral approach to object modelinThe CRC card has an attractive informal appeal thhelps make the emerging design tractable. SOHDemploys scenarios and OO views for findinnavigational units. Concentrating on responsibilitydriven scenarios and OO views is likely to capturnavigational requirements better than static daentities.

6. Conclusions

This paper develops a scenario-based objeoriented methodology for developing hypermediapplications. To our best knowledge, our methodologis the first to use scenarios to capture hypermednavigational requirements that are not shown in darelationship. The scenarios are transformed into objeoriented views. These views are used for designihypermedia pages with navigational links. The use scenarios is likely to improve the quality of hypermedidesign to ensure flexibility from the earliesopportunity. The use of scenario as well as data moimprove the quality of the navigation design.

The methodology is effective for integrating WWWhypermedia system with enterprise databases. prototype is built to demonstrate the usefulness of tmethodology.

The following research areas are further exploreFirst, a system for linking design phases in a flexibfashion is highly valued. It may reduce design timeSecond, security and authority problems can be solvbecause Intranet hypermedia systems contain critibusiness applications and data. Third, a reposito

1060-3425/98 $10.0

ris

ll

yis

r.mt

g.at

a

t-

yiatat-gf

el

Ae

.e.d

alry

system may be useful to maintain and reuse the anaand design outputs.

Acknowledgments

This research was partially supported by WaComputer Korea Ltd. Research Grant GI90020.

References

[1] P. Balasubramanian, T. Isakowitz, and E. A. Sto“Designing hypermedia applications”, Proceedinof the 28th Hawaii International Conference oSystem Sciences, 1994, pp.354-365.

[2] M. Bieber, and C. Kacmar, “Designing hypertesupport for computational applications”, CommuACM, Vo.38, No.8, August 1995, pp.99-107.

[3] M. R. Blaha, W. J. Premerlani, and J. Rumbaugh, “Relational database design usingobject-oriented methodology”, Commun. ACMVol.31, No.4, April 1988, pp.414-427.

[4] C. J. Date, An introduction to database system6th edition, Addison-Wesley, 1995

[5] J. Fong, “Mapping extended entity relationshmodel to object modeling technique”, SIGMORecord, Vol.24, No.3, September 1995, pp.18-2

[6] M. Frank, “Shifting gears”, Internet SystemVol.1, 1996, pp.6-47.

[7] F. Garzotto, L. Mainetti, and P. Paolin“Hypermedia design, analysis, and evaluatiissues”, Commun. ACM, Vol.38, No.8, Augus1995, pp.74-86.

[8] F. Garzotto, P. Paolini, and D. Schwabe, “HDM:model-based approach to hypertext applicatdesign”, ACM Trans. Off. Info. Syst., Vol.11No.1, January 1993, pp.1-26.

[9] F. Garzotto, P. Paolini, and L. Mainett“Navigational patterns in hypermedia databaseProceedings of the 26th Hawaii InternationConference on System Sciences, 1993, pp.3379.

[10] J. Gosling, and H. McGilton, The Java LanguaEnvironment, White Paper, Sun MicrosystemComputer Company, October 1995.

[11] F. G. Halasz, and M. Schwartz, “The Dexthypertext reference model”, Commun. ACMVol.37, No.2, February 1994, pp.30-39.

[12] A. T. F. Hutt, Object Analysis and Design Description of Methods, A Wiley-QEDPublication, John Wiley & Sons, Inc., 1994.

[13] T. Isakowitz, E. A. Stohr, and P. Balasubramani“Designing hypermedia applications”, Proceedinof the 27th Hawaii International Conference oSystem Sciences, 1994, pp.354-365.

0 (C) 1998 IEEE

,

f

-

,

,

r,ice

is,

[14] T. Isakowitz, E. A. Stohr, and P. Balasubramanian“RMM: A methodology for structured hypermediadesign”, Commun. ACM, Vol.38, No.8, August1995, pp.34-44.

[15] I. Jacobson, Object-Oriented Software Engineering- A Use Case Driven Approach, Addison-Wesley,1995.

[16] W. Kim, Modern Database Systems - The ObjectModel, Interoperability, and Beyond, AddisonWesley, 1995.

[17] D. B. Lange, “An object-oriented design methodfor hypermedia information systems”, Proceedingsof the 27th Hawaii International Conference onSystem Sciences, Maui, Hawaii, Vol.3, 1994,pp.336-375.

[18] D. B. Lange, “Enhanced relationships in object-oriented database modeling”, Proceedings oInfoScience ’93, Seoul, Korea, 1993, pp.296-304.

[19] D. B. Lange, “Object-oriented hypermodeling ofhypermedia supported information systems”,Proceedings of the 26th Hawaii InternationalConference on System Sciences, 1993, pp.380389.

[20] H. Lee, J. Kim, Y-G Kim, and S. H. Cho, “Viewbased methodology for hypermedia applications”,Journal of Database Management (Forthcoming).

[21] ORACLE Co., Oracle 7 Server SQL Reference,Release 7.2, Oracle Corporation, April 1995.

[22] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy,and W. Lorensen, Object Oriented Modeling andDesign, Prentice Hall, New York, 1991.

[23] D. Schwabe, and G. Rossi, “Building hypermediaapplications as navigational views of informationmodels”, Proceedings of the 28th HawaiiInternational Conference on System Sciences1995, pp.231-240.

[24] D. Schwabe, and G. Rossi, “The object-orientedhypermedia design model”, Commun. ACM, Vol.38, No. 8, August 1995, pp.45-46.

[25] D. Schwabe, G. Rossi, and S. D. J. Barbosa“Abstraction, composition, and layout definitionmechanisms in OOHDM”, Electronic Proceedingsof the ACM Workshop on Effective Abstractionsin Multimedia, Sanfrancisco, California, 4November 1995.

[26] A. Simon, Strategic Database Technology, MorganKumfmann Publishers, Inc., 1995.

[27] D. A. Taylor, Business Engineering with ObjectTechnology, John Wiley & Sons, Inc., 1995.

[29] M. Thuring, J. Hannemann, and J. M. Haake,“Hypermedia and cognition: designing forcomprehension”, Commun. ACM, Vol.38, No.8,August 1995, pp.57-66.

1060-3425/98 $10.00

[30] R. Wirfs-Brock, B. Wilkerson, L. And WieneDesigning Object-Oriented Software, PrentHall, Englewood Cliffs, NJ, 1990.

[31] E. Yourdon, Modern Structured AnalysPrentice-Hall, 1989.

(C) 1998 IEEE