第1章 为什么系统分析员需要学习UML
1.1 概述
系统分析员(System Analyst)的工作相当辛苦,他们站在用户与开发人员的中间,作为两者之间的沟通桥梁。系统分析员一方面需要向用户搜集并理清需求(Requirements),另一头又得急忙向开发人员提出清晰且明确的需求。
在项目进行期间,系统分析员除了得请神明保佑自己*好别误解或遗漏需求外,还得面对用户变更需求的反复性格,以及开发人员不愿因需求变更而白做工的强硬态度。这一切现象让系统分析员心力交瘁、焦头烂额。
在OO(Object-Oriented,面向对象的)与UML(Unified Modeling Language,统一建模语言)成了挡不住的潮流之后,程序员(Programmer)大量使用C++、Java等OO程序语言,同时也进一步带动设计师(System Designer)使用UML来表达关于OO设计。所以,设计师拿到系统分析文件后所做的第l件事情,便是将非OO文件转成OO的UML图,随后才能进行复杂的设计,并且生成各式的UML图,交由程序员按图编码。
然而,非OO的需求文件转成OO的UML图,不仅缺乏效率而且错误百出。许多公司开始意识到这样的问题,纷纷要求系统分析员学习OO概念,并且采用UML编写系分文件。这样一来,OO概念从分析开始,通过设计,一路贯穿到实现,沟通零误差。
UML是一套用来表达OO分析设计的国际标准语言,从1997年发展至今,吸引了相当多的爱好者,也发展出各式付费或免费的UML工具。挑选一套UML工具,作为系统分析员、设计师和程序员的工作平台,有助于提高工作效率。系统分析员生成的UML文件,可以交由设计师添加设计细节,*后再交由程序员按图编码。
1.2 UML并非**
有些系统分析员对UML怀有高度期望,希望采用UML来搜集及编写需求之后,可以不再误解或遗漏需求,或者可以降低需求变更。不难想见,系统分析员经常得面对这些问题,当然期望学TUML之后,可以一劳永逸地解决掉这些问题。可是UML并非**,无法根除这些本质性的问题,不过也不必悲观,总是有对策可以来处置需求误解、遗漏或变更的情况。
……