`
taomujian
  • 浏览: 111029 次
  • 性别: Icon_minigender_1
  • 来自: 安徽-合肥
社区版块
存档分类
最新评论
文章列表
近日在做个原型的是否发现一个以前一只没有注意到的问题,当我在AS类中动态的添加一个用MXML写的组件的时候,该组件内的其他组件(按钮啊什么的)虽然可以获取到ID,但是通过调试发现对象的引用是空的(在组件里通过AS世界实例化的对象是正常的),也就是说FLEX只是定义了那些子组件并没有去实例化他们,当我将组件添加到页面显示后组件内的子组件全部被实例化。 例如:  在点击按钮弹出一个页面,但是在页面加载到弹出页面之前我就派发了通知注册该组件Mediator类并在该类中注册该组件中的一个按钮的监听,此时系统报错“引用为空”,等将对象添加到显示页面后在派发通知问题解决。   //新增业务操作 privat ...
      一个简单直观的图形胜似千言万语。随者用例分析的逐步进展,可能会出现很多理解起来比较困难或者理解起来不够直观的问题,为了弥补文字描写用例带来的弊端,我们可以采用图形化用例来来描述用例中的一些关键点。      常用的图有三种:活动图,时序图以及图形用户接口。其中图形用户接口指的是原型,原型在需求阶段是非常重要的,他能使业务人员更加直观的了解到这个系统将来会做到什么模样并提出问题和建议。
当我们在迭代细化事件流时,常常会发现系统中的许多用例之间有很多的相似之处,这意味着有很多的重复劳动以及文档的可维护性会降低。为了利用系统中的这些相似之处,我们可以使用一些技术手段,但是绝不能为了方便而牺牲了清楚的描述,我们的最终目的是使文档变得更加的清晰易懂。一些常用的技术包括:包含、扩展、接口和继承。在这里面只有“包含”是最终用户关心的,而其他则是开发人员关心的。    包含:       经常我们在写一个功能相近的用例时,会出现很多的复制粘贴,当出现这种情况时我们就可以考虑将相同的部分提取出来作为一个通用的部分。 例如:     但是有点需要注意的地方就是,被包含的部分并不知道他何时会 ...
       当要决定去做一个项目的时候,就应该完成项目初始阶段的项目描述,风险分析,用例图,执行者和用例描述以及项目建议等等工作(项目建议其实就是概括了这个项目大体需要做成什么样子)。这时对项目的总体应该有个较为清晰的认识。那么接下来的工作就是需要给文档添加更多细节方面的东西。在细化阶段我们需要完善项目的需求文档,项目的体系结构,以及一个项目计划,对于一些较为复杂和较难解决的部分可以创建一些原型来帮助我们制定更加详细和准确的需求,计划。       在细化需求文档时我们要做的主要工作其实就是细化用例。一个合理的用例他应该包括:前置条件,后置条件,事件流。       前置条件表示用例在开始时系 ...
       首先让我们定义一下经常在项目中用到的术语。系统是指你打算开发的任何事物,他可能是软件、硬件或者过程;项目是指为了建立一个系统而做的所有事情,包括指定计划、安排进度以及归档等。 在项目描述以及风险分析后我们需要做的是确定系统边界,那么如何才能确定系统边界?      系统边界通俗点来说就是将项目分割成系统内的和系统外的,系统内的在以后的项目进展中我们必须为创建他们而投入大量的精力,系统外的我们不需要创建,但是需要我们考虑与他们的接口。若要将系统外的事物进行划分,那么系统外部大致可以分为我们产品将要面对的使用者(人),以及为外部别的系统提供的服务(其他的软件),数据存储,硬件设备,以及 ...
      用例被用来描绘一个系统外在可见的需求情况,常被用在项目的需求分析阶段,对项目的测试计划和用户指南也有用处。他们被用来创建和验证被提议的设计,并确保该设计满足所有的需求。用例也被用来在创建项目计划时决定在每一个版本中应该加入什么内容。       在项目中常有的一个问题就是,已经进入了开发阶段了确还要对某些东西进行重新的设计甚至增加新的需求,这些大都与项目开始时的前期准备阶段没有做充分准备有关。没有一个可以贯穿整个项目的方法论,而基于用例的分析技术可以帮助人们理清楚我的系统需要做什么,不需要做什么,哪些可以做,哪些不可以做,需要做的功能要做到什么程度,需要做的功能是不是一定要在这次完成 ...

开博典礼

希望这个博客能够记录我的程序人生!
Global site tag (gtag.js) - Google Analytics