电子文档交易市场
安卓APP | ios版本
电子文档交易市场
安卓APP | ios版本

OA系统项目开发

91页
  • 卖家[上传人]:549925****qq.com
  • 文档编号:122600512
  • 上传时间:2020-03-06
  • 文档格式:DOC
  • 文档大小:678.50KB
  • / 91 举报 版权申诉 马上下载
  • 文本预览
  • 下载提示
  • 常见问题
    • 1、 OA系统项目开发UML小结以及基于领域模型的系统设计初步UML不是OOA/D 也不是方法,它仅仅是一种图形表示法。其目的就是让人能看懂你的东西。每一种图,都相当于一种角度。不同的图就是从不同角度来观察系统。比如交通图和行政区划图,从不同角度观察中国。 必要性是画图的原则,虽然有这种关系,但不一定要画出来,如果非要画出来,则应考虑不要影响图形的美观。 活动图活动图表示的是一种流程。例子:顺序图顺序图的目的是为对象分配职责,而不是步骤的罗列。上图中,ActionServlet是没有必要画出来的,它是一个很稳定,也不是我们自己提供的,没有必要来说明它的对象职责。插在这里显然多余.如下图这样就可以了:用例和用例图用例的定义:文本形式的情节描述。 用例用于需求的发现和记录,它会影响后续的OOA/D工作 用例不是用例图。用例图不重要,用例描述很重要。 用例尽量不要用名词命名,尽量以动词开头,比如:管理商品。用例一般是用于功能性的需求而非性能性需求。编写用例时,在基本路径(即主成功路径)中,只书写主要的成功事件,而可能出现的其他情况(如找不到用户)应该写在扩展点中。 用例粒度:比如:是把管理用户当

      2、做用例还是把添加用户和删除用户分别当做两个用例。确定用例的粒度时,应该考虑描述这个用例的基本路径需要几个步骤。十步以内,七八步比较合适。一个典型的用例描述一个典型用例图其中销售经理和收银员之关系是泛化关系,即经理拥有收银员所拥有的一切用例。另外还有其独有的用例。类图类图允许我们标记静态内容及类之间的关系,它是UML中最重要的图形,可以在任何时候尝试使用类图。不要使用类图描述所有的细节,保持类图的简单。UML中主要有三种类:边界类、控制类和实体类边界类位于系统与外界的交界处,例如窗体、报表、以及表示通讯协议的类、直接与外部设备交互的类、直接与外部系统交互的类等。通过用例图可以确定需要的边界类,每个Actor/Use Case对至少要一个边界类,但并非每个Actor/Use Case对要唯一的边界类。实体类可以通过事件流和交互图发现。通常每个实体类在数据库中有相应的表,实体类中的属性对应数据库表中的字段。控制类是控制其他类工作的类。控制类可以被多个用例共用。其他类并不向控制类发送很多消息,而是由控制类发出很多消息。 类图中,要画出类之间的关系UML中继承、实现、依赖、关联、聚合、组合的联系

      3、与区别继承 (也叫泛化)指的是一个类(称为子类、子接口)继承另外的一个类(称为父类、父接口)的功能,并可以增加它自己的新功能的能力,继承是类与类或者接口与接口之间最常见的关系;在Java中此类关系通过关键字extends明确标识,在设计时一般没有争议性;实现指的是一个class类实现interface接口(可以是多个)的功能;实现是类与接口之间最常见的关系;在Java中此类关系通过关键字 implements明确标识,在设计时一般没有争议性;依赖可以简单的理解,就是一个类A使用到了另一个类B,而这种使用关系是具有偶然性的、临时性的、非常弱的,但是B类的变化会影响到A;比如某人要过河,需要借用一条船,此时人与船之间的关系就是依赖;表现在代码层面,为类B作为参数被类A在某个method方法中使用;关联他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系,比如我和我的朋友;这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的,一般是长期性的,而且双方的关系一般是平等的、关联可以是单向、双向的;表现在代码层面,为被关联类B以类属性的形式出现在关联类A中,也可能是关联类A引用了一

      4、个类型为被关联类B的全局变量;聚合聚合是关联关系的一种特例,他体现的是整体与部分、拥有的关系,即has-a的关系,此时整体与部分之间是可分离的,他们可以具有各自的生命周期,部分可以属于多个整体对象,也可以为多个整体对象共享;比如计算机与CPU、公司与员工的关系等;表现在代码层面,和关联关系是一致的,只能从语义级别来 区分;组合组合也是关联关系的一种特例,他体现的是一种contains-a的关系,这种关系比聚合更强,也称为强聚合;他同样体现整体与部分间的关系,但此时整体与部分是不可分的,整体的生命周期结束也就意味着部分的生命周期结束;比如你和你的大脑;表现在代码层面,和关联关系是一致的,只能从语义级别来区 分;总结:继承、实现体现的是类与类、或者类与接口间的纵向关系,不易混淆;其他的四者关系则体现的是类与类、或者类与接口间的引用、横向关系,这几种关系都是语义级别的,所以从代码层面并不能完全区分开来;例如在关心汽车的领域里,轮胎是一定要组合在汽车类中的,因为它离开了汽车就没有意义了。但是在卖轮胎的店铺业务里,就算轮胎离开了汽车,它也是有意义的,这就可以用聚合了。总的来说,后几种关系所表现的

      5、强弱程度依次为:组合聚合关联依赖示例一关联之特殊示例,下图表示一种树形结构类图,可以用如下代码实现Public Class Node Public ID; Private Node parent; Private Set children;示例二:已经在关联中表明了 Document 具有一个User类型的字段 Creator,故不必在Document中再写出Creator了。示例三:由于User是另一个复杂的概念,所以要建立关联,而不是把User也作为一个简单的属性(如name那样)不要把复杂的领域概念建模为属性。 示例四:Student 与 class 之间是双向关联关系,当然也可以说成是student依赖class,因为没有class,student是不能编译通过的。但画图并不是所有存在的东西都要画出来,这里表示成关联关系更为贴切些。另外,关联指的是关心对方的结构,如果对象A只是用一用对象B的某个方法,比如Collections.sort(), 这显然是依赖而非关联。基于领域模型的系统设计初步设计时重要原则: 低耦合,高内聚. 尽量降低对不稳定对象的依赖。对于非常稳定的东西,比如

      6、JDK的核心类库,尽可以随便依赖它。 不要依赖于正向工程和逆向工程,如果你要让其从图形生成代码,则你不得不在图形中注意各种细节,那不如你自己写代码。 图形是为了抽象出逻辑主干,方便人理解,它不能替代详细完整的文字描述。系统的核心价值领域模型的价值不在于它的设计优美(它只是一些对象最重要的也就是对象之间的关系)而在于它体现了系统的核心价值。什么是系统的核心价值呢?我想我们的图书馆系统和华尔街的一个商业系统本质的区别不在于系统用了什么语言、用了什么数据库、用的是OO还是过程,而在于系统能为使用者提供什么服务,以及提供的质量。这些通过系统的运行方式系统的运行过程系统的业务逻辑来体现。用例的价值系统分析员在接手一个系统后首先要做到的事情就是得出系统的服务和服务场景。也就是我们经常所讲的用例(use case)很多人不清楚清晰的用例的价值,只是因为看别人有漂亮的图形,所以自己也画一个,其实自己都不去看它。这样的用例分析只能糊弄一下老板,给别人show一下Demo而不会对系统开发什么实质作用。用例表示的是使用系统的一个场景其本质在于详细描述了系统用户(actor)与系统是如何交互的以及交互的后果是

      7、什么详细而完善的用例将指导您进行系统开发的全过程 低耦合的设计系统对象除了与领域模型、用户打交道以外它还会与系统的其它模块交互。如持久化系统、日志系统、信息通知系统(您不能因为用户要求由邮件通知改为短信通知就修改领域模型吧),当然还有UI,这些属于系统核心(领域模型)以外的东西。这些模块不该参杂进业务逻辑中。应该在边界与这些模块进行接触。 例子:Public void 借阅()借阅处理者 处理者 = new 借阅处理者(当前书籍当前登录人姓名); Bool successful = 处理者.借阅() /這個方法主要就是上面的那2行代碼 If(successful)持久化系统.add(当前书籍);日志系统.add日志(当前当籍,”借阅”)邮件系统.发送邮件(当前书籍.当前借书人姓名) /这个例子的关键在于,你本可以在借阅()方法中先实现借阅的逻辑,然后顺势进行持久化、日志、邮件操作。可是这里却多弄了个处理者对象来专门进行借阅操作,其目的就是为了将“借阅”逻辑独立出来,与其他模块耦合更松。 例子二:Void 持久化系统.add(书籍 当前书籍)借阅关系 Bbb = new 借阅关系 Bbb

      8、.id = 产生ID() Bbb.图书ID = 当前书籍.id; Bbb.借阅人 = 当前书籍.借阅记录.借阅人姓名 Bbb.借阅时间 = 当前书籍.借阅记录.借阅时间 Bbb.Save(); 在现实系统中我在if(successful)这里作了一些纯软件设计如利用C#具有Event特性将借阅方法后公开出一个事件这样我在再要添加什么外围模声时只要响应事件就可以了不需要再来动这个方法 。 其它模块处理过程类似。业务过程是系统的核心,其他模块都依赖于它而存在。一个系统要变更业务逻辑我们只要针对领域模型作变化即可再也不需要抱怨变化了OA_6_利用Rose创建各种组织机构的uml图形 OA6: 利用Rose创建各种组织机构的uml图形(.mdl)。 根据需求建立模型 职能型组织机构包括树形和直线型(集权型) 抽象出Party,可以复用一些公共的属性将树形结构关联转移到Party,可以同时支持Person和Orgnization的树形结构 混合型组织机构 矩阵型组织机构(网状组织机构)在需求分析中这几种关系最重要OA项目属于职能型 ( 一)组织机构管理l (struts) Action 与页面要注意的细节页面所需要的信息,参数,必须要在Acion里面定义好,否则页面取不出数据,Action主要负责页面数据的搜集OrgAction.javapublic class OrgAction extends ActionSupport/* * */private static final long serialVersionUID = 1L;private OrgManager orgManager;private List orgs;private int parentId;/向下导航处所有的子机构,需要传递参数,在页面上不去出来,不必注入request域public int getParentId() ret

      《OA系统项目开发》由会员549925****qq.com分享,可在线阅读,更多相关《OA系统项目开发》请在金锄头文库上搜索。

      点击阅读更多内容
    最新标签
    监控施工 信息化课堂中的合作学习结业作业七年级语文 发车时刻表 长途客运 入党志愿书填写模板精品 庆祝建党101周年多体裁诗歌朗诵素材汇编10篇唯一微庆祝 智能家居系统本科论文 心得感悟 雁楠中学 20230513224122 2022 公安主题党日 部编版四年级第三单元综合性学习课件 机关事务中心2022年全面依法治区工作总结及来年工作安排 入党积极分子自我推荐 世界水日ppt 关于构建更高水平的全民健身公共服务体系的意见 空气单元分析 哈里德课件 2022年乡村振兴驻村工作计划 空气教材分析 五年级下册科学教材分析 退役军人事务局季度工作总结 集装箱房合同 2021年财务报表 2022年继续教育公需课 2022年公需课 2022年日历每月一张 名词性从句在写作中的应用 局域网技术与局域网组建 施工网格 薪资体系 运维实施方案 硫酸安全技术 柔韧训练 既有居住建筑节能改造技术规程 建筑工地疫情防控 大型工程技术风险 磷酸二氢钾 2022年小学三年级语文下册教学总结例文 少儿美术-小花 2022年环保倡议书模板六篇 2022年监理辞职报告精选 2022年畅想未来记叙文精品 企业信息化建设与管理课程实验指导书范本 草房子读后感-第1篇 小数乘整数教学PPT课件人教版五年级数学上册 2022年教师个人工作计划范本-工作计划 国学小名士经典诵读电视大赛观后感诵读经典传承美德 医疗质量管理制度 2
    关于金锄头网 - 版权申诉 - 免责声明 - 诚邀英才 - 联系我们
    手机版 | 川公网安备 51140202000112号 | 经营许可证(蜀ICP备13022795号)
    ©2008-2016 by Sichuan Goldhoe Inc. All Rights Reserved.