Dégradation logicielle

Les étapes à suivre lors de la réalisation d'un projet

Pour comprendre l'importance de l'architecture, il est nécessaire de connaître les différentes étapes à suivre lors de la réalisation d'un projet. Tout projet est issu d'un besoin. Pour satisfaire les futurs utilisateurs, il est nécessaire d'étudier leurs besoins avant de développer une solution. Grâce à cela, il sera possible de définir une architecture logicielle adaptée afin d'obtenir un résultat proche de celui escompté. Avec une architecture bien définie, l'implémentation de la solution sera facilitée et correspondra mieux aux attentes du client s'il n'y a pas de divergences entre les deux.

L'architecture logicielle permet de réaliser entièrement le logiciel sous une forme théorique avant de le réaliser de manière pratique. Ceci permet de prévoir les contraintes techniques, d'envisager les évolutions de manière adaptée et de garantir la qualité du logiciel. Par conséquent, les coûts sont réduits et les logiciels sont sensiblement de meilleures qualités. L'architecture logicielle joue un rôle important dans les six aspects[2], ci-dessous, du développement logiciel :

• Elle simplifie notre capacité à comprendre les gros systèmes en les représentant par un niveau d'abstraction dans lequel une architecture de système haut niveau peut facilement être perçue.
• Elle favorise la réutilisation à multiples niveaux, des bibliothèques de composants aux framework.
• Elle permet la construction d'un plan pour le développement en indiquant les dépendances entre les différents composants.
• Elle facilite la mise en place des évolutions.
• Elle offre des nouvelles possibilités pour l'analyse telles que la vérification de la cohérence du système, la conformité des contraintes imposées par le style d'architecture, etc.
• Elle permet la bonne gestion de projets.

Pour faire la liaison entre l'architecture et l'implémentation, il est nécessaire de définir un ensemble de règles. Celles-ci permettront de détecter lorsque l'implémentation sera en train de dévier de l'architecture.

Il est possible de distinguer deux types de règles: les règles structurelles[3] et les règles d’interactions[4]. Les règles structurelles concernent l'existence des mêmes entités et les relations qui les unissent tandis que les règles d’interactions concernent essentiellement la présence des appels de méthode dans le même ordre.

Avec cet ensemble de règles[5], lors de l'analyse il y a trois types de résultats possibles :

• Convergence : La relation implémentée correspond à celle définie dans l'architecture.
• Divergence : La relation implémentée diffère de celle définie dans l'architecture.
• Absence : La relation est présente dans l'architecture mais n'est pas implémentée.

Il suffit maintenant de traiter chaque divergence et absence une par une. La pratique la plus courante est de modifier le code pour qu'il corresponde à l'architecture. Néanmoins, il est possible de devoir modifier l'architecture du projet à cause de difficultés techniques lors du développement.

Les principales causes[1] des dégradations logicielles sont les modifications apportées au code, à la documentation dans le non-respect des règles architecturales. Ces changements sont nécessaires pour suivantes raisons.

Pour faire face aux dégradations logicielles, il existe plusieurs solutions permettant de ralentir le vieillissement[7] mais également de garantir la qualité tout en essayant de garder un équilibre entre l'architecture et l'implémentation. Certaines technologies (citées plus bas) permettent de faire face aux dégradations. Cependant il existe des éléments pratiques à mettre en place pour conserver la qualité des logiciels.

Il existe des éléments pratiques, ci-dessous, permettant de garantir un équilibre entre l'architecture logicielle et son implémentation.

• Ne pas attendre la fin du développement avant d'effectuer des analyses de divergences entre l'architecture et le code car le refactoring sera plus complexe[11].
• Lors de la conception, prévoir une architecture décrivant le logiciel répondant aux besoins clients tout en laissant les possibilités de l'étendre; et lors de l'implémentation garder également ses possibilités tout en respectant les règles imposées par l'architecture.
• Maintenir la cohérence entre le code et la documentation.
• Trouver le bon compromis entre les stratégies d'efforts[12]: minimal et optimal.
• S'efforcer de modulariser.
• Élaborer des architectures claires et expressives.
• Prévoir des architectures correspondantes aux méthodologies utilisées.
• Réutiliser ce qui est réutilisable, si et seulement si cela répond aux besoins.
• Utiliser le concept PDCA[13](Plan, Do, Check, Act).

• (en) Philippe Kruchten, « Software architecture and agile software development: a clash of two cultures? », Software Engineering, 2010 ACM/IEEE 32nd International Conference on (Volume:2 ),‎ 2010, p. 497 - 498 (ISSN 0270-5257, DOI 10.1145/1810295.1810448)
• (en) David Garlan et Carnegie Mellon, « Software architecture: a roadmap », Proceedings of the Conference on The Future of Software Engineering,‎ 2000, p. 91 - 101 (ISBN 1-58113-253-0, DOI 10.1145/336512.336537)
• (en) Duszynski S., Knodel Jens et Lindvall M., « SAVE: Software Architecture Visualization and Evaluation », Software Maintenance and Reengineering, 2009. CSMR '09. 13th European Conference,‎ 2009, p. 323 - 324 (ISBN 978-0-7695-3589-0, ISSN 1534-5351, DOI 10.1109/CSMR.2009.52)
• (en) Knodel Jens, Muthig Dirk et Rost D., « Constructive architecture compliance checking — an experiment on support by live feedback », Software Maintenance, 2008. ICSM 2008. IEEE International Conference,‎ 2008, p. 287 - 296 (ISBN 978-1-4244-2614-0, ISSN 1063-6773, DOI 10.1109/ICSM.2008.4658077)
• (en) Knodel Jens, Muthig Dirk, Haury U. et Meier G., « Architecture Compliance Checking - Experiences from Successful Technology Transfer to Industry », Software Maintenance and Reengineering, 2008. CSMR 2008. 12th European Conference,‎ 2008, p. 43 - 52 (ISBN 978-1-4244-2157-2, ISSN 1534-5351, DOI 10.1109/CSMR.2008.4493299)
• (en) Allon Adir, Sigal Asaf, Laurent Fournier, Itai Jaeger et Ofer Peled, « A framework for the validation of processor architecture compliance », Proceedings of the 44th annual Design Automation Conference,‎ 2007, p. 902-905 (ISBN 978-1-59593-627-1, DOI 10.1145/1278480.1278702)
• (en) Baldassarre M.T., Bianchi A., Caivano D. et Visaggio C.A., « Full reuse maintenance process for reducing software degradation », Software Maintenance and Reengineering, 2003. Proceedings. Seventh European Conference,‎ 2003, p. 289 - 298 (ISBN 0-7695-1902-4, ISSN 1534-5351, DOI 10.1109/CSMR.2003.1192437)
• (en) Claire Dimech et Dharini Balasubramaniam, « Maintaining Architectural Conformance during Software Development: A Practical Approach », Software Architecture, vol. 7957,‎ 2013, p. 208-223 (ISBN 978-3-642-39030-2, DOI 10.1007/978-3-642-39031-9_19)
• (en) Jilles van Gurp et Jan Bosch, « Design erosion: problems and causes », Journal of Systems and Software, vol. 61,‎ 2002, p. 105-119 (DOI 10.1016/S0164-1212(01)00152-2)
• (en) David Lorge Parnas, « Software aging », Proceeding ICSE '94 Proceedings of the 16th international conference on Software engineering,‎ 1994, p. 279-287 (ISBN 0-8186-5855-X)
• (en) Sebastian Herold, « Checking architectural compliance in component-based systems », Proceedings of the 2010 ACM Symposium on Applied Computing,‎ 2010, p. 2244-2251 (ISBN 978-1-60558-639-7, DOI 10.1145/1774088.1774558)
• (en) Aldrich J., Chambers Craig et Notkin D., « ArchJava: connecting software architecture to implementation », Proceedings of the 24rd International Conference,‎ 2002, p. 187-197 (ISBN 1-58113-472-X)