message_passing: derive component_requirements#555
Conversation
gdadunashvili
requested review from
LittleHuba,
bemerybmw,
castler,
crimson11 and
hoe-jo
as code owners
gdadunashvili
force-pushed
the
dadu_component_requirements
branch
2 times, most recently
from
b3cd6c0 to
40fa793
Compare
| section "System Requirements" { | ||
|
|
||
| ScoreReq.CompReq SafetyCertifiedTransportMechanismUnderQNX { | ||
| description = "Under QNX, the message passing component shall use a safety-certified transport mechanism as the underlying IPC." |
There was a problem hiding this comment.
That's basically the same statement as in the upper requirement. We should define here that we are using message passing.
There was a problem hiding this comment.
We also should have a requirement what we use for linux to satisfy that this is OS abstracted
| } | ||
|
|
||
| ScoreReq.CompReq OSProvidedSenderIdentity { | ||
| description = "The message passing server shall be able to identify the sender of each received message by the sender's OS-provided UID." |
There was a problem hiding this comment.
UID = user-id?
or unique id, if unique id, then is the question what unique id?
If user-id, then we need an aou that every process should have a different user-id, and we should link this here somehow.
| } | ||
|
|
||
| ScoreReq.CompReq UnforgableSenderIdentity { | ||
| description = "The transport mechanism shall ensure that the UID used to identify a message, cannot be forged by the client." |
There was a problem hiding this comment.
This would then be a requirement towards the OS, no?
There was a problem hiding this comment.
According to my picture this would be an ExternalComponentRequirement
There was a problem hiding this comment.
Agree. That's why it is clustered in System Requirements section, i.e. Component level Requirements towards the system. If it needs to go in a different file I can do that.
There was a problem hiding this comment.
Or would it be better if this becomes an AOU?
| section "Behaviour Requirements" { | ||
|
|
||
| ScoreReq.CompReq ServerCallbacksAreSequential { | ||
| description = "The server shall serialize all callbacks belonging to the same IServer instance, such that no two such callbacks execute concurrently." |
There was a problem hiding this comment.
what is an IServer instance?
There was a problem hiding this comment.
I understood this and the next comment as a suggestion to not use API names but more generic terms like Server & Client, and made changes accordingly
| } | ||
|
|
||
| ScoreReq.CompReq ServerProcessesSinglePendingRequest { | ||
| description = "The server shall not dispatch a new sent-with-reply message callback on a given IServerConnection until the preceding request has been replied to via `IServerConnection::Reply()`." |
There was a problem hiding this comment.
Again IServerConnection, this sounds like implementation detail - I think what you did below with ´ClientConnection´ is maybe a little bit more abstract?
| } | ||
|
|
||
| ScoreReq.CompReq ClientConnectionMaintainsStateMachine { | ||
| description = "The `ClientConnection` shall maintain a state machine with the states `Starting`, `Ready`, `Stopping`, and `Stopped`." |
There was a problem hiding this comment.
What is the allowed transitions between these states? Should we draw this in a state diagram?
There was a problem hiding this comment.
I already drew a state diagram and it is merged
https://github.com/eclipse-score/communication/blob/main/score/message_passing/dependability/software_architectural_design/client_connection_activity_diagram.puml
Should I link it here? If yes what is our way of doing that? Just a path to the file?
| safety = ScoreReq.Asil.B | ||
| derived_from = [MessagePassingSEooC.ServerInterface@1] | ||
| version = 1 | ||
| } | ||
|
|
||
| ScoreReq.CompReq IServerStopListeningAPI { | ||
| description = "`IServer` shall provide a `StopListening` method that releases all registered callbacks and closes all active server connections." |
There was a problem hiding this comment.
I really like this way of writing the API requirements, without exactly specifying the C++ API!
gdadunashvili
force-pushed
the
dadu_component_requirements
branch
from
40fa793 to
c9db53d
Compare
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
github-project-automation
Bot
moved this from Backlog
to Done
in COM - Communication FT
3 participants
No description provided.