Hassan Mumtaz

Greenhorn
+ Follow
since Jul 04, 2001
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 Hassan Mumtaz

Dear all,
Has anyone used Together Control Center from TogetherSoft? It seems awesome.... Please check out the demos at the end of the webpage.
Hassan
Dear Safrole,
Congrats! Yes, it is a relief getting it off the back!
Best of luck for the future.
Hassan
Dear Qudsia,
Congratulations!
You have identified a very good point. My monitor was also small which caused me a lot of irritation and inconvenience. I had to switch between the question to one exhibit to the next then back ... However, during the exam I tried my best to not get bugged and let this affect my mental state... However, like you said we cannot find out if we had done better with a bigger monitor unless we retake the exam
Congrats again
Hassan
p.s. Are you now preparing for IBM 483?
No Sandeep, IBM believes the answer to product catalog brittle coupling question is B not C. Chris has marked B as the answer and he gets 4/4 on design & implementation techniques. Yes?
Regarding the Specification perspective question, I'm glad we agree on A and C. The thing is that B in its own right does not make sense, since while making a conceptual model, the motivation is NOT to identify domain classes but rather to get an understanding of the domain. Yes, later on in the design phase, some of those CONCEPTS will become classes. Don't mind me repeating this, especially if you had already figured this out.
Hassan
In the post "Which two are wrong?" (http://www.javaranch.com/ubb/Forum9/HTML/000445.html), the discussion ended with the fact that the answer to product catalog brittle coupling question was B as marked by Chris. This is confirmed Chris's score breakdown (given below) which shows 4/4 on design and implementation techniques.
Designs & Implementation Techniques 4 4 100.0
Requirements Modeling 5 5 100.0
Static Modeling 7 6 85.0
Development Process 4 4 100.0
Dynamic Modeling 6 6 100.0
Architecture 4 3 75.0
Given that one of the incorrect answers is to the the 2 vs 3 tier architecture question, then which is the other question that has an incorrect answer?
Since, besides Architecture the other category in which Chris got one wrong is Static Modelling, could it be that it is the specification perspective question under debate that has the wrong answer? After looking at the other questions, I believe that is the case and that the correct answers are A and C.
Do you agree? Sandeep, Junilu, Safrole?
Hassan

The subject "Just cleared the ... " plays a pun on the word "just". Yes, by some incredible stoke of luck, I narrowly escaped. I just cleared the exam an hour ago with 69% (passing score = 69%). It is not possible to describe the emotions when I saw this first. If you consider, it is an incredibly difficult achievement... to pass with a score nearest to the passing score... So, I've bettered Sandeep's performance by 4 percent!!! I don't think anyone can beat my record.. only equal it .
At the end of the day a pass is a pass... I am not sure if I could have absorbed the two books further. I think what may be critical is that I have no REAL OO development experience and switched to software only a few months ago.
Anyway, I feel relieved.
Hassan
Dear Elizabeth,
I may be off, but have you considered the Command Pattern?
Hassan
Dear Junilu,
I still maintain that A and C are correct. The key to understanding this issue is that the specification perspective (software OO interfaces) is separate from the implementation perspective (programming language). So as we move from analysis to design to implementation, we have:
1. Conceptual pespective: Domain concepts
2. Specification perspective: OO software interfaces
3. Implementation perpective: Programming language
Hassan
Dear Qudsia,
I agree that c) is correct but I disagree on b). I think a) is correct rather than b). Specification perspective is from an OO interface view (and therefore prog. lang. independent) while implementation perspective is taken considering a prog. lang. and even code generation. See chapter 4 of UML Distilled (Fowler).
The problem with b) is that the conceptual perspective
does not identify domain classes. Rather it is software independent and only identifies domain "concepts", not all of which will map onto domain classes during implementation.
Hassan
I think UML assets are "models". At the risk of sounding like a methodologist, I would say that they are "artifacts" (work products) and "documents" is not appropriate terminology. However, this is no oppoptunity to fight or argue as natural languages are imprecise anyway.
Q: What's the difference between a methodologist and a terrorist?
A: You can negotiate with a terrorist!
The relevant patterns for your problem are:
1. Model-View Separation (aka Model-View Controller) (Bushman et al.)
2. Observer (Gamma et al.)
For a good discussion see Chapter 22 of Larman (Applying UML and Pattern) or check http://www.cetus-links.org/oo_patterns.html
Hassan
Which is the correct answer and why?

When using OOAD artifacts to organize and assign team responsibilities on a project, it is BEST to:

a) evenly distribute use cases among team members and have them work as independently as possible in order to minimize code dependencies

b) designate one team for implementing interaction diagrams related to the "common code path" and another team for implementing interaction diagrams related to "code path variations" (for example ? conditional or error paths)

c) divide teams according to package diagram dependencies and utilize use cases to schedule the work for the individual team members

d) divide teams according to the layers in the software architecture and have them work as independently as possible in order to minimize dependencies between the layers

Hassan
In the following question which two are correct?
Which of the following are true about interpreting class diagrams from different perspectives?
a) Specification perspective class diagrams are developed without considering the programming language that might be used to implement it.
b) The conceptual perspective class diagram of an application would not include all the classes required and their details, rather, they would only identify domain classes.
c) In the conceptual perspective, associations represent relationships between classes, where as they represent responsibilities in the specification perspective.
d) Operations (the processes that a class knows to carry out) should be used in conceptual models to specify the interface of a class.

I know c) is correct, but I am confused between a) and b).
Isn't the specification perspective language independent, only concentrating on OO interfaces?
Hassan
Dear all,
I have been reading but not participating in this forum. Thank you all who have helped share their views/experiences on the Test. I will be taking the test on Saturday and have read the two books many times. I will share my (hopefully positive) experience then.
I have one last question: What is the split between theory (without figures) and application (with figures) questions?
Hassan
Dear All,
I have enclosed a real email in which a Project Manager describes a methodology for an information system project. Since I am planning to be associated with this company, I really care about it but I am a little confused. I have been doing a lot of research/reading on OOA&D and methodology (RUP, XP), and although I do not possess much *experience* in this cutting edge stuff, I feel I have a good grasp on the basic principles (I switched to software development 6 months ago). Please read the following excerpt and give your comments or ask any questions, especially with regard to the following:
1. Is this OOAD? If not, why is OOAD better than Structured D.?
2. Is this use-case driven development?
3. Is this Iterative development?
4. How does this fit into the philosopy of RUP and XP?
5. Anything else?
Hassan
***********************************************************

It was agreed that with the "Generic Specifications document"
provided by *someone* there is no need for detailed info about the UI screens any more. So we will work on Ph-2 and as and when we need any clarification - we will seek it from the on-site team.
As for the methodology for Ph-2 to Ph-5, instead of 'completing' each screen of the six screens in a series, here is what we have been doing so far;
1. You are aware that the generalized architecture for the back end divide each of the back end functions into 5 components - descriptor, model, manager, controller and view, we will call it a 'set' in this e-mail.
2. For each component in the 'set', *someone* has designed a template (similar to the one sent to you for UI components)
3. Each screen has it's unique functional requirements and thus each screen has different numbers of descriptors, models, views, managers and one controller. *someone* has prepared a list of the required components for all the six screens in Ph-2. A total of 74 components are identified for the back end functions of Ph-2 screens.
4. For each item in the list, relevant template is filled by
*someone* and handed over to a programmer (a part of the team called the code factory), he is instructed on how to use the template to generate the code for that component - this makes the code generation an almost mechanical process requiring minimal thinking or guessing on part of the programmer.
5. Once a 'set' is complete for a specific function of a screen -
integrators take over and integrate and test the back end for that function.
6. In the meantime - as more templates are filled by the technical leads, programmers continue to generate more components.
Working in the same manner (whenever possible) we will build
components for the front end thru our code factory and finally integrate the back end and front end to complete the screens.
We see several advantages of working in this manner, major one being that all the available resources are utilized efficiently in parallel (experienced people doing important work such as *someone* designing the templates, technical leads filling the templates, checking the code and integrating the components while relatively inexperienced programmers 'the
code factory' doing the bulk of the coding). As we progress into this project, the code factory will become more productive and reliable requiring little or no guidance and minimal rework. We also hope to groom a few more integrators from the team and thus will be able to generate more work for the code factory and check the code produced by them improving overall
efficiency of the team. In parallel, we are also exploring the
possibilities of writing 'code generating / checking' programs from these templates.