Utiliser des BlockChains dans vos applications WINDEV 23

https://www.youtube.com/watch?v=crVELl8VCJw

Blockchain : Comment ça marche ?

https://www.youtube.com/watch?v=SccvFbyDaUI

说了半天，区块链到底解决了什么问题？

https://www.jutuilian.com/article-36798-1.html

区块链解决的是“信任”问题 为什么现在介绍区块链的文章很多，但很多人仍觉得一头雾水？因为这些文章都太注重技术细节的描述，即便语言再白话、内容再通俗，对99%的普通人而言，意义都不大。 刷朋友圈的大爷大妈，并不需要懂TCP/IP协议，扫码买鸡蛋灌饼的上班族，也无需了解移动支付原理。复杂的底层技术从来就不是普通人应该关心的方面。 那区块链到底有什么用呢？如果说互联网技术主要解决了通讯问题，那么区块链技术主要解决的就是信任问题。 听到这你肯定还是一头雾水，我们举个栗子。 最近世界杯激战火热，本周六有场重头戏，1/8决赛，法国VS阿根廷。小金说法国一定赢，老金说阿根廷一定赢。为了表明各自的决心，小金翻箱倒柜找出仅有的20元，做了押注，老金也豁出去了，从媳妇口袋里偷了20元进行押注。但是双方都怀疑对方赌品不好，担心赖账，于是他们请来一位公证人，将40元交他保管，谁赢了这钱就归谁。 结果，比赛当晚，公证人携40元巨款出逃...... WTF...人和人最基本的信任哪去了？？？ 解决信任的方式之一：智能合约 如果结合区块链技术，小金和老金就可以保住这40元巨款，解决方案是利用”智能合约“来实现公平竞彩。 俩人先把各自的20元钱打到一个”智能合约“的账户里，这个合约不被任何人控制，只会被合约的代码控制。在写好“智能合约”的代码之后，把代码放到一个区块链上去运行，等比赛结果出来之后，代码自动执行，谁也赖不了账，谁也无法卷款。老金和小金无需互相相信，凭借区块链技术的去中心属性就能解决信任为题。 智能合约是区块链的典型应用，代表技术是以太坊（Ethereum）。 简单来说，我们可以将合同以可编程的代码形式，放到区块链上，由代码自动生效、执行和结束，这个过程不需要任何的组织和个人来监督执行、不需要事前审查和高昂的预付成本，任何人都可以使用这种方式参与到经济活动中，这就是所谓的智能合约。 智能合约的运用日趋广泛，比如在国际贸易活动中，“信用证”一般由银行开具，银行充当的是可信第三方的角色。而如今，大量的国际信用证开始使用区块链技术来做。 解决信任的方式之二、支付与结算 区块链技术问世之前，任何交易活动都需要有一个中介，否则，一群不存在信任关系的陌生人，根本无法达成交易。但是这种中介中心化的交易，存在交易成本高、系统不稳定、技术漏洞、道德风险等问题。 而区块链就是信任的机器，可以用代码取代信任中介的作用，基于算法使陌生人在不借助于第三方的情况下，完成交易。简单来说，这相当于我的支付与结算，通过的不是银行等中心机构，而是基于全球分布式账本、全网记账的区块链。 目前，已经有专门的区块链技术运用在支付与结算领域，最有代表性的就是瑞波（Ripple）区块链。 瑞波是目前区块链金融应用中，比较成功的应用之一，它基于一个开放、中性协议构建，支持全球不同分类账本和网络之间即时、低成本的国际支付。 很多银行也在利用瑞波的技术做国际付款，比如西班牙到墨西哥、加拿大到德国，转账的时间大约在20秒。而渣打银行用瑞波区块链进行的跨境转账耗时只有10秒钟。2017年年初，瑞波新开发了新的支付通道，使得瑞波币的交易吞吐量增加到每秒数万笔级别，理论上达到了Visa的级别。 截至2017年9月全球排名前50的银行中，已有15家与瑞波合作。 最后归纳一句话：要解决信任问题，最直接的办法恰恰是谁都不信。 以上部分内容素材整理自知乎“匿名用户”。 本文仅代表作者个人观点，不代表巨推链平台发声，对文章观点有疑义请先联系作者本人进行修改，若内容非法请联系平台管理员，邮箱cxb5918@163.com。更多区块链资讯，请到百万区块链发烧友聚集平台巨推链www.jutuilian.com学习区块链技术请到巨推学院www.jutuiedu.com

Developing blockchain applications

https://hyperledger.github.io/composer/v0.16/installing/development-tools.html

PowerBI

PowerBI est une suite d'outils d'analyse offrant des fonctionnalités de traitement et de représentation de données.
La version Desktop est gratuite et téléchargeable depuis le site de microsoft.
PowerBI transforme les données de votre entreprise en visuels de pilotage et d'aide à la décision et aide les organisations à mieux gérer les flux d'informations en interne et en externe.

程序员如何做到每天 17:00 准时下班？

原创： Turner-Trauring CSDN 3天前

https://mp.weixin.qq.com/s?__biz=MjM5MjAwODM4MA%3D%3D&mid=2650699574&idx=1&sn=d9a05655cbd0d1b09b7f4934695b5cf5&scene=45#wechat_redirect

你想每周只工作40个小时，每天5点钟准时回家。但是一个Bug绊住了你，必须改好，所以你需要稍微加一会儿班。结果一抬头发现已经6点了。

不久之后，你每周工作50个小时，然后每周60个小时，如果停止加班就会影响到你的产出，那么你的经理就会找你谈话，说你需要付出更多努力。所以，你的负担越来越重，你不知道该怎么办。

但是如果你的效率更高呢？如果你知道如何在公司时间内做好所有的工作，然后用自己的时间做想做的事情呢？

事实上，只需要一点时间管理，你就可以做到这一点。

▌一些警告

在介绍真正的技巧之前，我需要先交代一些事宜。

首先，只有当你的经理只注重结果（而不是待在办公室的时间长短）时，这些技巧才会管用。请记住很多经理虽然说希望你每周工作50个小时，但实际上如果你能在40个小时内做好所有工作的话，他们会很高兴。而且我假设你们公司没有处在长期危机的状态——如果这些假设不成立，那么时间管理也帮不了你，考虑找份新工作吧。

其次，这些技巧可以帮助你管理日常的时间。如果产出下降，那么你可能需要加班（重申：如果每周产出持续下降，那么考虑找份新工作吧）。

最后，为了简单起见，我假设你每天早上9点上班，5点下班。如果你的上班时间比较晚的话，请相应地调整时间。

▌我的时间我做主

既然你的问题时间在不知不觉中悄然流逝了，那么解决方案是严格限制开始新工作的时间，同时分配一些时间做计划，以便将来的工作更有效率。

下面是一张简短的时间表，可以帮助你在更短时间内完成更多工作：

在开始工作的时候，阅读前一天留下来的检查点（稍后我会对此作解释）。

到下午3点半前，正常工作。

下午3点半后，继续做正在做的已有任务。如果你完成了已有的任务，那么除非某个新任务可以在15分钟内完成，否则不要开始新任务。如果没有合适的任务，那么应该利用这点时间计划以后的工作。

下午4点45分，停止手头的工作，设置工作的检查点。

下午5点准时回家。

让我们深入解释一下，为什么这么做会对你有帮助。

▌一天的结束即为第二天的开始：检查点

在一天的最后15分钟内，停止手头的工作，设置工作的检查点。也就是说，记下第二天早上迅速展开工作时所需要知道的一切。

例如，如果你正在做某个任务，那么可以在代码中加入“XXX”的注释，并记录下你打算做的下一个改动。如果你正在做计划，那么你可以给自己分配一个任务，并尽可能地写下你的实现方法。

这样做有两个好处：

• 第二天早上上班时，甚至在周末或假期后，你可以在很短的时间内进入工作状态，并回忆起你的工作进度。而且，你的笔记可以清楚地告诉你下一步的工作。
• 通过规划第二天的工作，可以让你的大脑在潜意识中进入解决问题的状态，而你可以尽情享受休息时间。很有可能早上一觉醒来，你就已经找到了难题的解决方案，或者在淋浴的时候灵机一动。如果你想了解更多这方面的信息，请参阅Rich Hickey关于吊床驱动开发模式（Hammock Driven-Development）的演讲。

▌3点半以后不要开始新的大任务

到下午的时候，你已经工作好几个小时了，而你的大脑也开始疲倦。如果你正在做一项任务，那么可以继续做完，但是如果你做完了一项任务，那么不应该在一天即将结束之际再开始新的大任务。第二天早上再做会更好，因为到时你不那么疲倦，而且有更长的时间来做好任务。

那么这段时间应该做什么呢？你可以专心做小任务，例如审核代码等。

• 打开模糊的任务，并写下细节和子任务；
• 调查可能的解决方案；
• 研究新技术；
• 想法弄明白反复重现的问题的原因；
• 从大局出发，想想你的工作状况。

从长远看来，计划可以让你的实现工作加快速度。而将计划限制在一天中的一个时间段内，可以确保你不会在计划上花费所有时间。

▌5点钟准时回家

5点以后，多加几分钟班做完手头的工作无可厚非。问题是时间在不知不觉中悄然流逝了，对你来说这是个问题。严格规定下班时间可以迫使你不要加班到6点或7点。

另外，有时不仅仅是几分钟，有时你需要的不仅仅是解决问题的时间。晚上花两个小时才能做完的任务，如果放到第二天早上等你休息好以后再做，那么可能只需要10分钟。

从长远看来，避免长时间工作，会更有效率。

▌总结

我们总结一下你应该如何规划一天的工作时间：

• 早上9点到下午3点半：首先阅读前一天留下来的检查笔记，以便你能立即开始工作，然后正常工作；
• 下午3点半到4点45分：继续手头的任务，如果做完了就开始做小任务和计划；
• 下午4点45到5点：为工作设置检查点，然后离开办公室；
• 下午5点以后：做自己想做的事情。

当然这套特殊的规则并没有神奇的魔力。你可以根据自己的需要和情况，调整这个计划。

尽管如此，既然你面临时间在不知不觉中流逝的问题，那么我建议你遵循这个特殊的规则，只需要几周你会感受到这么做的好处。在管理好自己的时间之后，你可以修改规则以更好地适应自己的需求。

链接：https://codewithoutrules.com/2018/06/15/avoid-hour-creep/

作者：Itamar Turner-Trauring

译者：弯月

Big Data

http://baijiahao.baidu.com/s?id=1601158038450756367&wfr=spider&for=pc

Microsoft Azure

https://fr.wikipedia.org/wiki/Microsoft_Azure

Dématérialisation

Factur-X

https://communaute.chorus-pro.gouv.fr/factur-x-un-nouveau-standard-de-facture-dematerialisee/

Échange de données informatisées pour l'administration, le commerce et le transport

https://fr.wikipedia.org/wiki/%C3%89change_de_donn%C3%A9es_informatis%C3%A9es_pour_l%27administration,_le_commerce_et_le_transport

代码重构

https://zh.wikipedia.org/wiki/%E4%BB%A3%E7%A0%81%E9%87%8D%E6%9E%84

Réingénierie logicielle

https://fr.wikipedia.org/wiki/R%C3%A9ing%C3%A9nierie_logicielle

La réingénierie logicielle (RL) ou Software reengineering est un processus qui a pour objectif la transformation et l’amélioration d’un logiciel à partir du modèle existant. Le logiciel en question ne doit pas subir de régression au niveau fonctionnel mais doit gagner en performance et en évolutivité. L’obsolescence logicielle est rapide dans un secteur en évolution permanente et augmente le coût de la maintenance. Il y a pénurie des compétences pour ce qui concerne les plus vieux logiciels. Ces anciennes applications ne sont pas adaptées au changement de technologie et perdent de ce fait de leur performance.
La réingénierie logicielle se fait en plusieurs étapes successives.
La première est la rétroingénierie, processus qui permet l’analyse d’un programme afin d’identifier ses composants et leurs interrelations. Cette étape inclut la recherche de la documentation pour améliorer la compréhension du logiciel. Cette phase d’inventaire est utile à la création d’une représentation du logiciel sous une autre forme ou à un niveau d’abstraction plus élevé. Elle permet de reconnaitre les éléments à conserver de ceux qui doivent être écartés ou remodélisés.
La seconde est le processus d’ingénierie de reconstruction. Ce processus englobe des sous domaines très utilisés que sont la re-documentation, la restructuration du code et des données et la recomposition du logiciel. Elle se termine par un ensemble de tests pour valider la nouvelle solution et permettre sa standardisation.
Cette réorganisation logicielle comporte de multiples risques comme l’implication humaine, l’existence ou non d’une documentation, la complexité logicielle, sa durée ou le couple performance – évolutivité. Il convient de mesurer au plus près ce danger avant de commencer la réingénierie logicielle.

Cadre de la réingénierie logicielle (RL)

Définitions de la réingénierie logicielle

Les différentes phases de la réingénierie logicielle

La réingénierie logicielle est l'étude et la modification d'un système logiciel en vue de le recréer sous une nouvelle forme. Elle n'altère pas obligatoirement les fonctionnalités du logiciel mais elle peut éventuellement en créer de nouvelles. Elle se nomme aussi « rénovation logicielle » voir « réhabilitation logicielle »¹.
Le SWEBOK, document de base à la normalisation en ingénierie du logiciel, la définit comme suit² : « c'est l'analyse et la transformation d'un logiciel en vue de le recréer sous une nouvelle forme en incluant l'implémentation de cette nouvelle forme »^{note 1}.
La norme ISO/IEC/IEEE 24765:2010(E) Ingénierie des systèmes et du logiciel — Vocabulaire, de l'IEEE, définit aussi la réingénierie logicielle³. Ce document regroupe les termes couramment utilisés dans les technologies de l'information et en donne une définition comme étant : le cycle complet de l'exécution de la Rétroingénierie et de la reconstruction logicielle^{note 2}.
La réingénierie logicielle est plus globalement un processus qui assure la transformation d'un logiciel. Elle enchaîne d'autres processus plus basiques dont elle utilise les outils associés. Elle les organise et les enchaîne séquentiellement. Les deux processus basiques les plus rencontrés sont la Rétroingénierie et la reconstruction logicielle⁴.

Domaines d’application

La réingénierie logicielle fait partie du domaine de la maintenance logicielle⁵. C'est un processus de transformation utilisé pour l'analyse des besoins (définition des spécifications des problèmes, des objectifs, des contraintes...), le design (spécification des solutions) et l’implémentation logicielle (codage, réécriture, tests ...) ⁶. Mais un logiciel n'est pas seulement du code sur lequel la réflexion et l'intervention va porter. C'est aussi de la documentation, des représentations graphiques se rapportant au cahier des charges (aux spécifications), des données de tests, de validation et tout un ensemble de documentations et d'informations qui composent le logiciel lui-même et lui donne du corps⁷.
En s’appliquant au logiciel, la réingénierie logicielle s’applique aussi à tout son environnement. Elle assure non seulement la maintenabilité et l'évolutivité technique, mais aussi la création ou la mise à jour complète et illustrée de la documentation⁸. Souvent négligée, la documentation est très importante pour la réingénierie logicielle. Elle améliore la connaissance du logiciel, de ses fonctions et ainsi une meilleure compréhension de son code. C'est un véritable défi que d'assurer une réingénierie logicielle avec une documentation fréquemment obsolète, incomplète, voire indisponible⁸.

Différents acteurs

Trois groupes principaux d'acteurs sont identifiés. Leur engagement dans le processus de la réingénierie logicielle est essentiel⁹.

L'équipe experte de la réingénierie logicielle

Elle représente le cœur du projet. Elle se compose principalement d'intervenants comme le pilote de projet informatique, l'analyste, l'Architecte informatique, le développeur, le spécialiste en sécurité, l'administrateur système, l'administrateur de base de données, l'intégrateur d'application.

Mais de nouveaux métiers avec de nouveaux noms voient le jour. Les architectes Service Orienté Architecture, les concepteurs de modèle, les concepteurs de service, les concepteurs de processus, les développeur de service, les spécialistes d'intégration, les testeurs d'interopérabilité, les pilotes de projet SOA, les administrateurs système SOA¹⁰.

Les exploitants du logiciel

L'utilisateur de l'application se rattache quant à lui à l'équipe des exploitants du logiciel¹¹.La réussite du projet de réingénierie est en grande partie attachée à l'acceptation qu'ils ont de la transformation de l'application qu'ils utilisent.

Les exploitants du logiciel mais extérieurs à la structure ou la RL va s'effectuer

Ils assurent une bonne objectivité quant aux évolutions choisies.

Processus utilisés

On trouve dans la littérature, essentiellement anglaise, plusieurs termes proches qui n'ont pas la même signification mais qui gravitent autour du sujet. On peut confondre leurs noms mais ils ont chacun un objectif différent. Ce sont des processus qui ont une fonction bien précise et des outils qui leur sont associés. Ces termes sont souvent cités dans le processus de réingénierie logicielle car ils y sont organisés et enchainés de manière cohérente.

Schéma des principaux processus utilisés en réingénierie logicielle.

La réingénierie logicielle s'appuie sur une multitude de processus⁶.

Forward engineering

Recomposition. Processus qui permet la conception physique d'un système informatique à partir de sa définition logique (le plus haut niveau d'abstraction)⁶.

Reverse engineering

Rétroingénierie. Activité qui consiste à étudier un objet pour en déterminer le fonctionnement interne ou la méthode de fabrication.

Design recovery

C'est un sous-ensemble du Reverse engineering. Il permet de comprendre la fonction d'un programme grâce à l'interprétation de code et de documentation de l'application¹.

Restructuring

C'est la transformation d'un logiciel en un autre logiciel avec pour objectif de préserver son comportement externe sur les fonctionnalités et la sémantique. Le nom de transformation code-to-code est aussi employé pour décrire le restructuring¹.

Redocumentation

C'est la modification des informations contenues dans le code et des documents spécifiques au logiciel¹².

Le software measurement, le browsing, le cross referencing, le object recovery, la remodularization peuvent être utilisés dans une démarche de réingénierie logicielle¹³.

Software measurement

Activité qui cherche à représenter les caractéristiques d’un système logiciel par des valeurs numériques. Chaque métrique s’associe une caractéristique du logiciel.

Browsing

Permet de comprendre les interconnexions d’une partie d’un système et de ses différentes vues. On peut déterminer les chemins d’accès des objets du système.

Cross referencing

Cherche à découvrir les relations entre les différents composants d'un système logiciel.

Object recovery

Sert à la transformation d’un système basé sur du code procédural en un système orienté objet. L’objectif est de créer des objets au sens programmation, à partir de morceaux de code procédural.

Remodularisation

Tente de changer la structure d'un système selon des critères communs. Cette technologie s’appuie principalement sur une analyse typologique du système.

Démarches et mise en œuvre de la réingénierie logicielle

Intérêt de la réingénierie logicielle

La mise à niveau du parc logiciel fait partie de l'évolution de l'entreprise. Les logiciels les plus anciens sont les premiers concernés par une évolution. C'est la lutte contre l'obsolescence logicielle dont l'objectif est d'améliorer les performances générale du logiciel mais aussi augmenter la fiabilité de l'application concernée et de réduire ses coûts d'exploitation¹⁴.
La lutte contre l'obsolescence logicielle permet aussi d'atteindre un autre objectif : La libération du code de l'application des contraintes propriétaires. L'entreprise peut différencier le matériel du logiciel et ainsi assurer la portabilité de son logiciel vers d'autres plate-formes. Elle peut aussi s'extraire d'une ancienne logique commerciale associant le matériel et le logiciel, qui s'avère pesante et couteuse¹⁵.
Les programmes éligibles ont un socle commun qui est souvent leur ancienneté technologique, logicielle ou matérielle. Le coût de maintenance est élevé, certaines fonctionnalités sont obsolètes, le support matériel est dépassé. Il en résulte un coût global élevé. La réingénierie logicielle est moins couteuse et plus sécurisante qu'un nouveau développement complet d'application. Ce coût et cette sécurité évoluent en fonction de l'importance de la réingénierie effectuée. Plus le code est modifié en quantité, plus le coût augmente et inversement pour la sécurité dont le niveau diminue¹⁶.
Le choix de faire de la réingénierie logicielle est parfois inévitable car certaines applications ont souvent une valeur « interne » au sein de l'entreprise, qui les rend indispensables. L'objectif suivi est d'améliorer la maintenabilité du logiciel, c'est-à-dire l'effort à fournir en vue de le corriger ou de le transformer. L'objectif est d'assurer une migration des logiciels anciens vers de nouveaux matériels plus performants et de nouvelles technologies de programmation plus modulables et plus aisées à maintenir¹⁷.
Mais la réingénierie logicielle ne s'applique pas qu'aux « vieux » logiciels. Ce processus s'applique à tous les logiciels qui participent à la flexibilité des entreprises. Dans un environnement économique très actif, une entreprise doit se concentrer sur les clients et les marchés. Une société doit sans cesse tester sa faculté d'adaptation au changement. Pour être efficace et rentable elle doit pouvoir changer ses exigences opérationnelles. Elle doit être capable d'implémenter de nouvelles fonctionnalités dans son système d'information de manière efficientes¹⁴.

Mises en œuvre

Il n'existe pas une mise en œuvre unique mais plusieurs. Le principe consiste à enchaîner des processus et d'assurer leur cohérence, en fonction des besoins et de l'importance du projet de réingénierie logicielle. Le champ de domaine de la réingéniérie logicielle est vaste. Il convient de situer et d'analyser chaque contexte de solution, ce qui se fait par l'établissement d'une classification des démarches à effectuer¹¹.La réingéniérie logicielle implique un mixage entre les principes et les techniques de génie logiciel. Il faut faire du cas par cas pour chaque solution de réingénierie logicielle¹⁸.
En amont de la phase de réingénierie logicielle proprement dite, il est nécessaire de situer et d'analyser chaque contexte dans lequel le processus s’inscrit. Il faut évaluer la faisabilité et les bénéfices de l’opération. En premier lieu il faut décrire l'environnement dans lequel le processus va s’inscrire. Cela veut dire comprendre l'organisation logicielle, l’architecture matérielle et connaitre les composants techniques associés. Puis il convient d'effectuer un inventaire. Celui-ci va identifier tous les composants et donner leurs caractéristiques. À ce moment précis, la phase d’analyse peut commencer. Elle va évaluer le potentiel de chaque composant et leur pertinence. Enfin, la dernière phase avant la décision de rentrer dans un processus de réingénierie logicielle, est l’évaluation des coûts et des risques encourus. La méthode de L'OAR ^{note 3} reprend toutes ces phases¹⁹

Modèle général pour la réingénierie logicielle

Le processus de réingénierie s'organise autour de deux grands groupes de processus. D'un côté, l'ingénierie inverse et de l'autre l'ingénierie de reconstruction²⁰.
La phase d'ingénierie inverse du logiciel englobe l'analyse du logiciel, de ses composants et de leurs interrelations, l'analyse des risques et la recherche de la documentation. Elle permet la mesure de sa complexité et de sa qualité au niveau logique, physique et conceptuel. Il en ressort une meilleure compréhension du programme au niveau du code et de sa documentation. Cette étape est importante car elle permet de pouvoir convertir le logiciel originel sans en modifier sa/ses fonctionnalité(s)initiale(s). Il est ainsi créé une représentation du programme à un niveau plus haut d'abstraction ce qui facilite la phase suivante qui va permettre l'altération du logiciel¹¹.
La seconde phase est l'ingénierie de reconstruction. C'est la réorganisation du logiciel, la réécriture de l’application et de sa documentation. Elle permet la reconstitution sous une nouvelle forme du logiciel avec ses nouvelles fonctionnalités^21,1.
Elle commence par l’amélioration fonctionnelle par ajout de nouveaux composants, mais aussi par modification de ceux existants. Il est pour cela nécessaire de récupérer la structure, ce qui permet de recouvrir les informations logicielles (spécifications) et conceptuelles (objectifs, contraintes, etc.).
Cette étape consiste aussi à effectuer une analyse d’impact qui doit permettre une évaluation des changements apportés et des efforts à fournir pour se rapprocher des nouveaux standards, comme la norme ISO 9000-3. Après des tests et si ceux-ci confirment l’amélioration logicielle, la migration technologique du logiciel est effectuée¹¹.

Formation

Les programmes d'études fournissant les formations nécessaires dans le domaine de la réingéniérie sont insuffisants. La plupart du temps, les personnes sont formées à la création de nouveaux programmes ou à leur développement s'ils sont récents. Ils n'apprennent pas comment comprendre et améliorer des logiciels existants ou complexes^22,23. Ils doivent apprendre la théorie et la pratique de la maintenance logicielle, mais aussi appréhender et comprendre de vieux programmes en exploitation²².
La réingénierie, en 2006 est encore presque ignorée²². Mohammad El-Ramly, indique qu'il ne trouva aucun manuel sur la réingénierie logicielle pour préparer ses cours. Il dût les construire à partir d'éléments comme des articles sur les systèmes, sur les logiciels ou encore dans les documents associés²⁴.

Facteurs de risques

Si la réingénierie logicielle est un outil puissant de transformation d’un logiciel, il n’en est pas moins risqué dans son utilisation. Son efficacité peut être très variable. Le processus rassemble beaucoup d’autres processus et de notions qui sont autant de facteurs de risques potentiels. Il convient de faire une analyse des dangers du processus pour un logiciel donné. Les points de vigilance se structurent autour de la satisfaction utilisateur, les coûts de la réingénierie logicielle, de l'ingénierie inverse, de la reconstruction logicielle, des performances du logiciel et de sa maintenance. Il faut les identifier et évaluer leur degré d’importance²⁵. Pour cela, il faut évaluer un taux d'exposition au risque en fonction des pertes et de leurs occurrences. Ainsi un facteur de risque est calculé, fonction du taux d'exposition et du coût estimé²⁶.

Aspects économiques

Financièrement la réingénierie logicielle est dans la plupart des cas moins coûteuse qu'une réécriture complète d'un code ou qu'une une nouvelle acquisition²⁷. Mais avant de prendre une décision, il est nécessaire de connaître précisément les gains attendus. Chaque projet doit mettre en lumière les gains amenés par la réingénierie logicielle. Ils sont fonction des bénéfices apportés, des coûts mis en œuvre et des facteurs de risques identifiés²⁸.

Les facteurs de risques de la réingénierie logicielle

La réingénierie logicielle se situe entre deux versions logicielles, celle du logiciel initial et celui dans son état final ou cible. Il y a une crainte de perdre du chiffre d'affaires au cours de cette période ²⁹. Après la modification, le système testé et le système à remplacer doivent fonctionner en parallèle. Cette période peut augmenter les coûts car beaucoup de ressources et de main-d'œuvre peuvent être nécessaires³⁰.

Aspects sociaux

La gestion des ressources humaine se révèle difficile car le changement de métier peut être important. Les personnes impliquées par le processus peuvent nourrir beaucoup d’appréhensions face à ce bouleversement. Une réticence au changement peut naître. Il est essentiel d'estimer les barrières psychologiques et émotionnelles et de les gérer soigneusement tout au long du processus⁷. La communication et la confiance sont des éléments primordiaux pour atteindre un succès de réingénierie. Si les salariés de l'entreprise, directement impliqués avec le processus, estiment qu'il y a un ordre du jour caché ou que l'on cache une réduction d'effectifs, le projet sera condamné dès le début²⁹. Il est essentiel que chaque contributeur participe à toutes les étapes de l'opération¹¹. Les utilisateurs ne valideront pas le nouveau système proposé s'ils n’ont pas été impliqués dans le processus et si leurs besoins n'ont pas été pris en compte. La conséquence en serait un nouvel outil non adapté³¹.

Aspects techniques

Pour la migration d'un ancien système, le problème essentiel provient de l’adhérence du langage de programmation à l'architecture matérielle. Le changement de plate-forme ou de langage utilisé peut amener une baisse de performance du logiciel final ³².
Il est aussi essentiel que les fonctionnalités du « nouveau logiciel » soient suffisamment bien définies et puissent être testées. Car le manque de tests sur les accès aux données ou des choix architecturaux mal précisés peuvent augmenter des délais de réponse de l'application et la rendre inexploitable³¹.
La réécriture de code est aussi un facteur à risque. Il n'est pas aisé de re-coder des fonctionnalités dans une nouvelle architecture surtout quand l'adhérence entre le matériel et le logiciel est forte. Le taux de changement du logiciel est évalué en fonction du taux de réécriture de code. Il s'avère que plus le taux de changement est élevé plus le coût et les risques augmentent.

Facteur de risque pour la réécriture du code²⁶

Désignation	Taux de réécriture de code	Coûts et risques
Encapsulation	20 %	faibles
Rénovation	20 % à 50 %	moyens
Migration	50 % à 100 %	importants

Exemples

AS-400 COBOL

Migration d'un système AS-400 cobol vers un système portable en java. Cette migration montre qu'il n'est pas possible de convertir tout le code cobol en code java car la programmation initiale est très liée au matériel. Il en résulte que 60 % de code a pu être transformé. Les 40 % restants devront être ré-encodés manuellement³³.

Le logiciel de l'Air Force

Expérience de réingénierie sur un logiciel de modélisation électronique pour l'Air Force. La réingénierie logicielle terminée, les concepteurs ont voulu établir une confirmation formelle que le logiciel recréé était vraiment plus recevable que le logiciel original³⁴. Les tests sur le logiciel en question montrent une augmentation de la maintenabilité³⁵.

Le cas de la Base de données hiérarchique

Dans ce cas, la réingénierie logicielle s'applique sur une Base de données hiérarchique et débouche en fin de processus sur une Base de données relationnelle, type de base de donnée plus récente et plus performante. Les changements sont importants. Très peu de composants initiaux peuvent être ré-utilisés. Il s'agit d'une RL à risque car sa durée est plus longue⁷.

Pour aller plus loin : le SOSR

Le Service-Oriented Software Reengineering (SOSR) ^{note 4} est une méthodologie de réingénierie logicielle qui implémente le concept d'Architecture orientée services pour assurer la réorganisation d'ancien système informatique. C'est la réingénierie logicielle vue comme un service ³⁶. Elle ajoute à toutes les notions de web-service, la notion de responsabilité des participants et la définition de leur rôle. la méthodologie SOSR consiste à appliquer, à chaque étape de la réingénierie logicielle, un nombre de concepts définis et d'identifier les rôles précis de chaque participants¹⁰. SOSR s'appuie sur les concepts suivants :

• Architecture trois tier,
• n-tier (distributed process);
• business process design and execution,
• role-base model,
• modèle de vue architecturé 4+1 (en)
• modèle RACI (en)

Le socle de connaissance du SOSR n'est pas assez stable car le nombre d'applications étudiées est encore faible. Il doit se développer³⁷.

程序理解

https://baike.baidu.com/item/%E7%A8%8B%E5%BA%8F%E7%90%86%E8%A7%A3/20835343

程序理解是一个从计算机程序中获取知识信息的过程。这些知识信息可以应用于程序排错、增强程序、重用程序以及整理文档等方面的工作上。程序理解是软件工程领域里的一个重要部分。

通俗地讲，程序理解就是通过一定的设施和方法来弄清楚一个程序是“做什么的”以及“如何做的”。如果对它进行精确定义，可以把程序理解看作这样的任务：以软件维护、升级和再工程为目的，在不同的抽象级别上建立基本软件的概念模型，包括从代码本身的模型到基本应用领域的模型，即建立从问题/应用领域到程序设计/实现域的映射集。 ^[1] 

中文名

程序理解

外文名

program comprehension

任务

 

程序理解的任务就是要揭示程序的功能与实现机制，即理解系统的外部行为和内部构造，其具体任务可分解如下。

1)通过检查单个的程序设计结构，程序被表示成抽象语法树、符号表或普通源文本，这其中包括手工代码阅读、人工制品提取、程序分析、静态分析和动态分析几个过程。

2)尽量做到程序隐含信息的显性表示及程序内部关系的可视化。如控制流和数据流分析，各种程序视图的构造等。

3)从源代码中提取信息，并存放在通用的数据库中，然后通过查询语言对数据库进行查询。

4)检查程序构造过程中的结构关系，明确表示程序组成部分之间的依赖关系。

5)识别程序的高层概念，如标准算法、数据结构、语法及语义匹配等。 ^[2] 

内容

经过分析，全面、准确、迅速地理解程序，对于软件的开发、维护、质量保证及逆向工程和再工程有着重要意义。不过，程序理解的内容比较多，要讲述程序理解的内容，就必须结合具体的程序设计语言。尽管如此，程序理解一般都包含如下内容：

·程序理解的功能和目标。

·掌握程序的结构信息，即从程序中细分出若干结构成分，如程序系统结构、控制结构、数据结构、输入/输出结构等。

·了解数据流信息，即涉及的数据源于何处，在哪里被使用。

·了解控制流信息，即了解每条路径的结果。

·程序理解的操作(使用)要求。

·面向对象的理解(对象、类、继承、通信等等)。 ^[3] 

相关技术

1.语句分析

与自然语言类似，程序文件是由语句构成的，包括标识符、操作符、关键字、字符串、数字、标点符号等词法单元。语句分析分别构造程序的词法模型与语法模型，它们对应于词法分析与语法分析。由于这两种分析不生成任何语义信息，所以它们生成的模型仅仅适用于源代码的模式匹配。

2．程序流分析

程序流分析技术，即在程序运行之前，通过静态分析去发现程序在运行行为方面的某些特性。程序流分析包括控制流分析和数据流分析两种，其中控制流分析侧重于对程序结构的分析，而数据流分析则侧重于对变量控制结构中数据的赋值、使用及传递情况的分析。

程序理解的首要任务是发现它的控制结构，即语句的可能执行路径，通过控制流分析建立过程内部的控制层次。控制流分析可以分为两大类：必经点分析和区间分析，这两种分析方法都是先对程序文本进行分析，将其转化成某种中间表示，然后在中问表示的基础上进行分析，具体选用哪种方法需根据程序理解的任务而定。

数据流分析是为了计算被分析程序在生成数据方面的行为，通常用于程序优化，即为程序优化建立环境。目前，使用最为广泛的方法是对控制流图进行循环分析，称为迭代数据流分析。

由于非结构化程序会给测试、排错和程序维护带来较大的困难，因此按照结构化程序设计的要求，理想的程序设计是尽量避免使用goto语句，程序的控制结构尽量做到单入口、单出口。基于这些原因，在对被测软件进行分析时，系统地检查程序的控制结构成了十分有意义的工作。

3．软件结构图

软件结构图分程序调用关系图(或函数调用关系图)和系统结构图。函数调用关系图或者说是程序调用关系图，都是对源程序中函数关系的一种静态描述，在函数调用关系图中，节点表示函数，边表示函数之间的调用关系。 ^[3] 

基本策略

从软件心理学和认知学的角度，通过对维护人员和维护人员理解过程的研究，总结出3种理解策略，并且提出若干相应的模型。

1．自顶向下的程序理解策略

自顶向下理解策略的原则是维护人员从程序的顶层开始，以从上到下的方式逐步理解下层细节。主要的自顶向下模型有Soloway模型等。Soloway在他的模型中采用自顶向下的方法，根据所拥有的知识和假设，把系统分解成能够在代码中实现的预料中的子系统，然后逐个分解每个子系统直到实现既定功能的一个个代码块。用这种方法构造的智力模型由目标和设计的层次构成，利用论述规则把目标分解成设计，继而分解成更低层的设计。该模型使用3种不同的设计类型：

(1)战略性设计，它描述程序中的整体策略；

(2)策略性设计，它与局部的问题解决策略有关；

(3)实现性设计，它考虑实现策略格局的语言的特征。

2．自底向上的理解策略

自底向上理解策略的原则是软件人员自底向上认知程序的模式，聚合这些模式可以得到更有意义的高层结构，然后再按照自底向上的方式把这些高层结构聚合在一起，构成更大的结构，直到程序被完全理解。在构造的过程中使用了交叉引用表，可把过程层或语句层的表示直接映射到功能层表示。更高层次的设计可让维护人员重新考虑程序模型并做出必要的变更和改进。

3．机会主义的理解策略

在实际工作中，程序理解过程很少像上述这些模型所描述的那样定义完备。所以，VonMayrhauser和Vans提出了使用一种集成模型的机会主义的理解策略。他们的研究发现，理解过程是自顶向下与自底向上这两种方法的结合过程。集成模型包括4个主要部分，即程序模型、状况模型、自顶向下模型和知识库。当对代码熟悉时，使用自顶向下模型，而对代码完全不熟悉时，使用自底向上模型，通过这种灵活的方式推进理解过程。知识库能够帮助对其他3个部分模型的构造，每个模型均由代码的中间表示以及建立这种中间表示的策略构成，知识库融合了以前需要的相关信息和知识。在理解过程中，新的信息被开发出来放在知识库中以便将来使用。 ^[4] 

具体方法

下面简单介绍几种程序理解方法。

1、工程法：利用工程的方法来进行程序理解。工程法包括正向工程、逆向工程、再结构、重用工程以及软件再工程的方法等。

2)程序切片法：程序切片(program slicing)是根据控制流和数据流分析引进的一种程序分析技术。包括语句切片、无定型切片、过程间和过程内切片以及面向对象切片方法等。

3)格局识别法：维护人员必须在改正、加强和再工程程序之前找到相关代码，通常是适合某种模式的代码。模式是一种结构或行为，依赖于寻找有特定语法结构的代码，还是与程序执行有关的特定数据流、控制流或动态相关的代码。为定位这种模式需要一种更接近软件工程师智力模型的搜寻机制(而不是一般的程序分析工具)，这种机制称为格局识别。

4)概念赋值和概念分析法：概念赋值(concept assignment)是发现面向人类的概念中的问题，并把它们赋值给它们在软件系统内部的实现实例。概念赋值是在用户终端应用语义层的模式匹配，是一个在源代码内重新识别概念，并通过联系可识别概念及对应程序来建立程序的一种理解的过程。概念分析(concept analysis)把任何对象和属性之问的关系转换成一个完全的概念格，可通过代数含义来研究这些概念格，并且利用概念格能够很成功地研究初始关系的特性和结构的本质。

5)模式匹配法：模式匹配是在不同的抽象层次卜对程序的各种模式进行匹配的过程。软件理解技术按如下递增抽象形式考虑源代码：粗糙文本、预处理文本、词汇标志、语法树、带符号表的注解抽象语法树、控制流/数据流图、程序格局、构筑范式描述和概念模型等。对不同的用户和不同的软件理解目的来说必须进行不同层次的分析。用基于语法、语义和概念模式匹配的逆向工程理解方法能够加强对程序的理解。

6)程序分析法：程序分析包括静态程序分析和动态程序分析两种：静态程序分析无需执行主题程序而只是根据一些模型推断程序本质结果的过程。静态程序分析包括语法分析、类型检查和推理、控制和数据流分析、结构化分析、交叉引用、复杂度度量等过程；动态程序分析是在一个主题系统中发现运行时依赖的过程。它包括对象实例依赖、动态联编和多态性、方法调用图、路径覆盖测试、内存管理、功能瓶颈、分支和并发等。

7)智能理解(intelligent understanding)法：利用人工智能和专家系统技术帮助进行软件理解。 ^[1] 

辅助工具

阅读源代码是程序理解的一项重要活动，但是阅读别人的代码是枯燥乏味而且比较困难的工作，所以开发辅助工具成了程序理解的一项重要研究内容，并且在这一领域已经有了很多成果。这些工具能以更清晰、更可读、更可理解的方式组织和表示源代码，把人们从烦躁的代码阅读中解放出来。常见的辅助工具有以下几种：程序切分器、静态分析器、动态分析器等。程序切分器能够帮助程序员选择并只观察所提议更改影响的程序部件，不受无关部件的干扰，显示数据链和相关特征，使程序员能够跟踪更改影响。静态分析器能够帮助程序员快速提取模块、过程、变量、数据元素、对象与类、类层次结构等信息。在理解过程中，理解人员应该使用这些工具，以提高理解效率。

目前，除了针对C++、Java以及Ada等语言而专门开发的程序理解工具Understand外，专门用于程序理解的工具还不是很多，并且其中大多是作为辅助功能用于支持开发、测试或其他任务，如Logiscope、Panorama++、McCabe IQ、Klocwork以及有关的IDE。国内北大青鸟在“九五”期间专门将c++的程序理解工具作为科技攻关项目，并取得了较好的成绩，但遗憾的是并未看到他们普及应用的商业化产品或开源产品。 ^[3] 

提高对策

正确、完整、快速地理解程序意味着程序理解的效率高。在程序理解过程中，维护人员要尽可能多地搜集信息(程序文档、源代码、程序的组织与表示等)，而这些信息的完整性、易读性、可靠性都直接影响理解的效率。另外，软件人员自身的专业知识和应用领域知识也很重要，这些都是影响程序理解的因素，针对这些因素，可采用下列对策。

1．提高维护人员的素质

维护人员是软件理解过程的主体，所以维护人员自身的素质直接影响理解的效率。维护人员在应用领域或编程语言方面的经验越多，越容易理解程序以及整个软件系统。因此，应该多给维护人员培训的机会，提高他们的专业水平，使维护团队的整体素质得到提高。另外，还应该拓宽维护人员的知识领域。例如，若要理解的是某个应用在金融领域的系统，在理解的开始，就应该邀请该领域的专家对理解者做相应的培训工作，拓宽他们的知识面，帮助他们较快地进入到软件理解的环境中去。

2．科学地管理开发过程

程序理解是在现有系统和保存信息的基础上进行的，所以程序理解活动中经常要咨询系统开发时的参与者。但这存在一定的困难，原因之一可能是这些工作人员任务繁重，或是由于遗忘，很难配合维护人员的工作；也可能这些人已经离开了本单位，根本无法咨询。所以，在系统开发时就应该采取科学的管理。它包含两层含义：一是保留所有有关的文档，并做到及时更新。例如从最初的需求规格说明，系统设计文档到维护文档，都要做到妥善保存、及时更新。这些信息都直接影响到维护人员搜集信息的质量。二是要注意系统的实现问题，例如命名风格、注释、嵌套层次，最好使用统一的规则，这些都直接影响维护人员理解的容易程度和深度。

3．有效地使用自动化辅助工具

开发辅助工具是软件理解的一项重要研究内容，并且在这一领域已经有了很多成果。这些工具能以更清晰、更可读、更可理解的方式组织和表示源代码，把人们从烦琐的代码阅读中解放出来。常见的辅助工具有程序切分器、静态分析器、动态分析器等。程序切分器能够帮助维护人员选择并只观察要修改和受修改影响的程序部件，不受其他无关部件的干扰，显示数据链和相关特征，使维护人员能够跟踪变更的影响。静态分析器能够帮助维护人员快速提取模块、过程、变量、数据元素、对象与类、类层次结构等信息。在理解过程中，维护人员应该使用这些工具，提高理解效率。 ^[4] 

参考资料

·         1.    蔡建平编著．软件测试大学教程：清华大学出版社，2009.09

·         2.    田文洪主编；王玉林，李凡，周俊临副主编．软件工程：共同演进的方法与实践：机械工业出版社，2013.04

·         3.    蔡建平编著．软件测试实验指导教程：清华大学出版社，2009.11

·         4.    殷人昆，郑人杰，马素霞等编著．实用软件工程：清华大学出版社，2010.11