Is component always interface implementation?

1.3k Views Asked by At

I want to show architectural representation of my software. My college lecture recommend me to use component diagram. But what i should draw as my component if my software doesn't use interface at all?

Because AFAIK, component in component diagram consist of interface and their implementation. Unfortunately, my software (an Android application) doesn't use interface at all (only use interface as retrofit API). I read some of the post in stack overflow, but that doesn't give me a sense. I ended up drawing the component diagram below per directory. Please give me some suggestion to draw component diagram.

enter image description here

2

There are 2 best solutions below

0
On BEST ANSWER

According to the UML specification it is allowed to have a component without an interface in a component diagram, at least I am not aware of anything in the specification that would forbid that. If one component X uses another component Y, you should draw a dependency relationship (a dashed arrow with an open arrowhead) from X to Y, optionally adorned with stereotype ≪use≫.

Here are my comments on your component diagram:

  • Replace the solid arrows between packages by dashed arrows between components.
  • Do not use the ball-and-socket notation, but use dependencies on interfaces instead (see my answer on this topic).
2
On

The answer is in your diagram. You have four components, in four different packages. You have explicitly identified an API (Application Programming Interface) between your Android app and your server, that much is obvious. However you have also identified at least 5 other interfaces here:

  1. Your Android App is stereotyped as "UI" (which I presume to mean User Interface). This is an interface between your user and your system.
  2. Android App connects to (references?) Database. That's another interface -- assume some sort of OLTP if its an RDBMS?
  3. UI to application model. This could be interfaced internally within your runtime assuming your model is compiled-in to the app.
  4. Server to application model. Again internal to the server assuming its compiled-in.
  5. Application model to Database (I assume you have the reference arrow the wrong way around here?).