wood burning stoves 2.0*
The moose likes OO, Patterns, UML and Refactoring and the fly likes is the Entity in BCE equals to EJB? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "is the Entity in BCE equals to EJB?" Watch "is the Entity in BCE equals to EJB?" New topic
Author

is the Entity in BCE equals to EJB?

Sean Li
Ranch Hand

Joined: Feb 27, 2002
Posts: 154
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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
What does BCE stand for?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Sean Li
Ranch Hand

Joined: Feb 27, 2002
Posts: 154
B:Boundary
C:Control
E:Entity
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Ranch Hand

Joined: Feb 27, 2002
Posts: 154
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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Ranch Hand

Joined: Feb 27, 2002
Posts: 154
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
Sheriff

Joined: Jan 07, 1999
Posts: 6920
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.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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."


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: is the Entity in BCE equals to EJB?
 
Similar Threads
Question about EB remove
Entity Object Vs Entity bean
new to hibernate
equals method
JPA DISTINCT Clarification