软件总体分析

㈠ 软件需求的分析方法

软件需求分析方法大体分为如下四类：结构化方法、面向对象方法、面向控制方法和面向数据方法。限于篇幅，将主要从结构化方法和面向对象方法以及RUP三个方面进行简要的探讨。 面向对象（Object Oriented, OO）的方法把分析建立在系统对象以及对象间交互的基础之上，使得我们能以3个最基本的方法框架——对象及其属性、分类结构和集合结构来定义和沟通需求。面向对象的问题分析模型从3个侧面进行描述，即对象模型(对象的静态结构)、动态模型(对象相互作用的顺序)和功能模型(数据变换及功能依存关系)。需求工程的抽象原则、层次原则和分割原则同样适用于面向对象方法，即对象抽象与功能抽象原则是一样的，也是从高级到低级、从逻辑到物理，逐级细分．每一级抽象都重复对象建模(对象识别)一动态建模(事件识别)一功能建模(操作识别)的过程，直到每一个对象实例在物理(程序编码)上全部实现为止。
面向对象需求分析(OORA)利用一些基本概念来建立相应模型，以表达目标系统的不同侧面。尽管不同的方法所采用的具体模型不尽相同，但都无外乎用如下五个基本模型来描述软件需求：
整体—部分模型：该模型描述对象(类)是如何由简单的对象（类）构成的。将一个复杂对象(类)描述成一个由交互作用的若干对象(类)构成的结构的能力是OO途径的突出优点。该模型亦称聚合模型。
分类模型：分类模型描述类之间的继承关系。与聚合关系不同，它说明的是一个类可以继承另一个或另一些类的成分，以实现类中成分的复用。
类—对象模型：分析过程必须描述属于每个类的对象所具有的行为，这种行为描述的详细程度可以根据具体情况而定。既可以只说明行为的输入、输出和功能，也可以采用比较形式的途径来精确地描述其输入、输出及其相应的类型甚至使用伪码或小说明的形式来详细刻画。
对象交互模型：一个面向对象的系统模型必须描述其中对象的交互方法。如前所述，对象交互是通过消息传递来实现的。事实人对象交互也可看作是对象行为之间的引用关系。因此，对象交互模型就要刻画对象之间的消息流。对应于不同的详细程度，有不同的消息流描述分析，分析人员应根据具体馆况而选择。一般地，一个详细的对象交互模型能够说明对象之间的消息及其流向，并且同时说明该消息将激活的对象及行为。一个不太详细的对象交互模型可以只说明对象之间有消息，并指明其流向即可。还有一种状况就是介于此两者之间。
状态模型：在状态模型中，把一个对象看作是一个有限状态机，由一个状态到另一状态的转变称作状态转换。状态模型将对象的行为描述成其不同状态之间的通路。它也可以刻画动态系统中对象的创建和废除，并称由对象的创建到对象的废除状态之间的退路为对象的生存期。
状态模型既可以用状态转换因的图形化手段，又可用决策表或称决策矩阵的形式来表。 RUP（Rational Unified Process）是Rational公司开发和维护的过程产品。RUP是工程化的软件开发过程，它提供了在开发机构中分派任务和责任的纪律化方法。RUP不仅仅是一个简单的过程，而是一个通用的过程框架，可用于各种不同类型的软件系统、各种不同的应用领域、各种不同类型的组织、各种不同的功能级别以及各种不同的项目规模。RUP的突出特点可以由以下三个关键词来体现——用例驱动、以构架为中心、迭代和增量的。这些是RUP所特有的，也是同等重要的。构架提供了一种结构来指导迭代过程中的工作，而用例则确定了目标井驱动每次迭代的工作。
进行需求分析的基础是要获得用户的需要，为了完成这一工作，必须建立业务模型，通过描述业务规则、业务逻辑，明确业务过程并对其进行规范、优化。对于一个系统，在建立业务模型时，应从3个方面来描述其特性：功能、行为、数据，对应于这些特性。 基于上述分析可知，结构化分析方法与面向对象分析方法的区别主要体现在两个方面：
* 将系统分解成于系统的方式不同。前者将系统描述成一组交互作用的处理，后者则描述成一组交互作用的对象。
* 子系统之间的交互关系的描述方式不一样。前者加工之间的交互是通过不太精确的数据流来表示的，而后者对象之间通过消息传递交互关系。
因此，面向对象软件需求分析的结果能更好地刻画现实世界，处理复杂问题，对象比过程更具有稳定性，便于维护与复用。

㈡ 软件总体设计以什么为基础

总体设计阶段必须以需求分析的结果（数据流图＋数据字典）为基础进行设计，以得到系统的框架。

总体设计的基本目的就是回答“概括地说，系统应该如何实现”这个问题，因此，总体设计又称为概要设计或初步设计。

总体设计阶段的另一项重要任务是设计软件的结构，也就是要确定系统中每个程序是由哪些模块组成的，以及这些模块相互间的关系。

在总体设计阶段分析员应该考虑各种可能的实现方案，并且力求从中选出最佳方案。

需求分析阶段得出的数据流图是总体设计的极好的出发点。

设想供选择的方案的一种常用的方法是，设想把数据流图中的处理分组的各种可能的方法，抛弃在技术上行不通的分组方法（例如，组内不同处理的执行时间不相容），余下的分组方法代表可能的实现策略，并且可以启示供选择的物理系统。

㈢ 如何进行项目的硬件分析和软件分析

本文结合自己的经验，从实践的角度，对项目软件的分析工作从7个方面进行了阐述，并指出一些容易失误的做法。希望能对从事分析工作的同仁有所参考。
这一点对于获取真正的用户要求非常重要。通常，客户方会组织专工以上层次的人或在单位小有名气的计算机能手来和开发方分析人员配合，共同整理需求。
应该对客户方配合人员进行分类，层次化，使之和分析的各阶段相对应。
分析的初期，即总体分析阶段，需要得到整体意义上的轮廓需求，此时，应与客户方总工以上层次的人员进行交流，这一层次的人，对未来的系统会有完整的描绘，可以划分出子系统，及其之间的关系，这也是高级管理层对系统的期望。可以以此作为纲领性的文档指导进一步的分析，并约束后续的分析过程，避免需求范围漫无边际的扩大；
专业系统分析阶段，通常，客户单位都会有专业分工，彼此之间既相互独立，又会在某些点上发生联系。此阶段应与客户方专工层次的人员进行深入的讨论。这一层次的人，对自己的专业相当熟悉，对专业内的需求会非常到位，大都年富力强，有相当的阅历和理解能力，甚至自己都可以绘制业务流图，总结业务功能点。对他们应充分鼓励，尽量调动其积极性；

系统关联分析阶段，在各专业系统得到充分分析的基础上，紧接着就要理清它们之间的关系，这是提升需求档次的关键阶段，也是高级领导层和专工都关心的阶段。通常，客户单位都会有一些零散的软件，如财务软件，部颁软件等，这些专业软件都发挥着重要的作用，但都是些信息孤岛，客户会很自然的希望能把这些信息融合到整个系统中来，为更多的人所共享。同时，也希望数据能够在各专业系统间顺畅的流动，从而减少重复劳动，提高工作效率。此阶段应把总工层和专工层召集到一起，共同理清系统间的接口。

经过这三个阶段，对需求的描述将比较准确和完整。

㈣ 软件工程里面总体设计的原则是什么

系统总体结构设计是要根据系统分析的要求和组主的实际情况来对新系统的总体结构形式和可利用的阻援进行大致的设计，是宏观上的规划。在总体设计阶段应该将系统的物理元素划分出来——程序、文件、数据库、人工过程和文档

㈤ 软件的需求分析怎么写啊

软件需求分析免费下载

链接:https://pan..com/s/1qNBwqvbRS5ziBSIeanLQAQ

需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。

㈥ PROE软件总体说明

ro/ENGINEER Foundation XE
Pro/CONCEPT 概念设计
Pro/ENGINEER 高级装配
Pro/ENGINEER 交互式曲面设计II
Pro/ENGINEER Advance Render 高级渲染
Pro/ENGINEER Reverse Engineering 逆向工程

Pro/ENGINEER Mechanism Dynamics 机构动力学
Pro/ENGINEER Mechanica 结构和热传导分析
Pro/ENGINEER Fatigue Advisor 疲劳分析模块
Pro/ENGINEER Behavioral Modeling 行为建模
Pro/ENGINEER Plastic Advisor 塑料顾问

Pro/ENGINEER Interface for CATIA II with ATB
Pro/ENGINEER Interface for CATIA V5 with ATB
Pro/ENGINEER Interface for I-DEAS
Pro/ENGINEER Interface for Unigraphics with ATB

Pro/ENGINEER Routed Systems Designer 布线系统设计工具
Pro/ENGINEER Piping Design 管道设计
Pro/ENGINEER Cabling Design 电缆敷设设计

Pro/ENGINEER Tool Design 模具型芯和型腔设计
Pro/ENGINEER Expert Moldbase 模架设计
Pro/ENGINEER Complete Mold Design 完整模具设计包
Pro/ENGINEER Prismatic and Multi-surface Milling 棱柱和多曲面铣削
Pro/ENGINEER Proction Machining 生产加工
Pro/ENGINEER Complete Machining 完整加工
Pro/ENGINEER Expert Framework 框架结构设计专家
Pro/ENGINEER Progressive Die 级进模设计
Pro/ENGINEER NC Sheetmetal 钣金加工

Pro/TOOLKIT Customization API （二次开发）
GRANITE Interoperability Kernel （软件内核）
Pro/INTRALINK 工作组数据管理

㈦ 软件总体设计过程中需要遵守哪些基本原理

定义
软件工程一直以来都缺乏一个统一的定义，很多学者、组织机构都分别给出了自己的定义：

Boehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。

IEEE：软件工程是开发、运行、维护和修复软件的系统方法。

Fritz Bauer：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。
目前比较认可的一种定义认为：软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。

软件工程学的内容
软件工程学的主要内容是软件开发技术和软件工程管理．
软件开发技术包含软件工程方法学、软件工具和软件开发环境；软件工程管理学包含软件工程经济学和软件管理学。

软件工程基本原理
著名软件工程专家B.Boehm综合有关专家和学者的意见并总结了多年来开发软件的经验，于1983年在一篇论文中提出了软件工程的七条基本原理。
（1）用分阶段的生存周期计划进行严格的管理。
（2）坚持进行阶段评审。
（3）实行严格的产品控制。
（4）采用现代程序设计技术。
（5）软件工程结果应能清楚地审查。
（6）开发小组的人员应该少而精。
（7）承认不断改进软件工程实践的必要性。
B.Boehm指出，遵循前六条基本原理，能够实现软件的工程化生产；按照第七条原理，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验。
软件工程(SoftWare Engineering)的框架可概括为：目标、过程和原则。
(1)软件工程目标：生产具有正确性、可用性以及开销合宜的产品。正确性指软件产品达到预期功能的程度。可用性指软件基本结构、实现及文档为用户可用的程度。开销合宜是指软件开发、运行的整个开销满足用户要求的程度。这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题，它们形成了对过程、过程模型及工程方法选取的约束。
(2)软件工程过程：生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件工程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、确认以及维护等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义，又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。维护活动包括使用过程中的扩充、修改与完善。伴随以上过程，还有管理过程、支持过程、培训过程等。
(3)软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。

软件工程必须遵循什么原则
围绕工程设计、工程支持以及工程管理已提出了以下四条基本原则：

(1)选取适宜的开发模型

该原则与系统设计有关。在系统设计中，软件需求、硬件需求以及其它因素间是相互制约和影响的，经常需要权衡。因此，必需认识需求定义的易变性，采用适当的开发模型，保证软件产品满足用户的要求。

(2)采用合适的设计方法

在软件设计中，通常需要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征。合适的设计方法有助于这些特征的实现，以达到软件工程的目标。

(3)提供高质量的工程支撑

工欲善其事，必先利其器。在软件工程中，软件工具与环境对软件过程的支持颇为重要。软件工程项目的质量与开销直接取决于对软件工程所提供的支撑质量和效用。

(4)重视软件工程的管理

软件工程的管理直接影响可用资源的有效利用，生产满足目标的软件产品以及提高软件组织的生产能力等问题。因此，仅当软件过程予以有效管理时，才能实现有效的软件工程。

软件工程是指导计算机软件开发和维护的工程学科。

采用工程的概念、原理、 技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够 得到的最好的技术方法结合起来，这就是软件工程。

软件工程强调使用生存周期方法学和各种结构分析及结构设计技术。它们是在七十年代为了对付应用软件日益增长的复杂程度、漫长的开发周期以及用户对软件产品经常不满意的状况而发展起来的。人类解决复杂问题时普遍采用的一个策略就是“各个击破”，也就是对问题进行分解然后再分别解决各个子问题的策略。软件工程采用的生存周期方法学就是从时间角度对软件开发和维护的复杂问题进行分解，把软件生存的漫长周期依次划分为若干个阶段，每个阶段有相对独立的任务，然后逐步完成每个阶段的任务。采用软件工程方法论开发软件的时候，从对任务的抽象逻辑分析开始，一个阶段一个阶段地进行开发。前一个阶段任务的完成是开始进行后一个阶段工作的前提和基础，而后一阶段任务的完成通常是使前一阶段提出的解法更进一步具体化，加进了更多的物理细节。每一个阶段的开始和结束都有严格标准，对于任何两个相邻的阶段而言，前一阶段的结束标准就是后一阶段的开始标准。在每一个阶段结束之前都必须进行正式严格的技术审查和管理复审，从技术和管理两方面对这个阶段的开发成果进行检查，通过之后这个阶段才算结束；如果检查通不过，则必须进行必要的返工，并且返工后还要再经过审查。审查的一条主要标准就是每个阶段都应该交出“最新式的”（即和所开发的软件完全一致的）高质量的文档资料，从而保证在软件开发工程结束时有一个完整准确的软件配置交付使用。文档是通信的工具，它们清楚准确地说明了到这个时候为止，关于该项工程已经知道了什么，同时确立了下一步工作的基础。此外，文档也起备忘录的作用，如果文档不完整，那么一定是某些工作忘记做了，在进入生存周期的下一阶段之前，必须补足这些遗漏的细节。在完成生存周期每个阶段的任务时，应该采用适合该阶段任务特点的系统化的技术方法──结构分析或结构设计技术。

把软件生存周期划分成若干个阶段，每个阶段的任务相对独立，而且比较简单，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度；在软件生存周期的每个阶段都采用科学的管理技术和良好的技术方法，而且在每个阶段结束之前都从技术和管理两个角度进行严格的审查，合格之后才开始下一阶段的工作，这就使软件开发工程的全过程以一种有条不紊的方式进行，保证了软件的质量，特别是提高了软件的可维护性。总之，采用软件工程方法论可以大大提高软件开发的成功率，软件开发的生产率也能明显提高。

目前划分软件生存周期阶段的方法有许多种，软件规模、种类、开发方式、开发环境以及开发时使用的方法论都影响软件生存周期阶段的划分。在划分软件生存周期的阶段时应该遵循的一条基本原则就是使各阶段的任务彼此间尽可能相对独立，同一阶段各项任务的性质尽可能相同，从而降低每个阶段任务的复杂程度，简化不同阶段之间的联系，有利于软件开发工程的组织管理。一般说来，软件生存周期由软件定义、软件开发和软件维护三个时期组成，每个时期又进一步划分成若干个阶段。下面的论述主要针对应用软件，对系统软件也基本适用。

软件定义时期的任务是确定软件开发工程必须完成的总目标；确定工程的可行性，导出实现工程目标应该采用的策略及系统必须完成的功能；估计完成该项工程需要的资源和成本，并且制定工程进度表。这个时期的工作通常又称为系统分析，由系统分析员负责完成。软件定义时期通常进一步划分成三个阶段，即问题定义、可行性研究和需求分析。

开发时期具体设计和实现在前一个时期定义的软件，它通常由下述四个阶段组成：总体设计，详细设计，编码和单元测试，综合测试。

维护时期的主要任务是使软件持久地满足用户的需要。具体地说，当软件在使用过程中发现错误时应该加以改正；当环境改变时应该修改软件以适应新的环境；当用户有新要求时应该及时改进软件满足用户的新需要。通常对维护时期不再进一步划分阶段，但是每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。

㈧ 如何进行软件系统分析

实体类通常指系统中需要持久化的类，代表系统中的核心概念。 软件系统分析目前用的较多的方法就是鲁棒（Robust）分析，也就是健壮性分析。 首先根据用例的描述设计系统的边界类、实体类，和控制类。 一、边界类 边界类描述系统与角色的接口，通常是图形用户界面，通信协议、打印机接口、传感器和终端。最常见的就是窗体。那窗体中的各种控件算不算呢？不算，窗体本身是最合适的边界类，而其中的控件就太细小了。 二、控制类 控制类表示系统的动态行为，处理主要的任务和控制流。简单的说控制类指的就是业务逻辑，他通常独立于实体类和边界类，稳定性较好。 如果业务流程比较复杂，则需要单独设计控制类。 通常一个控制类只和一个角色进行交互，这是基于最小化变更对系统的影响来考虑的。 三、实体类 四、关系限制 不同的类之间关系的建模有些是必要的，有些则是需要避免的。 边界类－＞实体类允许：因为边界对象可能需要在这个边界对象的各个操作之间对某些实体对象进行跟踪。 边界类＜-＞控制类避免：因为关系是短时间存在的，所以没必要建模。 边界类＜-＞边界类允许 控制类＜-＞控制类避免：因为关系是短时间存在的，所以没必要建模。 控制类-＞实体类允许 实体类＜-＞实体类允许 实体类-＞边界类不允许 实体类-＞控制类不允许 实体类对象的生存期一般都很长；而控制类对象和边界类对象的生存期则很短。正是由于这些类的生存期相差如此之大，所以在这些类之间建立关联关系是不可取的。 五、类设计的原则 １、不同的类之间如果存在相似的职责，考虑重用现有类，如果没有有重用可能的类，才考虑建立新的类。 ２、如果一个类的两个职责之间互不相关，考虑将这个类分成两个。并更新相应的协作关系。 ３、如果一个类只有一项职责，那么需要重新考虑该类存在的必要性.

㈨ 软件系统的总体结构

钻孔设计与轨迹动态监控CAD软件系统主要包括钻孔设计和钻孔轨迹动态监控两大模块。钻孔设计模块包括钻孔结构设计、初级定向钻孔设计与受控定向钻孔轨迹设计、钻探工程综合图的绘制、钻孔设计书及钻孔地质柱状图的自动生成等子模块;钻孔轨迹动态监控模块包括钻孔轨迹在地下空间的精确定位、钻孔轨迹自然弯曲规律分析、钻孔设计轨迹与实际轨迹的对比及根据钻孔实际轨迹偏差跟踪设计钻孔纠斜或造斜的轨迹控制参数等子模块。软件系统的总体结构见图8-3,设有9个应用功能模块和1个数据库模块。为进一步增强钻孔轨迹直观显示效果,软件系统还设置有钻孔轨迹三维动态演示。

为方便野外工作人员使用,软件功能模块采用外部彼此独立、内部紧密联系的总体结构方式,系统各模块功能目标明确,操作步骤采用文字空格光标和功能键提示方式。各功能模块均设计有数据录入界面,并可以将录入的数据保存在统一的数据库文件中便于相互调用。

图8-3 多功能定向钻探软件系统总体结构图