User Tools

Site Tools


v070:language

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
v070:language [2018/10/08 10:24]
djnemeth [Associations]
v070:language [2018/10/08 16:15] (current)
djnemeth [Collections]
Line 203: Line 203:
 According to UML, the multiplicity of the //​container//​ end is implicitly ''​0..1'',​ the multiplicity of the other end can be arbitrarily defined. Both ends can be either navigable or non-navigable:​ The container end can be made non-navigable by writing ''​hidden container''​ in XtxtUML or extending ''​HiddenContainerEnd''​ in JtxtUML. According to UML, the multiplicity of the //​container//​ end is implicitly ''​0..1'',​ the multiplicity of the other end can be arbitrarily defined. Both ends can be either navigable or non-navigable:​ The container end can be made non-navigable by writing ''​hidden container''​ in XtxtUML or extending ''​HiddenContainerEnd''​ in JtxtUML.
  
 +==== Collections ====
 +
 +Collections in txtUML are represented by its own [[http://​txtuml.inf.elte.hu/​releases/​txtuml-v070/​api/​java/​hu/​elte/​txtuml/​api/​model/​GeneralCollection.html|Collection Framework]]. All txtUML collections are immutable and therefore thread-safe. For each collection //type//, ordering, uniqueness and multiplicity can be specified. ​
 +
 +Currently, the following collection types are pre-defined:​
 +  * ''​Any'':​ unordered, non-unique, 0..*
 +  * ''​OrderedAny'':​ ordered, non-unique, 0..*
 +  * ''​UniqueAny'':​ unordered, unique, 0..*
 +  * ''​OrderedUniqueAny'':​ ordered, unique, 0..*
 +  * ''​OneToAny'':​ unordered, non-unique, 1..*
 +  * ''​OrderedOneToAny'':​ ordered, non-unique, 1..*
 +  * ''​UniqueOneToAny'':​ unordered, unique, 1..*
 +  * ''​OrderedUniqueOneToAny'':​ ordered, unique, 1..*
 +  * ''​One'':​ 1..1 (ordering and uniqueness not applicable)
 +  * ''​ZeroToOne'':​ 0..1 (ordering and uniqueness not applicable)
 +
 +Additionally,​ in JtxtUML, custom collections can also be defined in the following format:
 +
 +<code java>
 +@Min(lower)
 +@Max(upper)
 +class MyCollection<​T>​ extends Scheme<​T,​ MyCollection<​T>>​ {}
 +</​code>​
 +
 +In this template, you have to fill in the following placeholders:​
 +  * ''​lower'':​ lower multiplicity bound as integer, if omitted: 0
 +  * ''​upper'':​ upper multiplicity bound as integer, if omitted: infinity
 +  * ''​Scheme'':​ one of the following:
 +    * ''​Collection'':​ unordered, non-unique
 +    * ''​OrderedCollection'':​ ordered, non-unique
 +    * ''​UniqueCollection'':​ unordered, unique
 +    * ''​OrderedUniqueCollection'':​ ordered, unique
 +
 +For example, the definition of the built-in ''​OrderedOneToAny''​ collection type would look like this:
 +
 +<code java>
 +@Min(1) // @Max omitted to represent infinity as the upper bound
 +class OrderedOneToAny<​T>​ extends OrderedCollection<​T,​ OrderedOneToAny<​T>>​ {}
 +</​code>​
 +
 +Naturally, you can also concretize type parameter ''​T''​ in the definition to obtain a non-generic collection type. Defining custom collections is not possible in //XtxtUML// yet. See section [[v070:​language#​Collection operations]] for usage examples.
 ==== Model enums ==== ==== Model enums ====
  
Line 253: Line 294:
   public boolean b;   public boolean b;
 } }
 +
 +signal DerivedSignal extends ExampleSignal { /* ... */ }
 </​code>​ </​code>​
  
-In //​XtxtUML//,​ only signal parameters are allowed inside a signal definition, from which a constructor is going to be inferred. Signal inheritance is not yet supported in //XtxtUML//.+In //​XtxtUML//,​ only signal parameters are allowed inside a signal definition, from which a constructor is going to be inferred.
  
 <code java> <code java>
Line 368: Line 411:
 // JtxtUML: // JtxtUML:
 class ExampleComposition extends Composition { class ExampleComposition extends Composition {
-  class a extends ​Container<A> {} +  class a extends ​ContainerEnd<A> {} 
-  class b extends One<​B>​ {}+  class b extends ​End<One<B>> {}
 } }
 </​code>​ </​code>​
Line 606: Line 649:
 A obj3 = create A(p1, ..., pn) as "​name3";​ A obj3 = create A(p1, ..., pn) as "​name3";​
 A obj4 = new A(p1, ..., pn) as "​name4";​ A obj4 = new A(p1, ..., pn) as "​name4";​
 +  // names appear in logs
 </​code>​ </​code>​
  
Line 612: Line 655:
 // JtxtUML: // JtxtUML:
 // With parameters p1, ..., pn. // With parameters p1, ..., pn.
-obj = Action.create(A.class,​ p1, ..., pn);+obj1 = Action.create(A.class,​ p1, ..., pn); 
 +A obj2 = Action.createWithName(A.class,​ "​name2",​ p1, ..., pn); 
 +  // names appear in logs
 </​code>​ </​code>​
  
Line 631: Line 676:
 <​code>​ <​code>​
 // XtxtUML: // XtxtUML:
-link(AB.a, instanceOfA,​ AB.b, instanceOfB);​ 
  
 +// Explicit version:
 link instanceOfA as AB.a, instanceOfB as AB.b via AB; link instanceOfA as AB.a, instanceOfB as AB.b via AB;
-// as is optional and can be ommited if association ends can be infered.+ 
 +// Short version:
 link instanceOfA,​ instanceOfB via AB; link instanceOfA,​ instanceOfB via AB;
 +  // '​as'​ parts are optional and can be omitted
 +  // if matching ends are inferrable.
  
 // In case of the following association definition: // In case of the following association definition:
Line 650: Line 698:
 // In case of the following association definition: // In case of the following association definition:
 class AB extends Association { class AB extends Association {
-  class a extends ​Some<A> {} +  class a extends ​End<​OneToAny<A>> {} 
-  class b extends ​Some<B> {}+  class b extends ​End<​OneToAny<B>> {}
 } }
 </​code>​ </​code>​
Line 659: Line 707:
 <​code>​ <​code>​
 // XtxtUML: // XtxtUML:
 +// Explicit version:
 unlink instanceOfA as AB.a, instanceOfB as AB.b via AB; unlink instanceOfA as AB.a, instanceOfB as AB.b via AB;
-// Or+ 
 +// Short version:
 unlink instanceOfA,​ instanceOfB via AB; unlink instanceOfA,​ instanceOfB via AB;
 +  // '​as'​ parts are optional and can be omitted
 +  // if matching ends are inferrable.
 </​code>​ </​code>​
  
Line 673: Line 725:
 <​code>​ <​code>​
 // XtxtUML: // XtxtUML:
-Collection<B> all = instanceOfA->​(AB.b);​ // the parentheses after -> are mandatory +OneToAny<B> all = instanceOfA->​(AB.b);​ // the parentheses after -> are mandatory 
-B obj = all.selectAny();+B obj = all.one();
 </​code>​ </​code>​
  
 <code java> <code java>
 // JtxtUML: // JtxtUML:
-Collection<B> all = instanceOfA.assoc(AB.b.class);​ +OneToAny<B> all = instanceOfA.assoc(AB.b.class);​ 
-B obj = all.selectAny();+B obj = all.one();
 </​code>​ </​code>​
  
-Note: even in //​XtxtUML//,​ the ''​selectAny()''​ call can be performed directly on the navigation expression:+Note: even in //​XtxtUML//,​ the ''​one()''​ call can be performed directly on the navigation expression:
  
 <​code>​ <​code>​
 // XtxtUML: // XtxtUML:
-B obj = instanceOfA->​(AB.b).selectAny();+B obj = instanceOfA->​(AB.b).one(); 
 +</​code>​ 
 + 
 +=== Collection operations === 
 + 
 +<​code>​ 
 +// XtxtUML: 
 +B b1 = create B(); 
 +B b2 = create B(); 
 + 
 +Any<​B>​ bs = collect(b1, b2); 
 +bs.one(); // b1 or b2, bs is not ordered 
 + 
 +Any<​B>​ bs2 = bs.add(create B()); 
 +bs2.size(); // 3 
 +bs.size(); // 2, txtUML collections are immutable 
 + 
 +OrderedAny<​B>​ obs = collectIn(OrderedAny,​ b1, b2); 
 +obs.one(); // b1, obs is ordered 
 + 
 +bs = obs.^as(Any);​ // '​as'​ has to be escaped 
 +  // target type is less restrictive,​ no problem 
 + 
 +UniqueAny<​B>​ ubs = collectIn(UniqueAny,​ b1, b1); 
 +ubs.size(); // 1, ubs is unique 
 +   
 +// Runtime error examples: 
 +//   - multiplicity violation 
 +//   - calling one() on empty collection 
 +//   - unordered -> ordered conversion 
 +//   - non-unique -> unique conversion 
 +</​code>​ 
 + 
 +<code java> 
 +// JtxtUML: 
 +B b1 = Action.create(B.class);​ 
 +B b2 = Action.create(B.class);​ 
 + 
 +Any<​B>​ bs = Action.collect(b1,​ b2); 
 +bs.one(); // b1 or b2, bs is not ordered 
 + 
 +Any<​B>​ bs2 = bs.add(Action.create(B.class));​ 
 +bs2.size(); // 3 
 +bs.size(); // 2, txtUML collections are immutable 
 + 
 +OrderedAny<​B>​ obs = Action.collectIn(OrderedAny.class,​ b1, b2); 
 +obs.one(); // b1, obs is ordered 
 + 
 +bs = obs.as(Any.class);​ 
 +  // target type is less restrictive,​ no problem 
 + 
 +UniqueAny<​B>​ ubs = Action.collectIn(UniqueAny.class,​ b1, b1); 
 +ubs.size(); // 1, ubs is unique 
 +   
 +// Runtime error examples: 
 +//   - multiplicity violation 
 +//   - calling one() on empty collection 
 +//   - unordered -> ordered conversion 
 +//   - non-unique -> unique conversion
 </​code>​ </​code>​
  
Line 694: Line 804:
 <​code>​ <​code>​
 // XtxtUML: // XtxtUML:
-connect aObj->​(A.P),​ bObj->​(B.Q) via CAB; +Explicit version: 
-connect aObj->​(A.P) as CAB.e, bObj->​(B.Q) via CAB; +connect ​instanceOfA->(A.P) as CAB.e, ​instanceOfB->(B.Q) as CAB.f via CAB;
-connect aObj->​(A.P),​ bObj->​(B.Q) as CAB.f via CAB; +
-connect ​aObj->(A.P) as CAB.e, ​bObj->(B.Q) as CAB.f via CAB;+
  
-//In case of the following connector+Short version: 
 +connect instanceOfA->​(A.P),​ instanceOfB->​(B.Q) via CAB; 
 +  // '​as'​ parts are optional and can be omitted 
 +  // if matching ends are inferrable. 
 + 
 +// In case of the following connector ​definition:
 connector CAB { connector CAB {
- CA.a->​A.P e; +  ​CA.a->​A.P e; 
- CB.b->​B.Q f;+  CB.b->​B.Q f;
 } }
 </​code>​ </​code>​
Line 710: Line 823:
 Action.connect(CA.e.class,​ aObj.port(A.P.class),​ Action.connect(CA.e.class,​ aObj.port(A.P.class),​
                ​CB.f.class,​ bObj.port(B.Q.class));​                ​CB.f.class,​ bObj.port(B.Q.class));​
 +
 +// In case of the following connector definition:
 +class CAB extends Connector {
 +  class e extends One<​CA.a,​ A.P>;
 +  class f extends One<​CB.b,​ B.Q>;
 +}
 </​code>​ </​code>​
  
Line 752: Line 871:
 // XtxtUML: // XtxtUML:
 log "​message";​ log "​message";​
-log-error "Error message";​+log-error "error message";​
 </​code>​ </​code>​
  
Line 758: Line 877:
 // JtxtUML: // JtxtUML:
 Action.log("​message"​);​ Action.log("​message"​);​
-Action.logError("​Error message"​);​+Action.logError("​error message"​);​
 </​code>​ </​code>​
  
Line 767: Line 886:
   * while,   * while,
   * for.   * for.
 +
 +==== External elements ====
 +
 +To keep txtUML models compliant to the UML standard, several limitations have to be considered during modeling. ​ In some cases, however, it is not desired or even possible to define a functionality using the tools of UML exclusively. To address this problem, we offer the concept of //​externals//​.
 +
 +A model element marked as external is invisible for the rest of the model. You can use any Java features inside, but that part of the model can't be referenced internally, validated, exported, visualized or translated to other languages. Currently, attributes, operations, operation bodies (both in XtxtUML and JtxtUML), types and super declarations (JtxtUML only) can be marked as external.
 +
 +<​code>​
 +// XtxtUML:
 +
 +// Class B is part of the model,
 +// but it may have externals inside.
 +class B {
 +  // Attribute a is invisible in the model.
 +  external Anything a;
 +
 +  // Operation op1 is invisible in the model.
 +  external void op1(Anything a) { /* ... */ }
 +
 +  // The signature of op2 is visible in the model,
 +  // but its body is not part of the model.
 +  external-body void op2(int i) { /* ... */ }
 +}
 +</​code>​
 +
 +<code java>
 +// JtxtUML:
 +
 +// Class A is not visible in the model,
 +// but it can be placed in a model package for convenience.
 +@External
 +class A extends Anything {}
 +
 +// Class B is part of the model,
 +// but it may have externals inside.
 +class B extends ModelClass implements @External Anything {
 +  // Attribute a is invisible in the model.
 +  @External
 +  Anything a;
 +
 +  // Operation op1 is invisible in the model.
 +  @External
 +  void op1(Anything a) { /* ... */ }
 +
 +  // The signature of op2 is visible in the model,
 +  // but its body is not part of the model.
 +  @ExternalBody
 +  void op2(int i) { /* ... */ }
 +}
 +</​code>​
v070/language.1538987092.txt.gz · Last modified: 2018/10/08 10:24 by djnemeth