假设，你所在公司的CEO请你对最近公司网站制作人员开发的250个内部软件进行一次检查，以便找出建立可重用组件库的备选功能组件，这些组件包括设计、代码和测试用例。你该如何完成这项任务呢？以2009年左右的技术水平来说。这项任务并不容易完成。在这250个软件应用中，大约会有75个是少于1000个功能点的小型软件，它们很可能会使用敏捷开发方式而且使用用户故事作为主要的设计描述方式，同时也可能会混合使用其他的描述方法。对于单个的软件应用来说，用户故事是非常有用的，但如果需要找出多个软件应用中的共同点，用户故事就显得不是那么有效了。 还可能会有大约50个软件是超过5000个功能点的大型商业软件，这些软件很可能是用了多种正式的设计描述方式，也或许会使用UML方法来描述从联合应用设计(JAD)方法中收集到的需求。尽管UML方式可以帮助我们为单独的软件应用建立模型，但是考虑到如此多的各具特点的UML图表，如果找们要想通过审视大量项目的UML图表(如50个项目)来试图找出其中共有的功能，这仍然不是一件容易的或者很快就可以完成的工作。 自动化的工具，例如静态分析工具，也许可以通过分析基于UML的元语言的语法结构来找出共有的模型，但在2009年左右，这项技术还不能应用到实践中。在这250个软件应用中，还可能会有25个是科研项目软件或工程项目软件，它们可能会使用状态变化图、建模语言(如LePus3语言e ，Express语言。)或者质量功能展开(QFD)方法所建立的“质量屋“图表以及其他多种架构建模元语言。 余下的100个软件应用可能使用了多种描述方法。包括但不限于用例、UML方法、N-S图、Jackson Design,流程图、决策表、致据流向图、HIPO图以及其他各种方式。其中的一些方法可能会定义模型，但即使是对100个项口进行扫描检查也不是一件容易的事情。 总结来说，这250个最新开发的软件应用使用了超过50种不同的设计语言和方法，而对其中的大部分语言和方法来说。进行相互转化是一件非常困难的工作。同时，这些语育和方法也很难通过自动化验证工具和自动化错误检查工具来处理。