【软件工程】软件工程课程复习笔记

第一讲 介绍

工程这个词,对应的是科学
工程是可以重复的,而科学通常不强求重复
软件工程:其中遇到的模型,怎么做,方法

一、基本信息

1.模块化的设计 UML diagrams图
2.涵盖软件整个生命周期,和软件开发的整个阶段应该怎么去做。
3.以团队为主的(team-based),需要实际动手操作,需要一系列编程。
4.不会教任何一门特殊的编程语言
5.团队开发一个相对逻辑复杂(编程、业务)的系统,需要多方面(性能和资源的小号如并发量、存储量)的权衡。

二、参考书目

在这里插入图片描述

三、介绍

Software is complex=事情由很多部分组成,能够互相关联在一起。
(而complicated 模糊的,即便分析也分析不出来,不能解释。)
防止产生温水煮青蛙的问题:
1.小问题尽量考虑清楚,从而不至于导致大的缺陷
2.负面反馈是一种积累,刚开始看上去问题不大,到后面就会太严重以至于不能解决
3.Design smells,technical debt,software rot

四、软件工程的角色

在这里插入图片描述

第一法则:必须能够学习问题的领域(先要知道客户需求)

Customer:需要一个计算机系统去实现一些业务目标,通过用户交互(与环境,或与一个特殊方式)
软工的任务:理解system-to-be如何与环境或user交互,从而能够达成用户需求,并且设计software-to-be

解决问题的策略:分而治之:

1.识别系统上的逻辑组成部分(逻辑划分),其能解决问题的一块
2.掌握问题最快的方式:需要领域专家(谁懂怎么去用,目前是怎么做的)
3.产生:领域问题的模型(或问题域模型)

五、软件工程的蓝图

1.准确的理解软件的问题和解决方案
(1)不幸的是,很多人不是艺术家画不出来,所以我们用一些工具,UML symbols

六、第二法则

第二法则:以人为本
Nurture培养滋养
在这里插入图片描述

七、软件开发方法:工作策略

1.瀑布模型
在这里插入图片描述

单向的 不能回滚。开发好开,修复不好修复
2.迭代和增量模型
3.持续的用户反馈,反馈在不同级别上与项目本身有关

八、UML

在这里插入图片描述

九、有多少种绘制图形的方式?

在这里插入图片描述

1.在早期阶段和开发团队内部使用非正式的、临时的、手绘的、粗糙的图表。手绘会导致节约和低情绪投资,始终拍摄快照以保存记录以备将来回顾
2.使用标准化的、整洁的,计算机生成的图表,保证一致性,设计有“稳定性”。标准化的绘图方式如UML,在广泛的利益相关者(stakeholder)之间促进沟通。先画草图,仅仅在设计达到一致的时候,才需要用标准化的图表。

十、理解问题领域

在这里插入图片描述

Actors–能与系统交互的系统外部的角色

概念/对象–能起到一定作用的在系统内部使用的角色

用例–若干个使用系统的场景

十一、项目管理:

如何评估:
1 成本和周期(时间规划)的问题:
2 产出 质量评估

评估策略:
1 猜测工作的每一个小部分是什么(基本单元划分)
2 做一点工作,判断出来自己的工作效率
3 尽量让估计变得准确
4 不断迭代,直到需要不再需要纠正之

项目没有实施的时候不存在。初始化的估计依靠于经验和想象。

Backlog 有具象估计,工作量和优先级
评估需要领域知识,而不是开发者

概念图:概念➕关系图
Tenant租客
然后用use case图做场景设计

十二、状态和转换图:

#

第二讲 对象模型

一、对象和方法调用

在这里插入图片描述

二、接口

接口----指纹、签名
多态:子类对父类的同名方法做不同的实现机制
在这里插入图片描述

模块:子程序和数据的松散分组

三、UML表示法

在这里插入图片描述

四、对象关系

组成:使用实例引用其他对象的变量
继承:继承普通通过类扩展的属性
在这里插入图片描述

继承和组合都扩展了另一个对象提供的基本功能
继承:“基类”中的更改会传导到子类及客户机类。
但是任何代码更改都有无意引入bug的风险。
组合:更能适应变化,因为“基类”中的变化很容易被“包含”并对前端类的客户机隐藏。

五、面向对象/算法与面向对象方法

面向过程:更直观,以人为中心
思考下一步该做什么,该走哪条路
But:大规模的问题需要人的组织,而不是单独个 人工作
面向对象:由于分工,面向对象会更混乱
思考如何把问题分解成任务,分配责任,协调 工作。这是一个管理问题。
But:很难设计好的组织

六、如何设计好的面向对象的系统?

决定性方法因素:
1.可追溯性:可以一步步跟踪系统的发展,从单个需求到设计对象,再到代码块。
避免莫名其妙的跳跃
2.测试:测量 安全
测试驱动开发:开发过程中每一步必须从如何验证结果是否符合目标的计划开始
开发人员只有在知道如何测试的时候再创建软件工作。
3.测量
在这里插入图片描述

但是测试是不够的

4.安全

第三讲 软件配置管理

一、 概念

(一)SCM的作用
软件配置管理是控制软件系统演化的过程

  1. 简化分享代码和其他文档
  2. 能够回溯到旧版本undo
  3. coherently并发的整合团队成员的贡献merge
  4. 通知新模块的相关部分的改变reporting
  5. 追溯软件问题(如bugs)
  6. 创建一个可以审计的记录(archiving 归档)
    (二)为什么做SCM?
  7. 简化、增量产出
  8. 传统方式不合适so有新的便捷方式
    (三)定义
  9. 软件配置:一系列在一个项目周期内完成的工作的整合
  10. 软件配置条目:被一个人/开发者/客户关心的内容
  11. 镜象snapshot:项目到一个节点的时候做的快照,包含条目,每个条目的版本和时间
  12. commit提交:提交一个项目配置到项目数据库repository
    5.build构建工具:一个版本的项目代码,发布成可以运行的格式。计算机上单独的可执行的代码。

(四)
repository:项目数据库(多人共享的)project database
workspace:自己的电脑/机器中的数据库
在这里插入图片描述

(五)版本图 vs分支
master branch/trunk/mainline
Fork修订分支
merge提交合并到主干
每一次commit代表一个不同的版本
snapshot通常指的是最新的版本的

二、 工作环境

场景:
在这里插入图片描述

  1. 在新工作中撤销错误undo mistakes

  2. 支持多分支(多管齐下)产品演变

  3. 发展产品线

  4. peers为工作单位工作

  5. 以受控管理的团队为工作单位
    cicd开发部署一体化

revert保留当前版本,回溯到正确版本git revert(safe)
reset删除当前版本,回溯到正确版本git reset

第四讲理解问题和划分工作
分而治之的思想:降低耦合性,尽量独立完成工作
康威法则:设计系统的组织通常受限于组织内部的沟通的结构
最终交付的模型与组织结构相关

一、 任务切分的两种模式 partitioning && projection
二、 职责划分
三、 减少团队内的沟通

划分工作的两种方法:
一、由问题划分
在这里插入图片描述

二、由解决方案划分
不同团队成员负责系统的不同部分
在这里插入图片描述

反例:汽车生产中,不同公司负责不同子系统
经过大量试错后,每个子系统都能演化成独立解决子问题的不同的系统了

第四讲 设计模式

在这里插入图片描述

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

在这里插入图片描述

第五讲 面向对象UML

在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/qq_43984062/article/details/136399083
今日推荐