Do you have any idea how to reuse an interaction in more than one sequence diagram in Enterprise Architect?
In this case, I'd like to reuse the interaction ServiceX in different sequence diagram.
You must not do that. A message is only part of the diagram it is placed on and used in the very context you show on that specific SD. The same applies for the life lines. They are all instances of classes and never re-used in other SDs.
Actually you derive the message from an operation defined in the class that instantiates your object. Just choose the right one from the message drop down.
As you can see, Class1 is the classifier of Object1 and its operation is available in the dropdown.
Related
How can I associate messages(operation calls) in a sequence diagram to its implementation(method)as an activity diagram?
I am using Papyrus for modelling.
There is an indirect relationship possible in this case.
A method is typically defined in a class from a class diagram.
The same method is specified using an activity diagram.
The invocation of the method can be shown on a sequence diagram.
Class diagram gives kind of a structural back-up the the rest of the diagrams, and is highely recommendable to make one (if you don't have it already).
The messaging in a sequence diagram are meant to become method invocations upon classes of objects. Activity diagrams are meant to be like a flow chart of the business processes. The former will be very specific and detailed; the latter will be more generic and not so specific.
While they can be coincidentally related if you choose to model that way, since they are not by UML standards to be that directly related I don't think you'll find tooling that will do this for you.
You can read more here:
UML Activity Diagram tutorial
UML Sequence Diagram tutorial
What is the best UML diagram type to use when trying to show how a class' behavior flows from one method to another?
I am trying to diagram existing code and the behavior I am looking at primarily involves private method calls, with a few calls to static objects outside the class. I don't feel that a sequence diagram would give the best detail in this case since the class in question doesn't interact with any other classes except for the very few static calls mentioned earlier.
What would fit best in this situation?
According to the UML Superstructure (http://www.omg.org/spec/UML), in the UML two kind of behaviors exist: emergent behaviors and executing behaviors.
An executing behavior is performed by an object (its host) and is the description of the behavior of this object.
An executing behavior is directly caused by the invocation of a behavioral feature of that object or by its creation. In either case, it is a consequence of the execution of an action by some related object. A behavior has access to the structural features of its host object. Objects that may host behaviors are specified by the concrete subtypes of the BehavioredClassifier metaclass.
Emergent behavior results from the interaction of one or more participant objects. If the participating objects are parts of a larger composite object, an emerging behavior can be seen as indirectly describing the behavior of the container object also. Nevertheless, an emergent behavior can result from the executing behaviors of the participant objects.
You can model behaviors by means of Activities or Interactions (actually you may also use state machines and use cases). Activities are more adapt to model executing behaviors while Interactions to model emergent behaviors.
Now if your class has many parts and its behavior you want to model consists in a "complex" interaction of its parts then probably an interaction diagram (sequence) may be the right choice. Otherwise, if the behavior you need to model, consists of a sequence of atomic actions an activity may be better. Consider in UML there is a specific actions to represent the invokation of a method (CallOperationAction) which takes as input pin the object reference you can retrieve by means of a dedicated action (ReadSelfAction). There is also an action to read an object attribute (ReadStructuralFeatureAction).
Also check the Foundational for Executable UML Models (FUML) http://www.omg.org/spec/FUML
While all of the previous answers are correct, I would like to add the option of using a State-Machine to define the behavior of the class. State machines allow you to show what is the current state of the class and how the state of the class changes as methods are called or events are received. Since you state that you are mostly modeling one class, I think the most important thing to show is what can be done (what method calls can be called) depending on the current state and how these method calls affect the state of the class. One think I really like about state machines is that they have relatively well defined semantics and also have ways to show information at different levels using composite and orthogonal states.
Broadly you have 2 choices (per #Silli's answer): sequence or activity diagram. I would probably have suggested sequence diag as first choice, however you say you don't think that's appropriate. Could you elaborate why?
Perhaps it's conditional logic? If so an activity diagram may be the better choice. It has more intuitive syntax for showing control flow than a sequence diagram. You could also show the static objects in separate swimlanes - so clearly differentiating calls to external objects. You can also illustrate parallel behaviour if that's relevant to you. Some good examples here if it helps.
hth.
I would recommend collaboration diagram (UML 1.x) renamed to Communication diagram (UML 2.x).
This may be better than sequence diagram, better because it may be more readable in your case.
A Communication diagram models the interactions between objects or parts in terms of sequenced messages. Communication diagrams represent a combination of information taken from Class, Sequence, and Use Case Diagrams describing both the static structure and dynamic behavior of a system.
http://en.wikipedia.org/wiki/Communication_diagram
I am designing a system that lets a user assign a specific task to be performed when a button is pressed. The task to be performed can be assigned to all sorts of things. So I have an abstract base class called "ButtonTask", and all other tasks inherit from this base to implement the task to be performed along with the associated data it needs to know. This way I can use polymorphism to abstract away all the specifics, I just call "PerformTask" without having to care about what type it actually is. So far so good.
The actual task itself can be set in may different ways, the user may change the task with a UI menu, the task may be read from a file, and also the task may be set remotely via a network message.
At the moment I have a factory function that will create the correct derived type based on the network message, and return a pointer to the base type. The problem is that the UI menu and the file reading feel like they need their own factory method for object creation, as they are inherently different from one another. Is it generally a good idea to have multiple factories for this kind of problem? I can't really think of another way around this problem but perhaps there's something neater I can do.
The only good reason I see to implement multiple factory methods is if you want to be able to create the objects with different sets of initial attributes, for instance by allowing the caller to specify some attributes and setting default values for others - the equivalent of having multiple public constructors.
If the idea is that the tasks are independent of the way they were initiated (GUI, network, etc), then I don't see a need for separate factory methods. Instead, I would say that one of the duties of the factory is to achieve this very abstraction. In other words, calling the same factory from three different parts of the code is absolutely fine. It is probably a good idea to make the factory method static or to make the factory a singleton object, though.
If on the other hand you have a situation where certain tasks can only ever be initiated from the network and others from the GUI, and only a few can be initiated in all three ways, then it might be worthwhile to rethink the design a bit. You should then consider adding another level of abstract Task classes, eg CommonTask, GuiTask, NetworkTask, FileTask, and have factories for them instead of ButtonTask. This is obviously more complex and whether or not it's worth it depends on the number of task classes and the structure of your code.
What you want to avoid is a situation where users of the factory are aware of which specific subclasses of ButtonTask they can receive from the factory. That's a "false base class" situation, ie one where the base class is not a true abstraction of the whole set of its subclasses, and you get out of it by adding the extra subclass layer as outlined above.
Other than that, you might also want to consider renaming ButtonTask; it sounds like a GUI-only task just from the name.
I’m fairly new to OO. If I have two classes A and B that need to exchange data, or call each other’s methods, I need to be able to access an instance of class B from class A. Should I maintain the address of the instance object in a global variable? Should I appoint a (singleton) master class, and make (pointers to) instances of A and B properties of the master class? (AppDelegate comes to mind.)
Is there a straightforward by-the-book way to implement this? Somehow I‘m missing some "best practice" here. I’ve looked through Apple's examples, but didn't find an answer.
EDIT: Since I'm fairly new to MVC design patterns, my question is essentially "Who creates who"?
We're talking about an Audio Player here. 1. When the user selects a song, the UI displays its waveform by creating a viewController which creates the appropriate view. 2. When the user hits play, the UI displays a timeline while the song is playing by overlaying a new view over the waveform. Now, the latter view needs some info from the waveform display viewController. Right now, I'm storing a pointer to the viewController in an instance variable of my appDelegate. This works, but feels extremely strange.
Should I outsource the info that is needed by both classes to some third entity that every class can access easily?
Classes aren't simply departments of code. They are templates for the creation of objects, which you should think of as actors in your program, doing things within their areas of responsibility (which you define—you decide what each object does) and interacting with each other.
While you can handle a class as you would an object, classes generally do not talk to each other. Most of the time, you will create and use instances of the classes—which is what we normally mean by “objects”—and have those talking to each other. One object sends another a message, telling the receiver to do something or changing one of the receiver's properties. These messages are the interactions between your program's objects.
Those weird expressions in the square brackets are message expressions. Nearly everything you'll do with a class or object will involve one or more messages. You can send messages to classes the same as to objects, and classes can send messages just as objects can.
In Cocoa and Cocoa Touch, you typically have model objects, view objects, controller objects, data objects (such as NSString, NS/UIImage, and NSURL), and helper objects (such as NSFileManager). The classes you'll write for your application will mainly be model, view, and controller objects (MVC). The model represents (models) what the user will see themselves manipulating; the view displays the model to the user; the controller implements logic and makes sure the model gets saved to and loaded from persistent storage.
For more information, see Object-Oriented Programming in Objective-C and the Cocoa Fundamentals Guide.
Since I'm fairly new to MVC design patterns, my question is essentially "Who creates who"?
Controllers create and load the model, and load the views, and pass the model to the view for display. Certain controllers may also create other controllers.
It's good to keep a straightforward tree-like graph of ownership from a single root of your program—typically the application object—down through controllers to leaf objects in the models and views. If two objects own each other, that's a problem. If an object is not owned by anything outside of its own class (a singleton), that's usually a problem as well—a sign you need to think some more about where that code belongs. (Helper objects are the main exception; most of those are singletons. Again, see NSFileManager for an example. But they are few and far between.)
Further situation analysis require more information. At first place you should more specify the relation between classes and what exactly do you mean by exchanging data.
Singletons should be generally avoided. If you want to exchange information it is usually sufficient to provide for example instance of the class A to the instance of the class B by some method or constructor. The instance of B is then capable of calling public methods (and accessing public properties) of the instance of A.
A little bit of "best practices" can be learn by searching up "Design Patterns".
You should decide if one class can be an object of another class (encapsulation), or if one class can inherit from the other class (inheritance). If neither of these is an option, then maybe you could make one class (or some of its members) static?
Thanks for your contributions. Additionally, I found information on this page very useful. It lays out MCV considerations for cocoa in a hands-on way and practical language.
I see a lot of classes labelled "Manager". How is a manager class used?
For example, does it get used by composition like this?:
var m: Mananger = new ManagerClass();
m.doSomething();
Manager classes are the common dumping ground for code that somehow didn't fit somewhere else. They also tend to be or become god classes.
Classes like that are used to manage a set of objects of another class, which are often resources.
For example, let's say you have a pool of database connections, each one represented by an object of DBConnection class.
If your code needs to connect to DB via a pool of connections, it will merely ask DBConnection_Manager class for a new connection. Why do we need the manager class?
The Manager class will consult its list of DBConnection objects, and determine if any of them is un-allocated, and return one. If all are allocated, it will either create one and add to the pool (subject to max connections allowed limit) or place the request on queue, or report back failure.
ALL of this functionality is full hidden from the caller - the nitty-gritty details of managing the pool are the job of the Manager class.
This is just a specific example, but the idea is that resource management is centralized and encapsulated withing a Manager class and the user code merely asks for "a resource".
I'm not sure if there's a bona-fide "design pattern" for this approach, though I found at least one web page that says so: http://www.eventhelix.com/realtimemantra/ManagerDesignPattern.htm
Update: in case of actionscript, such a class could be used to manage sounds, or event listeners, or GUI widgets (e.g. context menus)
Some consider managers to be a code smell
it usually means somebody is implementing a design pattern and doesnt know (or doesnt want to use) the formal name for it. you'll have to read the code to draw any meaningful conclusions.
In my opinion, manager class should be used in these conditions:
Multiple objects need to be process
Pass object list to caller is not enough, you should provide some advance functions such as select the max or the min one
The objects to be managed should belong to one class (manage easily)