摘要:系统分析的主要任务似乎对现行的系统进一步详细调查,将调查到的文挡资料集中,对组织内部整体管理状况和信息处理过程进行分析,为系统开发提供所需的资料,并提交系统方案说明书;
系统分析基础知识
1、系统分析的目的和任务
系统分析的主要任务似乎对现行的系统进一步详细调查,将调查到的文挡资料集中,对组织内部整体管理状况和信息处理过程进行分析,为系统开发提供所需的资料,并提交系统方案说明书;
系统分析侧重于从业务全过程的角度进行分析,确定分析结果,提出信息系统的各种设想和方案,并对所有的设想和方案进行分、研究、比较、判断和选择,获得一个最优的新系统的逻辑模型,并在用户理解计算机系统的工作流程和处理方式的情况下,将它明确的表达成书面资料—系统分析报告,即系统方案说明书。
系统分析阶段的结果是得到目标系统的逻辑模型,系统分析的主要步骤:
1)对当前的系统进行详细调查,收集数据;
2)建立当前系统的逻辑模型
3)对现状分析,提出改良意见和新年系统应达到的目标
4)建立新系统的逻辑模型
5)编写系统方案说明书
2、结构化分析方法
采用结构化的分析方法对一个系统进行分析可以从下面几个步骤出发:
需求分析
需求分析是对处理对象进行系统调查,在完全弄清楚用户对新系统的确切要求后,用统一、规范的图表和书面语言表达出来,它是系统开发工作中最重要的环节之一。
①系统范围和系统目标分析:
确定系统的范围、定义业务目标,主要完成3个任务:
n确定系统范围:把系统范围文档化;
n确定系统需求:把业务目标、系统目标和关键功能需求文档化;
n系统内容说明书:系统反问、需求描述和分析中产生的其他信息
②系统组织结构与功能分析:
调查组织发展目标及战略规划,了解组织的现状及管理体制,划分各个功能,分清组织内各种流向,如物资流(正向)、资金流(反向)和信息流(双向),可以使用组织结构图和业务功能图来分析;
③系统性能分析:
性能评价指标是客观评价信息系统性能的依据,一般包括系统平均无故障时间,系统联机响应时间、处理速度、吞吐量、操作灵活性,系统加工数据的准确性,系统的可扩充性等。
业务流程分析:
业务流程分析的目的是为了了解各个行业业务流程的过程,明确各个部门之间的关系,明确哥哥业务处理的意义,位业务流程的合理化改造提供建议,为系统的数据流程化提供依据,主要有以下几个步骤:
①组织结构于业务流程详细调查:
按现行系统物质、信息或数据流动的过程,逐个调查现行系统中每个环节物质流、信息流或数据流,以弄清每个环节的物质流和信息流的来源和去向,并将现行系统按数据加工的顺序进行描述。
②业务流程图和系统概况图:
业务流程分析是描述现行系统的物理模型,现行系统概况图再现行系统业务流程图基础上提取系统的基本要素—输入、输出、处理、存储和外部环境等编制而成。
③业务流程优化与再造:
为了提高企业的核心能力,可以对企业的业务流程进行改善和再造,。其中改善是对原来业务流程的连续的、渐进的改善,而再造是对企业业务流程的根本的再思考和再设计,从而使企业的关键绩效得到提高。
数据流程分析:
数据流程分析就是吧数据再现行系统内部的流动情况抽象出来,舍去了具体组织机构、信息载体、处理工作等物理组成,单纯从数据流动过程来考察实际业务的数据处理模式。数据流程分析主要包括信息流动、传递、处理、存储等的分析,目的就是确定数据项,合适的数据流向和合适的处理过程,并发现和解决数据流通中出现的问题。
一个系统的基本组成部件包括输入流、输出流和处理过程。数据流是用于记录系统中各种流的抽象表达形式。数据流贯穿在组织内的每个活动中,数据流是用以控制其他流的,而事务流则是被控制的对象。
数据流图是一种便于用户理解、分析系统数据流程的图形工具,是逻辑模型的组成部分。数据流图是信息活动的抽象,描述的内容是面向用户的,一般遵循以下原则:
n明确系统边界
n总体上遵循自顶向下的原则
n在局部上遵循由外向里的原则
数据流图的绘制一般用以下步骤:
n识别系统的输入和输出
n绘制系统内部数据流
n对复杂加工进行分解
n对草图进行检查和合理布局
n和用户交流
n检查、修改、完善
数据字典
数据字典是系统逻辑模型的详细、具体说明,是系统分析阶段的重要文件,实际上是一个关于数据的数据库。
编制数据字典的基本要求:
n对数据流图上的各种成分的定义必须明确
n命名、编号和数据流图一致
n符合一致性与完整性要求
n模式规范、风格统一、蚊子精炼,数字符号正确
数据字典中有6类条目:
n数据元素:最小的数据组成单位
n数据结构:数据之间的组合关系
n数据流:数据流的来源、去向、组成、流通量
n数据存储:数据存储的结构和有关数据流、查询要求
n外部实体:外部实体是数据的来源和去向
n处理:需要在数据字典中描述的处理框的编号、名称、功能的简要说明以及有关的输入和输出。
3、统一建模语言(UML)
UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计,还支持从需求分析开始的软件开发的全过程。
然UML不是一种方法学,它就不需要任何正式的工作产品。而且它还提供了多种类型的模型描述图(diagram),当在某种给定的方法学中使用这些图时,它使得开发中的应用程序的更易理解。UML的内涵远不只是这些模型描述图,但是对于入门来说,这些图对这门语言及其用法背后的基本原理提供了很好的介绍。通过把标准的UML图放进您的工作产品中,精通UML的人员就更加容易加入您的项目并迅速进入角色。最常用的UML图包括:用例图、类图、序列图、状态图、活动图、组件图和部署图。
用例图:
用例图描述了系统提供的一个功能单元。用例图的主要目的是帮助开发团队以一种可视化的方式理解系统的功能需求,包括基于基本流程的"角色"(actors,也就是与系统交互的其他实体)关系,以及系统内用例之间的关系。用例图一般表示出用例的组织关系--要么是整个系统的全部用例,要么是完成具有功能(例如,所有安全管理相关的用例)的一组用例。要在用例图上显示某个用例,可绘制一个椭圆,然后将用例的名称放在椭圆的中心或椭圆下面的中间位置。要在用例图上绘制一个角色(表示一个系统用户),可绘制一个人形符号。角色和用例之间的关系使用简单的线段来描述.
用例图通常用于表达系统或者系统范畴的高级功能。此外,在用例图中,没有列出的用例表明了该系统不能完成的功能。在用例图中提供清楚的、简要的用例描述,项目赞助商就很容易看出系统是否提供了必须的功能。
类图:
类图表示不同的实体(人、事物和数据)如何彼此相关;换句话说,它显示了系统的静态结构。类图可用于表示逻辑类,逻辑类通常就是业务人员所谈及的事物种类--摇滚乐队、CD、广播剧;或者贷款、住房抵押、汽车信贷以及利率。类图还可用于表示实现类,实现类就是程序员处理的实体。实现类图或许会与逻辑类图显示一些相同的类。然而,实现类图不会使用相同的属性来描述,因为它很可能具有对诸如Vector和HashMap这种事物的引用。
类在类图上使用包含三个部分的矩形来描述。最上面的部分显示类的名称,中间部分包含类的属性,最下面的部分包含类的操作(或者说"方法")。
序列图:
序列图显示具体用例(或者是用例的一部分)的详细流程。它几乎是自描述的,并且显示了流程中中不同对象之间的调用关系,同时还可以很详细地显示对不同对象的不同调用。
序列图有两个维度:垂直维度以发生的时间顺序显示消息/调用的序列;水平维度显示消息被发送到的对象实例。
序列图的绘制非常简单。横跨图的顶部,每个框表示每个类的实例(对象)。在框中,类实例名称和类名称之间用空格/冒号/空格来分隔,例如,myReportGenerator:ReportGenerator。如果某个类实例向另一个类实例发送一条消息,则绘制一条具有指向接收类实例的开箭头的连线,并把消息/方法的名称放在连线上面。对于某些特别重要的消息,您可以绘制一条具有指向发起类实例的开箭头的虚线,将返回值标注在虚线上。就我而言,我总喜欢绘制出包括返回值的虚线,这些额外的信息可以使得序列图更易于阅读。
阅读序列图也非常简单。从左上角启动序列的"驱动"类实例开始,然后顺着每条消息往下阅读。
状态图:
状态图表示某个类所处的不同状态和该类的状态转换信息。有人可能会争论说每个类都有状态,但不是每个类都应该有一个状态图。只对"感兴趣的"状态的类(也就是说,在系统活动期间具有三个或更多潜在状态的类)才进行状态图描述。
状态图的符号集包括5个基本元素:初始起点,它使用实心圆来绘制;状态之间的转换,它使用具有开箭头的线段来绘制;状态,它使用圆角矩形来绘制;判断点,它使用空心圆来绘制;以及一个或者多个终止点,它们使用内部包含实心圆的圆来绘制。要绘制状态图,首先绘制起点和一条指向该类的初始状态的转换线段。状态本身可以在图上的任意位置绘制,然后只需使用状态转换线条将它们连接起来。
活动图:
活动图表示在处理某个活动时,两个或者更多类对象之间的过程控制流。活动图可用于在业务单元的级别上对更高级别的业务过程进行建模,或者对低级别的内部类操作进行建模。根据我的经验,活动图最适合用于对较高级别的过程建模,比如公司当前在如何运作业务,或者业务如何运作等。这是因为与序列图相比,活动图在表示上"不够技术性的",但有业务头脑的人们往往能够更快速地理解它们。
活动图的符号集与状态图中使用的符号集类似。像状态图一样,活动图也从一个连接到初始活动的实心圆开始。活动是通过一个圆角矩形(活动的名称包含在其内)来表示的。活动可以通过转换线段连接到其他活动,或者连接到判断点,这些判断点连接到由判断点的条件所保护的不同活动。结束过程的活动连接到一个终止点(就像在状态图中一样)。作为一种选择,活动可以分组为泳道(swimlane),泳道用于表示实际执行活动的对象.
该活动图中有两个泳道,因为有两个对象控制着各自的活动:乐队经理和报告工具。整个过程首先从乐队经理选择查看他的乐队销售报告开始。然后报告工具检索并显示他管理的所有乐队,并要求他从中选择一个乐队。在乐队经理选择一个乐队之后,报告工具就检索销售信息并显示销售报告。该活动图表明,显示报告是整个过程中的最后一步。
组件图:
组件图提供系统的物理视图。它的用途是显示系统中的软件对其他软件组件(例如,库函数)的依赖关系。组件图可以在一个非常高的层次上显示,从而仅显示粗粒度的组件,也可以在组件包层次2上显示。
部署图:
部署图表示该软件系统如何部署到硬件环境中。它的用途是显示该系统不同的组件将在何处物理地运行,以及它们将如何彼此通信。因为部署图是对物理运行情况进行建模,系统的生产人员就可以很好地利用这种图。
部署图中的符号包括组件图中所使用的符号元素,另外还增加了几个符号,包括节点的概念。一个节点可以代表一台物理机器,或代表一个虚拟机器节点(例如,一个大型机节点)。要对节点进行建模,只需绘制一个三维立方体,节点的名称位于立方体的顶部。
4、系统规格说明书
完成整个分析阶段的工作后,要提交一份完整的系统分析报告,在分析报告中,数据流图、数据字典和加工说明这三部分是主体。
系统分析报告应包含以下内容:
n组织情况概述
n现行系统概述
n系统逻辑模型
n新系统在各个业务处理环节采用的管理方法
n与新系统相配套的管理制度和运行体制
n系统设计与实施的初步计划
n用户领导审批意见
相关推荐
软考备考资料免费领取
去领取