unix系统的详细的命令.docx
《unix系统的详细的命令.docx》由会员分享，可在线阅读，更多相关《unix系统的详细的命令.docx（29页珍藏版）》请在冰豆网上搜索。
unix系统的详细的命令
2009年毕设
1.基于遗传算法的人脸特征识别研究
2.基于动态构模机制的报表系统的研究与实现
3.基于WEB的动态图形方法研究与实现
4.
UML笔记
《红皮书》
P43
泛化关系：
（“isakindof”）是一般事物（超类或父类）和该事物的较为特殊的种类（子类）之间的关系。
用子类指向父类的空心三角形箭头表示。
聚合关系：
（has-a）表示类间的关系是整体与部分的关系。
用空心的菱形关的实线表示，菱形头端为整体部分。
导航性：
表示可从源类的任何对象到目标类的一个或多个对象遍历。
即给定源类的一个对象，可以达到目标类的所有对象。
有单向关联，用一条带箭头的实线表示；双向关联，用一条没有箭头的实线表示。
P48
实现关系：
表示不继承结构而只继承行为。
通常用来规定接口和实现接口的类或组件之间的关系。
可以在两种情况下使用实现关系：
第一，在接口与实现该接口的类间；第二，在用例以及实现该用例的协作间。
用一个带空心三角形的虚线箭头表示，箭头方向指向接口。
P52
对象图（ObjectDiagram）：
表示在某一时刻一组对象以及它们之间关系的图。
可以看作是类图在系统某一时刻的实例。
由节点以及连接这些节点的连线组成，节点可以是对象也可以是类，连线表示对象间的关系。
对象图还可以包含标注和约束。
包图：
由包和包之间的联系构成，它是维护和控制系统总体结构的重要建模工具。
在对大型系统建模时，要处理大量的类、接口、组件、节点和图时，有必要将这些元素进行分组，即把语义相近关倾向于一起变化的元素组织起来加入同一包中，这样便于理解和处理整个模型，也便于轻松地控制这些元素的可见性，使一些元素在包外可见，一些元素隐藏在包内。
（1）教师类的基本属性
编号
姓名
职称
单位
性别
年龄
（2）学生类的基本属性
编号
姓名
专业
入学时间
性别
年龄
籍贯
外语
（3）课程类的基本属性
编号
名称
计划学时
学分
理论课时
实验学时
（4）教务管理类基本属性
编号
姓名
职务
单位
性别
年龄
用例图
（1）学生请求服务的用例图
选课
查成绩
查课表
查奖惩
（2）教师维护学生成绩及请求服务的用例图
录入成绩
更新成绩
查看成绩
查课表
查看教学计划
（3）教务管理人员维护学生教师及课程的用例图
增加学生
删除或更新学生信息
增加教师
删除或更新教师信息
增加课程
删除或更新课程信息
增加教学计划
删除或更新教学计划信息
（4）教务管理人员登录查询信息用例图
登录
查看学生信息
查看教师信息
查看课程信息
查看教学计划信息
参P67-68图5-4、图5-5
时序图参P83图6-5、图6-6
用例图的内容
（1）用例
（2）参与者
（3）依赖、泛化以及关联关系
用例是一个叙述型的文档，描述参与者使用系统完成某个事件时的事情发生顺序。
用例是系统的使用过程，不是需求或者功能的规格说明，但用例也展示和体现了其所描述的过程中的需求情况。
时序图（sequencediagram）：
是强调消息时间顺序的交互图。
描述了类以及类间相互交换以完成期望行为的消息。
时序图提供了事件流随时间推移的、清晰的和可视化的轨迹。
时序图中包括的元素：
类角色、生命线、激活期和消息。
生命线（lifeline）：
代表时序图中的对象在一段时期内的存在。
用位于对象底部中心的垂直虚线表示。
激活期（Activation）：
代表时序图中的对象执行一项操作的时期。
用位于对象生命线上的窄矩形表示。
协作图（collaborationdiagram）：
只对相互间有交互作用的对象和这些对象间的关系建模，忽略其他对象和关联。
协作图可视为对象图的扩展，它除了展现出对象间的关联外，还显示出对象间的消息传递。
强调交互中实例间的结构关系以及所传送的消息。
对复杂的迭代和分支的可视化以及对多并发控制流的可视化要比时序图好。
协作图中包括的元素：
类角色、关联角色和消息流。
关联角色（associationrole）：
代表协作图中连接在交互中所扮演的角色。
用连接（即连线或路径）表示。
消息流（MessageFlow）：
代表协作图中对象间通过链接发送的消息。
用类角色之间的箭头表示，消息流上标有消息的序列号和类角色间发送的消息。
一条消息会触发接受对象中的一项操作。
P84
状态图（statechartdiagram）：
是通过对象的生命周期建立模型来描述对象随时间变化的动态行为。
状态图包括的内容：
状态、转换。
（1）状态：
定义对象在其生命周期中的条件或状态，在此状态下，对象满足某些条件，执行某些操作或等待某些事件。
状态用于对实体在其生命中状况建模。
（2）转换：
包括事件和动作。
一个完整的状态有5个组成部分。
（1）名字（name）
状态可以是匿名的，即没有名字。
状态名一般放置在状态图符的顶部。
（2）入口/出口动作（entry/exitaction）
入口动作语法：
entry/执行的动作；
出口动作语法：
exit/执行的动作。
动作可以是原子动作，也可以是动作序列（actionsequence）
（3）内部转换（InternalTransition）
内部转换不会引起状态变化的转换，此转换的触发不会导致状态入口/出口动作被执行。
内部转换标识在状态的圆角矩形内部。
内部变迁语法：
事件/动作表达式
（4）延迟事件（DeferredEvent）
延迟事件该状态下暂不处理，但将推迟到该对象的另一个状态下事件处理队列。
就是说所有延迟事件是事件的一个列表，此列表内的事件当前状态下不会处理，在系统进入其他状态时再处理。
（5）子状态（Substate）
在UML中子状态是状态的嵌套结构，即包含在某状态内部的状态。
在UML中，包含子状态的状态被称为复合状态（CompositeState），不包含子状态的状态被称为简单状态（SimpleState）。
子状态以两种形式出现：
顺序子状态和并发子状态。
顺序子状态（SequentialSubstate）：
如果一个复合状态的子状态对应的对象在其生命期内任何时刻都只能处于一个子状态，即不会有多个子状态同时发生的情况，这个子状态被称为顺序子状态。
并发子状态（ConcurrentSubstate）
当复合状态中有两个或多个并发执行的子状态机时，则称复合状态的子状态为并发子状态。
P88
转换由5个部分组成，分别是：
源状态、目标状态、触发事件、监护条件和动作。
（1）源状态（SourceState）
一个转换可以有多个源状态，这表示状态机所在对象中的多个控制流在转换发生时汇合成一个控制流。
在UML中，多源状态的转换通常使用活动图表示。
（2）目标状态（TargetState）
（3）触发事件（TriggerEvent）
是引起转变的事件。
这里的事件可以是信号、调用、时间段或状态的一个改变。
一个信号或调用可以带有参数，参数值可以由监护条件和动作的表达式的转换得到。
（4）监护条件（GuardCondition）
监护条件是一个方括号括起来的布尔表达式，它被放在触发事件的后面。
监护条件可以引用对象的属性值和触以事件的参数。
当一个触发事件被触发时，布尔表达式被赋值。
如果值为“真”，则触发事件使转换有效。
如果值为“假”，则不会引起转换。
需求分析
《软件需求工程》P3
目标需求：
反映组织机构或客户对系统和产品提出的高层次的目标要求，限定了项目的范围和项目应达到的目标。
业务需求：
描述软件系统必须完成的任务、实际业务或工作流程等。
软件开发人员可从业务需求进一步细化出具体的功能需求和非功能需求。
功能需求：
指开发人员必须实现的软件功能或软件系统应具有的外部行为。
性能需求：
指实现的软件系统功能应达到的技术指标，如：
计算效率和精度、可靠性、可维护性和可扩展性等。
约束与限制：
指软件开发人员在设计和实现软件系统时的限制，如：
开发语言、使用的数据库等。
软件需求的分类：
《兰皮书》P125
系统需求可分为三类：
功能性需求、非功能性需求和可用性需求。
在需求分析中，经常使用的是功能性需求和非功能性需求两种类型。
可用性需求在小规模系统开发过程中常常被忽略，但在规模较大的软件开发中却是衡量一个软件是否成功的重要因素之一。
功能性需求描述了系统可以做什么，或者被期望做什么，即描述了系统的功能。
用例图用于描述系统的功能。
非功能性需求描述了保证系统正常运行（例如，安全性和可靠性）与提高系统性能等有关方面的问题。
可用性需求研究的主题是人机交互的方便性、易用性等方面的问题。
在教务系统中，要为每位学生建立一个账户，账户中存储着学生的个人信息。
学生登录系统可以查询自己的成绩、课表等信息，并可以更改个人密码。
系统功能需求：
教务管理系统为管理员提供主功能界面。
教务管理系统在启动时要求管理员输入口令，只有口令正确，才可以进入系统的主功能界面。
管理员负责对教务管理系统的维护工作，因此系统应赋予管理员对学生信息、课程信息、教师信息和教学计划信息能进行录入、修改、查询和删除等功能的操作权限。
《兰皮书》P23
用例图中的关系
泛化关系
泛化（Generalization）代表一般与特殊的关系。
在泛化关系中，子用例继承了父用例的行为和含义。
另一方面，子用例也可以增加新的行为和含义，或者覆盖父用例中的行为和含义。
表示泛化关系示例的用例图如图3.4所示。
包含关系
包含（Include）指的是一个用例（基本用例）的行为包含了另一个用例（包含用例）的行为。
在包含关系中，箭头的方向是从基本用例到包含用例，即基本用例是依赖于包含用例的。
表示包含关系示例的用例图如图3.5所示。
扩展关系
扩展（Extend）关系的基本含义与泛化关系类似，但对于扩展用例有以下的规则进行限制：
（1）基本用例必须声明若干“扩展点”。
（2）扩展用例只能在这些扩展点上增加新的行为和含义；
（3）扩展关系中箭头方向是从扩展用例到基本用例，即扩展用例依赖于基本用例。
表示扩展关系示例的用例图如图3.6所示。
三种关系的比较
（1）泛化和扩展表示的是用例之间的“isa”关系。
（2）扩展与泛化关系相比，多了扩展点的概念，即一个扩展用例只能在基本用例的扩展点上进行扩展。
（3）包含关系表示的是用例之间的“hasa”关系。
系统需求可分为三类：
功能性需求、非功能性需求和可用性需求。
在需求分析中，经常使用的是功能性需求和非功能性需求两种类型。
可用性需求在小规模系统开发过程中常常被忽略，但在规模较大的软件开发中却是衡量一个软件是否成功的重要因素之一。
功能性需求描述了系统可以做什么，或者被期望做什么，即描述了系统的功能。
用例图用于描述系统的功能。
非功能性需求描述了保证系统正常运行（例如，安全性和可靠性）与提高系统性能等有关方面的问题。
可用性需求研究的主题是人机交互的方便性、易用性等方面的问题。
在教务系统中，要为每位学生建立一个账户，账户中存储着学生的个人信息。
学生登录系统可以查询自己的成绩、课表等信息，并可以更改个人密码。
《兰皮书》P23
描述用例
用例的描述用脚本来完成，它是一份关于行为者与用例之间如何交互的简明和一致的说明书。
用例的述描着眼于系统的外部行为，而忽略系统的内部实现。
描述中尽可能使用客户的语言和术语。
用例的描述一般包含以下内容：
（1）用例的目的――用例的最终目的是什么？
（2）用例是如何启动的――哪个参与者在什么情况下启动用例的执行？
（3）参与者和用例之间的消息流――用例和参与者之间交换什么消息或事件来通知对方改变或恢复信息，并帮助对方做出决定？
描述系统与参与者之间的主消息流是什么？
系统中哪些实体被使用或修改？
（4）用例中可供选择的流――用例中的活动可根据条件或者异常有选择地执行？
（5）如何通过给参与者一个值来结束用例――描述何时可以认为用例已经结束。
用例图建模示例
学生成绩系统的业务需求如下：
（1）教师使用系统输入、更新学生的成绩。
（2）系统管理员根据教师提供的成绩创建学生成绩报告单。
（3）教师需要通过系统分发学生成绩报告单。
（4）系统允许教师和学生查询记录的成绩。
建立上述学生成绩系统的用例模型。
1.确定参与者
系统的参与者为：
教师、学生和系统管理员。
2.确定用例
确定参与者使用的用例，可通过提出“系统要做什么？
”的问题完成。
学生成绩系统的用例有：
输入成绩、更新成绩、创建学生成绩报告单、检查学生成绩报告单的准确性、分发学生成绩报告单和查询成绩。
对上述已经确定的用例，还要进一步明确它们之间的优先次序。
学生成绩系统的用例的优先次序为：
（1）输入成绩。
（2）查询成绩。
（3）更新成绩。
（4）创建学生成绩报告单。
（5）检查学生成绩报告单的准确性。
（6）分发学生成绩报告单。
3.描述用例
UseCase:
InputGrades
参与者：
Teacher
主要事件执行流程：
（1）教师登录系统。
（2）教师确定要记录哪些学生的成绩。
（3）系统要保证学生的自然情况数据已保存在数据库中。
（4）教师选择要输入成绩的课程。
（5）系统开始数据库的一项事务处理。
（6）教师输入学生的成绩。
（7）系统校对输入的成绩以确保其属于正确的值域。
（8）系统保存本门课程的成绩。
（9）系统结束事务处理。
（10）系统提示教师成绩保存完毕。
UseCase:
ViewGrades
参与者：
Teacher，Student
主要事件执行流程：
（1）教师或学生登录系统。
（2）教师或学生选择要查询成绩的课程。
（3）教师或学生输入查询条件。
（4）系统开始数据库的一项事务处理。
（5）系统加载足满足条件的学生成绩。
（6）系统显示学生成绩。
（7）系统结束事务处理。
（8）系统提示教师或学生成绩显示完毕。
UseCase:
UpdateGrades
参与者：
Teacher
主要事件执行流程：
（1）教师登录系统。
（2）教师选择要更新的成绩的课程。
（3）教师输入更新条件。
（4）系统开始数据库的一项事务处理。
（5）系统加载满足条件的学生成绩。
（6）系统显示学生成绩。
（7）教师更新学生成绩。
（8）系统保存本次更新。
（9）系统结束事务处理。
（10）系统提示教师成绩保存完毕。
检查学生成绩报告单的准确性（CheckReportCardsForAccuracy）用例是一个手工处理过程，而不是一个系统处理过程。
因此，可以把这个用例从脚本中删除。
UseCase:
GenerateReportGrades
参与者：
Administrator
主要事件执行流程：
（1）创建学生某一门课程的成绩报告单。
UseCase:
GenerateReportGrades（方法二？
这仅适用于教师用的）
参与者：
Teacher
主要事件执行流程：
（1）教师登录系统。
（2）教师选择要创建的成绩报告的课程。
（3）教师选择要创建的成绩报告的学生班级。
（4）系统开始数据库的一项事务处理。
（5）系统创建满足条件的学生成绩单。
（6）系统显示学生成绩单。
（7）系统结束事务处理。
（8）系统提示教师成绩报告单创建完毕。
UseCase:
DistributeReportGrades
参与者：
Teacher
主要事件执行流程：
（1）教师登录系统。
（2）在网上发布学生某一门课程的成绩报告单。
UseCase:
DistributeReportGrades（方法二）
参与者：
Teacher
主要事件执行流程：
（1）教师登录系统。
（2）教师选择要发布成绩报告的课程。
（3）教师选择要发布成绩报告的学生班级。
（4）系统开始数据库的一项事务处理。
（5）在网上发布学生某一门课程的成绩报告单。
（7）系统结束事务处理。
（8）系统提示教师成绩报告发布完毕。
在对上述系统用例进行详细描述之后，除了原有的用例之外，还产生了3个用例：
系统登录（Login）、加载成绩（LoadGrades）和保存成绩（SaveGrades）。
UseCase:
SaveGrades？
？
（自拟）
参与者：
Teacher
主要事件执行流程：
（1）系统开始数据库的一项事务处理。
（2）系统保存。
（3）系统结束事务处理。
（4）系统返回保存完毕信息。
UseCase:
LoadGrades？
？
（自拟）
参与者：
Teacher
主要事件执行流程：
（1）系统开始数据库的一项事务处理。
（2）系统加载学生成绩。
（3）系统结束事务处理。
（4）系统返回加载完毕信息。
UseCase:
Login（自拟P130）
参与者：
Administrator、Teacher、Student
前置条件
无
后置条件
如果用例成功，参与者可以启动系统，使用系统提供的功能。
反之，系统的状态不发生变化。
基本事件流
当学生成绩系统启动时，用例启动。
主要事件执行流程：
（1）系统提示用户输入用户名和密码。
（2）用户输入用户名和密码。
（3）系统验证用户名和密码，若正确，则用户登录到系统中。
异常事件流
如果用户输入无效的用户名/密码，则系统显示错误信息。
用户可以选择返回基本事件流的起始点，重新输入正确的用户名/密码；或者取消登录，用例结束。
4.创建用例模型
根据以上的分析，学生成绩系统用例模型的功能如下：
（1）教师可以输入学生成绩。
（2）输入学生成绩包含了保存学生成绩。
（3）教师可以更新学生成绩。
（4）更新学生成绩包含了加载、保存成绩。
（5）教师、系统管理员和学生可以查询成绩。
（6）查询成绩包含了系统登录。
（7）系统管理员可以创建学生成绩报告单。
（8）教师可以在网上发布学生成绩报告单。
根据上述系统用例模型的功能，可在Rose建模环境下绘制出如图所示的学生成绩系统的用例模型。
UML顺序图
顺序图的建模元素有对象（参与者的实例也是对象）、生命线（LifeLine）、控制焦点（FocusOfControl）、消息（Message）等。
顺序图建模示例
继续为学生成绩系统的顺序图建模。
以教师查询学生成绩（ViewGrades）用例进行顺序图建模。
1.确定工作流
根据对ViewGrades用例的分析可知，教师查询学生成绩用例至少有以下3个工作流：
（1）教师成功地查询学生的分数。
（2）教师试图查询某个学生的分数，但该学生不存在。
（3）教师试图查询某个学生的分数，但该学生的分数不存在。
2.从左到右布置对象
从左到右布置所有参与者和对象，包括要添加消息的对象的生命线，如图4.3所示。
3.添加消息和条件以便创建每一个工作流
（1）第1个工作流――教师成功地查询某个学生成绩的顺序图，如图4.4所示。
（2）第2个工作流――教师试图查询某个学生分数，但该学生不存在的顺序图，如图4.5所示。
（3）第3个工作流――教师试图查询某个学生分数，但该学生的分数不存在的顺序图，如图4.6所示。
UML协作图
协作图建模
继续以学生管理系统进行协作图建模。
在这个示例中，将对学校的教师（Teacher）登录网站（Website）查看学生成绩这个用例进行协作图建模。
1.确定属于协作图的对象
从用例的描述中可以确定需要教师（Teacher）、学生（Student）和成绩（Grade）这3个类的实例，即对象。
但这3个对象能否满足用例要求的功能呢？
通过下列问题的分析得出结论：
（1）Teacher类如何与Student类进行交互？
（2）Student类从哪里获取其数据？
（3）Teacher类如何才能登录系统？
通过上述3个问题的分析可知：
第一，需要一个Website类的实例提供进行交互的接口；
第二，需要一个Database类的实例提供为Student检索信息的功能；
第三，需要一个Login类的实例提供让Teacher登录系统的手段。
完成上述功能的3种类的实例如图4.17所示。
4.17确定属于协作图的元素
2.确定对象之间的链接，以及沿着链接的消息
接下来需要用到许多描述对象之间链接的消息的标记符，以及特定消息类型的规范。
描述教师登录网站查看学生成绩这个用例的协作图执行过程如下：
（1）Teacher对象把Login（UID,PWD）消息发送给Website对象；
（2）Website对象把Validate（UID,PWD）消息发送给Login对象；
（3）Login对象把Lookup（UID,PWD）消息发送给Database对象；
（4）如果Lookup消息的结果为Pass，则Login对象把DisplayMenu（）消息发送给Website对象；
（5）如果Lookup消息的结果为Fail，则Login对象把Logout（）消息发送给Website对象；
（6）如果已显示用户界面菜单（即已经登录），则Teacher对象把LoadStudent（name）消息发送给Website对象；
（7）Website对象把GreateStudent（name）消息发送给Student对象以便创建它。
（8）Student对象把LoadStudentInfo（name）消息发送给Grades对象集合中的每一个Grades对象。
（9）每一个Grade对象把LoadGrades（）消息发送给Database对象。
（10）Student对象把DisplayStudent（Grades）消息发送给Website对象。
实现上述执行过程的协作图如图4.18所示。
图4.18查看学生成绩的协作图建模
小结
顺序图和协作图都属于交互图，顺序图从时间的角度描述对象之间的交互，而协作图从对象之间协作的观点描述对象之间的交互。
顺序图可清楚地表达对象之间交互的时间顺序，但没有明确表达对象之间的关系。
协作图能够清楚地表达对象间的关系，但时间顺序必须从顺序号获得。
顺序图用于表示解决方案，而协作图常用于过程的详细设计。
协作图是对象图的扩展。
对象图描述出了对象和对象之间的静态关系，而协作图不但描述了对象之间的关联，还描述了对象之间的消息传递。
类图建模（逻辑视图）
UML类图建模需要反复执行以下两个步骤：
（1）确定类及其关联。
（2）确定属性和操作。
本节创建学生成绩系统的UML类模型。
1.确定类和关联
（1）可以通过分析用例图确定类及其关联。
通过图3.7的用例图分析，可以确定Grades和ReportCards两个类。
（2）通过用例图中的参与者名称，可以确定Teacher,Student和Administrator三个附加类。
（3）检查用例图中各个用例（功能）所属的类：
①发布学生成绩报告单――Grades类。
②输入成绩――Grades类。
③更新成绩――Grades类。
④保存成绩――Grades类。
⑤加载成绩――Grades类。
⑥查询成绩――Grades类。
⑦生成学生成绩报告单――ReportCards类。
⑧系统登录――Login类。
（4）创建类之间的关联：
①Teacher发布Grades。
②Teacher输入Grades。
③Teacher更新Grades。
④保存Grades。
⑤加载Gr
升级会员 