EVALUATION EN GENIE LOGICIEL TEST  03/ XX   

Examen Genie Logiciel

Exercice 01 :  Développement Agile des Logiciel 04pts

1. Expliquez pourquoi la livraison rapide et le déploiement de nouveaux systèmes sont souvent plus importants pour les entreprises que la fonctionnalité détaillée de ces systèmes.
2. Expliquer comment les principes fondamentaux des méthodes agiles conduisent au développement et au déploiement accélérés de logiciels.
3. Extreme programming exprime les exigences des utilisateurs comme des stories, chaque story étant écrite sur une carte. Discutez des avantages et des inconvénients de cette approche de la description des exigences.
4. Quand recommanderiez-vous l'utilisation d'une méthode agile pour développer un système logiciel

PROBLEME DIAGRAMME UML : Le système GBU 16pts

Le système GBU (Gestion de bibliothèque universitaire) permet de gérer les livres et revues scientifiques d'une bibliothèque universitaire. Il traite les ajouts, les suppressions, les commandes ainsi que les emprunts et les retours des ressources de la bibliothèque, c'est-à-dire les livres et les numéros des diverses revues auxquelles elle est abonnée. Il effectue des relances périodiques des emprunteurs et assiste le bibliothécaire pour chercher ou remettre à leur place les exemplaires de livre ou de revue lors des emprunts et des retours. Seuls les utilisateurs enregistrés peuvent emprunter des ressources de la bibliothèque. Un utilisateur s'enregistre via le bibliothécaire et dépose à cette occasion une caution qui sert à garantir le retour des ouvrages. À chaque ouvrage on associe une caution minimale qui doit rester sur le compte de l'emprunteur pour que celui-ci puisse emprunter cet ouvrage. À chaque emprunt d'ouvrage, la caution est décrémentée ; à chaque retour, sa caution est incrémentée. Les utilisateurs peuvent créditer leur caution via le système pour améliorer leur capacité d'emprunt de ressources. Le système limite les fonctionnalités à la gestion des emprunts, des retours, des relances périodiques et des cautions. Un livre est caractérisé par son titre, son auteur (unique pour simplifier) et son code ISBN (unique). Un numéro de revue comprend le titre de la revue, sa date de parution et un numéro de volume (ex. : "Journal Orcéen de UML", Mars 2007, Volume 57). Chaque exemplaire d'une ressource est identifié de manière unique par un code-barre, utilisé lors de la restitution par l'utilisateur. La bibliothèque possède généralement plusieurs exemplaires d'un livre ou d'un numéro de revue, tous rangés à la même place. Une place est indiquée de manière imprécise : numéro de travée, numéro d'étagère, et niveau. Plusieurs ouvrages différents peuvent donc être à la même place. Un utilisateur ne peut pas emprunter plusieurs exemplaires d'une même ressource. S'il est en retard pour rendre une ressource, il ne peut en emprunter de nouvelles. Il en est de même si sa caution restante est inférieure à la caution associée à la ressource. Chaque jour, GBU déclenche une vérification des emprunts pour relancer les éventuels emprunteurs en retard. La relance liste tous les emprunts en retard. Une amende forfaitaire est déduite de la caution de l'emprunteur en cas de retard. Lors d'un emprunt, le bibliothécaire indique au système le nom de la ressource à emprunter. Le système vérifie la disponibilité de l'exemplaire, que l'emprunteur n'en a pas déjà un, et que sa caution est suffisante. Si tout est en ordre, le système indique le code-barre de l'exemplaire à fournir et son emplacement. La durée de l'emprunt est de 15 jours. Lors d'un retour, le bibliothécaire identifie l'exemplaire rendu grâce à son code-barre. Le système indique l'emplacement où ranger l'exemplaire.

Partie 1 : Modélisation UML (7 points)

1. Diagramme des cas d'utilisation et diagrammes de séquence illustrant les opérations avec paramètres, valeurs retournées et cas d'erreurs possibles.
2. Scénarios dynamiques illustrant les principaux aspects du système, avec enchaînements pertinents d'opérations et brève description de la pertinence.
3. Diagramme de classes du système avec attributs (type), associations (cardinalités) et noms de rôle pertinents.
4. Description des invariants potentiels, spécifiant ceux qui ne le sont pas réellement, ceux déjà exprimés dans le diagramme de classes et ceux non exprimés dans le diagramme, traduits en français en utilisant la navigation dans le diagramme de classes.

Partie 2: Manipulation des contraintes OCL (9 points)

Exprimer les invariants suivants en OCL :

• (a) La caution associée à un ouvrage est toujours positive ou nulle.
• (b) Les codes barres de deux exemplaires quelconques sont distincts.
• (c) Les codes barres de chaque exemplaire d'un ouvrage sont distincts.
• (d) Un emprunteur ne peut pas avoir plus d'un exemplaire de chaque ouvrage.
• (e) On ne peut pas emprunter plus de 5 ouvrages en même temps.
• (f) Les livres rares n'existent qu'en un seul exemplaire, avec une caution élevée de 25 pour éviter les retards.
• (g) On ne peut pas emprunter plus de 2 exemplaires de revue en même temps.
• (h) Si une personne a un exemplaire dans la liste de ses emprunts, l'emprunteur associé à cet ouvrage est la même personne.
• (i) La somme des cautions des ouvrages empruntés ne peut pas dépasser 25.

                                                                          Contact WhatsApp : +237 658395978 / Réaliser Par Joël_Yk

exercice 01 : AGILITE

1. La livraison rapide et le déploiement de nouveaux systèmes sont souvent plus importants pour les entreprises que la fonctionnalité détaillée de ces systèmes pour plusieurs raisons clés :

• Avantage concurrentiel : Dans un environnement commercial compétitif, être capable de lancer rapidement des solutions innovantes sur le marché peut permettre à une entreprise de prendre de l'avance sur ses concurrents et de saisir des opportunités.
• Rétroaction des utilisateurs : En lançant rapidement des versions initiales d'un système, une entreprise peut recueillir les commentaires et les retours des utilisateurs réels. Cela permet d'ajuster rapidement la direction du développement en fonction des besoins et des préférences réels des utilisateurs, ce qui conduit à des solutions plus adaptées.
• Apprentissage itératif : En livrant des versions initiales, les entreprises peuvent apprendre de manière itérative et affiner leur compréhension des exigences et des priorités du projet. Cela réduit le risque de développer une solution inadaptée aux besoins du marché.
• Évolution continue : Les besoins et les préférences des clients évoluent rapidement. Ainsi, la capacité à livrer rapidement et à déployer de nouvelles fonctionnalités permet aux entreprises de s'adapter aux changements du marché plus rapidement et de rester pertinents.
• Validation rapide de la valeur : La livraison précoce permet de valider rapidement si une idée ou une fonctionnalité apporte réellement de la valeur aux utilisateurs. Si ce n'est pas le cas, l'entreprise peut ajuster sa stratégie sans avoir investi trop de ressources.

2. Les principes fondamentaux du développement agile sont les suivants:

• a) Personnes et interaction plutôt que processus et outils. En prenant les avantages des compétences individuelles et en veillant à ce que l'équipe de développement sache ce que font les autres, les frais généraux de communication formelle et d'assurance de processus sont évités. Cela signifie que l'équipe peut se concentrer sur le développement de logiciels de travail.
• b) Logiciel fonctionnel plutôt que documentation complète. Cela contribue à accélérer le développement parce que le temps n'est pas passé à se développer, vérifier et gérer la documentation. Le temps du programmeur est plutôt axé sur le développement et le test du code.
• c) Collaboration avec le client plutôt que négociation de contrat. Plutôt que de passer du temps à développer, analyser et négocier les exigences à inclure dans un contrat système, les développeurs agiles soutiennent qu'il est plus efficace d'obtenir des commentaires des clients directement au cours du développement sur ce qui est requis. Cela permet de développer et de livrer des fonctionnalités utiles plus tôt que cela ne serait possible si des contrats étaient requis.
• d) Réagir au changement plutôt que suivre un plan. Les développeurs agiles soutiennent (à juste titre) qu'être attentif aux changements est plus efficace que de suivre un processus basé sur un plan parce que le changement est inévitable quel que soit le processus utilisé. Il y a des frais généraux importants dans la modification des plans pour s'adapter au changement et l'inflexibilité d'un plan signifie que le travail peut être fait qui est ensuite mis au rebut.

3.-------
Avantages des stories:

• 1. Ils représentent des situations réelles qui se posent généralement afin que le système soutenir les opérations les plus courantes de l'utilisateur.
• 2. Il est facile pour les utilisateurs de comprendre et de critiquer les stories.
• 3. Ils représentent des incréments de fonctionnalité - la mise en œuvre d'un story délivre une certaine valeur pour l'utilisateur.

Inconvénients des stories

• 1. Ils sont susceptibles d'être incomplètes et leur nature informelle rend l‟incomplétude difficile à détecter.
• 2. Ils se concentrent sur les exigences fonctionnelles plutôt que les non-fonctionnelles.
• 3. Représentation des exigences transversales du système telles que la performance et la fiabilité est impossible lorsque les stories sont utilisées.
• 4. La relation entre l'architecture du système et les stories d‟utilisateurs est peu claire et donc, la conception architecturale est difficile.

4. L'utilisation d'une méthode agile pour développer un système logiciel est recommandée lorsque :

• Les besoins évoluent rapidement : Les méthodes agiles sont particulièrement adaptées lorsque les exigences et les priorités changent fréquemment, car elles permettent de s'adapter plus facilement aux nouvelles informations et aux retours des utilisateurs.
• La collaboration est essentielle : Les méthodes agiles encouragent la collaboration continue entre les développeurs, les parties prenantes et les utilisateurs finaux, ce qui favorise une meilleure compréhension des besoins et des objectifs du projet.
• L'itération est valorisée : Si l'entreprise souhaite livrer des versions initiales du produit rapidement, puis itérer pour améliorer progressivement les fonctionnalités en fonction des retours, une approche agile convient mieux.
• La rapidité est cruciale : Si le délai de mise sur le marché est un facteur déterminant, l'agilité permet de lancer des versions fonctionnelles plus tôt, ce qui peut être avantageux.
• Le contrôle et l'adaptabilité sont nécessaires : Les méthodes agiles offrent une flexibilité pour ajuster les objectifs et les fonctionnalités du projet au fur et à mesure que de nouvelles informations et des priorités émergent.

problème 16 pts:

Partie 1 : Modélisation UML

1. Diagramme des Cas d'Utilisation :

Voici le diagramme des cas d'utilisation correspondant au texte :

2. Diagrammes de Séquence :

a. Emprunter Ressource :

b. Retourner Ressource :

c. Enregistrer Utilisateur (Emprunteur) :

d. Relancer Emprunteur & e. Créditer Caution : suite ici :

3. Diagramme des Classes : (Emprunteur ou Utilisateur)

4. Invariants :

Parmi les invariants potentiels :

a. Invariants Corrects :

• La caution associée à un ouvrage est toujours positive ou nulle.
• Les codes-barres de deux exemplaires quelconques sont distincts.
• Les codes barres de chaque exemplaire d'un ouvrage sont distincts.
• Un emprunteur ne peut pas avoir plus d'un exemplaire de chaque ouvrage.
• On ne peut pas emprunter plus de 5 ouvrages en même temps.
• On ne peut pas emprunter plus de 2 exemplaires de revue en même temps.
• Si une personne a un exemplaire dans la liste de ses emprunts, l'emprunteur associé à cet ouvrage est ladite personne.
• La somme des cautions des ouvrages empruntés ne peut pas dépasser 25.

b. Invariants Déjà Exprimés dans le Diagramme de Classes :

• Les livres rares n'existent qu'en un seul exemplaire.
• Les livres rares ont une caution élevée, fixée à 25.
• On ne peut pas emprunter plus d'un ouvrage rare.

c. Invariants Non Exprimés dans le Diagramme de Classes :

• La caution associée à un ouvrage rare doit rester à 25.
• Un utilisateur ne peut pas emprunter de nouvelles ressources s'il est en retard pour en rendre une.
• Un utilisateur ne peut pas emprunter de nouvelles ressources si sa caution restante est inférieure à la caution associée à la ressource.

Partie 2 : Manipulation des contraintes OCL

Note ( Emprunteur = Utilisateur)

(a)

context Ressource

inv: self.cautionMinimale >= 0

(b)

context Exemplaire

inv: Exemplaire.allInstances()->isUnique(codeBarre)

OU

context Exemplaire

inv: Exemplaire.allInstances()->forAll(e1, e2 | e1 <> e2 implies e1.CodeBarre <> e2.CodeBarre)

(c)

context Exemplaire

inv: self.Ressource.Exemplaire->isUnique(codeBarre)

ou

context Livre

inv: self.Exemplaires->forAll(e1, e2 | e1 <> e2 implies e1.CodeBarre <> e2.CodeBarre)

(d)

context Emprunteur

inv: self.Emprunt->forAll(e1, e2 | e1 <> e2 implies e1.Exemplaire.Ressource <> e2.Exemplaire.Ressource)

(e)

context Emprunteur

inv: self.Emprunt->size() <= 5

(f)

context Livre

inv: self.Ressource.Exemplaire->size() <= 1 implies self.cautionMinimale = 25

(g)

context Ressource

inv: self.Exemplaire->size() <= 2 implies self.oclIsTypeOf(NumeroRevue)

(h)

context Exemplaire

inv: self.Utilisateur.Emprunt->exists(e | e.Exemplaire = self) implies self.Utilisateur = e.Utilisateur

(i)

context Utilisateur

inv: self.Emprunt->collect(e | e.Exemplaire.Ressource.cautionMinimale)->sum()< = 25

 PROCHAIN TEST  >>