PRFC (Pascal Roques Formation & Conseil)

Félicitations! Je viens justement de me repencher sur une ancienne édition (vraiment!). J'espère que cette nouvelle mouture corrigera quelques points qui ne me plaisaient pas trop dans la mienne. Un passage à la FNAC s'impose... (oui, c'est un des rares bouquins d'info qu'ils ont généralement encore... planqué entre le Vidal et un petit Spirou)

Merci de tes encouragements ! J'en profite pour inviter mes lecteurs à ne pas hésiter à me faire part de leurs critiques : c'est comme ça que les versions s'améliorent !

Pascal

Salut Pascal,

I have just finished reading your UML par la pratique and found it excellent. I am not a big fan at all of UML and UML books, but I found your styile and case studies clear and pleasant to read. I also won your other book UML en Action, we will see if it is also as good ! ;)
I think it would be great though if one could download the diagram used in the book, and also if one could get a pdf copy of the text. It is a handy text to have as a reference, but sure enough I don't wanna bring around the hardcopy wherever I go...
If you think you could help, at least with the pdf ebook, well email me and I will appreciate it a lot!
Keep on with the good work!
Riccardo

Hello,

Thanks for your kind comments.
Regarding the pdf version of my books, my editor (Eyrolles) has all the rights, so I can't send it to anybody. In fact, I don't even have the .pdf version myself!

Bonjour, je voulais savoir si il s'agissait d'une erreur ou pas: page 37, en bas du diag d'activité, l'état ne devrait il pas plutôt déboucher sur l'état plutôt que sur la ? Merci, Pierre.

Ré-écriture du commentaire sans les balises qui ont fait disparaître les noms des états dont je voulais parler !

Bonjour, je voulais savoir si il s'agissait d'une erreur ou pas: page 37, en bas du diag d'activité, l'état Impression des tickets ne devrait il pas plutôt déboucher sur l'état Ejection des billets plutôt que sur la Fin normale (via le join) ? Merci, Pierre.

Il s'agit d'abord d'un exemple d'utilisation du Fork pour exprimer le fait que l'éjection des billets et l'impression du ticket se font en parallèle. Ensuite le Join permet de s'assurer que la fin normale n'arrive que si les billets ont été récupérés et le ticket imprimé. On aurait pu le modéliser autrement, mais c'était surtout pour mettre un exemple simple de Fork et de Join sur le diagramme...

Pascal

Bonjour,

UML 2.0 par la pratique, page 102:

Répartition entre VolGénérique et vol, le qualificatif NUMERO accolé à la classe CompagnieAeriennene ne devrait il pas plutôt être placé sur la liaison "propose" liée à la classe "Vol", plutôt que sur la liaison "définit" liée à VolGénérique ?

Merci,

Pierre.

Suite question posée juste avant:

j'ai posé cette question car j'ai supposé que les numéros de vols concernaient un vol bien précis (réel) et non un type de vol (comme la navette toulouse-paris du lundi matin dont vous parlez juste avant la page 102, et qui justement nous fait aboutir à l'idée du patern de metaclasse).

Si cette supposition est erronée, alors ma question n'a pas de raison d'être.

;)

Pierre.

Tu as répondu toi-même à la question : les numéros de vol concernent bien les vols "génériques" !

Mais continue à poser de telles questions, tu finiras bien par trouver une erreur !

Merci

Pascal

ben en fait de vraies grosses erreurs non ;)

juste des erreurs d'édition par ci par là...

comme p.103 tous les accents ont disparu dans la figure 3-34

ou encore la phrase répétées deux fois de suite, en bas de la p.111 et au début de la p.112

bref, rien de méchant qui n'entrave la compréhension du bouquin ;)

Pierre.

Exact

Pascal

Salut,

C'est encore moi ;)

j'aurais voulu vous soumettre une idée, p.123, figure 4-10, ne pourrait on pas envisager la solution suivante:

classe PersonnePhysique (nom, prenom, sexe)
association "est uni avec" 0..1 0..1

classe d'association Union (date, lieu) spécialisée en deux classes associations enfants Mariage (contrat) et PACS(), avec contrainte {p.pacsee != p} sur la classe d'association PACS, et la containte {p.sexe != p.pacsee.sexe} sur la classe Mariage.

Il me semble que le schéma final est ainsi plus simple, en effet, plus besoin de mettre la contrainte {xor}, et plus besoin de définir les classe Homme et Femme.

Mais est il réalisable dans selon les règle d'UML 2.0 ? notamment comment positionner les deux contraintes associées aux deux classes d'association enfant que sont PACS et Mariage ?

Merci.

Pierre.

oups, j'oubliais, l'association "est uni avec" 0..1 0..1 est positionnée comme sur la figure 4.10, et est reliée par les tirets à la classe d'association Union.

C'est tout à fait correct. Je l'ajouterai à la prochaine édition !
Je préfère cependant garder les classes Homme et Femme pour décrire le mariage, mais ta proposition est intéressante et constitue une solution alternative.

Pascal

bon ben là pour le coup, oui, y'a une petite erreur ;)

p.125, figure 4-13, c'est la classe capitale et non ville, vu que ce n'est que juste après, figure 4-14, que l'on ajoute le concept de ville, et donc la classe ville.

Je pense que ce petit point peut avoir légèrement embourbé les moins initiés.

Je précise que je ne suis pas là pour démonter le livre, par ailleurs très bien fait, mais juste pour apporter diverses petites remarques correctrices quand je tombe dessus.

J'ai une formation POO à la base (3° année iut de blagnac en 97 !), ça fait longtemps que je n'ai plus trop fait de POO, et là je me sers de votre livre car j'ai la charge de la conception UML complète d'une application.

Cordialement,

Pierre.

Tu as encore raison !
Merci
Pascal

Salut,

encore une question !

page 76, vous écrivez:
"Comprendre la différence entre modèles d'analyse et de conception"

Mais je n'arrive pas à trouver à quel endroit de ce chapitre (déjà entièrement lu évidemment) ce point précis est étudié ?

Merci,

Pierre.

Dans les deux encarts p. 86 et 97.

Pascal

Encore moi ! :)

Bon, cette fois, c'est page 171, je suis surpris, car juste avant, fin de la page 169 (et représentation graphique page 170) tu dis (je pense qu'on peut se tutoyer entre informaticiens-umlistes ? ;) ), qu'il vaut mieux schématiser "introPièce(p) / incrémenterCrédit(p)" puis, sur l'autre évènement "when(crédit>=2)", c'est à dire spérer l'action du test.

Et arrivé page 171, au niveau de l'état "communication", tu fais ce qu'il ne faut à priori pas faire (dixit pages 169/170) : tu mets "UT [crédit suffisant] /taxer" dans le 1er evenement, puis "UT [crédit insuffisant] / taxer" dans le deuxième... !

Il faudrait plutôt, si l'on s'en tient à la règle dictée pages 169/170, mettre "UT /taxer" au 1er évenement, puis "when(crédit insuffisant)" au deuxième, non ? On sépare l'action et le test !

J'attends ta réponse qui m'éclairera sur ce petit point.

Cordialement,

Pierre.

Oui, bien sûr, on peut se tutoyer ! :-)

La règle donnée page 169 concerne la séparation du test de la valeur d'une donnée dans une condition alors que cette donnée est modifiée dans l'effet de la même transition. C'est le cas pour l'exemple ou l'événement intropiece(p) modifie le crédit du publiphone.
Par contre, p. 171, ce n'est pas exactement le même cas : l'événement UT déclenche juste le fait qu'une pièce va tomber et qu'il faut prévoir lors de la dernière pièce de changer d'état.

Pascal