You could do couple of things in terms of design to address these.
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! :-)
From the exam point of view, I don't think there is anything concrete which gives 100% guarantee that your design will make sure that it executed all transactions within the stipulated maximum time. But what is expected from you is that your design has the capability to satisfy the given NFR. You can leverage the deployment diagram to show that your system wil perform as per the requirement(All transaction within some x seconds). In the diagram you should depict/describe both vertical(CPUs, memory etc) and horizontal scaling(clusters), which in turn helps you maintain the given NFR. Its good to mention load balancing, fail overs in your design(Deployment diagram). Also by providing a sample hardware configuration of each server, you are telling the evaluator that your setup is good enough to satisfy the given NFR.