因为收到人家给我的uml图, 如果,只照那个看,应该就是一个class,下面很多attibute, 然后这些class之间再发生一些关系. 我做的时候,有几个问题不是很明白照我现在看到和感受到的是,
1\现在这个程序员的思路应该是根据这个UML的类和属性表,设计数据库,可他不可能一下把所有类,至少是不太可能一次把类下的所有属性都完善地填好吧? 我本来是认为,他一步步做, 我一点点把相关的部分的 ,用现在看,属于"各个类"和类下的各个具体的属性,告诉他.他逐步建立. 一般开发时是应该一次建立,有个大的结构概念,还是逐步建立的? 其实,以我看,程序员不可能一开始就建立很完全的这个表啊....或者,是一般其他的瀑布型开发的项目,都是先这样建立起来UML图,然后是数据库,然后再开发? 那些数据也不是一下都需要啊...
2\我自己在设计时,有些想到,但没有打算现在做的一些东西,和目前这个类有关的属性,是现在就应该放进去,还是以后可以作为一个类加进去? 是不是类比较好加,属性比较难加?
因为,老有很多人提醒我,数据库结构在开始做之前就要设计好,有些东西,后来就不好加了,我如何判断哪些是好加的,哪些是不好加的? 肯定有自己没设计周到的,是不是属性,都应该多留一些空白的,准备以后加?
现在我不用word文字,改用ppt来表达界面,同时表达页面跳转逻辑,对程序员就足够了吧,数据流不用再另外画图的吧?
3\顺便记录一下,前几天和小兄弟电话请教那个数据库反推得到的vsd图时,我问过他,是不是不如我自己把这个图给设计了, 他和我说,这个图,不应该我设计,因为我的理解和程序员对数据库的理解是不一样的, 比如,一个分享状态,它是用2个键控制,我可能就是描述的是,一个分享,+ 4种情况,可能就只会做成一个外键,而实际,是需要另外一个来控制的,数据库里的东西,很多前端是不显示的.我应该只是看程序员的设计,而不是自己动手设计.
不过,要是单从目前接收到的UML图的类和属性看,肯定是不如我自己动手设计对程序员帮助更大,也能帮助他理解,和不忘掉元素..
4\我看到我收到的这个图就2种关系,一个箭头是generalization 归纳? 继承?,一个是Composition,应该是构成的意思?. 我还没太明白
5\ 我不太明白,比如,用户这个类下, 用户名,邮箱,密码等等这些是属性,那 站内短信,用户的粉丝,关注的对象,这些也要算在用户类下的属性吗? 还是另外一个类?
顺便说个小感觉,好像不仅是文人相轻,程序员也彼此相轻啊, 我到现在还没遇到一个程序员看到之前程序员做的东西赞不绝口的:) 别说赞不绝口了,基本极少赞任何的,99%都是说前面或其它的人做的不好,各种这缺点那缺点的. 嗯,主要是90%以上其实基本根本都没详细看,就说不好.
小兄弟倒是说过之前的兼职的算是中规中矩的,当然,也还是说结构设计不好. 虽然,我也不懂他的结构的概念和我的结构的概念是不是一样的.不过,我自己是觉得结构上应该有问题,因为有些我觉得是硬伤的地方,他完全没办法改.
现在,之前兼职程序员和小兄弟的程序,都被人说是一打开什么开发的软件,就自动检测到非常多错误. 还有,说,前面做的没有底层设计.
刚刚不会用那个关系的箭头,搜索了一下,网上有介绍staruml的,我决定迅速地看一下.http://wenku.baidu.com/view/b6b5d6c66137ee06eff918bf.html