POPULATION SIMULATION SYSTEM CPSC 462: Spring 2009 Professor Haig Krikorian

Ahmad Abuqasem David Choi Aruni Kirtipal Kunal Malviya Komal Tamhane Thanh Truong

TABLE OF CONTENTS
I. II. III. IV. TABLE OF CONTENTS DIVISION OF WORKLOAD INTRODUCTION UML DESIGN a. USE CASE TABLE b. USE CASE DIAGRAM c. SEQUENCE DIAGRAMS d. UML CLASS DIAGRAM e. DATA FLOW DIAGRAMS f. STATE DIAGRAM g. ACTIVITY DIAGRAM h. LOGICAL VIEW i. QUALITY & POLICY DESCRIPTIONS j. QUALITY & POLICY RANKING TABLE DESIGN PATTERNS ARCHITECTURE DESIGN (ARCHSTUDIO) a. INITIAL ARCHITECTURE i. USE CASE ANALYSIS OF SECOND ARCHITECTURE b. REVISED ARCHITECTURE i. USE CASE ANALYSIS OF FINAL REVISED ARCHITECTURE c. ARCHSTUDIO SUBSYSTEMS AND MODULES CLASS DESIGN (PROTÉGÉ) a. CLASS DECRIPTION i. CLASS DEFINITION b. PROTÉGÉ DESIGN c. PROTÉGÉ PROPERTIES i. PROTÉGÉ EXAMPLE d. PROTÉGÉ DEMONSTRATION e. OWLVIZ DEMONSTRATION f. PROTÉGÉ CODE PROVING THE DESIGN (ALLOY) a. INITIAL ALLOY DESIGN WITH DEFINITION b. EVALUATION OF INITIAL ALLOY DESIGN c. EVALUATION OF FINAL ALLOY DESIGN d. DYNALLOY TIME SIMULATIONS (CHEDDAR) a. CHEDDAR CONCLUSION REFERENCES 1 2 3 5 8 9 20 22 24 27 30 31 53 56 61 64 65 67 68 74 75 75 77 83 85 88 89 94 98 99 102 108 116 118

V. VI.

VII.

VIII.

IX. X. XI.

1

DIVISION OF WORKLOAD
The following chart represents the division of workload for our project. The percentages next to each category was the approximate proportional amount of time we devoted to the project and is further broken down per person. Every member of the group equally contributed 16.67% percent of the total workload. Title Documentation – 10% Elaboration – 10% Name David David Thanh Komal Kunal Aruni Ahmad Thanh David Komal Kunal Aruni Ahmad Kunal Komal Thanh Aruni Ahmad Kunal Aruni Komal Komal Kunal Primary/Secondary Primary (10%)

All Together (10%)

UML Design – 20%

Design Patterns – 10% Alloy – 15% Protégé – 15% Archstudio – 15% Cheddar – 2.5% Dynalloy – 2.5%

Primary (5%) Primary (5%) Secondary (2.5%) Secondary (2.5%) Secondary (2.5%) Secondary (2.5%) Primary (7.5%) Secondary (2.5%) Primary (10%) Secondary (5%) Primary (12.5%) Secondary (2.5%) Primary (7.5%) Secondary (7.5%) Primary (2.5 %) Primary (2.5%)

2

INTRODUCTION
The Issue The goal of this project is to design a population simulation system where the population can dynamically grow and decline - the only restriction is that a person cannot marry their second cousin or anyone closer. The simulation will accomplish this by examining all the genealogical interdependencies and marriage possibilities in a set of data for each person. Description of Requirements and Assumptions Initialization Stage The initial seed consists of 5,000 males and 5,000 females all unrelated to each other. The initial seed will have no parents or any ancestors. The ages of the initial seed population are randomly and evenly dispersed from the age of 1 day old to 99 years and 364 days old. Age and Mortality There is a required enforced mortality limit of exactly 100 years of age. If someone is not dead by 99 years and 364 days of age, they are humanly euthanized for the betterment of mankind. There are 5 age classes: o Alpha Class: 1 day to 19 years old. o Beta Class: 20 years to 39 years old. o Gamma Class: 40 years to 59 years old. o Delta Class: 60 to 79 years old. o Omega Class: 80 to 99 years old. Marriage Restrictions o Marriage is defined as between a man and a woman. o Anyone man or woman related closer than that of a second cousin are not allowed to get married. o Polygamy is strictly forbidden. o Divorce is allowed and remarriage is allowed so long as it doesn’t become polygamous. o Inferior (either genealogically deficient, impotent, or otherwise diseased or sick) people (statistically 1% of population) cannot get married. o Only Beta, Delta & Gamma classes are allowed to get married. Marriage Filters – “Compatibility Score Algorithm (CSA)” o Marriage is based on a score from two pieces of data: A CSA score based on nine filters and a age score based on likelihood of candidate getting married at their respective age.
3

o Each filter is an attribute assigned a value of 1-10 based on the personality profile of the individual. 1. Race 2. Religion 3. Education 4. Wealth 5. Health 6. Reputation 7. Cultural 8. Criminal Background 9. Location Children All married couples may have children. Couples may have 0 or more children. “Dynamically Adjusting System Clock” (DASC) One minute of real time is equivalent to one year in the system simulation. The system clock speed is determined by measuring the rate of percentage change of the population from the previous year. There are five variable clock speeds. o Very Fast Mode - if the population growth is 9% or greater, we remove candidates from the age classes Gamma and Delta (only couples both in the Beta class can get married and have children) and we apply China’s 1 child only law. o Fast Mode – if the population growth is between 6% to 8%, we remove candidates from the age class Delta (only couples both in the Beta and Gamma can get married and have children) and we apply Japan’s 2 child only law. o Normal Mode – if the population growth is between 3% to 5%, then our system will run as elucidated above (couples in the Beta, Delta and Gamma classes can get married and have as many children as they want). o Slow Mode – if the population growth is between 1% to 3%, we add candidates from the age class Alpha (couples in the Alpha, Beta, Delta and Gamma can get married and have as many children as they want) and we limit the CSA marriage filters by only applying filters #6 through #9. o Very Slow Mode - if the population growth is less than 1%, every person alive in our system outside of the inferior people can get married and have as many children as they want and we will only apply CSA marriage filter #9. Assumptions Each person can have and must have only two biological parents, a male and a female. Only the system and the administrator may access the system.

4

UML DESIGN
USE CASE TABLE
The use cases that are present in the system are based on how users will interact with the system. In our system, there are only two major actors, the administrator and the system itself. The administrator is the outside actor (“God”) who injects themselves into the system only if something has gone wrong or to perform diagnostics. The activities that are reserved for administrator use only are “system startup”, “system test”, and “system self-repair”. The system itself is the internal actor which automates most of the activities within our system. The activities that are reserved for system use only is “determine a person’s relationship to another person”, “dynamically adjust population control”, “check up to 2nd cousin”, and “compatibility score algorithm”. The administrator and the system also have shared activities that are “view a person”, “update the database”, and “add a person”. While it is more than likely that the system will automate most of these activities, we reserve the right of the administrator to have access to these activities if needed. The following charts provides a high level view of how each case interacts with the system.

5

Database is up to date Database is Efficiency updated. 2 Determine a System person's relationship to another person 3 Dynamically adjust population control System System checks to see if a male and female are potential marriage candidates To effectively control population size Both Efficiency persons Reliability are present in the database. 5 Administrator System System is functioning properly All transaction s updated in real-time Reliability Usability Performance Availability 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 Availability is present Reliability in the database. Successfully commits the transaction and updates all associated attributes within the system. Performance Clock speed is not normal System queries the database to show the individual's information plus all the relational dependencies System will check the database to see if they are related (2nd cousin or higher) System will check the population growth every minute (year) and apply the necessary population control filters accordingly. Database is up to date. The system is turned on and it works. 4 System startup Update the database Administrator To start the system To show the most current information in real-time.

Delta and Gamma. Efficiency System will create a new entry and update database and new associations Verification results are displayed in either textual description or graphical representation If the candidates are eligible. To remove all faults from the system. System is malfunctioning Availability Reliability The system is restored to a previous working state. Otherwise. 7 . system will put them in the marriage bucket. entry to the Database database storage has not reached its maximum capacity. Systems always return a suitable match.6 Add a person Administrator System To add a new Person is alive. Candidate is in age brackets Beta. Efficiency Reliability 7 System test Administrator Testability Maintainability 8 Check up to 2nd cousin System To determine if the two candidates are eligible for marriage Both candidates exists in the current database. they go back to hopper. Efficiency Reliability 9 Compatibility System Score Algorithm 10 System selfrepair Administrator To generate a compatibility score for each candidate. To check system performance System is in operational state.

8 . This diagram shows the interrelationships of the users (administrator and the system) and the use cases.USE CASE DIAGRAM Our use cases can also be demonstrated graphically by a use case diagram.

SEQUENCE DIAGRAMS View a Person System Administrator requests to view an islander’s information. UI Handler displays the requested islander’s information on the screen. Rules Engine executes a set of system rules and returns the additional rules required for the request to the Request Handler. System UI (User Interface) Handler responds and generates a view request to the Request Handler. Request Handler gathers all information and queries the Master Database for the islander’s information. namely the rules. 9 . Request Handler processes the request and runs the Rules Engine to get all associated information. UI Handler formats the retrieved data. forwards it to the UI Handler. in turn. Database engine returns the query results to the Request Handler which.

Relationship Manager generates a family tree request for the first person (i. Request Handler eventually forwards a list of Person B’s ancestors to Relationship Manager. Relationship Manager traverses the two family trees to find out the actual relationship (e.e. Relationship Manager returns the retrieved relationship to the PSS System Handler. Person B) and sends it to the Request Handler.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 examines the two sets of ancestors and checks if they intersect. Relationship Manager generates another family tree request for the second person (i. forwards it to Relationship Manager. 10 . Person A) and sends it to the Request Handler. aunt & niece).g. Database engine returns the requested records to the Request Handler which. in turn.e. Request Handler processes the request and queries the island Master Database for Person A’s ancestor records up to Great Grand Parent generation. once again up to Great Grand Parent generation only.

System Handler adjusts the system clock speed accordingly. System Clock returns the result of the operation to the PSS System Handler 11 . System Handler requests for the current annual population growth on the island from the Population Monitor Handler. System Handler analyzes the given population growth rate. Population Monitor Handler returns the most current population growth rate to the System Handler.Dynamically Adjust Population Control The PSS System Handler registers with the Timer for end-of-year events (i. the end of every minute) The Timer notifies the PSS System Handler of end-of-year events.e.

Request Handler processes the living population request and runs the Rules Engine to retrieve all rules that will be triggered by the request. forwards it to the System Data Manager. 12 . Request Handler gathers all information and queries the Master Database for the islander’s living population. System Handler initializes and sets all the default states and behaviors. in turn.System Start Up System Administrator powers up the PSS (Population Simulation System). System Handler starts the Timer to keep track of elapsed time (Assumption: 1 minute of system simulation = 1 earth year). Database engine returns the query results to the Request Handler. System Data Manager stores the data locally. which. Rules Engine executes a set of system rules and returns the additional rules required to the Request Handler. System Handler requests for the island’s living population.

Database engine returns the query result to the Request Handler which. forwards it to the System Handler.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. in turn. 13 . The Rules Engine executes a set of system rules and returns the required set of rules associated with the request to the Request Handler. The Request Handler accepts the request and runs the Rules Engine to retrieve all the additional rules required. Request Handler gathers all information and sends a query to the Master Database to update certain records.

forwards it to the Population Monitor Handler. Request Handler collects all information and queries the Master Database to create a new record for the new islander. in turn. Rules Engine executes a set of system rules and returns the rules required for the current request to the Request Handler. Request Handler processes the new entry request and runs the Rules Engine to retrieve all the rules that will be triggered by this request.Add a person PSS System Handler invokes the Population Monitor Handler to add a newborn baby to the island Master Database. Database engine returns the query result to the Request Handler which. 14 . Population Monitor Handler updates the island’s current population size. Population Monitor Handler generates a new entry request and sends it to the Request Handler for processing. Population Monitor Handler sends the status of the original request to the PSS System Handler.

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

in turn.e. Relationship Manager checks for any point of intersection between the two sets. Relationship Manager generates a family tree request for the first person (i. forwards it to Relationship Manager. Person B) and sends it to the Request Handler. each containing 14 ancestors. Database engine returns the requested records to the Request Handler which. Person A) and sends it to the Request Handler. once again up to Great Grand Parent generation only. 16 . Request Handler eventually forwards a set of Person B’s ancestors to Relationship Manager.e. Relationship Manager generates another family tree request for the second person (i.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. a Boolean value) to the PSS System Handler. Relationship Manager returns the lookup result (i.e. Request Handler processes the request and queries the island Master Database for Person A’s ancestor records up to Great Grand Parent generation.

Compatibility Score Algorithm 17 .

in turn. Compatibility Manager sets the CSA’s Wealth input. Compatibility Manager sets the CSA’s Current Location input. Compatibility Manager creates a Compatibility Score Algorithm instance. Compatibility Manager then directs CSA to generate a compatibility score based on the above inputs. Compatibility Manager sets the CSA’s Health Status input. Compatibility Manager sets the CSA’s Reputation input. Compatibility Manager sets the CSA’s Criminal Background input. Compatibility Manager sets the CSA’s Race input. 18 . Compatibility Manager sets the CSA’s Age Bracket input. Compatibility Manager verifies the candidate’s information and sets default values for malformed attributes. Compatibility Manager sets the CSA’s Cultural Background input. Compatibility Manager sets the CSA’s Religion input.PSS System Handler requests a compatibility score for Candidate A from Compatibility Manager. forwards it to PSS System Handler. Compatibility Manager sets the CSA’s Education input. CSA generates a score and returns it to Compatibility Manager which.

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 goes back to monitoring. Health Monitor Handler commands the inactive handlers to start processing. 19 . Health Monitor Handler then sends a get alive status message to other listening handlers in the system.

UML CLASS DIAGRAM 20 .

At the end. while the Processing thread is responsible for removing the oldest request from the queue and processing it. Population Monitor: This module is responsible for monitoring the annual population growth on the island. It then applies some filters and executes a Compatibility Score Algorithm on these islanders. they will be placed in the marriage bucket waiting to exchange their vows. 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. Clock: This module accepts speed change commands from Population Monitor and sets the speed. It presents to the user simulation options and processes selected commands by sending a signal message to the PSS Logic Server. With this request handling mechanism in place. Person: This module contains all the information associated with a simulated person in PSS system. If the couples pass the 2nd cousin or closer relationship test. 21 . Ranking Manager: This module takes the island population as an input from the Request Handler. Other characteristics will be used to determine compatibility with others in the database. A person’s attributes such as parents. children will be used by the system to retrieve his/her family tree.These modules together represent the software architecture of our Population Simulation System. spouse. 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. 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. 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. all system requests will be guaranteed to get serviced. People with scores in the same range will be likely to become soul mates. PSS Client refreshes its user interface as feedbacks are received from PSS Logic Server to indicate current simulation progress. PSS Client: This module is responsible for launching the system’s web-based user interface. people with a passing score will be placed in a marriage candidate bucket. Marriage Manager: This module marries chosen couples from the marriage bucket and have them bear children. It analyzes the yearly growth rate and sets the system clock speed accordingly. Candidate Manager: This module selects couples with the same compatibility score range and plays the system’s matchmaker role. Its main role is to apply system filters to ensure that growth rate is as close to normal as possible.

PSS Resource Manager forwards them to the PSS Business Logic Server which starts the simulation of life on the island by matching and marrying people with 2 nd cousin relationship constraints. PSS client machine is responsible for presenting feedback to and accepting commands from the user. 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. PSS Resource Manager Server starts querying the database for the island records. 22 . At the Presentation tier. At the Data tier.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. Once the records are retrieved. At the Logic tier.

who will send out a command to update the Island database with the received information. expected rate.PSS Business logic server data flow diagram The above data flow diagram illustrates all the processing logic within the PSS Business Logic Server. in an effort to keep the population growth at a normal. 23 . The change in system clock speed will have an immediate effect on how the ranking algorithm and child bearing law work. Population Control will ask the Request Handler for the current population growth. each having a generated compatibility score. Population Control analyzes the growth rate and sets the system clock speed accordingly. 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. it will start matching people (with the 2nd cousin relationship or closer restriction) and sends the association pairs over to Marriage Manager. Marriage Manager will start marrying chosen couples and have them bear children. At the next step. Marriage Manager then sends the couple’s marital status and their children’s information to the Request Handler. Once Candidate Manager receives the set of marriage candidates from Ranking Manager. At an emulated year-end event.

The system requests for the islander’s living population. 24 . Records catch locally. PSS System is ready to use. System is initialized as soon as it is turned ON. State diagrams describe all of the possible states of an object as events occur.STATE DIAGRAM State diagrams are used to describe the behavior of a system. We have three state diagrams corresponding to three important use cases. System goes into updated state. System Startup System Administrator turns ON the Population Simulation System (PSS).

25 . To control the population growth dynamically. system gets the rate of population growth.Dynamic Population Control System is ready and running. Depending on the rate of growth. system will set the clock to any of the five predetermined speeds. The rate of growth is analyzed to set the clock dynamically.

e.B are related. system will determine if person A. The system will fetch other person’s family tree and further check for any point of intersection i. system will fetch the person’s family tree. 26 . B are related or share any of 14 ancestors. System will display the results.Second Cousin Check System is running To determine if person A.

ACTIVITY DIAGRAM Activity diagrams describe the workflow behavior of a system. The system queries the database to extract the living population. system initializes its servers and database. 27 . System Startup When the administrator turns ON the system. This diagram basically models the workflow of the system being designed. Same time the GUI are also initialized.

Dynamic Population Control System checks the population growth. 28 . 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.

Once family tree is fetched the system will check for common ancestors. 29 .Second Cousin Check System will first fetch the family tree of the person to check if he is related to other person. system will display that the two individuals are related else not related. If at all there is a common ancestry.

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. The simulation starts. 30 . Database server gets the records from the database. Everything flows back to the logic server. PSS logic server queries the population from the PSS database server.

Actual “people” in the system do not have any ability to “write” any data. However. The CSA involves nine 1 General FUNCTIONALITY 2 Suitability 31 . Our system shall not allow any other “users”. The administrator shall have full access to the system. 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. there are only two actors that can manipulate any data in the system: the system itself and the administrator (God). our system does allow on a limited exception for “people” in our system to be able to “view their relationship with another”. The system shall filter out compatibility issues with each other by using a specialized algorithm called the “Compatibility Score Algorithm” (CSA).QUALITY & POLICY DESCRIPTION Type Number Quality Attribute Description In our system.

the data is automatically purged. The system shall ensure this level of accuracy by requiring weekly testing and daily indexing of the data. and location. This score will be assigned by using a kind of questionnaire or test format that each individual must fill out. After 400 years. criminal background. 3 Accuracy 32 . 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. cultural.99%. The system shall keep data on all individuals for 400 years. education. health. reputation. females -= 25). wealth. The system shall ensure this level of accuracy by redundancy in our architecture design. The system shall retain accuracy of data at 99. religion.different filters including race.

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

5

Security

33

security by only allowing the administrator to have access to modify, change, add, delete or alter in any form or manner any data whatsoever or restart the system with a software or hardware reboot. The system shall ensure compliance with the functionality quality attributes by requiring the system be highly secure and reliable. Compliance will be ensured by restricting any critical tasks to the administrator and by tailoring the system to be highly redundant and available.

6

Compliance

34

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

RELIABILITY

8

Fault Tolerance

35

24 hours a day.999999% of the 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.317 nanoseconds in real-time per a calendar year of 365 days.any delay whatsoever. The system shall be available 99. The system shall be recoverable easily by a hard system boot by the administrator. The system shall ensure compliance 9 Recoverability 10 Availability 11 Compliance 36 . 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 also be recoverable easily by a software boot done by the administrator. This is the equivalent of . The system will ensure easy recoverability by auto-saving to the database at the end of every second of realtime.

compliance will be ensured by requiring ultra high availability. Secondly. Compliance will be ensured primarily with superior hardware. recoverability and fault tolerance will be built into the system as “stop-gap” measures to prevent any data loss. 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. In the event that fails.

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 shall be easy to learn and use for the administrator and if a person wants to view their relationships. easy to use and simple as possible. The system will ensure learnability by making the system as logical. The system will ensure learnability by producing a step-bystep tutorial on the web-page interface that will address all logical paths one can take on the website. 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.12 Understandability USABILITY 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. 13 Learnability 38 .

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. with a modern interface that makes the system look robust. The system shall be an attractive piece of software by having a graphical user interface. Compliance will be 15 Attractiveness 16 Compliance 39 . hightech. 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.14 Operability The system shall have a high degree of operability and ease of use. The system shall look professional. 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.

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.

Thus. The system shall utilize the optimal amount of resources at all times. The system shall execute any query it’s given within 5 milliseconds. This backup will ensure that all activity of the previous second will be fully backed up. Time behavior is linked to recoverability and thus without a high degree of this attribute. 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.17 Time Behavior EFFICIENCY The system shall ensure time behavior my building into the architecture strict restrictions about how quickly data must be executed. The system shall commence backups at the beginning of every second and finish at the end of every second. The system will ensure 18 Resource Utilization 41 . backups will not exist. The system shall accommodate all requests by providing whatever resources it needs.

deadlock prevention by using an algorithm to prioritize resources and to age and prioritize every event. Resource utilization will be ensured by dividing multiple tasks in parallel and be handled by multiple processors to achieve optimal efficiency. The system shall ensure compliance with the efficiency functionality quality attributes by requiring the system always accomplish its data transactions in the same amount of time – all the time. Compliance will be ensured by using hardware components 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.

19

Compliance

42

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

MAINTAINABILITY 21 Changeability

22

Stability

43

Stability will be ensured by checking weekly to see if the system is running efficiently and normally. Stability will be ensured by checking for any deviant behavior or anomalies on a weekly basis. regular basis. . The system shall be easily testable and be easy to run diagnostics to see if there is anything wrong with the system. Testability will be ensured by having unit testing available to the administrator. Testability will be ensured by having integration testing available to the administrator. The system shall ensure compliance with the maintainability quality attributes by requiring the system be highly adaptable and easy to 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.

23

Testability

24

Compliance

44

Co-existence shall be ensured by requiring all the hardware components and software modules to be in one physical PORTABILITY 26 Installabiltiy 27 Co-Existence 45 .25 Adaptability The system shall be capable of handing at least 25 million transactions per second at any given time. 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. The system’s individual servers shall each co-exist by themselves as standalone units. The superset of transactions will include making all transactions regarding any and all associations. The system shall be easily installable as on different servers. Adaptability will be ensured by running multiple stress testing scenarios to see how many transactions the system can handle at any given time.

The system shall 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. Replaceability is ensured by requiring regular weekly maintenance of both hardware components and any buggy software modules. one server at a time.machine. 28 Replaceability 29 Compliance 46 . Replaceability is ensured by using offthe-shelf hardware components and software modules that are based in objectoriented programming languages so it is easy to isolate the problem. The system shall be easily replaceable in the event that a hardware component or software module becomes faulty.

or general maintenance. patches. An effective system will be productive if it does its required tasks efficiency and needs minimal updates. Productivity will be determined primarily by the amount of unnecessary interaction with the administrator. 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. Effectiveness shall be ensured by having the system fulfill the purpose for which it was created. The system will be absolutely safe by having multiple layers of security. Safety will be ensured QUALITY 31 Productivity 32 Safety 47 .30 Effectiveness The system shall not only be an effective system but it will be cost-effective as well. The productivity of the system is determined by how well the system does the task it’s supposed to do.

Safety will be ensured by requiring the administrator to submit a password consisting of 128 unique characters. The satisfaction of the system will be determined by the usefulness and happiness of the user experience of the administrator. Safety will be ensured by requiring both a retina and handprint scan before the administrator is allowed inside. top-secret classified location.by having the system locked in a secured. 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. 33 Satisfaction 48 . Satisfaction will be ensured by developing a system to meet the needs and requirements of the administrator.

In the event of a high priority request. Data for each person in the system shall be kept updated every second for a total of 400 minutes in realtime (400 years in the 35 Data 49 . that event shall be handled before any other event and be preempt any pending events. Functionality shall be ensured as it depends on a First-Come FirstServe (FCFS) priority basis. unless there is a high priority request. Deadlock prevention shall be ensured by also creating a TTL (time to live) attribute for any and all events. The integrity of the data in our system shall be maintained by not allowing any outside access to manipulate or change the data outside of the administrator. The data shall remain concurrent and standard by updating the database every second.34 Functional POLICY Our system shall be functional because the allocation of resources will always be optimized and take place using a deadlock prevention algorithm.

This data shall be aged by using a aging algorithm for any and all data attributes. 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. Data shall be transmitted by a data bus and events shall be transmitted by an event bus. the system will alter its events dynamically to allow more or less population growth in order to keep the 36 Control 37 Control/Data interfaces 38 Event 50 . Based on the system clock.system). 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. The system shall generate its events from the system clock. The data shall be purged after 400 minutes.

The data shall be purged automatically from the database after 400 minutes. 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 purge all data for each individual after 400 minutes (400 years in the system). The system shall rank different data in different priorities over time depending on how long the event has lived in the system. The system shall maintain data for each person for 400 years in the system (400 minutes in real-time). This data will be automatically deleted 39 State maintenance 40 Interfaces 41 Behavior over time 42 Time Relationships 51 . The system shall have an administrator interface for the administrator’s use only. The interface will be a graphical user interface and be webbased and use Windows style logic.system functioning.

The system shall be able to update the database in real-time and will alert the administrator if there is any redundant or recurrent data. The system shall first do its events using a FCFS algorithm. If an event is a high priority task. The system shall execute all tasks in a specific sequence. Every event in the system shall have its own priority which will be executed in the respective order of the priority. 43 Time sequences 44 Time concurrencies 45 Time synchronization 52 . The system will ensure time synchronization by building an architecture that can handle multiple processes. The system shall be able to handle multiple requests at the same in parallel. The system shall be built using an architecture that can handle multiple transactions concurrently in realtime.from the database. the system shall preempt that event and assign it as a high priority.

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 General Suitability FUNCTIONALITY Accuracy Interoperability Security Compliance Type/Use Case Maturity RELIABILITY Recoverability Availability Compliance Type/Use Case Understandability Learnability USABILITY Operability Attractiveness Compliance Type/Use Case Time Behavior EFFICIENCY Resource Utilization Compliance 1 2 10 10 10 3 10 10 10 1 10 2 10 1 2 3 10 10 10 10 10 10 3 4 10 10 10 10 10 3 4 4 5 10 10 10 10 10 10 5 10 10 10 10 10 5 6 10 10 10 10 10 6 7 7 8 10 10 10 10 10 8 9 9 10 10 10 10 10 10 10 Total Rank 350 1st Total Rank 120 4th 6 7 8 9 10 Total Rank Fault Tolerance 10 10 10 10 10 10 10 10 1 2 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 4 5 6 10 10 10 7 8 10 10 10 9 10 10 10 150 2nd 10 Total Rank 150 2nd 53 .

54 . downtime of even a couple of seconds can have huge effects on our data. “Our most important quality was that of reliability”. 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. we added up the total for each quality or policy type and ranked them – the more points.Type/Use Case Analyzability Changeability MAINTAINABILITY Stability Testability Compliance Type/Use Case Adaptability Installability PORTABILITY Co-existence Replaceability Compliance Type/Use Case Effectiveness QUALITY Productivity Safety Satisfaction 1 1 1 2 3 4 5 6 7 10 10 10 10 10 8 9 10 Total Rank 50 6th 2 3 4 5 6 7 8 9 10 Total Rank 0 7th 2 3 10 10 10 10 4 5 10 10 10 10 6 7 8 9 10 Total Rank 80 5th 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. Not surprisingly. Therefore our system has an extreme emphasis on being reliable and our architecture design (described below) is meant to reflect this. the more important that quality or policy was for our architecture and design. Based on this.

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. Due to the complexity of data and amount of data being piped through out system. Nonetheless. 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. 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. Not only should the product be satisfying and productive.” This attribute. Further. However. For our design. Our system is designed with reliability being the most important quality attribute so our system is designed to withstand many different type of failures. Thereby. “Our next highest quality attribute is that of functionality. “The last quality attribute is that of portability. expensive software and hardware components. while important in some regards. “The next highest is the policy attribute of quality. making the system as to cater to portability is the least important aspect when it comes to designing our system. Thus.” The most important aspect of this quality attribute was that it involved testing and maintaining of our system.” Our system must function at a high level and maintain accuracy of its data. 55 . actually scored a 0 for our system design. our system must also be one that has a high degree of usability. the system must be highly efficient and must prioritize this quality as one of the highest. it should be effective as well. portability did not reflect our overall architecture design.“Our second highest qualities were that of efficiency and usability” As our system is performing thousands of transactions per second. 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). It must also be constantly monitored and secure. 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. This quality requirement is reflected in our architecture design below. Our system is a highly complex design that requires very high powered.” The goal of the system is to create a system where overall high quality is achieved and maintained throughout the life of the project.

who creates it. their roles and collaborations. and represented. and create new objects by copying this prototype. abstracts. text box for our system. composed. It describes when it applies. and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. whether it can be applied in view of other design constraints. In our system a person record in the island database can be used as a factory method. They help make a system independent of how its objects are created. Operations like submitting the data or fetching some information would be accomplished through the use of a factory. Configuration here can be static ( at compile-time) or dynamic (at run-time). and the consequences and trade-offs of its use. The output is then passed through the candidate subsystem It defines an interface for creating an object. The design pattern identifies the participating classes and instances. 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. Creational Pattern Abstract Factory Description & Use Abstract Factory helps in creating a interface which includes making buttons. The creational patterns give you a lot of flexibility in what gets created. but let subclasses decide which class to represent. and when.DESIGN PATTERNS A design pattern names. There are two recurring themes in these patterns. Second. Adding a person. they all encapsulate knowledge about which concrete classes the system uses. Each design pattern focuses on a particular object-oriented design problem or issue. The Factory Method maps one record of a Person object to one entry in the database. they hide how instances of these classes are created and put together. It specifies the kinds of objects to create using a prototypical instance. creating set of association or checking for second cousin are the most common activity in our system and hence this can be use a prototype to create new objects by 56 Builder Factory Method Prototype . and the distribution of responsibilities. Creational Patterns Creational design patterns abstract the representation process. First. how it gets created.

Whenever the information is ready to be shown to the user. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces. A façade is an object that provides a simplified interface to a larger body of code. Composite lets clients treat individual objects and compositions of objects uniformly. 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 intent of this pattern is to add additional responsibilities dynamically to an object. The facade pattern can make the task of accessing a large number of modules much simpler by providing an additional interface layer. such as a class library. This pattern is particularly useful for making independently developed class libraries work together. Compose objects into tree structures to represent part-whole hierarchies. Structural Pattern Adapter Description & Use It convert’s the interface displaying information into another interface readable by the client. Storage of the parent and children information about each persons stored 57 Bridge Composite Decorator Facade Flyweight . decorator puts the data up and present it in a more fashionable way. The intent of this pattern is to decouple abstraction from implementation so that the two can vary independently. It works in combination with adapters to decorate the GUI design of the system. Structural class patterns use inheritance to compose interfaces or implementations. Structural Pattern Structural patterns are concerned with how classes and objects are composed to form larger structures.copying it. The data table uses a pointer system to share information about the records instead of recopying the information into each record of the system.

It provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation. Behavioral Pattern Behavioral patterns are concerned with algorithms and the assignment of responsibilities between objects.Proxy dynamically instead of statically. Behavioral Pattern Chain of Responsibility Description & Use The Chain of Responsibility design pattern allows an object to send a command without knowing what object will receive and handle it. 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. In our system. For example check for cousin is a commanding class. For this purpose link list or a hash table can be use. The Interpreter pattern describes how to define a grammar for simple languages. Behavioral class patterns use inheritance to distribute behavior between classes. and interpret these sentences. These patterns characterize complex control flow that's difficult to follow at run-time. It encloses a request for specific action inside an object and gives it a known public interface. 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. represent sentences in the language. Behavioral patterns describe not just patterns of objects or classes but also the patterns of communication between them. The client-server system has a proxy connection to connect the data from one port location to another. It encapsulates a request in an object and allows the parameterization of clients with different requests. 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. that would help us to chain all of the children for that particular person and the 58 Command Interpreter Iterator .

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. A mediator is responsible for controlling and coordinating the interactions of a group of objects. Allow an object to alter its behavior when its internal state changes.Mediator Memento Observer State Strategy Template Method iterator can iterate through the children when a search or add function is needed. and make them interchangeable. For example Define a family of algorithms. Strategy lets the algorithm vary independently from clients that use it. Intent is to define a one-to-many dependency between objects so that when one object changes state. encapsulate each one. 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. Clicking on button will prompt for different actions according to the request. The object will appear to change its class. 59 . 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. 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. Update Database subsystem updates and creates checkpoint every second in order to do the roll back in case of any errors. A memento is an object that stores a snapshot of the internal state of another object—the memento's originator. There are common situations when classes differ only in their behavior.

Visitor lets you define a new operation without changing the classes of the elements on which it operates.Visitor Represent an operation to be performed on the elements of an object structure. 60 .

ARCHITECTURE DESIGN INITIAL ARCHITECTURE DESIGN Figure 1 – First Architecture Design Our first attempt at an architecture started with coming up with a series of requirements and from that we formulated an architecture which turned out to be overly restrictive. The result was an architecture which was nothing but a series of “if-then” statements written in a flow chart style system. This system was flawed as it was far too simplistic and just functioned as a call and return system. 61 .

but was not flexible to handle any dynamic changes in our system. Conversely. These subsystems are: initial startup subsystem. criminal background and location. enforced euthanasia of 100 years of age. health. education. We then developed an architecture that was built to handle exceptions and “calamities” in a world that would loop and continue forever. gamma and delta groups can get married and have children). a population subsystem. If the population has decreased more than normal. Our architecture was then revamped and we started our design from almost from scratch. a family subsystem. Our second novel idea was using a system to rate our system clock speed to 5 different speeds. Our first architecture contains several major subsystems which in totality is called our “Business Logic Server”. the system clock will slow down so population growth can be curbed. We left some remnants of our previous attempt of an architecture including the idea of having an initial seed. 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. religion. 62 . wealth.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. the system clock will be sped up to repopulate the population. The subsystems are described more fully below in our “Archstudio Subsystems and Module” section. and each candidate is assigned a final "score". a update status subsystem and a event bus subsystem. a candidate subsystem. marriage and children restrictions (only couples in the beta. Our system clock is based on checking the amount of total population every year. if the population is increasing more than normal it will enter into fast or very fast. This dynamic clock would serve to regulate any depopulation or overpopulation scenarios. 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. cultural. our "Compatibility Score Algorithm" is run. At that point. Candidates who have the most similar scores for each other are most likely to get married to each other. These filters are race. reputation. age brackets.

” We then ran a use-case analysis based on our second architecture in order to see how the architecture fit into our design. We felt that adding a client component to the business logic server would make our system more usable. we felt that adding another server to act as a client would offload some processing power thus making our business logic server more reliable. This is both burdensome and cumbersome and impedes greatly on usability. The second most important quality attribute we wanted to address dealt with usability.Figure 2 – Second Architecture Design In our first architecture. because both maintainability and portability are low on our priorities. 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). this modification to our system was made. 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. 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. However. The most important quality attribute we have is reliability and we felt that system like this would suffer in reliability. “To solve both issues we added a client-server architecture to our pipe and filter system and ended up with a 3 tiered architecture. 63 . Thus. The reason we felt reliability was threatened was because literally every transaction was taking place on our business logic server.

System Administrator 3-tier client-server Pipe and Filter 3-tier client-server 3-tier client-server 3-tier client-server Pipe and Filter 6 7 8 Check up to 2nd System cousin 3-tier client-server 9 Compatibility Score Algorithm System Pipe and Filter 10 System selfrepair Administrator 3-tier client-server 64 . To determine if the two candidates are eligible for marriage. To check system performance. To effectively control population size. To generate a love/compatibility score for each candidate. To add a new entry to the database. System Administrator. System System PURPOSE Requesting to view an individual’s information. To start the system To show the most current information in real-time.Use Case Analysis of Second Architecture Design USE CASE 1 DESCRIPTION View a person ACTOR(S) Administrator. ARCHITECTURE TYPE 3-tier client-server 2 Determine a person's relationship to another person Dynamically adjust population control System startup Update the database Add a person System test Pipe and Filter 3-tier client-server 3 System Pipe and Filter 4 5 Administrator Administrator. System checks to see if a male and female are potential marriage candidates. To remove all faults from the system.

Further. 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). They would essentially work the same but they would basically split up the work in half. namely our business logic server. we added a distributed feature to our 3-tiered architecture. 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. performance and thus functionality. This helped the system be both more efficient and more functional.FINAL REVISED ARCHITECTURE DESIGN Figure 3 . we felt that having our system rely just on one main database could possibly be a bottleneck and also create functionality issues. If there are two databases. We felt that our system was still not efficient enough because there was far too much emphasis and processing power on one server. “To resolve both efficiency and functionality issues. With respect to functionality. The business logic server was split into two distributed servers as was the database server. However.” 65 . To address efficiency we felt that we needed to split up the business logic server into two separate business logic servers.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. 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 so many physical components would be very hard to keep portable. Further. A system with more servers is harder to test for and keep well maintained (such as running diagnostics and weekly performance testing). 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. we felt that having two database servers instead of one would create higher security.

two backup) and four database servers (two primary. As before. Thus. After modifying our architecture. In addition to those. the cost that this would have on our overall system would be again that both maintainability and portability would be harder to implement. “To achieve extreme reliability we added fault tolerance to our existing 3-tiered architecture. 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. maintainability and portability. 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. 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”. Each business logic server was cloned and each database server was also cloned. This helped guarantee our system would be reliable and fault tolerant. There were now four total business logic servers (two primary. ” 66 . we felt that our system needed redundancy to make our system truly fault tolerant and therefore extremely reliable. we then ran a use-case analysis based on our final revised architecture and was satisfied with our final architecture. However. two backup). we still felt the lingering issue that our system was still not reliable enough. performance. What if any of our seemingly many servers failed? Our system which required such high reliability would come to a spectacular fault.Figure 4 – Final Revised Architecture Design After our third architecture. This task was accomplished by adding a “clone” of each server at every point in our architecture.

System Administrator 6 To show the most current information in real-time. To effectively control population size. To remove all faults from the system. System checks to see if a male and female are potential marriage candidates. To start the system ARCHITECTURE TYPE Distributed 3-tier client server Pipe and Filter 2 Determine a person's relationship to another person Dynamically adjust population control System startup Distributed 3-tier client server 3 System Pipe and Filter 4 Administrator Distributed 3-tier client server w/ fault tolerance Pipe and Filter 5 Update the database Add a person Administrator. To generate a love/compatibility score for each candidate.Use Case Analysis of Final Revised Architecture Design USE CASE 1 DESCRIPTION View a person ACTOR(S) Administrator. To check system performance. System System PURPOSE Requesting to view an individual’s information. To add a new entry to the database. 7 System test Distributed 3-tier client server Client-server Distributed 3-tier client server Distributed 3-tier client server w/ fault tolerance Pipe and Filter 8 Check up to 2nd System cousin Distributed 3-tier client server Pipe and Filter 9 Compatibility Score Algorithm System 10 System selfrepair Administrator Distributed 3-tier client server w/ fault tolerance 67 . System Administrator. To determine if the two candidates are eligible for marriage.

68 . the male process subsystem and the female process subsystem.ARCHSTUDIO SUBSYTEMS AND MODULES Initial Startup Subsystem This is the initial startup subsystem. The male and female process subsystem are explained below. It contains the initial startup module.

the 9 filters that feed into the CSA . individuals are assigned a “score” from the CSA which determines the likelihood of marrying someone similar to you. the individuals are filtered through 9 different filters. After all the filtering. After this. The eligible individuals are then ranked according to likelihood of marriage and child rearing. the age ranking. the age bracket filter. Following that. 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.Male Process Subsystem Female Process Subsystem Both male and female subsystems contain five modules: the input of the initial seed. 69 . they are put into the “candidate” bucket and become eligible to be married.

This contains the marriage module and children module. The candidate module collects all the eligible candidates that can and will get married. Family Subsystem This is the family subsystem.Candidate Subsystem This is the candidate subsystem. Any changes in the population via childbirth will be updated into the database. The set of associations are then updated again when they are checked for second cousin status. Here the candidates who are the most compatible (as determined by the CSA) will get married. The people in the married bucket may have as many children as they want. This contains the candidate module and the 2nd cousin module. their marital status will be updated and finally they will be placed in the “married’ bucket. 70 . The set of associations are made between all eligible candidates.

For every minute that passes in “real-time”. If there is a sharp imbalance (hyper growth or massive extinction). the clock speed is set to normal which assumes that the rate of population fits within the normal category. the system clock will automatically adjust to accommodate fast or slow growth in the population. 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. 71 .Population Subsystem This is the population subsystem. The system will check for population differences dynamically by comparing the number of people on the island to the previous year. the system will age the population by one year. Initially.

living check and clock check modules. This includes whether or not an individual is already married. 72 . The update status subsystem accounts for the current status of any and all individuals in the system. It contains the marital status check.Update Status Subsystem This is the update status subsystem. whether or not they are alive and it checks the clock to see what speed to operate at.

It contains the queries database module. update database module. the update status subsystem. This subsystem is responsible for all events the system is generating. the SOA module. one year older module and the set clock speed module. the queries database 73 . update SOA module.Event Bus Subsystem This is the event bus subsystem.

Inside of the data table. the two parents are pointed to and the children and spouse are made null initially. the two parents of the person. the data is stored in the form of Person records containing information about the person: such as identification number. To represent the structure of the parents. and spouse: pointers to those records are used as in the next figure. From this class description. the children. When new Person data comes into the system. Once the identification number is generated. 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. the implementation design of the Person object can be defined relatively simple. the identification number is computer generated unique hashed value for the record. 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. construction of the tree is fairly simple. The following diagram is an example set of connected Person objects: Figure 2: An example set of connected Person objects. children. 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. and a possible spouse.

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

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. This property is the inverse of the property hasParent. All other properties. about a Person. In Protégé. the definition of Person is as follows: Figure 4: Definition of Person Object and Instances in Protégé 76 . 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.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.

hasGrandChild: The grandchild property is the inverse of the hasGrandParent property that finds the children’s children. hasSibling: This property is found by looking at the parent’s children. If a person X has a child Y. hasGreatGrandChild: The hasGreatGrandChild property is the inverse of the hasGreatGrandParent. 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 hasParent hasSibling hasGrandParent hasGrandChild hasGreatGrandParent hasGreatGrandChild hasFirstCousin hasSecondCousin hasAncestor D/R Person Person Person Person Person Person Person Person Person Chain Property inverse of hasChild hasParent o hasChild hasParent o hasParent inverse of hasGrandParent hasParent o hasParent o hasParent inverse of hasGreatGrandParent hasParent o hasSibling o hasChild hasGrandParent o hasSibling o hasGrandChild hasParent o hasParent o hasParent hasParent o hasParent hasParent hasChild o hasChild o hasChild hasChild o hasChild hasChild hasDescendent o has Ancestor hasAncestor o hasDescendent isRelatedTo hasDescendent Person isRelatedTo CantMarry Person Person Table 1: Object Properties using a Chain Property hasPatrent: This property is the inverse of the hasChild object property. the children’s of the children’s children is looked at. hasGrandParent: The grandparent property is found by looking for the parent’s parents. then Y has a parent X. 77 .PROTÉGÉ PROPERTIES The inferred object properties are items that must be determined from the asserted properties. the parent’s of the parent’s parents is looked at. hasGreatGrandParent: In the hasGreatGrandParent property.

the descendents of the people up to the greatgrandparent level cannot also be married. From the greatgrandparent level.hasFirstCousin: The property of hasFirstCousin finds the children of the sibling of the parent. that person could be related up to the greatgrandparent level. From the greatgrandparent level. isRelatedTo: To be related to a person. the descendents of the people up to the greatgrandparent level also will be related. CantMarry: To not marry a person. 78 . hasAncestor: The ancestor of a person is found by an object property hasParent and hasParent and hasParent. be an ancestor. be an ancestor. that person cannot be related up to the greatgrandparent level. hasSecondCousin: The property of hasSecondCousin finds the grandchildren of the sibling of the grandparent. or be a descendent. or be a descendent. hasDescendent: The descendent of a person is found by an object property hasChild and hasChild and hasChild.

Each of these object properties can be defined using one or more of the following characteristics: functional (F). and hasGreatGrandChild all use transitivity). Siblings. hasGreatGrandParent. symmetric (S). First Cousins. reflexive (R). Symmetric properties are ones where one direction means that the other direction must be included. inverse functional (I). and Second Cousins all use symmetry when describing these relationships. transitive (T). x x x x x x x F I T S A R X X X x x x x x x x x x 79 . asymmetric (A). hasGrandChild. and ir-reflexive (X). a must also be in that set. Finally all of the properties are ir-reflexive because people cannot declare themselves as any of these object properties. for instance if (a. b) is in the set then (b. The following figure contains the type of characteristic that each object property has: Object Properties hasChild hasParent hasSibling hasGrandParent hasGrandChild hasGreatGrandParent hasGreatGrandChild hasFirstCousin hasSecondCousin hasAncestor hasDescendent isRelatedTo CantMarry x x x 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.

The property chain for the hasSibling operation is written in Protégé as shown below: Figure 5: Property Chain for hasSecondCousin Object Property Figure 6: Property Chain for hasFirstCousin Object Property 80 .

Figure 7: Property Chain for isRelatedTo Object Property Figure 8: Property Chain for hasSibling Object Property 81 .

Figure 9: Property Chain for hasGrandParent Object Property Figure 10: Property Chain for hasGreatGrandParent Object Property Figure 10: Property Chain for hasGreatGrandParent Object Property 82 .

supposed that A is the instance of interest. If hasChild is called on A. then it tries to infer this information: A hasGrandParent (?) A hasParent (?) hasParent (?) To solve this. 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. then it should return B (each of the black lines represent the hasChild object property) object property hasParent is invrerse property of hasChild . hasFirstCousin. A hasFirstCousin (?) 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. Taking a much harder example. If hasGrandParent is called on A. the property again evaluates similar to that of the hasGrandParent Property. set of question marks. A cannot be in the set of A hasGrandParent A.

F) hasChild (?) A hasParent B hasParent C hasChild (B. The key to the hasFirstCousin is that hasSibling relationship is ir-reflexive in order to avoid hasChild from returning a (B. the system returns: A hasParent B hasParent C hasChild F hasChild G A hasFirstCousin G 84 . Once the ir-reflexive property is used on hasSibling and hasFirstCousin.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.G) Notice from this chain property.B) relationship which is reflexive.E. 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.F) hasChild (A.

PROTÉGÉ DEMONSTRATION Using the tree from the previous figure. 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. all of the information was put in and inputted for each of the different instances. which is of type Person. The following capture displays the information about the instance AA (which is disjointed and distinct from all of the other instances in the class Person): Figure 12: Definition of Instance AA in Protégé 85 .

the result for the query shown for instance AA which is in the following figures: Figure 13: Run of query hasParent on instance AA Figure 14: Run of query isRelatedTo on Instance AA 86 .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.

Figure 15: Run of query hasGrandParent on Instance AA Figure 16: Run of query hasGreatGrandParent on Instance AA 87 .

Thing is universal as all objects can be declared as things and Person is a derived concept from Thing that is a subset of the Thing. Figure 17: OWLViz Description of Person 88 .OWLVIZ DEMONSTRATION Protégé also has the ability to show by explicit and inference methods on how objects are related together. only two objects are considered: Thing and Person. The OWLViz Description shows all of the objects in an “is-a” relationship and for the class design.

owl#Son SubClassOf(Son Male) // Object property: http://www.owl#Uncle SubClassOf(Uncle Male) // Class: http://www.owl#Father SubClassOf(Father Male) // Class: http://www.org/ontologies/marriege.org/2002/07/owl#>) Ontology(<http://www.owl#GreatGrandFather SubClassOf(GreatGrandFather Male) // Class: http://www.org/ontologies/marriege.owl#Male SubClassOf(Male Person) DisjointClasses(Male Female) // Class: http://www.owl#Mother SubClassOf(Mother Female) // Class: http://www.semanticweb.semanticweb.owl#Daughter SubClassOf(Daughter Female) // Class: http://www.semanticweb.semanticweb.semanticweb.owl#Female SubClassOf(Female Person) DisjointClasses(Female Male) // Class: http://www.org/1999/02/22-rdf-syntax-ns#>) Namespace(owl=<http://www.org/ontologies/marriege.owl#Aunt SubClassOf(Aunt Female) // Class: http://www.org/ontologies/marriege.PROTÉGÉ CODE Namespace(=<http://www.w3.org/ontologies/marriege.org/2001/XMLSchema#>) Namespace(rdfs=<http://www.semanticweb.w3.owl#Brother SubClassOf(Brother Male) // Class: http://www.org/ontologies/marriege.org/2000/01/rdf-schema#>) Namespace(rdf=<http://www.org/ontologies/marriege.owl#hasAncestor TransitiveObjectProperty(hasAncestor) ObjectPropertyDomain(hasAncestor Person) ObjectPropertyRange(hasAncestor Person) 89 .org/ontologies/marriege.semanticweb.org/ontologies/marriege.org/ontologies/marriege.semanticweb.owl#GreatGrandMother SubClassOf(GreatGrandMother Female) // Class: http://www.org/2002/07/owl#Thing // Class: http://www.org/ontologies/marriege.owl#>) Namespace(owl2xml=<http://www.org/ontologies/marriege.semanticweb.owl> // Class: http://www.semanticweb.owl#>) Namespace(xsd=<http://www.semanticweb.w3.semanticweb.semanticweb.owl#Sister SubClassOf(Sister Female) // Class: http://www.semanticweb.semanticweb.org/ontologies/marriege.owl#GrandMother SubClassOf(GrandMother Female) // Class: http://www.w3.org/ontologies/marriege.semanticweb.semanticweb.semanticweb.w3.org/2006/12/owl2-xml#>) Namespace(marriege=<http://www.owl#Person SubClassOf(Person owl:Thing) // Class: http://www.org/ontologies/marriege.org/ontologies/marriege.w3.org/ontologies/marriege.org/ontologies/marriege.owl#GrandFather SubClassOf(GrandFather Male) // Class: http://www.semanticweb.org/ontologies/marriege.

semanticweb.org/ontologies/marriege.org/ontologies/marriege.owl#isRelatedTo TransitiveObjectProperty(isRelatedTo) ObjectPropertyDomain(isRelatedTo Person) ObjectPropertyRange(isRelatedTo Person) // Object property: http://www.owl#hasGrandParent InverseObjectProperties(hasGrandParent hasGrandChild) TransitiveObjectProperty(hasGrandParent) ObjectPropertyDomain(hasGrandParent Person) ObjectPropertyRange(hasGrandParent Person) // Object property: http://www.org/ontologies/marriege.owl#hasDescendent TransitiveObjectProperty(hasDescendent) ObjectPropertyDomain(hasDescendent Person) ObjectPropertyRange(hasDescendent Person) // Object property: http://www.semanticweb.semanticweb.semanticweb.owl#hasGreatGrandChild TransitiveObjectProperty(hasGreatGrandChild) ObjectPropertyDomain(hasGreatGrandChild Person) ObjectPropertyRange(hasGreatGrandChild Person) // Object property: http://www.owl#hasSibling SymmetricObjectProperty(hasSibling) ObjectPropertyDomain(hasSibling Person) ObjectPropertyRange(hasSibling Person) // Object property: http://www.org/ontologies/marriege.semanticweb.org/ontologies/marriege.owl#hasSecondCousin SymmetricObjectProperty(hasSecondCousin) ObjectPropertyDomain(hasSecondCousin Person) ObjectPropertyRange(hasSecondCousin Person) // Object property: http://www.org/ontologies/marriege.org/ontologies/marriege.semanticweb.semanticweb.org/ontologies/marriege.semanticweb.owl#hasParent InverseObjectProperties(hasChild hasParent) IrreflexiveObjectProperty(hasParent) ObjectPropertyDomain(hasParent Person) ObjectPropertyRange(hasParent Person) 90 .owl#hasGreatGrandParent TransitiveObjectProperty(hasGreatGrandParent) ObjectPropertyDomain(hasGreatGrandParent Person) ObjectPropertyRange(hasGreatGrandParent Person) // Object property: http://www.owl#hasFirstCousin SymmetricObjectProperty(hasFirstCousin) ObjectPropertyDomain(hasFirstCousin Person) ObjectPropertyRange(hasFirstCousin Person) // Object property: http://www.org/ontologies/marriege.// Object property: http://www.org/ontologies/marriege.semanticweb.owl#hasGrandChild InverseObjectProperties(hasGrandParent hasGrandChild) TransitiveObjectProperty(hasGrandChild) ObjectPropertyDomain(hasGrandChild Person) ObjectPropertyRange(hasGrandChild Person) // Object property: http://www.semanticweb.org/ontologies/marriege.semanticweb.owl#hasChild InverseObjectProperties(hasChild hasParent) IrreflexiveObjectProperty(hasChild) ObjectPropertyDomain(hasChild Person) ObjectPropertyRange(hasChild Person) // Object property: http://www.

semanticweb.semanticweb.semanticweb.org/ontologies/marriege.org/ontologies/marriege.org/ontologies/marriege.owl#CantMarry TransitiveObjectProperty(CantMarry) ObjectPropertyDomain(CantMarry Person) ObjectPropertyRange(CantMarry Person) // Data property: http://www.org/ontologies/marriege.owl#EE ClassAssertion(EE Person) ObjectPropertyAssertion(hasChild EE EA) ObjectPropertyAssertion(hasChild EE EB) // Individual: http://www.owl#AA ClassAssertion(AA Person) ObjectPropertyAssertion(hasChild AA BB) ObjectPropertyAssertion(hasChild AA CC) // Individual: http://www.semanticweb.semanticweb.semanticweb.owl#SS ClassAssertion(SS Person) ObjectPropertyAssertion(hasChild SS SB) 91 .owl#hasMaritalStatus DataPropertyDomain(hasMaritalStatus Person) DataPropertyRange(hasMaritalStatus xsd:string) // Individual: http://www.owl#VV ClassAssertion(VV Person) ObjectPropertyAssertion(hasChild VV VB) ObjectPropertyAssertion(hasChild VV VA) // Individual: http://www.org/ontologies/marriege.owl#BB ClassAssertion(BB Person) ObjectPropertyAssertion(hasChild BB EE) ObjectPropertyAssertion(hasChild BB DD) // Individual: http://www.owl#DA ClassAssertion(DA Person) // Individual: http://www.semanticweb.semanticweb.org/ontologies/marriege.owl#SB ClassAssertion(SB Person) // Individual: http://www.org/ontologies/marriege.owl#GB ClassAssertion(GB Person) // Individual: http://www.owl#UU ClassAssertion(UU Person) ObjectPropertyAssertion(hasChild UU UB) ObjectPropertyAssertion(hasChild UU UA) // Individual: http://www.org/ontologies/marriege.owl#FA ClassAssertion(FA Person) // Individual: http://www.org/ontologies/marriege.org/ontologies/marriege.semanticweb.semanticweb.owl#hasSpouse SymmetricObjectProperty(hasSpouse) ObjectPropertyDomain(hasSpouse Person) ObjectPropertyRange(hasSpouse Person) // Object property: http://www.org/ontologies/marriege.org/ontologies/marriege.semanticweb.org/ontologies/marriege.semanticweb.semanticweb.semanticweb.semanticweb.// Object property: http://www.org/ontologies/marriege.owl#hasAge DataPropertyDomain(hasAge Person) DataPropertyRange(hasAge xsd:short) // Data property: http://www.owl#hasGender DataPropertyDomain(hasGender Person) DataPropertyRange(hasGender xsd:string) // Data property: http://www.org/ontologies/marriege.

semanticweb.org/ontologies/marriege.owl#QQ ClassAssertion(QQ Person) ObjectPropertyAssertion(hasChild QQ SS) ObjectPropertyAssertion(hasChild QQ TT) // Individual: http://www.semanticweb.semanticweb.owl#CC ClassAssertion(CC Person) ObjectPropertyAssertion(hasChild CC GG) ObjectPropertyAssertion(hasChild CC FF) // Individual: http://www.owl#RR ClassAssertion(RR Person) ObjectPropertyAssertion(hasChild RR VV) 92 .owl#UB ClassAssertion(UB Person) // Individual: http://www.owl#PP ClassAssertion(PP Person) ObjectPropertyAssertion(hasChild PP QQ) ObjectPropertyAssertion(hasChild PP RR) // Individual: http://www.semanticweb.org/ontologies/marriege.owl#FB ClassAssertion(FB Person) // Individual: http://www.semanticweb.owl#GA ClassAssertion(GA Person) // Individual: http://www.owl#TB ClassAssertion(TB Person) // Individual: http://www.semanticweb.owl#DB ClassAssertion(DB Person) // Individual: http://www.ObjectPropertyAssertion(hasChild SS SA) // Individual: http://www.owl#GG ClassAssertion(GG Person) ObjectPropertyAssertion(hasChild GG GA) ObjectPropertyAssertion(hasChild GG GB) // Individual: http://www.semanticweb.org/ontologies/marriege.semanticweb.semanticweb.owl#EA ClassAssertion(EA Person) // Individual: http://www.owl#TA ClassAssertion(TA Person) // Individual: http://www.org/ontologies/marriege.org/ontologies/marriege.semanticweb.semanticweb.semanticweb.org/ontologies/marriege.owl#VB ClassAssertion(VB Person) // Individual: http://www.org/ontologies/marriege.org/ontologies/marriege.org/ontologies/marriege.org/ontologies/marriege.semanticweb.org/ontologies/marriege.owl#EB ClassAssertion(EB Person) // Individual: http://www.semanticweb.owl#SA ClassAssertion(SA Person) // Individual: http://www.org/ontologies/marriege.owl#VA ClassAssertion(VA Person) // Individual: http://www.org/ontologies/marriege.org/ontologies/marriege.org/ontologies/marriege.semanticweb.semanticweb.owl#UA ClassAssertion(UA Person) // Individual: http://www.semanticweb.org/ontologies/marriege.semanticweb.org/ontologies/marriege.org/ontologies/marriege.owl#DD ClassAssertion(DD Person) ObjectPropertyAssertion(hasChild DD DA) ObjectPropertyAssertion(hasChild DD DB) // Individual: http://www.

org/ontologies/marriege.net 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.1042) http://owlapi.2.1.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.sourceforge.

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. which has to be a woman. With the class diagram above. mother : lone Woman } sig Woman extends Person 94 . Next we defined spousal relationship so a Husband and a Wife attribute were added to the Man and Woman class respectively. a woman can have at most 1 husband. Man and Woman classes: abstract sig Person { father : lone Man. we can add more constraints for the Father and Mother attributes of the Person class by specifying the gender of each attribute. which has to be a man.PROVING THE DESIGN INITIAL ALLOY DESIGN WITH DEFINITION We began our Alloy model with an abstract Person class. Father has to be a Man and Mother has to be a Woman. which has two attributes: Father and Mother. and a man can have at most 1 wife. Then we added two more classes Man and Woman which extended the abstract Person class. that is. Now that we constrain all Persons have to be of male or female gender. Provided below is our initial Alloy code with Person.

fact spousal_Relationship { husband =~ wife } fact no_Self_Ancestor { no x : Person | x in x. 95 .mother. then that woman is your wife. spousal_Relationship: This fact states that if you are the hushand of some woman.wife = x.husband in w. no_Self_Ancestor: This will make sure that no person can be his or her own ancestor.mother) } fact noIncestMarriage { no m : Man | m.father) and (x.wife in m.father.^(father + mother) } fact parents_Relationship { all x : Person | #x.{ husband : lone Man } sig Man extends Person { wife : lone Woman } At the very next stage. We defined a set of four facts that help detect illegal marriages.(father + mother) = 2 => (x.^(father) } Below is the complete description of each fact that is mentioned above and also their usefulness for our system.(^mother) no w : Woman | w.husband = x. 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.

parents_Relationship: This fact states that for every person who has two parents (one mother and one father). This situation is true if both person have same great-grand parent named z. y.(father + mother). isSecondCousin: This predicate determines if person x is second cousin of peson y.(father + mother).(father + mother)) = none } pred isGreatGrandParent (x.y & z must be distinct and their ancestors are disjoint. y] and (x. x. y: Person) { x in y. y: Person) { x in y. y: Person) { some z : Person | isThreeDistinctNodes[x.(father + mother) } pred isThreeDistinctNodes (x. their parents must be spouses of each other. Above mentioned facts must hold in order for our logic to work properly.(father + mother). we need to define predicates that determine a person’s relationship to another.(father + mother)) & (y.(father + mother). At the next step. noIncestMarriage: This fact is to make sure that no man or woman is allowed to marry their own ancestors. 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.(father + mother) } pred isParent(x. z] and isGreatGrandParent[z. 96 . y: Person) { x in y.(father + mother) } pred isGrandParent (x. pred isSecondCousin(x.(father + mother) + y. y.(father + mother).(father + mother) + x. x] and isGreatGrandParent[z.

If y’s parents include x then this statement is true. In case x is included in y’s parents of parents of parents. 97 . isParent: This predicate determines if person x is one of the parent of person y.isGreatGrandParent: This predicate determines if person x is great grand parent of person y. isThreeDistinctNodes: This will confirm if three person are same or not. this statement is true.

This problem was exposed during the sample run of our program code for 14 persons. 98 . we add a new fact to our system. Therefore in order to remove this error. we can see that Woman 0 and Man 3 has an incest marriage because Woman0 is also Man3’s great aunt.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. In the Alloy-generated diagram below.

mother) = 1 } fact spousal_Relationship { husband =~ wife } fact no_Self_Ancestor { no x : Person | x in x.mother) } fact noIncestMarriage { no m : Man | m.EVALUATION OF FINAL ALLOY DESIGN abstract sig Person { father : lone Man.wife in m.^(father + mother) } fact parents_Relationship { all x : Person | #x.husband = x.husband in w.father) and (x.wife = x. mother : lone Woman } sig Woman extends Person { husband : lone Man } sig Man extends Person { wife : lone Woman } fact haveParents { all x : Person | #(x.^(father) } pred isSecondCousin(x.(father + mother) = 2 => (x.(^mother) no w : Woman | w.mother.father) = 1 and #(x.father. y: Person) { some z : Person | 99 .

(father + mother). y: Person) { x in y. Predicate may be inconsistent. and Alloy Analyzer said “No instance found”.(father + mother)) == none } pred isGreatGrandParent (x. which means no counterexample was found in our model.(father + mother) + y.isThreeDistinctNodes[x.(father + mother)) & (y. y: Person) { x in y. 56737ms.(father + mother).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. Executing "Run isSecondCousin for 18 Person" Solver=sat4j Bitwidth=4 MaxSeq=4 Symmetry=20 100 .(father + mother) } pred isParent(x.. z: Person) { (x != y) and (x != z) and (y != z) } run isSecondCousin for 14 Person We ran our final Alloy design with 14 person. y] and (x. y. 854 primary vars. y: Person) { x in y.(father + mother). 608ms. Below are a few sample Alloy runs: Alloy Analyzer 4. x] and isGreatGrandParent[z. 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. z] and isGreatGrandParent[z. No instance found.(father + mother) + x. 166209 clauses.(father + mother). as per the professor’s recommendation. 437ms..(father + mother). 1104 primary vars. Executing "Run isSecondCousin for 16 Person" Solver=sat4j Bitwidth=4 MaxSeq=4 Symmetry=20 77376 vars.(father + mother) } pred isGrandParent (x. y. 115651 clauses.1. Solving.(father + mother) } pred isThreeDistinctNodes (x.

Solving. 1155ms. Also the Eclipse plugin version does not work! We had to resort to a standalone Alloy version (v 4. 267222 clauses.7).. Alloy Analyzer seems to be stuck at “Solving” state when the model scope increased beyond 15 Persons.1. 1386 primary vars. 101 . so for our model it is best to be executed with 14 Person which took about 4 to 6 seconds.126045 vars..

we did some code cleanup and.father.wife = x. 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) = 1} /* If you are the husband of some woman. two unused predicates isGrandParent() and isParent() were removed. as a result.father) = 1 and #(x. their parents must be spouses of each other */ fact parents_Relationship { all x : Person | #x.father) and (x. which has to be a man */ sig Woman extends Person { husband : lone Man } /* A man can have at most 1 wife.^(father + mother)} /* For every person who has 2 parents (1 mother and 1 father).husband = x.(father + mother) = 2 => (x. 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.mother. 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. mother : lone Woman} /* A woman can have at most 1 husband.DYNALLOY Original Alloy Code Before converting Alloy code to DynAlloy code.mother)} 102 .

we just need to define 1 program with supporting actions for DynAlloy code. Programs can contain a combination of actions and other programs. and programs we need for DynAlloy: /* This predicate will check to see if three given people are all different individuals */ pred isThreeDistinctNodes (x. and since our original Alloy code was simple enough.wife in m.(father + mother). Using DynAlloy syntax.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.(father + mother) } /* This predicate checks if two given persons have common ancestors */ pred noCommonAncestor(x. z: Person] { pre { none[] } post { isThreeDistinctNodes[x. y. actions.(father + mother). y.(^mother) no w : Woman | w. y: Person) { x in y.(father + mother).(father + mother)) & (y. we will now add actions and programs to the final version of our Alloy code.(father + mother) + y. Actions are easy to define./* No man or woman is allowed to marry their own ancestors */ fact noIncestMarriage { no m : Man | m.(father + mother)) == none} /* This predicate will check to see if two given people are different individuals */ pred isTwoDistinctNodes (x. z] }} 103 . The following defines all the predicates. y. Every action has a pre-condition and post-condition which ensure that certain logic must hold before and after the action execution. y: Person) { (x.(father + mother) + x.(father + mother). z: Person) { (x != y) and (x != z) and (y != z)} /* This predicate will detect great grandparent relationship */ pred isGreatGrandParent (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. Predefined Alloy predicates are used for these conditions.

action is_Great_Grand_Parent[x. is_Great_Grand_Parent[z. x]. is_Great_Grand_Parent[z. y] }} program is_Second_Cousin[x. y] } post { isGreatGrandParent[x. y: Person] var [z: Person] { is_Three_Distinct_Nodes[x. z]. y] } 104 . y: Person] { pre { isTwoDistinctNodes[x. y] }} action no_Common_Ancestor[x. no_Common_Ancestor[x. y] } post { noCommonAncestor[x. y]. y. y: Person] { pre { isTwoDistinctNodes[x.

DynAlloy Translation Next. mother : lone Woman} /* A woman can have at most 1 husband. which has to be a man */ sig Woman extends Person { husband : lone Man } 105 . 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. we will use the DynAlloy4 Translator tool to translate the newly derived DynAlloy code into Alloy code.

(father + mother)) & (y./* A man can have at most 1 wife.(father + mother) + y.(father + mother).(father + mother). their parents must be spouses of each other */ fact parents_Relationship { all x : Person | #x.(father + mother).husband in w.(father + mother) = 2 => (x.husband = x. y: Person) { (x.(father + mother).^(father)} /* This predicate will check to see if three given people are all different individuals */ pred isThreeDistinctNodes (x. 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.mother)} /* No man or woman is allowed to marry their own ancestors */ fact noIncestMarriage { no m : Man | m. y.wife = x.father.(father + mother)) == none} 106 .wife in m.father) = 1 and #(x. z: Person) { (x != y) and (x != z) and (y != z)} /* This predicate will detect great grand parent relationship */ pred isGreatGrandParent (x.(^mother) no w : Woman | w.mother.mother) = 1} /* If you are the hushand of some woman.(father + mother) } pred noCommonAncestor(x.^(father + mother)} /* For every person who has 2 parents (1 mother and 1 father).father) and (x. y: Person) { x in y. 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 + mother) + x.

The translated Alloy code using DynAlloy4 Translator tool is longer. Predicate may be inconsistent.y_0. 115657 clauses.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.z_0]} pred no_Common_Ancestor[x_0: Person.y_0]} pred is_Great_Grand_Parent[x_0: Person.z_0] and is_Great_Grand_Parent[z_0.z_0: Person]{none[] and isThreeDistinctNodes[x_0. Perhaps I need to play with DynAlloy more in my own time in order to find out its true potential. I do not find it being useful since the Alloy code must be done before DynAlloy code can be written. 795ms. DynAlloy Evaluation DynAlloy is an extension of the Alloy tool.y_0: Person]{isTwoDistinctNodes[x_0. no instance or counter example was found in our design.y_0] and noCommonAncestor[x_0. but it is easier to understand because the isSecondCousin() predicate is now broken down to several predicates. As a result.y_0: Person./* This predicate will check to see if two given people are different individuals */ pred isTwoDistinctNodes (x. 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. 107 .y_0] and no_Common_Ancestor[x_0.y_0] and isGreatGrandParent[x_0. 48906ms. 854 primary vars. 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]} pred is_Second_Cousin[x_0: Person.x_0] and is_Great_Grand_Parent[z_0. It has support for the creation of dynamic properties of a system using actions. I did not like the idea of adding a dummy predicate for the pre-condition when one is not needed.z_0: Person]{is_Three_Distinct_Nodes[x_0.y_0: Person.y_0: Person]{isTwoDistinctNodes[x_0. Even though DynAlloy forces us to simplify the original Alloy code.y_0. that is. However. No instance found. Programs are somewhat similar to functions or methods of conventional programming languages like Java because they can contain a set of statements. 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. DynAlloy actions and programs are fairly easy to work with.

Each block has many processes and sub processes or tasks or its sub tasks. as features and services got added in original architecture. All of these tasks were periodic. Following figure shows task precedence graph for Pipe and Filter architecture. We have our initial architecture as Pipe and Filter. In all architectures. we have four main subsystems which are further divided into 9 sub blocks. 108 . Here the nine tasks were addressed as T1 to T9. This is simple single processor architecture. Data Store is general database from where data or information is passed to entire system. Processor does scheduling of each task in system just to achieve load balancing.TIME SIMULATIONS CHEDDAR We used CHEDDAR tool to show time simulations and scheduling done on Population Simulation System (PSS). As it is clear Task T9 Is controller element and it represents clock for all architectures. Eventually. in CHEDDAR we have considered each block of our four sub system as a single task. All the tasks are rather independent to avoid situation of deadlocks. But for simplification. Thus we had nine tasks in all. In Pipe and Filter architecture we have considered a single processor which uses Pre-emptive Round Robin Scheduling scheme. As such each of tasks will change its operation.tiered Client Server with fault Tolerance. we came up with following three architectures which were 3-tiered Client Server. In our initial architecture. clock will be controlling element for all tasks. This is because the clock will dynamically adjust itself according to rate of population growth. Distributed 3tiered Client Server and finally the Distributed 3.

The processor schedules all tasks in Round-Robin scheduling scheme. All tasks are periodic so have period of 5 nsecs.Tasks Precedence Graph for Pipe and Filter Following figure shows Time scheduling done for major nine tasks of the system. 109 . For the simple Pipe and Filter architecture all the tasks are meeting their deadlines.

Following figure shows precedence graph for a 3-tiered client server. But in this new architecture we had a new aperiodic task T10 added to our system.Though this architecture was stable and scheduling and time simulations were successful. 110 . This task signifies the request coming from client end. Here came need to add a new architecture to our system. With a new aperiodic task system seemed little bit unstable. We thought of a basic 3tiered Client Server architecture to solve this problem. it would not suffice to increased number of queries to database or increased load on processor. gradually with time load on processor are bound to be increased. As this is Population Simulation System.

The periodic tasks have their period as 5 Nsecs.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. 111 . 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.

This is highly undesirable as we needed to introduce a new architecture. T2. Each of the processor has pre-emptive operation and uses different scheduling schemes according to nature of tasks it has to process. From Figure it appears that new task T10 seems to miss its deadline.With addition of a new aperiodic task the system becomes unstable. T3. Processor PRSR3 handle tasks T6. As such the next figure shows time precedence graph for our Distributed architecture. and T8 while PRSR4 handle only and most important controller task T9 which is clock element. The processors PRSR2 and 112 . For such real-time systems. T7. We introduced two new architectures Distributed 3-tiered Client Server and Distributed 3-tiered Client server with fault tolerance. In distributed architecture we have divided all the tasks among four processors. missing of deadline is highly undesirable. Thus we have processor PRSR1 scheduling and executing tasks T1. Increased number of processors aid in dividing stresses and achieve a better load balancing. Here CPU time is shared by all the tasks processed by the processor. Processor PRSR2 handles task T4 and T5. and T10. As such some of these tasks appear to miss their deadlines. Thus processor PRSR1 uses a scheduling scheme known as Time Sharing based on CPU usage.

Next figure shows a precedence graph for our distributed architectures. whose deadline is nearest. Here in distributed architecture as the business logic layer is distributed. Time Precedence Graph for Distributed Architectures: Next figures show time simulations done for distributed architectures.PRSR3 use a scheduling scheme Earliest Deadline first. Here we consider that Data_Store1 represents entire backup system for entire PSS system. The Processor PRSR4 again schedules its tasks based on Time Sharing done according to CPU usage. 113 . As it is clear from the simulation almost all of the tasks are handled gracefully. For such real-time systems the reliability and predictability are most important issues system has to handle. each processor can process and handle the tasks more efficiently. Deadline misses are reduced and system is more reliable predictable and highly efficient. Thus Increasing number of processor immensely helped in improving overall performance of system. Here the processor will process those tasks first.

114 .

115 . The prioritization of task was done according to the nature of tasks and the time the task is invoked in the system. Thus using CHEDDAR tool immensely helped us to identify considerations needed for such kind of real-time system. But just addition of one single aperiodic process to our system in 3-tiered Client Server made it unstable and thus highly unreliable. 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. 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. CHEDDAR Final Thoughts Looking back from the final version of architecture. Initially we modeled our initial architecture as a simple single processor which used a simple Round-Robin Scheduling.Thus scheduling simulations help in determining whether system is able to handle particular load and stress levels. This architecture was handling all tasks gracefully.

there are limitations and challenges to this software and the Protégé design. in defining the 2nd cousin constraint in a predicate formed language like Alloy or Prolog. Other than these small issues. one struggling problem that occurred in Protégé was the fact of an Unsupported Feature Exception with the ir-reflexive property. the system is much easier to write up than in Protégé.0 does not support ir-reflexive option in an object property that contains a property chain. As such we came up with several revisions to our original architecture. For instance. writing an intermediate node can be easily defined by using a random variable. But somehow we felt that the tool needs to have proper tutorials. The group got this error because Protégé 4. The first problem with Protégé is in determining relationships using intermediate nodes.CONCLUSION Archstudio Final Thoughts Initially we came up with a simple Pipe and Filter Architecture. We designed all architectures through Archstudio. In Alloy. Other feature where we had hard time was all editing or even adding features are given on right click. With this error. We got to learn this tool. But shortly we realized that a simple pipe and filter would not suffice to dynamic and near real-time nature of project. Archstudio is a good tool to design the basic architecture of the system. 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). Intermediate ones were a simple 3-tier client-server and a distributed 3-tier client server. There is no consistency in the number of recursive calls made in a recursive property chain. Also. 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). However. the recursive calls may possibly be 1 but in the next run the recursive calls may be 2. No random variables can be used. Protégé Final Thoughts Protégé can be very useful in determining and showing relationships between different classes of objects and their properties. In one run of the reasoner. Our final attempt was a Distributed 3-tier client server with fault tolerance. Designing all architectures in Archstudio was an enriching experience. however in Protégé intermediate nodes are only defined by their actions in the property chain. 116 . Another feature of Protégé that is interesting to note is the use of recursive property chains in the object properties. 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. Also. So the interface has no other feature to accommodate that.

However. 117 . our final working Alloy model consists of only 3 signatures. the only thing that was left was implementing it using the tools. Although daunting at first. Alloy’s syntax is difficult to understand. We learned how we get from use cases to running counter-examples in Alloy. Alloy documentation is also very good. Thank you very much for providing us weekly assistance and patience with our group. As a matter of fact. Alloy. While the architecture technically “worked” it wasn’t dynamic.85MB. 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. All in all. and all of our UML. 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. our design. 5 facts. we are really proud of the work we produced and felt that we learned a tremendous amount from this class. Weekly meetings and constantly talking about the requirements of the project helped us frame our second architecture (our first real architecture). 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. there are tutorials with sample code files for every version release.Alloy Final Thoughts Alloy Analyzer has a really small footprint so downloading and running the tool did not take much time at all. we learned what it meant to design software. Alloy's visualizer is great for generating a map of tree nodes that shows us what the error in our logic is. another two worked on Protégé and another two worked on Alloy. which we used to drive our architecture. Alloy Analyzer helped us prove our design logic for preventing people related to each other by 2nd cousin relationship or closer from getting married. All we knew in the beginning was that we had to use several tools including Archstudio. we were rather bewildered as how to approach this task. Two members of our group tackled Archstudio. We used the requirements to develop our use cases. Through it all. We weren’t sure what fit where and how one tool interrelated with the other. The size of the Alloy jar is only 3. Our first architecture was terrible as it was nothing but a system of if-then statements. These together added up to no more than 50 lines of code. At first. Once we had a clear idea of what we wanted to build. it wasn’t extensible and it didn’t really create a simulation. 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. and 4 predicates. Protégé. to see if we could create a society where one cannot marry their second cousin or anyone closer. Dynalloy and Cheddar. We learned what drove the whole process.

http://www.. 2005. http://www. http://protege. Seater R.sts. University of California.tu-harburg.com/blog/entry/title/introduction-to-semantic-web-vision-andtechnologies-part-5-building-owl-ontologies-using-protege-4-screencast/ Dashofy. R. Marcelo F. DynAlloy as a Formal Method for the Analysis of Java Programs.isr. C. http://www. Aguirre N. G.0.de/teaching/ws-07.08/LTOOAD/07-alloy-logic. C.P. Irvine.. H. Galeotti. 2005. A Practical Guide To Building OWL Ontologies Using Protégé 4 and CO-ODE Tools. C. http://www. M.semanticfocus. Archipelago: ArchStudio’s Graphical Editor.. http://www. Johnson.edu/~hasuncio/classes/in4matx119/HelloWorldTutorial.pdf. page 57-60.html. Horridge.. Galeotti. pages 249-260.L..edu/%7Ehasuncio/prospective_rules2.uci. DynAlloy: Upgrading Alloy with actions (Extended Abstract).org/resources/tutorials/ProtegeOWLTutorial-p4. page 442-450.REFERENCES ArchStudio 4: Hello World Tutorial.. Pombo.ics. J.. 118 . J. E. Aguirre N. International Workshop on Applications of Kleene Algebra.uci. Drummond... Protege-OWL Tutorial. Dennis. 8th International Protege Conference.isr.uci.edu/conference/2005/slides/T2_OWLTutorialI_Drummond_final. 1995.. DynAlloy: Upgrading Alloy with actions.. Conference on Relational Methods in Computer Science (RelMiCS) . Irvine. Marcelo F.P. University of Irvine. ICSE 2005: 27th International Conference on Software Engineering. N. Prospective Rules. J.P. 2007. Helm. A Practical Guide to Building OWL Ontologies Using Protégé 4.pdf Asuncion. J.pdf Gamma. 2006. Vlissides.3nd. University of California. LLC. 2005. Burleson Technology Group.pdf. Knublauch. Volume 227.. Galeotti.mp4 Burleson.. R. M. Horridge M. FM 2006 Alloy: Intro and Login. Frias. Design Patterns: Elements of Reusable ObjectOriented Software. Proceedings of the 8th. Pombo.co-ode. E.L. H.edu/projects/archstudio/archipelago-overview. http://www. Software Engineering Techniques: Design for Quality.stanford. 2006.

L.ppt Wong. Krikorian. Nana.ac. Dennis. A Comparison of Object Modeling Notations: Alloy. F. E.ecs.mit.edu/alloy4/tutorial4/ Singhoff F.fr/~singhoff/cheddar/ug/cheddar-r2.pdf Seater.. D.. Scheduling and Memory requirements analysis with AADL.php 119 . Cheddar Release 2.univ-brest.pdf Taylor. Legrand J. http://people.. Cheddar : a Flexible Real Time Scheduling Framework. Tutorial for Alloy Analyzer 4.uci.pdf. 2008.. University of California.fr/~singhoff/cheddar/ Singhoff F.edu/dnj/talks/re05-tutorial/alloy-90. http://beru. Tayeb.pdf Singhoff.fullerton. http://sdg. http://beru. http://haig. http://www. Singhoff.univ-brest. MIT Lab for Computer Science. Software Design Group. Jackson.doc. 2005. A Guide to Alloy. Legrand J.edu/files/Software%20Design/CS-462-Details.. http://alloy.Jackson. R.univ-brest.csail.html. F.. http://beru. Fullerton. Marc´ e L. Alloy in 90 Minutes.fr/~singhoff/cheddar/publications/singhoff05a.x User’s Guide. G.uk/project/examples/2007/271j/suprema_on_alloy/Web/index.ic.mit. L. Chang. R. F. Herrmann. http://www. D. INF123_Discussion4. California State University. Irvine. Fall 2008. M. The Cheddar project : a free real time scheduling analyzer.0. 1999. http://beru.csail.mit. 1999. UML.. Le Berre D. 2008.edu/~taylor/classes/123/INF123_Discussion4. and Z. O. Nana.ics.fr/~singhoff/cheddar/publications/singhoff04a. Software Design.pdf . 2008.edu/pubs/1999/alloy-comparison.univ-brest. H. Marc´ e L.

Sign up to vote on this title
UsefulNot useful