参考答案：在初步的业务需求描述已经形成的前提下，基于UML的需求分析大致可分为以下几个步骤。
·利用用例及用例图表示需求。从业务需求描述出发获取执行者和场景；对场景进行汇总、分类和抽象；形成用例；确定执行者与用例，用例与用例图之间的关系，生成用例图。
·利用包图及类图表示目标软件系统的总体框架结构。根据领域知识、业务需求描述和既往经验设计目标软件系统的顶层架构；从业务需求描述中提取“关键概念”，形成领域概念模型；从概念模型和用例出发，研究系统中主要的类之间的关系，生成类图。
上述两个步骤并没有时序关系，它们可以并行展开。其中，顶层架构的主要目的是为后续的分析和设计活动建立一种结构和分划，以便开发人员在不同的开发阶段，以及同一开发阶段的不同开发人员，能够聚焦于系统的不同部分。顶层架构是分析和设计的阶段成果的承载体。随着开发过程的推进，框架中的内容不断丰富和翔实，最终演进为完整的面向对象的软件结构。UML包图是表示项层架构的适当机制。
建立软件系统顶层架构的基本方法是，结合实际需求，从既往的架构设计经验模型中选取适当者，再进行微调或局部改造。目前有以下几种主要的架构模式。
(1)流程处理模式。流程处理系统以算法和数据结构为中心，其系统功能由一系列的处理步骤构成，相邻的处理步骤之间以数据流通管道相互连接。该模式仅适合于采用批处理方式的软件系统，不适合于交互式系统。
(2)客户/服务器模式。客户端负责用户输入和处理结果的呈现，服务器端则负责后台的业务逻辑处理。
(3)模型—视图—控制器(MVC)模式。该模式将整个软件系统划分为模型、视图和控制器3个部分。模型负责维护并保存具有持久性的业务数据，实现业务处理功能，并将业务数据的变化情况及时通知视图；视图负责呈现模型的业务数据，响应模型变化通知，更新呈现形式，并向控制器传递用户的界面动作；控制器负责将用户的界面动作映射为模型中业务处理功能并实际调用之，然后根据模型返回的业务处理结果选择新的视图。MVC模式特别适合于分布式应用软件，尤其是Web应用系统。
(4)分层模式。该模式将整个软件系统分为若干层次，最顶层直接面向用户提供软件系统的操作界面，其余各层为紧邻其上的层次提供服务。层次划时分的主要原则是，较易变化的软件部分(例如用户界面和与业务逻辑紧密相关的部件)置于较高层次，较稳定的软件部分(例如公共的技术服务部件)则位于较低层次；每一层次尽量只访问其紧邻下层提供的服务，避免越级访问，尤其要避免逆向访问(上层模块为下层模块提供服务)；在许多情况下，可以将目标软件系统的外部接口置入较低层次，目标软件系统其余部分对外部系统的访问或操作均通过这些外部接口所提供的公共服务来完成。分层模式可以有效地降低软件系统的耦合度，因此其应用十分普遍。
在全面了解软件架构样式的前提下，对于具体的应用需求而言，影响顶层架构选取的主要因素在于系统架构师的经验及他们对每种架构样式与当前软件项目之间匹配程度的判断。事实上，大型软件的顶层架构往往需要复合使用多种架构样式。例如，整个目标软件系统采用分层结构，在系统的不同层次内再分别使用适宜的其他种类的架构模式。
在确立顶层架构的过程中，需要综合考虑以下因素。
(1)架构中包的数量。原则上，如果每个包中包含的软件元素(例如类)的数量过多，应考虑将其进一步细分；如果过少，则说明架构过早地陷入了细节，架构划分返工的可能性较大，同时也不合理地限制了后续分析和设计活动的自由空间。
(2)架构中包之间的耦合度。包之间的依赖关系和连接关系应尽量简单、稀疏，例如，在分层结构中，通常要求某一层中的软件元素只与同层及相邻下一层的元素之间存在依赖关系。
(3)软件元素的稳定性。要尽量抽取不稳定的软件元素之中相对稳定的部分，将不稳定的软件元素分类聚集于少数几个包中，以提高软件系统的可维护性。
(4)软件元素的必然性。可以将可选功能和必须实现的功能分置于架构中不同的包或子包之中。
(5)作为软件系统运行环境的物理网络拓扑。根据软件元素在分布环境的部署情况，区分顶层架构中的包，可以使包之间的消息传递与物理节点之间的通信相吻合，使后续的分析和设计活动受益于顶层架构中明确定义的通信关系。
(6)软件元素的安全和保密级别。根据安全访问的权限划分顶层架构中的包或者子包。
(7)开发团队的技术专长。根据开发人员在问题领域和软件技术领域不同的专长划分顶层架构中的包，使每个包都能分配给最适合的开发人员进行后续的分析、设计、编码和测试等，从而有利于并行开发。