There is currently no document on the Cheddar's framework but this directory provides somes examples of programs that you can use in order to directly call the framework without the machine-man interface. To call the framework, you must use the framework interface. The framework interface is described in the call_framework.ads package. The call_framework.ads package implements the facade design pattern : it means that all the services provided by the framework is available from this package.

The following programs use the call_framework.ads interface :

• xml_basics.adb : this program shows you how to call Cheddar and to solve the analysis results computed by feasibility test in a XML file. given in the package architecture_models.adb. The schedule_hardcoded_model.adb package called a sub-program of architecture_models.adb to build a architecture model and then, compute scheduling sequences for the builded architecture model.
• schedule_hardcoded_model.adb : this program shows you how to use the Cheddar framework API to design an architecture model. Some examples of architecture models are given in the package architecture_models.adb. The schedule_hardcoded_model.adb package called a sub-program of architecture_models.adb to build a architecture model and then, compute scheduling sequences for the builded architecture model.
• build_schedule_from_xml.adb : this program computes a scheduling from an XML Cheddar project file and save the result into a second XML file. This is an example which shows how to use cheddar through the command line. The XML file name of the system to analyze must be given with the "-i" switch. The XML file name of the scheduling to save must be given with the "-o" switch. This program also takes one argument : the period on which the scheduling must be computed. The resulting scheduling is in fact the event table produced by the scheduling engine.
• parse_and_display_schedule.adb : this program shows how to read and parse an XML file containing a schedule computed by Cheddar. This schedule is in fact, the event table produced by the scheduling engine. The "-s" switch must be used to provide the anayzed system (eg. its XML file name). The "-e" switch must be used to provide the event table (eg. its XML file name).
• read_sys.adb : this program gives an examples on how to load a XML Cheddar project file into the framework.
  
• write_sys.adb : this program gives an examples on how to save a model in a XML Cheddar project file.
  
• comprehensive_call.adb : this program is an example of a call to the framework. This call includes the analysis of a scheduling. The result is formatted as a simple ASCII text.
  
• xml_comprehensive_call.adb : this program implements the same calls to the framework than comprehensive_call.adb but the result produced by this program is generated with XML tags (in order to be displayed by an Internet browser).

****************** ***PRESENTATION*** ****************** Select_feasibility_test_simpl_from_xml is an example of feasibility test selection prototype. It enable to apply the design pattern recognition method to architecture models. This program can either take an architecture model in xml format as an entry, and also provide 8 architecture examples to illustrate how it works. Those 8 example are: (1) compliant_ttc: an architecture compliant to the Time_Triggered_Communication Design pattern; (2)uncompliant_ttc: an architecture close but uncompliant to the Time_Triggered_Communication Design pattern; (3)compliant_rav: an architecture compliant to the Ravenscar Design pattern; (4)uncompliant_rav: an architecture close but uncompliant to the Ravenscar Design pattern; (5)compliant_unpl: an architecture compliant to the Time_Triggered_Communication Design pattern; (6)uncompliant_unpl: an architecture close but uncompliant to the Unplugged Design pattern; (7)uncompliant_env: an architecture with a multi core processor environment (8)uncompliant_buff: an architecture close but uncompliant to the Time_Triggered_Communication Design pattern (there is an extra buffer). The result and the xml representation of the architecture are displayed if the verbose mode is asked (-v). The result is stored in a text file whom name is given by the user. ***************** ***COMPILATION*** ***************** This file is compiled with the makefile target dp. The executable is created in the binaries/bin/debug folder. *************** ***EXECUTION*** *************** Taking a XML file for entry does not work yet. The only way to test the prototype is to use it with predefined architecture Here is an example of command line to launch the program: ./select_feasibility_test_simple_from_xml -v -a 1 -o result1.txt Just change the architecture number to try the different cases. *********** ***USAGE*** *********** select_feasibility_tests_from_xml version 3.0, Copyright (C) 2002-2012, by Frank Singhoff, Alain Plantec, Jerome Legrand Compiled from the SVN source code revision number $Rev: 523 $, source code changed on $Date: 2012-09-26 15:09:39 +0200 (Wed, 26 Sep 2012) $ The Cheddar project was started in 2002 by Frank Singhoff, LISyC Team, Université de Bretagne Occidentale Since 2008, Ellidiss technologies also contributes to the development of Cheddar and provides industrial support select_feasibility_tests_from_xml comes with ABSOLUTELY NO WARRANTY; This is free software, and you are welcome to redistribute it under certain conditions; See the GNU General Public License for details. select_feasibility_tests_from_xml is a program which select feasibility tests from an XML Cheddar project file and save the result into a second XML file. Check Cheddar home page for details : http://beru.univ-brest.fr/~singhoff/cheddar Usage : select_feasibility_tests_from_xml switch can be : -u get this help -v verbose mode -o file-name, write the scheduling into the file file-name -i file-name, read the system to analyze from the XML file file-name -a architecture-name, analyze dor demonstration from pre-defined example architecture-name architecture-name can be: (1) compliant_ttc, (2)uncompliant_ttc, (3)compliant_rav, (4)uncompliant_rav, (5)compliant_unpl, (6)uncompliant_unpl, (7)uncompliant_env, (8)uncompliant_buff