To start with you could cache data.
You could make interactions with database less chatty. You could highlight these type of decisions/optimizations that you have done
You could try to do some parts of the processing asynchronously. Example the page does some heavy updates, these updates can be written to a JMS queue, a MDB can then process these
You could do some multithreading although this is not recommended in J2EE environment as you would want the thread life cycles to be managed by container. In case of getting data in one call you could break it, retrieve data by spawning multiple threads & then merge data & return it.
You could highlight these as design decisions taken to address NFR. This information could also be provided in relevant sequence diagrams.
Yegor Bugayenko wrote:One of NFRs in my SCEA-2 assignment says that the SuD shall process all transactions in less than 5 seconds.
What are the possible objective (!) mechanisms that can guarantee/ensure such an NFR? I'm a bit stuck. Thanks in advance!
I do not think that there is any specific way in the UML diagrams to achieve this NFR. They put it there maybe for the risk/mitigation section.
Some patterns should be applied as caching, as mentioned earlier, but I'd have in mind also vertical scaling and DB tuning. If you have a DB2 system running on a less powerful old dusty PC with 1GB of RAM and not tuned accordingly, also having not normalized tables, the transactions could complete in minutes and not in less than 5 seconds! :-)
With best regards,
Hope it helps.