https://eSparkL.top/categories/%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B/Recent content in 软件工程 on esparkl.topHugo -- gohugo.iozh-CNWed, 21 May 2025 14:39:35 +0800https://eSparkL.top/study/12-%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B5.21/Wed, 21 May 2025 14:39:35 +0800https://eSparkL.top/study/12-%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B5.21/ <h2 id="进程视图">进程视图</h2> <ul> <li> <p>面向系统架构师和开发人员</p> </li> <li> <p>适用于多进程多视图，关注系统的并发性、分布性、性能和资源分配</p> </li> <li> <p>形式</p> <ul> <li>UML类图</li> </ul> </li> <li> <p>进程间的交互</p> <ul> <li>进程间的交互可以用时序图表示</li> </ul> </li> <li> <p>单线程的Web服务器</p>https://eSparkL.top/study/4-%E8%BD%AF%E5%B7%A5%E8%AF%BE%E5%A0%82%E6%80%9D%E8%B7%AF%E7%AC%94%E8%AE%B0/Sun, 11 May 2025 19:24:08 +0800https://eSparkL.top/study/4-%E8%BD%AF%E5%B7%A5%E8%AF%BE%E5%A0%82%E6%80%9D%E8%B7%AF%E7%AC%94%E8%AE%B0/ <p>tags: [TOC]</p> <h2 id="需求工程">需求工程</h2> <h3 id="用例规约">用例规约</h3> <h4 id="1-画出use-case">1. 画出Use Case</h4> <h4 id="2-编写用例规约">2. 编写用例规约</h4> <h5 id="1-可选需求">1. 可选需求</h5> <h5 id="2-非功能需求">2. 非功能需求</h5> <h5 id="3-黑盒用例规约-和-白盒用例规约">3. 黑盒用例规约 和 白盒用例规约</h5> <ul> <li>随着开发的过程要不断添加细节 <ul> <li>1.识别用例：有哪些时间、actor</li> <li>2.用例分布提纲：+前置条件 +后置条件</li> <li>3.（非技术甲方）黑盒规约：+完整的事件流</li> <li>4.（技术人员）白盒规约：+系统内部行为的细节描述</li> </ul> </li> <li>可以采用双列（用户视图 | 系统视图）</li> </ul> <h4 id="3-用例图优化">3. 用例图优化</h4> <ul> <li>符号： <ul> <li>Include包含 <figure> <picture> <img loading="lazy" decoding="async" alt="alt text" class="image_figure image_internal image_processed" width="206" height="85" src="https://eSparkL.top/study/4-%E8%BD%AF%E5%B7%A5%E8%AF%BE%E5%A0%82%E6%80%9D%E8%B7%AF%E7%AC%94%E8%AE%B0/image-2.png" /> </picture> </figure> <ul> <li>从基本用例→包含用例，包含用例为基本用例提供功能</li> <li>&lt;&gt;衍型</li> </ul> </li> <li>Extend扩展 <figure> <picture> <img loading="lazy" decoding="async" alt="alt text" class="image_figure image_internal image_processed" width="212" height="106" src="https://eSparkL.top/study/4-%E8%BD%AF%E5%B7%A5%E8%AF%BE%E5%A0%82%E6%80%9D%E8%B7%AF%E7%AC%94%E8%AE%B0/image-1.png" /> </picture> </figure> </li> <li>Generalization泛化（类似类中的继承关系） <figure> <picture> <img loading="lazy" decoding="async" alt="alt text" class="image_figure image_internal image_processed" width="237" height="101" src="https://eSparkL.top/study/4-%E8%BD%AF%E5%B7%A5%E8%AF%BE%E5%A0%82%E6%80%9D%E8%B7%AF%E7%AC%94%E8%AE%B0/image.png" /> </picture> </figure> </li> </ul> </li> <li>Include关系 <ul> <li>基数</li> <li>Include中，不需要处理条件，</li> <li>分离非主要行为，突出用例的核心价值</li> <li>提出多个用例存在一段共有的行为，可以提取出来反复使用</li> </ul> </li> <li>Extend关系（见图） <ul> <li>Extension扩展用例——Base基本用例</li> <li>基数</li> <li>扩展关系符号是</li> </ul> </li> <li>Generalization泛化，</li> </ul> <h4 id="建立概念模型conceptual-class">建立概念模型Conceptual Class</h4> <h5 id="识别conceptual-class">识别Conceptual Class</h5> <ul> <li>分类法 <ul> <li>物理实体</li> <li>逻辑实体</li> <li>组织实体</li> </ul> </li> <li>名词提取法 <ul> <li>1.从规约中提取所有名词，可重复</li> <li>2.去掉：冗余、执行者和系统本身、边界类（菜单、链接）、类的属性</li> <li>3.得到基本概念类</li> <li>易错：类的实体当做属性被删掉（e.g.型号） <ul> <li>属性特征：数字，文本</li> <li>因此如果一个东西不能简单用数字或文本描述，应该为类而非属性</li> </ul> </li> </ul> </li> </ul> <h5 id="建立conceptual-class之间的关系">建立Conceptual Class之间的关系</h5> <ul> <li>类图：类 + 类之间的关系</li> <li>类是结构，结构是<strong>静态</strong>的</li> <li>UML <figure> <picture> <img loading="lazy" decoding="async" alt="alt text" class="image_figure image_internal image_processed" width="2011" height="935" src="https://eSparkL.top/study/4-%E8%BD%AF%E5%B7%A5%E8%AF%BE%E5%A0%82%E6%80%9D%E8%B7%AF%E7%AC%94%E8%AE%B0/image-5.png" /> </picture> </figure> <ul> <li>类名 | 属性 | 操作</li> <li>可见性Visibility <ul> <li>+公共可见性</li> <li>#受保护</li> <li>-私有</li> <li>~包可见</li> </ul> </li> <li>多重性Multiplicity <ul> <li>描述关联 <ul> <li>*无限多个</li> <li>1， 2， 0， 正好1，2，0个</li> <li>{1 or 2...4}离散值</li> </ul> </li> <li>vs <ul> <li>基数：整个关系</li> <li>多重性：某一端，“从这边看过去，能连几个那边”</li> </ul> </li> </ul> </li> <li>关联关系Relationship：Association <ul> <li>“一个类知道另一个类” <ul> <li>无箭头实线：彼此都知道 <ul> <li>↑耦合性</li> <li>但更灵活</li> </ul> </li> <li>单向实线：A知道B，A→B，订单→支付方式 <ul> <li>符合封装原则，↓耦合</li> <li>但导航性可能会比较麻烦，比如反向查询不方便 <ul> <li>导航性：一个类能否通过关联访问另一个类 <ul> <li>决定哪个类负责持有或访问数据</li> </ul> </li> </ul> </li> </ul> </li> </ul> </li> <li>需求分析阶段</li> <li>设计阶段</li> </ul> </li> <li>聚合关系Relationship：Aggregation <ul> <li>整体-部分</li> <li>空菱形实线箭头，菱形在整体</li> </ul> </li> <li>组合关系Relationship：Composition <ul> <li>生命周期，部分和组合一起消亡，强关联</li> <li>实菱形实线箭头</li> </ul> </li> <li>泛化关系Relationship：Generalization <ul> <li>空心实线箭头，空心箭头在父类</li> <li>尽量避免用多重继承 <ul> <li>重复继承问题，<code>“钻石问题”</code></li> </ul> </li> <li>优化： <ul> <li>Liskov替换准则LSP</li> <li>继承是is a kind of关系，即子类应该能替换基类型 <figure> <picture> <img loading="lazy" decoding="async" alt="alt text" class="image_figure image_internal image_processed" width="121" height="81" src="https://eSparkL.top/study/4-%E8%BD%AF%E5%B7%A5%E8%AF%BE%E5%A0%82%E6%80%9D%E8%B7%AF%E7%AC%94%E8%AE%B0/image-3.png" /> </picture> </figure> </li> <li>区分：泛化 vs 聚合 <ul> <li>带滚动条的窗口 <ul> <li>带滚动条的窗口 是 窗口；带滚动条的窗口 包含了 滚动条</li> </ul> </li> </ul> </li> </ul> </li> </ul> </li> <li>依赖关系Relationship：Dependency <ul> <li>虚线带箭头，依赖类型&lt;&lt;自定义&gt;&gt;</li> </ul> </li> <li>接口 <ul> <li>一组操作的集合（不包含属性）</li> <li>表示方法 <figure> <picture> <img loading="lazy" decoding="async" alt="alt text" class="image_figure image_internal image_processed" width="629" height="375" src="https://eSparkL.top/study/4-%E8%BD%AF%E5%B7%A5%E8%AF%BE%E5%A0%82%E6%80%9D%E8%B7%AF%E7%AC%94%E8%AE%B0/image-6.png" /> </picture> </figure> <ul> <li>&lt;&gt;</li> <li>圆圈表示</li> </ul> </li> <li>分类 <ul> <li>供给接口 <ul> <li>提供的服务</li> <li>圆圈</li> </ul> </li> <li>需求接口 <ul> <li>需要得到的服务</li> <li>半圆</li> </ul> </li> </ul> </li> </ul> </li> <li>增加属性，类的属性（先）比操作（后）更重要</li> <li>状态机图 <ul> <li>类的行为性特征</li> <li>分类 <ul> <li>行为状态机 <ul> <li>内部</li> </ul> </li> <li>协议状态机 <ul> <li>外部</li> </ul> </li> </ul> </li> <li>核心元素 <ul> <li>初始状态：实心圆⚫</li> <li>终止状态：圆圈包围⚫</li> <li>其他状态：圆角矩形，内部显示状态名</li> <li>状态转移： <ul> <li>箭头</li> </ul> </li> <li>事件：状态机中事件触发迁移 <ul> <li>转移上的标号表示</li> </ul> </li> <li>entry-do-exit-event？</li> </ul> </li> <li>为什么要用状态机图 <ul> <li>1.对象的职责或行为变化显著</li> <li>2.系统或对象的用例涉及复杂的逻辑，且这些逻辑由状态驱动时</li> <li>×： <ul> <li>对象的逻辑简单明了，不需要额外的状态机抽象</li> <li>对象的行为不依赖状态变化</li> <li>对象单一状态</li> <li>总结：不存在复杂的状态变化</li> </ul> </li> </ul> </li> </ul> </li> </ul> </li> </ul> <h4 id="用例实现ucr">用例实现UCR</h4> <h4></h4> <ul> <li>需求和设计之间的桥梁</li> <li>用例中的每一个用力，在分析模型和设计模型中至少有一个用例实现与对应</li> <li>分类 <ul> <li>动态交互图</li> <li>类图，静态视图</li> </ul> </li> </ul> <h5 id="识别分析类">识别分析类</h5> <ul> <li>分析类：描述每个角色的职责</li> <li>设计阶段：角色赋与台词和动作，变成实际的系统组件</li> <li>分析类： <ul> <li>平台无关模型，与实现无关（可能做不出来）</li> <li>MVC模型-视图-控制器 <ul> <li>实体类 <ul> <li>描述存储的信息，及信息相关的行为</li> <li>反映逻辑数据结构</li> <li>实体类不是某个用力实现所特有的</li> <li>识别：名词过滤</li> </ul> </li> <li>边界类 <ul> <li>分类 <ul> <li>用户界面类</li> <li>系统接口类</li> <li>设备接口类</li> </ul> </li> <li>识别规则actor和用例之间的一条通信关联对应一个边界类，actor是什么类型对应对应的边界类</li> </ul> </li> <li>控制类 <ul> <li>每一个用例一定会有一个控制类</li> <li>关注流程逻辑，是事件流的抽象</li> </ul> </li> </ul> </li> </ul> </li> </ul> <h4 id="构建分析模型">构建分析模型</h4> <ul> <li>交互图 <ul> <li> <p>顺序图/时序图</p>