1. 2ème
partie : Etude de cas – Système de Gestion de restaurants superkebab
NFE103 – Manuel Ramos 04.07.2009 1
Cahier des charges :
L’entreprise Superkebab se compose de nombreux restaurants « Kebab Hubs ».
L’activité est spécialisée dans la livraison à domicile de Kebabs et autres spécialités.
Les commandes se font par téléphone directement auprès de chaque restaurant.
Une commande comporte en général plusieurs plats.
Le nombre de commandes est limité, chaque client doit connaître la carte des plats offerts par
le restaurant contacté.
Informatiser le processus de commande/fabrication/livraison, développer un système
permettant de gérer à distance et de manière centralisée toutes les commandes, les restaurants
et les employés (collaborateurs).
Centralisation des données (plats disponibles) sur internet.
Plat (nom, photo, prix).
Une durée est également associée à chaque plat chaud.
Si temps livraison-fin de préparation>durée alors remboursement de la commande par le
restaurant.
Pour les commandes par internet, disposer d’une carte de crédit est une obligation.
Lors de la première commande, saisir son nom et son lieu de résidence.
Pour chaque plat sélectionné, le client doit indiquer la quantité désirée.
Après avoir passé la commande, le client peut à tout moment consulter l’état de sa commande.
Tant que la commande n’est pas partie, il peut l’annuler.
Les restaurants Kebab fait appel à des collaborateurs souvent des étudiants. Un téléphone
portable leur est remis. Dans chaque restaurant Kebab un collaborateur joue le rôle de
« coordinateur » consultant les commandes à réaliser, les autres préparent les plats.
Bouton spécifique pour indiquer la disponibilité, un autre bouton pour le contraire.
Le gérant peut consulter l’état du système global, il place le collaborateur soit à un restaurant
soit à la livraison. Son rôle est d’optimiser l’attribution de chaque collaborateur en fonction
des commandes. Il affecte la commande à un livreur et à un point de vente.
Chaque livreur utilise son propre moyen de transport (bus, vélo, roller, voiture). Un appareil
« pilote » lui est remis à la livraison, intégrant un GPS
Le collaborateur peut changer de lieu de travail ou de rôle plusieurs fois dans la journée.

2. 2ème
partie : Etude de cas – Système de Gestion de restaurants superkebab
NFE103 – Manuel Ramos 04.07.2009 2
A. Modélisation du système de gestion de réservations avec UML
1) Elaborer le diagramme de cas d’utilisation de ce système.
2) Représenter, sous forme de diagramme de séquences, le scénario nominal de la
réservation par un client d’une commande (une commande comporte en
général plusieurs plats).
3) Tracer le diagramme états-transitions de l’objet commande.

3. 2ème
partie : Etude de cas – Système de Gestion de restaurants superkebab
NFE103 – Manuel Ramos 04.07.2009 3
Commandé
Préparé
Livré
Annulé

4. 2ème
partie : Etude de cas – Système de Gestion de restaurants superkebab
NFE103 – Manuel Ramos 04.07.2009 4
4) Quel est le design pattern le plus approprié pour représenter le comportement
de l’objet commande ? Décrire la problématique et le contexte de mise en
œuvre de ce design pattern.
Nous avons une implémentation de la commande :
Commande
Commandé
Annulé
Livré
Préparé
Etat courant
La commande contient
maintenant une instance de
chaque classe état
Etat de la
commandeL’état courant de la
commande est toujours l’une
de ces instances de clase.

5. 2ème
partie : Etude de cas – Système de Gestion de restaurants superkebab
NFE103 – Manuel Ramos 04.07.2009 5
5) Construire le diagramme de classes détaillé du système (avec toutes les
propriétés et les méthodes de chacune des classes).
6) Représenter l’architecture logique globale de ce système sous forme
d’architecture n-tiers (à l’aide de packages UML).
B. Architecture technique du système
Pour des raisons économiques, la maîtrise d’œuvre impose l’utilisation du serveur
web Apache, du container web TOMCAT, du framework technique STRUTS, du
serveur d’applications JBoss et du SGBD PostgreSQL :
1) Décrire les fonctions principales réalisées par chacune de ces briques
fonctionnelles de l’architecture ?
A) Le serveur Apache se charge de gérer les connexions http.

6. 2ème
partie : Etude de cas – Système de Gestion de restaurants superkebab
NFE103 – Manuel Ramos 04.07.2009 6
B) Tomcat pour la couche web, c’est un container web gérant l’exécution des
JSP et les servlets. Elles sont regroupées dans des unités de déploiement
constituant les applications web.
C) Le framework d’application web Struts pour la couche présentation
utilisant l’architecture MVC, ne définit jamais le modèle.
D) Le serveur d’application Jboss, un container de composants transactionnels
EJB permet de développer la logique métier grâce aux EJB.
E) Le SGBD PostGreSQL pour la couche persistance va permettre le
stockage des données dans une BD relationnelle à l’aide de SQL.
2) Représenter schématiquement l’architecture technique globale de ce
système.
C. Conception des EJB (Enterprise Javabeans)
1) Rappeler les principales étapes de la démarche conduisant à l’exécution d’une
application complète à base de composants EJB (Enterprise Java Beans) CMP
(Container Managed Persistance)
Un bean CMP est semblable à l’utilisation d’un bean de session avec état.
Le serveur d’application JBoss utilise une technique efficace pour optimiser les
EJB CMP. On fera donc le choix d’utiliser ce type d’EJB car le code à écrire est
plus court d’où un gain de temps.
Chaque instance d’un EJB se construit dans un container EJB, un environnement
d’exécution fournissant divers services (annuaires, sécurité, transactions,
connexions à la base de données).
Un client n’accède jamais directement à un composant (=Interface +
Implémentation). Il doit pour cela passer par 2 interfaces (locales et distantes).
L’interface locale décrit le cycle d’existence du composant en définissant des
méthodes permettant de le trouver, de le créer, de le détruire. Et L’interface
distante spécifie les méthodes que ce composant présente au monde extérieur.

7. 2ème
partie : Etude de cas – Système de Gestion de restaurants superkebab
NFE103 – Manuel Ramos 04.07.2009 7
2) Ecrire en Java les squelettes de description de la HomeInterface (locale) et de
la RemoteInterface (distant) de ce système.
Un composant EJB se décompose en un ensemble de pièce, dont le Bean lui-même
(classe java), l'implémentation d'interfaces (Home et Remote) et un fichier
d'informations au format XML (descripteur de déploiement). Le tout est rassemblé
dans un fichier EJB-jar.
Chaque Enterprise Bean créé doit être associé à une interface Home. L'interface
Home est utilisée comme une Factory de votre EJB. Les clients utilisent l'interface
Home pour trouver une instance de votre EJB ou pour créer une nouvelle instance
de votre EJB.
L'interface Remote est l'interface Java qui reflète les méthodes de l'Enterprise
Bean que l'on souhaite rendre disponible au monde extérieur. L'interface Remote
joue un rôle similaire à celui de l'interface IDL de CORBA.
L’interface « HomeInterface » doit étendre « javax.ejb.EJBHome » :
- L'interface Home doit être public.
- L’interface « HomeInterface » possède au moins une méthode create ayant une
signature similaire à une méthode ejbCreate de Bean
- Chaque méthode create doit renvoyer une instance de « RemoteInterface »,
- Chaque méthode create de « HomeInterface » est susceptible de lever 2
exceptions : « java.rmi.RemoteException », « javax.ejb.CreateException ».
L’interface « HomeInterface » doit implémenter au moins la méthode de
recherche par clé primaire : findByPrimaryKey, prenant en paramètre un objet de
la même classe que la clé primaire,
- Parmi les méthodes de recherche, seule la méthode findByPrimaryKey renvoie
une instance de « RemoteInterface », les autres méthodes renvoient toutes des
« java.util.Collection ».
- Toutes les méthodes de recherche sont susceptibles de renvoyer 2 exceptions :
« java.rmi.RemoteException » et « javax.ejb.FinderExeption ».
L’interface « RemoteInterface » doit étendre « javax.ejb.EJBObject » :
- L'interface Remote est l'interface Java qui reflète les méthodes de l'Enterprise
Bean que l'on souhaite rendre disponible au monde extérieur. L'interface Remote
joue un rôle similaire à celui de l'interface IDL de CORBA.
- Les méthodes métiers de « RemoteInterface » sont toutes susceptibles de lever
une exception : « java.rmi.RemoteException ».
- L'interface Remote doit être public.
- L'interface Remote doit hériter de l'interface javax.ejb.EJBObject.