• 我知道的软件思想至今发展的主要过程：面向过程 －》OO－》DDD－》DCI 始终是一个进化的过程，OO解决了面向过程的封装，但他依然是基于静态的分析；DDD提供了面向应用业务的分析指导，但是他没有直接提供解决对象变化的指导；DCI提供了系统模型分析的指导，
  • 以前的设计思路就是，通过画出usecase之后 找出需要被存储的表和属性，然后在业务操作的时候就是操作对应的表数据，这样典型的就是数据库驱动设计。如果碰到复杂的业务系统，数据库设计就会让人望而生畏，没有标准的设计原语，只有生涩的数据库图表，一旦复杂系统升级基本上是噩梦不如重做。
  • 区块链不是物联网，区块链很难和你的现实联系，区块链是形式逻辑世界的产物，是第三元世界的。如今，人们出于各种原因诉诸区块链。自从我在2017年中期开始进行智能合约安全审核以来，我已经看到了这一切。“区块链可以到处使用”似乎是合乎逻辑且有益的，但实际上包含一些问题，我将提供一些此类问题和 icon
  • 根据UML Distilled（第 9 章），用例是由一个共同的用户目标联系在一起的一组场景（banq：特定角 icon
  • 作为业务分析师，我们以BRD（业务需求文档），FSD（功能规范文档）和SRS（软件需求规范）等不同文档捕获需求。如果我们要以这么多不同文档来捕获需求？那么为什么这些文档名称会不同？答案是肯定的。我们正在从不同角度捕获需求。这就是文档名称不同的原因。 需求是指从业务用户的角度来 icon
  • OpenAI的最新产品GPT-3 是AI领域的新星，并且自其诞生之日起就席卷整个AI社区，其类似于人的文本生成功能，参数有1,750亿庞大的规模，还有OpenAI选择保留算法专有权而不是开源。 GPT-3（Generative Pre-trained Transformer- 3）采 icon
  • 1.慎用分解。use case有uses和extendes两种关系。但应慎用对use case的分解，因为容易使你的use case写成功能分解的形势。并不是说功能分解有什么不好。主要是你的use case映射成类图后会使你的设计不遵循面向对象的原则。 icon
  • 才初步入门架构学习，请前辈指教，需求分析：主要单位设置：1、 生产科 检验科、外协科2、 机加车间、热磨车间、总装车间3、 毛坯库、成品库 各个部门职责和流程：1、 生产科负责指定生产计划，生产计划可 icon
  • 用例的创建是在概要设计，还是在详细设计阶段?如果有一个“用户登陆”用例，是否应该有型如“填写用户登陆日志”这种话呢？这句话是不是放在详细设计阶段更好呢？ icon