面向对象分析过程的实际案例

在绘制时序图的过程中，我们获得了关键对象以及这些对象的方法. 接下来，我们在图形中绘制这些对象及其方法，定义它们之间的关系面向对象的分析过程，然后获得分析类静态图. :

（此图片实际上是一个小问题，因为此矩形元素代表设计类而不是分析类，绘制时序图时分析类的形状应为圆形，并且没有无效水平. 使用的建模工具是EA. 我不知道该工具不支持分析类中的绘制方法，或者我自己也找不到它. 无论如何，有可能出现在玫瑰中）

通过分析类对象来实现用例场景的过程是类派生的过程. 现在我们已经获得了第一类及其方法，尽管它看起来很粗糙，但已从需求的角度出发，而进入了系统设计的角度.

这些分析类是我们系统设计的基础. 分析类使用的特定框架（例如SSH）和体系结构可用于派生设计类并生成设计模型.

由于特定的框架，推导设计类的过程可能会实现某些接口，继承抽象类等等. 在这里我不会谈论它. 过一会儿我会写一篇新文章. 由于该项目使用的是SSH框架，我想知道为什么我没有看到Action类，Service类，pojo和DAO. 我没看到！后来，我突然意识到，哦，原始的抽象级别有所不同. 分析模型的抽象级别高于设计模型，并且不涉及特定的框架，体系结构，语言和其他实现方法，因此在此抽象级别上，您可以忽略它的实现细节，屏蔽不相关的信息，并专注于通过三种类型的分析对象之间的交互来实现需求，在需求和设计之间架起一座桥梁，设计模型是基于分析模型并结合特定的框架，体系结构，语言等实现实例化分析模型的过程. 完整而全面的分析模型可以用作系统摘要设计文档.

实际上，我个人认为从业务模型到设计模型（中间可能有概念模型），再到分析模型，再到设计模型，这种建模过程是减少抽象水平和边界粒度类似，因为我们要描述诸如汽车之类的事物，所以我们可以这样说: 站在汽车的抽象水平上，我们可以看到车身和轮胎的边界；降低对人体的抽象水平，我们面对着方向盘，引擎，边界（例如座椅）；站在引擎的抽象层次上，我们看到的是引擎，活塞等的边界. 通过使用这种自上而下的方法清晰地描述事物，可以一直扩展这一抽象层次. 抽象级别的优点是，无论您处于哪个级别，都只需要面对有限的复杂性和结构，这有助于我们了解此级别的对象如何工作. 伴随着边界和抽象级别，并且不同的抽象级别面临着不同的边界粒度. 编程中所谓的“接口编程”实际上是将对对象的理解附加到接口的边界. 我们只需要知道他可以做什么，而不必减少边界的粒度即可考虑特定的实现方法. 可替换灵活性的具体实现.

本文写在这里. 我想把它写下来. 我目前太虚弱了. 毕竟，要用我目前的能力来写那么多的内容并不容易，尽管这个问题的情况很简单，但是这种面向对象的分析是相同的.

过去两天，福州的天气非常炎热. 我在两个周末都读了这篇文章，以撰写本文. 我在吹空调的时候在宿舍写的. 实际上，一个项目必须面对的问题远远超出了本文所提到的. 例如，为了为特定问题（例如权限系统等）构建域模型，本文还省略了对业务规则的分析. 不过，我觉得我基本上已经说了我想要的东西. 在目前的水平上，可以说有很多帐户，至少我觉得我已经找到了面向对象分析的大门. 这条路很长...

最后面向对象的分析过程，在2004年IBM Developer Works Live中，我指的是面向对象的大师Grady Booch！会议结束时在访谈中被广泛使用的词语是: “我面向对象编程的目标是从不重用. 相反，对我来说，对象提供了一种处理复杂性的方法. 这个问题可以追溯到亚里斯多德: 您将世界视为一个过程还是一个对象？在面向对象的运动兴起之前，编程就集中在诸如结构化设计方法之类的过程上，但是，系统已经超出了其处理能力的复杂性是极端的使用对象，我们可以通过提高抽象级别来构建更大，更复杂的系统-我认为这是面向对象编程运动的真正胜利. ”

原文:

链接到本文:

来源: CSDN

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-209733-1.html