Lernmaterialien für Analyse et méthode an der Université Libre de Bruxelles

La vue des  est centrale en UML. Chaque vue décrit complètement le système selon son angle d'attaque, et la use case décrit la vue des utilisateurs et des besoins.

C'est une vue centrale car ce sont les besoins qui définissent le programme, le projet. 

Cette vue décrit mieux les besoins fonctionnels que les non-fonctionnels. On exprime des intéractions, pas des contraintes. Les besoin non-fonctionnels sont généralement exprimés hors d'UML, dans des documents classiques.

Au début, on commence avec la frontière entre le système et l'extérieur. On analyse ce qui vient de l'extérieur et ce qu'on y envoie.

 est comme l'agrégation : on a un tout définit par des parties. Sauf que cette fois-ci, la relation est beaucoup plus forte. Si on détruit le tout, on détruit tous les éléments (tandit que dans la flotte, si on détruit la flotte, les bateaux peuvent vivre en dehors). Là, l'objet se repose vraiment sur ses parties. Une partie ne peut pas appartenir à plusieurs touts. On représente ça avec un diamant noir, rempli.

Relation étendues

se base sur le fait que si un bout de code qui en utilise un autre sait que cet autre en utilise un troisième, alors le premier et le troisième sont liés. C'est comme si Client savait que Provider utilise Account, et donc peut faire des assumptions dessus. Client est donc couplé à Account, car il peut faire provider.account().brol(). Le Client voit à travers le Provider.

On évite ça en s'assurant que l'interface publique d'un objet n'expose rien d'interne. La loi de demeter dit qu'on ne peut envoyer un message qu'à soi-même, un objet qu'on crée, ses attributs, les arguments qu'on reçoit ou super. C'est une règle très stricte, on ne peut pas passer « à travers » un objet.

On peut avoir des objets qui s'appellent entre eux, et des chaînes d'actions. Mais il ne faut pas qu'on objet voie toute cette chaîne d'appel. Ainsi, si on fait évoluer un objet, on ne fait évoluer que ce qui change et ce qui l'utilise directement. On ne doit pas remonter dans 10 classes pour trouver toutes les utilisations indirectes.

Pré-condition Condition booléenne qui doit être vraie avant l'appel d'une méthode. 

Post-condition Condition booléenne qui doit être vraie après l'appel d'une méthode. 

Invariant Condition booléenne qui doit être vraie avant et après le traitement. Il peut temporairement être faux durant le traitement. Si un des invariant est faux, c'est qu'il y a une erreur. 

Le test unitaire est un test où on ne teste pas l'application mais ses composants. On va créer un code supplémentaire pour réaliser cela. Contrairement au test unitaire, le test exploratoire est le fait de jouer avec l'application. On utilise l'interface mais on a rien prévu pour tout tester. 

On sépare l'implémentation de la spécification. On décrit le type de données, endisant ce qu'il fait et les opérations possible , et on garde ca séparé de l'implémentation.

Parmi les avanrages il y a la réutilisation et l'assemblage d'éléments en bibliothèque avec la spécification comme documentation.

Quand on écrit un logiciels on l'écrit pas modules et non un gros bloc. les avantages de cette méthodes est que s'il y a un problème la modifications ne va pas trop impacter le reste du programme(modification  sera locales)

Quand on est un bonne architecte on sait séparer et découplé correctement un code. L'orient objet sert a ca, grâce a ses spécificité ( polymorphisme ,héritage). Mais pour cela il faut écrire son programme en acceptant de ne pas toucher au attribut privées des méthodes que l'on vient d'écrire.

Même dan l'ADT on essaye d'être le plus abstrait possible. On essaye de réutiliser les méthodes que l'on a déjà écrite. Un inconvénient est la lenteur mais elle nous dérange pas trop car elle est imperceptible de nos jour et qu'on préfère un code lent et facilement maintenable.

1.On va chez le client pour entendre ses requêtes, ses envies concernant le programme qu'il veut (le risque est l'ambiguïté, le fait que ca peut être incomplet et inexacte)

2. On envoie ensuite les demandes du client a l'analyse-te qui va dresser la liste des besoins concernant le programme voulu. (risque d'avoir mal compris le client et donc d'ajouter des fonctionnalités non voulu au départ)

3.L'architecte va dresser l'architecture du programme a quoi il va ressembler en fonction du besoins, ...

4.Les codeurs vont coder le proramme comme on leur a décrit. il ne peuvent pas anticiper un problème, tout ce voit a la fin lorsque le programme est fini.

Le programme est ensuite assemblé et donner au client . Malheureusement cette méthodes n'est pas optimale si le client  voit que le programme ne correspond pas a sa demande ou qu'il veut y ajouter quelque chose, cela va couiter cher en temp et en argent. Le seul point positif est qu'on a un document très complet quant a la description du logiciel mais s'il y a une modification a faire il faudra trouver la section du changement et reimprimer tout.

Quand on a plusieurs objets, ils peuvent interagir entre eux. On peut passer un objet en paramètre d'une message. 

Il y a une différence entre un message et une méthodes. Une méthodes est le code exécuté par l'objet lorsqu'il reçoit le message.

On ne peut pas toucher au attribut d'un objets sans passer par un message. Seul les méthodes de l'objet peuvent modifier les attributs

Un message est différe d'une appel de fonction. Quand on envoie un message, on dit qur quelle objet ca va intervenir. C'est un paramètre implicite, l'objet précis recoit un message précis. Une fonction peut porter sur n'importe quoi. L'interprétation dépend du message.

On va arriver a une premier définition du polymorphisme : O envoie un même message a 2 objets différent leur réponse peut être different. On a donc un cmportement différent des objets.

On a vu qu'un objet a des données, un état, un comportement. Si on a 1000 objet on aura 1000 copie de ses attribut et de ses méthodes.

c'est pour cela que l'on va introduire le concept de classes. Une classe a une réalité en mémoire, elle comporte du code mais pas de données. Un objet a également une réalité en mémoire elle contient les valeurs des attribut mais pas d codes. Un objet devient donc une instance d'une classe. Une classe est une structure et un objet est une valeur dont le type est une structure.

Quand un objet va recevoir un message elle demandera d'abord a sa calsse quelle méthode convient et s'exécute