Prérequis sur les généralités sur la modélisation et l’expression des besoins

(1)

Prérequis sur les généralités sur la modélisation et l’expression des

besoins

Denis Conan

CSC4102

(2)

Prérequis : modélisation et expression des besoins

Table des matières

Prérequis sur les généralités sur la modélisation et l’expression des besoins Denis Conan, , Télécom SudParis, CSC4102

Janvier 2022 1

Grille d’auto-évaluation des prérequis 3

Déﬁnition des niveaux de compétences des connaissances et des savoir-faire . . . 3

Grille d’auto-évaluation . . . 4

1 Généralités sur la modélisation orientée objet et sur UML 5 1.1 Principes de la modélisation . . . 6

1.2 Pourquoi et comment modéliser en orienté objet . . . 7

1.3Uniﬁed Modelling Language (UML) . . . 8

1.3.1 UML, un langage . . . 9

2 Expression des besoins 9 2.1 Rôle de l’expression des besoins . . . 11

2.2 Exemple de cahier des charges :Médiathèque . . . 12

2.3 Règles de gestion de l’application . . . 14

(3)

Grille d’auto-évaluation des prérequis

Avant certaines séances, comme ici avant la séance 2, nous vous demandons d’auto-évaluer vos acquis provenant de modules antérieurs. Dans cette section, nous commençons par déﬁnir les niveaux de compétences des connaissances et des savoir-faire. Puis, nous présentons la grille pour les prérequis de la séance à venir.

Déﬁnition des niveaux de compétences des connaissances et des savoir-faire

Une grille d’évaluation se présente sous la forme d’un tableau ayant en ligne les notions / concepts et en colonne les niveaux d’acquisition estimés : gradués en 5 niveaux au dessus de 0.

Pour information, les niveaux correspondent en partie aux niveaux de la taxonomie de Bloom, qui concerne uniquement le domaine cognitif et qui comporte six niveaux. Nous préférons pour des raisons de faciliter l’utilisation de cinq niveaux, les niveaux 5 (synthèse) et 6 (évaluation) étant ici fusionnés. Par ailleurs, nous ajoutons le domaine psychomoteur, qui concerne les savoir-faire. Enﬁn, pour rester raisonnable, ces niveaux étant utilisés dans de nombreuses grilles d’évaluations, nous fusionnons les niveaux des deux domaines dans une seule échelle.

Comme visualisé dans la ﬁgure qui suit, le niveau « 0 » indique que vous n’avez pas de connaissance sur la notion. Le niveau « 1 » indique, dans le domaine du savoir, que vous êtes capable de déﬁnir le concept et d’énumérer les caractéristiques ou propriétés du concept, et dans le domaine du savoir-faire, que vous êtes capable d’observer le concept pour décrire un logiciel existant. Le niveau « 2 » indique, dans le domaine du savoir, que vous êtes capable d’expliquer et d’interpréter l’utilisation du concept dans un logiciel existant.

Le niveau « 3 » indique, dans les domaines du savoir et du savoir-faire, que vous êtes capable de l’utiliser pour construire un nouveau logiciel. Le niveau « 4 » indique, dans le domaine du savoir, que vous êtes capable de choisir le concept (sous-entendu plutôt qu’un autre concept, qui peut être similaire) et d’analyser son utilisation. Enﬁn, le niveau « 5 » indique, dans les domaines du savoir et du savoir-faire, que vous êtes capable de défendre ou critiquer l’utilisation du concept dans un logiciel existant ou pour construire sa solution. Dans la grille d’auto-évaluation d’un prérequis, nous indiquons le niveau d’acquisition minimum requis pour chacune des notions de manière visuelle en « grisant » les niveaux au-delà de ce qui est requis.

1 2

interpréter expliquer,

0

pas de connaissance

3 4

analyser distinguer,

le choix, faire

défendre, 5

critiquer appliquer

résoudre, utiliser, pour décrire

observer énumérer,

définir,

Figure 1 : Niveaux de compétence utilisés dans les grilles d’évaluation (formative ou certiﬁcative)

(4)

Grille d’auto-évaluation

Voici la grille d’auto-évaluation de compétencesa priori acquises dans les modules CSC3601 et PRO3600.

Si certaines notions de la grille ne vous semblent pas acquises, prenez connaissance des pages qui suivent.

Notions / concept/ élément de modélisation 0 1 2 3 4 5

Modèle X

Modélisation informelleVersus semi-formelle (graphique) versus formelle (mathématique)

X X

Rôle de la notation UML X X

Rôle de l’expression des besoins X X X

Cahier des charges X X X

Règle de gestion X X X

Table 1: Grille d’auto-évaluation des prérequis sur la modélisation et l’expression des besoins

(5)

# 2

'

&

$

%

1 Généralités sur la modélisation orientée objet et sur UML

1.1 Principes de la modélisation. . . .3 1.2 Pourquoi et comment modéliser en orienté objet . . . 4 1.3 Uniﬁed Modelling Language (UML) . . . 5

Une organisation, grande ou petite, dépend souvent, d’une part, de la qualité de son système d’information, et d’autre part, de systèmes informatiques spécifiques à son métier. Une organisation qui sait développer ou faire développer les logiciels dont ses collaborateurs ont besoin en temps et en heure tout en restant dans les budgets fixés assure sa pérennité et son efficience. Cet aspect est stratégique et permet de se distinguer des concurrents. Pour développer des logiciels correspondant aux besoins des utilisateurs, un processus de développement compris par l’ensemble des intervenants est très utile. Dès que le logiciel à développer est non trivial et doit rendre service pendant plusieurs années, toute partie du logiciel doit être utile (pour éviter de maintenir du code qui ne sert à rien), et doit être comprise par les différentes équipes de développement qui produisent les différentes versions d’année en année et par les utilisateurs nouveaux qui arrivent au fil des années. Pour toutes ces raisons, un modèle du système informatique, comprenant un modèle de la partie logicielle, est nécessaire.

L’objectif de ce cours est de vous présenter les concepts de la modélisation de systèmes informatiques, c’est-à-dire des systèmes dans lesquels la partie logicielle est prépondérante. La co-conception matérielle et logicielle n’est pas abordée dans ce cours.

Un modèle est une abstraction de la réalité permettant de mieux comprendre le système. Nous construi- sons des modèles des systèmes complexes parce qu’il est diﬃcile, voire impossible, de maîtriser la complexité sans modélisation abstraite au delà d’une certaine taille. En outre, le choix du modèle à créer est important.

Le système logiciel est étudié selon son architecture et exprime comment des entités (appelées objets par la suite) interagissent pour remplir une fonction. Un critère important de la qualité d’un modèle orienté objet est alors la cohérence entre les objets (réels) du système réel modélisé et les objets (virtuels) du modèle du système réel.

La modélisation à base de graphiques est plus précise qu’une description informelle en langage naturel.

C’est un premier niveau de formalisme, suffisamment léger pour être compris par le client, suffisamment formel pour pouvoir proposer une première analyse, support à l’approfondissement nécessaire ultérieur avec une notation plus formelle ou à la réalisation du logiciel dans un langage donné. Le grand intérêt de la notation UML réside d’une part dans son orientation objet avec des notations graphiques faciles à comprendre par tout public, et d’autre part, dans sa standardisation et très grande diffusion aussi bien dans le milieu académique qu’industriel. Les modèles mathématiques utilisés pour modéliser les systèmes critiques ne sont pas étudiés dans ce cours.

(6)

Prérequis : modélisation et expression des besoins 1 Généralités sur la modélisation orientée objet et sur UML

# 3

'

&

$

%

1.1 Principes de la modélisation

■ Objectif principal de la modélisation=maîtriser la complexité

■ Modéliser=abstraire la réalité pour mieux comprendre le système à réaliser / réalisé

■ Le modèle doit être relié au monde réel

♦ Par exemple : l’existant avant les travaux, le réalisé, le restant à réaliser

■ Un modèle peut être exprimé avec diﬀérents niveaux d’abstraction / de raﬃnement

♦ Par analogie : répartition électrique de l’immeuble, de la cage d’escalier, de l’appartement, de la pièce

■ Une seule « vue » du système n’est pas suﬃsante

♦ Les intervenants multiples du projet informatique possèdent des préoccupations multiples

▶ Par analogie : plan de masse, vues de face et de côté, schéma électrique, plan de plomberie, plan de calculs de construction

Le processus de modélisation vise à obtenirunesolution acceptable du système informatique. La solution ﬁnalement retenue n’est pas obtenue en une seule itération. Plusieurs étapes sont nécessaires ; ces étapes successives permettent de raﬃner le niveau de détails du système à réaliser. Les premières étapes donnent une vision à très gros grains et permettent d’avancer dans la compréhension du problème.

Par analogie avec un architecte qui dessine plusieurs plans pour concevoir une maison, la conception d’un système informatique est organisée dans un modèle d’architecture qui prévoit plusieurs visions du même problème pour aider à trouver unesolution acceptable. La cohérence entre les différentes vues du système est importante, chaque vue ciblant des catégories différentes d’intervenants ayant des attentes différentes.

Lorsqu’une équipe collabore au développement d’un système informatique (de taille conséquente), trop de détails empêchent d’avoir une vue synthétique compréhensible par tous les participants (en anglais,sta- keholders)¹ au projet informatique, et trop peu d’informations conduit à des interprétations différentes et contradictoires. À partir d’une certaine taille et complexité, l’informatisation d’un système nécessite un processus de modélisation. Quelle que soit la taille du problème, une phase de modélisation est une aide au développement du système informatique. Cependant, souvent, le nombre de personnes qui participent à la résolution du problème (clients, équipe de développement, équipe de maintenance) est un des éléments jouant fortement dans la décision de passer par une phase de modélisation. Plus le nombre de personnes est important, plus les échanges de documents sont importants. Le processus de modélisation est nécessaire pendant toute la durée de vie du projet : discussion avec les clients, analyse du système à réaliser, documentation commune entre les développeurs, etc. La pérennité de l’informatisation réalisée est un autre élément justifiant la décision de modéliser le système. En effet, le développement mais aussi la maintenance corrective et la maintenance évolutive du système bénéficient de l’existence du modèle en tant que documentation de référence.

Le modèle permet donc de spéciﬁer le système à réaliser/réalisé, de valider le modèle vis-à-vis des clients, de fournir un guide pour la construction du système pour organiser les structures de données et le compor- tement du système, et de documenter le système et les décisions prises.

Cf. le glossaire pour la déﬁnition des termes « modèle », « processus de modélisation », « élément de modèle ».

1. Il est d’usage d’utiliser le singulier pour nommer collectivement les participants possédant le même rôle dans le projet. Il est plus important de nommer les rôles que de préciser si le rôle est tenu par une personne ou par une équipe. Par conséquent, le pluriel utilisé ici à «stakeholders» indique la multiplicité des rôles.

(7)

# 4

'

&

$

%

1.2 Pourquoi et comment modéliser en orienté objet

■ Relier le modèle au monde réel par la notion d’objet

■ Orienté objet=abstraire et décomposer le système informatique en objets

♦ Le monde réel est constitué d’objets physiques ou immatériels

♦ Tracer les objets virtuels de modélisation depuis les objets du monde réel

▶ Relier les objets (réels) du problème et les objets (virtuels) de la solution

♦ Favoriser les abstractions naturelles du monde réel utilisables en modélisation

▶ Objets vus comme des « boîtes noires » : seules les propriétés visibles de l’extérieur intéressent

▶ Objets possédant un nom, qualiﬁables, classables, polymorphes, dé-/composables, interagissant avec d’autres objets, etc.

■ Objectifs supplémentaires lors de la modélisation orientée objet

♦ Meilleure indépendance du modèle par rapport aux fonctions demandées

♦ Meilleure capacité d’adaptation et d’évolution du modèle lorsque des fonctionnalités sont modiﬁées ou ajoutées

Un modèle est une abstraction d’objets¹ de la réalité. C’est donc une simplification du monde réel. La problématique consiste alors, de manière idéale, à trouver le bon niveau d’abstraction et à exprimer les concepts du monde réel dans un langage assez abstrait pour passer à l’échelle (en termes d’objets reliés entre eux, donc organisés en graphe [cf. la théorie des graphes]) mais aussi précis qu’un langage de programmation pour que ce langage soit interprétable par un programme informatique. Le code source d’un système logiciel est un modèle du système. Ce code source ne fournit cependant qu’un seul niveau d’abstraction, celui de la mise en œuvre sur une infrastructure matérielle particulière, compréhensible par une partie seulement des intervenants du projet informatique, les développeurs. Le processus d’informatisation consiste à définir des étapes pour aller d’un cahier des charges rédigé en langage naturel à une mise en œuvre dans un code source particulier. Le modèle du système dans les premières phases de ce processus est nécessairement une simplification du système réel. Le processus de modélisation vise à mieux cerner les limites du système à réaliser. Ensuite, les modèles sont raffinés de plus en plus pour aboutir au code.

L’approche orientée objet est une façon d’aborder un problème et de le découper en petits sous-problèmes.

On commence par rechercher les objets du système puis leurs interactions. Par analogie, si je m’intéresse au fonctionnement du corps humain, je décompose l’étude du problème en plusieurs sous-problèmes plus simples : le cœur, le système digestif, le système nerveux, le squelette, etc. Nous avons alors une étude des différents éléments mais également une étude des interactions entre ces différents éléments. De la même façon, si j’appréhende l’informatisation d’une banque, je recherche les différents types d’objets qui font partie du système à réaliser : la banque, les clients, les comptes bancaires, les conseillers clients, les transferts, les placements, les emprunts, etc. J’étudie ensuite les interactions entre ces différents types d’objets : par exemple, la création d’un compte bancaire nécessite des interactions entre le client et un conseiller client.

Cf. le glossaire pour la déﬁnition des termes « objet » et « encapsulation ».

(8)

# 5

'

&

$

%

1.3 Uniﬁed Modelling Language (UML)

OMT−2

James Rumbaugh

Booch’93

Grady Booch

OOSE

Ivar Jacobson

UML 0.9

WWW Juin 96

UML 0.8

OOSPLA’95

UML 1.0

Proposé à un standard OMG

UML 1.1

Standard OMG ADTF fin 1997

divers

Partenaires ^{fin 1997} Task force

UML 1.2 UML 1.3

1998

UML 1.4

2001

UML 1.5

2003

UML 2.0

2005

UML 2.3

2010 2013

UML 2.4.1 UML 2.4.1

2013

UML 2.5.1

2017

■ Systèmes d’informations des entreprises, Banques et services ﬁnanciers, Télécommunications, Transports, Défense et aérospatiale, Calculs scientiﬁques, Applications réparties en réseau, services Web Internet, etc.

L’orientation objet est un concept apparu d’abord dans les communautés de recherche sur les langages de programmation. Ainsi, le premier langage de programmation orienté objet (appeléSimula) date de la fin des années 1960, ce qui valut à ses auteurs norvégien Ole-Johan Dahl et Kristen Nygaard l’ACMTuring Award (considéré comme le prix Nobel d’informatique) en 2001. Le premier langage orienté objet qui fut accueilli à la fin des années 1980 par un public plus large et qui rassemble une communauté d’utilisateurs toujours très active est le langageSmalltalk. Depuis, sont apparusObjective C,C++,Eiffel,Java,Python,Ruby,Scala, etc.

Les premières méthodes de modélisation, quant à elles, ont été élaborées à la fin des années 1980. Les trois plus célèbres s’appelaient la méthode Booch (du nom de l’auteur Grady Booch), OOSE (Object-Oriented Software Engineering) de Ivar Jacobson, et OMT (Object Modeling Technique) de James Rumbaugh.Los Tres Amigos, comme ils sont appelés dans la communauté, se sont unis dans les années 1990 pour former UML (Unified Modeling Language). Cette unification s’est opérée dans le cadre de la sociétéRational Software qui a été absorbée depuis par IBM. Afin de toucher une plus large audience, leurs résultats ont été standardisés ensuite par le consortium OMG (Object Management Group) en tant que la notation UML. La version actuelle de la notation UML est disponible sur le site de l’OMG (www.omg.org).

UML est une notation de modélisation très répandue dans le monde. Cette diapositive liste certains des domaines qui se sont constitués en «task force» au sein de l’OMG. La spéciﬁcation d’un système avec UML n’exclut pas bien sûr une modélisation du système avec des modèles formels (c’est-à-dire plus formels que la modélisation semi-formelle à base de diagrammes graphiques UML).

(9)

# 6

'

&

$

%

1.3.1 UML, un langage

■ UML est un langage de modélisation orienté objet

■ UML n’est pas une méthode

■ UML a été adopté par toutes les méthodes orientées objet

■ UML est dans le domaine public ; c’est un standard

■ UML est un langage pour :

♦ Visualiser

▶ Chaque symbole graphique possède une sémantique

♦ Spéciﬁer

▶ De manière précise et complète, sans ambiguïté

♦ Construire

▶ Une partie du code des classes peut être généré automatiquement

♦ Documenter

▶ Les diﬀérents diagrammes, notes, contraintes, exigences sont conservés dans un document

UML est un langage de modélisation orienté objet, c’est-à-dire que toutes les entités modélisées sont des objets ou se rapportent à des objets : par exemple, un objet possède une structure de données (avec ce qui s’appelle des « attributs ») et des comportements (avec ce qui s’appelle des « opérations »). UML n’est pas une méthode. C’est pourquoi ce cours ne se résume pas à l’acquisition des notations UML mais comprend la présentation et la mise en pratique d’une méthodologie simple. UML a été adopté par toutes les méthodes orientées objet et est devenu le standard de l’industrie.

UML est un langage et possède les attributs d’un langage. Ainsi, étant graphique, UML permet de visualiser le système réalisé ; le modèle est divisé en vues sélectionnant les éléments pertinents puis en diagrammes de différents types. L’aspect graphique de la notation UML retient le premier l’attention de ses utilisateurs. Comme pour tout langage, les éléments du langage sont définis de manière précise, complète et sans ambiguïté. Cependant, au moment de l’écriture de ce commentaire (2018), il n’existe pas de preuve formelle de la correction/robustesse (en anglais,soundness) de UML comme un tout ; seuls les langages de certains diagrammes sont formellement prouvés corrects. En outre, UML est outillé par des éditeurs logiciels dans des ateliers de génie logiciel (AGL) qui permettent, en plus de la modélisation, de générer le squelette du code source de certaines parties du système informatique, ce qui ajoute de l’intérêt à UML. Certains de ces ateliers permettent aussi d’effectuer la rétro-conception d’un système déjà réalisé : à partir du code, construction du modèle UML. Enfin, UML permet la documentation du système. Cette documentation est utilisée pour faciliter les échanges entre les différents intervenants dans toutes les phases du processus de développement et de maintenance du système informatique.

En conclusion de cette section sur les généralités sur la modélisation, nous formulons l’avertissement qui suit : il est important de garder en mémoire tout au long de ce module que la méthodologie proposée n’est qu’une parmi beaucoup d’autres et que des choix diﬀérents peuvent être eﬀec- tués quant à l’utilisation dans telle ou telle activité du processus de développement de tel ou tel type de diagramme.

Cf. le glossaire pour la déﬁnition du terme « processus de développement ».

(10)

# 7

'

&

$

%

2 Expression des besoins

2.1 Rôle de l’expression des besoins . . . 8 2.2 Exemple de cahier des charges : Médiathèque . . . 10 2.3 Règles de gestion de l’application . . . 12

Dans notre étude de cas, nous fournissons le cahier des charges. Autrement dit, l’expression des besoins est faite. C’est une tâche qui prend beaucoup de temps et qui, bien sûr, dépend du domaine métier du système à réaliser.

Dans ces quelques pages, nous expliquons succintement le rôle de l’expression des besoins. Ensuite, nous présentons le cahier des charges de l’application exemple (la médiathèque) utilisée comme fil rouge dans les cours. Enfin, nous vous demandons de lire le cahier des charges de l’étude de cas sur laquelle vous travaillez tout au long du module.Ce travail doit impérativement être effectué avant d’arriver au cours de la Séance 2.

(11)

Prérequis : modélisation et expression des besoins 2 Expression des besoins

# 8

'

&

$

%

2.1 Rôle de l’expression des besoins

■ Permettre une meilleure compréhension du système

■ Comprendre et structurer les besoins du client

♦ Clariﬁer, ﬁltrer et organiser les besoins, ne pas chercher l’exhaustivité

■ Une fois identiﬁés et structurés, ces besoins :

♦ Déﬁnissent le contour du système à modéliser

▶ Précisent le but à atteindre

♦ Permettent d’identiﬁer les fonctionnalités principales du système

Dans ce cours, nous supposons que le client vient vous voir avec un cahier des charges du système à réaliser. Bien sûr, il existe des méthodologies d’établissement de cahiers des charges.

Ces problématiques et les phases correspondantes qui se situent en amont de l’établissement du cahier des charges du système, comme par exemple le positionnement du système dans un ensemble plus vaste de systèmes de systèmes (activité appelée « urbanisation »), sont étudiées notamment dans les voies d’approfondissement DSI (« Intégration et Déploiement de Systèmes d’Information ») et ISI (« Ingénierie des Systèmes d’Information »).

Cf. le glossaire pour la déﬁnition du terme « exigence ».

(12)

# 9

'

&

$

%

2.2 Exemple de cahier des charges : Médiathèque

■ Système de gestion du fond de CD audios, de DVD et de livres

■ Système accessible à tous les employés de la médiathèque

■ Pour les clients, fonctions de consultation des catalogues et de consultation de ses propres emprunts en cours

■ Documents disponibles à la consultation ou à l’emprunt

■ Les personnes désirant emprunter doivent s’inscrire auprès d’un employé de la médiathèque

■ Ils empruntent et rendent un document par l’intermédiaire d’un employé de la médiathèque

■ L’inscription consiste à indiquer les nom, prénom et adresse

■ Les catégories de client sont « à tarif normal » ou « à tarif réduit » ou « abonné » (avec cotisation annuelle)

■ La catégorie de client conditionne les critères d’emprunt suivants :

♦ Le nombre de documents empruntables et la durée de prêt

# 10

'

&

$

%

■ Chaque document est repéré par un code unique et une localisation (salle/rayon)

■ Certains documents ne peuvent pas être empruntés, mais uniquement consultés sur place

■ Les informations communes aux documents sont les suivantes : le titre, l’auteur (écrivain, groupe ou metteur en scène) et l’année de sortie

♦ les CD possèdent un genre musical (par exemple, « classique », « variétés françaises », « variétés internationales », « compilation ») et une classiﬁcation (par exemple, « opéra » pour le genre « classique », «hardcore» pour le genre

« variétés internationales » ou «rock » pour le genre « compilation ») ;

♦ Les DVD possèdent un genre de vidéo (« documentaire », « comédie »...), une durée d’émission et une mention légale de diﬀusion (restrictions d’usage) ; cette mention doit être disponible lors de l’emprunt du DVD pour permettre un éventuel contrôle ;

♦ Les livres possèdent un genre (« roman », « policier », etc.) et un nombre de pages.

■ Chaque sortie de document entraîne la constitution d’une ﬁche d’emprunt.

Voici la « version » textuelle du cahier des charges.

Nous souhaitons réaliser un système de gestion du fond de CD audios, de DVD et de livres d’une mé- diathèque, et du prêt de ce fond à ses clients. Ce système doit être accessible par tous les employés de la médiathèque. Les fonctions de consultation des catalogues et de consultation de ses propres emprunts en cours doivent également être accessibles aux clients de la médiathèque.

• La médiathèque contient un certain nombre de documents disponibles à la consultation ou à l’emprunt ; les personnes désirant emprunter des ouvrages pour une durée et à un tarif donnés doivent s’inscrire en tant que client.

• Les clients s’inscrivent auprès d’un employé de la médiathèque, et empruntent et rendent un document par l’intermédiaire d’un employé de la médiathèque.

(13)

• L’inscription des clients consiste à remplir une ﬁche datée sur laquelle sont notées les informations suivantes : nom et prénom du client ainsi que son adresse.

• Les catégories actuelles de client permettent au client de choisir de payer à chaque emprunt eﬀectué (catégorie « à tarif normal » ou « à tarif réduit ») ou de régler une cotisation annuelle (catégorie

« abonné »).

• Outre le tarif, la catégorie du client conditionne les critères d’emprunt suivants : le nombre de documents empruntables et la durée de prêt (voir ci-dessous). Dans le cas « tarif réduit », un justiﬁcatif est demandé à l’inscription, puis à chaque date anniversaire. Les justiﬁcatifs à prévoir sont les suivants : carte étudiant/scolaire, carte vermeil et carte « à caractère social ».

• Les documents disponibles sont des CD audios, des DVD ou des livres. Chaque document est repéré par un code unique et une localisation (salle/rayon) dans la médiathèque. Certains documents ne peuvent pas être empruntés, mais uniquement consultés sur place. Les informations communes aux documents sont les suivantes : le titre, l’auteur (écrivain, groupe ou metteur en scène) et l’année de sortie. Le système devra permettre de disposer de statistiques d’utilisation, telles que le nombre d’emprunts eﬀectués pour les diﬀérentes catégories et genres de documents. Les autres informations des documents sont les suivantes :

– les CD possèdent un genre musical (par exemple, « classique », « variétés françaises », « variétés internationales », « compilation ») et une classiﬁcation (par exemple, « opéra » pour le genre

« classique », « hardcore » pour le genre « variétés internationales » ou « rock » pour le genre

« compilation ») ;

– Les DVD possèdent un genre de vidéo (« documentaire », « comédie »...), une durée d’émission et une mention légale de diﬀusion (restrictions d’usage) ; cette mention doit être disponible lors de l’emprunt du DVD pour permettre un éventuel contrôle ;

– Les livres possèdent un genre (« roman », « policier », etc.) et un nombre de pages.

Les genres précisés sont libres ; ils sont donnés aux clients à titre indicatif pour aider au choix lors d’un emprunt.

• Chaque sortie de document entraîne la constitution d’une ﬁche d’emprunt. Sur cette ﬁche, sont notés le client emprunteur, la date de début du prêt, le document emprunté et la date limite de restitution. Les durées de prêt dépendent du type de document et de la catégorie du client (voir les règles ci-dessous) ;

• La médiathèque met à la disposition des clients des ordinateurs pour qu’ils consultent le catalogue, leurs emprunts, et puissent mettre à jour leur adresse.

Le système de gestion doit prévoir toute opération d’ajout et de suppression de clients et de documents.

Les informations les concernant ne sont pas construites par le système (par exemple, la localisation des documents dans les locaux), mais supposées fournies lors de l’invocation de ces opérations. Le système doit permettre de réviser les catégories et leurs conditions associées. D’autre part, les formats de la plupart des informations sont libres (chaînes de caractères) ; le système doit toutefois veiller à la cohérence des informations stockées (impossibilité d’avoir deux clients ou deux documents avec le même nom, d’emprunter deux fois le même document, etc.).

(14)

# 11

'

&

$

%

2.3 Règles de gestion de l’application

■ Un client ne peut pas emprunter plus d’un certain nombre de documents : 2 pour

« tarif réduit », 5 pour « tarif normal » et 10 pour « abonné »

♦ Dès que ce nombre maximal est atteint pour un client donné, tout nouveau prêt doit être impossible

■ Tout client qui n’a pas restitué un document avant sa date limite de restitution ne peut plus faire de nouvel emprunt tant qu’il n’a pas régularisé sa situation, ceci même si le nombre maximal d’emprunts n’est pas atteint

■ Le tarif des emprunts dépend du document et du client

♦ Le tarif du document est ﬁxé par son type :0,5epour un livre,1epour un CD audio et1,5epour un DVD

♦ Pour les clients « à tarif normal »=montant ﬁxé pour chaque document emprunté

♦ Pour les clients « à tarif réduit »=moitié du « tarif normal »

♦ Pour les « abonnés »=cotisation annuelle =⇒ gratuit

# 12

'

&

$

%

■ la durée des emprunts dépend du document et du client

♦ Chaque type de document est empruntable pour une durée dite normale : 2 semaines pour un DVD, 4 semaines pour un CD audio et 6 semaines pour un livre

♦ La durée de prêt est modiﬁée selon la catégorie du client : aucun changement

— la durée normale — pour un client à tarif normal, la moitié de cette durée pour un client à tarif réduit et le double de cette durée pour un abonné

■ Un client peut changer de statut

Les premiers éléments du cahier des charges sont complétés par des règles dites de gestion, c’est-à-dire des contraintes opérationnelles. Voici la « version » textuelle des règles de gestion de l’étude de cas Médiathèque.

L’emprunt d’un document par un client obéit à certaines règles :

• un client ne peut pas emprunter plus d’un certain nombre de documents ﬁxé par sa catégorie : 2 pour la catégorie « à tarif réduit », 5 pour la catégorie « à tarif normal » et 10 pour la catégorie « abonné ».

Dès que ce nombre maximal est atteint pour un client donné, tout nouveau prêt doit être impossible ;

• tout client qui n’a pas restitué un document avant sa date limite de restitution ne peut plus faire de nouvel emprunt tant qu’il n’a pas régularisé sa situation, ceci même si le nombre maximal d’emprunts n’est pas atteint. Pour ce faire, à chaque demande d’emprunt, le système vériﬁe s’il est à jour dans ses restitutions ; si ce n’est pas le cas, l’emprunt n’est pas autorisé.

(15)

• l’ensemble des fiches d’emprunt est parcouru chaque jour afin de repérer s’il existe des documents pour lesquels la date limite de restitution est dépassée. Pour chacune de ces fiches trouvées, la date de rappel de la fiche est mise à la date du jour, le client concerné est marqué et la médiathèque envoie une lettre de rappel que nous considérons hors système. Les fiches ayant fait l’objet d’un rappel font l’objet d’une relance hebdomadaire.

• le tarif des emprunts dépend du document et du client. Le tarif du document est ﬁxé par son type : 0,5e pour un livre,1epour un CD audio et1,5epour un DVD. La règle pour les clients « à tarif normal » est de payer le montant ﬁxé pour chaque document emprunté (indiqué auparavant). Le tarif appliqué aux clients « à tarif réduit » est la moitié du « tarif normal ». Les « abonnés » réglant une cotisation annuelle empruntent les documents gratuitement ;

• la durée des emprunts dépend du document et du client. Chaque type de document est empruntable pour une durée dite normale : 2 semaines pour un DVD, 4 semaines pour un CD audio et 6 semaines pour un livre. Ensuite, la durée de prêt est modiﬁée selon la catégorie de client : aucun changement

— la durée normale — pour un client à tarif normal, la moitié de cette durée pour un client à tarif réduit et le double de cette durée pour un abonné ;

• un client peut changer de statut.Par exemple, un client abonné devient un client à tarif normal si son abonnement n’est pas renouvelé à la date anniversaire. De la même façon, un client à tarif réduit devient un client à tarif normal si aucun justiﬁcatif n’est fourni à la date anniversaire.

Cf. le glossaire pour la déﬁnition du terme « règle de gestion ».

Prérequis sur les généralités sur la modélisation et l’expression des besoins