1.1什么是软件危机它有哪些典型表现为什么会出现软件危机
答：软件危机是指在计算机软件开发和维护过程中所遇到的一系列的严重问题。
它的典型表现：1.软件开发成本高，成本难以控制。2.研究周期长，软件开发进度难以控制，周期拖得很长。3.正确性难以保证，软件质量差，可靠性难以保证。4.软件维护困难，维护人员和维护费用不断增长。5.软件发展跟不上硬件的发展和用户的要求。
它出现的原因一方面是由于软件生产本身存在着复杂性，另一方面是与软件开发所使用的方法和技术有关。软件不同于硬件，它是计算机系统中的逻辑部件而不是物理部件。管理和控制软件开发工程相当困难，软件是规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。目前相当多的软件专业技术人员对软件开发和维护还有不省糊涂观念，在实践过程中或多或少地采用了错误的方法和技术，这是使软件问题发展成为软件危机的主要原因。
1.2什么是软件工程它有哪些本质特性怎样用软件工程消除软件危机
答：软件工程是将系统化的，规范化的，可度量的方法应用于软件开发，运行和维护的过程，即将工程化应用于软件中。
基本原理:1.用分阶段的生命周期计划严格管理2.坚持进行阶段评审3.实行严格的产品控制4.采用现代程序设计的技术5.结果应能清楚地审查6.开发小组的人员应该少而精7.承认不断改进软件工程实践的必要性。
1.3什么是软件？它有什么特点？
它的特点是：1.抽象而非具体2.开发而非制造3.退化而非磨损4.定制而非基于构件5.不可见6.复杂7.易改变8.易复制
1.4什么是软件过程它与软件工程方法学有何关系
答：软件过程是为了开发出高质量的软件产品所需完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
软件过程定义了运用技术方法的顺序，应该交付的文档资料，为保证软件质量和协调软件变化必须采用的管理措施，以及标志完成了相应开发活动的里程碑。软件过程是软件工程方法学的3个重要组成部分之一。软件工程的基础是软件过程。
1.5什么是软件生命周期模型试比较瀑布模型、原型模型、增量模型和螺旋模型的优缺点，说明每种模型的适用范围。
答：软件生命周期模型是软件开发全部过程，活动和任务的结构框架，它能直观表达软件开发全过程，明确规定要完成的主要活动，任务和开发策略。也叫软件开发模型。
瀑布模型优点：有利于大型软件开发过程中人员的组织，管理，有利于软件开发方法和工具的研究，从而提高了大型软件项目开发的质量和效率。
缺点：1，开发过程一般不能逆转，否则代价太大2.实际的项目开发很难严格按
照该模型进行3.客户往往很难清楚地给出所有的需求，而该模型却要求如此4.软件的实际情况必须到项目开发的后期客户才能看到，这要求客户有足够的耐心。
适用范围：1.用户的需求非常清楚全面，且在开发过程中没有或变化很少2.开发人员对软件的应用领域很熟悉3.用户的使用环境非常稳定4.开发工作队用户参与的要求很低。
原型模型优点：1.可以得到比较良好的需求定义，容易适应需求的变化2.有利于开发与培训的同步3.开发费用低，开发周期短且队用户更友好。
缺点：1.客户与开发者对原型的理解不同2.准确的原型设计比较困难3.不利于开发人员的创新
适用范围：1.对所开发的领域比较熟悉而且有快速的原型开发工具2.项目投标时，可以以原型模型作为软件的开发模型3.进行产品移植或升级时，或对已有产品原型进行客户化工作时，原型模型非常合适。
增量模型优点：1.采用增量模型的优点是人员分配灵活，刚开始不用投入大量的人力资源
2.如果核心产品很受欢迎，则可增加人力实现下一个增量3.可先发部分功能给客户，对客户起到镇静剂的作用。
缺点：1.并行开发构件有可能遇到不能集成的风险，软件必须具备开放式的体系结构2.增量模型的灵活性可以使其适应这种变化的能力大于优于瀑布模型和原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。
适用范围：1.进行已有产品升级或新版本开发，增量模型是非常适合的2.对完成期限严格要求的产品，可以使用增量模型3.对所开发的领域比较熟悉而且已有原型系统，增量模型也非常适合。
螺旋模型优点：1.实际上的灵活性，可以再项目的各个阶级进行变更2.以小的分段来构建大型系统，是成本计算变得简单容易3.客户始终参与每个阶段的开发，保证了项目不偏离正确方向以及项目的可控性4.随着项目推进，客户始终掌握项目的最新消息，从而是他或她能够和管理层有效地交互。
适用范围：只适合于大规模的软件项目。
1.6怎么理解软件工程的概念及其意义？
答：软件工程是一门将理论和知识应用于实践的工程，它借鉴了传统工程的原则和方法，以求高效地开发高质量软件。它是一种层次化技术。
意义：从历史上讲，软件工程的作用，是为了克服上个世纪60年代出现的软件危机，这种危机表现为软件开发的成本大、进度慢、维护难和质量得不到保障。从当前来讲，软件工程的作用，就是告诉人们怎样去开发软件和管理软件。具体地讲，它表现在与软件开发和管理有关的人员和过程上。
1.7软件过程的通用过程框架包含哪两类活动？
答：一类是框架活动，还有一类是保护性活动。
1.8描述基于构件开发的思想以及目前的发展情况。
答：基于构件开发强调将被设计的系统分解成功能的或逻辑的构件，构件用定义好的接口进行通信。
1.9请简要说明RUP的9个规程（disciplines）及之间关系？
答：RUP的9个规程为：业务建模，需求，分析与设计，实现，测试，部署，配置与变更管理，项目管理以及环境。
对于一个大型项目，RUP九个规程的活动不可或缺，但对于有些项目可能不需要经过所有九个规程，在项目开发时需要对这些规程涉及的活动做具体的裁剪，以适应具体项目的开发需要。
1.10说明面向切面编程的特点，有什么优势？
答：该范型以一种称为切面的语言构造为基础，切面是一种新的模块化机制，用来描述分散在对象、类或函数中分离出来可以大大增强程序的模块性。
优势：他把特定领域问题的代码从业务逻辑中独立出来，业务逻辑的代码中不再含有针对特定领域问题代码的调用，业务逻辑同特定领域问题的关系通过切面来进行封装，维护。优势：面向切面编程的特点是针对业务处理过程中的切面提取，所面对的是处理过程中的某个步骤或阶段，以获得逻辑过程中各部分之间低耦合性的隔离效果，降低了耦合性。
1.11模型驱动工程中MDA的基本思想是什么？
Chapter2
2.1描述面向对象的基本概念和思想。
答：面向对象是一种以对象为基础，以事件或消息来驱动对象执行处理和程序设计技术。面向对象的基本思想是认为客观实体和实体之间的联系构成了现实世界的所有问题，而每
一个实体都可以抽象为对象。
2.2面向对象分析设计的基本思路和过程是怎样的？
答：分析过程主要包括理解、表达和验证。设计是把分析阶段得到的需求转变成符合成本和质量要求的、抽象的系统实现方案的过程。
过程：识别系统的用例和角色，进行系统分析并抽象出类，设计系统并设计系统中的类及其行为。
2.3面向对象程序设计中的概念主要包括哪些？分别阐述其主要思想。
答：对象：封装了数据和操作这些数据的代码的逻辑实体。
类：具有相同类型的对象的抽象。
封装：保证软件部分具有优良的模块性的基础。
继承：让某个类型对象获得另一个类型的对象特征。
多态：使不同内部结构的对象可以共享相同的外部接口，减少代码复杂度。
动态绑定：多态实现的具体形式，将一个过程调用与相应代码链接起来的行为。消息传递：使得对现实世界的描述更容易。
方法：定义一个类可以做的，但不一定去做的事。
2.4描述UML的主要概念和历史。
答：UML是统一建模语言，用来对软件密集系统进行可视化建模的一种语言。UML为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。
历史：Rumbaugh和Booch将Booch93和OMT-2统一起来，发布了UM0.8；后经过Booch，Rumbaugh和Jacobson的共同努力，发布了UML0.9和UML0.91，并将UM重命名为UML。97年，Rational组织成立了UML合作者联盟，以完善、加强和促进UML的定义工作。2000年启动了UML2.0标准的制定工作。
2.5RUP是什么？应用RUP对软件开发有什么意义？
答：RUP（RationalUnifiedProcess）是统一软件开发过程，是一个面向对象且基于网络的程序开发方法论。
应用RUP为软件开发提供了一个模版，使得软件开发过程规范化，统一化。
Chapter3
3.1为什么要进行业务建模？业务建模适用什么场合的软件项目开发？
答：进行业务建模的原因：业务人员、IT技术的业务知识、IT技术知识彼此之间存在着较大的差异，而规模较大的软件开发项目是不太可能让所有参加项目的IT技术人员都先熟悉
业务知识而再进行开发的，所以需要通过“业务建模”将“业务需求”准确地转换为IT技术人员所熟悉的“软件需求”。
适用场合：规模较大的软件项目开发。
3.2业务建模可以分哪些工作流进行？
答：评估业务状态、描述当前业务、定义业务、探索流程自动化、开发领域模型。
3.3什么是领域模型？与业务模型的关系是什么？
答：领域模型：领域模型是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。领域模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。
关系：开发领域模型是一个备选活动，领域模型是业务分析模型中独立的一部分，注重于说明对于业务领域很重要的概念、产品、可交付成果和事件。这样一个模型仅描述业务中的重要信息，并不包括人员承担的职责。
3.4什么是系统上下文？明确目标系统的上下文有什么意义？
答：系统上下文：指的是目标系统、与之交互的用户和外部系统。
意义：业务建模作为软件需求的前一阶段，了解目标系统的上下文是很有必要的，便于确定目标组织和业务范围。
3.5什么是业务涉众？业务涉众可能来自哪些方面？
答：业务涉众：所有跟目标业务有利害关系的人。
方面：可能来自目标组织内部及目标组织外部且跟目标组织有关系的人和组织。
3.6什么是业务愿景？怎么理解业务愿景的重要性？
答：业务愿景：定义业务建模工作所针对的一组目标。
重要性：要了解组织的业务过程，对业务进行建模，首先必须理解组织的共同愿景，业务建模时期的重要任务就是确定项目涉众的共同愿景，而了解最有影响力的涉众的愿望和目标是非常重要的环节。所以业务愿景对整个业务建模过程来说是十分关键和重要的。
3.7业务建模的作用是什么？哪些人和组织是潜在的业务执行者？
答：作用：
（1）了解目标组织（将要在其中部署系统的组织）的结构和机制；
（2）了解目标组织中当前存在的问题并确定潜在改进的可能性；
（3）确保客户、最终用户、开发人员和其他各方就目标组织达成共识；
（4）导出支持目标组织所需的系统需求；
（5）了解要部署的软件系统将如何融入组织。
潜在的业务执行者：客户、合作伙伴、供应商、权威机构（法律、法规等制订机构）、子公司、所有者和投资者、业务以外的信息系统等。
3.8结构化业务用例的三种关系是什么？
答：三种关系：包含关系、扩展关系、泛化关系。
3.9业务用例的包含与扩展关系、包含与泛化的区别是什么？
答：包含与泛化的区别：（1）对于用例泛化关系，子用例的执行取决于父用例（重用部分）的结构和行为，而在包含关系中，基本用例的执行只取决于包含用例（重用部分）所执行的功能的结果。（2）在泛化关系中，子用例的用途和结构是相似的，而在包含关系中，重用同一个包含用例的基本用例可能有完全不同的用途，但需求执行相同的功能。
包含与扩展的区别：（1）包含关系：如果基本用例的某个部分代表一个功能，而业务用例只依赖于本功能的结果，而不是产生结果的方法，那么可以将这部分分离出来，形成一个附加用例。使用包含关系，将附加部分明确包含于基本用例中。包含关系将基本用例和包含用例连接起来。
(2)扩展关系：如果基本用例的一部分是可选的，或对于理解该用例的主要目的来说不是必需的，那么可以将这部分分离出来，形成一个附加用例，以简化基本用例的结构。利用扩展关系，将附加部分隐含地包含于基本用例中。扩展关系将扩展用例与基本用例连接起来。
3.10业务分析模型的作用是什么？与业务用例模型的之间是什么关系？
关系：业务用例模型是从与客户和业务流程对应的业务执行者和业务用例的角度，对业务进行描述。业务用例模型包括工作流程说明，此说明确定完成了那些工作。所以业务用例模型描述在业务执行者和业务之间发生了什么，对于业务结构或如何实现业务用例不作任何假设。而业务分析模型就是用于描述如何执行业务用例，并具体定义业务提供的服务，内部业务工作者及其使用的信息，将它们的结构化组织描述为独立的单元，定义业务工作者如何通过交户来实现业务用例中所描述的行为。
3.11
（c）
2.以医院为研究对象，请描述医生、病历的性质分别是()
(a)businessactor、businessworker
(b)businessworker、businessactor
(c)businessactor、businessentity
(d)businessworker、businessentity
3.12综合案例分析-餐厅点菜业务分析
某餐厅的点菜服务流程与规范如下：
1.递上菜单
（1）客人入座后，服务员询问客人需要什么茶水。准备好茶水后，按“女士优先，先
宾后主”的原则从右边为客人斟上茶水。
（2）将菜单打开第一页，按照“女士优先”原则，用双手从客人右侧将菜单送至客人手中，然后站在客人斜后方能观察客人面部表情的地方，上身微躬。
2.推荐介绍酒店菜品
（2）在客人翻看菜单时，应及时向客人简单介绍菜单上的菜，回答客人的询问。
（3）向客人介绍厨师长今日特别推荐的菜品、其他的特色菜、畅销菜和高档菜等菜品，并介绍其样式、味道、温度和特点。
3.接受点菜
（1）服务员先在点菜单上记下日期、本人姓名及台号、就餐人数等。
（2）客人点菜时，应注视客人，听清客人点的菜名，适时帮助客人选择菜品和主动推介菜品，准确地记录菜名。
（3）对于特殊菜品，应介绍其特殊之处，并问清客人所需火候、配料及调料等。
（5）若客人有特殊要求，应在点菜单上清楚注明，并告知传菜服务员。
4.复述点菜内容
（1）客人点菜完毕后，服务员应清楚地重复一遍所点菜品内容，并请客人确认。
5.分送点菜单
（1）服务员将点菜单的第一联送至收银处。
（2）将点菜单的第二联送至厨房。
（3）将第三联给客户，第四联交给传菜员、值台服务员留底备查。
根据案例的描述，请你完成下列任务：
1.分析餐厅的点菜业务，建立点菜业务模型。
这项业务的业务涉众：外部涉众：客人，
内部涉众：服务员，收银处，厨房，值台服务员
分析点菜业务模型：
业务执行者为：客人
业务用例是：入座，推荐菜品，点菜，确认内容，分送菜单，上菜
2.用活动图描述客人点菜的活动。
3.分析点菜业务模型，找出有哪些业务工作者和业务实体，并用交互图来说明之间的通信和交互关系。
业务工作者为：服务员,收银处，厨房，值台服务员
业务实体为：菜单，点菜单
Chapter4
4.1需求的类别有哪些？
答：需求可分为功能性需求和非功能性需求。
功能性需求规定了系统无需考虑物理约束而必须能够执行的动作，描述支持用户目标、任务或活动的系统行为（功能或服务）。
非功能性需求是功能性需求之外的需求，包含质量和约束，它们仅仅说明系统或系统环境的属性。
4.2怎么理解文中FredBrooks关于需求的那段话？
构建软件系统最难的部分是确定要构建什么（即系统需求）。相比其他工作，如果这个工作做错，会严重影响将产生的系统，也更难在以后矫正。
答：需求工作对于整个软件系统来说是非常重要的，它是实现和测试的先启阶段，需求建模解释如何理清涉众的请求及如何把这些请求转化为一组需求工作产品，确定要建系统的范围，提供系统必须做的详细要求。此阶段是后续工作以及整个系统的基础和关键，一旦这个阶段出现问题，将会直接影响到后续工作的正常顺利进行，而如果想要在以后改，代价是非常大的，并且也难纠正。
4.3系统用例模型可以描述什么方面的需求？补充规约主要补充哪方面的需求？
答：系统用例模型可以描述设计软件系统方面的需求，参与者与软件系统的交互，在系统用例说明中书写足够详细的事件流。
补充归约主要补充那些无法在用例中记录的需求。包括：捕捉无用例归约的功能性需求，捕捉系统资量，捕捉约束，捕捉符合性需求，捕捉文档需求。
4.4什么是系统执行者？如何寻找潜在的系统执行者？
答：系统执行者：是指与目标系统交换数据的任何对象，是在系统之外，透过系统边界与系统进行有意义交互的任何事物。执行者可以是用户、外部硬件或其它系统。
满足一个或多个上面这些范畴的任何个人、小组或事物有可能就是执行者。
4.5如何理解系统执行者与业务执行者、业务工作者的关系？
答：业务执行者是指某人或某物与业务进行交互时所担任的角色，它是指在业务之外和业务交互的人、组织或事物。
业务工作者代表在业务中进行操作的人、软件或硬件的抽象。它代表业务中的一个或一组角色。
系统执行者：是指与目标系统交换数据的任何对象，是在系统之外，透过系统边界与系统进行有意义交互的任何事物。执行者可以是用户、外部硬件或其它系统。
关系：系统执行者是针对软件系统来说明的，而业务执行者和业务工作者是针对业务来说明的，系统执行者和业务执行者含义相似，只是所在的描述范畴不一样。
4.6请分析用例中的包含关系和扩展关系的相似与区别？
答：相似：都是如果用例包含的一段行为片段可以用于其他用例，则将这段行为片段归到“包含用例”或“扩展用例”中，形成一个新的用例，原始用例就成为基本用例，对“包含用例”和“扩展用例”分别有包含关系和扩展关系。
区别：（1）扩展用例是可选的，而包含用例不是可选的；（2）基本用例没有扩展用例是可以完成的，但没有包含用例则不能完成；（3）扩展用例的执行是有条件的，而包含用例没有；（4）扩展用例会改变基本用例的行为，而包含用例不会。
4.7简单说明把用例组织到包中有什么好处。
答：用例包是用例、执行者、关系、图和其他包的集合，可以通过将用例模型分成更小的部分来结构化用例模型。这样可以使得具有大量元素的用例模型中的用例结构化，同一包中的用例彼此之间都有某种关系，更加清楚明了，便于以后模型的分析和使用。
4.8用例详细描述中有哪三种事件流，分别表示什么场景？
答：三种事件流：主事件流、分支事件流和异常事件流。
主事件流：在描述正常过程时列出执行者和系统之间相互交互或对话的动作序列。当这种对话结束时，执行者也达到了预期的目的。
分支事件流：也可促进成功地完成任务，但它们代表了任务的细节或用于完成任务的途径的变化部分。
异常事件流：不符合用例流正常或基本行为，引起任务不能顺利完成。
4.9什么是软件需求规约（SRS）？
答：软件需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。
4.10如何理解界面原型在需求建模中作用？
答：可以处理模糊需求，开发者和用户可充分通信，降低开发风险。
静态界面原型：供分析人员与用户进行进一步交流和沟通，通过这种可视化方法，使双方逐步就明确系统需求达成共识。
交互式界面原型：便于用户可以操作，展示实际系统效果。
4.11选择题
1.如图4.11-1所示.A1、A2和A3是什么(单选题)(C)
(a)role
(b)Actress
(c)Actor
(d)User
2.如图4.11-1中，下面哪个语句是正确的(多选题)(BCD)(a)A3可以使用UC4与系统交互。
(b)Al可以使用UCl和UC4与系统交互。(c)A3,Al与A2不同。
(d)UC3是没有步骤的抽象用例。
3.如图4.11-1所示,下面哪个语句是正确的(多选题)(CD)(a)UC5是UC4的补充部分。(b)UC4是UC5的可选部分。(c)UC1是没有用的。
(d)UC2是UC4的可选部分。(e)UC4是UC2的补充部分。
4.12综合案例分析-餐厅智能移动终端无线点菜系统需求
根据第3章的练习3.11综合案例分析的业务描述，来分析点餐系统的需求。
现在该餐厅为了提高管理效率，避免在点菜过程中出现掉单、飞单,错单、舞弊等现象，计划采用智能移动终端无线点菜系统。无线点菜系统的要求：1.即时点菜
服务员随时随地地使用智能掌上电脑系统，为顾客点菜、加菜，系统自动将数据传到后台和分布在厨房与前台的打印机上。打印机立刻打印所点的菜单。2.无需布线
系统前台使用无线网络与掌上电脑技术，使前台使用者可以在营业大厅内随意走动，自由的使用系统为顾客服务，无需在大厅中布置任何网络线路，从而避免影响餐厅的整体环境。3操作简单
传送距离可达100米，室外传送距离可送300米。根据案例的描述，请你完成下列任务：
1.建立无线点菜系统的用例模型（找出所有的系统Actor和UseCase）；
用例模型
系统Actor：服务员、客户、经理
Usecase：点菜服务、自助点菜、统计
2.对用例进行详细描述，包括前置条件、后置条件，以及各事件流，并用泳道图画出用例对应的事件流。前置条件：
服务员有掌上电脑系统，厨房与前台有打印机，在传输距离之内后置条件：
打印机打印所点菜单事件流：主事件流：1.顾客点菜；
2.服务员用掌上电脑及菜单；3.厨房和前台打印机打印菜单分支事件流：无
异常事件流：
步骤2后步骤3未接收，无法打印，返回步骤
2
3）.打印菜单用例描述：用例名称：打印菜单
用例描述：打印点菜内容参与者：打印机前置条件：点菜完成
后置条件：打印机打印菜单给后台，厨房和前台主事件流：1.系统发送点菜单至打印机
2．打印机接收菜单3．打印机打印菜单分支事件流：无异常事件流：无泳道图：
Chapter5
5.1如何理解分析与设计的联系？
答：“分析”是指“做什么”，强调对问题的调研而不是如何确定解决方案，重点集中在需求和应用领域上；而“设计”指“怎么做”，强调的是问题的逻辑解决方案，即系统怎样才能满足需求，重点转移了要产生软件的结构上。但由于分析与设计是把用户需求转化为实现的桥梁，分析和设计自始至终可以用相同的技术和类似的表示方法，它们之间的界限很难划清，且没有太多意义。
5.2分析设计包括哪些工作流程？
答：分析和设计过程是一个不断迭代优化的过程。
包括：执行体系结构合成；定义候选体系结构；优化体系结构；分析行为；设计构件；设计数据库；服务识别；服务规范。
5.3分析建模的元素分哪几类？具体是什么？答：分析建模的元素分为四大类，分别是：（1）基于场景元素：
这类元素包括：用例文本、用例图、活动图和泳道图等；（2）面向流的元素：
这类元素包括数据流图、控制流图、处理叙述等；（3）基于类的元素：
这类元素包括类图、分析包、CRC模型、通信图等；（4）行为的元素：
这类元素包括状态图、顺序图等。
5.4分析模型的静态模型的用途是什么？静态模型的元素有哪些？
答：用途：通过分析，可以将业务需求模型和系统需求模型转化为系统可以处理的对象模型，并给出对象的基本属性和对象间相互关系。
分析模型中静态模型主要的元素是基于类的元素，包括：分析包：模型中的包，表示层次结构。类：模型中的类，由包所拥有。关系：模型中的关系，由包所拥有。
图：模型中的类图、协作（通信）图，由包所拥有。
5.5动态模型的类被分为哪三类？分别在系统中承担什么职责？答：边界类、控制类和实体类。
边界类：是用来对系统环境及其内部工作之间的交互建模的类。这样的交互涉及转换和转移事件，并注释系统表示中的更改（例如界面）。
控制类：是用于对特定于一个或一些用例的控制行为建模的类。实体类：是用来对必须存储的信息及关联行为建模的类。
5.6按照设计模型的不同层次和功能，设计元素可以分哪些方面？
答：（1）体系结构元素；（2）构件级元素；（3）接口/界面元素：用户界面、构件接口、系统接口；（4）数据元素：数据库设计、数据结构设计；（5）部署级元素。
5.7软件模式有哪三个层次？分别说明之。
答：一般地，软件模式可划分为三个层次：体系结构模式，设计模式和代码模式。
体系结构模式：描述软件系统里的基本的结构组织或纲要。体系结构模式提供一些事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。
设计模型：提供一种提炼子系统或软件系统中的构件或者两者之间关系的纲要设计。设计模型描述普遍存在的在相互通讯的构件中重复出现的结构，这种结构解决在一定的背景中的具有一般性的设计问题。
5.8什么是软件体系结构？简述软件体系结构的设计重要性。
答：软件体系结构：是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工，数据构件是被加工的信息，连接构件把体系结构的不同部分组组合连接起来。这一定义注重区分处理构件、数据构件和连接构件，这一方法在其他的定义和方法中基本上得到保持。
重要性：软件体系结构设计是高阶层的设计，定义了包（子系统），包括包之间的依赖关系和主要的通信机制。自然清晰和简单的结构是目标，避免几乎没有依赖或双向依赖。
5.9试说明软件体系结构的演变过程。
答：（1）单机系统：是指只需装在一台电脑上，同时只能一个用户使用的系统，没有服务器概念，很多早期的软件都是单机系统，与分布式系统区别。
（2）客户机/服务器（两层）结构：由服务器提供应用（数据）服务，多台客户机进行连接。
（3）浏览器/服务器（B/S）结构：在当前Internet/Intranet领域，“浏览器/服务器”结构是非常流行的客户机/服务器结构。这种结构最大的优点是：客户机统一采用浏览器，这不仅让用户使用方便，而且使得客户机不存在安装维护问题。
（4）三层结构：三层结构的客户机/服务器模型是一种先进的协同应用程序开发模型，不是物理上，而是逻辑上将客户机/服务器系统中各种各样的部件划分为三“层”服务，它们共同组成一个应用程序，这三层服务包括：数据访问层、业务逻辑层和表示层。
5.10如何理解体系结构风格和模式的本质？
答：体系结构风格：定义了结构组织模式的系统族，用来表达一组协作的约束，使得对公共约束的特征进行沟通变得更加容易，被用作一种进行抽象的方法，而不是代表一种个性化的设计。
体系结构模式：是对某类问题域给出的一套软件结构的解决方案，描述了软件系统基本的结构化组织方案，是处理特定问题的高效、成熟的模板。
5.11什么是软件框架？与模式的区别是什么？
答：软件框架：软件开发过程中提取特定领域软件的共性部分形成的体系结构，不同领域的软件项目有着不同的框架模型。
区别：模式提供一种思想方法的指导，应用模式的指导，可以帮助设计人员做出一个优良的设计方案，达到事半功倍的效果。但模式不体现为程序，如MVC是一种体系结构的模式，对于同一软件体系结构，可以通过多种框架来实现。如Struts是实现MVC模式的著名框架，但不是唯一的。
5.12RUP的4+1视图分别是什么？答：概括而言，RUP的4+1视图是：（1）逻辑视图：设计的对象模型。
（2）进程视图：捕捉设计的并发和同步特征。
（3）实现视图：描述了在开发环境中软件的静态组织结构。
（4）部署视图：描述了软件到硬件的映射，反映了分布式特征。
（5）用例视图：该视图是其他视图的冗余（因此“+1”）。它包含用例和场景。
5.13什么是设计模式？
答：设计模式：是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。
5.14简要说明类的详细设计分哪几步来实现？
答：（1）使用设计模式和机制：使用适合设计的类或功能、符合项目设计指南的设计模式和机制。
（2）创建初始设计类：为指定为此任务输入的分析类创建一个或多个初始设计类，并指定跟踪依赖关系。包括设计边界类、设计实体类和设计控制类。
（3）定义属性：类的属性为类实例提供信息存储，并经常用于代表类实例的状态。类本身保持的任何信息都是通过其属性完成的。
（4）确定持久类：需要在永久介质上存储其状态的类被称为持久类。
（5）定义操作：类的操作是类的行为特征或动态特征，表示类提供的服务。（6）定义方法：方法制定操作的实现。
（7）定义状态：对于一些操作，操作的行为取决于接受者对象所处的状态。
5.15什么是实体类与持久类？说说两者之间区别与联系。
持久类：需要在永久介质上存储其状态的类。
区别和联系：持久类是针对于hibernate对数据库的映射来说的，持久类=实体类+xml或注解配置；而实体类就是一个javabean类，有属性，get、set方法，以及一些简单处理的方法。
5.16开发物理数据库设计的详细步骤有哪些？
答：（1）定义域；（2）创建初始物理数据库设计元素；（3）定义引用表；（4）创建主键和唯一性约束；（5）定义数据和参照完整性实现规则；（6）将数据库设计反向规范化来为性能进行优化；（7）优化数据访问；（8）定义存储器特征；（9）设计存储过程来将类行为分发给数据库。
5.17进行界面设计时分析用户的特征有什么作用？
答：描述某些（人类）用户的特征，这些用户将与系统交互来执行当前迭代中考虑的需求。要重点描述主要用户，因为交互的大部分涉及这些用户。该信息对于下面的后续步骤很重
要。
与系统分析人员协作，确定是否需要对用户（主要的执行者）描述做出更改，来反映特征描述。
5.18选择题
1.如图5.18-1所示.A、B和C是什么对象(单选题)(D)(a)A是实体.B是控制.C是边界(b)A是边界.B是实体.C是控制(c)A是实体，B是边界，C是控制(d)A是控制，B是实体.C是边界(e)A是边界.B是控制，C是实体(f)A是控制，B是边界.C是实体
2.在UML图中，哪个图用于显示在对象之间传送的消息(多选题)(CE)(a)活动图(b)对象图(c)通信图(d)状态机图(e)顺序图(f)部署图
(c)interfaces(d)projectscope
5.19综合案例分析-餐厅PDA无线点菜系统分析与设计
2.画出系统分析动态模型中的顺序图（要体现边界类、控制类和实体类之间通信内容）。3.从上面的顺序图中解析出实体类的操作，画出初步的设计类图。4.选择Ｂ／Ｓ结构，为系统设计相应的界面。5.设计相应的数据库表结构
答：1.主要的概念实体：客人，点菜单，点菜记录，打印机，服务员，菜品分类
实体类图：
2.
3.实体类操作：1）客人：输入已点菜品（）
2）点菜记录：记录已点菜品（）；确认点菜记录（）；发送点菜记录（）3)打印机：打印点菜记录（）