LOG430 Architecture Logicielle Francis Meloche Charlebois -
MELF11048606 Yves Dubois - DUBY19077907 Marco Roy - ROYM02058709
Dominique Sarrazin - SARD16128505
Page 2
1. Pilotes commerciaux 1.1. Vision du systme
Page 3
1. Pilotes commerciaux 1.2. Principales fonctionnalits ID
unique TraabilitDescriptionPriorit F1IL-UC-01Grer 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 linformation des feuilles
de comptageH/H F5IL-EF-10PermissionsH/H
Page 4
1. Pilotes commerciaux 1.3. Principaux attributs de qualit ID
unique TraabilitDescriptionPriorit 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 rponse Le temps de
rponse doit tre de lordre de 2 secondes par transaction
dentreposage M/M AQ3IL-ENF-12 Temps de recherche dune marchandise
Les employs des oprations des CD doivent pouvoir trouver la
marchandise en 4 minutes en moyenne. H/H AQ4IL-ENF-13 Temps de
placement de la marchandise Les employs des CD doivent pouvoir
placer la marchandise en 8 minutes en moyenne. H/H AQ5 Annexe B,
IMP-01 Accs aux donnes scuris Permettre laccs et la modification
des donnes uniquement aux employs autoriss H/H
Page 5
1. Pilotes commerciaux 1.4. Principales contraintes de
conception ID unique TraabilitDescriptionPriorit CC1Annexe B, C1
Intgration MER Le logiciel InL doit tre intgr MER et utiliser la
mme base de donnes Oracle, version 10g. H/H CC2Annexe B, C5
Utiliser Oracle Forms/Reports La partie logicielle de InL doit tre
ralise laide de Oracle Forms/Reports 10g. M/M CC3Annexe B, C6 RF
Scanneur dvelopps 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 scurise sous SSL La connexion avec les
RF Scanneurs doit tre scurise en utilisant des sockets SSL afin
dempcher les intrusions et les fuites dinformation H/H
Page 6
1. Pilotes commerciaux 1.5. Parties prenantes Gestionnaire de
projet VP Finances Client Dveloppeur Testeur Architecte
Page 7
2. Architecture ( Vue #1 ) Vue Famille: Module Style: Utilise
Pilotes architecturaux rencontrs 1. F1: Grer les localisations 2.
F2: Entrer la marchandise dans une localisation (IN) 3. F3: Sortir
la marchandise dune localisation (OUT) 4. F5: Systme de permissions
5. AQ5: Accs aux donnes scuris 6. AQ6: Intgrit des
transactions
Page 8
2. Architecture ( Vue #1 )
Page 9
2. Architecture ( Vue #2 ) Vue Famille: C & C et Module
Style: Client / Serveur et dcomposition Pilotes architecturaux
rencontrs 1. F4: Scanner linformation des feuilles de comptage 2.
AQ3: Temps de recherche dune marchandise 3. AQ4: Temps de placement
de la marchandise
Page 10
2. Architecture ( Vue #2 )
Page 11
2. Architecture ( Vue #3 ) Vue Famille: Affectation Style:
Dploiement Pilotes architecturaux rencontrs 1. CC1: Intgration MER
2. CC2: Utiliser Oracle Forms/Reports 3. CC3: RF Scanneur dvelopp
en Java 4. AQ1: Horaires de disponibilit du systme 5. AQ2: Temps de
rponse de 2 secondes par transaction
Page 12
2. Architecture ( Vue #3 ) Vue affectation: (1)
Page 13
3. Approches architecturales Arbre dutilit (cinq scnarios)
AttributRaffinementScnario DisponibilitFiabilitSSP10 - Reprise
rapide de service Plage de disponibilit SSP1 - Effectuer une
transaction dans une plage horaire PerformanceFacteur temps SSP2 -
Effectuer une transaction dans un dlai UtilisabilitEfficience SSP3
- Effectuer une recherche de marchandise SSP4 - Effectuer un
placement de marchandise
Page 14
3. Approches architecturales Cinq tactiques Redondance Active
Enregistrer les oprations Maintenir des copies Utiliser des
services distants Limiter laccs aux oprations
Page 15
3. Approches architecturales Cinq styles architecturaux :
Utilise Utiliser des permissions Utiliser un buffer dentr/sortie
Utiliser un base de donnes
Page 16
3. Approches architecturales Cinq styles architecturaux:
Utilise
Page 17
3. Approches architecturales Cinq styles architecturaux:
Dcomposition Sparer les services Sparer les donnes
Page 18
3. Approches architecturales Cinq styles architecturaux:
Dcomposition
Page 19
3. Approches architecturales Cinq styles architecturaux:
Client/Serveur Utiliser un protocole Utiliser de la
cryptographie
Page 20
3. Approches architecturales Cinq styles architecturaux:
Client/Serveur
Page 21
3. Approches architecturales Cinq styles architecturaux:
Dploiement Utiliser un serveur de backup Maintenir une copie des
donnes Utiliser un WAN (Internet)
Page 22
3. Approches architecturales Cinq styles architecturaux:
Dploiement
Page 23
3. Approches architecturales Cinq styles architecturaux: Donnes
Partages Utiliser un rseau Wifi Permettre plusieurs clients
Page 24
3. Approches architecturales Cinq styles architecturaux: Donnes
Partages
Page 25
4. Analyse de scnarios Scenario : SSP1 : Effectuer une
transaction dans une plage horaire Attribut : Disponibilit
Environnement : Normal Stimuli : Un employ effectue une transaction
dentreposage entre 7h00 et 23h00, du dimanche au vendredi. Rponse :
La transaction est enregistre correctement dans le systme. Le
systme est oprationnel dans la plage horaire spcifie, i.e. de 7h00
23h00, du dimanche au vendredi.
Page 26
4. Analyse de scnarios SSP1 : Effectuer une transaction dans
une plage horaire Dcision architecturaleRisqueSensibilitCompromis
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 quun scnario (voir SSP2). La perte dun
serveur local naffecte quun centre de distribution. (vite le single
point of failure ) Permet de limiter le nombre le nombre de requtes
qui vont au serveur MER en servant de cache pour les donnes
locales. Serveur MER de secours (redondance active) Permet de
sassurer que les transactions venant des serveurs InL locaux sont
toujours reues. (Voir risque R2) Permet au systme de fonctionner en
cas de panne du serveur principal sans aide externe. Certaines
requtes (lecture de donnes) pourraient tre divises entre les deux
serveurs. (Un bonus, pourrait aider avec le scnario SSP2)
Page 27
4. Analyse de scnarios SSP2 : Effectuer une transaction dans un
dlai Attribut : Performance Environnement : Normal Stimuli : Un
employ effectue une transaction dentreposage. Rponse : La
transaction est enregistre correctement dans le systme. Le temps de
rponse du systme est de lordre de 2 secondes par transaction.
Page 28
4. Analyse de scnarios SSP2 : Effectuer une transaction dans un
dlai Dcision architecturaleRisqueSensibilitCompromis 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 quun scnario (voir SSP1).
Permet presque assurment de satisfaire lexigence, peu importe la
vitesse ou mme le statut de la connexion avec le serveur MER. (Voir
risque R5) Il ny a aucune garantie quun CD puisse communiquer avec
le serveur MER dans les dlais ncessaires. (voir risque R4)
Page 29
4. Analyse de scnarios Scenario : SSP5 : Sauthentifier dans le
systme Attribut : Scurit Environnement : Normal Stimuli : Quelquun
tente dutiliser les fonctionnalits du systme. Rponse : La personne
peut effectuer son travail, mais ne peut causer du tord au
systme.
Page 30
4. Analyse de scnarios SSP5 : Sauthentifier dans le systme
Dcision architecturaleRisqueSensibilitCompromis Authentifier les
utilisateursS4C4 Limiter laccs des donnesC4 Limiter les heures
daccs une plage horaireR6 Raisonnement : Il y a certainement des
donnes et fonctionnalits qui devraient tre restreintes.
Lauthentification des utilisateurs est primordiale. Limiter les
heures daccs une plage horaire peut causer des problmes avec les
heures supplmentaires sans pour autant augmenter la scurit de faon
significative.
Page 31
4. Analyse de scnarios Risques CodeDescription R1 Si des
serveurs InL locaux et une redondance passive est utilise pour le
MER, alors le serveur MER de secours risque dtre cras par les
transactions en attente. R2 Le serveur MER existant risque de ne
pas pouvoir rpondre la nouvelle demande venant des transactions
InL. R3 Il est difficile de dterminer si deux serveurs concurrent
aiderait la vitesse des transactions. Risque dtre seulement du Gold
plating . R4 Il ny a aucune garantie quun centre de distribution
puisse communiquer avec le serveur MER dans les dlais ncessaires.
On ne peut pas garantir quun futur centre de distribution a accs
une connexion assez rapide. R5 La priorisation des transactions
naide que les transactions prioritaires, et ce, seulement sil y a
un problme de congestion. R6 Limiter les heures daccs une plage
horaire peut causer dnormes maux de ttes si les employs font
souvent des heures de travail supplmentaires. Ceci pourrait baisser
la satisfaction du client ou celui-ci risque de ne pas se servir de
la fonctionnalit.
Page 32
4. Analyse de scnarios Points sensibles CodeDescription S1 Il
faudrait faire lachat dun serveur pour chaque centre de
distribution. Avec la documentation actuelle, il nest pas clair si
celui-ci en a les moyens financiers. S2 Il faudrait faire lachat
dun serveur MER supplmentaire. Avec la documentation actuelle, il
nest pas clair si celui-ci en a les moyens financiers. S3 Mme si
lon peut vrifier les centres de distributions actuels, il nest pas
possible de sassurer que de futurs CDs aient accs une connexion
rapide avec le serveur MER. Est-ce que le client serait prt
accepter ce rique? S4 Les RF scanneurs utiliss par les employs des
centres de distribution nont pas de clavier. Peut-on trouver une
mthode dauthentification assez robuste et simple pour ces
appareils?
Page 33
4. Analyse de scnarios Compromis CodeDescription C1
Limplmentation dun serveur local augmente la performance et la
disponibilit, mais baisse drastiquement la simplicit. Il faut
essentiellement prparer un module supplmentaire. C2 Lajout dun
serveur MER de secours augmente la performance et la disponibilit,
mais diminue la simplicit (il faut ajouter un systme de rplication
des donnes) et la maintenabilit des serveurs. C3 La priorisation
des transactions augmente la performance de certaines transactions,
mais baisse celle de dautres transactions. C4 Les systmes
dauthentification augmente la scurit, mais baisse lutilisabilit.
Par contre, ce compromis est presque universellement accept.
