网站推广方案怎么写的,怎么去推广一个app,网站永久免费建站,客户买东西返利网站怎么做目录
1. 软件需求
1.1 需求分类
1.2 需求获取
1.3 需求分析
2. 面向对象分析#xff08;OOA#xff09;
2.1 统一建模语言 UML
2.2 用例模型
2.2.1 用例图的元素
2.2.2 识别参与者
2.2.3 合并需求获得用例
2.2.4 细化用例描述
2.3 分析模型
2.3.1 定义概念类
…目录
1. 软件需求
1.1 需求分类
1.2 需求获取
1.3 需求分析
2. 面向对象分析OOA
2.1 统一建模语言 UML
2.2 用例模型
2.2.1 用例图的元素
2.2.2 识别参与者
2.2.3 合并需求获得用例
2.2.4 细化用例描述
2.3 分析模型
2.3.1 定义概念类
2.3.2 确定类之间的关系
2.3.3 为类添加职责 1. 软件需求 在软件生命周期中需求分析是⾮常重要的⼀步在进行需求分析前我们需要先了解⼀下需求的分类以及如何获取需求。 1.1 需求分类
业务需求指反映企业或客户对系统的目标要求通常来自与企业内部。用户需求描述的是用户的具体目标或用户要求系统必须能完成的任务。系统需求从系统角度来说明软件的需求包括功能需求(系统必须实现的功能)、非功能需求(比如软件的质量可维护性效率等等)和设计约束(交付时的一些限制条件比如必须采用国有自主知识产权的数据库必须运行在某个操作系统下)等等。
1.2 需求获取 需求获取的方式主要有以下几种 用户访谈最基本的方式。问卷调查由于对用户进行逐一访谈比较耗时且用户时间不一定允许及时参与访谈所以可以预先准备问卷调查表让用户填写再根据结果进行小范围访谈可以看做是对用户访谈的一种优化。采样对特定群体进行采样研究所选出的样本得到有用信息。对于信息系统的开发现在文档就是采样种群。情节串联板通过一系统图片、幻灯片来进行讲解说明系统应该如何运行。
1.3 需求分析
获取需求后进行具体的需求分析工作最终形成软件需求规格说明书做为向下⼀个阶段交付的 成果。 工作内容有以下几点 绘制系统上下文范围关系图用于定义系统与系统外部实体间界限和接口的简单模型为需求确定范围创建用户界面原型可以通过快速开发工具开发一个原型或者通过幻灯片、Flash等演示工具制作一个演示原型甚至可以通过纸笔画出一些关键的界面接口示意图从而帮助用户更好的理解要解决的问题理解系统;分析需求的可行性对获取到的需求进行成本、性能和技术实现方面的可行性研究以及是否与其他的需求存在冲突是否有对外部的依赖等;确定需求的优先级是制订迭代计划的一个重要的依据可以使用满意和不满意指标进行说明。满意度表示当需求被实现时用户的满意程度不满意度表示当需求未被实现时用户的不满意程度为需求建立模型表现形式主要是图表加上少量的文字描述图形化的描述使需求更加清晰、易懂。需求分析模型主要描述系统的数据、功能、用户界面和运行的外部行为并不会涉及软件的具体实现细节同时为后续的软件设计提供了系统的表示视图创建数据字典对系统用到的所有数据项和结构进行定义以确保开发人员使用统一的数据定义。 2. 面向对象分析OOA OOA的基本任务是运用面象对象方法对问题域进行分拆和理解正确认识事物间的关系找 出描述问题域和系统功能的类和对象定义它们的属性和职责以及它们之间形成的各种联系。 2.1 统一建模语言 UML
UML(Unified Modeling Language)是一种易于表达、功能强大且普遍适用的建模语言它的作用不限于支持OOA和OOD还支持从需求分析开始的软件开发全过程。 UML的重要组成部分
事物事物也称为建模元素包括结构事物、行为事物、分级事物和注释事物这些事物是UML模型中最基本的OO构造块;关系UML用关系把各个事物结合在一起主要的关系有: 依赖(dependency)、关联association)、泛化(generalization)、实现(realization);图主要包括类图、对象图、构件图、组合结构图、用例图、顺序图、通信图、定时图、状态图、活动图、部署图、制品图、包图、交互概览图等。
2.2 用例模型
从用户的角度来看他们并不想了解系统的内部结构和设计他们关心的是系统所能提供的服务把从用户那里获取的需求记录下来进行合成与提炼从而建立用例模型。在OOA方法中构建用例模型一般需要经历以下阶段分别的识别参与者、合并需求获得用例、细化用例描述和调整用例模型其中前三个阶段是必需的。
2.2.1 用例图的元素
用例是一种描述系统需求的方法在用例图中主要包括参与者、用例和通信关联三种元素如下图所示。 参与者参与者是指存在于系统外部并与系统进行交互的任何事物既可以是使用系统的用户也可以是其他外部系统和设备等用例指在系统中执行的动作这些动作将生成参与者可见的结果。也就是说用例表示系统所提供的服务它定义了系统是如何被参与者所使用描述的是参与者为了使用系统提供的服务与使用发生的一段对话通信关联表示的是参与者和用例之间的关系或者用例与用例之间的关系。箭头所指方是对话的被动接受者箭尾所指方是对话的主动发起者如果不想强调对话中的主动与被动关系可以使用不带箭头的关系实线。
2.2.2 识别参与者
参与者是与系统交互的所有事物不仅可以由人承担还可以是其他系统和硬件设备要注意的是参与者一定在系统之外不是系统的一部分。执行系统功能的参与者可能有多个有主次之分开发用例的主要目的是找到主要参与者。
2.2.3 合并需求获得用例
将参与者都找到之后接下来就要仔细检查参与者为每个参与者确定用例。 首先要将获取到的需求分配给参与者比如普通用户可以进行注册登录编辑个人信息发贴子修改自己发的贴子发站内信等等管理员不仅可以进行普通用户的操作还可以进行版块管理等等。 其次进行需求合并操作并产生用例比如对于帖子来说可以相关的操作描述成具体的动作如发布帖子修改帖子删除帖子在这里合并为操作帖子。注用例并不需要包括具体的操作流程(事件流)事件流将在细化用例描述中体现。 然后将识别到的参与者和合并生成的用例通过用例图的形式表示出来至此以获得用例模型的框架。如下图所示 2.2.4 细化用例描述
用例描述可以迭代完成先对一些重要的用例编制相对细致的描述对于那些不重要的用例可以留待以后再补充完成用例描述通常包括用例名称、简要说明、事件流、非功能需求、前置和后置条件、扩展点、优先级。
2.3 分析模型
2.3.1 定义概念类
概念类模型中可以代表事物与概念的对象。
OOA的主要任务就是找到系统中的对象和类这些类将反映到OOD中的软件类和OOP中具体的实现类。 发现类的方式有很多种其中应用最广泛的是名词短语法具体步骤如下:
阅读和理解需求文档或用例描述筛选出名词或名词短语建立初始类清单(候选类)将候选类分为三类:分别是显而易见的类明显无意义的类和不确定类别的类舍弃明显无意义类别的类讨论不确定类别的类直到把他们合并或调整到其他两个类别。
2.3.2 确定类之间的关系 当完成了类的寻找⼯作之后就是理清这些类之间的关系类之间的关系有关联、依赖、泛 化、聚合、组合和实现他们在UML中的表示方式如下 关联关系提供不同类的对象之间的结构关系而不是类与类之间的关系两个对象之间一般以动词连接比如用户-发布-帖子可以用一个箭头连接表示关联关系对象可以从一个端得到另一端对象如果没有箭头认为是一个双向关系或是一个未定义的关联依赖关系两个类A和 B如果B变化可能会引起A的变化则称类A依赖与B比如一个类是另一个类的数据成员一个类是另一个类的某个操作的参数等聚合关系共享聚集关系通常简称为聚合关系他表示了类之间整体与部分的关系“部分”可以属于不同的“整体”“部分”与“整体”的生命周期可以不同比如汽车和车轮一个汽有一多个轮子汽车坏了轮子还可以用轮了坏了可以再换一个组合关系组合聚集关系通常简称为组合关系他也表示了类之间整体与部分的关系与聚合关系的区别在于组合关系中的“部分”只能属于一个“整体”“部分”与“整体”的生命周期相同比如一个公司有多个部门他们之间就是组合关系公司一旦倒闭部分也就不存在了实现关系:描述的是类和接口之间的关系一个类可以实现接口中声明的方法泛化关系:描述的是父类与子类之间的关系继承关系是泛化关系的反关系也就是说子类继承了父类而父类是子类的泛化。
2.3.3 为类添加职责
在找到概念类并且理清了他们之间的关系后就可为类添加职责主要包括两方面内容
类所维护的知识即成员变量或属性 注意要保持属性的简单性即:只定义与系统责任和目标相关的属性使用简单数据类型定义不为类关联定义属性。类能够执行的行为即成员方法或责任 可以根据动词来判断再进行筛选与识别类的过程类似。
这个阶段只找出一些主要的、明显、与业务规则相关的部分切忌在这个阶段不断地细化 。
