Win a copy of Microservices Testing (Live Project) this week in the Spring forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Liutauras Vilda
  • Henry Wong
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Al Hobbs
  • Carey Brown
Bartenders:
  • Piet Souris
  • Mikalai Zaikin
  • Himai Minh

UML - Where does performance go in use cases

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I am currently working on writing my use cases based on the requirements for a Java based SDK. There is a requirement stating that the performance of this SDK at runtime should be a certain level. I am not sure exactly how this should(if at all) be represented in a Use Case, or indeed where in my UML this should be put.
Just new to the UML - and havent seen this in any examples to date. Hope someone can help.
Regards,
Paul.
 
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I guess I would argue that use cases are not quite the same as requirements management. Use cases are useful (sic) for uncovering requirements and major system interactions. Specifying performance expectations is a good thing, but I'd have to wonder if you could place them effectively in a use case. At best, they'd have to be indications of the performance expectations of the user (i.e. gui responsiveness on a task). I don't see them as a way of indicating things like server load/utilization metrics.
Maybe this comes down to distinguishing functionality from constraints in your requirements. Use cases I don't think present constraint information very effectively. I think you need a requirements doc, apart from the use cases, to capture that information.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with Reid.
Notice also that UML Use Case Diagrams and Use Cases are *not* the same. Use Cases are typically in text form, whereas Use Case Diagrams are only a simplified representation of the collection of Use Cases.
 
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Larman suggests that performance constraints be defined in "Supplementary Specification". 2ed p88
 
Reid M. Pinchback
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
I agree with Reid.
Use Cases are typically in text form, whereas Use Case Diagrams are only a simplified representation of the collection of Use Cases.


Also, some writers emphasize the distinction between a use case, as Ilja has described, and a use case scenario. The former is a higher-level abstract description of the interaction. The latter is a specific situation, preferably grounded in a real-world example.
The reason for making the distinction is important. You hope that the high-level abstraction captures the issues, but sometimes it doesn't. People can make unwarranted assumptions if they don't periodically use a real problem to ground the requirements capture. Scenarios are viewed as being a more robust way of keeping you in touch with the real facts. After you get some scenarios you step back and try to create a reasonable abstraction in the use case.
It might be that performance issues could have been raised in discussions with an end-user during scenario capture. A high-level use case discussion (probably with a supervisor instead of the real do-er of a task) may never reveal the constraint.
 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
If one follows Rational's Approach, then we can say that the interactions of the system with the external enviornemnt is represented by use cases. So we can say the functional requirements of the system under considerations are captured by virtue of use case diagrams, and the non functional requirements of the system under consideration shud be put into a document called Supplementary Specifications. So at the end of the requirement analysis stage, what one has is a use case model which comprises of use cases, supplementary specifications and glossary.
I hope this piece of info helps u in some regards. You can put ur performance requirement in ur supplementary specification document.
 
reply
    Bookmark Topic Watch Topic
  • New Topic