My system is still at the concept stage, but I'm creating a Deployment Diagram to focus discussions about the end result. The system will have some run-time subroutine libraries. At at this stage there is no way to know how many there will be: in fact the number may never stabilize, since it will depend on various other aspects of the system.
A library is an artifact with stereotype "library" in guillemets. Several ways to diagram the unknown number come to mind:
Show one library, with a note attached saying that the number of libraries is unknown
Put an asterisk at the upper right of the library artifact, as with composite structure diagrams
Draw a slanted stack of overlapping artifacts
Don't diagram them individually: just list "library 1, library 2, library 3..."
Use a "manifest" relationship a between an artifact and an asterisked-component.
And there must be lots of other creative possibilities.
Does anyone know if there's a UML-prescribed way to show this unknown number of libraries on a Deployment Diagram, and if so, what it is?
I think you need to separate your logical Deployment Model (abstract) that shows classes of Artefacts, Components, Nodes etc. from your physical Deployment Model(s) (concrete) that show specific instances of those Artefacts, Components and Nodes etc. At the logical level, you could show an abstract Artefact called "Library" that has associations with plural multiplicities to Nodes, Components etc. in your logical design. Then, you could specialise that abstract Artefact, and at the concrete Deployment Model(s) level, create instances of these Library specialisations that are associated with instances of Nodes, Components etc.
Something like:
Related
My questions is about bringing a concept to reality through technical availability of EA.
I am looking for a way to connect instances at an object diagram through which I can transfer tagged values. Let me explain the background of the project.
Purpose is to first have Stereotypes for specific roles in the system, such as "Calculation", "Transmission", "Decision", "Qualification", "Abstraction" etc.
Each of these stereotypes have specific tagged values suitable for their purpose.
Then I am creating instances from these stereotypes, eg. "MotorTorque:Calculation" and "LimitedTorque:Abstraction"
Each of these instances have a common tagged value, "criticality", boolean and I want this tagged value to progress from "MotorTorque:Calculation" to "LimitedTorque:Abstraction" through an output port > some sort of flow > input port kind of way.
Questions are:
1- Is this approach technically achievable in EA? If so what would be the correct way to do it?
2- The purpose is to have this "connection" readable in XMI export of the diagram which I will be using as an input for another purpose.
I have created an MDG Technology for my project with stereotypes and tagged values, however, I am having difficulty achieving this "connection", this "flow" of values.
Thank you for your time.
What you are asking for is not directly achievable. However, many ways lead to Rome.
One way would be to <<trace>> connect those objects to a Status class (or what ever you like to name it) and have this carry the "shared TV".
Another way is (by far more complex) to use an add-in. You would anyway need ways to create groups which share the TV. From your current explanation I can't see what that might be. Maybe the instantiating class of those instances? If so, you make a script that propagates a TV setting from ist current to all other linked instances. I'm not sure if the add-in events fire when a TV is changes (I do have some doubts here). If needed I could look that up.
What you propose is partially feasible.
There is a tagged value inheritance chain in EA, in which tagged values are inherited down the generalization chain, and from a classifier to its instances. In the GUI, inherited tagged values are shown separately from the instance's own ones, and in the API they are accessed using the Element.TaggedValuesEx property. Inherited tagged values can also be overridden.
Since the correct way to create a port (or part/property) is to make it an instance of a component, a port will inherit any tagged values from that component. So if your Calculation stereotype applies to component, ports which are instances of Calculation components will inherit the MotorTorque tagged value.
However, there is no way to "flow" tagged values from one port to another. If you want such a function, you'll have to implement it yourself with an Add-In.
Regarding XMI, first you must understand that an XMI export is based on a package, not a diagram. The XMI format itself is extensible, which means that different tool vendors create their own extensions which are typically not publicly documented. Crucially, diagram layouts are part of these non-standardized extensions. In EA's case, the image data is some sort of UU-encoded bitmap which you won't be able to extract any useful information from.
Elements' tagged values are included in an XMI export, but again, the EA extensions are not publicly documented. In other words, you can import EA:s XMI format in another program, but you will need to reverse-engineer the format. Not impossible, but it's probably better to either write your own specialized export function, or export via CSV. Note, however, that CSV export cannot be automated -- there's no call for it in the API.
What is the rationale behind Branch and Merge using the same symbol?
I find it confusing, because you can't rely on the shape to know whether there's a conditional going on or not.
Is there some other standard symbol or symbol variation I can use? I would rather avoid connecting many arrows to the same endpoint, because it makes it difficult to follow the diagram. But I'd also like to differentiate between conditionals and merge points.
Note that this question has nothing to do with Fork and Join, which deal with concurrency and are represented by a black rectangle.
The reason probably is that you are allowed to combine the two in a single node.
UML 2.5 specs state:
The functionality of a MergeNode and a DecisionNode can be combined by using the same node symbol, as shown in Figure 15.34. At most one of the incoming flows may be annotated as a decisionInputFlow. This notation maps to a model containing a MergeNode with all the incoming edges shown in the diagram and one outgoing edge to a DecisionNode that has all the outgoing edges shown in the diagram.
Whilst evaluating NDepend I attached a NDepend project to all the Visual Studio projects that comprise our company's software suite. Particularly striking is the result of the Abstractness vs Instability graph. Almost all of the projects are crammed into the bottom-right corner of the graph, indicating a very high level of "instability".
The NDepend documentation's definition of instability is:
The ratio of efferent coupling (Ce) to total coupling. I = Ce / (Ce + Ca). This metric is an indicator of the assembly's resilience to change. The range for this metric is 0 to 1, with I=0 indicating a completely stable assembly and I=1 indicating a completely instable assembly.
However, I have been unable to find a clear definition of "resilience to change" in this context. Would anyone like to try to produce a definition?
Added
Obviously, the sentence in which "resilience to change" appears gives a loose definition of this concept as the "ratio of efferent coupling (Ce) to total coupling". But that leaves open the question of what the significance of this ratio is and how it relates to change.
See the documentation in report. stable means painful to modify hence instable is a positive things, it means it can be changed with few pain, it means the assembly is resilient to changes.
Excerpt from the documentation in the report: Abstractness versus Instability Diagram
The Abstractness versus Instability Diagram helps to detect which assemblies are potentially painful to maintain (i.e concrete and stable) and which assemblies are potentially useless (i.e abstract and instable).
Abstractness: If an assembly contains many abstract types (i.e interfaces and abstract classes) and few concrete types, it is considered as abstract.
Stability: An assembly is considered stable if its types are used by a lot of types of tier assemblies. In this conditions stable means painful to modify.
This is the scenario.
There are three components, A, B and C.
Component A can access methods of component B.
Component B can access methods of component A and component C.
Component C can access methods of component B.
To implement this scenario how many interface description language (IDL) files are needed? How many stubs and skeletons do we require?
I was thinking four IDL files. But can we have multiple stubs and skeletons?
Depending on the size of your services/components (number of methods), I would rather try to split them into logical units rather than based on the number of computers you want to connect.
For example, it can make sense to have two different services implemented by the same server: One for internal purposes and one that is to be published. Or a service is split into two parts, because these two parts do not really belong together logically, although they are for some reason implemented by the same component. All of these services may or may not share the same IDL file.
Last not least, if you still want to minimize the amount of files, keep in mind that declaring, publishing and knowing about a certain service interface does not imply, that a given component must implement the service, must be able to reach the service, wants to use the service, or is allowed to call it.
I am implementing my first Spring-Batch application. In the naming of the packages, the Samples project names each domain in its own package with readers-writers-processors all in one package for the respective domain (i.e. football game). Is that typical?
Say, for example, I have jobs to read-process-write for 10 different flat files. Should I have 10 different packages with each package containing the readers-processors-writers for each respective file/job?
Or, could it be equally reasonable to have one 'readers' package for all the readers, and a 'processors' package for all the processors, and a 'writers' package for all writers.
I'm interfacing with an SAP system, and over time, the number of files we process will grow. So, I'm trying to get a smarter handle on what's better, in terms of naming and organizing my packages. And, I want to do it the way the Spring-Batch community would do it.
Thanks.
I would use the first solution,but perhaps adding an extra package for complex jobs containing many steps, for example: com.company.software.batch.jobName.stepName
Then you will have a clear functional view of all your jobs.