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

Practical application of use cases to a real-time system

RM13: Practical application of use cases to a real-time system

There's a perception that use cases are only useful when you are describing a highly interactive system, typically an IT system, such as a bank system

i think that this guy is clearing a big prominnent myth among many of
us. even i thought that use cases couldnt be of much hope fro embedded
and real time systems. whenever we had to do a project that required
UML modelling one of the prime factors in zeroing on one project would
be whether or not we would be able to apply our use-case concepts
easily. i mean it had to be a real complex B2B/B2C kindoff sytem where
there would be a number of scenarios, a number of actors and all that
to really show something credible in terms of UML usecasse. but this
guy seems to say that "nah, man use cases are required everywhewre".
and best hes goint to quote from his own experience
annd i thin hes right when hes talking about the automated teller example that is shown in ever damm UML tutorial on this earth. i think they limit the generalization one is suppose to make when learnign UML.

Real-time systems can have minimal interactions with the user, and, again, this is a consideration where specifying such a system with use cases is concerned. Real-time systems can be highly algorithmic, and use cases may not be the best way of documenting algorithms. Typically, a use case will refer to an algorithm that is documented elsewhere, leaving the use case specification rather empty.If your system has significant externally-visible behavior however, then use cases are a great vehicle for documenting the requirements. The system I'll describe here has a lot of externally-visible behavior. All the same rules that apply to documenting IT systems using use cases apply here

now its getting confusing. i thought he waas going t show me a kool way of using usecases for real time embedded systems. but now it seems hes back to the interacive, external behaviour stuff. lets seee where this goes.
man im loosing intrest in this. hes describing some project that he has done and then teh stuff that they did. man im leaving it here.

Design for webSyn

Design for requirement 3
version 0.1: load the xml feed, validate and then throw on the screen
there would be one main class known as IntegratorServlet. this servlet would load the file and throw it on the screen. at present instead of a http request an IO operation will be used.

plAn for webSyndicator

k this is suppose to be th eproject plan
high level requirements
1) user hits url of personal page and gets to it after authentication(check if u could get the username of the logon session. it could be a n appropriate way of authentication)
2) the web page is split into 2 frames(check which is eassier frames or tables)
3) the left frame(the smaller one width wise must allow the user to subscribe to new atom feeds or unsubscribe from existing feeds
4) the right frame must show the user the contents of the current selected feed
5) the user must have the option of customizing what elements of the feed he wants to view on the left frame
6) study the required mechanism for refreshing though ttl and cloud parametres so as to fix a proper refreshing rate. there is also the thing if the user is not seeing then it doesnto need to be refreshed. if it is implemented then it raaises the complimentary reqirement of allowing only one feed to be active at a time.
priority of requirements
3>4>5>2>1

k
now i have been looking into ebXML for some time now. the following are my view on the ANCPA(automatic Negotiation CPA)
one would find the following new acronyms and definitions
NCPA-- Negotiation CPA. thisis the stuff that will control the negotiation protocol
Negotiation BPSS instance document-- this document is used to define the negotiation collaborative protocol. it is referenced from tea NCPA.
NDD-- negotiator Description Document. this document will refer to the CPP/CPA template and declare what is negotiable.
Negotiaiton messages- the messages used to offer and counter-offer
Negotiation Protocol- the collaborative protocol that leads to the negotiated CPA
nEGOTIATION aLGORithm- this is the algorithm that the party will use in deciding on what to offer first and stuff like that. this represents the internal negotiation stratergy employed by the party
k now for the real thing
whenever a company goes out looking in ebXML registries it could find one of the following combinations
1) it finds a CPP(say party A`S) AND THEN Authors a CPA template using A`s CPP and its own CPP and NDD.
2) also use party A`s NDD if available
3) maybe party A has already published a CPA template which B can use in accordance with its own CPP and NDD.
k now remember that party A and B must obey to the rules of the NCPA so as to negotiate all this and make all these offerings and counter offerings. again this deal as to which NCPA to use can happen in 2 ways.
1) the party can configure its whole system to only 1 default NCPA that it has published and which the other party will have to use
2) the party can publish some NCPA templates which it can do with and the other party can choose one with which it can collaborate and fill the required information to make it a legitimate NCPA
thats prob it.
basically to summariZe
1) party A must find a party B.
2) it must then author a CPA template depending on what party B has published(CPP, NDD, CPA template)
3) Party A must then offer a CPA template to party B.( they have to agree to a NCPA for this, they can do it in 2 ways-- real and virtual. see above)
4) party B has the options of rejecting it(end of ANCPA) or making a counter offer
NOTES
1) NCPA is the document that will tell that how an offer is to be made and stuff like that. 2 parties must agree toa a common NCPA to 'negotiate '.
2) Negotiation BPSS document is a kindoff Core Component.
3) negotiation Protocol is the actual protocol followed in negotiation by both the parish in actually performing the 'negotiation'
4) NDD is the document that what in the CPP is negotiable and is provided for reduction in non-viable offers
5) the above is base don my reading of the NCPA speX dated 1 nov 03.