Alloy:How to define the relations between two modules without the module dependency error? - alloy

Previously, I defined two simple signatures so that I can know which car does this wheel belong to.
sig Car{
wheels: some Wheel
}
sig Wheel{
BelongCar:one Car,
}{
BelongCar=this.~#wheels
}
However, when I put them into different modules, the analyzer will give the error "Circular dependency in module import". So how should I define the relations between Car and Wheels without the module dependency error?
\\in C.als
module C
open W
sig Car{
wheels: some Wheel
}
\\in W.als
module W
open C
sig Wheel{
BelongCar:one Car,
}{
BelongCar=this.~#wheels
}

As the error states, you try to open module W from module C which, in turns opens module W, which ...
To avoid this I can directly see 3 solutions, either:
Define wheel and car in a single module ( as the two concepts are intimately linked)
OR
define the relation between car and wheels in a third module.
In module C the concept of a car chassis ( without the notion of wheels )
In module W the concept of wheel is defined
In module X (which open C and W ), you can define the your concept of Car as being composed of Chassis and Wheels.
OR
Simply drop the BelongCar filed of the Wheel signature, as you can easily get this info from ~wheels...
We might be able to help you better if you tell us more about your requirements. Why the heck would you like to divide those two notions into two separate modules ?

Related

Does Graphviz support association classes?

I generated some UML diagrams with Graphviz. Now I would like to add association classes. Is this possible with Graphviz?
In Graphviz, there is no things to support UML. We should create them.
Try this (the most similar way to show Association-Class):
digraph hierarchy {
size="5,5"
node[shape=record,style=filled,fillcolor=ivory]
edge[dir=back, arrowtail=empty]
2[label = "{A|+ x\n+ y|...}"]
3[label = "{B|...| + method1()\l...}"]
4[label = "{C|...| + method2()\l...}"]
_23[shape=point label=""]
2-> _23 [dir=both arrowtail=none arrowhead=none]
_23 -> 3 [dir=both arrowtail=none arrowhead=none]
4 -> _23 [style=dotted arrowhead=none arrowtail=none]
}
see Online Demo
If you want an extension that support UML:
You can use PlantUML (see reference 2), the add-on for the Graphviz tool that allows you to write a textual definition of UML diagrams.
In PlantUML, you can work with all relationships between classes (see reference 3).

difference between RPG copybook and program

Could you give me some idea as to looking at file how can I differentiate between RPG copybook and program?
For example, in c, if you have main in the file, you know that it can be used as program.
Thanks in advance.
That's an interesting question...it is usually pretty obvious.
I suppose the quick answer is that copy books won't contain different types of specifications. An RPG IV program can have H, F, D, I, C, O, and P specifications , or their free-form equivalents. (The specification type is determined by the letter in column 6 of fixed format source). The order is important and you can't intermix the types. If you're looking at source that has only one type of specifications, it's probably designed as a copybook. Since the executable code is contained in C (Calculation) and/or P (Procedure) specs, a source without any C or P specs is a copybook. While it's usually bad practice to have C or P Specs in a copybook, RPG does allow it and I've seen it done. But again, the only thing in the copy book would be C or P specs.
EDIT You could have a copybook with for instance F & D specs, but the only place it could be included is at the end of a program's F specs prior to any D specs. You could have a copybook that makes use of compiler directives /IF DEFINED to control what part of the copybook is included where.
EDIT2 Turns out IBM added the ability to intermix F & D specs in version 7.1 and higher. A source member with just F & D specs would be a copybook So the short answer becomes, a source member with both definition (H, F, D, I, O) specs and executable (C & P) specs is designed to be compiled.
The longer answer, an RPG program also has a "main". Originally, the only option was what's known now as "cycle-main". IE. the "main" procedure is the implicitly generated "cycle" code that is built into RPG programs.
Then along came RPG IV and ILE. IBM added a control specification keyword, NOMAIN.
H NOMAIN
//or in freeform
ctl-opt nomain;
This resulted in a non-executable module without a "main" procedure; the code normally generated by the compiler for the "cycle" is left out. The resulting *MODULE object would need to be bound into a *PGM object with another *MODULE that provide a main procedure.
Or it could be bound with zero or more other *MODULE objects into a *SRVPGM object; *SRVPGM are just collections of procedures. Think of them like Windows DLLs.
Then IBM added the option of having a "linear-main" RPG IV program.
H MAIN(MYMAIN)
// or freeform
ctl-opt main(MYMAIN);
Thus the main procedure is whichever procedure you designate. The generated "cycle" code is again left out of the executable.
So the existence of either the NOMAIN or MAIN keywords would indicate that a source member is designed to be compiled; assuming there's more too the source. It's possible there's a "standard options" include file that would include one of those.
The lack of those two keywords would indicate you're dealing with either a cycle main or an include file.
If it's a cycle main program and it takes parameters as input, you'll be able to see the entry parameter list
//Fixed format, old school RPG III, IV
C *ENTRY PLIST
C PARM LCMPNO 2
C PARM LNTACT 1
// fixed format, RPG IV using a "Procedure Interface (PI) to replace *ENTRY PLIST
D CheckDate PI
D lDateIs 4a
// free format RPG IV
dcl-pi CheckDate;
lDateIs char(4);
end-pi;
Note that a key difference in the source between a "cycle-main" program that uses the PI instead of *ENTRY PLIST and a linear main is that a linear main procedure is surrounded by an explicit procedure definition.
// linear main
h main(CHECKDATE)
p CheckDate b
d CheckDate PI
d lDateIs 4a
//do something
*INLR = *ON
return;
p CheckDate e
//cycle main with PI
d lDateIs 4a
//do something
*INLR = *ON
return;
Starting in 7.1 (with the free-form PTFs from 2013), you can mix F and D specs (even in fixed form code).
rpg copy book is pretty close to imports in modern programing languages
A copy book should be used more like a header file in C or C++. Unfortunately it will not have that helpful .h extender to keep things separate. Shop standards can be helpful here. You can keep copybooks in a separate source file or even name them with a specific prefix or suffix to indicate that it is a copybook. I have seen suffixes like _ or _h used on copybooks where the base name is the same as the source member that it is acting as a header file for. Or in the case that copybooks and program source are stored in different source files, a program and it's header file would have the same name.
Like C, RPG4 can have source files that can be compiled into programs and source files that can be compiled into modules (a module is an IBM i term, much like a the unlinked .obj file generated by a C compiler on other platforms) or programs which are fully linked executables. In order for an RPG source to be compiled to a fully linked executable it needs a main procedure. Charles explained the main and nomain keywords for h specs. If the program source doesn't have the nomain keyword, it can be generated as a fully linked program. Be careful though, even though it isn't common, the h specs can be somewhere else, like in their own copybook, or in a dataarea.

Preprocessor in Haskell

I want to generate import qualified Aaaa.Bbb.Ccc as Ccc automatically at compile time.
Is there any way to do that? Maybe by Template Haskell or anyhow else with any extention? I think it's similar to macroses in C and the function $(...) in Tempalte Haskell.
If what you are trying to achieve is shortening your import list, you may try the following trick. Create a new module (Foo):
module Foo (module X) where
import A as X
import B as X
import C as X
Then import this module to get all members of A, B, and C:
module Bar where
import qualified Foo as X
This way you can combine modules which are commonly used throughout your project.
If you still need to auto-generate the imports, at least you only need to generate module Foo, but not Bar. So the automatically and manually generated code is separated cleanly.

Merging packages in UML 2 packages diagram

How do merging packages on uml packages diagrams exactly work? I couldn't find any straightforward explanation neither in books nor in the internet.
I mean, let's say that package A merges package B. What would be the result? Package A having all its elements + the elements from package B?
What if there are two classes with the same name though?
Following your example, the result of the merge would be new classes in package A. Package B is not affected.
For each class "Class" in B, we have the following procedure depending if the class with the same name exists in A:
class "Class" does not exist in A. A new class "Class" is created in A, as derived from the class "Class" in B. So, a simple generalization is done.
class "Class" already exists in A. Then, the existing class "Class" (from A) is extended by the features from the class "Class" in B, including methods, attributes and associations. The new class "Class" is therefore obtained by deriving the class "Class" from A from class "Class" in B.
In order to respect the constraints while merging, the packages name of the merged classes will be changed for instance package A; then all the attributes and methods will also migrate to the class which has the same signature.

Vocabulary: path in a graph of objects?

I'm having trouble with the following sentence:
DeepClone performs a deep clone of
the target object, stopping the cloning process
when all <dependency paths> have
reached a value type or an ITransactionalObject.
What I mean by "dependency path" is the chain of references you follow in the cloning process: object A has a reference to B, B to C, C to D,... and N to an ITransactionalObject, and then you stop there and don't clone the ITransactionalObject. Then you go back to M and follow that path, and so on, until all branches run into value types or ITransactionalObjects.
What term would you use rather than dependency path? I have the feeling there must already be a name for it.
Thanks :)
Path is the standard term for a walk through a graph, so unless you want to add more domain-specific terminology I think that's okay.
You could say "... until the dependency tree is fully resolved (i.e. all paths have terminated in ITransactionalObjects or value types)".

Resources