Author Topic: Abstraction of the SubActivity_Of Meronymy  (Read 776 times)

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Abstraction of the SubActivity_Of Meronymy
« on: October 08, 2005, 04:19:15 pm »
What would you consider to be a good abstraction of the SubActivity_of Meronymy?

This is another thread in my concerns about abstractions of the six types of meronymy.  The first thread of this series is the Part_of Meronymy .  The introductory and Background portions of that thread should be reviewed by readers new to this series.

Now to the Abstraction...A work in progress.

Sub activity / Process

This sub relation describes the different sub-activities that form a process in a structured way, for example in a temporally organized way. Into this class fall examples such as : pay/buy, give exams/teach.
• A sub-activity instance may be a part of more than one process at the same time.
• Destruction of a sub-activity destroys the processes of which it is a part.
• Destruction of the process does not always destroy its sub-activities. [Policy]
• The types of the sub-activities do not define the type of the process.
• A sub-activity may have its own thread of control (Concurrent) or execute within the control thread of its client process (Sequential).
• A process may activate a sub-activity by the use of a message or by raising an exception.
• Messages may, or may not, contain data.
• The raising of an exception results in an instantiation of an Exception Object which is made available to a sub-activity which deals with the raised exception.
• A sub-activity may, or may not, return a value.
• A sub-activity may, or may not, have access to the process’s attributes and behaviors.
• A sub-activity may, or may not, have side effects.
• Messages come in three main types, with regard to concurrency and threads of control:  sequential, synchronous, and asynchronous.  The sub-activity determines which of these three types of messages may be sent.
• A sequential message involves only a single thread of control and can only be sent to a sequential sub-activity;  The thread of control is passed from the client process to the sub-activity until the corresponding sub-activity is completed, at which point the thread of control is returned to the process.
• A synchronous message involves two threads of control that must synchronize during the execution of the sub-activity;  it can only be sent  by a concurrent process.
• An asynchronous message does not involve synchronization and is essentially a fire-and-forget message;  such a message can only be sent by a concurrent process.
• The process is responsible for assuring the availability of a sub-activity prior to sending it a sequential or synchronous message.
• Both Processes and Sub-activities may be specialized and/or derived.

Attributes of the association

/isTransient - Transient processes and sub-activities may be created and destroyed while the program runs and are therefore not guaranteed to exist for the duration of the program run. Default is True.
/isTemporary - Temporary processes and sub-activities persist while the program runs but cease to exist when the program stops.  Default = False.
/isPersistent - Persistent processes and sub-activities are stored in permanent storage, such as an object-oriented database. Default = false.
/isOrdered : Boolean Specifies whether the return parameter is ordered or not, if present. This is derived.
/isQuery - Boolean Specifies whether an execution of the Sub-activity leaves the state of the system unchanged (isQuery=true) or whether side effects may occur (isQuery=false). The default value is false.
/isUnique - Boolean Specifies whether the return parameter is unique or not, if present. This is derived.
/lower - Integer[0..1] Specifies the lower multiplicity of the return parameter, if present. This is derived.
/upper - UnlimitedNatural[0..1]Specifies the upper multiplicity of the return parameter, if present. This is derived.

Notation: An AssociationClass  stereotyped as << subActivityOf >>.  Association ends may be adorned with navigation arrowheads and ownership diamonds.  A link name (formed by the conjunction of two verbs, or verb phrases, separated by a slash) assists the reader in verbalizing the association from either of its ends. AssociationClass may show the Attributes of the association. The Process and Sub activity classes should show an isConcurrent attribute.
« Last Edit: October 08, 2005, 04:29:26 pm by jeshaw2 »
Verbal Use Cases aren't worth the paper they are written upon.

KP

  • EA Administrator
  • EA Expert
  • *****
  • Posts: 2436
  • Karma: +29/-2
    • View Profile
Re: Abstraction of the SubActivity_Of Meronymy
« Reply #1 on: October 09, 2005, 05:02:55 pm »
Another wee caveat of the "strict UML" variety...

Quote
A link name (formed by the conjunction of two verbs, or verb phrases, separated by a slash) assists the reader in verbalizing the association from either of its ends.


Since an association class is both class and association, its class name and association name should be the same. Having said that, EA doesn't enforce it so the link name field is there to be used...  :)
The Sparx Team
support@sparxsystems.com

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Abstraction of the SubActivity_Of Meronymy
« Reply #2 on: October 09, 2005, 06:00:27 pm »
Agreed  :)  They should be the same and displayed only in the class.

I spent some time trying to figure out a proper naming process for Sub Activity associations, but I didn't come up with one I liked.  I forgot to delete the naming method in my cut-n-paste of the Notation.
Verbal Use Cases aren't worth the paper they are written upon.