Sergej Logis

Greenhorn
+ Follow
since May 29, 2011
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Sergej Logis

I see... I would like them to be optional, that would make diagrams much more clear...
Any other opinions?
Thanks for reply.
However, my question is not about showing methods, but about showing arguments and return types of methods shown.
Adding them makes Sequence Diagram covered with text and Class Diagram to contain huge class boxes...
I have received mine today. Yesterday I have sent them letter with screenshot of bank transaction proving purchase of exam at Prometric. It took only 1 day for me. Try to resend your message.
Hello friends!
I have quite simple question regarding Class and Sequence diagrams. Do we need to specify methods arguments/return types in aforementioned diagrams? I have tried doing so, and diagrams started to looking overcrowded with information. Classes boxes became huge. I wonder, do fine-grained methods arguments/returns types are mandatory, or they can be omitted if method name clearly states what it's intended to? E.g. searchProduct() method, it doesn't really matters which arguments this method takes and what it returns, IMHO...
Also, should we show generic arguments in Class attributes? E.g., I have a class with argument of type Map<Integer, Renderer>. How to correctly specify it in Class diagram?
Thanks a lot!
I'm working on same assignment now
For me, PRODUCT is assembled house. COMPONENT is just one piece you can add to your house design.
I don't really know why we need PRODUCT and HOUSE domain objects with 1-to-1 relation. The only thing
which comes in mind is that we could use PRODUCT to store some house design summary, to be able get
fast view on house design WITHOUT loading entire component structure.
Hey Krzysztof!
I fully agree with you regarding persistency - my current model includes componentCode as THE ONLY persistent field

As for caching, catalog, especially components catalog, is very fluid thing, IMHO. Availability and other details can change
quite often. However, the only time I'm planning to query catalog WS is when customer selects components group to be added to
design for the first time in design session. Afterwards Value List Holder pattern should be applied for sure, to make UI more
responsible and to reduce network traffic. Final check for availability/validity can be done when design is confirmed by customer.
I think this part could (and should) be covered in more details than simple assumption IMHO
Well, IMO, SIMS system is used to query for available/compatible components (as it's name suggests - Stock and Inventory Management System).
SIMS is external system, it knows nothing about your entities. And taking in account that after field representative searches for completed design
and selects one, he/she should be able to evaluate that design - see image, analyze it, make some assumptions and so on. Therefore we simply
must persist design somehow somewhere. And it's definitively not SIMS system...

As to state synchronization with SIMS, only thing we must synchronize is reservation of components. It's quite easy, assuming SIMS provides Web Service for that.

ananthakrishnan ramachandran wrote:Hi,
I am also working on the same assignment.I have a question if we need to show DAOs in class diagram.As per the use case all the interaction happens through web services.Kindly clarify .


I think we should show DAO's on Class Diagram. At very least this would make Class Diagram look more professional and sophisticated, IMHO However, do we really need any DAO
at all? Why not using Container Managed Persistence? We do not have any sophisticated transactional requirements in our assignment, so why using BMP then? What do you think?
As to Web Services, only SIMS system is accessed this way. All design and other stuffs must be persisted locally somehow. So we in need for entities for sure.

P.S. I wonder, does this discussion breaks any SCEA assignment rules? I hope it does not...
Thanks! I will sure take your suggestions in account!
Cade and Sheil book is very controversal, I must admit... If we'd follow guidelines in their book,
then Assignment part of SCEA would take no more than 10 hours to complete, including UML tool
learning curve and HTML design (IMHO)...

Unfortunately for the moment I cannot be proud of having more clear understanding than you guys do...
I sure will post any useful information I will stumble upon!

Krzysztof Grajek wrote:I will just modify the resulting image somhow before including it in my submission. After all we just submit images and not a tool specific project file.


I thought about same approach too

Krzysztof Grajek wrote:2. I guess It would be usefull to show them (same as in Cade's book) at least I will.


The point is, Astah Community UTL tool, I'm using, (suggested here, on JavaRanch SCEA forum),
doesn't have "node" element in Component Diagram elements palette. So, either putting "node"
on Component Diagram is NOT UML 2 compliant, OR I don't know how to do it correctly... Can I
replace "node" with "component" element? Would that be correct use of it to depict external system?
Thanks.
Hi guys!
I just started working on my solution for Part II of SCEA (Factory Homes), and I really need to hurry up to submit
it until August 01, 2011... So I decided to dive into forum and ask questions here, in hope to get more correct and fast
answers (comparing to looking for information elsewhere, e.g. "eating" more books).

1. I have read Cade and Sheil book, and their solution to Part II is quite simple and easy. They claim, however, that it is
WORKING solution. So, if I understood correctly, no need to dive into much details and overdesign? Am I right?

2. Cade and Sheil shows LDAP and Email servers (along with two more external systems) on their Component Diagram
depicted as nodes. I'm using Astah Community to draw UML diagrams, and there is NO such element as node in Component
Diagram. I wonder, should I really mention external systems in my Component Diagram, and if so, which approach to take?
Essentially, those external systems ARE parts of SuD as a whole, so, IMHO, I sould draw them on as common components.
Am I right?

3. In my assignment (Factory Homes) I need to build system using which customers should be able to assemble their
own house. The question is: should I consider things such as graphical drawing tool in my design? E.g., specification says users
can add walls to design, however, no mention about how those walls are assembled together... I'm quite unsure there, and
I really don't want to overdesign my solution... Please guide me into right direction.

I will be VERY thankful for guides and suggestions, guys! Thanks in advance!