LOG430 – Architecture Logicielle

LOG430 – Architecture Logicielle
Inventory Locator LOG430 – Architecture Logicielle Francis Meloche Charlebois - MELF Yves Dubois - DUBY Marco Roy - ROYM Dominique Sarrazin - SARD

1. Pilotes commerciaux 1.1. Vision du système

1. Pilotes commerciaux 1.2. Principales fonctionnalités ID unique
Traçabilité Description Priorité F1 IL-UC-01 Gérer les localisations H/H F2 IL-UC-08 Entrer la marchandise dans une localisation (IN) F3 IL-UC-09 Sortir la marchandise de la localisation (OUT) F4 IL-UC-21 Scanner l’information des feuilles de comptage F5 IL-EF-10 Permissions

1. Pilotes commerciaux 1.3. Principaux attributs de qualité ID unique
Traçabilité Description Priorité AQ1 IL-ENF-03 Horaires de disponibilité Le logiciel doit être disponible entre 7h00 et 23h00 de dimanche au vendredi. H/H AQ2 IL-ENF-11 Temps de réponse Le temps de réponse doit être de l’ordre de 2 secondes par transaction d’entreposage M/M AQ3 IL-ENF-12 Temps de recherche d’une marchandise Les employés des opérations des CD doivent pouvoir trouver la marchandise en 4 minutes en moyenne. AQ4 IL-ENF-13 Temps de placement de la marchandise Les employés des CD doivent pouvoir placer la marchandise en 8 minutes en moyenne. AQ5 Annexe B, IMP-01 Accès aux données sécurisé Permettre l’accès et la modification des données uniquement aux employés autorisés

1. Pilotes commerciaux 1.4. Principales contraintes de conception
ID unique Traçabilité Description Priorité CC1 Annexe B, C1 Intégration à MER Le logiciel InL doit être intégré à MER et utiliser la même base de données Oracle, version 10g. H/H CC2 Annexe B, C5 Utiliser Oracle Forms/Reports La partie logicielle de InL doit être réalisée à l’aide de Oracle Forms/Reports 10g. M/M CC3 Annexe B, C6 RF Scanneur développés en Java La partie logicielle des RF Scanneurs doit être codé en Java. CC4 Annexe B, C8 Standard de code à bars Le standard de code à barres 128 doit être respecté. CC5 Annexe B, C9 Connexion avec RF Scanneurs sécurisée sous SSL La connexion avec les RF Scanneurs doit être sécurisée en utilisant des sockets SSL afin d’empêcher les intrusions et les fuites d’information

1. Pilotes commerciaux 1.5. Parties prenantes Gestionnaire de projet
VP Finances – Client Développeur Testeur Architecte

2. Architecture ( Vue #1 ) Vue Pilotes architecturaux rencontrés
Famille: Module Style: Utilise Pilotes architecturaux rencontrés F1: Gérer les localisations F2: Entrer la marchandise dans une localisation (IN) F3: Sortir la marchandise d’une localisation (OUT) F5: Système de permissions AQ5: Accès aux données sécurisé AQ6: Intégrité des transactions

2. Architecture ( Vue #1 )

Famille: C & C et Module Style: Client / Serveur et décomposition Pilotes architecturaux rencontrés F4: Scanner l’information des feuilles de comptage AQ3: Temps de recherche d’une marchandise AQ4: Temps de placement de la marchandise

2. Architecture ( Vue #2 )

Famille: Affectation Style: Déploiement Pilotes architecturaux rencontrés CC1: Intégration à MER CC2: Utiliser Oracle Forms/Reports CC3: RF Scanneur développé en Java AQ1: Horaires de disponibilité du système AQ2: Temps de réponse de 2 secondes par transaction

2. Architecture ( Vue #3 ) Vue affectation: (1)

3. Approches architecturales
Arbre d’utilité (cinq scénarios) Attribut Raffinement Scénario Disponibilité Fiabilité SSP10 - Reprise rapide de service Plage de disponibilité SSP1 - Effectuer une transaction dans une plage horaire Performance Facteur temps SSP2 - Effectuer une transaction dans un délai Utilisabilité Efficience SSP3 - Effectuer une recherche de marchandise SSP4 - Effectuer un placement de marchandise

Cinq tactiques Redondance Active Enregistrer les opérations Maintenir des copies Utiliser des services distants Limiter l’accès aux opérations

Cinq styles architecturaux : Utilise Utiliser des permissions Utiliser un buffer d’entré/sortie Utiliser un base de données

Cinq styles architecturaux: Utilise

Cinq styles architecturaux: Décomposition Séparer les services Séparer les données

Cinq styles architecturaux: Décomposition

Cinq styles architecturaux: Client/Serveur Utiliser un protocole Utiliser de la cryptographie

Cinq styles architecturaux: Client/Serveur

Cinq styles architecturaux: Déploiement Utiliser un serveur de backup Maintenir une copie des données Utiliser un WAN (Internet)

Cinq styles architecturaux: Déploiement

Cinq styles architecturaux: Données Partagées Utiliser un réseau Wifi Permettre plusieurs clients

Cinq styles architecturaux: Données Partagées

4. Analyse de scénarios Scenario : SSP1 : Effectuer une transaction dans une plage horaire Attribut : Disponibilité Environnement : Normal Stimuli : Un employé effectue une transaction d’entreposage entre 7h00 et 23h00, du dimanche au vendredi. Réponse : La transaction est enregistrée correctement dans le système. Le système est opérationnel dans la plage horaire spécifiée, i.e. de 7h00 à 23h00, du dimanche au vendredi.

4. Analyse de scénarios SSP1 : Effectuer une transaction dans une plage horaire Décision architecturale Risque Sensibilité Compromis Serveur InL local R1 S1 C1 Serveur MER de secours (redondance active) S2 C2 Serveur MER de secours (redondance passive) Utiliser le serveur MER existant R2 Raisonnement : Serveur InL local La solution pour plus qu’un scénario (voir SSP2). La perte d’un serveur local n’affecte qu’un centre de distribution. (évite le « single point of failure ») Permet de limiter le nombre le nombre de requêtes qui vont au serveur MER en servant de « cache » pour les données locales. Serveur MER de secours (redondance active) Permet de s’assurer que les transactions venant des serveurs InL locaux sont toujours reçues. (Voir risque R2) Permet au système de fonctionner en cas de panne du serveur principal sans aide externe. Certaines requêtes (lecture de données) pourraient être divisées entre les deux serveurs. (Un bonus, pourrait aider avec le scénario SSP2)

4. Analyse de scénarios SSP2 : Effectuer une transaction dans un délai Attribut : Performance Environnement : Normal Stimuli : Un employé effectue une transaction d’entreposage. Réponse : La transaction est enregistrée correctement dans le système. Le temps de réponse du système est de l’ordre de 2 secondes par transaction.

4. Analyse de scénarios SSP2 : Effectuer une transaction dans un délai
Décision architecturale Risque Sensibilité Compromis Serveur InL local S1 C1 Serveur MER concurrent (redondance active) R3 S2 C2 Utiliser la connexion actuelle R4 Assurer une vitesse de transmission rapide entre les CDs et le serveur MER S3 Prioriser les transactions R5 C3 Raisonnement : La solution pour plus qu’un scénario (voir SSP1). Permet presque assurément de satisfaire l’exigence, peu importe la vitesse ou même le statut de la connexion avec le serveur MER. (Voir risque R5) Il n’y a aucune garantie qu’un CD puisse communiquer avec le serveur MER dans les délais nécessaires. (voir risque R4)

4. Analyse de scénarios Scenario : SSP5 : S’authentifier dans le système Attribut : Sécurité Environnement : Normal Stimuli : Quelqu’un tente d’utiliser les fonctionnalités du système. Réponse : La personne peut effectuer son travail, mais ne peut causer du tord au système.

4. Analyse de scénarios SSP5 : S’authentifier dans le système
Décision architecturale Risque Sensibilité Compromis Authentifier les utilisateurs S4 C4 Limiter l’accès des données Limiter les heures d’accès à une plage horaire R6 Raisonnement : Il y a certainement des données et fonctionnalités qui devraient être restreintes. L’authentification des utilisateurs est primordiale. Limiter les heures d’accès à une plage horaire peut causer des problèmes avec les heures supplémentaires sans pour autant augmenter la sécurité de façon significative.

4. Analyse de scénarios Risques Code Description R1
Si des serveurs InL locaux et une redondance passive est utilisée pour le MER, alors le serveur MER de secours risque d’être écrasé par les transactions en attente. R2 Le serveur MER existant risque de ne pas pouvoir répondre à la nouvelle demande venant des transactions InL. R3 Il est difficile de déterminer si deux serveurs concurrent aiderait à la vitesse des transactions. Risque d’être seulement du « Gold plating ». R4 Il n’y a aucune garantie qu’un centre de distribution puisse communiquer avec le serveur MER dans les délais nécessaires. On ne peut pas garantir qu’un futur centre de distribution a accès à une connexion assez rapide. R5 La priorisation des transactions n’aide que les transactions prioritaires, et ce, seulement s’il y a un problème de congestion. R6 Limiter les heures d’accès à une plage horaire peut causer d’énormes maux de têtes si les employés font souvent des heures de travail supplémentaires. Ceci pourrait baisser la satisfaction du client ou celui-ci risque de ne pas se servir de la fonctionnalité.

4. Analyse de scénarios Points sensibles Code Description S1
Il faudrait faire l’achat d’un serveur pour chaque centre de distribution. Avec la documentation actuelle, il n’est pas clair si celui-ci en a les moyens financiers. S2 Il faudrait faire l’achat d’un serveur MER supplémentaire. Avec la documentation actuelle, il n’est pas clair si celui-ci en a les moyens financiers. S3 Même si l’on peut vérifier les centres de distributions actuels, il n’est pas possible de s’assurer que de futurs CDs aient accès à une connexion rapide avec le serveur MER. Est-ce que le client serait prêt à accepter ce rique? S4 Les RF scanneurs utilisés par les employés des centres de distribution n’ont pas de clavier. Peut-on trouver une méthode d’authentification assez robuste et simple pour ces appareils?

4. Analyse de scénarios Compromis Code Description C1
L’implémentation d’un serveur local augmente la performance et la disponibilité, mais baisse drastiquement la simplicité. Il faut essentiellement préparer un module supplémentaire. C2 L’ajout d’un serveur MER de secours augmente la performance et la disponibilité, mais diminue la simplicité (il faut ajouter un système de réplication des données) et la maintenabilité des serveurs. C3 La priorisation des transactions augmente la performance de certaines transactions, mais baisse celle de d’autres transactions. C4 Les systèmes d’authentification augmente la sécurité, mais baisse l’utilisabilité. Par contre, ce compromis est presque universellement accepté.

Conclusion Des questions?

LOG430 – Architecture Logicielle

Présentations similaires

Présentation au sujet: "LOG430 – Architecture Logicielle"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

LOG430 – Architecture Logicielle

Présentations similaires

Présentation au sujet: "LOG430 – Architecture Logicielle"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back