专注于.NET开发

摘要： 在这里再谈下需求和设计的边界问题，我们最终的业务系统实现出现的偏差，究竟是需求的问题还是设计的问题？如果边界不清楚则很难明确的区分。对于需求本身有原始需求，用户需求，产品需求和系统需求的各种阶段；而对于需求的过程也本身存在原始需求的收集，需求分析，需求挖掘，和需求相关的业务建模。而对于设计同样存在总体的企业架构设计，到单个应用的总体设计和架构设计，概要设计和详细设计。需求的重点是描述清楚现实世界，而设计的重点则是将现实世界的需求转换为抽象的模型。这是我们说的需求和设计的大边界，但是需求里面也不是简单的需求定义和挖掘的问题，还涉及到业务建模，业务建模和架构总体可以说是衔接需求和设计的重要内容。. 阅读全文

摘要： 概要设计首先要明白的是根据架构设计的内容进一步对某个模块的设计进一步细化。架构设计在系统级，而概要设计在子系统或模块级。拿建筑来比喻，架构设计是把一个建筑的框架结构全部定清楚，包括地基要挖多深，核心框架和承重结构如何，每一层的结构图如何，应该分为几个大套间这些内容都应该定下来。每个大套间的水，电，气等管道接入点在哪里等。而概要设计要做的是拿着一个套间，来考虑这个套间内部该如何设计，如何划分功能区域，如何将水电气接入点进一步在房间内延伸，哪些地方需要进一步增加非承重的隔断等。基于以上思路我们看到在架构设计的时候，除了很少部分的核心用例我们会谈到具体的用例实现完，大多数功能我们都不会谈到具体的用. 阅读全文

摘要： 架构设计包括了功能性架构和技术架构设计两个部分的内容，功能性架构解决业务流程和功能问题，而技术架构解决非功能性需求等问题。两种架构都包括了动态和静态两个方面的内容，对于功能性架构中动态部分为业务流程驱动全局用例，用例驱动的用例实现等；对于技术架构中动态部分为架构运行机制，而静态部分为框架，分层等方面的内容。功能性架构包括了全局用例设计，这个本身是用例分析和设计的一个延续，而全局用例分析建议的思路仍然是业务流程，业务用例建模到系统用例建模的过程。全局用例分析清楚后可以开始考虑子系统和模块的划分，形成系统的功能架构图，当然在划分过程中一定要考虑到通过CRUD矩阵等分析方法来分析模块如何划分合理，. 阅读全文