Interfaces in Component Diagram

[Rob Rider]

Hi!

UML 2 utilizes "ball and socket" notation as a standard way to describe communication between components via interfaces. But some small-scale components in my design like domain objects, JSF backed beans etc. doesn't implement interfaces. Could anybody advice the correct way to show components without explicit interfaces and their communication in Component Diagram?

Thanks you in advance,
Rob

[J J Wright]

I think maybe you're missing the point about what a component actually is. If you try and make everything a component (backing beans, business objects, etc.) what's to separate your component diagram from your class diagram? It sounds like the small-scale objects you're describing should possibly be the constituent parts that realise a larger component.

A component should be an autonomous unit that can be replaced by any another component exposing the same provided interfaces. In which case, is a backing bean really a component?

[Ronald Wouters]

In my assignment it said

Examples of components are EJB, servlets, JSP, major POJO, and important Managers, Controllers...

When talking about "interfaces" in component diagrams, you should not interpret the word "interface" only in the strict sense of a Java language interface definition. Things like, "SQL", "HTTP", "JSF EL", "JDBC", "Reflection API" can all be considered to be the "interface" between "components". A jsf backing bean can be considered an "important controller" (if it fullfils the same role as a controller servlet say) and therefore qualifies as a "component" to be shown on the component diagram. In case there is no interface available, in the strict java language sense of the word, consider another, possibly "higher level" interface as I mentioned above.


Regards

[Rob Rider]

Jonathan, Ronald! Thanks you for you replies!

It seems I really have miscomprehension with components My design contains the following elements:
- JSP and JSF backing beans at presentation tier
- Services and gateways designed as session EJBs
- Domain model is mostly anemic, domain objects are POJOs

I think that each EJB is good candidate to be a component. But:
- I'm going to show JSF as a <<framework>> and FacesServlet as a <<Front Controller>>. Which interface may be used to connect backing beans with JSF or FacesServlet? Ronald, as far as I understand, you suggest to use "ball and socket" notation with "Reflection API" interface name for this?

- How domain objects should be shown - as single component or as set of components? The main problem here is that domain has no explicit interfaces and all Services and JSF beans depends from domain objects, uses them. Hence domain objects are involved in numerous dependencies. It seems ugly, but how I can avoid this?

Thanks,
Rob

[J J Wright]

When talking about "interfaces" in component diagrams, you should not interpret the word "interface" only in the strict sense of a Java language interface definition

This is true. And, in the case of a backing bean, you are correct in that the backing bean is declared in the faces-config.xml, referenced by a logical name, and used via the expression language. As a result there's no real dependency on its type so you could swap it for another that exposes the same functionality (i.e. UML component "interface"). I stand corrected!

[J J Wright]

I'd be interested to hear what other people think, but in my opinion you should try and divide your system into a number of cohesive subsystem components. Domain objects can then be contained within the appropriate subsystem. Presentation tier classes should also be contained in a high level component. This component would then be realised by other components such your web framework, JSPs, and servlets. Dependencies can then be expressed more succinctly as dependencies between subsystems.

[Rob Rider]

Thanks, Jonathan! But I'm steel not clear with the following:

And, in the case of a backing bean, you are correct in that the backing bean is declared in the faces-config.xml, referenced by a logical name, and used via the expression language. As a result there's no real dependency on its type so you could swap it for another that exposes the same functionality

Ok, this concept is clear, but how this should be expressed in UML?

Dependencies can then be expressed more succinctly as dependencies between subsystems.

Domain classes are explicitly used in presentation tier (domain objects are simple in this design, hence there are no additional DTOs between domain and presentation tier) - in JSP, backing beans etc. In this case dependencies between these subsystems will be like "presentation subsystem uses everything from domain subsystem", this is not good type of dependency . Of course, there is a solution - create numerious DTOs in Services or Presentation, but in this particular design these DTOs will duplicate domain objects. Could you please suggest another approach?

Thanks,
Rob

[J J Wright]

If you're domain model objects are essentially anemic I don't think they should be shown as components. For example, what's the difference between returning a Date object and an anemic domain object? In my opinion there isn't any, they simply form part of the enclosing component's exposed interface.

Even if you have a rich domain model and no DTOs the same argument holds true. You can, and probably should, use some kind of Interface Segregation to only expose the minimum required functionality, i.e. getters and possibly setters. Again this interface would simply form part of the interface of the enclosing component.

this is not good type of dependency

You can't avoid dependencies in OO programming. The more important goal should be to enforce protected variation. If your domain model is unstable then the cost of introducing a layer of DTOs may be worth it. If it isn't, then having other components depending on it isn't a big problem.

Scott Amblers book on Agile Modeling contains some of the most useful information I've found on the subject.

[Hong Anderson]

Rob Rider wrote:
In this case dependencies between these subsystems will be like "presentation subsystem uses everything from domain subsystem", this is not good type of dependency . Of course, there is a solution - create numerious DTOs in Services or Presentation, but in this particular design these DTOs will duplicate domain objects. Could you please suggest another approach?

I don't get why you think it's not *good type of dependency*?
What criteria do you use to judge what is "good type", and what is "bad type"?

And I don't see how DTO would be a solution, as the name suggests DTO is used for "transferring", if you don't use remote interfaces to pass data, no need to use DTO at all.

[J J Wright]

And I don't see how DTO would be a solution

I was talking about DTOs, for want of a better term, in the context of adding a layer of abstraction between a volatile domain model and the presentation tier. But as I said you can also achieve the same degree of abstraction using Interfaces. If your domain model changes you simply implement a set of adapters to wrap your domain objects.

[Hong Anderson]

Jonathan Aotearoa wrote:

And I don't see how DTO would be a solution

I was talking about DTOs, for want of a better term, in the context of adding a layer of abstraction between a volatile domain model and the presentation tier. But as I said you can also achieve the same degree of abstraction using Interfaces. If your domain model changes you simply implement a set of adapters to wrap your domain objects.

If domain model changes just change presentation tier, it's very easy and very simple.

For example I have ModelA which have 2 attributes, after that I add 1 attribute, in View layer, I just modify to display the additional attribute.

If use DTO, we need to add attribute in ModelA, and add in DTO and change View. How does that help?
It's not like that we change model, and DTO then we don't need to do anything to UI codes.

[Rob Rider]

I don't get why you think it's not *good type of dependency*?
What criteria do you use to judge what is "good type", and what is "bad type"?

I have in mind that such type of dependency violates component concept as "A physical, replaceable part of a system that packages implementation and
conforms to and provides the realization of a set of interfaces". In this case tightly coupled subsystems are not replaceble and do not provide the realization of a set of interfaces.

If use DTO, we need to add attribute in ModelA, and add in DTO and change View. How does that help?

If we talking about single attribute then there is no problem to be solved via DTO. But if we have a set of large and complex domain objects and tens of use cases it will be very unsafe and inconvenient for presentation level to operate directly the domain objects. Each use case should operate a particular subset of domain functionality and this subset may be collected and delivered to presentation level via DTOs. In my small design this approach is not necessary, but may be used for domain isolation.

But as I said you can also achieve the same degree of abstraction using Interfaces.

It seems this approach is more simple and compact than DTOs. But from SCEA part II point of view:
- Should these interfaces be shown in Class Diagram explicitly?
- Is it ok to show that all services and presentation tier components are dependent from one Domain component even via interfaces?

Thanks,
Rob

[Hong Anderson]

Rob Rider wrote:

I don't get why you think it's not *good type of dependency*?
What criteria do you use to judge what is "good type", and what is "bad type"?

I have in mind that such type of dependency violates component concept as "A physical, replaceable part of a system that packages implementation and
conforms to and provides the realization of a set of interfaces". In this case tightly coupled subsystems are not replaceble and do not provide the realization of a set of interfaces.

Where do you get that description?
This is from UML 2 Superstructure:

A component can always be considered an autonomous unit within a system or subsystem. It has one or more provided and/or required interfaces

And a tightly coupled subsystems are replaceable, why not? It can be replaced with other component thats provide the same functionality.

Rob Rider wrote:

If use DTO, we need to add attribute in ModelA, and add in DTO and change View. How does that help?

If we talking about single attribute then there is no problem to be solved via DTO. But if we have a set of large and complex domain objects and tens of use cases it will be very unsafe and inconvenient for presentation level to operate directly the domain objects. Each use case should operate a particular subset of domain functionality and this subset may be collected and delivered to presentation level via DTOs. In my small design this approach is not necessary, but may be used for domain isolation.

First I think we shouldn't use term DTO, because what we are discussing is not DTO, let's call it Value Objects [DDD].
I'm not sure what you mean by unsafe? View should do only display, how displaying is unsafe?
Regarding, inconvenient why do you need to care? It's the job of View layer after all. If it contains reuseable part, you can create a UIRenderUtil class and put complex logic in that class for View layer to call.

You know, using Value Object is tight coupling than using domain model. If you have 10 Views, each view displays the same models differently, what should we do? Create 10 Services that return 10 different Value Objects for different View? We should put presentation logic in each view instead. How to render? how to display? Those are responsibility of View.

[Rob Rider]

Where do you get that description?

This is description from UML 1.3 specification.

And a tightly coupled subsystems are replaceable, why not? It can be replaced with other component thats provide the same functionality.

May be, but I think that desing should be loosely coupled if possible.

First I think we shouldn't use term DTO, because what we are discussing is not DTO, let's call it Value Objects [DDD].
I'm not sure what you mean by unsafe? View should do only display, how displaying is unsafe?
Regarding, inconvenient why do you need to care? It's the job of View layer after all. If it contains reuseable part, you can create a UIRenderUtil class and put complex logic in that class for View layer to call.

You know, using Value Object is tight coupling than using domain model. If you have 10 Views, each view displays the same models differently, what should we do? Create 10 Services that return 10 different Value Objects for different View? We should put presentation logic in each view instead. How to render? how to display? Those are responsibility of View.

It seems to me than if we have 10 complex domain objects and View which uses one field from each object it will be more convenient to assemble single VO and pass it to the View. Of course, this is not a doctrine, solution depends from many factors.



Ok, I think we deviated from original problem. Assuming that VO is a wrong way, how domain objects should be shown in Component Diagram? Should dependencies be explicitly shown for all other components which uses classes from domain?

Thanks,
Rob

[Hong Anderson]

I don't think we should put Domain Model in Component diagram, think about component in term of component-based development.

Regarding UML, UML 2 changes meaning of component concept. Component description in UML 1.x can cause confusion, but it's already addressed in UML 2, I suggest not to use Component description in UML 1.x.
Please take a look at the following article: http://www.ibm.com/developerworks/rational/library/dec04/bell/

[Rob Rider]

Well, assuming that the Domain Model component isn't shown in diagrams, how to link domain objects to artifacts (like domain.jar)?

Thanks,
Rob

[Hong Anderson]

If you think that make diagrams clearer, you can put it in component diagram.
But for me, it's not much necessary because we already have Domain Model in class diagram, so it's obvious that Components uses what models.