《Rose实验心得》由会员分享，可在线阅读，更多相关《Rose实验心得（3页珍藏版）》请在金锄头文库上搜索。
1、Rose实验心得Rose实验心得 1、Rational Rose使用心得 建模是人类对客观世界和抽象事物之间联系的具体描述。在过去的软件开发中，程序员利用手工建模，既耗费了大量的时间和精力又无法对整个复杂系统全面准确的描述，以至于直接影响应用系统的开发质量和速度。而今，我们不再为建模苦恼。 Rational Rose 是一个完全的，具有能满足所有建模环境需求能力和灵活性的一套解决方案。Rose允许开发人员，项目经理，系统工程师和分析人员在软件开发周期内在将需求和系统的体系架构转换成代码，消除浪费的消耗，对需求和系统的体系架构进行可视化，理解和精练。通过在软件开发周期内使用同一种建模工具可以确保
2、更快更好的创建满足客户需求的可扩展的、灵活的并且可靠的应用系统。 面对现代社会庞大而繁杂的信息事务，人们渴望使信息变得简单易懂。无论何种复杂程度的工程项目，设计者都是从建模开始的，设计者通过创建模型和设计蓝图来描述系统的结构。在软件工程中，Ratioal Rose能够把模型与实际应用紧密地联系起来。通过模型与代码之间的映射，可以直接为不同的程序开发环境生成系统结构的框架，通过建立模型和代码间的映射，可以确保代码改进时模型也随之更新了，而且通过模型与代码间自动连接，建模工具可以确保良好的设计实施。 Rational Rose与传统的两层结构相比，它支持三层结构方案，从而使它有着更多的优点： 对应
3、用结构任意一层做出修改时，只对其它层产生极小的影响。 固有的可塑性，三层既可共存于单机之中，也可根据需要相互分开。 公用代码数据库使事务处理规则在系统中共享。 Rational Rose可视化开发工具与多种开发环境无缝集成等。 Rational Rose也可支持企业级数据库。 Rational Rose支持绝大多数软件工程常见的个人/公共工作平台。直到所编制软件共享之前，我们都可以在个人工作平台修改自己的源代码和已建立的模型。 总之，通过这几周对Rational Rose的了解和初步的学习，使我掌握了关于Rational Rose的一些基本知识，这对我以后的进一步学习以及对以后就业都会起到很大
4、的帮助。 安装时出现的问题： 1、安装时出现需要导入证书的情况，需要再下载证书 2、一些.dll文件丢失，其实并没有丢失，只是需要重新配置环境变量 Rose画图时出现的问题 在画活动图时，分岔所联的多条关联线尾端聚集在分岔的同一部位，不能分散。 需求分析问题 需求分析阶段的常见问题是：需求分析不够深入，对问题域没有仔细研究，急于进入设计阶段。造成这种问题一方面是因为项目管目赶进度以及存在于管理人员头脑中的根深蒂固的想法：任何时候不能让任何人员闲着，另外很大的原因是很多人不知道如何进一步深入研究问题域。需求分析阶段不仅要列出系统的use case，更重要的是要列出use case的输入输出和例外
5、情况等，以及问题域中的对象之间的静态关系和动态关系，如对象间的包含关系，继承关系，调用关系等。 需求分析阶段另外一个常见的问题是常常将需求分析等同于数据库设计，需求分析阶段定义的是系统作什么，而不是怎么做，需求分析的结果应该与具体的技术实现无关。数据库设计是技术实现的细节，应该尽可能的推迟技术细节的决策，不应该使技术细节束缚了我们对系统需求的理解。需求分析阶段应该从用户的角度对系统建模，不应将大量的技术细节暴露给用户，导致系统易用性差。 需求分析阶段可以进一步细分为业务需求分析阶段和系统功能需求分析阶段。在很多研发性质的系统中，不注重业务需求分析，只有系统功能需求分析，导致开发人员知其然不知其
6、所以然。 系统功能规范文档与业务需求文档的重要区别有以下几点： 内容不同：系统需求分为功能需求和非功能需求，功能需求进一步分为业务功能需求和非业务功能需求。系统需求规范文档除了包括业务需求文档中的业务功能需求，功能规范文档需要增加以下内容：系统的非业务功能需求，由于业务需求由计算机系统实现而产生的功能需求，如系统需要系统管理员管理，系统管理员的角度产生一些非业务功能需求，另外需要描述系统非功能需求：数据量，性能要求，响应速度，可用性要求，可靠性要求，界面语言要求等等。 阅读的对象不同：业务需求文档是用来与业务人员交流，功能规范文档是开发人员开发的依据 使用的语言不同：业务需求文档使用自然语言书写，而功能规范文档使用比较严谨的语言，如：uml书写 对编写人的要求不一样：业务需求编写人员只需要对业务系统熟悉，系统规范由系统架构师完成 体现系统架构师价值的地方是编写系统规范文档和业务层设计, 系统规范文档是下一步界面设计，业务层设计和数据库设计的依据，表示层，业务层，数据访问层之间是相互联系的，它们之间的关系应该在系统规范文档中找到。
