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

1

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

2

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 Kunal Aruni Ahmad

All Together (10%)

UML Design – 20% Thanh David Komal Kunal Aruni Ahmad

Primary (5%) Primary (5%) Secondary (2.5%) Secondary (2.5%) Secondary (2.5%) Secondary (2.5%)

Design Patterns – 10% Kunal Komal

Primary (7.5%) Secondary (2.5%)

Alloy – 15% Thanh Aruni

Primary (10%) Secondary (5%)

Protégé – 15% Ahmad Kunal


Archstudio – 15% Aruni Komal


Cheddar – 2.5% Komal Primary (2.5 %)

Dynalloy – 2.5% Kunal Primary (2.5%)

3

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.

4

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.

5

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.

6

USE CASE

DESCRIPTION ACTOR(S) PURPOSE NOTES & ASSUMPTIONS

QUALITY ATTRIBUTES

OPERATIONAL CONCEPTS

1 View a person

Administrator System

Requesting to view an individual’s information

The person is present in the database. Database is up to date.

Availability Reliability

System queries the database to show the individual's information plus all the relational dependencies

2 Determine a person's relationship to another person

System System checks to see if a male and female are potential marriage candidates

Both persons are present in the database; Database is up to date

Efficiency Reliability

System will check the database to see if they are related (2nd cousin or higher)

3 Dynamically adjust population control

System To effectively control population size

Database is updated; Clock speed is not normal

Efficiency Performance

System will check the population growth every minute (year) and apply the necessary population control filters accordingly.

4 System startup

Administrator To start the system

System is functioning properly

Reliability Usability

The system is turned on and it works.

5 Update the database

Administrator System

To show the most current information in real-time.

All transactions updated in real-time

Performance Availability

Successfully commits the transaction and updates all associated attributes within the system.

7

6 Add a person Administrator System

To add a new entry to the database

Person is alive. Database storage has not reached its maximum capacity.


System will create a new entry and update database and new associations

7 System test Administrator To check system performance

System is in operational state.

TestabilityMaintain-ability

Verification results are displayed in either textual description or graphical representation

8 Check up to 2nd cousin

System To determine if the two candidates are eligible for marriage

Both candidates exists in the current database.


If the candidates are eligible, system will put them in the marriage bucket. Otherwise, they go back to hopper.

9 Compatibility Score Algorithm

System To generate a compatibility score for each candidate.

Candidate is in age brackets Beta, Delta and Gamma.

Efficiency Systems always return a suitable match.

10 System self-repair

Administrator To remove all faults from the system.

System is malfunctioning

Availability Reliability

The system is restored to a previous working state.

8

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.

9

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.

10

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.

11

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

12

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).

13

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.

14

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.

15

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.

16

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.

17

Compatibility Score Algorithm

18

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.

19

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.

20

UML CLASS DIAGRAM

21

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.

22

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 2nd cousin relationship constraints.

23

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.

24

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.

25

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.

26

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.

27

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.

28

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.

29

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.

30

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.

31

QUALITY & POLICY DESCRIPTION

Type Number Quality Attribute Description

FUNCTIONALITY

1 General

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 system. However, our system does allow on a limited exception for “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.

2 Suitability

The system shall filter out compatibility issues with each other by using a specialized algorithm called the “Compatibility Score Algorithm” (CSA). The CSA involves nine

32

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.

3 Accuracy

The system shall retain accuracy of data at 99.99%. The system shall ensure this level of accuracy by redundancy in our architecture design. The system shall ensure this level of accuracy by requiring weekly testing and daily indexing of the data.

33

4 Interoperability

The system ensure interoperability by using a TCP/IP connection between the different data transactions between interactions within 3 tiered distributed client-server architecture with fault tolerance. The system will ensure interoperability by using IPv6 style addressing to account for any future compatibility issues.

5 Security

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. 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. The system will ensure

34

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.

6 Compliance

The system shall ensure compliance with the functionality quality attributes by requiring the system be highly secure and reliable. Compliance will be ensured by restricting any critical tasks to the administrator and by tailoring the system to be highly redundant and available.

35

RELIABILITY

7 Maturity

The system shall be mature as it uses the standard maturity levels of IEEE and CMMI Level 4. The system will ensure maturity by requiring 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.

8 Fault Tolerance

The system shall ensure fault tolerance to an extreme at 100% as any total failure in the system would be catastrophic as our simulation is running a real-time population analysis. The system shall ensure absolute fault tolerance by developing an architecture that uses 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

36

any delay whatsoever.

9 Recoverability

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. The system will ensure easy recoverability by auto-saving to the 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.

10 Availability

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 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.

11 Compliance The system shall ensure compliance

37

with the reliability quality attributes by requiring the system 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.

38

USABILITY

12 Understandability

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 and if a person wants to view their relationships. The system will ensure basic understandability by using a graphic user interface and be user friendly by using big buttons and extremely easy to follow instructions.

13 Learnability

The system shall be easy and quick to learn for both the administrator and the person that might want to view their relationship. The system will ensure learnability by producing a step-by-step tutorial on the web-page interface that will address all logical paths one can take on the website. The system will ensure learnability by making the system as logical, easy to use and simple as possible.

39

14 Operability

The system shall have a high degree of operability and ease of use. The system will ensure operability by requiring a graphical user interface on top of a web-based interface which will allow simple operability of the system.

15 Attractiveness

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 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.

16 Compliance

The system shall ensure compliance with the usability quality attributes by requiring the system to be easy to use and be a graphical user interface and use a web-based interface. Compliance will be

40

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.

41

EFFICIENCY

17 Time Behavior

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. The system shall commence backups at the beginning of every second and finish at 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.

18 Resource Utilization

The system shall utilize the optimal amount of resources at all times. The system shall accommodate all requests by providing whatever resources it needs. The system will ensure

42

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.

19 Compliance

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 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.

43

MAINTAINABILITY

20 Analyzability

The system shall be easily diagnosed and analyzed for any software errors or hardware failures in the system. Analyzability shall be ensured by requiring the administrator to run scheduled analyzer tests every week to check for overall system performance and diagnostics.

21 Changeability

The system shall easily modifiable and easy to change. Changeability will be ensured by developing the entire software around the J2EE framework. Changeability will be ensured by requiring the entire software architecture be developed around and restricted to only Java and Java technologies thus ensuring full 100% compatibility.

22 Stability

The system shall be one that is extremely stable and resistant to any kind of hardware or software failures. Stability will be ensured by running periodic tests and system diagnostics on a weekly basis.

44

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. .

23 Testability

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 ensured by having unit testing available to the administrator. Testability will be ensured by having integration testing available to the administrator.

24 Compliance

The system shall ensure compliance with the maintainability quality attributes by requiring the system be highly adaptable and easy to test for. Compliance will be ensured by developing the system in a common framework and to create a series of tests easily usable to the administrator.

45

PORTABILITY

25 Adaptability

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 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.

26 Installabiltiy

The system shall be easily installable as on different servers. Installabiltiy shall be ensured by using a easy to use one click self executing installation package that does “everything” once the administrator simply runs the application.

27 Co-Existence

The system’s individual servers shall each co-exist by themselves as stand-alone units. Co-existence shall be ensured by requiring all the hardware components and software modules to be in one physical

46

machine, one server at a time.

28 Replaceability

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 are based in object-oriented programming languages so it is easy to isolate the problem. Replaceability is ensured by requiring regular weekly maintenance of both hardware components and any buggy software modules.

29 Compliance

The system shall ensure compliance with the portability quality attributes by requiring the system rely on industry standard hardware components and software modules. Compliance will be ensured by requiring superior hardware and superior software to be used throughout the lifecycle of the system.

47

QUALITY

30 Effectiveness

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 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.

31 Productivity

The productivity of the system is determined 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 minimal updates, patches, or general maintenance. Productivity will be determined primarily by the amount of unnecessary interaction with the administrator.

32 Safety

The system will be absolutely safe by having multiple layers of security. Safety will be ensured

48

by having the system locked in a secured, top-secret classified location. Safety will be ensured by allowing access to the actual system by bypassing a military grade security perimeter system with 12 armed guards 24/7/365. Safety will be ensured by requiring both a retina and handprint scan before the administrator is allowed inside. Safety will be ensured by requiring the administrator to submit a password consisting of 128 unique characters.

33 Satisfaction

The satisfaction of the system will be determined by the usefulness and happiness of the user experience of the administrator. Satisfaction will be ensured by developing a system to meet the needs and requirements of the administrator.

49

POLICY

34 Functional

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 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 also creating a TTL (time to live) attribute for any and all events.

35 Data

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 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

50

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.

36 Control

The system shall be dynamic and shall be maintained by the system clock which is adjusted dynamically at every minute by comparing the system population difference rate on a year to year (every minute in real time) basis.

37 Control/Data interfaces

The system’s control and data interfaces are the system clock that maintains all the events of the system. The system shall be maintained by the system clock. Data shall be transmitted by a data bus and events shall be transmitted by an event bus.

38 Event

The system shall generate its events from the system clock. Based on the system clock, the system will alter its events dynamically to allow more or less population growth in order to keep the

51

system functioning.

39 State maintenance

The system shall maintain data for each person for 400 years in the system (400 minutes in real-time). The data shall be purged automatically from the database after 400 minutes.

40 Interfaces

The system shall have an administrator interface for the administrator’s use only. The interface will be a graphical user interface and be web-based and use Windows style logic.

41 Behavior over time

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 real time. The system shall rank different data in different priorities over time depending on how long the event has lived in the system.

42 Time Relationships

The system shall purge all data for each individual after 400 minutes (400 years in the system). This data will be automatically deleted

52

from the database.

43 Time sequences

The system shall execute all tasks in a specific sequence. The system shall first do its events using a FCFS algorithm. If an event is a high priority task, the system shall preempt that event and assign it as a high priority.

44 Time concurrencies

The system shall be built using an architecture that can handle multiple transactions concurrently in real-time. 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.

45 Time synchronization

The system shall be able to handle multiple requests at the same in parallel. The system will ensure time synchronization by building an architecture that can handle multiple processes. Every event in the system shall have its own priority which will be executed in the respective order of the priority.

53

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

FUNCTIONALITY

General 10 10 120

4th

Suitability 10 10

Accuracy 10 10

Interoperability 10 10

Security 10 10

Compliance

10 10

Type/Use Case

1 2 3 4 5 6 7 8 9 10 Total Rank

RELIABILITY

Maturity 10 10 10 10 10 10 10 350

1st

Fault Tolerance 10 10 10 10 10 10 10

Recoverability 10 10 10 10 10 10 10

Availability 10 10 10 10 10 10 10

Compliance 10 10 10 10 10 10 10

Type/Use Case

1 2 3 4 5 6 7 8 9 10 Total Rank

USABILITY

Understandability 10 10 10 150

2nd

Learnability 10 10 10

Operability 10 10 10

Attractiveness 10 10 10

Compliance 10 10 10

Type/Use Case

1 2 3 4 5 6 7 8 9 10 Total Rank

EFFICIENCY

Time Behavior 10 10 10 10 10 150

2nd

Resource Utilization

10 10 10 10 10

Compliance 10 10 10 10 10

54

Type/Use Case

1 2 3 4 5 6 7 8 9 10 Total Rank

MAINTAINABILITY

Analyzability 10 50

6th

Changeability 10

Stability 10

Testability 10

Compliance

10

Type/Use Case

1 2 3 4 5 6 7 8 9 10 Total Rank

PORTABILITY

Adaptability 0

7th

Installability

Co-existence

Replaceability

Compliance

Type/Use Case

1 2 3 4 5 6 7 8 9 10 Total Rank

QUALITY

Effectiveness 10 10 80

5th

Productivity 10 10

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.

55

“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.

56

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

57

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

58

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

59

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.

60

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.

61

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.

62

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.

63

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.

64

Use Case Analysis of Second Architecture Design

USE CASE DESCRIPTION ACTOR(S) PURPOSE ARCHITECTURE TYPE

1 View a person Administrator, System

Requesting to view an individual’s information.

3-tier client-server


System System checks to see if a male and female are potential marriage candidates.

Pipe and Filter



System To effectively control population size.

Pipe and Filter

4 System startup Administrator To start the system 3-tier client-server


Administrator, System


Pipe and Filter 3-tier client-server

6 Add a person Administrator, System

To add a new entry to the database.


7 System test Administrator To check system performance.



System To determine if the two candidates are eligible for marriage.

Pipe and Filter



System To generate a love/compatibility score for each candidate.

Pipe and Filter




65

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.”

66

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.”

67

Use Case Analysis of Final Revised Architecture Design

USE CASE DESCRIPTION ACTOR(S) PURPOSE ARCHITECTURE TYPE

1 View a person Administrator, System

Requesting to view an individual’s information.

Distributed 3-tier client server


System System checks to see if a male and female are potential marriage candidates.

Pipe and Filter



System To effectively control population size.

Pipe and Filter

4 System startup Administrator To start the system Distributed 3-tier client server w/ fault tolerance


Administrator, System


Pipe and Filter


6 Add a person Administrator, System

To add a new entry to the database.

Client-server Distributed 3-tier client server

7 System test Administrator To check system performance.

Distributed 3-tier client server w/ fault tolerance


System To determine if the two candidates are eligible for marriage.

Pipe and Filter



System To generate a love/compatibility score for each candidate.

Pipe and Filter



Distributed 3-tier client server w/ fault tolerance

68

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.

69

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.

70

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.

71

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.

72

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.

73

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

74

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.

75

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é

76

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é

77

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.

78

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.

79

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.

80

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

81

Figure 7: Property Chain for isRelatedTo Object Property

Figure 8: Property Chain for hasSibling Object Property

82

Figure 9: Property Chain for hasGrandParent Object Property

Figure 10: Property Chain for hasGreatGrandParent Object Property

Figure 10: Property Chain for hasGreatGrandParent Object Property

83

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 (?)

84

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

85

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é

86

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

87

Figure 15: Run of query hasGrandParent on Instance AA

Figure 16: Run of query hasGreatGrandParent on Instance AA

88

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

89

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)

90

// 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)

91

// 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)

92

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)

93

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) // Sub property chain axiom SubObjectPropertyOf(SubObjectPropertyChain(hasDescendent hasAncestor) isRelatedTo) // Sub property chain axiom SubObjectPropertyOf(SubObjectPropertyChain(isRelatedTo) CantMarry) // Sub property chain axiom SubObjectPropertyOf(SubObjectPropertyChain(hasParent hasParent) hasGrandParent) // Sub property chain axiom SubObjectPropertyOf(SubObjectPropertyChain(hasChild hasChild) hasDescendent) // Sub property chain axiom SubObjectPropertyOf(SubObjectPropertyChain(hasParent hasParent hasParent) hasAncestor) // Sub property chain axiom SubObjectPropertyOf(SubObjectPropertyChain(hasChild hasChild hasChild) hasDescendent) // Sub property chain axiom SubObjectPropertyOf(SubObjectPropertyChain(hasAncestor hasDescendent) isRelatedTo) // Sub property chain axiom SubObjectPropertyOf(SubObjectPropertyChain(hasParent hasParent) hasAncestor) // Sub property chain axiom SubObjectPropertyOf(SubObjectPropertyChain(hasParent) hasAncestor) // Sub property chain axiom SubObjectPropertyOf(SubObjectPropertyChain(hasParent hasSibling hasChild) hasFirstCousin) // Sub property chain axiom SubObjectPropertyOf(SubObjectPropertyChain(hasParent hasParent hasParent) hasGreatGrandParent) // Sub property chain axiom SubObjectPropertyOf(SubObjectPropertyChain(hasGrandParent hasSibling hasGrandChild) hasSecondCousin) // Sub property chain axiom SubObjectPropertyOf(SubObjectPropertyChain(hasParent hasChild) hasSibling) // Generated by the OWL API (version 2.2.1.1042) http://owlapi.sourceforge.net

94

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

95

{ 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.

96

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.

97

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.

98

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.

99

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) } 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) } pred isSecondCousin(x, y: Person) { some z : Person |

100

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) } 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. Executing "Run isSecondCousin for 16 Person" Solver=sat4j Bitwidth=4 MaxSeq=4 Symmetry=20 77376 vars. 1104 primary vars. 166209 clauses. 608ms. Solving... Executing "Run isSecondCousin for 18 Person" Solver=sat4j Bitwidth=4 MaxSeq=4 Symmetry=20

101

126045 vars. 1386 primary vars. 267222 clauses. 1155ms. 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).

102

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) */ abstract sig Person { father : lone Man, mother : lone Woman} /* A woman can have at most 1 husband, which has to be a man */ sig Woman extends Person { husband : lone Man } /* A man can have at most 1 wife, which has to be a woman */ sig Man extends Person { 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 */ fact spousal_Relationship { husband =~ wife } /* No person can be his or her own ancestor */ fact no_Self_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 */ fact parents_Relationship { all x : Person | #x.(father + mother) = 2 => (x.mother.husband = x.father) and (x.father.wife = x.mother)}

103

/* No man or woman is allowed to marry their own ancestors */ fact noIncestMarriage { no m : Man | m.wife in m.(^mother) 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 */ pred isThreeDistinctNodes (x, y, z: Person) { (x != y) and (x != z) and (y != z)} /* This predicate will detect great grandparent relationship */ pred isGreatGrandParent (x, y: Person) { x in y.(father + mother).(father + mother).(father + mother) } /* This predicate checks if two given persons have common ancestors */ pred noCommonAncestor(x, y: Person) { (x.(father + mother) + x.(father + mother).(father + mother)) & (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] }}

104

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] }

105

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) */ abstract sig Person { father : lone Man, mother : lone Woman} /* A woman can have at most 1 husband, which has to be a man */ sig Woman extends Person { husband : lone Man }

106

/* A man can have at most 1 wife, which has to be a woman */ sig Man extends Person { 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 */ fact spousal_Relationship { husband =~ wife} /* No person can be his or her own ancestor */ fact no_Self_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 */ fact parents_Relationship { all x : Person | #x.(father + mother) = 2 => (x.mother.husband = x.father) and (x.father.wife = x.mother)} /* No man or woman is allowed to marry their own ancestors */ fact noIncestMarriage { no m : Man | m.wife in m.(^mother) no w : Woman | w.husband in w.^(father)} /* This predicate will check to see if three given people are all different individuals */ pred isThreeDistinctNodes (x, y, z: Person) { (x != y) and (x != z) and (y != z)} /* This predicate will detect great grand parent relationship */ pred isGreatGrandParent (x, y: Person) { x in y.(father + mother).(father + mother).(father + mother) } pred noCommonAncestor(x, y: Person) { (x.(father + mother) + x.(father + mother).(father + mother)) & (y.(father + mother) + y.(father + mother).(father + mother)) == none}

107

/* 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" Solver=sat4j Bitwidth=4 MaxSeq=4 Symmetry=20 53887 vars. 854 primary vars. 115657 clauses. 795ms. 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.

108

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.

109

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.

110

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.

111

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.

112

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

113

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.

115

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.

116

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.

117

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.

118

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.

119

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

documentation 10.0

Documents