La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

LOG430 – Architecture Logicielle Francis Meloche Charlebois - MELF11048606 Yves Dubois - DUBY19077907 Marco Roy - ROYM02058709 Dominique Sarrazin - SARD16128505.

Présentations similaires


Présentation au sujet: "LOG430 – Architecture Logicielle Francis Meloche Charlebois - MELF11048606 Yves Dubois - DUBY19077907 Marco Roy - ROYM02058709 Dominique Sarrazin - SARD16128505."— Transcription de la présentation:

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

2 1. Pilotes commerciaux 1.1. Vision du système

3 1. Pilotes commerciaux 1.2. Principales fonctionnalités ID unique TraçabilitéDescriptionPriorité F1IL-UC-01Gérer les localisationsH/H F2IL-UC-08Entrer la marchandise dans une localisation (IN)H/H F3IL-UC-09Sortir la marchandise de la localisation (OUT)H/H F4IL-UC-21Scanner l’information des feuilles de comptageH/H F5IL-EF-10PermissionsH/H

4 1. Pilotes commerciaux 1.3. Principaux attributs de qualité ID unique TraçabilitéDescriptionPriorité AQ1IL-ENF-03 Horaires de disponibilité Le logiciel doit être disponible entre 7h00 et 23h00 de dimanche au vendredi. H/H AQ2IL-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 AQ3IL-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. H/H AQ4IL-ENF-13 Temps de placement de la marchandise Les employés des CD doivent pouvoir placer la marchandise en 8 minutes en moyenne. H/H 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 H/H

5 1. Pilotes commerciaux 1.4. Principales contraintes de conception ID unique TraçabilitéDescriptionPriorité CC1Annexe 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 CC2Annexe 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 CC3Annexe B, C6 RF Scanneur développés en Java La partie logicielle des RF Scanneurs doit être codé en Java. H/H CC4Annexe B, C8 Standard de code à bars Le standard de code à barres 128 doit être respecté. H/H CC5Annexe 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 H/H

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

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

8 2. Architecture ( Vue #1 )

9 2. Architecture ( Vue #2 ) Vue Famille: C & C et Module Style: Client / Serveur et décomposition Pilotes architecturaux rencontrés 1. F4: Scanner l’information des feuilles de comptage 2. AQ3: Temps de recherche d’une marchandise 3. AQ4: Temps de placement de la marchandise

10 2. Architecture ( Vue #2 )

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

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

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

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

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

16 3. Approches architecturales Cinq styles architecturaux: Utilise

17 3. Approches architecturales Cinq styles architecturaux: Décomposition Séparer les services Séparer les données

18 3. Approches architecturales Cinq styles architecturaux: Décomposition

19 3. Approches architecturales Cinq styles architecturaux: Client/Serveur Utiliser un protocole Utiliser de la cryptographie

20 3. Approches architecturales Cinq styles architecturaux: Client/Serveur

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

22 3. Approches architecturales Cinq styles architecturaux: Déploiement

23 3. Approches architecturales Cinq styles architecturaux: Données Partagées Utiliser un réseau Wifi Permettre plusieurs clients

24 3. Approches architecturales Cinq styles architecturaux: Données Partagées

25 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.

26 4. Analyse de scénarios SSP1 : Effectuer une transaction dans une plage horaire Décision architecturaleRisqueSensibilitéCompromis Serveur InL localR1S1C1 Serveur MER de secours (redondance active)S2C2 Serveur MER de secours (redondance passive)R1S2C2 Utiliser le serveur MER existantR2 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)

27 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.

28 4. Analyse de scénarios SSP2 : Effectuer une transaction dans un délai Décision architecturaleRisqueSensibilitéCompromis Serveur InL localS1C1 Serveur MER concurrent (redondance active)R3S2C2 Utiliser la connexion actuelleR4 Assurer une vitesse de transmission rapide entre les CDs et le serveur MER S3 Prioriser les transactionsR5C3 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)

29 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.

30 4. Analyse de scénarios SSP5 : S’authentifier dans le système Décision architecturaleRisqueSensibilitéCompromis Authentifier les utilisateursS4C4 Limiter l’accès des donnéesC4 Limiter les heures d’accès à une plage horaireR6 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.

31 4. Analyse de scénarios Risques CodeDescription 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é.

32 4. Analyse de scénarios Points sensibles CodeDescription 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?

33 4. Analyse de scénarios Compromis CodeDescription 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é.

34 Conclusion Des questions?


Télécharger ppt "LOG430 – Architecture Logicielle Francis Meloche Charlebois - MELF11048606 Yves Dubois - DUBY19077907 Marco Roy - ROYM02058709 Dominique Sarrazin - SARD16128505."

Présentations similaires


Annonces Google