根据需求分析得到的用例、术语表、补充规格说明得出设计模型、架构模型、架构文档
分析和设计的区别:
架构:
4+1 视图
分析和架构工作流
分析和设计是用例驱动的
用例实现
迭代式开发
4+1视图
逻辑视图:
逻辑试图主要是用来描述系统的功能需求,即系统提供给最终用户的服务. 在逻辑视图中,系统分解成一系列的功能抽象、功能分解与功能分析,这些主要来自问题领域(Problem Definition)。 在面向对象技术中,通过抽象、封装、继承,可以用对象模型来代表逻辑视图,可以用类图(Class Diagram)来描述逻辑视图。
开发视图(Development/Module View) 开发视图主要用来描述软件模块的组织与管理(通过程序库或子系统)。服务于软件编程人员, 方便后续的设计与实现。它通过系统输入输出关系的模型图和子系统图来描述。要考虑软件的内部需求:开发的难易程度、重用的可能性,通用性,局限性等等。
进程试图侧重系统的运行特性,关注非功能性的需求(性能,可用性)。服务于系统集成人员,方便后续性能测试。强调并发性、分布性、集成性、鲁棒性(容错)、可扩充性、吞吐量等。定义逻辑视图中的各个类的具体操作是在哪一个线程(Thread)中被执行。
物理视图 物理试图主要描述硬件配置。服务于系统工程人员,解决系统的拓扑结构、系统安装、通信等问题。主要考虑如何把软件映射到硬件上,也要考虑系统性能、规模、可靠性等
逻辑视图、开发视图,都主要是用来描述系统的静态结构。 进程视图、物理视图,主要是用来描述系统的动态结构。 并非每个系统都必须把5个视图都画出来,而是各有侧重
场景(Scenarios) 场景用于刻画构件之间的相互关系,将四个视图有机地联系起来。可以描述一个特定的视图内的构件关系,也可以描述不同视图间的构件关系。文本、图形表示皆可。