• 《需求工程——软件建模与分析》读后感之三


      在需求获取中,需求工程师可以得到关于问题域的描述信息,可以得知相关者对软件系统的期望。可是,上述这些被记录在获取笔录上的内容都还是属于现实世界的信息,它们是用户和其他相关者对现实世界的理解与描述,使用的是实际业务的表达方式。换句话说,需求获取中得到的信息仅仅是解释了用户等现实世界群体对软件系统的期待,它们还不是开发者能够立即加以实现的解决方案。而且,开发者通常并不是来自业务世界,所以他们无法从杂乱的获取笔录中轻易地把握到用户表达某个信息时内容的真实意图,为其创建软件解决方案的工作也就更是无从谈起了。

      总的来说,需求获取得到的信息和需求开发应该建立的软件系统解决方案之间有着很大的差距。需求分析就是用来解决这个差距的需求工程活动。需求分析的根本任务是获取用户的理解和问题的描述,通过需求分析建立分析模型,创建解决方案,从而决定需求开发目标。

      常见的需求分析技术有上下文图、数据流图、实体联系图、功能实体矩阵、功能分解图、过程依赖图、用例图、类图、交互图、活动图、对方约束语言、微规格说明、数据字典、状态转换图等。

      之前我们已经学过上下文图了。它的主要作用是描述系统与环境中外部实体之间的界限和联系。他从现实世界的角度说明了系统的边界和环境,并确定了所有的输入和输出。数据流图也是经常用到,它从数据传递和加工的角度,描述了系统从输入到输出的功能处理过程。运用功能分解的方法,用层次结构简化处理复杂的问题。像用例图、类图、交互图等,在以前学习UML时学过,不过很少使用。他们的功能不再详述。

      需求分析的技术多种多样,学习所有这些技术并不是一件容易的事情。对每一种技术而言,不仅需要广泛的阅读,而且还需要进行很多的实践,才能很好地把握每种技术的内涵。实践表明,需求工程师在建模与分析中遭遇的最大的问题不在于某些具体技术的掌握问题,他们有足够的能力学习和掌握每一种技术。对需求分析技术的综合运用才是需求分析人员最大的困难。

      一方面,每一种需求分析技术都有自己的特点。这是它们具有在应用上独特性,即每一种分析技术都有自己适合的应用和不适合的应用。如果对需求分析技术的应用特性判断错误,那么即使对该技术掌握的再好也不可能很好地完成建模任务。另一方面,复杂的应用需要多视角的建模处理。没有哪种需求分析技术能够单独完成对复杂问题的建模任务,之后通过多种需求分析技术的有机结合与集成才能充分的描述复杂应用。

      传统的分析方法是毫无章法的,虽然传统分析也能取得一定的成功,但是它的工作过程缺乏结构、不可重复、不可测量和主观臆断。传统分析产生的分析结果往往会出现很多问题。在传统分析方法之后,人们想办法尝试使用相对形式化的模型来建立标准化的方法,形成了结构化分析方法。

      结构化分析方法把现实世界描绘为数据在信息系统中的流动,以及在数据流动过程中数据向信息转换。他帮助开发人员定义系统需要做什么(处理需求),系统需要存储和使用哪些数据(数据需求),需要什么样的输入和输出,以及如何把这些功能结合在一起来完成任务。

      对结构化分析方法改进之后产生了信息工程方法,它采用了结构化方法的各种技术,并根据信息系统开发的特点进行更为严格、全面的改进,关注策略规划、数据建模和自动化工具。信息工程主要从信息角度来开发系统,而不像结构化方法那样从功能角度考虑问题。客观世界被描述为数据和数据属性及其相互关系。信息工程方法的局限性在于它是为信息系统的开发而制定的,所以应用范围是有限制的。

      面向对象分析方法任务系统是对象的集合,这些对象之间相互协作,共同完成系统任务。也就是说面向对象分析方法和结构化分析方法有着完全不同的建模思路,前者是以对象为基础,后者是以功能和数据为基础。

  • 相关阅读:
    深入浅出SQL Server 2008 分区函数和分区表
    数据库的恢复模式
    Windows Server 2003网络负载均衡的实现(转)
    SharePoint2010网站备份还原简单介绍
    HTTP协议详解(转)
    SharePoint 2010之LINQ与SPMetal
    moss 自定义文档库文档图标
    SharePoint 2010环境搭建
    C#中的yield关键字
    .NET开发中你可能会用到的常用方法总结(添加ing...)
  • 原文地址:https://www.cnblogs.com/zrdm/p/4924600.html
Copyright © 2020-2023  润新知