-
Paper III
*The PLUSS Toolkit ― Extending Telelogic DOORS and IBM-Rational
Rose to Support Product Line Use
Case Modeling
Magnus Eriksson1, Henrik Morast2, Jürgen Börstler3 and Kjell
Borg1
1 Land Systems Hägglunds AB, SE-891 82 Örnsköldsvik, Sweden
{Magnus.Eriksson, Kjell.Borg}@baesystems.se
2 Syntell AB, PO Box 100 22, SE-100 55 Stockholm, Sweden
[email protected]
3 Dept. of Computing Science, Umeå University, SE-901 87 Umeå,
Sweden [email protected]
Abstract. The PLUSS approach (Product Line Use case modeling for
Systems and Software engineering) is a domain modeling method
tailored towards the development of long lived software intensive
systems. PLUSS provides means to maintain a common and complete use
case model for a whole family of systems. In this paper, we
describe how the commercial requirements management tool Telelogic
DOORS and the UML modeling tool IBM-Rational Rose can be extended
and used for managing system family models in accordance with the
PLUSS approach.
* Proceedings of the 20th IEEE/ACM International Conference on
Automated Software
Engineering, Long Beach California, ACM Press, pp. 300-304
-
Paper III – The PLUSS Toolkit 69
1 Introduction
Software intensive defense systems, for example vehicles, are
developed in short series. They are always customized for specific
customer needs and they are expected to have very long life spans,
often 30 years or longer. For a business to be competitive in a
market like this it is important to achieve high levels of reuse
and effective maintenance. An interesting approach to address such
issues is known as software product line development. The basic
idea of this approach is to use domain knowledge to identify common
parts within a family of products and to separate them from the
differences between the products. The commonalties are then used to
create a product platform that can be used as a common baseline for
all products within the product family.
Due to earlier positive experiences with use cases in single
system development, we aimed at a use case driven product line
approach that could be applied by both our systems- and software
engineering teams. To address problems and issues in existing
product line use case modeling approaches, we have developed a
domain modeling approach that utilizes features models [7], use
cases [6] and use case realizations [8]. We refer to this approach
as the PLUSS (Product Line Use case modeling for Systems and
Software engineering) approach [2].
In this paper we describe a number of extensions to the
commercial requirements management tool Telelogic DOORS and the UML
modeling tool IBM-Rational Rose aimed to better support the PLUSS
approach. For the reminder of this paper we will refer to these
extensions as the PLUSS toolkit.
2 The PLUSS Approach
The goal of the PLUSS approach is to provide means for
maintaining a common and complete use case model for a whole family
of systems. Doing so requires the proper management of variants
among family members within such a model. We identified four types
of variants in the use case models for our product families [2].
These variants regards the set of use cases included in a member of
a family, the set of scenarios included in each use case, and the
set of steps included in each use case scenario. Furthermore,
cross-cutting aspects can exist that affect several use cases on
several levels in the model.
Our approach for managing variability in PLUSS is based on the
work by Griss et al. on FeatuRSEB [5]. In FeatuRSEB a feature model
is added to the 4+1 view model adopted by Jacobson et al. in RSEB
[6]. Like Griss et al., we argue that feature models are better
suited for domain modeling than for example UML use case diagrams
and that a feature model therefore should be used as the high level
view of the product family. We use a feature model as a tool for
structuring use cases into reusable packages for a system family.
We thereby provide means to manage variants among family members.
Product instantiation of such a family model is then done by using
the feature model as a tool to choose among its variants. The set
of included features directly corresponds to a specific set of
included use cases for a product.
-
70 Magnus Eriksson, Henrik Morast, Jürgen Börstler and Kjell
Borg 2.1 Feature Modeling in PLUSS
Kang et al. first proposed using feature models in 1990 as part
of Feature Oriented Domain Analysis (FODA) [7]. In feature models,
system features are organized into trees that represent the
commonalities and variations within a family of related systems.
General features are located at the top of the tree and more
refined features are located below. Originally, FODA described
“Mandatory”, “Optional” and “Alternative” features that may have
“requires” and “excludes” relations to other features. Mandatory
features are available in all systems within a family. Optional
features may or may not be included in products. Alternative
features represent selections, where “exactly-one-out-of-many”
features must be chosen. A “requires” relationship indicates that a
feature depends on some other feature to make sense in a system. An
“excludes” relationship between two features indicates that both
features can not be included in the same system.
In PLUSS, FODA feature modeling is slightly extended and
modified to better suit our modeling needs. We have defined a new
feature type called “Multiple Adaptor” feature to represent an
“at-least-one-out-of-many” selection, which is missing in FODA [3].
We have also chosen to rename alternative features to “Single
Adaptor” features, following the naming scheme proposed by Mannion
et al. for the equivalent relations in their work on reusable
requirements [9]. Single and multiple adaptor features are
represented by the letters ‘S’ and ‘M’, respectively, surrounded by
a circle as shown in Fig. 1. In the FODA notation, an arc connects
sets of alternative features. Due to limitations in our tool
support we removed this arc from the PLUSS notation. Instead we
imposed a modeling constraint to ensure that only one set of single
adaptor and multiple adaptor features respectively may exist under
the same parent feature. This was necessary to avoid ambiguity in
models whether a certain feature belongs to a specific set of
single or multiple adaptor features. If several sets are needed
under the same parent, a new level must be created in the feature
tree and each set is placed under a separate parent feature.
Domain
a
ac
Saac
Saaa
Saab
Saba
abaa
Sabb
b
Mbca
Mbcb
Sbc
Sbb
Mbbb
Mbba
S Single AdaptorMandatory Optional M Multiple AdaptorRequires
Excludes
ba
Mbcc
Domain
aa
acac
Saac
Saac
Saaa
Saaa
Saab
Saab
Saba
Saba
ababaaaa
SabbS
abb
bb
MbcaM
bcaM
bcbM
bcb
SbcSbc
SbbS
bb
MbbbM
bbbM
bbaM
bba
S Single AdaptorMandatory Optional M Multiple AdaptorRequires
Excludes
S Single AdaptorS Single AdaptorMandatoryMandatory
OptionalOptional M Multiple AdaptorM Multiple
AdaptorRequiresRequires ExcludesExcludes
baba
Mbcc
Mbcc
Fig. 1: A feature model example in the PLUSS notation.
2.2 Relating Features and Use Cases
Gooma [4] proposed to model each feature as a use case package.
We have extended this idea saying that a whole set of features can
compose a use case package. This
-
Paper III – The PLUSS Toolkit 71
enables us to also visualize variants within use case
specifications using the feature model. As shown in the example in
Fig. 2, use cases as well as use case scenarios can be mapped to
features of any type to capture required variants among the members
of a system family.
Domain
a
Saac
Saaa
Saab
Saba
abaa
Sabb
b
Mbca
Mbcb
Sbc
Sbb
Mbbb
Mbba
ba
Mbcc
Optional Feature: abOptional Feature: ab
Use Case: Introduction.Main Success Scenario.Alternative
Scenarios
.
.
Use Case: Introduction.Main Success Scenario.Alternative
Scenarios
.
.
Domain
aa
Saac
Saac
Saaa
Saaa
Saab
Saab
Saba
Saba
ababaaaa
SabbS
abb
bb
MbcaM
bcaM
bcbM
bcb
SbcSbc
SbbS
bb
Mbbb
Mbbb
MbbaM
bba
baba
Mbcc
Mbcc
Optional Feature: abOptional Feature: ab
Use Case: Introduction.Main Success Scenario.Alternative
Scenarios
.
.
Use Case: Introduction.Main Success Scenario.Alternative
Scenarios
.
.
Fig. 2: An example of the relationship between features, use
cases and use case
scenarios.
We have chosen to adopt an extended version of the RUP-SE “Flow
of Events” notation [11] shown in Fig. 3 for describing use case
scenarios and realizations. As shown in the example in Fig. 4, the
extension utilizes the step identifier of the original notation to
capture variants as we described in [2].
DesignElement_1…
………………
Whitebox Action
DesignElement_2… DesignElement_3…
It shall…
………………
WhiteboxBudgeted Req.
……
1
2
3
Step
The Actor…
…
The use case ends when…
Actor Action
The System…
…
…
BlackboxSystem Response
It shall…
…
…
BlackboxBudgeted Req.
(a) (b)
DesignElement_1…
………………
Whitebox Action
DesignElement_2… DesignElement_3…
It shall…
………………
WhiteboxBudgeted Req.
……
1
2
3
Step
The Actor…
…
The use case ends when…
Actor Action
The System…
…
…
BlackboxSystem Response
It shall…
…
…
BlackboxBudgeted Req.
(a) (b)
DesignElement_1…
………………
Whitebox Action
DesignElement_2… DesignElement_3…
It shall…
………………
WhiteboxBudgeted Req.
……
1
2
3
Step
The Actor…
…
The use case ends when…
Actor Action
The System…
…
…
BlackboxSystem Response
It shall…
…
…
BlackboxBudgeted Req.
(a) (b) Fig. 3: The (a) Blackbox flow of events used for
describing use case scenarios, and
(b) the Whitebox flow of events used for describing use case
realizations.
As shown in Fig. 4, there is also a predefined set of feature
constructs that should be mapped against each type of variant in
the use case scenario notation. We maintain this redundant
information on purpose, since the extra information considerably
improves readability. Using the underlying tools, this redundancy
does not pose a problem since automatic consistency checking
between the models could easily be implemented. We also have
included use case parameters [6] in the PLUSS notation
-
72 Magnus Eriksson, Henrik Morast, Jürgen Börstler and Kjell
Borg [2], as shown in steps ‘3c’ and ‘5’ in Fig. 4. This provides
means to capture cross-cutting variability in models.
Step Actor Action BlackboxSystem Response
BlackboxBudgeted Req.
1
23a3b3c(4)(5)a(5)b(5)c(6)(6)(6)
22
The Actor…
……………………………
……
The System…
……………………………
……
It shall…
………… @PARAM_1……… $PARAM_2…………
……
SS
S
SS
S
MMM
MMM
S S S
S S S
Mandatory step
Optional step
Exactly one to beselected for amandatory step
At least one to beselected for amandatory step
Exactly one to beselected for anoptional step
At least one to be selected for anoptional step
Step Actor Action BlackboxSystem ResponseBlackbox
Budgeted Req.1
23a3b3c(4)(5)a(5)b(5)c(6)(6)(6)
22
The Actor…
……………………………
……
The System…
……………………………
……
It shall…
………… @PARAM_1……… $PARAM_2…………
……
Step Actor Action BlackboxSystem ResponseBlackbox
Budgeted Req.1
23a3b3c(4)(5)a(5)b(5)c(6)(6)(6)
22
The Actor…
……………………………
……
The System…
……………………………
……
It shall…
………… @PARAM_1……… $PARAM_2…………
……
SS
S
SS
S
MMM
MMM
S S SS S S
S S SS S S
Mandatory step
Optional step
Exactly one to beselected for amandatory step
At least one to beselected for amandatory step
Exactly one to beselected for anoptional step
At least one to be selected for anoptional step
Fig. 4: An example of the relationship between features, variant
use case scenario
steps and use case parameters in the PLUSS notation.
3 PLUSS Tool Support
For software product line development to become efficient in
every day practice, adequate tool support is an important factor.
Unfortunately, this tool support is lacking today. Some
experimental tools and very few commercial tools are available.
Furthermore, existing tools are not providing the functionality
needed to support the PLUSS approach in a satisfying manner. There
are many risks associated with using tools designed for single
system development in a software product line environment, like for
example the following (see [1] for a detailed discussion on these
issues).
1. There is a high risk that resources may be expended
unnecessarily, because of lack of adequate tool support.
2. There is a high risk that artifacts become inconsistent,
because tools do not enable linkage or traceability between the
different types of artifacts.
3. There is a high risk that tools become difficult to maintain,
because of the need for local modifications to enable product line
development.
Even tough we recognize and agree with these risks, we have
chosen to adapt and extend our existing single system CASE tool
environment to support the PLUSS approach. The two main arguments
for this decision were:
1. Using the existing CASE tool environment will minimize the
need for training of personnel.
2. Using commercially available tools will minimize the amount
of tool code that needs to be maintained.
The main tools used to support the PLUSS approach are the
requirements management tool Telelogic DOORS and the UML modeling
tool IBM-Rational Rose. Both tools are widely used and accepted in
industry. We use Telelogic DOORS to
-
Paper III – The PLUSS Toolkit 73
manage our system family use case models and IBM-Rational Rose
for drawing feature graphs and UML diagrams. We then generate
appropriate reports from our domain model as MS Word documents, as
shown in Fig. 5. We have implemented a number of small extensions
to these tools, which we refer to as the PLUSS toolkit. However, to
address the third risk above, our strategy is to keep these
extensions as small as possible.
Feature Model,Use Case Specifications
andUse Case Realizations
DOORS
Feature Graphand
UML Diagrams
Rose
Repository ofPublished Reports
Software CM SystemMS Word Reports
Feature Model,Use Case Specifications
andUse Case Realizations
DOORS
Feature Graphand
UML Diagrams
Rose
Repository ofPublished Reports
Software CM SystemMS Word Reports Fig. 5: Overview of the PLUSS
toolkit.
3.1 Telelogic DOORS
Telelogic DOORS is an “object” database intended for
requirements management. Objects may be arranged in a hierarchic
structure in modules. Typically, node objects are used as headings
and leaf objects are used for data items such as (textual)
requirements. Both headings and text are usually displayed in a
single column in the DOORS graphical user interface. This column is
referred to as the main column. DOORS also has a link concept
enabling definitions of binary relationships between objects. Links
form the basis for traceability in DOORS.
It is possible to define attributes on both module and object
level in DOORS. An object attribute holds a value for each object
in a module. Module attributes can be used for storing additional
data not related to specific objects in modules. An attribute
definition specifies what kind of information an attribute can
store. Object attributes can be displayed in columns within a
module in the DOORS graphical user interface. Combining this
possibility with DOORS support for filtering on properties of
objects, a user may define views suiting different needs. These
views are used when working with data and also for reporting and
exporting information to other tools. Views may be saved in a
module for later use.
3.2 Feature Modeling in DOORS
Feature models are managed in specific DOORS modules. The basic
idea is to use the standard DOORS object hierarchy to model the
“refine” relation for building feature
-
74 Magnus Eriksson, Henrik Morast, Jürgen Börstler and Kjell
Borg trees. Each feature becomes a heading and leaf objects are
used for capturing different kinds of information regarding each
feature. A number of attributes are defined in a feature model
module:
• A Characteristics attribute is used for classifying each
object in the module as “General Information”, a “Feature”, a
“Feature description”, a “Feature graph” or a “Use Case Diagram”.
General information objects are typically used for introductory
information in the domain model, such as use case actor
descriptions etc.
• A Feature Type attribute is used for classifying features in
the feature hierarchy. It can take the values “mandatory”,
“optional”, “single adaptor” or “multiple adaptor”.
• A Require attribute and an Exclude attribute is used to
capture the “requires” and “excludes” relation between features.
This is realized by means of a reference holding the identity of
the required or excluded feature objects.
• A Use Case Package attribute is used when filtering out a use
case model survey from the domain model. Elaborating on the
discussion in section 2.2, a sub-tree of the feature model
typically corresponds to a use case package for a specific system
within a system family. This attribute is used for marking such sub
trees in the model.
• A Product Instances attribute is used to mark features as
included or not by systems within a system family. This information
is managed using a multi-valued enumeration attribute that can
assume the names of all systems in the family as shown in Fig. 6.
This information is then used for filtering out product specific
use case models for the different systems in the family. Equivalent
information can however also be captured as incoming links from
higher level specifications to feature objects. Which method to
use, depends on the requirements for traceability to higher level
specifications in the specific project.
Fig. 6: The DOORS Domain Model View (note that project specific
information is
blurred).
-
Paper III – The PLUSS Toolkit 75
3.3 Feature Graphs in Rose
To be able to draw feature graphs in Rose, we utilized the UML
stereotype mechanism [10]. Icons for all PLUSS feature types were
created. These icons were then associated with UML “Classes” that
had been stereotyped as the different feature types. The UML
“Dependency” relation was then stereotyped as “require” and the UML
“Association” relation was stereotyped as “excludes”. Furthermore,
UML “Classes” are used for visualizing domain names and UML
“Association” relations are used for visualizing the refinement
relation in Rose. All new elements for feature modeling have been
added to the use case diagram toolbar in the graphical user
interface of Rose.
3.4 Use Case Specifications and Use Case Realizations in
DOORS
Each use case is managed as a separate module in the DOORS
database. Introductory information is captured in a traditional
document structure with headings and text in the DOORS main column.
To capture use case scenarios and use case realizations in DOORS,
we use one DOORS object to describe each scenario step. To be able
to do this, object attributes for all columns in the PLUSS notation
shown in Fig. 3, except the “Actor Action” column must be defined.
For the “Actor Action” column, the DOORS main column is used.
The relationship between blackbox and whitebox scenario steps
(realizations) is managed using the standard DOORS object
hierarchy. All whitebox step objects are children to their
corresponding blackbox step object. This means that use case
specifications and their corresponding realisation are actually
different views of the same DOORS module.
3.5 Relating Features and Use Cases in DOORS
We relate features and use cases as follows in DOORS: • A
feature can be related to zero or more complete use cases. We
manage this
relation in DOORS by inserting a UML use case diagram showing
use cases as a leaf object under a feature object in a feature
model module.
• A feature can be related to zero or more use case scenarios.
We manage this relation in DOORS by creating an outgoing link from
a heading object naming a scenario in a use case module, to a
feature object in a feature model module using the DOORS link
concept.
• A feature can be related to zero or more scenario steps. We
manage this relation in DOORS by creating an outgoing link from a
scenario step object in a use case module to a feature object in a
feature model module, using the DOORS link concept.
As shown in Fig. 4, we do not relate mandatory scenario steps to
the feature model. The same is also true for mandatory use case
scenarios. This is not needed since the primary purpose of the
feature model is not to provide a total view of a system family,
but rather to visualize variants in the family use case model.
-
76 Magnus Eriksson, Henrik Morast, Jürgen Börstler and Kjell
Borg 3.6 DOORS Extensions for the PLUSS Approach
DOORS can be customized using its integrated scripting language
DXL (DOORS eXtension Language) [12]. DXL supports all kinds of
manipulations of the DOORS database. DXL can also be used to adapt
and extend the standard DOORS user interface and for controlling
other Windows applications that provide automation interfaces.
The following sections briefly describe some DXL tools that were
developed as part of the PLUSS toolkit. These tools consist of
approximately 1.000 lines of low complexity DXL code in total.
3.6.1 Check Feature Model The purpose of the “Check Feature
Model” tool is to help the user with basic consistency control of
feature model modules. The tool checks a number of rules and
conditions and presents to the user any violations in the graphical
user interface. Currently, we have implemented the following
rules/conditions:
• Only heading objects are marked as features. • All feature
objects have a defined feature type. • No “require” relations exist
within a set of “single adaptor features”. • Only feature objects
have “require” or “exclude” relations. • All “exclude” relations
are bi-directional. • No contradictions exist regarding “exclude”
relations and “mandatory
features”. • No “exclude” relations exist between ancestors and
descendants in the
feature hierarchy. • No contradictions exist regarding “exclude”
relations and “require” relations.
3.6.2 Check Configuration The purpose of the “Check
Configuration” tool is to verify whether a specific product
instance (configuration) of the domain model is consistent with the
feature model. The tool checks the following properties and
presents to the user any violations in the graphical user
interface.
• All “mandatory features” with included parent features are
included in the configuration.
• All ancestors to included features in the feature hierarchy
are included in the configuration.
• The configuration does not violate “exclude” or “require”
relations. • The configuration does not violate the rules of
“single adaptor” or “multiple
adaptor” features.
3.6.3 Illustrate Feature Model Hierarchy The purpose of the
“Illustrate Feature Model Hierarchy” tool is to illustrate a
portion of the feature model hierarchy in the DOORS graphical user
interface. From a selected feature object in a feature model
module, a feature tree with all ancestors of the selected feature
is drawn in a dialog box. The tool provides possibilities to
-
Paper III – The PLUSS Toolkit 77
collapse and expand the nodes of the tree. The tool also
provides the user with an option to insert the illustration as a
picture in a new DOORS object.
3.6.4 Create Use Case Module The purpose of the “Create Use Case
Module” tool is to automatically create use case modules with
certain properties. This has been realized by pre-creating a use
case template module with predefined structure, attributes and
views which is copied by the tool.
3.6.5 Create Product Use Case Model Survey The purpose of the
“Create Product Use Case Model Survey” tool is to filter out a use
case model survey for a specific product instance from a feature
model module. The tool accomplishes this by removing, from the
selected view, those objects that do not fulfil all of the
following conditions:
• If an object is marked as “General Information”, it must be
either a descendant of an included “Feature” object or marked as
included by the specified product instance itself.
• If the object is marked as a “Feature”, it must also be marked
as included by the specified product instance and be marked as
being a “Use Case Package”. The names of these included features
then become headings in the use case model hierarchy in the
survey.
• If the object is marked as a “Use Case Diagram”, it must be a
descendant of a “Feature” object marked as included by the
specified product instance.
The resulting view can then be exported into a Use Case Model
Survey Report for the selected product instance using the standard
DOORS MS Word export.
3.6.6 Export Use Case The purpose of the “Export Use Case” tool
is to export use case modules from DOORS to MS Word as use case
specifications and use case realizations.
The “Export Use Case” tool is based on the standard DOORS MS
Word export, which is written in DXL. The basic idea of the tool is
to export blackbox and whitebox scenarios as specially formatted
tables (see Fig. 3), and all other information as ordinary headings
and text. The tool distinguish between scenarios and other
information using the “Step” attribute, which only has a defined
value if an object is part of a scenario.
4 Summary and Conclusions
We have described how commercially available CASE tools,
traditionally used in single system development, can be extended
and utilized for managing system family models in accordance with
the PLUSS approach.
The described PLUSS toolkit is currently being used in several
large scale industrial development projects in the defense domain.
Our experience so far is quite
-
78 Magnus Eriksson, Henrik Morast, Jürgen Börstler and Kjell
Borg positive. An informal evaluation indicated that the toolkit
allows developers to work more effectively. A formal evaluation of
the toolkit is currently planned.
References
1. Bass L., Clements P., Donohoe P., McGregor J. Nortrop L.:
Fourth Product Line Practice Workshop Report, Technical Report
CMU/SEI-2000-TR-002, Software Engineering Institute, Carnegie
Mellon University, Pittsburgh, PA (2000)
2. Eriksson M., Börstler J., Borg K.: The PLUSS Approach –
Domain Modeling with Features, Use Cases and Use Case Realizations,
, Proceedings of the International Conference on Software Product
Lines, LNCS, Vol. 3714, Springer-Verlag (2005) 33-44
3. Fey D., Fajta R., Boros A.: Feature Modeling: A Meta-model to
enhance Usability and Usefulness, Proceedings of the International
Conference on Software Product Lines, LNCS, Vol. 2371,
Springer-Verlag (2002) 198-216
4. Gooma H. Designing Software Product Lines with UML – From Use
Cases to Pattern-Based Software Architectures, Addisson-Wesley
(2004)
5. Griss M., Favaro J., d’Alessandro M.: Integrating Feature
Modeling with the RSEB, Proceedings of the Fifth International
Conference on Software Reuse, Vancouver, BC, Canada (1998)
76-85.
6. Jacobson I., Griss M., Jonsson P.: Software Reuse –
Architecture, Process and Organization for Business success,
Addison-Wesley (1997)
7. Kang K. Cohen S., Hess J., Novak W., Peterson A.: Feature
Oriented Domain Analysis (FODA) Feasibility Study, Technical Report
CMU/SEI-90-TR-021, Software Engineering Institute, Carnegie Mellon
University, Pittsburgh, PA (1990)
8. Kruchten P.: The Rational Unified Process - An Introduction,
Second Edition, Addison-Wesley (2000)
9. Mannion M., Lewis O., Kaindl H., Montroni G., Wheadon J.:
Representing Requirements on Generic Software in an Application
Family Model, Proceedings of the International Conference on
Software Reuse ICSR-6 (2000) 153-196.
10. Object Management Group: Unified Modeling Language Version
2.0, Available at: http://www.uml.org (2005)
11. Rational Software: The Rational Unified Process for Systems
Engineering Whitepaper, Ver. 1.1, Available at:
http://www.rational.com/media/whitepapers/TP165.pdf (2003)
12. Telelogic AB, DXL Reference Manual, DOORS 7.1 Manual
creation date: (3 May 2004)
/ColorImageDict > /JPEG2000ColorACSImageDict >
/JPEG2000ColorImageDict > /AntiAliasGrayImages false
/DownsampleGrayImages true /GrayImageDownsampleType /Bicubic
/GrayImageResolution 300 /GrayImageDepth -1
/GrayImageDownsampleThreshold 1.50000 /EncodeGrayImages true
/GrayImageFilter /DCTEncode /AutoFilterGrayImages true
/GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict >
/GrayImageDict > /JPEG2000GrayACSImageDict >
/JPEG2000GrayImageDict > /AntiAliasMonoImages false
/DownsampleMonoImages true /MonoImageDownsampleType /Bicubic
/MonoImageResolution 1200 /MonoImageDepth -1
/MonoImageDownsampleThreshold 1.50000 /EncodeMonoImages true
/MonoImageFilter /CCITTFaxEncode /MonoImageDict >
/AllowPSXObjects false /PDFX1aCheck false /PDFX3Check false
/PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true
/PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ]
/PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [
0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile ()
/PDFXOutputCondition () /PDFXRegistryName (http://www.color.org)
/PDFXTrapped /Unknown
/Description >>> setdistillerparams>
setpagedevice
