I have a class A with method B and attribute C. Method B is realized by an activity diagram D. I would like to access C from within D but I do not know how.
I have tried using "read self" within the activity diagram (and then "read structural feature" to get C); however, "read self" just points to the activity diagram and not the owning class. I have tried experimenting with the ownership field of the "read self" but got nowhere with it.
What is the proper syntax for accessing C within D?
Related
I have a bunch of separated PHP classes. They have nothing special, no constants, just normal variables. The only connection between them are the call of methods.
Is there a way to model this connection in the UML class diagram? I guessed that it would be the "association" with a -> arrow
Correct. If A2 has a reference to B2 (i.e., using a "normal variable"), you write the name of that variable at the end of the association, nearest to the arrowhead pointing to B2. If that variable references a collection of B2s, you ignore the intervening collection type and make the multiplicity [0..*].
In an interface method I want to have a collection of SomeType as an input parameter. How do I represent that within a Class Diagram in EA?
I tried using "SomeType[]" as parameter type, but EA doesn't seem to keep track of this: for instance when I rename the class SomeType to something else, the change doesn't propagate here.
You can specify multiplicity for each parameter of your method.
Parameter multiplicity is not directly visible in the class diagram even if you select "Full detail" in Parameter visibility in Diagram properties. But it is in the model.
The answer is unfortunately: you can't. EA does store the name only and not the reference to the class when you specify a parameter. There are other places where that's also the case (I currently can't recall where). So if you need to track that you need to write a smart SQL to list the used parameters.
Such a SQL could look like:
SELECT * FROM t_operationparams where Type = '<Search Term>'
I have been developing my skills at creating large object orientated programs (30+ classes).
I am trying to make my code as clean as possible after reading a fantastic book called clean code.
One problem I am having is to do with calling a method on an object from "across the program"
Say I have 5 classes.
`ClassA
ClassB
ClassC
ClassD
ClassE`
an instance of ClassA contains an instance of ClassB, which in turn contains an instance of classC, so
`ClassA > ClassB > ClassC`
I'm not saying that this is the inheritance chain, rather that in the constructor of classA an instance of ClassB is created and so on.
Now, say that ClassD > ClassE in a similar way. ClassD is instansiated with an instance variable containing an instance of ClassE.
This is all well and good, and the classes are small and only handle one job, and it all seems nice and clean.
However, say that at some point in the program I need the instance of classC to call a method on the instance of ClassE.
The two objects are on 'opposite sides of the program' so to speak. Yet the method call is necessary.
I am left with three options as I see it
make the instance of classE a global variable, so that classD AND classC can access it (as well as anything else in the program). I feel like this is bad form as global variables are generally considered bad news
Create the instance of ClassE at the top level, then pass it in as an argument to the constructors of ClassA, ClassB, and ClassC. The trouble with this is that I would end up with really long constructor argument lists if this is happening more than once, and it seems like lots of work to pass ojects down chains of constructors like this
Move the object of ClassE to be instantiated by ClassC. The trouble with that is that its more strongly coupled with ClassD and only needs to be called once in the entire running of the program by ClassC.
So what do I do in situations such as these? And are there any resources I can read about this. I know that I could use the observer pattern for situations similar to this, but when its just for one method call it seems excessive, as I would be making things observable all over the program. I want my code as clean as possible!
Thanks in advance :)
Three words: Single Responsibility Principle. If you worry that your class has too many constructor arguments it's probably because this class needs to deal with too many different things. If you keep classes focused, they will be small.
You correctly indicate the coupling problem in the third solution you've described. The coupling problem is also present in the first solution (depending on a global variable is even harder to find/diagnose later). So the second option seems to be the best - as long as you refactor the code to keep your classes simple.
You could read up on Law of Demeter (Short explanation on wikipedia: http://en.wikipedia.org/wiki/Law_of_Demeter or a longer but very well written example http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paper-boy/demeter.pdf)
Depending on the context / content of your example you could for instance: Build your Class D as a wrapper to your class E (or similar facade / adapter). Meaning if your class c sometimes needs to talk to an E instance it does so via it's class D instance.
Another way to go would be to provide a reference to a class E instance to those objects that need one.
If all your objects are talking to the same instance of E you could also think about the singleton pattern where there is only one instance of a class. But this instance is more or less globally available.
Give a bit more context info and we can develop this further.
EDIT: btw. a funny explanation of lad of demeter can be found here:
http://www.daedtech.com/visualization-mnemonics-for-software-principles
EDIT Nr.2 (your comment): ad. 1.) Maybe you can implement your class D in a way that reliefs your other classes of ever talking directly to an E object. Instead they ask their D instance to do something (not knowing that D delegates the call to E). Depending on what you are trying to do this might be an option for you.
ad. Singleton.) Yes and No. The Singleton main use is that it guarantees (if implemented correctly) that only one instance of the singleton object exists. If you are talking about config settings this might not be a requirement. You are right however that basically the thing is kind of a global variable with all it's downsides. Your object D sounds as if it's immutable in a sense that it does not change it's state while your program is running so maybe the problem is not that you create a complex dynamic behaviour but that you create too many dependencies.
Just another link/principle to get you thinking:
What is Inversion of Control?
Is the following format wrong if I add a pointer to an object of a class, as data attribute of class in Class diagram in UML?
could not find anything about using objects in class diagram, is
underlining the object correct within the class attributes?
I think you may be mis-understanding classes, objects and attributes. Apologies if it's me doing the mis-understanding. So. Here's the short answer:
it's absolutely fine and normal for the type of an attribute to be a Class. In other words, you're not restricted to using primitive types like int, long, char etc.
The consequence is, as you say, that the values of those attributes at run time will themselves be objects. Specifically, instances of the classes Ability, Move and See.
More specifically, each instance of Agent (i.e. each Agent object) will hold references - or more precisely pointers - to 3 other objects: one instance each of Ability, Move and See.
So, assuming that's right, what you have is correct - except for the underlining.
Underlining an attribute or operation says it sits at the class level - not the instance level. It's the equivalent of static in java. Think of declaring constants in class scope, or constructors.
If I understand your model that's not what you want. You want each instance of Agent to hold (a pointer to) its own instances of Ability, Move and See. You don't want all the Agent objects to share the same 3 instances. Assuming so, you don't need the underline.
Hope I understood and that helps.
In my case, UIViewController B is a subclass of UIViewController A. B can surely access all the methods and variables from A, since B is subclassing from A (i.e. A is the parent of B).
However, A needs a variable from B. Is there possible to do that ?
Thanks.
Actually, if you need this type of relations - your design is wrong. I mean - you do not need inheritance relationship in you case, but something like aggregation or composition. For example your type of relations breaks The Liskov Substitution Principle.
BUT. Objective C accepts reverse relationships. You can use delegates (#protocol) to describe interfaces which can retrieve some data from unknown objects who accepts this #protocol.
So, in your case class B should conform a protocol which provide access to some properties of B. And A should be able to work with this protocol, i.e. to know getters which A needs.
Add that variable as a default in subclass A. Then it's also available in subclass B?
If that's something you don't want, then I suppose there is something wrong with your design?
If the instance variable declared in the subclass has a getter method, any method in the superclass could always ask an object of its class if it respondsToSelector: for that getter method, and if so, call it to get the value of the instance variable.