• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

UML 2.0 component diagram

 
Saha Kumar
Ranch Hand
Posts: 218
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello All,

For a UML 2.0 component diagram:
The classes that are accessed by the exposed class should not be accessible to the client. Is it acceptable UML practice to have these classes show up in other component diagrams.

For example:

Component A:
A->B->C->D, where A,B,C,D are some type of Java classes.
Classes B, C, and D cannot be accessed by the client.


Component X:
X->Y->C, where X,Y,C are some type of Java classes.
Classes Y, C cannot be accessed by the client.

But is it valid that both component A and X can access C?

For example, can a given entity bean be accessed by two different session beans: SessionBeanA and SessionBeanB ?? Or is this considered poor design?

Thanks in advance.

-Saha
 
Saha Kumar
Ranch Hand
Posts: 218
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello All,

I think each entity EJB should only be accessed within one component. So no two UML 2.0 components access the same entity bean. This is what I am designing by.

Any thoughts?

-Saha
 
Ricardo Ferreira
Ranch Hand
Posts: 156
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Saha Kumar:
Hello All,

I think each entity EJB should only be accessed within one component. So no two UML 2.0 components access the same entity bean. This is what I am designing by.

Any thoughts?

-Saha


Hi Saha,

Well, first, to answer your question, it is not considered a poor design if you access one component (entity bean for example) by two diferent other components (an session bean for example).

Anyway, there are a lot of considerations to do, in order to decide the component dependency at you component diagram. And, talking about your second post, is not considered wrong access one component by only one another component. But do not think that is a kind of rule. Think that is a kind of rule or good technique, is considered wrong.

To effectively create a good design for an application using an component architecture, you should consider a lot of things before agree with some rule. You should group your pieces of functionalities or use cases into a single main boundarie for the system.

I think that a more detailed explanation are needed ... , so, let's go ...

Forget UML and J2EE for a moment. Let's talk about how related and coupled are your application services. When you start an project design, you must define wich important use cases are present in the context of your project.

There are two kinds of use cases: Business Uses Cases and Regular Use Cases.

The business use case represents the major vision about the project to ensure what the system must do and why. Threre is nothing technical in business use cases.

"The main purpose of the Business Case is to develop an economic plan for realizing the project Vision. Once developed, the Business Case is used to make an accurate assessment of the return on investment (ROI) provided by the project. It provides the justification for the project and establishes its economic constraints. It provides information to the economic decision makers on the project's worth, and is used to determine whether the project should move ahead." (RUP 2003)

The regular use cases or just 'use cases', are the realization of the business use cases, and they express how the system should perform the user needs given a specific scenario and an actor. Normally, use cases are written peer functionality and they represents the requirements for the application.

Let's go for an example:

----------------- [Contact Record Application] -----------------

[Business Use Case]: "The record contact application should record all the contact's of an specific user. The person should be able to create an new contact, update an existent, and delete one or more contacts recorded. Moreover, the user also should be able to search recorded contacts given your name and/or id."

You could see in this simple explanation from the user vision about what it wants that you create. There is nothing technical or specific in this explanation, and we can easily identify the application requirements in the text, wich are:

1) create new user
2) update user
3) delete user
4) search user by name or id

When you broke down an business use case to smallers and well defined pieces of functionalities, you are creating the application use cases. Apart from those use cases, you start to define, in terms of details, what and how, each use case must do, from the users perpective. At extremme programming (XP, Kent Beck) we can also call these of user stories.

What the SCEA assignment gives to you, is those use cases already defined and discussed. As an architect, you should be able to do the next follow lines in order to create an design for an paiyng customer, or, for the SCEA certification. So, pay attemption.

Let's go forward to the application design. The second step is define which are your entities at you application inception view. We can define that this simpliest application has one single entity, that is, the contact. So, let's consider that our contact entity will be represented by one Entity Bean. So, we have created our first application component. Let's call it of 'ContactBean'.

Now, we've seen that our application has four use cases. The first three use cases (create, update and delete contacts) can be grouped into a single object the represents all the related operations. You should agree with the idea of, the create, update and delete actions, represents the requirement of maintain the contact. So let's consider and define, our first boundarie for the application: The maintenance boundarie. This boundarie will group the follwing use cases: create contact, update contact and delete contact.

The last use case talks about an search feature, to promove the seek ability from the system, in order to make the user able to find recorded contacts. If you think for a while, you could see (and agree) that searching is not related with maintenance, and, should be considered out of the maintenance boundarie.

We can create an specific boundarie for this requirement (or group of related requirements), called searching boundarie. So, for now, we have two main boundaries:

- maintenance boundarie
- searching boundarie

That's it. Now that we have all the boundaries defined, we can create an ideal architecture that meet the requirements needs. A good technique well documented from Sun for this, is to create an facade for each boundarie of the system. So, talking about components (and talking about j2ee), we'll have two more components:

- an stateless session bean called MaintenanceFacadeBean
- an stateless session bean called SearchingFacadeBean

Both facades will access a common source of data, which is, our ContactBean.
For a good design, we can define to create local interfaces for the ContactBean, and expose ours facades by remote interfaces. Both facades will maintain an local reference for the ContactBean.

---

So Saha (and JavaRanch), if you could see in this explanation, i've tried to show you and for the others ranchers interessed in the architect certification, that is not a rule that an component is accessed by only one another component. IT DEPENDS OF YOUR DESIGN AND INCEPTION PHASES.

So, just to finish, let's go to learn something useful from this post:

- Facades should be created for each boundarie or view, not by each use case
- Components could be accessed by multiple others components
- Talking about EJB's, facades ALWAYS are remote components, never local
- Take care to do not create too many facades that could minimize the application granularity.

I really want that i could have helped you, JavaRanch!
 
Jignesh Patel
Ranch Hand
Posts: 626
Mac
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ricardo,

Very well explained.
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Saha,
Originally posted by Saha Kumar:
For a UML 2.0 component diagram:
The classes that are accessed by the exposed class should not be accessible to the client. Is it acceptable UML practice to have these classes show up in other component diagrams.

I did not yet (including the examples) understand the meaning of "the exposed class". Did you mean "the exposed interfaces", i.e. the provided interfaces? (Because no class or any realization details are to be exposed to the outside of a component, only interfaces are exposed).

Could you please clarify?

Thomas
 
Saha Kumar
Ranch Hand
Posts: 218
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Ricardo,

This is very clear now. Thank you for your valued response!

-Saha
 
Saha Kumar
Ranch Hand
Posts: 218
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Thomas,

Yes, I was referring to the exposed interface. Sorry for the ambiguity.

-Saha
 
Saha Kumar
Ranch Hand
Posts: 218
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello All,

Is protocol (HTTPS) or access control considered (depicted) in component diagrams?

Thanks.

-Saha
 
Saha Kumar
Ranch Hand
Posts: 218
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello All,

Would a BMP entity bean and its DAO be enclosed together in a UML 2.0 component diagram?

Thanks in advance.

-Saha
 
Saha Kumar
Ranch Hand
Posts: 218
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello All,

I noticed that in the Enterprise Architect for J2EE Technology Study Guide, the jsps which are included in the component diagram are forms. The jsps which present the product list, etc. are not shown in the component diagram.

Should we only show form-type jsps in our component diagram?

I have read in another post that we should include everything in the component diagram which fulfills a requirement.

Please give your input!

Thanks in advance.

-Saha
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Saha,
Originally posted by Saha Kumar:
Would a BMP entity bean and its DAO be enclosed together ...

I see these two as an eighther/or, so I could not see them together nor separatedn but just eighther/or.

Thomas
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Saha,
so what should I read after this clarification:

a) "The classes that are accessed by the exposed interface should not be accessible to the client."
- or -
b) "The interfaces that are accessed by the exposed class should not be accessible to the client."
- or -
c) "The interfaces that are exposed by the class should not be accessible to the client."
- or -
d) "The classes that are exposed by the interfaces should not be accessible to the client."
- or -
...
I do not want to guess. Please clarify. Thanks.
Thomas
 
Saha Kumar
Ranch Hand
Posts: 218
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Thomas,

Let me reword, because none of the choices are what I wanted. I just was not precise...my mistake...sorry. Anyway, I meant that in a component diagram, can the dependent classes show up in other component diagrams. I guess the answer is no. If the classes are not dependent, then they could not be shown inside the component diagram.

In another post, you said you would not put a DAO and a BMP entity together in the same component? If the DAO was not to be used anywhere else, wouldn't this be considered dependent?

Thanks in advance.

-Saha
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Saha,
Originally posted by Saha Kumar:
... in a component diagram, can the dependent classes show up in other component diagrams.

Dependent of what?
If "dependent of an interface" then we would not call it dependent but either provided or requested. Before having this clarified I can not give you any answer.

Maybe
- forbidding any direct dependency arrows in your component diagram and
- enforcing provided and requested interfaces on all the old arrows
helps to understand?

First of all you really should make clear to yourself what it means that a thing is "dependent" on another thing. Most dependencies in J2EE concern
1. changes within a method signature (parameters, types, ...) or
2. adding, removing whole method headers
of interfaces or classes:
a) explicitely in interfaces (of components and/or classes) or
b) implicitely in method signatures directly used by other classes - harder to survey.


Each dependency has two participants. Tell us both!

Thomas
[ May 12, 2006: Message edited by: Thomas Taeger ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic