StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
7221472
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2011-08-28T14:10:12.823
FavoriteCount
0
LastActivityDate
2011-08-28T14:10:12.823
LastEditDate
LastEditorUserId
0
OwnerUserId
419525
ParentId
7216538
PostTypeId
2
Score
1
ViewCount
0
LastEditorDisplayName
text
Body
I think you need to step back a little first. The purpose of Actors & Use Cases is to first ask: "who will use this system?" and "why will they use it?". You could start identifying till, printer, etc. as Actors - and indeed, some of them may be - but there's a danger you'll miss the key point. From your description, I'd guess the Actors and their Use Cases would be along the following lines: <ul> <li>Actor: Customer <ul> <li>Primary Use Case: Buy Product. This will likely break down into a few sub steps, e.g. Browse/Compare Products, Select Product(s) (place in shopping basket), Checkout, etc. There will also be supporting UCs: Check status of order, return goods, make complaint, etc.</li> </ul></li> <li>Actor: Accounts Clerk <ul> <li>Use Cases: presumably something to do with checking order/payment status</li> </ul></li> </ul> ...etc. When you come to designing the flow for each UC you will likely identify other components external to your system with which you need to interact - e.g. payment partner. You can show these as Actors if you wish (my preference is not, but that's purely personal). You'll also identify other elements of your system that play a role in realising the UC behaviour (e.g. sales db etc). These are part of your system - and wouldn't typically be shown as Actors. So in summary: Use Cases are meant to help you identify the purpose of the system and who receives value from it - rather than structure the internal design components. hth.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POIdentifying Actors for Use Cases
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USsfinnie
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.