WIKI KNOWLEDGE MANAGEMENT SYSTEM DOCUMENTATION
Daniel David Alden
B.S., Northern Illinois University, 2005
PROJECT
Submitted in partial satisfaction of
the requirements for the degree of
MASTER OF SCIENCE
In
BUSINESS ADMINISTRATION
(Management Information Systems)
at
CALIFORNIA STATE UNIVERSITY, SACRAMENTO
SUMMER
2010
© 2010
Daniel David Alden
ALL RIGHTS RESERVED
ii
WIKI KNOWLEDGE MANAGEMENT SYSTEM DOCUMENTATION
A Project
by
Daniel David Alden
Approved by:
__________________________________, Committee Chair
Russell Ching, Ph.D.
____________________________
Date
iii
Student: Daniel David Alden
I certify that this student has met the requirements for format contained in the University format
manual, and that this project is suitable for shelving in the Library and credit is to be awarded for
the project.
__________________________
Monica Lam, Ph.D
Associate Dean for Graduate and External Programs
College of Business Administration
iv
___________________
Date
Abstract
of
WIKI KNOWLEDGE MANAGEMENT SYSTEM DOCUMENTATION
by
Daniel David Alden
Statement of Problem
The California Department of General Services (DGS) can potentially lose many
employees, and subsequently lose much of the knowledge that these employees have
gained in their tenure with the department.
Sources of Data
The information was gathered through reviewing online academic journals,
professional websites, and on the job experience.
Conclusions Reached
DGS needs a Knowledge Management System. A Wiki best meets the
department’s knowledge management needs. The Wiki Knowledge Management System
will be written using Microsoft’s .Net and Microsoft SQL Server 2005.
_______________________, Committee Chair
Russell Ching, Ph.D.
_______________________
Date
v
TABLE OF CONTENTS
Page
List of Tables ......................................................................................................................... vii
List of Figures ....................................................................................................................... viii
Chapter
1. INTRODUCTION ............................................................................................................ 1
2. PROJECT INITIATION ..................................................................................................... 2
Problem ........................................................................................................................ 2
Solution ........................................................................................................................ 3
Benefits ........................................................................................................................ 3
Solution Alternatives ................................................................................................... 5
Project Scope ............................................................................................................... 7
Conclusion ................................................................................................................... 7
3. REQUIREMENTS GATHERING PHASE ........................................................................ 9
Introduction.................................................................................................................. 9
Functional Requirements ............................................................................................. 9
Nonfunctional Requirements ..................................................................................... 14
Accessibility ................................................................................................. 14
Compliance ................................................................................................... 15
Disaster Recovery ......................................................................................... 15
Security ......................................................................................................... 16
Usability ........................................................................................................ 17
Conclusion ................................................................................................................. 17
4. DESIGN PHASE .............................................................................................................. 18
Introduction................................................................................................................ 18
User Interface Tier ..................................................................................................... 19
Business Logic Tier ................................................................................................... 29
Data Access Tier ........................................................................................................ 31
Workflow Descriptions .............................................................................................. 32
Database Design ........................................................................................................ 40
vi
Conclusion ................................................................................................................. 49
5. CONCLUSION ................................................................................................................. 51
Appendix Use Cases ............................................................................................................... 53
Works Cited ............................................................................................................................ 61
vii
LIST OF TABLES
Page
1. Create New Topic Use Case ........................................................................................... 53
2. View Topic Use Case ...................................................................................................... 54
3. Edit Topic Use Case ........................................................................................................ 55
4. View Topic Index Use Case ........................................................................................... 56
5. Search Use Case .............................................................................................................. 57
6. View Topic History Use Case ......................................................................................... 58
7. View Archived Topic Use Case ...................................................................................... 59
8. Roll Back Topic Use Case .............................................................................................. 60
viii
LIST OF FIGURES
Page
1.
Use Case Diagram ......................................................................................................... 13
2.
Initial Domain Model .................................................................................................... 14
3.
Application Architecture ............................................................................................... 19
4.
Wiki Knowledge Management System Master Page .................................................... 22
5.
Create Topic Page ......................................................................................................... 23
6.
View Topic Content Page ............................................................................................. 24
7.
Edit Topic Page ............................................................................................................. 25
8.
View Topic Index Content Page ................................................................................... 26
9.
Search Results Content Page ......................................................................................... 27
10 View Topic History Content Page ................................................................................ 28
11. View Archived Topic Content Page ............................................................................. 29
12. Class Diagram ................................................................................................................ 31
13. New Topic Sequence Diagram ..................................................................................... 33
14. View Topic Sequence Diagram .................................................................................... 34
15. Edit Topic Sequence Diagram ...................................................................................... 35
16. View Index Sequence Diagram .................................................................................... 36
17. Search Sequence Diagram ............................................................................................ 37
18. View Topic History Sequence Diagram ....................................................................... 38
19. Roll Back Sequence Diagram ....................................................................................... 40
20. Topic Table DDL Code ................................................................................................ 41
21. ArchivedTopic Table DDL Code .................................................................................. 42
22. CreateTopic Stored Procedure DDL Code .................................................................... 43
ix
23. RetrieveTopic Stored Procedure DDL Code ................................................................ 43
24. EditTopic Stored Procedure DDL Code ....................................................................... 44
25. ViewTopicIndex DDL Code ......................................................................................... 45
26. SearchTopics Stored Procedure DDL Code .................................................................. 46
27. ViewTopicHistory Stored Procedure DDL Code ......................................................... 47
28. CreateArchivedTopic Stored Procedure DDL Code ..................................................... 48
29. FindNextVersionNumber Database Function DDL Code ............................................ 48
30. RetrieveArchivedTopic Stored Procedure DDL Code .................................................. 49
x
1
Chapter 1
INTRODUCTION
This Master’s Project is software documentation for a Knowledge Management
Information System that would be utilized by the Office of Technology Resources at the
California Department of General Services. The project begins in the Concept Phase,
continues into the Requirements Gathering Phase, and completes in the Design Phase.
Upon completion, the material of this project will be delivered to a development team,
and the development team will continue the project through development, testing, and
implementation.
Background
The California Department of General Services (DGS) is the California State
Government’s business manager. DGS provides many distinct services including
managing State real estate, managing the State’s automotive fleet, managing State
procurement, and providing printing services to State Agencies. DGS has over 4,000
employees and a budget of over one billion dollars.
The Office of Technology Resources (OTR) is part of the DGS Information
Technology Services Division (ITSD). OTR provides technology support services for the
entire department. Services include servers and hosting, application support, and systems
development. Additionally, OTR provides technology services for other smaller agencies
including the Office of Fair Employment and Housing, State Personnel Board, California
Building Standards Commission, and Victim Compensation and Government Claims
Board.
2
Chapter 2
PROJECT INITIATION
Problem
Zack (1999) defines knowledge as the “organized accumulation of information
(messages) through experience, communication, or inference” (Zack, 1999, 46).
Knowledge is as important as traditional assets such as land, labor, and capital (Swan and
Scarbrough 1). Regardless of this fact, many organizations do a subpar job of capturing
knowledge. A survey by Frappaolo and Wilson (2003) goes to show that 68% of
knowledge is not retained in an information system; much of this stored in the heads of
employees. When knowledge is stored in the heads of employees, it is lost when that
employee leaves the organization. An employee’s longevity with a firm is not what it
once was. The median tenure of an employee is four and one half years (Droege and
Hoobler, 2003). Couple this with the impending retirement of the “baby boomer”
generation, and there is a cause for alarm. When an employee leaves the organization,
they take a portion of their knowledge with them. American Management Association
states, "The direct cost of losing a key employee can be as much as 18 months' salary"
(Laing, Poitier, Ferguson, Carraher, and Ford, 2009, 11). A portion of this cost relates to
the loss of knowledge.
Nearly 78 million “Baby Boomers” are nearing retirement in the Bahamas, Japan,
and USA (11). The State of California Government is no different. Department of
Personnel Administration (DPA) figures indicate that 16% of the State’s workforce is age
3
50 or older. The DPA goes on to state that 62% of executives, 50% of management, and
35% of rank and file employees are eligible to retire within the next five years.
(http://www.dpa.ca.gov/personnel-policies/workforce-planning/demographics-and-laborstatistics.htm).
Solution
The OTR needs a Knowledge Management System (KMS) in order to mitigate
the risk of organizational change due to employee turnover and to leverage the many
benefits that a KMS can provide an organization.
Functional Requirements
The OTR needs an easily accessible KMS. The implemented solution needs to
fit within the department’s current Microsoft environment (servers, databases, active
directory, etc.). It needs to be web enabled, because there is not enough support to install
a client on each individual’s PC. The knowledge entry mechanism needs a quick and
simple method to document their experiences. This system needs to be searchable by
other employees so they can utilize the knowledge.
Benefits
There are many intangible benefits for a KMS. A KMS represents a process
improvement that benefits many areas of the organization. Swan and Scarbrough state,
“By capturing, stockpiling, and transferring greater quantities of knowledge; the
organization’s performance will be automatically improved.” Valuable knowledge leads
4
to better customer relationships. A KMS represents a large investment in the
organization's intellectual capital.
With the use of a KMS, employees should notice their daily activities become
easier and increase employee morale. Furloughs and budget cuts have brought down the
morale of the OTR staff. If tasks can become easier, the staff will increase their morale.
Yu, Chang, and Liu (2006) add the following intangible benefits: “reputation of the firm,
knowledge repository of the firm, growth of experience and knowledge of the staff, and
cultural of knowledge sharing of the firm”. Recently DGS has had some bad press.
Anytime the Department can improve their reputation is a bonus. If the “corporate
culture” of OTR changes to one that promotes knowledge sharing; OTR can become a
choice employer within the State.
Organizationally, OTR assigns information systems to a single developer for
support without a backup. It is common for a developer to support multiple applications.
Some information systems generate revenue for the Department of General Services. If
one of these systems were to “crash” and if the supporting developer were not available,
the Department would lose revenue while another developer researched the system, and
then fixed it. A KMS can greatly improve the problem solving abilities of the
organization, which can translate into tangible benefits. If knowledge about the system
were stored in a KMS, less time would be needed to associate one’s self with a system.
5
Yu explains that there are many additional benefits garnered from a KMS. “A
KMS can lead to time shortening, cost reduction, and man-hour saving” (Yu, Chang, and
Liu, 2006). A KMS would reduce the amount of time needed to research problems,
mitigate the risk of not having a key staff member, and free up developers to perform
other tasks. Potentially many new, not yet developed, information systems could either
generate revenue for the Department or provide efficiencies to the current business
practices of the Department’s business units. If developers spent less time fixing
problems, they could dedicate more time to develop these new information systems.
Solution Alternatives
The solution to this problem is an electronic online KMS. The KMS needs to
meet the following criteria:

Inexpensive to develop

Easily accessible

Requires little to no maintenance

Ability to scale

Must be hosted on the Corporate Intranet
The first alternative is to provide a ListServ. A ListServ is a mass emailing tool in
which users subscribe. To utilize a ListServ as a KMS, a piece of knowledge would be
given to the ListServ administrator and then this information would be disseminated to all
the subscribers. The advantages of a ListServ are that ListServs are scalable and simple.
6
Disadvantages are that they are centralized to the administrator and the knowledge is
stored in email.
The second alternative is to provide Web Logs to employees. Web Logs (or
Blogs) allow employees to keep a journal of their experiences. These experiences are
then displayed via a web site in reverse chronological order.
A third alternative is to persist the knowledge as static web pages in the Corporate
Content Management System (CMS). The Corporate CMS allows CMS Authors to
create HTML web pages that are accessible on the Corporate Intranet. Advantages to
using the CMS are that the technology is already in place, some CMS Authors are already
trained, and the CMS is scalable. Disadvantages of the CMS are that each page is stored
as a separate file in a file system, CMS pages are “owned” by its author, and training the
entire staff to become a CMS author could prove to be infeasible.
The final alternative is to create a Wiki. A Wiki is a set of linked web pages,
crated through the incremental development by a group of collaborating users (Leuf and
Cunningham, 1999). Advantages to a Wiki are that all Wiki users are allowed to
contribute, there is a small number of web pages to maintain, and the knowledge is stored
centrally in a database. Disadvantages to a Wiki are that the department does not
currently have the technology; so a Wiki engine needs to be purchased or developed.
7
Based on the current environment, and ease of implementation, the recommended
alternative to achieve the solution is to develop a Wiki. The Wiki will be developed
using the Department’s development standards, and developed by in-house staff.
Project Scope
The key deliverable for this project is a web-based information system. The purpose of
this information system is to retain employee knowledge through the submission of articles.
Important functions of this system include in-depth searching, user provided content, and article
association.
The scope of this project is to provide the core functionalities of the system. Any
enhancements can be added at a future date and can be considered a separate project. The
functionalities included in this project are: the ability to create new content, view existing
content, edit existing content, archive past versions of existing content, search existing content,
view an index of existing content, and view the archives of a piece of content.
Conclusion
Knowledge is important to the success of an organization. Unfortunately, much
of the knowledge within an organization is stored in the heads of the employees. The
tenure of employees is not very long and there is potential for large employee exodus in
the next five years due to the impending retirement of the baby boomer generation.
In order to mitigate the risk of losing large amounts of organizational knowledge,
the Office of Technology Resources (OTR) needs to create a Knowledge Management
System (KMS). A KMS allows employees to duplicate the knowledge they possess into
8
an information system. The KMS is searchable, and other employees can utilize the
knowledge from the system in their work.
A KMS has many benefits for OTR. Improved knowledge sharing creates
efficiencies that will create higher employee productivity. Working conditions have not
been ideal for OTR employees, and a KMS can improve morale by making tasks simpler.
There are many alternative architectures to implement a KMS at OTR. One
alternative is to implement a ListServ. A ListServ relies on a central administrator that
pushes knowledge out to employees via email. A second alternative are web logs (blogs).
Blogs provide employees an outlet to discuss their experiences. The third alternative is to
create static web pages in the department’s content management system (CMS). The
CMS pages are easy to publish and search, but they lack interactivity. The final
alternative is to implement a Wiki. A Wiki is similar to CMS pages, but Wiki topics are
simpler to create, are interactive, and historical versions of topics are stored for archives.
Due to the features provided, a Wiki is the chosen architecture. The requirements
for the OTR Wiki KMS include the ability to create topics, view topics, edit topics,
search topics, view topic indexes, and view historical versions of topics. The Wiki will
be web based to eliminate the need for client software installation. OTR development
staff will create the Wiki and deploy it to OTR servers.
9
Chapter 3
REQUIREMENTS GATHERING PHASE
Introduction
This chapter decomposes the requirements proposed in the Project Initiation
Phase. First, the Actors (types of users) are identified. Next, the functional requirements
are represented from the actor’s point of view using Use Cases. After the functionalities
are discussed, a preliminary domain model of the system will be discussed. Finally, all
the nonfunctional requirements that business practices and departmental policies require
will be discussed. The creator of the first Wiki, Ward Cunningham, states that there were
twelve design principles he had in mind when he created the first wiki, “WikiWikiWeb”
(Cunningham, 2009). The OTR KMS Wiki follows many of Cunningham’s design
principles.
Actors
Cunningham’s open design principle states that “any reader can edit it as he/she
sees fit” and the Universal design principle states “any writer is automatically an editor
and organizer” (Cunningham, 2009). Therefore, this system only has one actor, the Wiki
User.
Functional Requirements
The method to outline the functionalities of the system is through a series of Use
Cases. “A Use Case is the specification of a set of transactions between the system and
the external actors, thus, it may be described in terms of the interactions between the
10
system and the external actors” (J. Garcia, Carretero, Perez, F. Garcia, and Filgueira,
2005, p. 1). This chapter will narratively describe the Use Cases, and the detailed Use
Case specifications can be found in Appendix A.
The first Use Case is the Create New Topic Use Case (UC1). A topic is the
base unit of data in the Wiki Knowledge Management System. The Create New Topic
Use Case is initiated either by a hyperlink on the Master Page or by starting the View
Topic Use Case with a non-existent topic. Cunningham’s mundane design principle
states that the content of a topic is created using a small set of “text conventions” which
will produce the page’s markup (Cunningham, 2009). After the actor has provided a title
and content, the actor will store the topic in the data store. The Create New Topic Use
Case concludes with a call to the View Topic Use Case.
The next Use Case is the View Topic Use Case (UC2). This will be the primary
Use Case for the Knowledge Management System. The actor initiates the Use Case by
visiting the default wiki web page. A precondition to this Use Case is that there should
be a topic name provided. If there is not a topic name provided, the system would load
the root topic by default. The system then retrieves the data for the topic from the data
store. Cunningham’s overt design principle suggests that the topics are displayed just as
they are formatted when they were created. The incremental design principle specifies
that “Pages can cite other pages, including pages that have yet to be written”
(Cunningham, 2009). Therefore, if a topic name is provided and it does not currently
exist in the system, the View Topic Use Case will call upon the Create New Topic Use
11
Case. The actor will also have the ability to initiate the Edit Topic Use Case from the
View Topic Use Case.
The Edit Topic Use Case (UC3) serves Cunningham’s open design principle
(Cunningham, 2009). This Use Case begins when the actor selects to edit a topic on the
View Topic Content Page. The Edit Topic Use Case redirects to the Edit Topic Content
Page which is created in accordance to the mundane design principle (Cunningham,
2009). Once the topic is edited, the actor persists the topic. In the Edit Topic Use Case
the previous version of the topic is also persisted in an archived data store.
Create New Topic, View Topic, and Edit Topic are the basic functionalities
required by a basic wiki. Business practice has additional requirements. The first
additional requirement involves being able to locate a topic in the Knowledge
Management System. This comprises of two Use Cases. The first is the View Topic
Index Use Case (UC4). The View Topic Index Use Case is initiated by a hyperlink on
the View Topic Content Page. The Wiki Index Page displays every topic in the system
alphabetically. Each index entry is a hyperlink to the View Topic Content Page for the
given topic name.
The second “location” Use Case is a search engine. The Search Use Case (UC5)
is initiated by a search term box and a submit button on the View Topic Content Page. If
the system returns a single result related to the search term, the topic is shown on the
View Topic Content Page. If multiple results are returned, the results are displayed on
the Wiki Index Page. If no results are returned, a message is displayed to the actor.
12
Another characteristic of a wiki is that they contain “dynamically changing
knowledge” (Wagner 276). The Knowledge Management System needs to be able to
access previous versions of a topic; the View Topic History Use Case (UC6). The View
Topic Use Case is initiated by a View Topic History hyperlink on the View Topic
Content Page. Once initiated, this Use Case displays the Topic History Page. The Topic
History Index Page lists each entry for the topic in the archived data store. Each topic
history displayed on the page and is a hyperlink to display the content of the topic history
record on the View Topic Content Page.
Once the Wiki User is presented with a list of archived topics, the Wiki User
may select to view one of the archived topics. The View Archived Topic Use Case is
nearly identical to the View Topic Use Case (UC2). The difference is that the archived
topic is retrieved from the archived topic data store.
Along with displaying the previous versions of a topic, the Wiki Knowledge
Management System will allow for “rolling back” to a previous version of a topic. In
essence, a roll back is a special implementation of the Edit Topic Use Case (UC3).
Instead of the Wiki User providing the content for an edit, a roll back retrieves the
previous version of the topic and replaces the content in the Topic Data Store. For the
sake of these requirements, the Roll Back Use Case (UC8) will be separate from the Edit
Topic Use Case.
Figure 1 is the UML Use Case Diagram for the OTR Wiki Knowledge
Management System. A UML Use Case Diagram graphically represents the
functionalities by actors of a system. The Wiki User Actor is the only actor and it is
13
represented on the left side of the diagram. The Use Cases are connected to the Wiki
User Actor and are represented on the right side of the diagram.
Figure 1-Use Case Diagram
14
Based on the requirements represented in the Use Cases, there are two entities in
the Domain Model. A domain model is a high-level representation of the entities
involved in the system. The entities in this system are the User (Wiki User Actor) and
the Topic. The connectors in the domain model are generic representations of Use Cases.
Figure 2 represents the Initial Domain Model.
Figure 2-Initial Domain Model
Nonfunctional Requirements
Accessibility
Website accessibility standards for entities of the State of California are dictated
by three groups: The State of California Office of the State Chief Information Officer,
the Information Organization, Usability, Currency, and Accessibility (IOUCA) Working
Group, and the California Department of Rehabilitation. In June 2006, the groups met
and adopted a policy that required all State websites must conform to the World Wide
Web Consortium (W3C) Web Content Accessibility Guidelines 1.0 (WCAG 1.0) at an
“AA” Conformance Level. Additionally, the Department of Rehabilitation has proposed
five best practices specifically to accommodate those with disabilities. Visual Studio
Team Suite 2008, OTR’s standard development environment, contains a accessibility
15
checker that will scan source code and verify that it complies with WCAG 1.0. When
possible, it will suggest solutions to improve the system’s WCAG 1.0 compliance.
(http://www.webtools.ca.gov/Accessibility/State_Standards.asp)
Compliance
Since this project will be completed by an entity within the State of California; all
IT projects must comply with the Statewide Information Management Manual (SIMM).
According to the State of California Office of the State Chief Information Officer, the
SIMM contains “the instructions and guidelines needed to implement IT policy”
(http://www.cio.ca.gov/Government/IT_Policy/introduction.html). SIMM policy
includes Disaster Recovery (SIMM Section 5B and 65A), IT Project Reporting (SIMM
Section 10), the California Project Management Methodology (SIMM Section 17),
Feasibility Study Report (SIMM Section 20), Information Technology Project Oversight
Framework (SIMM Section 45), and Post Implementation Evaluation Report (SIMM
Section 50) (http://www.cio.ca.gov/Government/IT_Policy/SIMM.html).
Aside from the SIMM, OTR development staff must follow the Department of
General Service’s Design and Development Standards of Development. These
guidelines dictate how a project is billed to the customer business units, the Department’s
system development life cycle, and the Department’s project acceptance procedures.
Disaster Recovery
SIMM Section 65A describes the requirements that a State Agency needs to
include in the Disaster Recovery Plan (DRP). One portion of the DRP requires that the
Agency describe the applications that support their “critical business functions” A KMS
16
should be considered essential to the operation of the Department. The KMS will include
knowledge that is important to the further recovery from the disaster.
(http://www.cio.ca.gov/OIS/Government/documents/pdf/SIMM%2065ADRP_Doc_Instructions.pdf)
The KMS being proposed in this paper requires two elements to function. The
data for the system will be stored in one of the Department’s corporate databases. This
database will be backed up according to the department’s backup procedures. As part of
these backup procedures, backups are regularly stored off site in case of a catastrophic
loss of the Department’s IT facilities.
The second portion of the system is the presentation and business logic of the
application. These elements are important to the creation and retrieval of the data. The
source code for the application will be backed up in another of the Department’s
databases. In case of a disaster, this source code can be built, compiled, and deployed.
The procedure for recovering this application begins with the installation of a web
server and database server. Next, the KMS database needs to be restored. Following the
restoration of the data, the presentation and business logic needs to be installed on a web
server. Finally, a quick series of tests will test the retrieval, creation, updating, and
search features of the system.
Security
The Open Web Application Security Project (OWASP) is a worldwide
organization that sets standards for software application security. OWASP continuously
monitors application security, and maintains a list of the top ten security vulnerabilities;
17
the OWASP Top Ten (http://www.owasp.org/index.php/Top_10_2007 ) . The
Department of General Services Office of Information Security expects that all systems
developed for the Department to adequately address the OWASP Top Ten. To verify
compliance with the OWASP Top Ten, OTR utilizes the Fortify 360 security software.
Fortify 360 will scan the source code and validate the top ten. Fortify 360 integrates into
Visual Studio, and, if necessary, proposes solutions to fix problems. As part of system
completion, the Information Security Office requires that the development team provides
a successful Fortify 360 security audit confirmation.
Usability
In order to achieve customer acceptance, the Knowledge Management System
must be satisfactorily usable by customer standards. The Information Organization,
Usability, Currency, and Accessibility (IOUCA) Working Group have recommended six
best practices related to usability
(http://www.webtools.ca.gov/Usability/Best_Practices.asp). Prior to the release of the
system, an OTR Usability expert will review the system and certify that the system
sufficiently meets the Department’s usability guidelines.
Conclusion
The Requirements Gathering Phase breaks down the expected behaviors of the
system and creates a better understanding of them. The functional requirements are
represented by a series of Use Cases. Additionally, the Requirements Gathering Phase
detailed the non-functional requirements needed to either support business practice or
adhere to policy.
18
Chapter 4
DESIGN PHASE
Introduction
The Knowledge Management System will be written using a three-tier approach.
According to Manuel and AlGhamdi (2003), the three-tier architecture allows for
scalability, portability, and extensibility (Manuel and AlGhamdi, 2003, 197). Scalability
is important of this system, because it allows developers to easily allow other business
units outside of OTR to use the system. OTR management have requested that
applications be designed for mobile devices along with personal computers, therefore the
portability of the three-tier architecture will be an advantage. Often end users request
functionality that is not originally in the system. The extensible nature of the three-tier
architecture simplifies task of adding features.
The first of the three tiers is the user interface tier. In the Wiki Knowledge
Management system the user interface is made up of Microsoft ASP.Net Web Forms.
The second tier is the business logic tier. The business logic tier in the Wiki Knowledge
Management System will be a series of class libraries written in C#. The third tier is the
data access tier. The data access tier in the Wiki Knowledge Management System is also
a series of class libraries that utilize Microsoft’s Data Access Application Block.
19
Figure 3-Application Architecture
User Interface Tier
The User Interface Tier (UI) is built using Microsoft ASP.Net Technology.
According to the Microsoft Developer Network (MSDN) ASP.Net is, “ a unified Web
development model that includes the services necessary for you to build enterprise-class
Web Applications with a minimum coding” (http://msdn.microsoft.com/enus/library/4w3ex9c2.aspx). The UI will handle all the system interaction, data entry, and
navigation aspects of the Wiki Knowledge Management System. The UI calls upon the
Business Logic Tier for much of the processing needed by the system. The Business
Logic Tier in turn will return messages to the UI and the UI will relay these messages to
the Wiki User.
The UI for the Wiki Knowledge Management System is an ASP.Net Website. An
ASP.Net Website is made up of three portions that work together to create the “Screens”
in which a Wiki User utilizes. The first portion of a ASP.Net Website is the Master Page.
A Master Page creates a common look and feel throughout the application. Master Pages
contain the common elements shared throughout the UI. For example, the Master Page
provides common layout elements such as the header, body, and footer. The Master Page
will also contain common coding elements that are universal to all the UI screens such as
references to style sheets and client side scripting (such as JavaScript) By placing these
20
elements in the Master Page, this eliminates the need to place these elements on every
single screen. Master Pages also contain Content Placeholders. Content Placeholders are
an area of the screen in which Content Pages can place content.
The next portion of an ASP.Net Website is a series of Content Pages. Content
Pages are bound to the Master Page. There are many Content Pages throughout the
system. Within the Wiki Knowledge Management System each Use Case will be
logically separated by placing its functionality within its own Content Page. When a
Content Page is viewed in a WYSIWYG editor, the Master Page elements are visible but
are “grayed out”. All the Content Page specific elements are placed within the Master
Page’s Content Placeholders. These Content Placeholders will contain all the Web
Controls such as Labels, Text Boxes, Buttons, Hyperlinks, etc.
Content Pages also contain a Code-Behind. A Code-Behind allows the
programmer to keep the markup elements separate from the programming elements.
Within the Wiki Knowledge Management System, the Code-Behind contains logic that
validates data, calls Business Logic Tier methods, displays information to the Wiki User,
and provides screen to screen navigation. (http://msdn.microsoft.com/enus/library/015103yb.aspx)
The final portion of an ASP.Net Website is the collection of Web Controls. These
Web Controls are placed in the Content Placeholder of the Content Page, and are used to
display information, capture data entry, or fire system events. One Web Control the Wiki
Knowledge Management System utlizies is the Label. A Label simply displays formatted
text to the Wiki User. Another Web Control is the Text Box. A Text Box allows the
21
Wiki User to enter a simple string of characters that will be processed by a system event
such as a search. A HTML Editor is an advanced WYSIWYG Text Box that allows the
Wiki User to provide formatting such as Bold, Underline, Italics, etc. A Hyperlink is a
Web Control that provides navigation either from one screen to the next or navigation
outside the system entirely. The next series of Web Controls are the Buttons. A Button
fires a system event in the Code Behind. A standard Button is a raised gray rectangle that
contains text. A LinkButton is a hyperlink that functions as a button.. An ImageButton
is an image that functions as a button.
Figure 4 shows the Master Page for the Wiki Knowledge Management System.
This Master Page implements the design rules prescribed by The State of California
eServices (http://webtools.ca.gov/). This includes department level branding in the
heading. Next, the Master Page implements a tabular design for navigation. The tabs in
this system represent different use cases. The left portion of the Master Page has a
universal search box that will be located at the same position on all Content Pages in the
Wiki Knowledge Management System. Below the search box is another set of
navigation. Within the main portion of the Master Page is the primary content
placeholder. This content placeholder will contain the specific functional areas of each
content page. Finally, the Master Page has the standard eServices footer at the bottom.
This footer includes hyperlinks to departmental Internet resources and access to various
viewers for non-standard Internet document types.
22
Figure 4 - Wiki Knowledge Management System Master Page
Like all the Content Pages within the Wiki Knowledge Management System, the
Create New Topic Content Pages implements the Wiki Knowledge Management System
Master Page. Figure 5 shows the Create New Topic Content Page. Within the main
content placeholder are a Label and a Text Box which will be used for the entry of the
name of the topic. If the Wiki User attempts to view a non-existent topic, this topic name
will populate in the topic name text box. Below the topic name text box is a large HTML
Editor Web Control. This is the location where the Wiki User will enter the content for a
Wiki Topic. Below the Content HTML Editor Web Control are two buttons. The first
button is the Save Button. This Save Button initializes the Create Topic Use Case. The
second button is a Cancel Button which will redirect the system to the View Topic
23
Content Page. Finally, the bottom of the Create Topic Content Page has a Label that
contains some helpful hints for the Wiki User.
Figure 5- Create Topic Page
The View Topic Content Page is also known as the View Topic Content Page.
This page is used to display topics to the Wiki User. The topmost element within the
main content placeholder on the View Topic Content Page is the Title Label. This Label
displays the name of the current topic. Just below the Title Label is a Label Web Control
that displays who and when the topic was last updated. Below the Last Updated Label
the Content Label. The Content Label displays the HTML formatted contents of the
Topic. This Label may contain text, images, internal hyperlinks, and external hyperlinks.
Internal Hyperlinks are links to other Wiki Topics. If an Internal Hyperlink refers to an
existing topic, the text will appear blue, and if the topic does not exist the text will appear
red. External Hyperlinks appear blue and underlined. Below the Content Label is the
24
Edit Button. This Button redirects the system to the Edit Topic Content Page for the
current topic. Finally, there is a LinkButton Web Control at the bottom that is used to
redirect the system to the View Topic History Content Page. Figure 6 shows the View
Topic Content Page.
Figure 6 - View Topic Content Page
The Edit Topic Content Page (see Figure 7) is similar to the Create Topic Content
Page. The primary difference is that this Content Page will not allow the Wiki User to
change the name of the topic. Therefore, there is no Topic Name Text Box at the top.
Instead there is a Label that displays the name of the current topic. After the Name Label
there is an HTML Editor Web Control. This is identical to the Create Topic Content
Page. Below the HTML Editor Web Control is a Save Button that initiates the Edit Topic
Use Case. Additionally, there is a Cancel Button that will redirect the system to the
25
Views Topic Content Page for the currently viewed topic. Finally, there is an identical
Hint Label to the one found on the Create Topic Content Page.
Figure 7 - Edit Topic Page
The main content placeholder for the View Topic Index Content Page begins with
a LinkButton for each letter of the alphabet. Figure 8 shows the View Topic Index
Content Page. This allows the Wiki User to filter the index alphabetically. Additionally,
there is also a LinkButton that will show all topics. Below the filtering LinkButtons are
two columns. The left column is the list of topic names sorted alphabetically. Each entry
in this column is a hyperlink to the View Topic Content Page for the given name. The
right column is the date and time that the topic was last updated.
26
Figure 8 - View Topic Index Content Page
The Search Results Content Page (see Figure 9) is similar to the View Topic
Index Content Page. The Wiki User reaches the Search Results Content Page by using
the wiki search (which is a component of the Master Page). The Search Results Content
Page requires a search term parameter prior to loading. If no such parameter is provided,
a Label displays an error message. Prior to loading content onto the page, the Search
Results Content Page initiates the Search Use Case. This Use Case will return zero to
many matching results from the Wiki Data Store. If no topics are returned, an
appropriate message is displayed to the Wiki User. If a single result is returned, the
Search Results Content Page will redirect the system to the View Topic Content Page for
the returned topic. If multiple results are returned, the system will display the results in
two columns identical to the View Topic Index Content Page.
27
Figure 9 - Search Results Content Page
The View Topic History Content Page displays an archived list of versions for a
topic. Each time an Edit Topic Use Case is initiated for a topic, an archived version is
created. The View Topic History Content Page displays an Instruction Labe that directs
the Wiki User select a version to view its content. Below this Instruction label is a list of
versions. Each entry in the list contains a Select LinkButton. By clicking this
LinkButton, the system redirects to the View Archived Topic Content Page. Next to the
Select LinkButton is the date and time that the version was saved. Figure 10 shows the
View Topic History Content Page.
28
Figure 10 - View Topic History Content Page
The View Archived Topic Content Page (Figure 11) is designed to be almost
identical to the View Topic Content Page. In fact, the only difference is that the View
Archived Topic Content Page adds an additional button. This additional button (located
at the top of the main content placeholder) is labeled “Roll Back”, and initiates a restore
archived version use case. This is used as a rollback mechanism for the Wiki Knowledge
Management System.
29
Figure 11 - View Archived Topic Content Page
Business Logic Tier
The second tier of the application is the Business Logic Tier. According to
Robert Chartier the Business Logic Tier is where the business objects and business rules
are located (http://www.15seconds.com/issue/011023.htm). Joseph Reddy defines
business objects as, “a code construct that corresponds directly to a thing in the actual
business the software is meant to represent”
(http://swcses.eponym.com/blog/_archives/2006/9/19/2341371.html#BODef).
Meanwhile a business rule “is intended to assert business structure or to control or
influence the behavior of the business”
(http://www.businessrulesgroup.org/first_paper/br01c1.htm#s1e). The Business Logic
Tier separates these elements from what the user sees (Presentation Tier) and how the
system interacts with data (Data Access Tier).
30
There are two business objects in the Wiki Knowledge Management System. The
first object is the Topic Object. The Topic Object has five attributes. The first attribute
is the topic’s name. The second attribute is the content that is contained in the topic. The
next attributes who saved the topic and when it was saved. Finally, the topic contains a
incremental numeric value that tracks the current version of the topic.
The business rules for the Topic Object are captured in the form of methods. The
methods are the actions that the object performs. Additionally, the business rules
elaborate use cases captured during requirements gathering. The Topic Object methods
include CreateTopic, ViewTopic, EditTopic, ViewTopicIndex, and SearchTopics. The
Topic Object also has a FormatTopic method that converts Wiki Markup into HTML that
is displayed in the Presentation Tier.
The second business object in the Wiki Knowledge Management System is an
ArchivedTopic. An Archived Topic Object contains the same five attributes as the Topic
Object. The Archived Topic Object methods include CreateArchivedTopic,
RetrieveArchivedTopic, RollBackTopic, and ViewTopicHistory. The Archived Topic
Object also has a FormatTopic method.
Figure 12 shows the shows the Business Logic Tier represented by a UML Class
Diagram.
31
Figure 12 - Class Diagram
Data Access Tier
The Data Access Tier separates the data access functionality from the business
rules and presentation. Chartier explains that the Data Access Tier contains no data logic
and it is just a “reusable interface” for the database
(http://www.15seconds.com/issue/011023.htm). The Wiki Knowledge Management
System’s Data Access Layer is built using Microsoft’s Data Access Application Block.
The Data Access Application Block is part of Microsoft’s Enterprise Library. The
Enterprise Library is “a collection of reusable software components designed to assist
software developers with common enterprise development cross-cutting concerns”. By
utilizing the Enterprise Library, developers don’t have to “reinvent the wheel”.
The Data Access Tier exposes methods that require access to the data store. Each
method calls a database stored procedure and the enterprise library handles common tasks
such as opening and closing database connections. The Data Access Tier methods
include CreateTopic, EditTopic, RetrieveTopic, ViewIndex, SearchTopics,
CreateArchivedTopic, RetrieveArchivedTopic, RollbackTopic, and ViewTopicHistory.
32
Workflow Descriptions
The technical workflow of data through the system is represented by a series of
UML Sequence Diagrams. According to Larman (2005), “A sequence diagram is a
picture that shows, for one particular scenario of a use case, the events that external
actors generate, their order, and inter-system events” (Larman, 2005, 176). Sequence
Diagrams evolve use cases to the design phase. The workflows represent the information
flow through all three tiers of the Wiki Knowledge Management System.
The Create New Topic technical workflow (Figure 13) elaborates the Create New
Topic Use Case (UC1). This workflow begins with the Wiki User initiating the system
via the Create Topic Page by clicking the Save Button. The system verifies that the
required information (a Topic Name and Content for the Topic) has been provided. If the
data is valid, the Create Topic Page calls the CreateTopic method on the Topic Object
which in turn calls the CreateTopic Method of the Data Access Tier.
33
Figure 13 - New Topic Sequence Diagram
The View Topic Use Case technical workflow elaborates the View Topic Use
Case (UC2). It is initiated when the Wiki User views the Retrieve Topic Page.
After
initiation, the system calls the RetrieveTopic method of the Topic Object. The
RetrieveTopic method calls the RetrieveTopic method of the Data Access Tier. The data
from the data store are returned to the Topic Object. The Topic Object calls the
FormatTopic method which converts Wiki Markup into HTML. The HTML formatted
content is returned and rendered on the Retrieve Topic Page. This is represented by
Figure 14.
34
Figure 14 - View Topic Sequence Diagram
When a Wiki User wishes to edit a topic (UC3), they begin by clicking the Save
button on the Edit Topic Page. The Edit Topic Page validates that the Wiki User did
provide content. If the data is valid, the system calls the EditTopic method of the Topic
Object. The Topic Object creates an archived version of itself by calling the
CreateArchivedTopic method of the ArchivedTopic Object. The CreateArchivedTopic
method calls the CreateArchivedTopic Method of the Data Access Tier. Once an archive
has been created, the Topic Object calls the EditTopic Method of the Data Access Tier.
Figure 15 shows the Edit Topic Sequence Diagram.
35
Figure 15 - Edit Topic Sequence Diagram
The View Wiki Index Use Case (UC4) is initiated when the Wiki User visits the
Wiki Index Page. The Wiki Index Page then calls the ViewIndex method of the Topic
Object. The ViewIndex method can be called with either a string parameter (which
represents a letter of the alphabet) or no parameter. The Topic Object calls the
ViewIndex method of the Data Access Tier. If the is a parameter provided, the Data
Access Layer will return the collection of topics that begin with that letter. If no
parameter was provided, a collection of all topics are returned. The Topic Object returns
this list to the View Topic Index Page. Figure 16 shows the View Wiki Index Sequence
Diagram.
36
Figure 16- View Index Sequence Diagram
If a Wiki User needs to search the Wiki Knowledge Management System (UC5),
they begin by entering a search term in the search box located in the left navigation pane
and clicking the search button. The system then redirects to the Search Results Page. On
loading, the Search Results Page checks to see if a search term was entered. If no search
term was entered, an error message is displayed to the Wiki User. If a search term was
entered, the Search Results Page calls the SearchTopics Method of the Topic Object with
the search term as a parameter. The Topic Object calls the SearchTopics method of the
Data Access Tier. The Data Access Tier returns a collection of Topics that match the
search term. A match is determined first by matching Topic Names, and then by a match
in the content. The Topic Object returns this collection to the Search Results Page. If
there are no topics in the collection, the system will display an appropriate message. If
there is a single result, the system redirects to the View Topic Page displaying the single
37
result. If multiple topics are returned, the Search Results Page displays the list. Figure
17 shows the Search Sequence Diagram.
Figure 17 - Search Sequence Diagram
The View Topic History Use Case (UC6) is initiated by a button on the View
Topic Content Page. The system redirects the browser to the View Topic History Page.
The system calls the ViewTopicHistory Method of the Archived Topic Object. The
ViewTopicHistory calls the ViewTopicHistory Method of the Data Access Layer. The
38
Data Access Layer returns the list of Archived Topics for the current topic. The sorted
list of return values is returned to the View Topic History Page. The returned values are
displayed on the View Topic History Page. Figure 18 shows the View Topic History
Sequence Diagram.
Figure 18 - View Topic History Sequence Diagram
After a Wiki User views the Archived Topics, the next step is to view a particular
version of an Archived Topic. To select a version, the Wiki User selects one from the
View Topic History Page. Next the system redirects to the View Archived Topic Page.
The View Archived Topic Page calls the RetrieveArchivedTopic method of the Archived
Topic Object. TheRetrieveArchivedTopic method calls the RetrieveArchivedTopic
Method of the Data Access Tier. The Data Access Tier returns the particular Archived
Topic to the Archived Topic Object. The Archived Topic Object converts the Wiki
39
Markup Language to HTML. The Archived Topic Object returns the HTML formatted
content to the View Archived Topic Page. The View Archived Topic Page renders the
Archived Topic for the Wiki User.
When a Wiki User needs to restore a previous version of a topic they need to
execute the Roll Back Use Case. To begin a roll back the Wiki User needs to navigate to
the desired Archived Topic via the View Topic History Page. Once they are viewing the
particular Archived Topic on the View Archived Topic Page the workflow is initiated by
clicking the Roll Back button. Once initiated, the View Archived Topic Page calls the
RollBack Method on the Archived Topic Object. The Archived Topic Object calls the
CreateArchivedTopic Method on itself. The CreateArchivedTopic Method calls the
CreateArchivedTopic Method on the Data Access Tier. The Data Access Tier returns a
success message to the Archived Topic Object. Next the Archived Topic Object calls the
EditTopic Method of the Topic Object. The EditTopic Method calls the EditTopic
Method on the Data Access Layer. The Data Access Layer returns a message back to the
Topic Object, and then back to the View Archived Topic Page. Finally, the View
Archived Topic Page redirects to the View Topic Page for the current topic. Figure 19
shows the Roll Back Workflow.
40
Figure 19 - Roll Back Sequence Diagram
Database Design
The database server for the Wiki Knowledge Management System will be a
Microsoft SQL Server 2005 in accordance to OTR policy. There will be two database
tables. The first table maps directly to the Topic Object. The second table maps to the
Archived Topic Table.
The first database table is the Topic table. The Topic table defines an identity ID
field to act as the primary key. Another candidate key for this table is the Name field.
The Name field is a variable character data type with a size of 256 characters. The
second field is the Content field. The Content field will be a variable character data type
with a maximum length. The next field is the CreatedBy field. This field stores the name
41
of the Wiki User that saved the topic. This field will be variable character with a size of
20. The next field is the CreateDate field. This field will be a DateTime data type. The
final field in the Topic table is the VersionNumber field. This field is a integer data type.
Figure 20 shows the Data Definition Language (DDL) code used to create the Topic
table.
CREATE TABLE [dbo].[Topic](
[Id] [int] IDENTITY(1,1) NOT NULL,
[Name] [varchar](256) NOT NULL,
[Content] [varchar](max) NOT NULL,
[CreatedBy] [varchar](20) NOT NULL,
[CreateDate] [datetime] NOT NULL,
[VersionNumber] [int] NOT NULL,
CONSTRAINT IX_Topic_Name UNIQUE(Name),
CONSTRAINT [PK_Topic] PRIMARY KEY CLUSTERED
(
[Id] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
Figure 20 - Topic Table DDL Code
The ArchivedTopic table has the same fields as the Topic table. The difference in
the tables is the Name alone is not a key field. Instead, the Name and VersionNumber
fields together form a composite key. Figure 21 shows the Data DDL Code used to
create the ArchivedTopic table.
42
CREATE TABLE [dbo].[ArchivedTopic](
[Id] [int] IDENTITY(1,1) NOT NULL,
[Name] [varchar](256) NOT NULL,
[Content] [varchar](max) NOT NULL,
[CreatedBy] [varchar](20) NOT NULL,
[CreateDate] [datetime] NOT NULL,
[VersionNumber] [int] NOT NULL,
CONSTRAINT IX_ArchivedTopic_Name
UNIQUE(Name , VersionNumber),
CONSTRAINT [PK_ArchivedTopic] PRIMARY
KEY CLUSTERED
(
[Id] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
Figure 21 - ArchivedTopic Table DDL Code
The Data Access Layer of the application will access the data via stored
procedures. The Data Access Layer places stored procedure input values into parameters.
According to Chris Anley of NGSSoftware Insight Security Research, when code
accesses data using a stored procedure and assigns values to input parameters it is
generally safe (17).
The first stored procedure is the CreateTopic stored procedure. This stored
procedure takes @Name, @Content, @CreatedBy, and @CreateDate as input
parameters. The procedure then executes a data manipulation language insert query.
Since this stored procedure creates a new Topic, the VersionNumber is set to one. Figure
22 shows the DDL code for the CreateTopic stored procedure.
43
CREATE PROCEDURE CreateTopic
@Name varchar(256),
@Content varchar(MAX),
@CreatedBy varchar(20),
@CreateDate datetime
AS
BEGIN
INSERT INTO [Topic]
([Name]
,[Content]
,[CreatedBy]
,[CreateDate]
,[VersionNumber])
VALUES
(@Name
,@Content
,@CreatedBy
,@CreateDate
,1)
END
GO
Figure 22 - CreateTopic Stored Procedure DDL Code
The next stored procedure is the RetrieveTopic stored procedure. This procedure
receives a @Name as the input parameter. The procedure returns the single matching
record from the database. Figure 23 shows the DDL code for the RetrieveTopic stored
procedure.
CREATE PROCEDURE RetrieveTopic
@Name varchar(256)
AS
SELECT
[Name]
,[Content]
,[CreatedBy]
,[CreateDate]
,[VersionNumber]
FROM [Topic]
WHERE [Name] = @Name
Figure 23 - RetrieveTopic Stored Procedure DDL Code
44
The EditTopic stored procedure takes @Name, @Content, @CreatedBy, and
@CreateDate as input parameters. The VersionNumber field is calculated by
incrementing the previous value by one. Since the Name field is a unique key in the
Topic table, it is not a manipulated field, but it is used to update the correct record in the
database. Figure 24 shows the DDL code for the EditTopic stored procedure.
CREATE PROCEDURE EditTopic
@Name varchar(256),
@Content varchar(MAX),
@CreatedBy varchar(20),
@CreateDate datetime
AS
BEGIN
UPDATE [Topic]
SET [Content]=@Content,
[CreatedBy]=@CreatedBy,
[CreateDate]=@CreateDate,
[VersionNumber]=[VersionNumber] + 1
WHERE
[Name]=@Name
END
GO
Figure 24 - EditTopic Stored Procedure DDL Code
The ViewTopicIndex stored procedure retrieves a set of Topic records from the
database. This procedure takes @StartsWith as a parameter. This parameter is a
character type with a length of one. The system will return all records where the name
field begins with the @StartsWith parameter. Additionally, the @StartsWith parameter
may be passed in with a NULL value. When this is the case, the system will return all
records from the Topic table. Figure 25 shows the DDL code for the ViewTopicIndex
stored procedure.
45
CREATE PROCEDURE ViewTopicIndex
@StartsWith char(1)
AS
SELECT
[Name]
,[Content]
,[CreatedBy]
,[CreateDate]
,[VersionNumber]
FROM [Topic]
WHERE [NAME] LIKE IsNull(@StartsWith, '')
+ '%'
Figure 25 - View Topic Index DDL Code
The SearchTopics stored procedure implements a moderately complex search on
the Topic table. The stored procedure recieves @SearchTerm as an input paramters. The
procedure then takes the union of two separate select queries. The first select query
searches for all the Topic records that contain @SearchTerm in the name field. These
results are given a match value of one. The second select query in the union searches for
all the Topic records that contain @SearchTerm in the content. These records are given a
match value of two. The entire result set is returned ordered by the match value. This
means that Name field matches are placed before Content only value matches. Figure 26
shows the DDL code for the SearchTopics stored procedure.
46
CREATE PROCEDURE SearchTopics
@SearchTerm varchar(max)
AS
SELECT
[Name]
,[Content]
,[CreatedBy]
,[CreateDate]
,[VersionNumber]
FROM
(
SELECT [Name]
,[Content]
,[CreatedBy]
,[CreateDate]
,[VersionNumber]
,1 as Match
FROM [Topic]
WHERE [NAME] LIKE '%' +
IsNull(@SearchTerm, '') + '%'
UNION
SELECT [Name]
,[Content]
,[CreatedBy]
,[CreateDate]
,[VersionNumber]
,2 as Match
FROM [Topic]
WHERE [Content] LIKE '%' +
IsNull(@SearchTerm, '') + '%'
) UnionTable
Order By Match
Figure 26 - SearchTopics Stored Procedure DDL Code
The ViewTopicHistory stored procedure returns all the ArchivedTopic records
that have a particular value in the Name field. This procedure takes @Name as an input
parameter. The procedure then returns the values sorted by VersionNumber decending.
Figure 27 shows the DDL code for the ViewTopicHistory stored procedure.
47
CREATE PROCEDURE ViewTopicHistory
@Name varchar(256)
AS
BEGIN
SELECT [Id]
,[Name]
,[Content]
,[CreatedBy]
,[CreateDate]
,[VersionNumber]
FROM [ArchivedTopic]
WHERE [Name]=@Name
ORDER BY [VersionNumber] DESC
END
GO
Figure 27 - ViewTopicHistory Stored Procedure DDL Code
The CreateArchivedTopic stored procedure is similar to the CreateTopic stored
procedure. The first difference is that is is applied to the ArchivedTopic table instead of
the Topic table. The second difference is that when an ArchivedTopic record is created,
the VersionNumber field is calculated by finding the maximum existing VersionNumber
for that Name and adding one to it. This is done in the FindNextVersionNumber
database function. The input paramters are the same as the CreateTopic stored
procedure. Figure 28 shows the DDL code for the CreateArchivedTopic stored
procedure. Figure 29 shows the DDL code for the FindNextVersionNumber database
function.
48
CREATE PROCEDURE CreateArchivedTopic
@Name varchar(256),
@Content varchar(MAX),
@CreatedBy varchar(20),
@CreateDate datetime
AS
BEGIN
INSERT INTO [ArchivedTopic]
([Name]
,[Content]
,[CreatedBy]
,[CreateDate]
,[VersionNumber])
VALUES
(@Name
,@Content
,@CreatedBy
,@CreateDate
,dbo.FindNextVersionNumber(@Name))
END
GO
Figure 28 - CreateArchivedTopic Stored Procedure DDL Code
CREATE FUNCTION FindNextVersionNumber
(
@Name varchar(256)
)
RETURNS int
AS
BEGIN
declare @NextVersionNumber int
SELECT @NextVersionNumber = Max(VersionNumber) + 1
FROM
ArchivedTopic
WHERE
([Name] = @Name)
return @NextVersionNumber
END
Figure 29 - FindNextVersionNumber Database Function DDL Code
49
The RetrieveArchivedTopic stored procedure retrieves a single record from the
ArchivedTopic table. The input paramters are @Name and @VersionNumber. The DDL
code for the RetrieveArchivedTopic stored procedure can be found in Figure 30.
CREATE PROCEDURE RetrieveArchivedTopic
@Name varchar(256),
@VersionNumber int
AS
SELECT
[Name]
,[Content]
,[CreatedBy]
,[CreateDate]
,[VersionNumber]
FROM [ArchivedTopic]
WHERE [Name] = @Name and
[VersionNumber]=@VersionNumber
Figure 30 - RetrieveArchivedTopic Stored Procedure DDL Code
Conclusion
The Wiki Knowledge Management System is designed using a three tier
architecture. The first tier is the Presentation Tier. This tier is made up of several
Content Pages built upon Microsoft’s ASP.Net. All the Content Pages share a common
Master Page that provides a common look and feel for the entire Presentation Tier. The
only business logic in the Presentation Tier is for page to page navigation and simple data
validation.
A majority of the business logic for the Wiki Knowledge Management System is
found in the Business Logic Layer. The Business Logic Tier defines the business objects.
The business objects in the Wiki Knowledge Management System are the Topic object
and the ArchivedTopic object. The Business Logic Tier defines all the manipulations
50
that occur for the business objects. In this system these manipulations include creating
topics, retrieving topics, editing topics, searching topics, and archivng topics.
Data Access is seperated from the other tiers by placing it in the Data Access Tier.
The Data Access Tier for the Wiki Knowledge Management System utlizes the Microsoft
Data Access Applciation Block. This application block simplifies coding by handling
many common data access tasks. The Data Access Tier exposes many methods to the
Business Logic Tier. These methods are used to interact with the database.
The database for the Wiki Knowledge Management System has two tables: the
Topic table and the ArchivedTopic table. All manipulation of data to and from these
tables is done securely using stored procedures and parameters.
51
Chapter 5
CONCLUSION
The Department of General Services (DGS), an agency of the State of California, faces a
potential max exodus of employees. Approximately one in five employees are age 50 or
greater and may be eligible for retirement in the next five years. Additionally, working
conditions such as furloughs and layoffs have many employees contemplating leaving the
public sector.
When an employee leaves an organization there is a great cost to the firm. One of
the costs is the loss of knowledge. Many organizations do not do a adequate job of
retaining employee knowledge, therefore the knowledge is only kept with the employees.
To combat the loss of knowledge associated with employee turnover, the
Department of General Services needs to implement a Knowledge Management System
(KMS). A KMS will mitigate some of the cost of losing employee knowledge.
Additional benefits include process improvement, knowledge sharing, and increased
morale.
The KMS needs to be inexpensive, easy to use, and accessible by everyone.
Solution alternatives include a ListServ, static pages in the department Content
Management System, and a Wiki. A wiki is a Wiki is a set of linked web pages (topics),
created through the incremental development by a group of collaborating wiki users
(Leuf and Cunningham, 1999).
52
Users of the DGS KMS need to be able to create, view, and edit wiki topics.
Additionally, wiki users need to be able to find knowledge by viewing an index of topics,
and search topics. One feature of a wiki is that topics are archived. The DGS KMS
allows wiki users to view archived versions of topics and roll back topics to previous
versions.
The design architecture for the DGS KMS will utilize three tiers. The first tier is
the user interface. The user interface is made up of an ASP.Net master page and several
ASP.Net content pages. The second tier is the business logic tier. The business logic tier
is made up .Net class libraries and contains all the business rules and objects required by
the system. The final layer is the data access tier. The data access tier calls stored
procedures which reside in the department’s Microsoft SQL Server database.
53
APPENDIX
Use Cases
Use Case ID:
Use Case Name:
Actors:
Description:
UC1
Create New Topic
Wiki User
This Use Case describes how an actor creates a new topic in
the Wiki Knowledge Management System.
Trigger: This Use Case is initiated via:
 A hyperlink on the left navigation.
 A hyperlink (for a non-existent topic) within the
content of another topic.
Preconditions: The actor is identified and authenticated.
Post-Conditions: A topic entry is created in the system
Normal Flow: 1. The system requests that the actor provide a topic title*
and a content* of the title (* denotes a required field).
2. The actor enters the title and the content.
3. The actor clicks the save button.
4. The system stores the new topic in the topic data store.
Alternative Flows: Pre-entered Topic
Instead of Normal Flow Step 1, the topic title may be preentered if the actor attempts to view a non-existent topic.
Exceptions:
Frequency of Use:
Special Requirements:
Assumptions:
Cancel
At any time during the Normal Flow (Prior to the actor
clicking the save button); the actor may click the cancel
button. At this point they are redirected to the View Topic
Content Page.
Missing Required Field Exception
If the actor fails to provide a required field, the system will
display “[Field Name] is required.”
Often
This Use Case requires the wiki markup conventions
This Use Case assumes the data store is accessible.
Table 1-Create New Topic Use Case
54
Use Case ID:
Use Case Name:
Actors:
0Description:
Trigger:
Preconditions:
Postconditions:
Normal Flow:
Alternative Flows:
UC2
View Topic
Wiki User
This Use Case describes how an actor views a topic in the
Wiki Knowledge Management System.
This Use Case is initiated via:
 The initial visit to the system.
 A hyperlink from another topic.
 A hyperlink from the search.
The actor is identified and authenticated.
1.
1. The system is provided with a topic name (as part of
the URL or if one is not provided; the default topic).
2. The system retrieves the content from the topic data
store.
3. The topic markup is formatted into the standard
viewable format.
4. The formatted topic is displayed on the web page.
Topic Does Not Exist
If the topic is not found in the data store, this Use Case
terminates and the Create Topic Use Case (UC1) is initiated.
Historical Topic
The actor may initiate this Use Case by providing a historical
version of the topic. The retrieval, formatting, and display as
normal.
Exceptions: Missing Required Field Exception
If the actor fails to provide a required field, the system will
display “[Field Name] is required.”
Includes:
Priority:
Frequency of Use: Very Often
Business Rules:
Special Requirements:
Assumptions:
Notes and Issues:
Table 2-View Topic Use Case
Use Case ID: UC3
Use Case Name: Edit Topic
55
Actors: Wiki User
Description: This Use Case describes how an actor edits an existing wiki
topic.
Trigger: This Use Case is initiated by a hyperlink on the View Topic
Content Page
Preconditions: 1. The actor is identified and authenticated
2. The topic exists
Postconditions: 2.
Normal Flow:
1. The topic data is retrieved from the topic data store.
2. The View Topic Content Page is switched to edit
mode, meaning the main content block is replaced by a
rich text style text editor.
3. The content of the topic is displayed in the rich text
editor in markup style.
4. The actor is allowed to make edits to the content of the
topic.
5. The actor clicks the save button.
6. The system saves the previous version of the topic in
the archived data store.
7. The updated topic is persisted to the topic data store.
8. The View Topic Content Page is switched to view
mode.
Alternative Flows: Cancel
At any time between rendering the page and saving, the actor
may cancel the edit and the View Topic Content Page will
revert back to view mode.
Exceptions: Missing Required Field Exception
If the actor fails to provide a required field, the system will
display “[Field Name] is required.”
Includes:
Priority:
Frequency of Use: Often
Business Rules:
Special Requirements:
Assumptions:
Notes and Issues:
Table 3-Edit Topic Use Case
56
Use Case ID:
Use Case Name:
Actors:
Description:
UC4
View Topic Index
Wiki User
This Use Case describes how to view a list of wiki topics as
an index (20 at a time) and displays them to the screen
alphabetically.
Trigger: This Use Case may be initiated by A hyperlink on the View
Topic Content Page
Preconditions: The actor is identified and authenticated
Postconditions:
Normal Flow:
1. The system retrieves the first 20 records from the
system.
2. The name of the topic is displayed along with a small
portion of the content (with hyperlinks and markup
removed.)
3. A navigation button will be rendered to view the next
page.
Alternative Flows: Paging
When the actor pages through the index, the previous/next 20
records are displayed. Navigation buttons for previous and
next page will be displayed.
Filtering
The actor may select a hyperlink at the top of the index (there
will be hyperlinks for all the letters of the alphabet plus a
hyperlink for numbers) this will filter the results to only that
letter (or numbers).
Less than 20
If there are less than 20 records that can be returned, the
system will only return those records. Navigation buttons will
be rendered appropriately.
Exceptions: No Topics Found
If the system does not find any topics for a given filter, the
page will display “No Topics Match Your Search.”
Includes:
Priority:
Frequency of Use: Moderate
Business Rules:
Notes and Issues:
Table 4-View Topic Index Use Case
57
Use Case ID:
Use Case Name:
Actors:
Description:
UC5
Search
Wiki User
This Use Case describes how an actor can search the Wiki
Knowledge Management System using a key word search.
Trigger: This Use Case is initiated by:
 A search textbox and submit button located in
the left navigation pane of the View Topic
Content Page.
 A search textbox and submit button at the
bottom of the search results page.
Preconditions: The actor is identified and authenticated
Postconditions:
Normal Flow:
1. The actor enters a search term.
2. The actor clicks the search button.
3. The system searches the topic data store (both name
and content fields).
4. The system returns topics that contain the search term.
5. [If exactly one result is returned]
5.1.1. The View Topic Use Case is initiated with the
single result being the topic.
[If more than one result is returned]
5.2.1. The system displays the search results page
using the View Topic Index Use Case.
[If no results are returned]
5.3.1. The system displays a no results found
message.
Alternative Flows:
Exceptions:
Includes:
Priority:
Frequency of Use: Often
Business Rules:
Special Requirements:
Assumptions:
Notes and Issues:
Table 5-Search Use Case
58
Use Case ID:
Use Case Name:
Actors:
Description:
UC6
View Topic History
Wiki User
This Use Case describes how an actor can view archived
versions of a topic.
Trigger: This Use Case is initiated by a button on the View Topic
Content Page.
Preconditions: The actor is identified and authenticated.
Postconditions:
Normal Flow:
1. The system retrieves a list of all the archived versions
of the topic being viewed.
2. The system will display the list of archived version
dates in backwards chronological order.
3. The actor clicks a date hyperlink from the archived
version list.
4. The system retrieves the content of the selected
archived version.
5. The content is displayed to the user on the View Topic
Content Page.
6. The View Topic Content Page’s edit option is
disabled.
Alternative Flows:
Exceptions:
Includes:
Priority:
Frequency of Use: Moderate
Business Rules:
Special Requirements:
Assumptions:
Notes and Issues:
Table 6-View Topic History Use Case
59
Use Case ID:
Use Case Name:
Actors:
Description:
UC7
View Archived Topic Use Case
Wiki User
This Use Case describes how an actor can view an archived
version of a topic.
Trigger: This Use Case is initiated by selecting a topic on the View
Archived Topic Page.
Preconditions: The actor is identified and authenticated.
Postconditions:
Normal Flow:
1. The Wiki User selects a specific version from the
View Archived Topic Page.
2. Once initiated, this use case retrieves the specific
archived version of the Wiki Data Store.
3. The system formats the topic and it is displayed to the
Wiki User on the View Archived Topic Page.
Alternative Flows:
Exceptions:
Includes:
Priority:
Frequency of Use: Unknown
Business Rules:
Special Requirements:
Assumptions:
Notes and Issues:
Table 7 - View Archived Topic Use Case
60
Use Case ID:
Use Case Name:
Actors:
Description:
UC8
Roll Back Topic
Wiki User
This Use Case describes how an actor can restore an archived
version of a topic.
Trigger: This Use Case is initiated by a button on the View Archived
Topic Content Page.
Preconditions: The actor is identified and authenticated.
Postconditions:
Normal Flow:
4. Once initiated, this use case retrieves the specific
archived version of the Wiki Data Store.
5. Once retrieved, the system initiates a Edit Topic Use
Case (UC3) utilizing the name and content provided
from the archived version that was just retrieved.
6. After the Edit Topic Use Case is complete, the system
redirects to the View Topic Use Case for the currently
selected topic.
Alternative Flows:
Exceptions:
Includes: Edit Topic Use Case (UC3)
Priority:
Frequency of Use: Unknown
Business Rules:
Special Requirements:
Assumptions:
Notes and Issues:
Table 8 - Roll Back Topic Use Case
61
WORKS CITED
"Accessibility State Standards :: WebTools :: State of California." WebTools, State of
California. Web. 18 July 2010.
<http://www.webtools.ca.gov/Accessibility/State_Standards.asp>.
Anley, Chris. "Advance SQL Injection in SQL Server Applications." NGSSoftware
Insight Security Research (2002).
"ASP.NET Overview." MSDN | Microsoft Development, Subscriptions, Resources, and
More. 18 July 2010. <http://msdn.microsoft.com/en-us/library/4w3ex9c2.aspx>.
"ASP.NET Web Page Code Model." MSDN | Microsoft Development, Subscriptions,
Resources, and More. 18 July 2010. <http://msdn.microsoft.com/enus/library/015103yb.aspx>.
Chartier, Robert. "15 Seconds : Application Architecture: An N-Tier Approach - Part 1."
15 Seconds : Asp Tutorials, Asp.net Tutorials, ASP Programming Sample Code, and
Microsoft News from 15Seconds. 18 July 2010.
<http://www.15seconds.com/issue/011023.htm>.
Cunningham, Ward. "Wiki Design Principles." Cunningham & Cunningham, Inc. 18
July 2010. <http://c2.com/cgi/wiki?WikiDesignPrinciples>.
"Defining Business Rules ~ What Are They Really? (Chapter 1)." Web. 18 July 2010.
<http://www.businessrulesgroup.org/first_paper/br01c1.htm#s1e>.
"Disaster Recovery Plan Documentation for Agencies Instructions." California Office of
Information Security and Privacy Protection. (Novermber 2008).
62
"DPA - Workforce Planning - Demographics and Labor Statistics." Department of
Personnel Administration - Home. 18 July 2010. <http://www.dpa.ca.gov/personnelpolicies/workforce-planning/demographics-and-labor-statistics.htm>.
Droege, Scott B., and Jenny M. Hoobler. "Employee Turnover and Tacit Knowledge
Diffusion: A Network Perspective." Journal of Managerial Issues XV.1 (2003): 5064.
Frappaolo, Carl, and Larry T. Wilson. "After the Gold Rush - Harvesting Corporate
Knowledge Resources." Intelligent KM (2000).
Garcia, Jose Daniel, Jesus Carretero, Jose Maria Perez, Felix Garcia, and Rosa Filgueira.
"Specifying Use Case Behavior with Interaction Models." Journal of Object
Technology 2.2 (2003).
Laing, Shacarra, Roseanna Poitier, Holly Ferguson, Shawn M. Carraher, and Shauna
Ford. "Baby Boomers at 60: Effects on Retirement Plans, Benefits, and the
Workforce in the Bahamas, Japan, and the USA." Academy for Studies in
International Business Procedings 9.1 (2009): 11-15.
Larman, Craig. Applying UML and Patterns: an Introduction to Object-oriented Analysis
and Design and Iterative Development. Upper Saddle River, NJ: Prentice Hall PTR,
2005.
Leuf, B. and W. Cunningham (2001). The Wiki Way: Collaboration and Sharing on the
Internet, Reading, MA: Addison-Wesley.
63
"Maintaining a Website :: WebTools :: State of California." WebTools, State of
California. 18 July 2010.
<http://www.webtools.ca.gov/Usability/Best_Practices.asp>.
Manuel, Paul D., and Jarallah AlGhamdi. "A Data-centric Design for N-tier
Architecture." Information Sciences 150 (2003): 195-206.
"Reflections on Software Development… Is Object-Oriented Analysis and Design
Appropriate for the Common Business Application? Part II: What Are We Talking
About?" Reflections on Software Development Main Page. 18 July 2010.
<http://swcses.eponym.com/blog/_archives/2006/9/19/2341371.html#BODef>.
"State IT Policy Introduction." State Chief Information Officer - State of California. 18
July 2010. <http://www.cio.ca.gov/Government/IT_Policy/introduction.html>.
"Statewide Information Management Manual (SIMM)." State Chief Information Officer State of California. 18 July 2010.
<http://www.cio.ca.gov/Government/IT_Policy/SIMM.html>.
Swan, Jacky, and Harry Scarbrough. "Knowledge, Purpose, and Process: Linking
Knowledge Management and Innovation." Proceedings of the 34th Hawaii
International Conference on System Sciences (2001).
"Top 10 2007." OWASP. Web. 18 July 2010.
<http://www.owasp.org/index.php/Top_10_2007>.
Wagner, Christian. "Wiki: A Technology For Conversational Knowledge Management
and Group Collaboration." Communications of the Association of Information
Systems 13 (2004): 265-89.
64
Yu, Wen-der, Pei-lun Chang, and Shen-jung Liu. "Quantifying Benefits of Knowledge
Management System - A Case Study of an Engineering Consulting Firm."
International Symposium on Automation and Robotics in Construction (2006): 12429.
Zack, Michael H. "Managing Codified Knowledge." Sloan Management Review
(Summer 1999): 45-58.