UML学习入门就这一篇文章

第一篇：UML学习入门就这一篇文章

UML学习入门就这一篇文章

1.1 UML基础知识扫盲

UML这三个字母的全称是Unified Modeling Language，直接翻译就是统一建模语言，简单地说就是一种有特殊用途的语言。

你可能会问：这明明是一种图形，为什么说是语言呢?伟大的汉字还不是从图形(象形文字)开始的吗?语言是包括文字和图形的!其实有很多内容文字是无法表达的，你见过建筑设计图纸吗?里面还不是很多图形，光用文字能表达清楚建筑设计吗?在建筑界，有一套标准来描述设计，同样道理，在软件开发界，我们也需要一套标准来帮助我们做好软件开发的工作。UML就是其中的一种标准，注意这可不是唯一标准，只是UML是大家比较推崇的一种标准而已，说不定以后有一个更好的标准可能会取代她呢!UML并不是强制性标准，没有法律规定你在软件开发中一定要用UML，不能用其它的，我们的目标是善用包括UML在内的各种标准，来提高我们软件开发的水平。

UML由1.0版发展到1.1、1.2、...，到现在的2.0、2.x，本书将会以2.x版本为基础开展讨论。网络上、书籍、还有各种UML工具软件，各自基于的UML版本可能会不一样，大家在学习过程中可能会有一些困惑，不过没关系，本课程在某些关键地方会描述1.x与2.x的差异。

UML有什么用? 有很多人认为，UML的主要用途就是软件设计!也有人认为，如果你不是开发人员，是难以理解UML的。

然而我第一次在实际工作中应用UML的却不是软件设计，而是软件需求分析!当时我们和客户面对面沟通调研需求的时候，直接用类图、顺序图、活动图、用例图等UML。我们并没有因此和客户无法沟通，反而是沟通得更加顺畅。客户在我们的引导下，很快就会读懂这些UML图，因为UML图，让我们和客户的沟通效率和效果更好!你可能觉得很神奇，在后续章节中，我将会为你逐一揭开神奇背后的“秘密”。

UML可帮助我们做软件需求分析和软件设计的工作，在我工作中大概各占了50%的比例，当然在你的实际工作中不一定是这样的比例。UML会让你的需求分析或者软件设计工作更上一层楼，本书将会介绍UML在需求分析方面的最佳实践。

告诉你一个秘密，UML应用于软件需求分析时，其学习门槛将会大大降低!语法复杂度会降低，而且你基本不需要掌握软件开发的知识。只要你对软件需求分析感兴趣，认真学习和应用UML，就很有机会成为软件需求分析高手。

UML的分类 结构型的图(Structure Diagram)类图(Class Diagram)对象图(Object Diagram)构件图(Component Diagram)部署图(Deployment Diagram)包图(Package Diagram)行为型的图(Behavior Diagram)活动图(Activity Diagram)状态机图(State Machine Diagram)顺序图(Sequence Diagram)通信图(Communication Diagram)用例图(Use Case Diagram)时序图(Timing Diagram)本书所描述的UML的各种图的名字，以上述的为准。

UML各种图的中文译名，因为翻译的原因可能会有所不一样，如：Sequence Diagram和Timing Diagram有时候都会被译成“时序图”，这是最让人困扰的地方!Sequence Diagram 除了被译为顺序图，还有序列图的译法。

中国软件行业协会(CSIA)与日本UML建模推进协会(UMTP)共同在中国推动的UML专家认证，两个协会共同颁发认证证书、两国互认，CSIA与UMTP共同推出了UML中文术语标准，该标准全称为：CSIA-UMTP UML中文术语标准v1.0(本书后文将会简称为UML中文术语标准)。本书将会遵循UML中文术语标准，并且我们会同时给出中文译名和英文原名，大家要留意看英文名字噢，这样能帮助你不会被众多的中文译名混淆。

UML图为什么会分为结构型和行为型两种呢? 顾名思义，结构型的图描述的是某种结构，这种结构在某段时间内应该是稳定的，“静态”的;而结构型的图描述的是某种行为，是“动态”的。

分析系统需求时，我们会面对很多业务概念，它们之间会有某些关系，这些内容可以看成是“静态”的，我们可以利用UML的结构性的图来分析。同时，业务会涉及大量的流程、过程等，这些内容是“动态”的，我们可以用行为型的UML图来分析。

在我们软件设计时，我们需要考虑需要那些类、哪些构件、系统最后怎样部署等，这些内容可以看成是“静态”的，我们可以利用UML的结构型的图来设计。同时，我们也需要考虑软件如何和用户交互，类、构件、模块之间如何联系等“动态”内容，我们可以利用行为型的图来设计。

所谓“静态”和“动态”不是绝对的，下文我们将会进一步介绍结构型的UML和行为型的UML。通过下面的学习，你将会初步认识UML的各种图，你可能还会有很多问题，本章的主要目的是让你对UML有一个宏观的认识，带着你的问题继续阅读后面的章节吧!1.2 结构型的UML(Structure Diagram)类图(Class Diagram)请看下面这个类图：

图 1.1 某模具系统类图

此图截取自某模具管理系统的业务概念分析图，图中一个一个的矩形就是类，这些类之间有各种线条连接，这些线条表示类之间的关系。类图是分析业务概念的首选，类图可能是使用率最高的UML图。

再看下面这个Person类图，这时软件设计时用到的一个图：

图 1.2 Person类图

该Person类有以下属性(Attribute)：Name(姓名),Sex(性别),Department(部门)等，有以下操作(Operation)：Work(工作)等。类有属性和操作，但用类图分析业务模型时，往往不需要使用操作，如图1.1中的类就只有属性。

Attribute有特性、特征等译法，Operation也称作方法，但本书遵循UML中文术语标准，即Attribute为属性，Operation为操作。对象图(Object Diagram)一般情况下只有在软件开发中才会使用到对象图，下面的内容以开发的角度来说明对象图，如果你没有开发经验，阅读起来可能有一点难度。

图1.2中的Person类，用代码实例化如下：

Person person = new Person();……

类(Class)实例化后就是对象(Object)，对象person是类Person的实例，上述代码可以用对象图表示如下：

图 1.3 Person类的对象图

对象图和类图的样子很相似，对象是类的实例化，“person : Person”表示对象person是类Person的实例。对象图往往只在需要描述复杂算法时才会使用，画出来的对象图往往不会只有一个对象，该图只画了一个对象，其目的是尽量简化以便读者的理解什么是对象图。

在需求分析工作中基本上不需要使用对象图，从严谨的角度来看某些情况下应该使用对象图，但我往往还是会用类图来处理，这样更加简便而且容易理解。我们将在类图一章再次讲解对象图。

构件图(Component Diagram)构件图也叫组件图，两个名字均符合UML中文术语标准。一辆汽车由轮子、发动机等物理部件组成，一个软件往往也是由很多“物理部件”(如：控件、重用构件等)组成的，构件图就是用来描述软件内部物理组成的一种图。下图是某权限构件设计图：

图 1.4 某权限构件设计图

图1.4右上方有这样标志 的矩形表示一个构件，构件可以再包含构件。

软件需求分析工作中，需要用到构件图的情况不是很多，以下情况除外：

1.待开发的系统需要与第三方的系统、原有系统、某些老系统等交互，这时可用构件图描述交互要求。

2.客户对软件设计有某些特殊要求，这时可用构件图来描述要求。

构件图有时不会单独使用，还会和部署图一起结合使用。

部署图(Deployment Diagram)部署图是用来描述系统如何部署、本系统与其他系统是怎样的关系的一种图，如下图：

图 1.5 某24小时便利店的管理系统部署图

图中一个个立体的矩形是部署图的“节点”，一个节点表示一个物理的设备，节点之间的线条表示节点间的物理连接关系。大部分客户都会具备一定的IT基础环境(如具备局域网、一些服务器、某些软件平台等)，软件系统需要基于当前的IT基础环境来规划，这时我们可以使用部署图来做这个规划。

分析系统的需求，不能忽略系统架构、部署、IT架构等方面的要求，我们要基于客户当前的IT基础环境，做一个最符合客户利益的规划。

要活用构件图、部署图来分析需求，需要具备一定的IT基础架构知识和软件设计知识，如果你还不具备相关知识，那么可以考虑抓紧补充相关知识。不过需求分析工作更多的还是分析业务，提炼功能性需求，这部分工作能做好是相当不容易的事情。对于技术方面的非功能性需求分析，可交由有技术背景的专业人士负责。

包图(Package Diagram)Package有“打包”的意思，包图的主要用途是“打包”类图。用类图描述业务概念时，很多时候会因为业务类太多，而导致类图非常庞大，不利于阅读，这时可以将某些类放入“包”中，通过包图来组织业务概念图。

下图是包图的一个示例：

图 1.6 包图

图中好像文件夹样子的就是一个“包”，包之间的线条表示包之间的关系。1.3 行为型的UML(Behavior Diagram)活动图、状态机图、顺序图处于三种不同的角度来描述流程，是分析业务流程的三种不同利器，下面将会逐一说明。

活动图(Activity Diagram)我们将起床到出门上班这个过程画成活动图，可能是这样的：

图 1.7 起床到出门上班的活动图

活动图中的一个圆边框框表示一个“活动”，多个活动之间的带箭头线条表示活动的先后顺序，该图只是表达了一个顺序流程，活动图还可以表达分支结构。如果你以前曾学过流程图的话，你会发现活动图和流程图很相似。活动图可能是三种能表示流程的UML图中最接近我们思维习惯的一种，下面来学习另外两种能表达流程的图。

状态机图(State Machine Diagram)状态机图又叫状态图，但状态图这个译名并没有译出Machine的意思。

状态机图从某个物品的状态是如何变化的角度来展示流程，下图某请假条审批流程：

图 1.8 请假处理流程

整个请假审批流程是围绕“请假条”这个物体进行的，随着不同的审批阶段，请假条具备不同的状态。我们分析业务流程时会发现很多流程其实是围绕某个物品进行的，这时可考虑使用状态机图。

顺序图(Sequence Diagram)你去餐厅吃饭，向服务员点餐到服务员送菜上来，这个过程用顺序图可表示如下：

图 1.9 点菜的顺序图

该图有三个“小人”，每个“小人”下面的文字说明(如：顾客)表示其代表的角色。角色与角色之间有一些线条链接，表示角色之间是如何交互的。该图表示的意思是：顾客向服务员点菜后，服务员将点菜信息传递给厨师，然后厨师做菜，最后再由服务员送菜给你。

点菜过程涉及几个环节，每个环节均由不同的角色来负责，如果遇到类似的情况，你可以考虑使用顺序图来分析。用顺序图来分析的好处是能清晰表达整个过程所参与的角色，角色与角色之间的关系，各角色是如何被卷入这个过程当中的。

通信图(Communication Diagram)UML1.1时，该图英文名为Collaboration Diagram;UML2.x时，英文名为Communication Diagram。将英文名字直接翻译，原来的英文名字可译为协作图，而新的英文名字译为通信图。

通信图是顺序图的另外一种画法，点菜的顺序图，如果用通信图来画可表示如下：

图 1.10 点菜的通信图

三个“小人”分表表示三种角色：顾客、服务员、厨师;角色之间有直线联系表示他们之间有关系;带序号的文字和箭头，表示角色之间传递的信息。

顺序图更强调先后顺序，通信图更强调相互之间的关系。我觉得顺序图实用性更好一点，比通信图能表达更多的信息，更容易读懂，在需求分析工作中我基本不会使用通信图。

用例图(Use Case Diagram)下图是用例图的示意图：

图 1.11 用例图

用例图表达的是什么角色通过软件系统能做什么事情，我们可以使用用例图系统地表达软件系统的绝大部分需求。

时序图(Timing Diagram)时序图也叫时间图，时序图是UML中文术语标准的说法，而时间图不是标准的说法。

时序图是表示某东西的状态随时间变化而变化的一种图，参见下图：

图 1.12 灯的开关状态随时间变化图

此图表示在0秒到30秒，灯的状态是关的，30-60秒灯的状态为开，60秒后状态为关。

在实际工作中我基本上没有试用过时间图。

下面通过这个表格来总结一下我在需求分析工作中应用各种UML图的情况：

表 1.1 各种UML图实际应用情况

上表是根据我的工作经验总结的，相信会适用于很多情况。但每个人的工作经历、情况、环境等不太一样，上表仅作参考。

1.4 如何学好UML? UML的认识误区

误区一：认为UML主要用于软件设计。

前面的文章你可以看到，UML除了用于软件设计，还能用于需求分析，而本书就是专门来说明如何在需求分析工作中活用UML的。

误区二：客户无法理解UML，在需求分析中应用UML实际意义不大。

我还不熟悉UML时，确实也有这样的怀疑，而实际工作中发现UML恰恰成为与客户沟通的良好桥梁!UML其实不难读懂，只要稍加解释客户马上就能读懂。我在所有的项目需求分析工作中，都直接使用UML图与客户沟通，并且给客户签署的需求规格说明书中含有大量的UML图。

UML能直观、形象、严谨地描述出业务概念、业务流程、客户的期望和需求，只要稍加引导客户，客户将会很容易读懂UML，甚至会主动使用UML与项目组交流。我曾经遇到过客户向我们索要画UML图的工具，客户见识过UML的威力后，也想在自己实际工作中使用。

误区三：认为UML语法繁杂，难以学习和应用。

某些UML资料和书籍可能将UML说得过于复杂了，官方的UML标准资料也确实是枯燥难懂、人见人晕。我刚开始学习UML时，也看过一些UML书籍，觉得UML的语法太多、太复杂、太容易混淆了!在实际工作中，其实经常需要用到的UML语法并不多，而且很容易掌握。当我们在需求分析方面应用UML时，需要掌握的语法更少(在软件设计方面应用UML时需要掌握稍多一点的语法)。“二八原则”在这里完全适用，我们经常用到的UML语法，其实只占全部语法的20%，而本书将会重点介绍实用性强的UML语法。

误区四：UML用途不大。

很多人推崇UML，但也有不少人士不太认可UML。不认可的原因主要是因为一些人士学习UML后，发现在实际工作中发挥的作用并不是很大，有时候不用UML效果更好。

我不敢说UML能帮助我们解决所有问题，至少从我的多年使用经验上来说，UML对于提升我的需求分析能力帮助还是很大的。有人之所以感觉UML不太好用，我觉得原因还是只掌握了UML的形而没有领会UML的神。UML的常用语法可能几天就能学会了，而要真正做到“thinking in UML”却没有这么容易，需要长期的锻炼。

我的学习经历

我读大学时没有听说过UML，出来工作两三年后才开始接触UML，当时的感觉就好像找到了新大陆，很想好好发掘一番!而我当时的运气还是相当不错的，我的上司是UML达人，他带领我参加了项目的需求分析工作。我很快就见识了UML威力，在他的言传身教之下，迅速掌握了UML。

在那个项目以后，我便独立担当了多个项目管理及需求分析工作，没有一个项目不应用UML，而且我毫不保留地传授UML知识给项目组的其他成员。多年的工作进一步磨练了自己，对UML在实际工作中的应用有了更深刻的认识，形成自己的一套方法。

我的UML知识绝大部分来自于工作实践，期间虽然也看过一些书籍，但对我的帮助很少。当然我最大的得益还是来自我的UML启蒙老师，他在实际工作中教会了我UML，帮助我踏上自我成长的道路。我的UML学习最大体会就是：实践太重要了!如果有名师指导则会让你事半功倍!希望本书能成为你在实际工作中学习和应用UML的好帮手!UML学习难点

学UML之难，不在于学习语法，关键是要改变思维习惯。UML是一种新的工具，但同时也是代表了一种新的先进的思考方法，如果不能掌握这样的方法，只能学到了UML的形，而没有掌握其神髓。

要用好UML，你需要在平时多多培养下面的能力：

1.书面表达能力。

2.归纳总结能力。

3.“面向对象”的思维能力和抽象能力。

平时你可以利用各种机会来提升第1和第2种能力，如多写写项目文档、写写日记或博客等，多思考和总结平时自己的工作得失等。

第3种能力说起来有点虚，大家在大学中可能也学过相关知识。训练这种能力的最好方法就是多应用类图，我们将会在类图的章节再重点介绍，通过实例来体会什么才叫“面向对象”!

本书将会重点培养你的这三种能力，只要你有进步之心，多练习、多实践、多思考、多总结，一定会取得长足进步!1.5 小结

本章的主要目标是让你不需要阅读全书的情况下，就可以了解到UML的全貌，大概知道UML各种图的用途，同时给你说明学习UML的难点，为最终活用UML做好准备。下面我们一起来复习一下本章的主要内容：

UML是Unified Modeling Language的简称，是软件开发界的一套标准，UML不仅可用于软件设计，也可以用于软件需求分析。但UML并不是强制标准，我们应该善用包括UML在内的各种标准来提高我们的水平。

UML可分为两类：结构型、行为型，结构性的UML有：类图、对象图、构件图、部署图、包图，行为型的图有活动图、状态机图、顺序图、通信图、用例图、时间图。

类图是业务概念模型分析的有利武器，也是面向对象分析能力的强有力训练工具。

对象图在需求分析工作中并不常用。

构件图、部署图是分析IT基础架构、软件架构等方面需求的有利分析工具，但需要你具备IT基础架构、软件设计方面的知识和经验。

包图可用来组织类图，在需求分析工作中应用的机会不是很大。

活动图、状态机图、顺序图是分析业务流程的强力武器。活动图的表达思路与流程图很类似，很容易掌握，而且大部分情况下都可以使用活动图来分析业务流程;某流程如果是围绕某个物品进行，该物品在流程中转换多种状态，那么使用状态机图来分析是首选;用顺序图来分析的好处是能清晰表达整个过程所参与的角色，角色与角色之间的关系，各角色是如何被卷入这个过程当中的。

通信图可以看作是顺序图的另外一种表达形式，顺序图更强调先后顺序，通信图更强调相互之间的关系。而从我的工作经验看，顺序图更加实用一点。

有人会将用例图称作“公仔图”，用例图表达的是什么角色通过软件系统能做什么事情，我们可以使用用例图系统地表达软件系统的绝大部分需求。

时间图是表示某东西的状态随时间变化而变化的一种图，我在实际工作中很少有机会能用到这种图。

学UML之难，不在于学习语法，避免陷入UML的认识误区，多练习、多实践，培养良好的“think

in UML”思想，锻炼面向对象分析的能力，成为活用UML的需求分析高手不远矣!

第二篇：UML学习心得体会

——uml学习体会

养成良好的绘制uml序列图的习惯 在学习uml的过程中，你可能会遇到绘制uml序列图的问题，这里就讨论一下怎样才能养成良好的绘制uml序列图的习惯。

有一些方法可以帮助您提高uml序列图的质量和效力。它们包括：和主题问题专家一起验证决策；使解决方案尽量简单；为绘制消息和返回值选择一种一

致且有效的风格；将序列图分层；遵循一致的逻辑风格；牢记序列图是动态的。一：验证决策

绘制uml序列图时，我做了一些对其它模型可能有潜在影响的决策。例如，在对第10步建模时，假设（大致上是个设计决策）费用显示屏幕同时也处理学生对费用是否可接受所进行的验证。该决策应该由用户界面原型反映出来，并由主题问题专家(sme)进行验证。您应该和sme（特别是那些对于如何开发类似模型有着深刻见解的富有经验的人）一起执行序列图的绘制工作。

二：保持简单

在对第2和第3步建模时，我忽然意识到学生可能应该使用口令进入系统。在向sme提出了这个概念后发觉我错了：姓名和学号组合对于我们的目的来说已经足够唯一，并且学校也不希望增加复杂的口令管理。这是个很有意思的决策，因为这是学校的一个运作策略，所以可以作为一条商业规则记载到增补规范中。通过与sme一起检验这个想法，而不是假定我比他们知道得更多，我避免了“镀金”的机会，因而减少了我们小组开发这一系统所需的工作。

三：绘制消息和返回值

绘制uml序列图时我更喜欢从左至右地绘制消息，从右至左地绘制返回值，尽管这样对于复杂的对象／类来说不总是非常合适。我将消息上的标签和返回值对齐到离箭头最近的位置。我不喜欢在序列图上标出返回值，为的是使图尽可能地简化。不过，始终标出返回值也同样有效，特别是在序列图用于设计而不是分析目的时。（我希望我的分析图尽量简单，而设计图尽量全面。）在分析期间，我的目标是理解逻辑和确保逻辑的正确性。而在设计期间，则要赋予消息精确的细节。

四：将序列图分层 绘制uml序列图时我喜欢将序列图从左至右地分层。先标出参与者，然后是控制器类，然后是用户界面类，最后是商业类。在设计期间，可能需要添加系统类和持久类，我通常将它们放在序列图的最右侧。以这种方式将序列图分层往往使它们更易于阅读，并且更容易找出分层逻辑问题，例如用户界面类直接访问持久类。

五：遵循一致的逻辑风格

请注意，在图1序列图所示的过程中，逻辑风格做了部分更改。一开始，特别是在登录时，用户界面处理一些基本逻辑--而在选择研习班，以及稍后的验证时，则是控制器类进行处理。这实际上是个设计问题。我不会在这个问题上纠缠太久，但和往常一样，我建议选择一种适合于您的建模风格，然后始终如一地贯彻在所有序列图中。

六：牢记序列图是动态的绘制uml序列图时您可能听说过诸如动态建模和静态建模这样的术语，其他一些熟悉面向对象建模技术的开发人员常常会提到它们。您甚至可能听到过有关每种风格的优点的争论。动态建模技术主要集中在标识系统中的行为，包括序列图的绘制和活动图的绘制（请参阅“如何绘制uml活动图”）以及uml协作图的绘制。而静态建模则集中在系统的静态方面，包括类、它们的属性，以及类之间的关联。类模型和持久／数据模型一样，都是静态建模的主要产物。uml学习心得(一)uml（unified modeling language，统一建模语言）是一组用于描述ooad过程的图形化表达方式。uml为交流面向对象的设计中的需求，行为、体系结构的实现提供了一套综合的表示法。(二)uml由9个不同类型的图组成：

用例图：显示了系统的外部可视行为。

用例图描述了系统外的人员和系统的交互动作，以及系统的响应，该类型的图可以用于描述系统的功能需求。

活动图：显示系统行为的峡谷纳西描述。

活动图描述了单个功能需求内部的细节行为，包括基本的场景和一些可选的场景。

组件图：显示了系统的体系结构。

组件图描述了系统的可部署单元（可执行文件，组件，数据存储和其他一些内容）以及一些借口，可部署单元通过这些接口进行交互，该图可以用于研究系统的体系结构。

顺序图：显示了对象随着时间的交互。

顺序图描述了某个功能需求的路径或场景内相对时间的详细行为，该图可用于理解系统元素之间的消息流程。

协作图：显示了对象的交互，强调对象之间的关系。（在uml2.0里面找不到了）

类图：显示了类的定义和关系。

类图描述了系统设计中的类和接口，以及他们之间的关系。该图可用于定义内部的，面向对象的代码结构。

状态图：显示了响应时间的状态改变。

状态图描述了系统如何改变状态以相应内部的和外部的事件，确保每个事件都被适当的处理。

部署图：显示了系统的物理体系结构。

部署图描述了系统的可部署单元（应用，组件，数据存储等）如何被赋予不同的节点，这些节点如何交互通信，用于系统映射和负载的研究。

包图：显示了设计的层次结构。

包图描述了设计的相关元素如何按组结合在一起，以及他们之间的关系。(三)各种图的作用

1.用例图（usecasediagram）

它是uml中最简单也是最复杂的一种图。说它简单是因为它采用了面向对象的思想，又是基于用户视角的，绘制非常容易，简单的图形表示让人一看就懂。说它复杂是因为用例图往往不容易控制，要么过于复杂，要么过于简单。用例图表示了角色和用例以及它们之间的关系。

2.类图（classdiagram）uml面向对象中是最常用的一种图，类图可以帮助我们更直观的了解一个系统的体系结构。通过关系和类表示的类图，可以图形化的方式描述一个系统的设计部分。3.对象图 uml面向对象中对象图是类图的实例，几乎使用与类图完全相同的标识。它们的不同点在于对象图显示类的多个对象实例，而不是实例的类。一个对象图是类图的一个实例。由于对象存在生命周期，因此对象图只能在系统某一时间段存在。4.状态图

描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的时间做出反应的。通常创建一个uml状态图是为了以下的研究目的：研究类、角色、子系统、或组件的复杂行为。5.时序图

又称顺序图，描述了对象之间动态的交互关系，着重体现对象间消息传递的时间顺序。顺序图由一组对象构成，每个对象分别带有一条竖线，称作对象的生命线，它代表时间轴，时间沿竖线向下延伸。uml面向对象中顺序图描述了这些对象随着时间 的推移相互之间交换消息的过程。消息用从一务垂直的对象生命线指向另一个对象的生命线的水平箭头表示。图中还可以根据需要增加有关时间的说明和其他注释。6.协作图 uml面向对象中协作图用于显示组件及其交互关系的空间组织结构，它并不侧重于交互的顺序。协作图显示了交互中各个对象之间的组织交互关系以及对象 彼此之间的链接。与序列图不同，协作图显示的是对象之间的关系。另一方面，协作图没有将时间作为一个单独的维度，因此序列号就决定了消息及并发线程的顺 序。协作图是一个介于符号图和序列图之间的交叉产物，它用带有编号的箭头来描述特定的方案，以显示在整个方案过程中消息的移动情况。

协作图用途：

通过描绘对象之间消息的移动情况来反映具体的方案。

显示对象及其交互关系的空间组织结构，而非交互的顺序。7.活动图（activitydiagram）uml面向对象中uml活动图记录了单个操作或方法的逻辑，单个用户案例，或者单个业务流程的逻辑。描述系统中各种活动的执行顺序，通常用于描述一个操作中所要进行的各项活动的执行流程。同时，它也常被用来描述一个用例的处理流程，或者某种交互流程。

活动图由一些活动组成，图中同时包括了对这些活动的说明。当一个活动执行完毕之后，控制将沿着控制转移箭头转向下一个活动。活动图中还可以方便地描述控制转移的条件以及并行执行等要求。

组件图是用来反映代码的物理结构。从组件图中，可以了解各软件组件（如源代码文件或动态链接库）之间的编译器和运行时依赖关系。使用组件图可以将系统划分为内聚组件并显示代码自身的结构。

组件图的主要目的是显示系统组件间的结构关系。9.配置图

uml面向对象中配置图描述系统中硬件和软件的物理配置情况和系统体系结构。

在配置图中，用结点表示实际的物理设备，如计算机和各种外部设备等，并根据它们之间的连接关系，将相应的结点连接起来，并说明其连接方式。在结点里面，说明分配给该结点上运行的可执行构件或对象，从而说明哪些软件单元被分配在哪些结点上运行。uml是一种软件建模语言，可以对任何具有静态结构和动态行为的系统进行建模。在关注它建模特性的同时更要关注它的过程特性--在什么时间做什么工作，用什么模型，让哪些人来做。对系统用户而言，软件的开发模型向他们描述了软件开发者对软件系统需求的理解。让系统用户查看软件对象模型并且找到其中的问题，可以使开发者不至于从一开始就发生错误。对软件开发而言，软件的对象模型有助于他们对软件的需求以及系统的架构和功能进行沟通。对软件的维护和技术支持者而言，在软件系统开始运行后的相当长的一段时间内，软件的对象模型能够帮助他们理解程序的架构和功能，迅速地对软件所出现的问题进行修复。建模并不是仅对大型的软件系统，甚至一个小型的留言本也能从建模的过程中受益。利用uml可以有效地解决软件设计和分析过程中的沟通和交流问题，可以高效的了解整个系统结构，并且在设计之初就将软件的设计结构和思想固化在纸上有利于规避项目实施 过程中程序员离开的风险。uml可以贯穿软件开发周期中的没一个阶段，在开发阶段，他可以用于说明、可视化、构建和书写面向对象软件制品的设计语言。uml能贯穿整个软件开发过程是因为在每个阶段都能够提供相应相应的图形来对应，使得改变需求，设计代码，测试分析能变得相对简单。在需求分析过程中，应该分为两个过程：1 需求的获取

2、需求的分析。需求的获取，往往不受到重视，在网上经常看到有人说，特别是国内目前的情况，项目工期紧，公司往往想方设法先把项目拿下来，然后就拿自己公司 以往做过的项目做蓝本，然后再根据顾客的需求改动，再次开发，测试，交付就完工了。但如果需求的获取，做不好，往往对后面的步骤流程造成很大的影响，造成 太多的改动和损失。所以为了得到更好的需求，使用uml建模能变得相对简单。例如需求的用例图对系统的功能模型的搭建。用例间的关系有包含、扩展、泛化三类。用例图包括角色、用例和关 系。角色可以有角色的描述，用例可以有用例的描述，这些描述在交流或评审中会非常有用。用例可以泛化，泛化用例具有基本用例的功能，还可以做得更多。角色 也可以泛化，泛化角色能执行原角色能执行的所有用例，还可以执行更多的用例。除了基本用例，角色不能与包含用例、扩展用例和泛化用例有联系。一个用例可以 对应一个类图。增、删、改、查一般来说对于大多数应用做为一个简单的操作即可，不必要作为一个用例来分析。篇三：uml实训总结 实训总结（收获与体会）

通过一个学期的uml学习，我从书本上获取了基本的理论知识，而真正的学以致用，将书本理论知识运用到实际的过程，是这次uml实训的体现。

三个周的uml实训，主要是围绕着一个实训题目“基于uml系统需求分析与设计--合倍利业务流管理系统”进行的，以小组为单位进行文档的编写，其中还对各种流程图、类图、用例图等的绘制，整个过程设计了知识的方方面面。从中让我认识到uml的作用和运作模式以及方法，它是一种统一建模的标准语言，现在对于大多数软件开发来说，都使用uml作为建模语言，形成了统一的标准。它是图形化的的语言，可以很直观的描述一个事物的状态、行为与特征，很好的说明与表达了“合贝利任务管理”这个系统。总之，在我看来，uml是一种定义良好、易于表达、功能强大且普遍适用建模语言。融入软件工程领域的心思想、新方法和新技术，作用域不限于支持面向对象的分析和设计，也不单纯是一种方法，仅仅是一组符号而已，它可以对任何具有静态机构和动态行为的系统进行建模，所以我很喜欢适用uml，在今后的学习中，我还会进一步对该模型的学习，因为它方便、简洁、干净、清爽，直观形象，把整个软件系统的开发流程都融入进去。

这次实训过程中，文档方面的编写，遇到了很多的问题，这些问题主要是对基础知识的理解和把握不够，不能融会贯通和学以致用，有时遇到困难的时候真的不知如何着手解决，但是，我始终相信的那句话“读万卷书，不如行万里路，行万里路不如名师指路”。所以，当遇到自己模糊和自己难以解决的问题时，向指导老师和懂的同学请教，帮助解决我遇到的问题，经过他们的讲解后，我下来自己在分析，在动手，从不理解到理解，从不会到会，从懂到懂，这是一个让我学习愉快的过程，在这个过程中，既可以丰富了自己的知识，还可以和老师和同学进行有效地方沟通。

在这次实训过程中，感触最深的也就是合作精神了。独木难成林，单枪匹马，那是最错误的思想和做法。这次我是深有感触了。对于一个系统的分析，到最终项目的完成，需要分析每个文档，然后在写出纸质的文档，而在每个文档中，内容比较多，分析也要求比较到位，所以单独凭借一个人去完成，似乎有点困难，于是我们小组，将每个文档进行分析，能独立成块就分配给每一个人，这样，每个人都有自己的任务，谁也不会闲着，既学到了知识，也充实了自己。另外一点，就是我深深体会到了积累知识的重要性。在实训当中我们遇到了不少难题，但是经过我们大家的讨论和老师细心的一一指导，问题得到了解决。两个月的实训结束了，收获颇丰，同时也更深刻的认识到要做一个合格的程序员并非我以前想像的那么容易，最重要的还是细致严谨。社会是不会要一个一无是处的人的，所以我们要更多更快地从一个学生向工作者转变，总的来说我对这次实习还是比较满意的，它使我学到了很多东西，为我以后的学习做了引导，点明了方向。实训的日子即将结束，回想这一个过程，有过痛苦，有过烦恼，有过喜悦和有过成功。痛苦烦恼的是自己对所学书本知识掌握得不是很扎实，面对着从书本上学到的知识与实际联系不起来，总结起来就是自己的动手练习的时间太少。而喜悦的是，在做的过程中遇到了困难和问题，主动向老师和会的同学请教，然后再做，直至做正确做成功后的那种喜悦。

团队的力量是无穷的，通过组员的共同努力，完成了实训项目。虽然，我们这组的项目存在着诸多的不足和缺点，但这正是以后学习和工作需要弥补的。这次实训将为我以后进入社会提过了一笔宝贵的财富，是对我能力的一个见证。最后，不得不感谢指导教师熊飞老师的辛勤指导，和小组成员的共同努力！篇四：uml课设心得

六月23号至六月27号，是我们班进行uml专用周课程设计的时间，虽然时间并不是很长，只有短短的一个星期而已，但是让我受益匪浅，通过这次的uml课程设计，使我所学的书本知识得到了全面的检验，也让我对这门课程有了更加深厚的体会。

这次课程设计我们没有另外选题，而是在我们之前做过的系统之上加以完善和改进。现在看看之前提交的作品，确实不近人意；但经过在网上的不断查找资料，终于还是将它完成。之前我做的系统状态图和活动图，为了锻炼自己这次选择了交互图（也就是时序图和协作图）。虽然说自己没有这方面的经验，也不是特别熟悉其工作流程，但是有了在网上 查找资料得来的一些基础和课本里的讲解，自己对它也有了一定初步的认识，虽然不是很全面，但还是跌跌撞撞的完成。其中还因为和组员没有沟通好导致用的类不同，费了好大劲才改回来。

最后，这次课设使我们发现考试真的并不是最重要，最重要的是能运用所学的知识。在整个uml课程的学习过程中，我们突破了传统学习模式，把被动接受转变为主动学习。不再是用学到的知识解题，而是在实际运用时遇到什么学什么，重在把知识应用于实际。立体的运用比死板的模仿更有效也更容易接受。下学期就大四了，也就是大学校园里的最后一年，而课设里学到的动手能力和分析问题解决问题的能力也将是我们毕业找工作的一大筹码。篇五：uml学习重点汇总

第一章 oom&软件建模概述 uml（unified modeling language）

通用的标准建模语言,可以对任何具有静态结构和动态行为的系统进行建模。标准建模语言uml适用于以面向对象技术来描述任何类型的系统,而且适用于系统开发的不同阶段,从需求规格描述直至系统完成后的测试和维护。

特点：统一标准，面向对象，可视化、表达能力强，独立于过程，uml很适合于以体系结构中心的、用例驱动的、迭代式和渐增式的软件开发过程 第二章 uml构成 1.uml的“4+1视图”

从某个角度观察系统构成系统的一个视图，每个

数据库

5活动图——泳道图

泳道将活动图中的活动化分为若干组，并把每一视图都是系统描述的一个投影，说明了系统某个侧面的特征。（1）用例视图（2）逻辑视图（3）组件视图（4）进程视图（并发视图）（5）配置视图（部署视图）2.uml的模型图：

模型图是一组uml模型元素构成的有向图表示，它通常由一组节点（uml基本模型元素）, 及节点之间的连线（关系）组成。(1)用例视图：用例图(2)静态模型：类图、对象图、包图、构件图和配置图(3)动态模型：活动图、顺序图、状态图和协作图 3.用例图.用例图是表达用例和参与者及其关系的载体。关系包括：关联关系，依赖关系 实现关系： 3.用例图(续)——用例之间关系1（包含与扩展）.3.用例图(续)——用例之间关系2（泛化）.3.用例图(续)——用例与参与者

用例use case：一组用例的实例（场景），其中每个实例都是系统执行的一系列活动，这些活动产生了对每个参与者而言可观察的返回值。描述了从参与者角度看系统做了什么

用例模型本身不是面向对象建模技术。

参与者actor: 是指在系统外部与系统交互的人或其他系统，以某种方式参与了系统内用例的执行。4.交互式视图图(顺序图、协作图)1）协作图：采用图的形式展示对象间的交互 2）顺序图：采用栅栏格式展示对象间的交互

顺序图与协作图的优缺点： 顺序图

（优点）强调消息的时间顺序及对象生命线（优点）大量详细表示法选项

（缺点）强制在右侧增加新对象，消耗空间大 协作图（优点）强调结构组织，复杂交互表达更容易（优点）空间利用率高，和方便添加新对象（缺点）不宜查询消息的顺序，表示法选项少 5 活动图

活动图用于表示完成一个操作所需要的活动，或者是一个用例实例（场景）的活动。活动图适合描述动作流和并发处理行为。5活动图——实例

组指定给负责这组活动的业务组织即对象。泳道区分了负责活动的对象，明确地表示了哪些活动是由哪些对象进行的。

每个活动只能明确地属于一个泳道。6 状态图（状态机）

状态图(state diagram)一个对象在其生存期间的动态行为，表现对象响应事件所经历的状态序列以及伴随的动作。并不是所有类都有相应的状态图。状态图只适用于：具有若干个确定状态，类的行为在这些状态下 会受到影响且被不同的状态改变。

状态图与活动图的区别与联系（1）相同的图形符号。

（2）描述一个系统或对象在生存周期的状态或行为。（3）描述系统或对象在多进程中同步或异步操作并发行为。

（4）用条件分支来描述系统或对象的行为控制流。联系：

（2）描述多个对象共同完成一个操作的机制不同。活动图置于责任区（泳道）中，责任区将活动按责任目标和组织归属的原则分类。状态图采用状态嵌套方式描述多

对象协作。

7、类图

类图表示系统中类及类和类之间的关系，用于对系统的静态结构进行描述。类用来表示系统中需要处理的事物.类的关系：

（1）关联：关联表示两个类的对象之间存在某种语义上的联系。

（2）聚集：聚集也称为聚合，关联的特例 聚集表示类与类之间的关系是整体与部分的关系。

（3）泛化：uml中的泛化关系就是通常所说的继承关系，它是通用元素和具体元素之间的一种分类关系。（4）依赖和细化。2)类的关系——关联

间具有细化关系。细化用来协调不同阶段模型之间的关系。

构件图由构件、接口及构件之间的关系组成。构件图主要用于系统的静态实现视图模型，通过构件的依赖关系描述系统软件的组织结构，展示系统不同物理构件及其关系。

系统业务模型：业务过程和文档。系统开发管理模型：开发期间产物及关系 系统实现模型：系统实现的构件建模

第六章 从需求到设计 包图（package diagram）概念性的模型管理工具，用于将大型的软件系统中大量的建模元素有序的组织起来。

运用包可以把语义上相近的可能一起变更的模型元素组织在同一个包中，对包中的元素作为一个整体对待，并 2)类的关系——聚集

聚集也称为聚合，是关联的特例。聚集表示类与类之间的关系是整体与部分的关系。

（1.共享聚集 聚合：聚集关系中处于部分方的对象可同时参与多个处于整体方对象的构成.（2.组合聚集.组合：部分类完全隶属于整体类.部分与整体共存.整体不存在部分也随之消失。2)类的关系——泛化 uml中的泛化关系就是通常所说的继承关系（或一般与特殊关系）。2)类的关系——依赖

两个类之间有依赖，表明其中一个类.客户类.依赖于另一个类（供应类）所提供的某些服务。2)类的关系——细化

当对同一个事物在不同抽象层次上描述时，这些描述之

系统物理配置模型：数据文件、日志、安装/卸载等文件且控制它们的可视性和存取。包拥有内容，包括类、接构件建模 口、组件、节点、协同。use case、图，甚至其它包。集成系统模型：对api建模，帮助利用已有组件。第三章 unified process(1)构件: 系统中遵从并实现一组接口的物理的、可替换up的构成：二维的面向对象开发模型，兼顾技术和管理。的软件模块。构件是软件复用的基本物理实现单元，是工作流:过程工作流(业务建模+需求+分析与设计+实施+逻辑元素模型（类、接口、协同等）的物理包

测试+部署)和3个支持工作流（配置和变更管理+项目管理+环境）4个阶段：初始＋细化＋构造＋交付 up的迭代策略。

up的迭代开发策略:以体系结构为中心，以质量管理和

风险控制为目标，以用例为驱动，采用迭代式以螺旋上

升的模式进行软件开发。(2)构件的接口:一个构件可以定义对其他构件可见的接第四章 初始阶段(inception)口。构件间依赖通过指向所使用的构件接口来表示。接1.初始阶段的目标和任务：

口描述一个构件能提供服务的操作，是一个有操作而无做适当的调研，以形成对新系统的整体目的和可实现的类。包括输入和输出接口。

行性形成一个合理的意见。

建立项目的软件范围和边界条件，包括一个操作“前景”，“接受准则”和产品中包含什么，不包含什么„ 确定核心的用例，这是系统运行的主要场景，它将决定系统设计的方案

针对主要的场景，确定或者演示至少一个备选的系统结9 部署图（deployment diagram）

构

由节点和节点之间的联系组成，描述了处理器、设备和对整个项目估计总成本和计划(更详细的估计将安排在软件构件运行时的体系结构。

细化阶段中)估计可能的风险(不可预计性的来源）为项目准备支持环境 2.初始阶段的制品： 用例模型＋用例描述，词汇表，补充性规格说明，前景，业务规则 9 部署图——结点 3.用例描述

节点是存在于运行时的代表计算资源的物理元素，可摘要：简介描述用例，通常只给出主成功场景。以代表一种物理硬件设备或软件元素。非正式：用若干非正式段落来描述用例，通常给出多个包含：处理器和设备两种类型 不同场景。

详述：详细描述用例，通常给出所有的步骤及场景，并10 部署图——结点间联系

给出前置和后置条件等细节 节点间通过物理连接发生联系，以从硬件方面保证注意：用例描述的方法 系统各节点之间的协同运行。包括通讯关联、依赖联系4.用例的获取过程

等。(1)选择系统边界(2)寻找参与者(3)确定每个参与者的目标(4)定义用例 5.用例的定义:一般为每一个用户目标定义用例

确定用例的经验方法：

(1)老板测试：必须看到可量化的价值(2)ebp：能够增加可量化的业务价值，并且以持久状态留下数据(3)规模测试： 6.rup与用例

(1)意义：记录功能需求；迭代计划的重要部分，预算的关键输入；实现驱动设计；影响用户手册和测试(2)初始阶段：确定系统目标、范围、涉众；绝大部分摘要描述、10～20％详述；确定是否继续开发(3)细化阶段：80～90％被细化描述；分多次迭代(4)构造阶段：多次时间定量迭代；补充次要用例 第五章 细化阶段(elaboration)1.细化阶段的目标和任务: 8.系统顺序图

表述系统是什么，而不解释它是如何做的，将系统作为黑盒子 系统顺序图

它展示了对一个特定的用例，外部的参与者产生的事件，它们的顺序以及系统内的事件

协作与耦合从较高层到较低层进行，避免从较低层到较高层的耦合第七章 模式与对象设计 1 职责和职责驱动设计 类的契约和责任，分为：行为职责和认知职责。在对象设计中，职责被分配给对象，称为rdd。2 设计模式

设计模式：对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述。即，对特定问题的描述或解决方案。

目的: 易于理解，维护，扩展和重用 3 grasp模式 控制器（controller），创建者（creator），信息专家 构建核心体系架构，解决高风险问题，完成绝大部分需求的定义，并估计并估计总体计划和资源，保证架构，需求和计划足够稳定，风险被充分规避，确定和解决项目中所有与架构密切相关的风险，从与架构密切相关的场景中确定一个基准体系架构，产生一个达到产品级质量水准的演化性原型，也可以是一个或更多个探索型抛弃型原型，能够展示基准的体系架构以合理的价格和合适的时间支持系统需求，建立一个支持环境 2.核心活动: 尽快定义和验证体系架构，并确定体系架构基线 细化设想（vision）为构造阶段建立详细的迭代计划并建立基线 细化开发用例并将其部署到开发环境中 细化体系架构并选择组件 3.关键思想和实践

实行短时间定量、风险驱动的迭代，及早开始编程，对架构核心和风险部分进行适应性设计，实现和测试，尽早，频繁，实际的测试，基于来自测试，用户，开发者的反馈进行调整，通过一系列讨论会，详细编写大部分用例和其他需求，每个细化迭代举行一次 4.制定迭代计划: 通过风险、覆盖范围和关键程度组织需求和迭代。

风险：技术复杂性；其他因素

覆盖性：在早期迭代中，系统中主要的部分都有所涉及 关键性：具有高业务价值的功能

在每个迭代前将用例和特征进行排序 迭代单位：(1)用例；(2)场景 5.细化阶段的制品: 领域模型，设计模型，软件架构文档，数据模型，用例示意板，用户界面模型 6.领域模型(domain model)领域模型是对真实世界中概念类的表示，而不是软件对象的表示。它不是用来描述软件类、软件架构领域层或有职责软件对象的一组图。

领域模型用一套类图表示，但类没有操作。领域模型可以显示：领域对象或者概念类；概念类之间的关联；概念类的属性

概念类来源：现实（组织、地点、设备等）对象；业务（业务实体和概念）对象；过程（需要记录的时间）对象。9.操作契约

通过领域模型中的对象的状态变换(实例创建或删除;属性修改;关联形成或者打破)，定义了系统操作执行后的详细的系统行为.契约co2: enteritem 操作 : enteritem(itemid: itemid, quantity: integer)前提（preconditions）: there is a sale underway 后置条件（postconditions）: 一个saleslineitem的实例sli被创建；sli与当前的 sale 对象相关联；sli.quantity的数值被赋值，依据itemid的匹配，sli 与productspecification相关联 第六章 从需求到设计 1.软件的逻辑体系结构

逻辑架构（logical architecture）是软件类的宏观组织结构，它将软件类组织成包（命名空间），子系统和层等。

层（layer）：对类、包或子系统的粗粒度的分组，具有对系统主要方面加以内聚的职责。较高的层可以调用较低的层。常见的层：

用户界，应用逻辑和领域对象，技术服务 典型的分层模式 2.软件架构

架构是一组重要决策，其中涉及软件系统的组织，对结构元素及其组成系统的接口的选择，这些元素特定于其相互协作的行为，这些结构和行为元素到规模更大的子系统的组成，以及指导该组织结构的架构风格。3.分层设计模式（模型-视图分离, 如mvc架构）系统的大型逻辑结构组织为独立的，职责相关的离散层，具有清晰内聚的关注分离。较低的层是低级别和一般性服务，较高的层则是与应用相关。（information expert），高度内聚（high cohesion），低耦合（low coupling）4 命令——查询分类原则

执行动作（更新、调整）的命令方法，这种方法通常具有改变对象状态等副作用，并且是 void 的（没有返回值）。向调用者返回数据的查询，这种方法没有副作用，不会永久性的改变任何对象的状态。一个方法不应该同时属于以上两种类型。

第三篇：《管理就这几招》心得体会

读《管理就这几招》心得体会

一搜关于管理的书籍，各种五花八门的管理类书籍让我挑花了眼，大略浏览后，思量一番，最终还是选择了吴群学的《管理就这几招》。由于管理实在是门学问，而我连门都未进，粗粗浏览了下《管理就这几招》，初步了解了部分关于管理方面的些许方法，深入了解仍需时间，故在此略略提一下看此书的心得与体会。

《管理就这几招》的作者从角色管理、目标管理、团队管理、自我管理四大核心管理问题着手，重点论述了中层管理者在企业中有效的管理方法与多种技巧。板块“管理之道”与“管理践行”的理论与实际相结合,很值得我这仍处于茫然状态的初学者学习与借鉴。

首先，作为管理者，要清楚认识到自己的夹心角色地位，对上层是下属和执行人、对平级是同事和合作人、对下层是上司和决策人。应清楚自己的定位，了解自己的工作职责和范围，适当展示自己的专业素养和能力，对工作任务进行分析和判断并知人善用合理分配。

其次，善于对目标进行管理，确认每个人的责任分工，分解目标层级把控大方向来，利用小目标的累积来达成大目标。并在适当的阶段给予评价和奖励，增强团队凝聚力。

再是，团队管理至关重要。管理者应善于整合人力所构成的资源，培养团队的向心力、团队精神，与团队人员多进行沟通交流，听取众人意见，适当大胆授权，量才使用最为重要，即在合适的时间把核实的人用在合适的岗位，选对人做对事。众人拾柴火焰高，打造一个好团队方能更好、更快的完成目标。

在学习工作管理时，也应对自我进行管理。书中介绍了SWOT（strength、weakness、opportunity、threat）分析方法对自己进行分析，了解自己的优势、弱势，及找出职业机会和威胁。

以上是我初步看《管理就这几招》的心得，也算是读书笔记吧，让我初步了解管理者应该从哪方面入手及提升。以后会再深入的去揣摩、理解这本书，相信能带给我更多的感触和体会。

第四篇：《丰田就这几招》读后感

《丰田就这几招》读后感

本书通过幽默文字与精妙画面的完美组合，简明扼要地呈现了原本艰深繁复的TPS的精髓，看罢让人茅塞顿开，实为快速全面了解TPS的经典入门读本。本书，主要讲解以下几方面的精彩内容：什么是TPS经营； TPS经营的实体； TPS经营的成功事例；TPS经营的特征； 为了独立的TPS经营等。

通过对本书的阅读，总结出以下的内容和个人体会：

一、内容总结：

1、自动化概念：生产环节中的某一处发生了问题，所有有关的生产线就会全部停止作业。

2、JIT（Just In Time）：无论是对买汽车的顾客，还是对生产的员工，随时提供他们所需要的东西，随时补充需求但保持零库存状态。

3、后工程引受：从后道工序领取原材料或半成品，以推进整个工序的一种工作方法。

4、看板方式：信息的共享和传递。让每个员工都能领到布置其具体工作内容的工作看板，并按照看板要求进行生产，并传递到下一生产环节。

5、多品种少量生产：生产多样化才能产生效益，按客户的需要来引导生产。

6、多技能工化：让员工从单一的工种，发展成长为负责两种以上工作的技能工。

7、持续的改善：不断的挑战，不断的更新，不断的完善。

8、现场中心：到生产现场去看，彻底排除闭门造车。

9、做事的概念：不能产生附加价值的事，是浪费而不是做事。

10、以人性为中心：相信人要比相信设备重要，重视人在生产过程中的价值。

企业要实现TPS经营，必须在认识、设备、人力、生产方式、管理和经营等方面，与TPS经营特点和经营理念紧密结合。

文中让我印象极为深刻的，是讲述了丰田生产方式中，如何降低成本提高利润，以及如何通过平准化生产、杜绝浪费、提高效率等，如何将TPS的各种理念穿插和结合。

在我们的实际工作中，就可以很好的借鉴。虽然我们工作的产品，不是一个个具体的实物，而是产品、市场、销售、品牌运作的链条，但作为一个工作内容，其运作过程中，照样适用TPS的某些原则和方式。

1、在设计产品和流程的过程中，现场中心的概念会被强调，只有到生产的现场（生产基层、销售基层等）去了解，才能设计出符合实际需要的产品组合和流程组合。让设计师了解各个环节是非常重要的，比如培训设计师的各项技能（包括：模具、注塑、印刷、装配、包装等）；让设计师驻外（当销售代表推销自己的产品等），都会有效提升产品设计出来的市场竞争力；

2、为了实现生产的平准化，比如对工人能力方面会有更高的要求，这么以来，只有实现员工的多技能工化，才能最终以平准化生产方式实现多品种少量的产品需求。成本取决于生产方式，很多时候大批量生产看上去了降低了生产过程成本，但假如这个会影响其他产品的断货，实际上会增加更多的成本降低销售和利润。只有保证最快满足市场和客户需求才是企业发展和提升盈利的最好方法。

3、通过生产平准化实现的多品种少量生产，不仅满足了客户和市场的需求，也会更有效地减少库存，实现消除浪费（消除浪费是TPS的核心理念之一）。

4、不降低成本就无法提高利润，其实售价是顾客决定的，原来的方法是以提高售价来获取利润现在已不适合市场发展了，现在的市场必须靠降低成本来获取更高的利润才是正道。其中消除浪费对降低成本也很得要。

陈德暹

第五篇：嵌入式入门激励文章

这是一篇嵌入式入门激励文章，百度上流传已久

• 同济大学软件学院院长谈嵌入式方向选择

• 时间：2007-01-09

• 嵌入式系统无疑是当前最热门最有发展前途的IT应用领域之一。嵌入式系统用在一些特定专用设备上，通常这些设备的硬件资源（如处理器、存储器等）非常有限，并且对成本很敏感，有时对实时响应要求很高等。特别是随着消费家电的智能化，嵌入式更显重要。像我们平常常见到的手机、PDA、电子字典、可视电话、VCD/DVD/MP3 Player、数字相机（DC）、数字摄像机(DV)、U-Disk、机顶盒(Set Top Box)、高清电视(HDTV)、游戏机、智能玩具、交换机、路由器、数控设备或仪表、汽车电子、家电控制系统、医疗仪器、航天航空设备等等都是典型的嵌入式系统。

嵌入式系统是软硬结合的东西，搞嵌入式开发的人有两类。

一类是学电子工程、通信工程等偏硬件专业出身的人，他们主要是搞硬件设计，有时要开发一些与硬件关系最密切的最底层软件，如BootLoader、Board Support Package(像PC的BIOS一样，往下驱动硬件，往上支持操作系统），最初级的硬件驱动程序等。他们的优势是对硬件原理非常清楚，不足是他们更擅长定义各种硬件接口，但对复杂软件系统往往力不从心（例如嵌入式操作系统原理和复杂应用软件等）。

另一类是学软件、计算机专业出身的人，主要从事嵌入式操作系统和应用软件的开发。如果我们学软件的人对硬件原理和接口有较好的掌握，我们完全也可写BSP和硬件驱动程序。嵌入式硬件设计完后，各种功能就全靠软件来实现了，嵌入式设备的增值很大程度上取决于嵌入式软件，这占了嵌入式系统的最主要工作（目前有很多公司将硬件设计包给了专门的硬件公司，稍复杂的硬件都交给台湾或国外公司设计，国内的硬件设计力量很弱，很多嵌入式公司自己只负责开发软件，因为公司都知道，嵌入式产品的差异很大程度在软件上，在软件方面是最有“花头”可做的），所以我们搞软件的人完全不用担心我们在嵌入式市场上的用武之地，越是智能设备越是复杂系统，软件越起关键作用，而且这是目前的趋势。

从事嵌入式软件开发的好处是：

（1）目前国内外这方面的人都很稀缺。一方面，是因为这一领域入门门槛较高，不仅要懂较底层软件（例如操作系统级、驱动程序级软件），对软件专业水平要求较高（嵌入式系统对软件设计的时间和空间效率要求较高），而且必须懂得硬件的工作原理，所以非专业IT人员很难切入这一领域；另一方面，是因为这一领域较新，目前发展太快，很多软硬件技术出现时间不长或正在出现（如ARM处理器、嵌入式操作系统、MPEG技术、无线通信协议等），掌握这些新技术的人当然很找。嵌入式人才稀缺，身价自然就高，越有经验价格就越高。其实嵌入式人才稀少,根本原因可能是大多数人无条件接触,这需要相应的嵌入式开发板和软件,另外需要有经验的人进行指导开发流程。

（2）与企业计算等应用软件不同，嵌入式领域人才的工作强度通常低一些（但收入不低）。搞企业应用软件的IT企业，这个用户的系统搞完了，又得去搞下一个用户的，而且每个用户的需求和完成时间都得按客户要求改变，往往疲于奔命，重复劳动。相比而言，搞嵌入式系统的公司，都有自己的产品计划，按自己的节奏行事。所开发的产品通常是通用的，不会因客户的不同而修改。一个产品型号开发完了，往往有较长一段空闲时间（或只是对软件进行一些小修补），有时间进行充电和休整。另外，从事嵌入式软件的每个人工作范围相对狭窄，所涉及的专业技术范围就是那些（ARM、RTOS、MPEG、802.11等），时间长了这些东西会越搞越有经验，卖卖老本，几句指导也够让那些初入道者琢磨半年的。若搞应用软件，可能下一个客户要换成一个完全不同的软件开发平台，那就苦了。

（3）哪天若想创业，搞自已的产品，那么嵌入式是一个不错的主意，这可不像应用软件那样容易被盗版。土木学院有一个叫启明星的公司开发出一个好象叫“工程e”的掌上PDA（南校区门口有广告），施工技术人员用该PDA可当场进行土木概预算和其它土木计算，据说销路特好。我认识的某大学老师，他开发的饭馆用的点菜PDA（WinCE平台，可无线连网和上网），据他说销路不错，饭馆点点PDA让客户点菜，多显派头档次。我记得00级2+2班当年有一组同学在学Windows程序设计课程时用VC++设计了一个功能很强的点菜系统做为课程项目，当时真想建议他们将这个软件做成PDA，估计会有些销路（上海火车站南广场的Macdonald便使用很漂亮的PDA给用户点食品，像摸像样的）。这些PDA的硬件设计一般都是请其它公司给订做（这叫“贴牌”：OEM），都是通用的硬件，我们只管设计软件就变成自己的产品了。

从事嵌入式软件开发的缺点是：

（1）入门起点较高，所用到的技术往往都有一定难度，若软硬件基础不好，特别是操作系统级软件功底不深，则可能不适于此行。

（2）这方面的企业数量要远少于企业计算类企业。特别是从事嵌入式的小企业数量较多（小企业要搞自己的产品创业），知名大公司较少（搞嵌入式的大公司主要有Intel、Motorola、TI、Philip、Samsung、Sony、Futjtum、Bell-Alcatel、意法半导体、Microtek、研华、华为、中兴通信、上广电等制造类企业）。这些企业的习惯思维方式是到电子、通信等偏硬专业找人。由于我院以前毕业生以企业计算为主，所以我院与这些企业联系相对较少。我院正积极努力，目前已与其中部分公司建立了联系，争取今后能有我院同学到这些企业中实习或就业。

（3）有少数公司经常要硕士以上的人搞嵌入式，主要是基于嵌入式的难度。但大多数公司也并无此要求，只要有经验即可。

我院同学若学习嵌入式，显然应偏重于嵌入式软件，特别是嵌入式操作系统方面，应是我们的强项。对于搞嵌入式软件的人，最重要的技术显然是（实际上很多公司的招聘广告上就是这样写的）：

（1）掌握主流嵌入式微处理器的结构与原理

（2）必须掌握一个嵌入式操作系统

（3）必须熟悉嵌入式软件开发流程并至少做过一个嵌入式软件项目。

我院在嵌入式软件方面最重要的课程包括：

（1）嵌入式微处理器结构与应用：这是一门嵌入式硬件基础课程，我院用这门课取代了传统的“微机原理与接口”课程（目前国内已有少部分高校IT专业这样做了，因为讲x86微机原理与接口很难找到实际用处，只为教学而已）。我们说过，嵌入式是软硬件结合的技术，搞嵌入式软件的人应对ARM处理器工作原理和接口技术有充分了解，包括ARM的汇编指令系统。若不了解处理器原理，怎么能控制硬件工作，怎么能写出节省内存又运行高速的最优代码（嵌入式软件设计特别讲究时空效率），怎么能写出驱动程序（驱动程序都是与硬件打交道的）？很多公司招聘嵌入式软件人员时都要求熟悉ARM处理器，将来若同学到公司中从事嵌入式软件开发，公司都会给你一本该设备的硬件规格说明书(xxx Specification)，您必须能看懂其中的内存分布和端口使用等最基本的说明（就像x86汇编一样），否则怎么设计软件。有些同学觉得嵌入式处理器课程较枯燥，这主要是硬件课程都较抽象的原因，等我们的嵌入式实验室10月份建好后，您做了一些实验后就会觉得看得见摸得着。还有同学对ARM汇编不感兴趣，以为嵌入式开发用C语言就足够了。其实不应仅是将汇编语言当成一个程序设计语言，学汇编主要是为了掌握处理器工作原理的。一个不熟悉汇编语言的人，怎么能在该处理器写出最优的C语言代码。在嵌入式开发的一些关键部分，有时还必须写汇编，如Bootloader等（可能还包括BSP）。特别是在对速度有极高要求的场合（如DSP处理器的高速图像采集和图像解压缩），目前主要还要靠汇编写程序（我看到过很多公司是这样做的）。当您在一个嵌入式公司工作时，在查看描述原理的手册时，可能很多都是用汇编描述的（我就遇到过），这是因为很多硬件设计人员只会写或者喜欢用汇编描述，此时您就必须看懂汇编程序，否则软硬件人员可能就无法交流。很多嵌入式职位招聘时都要求熟悉汇编。

[小知识] 目前嵌入式处理器常见的有ARM、PowerPC、MIPS、Motorola 68K、ColdFire(冷火)等，但ARM占据了绝对主流（资料说手机中几乎100%都是ARM处理器）。ARM是一个只卖知识产权的公司，目前获得购买了ARM CPU核授权许可的大公司很多，包括Intel、Samsung、Amstel、Motorola、Philip等，他们都在ARM CPU核的基础上进行了一些外围扩展，形成自己的处理器（如Samsung S3C2410，Motorola i.MXL9328等处理器都是采用ARM 9内核，指令一级是相同的）。而众多中小公司又购买了这些处理器，设计了各种各样的开发板，如华恒等国内很多著名嵌入式公司都生产基于Samsung S3C2410的开发板，供最终用户使用或供教学实验。在ARM这个食物链上，ARM公司是大鱼，Intel、Samsung等公司是小鱼，而华恒等则是虾米，最终用户（想我们要采购嵌入式开发板的实验室）则是喂虾米的。Intel早期生产的是低端ARM(Strong ARM，相当于ARM 7),现在转向主要生产高端ARM(即Intel Xscale处理器,相当于ARM 10，主要用在高端PDA上,如HP和DELL生产的PDA都采用Intel Xscale，价格较高)。目前应用最多的是ARM 7和ARM 9两类处理器。ARM 7较便宜，可跑uclinux（是一个不支持高级内存管理功能的嵌入式Linux系统）、Vxworks、uc/os II等实时操作系统，但因处理器不带内存管理单元MMU（无内存分页和地址映射机制，所以不能使用虚拟内存），所以不能跑Windows CE，另外通用Linux中的某些内存管理功能也不能用在ARM 7上。ARM 9是一个带MMU功能的高端处理器，可跑WinCE或通用Linux的大多数功能。以上是我的一点了解，可能有不对的地方。我们学院正在建设的嵌入式实验室（10月底到货）包括30套ARM 7系统（拟采用Samsung S3C44b0x开发板，主要用于嵌入式处理器结构、嵌入式linux课程实验），10套ARM 9系统（拟采用Samsung S3C2410x开发板，主要用于Windows CE课程建设），每套实验板都配了高速仿真器，价格都很贵（比我们招标的DELL PC还贵），很容易损坏，同学应爱护使用。

(2)嵌入式操作系统类课程

除了WinCE的实时性稍差外，大多数嵌入式操作系统的实时性都很强,所以也可称为实时操作系统Real Time Operating System.从事嵌入式的人至少须掌握一个嵌入式操作系统(当然掌握两个更好),这在嵌入式的所有技术中是最为关键的了。目前最重要的RTOS主要包括：

第一类、传统的经典RTOS：最主要的便是Vxworks操作系统，以及其Tornado开发平台。Vxworks因出现稍早，实时性很强（据说可在1ms内响应外部事件请求），并且内核可极微（据说最小可8K），可靠性较高等，所以在北美，Vxworks占据了嵌入式系统的多半疆山。特别是在通信设备等实时性要求较高的系统中，几乎非Vxworks莫属。Vxworks的很多概念和技术都和Linux很类似，主要是C语言开发。像Bell-alcatel、Lucent、华为等通信企业在开发产品时，Vxworks用得很多。但Vxworks因价格很高，所以一些小公司或小产品中往往用不起。目前很多公司都在往嵌入式Linux转（听说华为目前正在这样转）。但无论如何，Vxworks在一段长时间内仍是不可动摇的。与Vxworks类似的稍有名的实时操作系统还有pSOS、QNX、Nucleus等RTOS。

第二类、嵌入式Linux操作系统：Linux的前途除作为服务器操作系统外，最成功的便是在嵌入式领域的应用，原因当然是免费、开源、支持软件多、呼拥者众，这样嵌入式产品成本会低。Linux本身不是一个为嵌入式设计的操作系统，不是微内核的，并且实时性不强。目前应用在嵌入式领域的Linux系统主要有两类：一类是专为嵌入式设计的已被裁减过的Linux系统，最常用的是uClinux（不带MMU功能），目前占较大应用份额，可在ARM7上跑；另一类是跑在ARM 9上的，一般是将Linux 2.4.18内核移植在其上，可使用更多的Linux功能（当然uClinux更可跑在ARM 9上）。很多人预测，嵌入式Linux预计将占嵌入式操作系统的50%以上份额，非常重要。缺点是熟悉Linux的人太少，开发难度稍大。另外，目前我们能发现很多教材和很多大学都以ucOS/II为教学用实时操作系统，这主要是由于ucOS/II较简单，且开源，非常适合入门者学习实时操作系统原理，但由于ucOS/II功能有限，实用用得较少，所以我院不将其作为教学重点，要学习就应学直接实用的，比如 uClinux就很实用。况且熟悉了Linux开发，不仅在嵌入式领域有用，对开发Linux应用软件，对加深操作系统的认识也有帮助，可谓一举多得。据我所知，目前Intel、Philip都在大搞ARM+LINUX的嵌入式开发，Fujitum则是在自己的处理器上大搞Linux开发。目前在嵌入式Linux领域，以下几个方面的人特别难找，一是能将Linux移植到某个新型号的开发版上；二是能写Linux驱动程序的人；三是熟悉Linux内核裁减和优化的人。我院在该嵌入式Linux方面的课程系列是：本科生操作系统必修课，然后是Linux程序设计选修课，最后是嵌入式Linux系统选修课。我院在Linux方面目前已有较强力量，魏老师和张老师熟悉Linux开发，金老师和唐老师熟悉Linux系统管理。

第三类、Windows CE嵌入式操作系统：Microsoft也看准了嵌入式的巨大市场，MS永远是最厉害的，WinCE出来只有几年时间，但目前已占据了很大市场份额，特别是在PDA、手机、显示仪表等界面要求较高或者要求快速开发的场合，WinCE目前已很流行（据说有一家卖工控机的公司板子卖得太好，以至来不及为客户裁减WinCE）。WinCE目前主要为4.2版（.NET)，开发平台主要为WinCE Platform Builder，有时也用EVC环境开发一些较上层的应用，由于WinCE开发都是大家熟悉的VC++环境，所以我院学过Windows程序设计课程的同学都不会有多大难度，这也是WinCE容易被人们接受的原因，开发环境方便快速，微软的强大技术支持，WinCE开发难度远低于嵌入式Linux。对于急于完成，不想拿嵌入式Linux冒险的开发场合，WinCE是最合适了（找嵌入式Linux的人可没那么好找的），毕竟公司不能像学生学习那样试试看，保证开发成功更重要。根据不同的侧重点，WinCE还有两个特殊版本，一个是MS PocketPC操作系统专用于PDA上（掌上电脑），另一个是MS SmartPhone操作系统用于智能手机上（带PDA功能的手机），两者也都属于WinCE平台。在PDA和手机市场上，除WinCE外，著名的PDA嵌入式操作系统还有Palm OS（因出现很早，很有名）、Symbian等，但在WinCE的强劲冲击下，Palm和Symbian来日还能有多长？我院可能是全国高校中唯一一家开设专门的“Windows CE嵌入式操作系统”课程的学校，这主要是基于以下原因：我院本身前面便有Windows程序设计课程，同学学过VC++后再学WinCE,非常方便自然，通过学习WinCE同样也可了解嵌入式软件的一般开发过程，对Linux有惧怕心理的同学也很合适。很显然，嵌入式Linux永远不可能替代WinCE，而且将来谁占份额大还很难讲，毕竟很多人更愿意接受MS的平台，就像各国政府都在大力推LINUX已好长时间，但您能看到几个在PC机上真正使用LINUX的用户？据我观察,目前在嵌入式平台上,LINUX是叫得最响,但还是WinCE实际用得更多.嵌入式LINUX可能更多地是一些有长远产品计划的公司,为降低成本而进行长远考虑;二是微软亚洲研究院对我院WinCE课程的支持计划，我们也很希望将来我院能有同学通过微软的面试去实习。WinCE和多媒体(如MPEG技术)是微软亚洲工程院目前做得较多的项目领域之一,他们很需要精通WinCE的人。

总结关于嵌入式操作系统类课程，若您觉得自己功底较深且能钻研下去，则可去学嵌入式Linux；若您觉得自己VC++功底较好且想短平快地学嵌入式开发，则我院的WinCE课程是最好的选择。

(3)嵌入式开发的其它相关软件课程

搞嵌入式若能熟悉嵌入式应用的一些主要领域，这样的人更受企业欢迎。主要的相关领域包括：

A、数字图像压缩技术：这是嵌入式最重要最热门的应用领域之一，主要是应掌握MPEG编解码算法和技术，如DVD、MP3、PDA、高精电视、机顶盒等都涉及MPEG高速解码问题。为此，我院已预订了一位能开设数字图像处理课程的博士。

B、通信协议及编程技术：这包括传统的TCP/IP协议和热门的无线通信协议。首先，大多数嵌入式设备都要连入局域网或Internet，所以首先应掌握TCP/IP协议及其编程，这是需首要掌握的基本技术；其次，无线通信是目前的大趋势，所以掌握无线通信协议及编程也是是很重要的。无结通信协议包括无线局域网通信协议802.11系列，Bluetooth，以及移动通信（如GPRS、GSM、CDMA等）。

C、网络与信息安全技术：如加密技术，数字证书CA等。我院有这方面的选修课。

D、DSP技术：DSP是Digital Signal Process数字信号处理的意思，DSP处理器通过硬件实现数字信号处理算法，如高速数据采集、压缩、解压缩、通信等。数字信号处理是电子、通信等硬件专业的课程，对于搞软件的人若能了解一下最好。目前DSP人才较缺。如果有信号与系统、数字信号处理等课程基础，对于学习MPEG编解码原理会有很大帮助。

（4）嵌入式开发的相关硬件基础

对于软件工程专业的学生，从事嵌入式软件开发，像数字电路、计算机组成原理、嵌入式微处理器结构等硬件课程是较重要的。另外，汇编语言、C/C++、数据结构和算法、特别是操作系统等软件基础课也是十分重要的。我们的主要目地是能看懂硬件工作原理，但重点应是在嵌入式软件，特别操作系统级软件，那将是我们的优势。

我们的研究生里有些是学电子、通信类专业过来的，有较好的模拟电路和单片机基础，学嵌入式非常合适。嵌入式本身就是从单片机发展过来的，只是单片机不带OS，而现在很多嵌入式应用越来越复杂，以至不得不引入嵌入式操作系统。另外，为追求更高速的信号处理速度，现在在一些速度要求较高的场合，有不少公司是将一些DSP算法，如MPEG压缩解压缩算法等用硬件来实现，这就涉及到HDL数字电路设计技术及其FPGA/IP核实现技术，这方面的人目前市场上也很缺。

(5)题外话

另外，能写驱动程序的人目前是非常紧缺的（驱动程序也可归于嵌入式范畴），包括桌面Windows中的DDK开发环境和WDM驱动程序。公司每时每刻都要推出新产品，每一个新产品出来了，要能被操作系统所使用，是必须写驱动程序的。写驱动程序就必须掌握操作系统(如Windows或Linux)的内部工作原理，还涉及到少量硬件知识，难度较大，所以这方面的人很难找。想成为高手的同学，也可从驱动程序方面获得突破。我可说一下自己的经历，三年前我曾短暂地在一家公司写过WinCE驱动程序（正是因为知道这方面的人紧缺，所以才要做这方面的事），尽管那以前从未做过驱动程序，应聘那个职位时正是看准了公司是很难招聘到这方面的人，既然都找不到人，驱动还得有人做，这正是可能有机会切入这一领域的大好机会。面试时大讲自己写过多少万行汇编程序，对计算机工作原理如何清楚，简历中又写着我曾阅读完两本关于Windows Driver Model的两本英文原版书，写过几个小型的驱动程序练习程序（其实根本没写过，我们的同学将来千万不要像我这样，早练就些过硬功夫，就不至于沦落到我这等地步，就不用像我那样去“欺骗”公司了，我这是一个典型的反面教材），居然一切都PASS（当然最重要的是笔试和面试问题还说得过去），这只能说明这一领域找人的困难程度。公司本就未指望找到搞过驱动的人，找个有相关基础的人就算不错了。做了以后，发现也并不是怎样难的。其实搞驱动程序的工作是很舒服的，搞完一个版本就会空一段时间，只有等公司新的芯片推出或新的OS出现后，才需要再去开发新一版驱动，那时有将近一个月时间空闲着在等WinCE.NET Beta版推出，准备将驱动程序升级到CE.NET上，现在在软件学院工作整日忙，无限怀念那段悠闲时光。

很巧合，最近本人无意中再次体会到了嵌入式的迷人之处。上周我那用了3年的手机终于不能WORK了。此次更新，除要求有手机常见功能外，最好有MP3功能（现在很多英语听力都有MP3文件），最好有英汉词典，最好还能读WORD文档。最后选了个满足以上条件的最便宜的手机DOPOD 515（斩了我2.2K，但想想这也算自己对嵌入式事业的支持，这样便也想开了），算得上最低档的智能手机了。回来一查，手机的about显示，本手机Processor是ARM，其OS是MS Smartphone（即WinCE.NET 4.2），这么巧合，简直可做为学习嵌入式课程的产品案例了（等我们的WinCE课程开得有声有色后，希望能从微软研究院搞些Smartphone来开发开发）。有OS的手机果然了得，金山词霸、WORD、EXCEL、REGEDIT等居然都有smartphone版的，PC上的MP3、DOC等居然在download时都可被自动转换成smartphone格式，真是爽。完全可用Windows CE自己开发一些需要的程序download到自己的手机上。现在市面销售PDA智能手机火爆，MS总是财源滚滚。但我已发现国产的ARM+LINUX手机出现在市面上，价格只1.2K。

要么走ARM+WinCE，要么走ARM+LINUX，要么走ARM+VXWORKS。每个搞嵌入式的人都可选一条路，条条大路通罗马。

• 来源：嵌入式在线

• 嵌入式软件工程师 培训获得政府补助

• 嵌入式在线 时间：2007-04-02

• 为促进我国服务外包产业健康快速发展，加强行业的能力建设，加大对服务外包人才培养的支持力度，国家商务部门设立“千百十工程”服务外包人才培训资金，并对中国服务外包基地上海示范区（漕河泾开发区）举办的服务外包人才培训予以支持。

开发区软件园培训中心举办的嵌入式软件工程师培训作为服务外包领域的紧缺人才得到了该专项资金资助，对符合条件的学员提供高额补贴。

由于在通讯、医疗、航天航空、过程控制等众多领域的广泛应用，被称为PC和因特网之后伟大发明的嵌入式智能，已成为继IT网络技术后又一迅速发展的技术方向。但同其快速发展相比，教育机构技术和培养的相对滞后，使得嵌入式软件人才存在巨大缺口。

在未来相当长的时间内，嵌入式软件人才都将是企业争夺的目标，嵌入式软件工程师也将是最热门的职业之一。