Glossaire

Le but du glossaire est de vous présenter les notions importantes qui sont utilisées durant la formation. Si vous repérez des notions qui sont importantes, mais qui ne sont pas présentes dans ce glossaire, n’hésitez pas à le signaler à la personne tutrice. Tout le contenu du document est extrait des textes utilisés dans le cours.

Acteur : c’est une entité qui a un comportement, comme une personne, un système ou une entreprise. Les acteurs se retrouvent sur le diagramme de cas d’utilisation.

Analyse : c’est une des disciplines préconisées par le processus unifié qui précède la conception. L’objectif de cette étape est d’expliciter les besoins du client et de définir le domaine concerné par le système. Elle met l’accent sur le « quoi ».

Agrégation : c’est un type d’association entre classes utilisée pour modéliser des relations de tout à partie entre différentes entités. Le « tout » est appelé composite.

Artefact : c’est le terme générique qui désigne n’importe quel produit du travail : code, graphiques Web, schémas de base de données, documents texte, diagrammes, modèles, etc.

Association : c’est une relation entre des classes (ou plus précisément des instances de classes) qui indique une connexion significative ou intéressante.

Attribut : c’est la valeur d’une donnée logique d’un objet. C’est aussi la propriété d’une classe.

Cas d’utilisation : c’est une collection de scénarios de réussite et d’échec qui décrivent la façon dont un acteur utilise un système pour atteindre un but.

Classe : terme UML générique représentant, soit une entité du monde réel (classe conceptuelle), soit une entité logicielle (classe logicielle).

Classe conceptuelle : c’est une idée, une chose ou un objet. Plus formellement, une classe conceptuelle est composée d’un symbole, d’une intension et d’une extension. Le modèle du domaine contient des classes conceptuelles.

Classe logicielle (ou classe de conception) : c’est une classe représentant un composant logiciel du point de vue de la conception ou de l’implémentation, indépendamment du processus ou de la méthode.

Conception : c’est l’une des disciplines préconisées par le processus unifié qui fait suite à l’analyse et qui précède l’implémentation. La conception est centrée sur la définition des objets logiciels et sur la façon dont ils collaborent pour satisfaire les besoins.

Design pattern : c’est un couple problème/solution nommé, que l’on peut appliquer à de nouveaux contextes de conception. Il est accompagné de conseils sur la façon de l’appliquer et d’une présentation de ses avantages et de ses inconvénients. Dans ce cours, vous utiliserez quelques patterns pour affecter efficacement les responsabilités aux différents objets.

Diagramme de cas d’utilisation : c’est un artefact qui représente de manière synthétique l’ensemble des cas d’utilisation définis et des acteurs identifiés. Apparaissent aussi les relations entre cas et acteurs.

Diagramme de classes de conception : créé en parallèle avec les diagrammes d’interaction, c’est un artefact qui représente les spécifications des classes logicielles. Il contient en général les indications suivantes : classes, associations, attributs, méthodes, indication du type de l’attribut, navigabilité et dépendances. Contrairement au modèle du domaine, ce diagramme ne représente pas des concepts du monde réel. Le modèle du domaine contient des classes conceptuelles alors que ce modèle contient des classes logicielles ou classes de conception.

Diagramme de collaboration : c’est un artefact qui illustre les interactions entre objets sous forme de graphes et de réseaux. Il permet de représenter des branchements complexes, des itérations et des comportements concurrents.

Diagramme d’interaction : cette expression englobe deux types de diagrammes UML spécialisés, qui peuvent servir les deux à exprimer des interactions de messages : les diagrammes de collaboration et les diagrammes de séquence.

Diagramme de séquence : c’est un artefact qui représente les interactions dans un format où chaque nouvel objet est ajouté à droite. Il indique clairement la séquence et l’ordonnancement des messages.

Diagramme de séquence système : c’est un artefact facile à créer et qui illustre les événements d’entrées/sorties liés aux systèmes considérés. C’est une image qui montre, pour des scénarios de cas d’utilisation précis, les événements générés par les acteurs externes, leur ordre et les événements intersystèmes.

Discipline : appelé à l’origine workflow, c’est un ensemble d’activités qui ont trait à un domaine précis, comme l’analyse ou la conception. Le processus unifié comprend un ensemble de disciplines. Le cours se concentre sur deux disciplines, l’analyse, la conception et aborde quelque peu une troisième discipline, l’implémentation.

Extension : ensemble des objets auxquels un concept s’applique. Les objets de l’extension sont des exemplaires ou des instances du concept.

Glossaire : au cours de l’étape d’analyse, le modèle de cas d’utilisation et le modèle du domaine sont accompagnés d’un glossaire des termes utilisés pour parler de et modéliser le système à réaliser.

Héritage : c’est un type d’association entre classes qui permet d’organiser les classes en superclasses et sous-classes. Ce mécanisme permet aussi de créer de nouveaux types en spécialisant des types (ou classes) existants.

Implémentation : c’est l’une des disciplines préconisées par le processus unifié. Elle fait suite à une phase de conception et sert de base au départ d’une nouvelle itération.
Instance : membre individuel d’une classe. Objet en UML.

Itération : terme propre au processus unifié qui désigne un miniprojet court de durée fixe.

Modèle de cas d’utilisation : c’est un ensemble d’artefacts préconisé par le processus unifié pour la discipline analyse des besoins (requirement). Dans le cadre de ce cours, le modèle de cas d’utilisation comprendra le glossaire, le diagramme de cas d’utilisation et les scénarios de chaque cas.

Modèle du domaine (ou diagramme de classes conceptuelles) : c’est une représentation des classes conceptuelles du monde réel. Ce n’est pas un ensemble de diagrammes décrivant les classes logicielles ou des objets logiciels ayant des responsabilités.

Objet : c’est une instance de classe. Les termes instance et objet sont régulièrement considérés comme synonymes.

Processus unifié : c’est un processus de développement pour la construction de systèmes orientés objet. Il rassemble en une description cohérente et bien documentée les meilleures pratiques communément acceptées. Le principe de base est qu’il est constitué d’itérations.

Responsabilité : c’est un contrat ou une obligation d’une classe. Les responsabilités sont liées aux obligations d’un objet en ce qui concerne son comportement.

Scénario : c’est une suite spécifique d’actions et d’interactions entre les acteurs et le système.

Visibilité : la visibilité d’un objet est l’aptitude d’un objet à voir un autre objet ou à avoir une référence à un autre objet. Il y a quatre types de visibilité : visibilité d’attribut, visibilité de paramètre, visibilité locale et visibilité globale.