我正在根据以下场景创建用例图:
有一个移动应用程序可以将数据传递到网络服务器/数据库。另一方面，网络服务器将数据发送到移动应用程序。
所以我有两个问题:
发送到应用程序的数据仅为该智能手机/用户的个人数据。那么，将服务器/数据库显示为与特定用例连接的外部系统参与者是否有意义？
(对于移动应用程序)是否有必要使用“显示有关某物的信息”或“刷新数据”等用例？因为我认为它们对于业务逻辑来说不是必需的。你觉得怎么样？
感谢您的想法!
最佳答案
Data send to the application is individual data only for this smartphone/user. So does it make sense to show server/database as an external system actor which gets connected with the specific use cases?
仅当服务器/数据库确实是一个与您的系统通信的外部系统时。如果不是，那么它就不可能是一个参与者，并且您应该强制进行额外的 UML 建模以阐明整体系统结构(组件图 + 序列)。
数据是单独的这一事实与此决定无关。 :)
Are use cases (for the mobile app) like "showing information about something" oder "refresh data" necessary? Because i think they are not necessary for the business logic. What do you think?
如果您正在构建此移动应用程序，并且这些是要实现的要求，那么您绝对应该将它们捕获为用例。
“它们对于业务逻辑来说不是必需的”是什么意思？
首先，您的系统的范围是什么？ (移动应用程序、移动应用程序+服务器/数据库或其他)？
更新(清理系统范围后)
We are building the mobile app AND the database. So we are not just getting data from there and send data. We´re modelling the whole system
范围现在很明确 - databese/server 不能成为参与者，因为它是范围的一部分。我看到的唯一参与者是移动应用程序用户。
when just placing the user beeing an actor and the app beeing the system i don´t know how to describe the use case, because i think i have to mention in the uce case description that data was send to server, etc...
您不必将所有内容都放入用例描述中，我很快就会回来讨论这一点。
For example: one use case is about taking a picture and send this to the server- –
那么，这个UC有什么问题呢？参与者是移动应用程序用户，用例是“上传图片”(可以选择包括拍照)。
我认为您对尝试将所有问题都放入用例模型中的几个问题感到困惑，而这是不可能的。
因此，我建议您将 cpncerns(系统的各个方面)分开，制作如下图表:
- 业务级别:事件图显示应用的整体使用情况/业务工作流程
- 用于捕获需求的用例模型
一定要从 Actor 的角度使这个模型变得简单。只需确定 Actor 可以执行的一小组有意义的交互(不是低级别的)。 例如:“上传照片”、“刷新数据”可能是一些可靠的UC
- (可选)概念/数据模型(清理相关数据结构)
- 通过组件/部署图的系统结构(这里显然至少有 3 个组件:移动应用程序、WEB 服务器(或从移动应用程序接收请求的任何内容)和数据库
- 通信机制 - 使用组件的序列图
现在您需要一些“粘合剂”来关联不同的概念 - 对于每个用例，使用组件图中的元素(+类(class)参与者)创建一个序列来显示其工作原理。
重点是“开放”用例并根据系统结构元素展示其内部实现。
关于mobile - UML 用例图服务器作为系统参与者以及哪种用例，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/23805681/