Details
I have an activity diagram for Login section designed in Eclipse Papyrus. Now I have to write OCL constraints for the following conditions:
My Effort
I already done this in class diagram like this but don't know how to apply constraints in activity diagram. I have read a lot of articles, watched videos and research papers and checked questions like this, this, this and this but none of them provide a proper answer.
This doesn't seem to have much to do with Activity Diagrams. Your new wording is clear, 5 attempts on one form or one attempt on each of five forms is bad, so User_Account::failedAttempts (rather than login::attempts) is a sensible model feature.
The Constraint is most eaaily defined as an upperbound of 5 on User_Account::failedAttempts. Note that a Constraint defines what is valid not how to react to invalidity. You could more use an invariant to upperbound against a maximumAttempts() computed value. You could inadvisedly use pre/ postconditions on operations or just knit your control operations.
You could sensibly have a User_Account::isLocked() operation whose body is failedAttempts >= maximumAttempts().
The Activity provides the Control for the Model. Presumably it has a lifeline associated with creation/destruction of a login. Presumably it makes use of a DataBase::checkPassword(userName, password) operation that return the User_Account and increments User_Account::failedAttempts as a side-effect. The enforcement of the maximum is therefore in User_Account::checkPassword. (NB you should not do two stage access for User_Account lookup then password validation to ensure that hackers cannot distinguish, possibly just by response time, whether a failure is due to a bad username or bad password.)
You need to clearly identify what is in the Model; what persists for the duration of your system, perhaps being restored from backup following a system restart. Therefore User_Account must have username and password and failedAttempts properties to define the persistent state.
Conversely what is part of the View/Control can be lost and recreated when another user interaction is initiated. The login form therefore also has username and password properties to represent what is entered on the form and which will be correlated with the Model DataBase by perhaps DataBase::getUserAccount and UserAccount::checkPassword.
I would not pollute the persistent DataBase model with transient login content. If you require recreation of in-progress login attempts across a server failure, I would have a separate ViewDataBase of transient viewed state. If nothing else you would recover the server failure by reactivating the persistent DataBase before reactivating the transient activities.
