UML 类图:健身追踪器 [英] UML CLASS DIAGRAM: FITNESS TRACKER

问题描述

嘿，我是制作类图的新手，我被指派为我的团队将要开发的健身计划制作一个简单的类图.

Hey I am new to making class diagrams and I am assigned to make a simple class diagram for a fitness program my team is going to develop.

我擅长制作类和属性.我对它的关系部分、聚合和所有这些好东西有问题.

I am good with making the classes and attributes. I am having a problem with the relationships part of it, aggregation and all of that good stuff.

这是一个简单的运行:有一个培训师，每个培训师都有一个客户.每个客户都有一个前后报告.此外，还有针对每位客户的每日锻炼团、每周处方和日志.

Here is a simple run down: There is a trainer, and each trainer has one client. There is a before and after report for each client. Also there is a daily workout regiment, weekly prescription and logs, for each client.

我已经添加了我已经拥有的草稿的图像.

I have added a image of a rough draft of what I have already.

推荐答案

首先client和trainer之间没有任何特定的属性来建立关系，关联是可以的，但是没有任何方法可以从中找出client培训师，反之亦然.
您可能需要通过提问来了解和使用会员之间的关系.
所以让我们从教练开始.

培训师
问:您是通过培训师找到客户，反之亦然?
A[0]: 客户端是由它的培训师找到的 (trainer->client) => 所以在这种情况下，你需要在培训师内部跟踪(拥有)客户端引用.

A[1]: 训练器被它的客户端找到(client->trainer)

A[2]: 培训师和客户都应该有相互参考


上述情况适用于(之后/之前)报告和客户端.

每日锻炼表
所以这里每个客户都会有 1 个以上的锻炼表，所以这里我们有聚合和组合，区别并不难理解.
Composition: 表示Client有一个DailyWorkoutSheet的列表和DailyWorkoutSheet的生​​命周期code> 是 Client 生命周期的 DEPENDENTS，这意味着如果 Client 被删除(从内存中删除)，那么这将导致删除所有DailyWorkoutSheet 的引用，这些引用与 Client 引用相关联.

(构图形状是一个填充的菱形，指向主持(client)客人(DailyWorkoutSheet)的班级)

Aggregation:表示Client有一个DailyWorkoutSheet的列表和DailyWorkoutSheet的生​​命周期code> 在 Client 生命周期中是 INDEPENDENTS.所以这意味着删除 Client 引用后，与 Client 引用关联的 DaileyWorkoutSheet(s) 将持续存在.

(聚合形状是一个空菱形，指向主持(client)客人(DailyWorkoutSheet))



上面的场景对于Client 和WeeklyPrescription 和Logs 之间的关系是正确的.

first there is no any specific attribute between client and trainer to make the relation, the association is okay, but there is no any way to find out the client from the trainer or vice versa.
you may need to understand and use the relations between members by asking some question.
so let's start with trainer.

Trainer
Q:do you find a client by its trainer or vice versa?
A[0]: the client is found by its trainer (trainer->client) => so in this case you need to track(have) the client reference inside the trainer.

A[1]: the trainer is found by its client (client->trainer)

A[2]: both trainer and client should have references from each other


the above scenario is true about (after/before)reports and client.

DailyWorkoutSheet
So here each client would has more than 1 workout sheet, so here we have Aggregation and Composition and the difference is not to much hard to understand.
Composition: it means Client has a list of DailyWorkoutSheet and the life-cycle of DailyWorkoutSheet is DEPENDENTS on Client life-cycle, it means if Client get delete(removed from memory), then this will causes to remove all references of DailyWorkoutSheet(s) which have associated to the Client reference.

(the composition shape is a FILLED diamond which points to the class which host(client) the guests(DailyWorkoutSheet))

Aggregation: it means Client has a list of DailyWorkoutSheet and the life-cycle of DailyWorkoutSheet is INDEPENDENTS on Client life-cycle. so it means with removing the Client reference, the DaileyWorkoutSheet(s) which have been associated to the Client reference will persist.

(the aggregation shape is a EMPTY diamond which points to the class which host(client) the guests(DailyWorkoutSheet))



the above scenario is true about the relation between Client and WeeklyPrescription and Logs.

这篇关于UML 类图:健身追踪器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！