• 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
  • Ron McLeod
  • Paul Clapham
  • Jeanne Boyarsky
  • Liutauras Vilda
Sheriffs:
  • Rob Spoor
  • Bear Bibeault
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Piet Souris
Bartenders:
  • Frits Walraven
  • Himai Minh

Depicting a calculation in a Use Case diagram

 
Ranch Hand
Posts: 424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have some logic that calculates customer income and I have to depict it in a Use Case.

I think the 'borrower' or 'screen' would be the Actor. The 'calculate' is the Use Case (action). But I am not sure how to depict the income sources that are being added together.

(Displayed on a screen)
Customer Income Total = (If income source1 > 0 then add to total) +
(If income source2 > 0 then add to total) +
(If income source3 > 0 then add to total) and so on...
[ February 07, 2006: Message edited by: M Burke ]
 
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by M Burke:

I think the 'borrower' or 'screen' would be the Actor. The 'calculate' is the Use Case (action).

(Displayed on a screen)
Customer Income Total = (If income source1 > 0 then add to total) +
(If income source2 > 0 then add to total) +
(If income source3 > 0 then add to total) and so on...

[ February 07, 2006: Message edited by: M Burke ]



In the usecase 'action' there must be a 'class' thats responsible for calculation.

So if you draw a sequence diagram, there would be a message from actor borrower, to object 'screen' . This message could be like 'calculate total'.
(1) Now the screen object, can send three messages to a dumb 'calculate' class, these three messages will be like three arrows that have same origination point, but different destination points on 'calculate' lifeline, with conditions can be placed on the arrows
OR
(2) screen object can send one message calculatetotal to self contained 'calculate' class with necessary 'parameters', and you can show self calling messages on caculate class.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A Use Case is a *textual* description of a requirement. A UML Use Case diagram isn't where the meat is - it just provides a rough overview over the existing Use Cases.

Additionally, even a textual Use Case shouldn't contain every detail of the business rules - those should be documented separately.

See http://www.agilemodeling.com/artifacts/essentialUseCase.htm for more details.
 
Babji Reddy
Ranch Hand
Posts: 106
  • 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:
A UML Use Case diagram isn't where the meat is - it just provides a rough overview over the existing Use Cases.



You are right, Usecase diagram is not meant for depicting flows.

.. even a textual Use Case shouldn't contain every detail of the business rules - those should be documented separately.
Well this depends on the granularity of the usecase. If the usecase itself is very tiny that does a little, then we need not document business rules separately. You can explain them using Normal , Alternate flows sections of usecase text.
 
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What you really need to do is create one of:
1. Use case.
2. UML Activity diagram.
3. Flow chart.

Fundamentally, you need to understand the strengths and weaknesses of multiple models so that you can apply the right artifact. You might find Artifacts for Agile Modeling: The UML and Beyond to be of value.

- Scott
 
Ranch Hand
Posts: 1934
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Why not add a comment on the usercase that is provided in a table format.

I am not sure why some of these authors and design officianados despise it.

There is nothing wrong with use case being somewhat explanatory.
 
Scott Ambler
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Within the use case that makes sense.

On the use case diagram all you would do is clutter the diagram.

Apply the right artifact for the situation.

- Scott
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic