Place objects in threads and processes in UML
in [OOP]
|
Prev: Error: A referral was returned from the server
Next: Call for Papers: The 2008 International Conference of Parallel and Distributed Computing (ICPDC 2008)
From: d99alu on 22 Jan 2008 04:40 Hi! How can I, in UML, show what objects are placed in what threads, and what treads are supposed to run in what processes? (I'm designing a framework for an embedded system that supports both processes and threads.) /Andreas - Sweden
From: junk.email.al on 22 Jan 2008 07:42 Hej, It is dynamic modelisation, use sequence or activity diagram. A little bit informal : make swimlanes for each processes, in each swimlanes, create 'nested' swimlanes for threads, and in each threads : create 'nested' swimlanes for objects. Then describe your activities or sequences. I do not think nested swimlanes are part of UML specification, but easily understandable (human readable). By the way : an object activity might be part of several threads and processes, and at 'higher level', part of several platforms. Alex. On 22 jan, 10:40, d99...(a)efd.lth.se wrote: > Hi! > > How can I, in UML, show what objects are placed in what threads, and > what treads are supposed to run in what processes? (I'm designing a > framework for an embedded system that supports both processes and > threads.) > > /Andreas - Sweden
From: H. S. Lahman on 22 Jan 2008 15:11 Responding to D99alu... Not my arena, but since there hasn't been much response... > How can I, in UML, show what objects are placed in what threads, and > what treads are supposed to run in what processes? (I'm designing a > framework for an embedded system that supports both processes and > threads.) An interesting question because of the subject matter. There is no direct way to represent threads in UML because OOA/D is at a higher level of abstraction than OOP implementation. Since threads are highly dependent on the specific implementation (OS and language), one generally does not deal with threads in UML models. (Typically threads are identified via an MDA Marking Model.) However, when the application space /is/ the implementation space subject matter, as in your framework, one is in a different ball game. So one needs to provide explicit abstractions for threads using the existing UML artifacts. As already mentioned, one way to do that is to provide an Interaction Diagram for each thread. That diagram just shows the object interactions that are relevant to (contained in) the thread. Another approach is to use the Package Diagram to collect model elements in thread packages. (This is close to way most commercial code generators use MDA Marking Models; they put a thread wrapper around the model elements identified in the Marking Model.) Yet another approach is to use an Activity Diagram to isolate threads via fork/join. Alas, all these approaches identify what goes on /in/ the thread but don't provide much insight into how a thread plays with other threads. Yet another alternative is to use Component stereotypes as thread entities to capture the processing. In effect the thread component cobbles together other UML elements as a sort of Facade pattern container. Then ports become a convenient mechanism for describing the interface to the rest of the application (thread instantiation, pausing, prioritizing, termination sorts of things). Personally I have never used this approach, but it seems like it has potential since your framework is likely to be mostly about gluing processes and threads together. UML used to have a <<thread>> stereotype, but that went away with v2.0. It seems to have been replaced with some remarkably obtuse meta semantics around Deployments. I have not ventured into that garden, but you might want to take a look at the verbiage. The notion of dependencies is intriguing because it could be interpreted in terms of connection points that might, say, trigger pausing. -- There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH
From: d99alu on 23 Jan 2008 03:18
Thanks a lot for all your input! I'm sure one of these approaches will help me out. Best Regards, Andreas - Sweden |