ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

系统分析师

2026/9/29 11:16:38 拓冰建站 浏览量
系统分析师 系统分析师之软件工程云计算体系结构组成资源层资源层是指基础架构层间的云计算服务这些服务可以提供虚拟化的资源从而隐藏物理资源的复杂性。如服务器存储平台层为用户提供对资源层服务的封装使用户可以构建自己的应用。应用层提供软件服务如财务管理客户关系管理商业智能用户访问层方便用户使用云计算服务所需的各种支撑服务针对每个层次的云计算服务都需要提供相应的访问接口。管理层提供对所有层次云计算服务的管理功能。云计算的使用场景云计算是一种基于并高度依赖Internet用户与实际服务提供的计算资源相分离集合了大量计算设备和资源并向用户屏蔽底层差异的分布式处理架构。一般地当有以下需求时可以考虑使用云计算服务短时间内的中、大规模计算需求代建系统前期投入低并且总体拥有成本较优在充分相信云计算服务提供商的情况下的数据安全性需求在没有足够的服务器管理和 运维人员在终端设备配置较差的情况下完成较复杂的应用。WS-BPEL业务流程编排Web Services Business Process Execution Language可以理解成把多个Web Service串起来组成一个完整业务流程。IDEFIntegration DEFinition method,集成定义方法建模方法IDEF是一系列建模、分析和仿真方法的统称每套方法都是通过建模来获得某种特定类型的信息。软件开发模型传统软件开发模型大体上可分为三种类型1以软件需求完全确定为前提的瀑布模型2在软件开发初始阶段只能提供基本需求时采用的迭代式或渐进式开发模型例如喷泉模型、螺旋模型、统一开发过程和敏捷方法等3以形式化开发方法为基础的变换模型。The Firset Model:瀑布模型瀑布模型是一种严格定义方法它将软件开发的过程分为软件计划、需求分析、软件设计、程序编码、软件测试和运行维护6个阶段形如瀑布流水最终得到软件产品。瀑布模型是一个线性顺序模型支持线性开发。它假设当线性序列完成之后就能交付一个完善的系统并没有考虑软件的演化特征。其优点是强调开发的阶段性、早期计划和需求调查以及产品测试以这样严格的方式构造软件开发人员很清楚每一步应该怎么做有利于项目管理。缺点对于风险的控制能力较弱The Second Model:演化模型演化模型主要针对事先不能完整定义需求的软件开发是在快速开发一个原型的基础上根据用户在调用原型的过程中提出的反馈意见和建议对原型进行改进获得原型的新版本重复这一过程直到演化成最终的软件产品。优点任何功能一经开发就能进入测试以便验证是否符合产品需求可以帮助引导出高质量的产品要求。缺点如果不加控制地让用户接触开发中尚未稳定地功能可能会对开发人员和用户都会产生负面的影响。The Third Model:螺旋模型螺旋模型是瀑布模型与演化模型相结合并加入两者所忽略的风险分析所建立的一种软件开发模型。螺旋模型是一种演化软件过程模型它将原型实现的迭代特征与线性顺序模型中的控制和系统化的方面结合起来使软件的增量版本的快速开发成为可能。在螺旋模型中软件开发使一系列的增量发布。优点强调风险分析适用于庞大、复杂并具有高风险的系统缺点过多的迭代次数会增加开发成本延迟提交时间。The Fourth Model喷泉模型喷泉模型是一种以用户需求为动力以对象为驱动的模型主要用于描述面向对象的软件开发过程。各活动之间没有明显的边界The Fifth ModelV模型V模型是在快速应用开发的基础上演变而来的应用在软件测试方面V模型强调软件开发的协作和速度将软件实现和验证有机地结合起来在保证较高地软件质量的情况下缩短开发周期。V模型适合企业级的软件开发它更清楚地揭示了软件开发过程的特性及其本质。快速应用开发快速应用开发Rapid Application DevelopmentRAD是一种比传统生命周期法快得多的开发方法它强调极短的开发周期。RAD模型是瀑布模型的一个高速变种通过使用基于构件的开发方法获得快速开发。RAD的基本思想让用户更主动地参与到系统分析、设计和构造活动中来。将项目开发组织成一系列重点突出的研讨会研讨会要让项目投资方、用户、系统分析师、设计人员和开发人员一起参与。通过一种迭代的构造方法加速需求分析和设计阶段。让用户看到一个可工作的系统。敏捷方法数据库设计的四个阶段需求分析概念结构设计逻辑结构设计物理设计系统设计的主要内容包括概要设计和详细设计。概要设计又称为系统总体结构设计它是系统开发过程中很关键的一步其主要任务是将系统的功能需求分配给软件模块确定每个模块的功能和调用关系形成软件的模块结构图即系统结构图。在概要设计中将系统开发的总任务分解成许多个基本的、具体的任务为每个具体的任务选择适当的技术手段和处理方法的过程称为详细设计。根据任务的不同详细设计又可分很多种例如网络设计、代码设计、输入/输出设计、处理流程设计、数据存储设计、用户界面设计、安全性和可靠性设计等。软件的逆向工程工作流参考模型工作流管理系统的基本功能软件能力成熟度模型UML中事物之间的关系关系英文核心含义典型关键词UML表示依赖Dependency临时使用使用虚线箭头关联Association长期存在联系拥有/知道实线聚合Aggregation弱“整体—部分”包含空心菱形组合Composition强“整体—部分”共存亡实心菱形泛化Generalization继承is-a是一种实线空心三角实现Realization实现接口implements虚线空心三角UML的14种图① 依赖 DependencyA - - - - - B虚线普通箭头② 关联 AssociationA ───────── B实线③ 聚合 Aggregation整体 ◇────── 部分空心菱形④ 组合 Composition整体 ◆────── 部分实心菱形⑤ 泛化 Generalization子类 ───────▷ 父类实线空心三角⑥ 实现 Realization实现类 - - -▷ 接口虚线空心三角两个类是什么关系│├── A是一种B吗│ ↓ 是│ 泛化│├── A实现某接口吗│ ↓ 是│ 实现│├── A是B的一部分吗│ ↓│ 整体没了部分还能存在│ ││ ┌───┴───┐│ ↓ ↓│ 能 不能│ ↓ ↓│ 聚合 组合│├── 两者存在稳定业务联系│ ↓│ 关联│└── 只是临时调用/使用↓依赖UML的5个系统视图需求获取在软件工程中需求获取是非常重要的环节它需要开展一系列活动来获取正确的需求。通常软件需求获取的过程包括评审和完全理解系统需求和安全需求。软件工程师必须对系统需求非常熟悉。对初始安全评估的理解也是掌握安全驱动力所必需的。与客户、系统工程师、领域专家进行会谈回答系统需求中的问题并补充遗漏的系统需求。在撰写软件需求前确定系统需求和安全需求的成熟度和完整度。与系统工程师一起改进系统需求。在软件组把系统需求细化为软件需求之前系统需求必须应该相对成熟和稳定。复用过去相关项目的需求并考查这些项目的问题报告。定义初步的术语表以保持需求陈述的术语的一致性避免项目成员对术语的使用及其含义产生误解减少二义性。所有其他文档的文字说明中都应该始终如一地使用术语表中的术语。而软件设计过程活动的要求包括在设计过程期间开发的低级需求和软件体系结构要符合软件设计标准并且是可追踪、可验证和一致的。要定义和分析派生的需求并保证不损害高级需求。软件设计过程的活动可能引入失效模式到软件中或相反地影响其他的软件。在软件设计中采用划分或其他结构方法可改变某些软件部件的软件等级的分配。在这些情况下将定义附加资料作为派生需求并把这些资料提供给系统安全性评估过程。当规定与安全相关的需求时要监控控制流和数据流如看门狗定时器、合理的检查和交叉通道比较。对失效状态的响应要与安全性有关的要求一致。在软件设计过程中检测到的不合适的或不正确的输入将提供给 系统的生存周期过程、软件需求过程或软件测试过程作为澄清或纠正的反馈。用例VS类用例描述“系统要为用户做什么”类描述“系统内部由什么组成”。23种设计模式遗留系统的再利用问题软件开发方法、软件开发模型和软件设计方法软件工程 / 信息系统开发│├── ① 系统开发方法│ ├── 结构化方法│ ├── 原型化方法│ ├── 面向对象方法│ └── 面向服务方法 SOA│├── ② 软件开发模型│ ├── 瀑布模型│ ├── V模型│ ├── 原型模型│ ├── 增量模型│ ├── 螺旋模型│ └── 敏捷开发│├── ③ 软件开发方法/敏捷方法│ ├── XP│ ├── Scrum│ ├── Crystal│ └── FDD等│└── ④ 软件设计方法├── 结构化设计├── 面向对象设计├── UML├── 设计原则└── 设计模式软件工程软件生命周期软件定义时期├─问题定义├─可行性研究└─需求分析软件开发时期├─概要设计├─详细设计├─编码└─测试软件运行维护时期└─运行、维护、升级、退役CMM成熟度等级软件重用和再工程