MIDDLE EAST TECHNICAL UNIVERSITY
COMPUTER ENGINEERING DEPARTMENT
CENG491
Final Design Report
FALL 2008
TEAM MEMBERS
Doruk Tekniker - 1449123
Gürkan İlhan
- 1448786
Mehmet Daşıran - 1297654
TABLE OF CONTENTS
1.INTRODUCTION......................................................... ........................................................ .........................3
1.1. PROJECT TITLE........................................................ .................................................................3
1.2. PROJECT DEFINITION........................................................ .....................................................3
1.3. PROJECT SCOPE & GOALS........................................................ .............................................6
1.4. DESIGN PRINCIPLES........................................................ .........................................................9
2. PROJECT CONSTRAINTS........................................................ ................................................................10
2.1. SYSTEM CONSTRAINTS........................................................ .................................................10
2.1.1. HARDWARE CONSTRAINTS........................................................ ........................10.
2.1.2. SOFTWARE CONSTRAINTS........................................................ ..........................11
2.2. TIME CONSTRAINTS........................................................ .......................................................12
2.3. RESOURCE CONSTRAINTS........................................................ ...........................................12
2.4. PROJECT DEVELOPMENT CONSTRAINTS........................................................ ..............13
2.3.1. USABILITY........................................................ ........................................................13
2.3.2. RELIABILITY........................................................ ...................................................13
2.3.3. PERFORMANCE........................................................ ..............................................13
2.3.4. USER FRIENDLINESS........................................................ .....................................13
3. SYSTEM ARCHITECTURE........................................................ ..............................................................14
3.1. GENERAL SYSTEM ARCHITECTURE DESIGN................................................................14
3.2. MODULES........................................................ ..........................................................................15
3.2.1. CONNECTION OPERATIONS...............................................................................15
3.2.2. RULE MODIFICATION...........................................................................................16
3.2.3. CHANNEL........................................................ .........................................................17
3.2.4. CONVERT........................................................ .........................................................18
3.2.5. PROCESS........................................................ ...........................................................19
3.2.6. EXTERNAL........................................................ .......................................................20
3.3. DIAGRAMS........................................................ ........................................................................21
3.3.1. USE CASE DIAGRAMS........................................................ ...................................21
3.3.2. CLASS DIAGRAMS........................................................ .........................................22
3.3.2.1. DSE Access
3.3.2.2. Internal Database Access
3.3.2.3. External Source Access
3.3.2.4. DSL Transformation
3.3.3. SEQUENCE DIAGRAMS........................................................ ................................26
3.3.3.1. Connection
3.3.3.2. Disconnection
3.3.3.3. Insert Rule
3.3.3.4. Update Rule
3.3.3.5. Delete Rule
3.3.3.6. Search Rule
3.4. GRAPHICAL USER INTERFACE FOR DST........................................................ ................32
3.4.1. CONNECTION PART........................................................ .......................................33
3.4.2. MESSAGE PART........................................................ ...............................................33
3.4.3. OPERATION PART........................................................ ..........................................33
3.4.4. RESULT SET........................................................ ......................................................35
3.5. DSL DATA BINDING........................................................ .........................................................35
4. DEVELOPMENT PROCESS........................................................ ..............................................................39
4.1. PROJECT SCHEDULE........................................................ ......................................................39
4.2. PROJECT MODEL........................................................ .............................................................39
4.3. GANNT CHART........................................................ ..................................................................40
4.4. TEAM STRUCTURE........................................................ ..........................................................41
4.5. TEAM RULES........................................................ .....................................................................41
5.CONCLUSION........................................................ ......................................................................................42
6.REFERENCES........................................................ ......................................................................................43
2
1.INTRODUCTION
This document is the final design report of our Design Project.
Throughout the report, the reader will find detailed information about
our Domain Specific Kit for Business Rule Management Design
Project including the relationship between DSE, DST and DSL,
relationship between DSK & External Resources, External Resource
Connections, Data Binding, Graphical User Interface Design for DST,
Class Definitions, Related Use-Case and Class Diagrams, Module
Definitions, Data Entities, Project Schedule, and System Architecture.
1.1. PROJECT TITLE
Our DSK4BRM Project is named ‘RULE’EM ALL’.
1.2. PROJECT DEFINITION
The “Business Rules” term has increasingly become common across
today’s information technology (IT) industry. Many problems that IT
professionals encounter seem to have a business rules component, thus
the term gained such a widespread acceptance.
Within the program code of an application, it is usually very difficult
to recognize what pieces of the code make up any particular rule. Thus
when large-scale changes are to be made to applications, people
suddenly realize that they do not know in sufficient detail how these
applications work.
3
With a business rules approach, it should be possible to know in
which applications any piece of logic, a business rule is implemented,
where to find it within these applications and how it is implemented in
each application.
Indeed, a better way of looking at the term is that it covers a
multifaceted and multidisciplinary approach to organizing the logic
needed to run an organization. The business rules approach attempts
to bring order to this logic by decomposing it into individual business
rules.
Nowadays every organization has thousands of business rules and
every organization needs to be able to manage them much better.
There is no exaggeration to say that many organization’s survival
depends on this. On this task rule-oriented data-based architectures
play a significantly powerful role.
Of course the job of handling business rules requires a Business Rule
Management System. A BRMS is a software system used to define,
deploy, execute, monitor and maintain the variety and complexity of
decision logic that is used by operational systems within an
organization or enterprise.
This logic, also referred to as business rules, includes policies,
requirements, and conditional statements that are used to determine
the tactical actions that take place in applications and systems.
4
A BRMS includes, at minimum:



A repository, allowing decision logic to be externalized from
core application code
Tools, allowing both technical developers and business experts
to define and manage decision logic
A runtime environment, allowing applications to invoke decision
logic managed within the BRMS and execute it using a business
rules engine
The top benefits of a BRMS include:




Reduced or removed reliance on IT departments for changes in
live systems
Increased control over implemented decision logic for
compliance and better business management
The ability to express decision logic with increased precision,
using a business vocabulary syntax and graphical rule
representations (decision tables, trees, scorecards and flows)
Improved efficiency of processes through increased decision
automation
Most BRMS vendors have evolved from rule engine vendors to
provide business-usable software development lifecycle solutions,
based on declarative definitions of business rules executed in their
own rule engine.
However, some vendors come from a different approach (for example,
they map decision trees or graphs to executable code). Rules in the
repository are generally mapped to decision services that are naturally
fully compliant with the latest SOA, Web Services, or other software
architecture trends.
5
Taking all above into consideration, our aim is to construct a Domain
Specific Kit for the purpose of seperation of business rule
management from the rest of the system. This DSK is going to include
a domain specific engine and a domain specific kit, co-operating with
a domain specific langugage.
1.3. PROJECT SCOPE & GOALS
Rule’em All offers a domain specific kit for all types of business
domains.
Users will be able to insert new rules & facts, update existing rules &
facts and delete these specified rules and facts using a graphical user
interface provided by our domain specific tool. A Graphical User
Interface will be used to perform these operations.
Then these rules will be converted to scripts in our domain specific
language and executed by our domain specific engine. After execution
predefined data will be stored under a internal relational database. At
any time the user can access the business rules or facts and may
change them at his/her will.
Our Domain Specific Tool’s task is to provide a GUI for user to
transfer business rules into the domain specific engine to execute the
rules. A very user friendly, easy to use environment will be provided
because no programming skills are assumed for the possible users.
Our DSL will be used by both our domain specific engine and tool.
The rules inserted by the user will be converted and will be ready to
be executed under the engine.
6
Finally, our engine will process the inputs, make connection with the
internal database (retrieving and storing data etc.), and external
resources to get related data. Afterwards, by using the appropriate
business logic, the engine will evaluate the business rules.
More detailed information about the relationship between DSE,
DST,DSL and external resources can be found in the following
chapters of this report.
The users for this DSK can be the following :
Business Analysts:
Business analysts are sometimes professionals whose sole function is
to provide an interface between a business area and IT professionals.
Business analysts can be expected to be very intelligent, have good
communication skills, and have an intimate knowledge of the business
domain they represent. They often have some of the skills of a
systems analyst. These include the capacity to decompose problems
into their component parts and to provide highquality descriptions of
business requirements. Sometimes they are able to do design work to a
certain level, which can be useful for developing prototypes.
System operators :
System operators are generally not good candidates for assisting in
business rule management. They are usually employed to make sure
an application keeps running from day to day. As such, they are often
more familiar with the eccentricities of the system they look after in a
production setting than the business concepts that underlie it. System
operators should generally be thought of as administrators of
production systems, not partners in development activities, though
there may sometimes be exceptions.
7
Consultants:
An organization that wishes to implement an application containing a
business rules management system often employs consultants for such
projects.
A consultant is not an employee of the organization, but is rather an
outsider hired for a specific task. In this, consultants differ from
business analysts and systems operators who are employees.
Consultants are expected to have a knowledge of the underlying
business which is at least as good as that of business analysts.
IT Staff:
Even when an organization decides to build a business rules engine
there may be issues with its information technology (IT) staff. Today,
IT staff tend to be administrators of the organization’s hardware and
software resources and often have limited understanding of
information resource management.
They may even be inexperienced in systems development. Many of
their tasks are oriented to implementing new software and installing
upgrades from time to time.
Programmers:
Programmers are a special kind of IT staff, and programmers will be
needed to build a rules engine. Despite this, they are not ideal
candidates to define business rules.
Programmers typically know little of the underlying business and tend
to want to solve problems by introducing new procedural code.
8
1.4. DESIGN PRINCIPLES
To name a few of the design principles we’ll regard while developing
our project Rule’em All are :
 Ease of use
 Enhanced
 Robust & Reliable
 Graphical & User friendly
 Consistent
 No prior programming language skills needed
 Business Domain Independent
 Secure
 Ease of modification
 Abstract enough to be used in wide variety
9
2. PROJECT CONSTRAINTS
2.1.SYSTEM CONSTRAINTS
2.1.1. HARDWARE CONSTRAINTS
We can divide hardware requirements into 3 sub-categories, to
name: hardware requirements for development process, client
side and server side.
The hardware requirements for development process are :
• Intel Pentium4 3.2 GHz processor (or above)
• 1 GB RAM
• 7 GB HDD Space
• Internet connection
The hardware requirements for client-side are :
• Intel Celeron 1.6 GHz processor (or above)
• 256 MB RAM (512 MB Preferable)
• 600 MB HDD Space
• Internet connection
The hardware requirements for server-side are :
• Intel Pentium Core 2 Duo 2.24 GHz processor (or above)
• 2 GB RAM
• 30 GB HDD Space
• Internet connection
Since our external resources are web services, relational database
management systems and other applications, internet connection
and a computer which can execute required operations rapidly,
are crucial necessities.
10
2.1.2. SOFTWARE CONSTRAINTS
During the development of our project we’ll work on several
tools & environments for different purposes such as
documentation and application development. The software
requirements for developing process are :
• Microsoft Windows XP / Vista
As Macrosoft team we’ve planned to use these
operating systems since .NET platform is preferred
• Microsoft Visual Studio 2008
Our main IDE is MS-VS because we’ve chosen C# as
our programming language
• MSSQL Server 2005
To handle database operations we need a SQL Server
compatible with .NET environment and we think the
best choice is MSSQL Server
• Microsoft Office 2007
Default MS Windows office application for
documentation
• SmartDraw
SmartDraw is an easy-to-use application for drawing
related diagrams for our project
• Mozilla Firefox
A secure, fast web browser
• Adobe Reader
PDF viewer for documentation purposes
• Notepad++
This program is thought to be helpful for code
viewing purposes
11
2.2. TIME CONSTRAINTS
Although we haven’t started to code for our domain specific engine,
implementation of our domain specific tool and our domain specific
language and especially the documents we’ve written for the design
project and our prototype development consume much of our time.
As Macrosoft members, we try to stick to the gannt chart and try to
finish the forseen tasks on time. There is still muck work to be done
however we believe we can overcome possible problems about time
restrictions.
2.3. RESOURCE CONSTRAINTS
We, as Macrosoft, have found valuable information through internet,
some e-books and we try to make good use of the notes taken at the
weekly meetings. Especially the meetings with our Cybersoft project
consultant Mr. Semih Çetin are very beneficial for our group.
Some projects like jDrew and Tomcat also enlightens our path during
our design phases.
Although there are some similar examples to our project, we
sometimes have difficulties about finding logical material including
system abstraction and architecture.
Most of the developers don’t want to share such information and since
our project consists of a newly introduced application type, there
aren’t much options in our hand.
12
2.4. PROJECT DEVELOPMENT CONSTRAINTS
2.4.1. USABILITY
Rule’em All will include an easy-to-use Domain Specific Tool.
This is an important requirement for us since our main claim is
to create an environment for users without the necessity of
prerior programming knowledge. User will be able to perform
query operations and rule/modifications using the graphical
interface of DST.
2.4.2. RELIABILITY
Rule’em All will be used by different organizations. High
reliability of the software will especially important for some
companies in need of large databases and thousands of business
rules.
2.4.3. PERFORMANCE
Performance is an important issue for Macrosoft because our aim
is to make it faster to get information or execute some query .
Our database should be big but our serve time should also be
fast.
2.4.4. USER FRIENDLINESS
The user is provided with a user-friendly program. One of our
main goals in our product Rule’em All is to create a well-defined
graphical user interface. GUI provides easy-to-understand and
easy-to-use interface.
13
3. SYSTEM ARCHITECTURE
3.1. GENERAL SYSTEM ARCHITECTURE DESIGN
14
3.2. MODULES
3.2.1. CONNECTION OPERATIONS MODULE
This module contains two classes.These classes are :
*Connect
*Disconnect
Connect class lets user to enter the login information to the
system which are required parameters for connecting to external
sources. Disconnect class is responsible for providing host
address to the system that will be disconnected.
15
3.2.2. RULE MODIFICATION MODULE
This module contains four classes.These classes are :
*Insert
*Update
*Delete
*Search
Insert class lets user to enter the required parameters to the
system for inserting a new rule or fact. Update class is
responsible for updating the selected rule with the entered
parameters.Delete class also responsible for deleting the selected
rule from the system.Search class lets user to search for rules
having parameters that user entered in fields.
16
3.2.3. CHANNEL MODULE
This module contains three classes.These classes are :
*Get
*Callback
*Message
Get class is responsible for delivering required data for the
process of the classes selected in the rule modifications or
connection operations modules. This data may consist of either
one of updated, inserted, deleted and searched rules or
connection, disconnection info.
Callback class sends package from DSE to DST which includes
information about the processes made in External, Process or
Convert modules. This class also delivers the data taken from
external sources by external module to DST. Callback class is
responsible for delivering the search results made in internal
database as well.
The information reached to DST is shown to the user with
message class. There are mainly two types of messages. First
type is system messages which inform user about the process of
system. The other type is informational messages that gives user
approval or warning messages.
17
3.2.4. CONVERT MODULE
This module is consist of two classes.These classes are:
*Demand
*Translate
After the process of get class in channel module, the rule is taken
by DSE and demand class starts working.In demand class, a
request is sent to DSL for converting the rule into the acceptable
language for DSE which makes the rule processable.Translate
class delivers this processable rule to DSE.
18
3.2.5. PROCESS MODULE
This module consists of two classes.These classes are:
*Inform
*Save
Save class enables DSE to save the new rules or facts into
Internal Database and save the changes made on rules or facts
that already exist.This class also sends the query parameters to
the internal database.
Inform class sends package to DSE in order to let DSE to keep
the code part of the new rules or inform the changes made on the
code part of deleted/updated rules which is used in save class.
Inform class also sends the query results.
19
3.2.6. EXTERNAL MODULE
This module consists of two classes. These classes are:
*Request
*Response
Request class is responsible for connection/disconnection to the
external sources through the login information taken in
connection operations module from user. This class also enables
DSE to request for related data included in external sources.
Response class sends the results of connection/disconnection.
This results are delivered to the user by the call back class in
Validation module.This class also gives the requested data to
DSE. These related data fill the objects and/or action fields in
DST.
20
3.3. DIAGRAMS
3.3.1. USE CASE DIAGRAM
21
3.3.2. CLASS DIAGRAMS
3.3.2.1. DSE Access
22
3.3.2.2. Internal Database Access
23
3.3.2.3. External Source Access
24
3.3.2.4. DSL Transformation
25
3.3.3. SEQUENCE DIAGRAMS
3.3.3.1. Connection
26
3.3.3.2. Disconnection
27
3.3.3.3. Insert Rule
28
3.3.3.4. Update Rule
29
3.3.3.5. Delete Rule
30
3.3.3.6. Search Rule
31
3.4. GRAPHICAL USER INTERFACE FOR DST
Our DST provides a user-friendly GUI for the users to insert, update,
delete and search for existence of rules or facts. Connection contains
the type of the connection, host address information, username and
password. Detailed information about GUI operations can be found
below :
32
3.4.1. CONNECTION PART
Connection Type Field includes RDBMS, Web Service and
Application, thus user may choose the external source he/she
wants to connect. After the selection an address for the host to
connect is requested from user. By using the pre-given username
and password, the user can connect to the source. If the user
enters an address onto which a connection has been already
made, connect button behaves like a disconnect button, and its
caption changes to “disconnect”. Several different connections
can be handled at the same time.
3.4.2. MESSAGE PART
Message part contains the necessary information for the user
about both connection status and the operation tried to be
executed. For example, if a connection error occurs, user will be
informed as “Failed to Connect” or if an existing rule is tried to
be inserted again, a message like “Rule Already Exists” will
appear in this part.
3.4.3. OPERATION PART
In this part, user can make several operations like insertion,
deletion and update on rules or facts, or make a query. Thus
“Operation Type” includes “Rule Process”, “Fact Process” or
“Query” as operation types.
The user will write the name of the object to the object box and
selects the attribute of the object. Operator field holds less
than(<), greater than(<), equal to(=), like, less or equal to(≤) and
greater or equal to(≥) symbols.
The criteria part can be filled with the corressponding data type,
same with the type of objects attribute.
33
To make a logical binding between several conditions, “Logical
Operators” is used. This field holds the following logical
operators like AND, OR and XOR.
Finally, user selects the action to take if the condition returns
true. Some actions may be got from an external source library.
The “Operation Information” holds the sentence in an userfriendly way.
For example, we consider the following inputs in the operation
part(sequentially selected/inserted) to insert a new rule like :
“If client ID is 3425 and connection speed is less than 56k then
automatically reject connection.”
FIELD
VALUE
Operation Type
Rule Process
Object
Client
Attribute
ID
Operator
=
Criteria
3425
Logical Operator
AND
Object
Connection
Attribute
Speed
Operator
<
Criteria
56000
Action
Reject_Con()
34
While entering the inputs, a sentence defining the rule will
appear in the operation information area progressively. After
clicking on the “INSERT” button, if the operation is successful,
a message is returned to the user in the Message Area. Some
graphical objects’ properties like “visible” or “enable” may
change due to the selected operation type. If “Query” is selected
as the operation type, “action” object will be disabled and
invisible, for example.
3.4.4. RESULT SET
Result set shows the values returning from a query or search
operation.
The related fields will be filled on run-time due to the operation.
User may wish to keep the results, or clear the results. These are
the purposes of “SAVE” and “CLEAR” buttons.
3.5. DSL DATA BINDING
DSL data binding is the process of representing the information in an
DSL document as an object in computer memory. This allows our
DSE to access the data in the DSL from the object. Our DSL data
binder accomplishes this by automatically creating a generic mapping
(transformation) between elements of the DSL schema of the
document we wish to bind and members of a class to be represented in
memory.
DSL Data Binding are composed of a protocol sequence, the name or
adress of a host computer and our internal database endpoint.
Therefore, our program must obtain or provide this information to
create a binding.
35
Since our program uses automatic binding for client side, we don’t
need to write extra special source code to create or manage the
binding. The client stub calls RPC functions required to establish and
maintain the binding. All we have to do is specify that our client uses
automatic binding handled in an application configuration file in our
DST and design the interface for DST accordingly.
As a solution, we can include a generated header file, “auto.h”, for
example, and thereby we can call some remote time-stamping
functions. Here, the stubs do all the work and auto.h obtains the
function prototypes for the remote procedures. Thus, DST will call to
the remote procedures as if they were calls to local procedures, as
shown in the following example :
#include <stdio.h>
#include <time.h>
#include "auto.h"
void main(int argc, char **argv)
{
time_t t1;
time_t t2;
char * pszTime;
...
GetTime(&t1); // GetTime is a remote procedure
GetTime(&t2);
pszTime = ctime(&t1);
printf("time 1= %s\n", pszTime);
pszTime = ctime(&t2);
printf("time 2= %s\n", pszTime);
Shutdown(); // Shutdown is a remote procedure
exit(0);
}
36
As can been seen in the example, the DST does not have to make any
explicit calls to the RPC run-time library functions. The client stub
manages them.
Actually there are several ways to obtain the binding information and
call the RPC functions to create the handles, however we’re planning
to use one of the following :
1. Either the setup program for our DSK that installs the
components for client side binding can stıre binding
information in environment variables that it creates;
2. Or binding information can be saved in an application
specific config. file.
Since binding information in environment variables or configuration
files is usually stored as strings, our application will need to convert
the string to a binding. In Windows XP/2000 environments, binding
information can be retrieved from Active Directory.
What we’ll do to data binding is actually something similar to xml
data binding, however instead of xml, we’ll use our own DSL. After
retreving data in DSL format to client side, a parsing operation will be
done. Afterwards getElementByID & getElementsByTagName like
methods can be called inside the C# source code.
There are some data binding frameworks and tools which are thought
to be useful:


Integrated into the .NET Framework, in the
System.Xml.Serialization namespace.
xsd.exe - A tool Supplied with Visual Studio which generates C#
or VB.Net code from an XSD.
These first two are considered to be more beneficial for us because of
their C# support.
37

gSOAP - Open source XML data binding compilers and
autocoders for C and C++, supports SOAP, WSDL and XSD.

Liquid XML Studio - Generates cross platform C++ classes from
XSD, XDR & DTD Schemas. Memory management is
performed using reference counting via smart pointers, the code
is thread safe, and compiles on Windows, Linux, Solaris.

CodeSynthesis XSD - Open source XML data binding compiler
for C++ which provides an event-driven, SAX-like C++
mapping in addition to the standard, tree-like in-memory object
model. For closed source use, the company also offers a
commercial license.

CodeSynthesis XSD/e - Open source, validating XML
parser/serializer and C++ data binding generator for mobile and
embedded systems.

xmlbeansxx - A C++ library for easing the processing of XML
data. It is very similar to and in fact was inspired by XMLBeans.

Codalogic LMX - GUI and command-line driven royalty-free
C++ XML data binding tool. Code generator runs on Windows
and Linux. Generated code runs on wide range of C++ compliant
platforms. Free edition available.
38
4.DEVELOPMENT PROCESS
4.1. PROJECT SCHEDULE
This project is going to be completed at the end of second term.
Schedule mechanism works differently for each semester. Because
this is a graduate project, there are definite deadlines determined by
our teaching assistant and instructor. These deadlines consisted of
proposal report, requirement analysis report, initial design report, final
design report and prototype for the first semester.
4.2. PROJECT MODEL
We follow a step by step program. The steps are analysis, initial
design, more detailed design, prototype, implementation, testing &
debugging and maintenance. The most suitable process model is
“Waterfall Model” for us. After we finished one step we won’t turn
back to previous steps. So, all the features of a step must be wellunderstood and applied.
39
4.3. GANNT CHART
40
4.4. TEAM STRUCTURE
We have decided that Controlled Decentralized (CD) team structure
fits us best. Our team has a leader to keep all the work on the road and
our leader assigns sub topics to members. We have a collaborative
decision mechanism and have equal contributions and offerings to the
project. Everyone in Macrosoft has a good knowledge in different
areas. Therefore we can make some suggestions about our research
and our area of specialization.
Doruk Tekniker
-Leader
-Devil’s Advocate
-Communicator
Gürkan İlhan
Mehmet Daşıran
-Optimist
-Gate Keeper
-Initiator
-Summarizer
-Agent
-Communicator
4.5. TEAM RULES
 Unequal task distribution should be avoided. Tasks should be
shared by members equally.
 Completed tasks should be gathered in a pool, and participated
in website
 Meeting times should be arranged according to members’
weekly schedule
 Member should pay attention to meeting hours.
 Ground rules will be considered in case of disobeyment
41
5.CONCLUSION
We benefit much from previous reports so when we started our final
design report we were aware of the importance and benefits of the
final design report. We are quite aware of the importance of good
design so we give our best to design our project and prepare this
document.
We believe that this report exceeds expectations and will not only help
us in the coming months but also will help next generation Domain
Specific Kit developers in their design phases.
We changed some of design choices since the initial analysis report so
we believe that writing an final design report will reflect our project
much more better than the previos reports.
Modules and classes are explained in detail in this report and we
believe that it will make our job easy in the coming months.
To summarize we believe that Macrosoft team will get benefits of this
final design report in the coming weeks. This report will guide us
throughout the next term also. With the feedbacks from course
coordinators, our teaching assistant and our project consultant from
Cybersoft, we will build up our design.
42
6.REFERENCES
 Software Engineering – A Practitioner’s Approach
(Pressman)
 Component Oriented Software Engineering (Ali H.
Doğru)
 http://en.wikipedia.org/
 Business Rules Segregation for Dynamic Process
Management with an Aspect-Oriented Framework (S.
Çetin, N. İ. Altıntaş, R. Solmaz)
 How to Build a Domain Specific Engine- Malcolm
Chisholm
43