UML Strengthening Collaboration Diagrams by State Transformations
Reiko Heckel and Stefan Sauer
University of Paderborn, Dept. of Mathematics and Computer Science D-33095 Paderborn, Germany reiko|[e-mail]
Abstract. Collaboration diagrams as described in the official UML documents specify patterns of system structure and interaction. In this paper, we propose their use for specifying, in addition, pre/postconditions and state transformations of operations and scenarios. This conceptual idea is formalized by means of graph transformation systems and graph process, thereby integrating the state transformation with the structural and the interaction aspect.
Keywords: UML collaboration diagrams, pre/postconditions, graph transformation, graph process
1
Introduction
The Unified Modeling Language (UML) [24] provides a collection of loosely coupled diagram languages for specifying models of software systems on all levels of abstraction, ranging from high-level requirement specifications over analysis and design models to visual programs. On each level, several kinds of diagrams are available to specify different aspects of the system, like the structural, functional, or interaction aspect. But even diagrams of the same kind may have different interpretations when used on different levels, while several aspects of the same level may be expressed within a single diagram. For example, interaction diagrams in UML, like sequence or collaboration diagrams, often represent sample communication scenarios, e.g., as refinement of a use case, or they may be used in order to give a complete specification of the protocol which governs the communication. Collaboration diagrams allow, in addition, to represent individual snapshots of the system as well as structural patterns. If such multi-purpose diagrammatic notations shall be employed successfully, a precise understanding of their different aspects and abstraction levels is required, as well as a careful analysis of their mutual relations. This understanding, once suitably formalized, can be the basis for tool support of process models, e.g., in the form of consistency checks or refinement rules.
Research partially supported by the ESPRIT Working Group APPLIGRAPH.
In this paper, we address these issues for UML collaboration diagrams. These diagrams are used on two different levels, the instance and the specification level, both related to a class diagram for typing (cf. Fig. 1). A specification-level diagram provides a pattern which may occur at the instance level.1
role Specification pattern type Type type occurrence extension Instance
Fig. 1. Two levels of collaboration diagrams and their typing
In addition, in the UML specification [24] two aspects of collaboration diagrams are identified: the structural aspect given by the graph of the collaboration, and the interaction aspect represented by the flow of messages. These aspects are orthogonal to the dimensions in Fig. 1: A specification-level diagram may provide a structural pattern as well as a pattern of interaction. At the instance level, a collaboration diagram may represent a snapshot of the system or a sample interaction scenario. Moreover, both aspects are typed over the class diagram, and the pattern-occurrence relation should respect this typing. One way to make precise the relationships between different diagrams and abstraction levels is the approach of meta modeling used in the UML specification [24]. It allows to specify the syntactic relation between different diagrams (or different uses of the same diagram) by representing the entire model by a single abstract syntax graph where dependencies between different diagrams can be expressed by means of additional links, subject to structural constraints specifying consistency. This approach provides a convenient and powerful language for integrating diagram languages, i.e., it contributes to the question, how the integration can be specified. However, it provides no guidelines, what the intended relationships between different diagrams should be. Therefore, in this paper, we take the alternative approach of translating the diagrams of interest into a formal method which is conceptually close enough in order to provide us with the required semantic intuition to answer the what question. Once this is sufficiently understood, the next step is to formulate these results in the language of the UML meta model. Our formal method of choice are graph transformation systems of the socalled algebraic double-pushout (DPO) approach [10] (see [5] for a recent survey).
1
The use of collaboration diagrams for role modeling is not captured by this picture. A role model provides a refinement of a class diagram where roles restrict the features of classes to those relevant to a particular interaction. A collaboration diagram representing a role model can be seen as a second level of typing for instance (and specification-level) diagrams which itself is typed over the class diagram. For simplicity, herein we restrict ourselves to a single level of typing.
2
In particular, their typed variant [4] has built in most of the aspects discussed above, including the distinction between pattern, instance, and typing, the structural aspect and (by way of the partial order semantics of graph processes [4]) a truly concurrent model for the interaction aspect. The latter is in line with the recent proposal for UML action semantics [1] which identifies a semantic domain for the UML based on a concurrent data flow model. The direct interpretation of class and collaboration diagrams as graphs and of their interrelations as graph homomorphisms limits somewhat the scope of the formalization. In particular, we deliberately neglect inheritance, ordered or qualified associations, aggregation, and composition in class diagrams as well as multi-objects in collaboration diagrams. This oversimplification for presentation purpose does not imply a general limitation of the approach as we could easily extend the graph model in order to accommodate these features, e.g., using a meta model-based approach like in [21]. Along with the semantic intuition gained through the interpretation of collaboration diagrams in terms of graph transformation comes a conceptual improvement: the use of collaboration diagrams as a visual query and update language for object structures. In fact, in addition to system structure and interaction, we propose the use of collaboration diagrams for specifying the state transformation aspect of the system. So far, this aspect has been largely neglected in the standard documents [24], although collaboration diagrams are used already in the CATALYSIS approach [6] and the FUSION method [3] for describing preand postconditions of operations and scenarios. Beside a variety of theoretical studies, in particular in the area of concurrency and distributed systems [9], application-oriented graph transformation approaches like PROGRES [29] or FUJABA [14] provide a rich background in using rule-based graph transformation for system modeling as well as for testing, code generation, and rapid prototyping of models (see [7] for a collection of survey articles on this subject). Recently, graph transformations have been applied to UML meta modeling, e.g., in [16, 2, 11]. Therefore, we believe that our approach not only provides a clarification, but also a conceptual improvement of the basic concepts of collaboration diagrams. Two approaches which share the overall motivation of this work remain to be discussed, although we do not formally relate them herein. Overgaard [26] uses sequences in order to describe the semantics of interactions, including notions of refinement and the relation with use cases. The semantic intuition comes from trace-based interleaving models which are popular, e.g., in process algebra. Knapp [22] provides a formalization of interactions using temporal logic and the pomset (partially ordered multi-set) model of concurrency [27]. In particular, the pomset model provides a semantic framework which has much similarity with graph processes, only that pomsets are essentially set-based while graph processes are about graphs, i.e., the structural aspect is already built in. Besides technical and methodological differences with the cited approaches, the main additional objective of this work is to strengthen collaboration diagrams by incorporating graph transformation concepts. 3
The presentation is structured according to the three aspects of collaboration diagrams. After introducing the basic concepts and a running example in Sect. 2, Sect. 3 deals with the structural and the transformation aspect, while Sect. 4 is concerned with interactions. Section 5 concludes the paper. A preliminary sketch of the ideas of this paper has been presented in [20].
2
UML Collaboration Diagrams: A Motivating Example
In this section, we introduce a running example to motivate and illustrate the concepts in this paper. First, we sketch the use of collaboration diagrams as suggested in the UML specification [24]. Then, we present an improved version of the same example exploiting the state transformation aspect. Figure 2 shows the class diagram of a sample application where a Company object is related to zero or more Store, Order, and Delivery objects. Order objects as well as Delivery objects are related to exactly one Customer who plays the role of the customer placing the order or the receiver of a delivery, respectively. A Customer can place several instances of Order and receive an unrestricted number of Delivery objects.
Store Company + processOrder (o:Order) 1 1 1 * store - products[*]: Integer - amounts[*]: Integer + deliver(d:Delivery) + available(p:Integer, a:Integer): Boolean
Delivery * delivery - pNr: Integer - amount: Integer + Delivery (o:Order, s:Store) * order Order - pNr: Integer - amount: Integer * 1 customer * 1 receiver Customer + charge (d:Delivery)
Fig. 2. A class diagram defining the structure of the example
A typical scenario within that setting is the situation where a customer orders a product from the company. After the step of refining and combining different use cases into a method-oriented specification one might end up with a collaboration diagram specifying the implementation of operation processOrder as depicted in the top of Fig. 3. Here, the company first obtains the product number pNr and the ordered amount using defined access functions. It then checks all stores to find one that can supply the requested amount of the demanded product. A delivery is created, and the selected store is called to send it out. Concurrently, the customer is charged for this delivery. After an order has been processed, it will be deleted. Collaboration diagrams like this, which specifies the execution of an operation, may be used for generating method implementations in Java [12], i.e., they 4
can be seen as visual representations of programs. However, in earlier phases of development, a higher-level style of specification is desirable which abstracts from implementation details like the get functions for accessing attributes and the implementation of queries by search functions on multi-objects. Therefore, we propose to interpret a collaboration as a visual query which uses pattern matching on objects, links, and attributes instead of low-level access and search operations. In fact, leaving out these details, the same operation can be specified more abstractly by the diagram in the lower left of Fig. 3. Here, the calls to getPNr and getAmount are replaced by variables p and a for the corresponding attribute values, and the call of search on the multi-object is replaced by a boolean function available which constrains the instantiation of /s:Store. (As specified in the lower right of the same figure, the function returns true if the Store object matching /s is connected to a Product object with the required product number p and an amount b greater than a.) The match is complete if all items in the diagram not marked as {new} are instantiated. Then, objects marked as {destroyed} are removed from the current state while objects marked as {new} are created, initializing appropriately the attributes and links. For example, the new Delivery object inherits its link and attribute values from the destroyed Order object.
processOrder(o) :Company
3: s:= search(p,a) store 5a: deliver(d) s <<local>> :Store :Store
delivery :Delivery <<local>> {new} d
1: p:= getPNr() 2: a:= getAmount()
4: Delivery(o,s) :Customer
o :Order <<parameter>> {destroyed}
5b: charge(d) receiver
customer
processOrder(/o)
1:available(p,a) 2a:deliver(/d) /c:Company delivery store /s:Store
available(p,a) /s:Store
2b:charge(/d)
/o:Order {destroyed} pNr = p amount = a
/d:Delivery {new} pNr = p amount = a
product
:Product
pNr = p {b a} amount = b
customer
/cu:Customer
receiver
Fig. 3. An implementation-oriented collaboration diagram (top), its declarative presentation (bottom left), and a visual query operation (bottom right)
In the following sections, we show how this more abstract use of collaboration diagrams can be formalized by means of graph transformation rules and graph processes. 5
3
Collaborations as Graph Transformations
A collaboration on specification level is a graph of classifier roles and association roles which specifies a view of the classes and associations of a class diagram as well as a pattern for objects and links on the instance level. This triangular relationship, which instantiates the type-specification-instance pattern of Fig. 1 for the structural aspect, shall be formalized in the first part of this section. Then, the state transformation aspect shall be described by means of graph transformations. The interaction aspect is considered in the next section. Structure. Focusing on the structural aspect first, we use graphs and graph homomorphisms (i.e., structure-compatible mappings between graphs) to describe the interrelations between class diagrams and collaboration diagrams on the specification and the instance level. The relation between class and instance diagrams is formally captured by the concept of type and instance graphs [4]. By graphs we mean directed unlabeled graphs G = GV , GE , srcG , tarG with set of vertices GV , set of edges GE , and functions srcG : GE GV and tarG : GE GV associating to each edge its source and target vertex, respectively. A graph homomorphism f : G H is a pair of functions fV : GV HV , fE : GE HE compatible with source and target, i.e., for all edges e in GE , fV (srcG (e)) = srcH (fE (e)) and fV (tarG (e)) = tarH (fE (e)). Let T G be the underlying graph of a class diagram, called type graph. A legal instance graph over T G consists of a graph G together with a typing homomorphism g : G T G associating to each vertex and edge x of G its type g(x) = t in T G. In UML notation, we write x : t. Observe that the compatibility of g with source and target ensures that, e.g., the class of the source object of a link is the source class of the link's association. Constraints like this can be found in the meta class diagrams and well-formedness rules of the UML meta model for the meta associations relating classifiers with instances, associations with links, association ends with link ends, etc. ([24], Sect. 2.9). The typing of specification-level graphs is described in a similar way ([24], Sect. 2.10). An interpretation of a graph homomorphism which is conceptually different, but requires the same notion of structural compatibility, is the occurrence of a pattern in a graph. For example, a collaboration on the specification level occurs in a collaboration on the instance level if there exists a mapping from classifier roles to instances and from association roles to links preserving the connections. Thus, the existence of a graph homomorphism from a given pattern graph implies the presence of a corresponding instance level structure. The occurrence has to be type-compatible, i.e., if a classifier role is mapped to an instance, both have to be of the same classifier. This compatibility is captured in the notion of a typed graph homomorphism between typed graphs, i.e., a graph homomorphism which preserves the typing. In our collaboration diagrams, this concept of graphical pattern matching is used to express visual queries on object structures. In summary, class and collaboration diagrams have a homogeneous, graphlike structure, and their triangular relationship can be expressed by three com6
patible graph homomorphisms. Next, this triangular relation shall be lifted to the state transformation view. State Transformation. Collaborations specifying queries and updates of object structures are formalized as graph transformation rules, while corresponding collaborations on the instance level represent individual graph transformations. A graph transformation rule r = L R consists of two graphs L, R such that the union L R is defined. (This ensures that, e.g., edges which appear in both L and R are connected to the same vertices in both graphs.) Consider the rule in the upper part of Fig. 4 representing the collaboration of processOrder in the lower left of Fig. 3. The precondition L contains all objects and links which have to be present before the operation, i.e., all elements of the diagram except for /d:Delivery which is marked as {new}. Analogously, the postcondition R contains all elements except for /o:Order which is marked as {destroyed}. (The {transient} constraint does not occur because a graph transformation rule is supposed to be atomic, i.e., conceptually there are no intermediate states between L and R.)
/c:Company store /s:Store /o:Order pNr = p amount = a customer /cu:Customer /c.processOrder (/o)
/c:Company delivery store /s:Store /d:Delivery pNr = p amount = a receiver /cu:Customer
/
5
R_/
co/c:Company store st/s:Store product pr:Product co/c:Company store st/s:Store product pr:Product ce.processOrder (or) pNr = 13 amount = 42 or/o:Order pNr = 13 amount = 28 customer custo/cu:Customer pNr = 13 amount = 14 de/d:Delivery pNr = 13 amount = 28 receiver
R_5
*
+
delivery
custo/cu:Customer
Fig. 4. A graph transition consisting of a rule L R specifying the operation processOrder (top), and its occurrence o in an instance-level transformation (bottom)
A similar diagram on the instance level represents a graph transformation. Graph transformation rules can be used to specify transformations in two different ways: either operationally by requiring that the rule is applied to a given graph in order to rewrite part of it, or axiomatically by specifying pre- and postconditions. In the first interpretation (in fact, the classical one [10], in 7
set-theoretic formulation), a graph transformation G = H from a pre-state G to a post-state H using rule r is represented by a graph homomorphism o : L R G H, called occurrence, such that 1. o(L) G and o(R) H (i.e., the left-hand side of the rule is matched by the pre-state and the right-hand side by the post-state), 2. o(L \ R) = G \ H and o(R \ L) = H \ G (i.e., all objects of G are {destroyed} that match classifier roles of L not belonging to R and, symmetrically, all objects of H are {new} that match classifier roles in R not belonging to L). That is, the transformation creates and destroys exactly what is specified by the rule and the occurrence. As a consequence, the rule together with the occurrence of the left-hand side L in the given graph G determines, up to renaming, the derived graph H, i.e., the approach has a clear operational interpretation, which is well-suited for visual programming. In the more liberal, axiomatic interpretation, requirement 2 is weakened to 2 . o(L \ R) G \ H and o(R \ L) H \ G (i.e., at least the objects of G are {destroyed} that match classifier roles of L not belonging to R and, symmetrically, at least the objects of H are {new} that match classifier roles in R not belonging to L). These so-called graph transitions [19] allow side effects not specified by the rule, in like the example of Fig. 4 where the amount of product pr changes without being explicitly rewritten by the rule. This is important for high-level modeling where specifications of behavior are often incomplete. In both cases, instance transformations as well as specification-level rules are typed over the same type graph, and the occurrence homomorphism respects these types. This completes the instantiation of the type-specification-instance pattern for the aspect of state transformation. Summarizing, a collaboration on the specification level represents a pattern for state transformations on the instance level, and the occurrence of this pattern requires, beside the structural match of the pre- and postconditions, (at least) the realization of the described effects. Graph transformations provide a formal model for the state transformation aspect which allows to describe the overall effect of a complex interaction. However, the interaction itself, which decomposes the global steps into more basic actions, is not modeled. In the next section, this finer structure shall be described in terms of the model of concurrency for graph transformation systems [4].
r(o)
4
Interactions as Graph Processes
In this section, we shall extend the triangular type-specification-instance pattern to the interaction part. First, we describe the formalization of the individual concepts and then the typing and occurrence relations. 8
Class diagrams. A class diagram is represented as a graph transformation system, briefly GTS, G = T G, R consisting of a type graph T G and a set of transformation rules R. The type graph captures the structural aspect of the class diagram, like the classes, associations, and attributes, as well as the types of call and return messages that are sent when an operation is invoked. For the fragment of the class diagram consisting of the classes Order, Customer, and Delivery, the customer association2 , and the attributes and operations of the first two classes, the type graph is shown in Fig. 5. Classes are as usually shown as rectangular, data types as oval shapes. Call and return messages are depicted like UML action states, i.e., nodes with convex borders at the two sides. Return messages are marked by overlined labels. Links from call message nodes represent the input parameters of the operation, while links from return message nodes point to output parameters (if any). The self link points to the object executing the operation. The rules of the GTS in Fig. 5 model different kinds of basic actions that are implicitly declared within the class diagram. Among them are state transformation actions like destroy o, control actions like send charge, and actions representing the execution of an operation like cu.charge(d).
7*
,QWHJHU S1U 2UGHU DPRXQW FXVWRPHU
FKDUJH
&XVWRPHU VHOI
'HOLYHU\
G
FKDUJH
G'HOLYHU\
o:Order
GHVWUR\ R
FX&XVWRPHU
VHQG FKDUJH G
FX&XVWRPHU VHOI FKDUJH
G'HOLYHU\
FX&XVWRPHU VHOI FKDUJH FXFKDUJHG G'HOLYHU\
FX&XVWRPHU
G'HOLYHU\
G
FKDUJH
Fig. 5. Graph transformation system for a fragment of the class diagram in Fig. 2
Interactions. An interaction consists of a set of messages, linked by control and data flow, that stimulate actions like access to attributes, invocation of operations, creation and deletion of objects, etc. While the control flow is explicitly given by sequence numbers specifying a partial order over messages, data flow information is only implicitly present, e.g., in the parameters of operations and in their implementation, as far as it is given. However, it is important that control and data flow are compatible, i.e., they must not create cyclic dependencies.
2
More precisely, in UML terms this is an unnamed association in which class Customer plays the role customer.
9
Such constraints are captured by the concept of a graph process which provides a partial order semantics for graph transformation systems. The general idea of process semantics, which have their origin in the theory of Petri nets [28], is to abstract, in an individual run, from the ordering of actions that are not causally dependent, i.e., which appear in this order only by accident or because of the strategy of a particular scheduler. If actions are represented by graph transformation rules specifying their behavior in a pre/postcondition style, these causal dependencies can be derived by analyzing the intersections of rules in the common context provided by the overall collaboration.
product
product available self /s amount
processOrder
available start /c amount /o store pNr = p amount = a /s self /cu customer
p a
p a
available
p available a /s
/s /c
self
order
/o store pNr = p amount = a customer /cu
deliver self /s /d delivery
deliver
available
fork
deliver delivery
charge delivery
deliver
/s /d
/s
/d
/cu
self
/s /cu
/d
self
charge self /cu
available delivery /d
charge
charge
deliver charge
return
processOrder
/cu
/d
destroy /o /o
/c
new link delivery
/c delivery
/o receiver /cu
destroy link customer
/o
/d
new link receiver
/d receiver /cu
new /d
/d pNr = p amount = a
/d
/d
/cu
/cu
Fig. 6. Graph process for the collaboration diagram of operation processOrder. The three rules in the upper left section represent the operations, those in the upper right realize the control flow between these operations, and the five rules in the lower part are responsible for state transformations (note that attribute values a and p of /d can be instantiated by new /d since all the rules of the graph process act in a common context given by the collaboration)
The graph process for the collaboration diagram in the lower left of Fig. 3 is shown in Fig. 6. It consists of a set of rules representing the internal actions, placed in a common name space. That means, e.g., the available node created by the rule start in the top right is the same as the one deleted by the rule available in the top left. Because of this causal dependency, available has to be performed after start. Thus, the causality of actions in a process is represented by the overlapping of the left- and right-hand sides of the rules. 10
Graph processes are formally defined in three steps. A safe graph transformation system consists of a graph C (best to be thought of as the graph of the collaboration) together with a set of rules T such that, for every rule t = G H T we have G, H C (that is, C provides a common context for the rules in T ). Intuitively, the rules in T represent transformations, i.e., occurrences of rules. In order to formalize this intuition, the notion of occurrence graph transformation system is introduced requiring, in addition, that the transformations in T can be ordered in a sequence. That means, the system has to be acyclic and free of conflicts, and the causality relation has to be compatible with the graphical structure. In order to make this precise, we define the causal relation associated to a safe GTS C, T . Let t : G H be one arbitrary transformation in T and e be any edge, node, or attribute in C. We say that t consumes e if e G \ H t creates e if e H \ G t preserves e if e G H The relation is defined on T C, i.e., it relates both graphical elements and operations. It is the transitive and reflexive closure of the relation < where e < t1 if t1 consumes e t1 < e if t1 creates e t1 < t2 if t1 creates e and t2 preserves e, or t1 preserves e and t2 consumes e Now, a safe GTS is called an occurrence graph transformation system if the causal relation is a partial order which respects source and target, i.e., if t T is a rule and a vertex v of C is source (or target) of an edge e, then t v implies t e and v t implies e t for all elements x of C, x is consumed by at most one rule in T , and it is created by at most one rule in T . The objective behind these conditions is to ensure that each occurrence
GTS represents an equivalence class of sequences of transformations "up-to-
rescheduling", which can be reconstructed as the linearizations of the partial order . Vice versa, from each transformation sequence one can build an occurrence GTS by taking as context C the colimit (sum) of all instance graphs in the sequence [4]. The causal relation between the rules in the occurrence GTS in Fig. 6 is visualized by the Petri net in the left of Fig. 7. For example, the dependency between available and start discussed above is represented by the place between the corresponding transitions. Of these dependencies, which include both controland data-flow, in the UML semantics only the control-flow dependencies are captured by a precedence relation on messages, specified using sequence numbers. This part is presented by the sub-net in the upper right of Fig. 7. In comparison, the net in the lower right of Fig. 7 visualizes the control flow if we replace the 11
synchronous call to deliver by an asynchronous one: The call is delegated to a thread which consumes the return message and terminates afterwards. This strategy for modeling asynchronous calls might seem a little ad-hoc, but it follows the implementation of asynchronous calls in Java as well as the formalization of asynchronous message passing in process calculi [23]. The essential property is the independence of the deliver and the charge action.
new link delivery start new /d new link receiver start available fork deliver available fork deliver
charge
return
charge
return
deliver
ignore
destroy link customer
destroy o/
start available
fork
charge return
Fig. 7. Control flow and data dependencies of the occurrence GTS in Fig. 6 (left), sub-net for control flow dependencies of occurrence GTS (top right), and control flow dependencies with asynchronous call of deliver (bottom right)
We have used graph transformation rules for specifying both the overall effect of an interaction as well as its basic, internal actions. A fundamental fact about occurrence GTS [4] relates the state transformation with the interaction aspect: Given an occurrence GTS O = C, T and its partial order , the sets of minimal and maximal elements of C w.r.t. form two graphs Min(O), Max (O) C. This allows us to view a process p externally as a transformation rule (p), called total rule of p, which combines the effects of all the local rules of T in a single, atomic step. The total rule of the process in Fig. 6 is shown in the top of Fig. 4. Summarizing, the three corners of our triangle are represented by a GTS representing the type level, and two occurrence GTS formalizing interactions on the specification and the instance level, respectively. It remains to define the relation between these three levels, i.e., the concepts of typing and occurrence. Typing. In analogy with the typing of graphs, an occurrence GTS O = C, T is typed over a GTS G = T G, R via a homomorphism of graph transformation systems, briefly GTS morphism. A GTS morphism p : O G consists of a graph homomorphism c : C T G typing the context graph C over the type graph T G, and a mapping of rules f : T R such that, for every t T , the rules t and f (t) are equal up to renaming. Such a typed occurrence GTS is called a graph process [4]. Since all graphs in the rules of Fig. 6 are well-typed over the type graph T G, their union C is typed over T G by the union of the typing homomorphisms of its 12
subgraphs. The rules representing basic actions, like operation invocations and state transformations, can be mapped directly to rules in R. The control flow rules, which are more complex, are mapped to compound rules derived from the elementary rules in R.3 Occurrence. The occurrence of a specification-level interaction pattern at the instance level is described by a plain homomorphism of graph transformation systems: We want the same granularity of actions on the specification and the instance level. An example of an instance-level collaboration diagram is given in Fig. 8. It does not contain additional actions (although this would be permit1:available(13,28)...