Quentend-on par système évolutif? Quelles techniques peuvent être utilisées pour parvenir à lévolutivité?

Meilleure réponse

Évolutif signifie que le système peut, avec une relative facilité, être adapté à une base dutilisateurs plus large que prévu initialement ou initialement . Les facteurs qui déterminent l’évolutivité d’une application incluent:

• une bonne structure de programme (la facilité avec laquelle le programme est compris et étendu pour prendre en charge de nouveaux rôles)
• utilisateurs multiples et accès et édition simultanés à la base de données (pour éviter le verrouillage de la base de données, le refus daccès, la corruption ou la perte de données)
• dispositions de sécurité pour laccès des utilisateurs et lintégrité de la base de données
• capacité à fonctionner en tant que application distribuée sur plusieurs serveurs et bases de données sur plusieurs fuseaux horaires
• sauvegarde, correction et restauration de bases de données
• dispositions linguistiques et culturelles
• fourniture dune intercommunication avec des tiers applications soit en exposant une interface de programme bien gérée, soit en souscrivant aux normes de lindustrie
• utilisation des ressources et dépendances du matériel / système dexploitation
• performances en temps réel

Il existe dautres facteurs, dépendant de domaines dactivité spécifiques, mais ce sont les facteurs que nous voyons régulièrement devenir un i ssue lorsquune entreprise essaie de «mettre à léchelle» ou «détendre» ses applications.

Lévolutivité souffre généralement lorsque / ou:

• le programme est conçu et écrit par quelquun qui nest pas qualifiés dans les disciplines du développement dapplications
• la responsabilité de lécriture dun programme est sous-traitée avec une spécification qui nexplore pas tous les facteurs appropriés aux besoins futurs des clients (une spécification faible conduit souvent à des solutions non évolutives )
• il ny a pas de supervision par un ingénieur logiciel qualifié qui comprend le domaine métier

Un exemple simple déchec de mise à léchelle est un programme dinventaire dentrepôt sur lequel jai travaillé en 1990 (ish).

Le programme original a été écrit pour un utilisateur, un serveur et des sauvegardes nocturnes (pendant lesquelles le système était indisponible). Dans un ordre successif, le client souhaitait:

• augmenter le nombre dutilisateurs de 1 à 50+ et appliquer divers rôles et privilèges daccès pour chaque utilisateur.
• étendre lapplication pour prendre en charge plusieurs entrepôts dans le même pays
• étendre lapplication pour prendre en compte les nouveaux entrepôts offshore qui impliquaient la prise en charge de plusieurs fuseaux horaires, langues, normes juridiques et procédures dexploitation

Le programme original navait jamais été structuré pour une telle exigence de mise à léchelle. La base de données a souffert de fréquents verrouillages «mortels», de pertes de données et de temps darrêt inacceptables dus aux procédures de sauvegarde de la base de données. Lapplication ne prévoyait pas de saisie de données «hors ligne» et, bien entendu, nétait pas écrite pour tolérer les problèmes de communication. Essayer de mettre à jour le programme sest également avéré être un cauchemar – en gros, tout leur système sest arrêté pendant les plusieurs heures quil a fallu pour installer une mise à jour globale.

Avant dêtre appelés, en tant que consultants, le programme a été «patché» par le codeur original (au singulier) qui avait par la suite quitté et disparu par la suite.

Le patch a obscurci la structure et la fonctionnalité du code – cependant je doute que le programme ait jamais été correctement structuré ou documenté – personne nen savait assez pour réaliser le risque que cela représentait pour lentreprise! Le code a été écrit en C ++ et a utilisé des tableaux doctets au lieu de chaînes de jeu de caractères multi-octets (MBCS) standard de lindustrie … vous voyez lidée générale!

Nous avons été appelés pour «corriger» le problèmes. La vérité est quil aurait été plus simple et moins coûteux de faire passer le client à un produit de gestion des stocks commerciaux, mais ils avaient une modélisation financière profondément intégrée dans le système et personne ne comprenait assez bien comment cela fonctionnait pour transférer ces fonctionnalités à une publicité. programme (au moins sans risque significatif).

En fin de compte, malgré les solutions les plus rentables, nous avons dû effectuer une rétro-ingénierie du produit et réécrire complètement lapplication. Il a fallu 2 concepteurs système, 4 ingénieurs principaux, 20 ingénieurs logiciels, 5 ingénieurs de validation et 2 ingénieurs outils / méthodologie pour réécrire le produit – et près de 2 ans de temps écoulé pour mettre lapplication en version générale.

Donc comment parvenir à lévolutivité?

1. Commencez par vous assurer que vous avez écrit vos exigences dévolutivité dans la spécification du produit. En général, les contraintes de temps et les coûts les plus bas entraîneront des sacrifices dans des domaines qui nétaient pas correctement mandatés dans la spécification.
2. Travaillez avec des experts du domaine qui peuvent vous aider à développer une structure qui répondra aux besoins futurs (probables).
3. Profitez de modèles de conception, de bibliothèques, dapplications 4GL / AI et darchitectures qui ont été formulés à partir de zéro pour éviter les problèmes dévolutivité (dont beaucoup ont été développés à partir dexpériences amères).
4. Renseignez-vous sur tous les domaines clés tels que les bases de données distribuées et tolérantes aux pannes pour les applications hautement simultanées, les architectures de sécurité intégrées, la réplication de bases de données, le traitement dans le cloud, etc.
5. Assurez-vous demployer ingénieurs chevronnés et expérimentés occupant des postes clés. Je dirais que près de 50\% des projets de sauvetage que nous avons entrepris étaient la conséquence dingénieurs en chef et de concepteurs de systèmes inexpérimentés. Le reste était dû à des échecs de gestion ou à des communications inappropriées entre lingénierie et le client.

Alors voilà. De nos jours, il ny a vraiment aucune excuse pour les problèmes dévolutivité dans les entreprises de taille moyenne à grande, mais de nombreuses entreprises commencent avec une poignée de personnes qui piratent les solutions du mieux quelles peuvent. Ensuite, lentreprise grandit et lévolutivité devient un cauchemar plutôt que la progression ordonnée quelle devrait être!

Réponse

Lévolutivité en génie logiciel se réfère, normalement, à la conception de systèmes logiciels de telle manière que , à mesure que le nombre dutilisateurs du système augmente (même par des facteurs de 100x ou plus), le logiciel continuera à fonctionner avec des temps de réponse comparables. Maintenant, la question suivante est «comment cela est-il accompli?».

Les logiciels de bureau autonomes (par exemple, les jeux) sont toujours 100\% évolutifs car chaque utilisateur dispose de son propre ordinateur. Il s’agit d’une forme simple d’évolutivité.

Les systèmes logiciels client-serveur et Web dépendent toutefois des serveurs , qui sont des ordinateurs qui fournissent des services à plusieurs utilisateurs. Il devrait être évident quun serveur donné ne peut gérer quun nombre limité dutilisateurs simultanés.

Il existe deux techniques générales qui permettent à un système dévoluer au-delà de ce quun seul serveur peut gérer. Les systèmes hautement évolutifs combineront les deux techniques.

La première consiste à diviser la fonctionnalité en différentes parties. Une division courante consiste à avoir un serveur séparé pour héberger la base de données sur laquelle le système sappuie (il existe presque toujours une sorte de base de données pour contenir des informations persistantes). Le serveur de base de données dispose dune grande quantité de mémoire et de disques ou matrices RAID très rapides tandis que lautre type de serveur nécessite moins de mémoire et relativement peu despace disque.

Cela peut être étendu à une architecture à n niveaux, où de plus en plus de fonctionnalités (et de données, pour les bases de données) sont réparties entre différents processus. Lorsque la charge augmente, les processus sont migrés vers des serveurs distincts pour maintenir les performances. Notez que tous ces serveurs sont physiquement dans la même batterie de serveurs et sont connectés par des connexions réseau à très haut débit.

Lautre technique utilisée pour lévolutivité est la réplication . Cela signifie que, par exemple, plusieurs serveurs Web sont utilisés et que chaque utilisateur nest connecté quà lun dentre eux. Pour prendre en charge plus dutilisateurs, le système a juste besoin de plus de matériel (systèmes de serveur Web dans cet exemple). Les bases de données sont également capables de réplication, de sorte que plusieurs serveurs de bases de données peuvent prendre en charge les clones de la base de données (il est parfois difficile de garder les différentes copies de la base de données à jour mais les dba traitent ce problème depuis des années). Pour les systèmes plus volumineux, il existe des bases de données conçues pour être évolutives, distribuant leurs données sur plusieurs serveurs.

A2A: «Quentend-on par« évolutivité »en génie logiciel?»