Documentation 10.0

POPULATION SIMULATION SYSTEM
CPSC 462: Spring 2009

Professor Haig Krikorian
Ahmad Abuqasem
David Choi
Aruni Kirtipal
Kunal Malviya
Komal Tamhane
Thanh Truong
TABLE OF CONTENTS
I. TABLE OF CONTENTS 1
II. DIVISION OF WORKLOAD 2
III. INTRODUCTION 3
IV. UML DESIGN
a. USE CASE TABLE 5
b. USE CASE DIAGRAM 8
c. SEQUENCE DIAGRAMS 9
d. UML CLASS DIAGRAM 20
e. DATA FLOW DIAGRAMS 22
f. STATE DIAGRAM 24
g. ACTIVITY DIAGRAM 27
h. LOGICAL VIEW 30
i. QUALITY & POLICY DESCRIPTIONS 31
j. QUALITY & POLICY RANKING TABLE 53
V. DESIGN PATTERNS 56
VI. ARCHITECTURE DESIGN (ARCHSTUDIO)
a. INITIAL ARCHITECTURE 61
i. USE CASE ANALYSIS OF SECOND ARCHITECTURE 64
b. REVISED ARCHITECTURE 65
i. USE CASE ANALYSIS OF FINAL REVISED ARCHITECTURE 67
c. ARCHSTUDIO SUBSYSTEMS AND MODULES 68
VII. CLASS DESIGN (PROTÉGÉ)
a. CLASS DECRIPTION 74
i. CLASS DEFINITION 75
b. PROTÉGÉ DESIGN 75
c. PROTÉGÉ PROPERTIES 77
i. PROTÉGÉ EXAMPLE 83
d. PROTÉGÉ DEMONSTRATION 85
e. OWLVIZ DEMONSTRATION 88
f. PROTÉGÉ CODE 89
VIII. PROVING THE DESIGN (ALLOY)
a. INITIAL ALLOY DESIGN WITH DEFINITION 94
b. EVALUATION OF INITIAL ALLOY DESIGN 98
c. EVALUATION OF FINAL ALLOY DESIGN 99
d. DYNALLOY 102
IX. TIME SIMULATIONS (CHEDDAR)
a. CHEDDAR 108
X. CONCLUSION 116
XI. REFERENCES 118
1
DIVISION OF WORKLOAD
The following chart represents the division of workload for our project. The percentages next
to each category was the approximate proportional amount of time we devoted to the project
and is further broken down per person. Every member of the group equally contributed
16.67% percent of the total workload.
Title Name Primary/Secondary

Documentation – 10% David Primary (10%)
Elaboration – 10% David
Thanh
Komal All Together (10%)
Kunal
Aruni
Ahmad
UML Design – 20% Thanh Primary (5%)
David Primary (5%)
Komal Secondary (2.5%)
Kunal Secondary (2.5%)
Aruni Secondary (2.5%)
Ahmad Secondary (2.5%)
Design Patterns – 10% Kunal Primary (7.5%)
Alloy – 15% Thanh Primary (10%)
Aruni Secondary (5%)
Protégé – 15% Ahmad Primary (12.5%)
Kunal Secondary (2.5%)
Archstudio – 15% Aruni Primary (7.5%)
Cheddar – 2.5% Komal Primary (2.5 %)
Dynalloy – 2.5% Kunal Primary (2.5%)
2
INTRODUCTION
The Issue
The goal of this project is to design a population simulation system where the population can
dynamically grow and decline - the only restriction is that a person cannot marry their second
cousin or anyone closer. The simulation will accomplish this by examining all the genealogical
interdependencies and marriage possibilities in a set of data for each person.
Description of Requirements and Assumptions
Initialization Stage
The initial seed consists of 5,000 males and 5,000 females all unrelated to each other.
The initial seed will have no parents or any ancestors.
The ages of the initial seed population are randomly and evenly dispersed from the age
of 1 day old to 99 years and 364 days old.
Age and Mortality

There is a required enforced mortality limit of exactly 100 years of age. If someone is
not dead by 99 years and 364 days of age, they are humanly euthanized for the
betterment of mankind.
There are 5 age classes:
o Alpha Class: 1 day to 19 years old.
o Beta Class: 20 years to 39 years old.
o Gamma Class: 40 years to 59 years old.
o Delta Class: 60 to 79 years old.
o Omega Class: 80 to 99 years old.
Marriage
Restrictions
o Marriage is defined as between a man and a woman.
o Anyone man or woman related closer than that of a second cousin are not
allowed to get married.
o Polygamy is strictly forbidden.
o Divorce is allowed and remarriage is allowed so long as it doesn’t become
polygamous.
o Inferior (either genealogically deficient, impotent, or otherwise diseased or sick)
people (statistically 1% of population) cannot get married.
o Only Beta, Delta & Gamma classes are allowed to get married.
Marriage Filters – “Compatibility Score Algorithm (CSA)”
o Marriage is based on a score from two pieces of data: A CSA score based on nine
filters and a age score based on likelihood of candidate getting married at their
respective age.
3
o Each filter is an attribute assigned a value of 1-10 based on the personality
profile of the individual.
1. Race
2. Religion
3. Education
4. Wealth
5. Health
6. Reputation
7. Cultural
8. Criminal Background
9. Location
Children
All married couples may have children.
Couples may have 0 or more children.
“Dynamically Adjusting System Clock” (DASC)

One minute of real time is equivalent to one year in the system simulation.
The system clock speed is determined by measuring the rate of percentage change of
the population from the previous year.
There are five variable clock speeds.
o Very Fast Mode - if the population growth is 9% or greater, we remove
candidates from the age classes Gamma and Delta (only couples both in the Beta
class can get married and have children) and we apply China’s 1 child only law.
o Fast Mode – if the population growth is between 6% to 8%, we remove
candidates from the age class Delta (only couples both in the Beta and Gamma
can get married and have children) and we apply Japan’s 2 child only law.
o Normal Mode – if the population growth is between 3% to 5%, then our system
will run as elucidated above (couples in the Beta, Delta and Gamma classes can
get married and have as many children as they want).
o Slow Mode – if the population growth is between 1% to 3%, we add candidates
from the age class Alpha (couples in the Alpha, Beta, Delta and Gamma can get
married and have as many children as they want) and we limit the CSA marriage
filters by only applying filters #6 through #9.
o Very Slow Mode - if the population growth is less than 1%, every person alive in
our system outside of the inferior people can get married and have as many
children as they want and we will only apply CSA marriage filter #9.
Assumptions
Each person can have and must have only two biological parents, a male and a female.
Only the system and the administrator may access the system.
4
UML DESIGN
USE CASE TABLE
The use cases that are present in the system are based on how users will interact with the
system. In our system, there are only two major actors, the administrator and the system itself.
The administrator is the outside actor (“God”) who injects themselves into the system only if
something has gone wrong or to perform diagnostics. The activities that are reserved for
administrator use only are “system startup”, “system test”, and “system self-repair”.
The system itself is the internal actor which automates most of the activities within our system.
The activities that are reserved for system use only is “determine a person’s relationship to
another person”, “dynamically adjust population control”, “check up to 2nd cousin”, and
“compatibility score algorithm”.
The administrator and the system also have shared activities that are “view a person”, “update
the database”, and “add a person”. While it is more than likely that the system will automate
most of these activities, we reserve the right of the administrator to have access to these
activities if needed.
The following charts provides a high level view of how each case interacts with the system.
5
USE DESCRIPTION ACTOR(S) PURPOSE NOTES & QUALITY OPERATIONAL
CASE ASSUMPTIONS ATTRIBUTES CONCEPTS
1 View a Administrator Requesting The person Availability System
person System to view an is present Reliability queries the
individual’s in the database to
information database. show the
Database is individual's
up to date. information
plus all the
relational
dependencies
2 Determine a System System Both Efficiency System will
person's checks to persons Reliability check the
relationship see if a male are present database to
to another and female in the see if they are
person are database; related (2nd
potential Database is cousin or
marriage up to date higher)
candidates
3 Dynamically System To Database is Efficiency System will
adjust effectively updated; Performance check the
population control Clock population
control population speed is growth every
size not normal minute (year)
and apply the
necessary
population
control filters
accordingly.
4 System Administrator To start the System is Reliability The system is
startup system functioning Usability turned on and
properly it works.
5 Update the Administrator To show the All Performance Successfully
database System most transaction Availability commits the
current s updated transaction
information in real-time and updates
in real-time. all associated
attributes
within the
system.
6
6 Add a person Administrator To add a new Person is alive. Efficiency System will
System entry to the Database Reliability create a new
database storage has entry and
not reached its update
maximum database and
capacity. new
associations
7 System test Administrator To check System is in Testability Verification
system operational Maintain- results are
performance state. ability displayed in
either textual
description or
graphical
representation
8 Check up to System To Both Efficiency If the
2nd cousin determine if candidates Reliability candidates are
the two exists in the eligible,
candidates current system will put
are eligible database. them in the
for marriage marriage
bucket.
Otherwise,
they go back
to hopper.
9 Compatibility System To generate Candidate is in Efficiency Systems
Score a age brackets always return
Algorithm compatibility Beta, Delta a suitable
score for and Gamma. match.
each
candidate.
10 System self- Administrator To remove System is Availability The system is
repair all faults malfunctioning Reliability restored to a
from the previous
system. working state.
7
USE CASE DIAGRAM
Our use cases can also be demonstrated graphically by a use case diagram. This diagram shows
the interrelationships of the users (administrator and the system) and the use cases.
8
SEQUENCE DIAGRAMS
View a Person
System Administrator requests to view an islander’s information.

System UI (User Interface) Handler responds and generates a view request to the Request
Handler.
Request Handler processes the request and runs the Rules Engine to get all associated
information, namely the rules.
Rules Engine executes a set of system rules and returns the additional rules required for the
request to the Request Handler.
Request Handler gathers all information and queries the Master Database for the islander’s
information.
Database engine returns the query results to the Request Handler which, in turn, forwards it to
the UI Handler.
UI Handler formats the retrieved data.
UI Handler displays the requested islander’s information on the screen.
9
Determine a person’s relationship to another person
PSS System Handler invokes Relationship Manager to get the relationship between Person A and
Person B.
Relationship Manager generates a family tree request for the first person (i.e. Person A) and
sends it to the Request Handler.
Request Handler processes the request and queries the island Master Database for Person A’s
ancestor records up to Great Grand Parent generation.
Database engine returns the requested records to the Request Handler which, in turn, forwards
it to Relationship Manager.
Relationship Manager generates another family tree request for the second person (i.e. Person
B) and sends it to the Request Handler.
Request Handler eventually forwards a list of Person B’s ancestors to Relationship Manager,
once again up to Great Grand Parent generation only.
Relationship Manager examines the two sets of ancestors and checks if they intersect.
Relationship Manager traverses the two family trees to find out the actual relationship (e.g. aunt
& niece).
Relationship Manager returns the retrieved relationship to the PSS System Handler.
10
Dynamically Adjust Population Control
The PSS System Handler registers with the Timer for end-of-year events (i.e. the end of
every minute)
The Timer notifies the PSS System Handler of end-of-year events.
System Handler requests for the current annual population growth on the island from
the Population Monitor Handler.
Population Monitor Handler returns the most current population growth rate to the
System Handler.
System Handler analyzes the given population growth rate.
System Handler adjusts the system clock speed accordingly.
System Clock returns the result of the operation to the PSS System Handler
11
System Start Up
System Administrator powers up the PSS (Population Simulation System).

System Handler initializes and sets all the default states and behaviors.
System Handler requests for the island’s living population.
Request Handler processes the living population request and runs the Rules Engine to
retrieve all rules that will be triggered by the request.
Rules Engine executes a set of system rules and returns the additional rules required to
the Request Handler.
Request Handler gathers all information and queries the Master Database for the
islander’s living population.
Database engine returns the query results to the Request Handler, which, in turn,
forwards it to the System Data Manager.
System Data Manager stores the data locally.
System Handler starts the Timer to keep track of elapsed time (Assumption: 1 minute of
system simulation = 1 earth year).
12
Update the Database
The PSS System Handler or some other Handler in the system generates a request to
update records in the database and sends it to the Request Handler.
The Request Handler accepts the request and runs the Rules Engine to retrieve all the
additional rules required.
The Rules Engine executes a set of system rules and returns the required set of rules
associated with the request to the Request Handler.
Request Handler gathers all information and sends a query to the Master Database to
update certain records.
Database engine returns the query result to the Request Handler which, in turn,
forwards it to the System Handler.
13
Add a person
PSS System Handler invokes the Population Monitor Handler to add a newborn baby to
the island Master Database.
Population Monitor Handler generates a new entry request and sends it to the Request
Handler for processing.
Request Handler processes the new entry request and runs the Rules Engine to retrieve
all the rules that will be triggered by this request.
Rules Engine executes a set of system rules and returns the rules required for the
current request to the Request Handler.
Request Handler collects all information and queries the Master Database to create a
new record for the new islander.
Database engine returns the query result to the Request Handler which, in turn,
forwards it to the Population Monitor Handler.
Population Monitor Handler updates the island’s current population size.
Population Monitor Handler sends the status of the original request to the PSS System
Handler.
14
System Test
System Administrator selects to run PSS built-in tests.

PSS System Handler directs Diagnostic Handler to start diagnosing the system for faults.
Diagnostic Handler retrieves the current system state from System Handler.
Diagnostic Handler determines the set of system built-in tests to execute based on the system’s
state.
Diagnostic Handler tells System Data Manager to check for data inconsistencies in the system.
System Data Manager queries the Master Database for inconsistent data patterns.
Database engine returns the inconsistent data records to System Data Manager.
System Data Manager analyzes query results.
System Data Manager reports diagnostic results to Report Handler.
Report Handler logs all reported data and invokes System Handler to display test run results on
the screen.
15
Check up to 2nd cousin
PSS System Handler invokes Relationship Manager to run an up-to-second-cousin relationship

check on Person A and Person B.
Relationship Manager generates a family tree request for the first person (i.e. Person A) and
sends it to the Request Handler.
Request Handler processes the request and queries the island Master Database for Person A’s
ancestor records up to Great Grand Parent generation.
Database engine returns the requested records to the Request Handler which, in turn, forwards
it to Relationship Manager.
Relationship Manager generates another family tree request for the second person (i.e. Person
B) and sends it to the Request Handler.
Request Handler eventually forwards a set of Person B’s ancestors to Relationship Manager,
once again up to Great Grand Parent generation only.
Relationship Manager checks for any point of intersection between the two sets, each
containing 14 ancestors.
Relationship Manager returns the lookup result (i.e. a Boolean value) to the PSS System Handler.
16
Compatibility Score Algorithm
17
PSS System Handler requests a compatibility score for Candidate A from Compatibility Manager.
Compatibility Manager verifies the candidate’s information and sets default values for
malformed attributes.
Compatibility Manager creates a Compatibility Score Algorithm instance.
Compatibility Manager sets the CSA’s Age Bracket input.
Compatibility Manager sets the CSA’s Race input.
Compatibility Manager sets the CSA’s Religion input.
Compatibility Manager sets the CSA’s Education input.
Compatibility Manager sets the CSA’s Wealth input.
Compatibility Manager sets the CSA’s Health Status input.
Compatibility Manager sets the CSA’s Reputation input.
Compatibility Manager sets the CSA’s Cultural Background input.
Compatibility Manager sets the CSA’s Criminal Background input.
Compatibility Manager sets the CSA’s Current Location input.
Compatibility Manager then directs CSA to generate a compatibility score based on the above
inputs.
CSA generates a score and returns it to Compatibility Manager which, in turn, forwards it to PSS
System Handler.
18
System Self Repair
PSS System Handler periodically queries Health Monitor Handler for its alive status.
PSS System Handler commands Health Monitor Handler to start monitoring if it has stopped
running.
Health Monitor Handler first checks to see if the Request Handler is still listening for system
query requests.
Health Monitor Handler restarts the Request Handler if it has stopped processing query
requests.
Health Monitor Handler then sends a get alive status message to other listening handlers in the
system.
Health Monitor Handler commands the inactive handlers to start processing.
Health Monitor Handler goes back to monitoring.
19
UML CLASS DIAGRAM
20
These modules together represent the software architecture of our Population Simulation System.
Person:
This module contains all the information associated with a simulated person in PSS system. A person’s
attributes such as parents, spouse, children will be used by the system to retrieve his/her family tree.
Other characteristics will be used to determine compatibility with others in the database.
PSS Client:
This module is responsible for launching the system’s web-based user interface. It presents to the user
simulation options and processes selected commands by sending a signal message to the PSS Logic
Server. PSS Client refreshes its user interface as feedbacks are received from PSS Logic Server to indicate
current simulation progress.
Request Handler:
This module runs two threads to handle all service requests. The Listener thread is responsible for
accepting requests and placing them on a queue, while the Processing thread is responsible for
removing the oldest request from the queue and processing it. With this request handling mechanism in
place, all system requests will be guaranteed to get serviced.
Ranking Manager:
This module takes the island population as an input from the Request Handler. It then applies some
filters and executes a Compatibility Score Algorithm on these islanders. At the end, people with a
passing score will be placed in a marriage candidate bucket.
CSA:
This module performs a complex computation in order to generate a compatibility score for a person
based on his/her age and other social characteristics. People with scores in the same range will be likely
to become soul mates.
Candidate Manager:
This module selects couples with the same compatibility score range and plays the system’s
matchmaker role. If the couples pass the 2nd cousin or closer relationship test, they will be placed in the
marriage bucket waiting to exchange their vows.
Marriage Manager:
This module marries chosen couples from the marriage bucket and have them bear children. It then
sends a request to the Request Handler module to first update the newlyweds’ marital status and then
add their children to the island’s master database.
Population Monitor:
This module is responsible for monitoring the annual population growth on the island. It analyzes the
yearly growth rate and sets the system clock speed accordingly. Its main role is to apply system filters to
ensure that growth rate is as close to normal as possible.
Clock:
This module accepts speed change commands from Population Monitor and sets the speed. A change in
the system clock speed will have an immediate effect on how filters are applied in the Ranking Manager
module as well as how child law restrictions are enforced in the Marriage Manager module.
21
DATA FLOW DIAGRAMS
PSS Components data flow diagram
The above data flow diagram serves as the three-tiered client-server architecture diagram with fault
tolerance for our system.
At the Presentation tier, PSS client machine is responsible for presenting feedback to and accepting
commands from the user.
At the Logic tier, PSS Business Logic Server processes simulation commands sent from the PSS client
by sending the island’s data request over to the PSS Resource Manager Server.
At the Data tier, PSS Resource Manager Server starts querying the database for the island records.
Once the records are retrieved, PSS Resource Manager forwards them to the PSS Business Logic Server
which starts the simulation of life on the island by matching and marrying people with 2 nd cousin
relationship constraints.
22
PSS Business logic server data flow diagram
The above data flow diagram illustrates all the processing logic within the PSS Business Logic Server. Life
simulation is started when the Request Handler sends the island population data to the Ranking
Manager which separates all males from females and applies filters to create a set of potential marriage
candidates, each having a generated compatibility score. Once Candidate Manager receives the set of
marriage candidates from Ranking Manager, it will start matching people (with the 2nd cousin
relationship or closer restriction) and sends the association pairs over to Marriage Manager. At the next
step, Marriage Manager will start marrying chosen couples and have them bear children. Marriage
Manager then sends the couple’s marital status and their children’s information to the Request Handler,
who will send out a command to update the Island database with the received information.
At an emulated year-end event, Population Control will ask the Request Handler for the current
population growth. Population Control analyzes the growth rate and sets the system clock speed
accordingly, in an effort to keep the population growth at a normal, expected rate. The change in system
clock speed will have an immediate effect on how the ranking algorithm and child bearing law work.
23
STATE DIAGRAM
State diagrams are used to describe the behavior of a system. State diagrams describe all of
the possible states of an object as events occur. We have three state diagrams corresponding to
three important use cases.
System Startup
System Administrator turns ON the Population Simulation System (PSS).

System is initialized as soon as it is turned ON.
The system requests for the islander’s living population.
System goes into updated state.
Records catch locally.
PSS System is ready to use.
24
Dynamic Population Control
System is ready and running.

To control the population growth dynamically, system gets the rate of population
growth.
The rate of growth is analyzed to set the clock dynamically.
Depending on the rate of growth, system will set the clock to any of the five
predetermined speeds.
25
Second Cousin Check
System is running
To determine if person A,B are related, system will fetch the person’s family tree.
The system will fetch other person’s family tree and further check for any point of
intersection i.e. system will determine if person A, B are related or share any of 14
ancestors.
System will display the results.
26
ACTIVITY DIAGRAM
Activity diagrams describe the workflow behavior of a system. This diagram basically models
the workflow of the system being designed.
System Startup
When the administrator turns ON the system, system initializes its servers and database.
Same time the GUI are also initialized.
The system queries the database to extract the living population.
27
Dynamic Population Control
System checks the population growth.

System further compares and analyzes the growth rate to set the clock to five
predetermined speeds.
The system will dynamically set the clock according to rate of population growth and
apply corresponding actions.
28
Second Cousin Check
System will first fetch the family tree of the person to check if he is related to other
person.
Once family tree is fetched the system will check for common ancestors.
If at all there is a common ancestry, system will display that the two individuals are
related else not related.
29
LOGICAL VIEW
System simulation logical view
PSS administrator starts up the system.

PSS client processes the request by sending a system simulation command to the logic
server.
PSS logic server queries the population from the PSS database server.
Database server gets the records from the database.
Everything flows back to the logic server.
The simulation starts.
30
QUALITY & POLICY DESCRIPTION
Type Number Quality Attribute Description

In our system, there
are only two actors
that can manipulate
any data in the
system: the system
itself and the
administrator (God).
Our system shall not
allow any other
“users”. Actual
“people” in the system
do not have any ability
to “write” any data.
The administrator shall
have full access to the
1 General system.
However, our system
does allow on a
limited exception for
FUNCTIONALITY “people” in our system
to be able to “view
their relationship with
another”. The
purpose of this is to
allow the option for
people to know what
relationship they have
with another person
within the system. It is
strictly a “read-only”
situation.
The system shall filter
out compatibility
issues with each other
by using a specialized
2 Suitability
algorithm called the
“Compatibility Score
Algorithm” (CSA). The
CSA involves nine
31
different filters
including race,
religion, education,
wealth, health,
reputation, cultural,
criminal background,
and location.
This score will be
assigned by using a
kind of questionnaire
or test format that
each individual must
fill out.
The system shall also
use a broad piping age
filter by ranking all the
ages of the individuals
and assigning higher
scores to people with
ages closer to the
optimal age of having
children (males = 30,
females -= 25).
The system shall keep
data on all individuals
for 400 years. After
400 years, the data is
automatically purged.
The system shall retain
accuracy of data at
99.99%.
The system shall
ensure this level of
accuracy by
redundancy in our
3 Accuracy
architecture design.
The system shall
ensure this level of
accuracy by requiring
weekly testing and
daily indexing of the
data.
32
The system ensure
interoperability by
using a TCP/IP
connection between
the different data
transactions between
interactions within 3
tiered distributed
4 Interoperability client-server
architecture with fault
tolerance.
The system will ensure
interoperability by
using IPv6 style
addressing to account
for any future
compatibility issues.
The system shall be
protected from
viruses, malware,
grayware, spyware,
denial of service
attacks, etc.
The system shall
ensure security by
using the latest and
recent copies of all
anti-spyware, anti-
virus, anti-malware
software.
5 Security
The system shall
ensure security by
using both a hardware
firewall and a software
firewall.
The system shall
ensure security by
requiring a fingerprint
and retinal scan
authentication for the
administrator to
access.
33
security by only
allowing the
administrator to have
access to modify,
change, add, delete or
alter in any form or
manner any data
whatsoever or restart
the system with a
software or hardware
reboot.
The system shall
ensure compliance
with the functionality
quality attributes by
requiring the system
be highly secure and
reliable.
6 Compliance
Compliance will be
ensured by restricting
any critical tasks to the
administrator and by
tailoring the system to
be highly redundant
and available.
34
The system shall be
mature as it uses the
standard maturity
levels of IEEE and
CMMI Level 4.
maturity by requiring
7 Maturity the hardware
specifications of our
system to be a Sun
Fire X4500 server
using a four-way x64
server running
OpenSolaris and ZFS
with 48 TB of storage.
The system shall
ensure fault tolerance
to an extreme at 100%
as any total failure in
the system would be
catastrophic as our
RELIABILITY simulation is running a
real-time population
analysis.
The system shall
ensure absolute fault
tolerance by
developing an
architecture that uses
8 Fault Tolerance
shared memory
involving multiple
servers which
constantly monitor the
other computers with
a heartbeat on hot
standby.
This architecture will
ensure that when one
of the servers goes
down, another will
take up the slack and
resume the operation
of our system without
35
any delay whatsoever.
The system shall be
recoverable easily by a
hard system boot by
the administrator.
The system shall also
be recoverable easily
by a software boot
done by the
administrator.
easy recoverability by
auto-saving to the
9 Recoverability database at the end of
every second of real-
time.
If the system does fail,
the system will ensure
recoverability by
restoring it to from the
previous save point –
in which case worst
case scenario will be
that the equivalent of
1 second of real-time
data would be lost.
The system shall
ensure ultra high
reliability as 1 minute
of “real-time” is
equivalent to 1 year of
the in the system.
The system shall be
10 Availability
available 99.999999%
of the time.
This is the equivalent
of .317 nanoseconds
in real-time per a
calendar year of 365
days, 24 hours a day.
The system shall
11 Compliance
ensure compliance
36
with the reliability
to be extremely
advanced and by
requiring an
architecture designed
around fault tolerance
and data redundancy.
Compliance will be
ensured primarily with
superior hardware.
Secondly, compliance
will be ensured by
requiring ultra high
availability.
In the event that fails,
recoverability and
fault tolerance will be
built into the system
as “stop-gap”
measures to prevent
any data loss.
37
The system has no
other actors
interacting with the
data besides the
administrator and the
system itself so the
interface shall be basic
and functional.
The system shall be
easy to learn and use
for the administrator
12 Understandability and if a person wants
to view their
relationships.
basic
understandability by
using a graphic user
interface and be user
friendly by using big
buttons and extremely
USABILITY easy to follow
instructions.
The system shall be
easy and quick to learn
for both the
administrator and the
person that might
want to view their
relationship.
learnability by
producing a step-by-
13 Learnability
step tutorial on the
web-page interface
that will address all
logical paths one can
take on the website.
learnability by making
the system as logical,
easy to use and simple
as possible.
38
The system shall have
a high degree of
operability and ease of
use.
operability by
14 Operability requiring a graphical
user interface on top
of a web-based
interface which will
allow simple
operability of the
system.
The system shall be an
attractive piece of
software by having a
graphical user
interface.
The system shall
ensure attractiveness
by hiring a web
designer and web
15 Attractiveness developer to design
and develop the front
end of the system as a
web-based interface.
The system shall look
professional, high-
tech, with a modern
interface that makes
the system look
robust.
The system shall
ensure compliance
with the usability
16 Compliance
to be easy to use and
be a graphical user
interface and use a
web-based interface.
Compliance will be
39
ensured by creating an
interface which is
extremely easy to use
and will have a built in
tutorial and many of
the functions will be a
simple one-click
operation.
Compliance will be
ensured by designing
the system so it feels
intuitive and natural
for both the
administrator and any
person wishing to view
their relationships.
40
The system shall
ensure time behavior
my building into the
architecture strict
restrictions about how
quickly data must be
executed.
Time behavior is linked
to recoverability and
thus without a high
degree of this
attribute, backups will
not exist.
The system shall
execute any query it’s
given within 5
milliseconds.
17 Time Behavior
The system shall
commence backups at
the beginning of every
second and finish at
EFFICIENCY the end of every
second.
This backup will
ensure that all activity
of the previous second
will be fully backed up.
Thus, a full backup of
the data will take up
to 90 milliseconds and
the delay in the actual
backup process can be
as great as 10
milliseconds.
The system shall utilize
the optimal amount of
resources at all times.
The system shall
18 Resource Utilization accommodate all
requests by providing
whatever resources it
needs.
41
deadlock prevention
by using an algorithm
to prioritize resources
and to age and
prioritize every event.
Resource utilization
will be ensured by
dividing multiple tasks
in parallel and be
handled by multiple
processors to achieve
optimal efficiency.
The system shall
ensure compliance
with the efficiency
functionality quality
attributes by requiring
the system always
accomplish its data
transactions in the
same amount of time
– all the time.
Compliance will be
ensured by using
hardware components
19 Compliance
that will guarantee to
meet the worst case
scenario in terms of
processing power.
Compliance will be
ensured by requiring
data for each person
to be stored for only
400 years (400
minutes in real-time)
so as to prevent excess
data from floating in
the system.
42
The system shall be
easily diagnosed and
analyzed for any
software errors or
hardware failures in
the system.
Analyzability shall be
20 Analyzability ensured by requiring
the administrator to
run scheduled
analyzer tests every
week to check for
overall system
performance and
diagnostics.
The system shall easily
modifiable and easy to
change.
Changeability will be
ensured by developing
the entire software
MAINTAINABILITY
around the J2EE
framework.
21 Changeability Changeability will be
the entire software
architecture be
developed around and
restricted to only Java
and Java technologies
thus ensuring full
100% compatibility.
The system shall be
one that is extremely
stable and resistant to
any kind of hardware
or software failures.
22 Stability
Stability will be
ensured by running
periodic tests and
system diagnostics on
a weekly basis.
43
Stability will be
ensured by checking
weekly to see if the
system is running
efficiently and
normally.
Stability will be
ensured by checking
for any deviant
behavior or anomalies
on a weekly basis.
regular basis. .
The system shall be
easily testable and be
easy to run diagnostics
to see if there is
anything wrong with
the system.
Testability will be
23 Testability ensured by having unit
testing available to the
administrator.
Testability will be
ensured by having
integration testing
available to the
administrator.
The system shall
ensure compliance
with the
maintainability quality
attributes by requiring
the system be highly
adaptable and easy to
24 Compliance test for.
Compliance will be
the system in a
common framework
and to create a series
of tests easily usable
to the administrator.
44
The system shall be
capable of handing at
least 25 million
transactions per
second at any given
time.
The superset of
transactions will
include making all
25 Adaptability transactions regarding
any and all
associations.
Adaptability will be
ensured by running
multiple stress testing
scenarios to see how
many transactions the
system can handle at
any given time.
The system shall be
easily installable as on
PORTABILITY
different servers.
Installabiltiy shall be
ensured by using a
easy to use one click
26 Installabiltiy
self executing
installation package
that does “everything”
once the administrator
simply runs the
application.
The system’s
individual servers shall
each co-exist by
themselves as stand-
alone units.
27 Co-Existence Co-existence shall be
all the hardware
components and
software modules to
be in one physical
45
machine, one server at
a time.
The system shall be
easily replaceable in
the event that a
hardware component
or software module
becomes faulty.
Replaceability is
ensured by using off-
the-shelf hardware
components and
software modules that
28 Replaceability
are based in object-
oriented programming
languages so it is easy
to isolate the problem.
Replaceability is
regular weekly
maintenance of both
hardware components
and any buggy
software modules.
The system shall
ensure compliance
with the portability
rely on industry
standard hardware
components and
29 Compliance
software modules.
Compliance will be
superior hardware and
superior software to
be used throughout
the lifecycle of the
system.
46
The system shall not
only be an effective
system but it will be
cost-effective as well.
Effectiveness shall be
ensured by having the
system fulfill the
purpose for which it
was created. as fulfill
30 Effectiveness the purpose for which
it was designed.
Effectiveness shall be
determined solely by
the administrator’s
feedback as to how
well the system
operates according to
the user experience
the administrator has.
The productivity of the
system is determined
QUALITY
by how well the
system does the task
it’s supposed to do.
An effective system
will be productive if it
does its required tasks
efficiency and needs
31 Productivity
minimal updates,
patches, or general
maintenance.
Productivity will be
determined primarily
by the amount of
unnecessary
interaction with the
administrator.
The system will be
absolutely safe by
32 Safety having multiple layers
of security.
Safety will be ensured
47
by having the system
locked in a secured,
top-secret classified
location.
by allowing access to
the actual system by
bypassing a military
grade security
perimeter system with
12 armed guards
24/7/365.
by requiring both a
retina and handprint
scan before the
administrator is
allowed inside.
by requiring the
administrator to
submit a password
consisting of 128
unique characters.
The satisfaction of the
system will be
determined by the
usefulness and
happiness of the user
experience of the
33 Satisfaction administrator.
Satisfaction will be
a system to meet the
needs and
requirements of the
administrator.
48
Our system shall be
functional because the
allocation of resources
will always be
optimized and take
place using a deadlock
prevention algorithm.
Functionality shall be
ensured as it depends
on a First-Come First-
Serve (FCFS) priority
basis, unless there is a
34 Functional
high priority request.
In the event of a high
priority request, that
event shall be handled
before any other
event and be preempt
any pending events.
Deadlock prevention
shall be ensured by
POLICY also creating a TTL
(time to live) attribute
for any and all events.
The integrity of the
data in our system
shall be maintained by
not allowing any
outside access to
manipulate or change
the data outside of the
administrator.
The data shall remain
35 Data concurrent and
standard by updating
the database every
second.
Data for each person
in the system shall be
kept updated every
second for a total of
400 minutes in real-
time (400 years in the
49
system).
This data shall be aged
by using a aging
algorithm for any and
all data attributes.
The data shall be
purged after 400
minutes.
The system shall be
dynamic and shall be
maintained by the
system clock which is
adjusted dynamically
36 Control at every minute by
comparing the system
population difference
rate on a year to year
(every minute in real
time) basis.
The system’s control
and data interfaces
are the system clock
that maintains all the
events of the system.
The system shall be
Control/Data
37 maintained by the
interfaces
system clock.
Data shall be
transmitted by a data
bus and events shall
be transmitted by an
event bus.
The system shall
generate its events
from the system clock.
Based on the system
clock, the system will
38 Event
alter its events
dynamically to allow
more or less
population growth in
order to keep the
50
system functioning.
The system shall
maintain data for each
person for 400 years in
the system (400
39 State maintenance minutes in real-time).
The data shall be
purged automatically
from the database
after 400 minutes.
The system shall have
an administrator
interface for the
administrator’s use
only.
40 Interfaces
The interface will be a
graphical user
interface and be web-
based and use
Windows style logic.
The system shall
consider 1 minute of
real time to be 1 year
in the system.
The data shall be
maintained for 400
years or 400 minute of
41 Behavior over time real time.
The system shall rank
different data in
different priorities
over time depending
on how long the event
has lived in the
system.
The system shall purge
all data for each
individual after 400
42 Time Relationships minutes (400 years in
the system).
This data will be
automatically deleted
51
from the database.
The system shall
execute all tasks in a
specific sequence.
The system shall first
do its events using a
43 Time sequences FCFS algorithm.
If an event is a high
priority task, the
system shall preempt
that event and assign
it as a high priority.
The system shall be
built using an
architecture that can
handle multiple
transactions
concurrently in real-
time.
44 Time concurrencies
The system shall be
able to update the
database in real-time
and will alert the
administrator if there
is any redundant or
recurrent data.
The system shall be
able to handle
multiple requests at
the same in parallel.
time synchronization
by building an
architecture that can
45 Time synchronization
handle multiple
processes.
Every event in the
system shall have its
own priority which will
be executed in the
respective order of the
priority.
52
QUALITY AND POLICY RANKING TABLE
This is a quality and policy ranking chart which ranks the use cases by the qualities that we
found to be the most important in our design.
Type/Use Case 1 2 3 4 5 6 7 8 9 10 Total Rank

General 10 10
Suitability 10 10
Accuracy 10 10 120 4th
FUNCTIONALITY
Interoperability 10 10
Security 10 10
Compliance 10 10

Maturity 10 10 10 10 10 10 10
Fault Tolerance 10 10 10 10 10 10 10
RELIABILITY Recoverability 10 10 10 10 10 10 10 350 1st
Availability 10 10 10 10 10 10 10
Compliance 10 10 10 10 10 10 10

Understandability 10 10 10
Learnability 10 10 10
USABILITY Operability 10 10 10 150 2nd
Attractiveness 10 10 10
Compliance 10 10 10

Time Behavior 10 10 10 10 10
Resource 10 10 10 10 10
EFFICIENCY 150 2nd
Utilization
Compliance 10 10 10 10 10
53
Analyzability 10
Changeability 10
MAINTAINABILITY Stability 10 50 6th
Testability 10
Compliance 10

Adaptability
Installability
PORTABILITY Co-existence 0 7th
Replaceability
Compliance

Effectiveness 10 10
Productivity 10 10
QUALITY 80 5th
Safety 10 10
Satisfaction 10 10
We assigned a value of “10” to quality and policy attributes which we valued the most in our
design and a nil value to those that we didn’t feel were particularly important for the given use
case. Based on this, we added up the total for each quality or policy type and ranked them –
the more points, the more important that quality or policy was for our architecture and design.
“Our most important quality was that of reliability”.
Not surprisingly, our system was designed with the idea that it must have ultra high reliability
as the system is conducting a test of a population living system where thousands of years will
pass by in few hours. As such, downtime of even a couple of seconds can have huge effects on
our data. Therefore our system has an extreme emphasis on being reliable and our
architecture design (described below) is meant to reflect this.
54
“Our second highest qualities were that of efficiency and usability”
As our system is performing thousands of transactions per second, the system must be highly
efficient and must prioritize this quality as one of the highest. Further, our system must also be
one that has a high degree of usability. Due to the complexity of data and amount of data
being piped through out system, it is important that the design reflect a relatively easy way for
the data to be understood and processed by any users (the administrator and the system itself).
This quality requirement is reflected in our architecture design below.
“Our next highest quality attribute is that of functionality.”
Our system must function at a high level and maintain accuracy of its data. A lot of the aspects
of functionality are already covered redundantly by the reliability and the usability attributes so
our functional quality attribute is not necessarily the highest. Nonetheless, it is important that
our system be highly functional and remain secure as data tampering of any kind can be
disastrous as reflected in our architecture below.
“The next highest is the policy attribute of quality.”
The goal of the system is to create a system where overall high quality is achieved and
maintained throughout the life of the project. Not only should the product be satisfying and
productive, it should be effective as well. However, quality is not a very high attribute in our
design process so its priority remains lower in our scope of overall architecture design and is
reflected as below.
“The next quality attribute to consider was maintainability.”
The most important aspect of this quality attribute was that it involved testing and maintaining
of our system. Our system is designed with reliability being the most important quality
attribute so our system is designed to withstand many different type of failures. For our design,
maintainability only comes into play to enhance the usability or functionality of the overall
system and thus is not a very important aspect within the overall architecture design planning.
“The last quality attribute is that of portability.”
This attribute, while important in some regards, actually scored a 0 for our system design. Our
system is a highly complex design that requires very high powered, expensive software and
hardware components. It must also be constantly monitored and secure. Thus, making the
system as to cater to portability is the least important aspect when it comes to designing our
system. Thereby, portability did not reflect our overall architecture design.
55
DESIGN PATTERNS
A design pattern names, abstracts, and identifies the key aspects of a common design structure
that make it useful for creating a reusable object-oriented design. The design pattern identifies
the participating classes and instances, their roles and collaborations, and the distribution of
responsibilities. Each design pattern focuses on a particular object-oriented design problem or
issue. It describes when it applies, whether it can be applied in view of other design constraints,
and the consequences and trade-offs of its use.
Creational Patterns
Creational design patterns abstract the representation process. They help make a system
independent of how its objects are created, composed, and represented. There are two
recurring themes in these patterns. First, they all encapsulate knowledge about which concrete
classes the system uses. Second, they hide how instances of these classes are created and put
together. The creational patterns give you a lot of flexibility in what gets created, who creates
it, how it gets created, and when. Configuration here can be static ( at compile-time) or dynamic
(at run-time).
Creational Pattern Description & Use

Abstract Factory Abstract Factory helps in creating a interface
which includes making buttons, text box for
our system. Operations like submitting the
data or fetching some information would be
accomplished through the use of a factory.
Builder Builder can used for the male process and
female process subsystem to narrow down
the person according to their age and using
compatibility score algorithm. The output is
then passed through the candidate subsystem
Factory Method It defines an interface for creating an object,
but let subclasses decide which class to
represent. In our system a person record in
the island database can be used as a factory
method. The Factory Method maps one
record of a Person object to one entry in the
database.
Prototype It specifies the kinds of objects to create using
a prototypical instance, and create new
objects by copying this prototype. Adding a
person, creating set of association or checking
for second cousin are the most common
activity in our system and hence this can be
use a prototype to create new objects by
56
copying it.
Structural Pattern
Structural patterns are concerned with how classes and objects are composed to form larger
structures. Structural class patterns use inheritance to compose interfaces or implementations.
This pattern is particularly useful for making independently developed class libraries work
together.
Structural Pattern Description & Use

Adapter It convert’s the interface displaying
information into another interface readable
by the client. Adapter lets classes work
together that couldn't otherwise because of
incompatible interfaces.
Bridge The intent of this pattern is to decouple
abstraction from implementation so that the
two can vary independently.
Composite Compose objects into tree structures to
represent part-whole hierarchies. Composite
lets clients treat individual objects and
compositions of objects uniformly.
Decorator The intent of this pattern is to add additional
responsibilities dynamically to an object. It
works in combination with adapters to
decorate the GUI design of the system.
Whenever the information is ready to be
shown to the user, decorator puts the data up
and present it in a more fashionable way.
Facade A façade is an object that provides a simplified
interface to a larger body of code, such as
a class library. The facade pattern can make
the task of accessing a large number of
modules much simpler by providing an
additional interface layer.
Flyweight This pattern uses sharing to support a large
number of objects that have part of their
internal state in common where the other
part of state can vary. The data table uses a
pointer system to share information about
the records instead of recopying the
information into each record of the system.
Storage of the parent and children
information about each persons stored
57
dynamically instead of statically.
Proxy The Proxy can be used for two areas in the
system: connection in the client-server system
and storage of information into the static
memory. The client-server system has a proxy
connection to connect the data from one port
location to another. Also the proxy can be
used for a 24-hour backup on the data in a
separate data table to save for availability and
recoverability.
Behavioral Pattern
Behavioral patterns are concerned with algorithms and the assignment of responsibilities
between objects. Behavioral patterns describe not just patterns of objects or classes but also
the patterns of communication between them. These patterns characterize complex control
flow that's difficult to follow at run-time. Behavioral class patterns use inheritance to distribute
behavior between classes.
Behavioral Pattern Description & Use

Chain of Responsibility The Chain of Responsibility design pattern
allows an object to send a command without
knowing what object will receive and handle
it. In our system, information would be
requested by client from server which in turn
will perform the necessary execution needed
to perform the action and deliver the results
to user.
Command It encapsulates a request in an object and
allows the parameterization of clients with
different requests. It encloses a request for
specific action inside an object and gives it a
known public interface. For example check for
cousin is a commanding class.
Interpreter The Interpreter pattern describes how to
define a grammar for simple languages,
represent sentences in the language, and
interpret these sentences.
Iterator It provides a way to access the elements of an
aggregate object sequentially without
exposing its underlying representation. For
this purpose link list or a hash table can be
use, that would help us to chain all of the
children for that particular person and the
58
iterator can iterate through the children when
a search or add function is needed.
Mediator A mediator is responsible for controlling and
coordinating the interactions of a group of
objects. Clock can be use as a mediator which
dynamically adjusts working of all other
classes so that classes don’t have to refer to
each other to perform appropriate action.
Memento A memento is an object that stores a
snapshot of the internal state of another
object—the memento's originator. Update
Database subsystem updates and creates
checkpoint every second in order to do the
roll back in case of any errors.
Observer Intent is to define a one-to-many dependency
between objects so that when one object
changes state, all its dependents are notified
and updated automatically. Male process
subsystem notifies the update status
subsystem whenever it completes the
requested process so that update status
subsystem can act accordingly.
State Allow an object to alter its behavior when its
internal state changes. The object will appear
to change its class. Clicking on button will
prompt for different actions according to the
request. For example
Strategy Define a family of algorithms, encapsulate
each one, and make them interchangeable.
Strategy lets the algorithm vary
independently from clients that use it. There
are common situations when classes differ
only in their behavior. For this cases is a good
idea to isolate the algorithms in separate
classes in order to have the ability to select
different algorithms at runtime.
Template Method It creates a template for certain algorithm and
the same algorithm can be extended to
subclasses which would only require to
redefine few steps like the algorithm for
Person class will not contain the gender and
we just need to specify gender for these
subclasses.
59
Visitor Represent an operation to be performed on
the elements of an object structure. Visitor
lets you define a new operation without
changing the classes of the elements on which
it operates.
60
ARCHITECTURE DESIGN
INITIAL ARCHITECTURE DESIGN
Figure 1 – First Architecture Design
Our first attempt at an architecture started with coming up with a series of requirements and
from that we formulated an architecture which turned out to be overly restrictive. The result
was an architecture which was nothing but a series of “if-then” statements written in a flow
chart style system. This system was flawed as it was far too simplistic and just functioned as a
call and return system.
61
We went back to the drawing board and decided that our previous iteration of an architecture
had way too many restrictions which resulted in a system that "could" work, but was not
flexible to handle any dynamic changes in our system.
Our architecture was then revamped and we started our design from almost from scratch. We
left some remnants of our previous attempt of an architecture including the idea of having an
initial seed, age brackets, enforced euthanasia of 100 years of age, marriage and children
restrictions (only couples in the beta, gamma and delta groups can get married and have
children). We then developed an architecture that was built to handle exceptions and
“calamities” in a world that would loop and continue forever.
We introduced two novel ideas to our system which involved a series of ranked filters for Males
and Females before they entered into our "candidates to be married" bucket. These filters are
race, religion, education, wealth, health, reputation, cultural, criminal background and location.
Each candidate is given a score per attribute (scores of 1-10) and each candidate is given a
score for their age based on our age ranking filter. At that point, our "Compatibility Score
Algorithm" is run, and each candidate is assigned a final "score". Candidates who have the
most similar scores for each other are most likely to get married to each other.
Our second novel idea was using a system to rate our system clock speed to 5 different speeds.
This dynamic clock would serve to regulate any depopulation or overpopulation scenarios. Our
system clock is based on checking the amount of total population every year. If the population
has decreased more than normal, the system clock will be sped up to repopulate the
population. Conversely, if the population is increasing more than normal it will enter into fast
or very fast, the system clock will slow down so population growth can be curbed.
Our first architecture contains several major subsystems which in totality is called our “Business
Logic Server”. These subsystems are: initial startup subsystem, a family subsystem, a
population subsystem, a candidate subsystem, a update status subsystem and a event bus
subsystem. The subsystems are described more fully below in our “Archstudio Subsystems and
Module” section.
62
Figure 2 – Second Architecture Design
In our first architecture, we used only a pipe and filter architecture and immediately we came
to realize that this would create problems regarding the quality attributes we wanted to
emphasize the most. The most important quality attribute we have is reliability and we felt
that system like this would suffer in reliability. The reason we felt reliability was threatened
was because literally every transaction was taking place on our business logic server. Thus, we
felt that adding another server to act as a client would offload some processing power thus
making our business logic server more reliable.
The second most important quality attribute we wanted to address dealt with usability. We felt
that in this system it would be difficult for the administrator to access the business logic server
because the only access would be to physically access the server. This is both burdensome and
cumbersome and impedes greatly on usability. We felt that adding a client component to the
business logic server would make our system more usable.
“To solve both issues we added a client-server architecture to our pipe and filter
system and ended up with a 3 tiered architecture. This helped us address issues of
reliability and usability but doing so does hurt in terms of maintainability (as there
is more to maintain now) and portability (it is harder to “move” the system if
needed). However, because both maintainability and portability are low on our
priorities, this modification to our system was made.”
We then ran a use-case analysis based on our second architecture in order to see how the
architecture fit into our design.
63
Use Case Analysis of Second Architecture Design
USE CASE DESCRIPTION ACTOR(S) PURPOSE ARCHITECTURE TYPE

1 View a person Administrator, Requesting to view 3-tier client-server
System an individual’s
information.
2 Determine a System System checks to Pipe and Filter
person's see if a male and 3-tier client-server
relationship to female are
another person potential marriage
candidates.
3 Dynamically System To effectively Pipe and Filter
adjust control population
population size.
control
4 System startup Administrator To start the system 3-tier client-server
5 Update the Administrator, To show the most Pipe and Filter

database System current information 3-tier client-server
in real-time.
6 Add a person Administrator, To add a new entry 3-tier client-server
System to the database.
7 System test Administrator To check system 3-tier client-server
performance.
8 Check up to 2nd System To determine if the Pipe and Filter
cousin two candidates are 3-tier client-server
eligible for
marriage.
9 Compatibility System To generate a Pipe and Filter
Score Algorithm love/compatibility
score for each
candidate.
10 System self- Administrator To remove all faults 3-tier client-server
repair from the system.
64
FINAL REVISED ARCHITECTURE DESIGN
Figure 3 - Third Architecture Design
After we ran our use-case analysis against our second architecture we realized there were still
some outstanding flaws and problems in our architecture. We felt that our system was still not
efficient enough because there was far too much emphasis and processing power on one
server, namely our business logic server. Further, we felt that having our system rely just on
one main database could possibly be a bottleneck and also create functionality issues.
To address efficiency we felt that we needed to split up the business logic server into two
separate business logic servers. They would essentially work the same but they would basically
split up the work in half. Each of the business logic servers would still have an event and data
bus and each would contain two modules (instead of four in the previous architecture).
With respect to functionality, we felt that having two database servers instead of one would
create higher security, performance and thus functionality. If there are two databases, one of
them would function more in tertiary role and be used as a “read-only” database thus providing
load balancing and less constant writing to the database.
“To resolve both efficiency and functionality issues, we added a distributed feature
to our 3-tiered architecture. The business logic server was split into two
distributed servers as was the database server. This helped the system be both
more efficient and more functional. The cost that this would have on our overall
system would be that again both maintainability and portability would be harder
to implement. A system with more servers is harder to test for and keep well
maintained (such as running diagnostics and weekly performance testing).
Further, a system with so many physical components would be very hard to keep
portable. However, the cost of adding more efficiency and functionality greatly
outweighed the low cost of maintainability and portability so this modification to
our system was made.”
65
Figure 4 – Final Revised Architecture Design
After our third architecture, we still felt the lingering issue that our system was still not reliable
enough. What if any of our seemingly many servers failed? Our system which required such
high reliability would come to a spectacular fault. Thus, we felt that our system needed
redundancy to make our system truly fault tolerant and therefore extremely reliable. This task
was accomplished by adding a “clone” of each server at every point in our architecture. There
were now four total business logic servers (two primary, two backup) and four database servers
(two primary, two backup). After modifying our architecture, we then ran a use-case analysis
based on our final revised architecture and was satisfied with our final architecture.
“To achieve extreme reliability we added fault tolerance to our existing 3-tiered
architecture. Each business logic server was cloned and each database server was
also cloned. This helped guarantee our system would be reliable and fault
tolerant. As before, the cost that this would have on our overall system would be
again that both maintainability and portability would be harder to implement. In
addition to those, adding redundancy would also have a cost in terms of overall
efficiency and performance because now there needs to be processing power that
constantly sends out a “heartbeat”. The system will also now need to
accommodate some kind of shared memory infrastructure so our backup servers
could immediately come out of hot standby when the primary went down.
However, the cost of adding extreme reliability (our most important quality) is so
great that so we were willing to sacrifice a little bit of efficiency, performance,
maintainability and portability. ”
66
Use Case Analysis of Final Revised Architecture Design
USE CASE DESCRIPTION ACTOR(S) PURPOSE ARCHITECTURE TYPE

1 View a person Administrator, Requesting to view Distributed 3-tier
System an individual’s client server
information.
2 Determine a System System checks to Pipe and Filter
person's see if a male and Distributed 3-tier
relationship to female are client server
another person potential marriage
candidates.
3 Dynamically System To effectively Pipe and Filter
adjust control population
population size.
control
4 System startup Administrator To start the system Distributed 3-tier
client server w/ fault
tolerance
5 Update the Administrator, To show the most Pipe and Filter
database System current information Distributed 3-tier
in real-time. client server
6 Add a person Administrator, To add a new entry Client-server
System to the database. Distributed 3-tier
client server
7 System test Administrator To check system Distributed 3-tier
performance. client server w/ fault
tolerance
8 Check up to 2nd System To determine if the Pipe and Filter
cousin two candidates are Distributed 3-tier
eligible for client server
marriage.
9 Compatibility System To generate a Pipe and Filter
Score Algorithm love/compatibility
score for each
candidate.
10 System self- Administrator To remove all faults Distributed 3-tier
repair from the system. client server w/ fault
tolerance
67
ARCHSTUDIO SUBSYTEMS AND MODULES
Initial Startup Subsystem
This is the initial startup subsystem. It contains the initial startup module, the male process
subsystem and the female process subsystem. The male and female process subsystem are
explained below.
68
Male Process Subsystem
Female Process Subsystem
Both male and female subsystems contain five modules: the input of the initial seed, the age
bracket filter, the age ranking, the 9 filters that feed into the CSA , and the results of the
Compatibility Score Algorithm (CSA).
The data flows from the initial seed into the age bracket filter at which point the ages of the
individuals are hard filtered based on ages. The eligible individuals are then ranked according
to likelihood of marriage and child rearing. Following that, the individuals are filtered through 9
different filters. After all the filtering, individuals are assigned a “score” from the CSA which
determines the likelihood of marrying someone similar to you. After this, they are put into the
“candidate” bucket and become eligible to be married.
69
Candidate Subsystem
This is the candidate subsystem. This contains the candidate module and the 2nd cousin
module. The candidate module collects all the eligible candidates that can and will get married.
The set of associations are made between all eligible candidates. The set of associations are
then updated again when they are checked for second cousin status.
Family Subsystem
This is the family subsystem. This contains the marriage module and children module. Here the
candidates who are the most compatible (as determined by the CSA) will get married, their
marital status will be updated and finally they will be placed in the “married’ bucket. The
people in the married bucket may have as many children as they want. Any changes in the
population via childbirth will be updated into the database.
70
Population Subsystem
This is the population subsystem. It contains the age population module and clock module. This
is the most important subsystem as its responsible for how “fast” the system moves and it ages
the population.
For every minute that passes in “real-time”, the system will age the population by one year.
Initially, the clock speed is set to normal which assumes that the rate of population fits within
the normal category. The system will check for population differences dynamically by
comparing the number of people on the island to the previous year. If there is a sharp
imbalance (hyper growth or massive extinction), the system clock will automatically adjust to
accommodate fast or slow growth in the population.
71
Update Status Subsystem
This is the update status subsystem. It contains the marital status check, living check and clock
check modules. The update status subsystem accounts for the current status of any and all
individuals in the system. This includes whether or not an individual is already married,
whether or not they are alive and it checks the clock to see what speed to operate at.
72
Event Bus Subsystem
This is the event bus subsystem. This

subsystem is responsible for all events the
system is generating. It contains the
queries database module, the update
status subsystem, the SOA module, update
SOA module, update database module,
one year older module and the set clock
speed module. the queries database
73
CLASS DESIGN
CLASS DESCRIPTION
The main class of objects that are dealt with by the data is by the use of the Person class. Inside
of the data table, the data is stored in the form of Person records containing information about
the person: such as identification number, the two parents of the person, the children, and a
possible spouse. To represent the structure of the parents, children, and spouse: pointers to
those records are used as in the next figure. Each structure is represented as the following:
Id Parent1 Parent2 Child Spouse
Figure 1: A structural design of the class Person
Using this structure of id’s and pointers, construction of the tree is fairly simple. When new
Person data comes into the system, the identification number is computer generated unique
hashed value for the record. Once the identification number is generated, the two parents are
pointed to and the children and spouse are made null initially. The following diagram is an
example set of connected Person objects:
Figure 2: An example set of connected Person objects.
From this class description, the implementation design of the Person object can be defined
relatively simple. There are structures made for each Person object and a dynamical Linked List
used for the children so that the size of the children can grow easily when new children are
added into the system.
74
Class Definition
Using the class description, the Person object would be structured as so:
Abstract class Person

{
String id;
Person *parents, *spouse;
LinkList<Person> *children;
};
The person class is abstract due to the fact that is class is extendible in the Alloy design for the
Man and Woman classes. The Man and Woman classes are ignored for the Protégé level to
keep the classes simple.
PROTÉGÉ DESIGN
From the class definition, this information can be carried over into Protégé. In Protégé, each
class (in this case, the Person) is considered to be one set of information with individuals or
instances in the class. For the Protégé description and design, only the Person class is
considered for simplicity purposes.
Using the set, Person, in Protégé there are two more features to be added into the class that
must be defined: child and spouse. A child defines the relationship between instances of a
Person to another instance of a Person and similarly a spouse is of the same relationship. To
relate one instance of a class to another, a definition in the object properties is made: hasChild
and hasSpouse which can be represented as in the following figure.
Figure 3: Definition of hasChild and hasSpouse written in Protégé

75
The hasChild and hasSpouse are considered to be object properties that are asserted meaning
they must be specified by the system as information supplied by the user. All other properties,
about a Person, are inferred and must be determined using Protégé rules.
hasChild: The domain and range for this property is in the mapping of Person to Person where
one instance of Person maps to another instance in Person. This property is the inverse of the
property hasParent.
hasSpouse: The domain and range for this property is in the mapping of Person to Person
where one instance of Person maps to another instance in Person.
In Protégé, the definition of Person is as follows:
Figure 4: Definition of Person Object and Instances in Protégé
76
PROTÉGÉ PROPERTIES
The inferred object properties are items that must be determined from the asserted properties.
The following table below contains all of the object properties that are inferred by the system
which have a specific D/R (domain and range) and chain property which describes their action:
Object Properties D/R Chain Property

hasParent Person inverse of hasChild
hasSibling Person hasParent o hasChild
hasGrandParent Person hasParent o hasParent
hasGrandChild Person inverse of hasGrandParent
hasGreatGrandParent Person hasParent o hasParent o hasParent
hasGreatGrandChild Person inverse of hasGreatGrandParent
hasFirstCousin Person hasParent o hasSibling o hasChild
hasSecondCousin Person hasGrandParent o hasSibling o hasGrandChild
hasAncestor Person hasParent o hasParent o hasParent
hasParent o hasParent
hasParent
hasDescendent Person hasChild o hasChild o hasChild
hasChild o hasChild
hasChild
isRelatedTo Person hasDescendent o has Ancestor
hasAncestor o hasDescendent
CantMarry Person isRelatedTo
Table 1: Object Properties using a Chain Property
hasPatrent: This property is the inverse of the hasChild object property. If a person X has
a child Y, then Y has a parent X.
hasSibling: This property is found by looking at the parent’s children.
hasGrandParent: The grandparent property is found by looking for the parent’s

parents.
hasGrandChild: The grandchild property is the inverse of the hasGrandParent

property that finds the children’s children.
hasGreatGrandParent: In the hasGreatGrandParent property, the parent’s of the

parent’s parents is looked at.
hasGreatGrandChild: The hasGreatGrandChild property is the inverse of the

hasGreatGrandParent, the children’s of the children’s children is looked at.
77
hasFirstCousin: The property of hasFirstCousin finds the children of the sibling of the
parent.
hasSecondCousin: The property of hasSecondCousin finds the grandchildren of the

sibling of the grandparent.
hasAncestor: The ancestor of a person is found by an object property hasParent and

hasParent and hasParent.
hasDescendent: The descendent of a person is found by an object property hasChild

and hasChild and hasChild.
isRelatedTo: To be related to a person, that person could be related up to the

greatgrandparent level, be an ancestor, or be a descendent. From the greatgrandparent
level, the descendents of the people up to the greatgrandparent level also will be
related.
CantMarry: To not marry a person, that person cannot be related up to the

greatgrandparent level, be an ancestor, or be a descendent. From the greatgrandparent
level, the descendents of the people up to the greatgrandparent level cannot also be
married.
78
Each of these object properties can be defined using one or more of the following
characteristics: functional (F), inverse functional (I), transitive (T), symmetric (S), asymmetric
(A), reflexive (R), and ir-reflexive (X). The following figure contains the type of characteristic that
each object property has:
Object Properties F I T S A R X
hasChild X
hasParent X
hasSibling x x
hasGrandParent x x
hasGrandChild x x
hasGreatGrandParent x x
hasGreatGrandChild x x
hasFirstCousin x x
hasSecondCousin x x
hasAncestor x x
hasDescendent x x
isRelatedTo x
CantMarry x
Table 2: Object Properties with their Characteristics
Properties that have multiple uses of the same object property are considered to have
transitivity (hence hasGrandParent, hasGrandChild, hasGreatGrandParent, and
hasGreatGrandChild all use transitivity). Symmetric properties are ones where one direction
means that the other direction must be included, for instance if (a, b) is in the set then (b, a
must also be in that set. Siblings, First Cousins, and Second Cousins all use symmetry when
describing these relationships. Finally all of the properties are ir-reflexive because people
cannot declare themselves as any of these object properties.
79
The property chain for the hasSibling operation is written in Protégé as shown below:
Figure 5: Property Chain for hasSecondCousin Object Property
Figure 6: Property Chain for hasFirstCousin Object Property
80
Figure 7: Property Chain for isRelatedTo Object Property
Figure 8: Property Chain for hasSibling Object Property
81
Figure 9: Property Chain for hasGrandParent Object Property
Figure 10: Property Chain for hasGreatGrandParent Object Property
Figure 10: Property Chain for hasGreatGrandParent Object Property
82
Protégé Example
The following diagram shows how Protégé works for a particular example:
Figure 11: An Example of a Set of Instances for Protégé
In this example, supposed that A is the instance of interest. If hasChild is called on A,

then it should return B (each of the black lines represent the hasChild object property)
object property hasParent is invrerse property of hasChild . If hasGrandParent is called
on A, then it tries to infer this information:
A hasGrandParent (?)
A hasParent (?) hasParent (?)
To solve this, set of question marks, the system tries to use the information given to solve the
problem:
A hasParent B hasParent C
A hasGrandParent C
Since hasGrandParent is ir-reflexive, A cannot be in the set of A hasGrandParent A. Taking a

much harder example, hasFirstCousin, the property again evaluates similar to that of the
hasGrandParent Property.
A hasFirstCousin (?)
83
A hasParent (?) hasSibling (?) hasChild (?)
A hasParent B hasSibling (?) hasChild (?)
A hasParent B hasParent (?) hasChild (?) hasChild(?)
A hasParent B hasParent C hasChild (?) hasChild(?)
A hasParent B hasParent C hasChild (B,F) hasChild (?)
A hasParent B hasParent C hasChild (B,F) hasChild (A,E,G)
Notice from this chain property, that hasChild returns the B that is common from the hasParent
property call (inverses of each other). Since they are inverses they cancel each other out leaving
a problem of duplicate answers. The key to the hasFirstCousin is that hasSibling relationship is
ir-reflexive in order to avoid hasChild from returning a (B,B) relationship which is reflexive. Once
the ir-reflexive property is used on hasSibling and hasFirstCousin, the system returns:
A hasParent B hasParent C hasChild F hasChild G

A hasFirstCousin G
84
PROTÉGÉ DEMONSTRATION
Using the tree from the previous figure, all of the information was put in and inputted for each
of the different instances. The information that must be inputted to each of the instances must
be the hasChild property which tells who are the Children for that particular instance and the
type of thing they are, which is of type Person.
The following capture displays the information about the instance AA (which is disjointed and
distinct from all of the other instances in the class Person):
Figure 12: Definition of Instance AA in Protégé
85
The next step is to run the query of inferred relationships of AA to determine the validity of the
solution. When the system is checked and reasoned, the result for the query shown for instance
AA which is in the following figures:
Figure 13: Run of query hasParent on instance AA
Figure 14: Run of query isRelatedTo on Instance AA
86
Figure 15: Run of query hasGrandParent on Instance AA
Figure 16: Run of query hasGreatGrandParent on Instance AA
87
OWLVIZ DEMONSTRATION
Protégé also has the ability to show by explicit and inference methods on how objects are
related together. The OWLViz Description shows all of the objects in an “is-a” relationship and
for the class design, only two objects are considered: Thing and Person. Thing is universal as all
objects can be declared as things and Person is a derived concept from Thing that is a subset of
the Thing.
Figure 17: OWLViz Description of Person
88
PROTÉGÉ CODE
Namespace(=<http://www.semanticweb.org/ontologies/marriege.owl#>)
Namespace(owl2xml=<http://www.w3.org/2006/12/owl2-xml#>)
Namespace(marriege=<http://www.semanticweb.org/ontologies/marriege.owl#>)
Namespace(xsd=<http://www.w3.org/2001/XMLSchema#>)
Namespace(rdfs=<http://www.w3.org/2000/01/rdf-schema#>)
Namespace(rdf=<http://www.w3.org/1999/02/22-rdf-syntax-ns#>)
Namespace(owl=<http://www.w3.org/2002/07/owl#>)
Ontology(<http://www.semanticweb.org/ontologies/marriege.owl>
// Class: http://www.w3.org/2002/07/owl#Thing
// Class: http://www.semanticweb.org/ontologies/marriege.owl#Brother
SubClassOf(Brother Male)
// Class: http://www.semanticweb.org/ontologies/marriege.owl#GrandMother
SubClassOf(GrandMother Female)
// Class: http://www.semanticweb.org/ontologies/marriege.owl#Female
SubClassOf(Female Person)
DisjointClasses(Female Male)
// Class: http://www.semanticweb.org/ontologies/marriege.owl#Sister
SubClassOf(Sister Female)
// Class: http://www.semanticweb.org/ontologies/marriege.owl#Mother
SubClassOf(Mother Female)
// Class: http://www.semanticweb.org/ontologies/marriege.owl#Aunt
SubClassOf(Aunt Female)
// Class: http://www.semanticweb.org/ontologies/marriege.owl#Uncle
SubClassOf(Uncle Male)
// Class: http://www.semanticweb.org/ontologies/marriege.owl#Male
SubClassOf(Male Person)
DisjointClasses(Male Female)
// Class: http://www.semanticweb.org/ontologies/marriege.owl#Daughter
SubClassOf(Daughter Female)
// Class: http://www.semanticweb.org/ontologies/marriege.owl#Father
SubClassOf(Father Male)
// Class: http://www.semanticweb.org/ontologies/marriege.owl#GrandFather
SubClassOf(GrandFather Male)
// Class: http://www.semanticweb.org/ontologies/marriege.owl#GreatGrandMother
SubClassOf(GreatGrandMother Female)
// Class: http://www.semanticweb.org/ontologies/marriege.owl#GreatGrandFather
SubClassOf(GreatGrandFather Male)
// Class: http://www.semanticweb.org/ontologies/marriege.owl#Person
SubClassOf(Person owl:Thing)
// Class: http://www.semanticweb.org/ontologies/marriege.owl#Son
SubClassOf(Son Male)
// Object property: http://www.semanticweb.org/ontologies/marriege.owl#hasAncestor
TransitiveObjectProperty(hasAncestor)
ObjectPropertyDomain(hasAncestor Person)
ObjectPropertyRange(hasAncestor Person)
89
// Object property: http://www.semanticweb.org/ontologies/marriege.owl#hasSecondCousin
SymmetricObjectProperty(hasSecondCousin)
ObjectPropertyDomain(hasSecondCousin Person)
ObjectPropertyRange(hasSecondCousin Person)
// Object property: http://www.semanticweb.org/ontologies/marriege.owl#hasGreatGrandChild
TransitiveObjectProperty(hasGreatGrandChild)
ObjectPropertyDomain(hasGreatGrandChild Person)
ObjectPropertyRange(hasGreatGrandChild Person)
// Object property: http://www.semanticweb.org/ontologies/marriege.owl#hasDescendent
TransitiveObjectProperty(hasDescendent)
ObjectPropertyDomain(hasDescendent Person)
ObjectPropertyRange(hasDescendent Person)
// Object property: http://www.semanticweb.org/ontologies/marriege.owl#isRelatedTo
TransitiveObjectProperty(isRelatedTo)
ObjectPropertyDomain(isRelatedTo Person)
ObjectPropertyRange(isRelatedTo Person)
// Object property: http://www.semanticweb.org/ontologies/marriege.owl#hasChild
InverseObjectProperties(hasChild hasParent)
IrreflexiveObjectProperty(hasChild)
ObjectPropertyDomain(hasChild Person)
ObjectPropertyRange(hasChild Person)
// Object property: http://www.semanticweb.org/ontologies/marriege.owl#hasSibling
SymmetricObjectProperty(hasSibling)
ObjectPropertyDomain(hasSibling Person)
ObjectPropertyRange(hasSibling Person)
// Object property: http://www.semanticweb.org/ontologies/marriege.owl#hasGreatGrandParent
TransitiveObjectProperty(hasGreatGrandParent)
ObjectPropertyDomain(hasGreatGrandParent Person)
ObjectPropertyRange(hasGreatGrandParent Person)
// Object property: http://www.semanticweb.org/ontologies/marriege.owl#hasGrandParent
InverseObjectProperties(hasGrandParent hasGrandChild)
TransitiveObjectProperty(hasGrandParent)
ObjectPropertyDomain(hasGrandParent Person)
ObjectPropertyRange(hasGrandParent Person)
// Object property: http://www.semanticweb.org/ontologies/marriege.owl#hasGrandChild
InverseObjectProperties(hasGrandParent hasGrandChild)
TransitiveObjectProperty(hasGrandChild)
ObjectPropertyDomain(hasGrandChild Person)
ObjectPropertyRange(hasGrandChild Person)
// Object property: http://www.semanticweb.org/ontologies/marriege.owl#hasFirstCousin
SymmetricObjectProperty(hasFirstCousin)
ObjectPropertyDomain(hasFirstCousin Person)
ObjectPropertyRange(hasFirstCousin Person)
// Object property: http://www.semanticweb.org/ontologies/marriege.owl#hasParent
InverseObjectProperties(hasChild hasParent)
IrreflexiveObjectProperty(hasParent)
ObjectPropertyDomain(hasParent Person)
ObjectPropertyRange(hasParent Person)
90
// Object property: http://www.semanticweb.org/ontologies/marriege.owl#hasSpouse
SymmetricObjectProperty(hasSpouse)
ObjectPropertyDomain(hasSpouse Person)
ObjectPropertyRange(hasSpouse Person)
// Object property: http://www.semanticweb.org/ontologies/marriege.owl#CantMarry
TransitiveObjectProperty(CantMarry)
ObjectPropertyDomain(CantMarry Person)
ObjectPropertyRange(CantMarry Person)
// Data property: http://www.semanticweb.org/ontologies/marriege.owl#hasAge
DataPropertyDomain(hasAge Person)
DataPropertyRange(hasAge xsd:short)
// Data property: http://www.semanticweb.org/ontologies/marriege.owl#hasGender
DataPropertyDomain(hasGender Person)
DataPropertyRange(hasGender xsd:string)
// Data property: http://www.semanticweb.org/ontologies/marriege.owl#hasMaritalStatus
DataPropertyDomain(hasMaritalStatus Person)
DataPropertyRange(hasMaritalStatus xsd:string)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#AA
ClassAssertion(AA Person)
ObjectPropertyAssertion(hasChild AA BB)
ObjectPropertyAssertion(hasChild AA CC)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#SB
ClassAssertion(SB Person)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#EE
ClassAssertion(EE Person)
ObjectPropertyAssertion(hasChild EE EA)
ObjectPropertyAssertion(hasChild EE EB)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#VV
ClassAssertion(VV Person)
ObjectPropertyAssertion(hasChild VV VB)
ObjectPropertyAssertion(hasChild VV VA)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#BB
ClassAssertion(BB Person)
ObjectPropertyAssertion(hasChild BB EE)
ObjectPropertyAssertion(hasChild BB DD)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#DA
ClassAssertion(DA Person)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#GB
ClassAssertion(GB Person)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#UU
ClassAssertion(UU Person)
ObjectPropertyAssertion(hasChild UU UB)
ObjectPropertyAssertion(hasChild UU UA)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#FA
ClassAssertion(FA Person)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#SS
ClassAssertion(SS Person)
ObjectPropertyAssertion(hasChild SS SB)
91
ObjectPropertyAssertion(hasChild SS SA)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#DB
ClassAssertion(DB Person)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#GG
ClassAssertion(GG Person)
ObjectPropertyAssertion(hasChild GG GA)
ObjectPropertyAssertion(hasChild GG GB)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#TA
ClassAssertion(TA Person)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#EA
ClassAssertion(EA Person)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#QQ
ClassAssertion(QQ Person)
ObjectPropertyAssertion(hasChild QQ SS)
ObjectPropertyAssertion(hasChild QQ TT)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#DD
ClassAssertion(DD Person)
ObjectPropertyAssertion(hasChild DD DA)
ObjectPropertyAssertion(hasChild DD DB)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#SA
ClassAssertion(SA Person)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#CC
ClassAssertion(CC Person)
ObjectPropertyAssertion(hasChild CC GG)
ObjectPropertyAssertion(hasChild CC FF)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#GA
ClassAssertion(GA Person)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#FB
ClassAssertion(FB Person)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#PP
ClassAssertion(PP Person)
ObjectPropertyAssertion(hasChild PP QQ)
ObjectPropertyAssertion(hasChild PP RR)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#VB
ClassAssertion(VB Person)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#UA
ClassAssertion(UA Person)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#VA
ClassAssertion(VA Person)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#UB
ClassAssertion(UB Person)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#EB
ClassAssertion(EB Person)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#TB
ClassAssertion(TB Person)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#RR
ClassAssertion(RR Person)
ObjectPropertyAssertion(hasChild RR VV)
92
ObjectPropertyAssertion(hasChild RR UU)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#FF
ClassAssertion(FF Person)
ObjectPropertyAssertion(hasSpouse FF SS)
ObjectPropertyAssertion(hasChild FF FA)
ObjectPropertyAssertion(hasChild FF FB)
// Individual: http://www.semanticweb.org/ontologies/marriege.owl#TT
ClassAssertion(TT Person)
ObjectPropertyAssertion(hasChild TT TB)
ObjectPropertyAssertion(hasChild TT TA)
// Sub property chain axiom
SubObjectPropertyOf(SubObjectPropertyChain(hasChild) hasDescendent)
SubObjectPropertyOf(SubObjectPropertyChain(hasDescendent hasAncestor) isRelatedTo)
SubObjectPropertyOf(SubObjectPropertyChain(isRelatedTo) CantMarry)
SubObjectPropertyOf(SubObjectPropertyChain(hasParent hasParent) hasGrandParent)
SubObjectPropertyOf(SubObjectPropertyChain(hasChild hasChild) hasDescendent)
SubObjectPropertyOf(SubObjectPropertyChain(hasParent hasParent hasParent) hasAncestor)
SubObjectPropertyOf(SubObjectPropertyChain(hasChild hasChild hasChild) hasDescendent)
SubObjectPropertyOf(SubObjectPropertyChain(hasAncestor hasDescendent) isRelatedTo)
SubObjectPropertyOf(SubObjectPropertyChain(hasParent hasParent) hasAncestor)
SubObjectPropertyOf(SubObjectPropertyChain(hasParent) hasAncestor)
SubObjectPropertyOf(SubObjectPropertyChain(hasParent hasSibling hasChild) hasFirstCousin)
SubObjectPropertyOf(SubObjectPropertyChain(hasParent hasParent hasParent) hasGreatGrandParent)
SubObjectPropertyOf(SubObjectPropertyChain(hasGrandParent hasSibling hasGrandChild)
hasSecondCousin)
SubObjectPropertyOf(SubObjectPropertyChain(hasParent hasChild) hasSibling)
// Generated by the OWL API (version 2.2.1.1042) http://owlapi.sourceforge.net
93
PROVING THE DESIGN
INITIAL ALLOY DESIGN WITH DEFINITION
We began our Alloy model with an abstract Person class, which has two attributes: Father and
Mother. Then we added two more classes Man and Woman which extended the abstract
Person class. Now that we constrain all Persons have to be of male or female gender, we can
add more constraints for the Father and Mother attributes of the Person class by specifying the
gender of each attribute, that is, Father has to be a Man and Mother has to be a Woman. Next
we defined spousal relationship so a Husband and a Wife attribute were added to the Man and
Woman class respectively.
With the class diagram above, we put together a rule-based Alloy model that considers three
different features of each Person: every Person has at most one father and one mother, a
woman can have at most 1 husband, which has to be a man, and a man can have at most 1
wife, which has to be a woman.
Provided below is our initial Alloy code with Person, Man and Woman classes:
abstract sig Person

{
father : lone Man,
mother : lone Woman
}
sig Woman extends Person
94
{
husband : lone Man
}
sig Man extends Person

{
wife : lone Woman
}
At the very next stage, we specified some constraints on the Alloy model in order to forbid
people who are related to each other by second cousin relationship or closer from getting
married. We defined a set of four facts that help detect illegal marriages.
fact spousal_Relationship
{
husband =~ wife
}
fact no_Self_Ancestor
{
no x : Person | x in x.^(father + mother)
}
fact parents_Relationship
{
all x : Person |
#x.(father + mother) = 2 =>
(x.mother.husband = x.father) and
(x.father.wife = x.mother)
}
fact noIncestMarriage
{
no m : Man | m.wife in m.(^mother)
no w : Woman | w.husband in w.^(father)
}
Below is the complete description of each fact that is mentioned above and also their
usefulness for our system.
spousal_Relationship: This fact states that if you are the hushand of some woman, then
that woman is your wife.
no_Self_Ancestor: This will make sure that no person can be his or her own ancestor.
95
parents_Relationship: This fact states that for every person who has two parents (one
mother and one father), their parents must be spouses of each other.
noIncestMarriage: This fact is to make sure that no man or woman is allowed to marry
their own ancestors.
Above mentioned facts must hold in order for our logic to work properly. At the next step, we
need to define predicates that determine a person’s relationship to another.
pred isSecondCousin(x, y: Person)

{
some z : Person |
isThreeDistinctNodes[x, y, z] and
isGreatGrandParent[z, x] and
isGreatGrandParent[z, y] and
(x.(father + mother) + x.(father + mother).(father + mother)) &
(y.(father + mother) + y.(father + mother).(father + mother)) = none
}
pred isGreatGrandParent (x, y: Person)

{
x in y.(father + mother).(father + mother).(father + mother)
}
pred isGrandParent (x, y: Person)

{
x in y.(father + mother).(father + mother)
}
pred isParent(x, y: Person)

{
x in y.(father + mother)
}
pred isThreeDistinctNodes (x, y, z: Person)

{
(x != y) and (x != z) and (y != z)
}
Below is the complete description of each predicate that is mentioned above and also their
usefulness for our system.
isSecondCousin: This predicate determines if person x is second cousin of peson y. This

situation is true if both person have same great-grand parent named z. x,y & z must be
distinct and their ancestors are disjoint.
96
isGreatGrandParent: This predicate determines if person x is great grand parent of
person y. In case x is included in y’s parents of parents of parents, this statement is true.
isParent: This predicate determines if person x is one of the parent of person y. If y’s
parents include x then this statement is true.
isThreeDistinctNodes: This will confirm if three person are same or not.
97
EVALUATION OF INITIAL ALLOY DESIGN
One of the main problems with the initial Alloy code is that we have no restrictions on the
number of parents a person can have. This problem was exposed during the sample run of our
program code for 14 persons. In the Alloy-generated diagram below, we can see that Woman 0
and Man 3 has an incest marriage because Woman0 is also Man3’s great aunt. Therefore in
order to remove this error, we add a new fact to our system.
98
EVALUATION OF FINAL ALLOY DESIGN
abstract sig Person {

father : lone Man,
mother : lone Woman
}
sig Woman extends Person {

husband : lone Man
}
sig Man extends Person {

wife : lone Woman
}
fact haveParents {
all x : Person |
#(x.father) = 1 and #(x.mother) = 1
}
fact spousal_Relationship {
husband =~ wife
}
fact no_Self_Ancestor {
no x : Person | x in x.^(father + mother)
}
{
all x : Person |
(x.father.wife = x.mother)
}
{
no w : Woman | w.husband in w.^(father)
}
pred isSecondCousin(x, y: Person) {

some z : Person |
99
isThreeDistinctNodes[x, y, z] and
isGreatGrandParent[z, x] and
isGreatGrandParent[z, y] and
(y.(father + mother) + y.(father + mother).(father + mother)) == none
}
pred isGreatGrandParent (x, y: Person) {

x in y.(father + mother).(father + mother).(father + mother)
}
pred isGrandParent (x, y: Person) {

x in y.(father + mother).(father + mother)
}
pred isParent(x, y: Person) {

x in y.(father + mother)
}
pred isThreeDistinctNodes (x, y, z: Person) {

(x != y) and (x != z) and (y != z)
}
run isSecondCousin for 14 Person
We ran our final Alloy design with 14 person, as per the professor’s recommendation, and Alloy
Analyzer said “No instance found”, which means no counterexample was found in our model.
We also notice that Scope is very important to our Alloy model because performance was really
bad when we try to run it with more than 15 Persons. Below are a few sample Alloy runs:
Alloy Analyzer 4.1.7 (build date: 2008/07/21 23:20 EDT
Executing "Run isSecondCousin for 14 Person"

Solver=sat4j Bitwidth=4 MaxSeq=4 Symmetry=20
53884 vars. 854 primary vars. 115651 clauses. 437ms.
No instance found. Predicate may be inconsistent. 56737ms.

Solving...

100
Solving...
Alloy Analyzer seems to be stuck at “Solving” state when the model scope increased beyond 15
Persons, so for our model it is best to be executed with 14 Person which took about 4 to 6
seconds. Also the Eclipse plugin version does not work! We had to resort to a standalone Alloy
version (v 4.1.7).
101
DYNALLOY
Original Alloy Code
Before converting Alloy code to DynAlloy code, we did some code cleanup and, as a result, two
unused predicates isGrandParent() and isParent() were removed. The following is our original
signatures and facts:
/* Every person has at most 1 father (a man) and 1 mother (a woman) */

father : lone Man,
mother : lone Woman}
/* A woman can have at most 1 husband, which has to be a man */

husband : lone Man }
/* A man can have at most 1 wife, which has to be a woman */

wife : lone Woman}
/* Every person will have 1 father and 1 mother */

fact haveParents {
all x : Person |
#(x.father) = 1 and #(x.mother) = 1}
/* If you are the husband of some woman, then that woman is your wife */
husband =~ wife }
/* No person can be his or her own ancestor */

no x : Person | x in x.^(father + mother)}
/* For every person who has 2 parents (1 mother and 1 father), their parents must be spouses
of each other */
{
all x : Person |
(x.father.wife = x.mother)}
102
/* No man or woman is allowed to marry their own ancestors */
{
no w : Woman | w.husband in w.^(father)}
Modified DynAlloy Code
We simplified the logic in the original isSecondCousin() predicate by removing the code that
checks for common ancestor into a new predicate.
Using DynAlloy syntax, we will now add actions and programs to the final version of our Alloy
code. Actions are easy to define. Every action has a pre-condition and post-condition which
ensure that certain logic must hold before and after the action execution. Predefined Alloy
predicates are used for these conditions. Programs can contain a combination of actions and
other programs, and since our original Alloy code was simple enough, we just need to define 1
program with supporting actions for DynAlloy code.
The following defines all the predicates, actions, and programs we need for DynAlloy:
/* This predicate will check to see if three given people are all different individuals */
(x != y) and (x != z) and (y != z)}
/* This predicate will detect great grandparent relationship */

x in y.(father + mother).(father + mother).(father + mother) }
/* This predicate checks if two given persons have common ancestors */

pred noCommonAncestor(x, y: Person) {
(y.(father + mother) + y.(father + mother).(father + mother)) == none}
/* This predicate will check to see if two given people are different individuals */
pred isTwoDistinctNodes (x, y: Person) {
(x != y) }
/* This predicate is used in actions to indicate that there is no precondition */

pred none() {}
action is_Three_Distinct_Nodes[x, y, z: Person]

{
pre { none[] }
post { isThreeDistinctNodes[x, y, z] }}
103
action is_Great_Grand_Parent[x, y: Person]
{
pre { isTwoDistinctNodes[x, y] }
post { isGreatGrandParent[x, y] }}
action no_Common_Ancestor[x, y: Person]

{
pre { isTwoDistinctNodes[x, y] }
post { noCommonAncestor[x, y] }}
program is_Second_Cousin[x, y: Person]

var [z: Person]
{
is_Three_Distinct_Nodes[x, y, z];
is_Great_Grand_Parent[z, x];
is_Great_Grand_Parent[z, y];
no_Common_Ancestor[x, y] }
104
DynAlloy Translation
Next, we will use the DynAlloy4 Translator tool to translate the newly derived DynAlloy code
into Alloy code.
As the screenshot above illustrates, the translation was successful. Here are the contents of the
newly and successfully translated ALS file:
/* Every person has at most 1 father (a man) and 1 mother (a woman) */

father : lone Man,
mother : lone Woman}
/* A woman can have at most 1 husband, which has to be a man */

husband : lone Man }
105
/* A man can have at most 1 wife, which has to be a woman */
wife : lone Woman}
/* Everybody will have 1 father and 1 mother */

fact haveParents {
all x : Person |
#(x.father) = 1 and #(x.mother) = 1}
/* If you are the hushand of some woman, then that woman is your wife */
husband =~ wife}
/* No person can be his or her own ancestor */

no x : Person | x in x.^(father + mother)}
/* For every person who has 2 parents (1 mother and 1 father), their parents must be spouses
of each other */
{
all x : Person |
(x.father.wife = x.mother)}
/* No man or woman is allowed to marry their own ancestors */

{
no w : Woman | w.husband in w.^(father)}
/* This predicate will check to see if three given people are all different individuals */
(x != y) and (x != z) and (y != z)}
/* This predicate will detect great grand parent relationship */

x in y.(father + mother).(father + mother).(father + mother) }
pred noCommonAncestor(x, y: Person) {
(y.(father + mother) + y.(father + mother).(father + mother)) == none}
106
/* This predicate will check to see if two given people are different individuals */
pred isTwoDistinctNodes (x, y: Person) {
(x != y) }
/* This predicate is used in actions to indicate that there is no precondition */

pred none() {}
pred is_Three_Distinct_Nodes[x_0: Person,y_0: Person,z_0: Person]{none[] and
isThreeDistinctNodes[x_0,y_0,z_0]}
pred no_Common_Ancestor[x_0: Person,y_0: Person]{isTwoDistinctNodes[x_0,y_0] and
noCommonAncestor[x_0,y_0]}
pred is_Great_Grand_Parent[x_0: Person,y_0: Person]{isTwoDistinctNodes[x_0,y_0] and
isGreatGrandParent[x_0,y_0]}
pred is_Second_Cousin[x_0: Person,y_0: Person,z_0:
Person]{is_Three_Distinct_Nodes[x_0,y_0,z_0] and is_Great_Grand_Parent[z_0,x_0] and
is_Great_Grand_Parent[z_0,y_0] and no_Common_Ancestor[x_0,y_0]}
run is_Second_Cousin for 14 Person
Running the above code with the none() predicate and its reference call removed yields the
following results in Alloy4 Analyzer:
Executing "Run is_Second_Cousin for 14 Person"
No instance found. Predicate may be inconsistent. 48906ms.
The output is the same as the original Alloy code which means our DynAlloy logic is correct
since the two Alloy files produce the same output, that is, no instance or counter example was
found in our design.
DynAlloy Evaluation
DynAlloy is an extension of the Alloy tool. It has support for the creation of dynamic properties
of a system using actions. DynAlloy actions and programs are fairly easy to work with. Programs
are somewhat similar to functions or methods of conventional programming languages like Java
because they can contain a set of statements. However, I did not like the idea of adding a
dummy predicate for the pre-condition when one is not needed. As a result, I had to get rid of
the none() predicate in the translated Alloy file in order for it to execute successfully back in
Alloy4 Analyzer tool.
The translated Alloy code using DynAlloy4 Translator tool is longer, but it is easier to
understand because the isSecondCousin() predicate is now broken down to several predicates.
Even though DynAlloy forces us to simplify the original Alloy code, I do not find it being useful
since the Alloy code must be done before DynAlloy code can be written. Perhaps I need to play
with DynAlloy more in my own time in order to find out its true potential.
107
TIME SIMULATIONS
CHEDDAR
We used CHEDDAR tool to show time simulations and scheduling done on Population
Simulation System (PSS). We have our initial architecture as Pipe and Filter. This is simple single
processor architecture. Eventually, as features and services got added in original architecture,
we came up with following three architectures which were 3-tiered Client Server, Distributed 3-
tiered Client Server and finally the Distributed 3- tiered Client Server with fault Tolerance.
In our initial architecture, we have four main subsystems which are further divided into 9 sub
blocks. Each block has many processes and sub processes or tasks or its sub tasks. But for
simplification, in CHEDDAR we have considered each block of our four sub system as a single
task. Thus we had nine tasks in all. Here the nine tasks were addressed as T1 to T9. All of these
tasks were periodic. In Pipe and Filter architecture we have considered a single processor which
uses Pre-emptive Round Robin Scheduling scheme. Processor does scheduling of each task in
system just to achieve load balancing. Following figure shows task precedence graph for Pipe
and Filter architecture. As it is clear Task T9 Is controller element and it represents clock for all
architectures. Data Store is general database from where data or information is passed to
entire system. All the tasks are rather independent to avoid situation of deadlocks. In all
architectures, clock will be controlling element for all tasks. This is because the clock will
dynamically adjust itself according to rate of population growth. As such each of tasks will
change its operation.
108
Tasks Precedence Graph for Pipe and Filter
Following figure shows Time scheduling done for major nine tasks of the system. All tasks are
periodic so have period of 5 nsecs. The processor schedules all tasks in Round-Robin scheduling
scheme. For the simple Pipe and Filter architecture all the tasks are meeting their deadlines.
109
Though this architecture was stable and scheduling and time simulations were successful, it
would not suffice to increased number of queries to database or increased load on processor.
As this is Population Simulation System, gradually with time load on processor are bound to be
increased. Here came need to add a new architecture to our system. We thought of a basic 3-
tiered Client Server architecture to solve this problem. But in this new architecture we had a
new aperiodic task T10 added to our system. This task signifies the request coming from client
end. With a new aperiodic task system seemed little bit unstable. Following figure shows
precedence graph for a 3-tiered client server.
110
Task Precedence for 3-tiered Client Server
Now the next figure shows time scheduling done all major ten tasks of our system. Thus there
are nine periodic and one aperiodic task in system currently. As discussed earlier task T10 is
aperiodic as it refers a client request which can arrive at any time. Processor still schedules the
tasks in pre-emptive Round-Round scheduling scheme. The periodic tasks have their period as 5
Nsecs.
111
With addition of a new aperiodic task the system becomes unstable. As such some of these
tasks appear to miss their deadlines. For such real-time systems, missing of deadline is highly
undesirable. From Figure it appears that new task T10 seems to miss its deadline. This is highly
undesirable as we needed to introduce a new architecture. We introduced two new
architectures Distributed 3-tiered Client Server and Distributed 3-tiered Client server with fault
tolerance. As such the next figure shows time precedence graph for our Distributed
architecture.
In distributed architecture we have divided all the tasks among four processors. Thus we have
processor PRSR1 scheduling and executing tasks T1, T2, T3, and T10. Processor PRSR2 handles
task T4 and T5. Processor PRSR3 handle tasks T6, T7, and T8 while PRSR4 handle only and most
important controller task T9 which is clock element. Increased number of processors aid in
dividing stresses and achieve a better load balancing. Each of the processor has pre-emptive
operation and uses different scheduling schemes according to nature of tasks it has to process.
Thus processor PRSR1 uses a scheduling scheme known as Time Sharing based on CPU usage.
Here CPU time is shared by all the tasks processed by the processor. The processors PRSR2 and
112
PRSR3 use a scheduling scheme Earliest Deadline first. Here the processor will process those
tasks first, whose deadline is nearest. The Processor PRSR4 again schedules its tasks based on
Time Sharing done according to CPU usage. Here in distributed architecture as the business
logic layer is distributed, each processor can process and handle the tasks more efficiently. Here
we consider that Data_Store1 represents entire backup system for entire PSS system. Next
figure shows a precedence graph for our distributed architectures.
Time Precedence Graph for Distributed Architectures:
Next figures show time simulations done for distributed architectures. Thus Increasing number
of processor immensely helped in improving overall performance of system. As it is clear from
the simulation almost all of the tasks are handled gracefully. Deadline misses are reduced and
system is more reliable predictable and highly efficient. For such real-time systems the
reliability and predictability are most important issues system has to handle.
113
114
Thus scheduling simulations help in determining whether system is able to handle particular load
and stress levels.
CHEDDAR Final Thoughts
Looking back from the final version of architecture, we came up with four revisions to our original
architecture. Cheddar tool helped and motivated us to think more deeply into issues of load
balancing. Initially we modeled our initial architecture as a simple single processor which used a
simple Round-Robin Scheduling. The prioritization of task was done according to the nature of
tasks and the time the task is invoked in the system. This architecture was handling all tasks
gracefully. But just addition of one single aperiodic process to our system in 3-tiered Client Server
made it unstable and thus highly unreliable. Thus we had to introduce a concept of distributed
architectures which consists of several processors which would rather handle the each tasks of our
system gracefully increasing its reliability. Thus using CHEDDAR tool immensely helped us to
identify considerations needed for such kind of real-time system.
115
CONCLUSION
Archstudio Final Thoughts
Initially we came up with a simple Pipe and Filter Architecture. But shortly we realized that a
simple pipe and filter would not suffice to dynamic and near real-time nature of project. As
such we came up with several revisions to our original architecture. Our final attempt was a
Distributed 3-tier client server with fault tolerance. Intermediate ones were a simple 3-tier
client-server and a distributed 3-tier client server. We designed all architectures through
Archstudio.
Designing all architectures in Archstudio was an enriching experience. We got to learn this tool.
But somehow we felt that the tool needs to have proper tutorials. Other feature where we had
hard time was all editing or even adding features are given on right click. So the interface has
no other feature to accommodate that. Other than these small issues, Archstudio is a good tool
to design the basic architecture of the system.
Protégé Final Thoughts
Protégé can be very useful in determining and showing relationships between different classes
of objects and their properties. However, there are limitations and challenges to this software
and the Protégé design. The first problem with Protégé is in determining relationships using
intermediate nodes. For instance, in defining the 2nd cousin constraint in a predicate formed
language like Alloy or Prolog, the system is much easier to write up than in Protégé. In Alloy,
writing an intermediate node can be easily defined by using a random variable, however in
Protégé intermediate nodes are only defined by their actions in the property chain. No random
variables can be used. Also, one struggling problem that occurred in Protégé was the fact of an
Unsupported Feature Exception with the ir-reflexive property. The group got this error because
Protégé 4.0 does not support ir-reflexive option in an object property that contains a property
chain. With this error, each ir-reflexive property always returns itself as a possible answer
(hence there is a possibility that A can be a sibling of A or him or herself).
Another feature of Protégé that is interesting to note is the use of recursive property chains in
the object properties. At first the user of recursive property chains seemed to be not available
in Protégé (versus in Alloy to declare an infinite length of isParent calls is done by the usage of
the ^ symbol or the transitive closure). Also, one interesting fact about the recursive properties
in Protégé is that the number of recalls to the property that is recursive is solely dependent on
the reasoner. In one run of the reasoner, the recursive calls may possibly be 1 but in the next
run the recursive calls may be 2. There is no consistency in the number of recursive calls made
in a recursive property chain.
116
Alloy Final Thoughts
Alloy Analyzer has a really small footprint so downloading and running the tool did not take
much time at all. The size of the Alloy jar is only 3.85MB. Alloy documentation is also very good;
there are tutorials with sample code files for every version release.
Alloy Analyzer helped us prove our design logic for preventing people related to each other by
2nd cousin relationship or closer from getting married. Alloy's visualizer is great for generating
a map of tree nodes that shows us what the error in our logic is. The best thing about the
visualizer is that it showed a counterexample for our design so we don't have to spend a lot of
time tracking down where the flaw in our design originated from.
Being able to design a tiny model which represents an important aspect of our system with just
a small code file is above and beyond my expectation for Alloy. As a matter of fact, our final
working Alloy model consists of only 3 signatures, 5 facts, and 4 predicates. These together
added up to no more than 50 lines of code. However, Alloy’s syntax is difficult to understand. It
is nothing like conventional programming logic so it will take a substantial amount of effort for
application developers like myself to really grasp Alloy’s grammar before I can start coding.
Overall Thoughts
The goal of this project was to create a simulation of real life, to see if we could create a society
where one cannot marry their second cousin or anyone closer. At first, we were rather
bewildered as how to approach this task. All we knew in the beginning was that we had to use
several tools including Archstudio, Alloy, Protégé, Dynalloy and Cheddar. We weren’t sure what
fit where and how one tool interrelated with the other.
Our first architecture was terrible as it was nothing but a system of if-then statements. While
the architecture technically “worked” it wasn’t dynamic, it wasn’t extensible and it didn’t really
create a simulation.
Weekly meetings and constantly talking about the requirements of the project helped us frame
our second architecture (our first real architecture). We used the requirements to develop our
use cases, which we used to drive our architecture, our design, and all of our UML. Once we
had a clear idea of what we wanted to build, the only thing that was left was implementing it
using the tools. Two members of our group tackled Archstudio, another two worked on
Protégé and another two worked on Alloy. Although daunting at first, we were proud that we
were able to become proficient at all three tools and were able to solve implement our design
using all three of them.
Through it all, we learned what it meant to design software. We learned what drove the whole
process. We learned how we get from use cases to running counter-examples in Alloy. All in
all, we are really proud of the work we produced and felt that we learned a tremendous
amount from this class. Thank you very much for providing us weekly assistance and patience
with our group.
117
REFERENCES
ArchStudio 4: Hello World Tutorial. University of California, Irvine.
http://www.ics.uci.edu/~hasuncio/classes/in4matx119/HelloWorldTutorial.pdf
Asuncion, H. Prospective Rules. University of California, Irvine.

http://www.isr.uci.edu/%7Ehasuncio/prospective_rules2.mp4
Burleson, C. A Practical Guide to Building OWL Ontologies Using Protégé 4. Burleson

Technology Group, LLC.
http://www.semanticfocus.com/blog/entry/title/introduction-to-semantic-web-vision-and-
technologies-part-5-building-owl-ontologies-using-protege-4-screencast/
Dashofy, E. Archipelago: ArchStudio’s Graphical Editor. University of Irvine.

http://www.isr.uci.edu/projects/archstudio/archipelago-overview.html.
Dennis, G.; Seater R. FM 2006 Alloy: Intro and Login. 2006.

http://www.sts.tu-harburg.de/teaching/ws-07.08/LTOOAD/07-alloy-logic.pdf.
Drummond, N.; Horridge M.; Knublauch, H. Protege-OWL Tutorial. 2005. 8th International
Protege Conference.
http://protege.stanford.edu/conference/2005/slides/T2_OWLTutorialI_Drummond_final.pdf
Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. Design Patterns: Elements of Reusable Object-
Oriented Software. 1995.
Galeotti, J.P.; Frias, M. DynAlloy as a Formal Method for the Analysis of Java Programs. 2006.
Software Engineering Techniques: Design for Quality, Volume 227, pages 249-260.
Galeotti, J.P.; Marcelo F.; Pombo, C.L., Aguirre N. DynAlloy: Upgrading Alloy with actions. 2005.
ICSE 2005: 27th International Conference on Software Engineering, page 442-450.
Galeotti, J.P.; Marcelo F.; Pombo, C.L., Aguirre N. DynAlloy: Upgrading Alloy with actions
(Extended Abstract). 2005. Proceedings of the 8th. Conference on Relational Methods in
Computer Science (RelMiCS) - 3nd. International Workshop on Applications of Kleene Algebra,
page 57-60.
Horridge, M. A Practical Guide To Building OWL Ontologies Using Protégé 4 and CO-ODE Tools.
2007.
http://www.co-ode.org/resources/tutorials/ProtegeOWLTutorial-p4.0.pdf.
118
Jackson, D. A Comparison of Object Modeling Notations: Alloy, UML, and Z. 1999. MIT Lab for
Computer Science. 1999.
http://sdg.csail.mit.edu/pubs/1999/alloy-comparison.pdf.
Jackson, D. Alloy in 90 Minutes. 2005.

http://people.csail.mit.edu/dnj/talks/re05-tutorial/alloy-90.pdf .
Krikorian, H. Software Design. California State University, Fullerton. Fall 2008.

http://haig.ecs.fullerton.edu/files/Software%20Design/CS-462-Details.pdf
Seater, R; Dennis, G; Le Berre D.; Chang, F. Tutorial for Alloy Analyzer 4.0. Software Design
Group. 2008.
http://alloy.mit.edu/alloy4/tutorial4/
Singhoff F.; Legrand J.; Nana, L; Marc´ e L. Cheddar : a Flexible Real Time Scheduling
Framework.
http://beru.univ-brest.fr/~singhoff/cheddar/publications/singhoff04a.pdf
Singhoff, F. Cheddar Release 2.x User’s Guide. 2008.

http://beru.univ-brest.fr/~singhoff/cheddar/ug/cheddar-r2.html.
Singhoff, F. The Cheddar project : a free real time scheduling analyzer.

http://beru.univ-brest.fr/~singhoff/cheddar/
Singhoff F.; Legrand J.; Nana, L; Marc´ e L. Scheduling and Memory requirements analysis with
AADL.
http://beru.univ-brest.fr/~singhoff/cheddar/publications/singhoff05a.pdf
Taylor, R. INF123_Discussion4. University of California, Irvine.

http://www.ics.uci.edu/~taylor/classes/123/INF123_Discussion4.ppt
Wong, E.; Tayeb, O.; Herrmann, M. A Guide to Alloy. 2008.

http://www.doc.ic.ac.uk/project/examples/2007/271j/suprema_on_alloy/Web/index.php
119

Documentation 10.0

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Documentation 10.0

Uploaded by

Copyright:

Available Formats

POPULATION SIMULATION SYSTEM

CPSC 462: Spring 2009

Title Name Primary/Secondary

Description of Requirements and Assumptions

Age and Mortality

“Dynamically Adjusting System Clock” (DASC)

System Administrator requests to view an islander’s information.

System Administrator powers up the PSS (Population Simulation System).

System Administrator selects to run PSS built-in tests.

PSS System Handler invokes Relationship Manager to run an up-to-second-cousin relationship

PSS Components data flow diagram

System Administrator turns ON the Population Simulation System (PSS).

System is ready and running.

System checks the population growth.

System simulation logical view

PSS administrator starts up the system.

Type Number Quality Attribute Description

Type/Use Case 1 2 3 4 5 6 7 8 9 10 Total Rank

Type/Use Case 1 2 3 4 5 6 7 8 9 10 Total Rank

Type/Use Case 1 2 3 4 5 6 7 8 9 10 Total Rank

Type/Use Case 1 2 3 4 5 6 7 8 9 10 Total Rank

Type/Use Case 1 2 3 4 5 6 7 8 9 10 Total Rank

Type/Use Case 1 2 3 4 5 6 7 8 9 10 Total Rank

“Our most important quality was that of reliability”.

“Our next highest quality attribute is that of functionality.”

“The next highest is the policy attribute of quality.”

“The next quality attribute to consider was maintainability.”

“The last quality attribute is that of portability.”

Creational Pattern Description & Use

Structural Pattern Description & Use

Behavioral Pattern Description & Use

Figure 1 – First Architecture Design

USE CASE DESCRIPTION ACTOR(S) PURPOSE ARCHITECTURE TYPE

5 Update the Administrator, To show the most Pipe and Filter

Figure 3 - Third Architecture Design

USE CASE DESCRIPTION ACTOR(S) PURPOSE ARCHITECTURE TYPE

Initial Startup Subsystem

Female Process Subsystem

This is the event bus subsystem. This

Id Parent1 Parent2 Child Spouse

Figure 1: A structural design of the class Person

Figure 2: An example set of connected Person objects.

Abstract class Person

Figure 3: Definition of hasChild and hasSpouse written in Protégé

In Protégé, the definition of Person is as follows:

Figure 4: Definition of Person Object and Instances in Protégé

Object Properties D/R Chain Property

Table 1: Object Properties using a Chain Property

hasSibling: This property is found by looking at the parent’s children.

hasGrandParent: The grandparent property is found by looking for the parent’s

hasGrandChild: The grandchild property is the inverse of the hasGrandParent

hasGreatGrandParent: In the hasGreatGrandParent property, the parent’s of the

hasGreatGrandChild: The hasGreatGrandChild property is the inverse of the

hasSecondCousin: The property of hasSecondCousin finds the grandchildren of the

hasAncestor: The ancestor of a person is found by an object property hasParent and

hasDescendent: The descendent of a person is found by an object property hasChild

isRelatedTo: To be related to a person, that person could be related up to the

CantMarry: To not marry a person, that person cannot be related up to the

Table 2: Object Properties with their Characteristics

Figure 5: Property Chain for hasSecondCousin Object Property

Figure 6: Property Chain for hasFirstCousin Object Property

Figure 8: Property Chain for hasSibling Object Property

Figure 10: Property Chain for hasGreatGrandParent Object Property