软件工程导论/UML/介绍
软件工程师使用一种有趣的语言，叫做统一建模语言，简称UML。就像音乐家必须学习乐谱才能弹钢琴一样，我们需要学习UML才能进行软件工程。UML在软件工程过程的许多部分都很有用，例如：规划、架构、文档或逆向工程。因此，值得我们花时间去学习它。
设计软件有点像为好莱坞电影写剧本。角色的特征、动作和互动，以及他们环境中的相关组成部分，都需要仔细规划。作为一个入门示例，让我们考虑我们的朋友比尔，他是一个顾客，正在餐厅吃饭。他的服务员是莱纳斯，他负责点餐和送餐。厨房里是拉里，厨师。史蒂夫是收银员。这样，我们就为餐厅的运作提供了有用且易于获取的信息。
用例模型是系统预期功能及其环境的表示。软件工程师首先绘制用例图。所有参与者都用小棍人表示，所有动作都用椭圆表示，并称为用例。参与者和用例通过线连接。通常还会有一个或多个系统边界。参与者通常不属于系统，因此绘制在系统区域之外。
用例图非常简单，即使是经理也能理解。但它们对于理解要设计的系统非常有用。它们应该列出系统中涉及的所有方以及系统应该能够执行的所有主要动作。它们最重要的方面是你不会遗漏任何东西，而细节程度则并不重要，因为我们还有其他类型的图来描述细节。
接下来，我们将绘制活动图。活动图对给定的用例提供了更多细节，并且通常描绘信息流，因此也称为流程图。用例图没有时间顺序，而活动图有起点和终点，并且还描绘了决策和重复。
如果用例图命名了参与者并为我们提供了剧本中每个场景（用例）的标题，那么活动图则讲述了每个场景背后的详细故事。一些经理可能能够理解活动图，但不要指望所有人都会。
完成活动图的绘制后，下一步细化就是时序图。在这个图中，我们水平地列出参与者或对象，然后用水平线描绘对象之间来回传递的消息。在这个图中，时间始终向下发展。
时序图是面向对象分析和设计中称为过程的重要步骤。该图非常重要，因为它一方面识别了我们的对象/类，另一方面也提供了每个类的成员方法，因为每条消息都变成了一个成员方法。时序图可能会变得非常庞大，因为它们本质上描述了整个程序。确保你的时序图涵盖所有路径，但尽量避免不必要的重复。经理很可能无法理解时序图。
协作图是帮助我们从时序图过渡到类图的中间步骤。它与时序图类似，但布局不同。我们不再关注时间轴，而是关注对象之间的交互。每个对象都用一个方框表示，对象之间的交互用箭头表示。
该图显示了对象的职责。如果一个对象承担了过多的职责，意味着有太多线条进出方框，那么你的设计可能存在问题。通常情况下，你希望将一个方框拆分成两个或多个更小的方框。在这个设计阶段，这仍然很容易做到。尝试在开始编码时或更晚的时候进行拆分，否则会变成一场噩梦。
对于我们这些软件工程师来说，至少对于面向对象的软件工程师来说，类图是最重要的一个。类图由类和它们之间的线组成。类本身用方框绘制，并分成两个部分，一个用于成员方法，另一个用于属性。
从协作图开始，你首先要做的是将所有方框都称为类。接下来，不要用多条线连接对象，而是用一条线代替。但是，对于每条删除的线，你都必须在类的成员方法部分添加一个成员方法条目。因此，在这个阶段，类图看起来与协作图非常相似。
使类图不同的因素是属性，以及不仅仅有一种类型的线，而是几种不同的类型。至于属性，你必须仔细查看每个类并确定该类正常运行所需的变量。如果该类只是一个数据容器，这很简单。如果该类执行更复杂的操作，这可能并不容易。
至于线条，我们称之为对象之间的关系，基本上有三种主要类型
- 关联（拥有）：静态关系，通常一个类是另一个类的属性，或一个类使用另一个类
- 聚合（包含）：例如，一个订单包含订单明细
- 继承（是）：描述类之间的层次结构
完成类图后，你就可以放松一下了：如果你有一个好的UML建模工具，只需点击“生成代码”按钮，它就会用你最喜欢的编程语言为所有类创建包含成员方法和属性的存根。顺便说一下，不要指望你的经理能理解类图。