任何事情都要先想清楚了才能作,软件开发更是如此!软件开发过程不可能一上来就开始盲目写代码,写代码以前必须搞清楚下面一些基本问题:
· 要作什么?
· 作成什么样?
· 怎么去作?
软件设计: 把软件开发想清楚的过程。
软件工程: 对软件开发全过程进行建模和管理。 数据库
• 模型: 对问题的书面上的无歧义文字或图形的描述.简言之, 模型是对现实的简化. 经过模型, 人们能够了解所研究事物的本质。架构
• 最杰出的模型: 地图并发
• 建模: 对现实系统进行适当的过滤, 用适当的表现规则描述出简洁的模型。框架
• 建模是一种深刻解决问题的方法。jsp
(1) 选择创建什么样的模型对如何发现和解决问题具备重要的影响。正确的模型有助于提升开发者的洞察力。数据库设计
(2) 每一个模型能够有多种表达方式. 使用者的身份和使用的缘由是评判模型好坏的关键。
(3) 最好的模型老是可以切合实际. 模型是现实的简化,必须保证简化过程不会掩盖任何重要的细节。
(4) 孤立的模型是不完整的。性能
· 软件建模的做用是把来源于现实世界的问题转化为计算机能够理解和实现的问题。单元测试
· 软件建模的实现过程是从需求入手, 用模型表达分析设计过程, 最终将模型映射成软件实现。测试
· UML(United Modeling Language, 统一建模语言): 是一种基于面向对象的可视化建模语言.
· UML 采用了一组形象化的图形(如类图)符号做为建模语言, 使用这些符号能够形象地描述系统的各个方面
· UML 经过创建图形之间的各类关系(如类与类之间的关系)来描述模型编码
• UML 中的关系主要包括 4 种:
- 关联关系(association)
- 依赖关系(dependency)
- 泛化关系(generalization)
- 实现关系(realization)
用例图(Use Case Diagram): 也称为用户模型图, 是从软件需求分析到最终实现的第一步, 它是从客户的角度来描述系统功能。
用例图包含 3 个基本组件: 参与者(Actor), 用例(Use Case), 关系:
· 参与者(Actor): 与系统打交道的人或其余系统即便用该系统的人或事物. 在 UML 中参与者用人形图标表示
· 用例(Use Case): 表明系统的某项完整的功能. 在 UML 中使用一个椭圆来表示
· 关系: 定义用例之间的关系 ------ 泛化关系, 扩展关系, 包含关系
类图是面向对象系统建模中最经常使用的图,是定义其余图的基础。类图主要是用来显示系统中的类, 接口以及它们之间的关系。类图包含的主要元素有类, 接口和关系,其中关系有关联关系, 泛化关系, 依赖关系和实现关系,在类图中也能够包含注释和约束。
• 关联关系的名称: 关联关系能够有一个名称, 用于描述该关系的性质. 此关联名称应该是动词短语, 由于它代表源对象正在目标对象上执行动做.
• 当一个类处于关联的某一端时, 该类就在这个关系中扮演一个特定的角色. 具体来讲, 角色就是关联关系中一个类对另外一个类所表现的职责. 角色名称是名词或名称短语.
• 关联关系的多重性是指有多少对象能够参与该关联, 多重性能够用来表达一个取值范围, 特定值, 无限定的范围.
• 聚合关联是一种特殊的关联. 它表示类间的关系是总体与部分的关系. 简言之: 关联关系中的一个类描述了一个较大的事物, 它由较小的事物组成.
• 聚合关系描述了 “has a” 的关系, 即总体对象拥有部分对象
• 总体和部分之间用空心菱形箭头的连线链接, 箭头指向总体
• 组成关系是更强形式的聚合.
• 组合关系中, 整件拥有部件的生命周期, 因此整件删除时, 部件必定会跟着删除. 并且, 多个整件不能够同时共享同一个部件。
• 聚合关系中, 整件不会拥有部件的生命周期, 因此整件删除时, 部件不会被删除. 再者, 多个整件能够共享同一个部件.
• UML 中组成关系用实心的菱形实线表示
• 导航性表示可从源类的任何对象到目标类的一个或多个对象遍历. 即: 给定源类的一个对象, 能够获得目标类的全部对象. 能够在关联关系上加上箭头表示导航方向.
• 只在一个方向上能够导航的关联称为单向关联,用一个带箭头的方向表示; 在两个方向上均可以导航的关联称为双向关联, 用一条没有箭头的实线表示.
• 时序图用于描述对象之间的传递消息的时间顺序, 即用例中的行为顺序.
• 当执行一个用例时, 时序图中的每条消息对应了一个类操做或者引发转换的触发事件.
• 在 UML 中, 时序图表示为一个二维的关系图, 其中, 纵轴是时间轴, 时间延竖线向下延伸. 横轴表明在协做中各个独立的对象. 当对象存在时, 生命线用一条虚线表示, 消息用从一个对象的生命线到另外一个对象的生命线的箭头表示. 箭头以时间的顺序在图中上下排列.
• 对象: 时序图中对象使用矩形表示, 而且对象名称下有下划线. 将对象置于时序图的顶部说明在交互开始时对象就已经存在了. 若是对象的位置不在顶部, 表示对象是在交互的过程当中被建立的.
• 生命线: 生命线是一条垂直的虚线. 表示时序图中的对象在一段生命周期内的存在. 每一个对象底部中心的位置都带有生命线.
• 消息: 两个对象之间的单路通讯. 从发送方指向接收方. 在时序图中不多使用返回消息.
• 激活: 时序图能够描述对象的激活和钝化. 激活表示该对象被占用已完成某个任务. 钝化指对象处于空闲状态, 等待消息. 在 UML 中, 对象的激活时将对象的生命线拓宽为矩形来表示的. 矩形称为计划条或控制期. 对象就是在激活条的顶部被激活的. 对象在完成本身的工做后被钝化.
• 对象的建立和销毁: 在时序图中, 对象的默认位置是在图的顶部. 这说明对象在交互开始以前就已经存在了. 若是对象是在交互过程当中建立的, 那么就应该将对象放到中间部分. 若是要撤销一个对象, 在其生命线终止点处放置 “ X” 符号.
在 UML 中, 活动图本质上就是流程图. 它用于描述系统的活动, 断定点和分支等.
• 动做状态: 原子的, 不可中断的动做, 并在此动做完成以后向另外一个动做转变. 在 UML 中动做状态用圆角矩形 表示, 动做状态所表示的动做写在圆角矩形内部.
• 分支与合并: 分支在软件系统中很常见. 通常用于表示对象类所具备的条件行为. 用一个布尔型表达式的真假来断定动做的流向. 条件行为用分支和合并表达.在活动图中, 分支用空心小菱形 表示. 分支包括一个入转换和两个待条件的出转换, 出转换的条件应该是互斥的, 须保证只有一条出转换可以被触发. 合并包含两个带条件的入转换和一个出转换.
• 分叉与汇合: 分叉用来描述并发线程, 每一个分叉能够有一个输入转换和两个或多个输出转换. 每一个转换均可以是独立的控制流. 汇合表明两个或多个并发控制流同步发生, 当全部的控制流都达到汇合点后, 控制才能继续往下进行. 每一个汇合能够有两个或多个输入转换和一个输出转换. 在 UML 中分叉和汇合用一条粗直线表示
• 泳道: 泳道将活动图中的活动划分为若干组, 并将每一组指定给负责这组活动的业务组织. 泳道区分负责活动的对象, 明确地表示哪些活动是由哪些对象进行的. 每一个活动指定明确地属于一个泳道. 在活动图中, 泳道用垂直实线绘出, 垂直线分隔的区域即为泳道
状态图: 经过创建对象的生存周期模型来描述对象随时间变化的动态行为.
• 状态: 用圆角矩形表示. 状态名称表示状态的名字, 一般用字符串表示. 一个状态的名称在状态图所在的上下文中应该是惟一的.
• 转换: 用带箭头的直线表示. 一端连着源状态, 一端连着目标状态.
• 初始状态: 每一个状态图都有一个初始状态. 此状态表明状态图的起始位置. 初始状态只能做为转换的源, 不能做为转换的目标, 而且在状态图中只能有一个. 初始状态用一个实心圆表示.
• 终止状态: 模型元素的最后状态, 是一个状态图的终止点. 终止状态在一个状态图中能够有多个.
协做图(也叫合做图)是一种交互图。时序图主要侧重于对象间消息传递在时间上的前后关系, 而协做图表达对象间的交互过程及对象间的关联关系。
对象图是类图的一个实例, 用于显示系统执行时的一个可能的快照. 即在某一个时间上系统可能出现的样子. 对象图用带下划线的对象名称来表示对象.
• 包图: 由包和包之间的关系组成. 包的图标就如同一个带标签的文件夹.
• 包提供了一种用于组织各类元素的分组机制. 在 UML 中, 包用来对元素进行分组, 并为这些元素提供命名空间. 包所拥有的或者引用的全部元素称为包的内容, 包没有实例.
组件图用来创建系统中各组件之间的关系, 各组件经过功能组织在一块儿。Javabean, ejb, jsp 都是组件。在UML中,组件使用在左侧有两个小矩形的大矩形来表示。组件图能够用来设计系统的总体构架。
• 部署图用来帮助开发者了解软件中的各个组件驻留在什么硬件位置, 以及这些硬件之间的交互关系。
• 节点: 用来表示一种硬件, 能够是打印机, 计算机等.节点的标记符号是一个三维框,在框的左上方包含了节点的名称。
• 通讯关联: 节点经过通讯关联创建彼此的关系,采用从节点到节点绘制实线来表示关联。
软件生命周期: 软件的产生直到报废的生命周期。软件生命周期内有问题定义, 可行性分析, 整体描述, 系统设计,编码, 调试和测试, 验收与运行, 维护升级到废弃等阶段。随着新的面向对象的设计方法和技术的成熟, 软件生命周期设计方法的指导意义正在逐步减小。
• 软件工程能够分为三个大的阶段:需求; 设计; 测试与维护
• 1. 需求:
–开发目标
–可行性分析
–需求分析
•2. 设计:
–概要设计
–详细设计
–编码与单元测试
•3. 测试与维护
–综合测试
–维护
一、问题的定义及规划(可行性分析报告和软件开发计划): 此阶段是软件开发方与需求方共同讨
论,主要肯定软件的开发目标及其可行性。
二、需求分析(需求分析说明书和初步的用户手册): 在肯定软件开发可行的状况下,对软件须要
实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段,这一阶段作得好,将为
整个软件开发项目的成功打下良好的基础。
三、软件设计(概要设计、详细设计): 此阶段主要根据需求分析的结果,对整个软件系统进行设
计,如系统框架设计,数据库设计等等。软件设计通常分为整体设计和详细设计。
四、程序编码(提交源程序及清单): 此阶段是将软件设计的结果转换成计算机可运行的程序代码。
在程序编码中必需要制定统一,符合标准的编写规范。以保证程序的可读性,易维护性,提
高程序的运行效率。
五、软件测试(提交软件维护测试报告): 在软件设计完成后要通过严密的测试,以发现软件在整
个设计过程当中存在的问题并加以纠正。整个测试过程分单元测试(白盒)、集成测试(黑
盒,功能测试、强度性能测试)以及系统测试三个阶段进行。测试的方法主要有白盒测试和
黑盒测试两种。在测试过程当中须要创建详细的测试计划并严格按照测试计划进行测试,以减
少测试的随意性。
六、运行维护(提交软件维护报告) : 软件维护是软件生命周期中持续时间最长的阶段。在软件
开发完成并投入使后,因为多方面的缘由,软件不能继续适应用户的要求。要延续软件的使
用寿命,就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。
• 统一软件开发过程(Rational Unified Process,RUP): 一个通用的软件流程框架, 以架构为中心, 用例驱动的迭代化开发流程. RUP 是从几千个软件项目的实践经验中总结出来的, 对于实际的项目具备很强的指导意义.
• RUP 用二维坐标来描述. 横轴经过时间来组织, 是过程展开的生命周期特征, 体现开发过程的动态结构; 纵轴之内容来组织, 体现开发过程的静态结构.
• 初始阶段: “得到项目的基础”. 该阶段的主要人员是项目经理和系统设计师. 所要完成的主要任务包括对系统的可行性分析; 建立基本的需求; 识别系统的关键任务.
• 细化: 主要目标是建立可执行构件基线; 精化风险评估; 捕捉大部分的系统功能需求用例; 为构造阶段建立详细需求. 该阶段并非要建立可执行的系统, 而是展示用户所指望的需求.
• 构建: 完成全部的需求, 分析和设计. 该阶段的制品将演化成最终系统
• 交付: 将完整的系统部署到用户所处的环境中.
• RUP中有9个核心工做流. 分为6个核心过程工做流(Core Process Workflows) 和 3个核心支持工做流 (Core Supporting Workflows). 尽管6个核心过程工做流相似于传统瀑布模型中的几个阶段, 但迭代过程当中的阶段是彻底不一样的, 这些工做流在整个生命周期中一次又一次被访问. 9个核心工做流在项目中轮流被使用, 在每一次迭代中以不一样的重点和强度重复.
本文为博主原创文章,转载请注明出处!