think in UmL(三)

在实践中思考!

在这一部分中,书中作者用实际的案例讲述了从一个个实际项目的可行性分析阶段倒是现阶段的整个过程,让我们奖赏部分学到的UML知识点在实践中的得到学习。

当我们拿到一个项目的时候首先要做的就是“准备工作”。(1)了解问题领域:软件是一种工具,是用来辅助人们解决某一问题的。软件的价值就在于它能够符合问题领域的需要,并达到人们解决问题的期望。(2)做好涉众分析:在了解业务概况和业务目标以后,系统分析员最先要做的事情不是去了解业务的细节,而是发现与这个目标相关的人和物,在课堂上我们已经学习了上下文图,将系统看作一个黑匣子,列出与系统相关的人物、甚至是时间地点、其他系统等,其中的人即是系统的利益相关者。(3)规划业务范围:这是一个很重要的部分,必须要考虑到人力物力财力。(4)整理好你的思路(5)客户访谈技巧:获取需求困难的一大原因是沟通,当与客户沟通是最好是携带一个笔记本,随时记下客户的需求,必须要有反馈与确认的过程,以免造成不必要的损失。

获取需求。(1)定义边界:如果不能决定好系统的业务范围,你的系统将无限制的扩大。(2)发现主角:只有那些直接与系统交互的涉众才能被成为主角,业务主角区别于参与者,不应当被过分的抽象化和虚拟化。(3)获取业务用例:对于系统来说,每一件事便是一个用例,每个业务用例都体现了业务主角的一个系统期望,而所有的这些期望则完成边界所代表的业务目标。(4)业务建模(5)领域建模(6)提炼业务规则:全局规则、内禀规则、分类业务规则、(7)获取非功能性需求:系统必须具有满足客户的工作所需的功能,要有一定的可靠性、安全性和可维护性,要保持可扩展的接口,要能与各种各样的旧系统、外部系统、易购系统打交道,客户总希望自己的系统是业界领先的不论是在技术上还是内容上,个性化。不过实际上,非功能需求也正是围绕着后四层次中提到的那些需求展开的。

需求分析:关键建模分析、业务架构、系统原型。

系统分析:确定系统用例、分析业务规则、用力实现、软件架构和框架、分析模型、组建模型、部署模型。

系统设计:系统分析与系统设计的差别、护色剂模型、接口设计、包设计。

开发:生成代码、分工策略。

测试:质量保证——新世界需要稳健运行、设计和开发测试例。

时间: 2024-10-06 03:26:38

think in UmL(三)的相关文章

UML简介

Unified Modeling Language (UML)又称统一建模语言或标准建模语言,是始于1997年一个OMG标准,它是一个支持模型化和软件系统开发的图形化语言,为软件开发的所有阶段提供模型化和可视化支持,包括由需求分析到规格,到构造和配置. 面向对象的分析与设计(OOA&D,OOAD)方法的发展在80年代末至90年代中出现了一个高潮,UML是这个高潮的产物.它不仅统一了Booch.Rumbaugh和Jacobson的表示方法,而且对其作了进一步的发展,并最终统一为大众所接受的标准建模

采用[ICONIX] 方法实践分析和设计之六 [时序图](转)

采用[ICONIX] 方法实践BLOG设计之六 [时序图] 在前几篇文章中,我们分别进行了域模型和用例建模,并使用 Robustness工具进一步分析验证了相应用例的处理流程,并在相应模型(域模型)的基础上,通过Robustness方法引入相关的边界对象,控制对象(控制器),并更新了相应域模型中类的属性(字段).下面就可以进入到交互建模阶段了.如下图:    作为交互建模本身,就是要通过寻找对象之间的交互关系,进而进行方法(操作或行为)分配.    正所谓"只有在所有的用例为所有事件进程建立了交

java面试题001

hibernate中离线查询去除重复项怎么加条件?? dc.setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY); http协议及端口,smtp协议及端口 http:超文本传输协议    端口 80 smtp:简单邮件传输协议 端口25 编写程序,完成文件复制功能 Servlet创建过程及生命周期Servlet 在容器中运行时,其实例的创建及销毁等是由容器进行控制. Servlet 的创建有两种方法. 客户端请求对应的 Servlet 时,创建

Mix 导航

Mix 导航 一.程序员必备技能 Markdonw 使用 Git 常用命令 二.分析设计 UML 三.其他 博客园代码样式修改 原文地址:https://www.cnblogs.com/-Tiger/p/9742324.html

UML类图三

2. 依赖关系  依赖(Dependency)关系是一种使用关系,特定事物的改变有可能会影响到使用该事物的其他事物,在需要表示一个事物使用另一个事物时使用依赖关系.大多数情况下,依赖关系体现在某个类的方法使用另一个类的对象作为参数.在UML中,依赖关系用带箭头的虚线表示,由依赖的一方指向被依赖的一方.例如:驾驶员开车,在Driver类的drive()方法中将Car类型的对象car作为一个参数传递,以便在drive()方法中能够调用car的move()方法,且驾驶员的drive()方法依赖车的mo

对软件开发中uml建模的理解和图形整理(三)

今天接着上一节的内容,继续来了解uml剩下的几种的静态建模和动态建模. 三.对象图:主要用来表现对象的特征,展示多个对象的特征及对象之间的交互.就拿咱出行旅游使用交通工具为例,如图: 说明:对象图只在系统的某一段时间存在,可以被看作是类图在该时刻的实例,主要用来描述对象之间的行为. 四.组件图:也称为构件图,主要用来描述软件中组件之间的关系,同时也是系统设计的一个模块化元素.组件(构件)是系统中可替换的物理部分,它封装了类的实现以及对象提供一组接口,在软件开发过程中,满足相同接口的组件可以自由地

<三>面向对象分析之UML核心元素之参与者

一:版型        --->在UML里有一个概念叫版型.有些书里也称类型,构造型.        --->这个概念是对一个UML元素基础定义的扩展.在同一个元素基础定义的基础上赋予特别的含义,使得这个元素适用于特定的场合.        --->例如(1)用例:的版型有:“业务用例”,“业务用例实现”                      (2)类:的版型有:“接口”,“边界类”,“实体类”,“控制类”        --->除了UML已经定义的版型外,为了在某种场合下让元

[3]工欲善其事必先利其器-------UML常用的图(三)

该部分主要针对UML中常用的类图,用例图,顺序图,状态图,活动图这四个部分进行简要介绍. 一.类图 1.类图用于描述系统中类的静态结构,它包括系统中每个类的结构以及类与类之间的关系的描述. 其中类的结构如下图所示: 类与类之间的关系:见上一小结<UML中的几种常见关系>介绍 二.用例图 用例图一般用于需求分析,它是从用户的角度来描述系统的功能. 用例图列出系统中的用例,系统外的参与者,以及哪个参与者参与了哪些用例这三个部分. 参与者:在系统外部与系统直接打交道的人或者物. 用例:系统外部可见的

UML视图(三)包图

包图,跟类的作用很相似,同是把相关或某方面具有共同特征的信息房子一起分隔开来:不同的是,包的范围更大容量更广. 包能容纳UML中的任何元素,例用例.业务实体.包(子包)等.Rose画图软件中的Use Case View(用例视图).Logic View(逻辑视图)和Component View(组件视图)就是三个包. 包是一种容器,如同文件夹一样,它将某些信息分类,形成逻辑单元,使用包的目的是为了整合复杂的信息. 包这么亲和,那为了避免无意的滥用,造成混乱.对包的划分进行了一些约束,总结为一句话