下载文档原格式
第五章-信息系统⼯程1-软件⼯程1.1-架构设计1.软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述，构件的相互作用（连接体）、指导构件集成的模式以及这些模式的约束组成。
2.软件架构主要研究内容涉及软件架构描述、软件架构风格。
软件架构评估和软件架构的形式化方法等。
3.研究软件架构的根本目的是解决好软件的复用、质量和维护问题。
4.软件架构设计的一个核心问题是能否达到架构级的软件复用，也就是说，能否在不同的系统中使用同一个架构软件。
软件架构风格是描述某一个特定应用领域找那个系统组织方式的惯用模式。
5.通用软件架构：数据流风格、调用/返回风格、独立构件风格、虚拟机风格和仓库风格。
6.数据流风格：包括批处理序列和管道/过滤器两种风格。
7.调用/返回风格包括主程序/子程序、数据抽象和面向对象，以及层次结构。
8.独立构件风格包括进程通信和事件驱动的系统9.虚拟机⻛格包括解释器和基于规则的系统。
10.仓库⻛格包括数据库系统、⿊板系统和超⽂本系统。
11.在架构评估过程中，评估⼈员所关注的是系统的质量属性。
1.2-需求分析1.虚拟机⻛格包括解释器和基于规则的系统。
需求是多层次的，包括业务需求、⽤户需求和系统需求，这三个不同层次从⽬标到具体，从整体到局部，从概念到细节。
2.业务需求：指反映企业或客户对系统⾼层次的⼀个⽬标追求，通常来⾃项⽬投资⼈、购买产品的客户、客户单位的管理⼈员、市场营销部⻔或产品策划部⻔等。
3.⽤户需求：描述的是⽤户的具体⽬标，或者⽤户要求系统能完成的任务，⽤户需求描述了⽤户能让系统来做什么。
4.系统需求：是指从系统的⻆度来说明软件的需求，包括功能需求，⾮功能需求和设计约束。
5.质量功能部署QFD是⼀种将⽤户要求转化成软件需求的技术，其⽬的是最⼤限度地提升软件⼯程过程中⽤户的满意度。
为了达到这个⽬标，QFD将需求分为三类，分别是常规需求、期望需求和意外需求。
6.需求过程主要包括需求获取、需求分析、需求规格说明书编制、需求验证与确认等。
形式化说明技术按照形式化的程度，可以把软件工程使用的方法划分成非形式化，半形式化和形式化3类。
用自然语言描述需求规格说明，是典型的非形式化方法。
用数据流图或实体—联系图建立模型，是典型的半形式化方法。
所谓形式化方法，是描述系统性质的基于数学的技术，也就是说，如果一种方法有坚实的数学基础，那么它就是形式化的。
4.1 概述4.1.1 非形式化方法的缺点用自然语言书写的系统规格说明书，可能存在矛盾、二义性、含糊性、不完整性及抽象层次混乱等问题。
所谓矛盾是指一组相互冲突的陈述。
例如，规格说明书的某一部分可能规定系统必须监控化学反应容器中的温度，而另一部分（可能由另一位系统分析员撰写）却规定只监控在一定范围内的温度。
如果这两个相互矛盾的规定写在同一页纸上，自然很容易查出，不幸的是，它们往往出现在相距几十页甚至数百页的两页纸中。
二义性是指读者可以用不同方式理解的陈述。
例如，下面的陈述就是具有二义性：“操作员标识由操作员姓名和密码组成，密码由6位数字构成。
当操作员登录进系统时它被存放在注册文件中。
”在上面这段陈述中，“它”到底代表“密码”还是“操作员标识”，不同的人往往有不同的理解。
系统规格说明书是很庞大的文档，因此，几乎不可避免地会出现含糊性。
例如，我们可能经常在文档中看到类似下面这样的需求：“系统界面应该是对用户友好的。
”实际上，这样笼统的陈述并没有给出任何有用的信息。
不完整性可能是在系统规格说明中最常遇到的问题之一。
例如，考虑下述的系统功能需求：“系统每小时从安放在水库中的深度传感器获取一次水库深度数据，这些数值应该保留6个月。
”假设在系统规格说明书中还规定了某个命令的功能：“AVERAGE命令的功能是，在PC机上显示由某个传感器在两个日期之间获取的平均水深。
”如果在规格说明书中对这个命令的功能没有更多的描述，那么，该命令的细节是严重不完整的，例如，对该命令的描述没有告诉我们，如果用户给定的日期是在当前日期的6个月之前，那么系统应该做什么。
