Architectural Design Document

Architectural
Design
Document
This is the Architectural Design Document of the project, ‘Personalized
Semantic Web service for Classifieds’ (PSWSC). In this document we briefly
described the layering strategies used and justifications, proposed Group No:15
technologies and their relevant proof of concepts.
2
Table of contents,
1. Introduction
1.1 Aim
1.2 People
1.3 System overview
1.3.1 Project outline
1.3.2 Project purpose
2. Architectural Goals and Constraints
2.1 The Incremental lifecycle model
2.2 List of the builds
3 Architectural Builds
3.1Implementing the ontology tree
3.1.1 Goals of Build 1
3.1.2 Ontology Tree
3.1.3 Protégé
3.1.3.1 Description Logic Reasoners
3.1.4 OWL
3.1.5 Ontology Development Process
3.1.5.1 Determine scope
3.1.5.2 Consider reuse
3.1.5.3 Enumerate Important terms
3.1.5.4 Define Classes and the Class Hierarchy
3.1.5.5 Define Properties of Classes – Slots
3.1.5.6 Define constraints
3.1.5.7 Create instances
3.2 implementing the searching mechanism
3.2.1 Rules
3.2.2 SWRL
3.2.3 SWRL Rule Engine Bridge
Copyright@2009bySemanticClassifiedsGroup
3
3.3 Making the User Interface according to the requirements listed in the SRS
3.3.1 Login
3.3.2 Advertise Your Ad
3.3.3 Register
3.3.4 Search
3.3.5 Send a Message
3.3.6 Email Ad
3.3.7 Report Generation
3.3.8 Administrator
3.4 Making the web based front end and back end for the PSWSC system
3.4.1 Adobe® Flex® Builder™
3.4.2 Frontend
3.4.2.1 Creating Pages
3.4.2.2 Building Ads
3.4.2.3 RSS feed
3.4.2.4 Forms
3.4.3 Backend
3.4.3.1 XML
4
1 Introduction
1.1 Aim
The Architectural Design Document (ADD) aims to create a modular decomposition of the
project Personalized Semantic Web Service for Classifieds that is being developed.
1.2 people
Supervisor:
Name Email address

Dr. Prasad Wimalarathna. spw@ucsc.cmb.ac.lk
Group Members:
Name Reg.No Index No

J.K.P.S. Chathurika 2007 cs 016 07000162
T.R. Kodikara 2007 cs 062 07000626
M.L.D. Prasad 2007 cs 093 07000936
R.G.S. Saranga 2007 cs 115 07001152
K. Wijewardena 2007 cs 139 07001398
1.3 System Overview

1.3.1 Project outline
Our project presents a scalable framework for personalized, ontology-based, semantic web
service discovery for classified domain by enhancing the current search mechanism with
semantic web technologies.
We provides user to advertise his vehicle ads in our system. Then anyone can search the
application with few keywords and can choose a vehicle he desire easily.
This system also has increased functionality to allow for future expansion. System will
bridge vehicle buyers and sellers although they are in several places in the world.
1.3.2 Project purpose

Normally a normal search on a classified web application the user faces more difficulties
when searching his needs. When the user searches a vehicle using few keywords the system
gives list of data (with lot of user unwanted data). Then the user has to find the
advertisement that suit to him one by one. In here user gets a lot of troubles to find the
actual vehicle that he wants.
5
When searching, if the search gives only the data that the user probably wants, it’s a huge
opportunity to the user to find his needs easy and without wasting any time.
2 Architectural Goals and Constraints
This project intends to use a Three Tier Architecture Model as the overall system
architectural model. This model was chosen due to its features of scalability, reusability,
maintainability as well as edibility. Adhering to this model the system will be divided into
three tiers.
Top Tier
User Interface
Web Server Middle Tier
Database/XML Bottom Tier
 Top most tier involving System User Interface.

 Middle tier, the Web Server, handling request processing from the top most tier and
responding with the required information from the bottom tier, handling also
authentications and validations and computation and analysis.
 Bottom tier acting as a store of data.
2.1 The Incremental lifecycle model

The Incremental Model of development is used as the Software Life Cycle model in
developing the product ‘Personalized Semantic Web Service for Classifieds’. The product
will be designed, implemented, integrated, and tested as a series of incremental builds,
where a build consists of code pieces from various modules interacting together to provide
a specific operational capability.
The incremental model was chosen due to the fact that the ‘Personalized Semantic Web
Service for Classifieds’ project could be easily broken into several parts which can be done
independently of each other. The separate design, implementation and testing will allow
Team PSWSC to utilize the available resources most efficiently. By using this model, an
6
operational quality product maybe delivered, at the completion of each build. The gradual
construction of the product will allow the team to add new features later on without having
to worry about the parts already done. Finally it will make maintenance of the product
much easier. Since the various features of the system, have been implemented in builds,
narrowing down the area of a fault or upgrade is much more manageable.
2.2 List of the builds

The PSWSC project will be separated into four builds. The builds were decided by analyzing
the overall system structure, the priority of the requirements and their dependencies. Lists
of the four builds are shown below.
 Build one:
Implementing the ontology tree
 Build two:
Implementing the searching mechanism
 Build three:
Making the User Interface according to the requirements listed in the SRS
 Build four:
Making the web based front end and back end for the PSWSC system
2.3 Builds Interaction
The interactions of the four builds are shown in Figure 1.
7
Requirements Specification Architectural Design
Detailed Implementation Testing

Design & Integration



Complete Application
Figure 1
3 Architectural Builds
8
3.1 Implementing the ontology tree
3.1.1 Goals of Build 1
The goal of this build is to create an Ontology Tree that will support the proposed system.
3.1.2 Ontology Tree
Ontology is a formal representation of a set of concepts within a domain and the relationships
between those concepts. It is used to reason about the properties of that domain, and may be
used to define the domain.
In theory, ontology is a "formal, explicit specification of a shared conceptualization". Ontology

provides a shared vocabulary, which can be used to model a domain — that is, the type of
objects and/or concepts that exist, and their properties and relations.
Ontologies are now central to many applications such as scientific knowledge portals,
information management and integration systems, electronic commerce, and semantic web
services.
3.1.3 Protégé
We use Protégé (Protégé 3.4.1) when developing the Ontology.
Protégé is a free, open-source platform that provides a growing user community with a suite of
tools to construct domain models and knowledge-based applications with Ontologies. At its
core, Protégé implements a rich set of knowledge-modeling structures and actions that support
the creation, visualization, and manipulation of Ontologies in various representation formats.
Protégé can be customized to provide domain-friendly support for creating knowledge models
and entering data. Further, Protégé can be extended by way of a plug-in architecture and a
Java-based Application Programming Interface (API) for building knowledge-based tools and
applications.
9
Figure 2
The Protégé platform supports two main ways of modeling Ontologies:
 The Protégé-Frames editor
 The Protégé-OWL editor
The Protégé-OWL editor enables users to build Ontologies for the Semantic Web, in particular
in the W3C's Web Ontology Language (OWL). So we use The Protégé-OWL editor to build our
Ontology.
3.1.3.1 Description Logic Reasoners
In addition to providing an API that facilitates programmatic exploration and editing of OWL
Ontologies, Protégé-OWL features a reasoning API, which can be used to access an external DIG
compliant reasoner, thereby enabling inferences to be made about classes and individuals in an
ontology.
OWL-DL has its foundations in Description Logics, which are decidable fragments of First Order
Logic. For a particular task, a logic is decidable if it is possible to design an algorithm that will
10
terminate in a finite number of steps (i.e., the algorithm is guaranteed not to run forever). For
example, in Description Logic it is possible to write an algorithm that calculates whether or not
one concept is a subclass of another concept, which is guaranteed to terminate after a finite
number of steps. Because OWL-DL ontology can be translated into a Description Logic
representation, it is possible to perform automated reasoning over the ontology using a
Description Logic reasoner. A Description Logic reasoner performs various inferencing services,
such as computing the inferred super classes of a class, determining whether or not a class is
consistent (a class is inconsistent if it cannot possibly have any instances), deciding whether or
not one class is subsumed by another, etc. Some of the popular Description Logic reasoners
that are available are listed below:
 RACER
 FaCT
 FaCT++
 Pellet
In our application we are using RACER logic reasoner when developing the Ontology.
3.1.4 OWL
The OWL Web Ontology Language is a language for defining and instantiating Web Ontologies.
OWL ontology may include descriptions of classes, properties and their instances.
The OWL language provides three increasingly expressive sublanguages designed for use by
specific communities of implementers and users.
 OWL Lite
 OWL DL
 OWL Full
OWL is a component of the Semantic Web activity. This effort aims to make Web resources
more readily accessible to automated processes by adding information about the resources
that describe or provide Web content. As the Semantic Web is inherently distributed, OWL
must allow for information to be gathered from distributed sources. This is partly done by
11
allowing Ontologies to be related, including explicitly importing information from other

Ontologies.
In addition, OWL makes an open world assumption. That is, descriptions of resources are not
confined to a single file or scope.
3.1.5 Ontology Development Process

Semantic Web Layer
Toyata.owl … Audi.owl
Core Ontology
Web Service End-User

Internal Layer
Cars.owl
Interface Interface
(WSDL) (JSP)
Cars.java
Web Service, Control Logic (Java

Figure 3
Dynamic Object Model Code)
Semantic Web applications usually need to make some ontological commitments, i.e., they
need to have hard-coded
Reasoners (OWLknowledge about certain domain ontology. In the example above, the
DL, SWRL …)
application has hard-coded behavior that depends on the cars.owl ontology, which contains
classes like Toyota and Audi. The application can also operate on extensions of these core
concepts, e.g., stemming from dynamic extension Ontologies about specific types of Toyota
cars and Audi cars. Then, the application can exploit reasoning engines like Racer or rule
engines like SWRL to expose "intelligent" behavior. All of this is controlled by some logic (Java
code), which also interacts with the end user by means of interface technologies like JSPs.
12
Ontology development steps,
Determine Consider Enumerate Define Define Define Create
scope reuse terms classes properties constraints instances
3.1.5.1 Determine scope
In our Ontology we cover the domain, CAR.
Our system provides classifieds of cars. Here sellers can sell their cars and buyers can buy cars
which they prefer.
3.1.5.2 Consider reuse
System reuses other Ontologies to save the effort, to interact with the tools that use other
Ontologies, to use Ontologies that have been validated through use in applications.
Ontology libraries
 DAML ontology library (www.daml.org/ontologies)
 Ontolingua ontology library (www.ksl.stanford.edu/software/ontolingua/)
 Protégé ontology library (protege.stanford.edu/plugins.html)
Upper Ontologies
 IEEE Standard Upper Ontology (suo.ieee.org)
 Cyc (www.cyc.com)
General Ontologies
 DMOZ (www.dmoz.org)
 WordNet (www.cogsci.princeton.edu/~wn/)
Domain-specific Ontologies
 UMLS Semantic Net
 GO (Gene Ontology) (www.geneontology.org)
13
3.1.5.3 Enumerate Important terms
Make, model, sub models, year, engine, color, price, etc.
3.1.5.4 Define Classes and the Class Hierarchy
A class is a concept in the domain which is a collection of elements with similar properties.
Classes usually constitute a taxonomic hierarchy (a subclass-superclass hierarchy).
Instances of classes (individual),
 A car ad
Levels in the Hierarchy,
Top Level
Middle Level
Bottom Level
Figure 4
14
3.1.5.5 Define Properties of Classes – Slots
Slots in a class definition describe attributes of instances of the class and relations to other
instances.
E.g., each car will have model, color, engine, etc…
Slot and Class Inheritance
 A subclass inherits all the slots from the super class
 If a class has multiple super classes, it inherits slots from all of them
3.1.5.6 Define constraints
Property constraints (facets) describe or limit the set of possible values for a slot.
Common Facets
 Slot cardinality
 Slot value type
 Minimum and maximum value
 Default value
3.1.5.7 Create instances (individuals)
The class becomes a direct type of the instance. Any super class of the direct type is a type of
the instance.
15
Example of Ontology,
Car
Audi BMW Hyundai Isuzu …
100 200 4000 … Accent Sonata Azera …
CS S Base … GLS GS SE …
Sedan Wagon Coupe …
2008 2007 2006 …
Red Green Yellow …
Figure 5
16
3.2 Implementing the searching mechanism
This is the most important build of the system. Complete project completely depends on this
build.
Implementing searching mechanism is interconnecting the ontology and individuals (In our
system an individual is an ad).
Our system’s searching criteria works on according to the several user inputs. In several stages
user wants to select options that system gives. Then system directs user to the correct
destination very fast.
User Interface
Ontology SWRL Rule Engine Rule Engine Web Browser

Bridge
Individual
Figure 6
3.2.1 Rules
Rules are of the form of an implication between an antecedent (body) and consequent (head).
The intended meaning can be read as: whenever the conditions specified in the antecedent
hold, then the conditions specified in the consequent must also hold.
In order to write rules we have to use rule engine which facilitate sufficient environment to
write rules.
17
Example;
Human Readable Syntax:-
hasParent(?x1,?x2) ∧ hasBrother(?x2,?x3) ⇒ hasUncle(?x1,?x3)
XML Concrete Syntax:-
The XML Concrete Syntax is a combination of the OWL Web Ontology Language XML
Presentation Syntax with the RuleML XML syntax.
<ruleml:imp>
<ruleml:_rlab ruleml:href="#example1"/>
<ruleml:_body>
<swrlx:individualPropertyAtom swrlx:property="hasParent">
<ruleml:var>x1</ruleml:var>
</swrlx:individualPropertyAtom>
<swrlx:individualPropertyAtom swrlx:property="hasBrother">
</ruleml:_body>
<ruleml:_head>
<swrlx:individualPropertyAtom swrlx:property="hasUncle">
</ruleml:_head>
</ruleml:imp>
RDF Concrete Syntax:-
It is straightforward to provide such an RDF concrete syntax for rules, but the presence of
variables in rules goes beyond the RDF Semantics. Translation from the XML Concrete Syntax to
RDF/XML could be easily accomplished by extending the XSLT transformation for the OWL XML
Presentation syntax.
18
3.2.2 SWRL
SWRL (Semantic Web Rule Language) is a proposal for a Semantic Web rules-language,
combining sublanguages of the OWL Web Ontology Language (OWL DL and Lite) with those of
the Rule Markup Language (Unary/Binary Datalog)
3.2.3 SWRL rule Engine Bridge
The SWRL Rule Engine Bridge is a subcomponent of the SWRLTab that provides a bridge
between an OWL model with SWRL rules and a rule engine. Its goal is to provide the
infrastructure necessary to incorporate rule engines into Protégé-OWL to execute SWRL rules.
The bridge provides mechanisms to import SWRL rules and relevant OWL classes, individuals,
properties and restrictions from an OWL model; write that knowledge to a rule engine; allow
the rule engine to perform inference and to assert its new knowledge back to the bridge; and
insert that asserted knowledge into an OWL model. The bridge also provides mechanisms to
dynamically add graphical user interfaces to the SWRLTab to allow interaction between a
particular rule engine implementation and a user.
19
3.3 Making the User Interface according to the requirements listed in the SRS
This build is to implement user interface according to the User Interface requirements listed in
the SRS. Each screen in the SRS has been treated as a module. The modules have been grouped
into several module sets. Each module set contains modules that are closely related to each
other. An illustration of the module sets is in Figure 6.
Home Login Advertise your Ad
Search Administrator
Register Create a new account
We Ste Maintenance
External Links
Send a Massage
Email Ad
Report Generation
Figure 7
3.3.1 Login
This module set contains the modules that will handle user login. It will direct user to his
personal account. If a user hasn’t an account he can register in the system through “create an
account” link.
20
3.3.2 Advertise Your Ad
After login user can put his ads on the site in this module. User wants to fill a form to provide
his information about the ad. User may also upload photos of his car.
3.3.3 Register
This module requests several details from the user and create an account for the user. User
should fill a form including his personal details.
3.3.4 Search
This is the most important module of the system. This gives user to enter few keywords and
search. In few steps the system drives user to the ad/ads he prefer. In the middle stages system
takes few user inputs also. In a few seconds user can select ad/ads he is looking for.
3.3.5 Send a Massage
After selecting ad user can leave a message to the ad holder.
3.3.6 Email Ad
In this module system facilitate user to email the ad he selected.
3.3.7 Report Generation
Here user can generate a report from the ad he selected.
3.3.8 Administrator
After login administrator can handle the system. E.g. maintain the site, set user privileges,
create accounts, delete accounts, maintain ads, etc.
21
3.4 Making the web based front end and back end for the PSWSC system
The goal of Build 4 is to build the web site frontend and backend. To build entire system we use
‘Adobe® Flex® Builder™ 3’ which is flash oriented web design tool. E.g. page’s interfaces, ads,
forms, reports, etc.
Flex Builder 3 MXML Compiler App.html
App.mxml App.swf
Figure 8
3.4.1 Adobe® Flex® Builder™
Flex is a highly productive, free open source framework for building and maintaining expressive
web applications that deploy consistently on all major browsers, desktops, and operating
systems. While Flex applications can be built using only the free open source framework,
developers can use Adobe® Flex® Builder™ software to dramatically accelerate development.
3.4.2 Frontend
3.4.2.1 Creating Pages
Home page consists of 4 blocks, top banner and other three vertical blocks. Normally other
pages consist of two blocks, including the top banner. When building these things we use flex’s
components. Such as Canvas, panel, form, Hbox, Vbox, button, control bar, text area, data grid,
etc.
3.4.2.2 Building Ads
Flex builder has its own components list, also it provides user to build their own components.
We generate a flex component to use as an ad.
22
When considering the ad it has two forms, small and large. Immediate after the user searching
ads, ads will display as a small form. In small form there are a few details are listed in the ad.
Like picture, make, model, year. User wants to click on the ad to view it as a large form. In large
form there is all details displayed in the ad.
Normally ad holds a picture of the car (if user didn’t upload a picture system places a default
picture), details of the car, details of the car owner, other features and buyers can make a
comments.
3.4.2.3 RSS feed
We put RSS feeds from several automobile sites. Newest news from automobile world will
display on our site as well.
3.4.2.4 Forms
When creating forms flex provides several components to create forms, like label, text, button,
check box, list, radio button, text input, etc.
3.4.3 Backend
When considering the backend it is full of xml files. We use xml files to store all of our useful
data other than a usual database.
3.4.3.1 XML
When HTML is used to display data, the data is stored inside HTML. With XML, data can be
stored in separate XML files. This way we can concentrate on using HTML for data layout and
display, and be sure that changes in the underlying data will not require any changes to our
HTML.
In the real world, computer systems and databases contain data in incompatible formats. One
of the most time-consuming challenges for developers has been to exchange data between
such systems over the Internet.
Converting the data to XML can greatly reduce this complexity and create data that can be read
by many different types of applications.
All the ads (data) that user input will converts to xml files. User account details are also stored
as xml files.

Architectural Design Document

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Architectural Design Document

Diunggah oleh

Hak Cipta:

Format Tersedia

Architectural

Name Email address

Name Reg.No Index No

1.3 System Overview

1.3.2 Project purpose

Web Server Middle Tier

Database/XML Bottom Tier

 Top most tier involving System User Interface.

2.1 The Incremental lifecycle model

2.2 List of the builds

2.3 Builds Interaction

The interactions of the four builds are shown in Figure 1.

Requirements Specification Architectural Design

Detailed Implementation Testing

Detailed Implementation Testing

Detailed Implementation Testing

Detailed Implementation Testing

3.1 Implementing the ontology tree

3.1.1 Goals of Build 1

3.1.2 Ontology Tree

In theory, ontology is a "formal, explicit specification of a shared conceptualization". Ontology

We use Protégé (Protégé 3.4.1) when developing the Ontology.

The Protégé platform supports two main ways of modeling Ontologies:

 The Protégé-Frames editor

 The Protégé-OWL editor

3.1.3.1 Description Logic Reasoners

allowing Ontologies to be related, including explicitly importing information from other

3.1.5 Ontology Development Process

Web Service End-User

Web Service, Control Logic (Java

Ontology development steps,

Determine Consider Enumerate Define Define Define Create

scope reuse terms classes properties constraints instances

3.1.5.1 Determine scope

In our Ontology we cover the domain, CAR.

3.1.5.2 Consider reuse

 DAML ontology library (www.daml.org/ontologies)

 Ontolingua ontology library (www.ksl.stanford.edu/software/ontolingua/)

 Protégé ontology library (protege.stanford.edu/plugins.html)

 IEEE Standard Upper Ontology (suo.ieee.org)

 UMLS Semantic Net

 GO (Gene Ontology) (www.geneontology.org)

3.1.5.3 Enumerate Important terms

Make, model, sub models, year, engine, color, price, etc.

3.1.5.4 Define Classes and the Class Hierarchy

Instances of classes (individual),

Levels in the Hierarchy,

3.1.5.5 Define Properties of Classes – Slots

E.g., each car will have model, color, engine, etc…

Slot and Class Inheritance

 A subclass inherits all the slots from the super class

3.1.5.6 Define constraints

 Slot value type

 Minimum and maximum value

3.1.5.7 Create instances (individuals)

Audi BMW Hyundai Isuzu …

100 200 4000 … Accent Sonata Azera …

Sedan Wagon Coupe …

2008 2007 2006 …

Red Green Yellow …

3.2 Implementing the searching mechanism

Ontology SWRL Rule Engine Rule Engine Web Browser

Human Readable Syntax:-