Klaus Meucht

I'm not sure if there is a standardised definition now. I've read many books about UML and there are many difference interpretations about assoziation, aggregation and composition.

In all books the following facts are valid:

1.) Composition is more stronger as aggregation
2.) Aggregation is more stronger as association.

The difference between association and aggregation (with my point of view):

An aggregation defines a whole part relation. There is an association between human and cars. A human can drive a car. But I think this is no aggregation, because a human is no part of the car.

An aggregation could be a racing driver and his team. Michael Schumacher was a member of the ferrari team. The relation between Michael Schumacher and Ferrari could be modeled as aggregation.

The difference between aggregation and composition:

A composition is a stronger aggregation. If you delete the whole - you have to delete the part. I think the relation between Michael Schumacher and Ferrari is no composition. If Ferrari would stop driving races, the drivers could go to another team.

It's much harder to say if the engine and the car is a composition or only an aggregation. I think with normal cars it is a composition. Normally you don't reuse an engine. If you sell a car, you will sell it with its engine.
But I think with racing cars, the relationship between a car and his engine is an aggregation because with racing cars the engine is changed many times.

When I code, I don't think in associations, aggregations and compositions. You can code all kind of the relations with instance variables or you can use a mapping algorithm.

Every compony has another view, how to use uml-diagrams. Some componies use uml-diagrams as a contract with the customer. I don't like it, because I can't expect that the customer can read UML or often he does have a different interpretation as I have.

Some companies thinks that the uml-diagrams must have nearly the same level of detail as the code. They want to generate code from the uml-diagrams. They expect the programmer has only to do some optimisation. So they are independent from the computer language. I don't like this view, because I don't know how to test the correctness of a uml-diagram.

I think the best way to use uml-diagrams is to enforce communication or brain-storming. I like UML-diagrams only on white boards or on sheets of paper, that I use only for some days. If I have to introduce a new employee, it makes sense first to draw the relations of the most important classes and after this to concentrate on the code. I think it's much easier for the new employeer if he sees how I draw and explain the diagram, than to give him a printing. And if I can't explain the relations of the base classes without electronical help, I know that the my model is too complicated (or I'm to stupid for my job). The level of detail is much lower as code. I don't model inner classes. I think that is the decision of the programmer when to use inner classes.

I have no experiance with using a scripting language directly in Java.

If I mix java and groovy, doesn't it produce code that is really hard to detect duplicated code?

Can a code coverage tool like CLOVER, detect the coverage of Groovy code?
Makes it sense to use Groovy only for Test Classes and MockObjects and let the production code in plain java?

If a developer is not familiar in Groovy, how easy is it for him to understand the code?

I'm not really sure what you mean under Software Requirement Specification.

I think requirements must be independent from source code. I think it's the task of the customers (with help of the IT-Consultants) to write the requirements. But even if the IT-Spe******ts write the requirements, they have to write them in a language that customers can understand.

You can use the open source product FIT or Fitnesse (www.fitnesse.org) to write requirements and translate the requirements into java code.

If you mean with SRS a document that explains how to use or extend a framework it makes sense to use Java interfaces.

Hello Bruno Lowagie

Is the book "IText in Action" itself written with iText?

I was at your homepage and I saw the sampleChapter 3 on your book.

On page 95 there is published a little bit of source code (HelloWorldEncryptDecrypt.java). Some lines are marked with black points and numbers in it. There is a vertical line to mark more than one line of the source code.

I like this kind of marking to explain source code. Can I do this with iText?

Hello Mary and Tom

Now you've written 2 books about Lean Software Development.
What are the differences? Can I read the new book, before the older one?

With best regards

Klaus Meucht

Hello Mr. Hohmann

I've just visited your website http://www.innovationgames.com. First I looked at the game product box. I'm not sure a customer would like to take some colored pencils, and draw like a child.

Our customer's are often managers. Not Top-managers, but they earn much more as a programmer. They are used to lead people, and I think many managers have problems to get instructions from people in lower positions.

And I think customers are under great pressure. They must prove that every hour of their work has business value. I'm not sure a customer sees a business value in drawing a product box.

Perhaps in America the people are more open-minded as in Europe. Perhaps my problem is that I'm not open-minded to our customers.

Have you used the innovation games in different countries? What can I do if I see my customer is not open-minded in playing games?

[Fixed URL - Dave]
[ October 31, 2006: Message edited by: David O'Meara ]

I think the word deadline is not used by an Agile Team. Agile Teams don't plan for month's. They try to make the release cycle very short. And every release must have value for the customer.

In traditional software developers, the amount of features to implement for a release is defined, and the team try to implement this features as fast as possible. If the developement team is slower as expected they will deliver the software later.

For Agile teams the iteration cycle of a release is constant. An Agile team will always deliver the software on time. If the developement team is slower as expected, they will implement less features. Agile Teams avoid working for months, without feedback from the customer. It's not like christmas, when the child wrapp off all his presents at one time point. The child get every month a little present. The parents can watch the child, if it really uses the present. If not the parent can learn from it, and buy a better one next month.

The main advantage is that Agile Teams are always open for changes.

Developing software is a learning process. The programmers have to learn about the business domain, the customers have to learn how the technology changes the workflows.

With traditional software engineering process the IT-Team gathers the requirements at the beginnig of the developement process. They are afraid if they miss one requirement, they won't get the best design. Traditional software engineering doesn't consider that learning process. They don't expect that the requirements will change over time.

Agile Teams, know that it is impossible to gather all requirements at the beginning. They try to write their software in such way, that it is always open for changes. They try to benifit from the learning process. They give the customer the chance to intervene in the developement process at every time of the developement process.

Agile teams are not such dependent on individual employee's like traditional teams. They don't seperate people in gathering requirements, design the software and testing. Every programmer is involved in testing (testing is part of programming), and is involved in understanding the business domain. The communication among the members of agile teams, and between the team and customer, is much higher as in traditional teams.

Agile teams hate solutions, that only a few people can understand and maintain - they try always to find the easiest design. The knowledge is not concentrated to only a few key-players. The iteration cycles are very short, a team member shows daily his work to his team. Often they do their work in pairs, and change their pair partner frequently. If one team member has difficulties doing his work, the team realizes it very soon and can help him. Because agile teams works very tightly together, beginners will learn very quick from experience people.

Please excuse my English. It is not easy to learn it.

Hello

Which Features doesn't Extreme Planner use, that conventional planner tools have, because agile project teams don't need this features.

Are there any features that are special for agile projects, that conventional planner tools don't have?

Klaus Meucht

There were 3 until 5 questions I was very surprised, because it was not mentioned in the objectives

* One question was about the right JNDI configuration.
* One question was about ejb-local-ref as subelement of web.xml
* There were mentioned more design-patterns as in the objectives, special
Session Facade
* There was one question, I didn't had any idea what was the meaning of.

The time was realy enough. I've read every question three times, and take sometimes over 5 minutes for realy hard questions. But many questions are
very easy. I've finished in the last minute, but in this time I could review
the questions I marked twice.

The question with EL expressions were hard. There were question on examples,
no normal programmer will use this style.

I had a bad score in the topic "Building JSP Pages Using Standard Actions" (50%). I didn't know why I had so much problems with this topic, because
these questions seemed easy. The problem is that you get only your score from every topic. But you will never see your faults in detail.

For preparing myself to SCWCD 1.4 I wrote a German SCWCD tutoriel.
It can not replace a good book, but I think it could be a help.

You can find this book at:

http://home.arcor.de/klaus.meucht/cocodil/SCWCD/content.htm

Hello

I'm in preparation of the exam,

I think you will need to know:

The following elements are very easy, they are not explicitly mentioned
in the objectives. Perhaps you need it:

description, display-name,icon (with subelements), distributable,

I think following elements are important for the exam: I do not mention
the subelements.

context-param, filter, filter-mapping, servlet, servlet-mapping, listener,
session-config, mime-mapping, welcome-file-list, error-page, jsp-config,
security-constraint, login-config, security-role.

I think you need not to know the following elements:

env-entry, ejb-ref, ejb-local-ref, service-ref, resource-ref, resource-env-ref, message-destination-ref, message-destination,
locale-encoding-mapping-list

Klaus

Concratulations

You are not a looser, you are a winner.

I think there are many people failing the certification, but they will
never post it. It's important to understand the concepts, it's not so important to know the exactly syntax. I know some people failing the SCJP certification at first time, but they are realy good programmers.

I will take the SCWCD 1.4 in 9 days. I will be happy if I have 73%.

Originally posted by Frederic Filiatrault:
Hi there,

Kind of a silent user but thanks to this site, I just passed the exam !
I think also that I`m can be proud to be the one, and only one with the... lowest score : 73%.

What a shame ! Sorry people... with all your 90-100% notes, looks like I'm a kind of a looser !