This question will treat software like a tree, where:
Each node in the tree represents some code unit (eg class \ method \ line etc.)
Node X is son of Node Y if in the source code X is set in Y
Here is the definition of the term T:
T relative to Node X is the probability that any change on X will result changes in nodes that are within the sub-tree of X.
What is the term T? Cohesion or Coupling ?
Coupling would be horizontal, across nodes. Cohesion would be vertical, within the same tree.
So T would be cohesion.
Two separate modules, loosely coupled, would be in separate subtrees, and a change in one would not affect the other. But if tightly coupled, a change in one might require a change in the other, even though they are in separate subtrees. Obviously this cannot be what T is.
Cohesion: It is an intra-module concept and indicates relationships within modules.
Coupling: It is an inter-module concept and indicates relationships among modules.
In order to ensure a balanced flexibility and rigidity of any system or software, coupling and cohesion should be balanced.
See this reference for more details.
Related
I am trying to represent my program in a UML diagram. I have 2 classes as below:
Mesh.h
class Mesh
{
public:
Mesh();
~Mesh();
VertexArrayObject* vao;
};
VertexArrayObject.h
class VertexArrayObject
{
public:
VertexArrayObject(Mesh* mesh);
~VertexArrayObject();
Mesh* mesh;
};
I'd imagine it'd be drawn like this:
However that doesn't look right at all. How is it best to represent a relationship where both classes have references to each other using UML?
No. That's plain wrong. Composite aggregation can only be on one side. (Imagine the car/wheel example: each aggregating the other is nonsense.) Remove the diamonds and you're done.
You can go further and put dots instead of the diamonds. That will mean that both sides have attributes referring the class at the other side. See this answer.
This depends a lot on what the logical construct is you are wanting to represent. You could specify the relationship between Mesh and Vertex in many ways and get the message across; what I understand from the model you have posted is that you think composition may be an important aspect of the relationship, e.g. Vertex is a composite part of Mesh (or vice versa).
In UML you can’t really have a bidirectional composition since this leads to a logical paradox — I.e. you cant simultaneously have two classes that are at the same time both composite parts of each other. If composition is important then you will need to choose which is composed of which.
Given my (poor) understanding of 3D (I guess that’s what your program is about), I would assume that a Mesh includes a collection of Verticies, so the composition would run from the Vertex type to the Mesh type with the solid diamond at the Mesh end. You might also want to add multiplicities (so that it is obvious that multiple Vertex may exist within the Mesh) and also consider whether the relationship is composite or a shared aggregate (can a Vertex exist outside a Mesh? If so a shared aggregate (white diamond) is needed).
You probably don’t need to represent the relationship from Mesh to Vertex, as this is an implementation detail that may be safely abstracted away in UML. The fact that you’re using a pointer to an array is probably not relevant to the logic that Mesh is composed of many Vertex.
That said, if you do want to specify what you have in code precisely then this can be done in UML. I would recommend abstracting out the Array of Vertex from Vertex — there are three logical types in your code — Mesh, Vertex and VertexArray. You might illustrate Mesh having a basic association with VertexArray (with an arrow to identify direction of reference), and this in turn being composed of Vertex (black diamond at VertexArray end).
Of course, I am assuming that VertexArray represents an array of Vertex objects, not a single Vertex!
For my understanding, the ApplicationDataType was introduced to AUTOSAR Version 4 to design Software-Components that are independent of the underlying platform and are therefore re-usable in different projects and applications.
But how about the implementation behind such a SW-C to be platform independent?
Use-case example: You want to design and implement a SW-C that works as a FiFo. You have one Port for Input-Data, an internal buffer and one Port for Output-Data. You could implement this without knowing about the data type of the data by using the “abstract” ApplicationDataType.
By using an ApplicationDataType for a variable as part of a PortInterface sooner or later you have to map this ApplicationDataType to an ImplementationDataType for the RTE-Generator.
Finally, the code created by the RTE-Generator only uses the ImplementationDataType. The ApplicationDataType is nowhere to be found in the generated code.
Is this intended behavior or a bug of the RTE-Generator?
(Or maybe I'm missing something?)
It is intended that ApplicationDataTypes do not directly appear in code, they are represented by their ImplementationDataType counterparts.
The motivation for the definition of data types on different levels of abstraction is explained in the AUTOSAR specifications, namely the TPS Software Component Template.
You will never find an ApplicationDataType in the C code, because it's defined on a physical level with a physical unit and might have a (completly) different representation on the implementation level in C.
Imagine a battery control sensor that measures the voltage. The value can be in range 0.0V and 14.0V with one digit after the decimal point (physical). You could map it to a float in C but floating point operations are expensive. Instead, you use a fixed point arithmetic where you map the phyiscal value 0.0 to 0, 0.1 to 1, 0.2 to 2 and so on. This mapping is described by a so called compuMethod.
The software component will always use the internal representation. So, why do you need the ApplicationDataType then? There are many reasons to use them, some of them are:
Methodology: The software component designer doesn't need to worry about the implementation in C. Somebody else can define that in a later stage.
Measurement If you measure the value, you have a well defined compuMethod and know the physical interpretation of the value in C.
Data conversion: If you connect software component with different units e.g. km/h vs mph, the Rte could automatically convert the internal representation between them.
Constant conversion: You can specify an initial value on the physical value (e.g. 10.6V) and the Rte will convert it to the internal representation.
Variable Size Arrays: Without dynamic memory allocation, you cannot have a variable size array in C. But you could reserve some (max) memory in an array and store the actual length in a seperate field. On the implementation level you have then a struct with two members (value, length). But on the application level you just have an array.
from AUTOSAR_TPS_SoftwareComponentTemplate.pdf
ApplicationDataType defines a data type from the application point of
view. Especially it should be used whenever something "physical" is at
stake.
An ApplicationDataType represents a set of values as seen in the
application model, such as measurement units. It does not consider
implementation details such as bit-size, endianess, etc.
It should be possible to model the application level aspects of a VFB
system by using ApplicationDataTypes only.
I'm looking for the right keywords/nomenclature for the following problem, since I cannot find anything on google to this topic:
I have a graph where each edge and each node is assigned to a certain class/color or whatever you call it. Now I want to find a path between a start and a goal node, having some constraints on the path. For example I'd like to have as less "blue" nodes on the path as possible, or max. 2 "red" edges, or a combination of those things. Of course there are also the usual edge costs, which have to be minimized in addition to the fixed path constraints.
How is this kind of problem called, or what do I have to search for?
Best regards
Mark
I do not think that a name for such a general problem exists. However, I'm pretty certain you can re-model your graph and solve this problem via a simple Dijkstra search:
Trying to avoid certain (type of) vertex: Say you have a vertex that is to be avoided, and that has k neighbors. Replace it by a K_k (i.e. a clique with k vertices), and connect each neighbor to one of the k new vertices. Then set the weight of all the clique-edges to something large. Now every path passing over the original vertex will have to pass through the clique and "pay the fee", i.e. it will be avoided, if possible
Trying to avoid certain edges: Just raise their edge weight accordingly
Then, run a simple Dijkstra search. If you have multiple classes that are to be avoided, you can even set the weights as to determine priorities for avoiding each of them..
Hope that helps,
Lukas
Assume class A with methods M1 and M2 has low coupling with other classes
a) Should we also make sure that each individual method in class A is not tightly coupled with any other method in the same class? Thus, should we make sure that changing code in A.M1 doesn't also require us to change code in A.M2?
b) I assume if A.M1 is performing two closely related tasks T1 and T2 instead of just a single task, then T1 and T2 are tightly coupled, since changes in T1 may also require changes in T2?
thank you
Write code that follows single-point-of-maintenance. If you change something, only change it in one place. This will reduce bugs throughout your code. That being said avoid code duplication and split classes, methods, namespaces, etc. into parts parts with a single responsibility.
Changing something in method A() should not force you to make a change in method B(). Maybe use a helper function in both that shares common functionality.
EDIT: The SOLID acronym is a good one to follow for software design/engineering: http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
I'm looking for a way of storing graphs as strings. The strings are to be used as keys in a map, so that two topologically identical graphs will map to the same value in the map. Does anybody know of such an algorithm?
The nodes of the tree are labeled with duplicate labels being allowed.
The program is in java and an implementation in that would be neat, but any pointers to possible algorithms are appreciated.
if you have an algorithm that maps general graphs to strings, and so that two graphs map to the same string if and only if they are topologically equivalent, then you have an algorithm for GRAPH AUTOMORPHISM. Graph automorphism has no known polynomial-time algorithms. So you can't have (easily :) a polynomial-time algorithm that calculates the strings as you postulate them, because otherwise you'd have constructed a previously unknown and very efficient algorithm to graph automorphism.
This doesn't mean that it wouldn't be possible to solve the problem for your class of graphs; it just means that for the class of all graphs it's kind of difficult.
You may find the following question relevant...
Using finite automata as keys to a container
Basically, an automaton can be minimised using well-known algorithms from automata-theory textbooks. Hopcrofts is an example. There is precisely one minimal automaton that is equivalent to any given automaton. However, that minimal automaton may be represented in different ways. Constructing a safe canonical form is basically a matter of renumbering nodes and ordering the adjacency table using information that is significant in defining the automaton, and not by information that is specific to the representation.
The basic principle should extend to general graphs. Whether you can minimise your graphs depends on their semantics, but the basic idea of renumbering the nodes and sorting the adjacency list still applies.
Other answers here assume things about your graphs - for example that the nodes have unique labels that can be ordered and which are significant for the semantics of your graphs, that can be used to identify the nodes in an adjacency matrix or list. This simply won't work if you're interested in morphims of unlabelled graphs, for instance. Different ways of numbering the nodes (and thus ordering the adjacency list) will result in different canonical forms for equivalent graphs that just happen to be represented differently.
As for the renumbering etc, an approach is to borrow and adapt principles from automata minimisation algorithms. Basically...
Create a vector of blocks (sets of nodes). Initially, populate this with one block per class of nodes (ie per distinct node annotation). The modification here is that we order these by annotation details (not by representation-specific node IDs).
For each class (annotation) of edges in order, evaluate each block. If each node in the block can follow the current edge-type to reach the same set of next blocks, leave it untouched. Otherwise, split it as necessary to get maximal blocks that achieve this objective. Keep these split blocks clustered together in the vector (preserve the existing ordering, just refine it a bit), and order the split blocks based on a suitable ordering of the next-block sets. For example, use bitvectors as long as the current vector of blocks, with a set bit for each block reachable by following the current edge type. To order the bitvectors, treat them as big integers.
EDIT - I forgot to mention - in the second bullet, as soon as you split a block, you restart with the first block in the vector and first edge annotation. Obviously, a naive implementation will be slow, so take the principle and use it to adapt Hopcrofts minimisation algorithm.
If you end up with blocks that have multiple nodes in them, those nodes are equivalent. Whether that means they can be merged or not depends on your semantics, but the relative ordering of nodes within each such block clearly doesn't matter.
If dealing with graphs that can be minimised (e.g. automaton digraphs) I suspect it's best to minimise first, though I still haven't got around to implementing this myself.
The key thing is, of course, ensuring that your renumbering is sensitive only to the significant details of the graph - its structure and annotations - and not the things that are only there so that you can construct a representation such as node IDs/addresses etc.
Once you have the blocks ordered, deriving a canonical form should be easy.
gSpan introduced the 'minimum DFS code' which encodes graphs such that if two graphs have the same code, they must be isomorphic. gSpan has implementations in C++ and Java.
A common way to do this is using Adjacency lists
Beside an Adjacency list, there are adjacency matrices. Which one you choose should depend on which you use to implement your Graph class (adjacency lists are usually the better choice, but they both have strengths and weaknesses). If you have a totally different implementation of Graph, consider using one of these, as it makes many graph algorithms very easy to implement.
One other option is, if possible, overriding hashCode() and equals() on the Graph class and use the actual graph object as the key rather than converting to a string.
E: overriding the hashCode() and equals() is the route I would take if some vertices are not uniquely labeled. As noted in the comments, this can be expensive, but I think it would depend on the implementation of the Graph class.
If equals() is too expensive, then you should use an adjacency list or matrix, but don't just use the node names. You have to carefully specify exactly what it is that identifies individual graphs and vertices (and therefore what would make them equal), and then make your string representation of the adjacency list use those properties instead of the node names. I'd suggest you write this specification of your graph equals operation down.