SA Publisher for web generation : System Architect Publisher : Preparing reports : Report types
  
Report types
The website generation template that you build gets information from the System Architect repository using reports from the reporting system. The first report that is run is called the “starting report”. You can specify a default report to be run for all diagrams, symbols, or definition. You can specify default reports to run for particular diagram, symbol, or definition types. You can also specify an alternative report to be run (instead of the default) for a particular type, as that type is encountered within the context of a particular report.
Starting reports
As the starting report runs, it also runs subreports that traverse the System Architect repository like an octopus. The starting report and its subreports form a hierarchy of reports. You may optionally specify that a starting report direct its output to the website’s home page.
You may also specify more than one starting report. If you do, your website output has more than one top level. However, only one starting report can be specified as the output for the home page.
The starting report:
▪is the first report to run
▪drives the hierarchy of reports that are run
▪may be the first information that you see (this is an option)
You can have more than one starting report, but only one can generate its output to the home page or the website output.
Default reports for all diagrams, symbols and definitions
In System Architect, the three basic classes are diagrams, symbols, or definitions. You can specify a default report to be run for all diagrams, symbols, or definitions in the Class Defaults tab.
If you want a specific default report for a particular type of diagram, symbol, or definition, use the Type Defaults tab. This would include, for example, specifying a default report for all Use Case diagrams (diagram of type Use Case), or Use Case symbols, or Use Case definitions, and so on. For example, assume that the start report is for a Use Case diagram, which has Use Case symbols, which are defined by Use Case definitions. In such an example, if you want to specify a Use Case Step report as the default report to run for all Use Case definitions, you do not want to specify it as the default for all Definition types in this tab. It would run for all definitions, and give you unexpected output, since only a Use Case has Use Case steps. Specify the Use Case Step report as the default report for Use Case definitions in the Type Defaults tab.
System Architect Publisher indicates that a report has been specified for a class (diagram, symbol, or definition) by adding “R” to its icon.
Default reports for specific diagrams, symbols and definition types
You can specify default reports to run for particular diagram, symbol, or definition types. For example, a Use Case diagram is a type of diagram; an actor and a Use Case are types of symbols; and a class definition or a Use Case definition is a type of definition.
When you specify a default report for a type, System Architect Publisher will run the specified report for this type during the generation process and include the information in the generated web pages.
On the Type Defaults tab, only diagrams and definitions are listed at the highest level. To display symbols, expand Diagrams, and then expand a diagram type.
System Architect Publisher signifies that a report has been specified for a type by augmenting the icon representing the type with an R in circle icon.
Note You cannot bring over reports that are subreports in this dialog. They are missing the WHERE "Identity" = "SWGDDID" clause, and you will be told that this is missing.
Alternative reports for types
You can specify an alternative report to be run (instead of the default) for a particular type, as that type is encountered within the context of a particular report. For example, you might create two reports for a data modeling entity definition. One report might include detailed information that a database designer would be interested in; the second report might include only high-level information such as entity and attribute names. The first report might be the default report that is normally run for entities; you might only want the second report to run when a business modeling report run for business managers encounters a “related” entity.
What you want to specify in the Alternative Reports tab is the report that kicks off the exception (in the example above, the business modeling report), what type will set off the exception (in the example above, the entity definition), and what report to run when the exception is hit (in the example above, the second report providing only high level details of an entity for a business audience).
The logic that the XML template takes when running reports for a particular artifact (diagram, symbol, or definition), is as follows: First look to see if there is an alternate report specified for it; if there is, run it. If not, look to see if there is a default type report for the artifact; if there is, run it. Third, look to see if there is a class default specified for the artifact; if there is, run it.
To specify an alternative report, first specify the report that will kick off the exception condition, then specify the type that will kick off the exception, and then specify the alternative report.
Notes
▪System Architect does not prohibit you from adding a type that does not seem to make sense within the context of the “exception” report. For example, if the exception report is a UML Class diagram report, you could drag over an exception type of a BPMN process, even though a BPMN process does not seem to have any association to a class definition. System Architect cannot be sure that the exception report that you have chosen does not, in the case above, get BPMN processes that are somehow related to UML class definitions by navigating the many relationships in System Architect's metamodel (for example, a report could be made to get a class’s related entities and their related BPMN processes.
▪It is up to the user to intelligently add the exception type that they want.
▪The report that you add to the Alternate side (to kick off the exception) must be a report that has been specified to be used: if it has not been specified it will never run, and the exception condition will never arise. System Architect prevents you from adding a report as an exception report that has not been previously specified.
Adding subreports
Subreports enable you to generate a report page that includes both information on an artifact (diagram, symbol, or definition), and also complete reports on its properties.
For example, a typical report for a Class definition lists its attributes and methods, and for each attribute and each method, a link that goes to a page that contains a full report on each attribute and method. Using subreports, you can create a Class definition report that has an Attribute subreport and a Method subreport, so that all information is on one page.
To include subreports, add the SUBREPORT statement to the main report while you are editing it in text mode (not through the reporting system’s graphical user interface).
Use the code below (which reflects the figure above) as an example:
REPORT "Class Report"
ID 53008
{
SETTING { PAGESIZE -1", 0.00 }
SETTING { REPORTFORMAT 4 }
FIELD "Description <-- Description" { SOURCE PROPERTY "Description" LENGTH 500 TYPE MEMO LEGEND "Description" }
FIELD "Stereotype <-- Stereotype" { SOURCE PROPERTY "Stereotype" LENGTH 20 TYPE CHARACTER LEGEND "Stereotype" }
FIELD "Package <-- Package" { SOURCE PROPERTY "Package" LENGTH 90 TYPE CHARACTER LEGEND "Package" }
TABULAR 1 {
SELECT "Name" LEGEND "Invisible", SAUsrProps, "Description <-- Description",
"Stereotype <-- Stereotype", "Package <-- Package"
WHERE Class = Definition
WHERE Type = "Class"
WHERE "Identity" = "SWGDDID"
SUBREPORT "Class Attributes" { }
SUBREPORT "Class Methods" { }
SUBREPORT "Class Contained In Diagrams" { }
}
}
REPORT "Class Attributes"
DESCRIPT "Attributes"
ID 9673
{
SETTING { PAGESIZE -1", 0.00 }
SETTING { HEADER 1 "Class Definition" }
SETTING { REPORTFORMAT 4 }
FIELD "Description <-- Description" { SOURCE PROPERTY "Description" LENGTH 1500 TYPE MEMO LEGEND "Description" }
FIELD "Access <-- Java Attribute Access" { SOURCE PROPERTY "Java Attribute Access" LENGTH 20 TYPE CHARACTER LEGEND "Access" }
FIELD "Pre-Type <-- Pre-Type" { SOURCE PROPERTY "Pre-Type" LENGTH 20 TYPE CHARACTER LEGEND "Pre-Type" }
FIELD "Post-Type <-- Post-Type" { SOURCE PROPERTY "Post-Type" LENGTH 20 TYPE CHARACTER LEGEND "Post-Type" }
FIELD "Type <-- Type" { SOURCE PROPERTY "Type" LENGTH 90 TYPE CHARACTER LEGEND "Type" }
TABULAR 1 {
SELECT "Name", SAUsrProps
WHERE Class = Definition
WHERE Type = "Class"
JOIN
WHERE RELATION = "uses"
JOIN
SELECT "Name", SAUsrProps, "Description <-- Description",
"Access <-- Java Attribute Access" LEGEND "Visibility",
"Pre-Type <-- Pre-Type" LEGEND "Pre-Type", "Post-Type <-- Post-Type" LEGEND "Post-Type",
"Type <-- Type"
WHERE Class = Definition
WHERE Type = "Class Attribute"
}
}
REPORT "Class Methods"
DESCRIPT "Methods"
ID 34702
{
SETTING { PAGESIZE -1", 0.00 }
SETTING { HEADER 1 "Class Definition" }
SETTING { REPORTFORMAT 4 }
FIELD "Description <-- Description" { SOURCE PROPERTY "Description" LENGTH 4074 TYPE MEMO LEGEND "Description" }
FIELD "Access <-- Java Method Access" { SOURCE PROPERTY "Java Method Access" LENGTH 20 TYPE CHARACTER LEGEND "Access" }
FIELD "Return Pre-Type <-- Return Pre-Type" { SOURCE PROPERTY "Return Pre-Type" LENGTH 20 TYPE CHARACTER LEGEND "Return Pre-Type" }
FIELD "Return Post-Type <-- Return Post-Type" { SOURCE PROPERTY "Return Post-Type" LENGTH 20 TYPE CHARACTER LEGEND "Return Post-Type" }
FIELD "Return Type <-- Return Type" { SOURCE PROPERTY "Return Type" LENGTH 90 TYPE CHARACTER LEGEND "Return Type" }
TABULAR 1 {
SELECT "Name" LEGEND "Invisible", SAUsrProps
WHERE Class = Definition
WHERE Type = "Class"
JOIN
WHERE RELATION = "uses"
JOIN
SELECT "Name" LEGEND "Name", SAUsrProps, "Description <-- Description", "Access <-- Java Method Access" LEGEND "Visibility",
"Return Pre-Type <-- Return Pre-Type",
"Return Post-Type <-- Return Post-Type", "Return Type <-- Return Type"
WHERE Class = Definition
WHERE Type = "Method"
}
}
REPORT "Class Contained In Diagrams"
DESCRIPT "Contained In Diagrams"
ID 27627
{
SETTING { PAGESIZE -1", 0.00 }
SETTING { HEADER 1 "Class Definition" }
SETTING { REPORTFORMAT 4 }
TABULAR 1 {
SELECT "Name" LEGEND "Invisible", SAUsrProps
WHERE Class = Definition
WHERE Type = "Class"
JOIN
WHERE RELATION = "defines"
JOIN
WHERE Class = Symbol
JOIN
WHERE RELATION = "contained in"
JOIN
SELECT "Name" LEGEND "Name", "Type", SAUsrProps
WHERE Class = Diagram
}
}
See also
Preparing reports