西木空间

1、愿景要解决项目、产品或解决方案的起源问题。明确愿景，就是针对系统的目标、主要特性、功能范围和成功要素等进行构思并达成一致。愿景分析应阐明业务需求、描述需求产生的背景和理由等。 愿景分析最重要的工作成果是《愿景与范围文档》，产品型公司称为《市场需求文档》（MRD）或《产品需求文档》（PRD），项目型公司称为《项目立项书》。 典型《愿景与范围文档》包括下列内容：业务需求 ...

IEEE软件工程标准术语表将需求定义为：用户所需的解决某个问题或达到某个目标所要具备的条件或能力。 系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力。 上述第一项或第二项中定义的条件和能力的文档表述。RUP将需求定义为：需求描述了系统必须满足的情况或提供的能力，可以直接来自客户需要，也可以来自合同、标准、规范或其他有正规约束力的文档。 1、需...

需求分析主线中所包含的关键步骤，可以概括为“三横两纵”。三横 确定系统目标。 研究高层需求。 建立用例模型。 两纵 需求沟通、需求启发、需求验证。 确定非功能需求。 所谓“纵”，指的是实践中需要持续不断地进行。所谓“横”，则是有先后之分的。1、第1步：明确系统目标产品的“根”是系统的业务目标，我们要把业务目标写入《愿景文档》，成为《愿景文档》的关键部分。2...

1、用例技术1.1、用例图用例图描述软件系统为用户或外部系统提供的服务。用例图最重要的元素是参与者（Actor）和用例（Use Case），以此体现系统能为外部参与者（Actor）提供的功能（Use Case）。 参与者是与系统交互的角色或系统，既可以是系统的用户（User），也可以是和系统有直接交互关系的系统（System）。 用例的名称应该从参与者的角度进行描述，并以动词开头，...

1、小型流程 需求工作项 提交的文档 所处需求层次 业务目标 《目标列表》 业务需求 绘制用例图 《需求规约》或《用例模型》 用户需求 编写用例规约 行为需求 2、...

领域模型试讲领域概念以可视化的方式抽象成一个或一套模型。1、作用为需求定义提供了领域知识和领域词汇。 软件界面的设计往往和领域模型关系密切。 领域模型是否合理将严重影响软件系统的可扩展性。 领域模型经过精化之后会成为业务层的核心。 是设计持久化数据模型的良好基础。1.1、需求人员视角促进用户沟通、领域模型提供的词汇表应当成为所有团队成员所使用语言的核心，在需求活动以及其他活...

关键需求决定架构。关键需求横跨功能需求、质量属性，以及约束这三类需求。其余需求用来验证架构。1、确定关键质量需要做如下三方面工作：为了提高要开发软件系统受认可的程度，应着重提高哪些方面的质量属性要求。 充分考虑这些质量属性的相互制约或相互促进关系，以调整不同质量属性的要求标准。 同时，必须满足各种约束性需求。确定关键质量时考虑质量属性之间的矛盾关系。采用质量属性关系矩阵（“+...

1、基础概念概要架构满足“架构 = 组件 + 交互”的基本定义，只不过概要架构仅关注高层组件。 概要架构对高层组件的“职责”进行笼统的界定，并给出了高层组件之间的相互关系。 概要架构不应涉及接口细节。直指目标的设计思想、重大选择，是关乎任何复杂系统成败的最关键的、指向性的设计。具有针对性，三大特征分别为：直指目标 设计思想 重大选择2、关键需求->概要架构以关键需求为...

1、需求过渡到设计功能需求使用用例规约等技术描述功能，阐明待开发系统的使用方法，但并没有以类、包、组件、子系统等元素形式描述系统的内部结构。从用例规约向概要设计过渡之所以困难，是因为：用例是面向问题域的，设计师面向机器域的。 用例技术本身不是面向对象的，而设计应该是面向对象的，这是两种不同的思维方式。 用例规约采用自然语言描述，而设计采用形式化的模型描述，描述手段也不同。使用鲁棒图建...

1、场景思维场景是一种将笼统需求明确化的需求刻画技术。性能、持续可用性、安全性、可扩展性等笼统的非功能需求，通过建立场景来明确，并最终进行设计决策。这是以场景为“跳板”的非功能目标设计思维。场景应包含5要素：影响来源：来自系统外部或系统内部的触发因素。 如何影响：影响来源施加了什么影响。 受影响对象：默认的受影响对象为“本系统”。 问题或价值：受影响对象因此而出现什么问题，或...

1、设计要领1.1、1个决定，4个选择决定 如何划分顶级子系统。 选择 架构风格选型 开发技术选型 二次开发技术选型 集成技术选型 上述5项设计任务顺序：首先，选择架构风格、划分顶级子系统。这2项设计任务是相互影响、相辅相成的。 然后，开发技术选型、集成技术选型、二次开发技术选型。这3项设计任务紧密相关、同时进行。也可能不需要集成支持，也可以决定不支持二次开...

对软件研发而言，系统思考是以整体的观点对复杂系统构成部分之间的联系进行研究。1、从需求到设计“概念设计”是“细化架构设计”活动的输入。 各种“需求”是“细化架构设计”活动的输入。 “领域模型”是“细化架构设计”的输入。2、5视图设计过程2.1、开发架构程序单元 + 编译依赖关系程序单元 源文件、配置文件 程序库、框架 目标单元 程序单元组织 Projec...

架构视图是一种设计架构、描述架构的核心手段。通过“架构视图”作为分而治之的手段，使架构师分别专注于架构的不同方面、相对独立地分析和设计不同“子问题”。1、2视图方法逻辑视图+物理视图。1.1、逻辑架构软件的逻辑架构规定了软件系统由哪些逻辑元素组成以及这些逻辑元素之间的关系。具体而言，组成软件系统的逻辑元素可以是逻辑层（Layer）、功能子系统、模块。设计逻辑架构的核心任务，是比...

1、逻辑架构逻辑架构关注职责划分和接口定义。不同粒度的职责需要被关注，它们可能是逻辑层、功能子系统、模块、关键类等。不同通用程度的职责要分离，分别封装到专门模块、通用模块或通用机制中。如果使用UML来描述架构的逻辑架构，则该视图的静态方面由包图、类图、对象图来描述，动态方面由序列图、协作图、状态图和活动图来描述。核心设计任务是：模块划分、接口定义、领域模型细化。2、开发架构包括...

水平原型：在一定程度上实现用户交互层的界面布局和界面流转逻辑。低保真原型往往是在白板上或文档中画出界面的草图。又称行为原型。 垂直原型：往往涉及到不同的层，将为数不多的（甚至一个）功能真正地展现。又称结构原型。 抛弃原型：用过之后注定要被抛弃的。又称探索原型。 演进原型：保留下来作为正式开发的基础。 ...

1、原型法准确来说是“垂直演进原型”：为了真实地验证架构的表现，必须将选定的功能特性完整地实现；另一方面，这个原型不是验证单个技术的运用是否可行的垂直抛弃原型，而是要对一组架构设计决策“对系统要求的非功能需求的满足程度”进行验证，所以这个垂直原型应该是演进型的，将直接作为后面分头开发的基础。2、框架法将架构设计方案用框架的形式实现，并在此基础上进行评估验证。3、具体步骤测试运行...

1、功能树作为需求分析的手段，功能树是一种框架性工具，有助于需求分析人员一层一层地选择确定系统必须具有的各项功能与特性。作为需求分析的结果，功能树是一种功能表达结构，将“功能大类”、“功能组”和“功能项”的隶属于支持关系以“树”的形式呈现出来。1.1、与功能模块区别功能树是一种功能分解结构，功能模块则是对系统进行结构分解的结果示意图。 功能树刻画的是问题领域，功能模块刻画的是解决方案...

1、分层架构1.1、展现层、业务层、数据层层的职责 展现层，或称为表现层，用于显示数据和接收用户输入的数据，为用户提供一种交互式操作的界面。 业务层，或称为业务逻辑层，用来处理各种功能请求，实现系统的业务功能，是一个系统最为核心的部分。 数据层，或称为数据访问层，主要与数据存储打交道。 层间关系 展现层会向业务层传递参数，发出服务请求，并获取业务层返回的信息显示在界面上。...

描述需求的序列图，描述的是“内外对话”。 描述设计的序列图，描述的是“内部协作”。1、划分原理用例是需求，架构师设计。用例驱动的架构设计，从用例到模块划分结构，关键过渡是一组对象的相互协作。所谓协作，是一组对象为了实现某个目的而进行的交互。从“需求层”到“设计层”的总体思维路径，简称“两环节、四步骤”：需求分析环节 一方面用例图定义系统能提供给外部Actor的功能，此步在先。 ...

1、设计思维融合把层、功能模块、细粒度模块三个概念分清楚。功能模块是粗粒度的，一般对应一个功能组，最大的用途是基于功能模块进行开发小组分工。 层也是粗粒度的，UI交互层封装人机交互、系统交互层封装硬件访问和外部系统交互、数据管理层封装DB和File和Flsh存储。 模块划分设计需要进一步设计到细粒度模块一级。 一个细粒度模块，必然位于架构的某一层中。 一个细粒度模块，一般也都会属...