is the Entity in BCE equals to EJB?

[Sean Li]

when in analyse phase, we use BCE to represent three kinds of classes. but is this entity equals to EJB?
I'm confused at this point. because I think a entity here only means an object. information of this object may be saved to RDBMS, but it's only an object in memory now. writing to RDBMS only happens when we invoke some methods like save.
But if we take is as a EJB, every method on it will directely bind to RDBMS. in most cases, we won't need that.
I just read a article named "Developing J2EE Applications with the UML and Rational Rose", I don't agree with the author too much. I think there are many differences between entity with EJB. but I cannot tell it clearly.
maybe I have some conceptual errors. please help me. thanks.

[Ilja Preuss]

What does BCE stand for?

[Sean Li]

B:Boundary
C:Control
E:Entity

[Ilja Preuss]

Oh, OK. I guess the article is http://archive.devx.com/judgingjava/whitepapers/rational/default.asp ?
I think you are correct - there is no direct relationship between the entity stereotype in your analysis model and entity beans in EJB.
I also find it to be suboptimal to divide a system into data (entity objects) versus behaviour (controll objects). After all, one of the main concepts of OOP is to put data and the associated behaviour (that is, the operations on that data) into the *same* place.

[Anonymous]

Nice reference, Ilja,
but nevertheless, I shall write some remarks to myself.
1)First of all, EJBs are not used for simple applications (it is overkill) at all. At least, it is wise to avoid them there.
2)EJB is the code, components and have correspondence in design or implementation models. Starting from design models the stereotypes BCE are usually not used.
Entity Class is steretyped analysis class from UML profile foer Software Development.
Analysis model represents a high-level overview of a problem domain, what to do (in contrast to how to do in design models).
The goal of an analysis model is to create a preliminary mapping of required behavior onto modeling elements in the system. In most cases, it omits the detail of a design model in order to provide an overview of the system functionality.
O)nce more, the design or implementation models map to components/code, like EJB and analysis models map to design model. At least in my head.

[Ilja Preuss]

Originally posted by Tom�s S�oPaulo:
1)First of all, EJBs are not used for simple applications (it is overkill) at all. At least, it is wise to avoid them there.

In my humble opinion, it would also be wise to avoid them for many complex applications. They add their own complexity and bottlenecks to a system and constrain the design in some ways that seem to yield "less OO" solutions. You should very carefully weight the pros against the cons before deciding to go with them.

[Sean Li]

Tom�s S�oPaulo, are you the author of that article?
I know EJB is a big and resource consuming stuff, and I know I should not use them in improper situation. but the question now I'm facing is the OOAD problem.
as you said, BCE are stereotypes used in analyze phase. only in design phase, whether to use jdbc or ejb is considered. I know what u mean.
but in analyse phase, i still don't know how to deal with a persistence problem. a entity class is of course a persistence class, which in design phase will be connected to a table in a certain database. but in analyse phase, i have many methods to act on the entity class, some of them are create, modify, delete and update. are the methods here directely write to database or just a memory address? I know I should not think of that, because it's the issue of design phase. so what to do in design phase?
I don't know. maybe I still have conceptual problem. help me please!

[Ilja Preuss]

Originally posted by Sean Lee:
but in analyse phase, i still don't know how to deal with a persistence problem. a entity class is of course a persistence class, which in design phase will be connected to a table in a certain database. but in analyse phase, i have many methods to act on the entity class, some of them are create, modify, delete and update. are the methods here directely write to database or just a memory address? I know I should not think of that, because it's the issue of design phase.

Then don't do it? If you realy need to define which information needs to get persisted, use a tagged value {persistence = persistent} (see http://softdocwiz.com/Dictionary.htm#persistence). Or just mark it with a big P and communicate to your coworkers what the means...

so what to do in design phase?

In the design phase you need to decide how to persist the data. I wouldn't do this to early in the game, though...
Did that help at all?

[Sean Li]

I don't know, but thanks anyway.
maybe I should not think about the implementation of BCE in analyse phase too much. maybe the task of AD is just to get the essential attributes and operations.
but u know? the operations in a memory object is different with a object which is connected to database. maybe i should deal with the operations in design phase. which seems to hard for me.

[Frank Carver]

I think you may be confusing the goals of "analysis" and "design". Analysis is all about understanding what is wanted. Design is all deciding about how to provide it.
Your decisions about persistence seem very much part of the "design" activity. The analysis aspects of this work should include things which will help you decide how to design your solution. Things like getting user measurements (or at least informed estimates) of data sizes, frequency of views and updates etc. Once you have this sort of information available, you can start to make sensible choices about how to persist the necessary data.
There are lots of options: EJB, Object-relational mapping tools of many types, Prevalence, and so on. All of these have their advantages and disadvantages. Please don't feel you have to force a decision before you understand the problem.
For many low volume applications you may not need a database at all.

[Stan James]

I have to ring in with agreement with the last post. Persistence is a tricky bit of design. In early analysis you can completely ignore it.
When you put a domain object(E from BCE) in a design, imagine that it always exists, just like a real-world person, place or thing. If you can't quite make that leap, imagine that it will transparently take care of its own persistence.
For example, I work with customer service on insurance contracts. In domain analysis and highest level design we might have a contract object. If the customer changes his billing option, we draw a contract in a diagram and set the new billing option. And don't worry a bit about "retrieve from database" or "update to database".
Of course if you are explicitly creating new things, they "exist" only after you create them. If we sold new contracts we'd show creating them, but still no "save to database."