CHAPTER 1
THEORETICAL FOUNDATION
1.1 Theoretical Foundation
1.1.1
Introduction to Portal, Community and Forum
As we described in section Error! Reference source not found., this project is heavily
focused on the term portal, community, and forum. There are quite a number of different
descriptions which explain those three terms. Therefore, we consider that it is a good
idea to discuss about those three terms briefly before we go deeper into the theoretical
foundation and theoretical frameworks. We quote the most significant resources that best
describes about portal, community, and forum.
1.1.1.1
Definition of Portal
Rob Allan describes that portals are built in a similar technology used for websites,
though enhanced for its functionality and flexibility to cater the demands of specific
classes of user (Allan, Rob, et al, p.6, 2003).
Andy Powell of UKOLN (UK Office for Library Networking) describes a portal as
“an online service that provides a personalized, single point of access to resources that
support the end-user in one or more tasks (resource discovery, learning, research, buying
plane tickets, booking hotel rooms, etc.) (Allan, Rob, et al, p.6, 2003).
Andy and JISC's (The Joint Information Systems Committee) Chris Awre say that
"Technically, a portal is a network service that brings together content from diverse
distributed resources using technologies such as cross searching, harvesting, and alerting,
and collate this into an amalgamated form for presentation to the user. This presentation
is usually via a web browser, though other means are also possible.” (Allan, Rob, et al,
p.6, 2003).
We tend to simply say that a portal is "a layer which aggregates, integrates,
personalizes and presents information, transactions and applications to the user according
to their role and preferences." It provides a persistent state/ context for each user and/ or
group of collaborators. This state may consist of documents, personal registries, tool
configurations, calendars, or anything else related to the user's personal configuration of
the their "home" at the portal (Allan, Rob, et al, p.6, 2003).
A portal is only as good as its content. Standards are used for discovery, so content
must be discoverable. There is usually a shared infrastructure, typically with registry,
authentication, terminology and a presentation layer for usability, interface design,
information visualization. There must also be support through a service provider to
facilitate moving of data into the portal environment (Allan, Rob, et al, p.6, 2003).
1.1.1.2
Types of Portal
Portal technology is hugely versatile so it can be useful in many contexts (Microsoft
Corp., 2005). This is the list of seven of the most common examples of portal
applications that Microsoft describes:
Line-of-Business Portals
Line-of-business portals provide easy access to applications that serve a
specific area, such as procurement or human resources. This type of portal
could also support the needs of a division or an entire organization. These
portals help people track financial data more easily and execute business
processes more effectively.
Corporate Intranet Portals
A corporate Intranet portal often acts as gateway to other portals and websites
operated by an organization. Access to corporate directories can be enabled,
along with document sharing and search. Corporate Intranet portals can
support collaborative activity as well as information publishing.
Corporate Extranets
Extranet portals act as an interface between companies, customers and
suppliers, revealing subsets of information to specific audiences. Business-tobusiness and e-commerce transactions can be enabled, as well as supply chain
enhancement and order management operations.
Customer Service or Self-Service
Customer service and self-service portals are often seen as subsets of a
corporate Extranet, delivering online personalized content and services, as
well as training and support.
Team or Divisional Portal
This type of portal is used by groups or communities that want to share
specific content or business functions. These portals can also act as an
interface to broader organizations and external third parties, such as suppliers
and customers.
Personal Portal
This portal is geared to assist individuals who access information and
resources. Personalized application sets can be provided, with this portal type
often integrated into a corporate Intranet.
Enterprise Portals
The Enterprise Portal is the central portal for an entire organization. It
comprises all other portals deployed.
Since a portal is specific to the need of an institution, consequently BISIC is
considered as a student portal which is not included in Microsoft’s category of common
portal applications.
1.1.1.3
Student Portal
A student portal is a website gateway to online courseware, tools and resources for ECU
(Edith Cowan University) students available 24 hours a day, seven days a week (ECU,
www.ecugreatcareers.com, 2005). If we could categorize a student portal based on
Microsoft’s definition, then a student portal can be considered as a Line-of-Business
portal and Corporate Intranet Portal.
1.1.1.4
Definition of Community
Community is the aggregate of persons with common characteristics such as geographic,
professional, cultural, racial, religious, or socioeconomic similarities. Communities can
be defined by location, race, ethnicity, age, occupation, interest in particular problems or
outcomes, or other common bonds (State of Florida, www.doh.state.fl.us, 2004).
Another definition of community is that education listservs and other online
communities–forums for exchanging ideas around particular education topics or
challenges (Friesen, Dr. Norm, www.cancore.org, 2003).
1.1.1.5
Definition of Forum
Forum, from the point of view of Electronic classroom/internet, is a space in which users
can share messages and files with other students and staff members (The State of
Queensland, www.trainandemploy.qld.gov.au, 2005).
Another definition of forum is Bulletin Board, Discussion Group, Newsgroup,
Community of Interest (CMS Wiki, www.cmsreview.com, 2005).
In the end, we can say a forum is an online discussion group. Forums can be
newsgroups, or they can be Web-based (Sympatico Glossary, www1.sympatico.ca,
2005).
1.1.2
The System Lifecycle
After we discuss about the definition of portal, community and forum, we will now go
through the explanation that supports our system development. The system lifecycle
describes on how we are going to develop this portal system.
1.1.2.1
Definition of System Lifecycle
A system life cycle divides the life of an information system into two stages, systems
development and systems operations and support (Whitten, Jeffrey L. et al, p.78, 2001).
1.1.2.2
Definition of Methodology
In building the student portal, we use the methodology that fits our situation to ensure that
final system could fulfill the requirement, achieve the most usability, and be completed in
time.
A system development methodology is a very formal and precise system
development process that defines a set of activities, methods, best practices, deliverables,
and automated tools for system developers and project managers to develop and maintain
most or all information systems and software (Whitten, Jeffrey L. et al, p.78, 2001).
1.1.3
Analysis Phase
One of the phases in a methodology is the analysis phase. The analysis phase answers the
questions of who will use the system, what the system will do, and where and when it
will be used. All of the deliverables are combined into a system proposal, which is
presented to management who decided whether the project should continue to move
forward (Dennis, Alan, et al, p.97, 2003).
1.1.3.1
Definition of Systems Analysis
System analysis is the study of a business problem domain to recommend improvements
and specify the business requirements for the solution (Whitten, Jeffrey L. et al, p.13,
2002).
1.1.3.2
Definition of Use Case Analysis
A use case is a set of activities that produce some output result. Each use case describes
how the system reacts to an event that triggers the system. With this type of event driven
modeling, everything in the system can be thought as a response to some trigger event.
When there are no events, the system is at rest, patiently waiting for the next event to
trigger it. When a trigger event occurs, the system (and the people using it) responds,
performs the actions defined in the use case, and then returns to the waiting state (Dennis,
Alan, et al, p.144, 2003).
1.1.3.3
Elements Use-Case Analysis
While there are numerous pieces of information in the use case, there are three basic
elements in a use case: (Dennis, Alan, et al, p.145, 2003)
Basic Information
Each use case has a name, number, and brief description. Another element of
basic information is the trigger for the use case – the event that causes the use
case to begin. A trigger can be an external trigger, or it can be a temporal
trigger.
Inputs and Outputs
Each of the major inputs and outputs to the use case are described along with
their source or destination. The goal is to include everyone, but it is common
for users and analysts to miss inputs and outputs when they first define use
cases. This is not a major problem because the process of building use cases
is one of gradual refinement: as they work through the parts of the use case,
they often return to previous parts to correct them.
Details
The third major part of a use case is the detailed individual steps within the
use case and the inputs and outputs they use. These steps are the activities
that are performed during the use case. The steps are listed in the order in
which they are performed and any conditional steps are clearly noted.
Figure 1.1: Sample Use Case (Dennis, Alan, et al, p.145, 2003)
1.1.3.4
Use-Case Analysis
Use Case Analysis is composed of several steps in Rational Unified Process [RUP2003]:
(Evans, Gary K., 2004)
For each use case in an iteration
1. Create a use case realization
2. Supplement the Use-Case descriptions (if necessary)
3. Find Analysis Classes from Use-Case Behavior
4. Distribute Behavior to Analysis Classes
For each resulting analysis class
1. Describe the Class’s Responsibilities
2. Describe the Class’s Attributes and Associations

Define Class Attributes.

Establish Associations between Analysis Classes

Describe Event Dependencies between Analysis Classes
Reconcile the Use Case Realizations
Establish Traceability
Qualify Analysis Mechanisms
Evaluate the Results of Use-Case Analysis
This illustration also shows the steps recommended by RUP within the context of
Use Case Analysis. This diagram will become our visual roadmap as the remainder of
this paper addresses the specific tasks within these activities (Evans, Gary K., 2004).
Figure 1.2: Recommended Steps of Use Case Analysis (Evans, Gary K., 2004)
1.1.3.5
Definition of Data Flow Diagram
Data flow diagram (DFD) is a technique that diagrams the business processes and the
data that passes among them (Dennis, Alan, et al, p.168, 2003). Although the name data
flow diagram implies a focus on data, this is not the case. The focus is mainly on the
process or activities that are performed.
1.1.3.6
Elements of Data Flow Diagram
In the previous section, we have seen a brief introduction of Data Flow Diagram. Next,
we will discuss the four elements in the Data Flow Diagram language, which are:
(Dennis, Alan et al, p.170, 2003)
Process
A process is an activity or a function that is performed for some specific
business reason.
Data Flow
A data flow is a single piece of data (sometimes called a data element), or a
logical collection of several pieces of information.
Data Store
A data store is a collection of data that is stored in some way (which is
determined later when creating the physical model).
External Entity
An external entity is a person, organization, or system that is external to the
system but interacts with it.
Figure 1.3: Data Flow Diagram Elements (Dennis, Alan et al, p.170, 2003)
1.1.3.7
Creating Data Flow Diagram
The DFDs show the flow of data values from their sources in objects through the
processes that transform them to their destination in other objects. Values can include
input values, output values, and internal data stores. Control information is shown only in
the form of control flows (Telelogic AB, 2000).
You can follow certain guidelines to draw meaningful DFDs: (Telelogic AB, 2000)
Optional input flows do not exist. A process can perform its function only if all its
input flows are always available.
You cannot assign the same data to two output flows from the same process. If a
process produces more than one data flow, these flows are mutually exclusive.
You can split a flow, and you can merge two flows into one.
Figure 1.4: Sample of Data Flow Diagram (Telelogic AB, 2000)
Figure 1.5: Symbols in Data Flow Diagram (Telelogic AB, 2000)
1.1.3.8
Definition of Entity Relationship Diagram
An entity relationship diagram (ERD) is a picture that shows the information that is
created, stored, and used by a business system (Dennis, Alan et al, p.205, 2003). The
ERD will describe the relationship between different entities in BISIC.
1.1.3.9
Elements of Entity Relationship Diagram
There are three basic elements in the data modeling language: (Dennis, Alan et al, p.207,
2003)
Entity
The entity is the basic building block for a data model. It is a person, place,
event, or thing about which data is collected.
An entity is depicted by a
rectangle, and it is described by a singular noun spelled in capital letters.
Attribute
An attribute is some type of information that is captured about an entity. It is
easy to come up with hundreds of attributes for an entity, but only those that
will actually be used by a business process should be included in the model.
Relationship
Relationships are associations between entities, and they are lines that connect
together. Every relationship has a parent entity and a child entity, the parent
being the first entity in the relationship, and the child being the second.
Relationships should be clearly labeled with active verbs so that the
connections between entities can be understood.
Figure 1.6: Data Modeling Elements (Dennis, Alan et al, p.207, 2003)
1.1.3.10
Creating Entity Relationship Diagram
Entity Relationship Diagrams are a major data modeling tool and will help organize the
data in your project into entities and define the relationships between the entities. This
process has proved to enable the analyst to produce a good database structure so that the
data can be stored and retrieved in a most efficient manner (infocom.cqu.edu.au, 2000).
1. Identify Entities
Identify the roles, events, locations, tangible things or
concepts about which the end-users want to store data.
2. Find Relationships
Find the natural associations between pairs of entities
using a relationship matrix.
3. Draw Rough ERD
Put entities in rectangles and relationships on line
segments connecting the entities.
4. Fill in Cardinality
Determine the number of occurrences of one entity for a
single occurrence of the related entity.
5. Define Primary Keys
Identify the data attribute(s) that uniquely identify one
and only one occurrence of each entity.
6. Draw Key-Based ERD
Eliminate Many-to-Many relationships and include
primary and foreign keys in each entity.
7. Identify Attributes
Name the information details (fields) which are essential
to the system under development.
8. Map Attributes
For each attribute, match it with exactly one entity that it
describes.
9. Draw fully attributed
ERD
Adjust the ERD from step 6 to account for entities or
relationships discovered in step 8.
10. Check Results
Does the final Entity Relationship Diagram accurately
depict the system data?
Table 1.1: ERD Methodology (infocom.cqu.edu.au, 2000)
Figure 1.7: Sample of Entity Relationship Diagram (infocom.cqu.edu.au, 2000)
Figure 1.8: Symbols in Entity Relationship Diagram (infocom.cqu.edu.au, 2000)
Here is a sample of normalization rule (Dennis, Alan, p.226, 2003):
Do any attributes have multiple values for a single instance of an entity?

If yes then remove the repeating attributes and repeating groups.
Create an entity that describes the attributes. Usually you will need
to add a relationship to connect the old and new entities.

If no then the data model is in 1st Normal Form.
Is the identifier comprised of more than one attribute? If so, are any attribute
values dependent on just part of the identifier

Remove the partial dependency. Move the attributes to an entity in
which their values are dependent on the entire identifier. Usually you
will need to create a new entity and add a relationship to connect the
old and new entities

If no then the data model is in 2nd Normal Form.
Do any attribute values depend on an attribute that is not the entity’s identifier?

Remove the transitive dependency or derived attribute. Move the
attributes to an entity in which their values are dependent on the
identifier. Usually you will need to create a new entity and add a
relationship to connect the old and new entities.

1.1.4
The data model is in 3rd Normal Form.
Design Phase
The design phase decides how the system will operate. This collection of deliverables is
the system specifications that are handed to the program team for implementation. At the
end of the design phase, the feasibility analysis and project plan are reexamined and
revised, and another decision is made by the project sponsor and approval committee
about whether to terminate the project or continue (Dennis, Alan et al, p.237, 2003).
1.1.4.1
Definition of System Design
System design is the specification or construction of a technical, computer-based solution
for the business requirements identified in a systems analysis (Whitten, Jeffrey L. et al,
p.20, 2002).
1.1.4.2
Definition of Architecture Design
Architecture design is the plan for how the system will be distributed across the
computers and what hardware and software will be used for each computer (e.g.,
Windows, Linux) (Dennis, Alan et al, p.274, 2003).
1.1.4.3
Elements of Architecture Design
There are three principal application architectures in use today: (Dennis, Alan et al,
p.275, 2003)
Server-based architectures
In this architecture, the server (usually a central mainframe computer) is the
one which performing all four application functions.
The clients (usually
terminals) enabled users to send and receive messages to and from the server
computer. The clients merely captured keystrokes and sent them to the server
for processing, accepting instructions from the server on what to display.
Figure 1.9: Server-Based Architecture (Dennis, Alan et al, p.275, 2003)
Client-based architectures
The clients are microcomputers on a local area network, and the server
computer is a server on the same network. The applications software on the
client computers is responsible for the presentation logic, the application
logic, and the data access logic; the server simply stores the data.
Figure 1.10: Client-Based Architecture (Dennis, Alan et al, p.275, 2003)
Client-server architectures
These architectures attempt to balance the processing between the client and
the server. In these architectures, the client is responsible for the presentation
logic, whereas the server is responsible for the data access logic and data
storage.
Figure 1.11: Client-Server Architecture (Dennis, Alan et al, p.275, 2003)
1.1.4.4
Definition of Client-Server Architectures
Now, we will focus on the client server-architectures which are used in our system.
There are two different approaches in client-server architectures.
When the client has
most or all of the application logic, it is called a thick client. If the client contains only
the presentation function and most of application function resides on the server, it is
called a thin client (Dennis, Alan et al, p.276, 2003).
There are four benefits in client-server architectures: (Dennis, Alan et al, p.277, 2003)
They are easy to increase or decrease the storage and processing capabilities of
the servers.
They can support many different types of clients and servers.
Therefore it is
possible to connect computers that use different operating systems so that
users can choose which type of computer they prefer.
Thin client-server architectures that use the Internet standards, it is simple to
clearly separate the presentation logic, the application logic, and the data
access logic and design each to be somewhat independent.
Since there is no single server computer supports all the application, the network
is generally more reliable. Therefore, there is no central point of failure that
will halt the entire network if it fails. In addition to that, more processing
power will improve the reliability of the network.
1.1.4.5
Types of Client-Server Architectures
There are many ways in which the application login can be partitioned between the client
and the server, which are: (Dennis, Alan et al, p.278, 2003)
A two-tiered architecture
It uses only two sets of computers, clients, and servers. In this case, the server
is responsible for the data and the client is responsible for the application and
presentation.
A three-tiered architecture
It uses three sets of computers.
In this case, the software on the client
computer is responsible for presentation logic, an application server(s) is
responsible for the application logic, and a separate database server(s) is
responsible for the data access logic and data storage.
An n-tiered architecture
It uses more than three sets of computers. In this case, client is responsible for
presentation, a database server(s) is responsible for the data access logic and
data storage, and the application logic is spread across two or more different
sets of servers.
1.1.4.6
Three-Tiered Architecture
In this project, we will be using three-tiered architecture which will be discussed in
chapter 5. Hugh E. Williams explains, “At the base of an application is the database tier,
consisting of the database management system that manages the data users create, delete,
modify, and query. Built on top of the database tier is the middle tier, which contains
most of the application logic that you develop. It also communicates data between the
other tiers. On top is the client tier, usually web browser software that interacts with the
application” (Williams, Hugh E. et al, p.3, 2004). The presentation tier is included in the
client tier.
1.1.4.7
User Interface Design
A user interface is the part of the system with which the users interact. It includes the
screen displays that provide navigation through the system, the screens and forms that
capture data, and the reports that the system procedures (whether on paper, on the Web,
or via some other media) (Dennis, Alan et al, p.303, 2003).
Interface design is the process of defining how the system will interact with
external entities (e.g. customers, suppliers, other systems). The user interface design
defines the way in which the users will interact with the system and the nature of the
inputs and outputs that the system accepts and produces (Dennis, Alan et al, p.304,
2003).
The user interface includes three fundamental parts: (Dennis, Alan et al, p.304, 2003)
Navigation Mechanism
The way in which the user gives instructions to the system provides
information to the user or to other systems (e.g., buttons, menus). The
fundamental goal of navigation design is to make the system as simple to use
as possible, by preventing the user from making mistakes, simplifying the
recovery from mistakes, and using a consistent grammar order.
Input Mechanism
The way in which the system captures information (e.g., forms for adding new
customers). The goal of input design is to simply and easily capture accurate
information for the system, typically by using online or batch processing,
capturing data at the source, and minimizing keystrokes.
Output Mechanism
The way in which the system provides information to the user or to other
systems (e.g., reports, Web pages). The goal of output design is to present
information to users so they can accurately understand it with the last effort,
usually by understanding how reports will be used and designing them to
minimize information overload and bias.
Fundamental interface design principles which are common for navigation, input, and
output design are: (Dennis, Alan et al, p.305, 2003)
Layout
The interface should be a series of areas on the screen that are used
consistently for different purposes-for example, a top area for commands and
navigation, a middle area for information to be input or output, and a bottom
area for status information.
Content Awareness
Users should always be aware of where they are in the system and what
information is being displayed.
Aesthetics
Interfaces should be functional and inviting to users through careful use of
white space, colors, and fonts. There is often a trade-off between including
enough white space to make the interface look pleasing without losing so
much space that important information does not fit on the screen.
User Experience
Although ease of use and ease of learning often lead to similar design
decisions, there is sometimes a trade off between the two. Novice users or
infrequent users of software prefer ease of learning, whereas frequent users
will prefer ease of use.
Consistency
Consistency in interface design enables users to predict what will happen
before they perform a function. It is one of the most important elements in
ease of learning, ease of use, and aesthetics.
Minimal user effort
The interface should be simple to use. Most designers plan on having no more
than three mouse clicks from the starting menu until users perform work.
1.1.4.8
Database Design
A project team designs the data storage component of a system using a two-step
approach: selecting the format of the data and then optimizing it to perform efficiently
(Dennis, Alan et al, p.355, 2003). Some of the types of databases that exist in the market
nowadays are: (Dennis, Alan et al, p.359, 2003)
Legacy Databases
Examples of legacy databases are hierarchical database and network database.
Hierarchical databases (e.g., IDMS) use hierarchies, or inverted trees, to
represent relationships. Network database (e.g., IDMS/R, DBMS 10) are
collections of records that are related to each other through pointers. Both
legacy systems can handle data quite efficiently, but they require a great deal
of programming effort. The application system software needs to contain code
that manipulates the database pointers; in other words, the application
program must understand how the database is built and be written to follow
the structure of the database.
Relational Databases
The relational database is the most popular kind of database for application
development today. A relational database is based on collections of tables,
each of which has a primary key – a field (s) whose value is different for every
row of the table. The tables are related to each other by placing the primary
key from one table into the related table as a foreign key.
Most relational database management systems (RDBMS) support referential
integrity, or the idea of ensuring that values linking the tables together through
the primary and foreign keys are valid and correctly synchronized.
Object Databases
The basic premise of object orientation is that all things should be treated as
objects that have both data and processes. Changes to one object have no
effect on other objects because the data and processes are self-contained, or
encapsulated, within each one.
Multidimensional Databases
Multidimensional database is driven by the rise of data warehousing. Data
warehousing is the practice of taking data from a company’s transaction
processing systems, transforming the data (e.g., cleaning them up, totaling
them, aggregating them), and then storing the data for use in a data warehouse
(i.e., a large database) that supports decision support system (DSS).
Figure 1.12: Comparison of Data Storage Formats (Dennis, Alan et al, p.359, 2003)
Figure 1.13: Benefits of the Object Approach (Dennis, Alan et al, p.359, 2003)
1.1.5
Object-Oriented Approach to Analysis and Design
Object-oriented approaches emphasize iterative and incremental development that
undergoes continuous testing throughout the life of the project. Iteration of the system
brings the system closer and closer to the final needs of the users.
Concepts like
polymorphism, encapsulation, and inheritance taken together allow analysts to break a
complex system into smaller, more manageable components, to work on the components
individually, and to more easily piece of the components back together to form a system
(Dennis, Alan et al, p.488-489, 2003).
1.1.5.1
Definition of Unified Modeling Language
UML is a standard set of diagramming techniques that provide a graphical representation
that is rich enough to model any systems development project from analysis through
implementation. It is believe that users do not think in terms of data or processes, but
instead in terms of a collection of collaborating objects. Therefore, UML allows the
analysts to interact with user employing objects from the user’s environment instead of a
set of separate processes and data (Dennis, Alan et al, p.519, 2003).
1.1.5.2
Definition of Use Case Diagram
A use case diagram illustrates in a very simple way the main functions of the system and
the different kinds of users that will interact with it. Basically, an analyst can use the usecase diagram to better understand the functionality of the system at a very high level
(Dennis, Alan et al, p.495, 2003).
Figure 1.14: Unified Modeling Language Diagrams (Dennis, Alan et al, p.495, 2003)
1.1.5.3
Elements of Use Case Diagram
There are four elements in use diagram: (Dennis, Alan et al, p.496, 2003)
An actor
An actor is a person or system that derives benefit from and is external to the
system. An actor is not a specific user, but a role that a user can play while
interacting with the system. An actor is usually represented as a labeled stick
figure.
A use case
A use case is a major process that the system will perform that benefits an
actor in some way, and it is labeled using a descriptive verb phrase.
A system boundary
The use cases are enclosed within a system boundary, which is a box that
represents the scope of the system and clearly delineates what parts of the
diagram are external or internal to it.
An association
Use cases are connected to actors through associations, which show with
which use cases the actors interact. It is depicted by a line drawn from an
actor to a use case, and it is normally shown as a one-to-one relation with no
direction.
1.1.5.4
Creating Use Case Diagram
UCDs allow you to capture business events by analyzing how objects external to the
system interact with the system. A UCD represents a particular sequence of transactions
between the system and an actor (an end user or system external to the system being
analyzed). You can use UCDs to analyze system requirements and to help you define
system boundaries (Telelogic AB, 2000).
Here is a sample of a UCD. This UCD models a banking system. Customer,
Auditor, Clerk and Loan Officer are actors. Counter Transaction, Loan Application, and
Audit are use cases -- ways in which the actors use the system (Telelogic AB, 2000).
Figure 1.15: Sample of Use Case Diagram (Telelogic AB, 2000)
Figure 1.16: Symbols in Use Case Diagram (Telelogic AB, 2000)
The analyst must choose the appropriate level of detail. You need enough detail to
fully capture the business events and system requirement, but, you want to avoid using
UCDs for functional decomposition.
1.1.5.5
Definition of Class Diagram
The class diagram is a static model that supports the static view of the evolving system.
It shows the classes and the relationships among classes that remain constant in the
system over time (Dennis, Alan et al, p.503, 2003).
1.1.5.6
Elements of Class Diagram
There are four elements of class diagram: (Dennis, Alan et al, p.501, 2003)
A class
Class is the main building block of a class diagram. It stores and manages
information in the system. During analysis, classes refer to the people, places,
events, and things about which the system will capture information. Later,
during design and implementation, classes can refer to implementation,
classes can refer to implementation-specific artifacts like windows, forms, and
other objects used to build the system.
An attribute
Attributes are properties of the class about which we want to capture
information. They represent the state of each object that is created from the
class. There are also attributes which can be calculated or derived from other
attributes and therefore are not stored.
They are called derived attributes.
Moreover, attributes can be divided into three types based on their visibility:
public (+), protected (#) and private (-).
A method
Methods are actions or functions that a class can perform. They represent the
behavior of each object that is created from the class. Methods should be
shown with parentheses that are either empty or filled with some valued,
which represents a parameter that the method needs for it to act. There are
three kinds of methods: constructor, query, and update. Similar to attributes,
methods can also be divided into three types based on their visibility: public
(+), protected (#) and private (-).
An association
Classes are related to each other through an association, which as a name and
a multiplicity that denotes the minimum and maximum instances that
participate in the relationship.
Two special associations, aggregation and
generalization, are used when classes comprise other classes or when one
subclass inherits properties and behaviors from a superclass, respectively.
Figure 1.17: Class Diagram Syntax (Dennis, Alan et al, p.501, 2003)
1.1.5.7
Creating Class Diagram
The class diagram (CD) describes the type of objects in a system and their static
relationships. For each type of object, or class, in a CD, you can specify its characteristics
(attributes) and the processes it can carry out (operations) (Telelogic AB, 2000).
Figure 1.18: Sample of Class Diagram (Telelogic AB, 2000)
Figure 1.19: Symbols in Class Diagram (Telelogic AB, 2000)
1.1.5.8
Difference between Class Diagram and ERD
The class diagram is similar to the entity relationship diagram (ERD). However, the class
diagram depicts classes, which include attributes, behaviors and states, while entities in
the ERD only include attributes (Dennis, Alan et al, p.501, 2003).
1.1.5.9
Definition of Sequence Diagram
A sequence diagram illustrates the objects that participate in a use case and the messages
that pass between them over time for one use case. A sequence diagram is a dynamic
model that supports a dynamic view of the evolving system which shows the explicit
sequence of messages that are passed between objects in a defined interaction (Dennis,
Alan et al, p.510, 2003).
The sequence diagram can be a generic diagram that shows all possible scenarios
for a use case, but usually each analyst develops a set of instance sequence diagrams each
of which depicts a single scenario within the use case (Dennis, Alan et al, p.510, 2003).
1.1.5.10
Elements of Sequence Diagram
There are six elements of sequence diagram: (Dennis, Alan et al, p.512, 2003)
An actor
An actor is a person or system that derives benefit from and is external to the
system. An actor is placed across the top of the diagram.
An object
Objects are placed horizontally across the top of a sequence diagram.
A lifeline
A lifeline denotes the life on an object during a sequence.
A lifeline is a
dotted line place vertically below each object which contains an X at the point
at which the class no longer interacts.
A focus of control
A focus of control, represented by a thin rectangle, is placed over the lifeline
to show when the objects are sending or receiving messages. It denotes when
an object is sending or receiving messages.
A message
A message is a communication between objects that conveys information with
the expectation that activity will ensue and the messages are shown using an
arrow connecting two objects that points in the direction that the message is
being passed.
Object destruction
An X is placed at the end of an object’s lifeline to show that it is going out of
existence.
1.1.5.11
Creating Sequence Diagram
This SD shows a simple scenario for the use of an automatic teller machine. In this
scenario, the system rejects the card. For the customer this transaction is simple: he
inserts the card and the card is rejected. For the system, several actions are necessary. A
constraint specifies 10 seconds as the maximum acceptable time interval for the
transaction (Telelogic AB, 2000).
Figure 1.20: Sequence Diagram Syntax (Dennis, Alan et al, p.503, 2003)
Figure 1.21: Sample of Sequence Diagram (Telelogic AB, 2000)
This sequence is fairly general; you can work out the Insert Card event more
completely by including details such as entering the personal identification number and
requesting the type of transaction. The analyst must decide what level of detail to use in
the SDs (Telelogic AB, 2000).
Figure 1.22: Symbols in Sequence Diagram (Telelogic AB, 2000)
1.2 Theoretical Frameworks
The theoretical frameworks describe how the system is going to be developed. This
framework shows the phases we have been through.
1.2.1
Rapid Application Development (RAD)
RAD is characterized by a quick turnaround time from requirements definition to
completed system. It follows a sequence of revolutionary system integrations or
prototypes that review with the customer, discovering requirements along the way. There
are several phases in the RAD life cycle development process: (Futrell et al, p.130-131,
2002)
Requirements planning phase
Requirements are gathered using a workshop technique called joint
requirement planning (JRP), a structured discussion of the business problem at
hand.
User description
Joint Application Design (JAD) is used to harness user involvement; the
project team often uses automated tools to capture information from the users
during this nontechnical design of the system.
Construction phase
This phase combined a detailed design, the build, and the release to the
customer inside a time-box. It is heavily dependent on the use of code
generators, screen generators, and other types of productivity tools.
Cutover
This phase includes acceptance testing by the users, installation of the system
and user training.
Figure 1.23: Rapid Application Developers Model (Futrell et al, p.130-131, 2002)
Strengths of RAD model: (Futrell et al, p.131-132, 2002)
Cycle time for the full product can be reduced due to the use of powerful
development tools.
Fewer developers are required because the system is developed by a project team
familiar with the problem domain.
Quick initial views of the product visible.
Reduced cycle time and improved productivity with fewer people spell lower
cost.
The time-box approach mitigates cost and schedule risk.
It makes effective use of off-the-shelf tools and frameworks.
Ongoing customer involvements minimize the risk of not achieving customer
satisfaction and ensure that the system meets the business needs and that the
operational utility and product is sound.
Each time-box includes analysis, design, and implementation.
Constant integrations isolate problems and encourage customer feedback.
The focus moves from documentation to code – What You See is What You Get
(WYSIWYG)
It uses modeling approach and tools – business modeling, data modeling, process
modeling, and application generation.
Is reuses existing program components.
When to use RAD model: (Futrell et al, p.132-133, 2002)
On systems that may be modularized and that are scalable.
On system with reasonably well-know requirements.
When the end user can be involved throughout the lifecycle.
When users are willing to become heavily involved in the use of automated tools.
On projects requiring short development times.
On systems that can be time-boxed to deliver functionality in increments
When reusable parts are available through automated software repositories.
On system that are proof-of-concept, noncritical, or small.
When cost and schedule are not a critical concern (such as internal tool
development).
On system that do not require high performance, especially during tying interval.
When technical risk are low.
On information system.
When the project team is familiar with the problem domain, skilled in the use of
the developments tools, and highly motivated.
1.3 Support Knowledge
This supporting knowledge is meant to discuss various technical aspects which are
related to the project.
1.3.1
The Internet
Internet is a large global network comprised of thousands of smaller networks (Teachers
Insurance and Annuity Association - College Retirement Equities Fund, http://www.tiaacref.org/help/glossary.html, 2005).
1.3.1.1
TCP/ IP
TCP/IP (Transmission Control Protocol / Internet Protocol) is a standard that allows
different types of computers to communicate with each other (H.L. Capron, p.19, 2004).
TCP provides: (Gourley et al, p.12, 2002)
Error free data transportation.
In-order delivery (data will always arrive on the order in which it was sent).
Unsegmented data stream (can dribble out data in any size at any time).
TCP/IP hides the peculiarities and foibles of individual networks and hardware,
letting computers and networks of any type talk together reliably (Gourley et al, p.12,
2002).
1.3.1.2
HTTP
HTTP (HyperText Transfer Protocol) is the protocol for the exchange of Web-based
information between Web browsers and Web servers (Stallings, p.726, 2000). HTTP uses
reliable data-transmission protocols, it guarantees that your data will not be damaged or
scrambled in transit, even when it comes from the other side of the globe (Gourley et al,
p.3, 2002).
1.3.1.3
Web Browser
Web browser is software that gives a user access to the World Wide Web. Web browsers
provide a graphical interface that lets users click buttons, icons, and menu options to view
and navigate Web pages (Google, 2005).
1.3.1.4
Hyperlink
Hyperlink is a graphic or text string which, when clicked, opens a new web page or
jumps
to
a
new
location
in
the
current
page
(Amberton
University,
http://www.amberton.edu/VL_terms.htm, 2004).
1.3.2
Database Management System
A Database Management System is software designed to assist in maintaining and
utilizing large collections of data (Ramakrishnan et al, p.4, 2003). Using a DBMS to
manage data has many advantages: (Ramakrishnan et al, p.9, 2003)
Data Independence: Application should not, ideally, be exposed to details of data
representation and storage. The DBMS provides an abstract view of the data
that hides such details.
Efficient Data Access: A DBMS utilizes a variety of sophisticated techniques to
store and retrieve data efficiently. This feature is especially important if the
data is stored on external storage devices.
Data Integrity and Security: If data is always accessed through the DBMS, the
DBMS can enforce integrity constraints. Also, it can enforce access controls
that govern what data is visible to different classes of users.
Data Administration: When several users share the data, centralizing the
administration of data can offer significant improvements.
Concurrent Access and Crash Recovery: A DBMS schedules concurrent accesses
to the data in such a manner that users can think of the data as being accessed
by only one user at a time. Further, the DBMS protects users from the effects
of system failures.
Reduced Application Development Time: Clearly, the DBMS supports important
functions that are common to many applications accessing data in the DBMS.
This, in conjunction with the high-level interface to the data, facilitates quick
application development.
1.3.3
.NET Framework
A programming infrastructure created by Microsoft for building, deploying, and running
applications and services that use .NET technologies, such as desktop applications and
Web services. The .NET Framework contains three major parts: the Common Language
Runtime (CLR), the Framework Class Library, and ASP.NET (Developer.com Staff &
Murray, 2003).
1.3.4
Web Services
Web Services is a set of standards and protocols that allow web applications to talk to
each other. Web services are built on standard web technologies, such as HTTP. Web
services exchange information using XML over SOAP. The Extensible Markup
Language (XML) provides a way to create and interpret customized information about a
data object. The Simple Object Access Protocol (SOAP) is a standard for adding XML
information to HTTP messages (Gourley et al, p.206, 2002).
1.3.5 Definition of Usability
Usability is to determine how easy an interface design is to understand and use.
User-friendly document will let the user read or play any content at will; it will have an
ambigous interactive controls and a clear navigational scheme. (Lisa Graham, The
Principals of Interactive Design, 1999 quoted on Elizabeth Breunner Splash Three,
http://www.csc.calpoly.edu/~ebreunner/VocabWebDesign.html, 1999). Usability is the
measure of a product potential to accomplish the goals of the user (Iowa Public
Television, http://www.iptv.org/digital/dictionary_internet.cfm, 1995).
1.3.6 Definition of Usefulness
Usefulness is the quality of being of practical use (WordNet – Princeston
University Cognitive Science Laboratory, http://wordmap.princeston.edu/perl/webwn,
2005).
1.3.7 Definition of Efficiency
Effeciency is the ratio of an output to the input of any system (WordNet –
Princeston
University
Cognitive
http://wordmap.princeston.edu/perl/webwn, 2005).
Science
Laboratory,