Propriétés d’accessibilité des attributs et des méthodes

Cours propriétés d’accessibilité des attributs et des méthodes, tutoriel & guide de travaux pratiques en pdf.

Description statique

Les cas d’utilisation (use cases)

Analyse et représentation des besoins
Analyse des besoins:
Compréhension des besoins à couvrir par le logiciel
Formalisation de ces besoins
Représentation des besoins:
Use cases + scénarii : utilisation du logiciel par les acteurs
Diagrammes de séquences : analyse temporelle des scénarii
Diagrammes de classe/objets : structure du système
Diagramme de collaboration : interactions entre les éléments du système (acteurs et composants)

Cas d’utilisation

Un système est conçu pour des utilisateurs
Use cases
Description des comportements du système vis-àvis de l’utilisateur
Facilitent structuration des besoins
Représentation simple et expressive
Expriment les limites et les objectifs du système
Simplifient les échanges avec le rédacteur du cahier des charges C’est la représentation d’une fonctionnalité, réponse d’une stimulation de l’utilisateur

Définitions

Acteur:
Entité externe qui interagit avec le système Prend des décisions Possède un rôle vis-à-vis du système Il peut être un utilisateur et/ou un autre système
Acteur ≠ Utilisateur
Un utilisateur peut jouer plusieurs rôles Plusieurs utilisateurs peuvent jouer un même rôle Un acteur peut être un autre système
Cas d’utilisation:
Ensemble des actions réalisés par le système en réponse à une action donnée Suite d’interaction entre acteurs et système Correspond à une fonction visible à l’utilisateur Formalisation l’obtention d’un objectif Les cas d’utilisation doivent être mutuellement exclusifs

Relation entre les cas d’utilisation

Ne correspondent pas à des communications entre les cas.
Permettent une structuration des cas d’utilisation
Utilisation d’un autre cas (uses ou include): permet l’extraction d’un comportement commun à plusieurs cas d’utilisations (exemple: donner sont code de carte bleu à un GAB)
L’extension (extends) : extraction de scénarii communs ou optionnels (exemple: retirer de l’argent avec débit différé est une extension de retirer de l’argent)

Les scénarios : liens avec les use cases

Le système correspond à l’ensemble des use cases sans les acteurs
Un use case = un chemin d’exécution possible
Un scénario = un chemin particulier d’exécution une séquence d’événements / instructions. instance des cas d’utilisation
Les scénarii
Il s’agit en général d’un descriptif sous forme de texte des actions à effectuer pour un cas d’utilisation donné Il peut être décomposé en plusieurs
sous scénarii:
L’un correspondant au scénario optimal Les autres correspondants aux alternatifs (tests d’erreurs, mauvais renseignements, …)
Diagramme de classes
Une classe est une description abstraite permettant de définir des objets ayant:
Des propriétés,
Des comportements,
Des relations,
Des sémantiques…
…Communes

Propriétés d’accessibilité des attributs et des méthodes

On retrouve les trois niveaux de protections classiques:
Privé (-)
Protégé (#)
Publique (+)
Les attributs dérivés
Un attribut dérivé permet d’indiquer clairement qu’un attribut découle d’autres propriétés (exemple: la surface d’un rectangle dépend de sa largeur et de sa longueur)
Il sont noté /nom attribut et ont des valeurs calculées à partir des autres attributs
Relation entre les classes
Association
Agrégation
Composition
Spécialisation
Les associations
Représente une association structurelle entre 2 classes.
Ces associations peuvent être nommées.
Elles peuvent également posséder des cardinalités.
Toute association binaire possède 2 rôles.
Un rôle définit la manière dont une classe intervient dans une relation.
Le nommage des associations et celui des rôles ne sont pas mutuellement exclusifs
L’intérêt des rôles réside dans le cas où plusieurs associations lient deux classes.
Attention: Lorsqu’il y a trop d’associations entre deux classes c’est suspect…

Cardinalité et multiplicité des associations

La cardinalité est une information qui quantifie le nombre nécessaire de fois pour la participation d’un objet à une instance.

Les contraintes sur les associations

Contraintes qui portent sur une relation ou un groupe de relation (en général mise entre accolades {})
Contraintes de sous ensemble:
Collection incluse dans une autre collection
Une association parmi un groupe d’associations est possible
Agrégation
Une agrégation est une relation non symétrique.
Cette relation est à mettre en rapport avec la notion d’agrégation que nous avons vu en C++
Cas d’utilisation :
Une classe B « fait partie » d’une classe A
Les valeurs d’attributs de la classe B se propagent dans A
Une action sur A implique une action sur B
Les objets de B sont subordonnés aux objets de A
Il suffit que l’un de ces critère soit vérifié.
Composition
C’est un cas particulier d’agrégation Peut être modélisée au moyen d’attributs.
Le composant est physiquement présent dans l’agrégat Implique une contrainte sur la valeur de cardinalité coté agrégat (0 ou 1) 0 implique un attribut non renseigné La composition doit être retenue lorsqu’un attribut participe à la relation.
Introduction – Historique – Grands Principes
Analyse, Conception et Ingénierie
Diagrammes Structurels (vue statique)
Diagrammes Comportementaux (vue
dynamique)
Conclusion