UML Notation of HttpGet method

Viewed 89

I'm working on a UML diagram of a Web API

UML

Where i have a HttpGet method:

// GET: api/Posts
[HttpGet]
public async Task<ActionResult<IEnumerable<Post>>> GetPosts()
{
   return await _context.Posts.OrderByDescending(x => x.Date).ToListAsync();
}

I'm not sure how to show that it is an async task with ActionResult<IEnumerable<Post>, and how the return should look like.

Second question: How would an association of a Model and a controller look like?

1 Answers

Preliminary remark: It is not clear what {virtual} could mean in UML. Prperty modifiers and constraints are syntactically expected at the end. Is it possible that there is a stereotype defined in your UML profile to enrich standard UML with additional semantics? In this case, it should be «virtual».

Asynchronous design: ActionResult<IEnumerable<Post>> could be modelled as any other type. You may simply consider it as a distinct class and use its name in GetPosts() signature. The asynchronous calls are not modelled in a class model, at least not if the call can be synchronous as well as asynchronous: This detail is then shown in a sequence diagram. However:

  • You could think of using active classes, for classes designed to always run in their own thread. But asynchronous calls to a class do not seem sufficient to justify this.
  • If some methods are designed for being always called asynchronously, you may consider modelling them as receptions of signals. Signal and receptions are less-known UML features that are meant especially for modelling asynchronous communication. It's as simple as methods, but in a separate compartment, below the operation compartment, and each preeded with the keyword «signal».

Link between controller and model in your diagram: The only model element in your diagram seems to be Post. And the PostsController doesn't seem to keep any relation to Posts, except that it may use them in some calls. You'd then show this relationship with a usage dependency (dotted arrow with the «use» keyword). From an MVC point of view, the controller is expected to know somehow the model to be able to send commands to it. It is possible that this relationship is indirect (i.e. PostsController is related to a Controller which knows a Model which knows Post) but this is purely speculative here; you could ask a distinct question focused on this problem, but with some more infos provided.

Related