The generic scheme described in the previous section (Section 3.1) can be used to work with the user to adapt the scheme to the specific application under study. The customization is carried out through a process that consists of creating system-specific packages according to the structure of the generic scheme depicted in Figure 3.1 and selecting and adapting the views (i.e., CDs) which are relevant for the specific system.
The methodology suggests to create the application-specific packages (and to adapt the views contained in the newly created packages) by following a depth-first order on the package structure which is derived from the hierarchical structure and from the depend association defined between packages laying at the same structure level. This order of customization is compliant with the IEC standard dependability analysis procedure (depicted in Figure 2.10(A) of Chapter I) that establishes that the definition of the system features - activities performed in the firsts two steps - precede the definition of the strategy - activity performed in the third step - since both the identification of the system faults and failure modes and the definition of fault tolerance solutions are motivated by the structure of the system, its functionalities, and its dependability requirements and goals.
The names of the newly created packages are assigned by following the rule of prefixing the original names of the corresponding packages of the generic scheme with the name of the application.
A selected CD contained in a package packiof the hierarchical structure originates a (set of) CD(s) belonging to the corresponding application-specific package pack0i. It is worth to notice that, in general, there is not a one-to-one mapping of the generic CDs into the specific-application one-to-ones, since some generic CDs may not be relevant for the specific application to be customized as well as, for readability purposes, a generic CD may correspond to a set of customized CDs.
Elements of a generic CD cd are instantiated according to the following rules, exemplified in Figure 3.16, that are guidelines together with recommended syntactical rules:
Rule1 A class of cd may be used to generate one or more classes in the corresponding application-specific cd0: for example, the class Automation Site defined in the CD Structure of package Composition may correspond to two application specific sites Automation Site 1 and Automation Site 2. A second example can be made on the customization of the class Physical Faults defined in the CD Physical Faults Hierarchy of the package Fault
A’’
Figure 3.16: Rules for customization of views.
Model: the class can be duplicated in two application-specific classes Physical Faults Site 1 and Physical Faults Site 2 characterizing the physical faults affecting the automation components residing on the automation site 1 and on the automation site 2, respectively. The examples emphasize two main aspects of class customization:
in the first example, the customization of the class Automation Site corresponds to an effective instantiation of the class into objects. When this is the case, we suggest to consider the objects as particular classes, i.e., classes containing each one a single instance, in order to not to mix the Class Diagram and the Object Diagram notations.
In the second example, the customization of the class Physical Faults corresponds to a specialization of the class in two sub-classes, related to a specific application, that may not inherit all the attributes of the generic class. We discourage the use of specialization relationship of UML for class customization mainly because it introduces ambiguities in the customization of the hierarchical views of the CD scheme, as it will be explained in Sub-Section 3.2.1. To encompass these two aspects of class instantiation we suggest, then, the application of the following syntactical rule:
Syntactical Rule For each class of cd one or more copies may be created in an application-specific CD cd0. Since any name can be assigned to the copies, to keep trace of the class instantiation, the is-a input attribute is added to each copy of a class belonging to cd and it is initialized with the name of original class.
As exemplified in Figure 3.16(a) three copies of class A have been created, they have been named A0, A00 and
CHAPTER 3. USE OF CLASS DIAGRAMS IN THE DEPAUDE METHODOLOGY 59
A000respectively, and their is-a attributes have been initialized with the name of the original class A.
Rule2 The set of attributes characterizing a given application-specific class A0can be partitioned in two subsets:
the set of attributes Sder derived from the original class A and the set of the newly added application-specific attributes Snew. Note that, as anticipated in the previous rule, class A0 may not inherit all the attributes of the generic class A, hence the set Sdercan be empty. The set Snewcontains, instead, at least the input attribute is-a.
In order to add information in the customized classes, the range of an attribute attr∈ Sderdefined in class A0is expected to be a subset of the range of the same attribute defined in the original class A, i.e., range(attr)A0 ⊆ range(attr)A.
For example, let the application specific class Failure X be a copy of the generic class Failure of the CD Failure Hierarchy of the package Failure Model. The attribute PF, representing the probability of failure, is a metric to be computed and verified and in the generic class Failure its value ranges in the set [0, 1]∈ IR. The same attribute in the customized class Failure X, to be meaningful from a quantitative point of view, should be set to a specific value or should be allowed to range in a smaller interval.
Concerning the type of usage, i.e., input parameter ($) - measure (/) - upper/lower bound (/$), it should be not modified for attributes of the set Sderto not change the original meaning of the attributes of the generic classes;
at most a bound can become either an input parameter or a measure to be computed. The type of usage have to be explicitly defined, instead, for the attributes of the set Snew.
In general, an attribute belonging to an application-specific class A0 contains additional and/or more refined information with respect to the original one defined in the generic class. We have inspired to [65], where a general format for expressing time values has been given, to define a BNF format for an attribute specified in a class A0.
Syntactical Rule The format of an attribute belonging to a customized class complies with the BNF format defined in Table 3.1, where <attribute> and <String range> have been defined previously in the BNF format for attributes of the generic scheme. <String>, <Integer>, <Real> and <Boolean> are terminal keywords indicating the homonyms data types; <type of value> indicates whether the given/required value is either a mean or a variance or a kth moment or a maximum/minimum value or a probability distribution. In case the metric specification is a probability distribution, <PDFspec> declares a specific probability distribution function (PDF) together with the value(s) to be assigned to the distribution parameters. Dots have been added to mean that the BNF format is “open-ended”: declaration of other types of values as well as specific PDFs are left to the user.
In Figure 3.16(a), for example, a new attribute - attr4 - has been added to A0, it is an input parameter whose values are given by the exponential PDF of mean equal to 1/λ= 10, a maximum value has been set for attr2 in A00and a mean has been assigned to attr3 in A000.
<attribute IST> = <attribute> ’:’ <attrib spec>
<attrib spec> = <String>| <String range> | <Boolean> | <metric spec>
<metric spec> = (<type of value>) <value>| <interval> | ’dist (’ <PDF spec> ’)’
<type of value> = ’mean’| ’var’ | ’kth-mom ,’ <Integer> | ’max’ | ’min’ | . . .
<value> = <number> ( <unit measure> )
<number> = <Integer>| <Real>
<unit measure> = <String>
<interval> = <value> ’..’ <value>| <value> - <value>
<PDF spec> = <exponPDF>| <normalPDF> | <uniformPDF> | . . .
<exponPDF> = ’EXPO (’ <value> ’)’
<uniformPDF> = ’UNIF (’ <value> ’,’ <value> ’)’
<normalPDF> = ’NORMAL (’ <value> ’,’ <value> ’)’
. . .
Table 3.1: BNF format of an attribute of a customized class.
Rule3 Each association R : Aµ1→µ2 B in cd, either defined explicitly between two classes A and B or inherited, may correspond a set of associations SR={R0| R0: A0µ0
1→µ02 B0 }, where each association R0 relates two classes A0 and B0 of cd0 such that the value of their is-a attribute is A and B, respectively. Each R0 ∈ SR has got the same name, when specified, and the same association-end features of R (i.e., role names, qualifiers, aggregation indicator, navigability) except for the multiplicities which can have a different assignment provided that they satisfy the constraints µ01⊆ µ1 and µ02 ⊆ µ2. We have introduced this constraint over the associations derived from the associations of the generic CDs since the former are meant as inherited from the latter and at most specialized to add more information. For example, the association perform defined between classes Automation Components and Automation Functions in the generic CD scheme can be used to define the homonym associ-ation between the corresponding customized classes Automassoci-ation Components X and Automassoci-ation Functions X, respectively, characterized by multiplicities µ01= µ1= 1..n and µ02= 10..15.
Syntactical Rule The cardinality of the set SRdepends on the number of classes of the CD cd0having their is-a attribute set to A or B and on the multiplicities µ1and µ2of R. Possible values of µ1(µ2) are the intervals:
- 1≡ 1..1, in this case for all B0 (A0) such that its is-a attribute is equal to B (A) there exists a unique association R0: A0µ0
1→µ02 B0∈ SR;
- 0..1, in this case for all B0(A0) such that its is-a attribute is equal to B (A) there exists at most an association R0: A0µ0
1→µ02 B0∈ SR;
- 1..n, in this case for all B0(A0) such that its is-a attribute is equal to B (A) there exists at least an association R0: A0µ0
1→µ02 B0∈ SR;
CHAPTER 3. USE OF CLASS DIAGRAMS IN THE DEPAUDE METHODOLOGY 61
- 0..n, this is the most general case in which no restriction on SRare given.
Customization of associations is shown in Figure 3.16(c): for example, the aggregation association defined be-tween classes A and B in the generic CD corresponds, in the customized CD, to the aggregation associations defined between classes A0and B0and between classes A0 and B00, respectively: multiplicity µ02of the former has been restricted to the interval [5, 10] while the other multiplicities remain unchanged with respect to the ones of the generic association.
Rule4 New application-specific classes, sub-classes and binary associations can be added to the CD cd0 pro-vided that the type of view remains the same of cd (i.e., either hierarchy/logical view or aggregation/logical view or class definition view). Indeed, we discourage to mix the hierarchy/logical and the aggregation/logical views since this could make the set of CDs more difficult to understand. Figure 3.16(c) shows an aggregation view preservation. Classes D and F have been added: C0is an aggregation of D and there is an association between C000 and F. Class E in hierarchy relation is instead not introduced in order to preserve the aggregation/logical view.
Rule5 While new specialization relationships can be added between customized classes and new application specific classes, the introduction of new specialization relationships between customized classes is discouraged.
For example, let ACF Site 1 and ACF Site 2 be two copies of the generic class Automation Communication Function and Inter-site ACF X be a copy of the generic class Inter-site Automation Communication Function, then we can specialize the class Inter-site ACF X by adding the new classes Inter-site ACF XX and Inter-site ACF XY but we don’t want class Inter-site ACF X be a specialization of both classes ACF Site 1 and ACF Site 2.
Syntactical Rule Whenever a class B is a sub-class (specialization) of class A in cd, then for each class B0in cd0 such that the value of its is-a attribute is B, there exists at most a super-class A0with its is-a attribute set to value A. Figure 3.16(b) shows the application of this rule: the application-specific class B00can not be a sub-class of both A0and A00.
3.2.1 Further considerations on the customization process
We have chosen to add the relationship is-a, implemented through an attribute for readability purposes, to realize the customization instead of using uniquely the CD specialization as it is done in [75] also in the context of requirement reuse for the reasons clarified in the following.
The UML manual [64] defines specialization/generalization relationship as the taxonomic relationship between a more general element (the parent class) and a more specific element (the child class) that is fully consistent with the first element and that adds additional information.
Customization could be seen as a specialization in OMT terms, that is to say the CD are extended with new, application specific classes that inherit the definition of the classes of the generic CD, but this is an approach that has proved too limited in our case. The diagrams of the scheme can represent aggregation structure or
B A
B
A A’
B’
B’’
(a) (b)
Figure 3.17: Customization of an aggregation view using specialization relationships.
inheritance hierarchy, plus some freely defined associations among classes. Consider the aggregation diagram of Figure 3.17(a), that is a super-simplified version of, for example, the CD Structure of Figure 3.2. For each generic class we can define one or more subclasses that specialize the class behavior for a given application.
Since associations among classes are inherited by the super-classes the resulting CD (Figure 3.17(b)) includes the generic classes and aggregation relations among them, as well as the application specific (sub)classes and the inherited aggregation relations. This seems a very good way of producing an instantiated diagram, but let us now consider the use of a hierarchical CD, in which the primary relation among classes is inheritance, as shown in Figure 3.18(a) (this could be considered, for example, as a super-simplified version of the CD Relationships of Figure 3.3). The two subclasses B and C represent a specialization of the superclass; as is the case of the CD Relationships of Figure 3.3, elaboration and communication functions can be distinguished. These subclasses can be further specialized into an application specific subclasses B0, B00 and C0,C00,C000 (in case of automation function the generic subclasses can be further distinguished in application-specific elaboration functions and in application-specific communication functions), resulting in the CD of Figure 3.18(b), but what happens if we
B A
(a) (b)
C B
A
C
B’ B’’ C’ C’’ C’’’
A’
?
Figure 3.18: Customization of a hierarchy view using specialization relationships.
CHAPTER 3. USE OF CLASS DIAGRAMS IN THE DEPAUDE METHODOLOGY 63
want to instantiate also the generic class A, the superclass, into an application dependent subclass A0 ? A new subclass is defined for the top level class that has now three subclasses, two of them “generic”, that really relate to sub-typing, the other application specific. When we apply this to the automation function case we end up with a situation in which the application specific automation function is not a superclass of the application specific communication or elaboration automation function, which is indeed not what we would like to have.
Moreover, as we will see in the next section for the PSAS case study, when customizing classes to obtain the application-specific CD scheme it is not always necessary to inherit all the attributes of a given generic class: so that the inheritance relationship used for customization is “partial” in contrast to the specialization/generalization relationship defined in [64].
Another problem caused by using inheritance as the unique customization mechanisms is that inheritance im-plies that the whole generic diagram gets into the final application diagram, while obviously it is not so, and indeed one of the step of the specialization is to define which classes, hierarchies, aggregations and associations are relevant for the application and should be included into the final scheme.