Binly42 2018-06-29T19:22:20+00:00 laoyb42@gmail.com 第九次作业 2018-06-29T00:00:00+00:00 Binly42 //Binly42.github.io/System-Analysis-And-Design-Homework.09 第九次作业 (对应 lesson16.html)

说明

这个博客模板的 Markdown 渲染好像有点问题 … 好像还不如 Github 的渲染结果 …

使用 ECB 实现 make reservation 用例的详细设计（包含用例简介，顺序图，类图）

参考 第四次作业 和 第五次作业, 以及其他同学的优秀作业

用例简介

可作出 make reservation 用例的用例图如下:

用例图

从尽量简单的角度出发, 进行设计作图时会作简化, 不考虑一些具体行为 …

顺序图

顺序图

类图

类图

将逻辑设计类图映射到实际项目框架的包图。用树形结构表述实现的包和类

最单纯的按模块进行划分的那种结构:

包图

这里的文章除了特别说明为 [转载] 之外，均为本人原创，转载请说明出处。

]]> 第八次作业 2018-06-08T00:00:00+00:00 Binly42 //Binly42.github.io/System-Analysis-And-Design-Homework.08 第八次作业 (对应 lesson13.html)

说明

这个博客模板的 Markdown 渲染好像有点问题 … 好像还不如 Github 的渲染结果 …

描述软件架构与框架之间的区别与联系

按照 lesson13.html 课件上的说法:

  • 软件架构就是把系统分解为一些部件，描述这些部件的职责及它们之间的协作行为。
  • 框架是特定语言和技术的架构应用解决方案。

而且,

  • 框架是具体语言和技术相关的
  • 框架是一种或多种架构的组合的实现
  • 框架是集成了你的代码和多种第三方解决方案的工具，让你聚焦 业务逻辑代码 而 不是技术实现

大致来说,

  • 架构(模式) 是 做法, 策略, 思想, 组织方式 一样的东西 ;
  • 而 框架 则是其 具体表现, 也可以作为 工具或元素 辅助 架构搭建的工作 ;

以你的项目为案例

绘制三层架构模型图，细致到分区

注: 我不确定 三层架构模型图 的具体要求, 所以参考 我们小组的逻辑视图 又画了一个 …

三层架构模型图

结合你程序的结构，从程序员角度说明三层架构给开发者带来的便利

  • 关注点分离, 开发的时候可以减少各部分之间的互相影响和耦合, 明确焦点和分工, 利于并行开发, 也更便于设计, 复用, 迭代, 管理, 等等 ;

研究 VUE 与 Flux 状态管理的异同

就 状态管理 而言, Flux 和 Vue 的关系类同于 架构 和 框架 的关系 ;

注: (这里讨论的只是原始而普通的 Flux架构)

  • 若是针对 Vuex, 那么大致上 Vuex 其实是一个针对 Vue 特化的 Flux, 因而两者之间基本没有什么本质上的不同 ;
  • 若是针对 Vue 作为一个 MVVM 的框架, 那么大致上 两者的异同便又可以归结为 Flux 和 (传统)MVC 的异同, 也即 单向数据流 和 中心化的 dispatcher 等特性所引发的异同, 这个在课件上给出的链接里也有提到 ;

这里的文章除了特别说明为 [转载] 之外，均为本人原创，转载请说明出处。

]]> 第七次作业 2018-05-13T00:00:00+00:00 Binly42 //Binly42.github.io/System-Analysis-And-Design-Homework.07 第七次作业 (对应 lesson9.html)
说明

我选择的是: Owl Movies Ticket System 项目组的题目

是关于 一个种树应用 Forest 的 ;

用例图

use-case-diagram

XX业务或用例的活动图

种树业务: activity-diagram_种树业务

XX领域模型

种树业务: domain-model_种树业务

XX对象的状态图

种树业务 对象: state-diagram_种树业务对象

XX场景的系统顺序图与操作协议

种树业务 简单成功 (没有 解锁/取消/放弃 等情况发生) 场景: SSD_种树业务成功场景(简单

这里的文章除了特别说明为 [转载] 之外，均为本人原创，转载请说明出处。

]]> 第六次作业 2018-05-06T00:00:00+00:00 Binly42 //Binly42.github.io/System-Analysis-And-Design-Homework.06 第六次作业 (对应 lesson8.html)

1）使用 UML State Model

  • 建模对象： 参考 Asg_RH 文档， 对 Reservation/Order 对象建模。
  • 建模要求： 参考练习不能提供足够信息帮助你对订单对象建模，请参考现在 定旅馆 的旅游网站，尽可能分析围绕订单发生的各种情况，直到订单通过销售事件（柜台销售）结束订单。

Asg_RH文档-Reservation对象状态建模

2）研究淘宝退货流程活动图，对退货业务对象状态建模

淘宝退货业务对象状态建模

这里的文章除了特别说明为 [转载] 之外，均为本人原创，转载请说明出处。

]]> 第五次作业 2018-04-29T00:00:00+00:00 Binly42 //Binly42.github.io/System-Analysis-And-Design-Homework.05 第五次作业 (对应 lesson7.html)

a. 阅读 Asg_RH 文档，按用例构建领域模型。

  • 按 Task2 要求，请使用工具 UMLet，截图格式务必是 png 并控制尺寸
  • 说明：请不要受 PCMEF 层次结构影响。你需要识别实体（E）和 中介实体（M，也称状态实体）
    • 在单页面应用（如 vue）中，E 一般与数据库构建有关， M 一般与 store 模式 有关
    • 在 java web 应用中，E 一般与数据库构建有关， M 一般与 session 有关

HW05-a-class-model

b. 数据库建模(E-R 模型)

  • 按 Task 3 要求，给出系统的 E-R 模型（数据逻辑模型）
  • 建模工具 PowerDesigner（简称PD） 或开源工具 OpenSystemArchitect
  • 不负责的链接 http://www.cnblogs.com/mcgrady/archive/2013/05/25/3098588.html
  • 导出 Mysql 物理数据库的脚本
  • 简单叙说 数据库逻辑模型 与 领域模型 的异同

HW05-b-ER-model

导出的脚本如下:

-- +---------------------------------------------------------
-- | MODEL       :
-- | AUTHOR      :
-- | GENERATED BY: Open System Architect
-- +---------------------------------------------------------
-- | WARNING     : Review before execution
-- +---------------------------------------------------------

-- +---------------------------------------------------------
-- | CREATE
-- +---------------------------------------------------------
CREATE TABLE `Customer`
(
  id INTEGER NOT NULL,
  name VARCHAR,
  email VARCHAR,
  PRIMARY KEY (id)
);

CREATE TABLE `CreditCard`
(
  id VARCHAR NOT NULL,
  PRIMARY KEY (id)
);

CREATE TABLE `Payment`
(
  id INTEGER NOT NULL,
  cost NUMERIC,
  PRIMARY KEY (id)
);

CREATE TABLE `Reservation`
(
  id INTEGER NOT NULL,
  checkin_date TIME,
  checkout_date TIME,
  PRIMARY KEY (id)
);

CREATE TABLE `Room`
(
  id INTEGER NOT NULL,
  type VARCHAR,
  price NUMERIC,
  date TIME,
  PRIMARY KEY (id)
);

CREATE TABLE `Hotel`
(
  id INTEGER NOT NULL,
  name VARCHAR,
  PRIMARY KEY (id)
);

CREATE TABLE `Location`
(
  id INTEGER NOT NULL,
   ,
  PRIMARY KEY (id)
);

数据库逻辑模型 与 领域模型 的异同:

  • 异: 前者一般更具体更细致, 因为与实际的数据库设计有关 ; 而后者则更抽象更联系业务实际 ;
  • 同: 都能表现系统中的各个实体及其间的组织关系 ;

这里的文章除了特别说明为 [转载] 之外，均为本人原创，转载请说明出处。

]]> 第四次作业 2018-04-22T00:00:00+00:00 Binly42 //Binly42.github.io/System-Analysis-And-Design-Homework.04 第四次作业 (对应 lesson6.html)

1、用例建模

  • a. 阅读 Asg_RH 文档，绘制用例图。 按 Task1 要求，请使用工具 UMLet，截图格式务必是 png 并控制尺寸 HW04-1-a-use-case-model-diagram_v0.2
  • b. 选择你熟悉的定旅馆在线服务系统（或移动 APP），如绘制用例图。并满足以下要求： HW04-1-b-use-case-model-diagram-with-color-mark
  • c. 对比两个时代、不同地区产品的用例图，总结在项目早期，发现创新的思路与方法
    • 要根据实际情况/时代趋势等有针对性地提供服务, 比如, 不同的时代/地区等可能会有不同的支付方式及习惯 ;
    • 有所取舍与平衡, 可以根据具体情况考虑提供唯一的一个还是多个操作入口, 不同的年代下不同的用户的体验都可能不一样 ;
    • 要能敏锐地发掘细节上/深层次/多元化的用户心理和用户需求 ;
    • 多多参考/研究/反思已有的项目 ;
    • 等等等等 ;

  • d. 请使用 SCRUM 方法，在（任务b）用例图基础上，编制某定旅馆开发的需求 （backlog）

    story Est Imp
    作为用户, 可以根据 各种因素(包括但不仅限于 时间/地点/价格/…, 下同) 搜索酒店 3 30
    作为用户, 可以根据 各种因素 对 (搜索到的/所有的/某个列表中的) 酒店进行 排序/筛选 3 30
    作为用户, 可以选择 一间酒店 以继续后续预订操作 5 40
    作为用户, (在选定了某间酒店后) 可以对 房间 就各个方面(包括但不仅限于 类型/价格/楼层/…, 下同) 进行 选择 4 30
    作为用户, 可以 确定/提交 预订订单 3 40
    作为用户, 可以 取消 订单 3 20
    作为用户, 可以选择支付方式 8 20
    作为用户, 可以进行支付 8 40
    作为未登录用户, 可以登录 3 20
    …. …. ….

2、业务建模

  • a. 在（任务b）基础上，用活动图建模找酒店用例。简述利用流程图发现子用例的方法。
    • 活动图: HW04-2-a-activity-diagram
    • 观察流程图并思考, 整个流程的每个节点往往都可以继续细化, 联系前后的依赖关系, 即可提取各子用例 ;
  • b. 选择你身边的银行 ATM，用活动图描绘取款业务流程 活动图: HW04-2-b-activity-diagram
  • c. 查找淘宝退货业务官方文档，使用多泳道图，表达客户、淘宝网、淘宝商家服务系统、商家等用户和系统协同完成退货业务的过程。分析客户要完成退货业务，在淘宝网上需要实现哪些系统用例
    • HW04-2-c-swimlane-diagram
    • 淘宝网上需要实现的系统用例可能有: 接受并处理退货申请, 针对退货申请的仲裁, 对客户方的协调 等用例 ;

3、用例文本编写

  • 在大作业基础上，分析三种用例文本的优点和缺点
    • Brief:
      • 优点: 编写方便, 简洁, 便于快速了解 ;
      • 缺点: 缺少细节, 只能粗略地反映用例 ;
    • Fully:
      • 优点: 详细深入, 清晰明确 ;
      • 缺点: 编写过程工作量大 ;
    • Casual:
      • 基本介乎前述两者之间 ;

这里的文章除了特别说明为 [转载] 之外，均为本人原创，转载请说明出处。

]]> 第二次作业 2018-03-22T00:00:00+00:00 Binly42 //Binly42.github.io/System-Analysis-And-Design-Homework.02 第二次作业 (对应 lesson2.html)

1、简答题

  1. 简述瀑布模型、增量模型、螺旋模型（含原型方法）的优缺点。
    • 瀑布模型:
      • 按老师给的课件上说的: 瀑布模型的优缺点-from-LarmanOOAD_part1_C02.pdf
      • 按维基百科说的, 补充如下:
        • 优点:
          1. 能更早地发现问题/解决问题/作出规划等, 成本自然也更低;
          2. 往往导致项目的时间分配高度结构化并利于管理调控;
          3. 重视文档, 避免因开发人事变动等因素导致的效率降低等; (当然这点上往往有利有弊)
          4. 简单, 直观, 可套路化 …
          5. 同样地, 需求明确稳定等的情景下自然很适合;
        • 缺点:
          1. 见上, 见下 …
      • 另可参见百度百科: 瀑布模型优缺点
    • 增量模型:
      • 按老师给的课件上说的, 增量模型至少在一定程度上解决了 项目控制, 团队组织 等问题;
      • 按维基百科说的: 增量模型的优缺点-from-wiki-en
      • 另可参见百度百科: 增量模型优缺点
    • 螺旋模型（含原型方法）:
  2. 简述 UP 的三大特点，其中哪些内容体现了用户驱动的开发，哪些内容体现风险驱动的开发？
    • 按老师给的课件上的解释, UP 的三大特点为: (注: 与 wiki 上的说法有一定出入)
      1. Use Case Driven
      2. Architecture Centric
      3. Iterative and Evolutionary
    • 其中 1. 体现了用户驱动的开发, 2. 和 3. 则体现风险驱动的开发;
  3. UP 四个阶段的划分准则是什么？关键的里程碑是什么？
    • 按老师给的课件上说的: UP 四个阶段的划分准则-from-LarmanOOAD_part1_C02.pdf 因为我并不确定 划分准则 具体何意 …
    • 依据 Unified Process Explained:
      • UP 四个阶段的划分准则 即是: 其各自的关键里程碑, 也即, 以此为分界点;
      • 其各自的关键里程碑分别为:
        1. Life-Cycle Objective Milestone
        2. Life-Cycle Architecture
        3. Initial Operational Capability
        4. Product Release
  4. IT 项目管理中，“工期、质量、范围/内容” 三个元素中，在合同固定条件下，为什么说“范围/内容”是项目团队是易于控制的
    • 合同固定 的条件下, 显然 工期 和 质量 都是约定好的了;
    • 即便 质量 相对的难以被客观地评定, 但显然更取决于 客户 而非 项目团队 (各种意义上) …
    • 而 范围/内容 相对的显然就很容易被项目团队控制了, 不论技术体系, 构建过程, 种种取舍 … 反正是由项目团队主导的;
  5. 为什么说，UP 为企业按固定节奏生产、固定周期发布软件产品提供了依据？
    • 用了迭代, 增量式的开发方式 (Iterative and Evolutionary, incremental), 且迭代周期短而固定, 管制及时, 且控制力强, 代价可控 … ;
    • 各阶段明确, 且有里程碑作决策指导, 过程体系化标准化;

2、项目管理使用

  1. 使用截图工具（png格式输出），展现你团队的任务 Kanban
    • 如图: 团队的任务 Kanban
    • 地址: 中大春哥树洞
    • 我被分派到的分工是 网页前端开发 的组员, 第一周的任务是: 第一周任务 似乎由于 tower 的限制, 一个任务只能分配一个人, 所以只分配了组长 …

这里的文章除了特别说明为 [转载] 之外，均为本人原创，转载请说明出处。

]]> 第一次作业 2018-03-15T00:00:00+00:00 Binly42 //Binly42.github.io/System-Analysis-And-Design-Homework.01 第一次作业 (对应 lesson1.html)

1、简单题

  1. 软件工程的定义
    • 按老师给的课件上的定义: 软件工程的定义-from-00-SoftwareEngineeringReview-pdf 这也是 IEEE 的定义
    • 按维基百科的定义: 软件工程的定义-from-wiki-en 软件工程的定义-from-wiki-zh
  2. 阅读经典名著“人月神话”等资料，解释 software crisis、COCOMO 模型。
    • software crisis
      • 按老师给的课件上的解释: 解释SoftwareCrisis-from-00-SoftwareEngineeringReview-pdf
      • 按维基百科的解释: 解释SoftwareCrisis-from-wiki-zh
    • COCOMO
      • 按维基百科的解释: 解释COCOMO-from-wiki-en
      • 具体参见其维基词条:
      • 人月神话一书中, 作业也曾提及这套模型的一个成果: 解释COCOMO-from-人月神话-zh-Page.168 值得注意的是, 图中提及的 IBM 360系统, 恰也被认为是 software crisis 的一个典型案例 …
  3. 软件生命周期。
  4. 按照 SWEBok 的 KA 划分，本课程关注哪些 KA 或 知识领域？ 以 SWEBOK Version 3 为准, 我认为本课程主要关注:
    • Software requirements (我对此的理解是 软件需求相关的分析/设计/表达/管理等)
    • Software engineering process (也即, 与 SDLC 相关)
    • Software engineering models and methods
    • Software quality
  5. 解释 CMMI 的五个级别。例如：Level 1 - Initial：无序，自发生产模式。
  6. 用自己语言简述 SWEBok 或 CMMI （约200字）
    • SWEBok SWEBok, 全称 Software Engineering Body of Knowledge, 是一个 ISO 钦定的国际通用标准, 类似于一个权威指南, 其明确了整个软件工程领域中被广泛接受的各个主要知识领域(knowledge area); 比如, SWEBok version 3 就明确了如下的 15个方面:
      • Software requirements
      • Software design
      • Software construction
      • Software testing
      • Software maintenance
      • Software configuration management
      • Software engineering management
      • Software engineering process
      • Software engineering models and methods
      • Software quality
      • Software engineering professional practice
      • Software engineering economics
      • Computing foundations
      • Mathematical foundations
      • Engineering foundations
    • CMMI CMMI, 全称 Capability Maturity Model Integration, 中文译名可取 能力成熟度模型集, 是一个针对 process level 的改进, 训练及评估的项目, 由 CMU 主持开发并注册; CMU 声称 CMMI 可用于指导项目, 部门, 甚至一整个组织 的 过程改进工作 (并不只局限于软件工程领域); CMMI 共定义了以下的 5个级别:
      • Initial
      • Managed
      • Defined
      • Quantitatively Managed
      • and Optimizing

2、解释 PSP 各项指标及技能要求：

  1. 阅读《现代软件工程》的 PSP: Personal Software Process 章节。

  2. 按表格 PSP 2.1， 了解一个软件工程师在接到一个任务之后要做什么，需要哪些技能，解释你打算如何统计每项数据？ 如下图: 一个软件工程师在接到一个任务之后要做什么

    关于统计数据的打算:

    我认为应该针对具体情况对待这个统计工作, 比如, 开发方式有很多不同的可能, 因而对于一些开发方式或许有更贴切更合适也更有针对性的统计方式; 泛泛而谈的话, 简单的统计工作时间, 统计代码量, 统计具体完成情况, 等等应该都是可以考虑的方法; 也许, 适当地进行权重分配, 考虑相关的影响因子(比如, 任务重要性, 对其他工作单位的影响, 对整体的影响, 对工作成果的评价, 一些硬性指标及其变化, 等等) 等也可以考虑, 但对很多规模较小的项目我还是觉得一些东西不需要太细究 …

这里的文章除了特别说明为 [转载] 之外，均为本人原创，转载请说明出处。

]]>