• 如果说OO是对现实世界的一种抽象，那么MDA是比OO更加抽象的一种技术或方法论。我们在一个软件革命的开始，它象90年代我们看到的面向对象编程从传统过程语言中抽象出来一样。 四色原型是诞生于90年代，现在被广泛使用的一种系统分析方法：
  • 失败的项目经历 做项目的总有成功和失败，成功了需要总结，失败的更需要总结。以下要说的一个 Case 是我经历过的一个失败的项目，写出来，大家指点一下。 首先介绍一下背景，这个项目的客户是企业内部顾客，应用
  • 请问系统集成项目：1 需求分析出了一部分，如果用java来做的话，应该是ooa的部分吧，如果用uml来设计的话，用uml来描述什么呢，比如use case 2 是否要写个概要设计呢，就是系统的架构，软件模式，硬件结构，系统的开发原则，开发目标？3 详细设计是肯定要写的， icon
  • 采用用RUP开发过程 需求分析告一段落，业务需求都有了，UC也差不多写好了，接下来是设计，设计阶段该干什么呢？ 我认为：1.确认系统的物理结构，网络拓扑2.需求分级3.类图4.ER icon
  • 那么，一个正确的OOA/OOD/OOP步骤是什么呢？目前围绕模型驱动设计(MDD)的设计思想成为主流思想，MDA更是在MDD基础上提升和升华。下面让我们首先了解，如何使用领域驱动设计思想来分析设计一个软件系统。 icon
  • 我一直这样做:用rose做model->生成代码->修改代码->reverse->修改model如此循环，结果都是：到后期，文档和代码对应不上，慢慢地文档就没有用了。因此请教各位：有没有好方法，可以保证详细设计/代码一致性？ --刚才请教一个人，他的说法是 icon
  • 在用hibernate进行o/r映射的时候遇到这样的问题：hibernate要求你把所有的表都生成类，然后，从域模型出发进行映射。这引发了我得一个思考，似乎进行关系建模的时候，得出的实体（表），也都是来自与需求中的实体，而对象建模的得到的模型也是基于需求中的实体，二者似乎重合了，甚至可能一一 icon
  • 初触 uml modeling,特上解道，书已疑问： 相关的类，置于同一张类图，颇为直观，但它们位于不同包中，这种情况，是如何处理的？可否给出一张示范的类图，谢谢！ icon
  • 灵活设计是对领域建模的补充，当我们从领域中抓住那些隐隐约约的线索和概念原型后，就象准备好原料；下面就是通过迭代将原料锤炼成一定具体的形状，可以俗称“打铁”，本文谈如何打铁。 icon
  • >早年用OOA&D的方法，一上来就找对象。甚至从一篇用户提供的文档中划出名词，作为初始对象。UML出来后>，Jacobson的use case则成为一个主要的部分。一开始就教你捕获use case，搞用例模型，强调用例驱动。 >但我对此则常有疑惑，如果域对象都没有搞清楚，use case又如何能明确 icon
  • 最近看了以前的精华贴《项目失败经验谈》，正好公司有出色的PM和SA 都是台湾人，20年以上从业经验，做过经典的J2EE项目（IBM NEC等）， 他们讲“客户永远是对的，纠正用户错的（用数据）”，一味的把客户当上帝，只会“需求失控”，后面的 icon
  • 1.需求确认后对系统建模的大概用时有多少？（一般中型项目）2.根据需求构建系统的结构与选择成熟框架间有联系吗？3.对系统业务功能分解实现时从哪开始好？登录开始好吗？ icon
  • 小弟是初学者.在UML建模的时候, 关于各个方面到底要考虑到什么样的程序有点把握不定, 希望得到各位大哥的指点. 比如我在建UseCase图的时候, 有一个UseCase:[Search], 有四个Actor[Student],[Manager],[Teacher]和一个泛化的Ac icon