UML for RealTime

-->k, basically a real time system is a system that maintains acontinuously, timely relationship with its environment or inmathematical terms where output is a function of the inputs and thecurrent state.
-->now this is a good definition worth mentioning here

Architecture:
The organization of significant software components interacting throughinterfaces, those components being composed of successively smallercomponents and interfaces

-->basically there is something known as a capsulewhich is actually a stereotype of the class(UML class) concept. it hasa compulsory tag of ports and some constraints based on the ObjectConstraint Language.
-->then there is something known as a protocol whichdefines the interaction contracts between the capsules. againprotocol is a stereotype of collaboration andprotocolRole is a stereotype for Classifier Role.according to the titled document these are the only 4 stereotypesneeded for real time systems but i think there`s lots of stuff unclear.fine, now im referring to a pdf authored by James RumBaugh himself, sothings should clear up now.
-->i think this is a classic definition and man this guy is great

The one common feature of all real-time software systems istimeliness; that is, the requirement to respond correctly to inputswithin acceptable time intervals.

-->k getting back to ROOM now

For example, the central actor concept of ROOM iscaptured by the «capsule» stereotype a specialization of the generalUML concept of a class.

-->what??? this guy is talking about actor, capsule and class all atthe same time. lets get back to the basics.
1)a stereotype is used to extend the core semantics of the modeling
2) and actor is something that is not within the scope of the system(the system cannot control) but still interacts with the system and affects the state of the system
-->the statement still seems unclear to me. anyway

The structure of a system identifies the entities that are to be modeled and the relationships between them (e.g., communication relationships, containment, relationships).

-->another important distinction. as i had it in my mind class diagrams are there to represent the semantic relationships between 2 classes. as in what is the relationship between the classes Car and SportsCar. well as u guessed it rightly a SportsCar concept is teh extension of the car concepts. so clash diagrams represent relationships between the adjectives of the system. on the other hand collaboration diagrams represent the verb part of the system. actually the verb is more fitting for sequence and activity diagrams but nevertheless for this comparison it seems a good contrast. so collaboration diagrams basically talk about what kindoff role the instance of the class populace with the classes whose relationship with them is defined in the class diagram. rightly backed by mr. james.

Class diagrams capture universal relationships among classes ; those relationships that exist among instances of the classes in all contexts. Collaboration diagrams capture relationships that exist only within a particular context ; a pattern of usage for a particular purpose that is not inherent in the class itself. Collaboration diagrams therefore include a distinction between the usage of different instances of the same class, a distinction captured in the concept of role.

-->principally 3 structures are defined to model real time systems namely capsules, ports(we already saw these) and connectors.

The structure of a system identifies the entities that areto be modeled andthe relationships between them (e.g., communication relationships, containmentrelationships).

Capsules correspond to the ROOM concept of actors

--> so this is clear. capsules are basically actors again

They are complex, physical, possibly distributed architectural objects that interact with their surroundings through one or more signal-based1 boundary objects2 called ports.

-->i dont think this desciption as necessary. man u just said they were actors period
--> well i dont think i should frame any of this in my own words

A port is a physical part of the implementation of a capsule that mediates the interaction of the capsule with the outside world— it is an object that implements a specific interface. Each port of a capsule plays a particular role in a collaboration that the capsule has with other objects. To capture the complex semantics of these interactions, ports are associated with a protocol that defines the valid flow of information (signals) between connected ports of capsules. In a sense, a protocol captures the contractual obligations that exist between capsules. By forcing capsules to communicate solely through ports, it is possible to fully de-couple their internal implementations from any direct knowledge about the environment. This makes them highly reusable.

-->and somethings again not that clear

Connectors, which correspond to ROOM bindings, are abstract views of signal-based communication channels that interconnect two or more ports. The ports bound by a connection must play mutually complementary but compatible roles in a protocol. In collaboration diagrams, they are represented by association roles that interconnect the appropriate ports. If we abstract away the ports from this picture, connectors really capture the key communication relationships between capsules.

-->what i understand is capsules are the main stuff. ports are the boundary objects which allow capsules to play independant roles in front of different capsules. but what i dont get is the difference betwee an channel and a protocol and connectors too.
-->agian an importantr observation

Although ports are boundary objects that act as interfaces, they do not map directly to UML interfaces. A UML interface is purely a behavioral thing— it has no implementation structure. A port, on the other hand, includes both structure and behavior. It is a composite part of the structure of the capsule, not simply a constraint on its behavior. It realizes the architectural pattern that we might call "manifest interface".

-->again each port plays a specific role in some protocol. Thisprotocol role defines the type of the port, which simply means that theport implements the behavior specified by that protocol role. as theyar eboundary objects they can be viewed from both inside and outsidethe capsule. when viewed from outside the capsule ports can only bedifferentiated on teh basid os there identity and the role they play inthe protocol. but when viewed from inside the capsule there are 2 typesof ports
1)relay ports which are connected to sub-capsules and selectivelyexport the interfaces of the internal sub-capsules. as the namesuggests they just relay teh signals that they recieve. it is connectedto the sub-capsules througha connector(if they are not then one wouldloose the signal. and last thing relay ports are ideal in the sensethat they provide for the direct (zero overhead) delegation of signalsdestined for a capsule to a sub-capsule without requiring intervention
2) end potrs which are directly connected to the state machine of teh capsule. since signal-based communication can be asynchronous, an end port has a queue to hold messages that have been received but not yet processed by the state machine (i.e., it acts as a mailbox). The reception of the signal and the dispatching of the receiving state machine is performed by the state machine according to standard UML semantics. end ports may be of further 2 types - public and private. private are the ones that are used to communicate within sub-capsules (kindoff intra capsule and inter sub-capsule)
-->ports are parts of capsules(composition relationship, a protocol role is a kindoff realization of th e port , which is inturn a part of the protocol class). see fig 1
-->ports are represented in a different compartment by taking advantage of the UML feature of adding extra compartments. the multiplicity is represented in brackets and the visibility by a + or a #(protected). see fig 2. when showing ports in collaboration diagrams they can be shown as iconized boxes only
-->Connectors

A connector represents a communication channel that provides the transmission facilities for supporting a particular signal-based protocol. A key feature of connectors is that they can only interconnect ports that play complementary roles in the protocol associated with the connector. In principle, the protocol roles do not necessarily have to belong to the same protocol, but in that case they have to be compatible with the protocol of the connector. The similarity between connectors and protocols might suggest that the two concepts are equivalent. However, this is not the case, since protocols are abstract specifications of desired behavior while connectors are physical objects whose function is merely to convey signals from one port to the other. Typically, the connectors themselves are passive conduits. (In practice, physical connectors may sometimes deviate from the specified behavior. For example, as a result of an internal fault, a connector may lose, reorder, or duplicate messages. This type of failure is common in distributed communication channels.)

-->for purposse of modelling a connector is modelled by a association relationship. for advanced cases one may use an association class