Discussion :

[hegros]

Bonjour,

Avez-vous des liens vers des tutoriaux (plûtot débutant les bases ?) sur la conception de composant logiciel (spécification, contrat,symbolisme,propriété,environnement...) ?

Ou articles/littératures qui reprend si possible depuis le début.


Petite question à part : Peut-on concevoir un composant logiciel en utilisant une autre méthode normalisée que UML ? Si oui laquelle ( Tutoriaux,articles,cours... ) ?

Dernière question et je pars, pouvez-vous me donner un exemple/modéle que vous utilisez pour la conception de vos composants ?


En fait je recherche un document type pour décrire mon composant.

Voila voilou
Merci pour vos réponses.

[ego]

Avez-vous des liens vers des tutoriaux (plûtot débutant les bases ?) sur la conception de composant logiciel (spécification, contrat,symbolisme,propriété,environnement...) ?

Tu peux regarder la documentation de Spring, cela te donnera les bases. Il y a aussi les bouquins écrits par Rod Jonhson le créateur de Spring et aussi les bouquins écrits par Pascal Roques.

Petite question à part : Peut-on concevoir un composant logiciel en utilisant une autre méthode normalisée que UML ? Si oui laquelle ( Tutoriaux,articles,cours... ) ?

Ben oui car beaucoup de gens n'utilisent pas le formalisme UML encore aujourd'hui.
Petit point : UML n'est pas une méthode.

Dernière question et je pars, pouvez-vous me donner un exemple/modéle que vous utilisez pour la conception de vos composants ?

Je n'en connais pas. La "seule" chose que tu peux écrire avant de faire un dessin UML ou autre interface Java/C# (sachant que le dessin UML peux accompagner ton doc écrit), c'est définir le contrat (entrée/sorties/invariants/algorithme) de ton composant, ses responsabilités et les exigences qu'il doit remplir (fonctionnelles et non fonctionnelles). Tu peux regarder sinon du côté des "Design patterns".

[Hephaistos007]

Avez-vous des liens vers des tutoriaux (plûtot débutant les bases ?) sur la conception de composant logiciel (spécification, contrat,symbolisme,propriété,environnement...) ?

Salut,

Il y a plusieurs définition de la notion de composant logiciel. Quelle est la tienne ? A partir de là je pourrai peut-etre te répondre.

[hegros]

@ego : Merci
1- je tacherais de trouver la documentation de Spring et de ce qui tourne autour.

2-D'accord, en fait j'attendais plus qu'on me cite le formalisme le plus adapté. Je suppose que SADT peut faire l'affaire aussi ?

3- C'est ce point que je cherche à détailler. Cette notion de contrat,responsabilité et d'exigence. Je recherche un modéle de document me permettant de décrire tout ces éléments.


@ Hephaistos007 :

La définition que j'utilise est : Un composant logiciel est un module qui rend un service. Il peut exister des couplages (fort ou faible),des interactions entre ces dits module.
Il y a aussi une notion de cohésion (fonctionnelle,logique,temporelle...)

J'espére que ca répond à ton interrogation, j'espére lire tes définitions car je reste un peu sur ma faim la

[Hephaistos007]

J'avais fais un message très complet pour te répondre Hegros mais la soumission de mon message a deconné (merci le forum ! ). Donc, comme j'ai la flemme de tout rettaper, voici la maxi-synthèse :

Utilisation des ADLs (Architecture Description Langage) :
- Semi-formel: UML 2.0 grâce à son diagramme de composants
- Formel : Wright, CSP, ACME, ... (utilisation de logique temporelle et/ou logique du premier ordre)

Solution clé en main: ArchJava (Sun), mélange d'un ADL et du langage objet Java.

[hegros]

Super ca va exactement dans le sens que je recherchais.Pas encore tout regardé mais ca va venir.

Merci Hephaistos007

Avec toutes ces informations que vous venez de me transmettre il y a de quoi avancer.

Petite question :

Est-ce que le schéma suivant est valide pour une approche "orienté composant" ?

1-Identification des sous-système constituant le logiciel.
2-Décomposition de ces sous-système en composant ( Peut-on parler de de décomposition formelle ou informelle ?)
3-Décrire les interfaces,interaction,propriété,contrat etc de chaque composant.
4-?
5-?

Beaucoup de questions me viennent encore à l'esprit. Encore merci pour vos réponses de qualité.

[Hephaistos007]

Merci Hephaistos007

Avec toutes ces informations que vous venez de me transmettre il y a de quoi avancer.

De rien. Par ailleurs, saches que tu va peut-être te sentir seul lors de cet apprentissage (je parle par expérience). La programmation orienté composant est traitée dans la communauté de recherche mais n'est pas encore vulgarisée (car pas encore mature selon moi). Alors, maintenant que tu connais le terme "ADL", tu vas rapidement tomber sur des publications de recherches, rarement destinés aux néophytes.

Petite question :

Est-ce que le schéma suivant est valide pour une approche "orienté composant" ?

1-Identification des sous-système constituant le logiciel.
2-Décomposition de ces sous-système en composant ( Peut-on parler de de décomposition formelle ou informelle ?)
3-Décrire les interfaces,interaction,propriété,contrat etc de chaque composant.
4-?
5-?

*Je suis ok pour les phases 1 et 2. (je n'ai jamais entendu parlé de décomposition formelle/informelle, qu'est-ce ?)
*Ensuite tu passes effectivement à la description des composants et de leur interractions (d'où l'utilité des langages de description d'architectures)
* Ensuite il y a le déploiement : où est-ce que je mets mes composants ? celui-là sur telle machine, celui-ci sur celle là, ...

En vérité le cycle de developpement exacte est :

1. Expression des besoins
2. Analyse (tes phases 1 & 2)
3. Description (ta phase 3)
4. Implementation : association du composant à une unité d'implémentation
5. Tests
6. Deploiement
7. Maintenance (eh oui, comme toujours !)

Si tu as d'autres questions, n'hésites pas.

[ego]

je suis peut être néophyte en la matière ou bien trop vieux pour connaitre les "nouveaux" sujets de recherche mais l'approche composant ne date pas d'hier. Une méthode comme le RUP en parle et explique comment modéliser tout cela. Avec l'arrivée d'UML 2.0 c'est en plus plus facile d'exprimer ce que l'on veut.
Le vrai problème dans tout cela, comme d'habitude il ne faut pas attendre de miracle, c'est : "Quel composant créer ?", "Comment savoir si on a fait le 'bon' choix ?"
Là, mon expérience me dit qu'il n'y pas de recette miracle mais des principes simples et connus souvent de tous mais diificiles à mettre "correctement" en oeuvre = forte cohesion, faible dépendance (cf. design pattern - principes cité par de Craig Larman)

[Hephaistos007]

je suis peut être néophyte en la matière ou bien trop vieux pour connaitre les "nouveaux" sujets de recherche mais l'approche composant ne date pas d'hier.

Effectivement ca date de 1970. En 2006, c'est toujours un sujet de recherche à part entière.

Le vrai problème dans tout cela, comme d'habitude il ne faut pas attendre de miracle, c'est : "Quel composant créer ?", "Comment savoir si on a fait le 'bon' choix ?"

Non, effectivement il n'y a pas de solution miracle. Ce n'est d'ailleurs pas la question d'Hegros. A noter tout de même que l'on peut probablement trouver des "bests practices" dans certains domaines métier.

[wahiba.m]

je fais mes debuts dans la recherche, et je travaille sur la réutilisation des composants logiciels et c'est effectivement un thème de recherche en plein essor...en ce qui concerne le modèle de composant que tu peux utiliser! il ya EJB CCM et dotnet