并不是说OOA OOD就不会用到ER喔 只要你的软体计划中有需要使用DB，就会有ER或者类似的资料库模型文件 除非你使用结合DB的OOPL 另外资料库的stored procedure不是用来给你写物件的method的 是用来控制资料库的一致性的，补足DBMS内建constraint的不足 资料库的功能就是存放重要的资料 你不应该把AP的物件在资料库中实做 除非你用OODB或ORDBMS 这些资料库就会提供定义"method"的方法 或者让你mapping methods到stred procedures ※ 引述《seagal (会长绕跑了)》之铭言： : ※ 引述《come ()》之铭言： : : 我是说先有资料库才有程式喔 : : 你完全误会了 : : 这跟class diagram的语意一点都没关系 : : 这是跟资料库的设计和整个软体开发流程的先後顺序有关 : : 资料库是在analysis阶段就完成 : 这样说也是有道理 : 的确ER Model是在分析阶段就会产出的文件 : 不过这也是我最主要觉得的问题 : 硬把传统的结构化分析与设计 : 跟物件导向分析与设计串在一起 : 产生的很多问题 : 都让我觉得很吊诡 : 结构化的分析与设计 : 起源於1960年代末期 : 最初的结构化的分析与设计 : 并没有包含ER Model : 到新一代的结构化分析与设计 : 才将ER Model加入 : 我门看陈品山是在1976年提出这个模型就可以得知了 : 直到1986年 : Grady Booch率先发表物件导向的系统开发方法 : 以开启物件导向在软体工程上应用的新页 : 在这几十年之间 : 关联式资料模型的变化似乎不大 : 看看现在最流行的两种OO语言 : Java and .NET : 在支援OOA/OOD上可以说是配合的很好 : 例如简单的struts, EJB, servlet概念 : 让架构在OO上的MVC观念得以完全发挥 : 唯一我觉得有很多疑问的地方 : 就是在关联式资料库的部份 : 我这边举ASP.NET + SQL Server的例子 : 当我以三层式架构 : 完成我的ASP.NET网站的时候 : 每一层的类别都经过良好的分析与设计 : 配合的天衣无缝 : 却在资料处理层要与SQL Server沟通时 : 让我做了很多dirty work : 也就是O/R mapping要处理的议题 : 例如 : 今天我要将新闻模组(News)从资料库读出来 或写入资料库 : News类别里面的method我该怎麽实做在呢SQL Server呢? : 为了简化例子 : 我只需要简单的两个方法 getInstance, putInstance : 这样子就好 : 没错 SQL Server可以提供sprocs : 可是光是sprocs命名 : 我就得取名作 : News_getInstance(NewsID) : News_putInstance(NewsID) : 这两支 : 如果我每个类别有二十个方法呢 : 如果我有二十个类别呢? : 我的sprocs就会有400个 : 事实上有些method是应该被封装起来的 : 所以也不应该被其他method存取到 : 从sprocs拿出来的资料 : 交给ASP.NET处理的时候 : ASP.NET是利用一种ADO.NET的技术 : 简单来说就是将资料变成一个table : 你必须要再去读取每个table里面的值 : 转换成你自己的物件 : Oh my god : 我只是要用个OO而已 : 怎麽多出来这麽多个步骤了 : 虽然我还是乖乖做完了:( : 这只是一个小问题而已 : 我再举出另外两个问题 : 在OO的思维里 : 每个物件是不需要PK的 : 你也可以说她们本身就有PK : 因为每个物件都会自己产生独一无二的ID : 这也是现在的OODB实做的方式 : 而在上面我举的例子里面 : 我总是要透过News模组的PK (NewsID)来读取每个tuple : 最後一个问题 : 在传统的结构化分析与设计 : 将每个阶段都切的十分清楚 : 而如果用OOA/OOD的方式来开发的话 : 并不会产出ER Model的文件(上面提过这是结构化分析 设计的产物) : 有些DBA也没有学过UML(至少我们team的DBA没有学过) : 那分析阶段产出的UML该由谁负责转成ER Model呢 : 万能的SA/SD嘛 : 或是像come网友讲的 : 在分析阶段就产出ER Model : 後面的设计都绕着ER Model来做? : 这也就是说 : 把OOA/OOD以资料导向的方式来开发? : 我的领域并不在OODB上面 : 我只是最近刚好有需要 : 将生物资讯的大量资料作处理 : 有必要的话可能还是得硬着头皮弄出适合的一套档案(or DBMS)系统 : 所以如果有任何高手能指正的话 : 也欢迎针对我说错的地方指正 : : analysis阶段的class diagram只是一个雏形而已 : : 到了design阶段的class diagram还必须根据data base schema重新设计一次 : : 那你觉得这时候class diagram的设计是要迁就DB : : 还是要回头改DB设计? : : spiral model的开发模型是可以这样搞 : : 不过改到DB通常表示需求分析有问题 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 61.223.42.62