#|# 学习软件体系结构课程时每日的进展报告 #学习软件体系结构课程时每日

2/23
1、软件体系结构重要的理论基础
抽象、封装、数据隐藏、模块化、注意分离点、耦合和内聚、充分性、完备性和简单性、策略和实现的分离、接口和实现的分离、分而制之、层次性
（1）抽象：抽象是人们用来处理复杂问题的基本原理之一。
（2）封装：在面向对象程序设计当中的重要机制，在结构化程序设计中，封装在函数和子程序当中也得到了体现
（3）信息隐藏：信息隐藏是软件工程的最基本和最重要的原理之一，封装原理经常被用来作为实现信息隐藏的方法，信息隐藏也可以通过接口与实现分离的原理来实现。
（4）模块化：模块化主要关心如何将一个软件系统分解成子系统和构件，其主要任务就是决定怎样将构成应用的逻辑结构物理地分割成代码实体。
（5）注意分离点：如果一个构件在不同的环境下扮演不同的角色，在构件中这些角色应该独立且相互分离。
（6）耦合与内聚：
a、耦合是用来衡量一个模块同另一个模块的联系的紧密程度的，低好
b、内聚用来衡量单一模块内功能和元素间联系的紧密程度，高好
c、内聚有几种形式，最期望获得的是功能内聚，它说明一个模块或者构件内的所有元素都共同来完成具有良好边界的行为。最差的形式是偶然内聚，这种形式将毫无联系的抽象放置到同一模块之中。
d、其他形式的内聚还有：偶然内聚、时间内聚、过程内聚、通信内聚、顺序内聚和不规则内聚。
（7）充分性、完备性和简单性
a、充分性指的是构件应该把握住与其进行有意义和高效交互抽象的所有特性。
b、完备性指的是一个构件应该把握住所有与其抽象相关的特性。
c、简单性指的是构件所应该完成的操作都可以容易地得到实现。
d、在对一个指定的问题寻找构件设计方案时，使其具有充分性和完备性是一个主要目标。
（8）分而治之：在设计中将一个复杂任务或构件分割成可以独立设计的更小的部分。该原理经常被用来作为实现注意点分离的方法，但是更重要的还是简化了问题的复杂度。
（9）策略和实现的分离：软件系统的构件应该实现策略或处理问题，但不能同时处理两者。
（10）接口和实现的分离：该原理的主要目的是防止构件的客户接触到实现的细节，而只为客户提供构件的接口规范和使用方法。。就像封装一样，接口和实现的分离也是一种用来获得信息隐藏的技术。
（11）层次性：处理复杂问题有两种方法，即：分而制之的横向分割和分层次处理的纵向分割。后者
2、质量属性（QA）是系统的可测量或可测试属性，用于指示系统如何满足其利益相关者的需求。
（1）衡量QA的属性
a、可用性Availability
是指系统屏蔽或修复故障的能力，以便在指定的时间间隔内，累计服务中断时间不超过要求的值。系统的可用性可以计算为在指定的时间间隔内在所需界限内提供指定服务的概率。当提及硬件时，有一个众所周知的表达式用于推导稳态可用性。
MTBF是指平均故障间隔时间，MTTR是指平均修复时间。
ps：可用性策略
ps1：检测错误
ping/echo是指节点间发生变化的异步请求/响应消息对，用于确定通过相关网络路径的可达性和往返延迟。
心跳检测是一种故障检测机制，它使用系统监视器和被监视的进程之间的定期消息交换。
异常检测是指对改变正常执行流的系统条件的检测。
ps2：错误恢复
准备和修复策略基于各种组合的重新尝试计算或引入冗余。
重新引入是指故障部件在纠正后重新引入。
ps3：阻止错误
b、互操作性Interoperability
系统要求与其他系统交互。
ps：
ps1：
c、Modifiability可修改性是指以更高的性价比快速对系统进行更改的能力。通常基于某些特定的变更，可修改性是通过检查这些变更的成本来衡量的。
3/2
Q1:
我看了这一段文字：PPT第八页“瀑布模型规定了由前至后、相互衔接的固定次序，恰如奔流不息拾级而下的瀑布。在20世纪80年代之前，瀑布模型一直是唯一被广泛采用的生存周期模型，现在它仍然是软件工程中应用得最广泛的过程模型。传统软件工程方法学的软件过程，基本上可以用瀑布模型来描述。而且是以文档为驱动，适合于需求很明确的软件项目开发的模型”。
有这个问题：之后的ppt上已经很详细的解释了瀑布模型的缺点，瀑布模型却还是被最广泛采用的模型，之后的扩展中讲到平行瀑布模型是对瀑布模型的进一步改进，我认为·这种改进是十分合理的，但它为什么没有取代瀑布模型作为被最广泛应用的模型呢？甚至在了解软件体系风格之前，我们学校一直是采用的瀑布模型来进行项目开发？
我查了资料，有这些说法：“最早出现的瀑布模型已经落后于现代的软件开发模式。但是程实践和学术理论不同,在项目开发实践过程中,哪种方法最简单、最易行、最能符合人们的维习惯、最能表达事物的发展顺序,就会采用那种方法。引入“并行开发”的目的是为了减少不必要的.等待时间和各个阶段之间的反馈时间，如果有错误,能在最短时间内反馈给上一级,及做出变更。引入“迭代开发”的目.的是用“逐步求精”的方式对付容易变更的需求和技术。为了避免并行开发和迭代开发过于灵活而导致产品质量下降,应当对上述过程域产生的工作，结果进行严格的技术评审。
根据我的实践，我得到这些经验：在具体的项目开发中，根据已经写好的需求文档开发确实十分方便，而且并行开发很考验小组成员各自的配合程度和理解力，在学校里做不到灵活的并行开发是可以理解的。
但是我还是不太懂，我的困惑是：目前为止很多公司也在用这种模型进行开发，大大拖慢了软件开发的效率，作为有着具体管理人员和固定小组的公司，也应该可以做到人员之间的协作和调配，使用平行瀑布模型轻而易举，为什么不做呢？是因为并行开发出现的问题浪费的时间比一般开发更多吗？如果是，又该怎么解决？
Q2:
我看了这一段文字：PPT19页——“RUP(Rational Unified Process)是一个通用的过程框架，可以用于各种不同模型的软件系统，各种不同的应用领域和不同规模的项目。RUP的特点是由用例驱动，以构架为中心，采用迭代和增量的开发策略。RUP软件生存周期是一个二维的软件开发模型。”
有这个问题：RUP是个过程框架，由用例驱动，以构架为中心，采用迭代和增量的开发策略。那什么叫做用例驱动，构架又是什么？
我查了资料，有这些说法：“RUP的一大特征是用例驱动。简单地说，一个用例就是系统的一个功能。在系统分析和系统设计中，用例被用来将一个复杂的庞大系统分割、定义成一个个小的单元，这个小的单元就是用例。然后以每个小的单元为对象进行开发。按照RUP过程模型的描述，用例贯穿整个软件开发的生命周期。RUP的另一大特征是它强调软件开发是以构架为中心的。构架设计(ArchitecturalDesign)是系统设计的一个重要组成部分。在构架设计过程中，设计师(Architect)必须完成对技术和运行平台的选取，整个项目的基础框架( Framework)的设计，完成对公共组件的设计。”
根据我的实践，得到这些经验：也就是说，RUP是一个功能驱动的，把软件整体构架作为中心的二维软件开发模型。
但是我还是不太懂，我的困惑是：可以看出RUP的迭代模型和瀑布模型十分相似，那么RUP的迭代模型的优点是什么呢?它比瀑布模型更好吗？
分工：编码工作
今日进度：学习了老师提供的今日网课视频和PPT，了解了软件开发模型和生命周期的划分，大概划分小组分工。
明日规划：计划明天连OO Systems的相关资料，着手编码工作，以及个人翻译一到两页，计划用时1—2小时
3/3

当天投入时间和完成的内容
a、查阅面向对象体系结构风格资料，对代码的编写方向有大概把握——40min；
b、翻译四页英文——30min
第二天计划投入时间及工作计划
预计2小时
a、去看一些体系相关代码，学习实践；
b、采用这种风格写个简易Demo出来加深理解；
c、翻译2-3页
3.每日工作小结
a、OO概述：面向对象体系结构风格的组件是类和对象连接件是对象之间通过功能与函数调用实现交互。对象是通过函数和过程的调用-返回机制来交互的，而类是通过定义对象，再采用调用-返回机制进行交互
b、OO风格优点
复用和维护：利用封装和聚合提高生产力
–因为对象对其它对象隐藏它的表示，所以可改变一个对象的表示，不影响其它的对象。
–某一组件的算法与数据结构的修改不会影响其他组件
–组件之间依赖性降低，提高了复用度
反映现实世界
容易分解一个系统
c、OO风格缺点
-管理大量的对象：怎样确立大量对象的结构
-继承引起复杂度，关键系统中慎用
-必须知道对象的身份
-对比：在管道-过滤器系统中，一个过滤器无需知道其他过滤器的任何信息
-不是特别适合功能的扩展。为了增加新功能，要么修改已有的模块，要么就加入新的模块，从而影响性能

3/4

当天投入时间和完成的内容
a、完成所有翻译初稿——1h
b、学习面向对象风格实例——40min
c、写了一个简易测试demo——20min
第二天计划投入时间及工作计划
一、计划两个小时左右；
二、工作计划
a、进行小组会议，细分工作后进行项目开发；
b、按照项目要求先开始做个项目原型出来；
c、核对翻译初稿，检查格式错误以及翻译语序不通等问题；
3.每日工作小结
a、架构风格是一组原则。我们可以把它看成是一组为系统家族提供抽象框架的粗粒度模式。架构风格能改进分块，还能为频繁出现的问题提供解决方案，以此促进设计重用。
b、面向对象风格
该架构风格是将应用或系统任务分割成单独、可重用、可自给的对象，每个对象包含数据，以及与对象相关的行为。此架构风格分别适用于结构领域。
抽象数据类型概念对软件系统有着重要作用，目前软件界已普遍转向使用面向对象系统。这种风格建立在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。这种风格的构件是对象，或者说是抽象数据类型的实例。对象是一种被称作管理者的构件，因为它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。
c、示意图

d、特点
面向对象的系统有许多的优点，并早已为人所知：
(1) 因为对象对其它对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其它的对象。
(2) 设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。
但是，面向对象的系统也存在着某些问题：
(1)为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象。
(2)必须修改所有显式调用它的其它对象，并消除由此带来的一些副作用。例如，如果A使用了对象B，C也使用了对象B，那么，C对B的使用所造成的对A的影响可能是料想不到的。
e、架构风格和架构模式之间的细微差别
架构风格是系统主要的、组织性的设计。
架构模式从子系统或模块、及其之间的关系层次上描述了粗粒度的解决方案。
系统隐喻则更为概念化，比起软件工程概念，它更多地涉及现实世界的概念
f．David Calvert给出的架构风格/模式的部分清单:
数据流系统——批处理，管道-过滤器。
调用-返回系统——主程序和子程序，面向对象系统，分层。
独立组件——通信过程，事件系统。
虚拟机——解释器，基于规则的系统。
以数据为中心的系统（仓库）——数据库，超文本系统，黑板。
g、学习博客链接
https://www.cnblogs.com/wintersun/p/4869344.html
https://blog.csdn.net/shujian_tianya/article/details/80873850?depth_1-utm_source=distribute.pc_relevant.none-task&utm_source=distribute.pc_relevant.none-task——软件体系风格总体介绍
https://blog.csdn.net/llwszjj/article/details/36451877
https://www.cnblogs.com/adidasyang/p/6876468.html——面向对象编程实例
3/4
3. 当天投入时间和完成的内容
d、检查部分翻译稿——20min
e、了解面向对象风格的各种管理系统——40min
f、小组讨论定下详细分工——20min
4. 第二天计划投入时间及工作计划
一、计划1个小时左右；
二、工作计划
a、设计好数据库；
b、复习之前学过的mysql部分；
c、尽量完成查询功能（但每天可能要完成其他科目作业，也许来不及）；
3.每日工作小结
今天看了一下具体实现的项目，理解了OO风格的具体应用；
而且图书管理系统和其他管理系统没有很大的差别，基本就是增删查改，当然考虑到风格的要求，封装类的时候肯定比之前要谨慎一点，特别是各个对象的方法不能互串；
由于课设的原因，今天本来准备开始开发的计划搁置了，可能之后也会断断续续，因为bug一出现就得调一下午，很难把控时间；
以上。
【#|# 学习软件体系结构课程时每日的进展报告】3/5
Q1:
在PPT13页：“引入新的体系结构，通常会检查它的“纯”形式.纯粹的体系风格在实际中很难遇到。作为一个架构师，你必须理解“纯”的风格。理解它的优点与缺陷，也要理解背离此种风格之后会带来什么结果”
有这个问题：那么既然很少见“纯”的风格，现在使用的最常用的软件体系风格又是什么风格之间的混合呢？
我查了资料，有这些说法： B/S 与 C/S 混合软件体系结构是一种典型的异构体系结构。
C/S 与 B/S 混合软件体系结构的优点是外部用户不直接访问数据库服务器，能保证企业数据库的相对安全。企业内部用户的交互性较强，数据查询和修改的响应速度较快。C/S 与 B/S 混合软件体系结构的缺点是企业外部用户修改和维护数据时，速度较慢，较烦琐，数据的动态交互性不强。
但是我还是不太懂，我的困惑是：B/S软件体系是我从来没有使用过的结构，单纯从概念上来说：“B/S 软件体系结构，是随着 Internet 技术的兴起，对 C/S 体系结构的一种变化或者改进的结构。在 B/S 体系结构下，用户界面完全通过WWW 浏览器实现，一部分事务逻辑在前端实现，但是主要事务逻辑在服务器端实现。”既然是改进的结构为什么还要混合，难道改进后又产生了什么缺点吗？
Q2:
课上讲到两层客户机/服务器和三层客户机/服务器之间的区别，在PPT17页和32页的对比图很容易看出来两者的差别，其中，在三层客户机/服务器上，客户机上只需安装具有用户界面和简单的数据处理功能的应用程序，负责处理与用户的交互和与应用服务器的交互。应用服务器负责处理商业和应用逻辑。
有这个问题：那么到底什么是商业和应用逻辑？它具体是做什么的呢？
我查了资料，有这些说法：“业务逻辑（Business Logic ）无疑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计，也即是说它是与系统所应对的领域（Domain）逻辑有关，很多时候，也将业务逻辑层称为领域层。所谓的三层开发就是将系统的整个业务应用划分为表示层，业务逻辑层和数据访问层，这样有利于系统的开发、维护、部署和扩展。”
根据我的实践，我得到这些经验：三层客户机/服务器实际上就是我们常说的三层架构，而三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。区分层次的目的即为了“高内聚，低耦合”的思想。
但是我还是不太懂，我的困惑是：我曾经接触过MVC结构，具体开发的时候似乎和三层架构没有很大的区别，因为时间比较赶的原因我最后还是没有使用MVC，所以很疑惑这两者的区别是什么？既然分为两种结构，并且至今都被广泛使用，那么应该都有着优点与局限性，具体表现在哪些方面呢？
Q3:
PPT32-33页里说，“稳定性和可扩展性之间存在辨证的关系：稳定性和可扩展性都是体系结构设计的要素。如果每次变化都导致体系结构发生大的变动，这样的体系结构无疑是不可接受的。”
有这个问题：既然要在保证稳定性的基础上保证可扩展性，那么在软件开发中具体该怎么做呢？
我查了资料：成功的设计模式里最为重要的就是职责分离原则和开闭原则
职责分离原则，将框架与业务组件分开。框架设计的要点在于支撑业务组件的配置、注入、生命周期管理和状态转移。根据对业务的抽象，将大业务层层分拆成高内聚、低耦合的模块，将不同模块的通用部分加以归并成工具层，并持续将业务模块做细，这也就是我们通常所说的“分-合-细”三原则。
开闭原则，就是对修改关闭，对扩展开放。基于一个又一个高内聚低耦合的业务组件，在后续的业务发展迭代过程中，更期望能够不断地扩展新的组件，扩展新的工具服务层，而不是将之前的一切推倒从来或者从上层改到底层。
根据我的理解：实际上就是说在写代码的时候，要根据功能划分组件，并且越细越好，这样在后续的功能扩展中，我们甚至可以做到不修改大量代码，只要插入功能组件就OK了。这确实是很实用的原则。
我的困惑是：这样的话实际上会和高内聚低耦合有冲突，如果功能组件太多的话，类的数量急剧增多，这样就导致了其它类的耦合特别多，于是整个设计就变成了“高内聚高耦合”了。完全按照这两个原则显然也是不可取的，那么我应该怎么做呢？就只能靠经验的积累，审时度势吗？
当天投入时间和完成的内容：
1h——看视频和ppt；
45min——复习Hibernate框架；
20min——查各种零碎资料；
第二天计划投入时间及工作计划
2h
准备先把数据库设计好连上再说；
去查一下前端框架的用法；
每日工作小结
1、复习了一遍Hibernate，时间超出意料了一些，而且因为搭环境卡了我好久。
2、复习完框架部分之后看时间不太够了，干脆不编码直接看mysql部分，把数据库语句重新归纳了一遍
3、今天还没看翻译，但是待会晚上有时间打算全部过一遍。
3/6
当天投入时间：2.5h
完成的内容
1、花半小时核对了翻译语序问题
2、设计好了数据库并在控制台输出；
3、项目的结构搭建好了，接下来只需要具体实现类。
第二天计划投入时间：2h
工作计划
1、核对翻译格式并上传doc文档；
2、完善数据库设计以及实现查询功能
每日工作小结
数据库设计就是要考虑图书、读者和管理员三个部分，结构很简单，但实际写起来挺花时间的，虽然初步设计了一下，但图书与读者，管理员之间的管理还比较模糊，因为是基础部分所以决定明天要再修改一下；
今天连接数据库的时候又碰到了时区问题，每次都要重置时区很麻烦，我打算找个一劳永逸的办法（目前没找到）；
连接数据库没出什么问题，可能是有点经验了。
我看了一下之前的javaweb项目，实际也是基于面向对象思想开发的，虽然不是纯粹的风格，但还是有可以借鉴的地方。
当天投入时间2h
完成的内容
1、复习jdbc基本知识和查看三层架构实战项目来加深理解
2、数据库重新设计
第二天计划投入时间2h
工作计划
1、用jdbc的方式连接数据库；/
2、熟悉模板，配置并运行一遍。
.每日工作小结
重新复习了一下jdbc之后觉得不用框架连接数据库确实可以学到很多，而且今天突然发现自己之前做项目都是从头开始自己敲的代码，然后小组一致要求要直接套模板，我感到非常不好意思因为之前从没想过可以套模板这种事情。所以决定自己学习一下，把同伴给的代码跑起来，并抛弃Hibernate用jdbc来连接数据库。
3/9
当天投入时间3h
完成的内容
1、课上听取同学们的演示
2、小组讨论各个具体模块的功能
3、学习jdbc，数据库连接
第二天计划投入时间2h
工作计划
1、按照讨论好的功能模块重新搭建具体项目框架（之前的太笼统了而且不是用的jdbc的结构）
2、完成图书查找功能
每日工作小结
在今天课上看小组演示的过程中，对他们的风格有了了解，对图书管理系统的模块划分有了一个参考的模板，很有意义。同时，我也发现本组进度可能略慢，有了紧迫感，所以决定在接下来的日子一边学习一遍完成功能，实战或许是最好的学习方法。
3/10
当天投入时间2h
完成的内容
与代码组其他人讨论完具体编写部分；
完成用户表和书籍表的增删查改功能；
第二天计划投入时间1.5h
工作计划
完成另外两个表的数据访问层功能；
开始考虑业务逻辑层的架构；
每日工作小结
需求分析文档已经出来了，比起之前完全自己想着怎么敲代码，果然还是有了详细分析之后更加有思路一些，团队合作和及时的相互交流果然是很重要的；数据访问层出现的问题意外的比较多，比如今天在进行联合主键的查询时就被卡住了，目前还在查资料中——唉。
这是今天的参考博客https://www.cnblogs.com/warlu/p/7064388.html——Hibernate自动生成实体类+右键+Generate+tostring——tostring的idea自动生成，这种快捷方式很能提高效率。
3/11
当天投入时间3h
完成的内容
1、学习Hibernate框架的hql查找算法；
2、完成Book实体类的增删查找
3、解决各种bug
第二天计划投入时间2h
工作计划
1、完成Borrow表的数据访问层方法
2、学习Hibernate其他查询语句并归纳
每日工作小结
在jdbc的学习之后我又转回了框架，当然，这些学习并不是无用功，它让我对数据库具体的连接过程有了更深的理解，同时对HIbernate的便利也有更深的体会，所以最终我还是转回来了。当然，学习这些知识需要的时间不短，在还有课设要做的情况下这些花费的时间给了我很大的压力，之后应该注意ddl，合理安排时间。
今天复习了hql查找法，因为不用主键查询时我必须使用灵活可变的其他查找；
还有各种小错误，debug的时间挺长的，此处就不细说了。
3/13
当天投入时间2.5h
完成的内容
1、完成Borrow表的数据访问层方法
2、debug
3、把之前程序中遇到的问题整理归纳了一下，为之后写文档做准备
第二天计划投入时间2h
工作计划
1、完成翻译格式部分；
2、根据OO风格思考业务逻辑层的搭建方式
每日工作小结
今天发现遇到的bug之前其实也遇到过，重复查询很费时间，在整理笔记的过程中发现其实有些问题是由于没有一个系统的学习，在项目实战中零零散散的看博客这些弊端挺大的，总是知其然不知其所以然，这就导致了解决了一个问题之后马上又会出现新的问题，所以完成翻译后，我打算对框架部分以及面向对象风格做一个系统的学习。
汇报总结
在听取各个小组报告的过程中，我了解到每种体系风格各有优缺点，所以我们不可以只拘泥于具体的风格，一种纯粹的风格在实际项目里是很少存在的，特别是对于OO风格而言，它主要涉及类之间调用的问题，在开发过程中是难免涉及到整体开发的层次概念的。在今天听取的汇报中，感觉都讲的挺好的，分工已经明确，而且编码阶段基本上都做了一大半，预估完成任务的时间是本周内或下周内，和我们的进度差不多，甚至我们的进度稍显落后，因为本来还想预留出一些修改的时间的，现在看来有点赶。除此之外，大家的PPT做的有理有据，对各自的体系风格都有合适详尽的理解，我们组虽然也查了很多资料，但还是对代码的编写有些疑虑，这是我们组落后的地方，之后很需要详细讨论与总结。
3/14进展报告
当天投入时间2h
完成的内容
1、学习html和js前端；
2、解决一半的翻译格式问题
第二天计划投入时间2h
工作计划
1、解决另一半翻译，明天汇总一下提交doc文档；
2、继续前端学习。
每日工作小结
今天其实主要在做课设方面的事情，真挺麻烦的，但至少比之前有思路了，之前找资料的时候一直担心体系结构这门课程，写完自己代码部分之后总算能静心查课设的问题了，还是因为自己太菜了，心里没底——桑心。
然后学习前端是我担心最后整合的时候帮不上忙，因为之前都没有系统接触过前端部分，万一看不懂就尴尬了，今天了解了一些基础知识，主要能看得懂，目前不强求背下来，之后用的时候自然记得住了；
翻译拖太久了，明天做完免得老惦记。
3/16进展报告
当天投入时间1h
完成的内容
数据库更改和相应方法的变更
解决另一半翻译，
第二天计划投入时间1.5h
工作计划
3、汇总最后看一遍一下提交doc文档；
4、继续前端学习。
每日工作小结
1、今天需求小组突然说要改一下数据库，挺简单的，就是查图书简介啥的有点费时间，然后mysql导出总不刷新，中途不小心还动了一下配置，结果大家都懂的。/2、
2、翻译总算是弄完了，明天最后过一下就上传。
3、前端学习——仍需加油，明天保证继续。今天晚上只能把自己给课设了
以上
3/17进展报告
当天投入时间2h
完成的内容
1、最后检查一遍提交翻译doc文档
2、学习java的一些知识
第二天计划投入时间1.5h
工作计划
1、检查已完成代码，优化
2、继续前端学习。
每日工作小结
完成翻译之后目前为止的各项事情都告一段落了，接下来就准备继续做安排的其他事情；
今天打开代码的时候突然对java容器有点兴趣，想着自己好像一直没怎么理解，于是去查了一下相关资料；学到了一些内容，算是有所收获：
1、 Collection和Collections的区别：前者是集合接口，为各种具体的集合提供了基本操作的通用接口方法；后者则是集合类的一个工具类。提供了一些排序，搜索及线程安全的方法等；
2、 List、Set、Map的区别
3、 HashMap和HashSet的具体实现原理；
4、 ArrayList和LinkedList的区别等
3/18进展报告
当天投入时间0.5h
完成的内容
今天同伴提出管理员需要登录所以还是要做个访问类，于是花了半小时完成查询功能；
第二天计划投入时间1.5h
工作计划
学习git版本控制
每日工作小结
再一次更改自己的代码之后又要把整个项目发给同伴，觉得很麻烦，之前就听说过git的版本控制是个大杀器，经过这几次的修改也深刻体会到了这一点，打算如果明天能完成课设的第二部分语法分析器，就开始学习git。
3/19进展报告
当天投入时间
无
第二天计划投入时间1.5h
工作计划
学习git版本控制
工作小结
今天一整天都在做语法分析器，看来两天内搞定很悬，ddl将近所以今日本课程无进展，明天一定会继续学习新的内容的——先立个flag。。。
思想：场景是用例的实例，最重要需求的抽象，通过运用场景来对系统的功能点或业务流程的描述，模拟用户操作软件时的场景，主要用于测试系统的业务流程
优点：可以提高测试效果。
http://jz.docin.com/p-372587788.html
当天投入时间2.5h
完成的内容
2h 看课程视频和PPT
0.5h git学习
第二天计划投入时间1h
工作计划
完善优化代码，了解同组成员进度；
每日工作小结
今天上课学习了“4+1”视图模型，知道了它从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件体系结构。
每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件体系结构的全部内容。
除此之外一直拖着的git终于按教程完整操作了一遍，不得不说真太便利了，要是一开始小组就决定借助git共同开发一定会大大提高效率的，博客链接——https://blog.csdn.net/ZZQHELLO2018/article/details/82354900
3/23进展报告
当天投入时间3h
完成的内容
2h 看课程视频和PPT
1h查看代码，解决问题
第二天计划投入时间2h
工作计划
和小组讨论之后要做的事情；
辅助完成ppt
每日工作小结
今天课上了解了框架，构架和设计模式之间的关系，对于各种框架有了一个更实际的了解；
例如框架的定义是框架就是一组相互协作的类；框架和平台的关系；框架和类库的关系；框架和设计模式的关系等等
3/24进展报告
当天投入时间2h
完成的内容
整理了一下笔记，做了一下个人小结初稿；
配置环境运行项目
第二天计划投入时间2h
工作计划
了解文档开发进度；
继续配置代码
每日工作小结
今天把之前写代码遇到了的bug都整合了一下，结合做过的笔记了个人小结的初稿，大概花了半小时左右吧；
实际上大部分时间其实都花在了配置环境上面，今天不知道为什么界面调整一直404，甚至昨天没问题的tomcat都主页登不了了，配了半天然后关机重启了一下，好了。。。这一刻我终于明白了——dbq我不配作为一只程序猿。
3/25今日进展：
和小组讨论提前演示的准备；
完善文档；
明日计划：
听其他组汇报和看视频与ppt；
继续完善文档。
今日小结：
今天的任务是看了已完成的ppt，大致了解一下明天自己组要汇报的流程，为明天上课做准备。同时也和小组讨论了一下是不是要提前演示一下。除此之外还完善了一下自己的个人小结。明天上课时会根据其他小组的汇报继续完善。
3/26任务基本完成，进展报告结束