《信息系统分析与设计》10 - 系统总体设计
《信息系统分析与设计》10 - 系统总体设计软件架构的设计什么是软件架构架构的概念：建筑、文学、音乐、机械、电子、计算机软硬件等领域都会使用“架构（architecture）”这一概念。架构都提供了系统最高层的设计方案，以确保建筑、小说、乐曲、设备、计算机等系统满足期望的特性。架构包含系统的一组基本结构（structure），每种结构都有各种类型的部件（component）及其关系构成，架构描述了这些部件的组合、相互调用参照、通信以及其他动态交互。架构和结构的关系：架构是抽象无形的，体现高层全局的决策，就像文章的中心思想和提纲。结构是具体有形的，体现决策的贯彻，如同文章的每个段落及细节描述。1、软件架构软件架构（software architecture）的定义没有统一的版本；一般认为：一个应用程序或计算系统的软件架构是一个或一组结构，它包含组成系统的软件元素、这些元素对外可见的性质以及它们之间的关系。对外 可见的性质 指软件元素能够提供的服务、性能特征、错误处理、共享资源的用法等。软件的一个结构元素可能是一个子系统、构件、进程、库、数据库、计算结点、遗留系统等等。软件架构是 最高层次 的系统分解，它不会囊括所有的结构和行为的定义，它只关注那些被认为是重要的元素。架构难以更改，一旦修改，意味着整个系统重建，而结构修改只影响局部。软件架构（software architecture）包括逻辑设计和物理部署两方面。逻辑设计：通过对系统的层、包、类、接口和子系统的组织方式来描述；物理部署: 描述了进程分配和网络配置。2、软件架构模式大部分的架构来源于有相似关注点的 系统 的 总结和抽象，这些相似性被描述成某种特殊模式的架构风格，也就是架构模式（architectural pattern）。一种架构模式就是一个经验秘籍，架构师在设计不同系统时可以重复使用这些先进经验。简单来说：软件架构模式就是可重复使用的软件结构风格。多层应用架构设计1、分层的含义分层模型的理念就是将任务横向划分（如高层、中层、基层）为不同级别，而不是纵向。基于组件的软件开发，组件根据 横向位置 划分为多层（N-Layer）：下层组件负责对上层组件提供服务上层组件可以使用下层组件定义的服务，但下层组件对上层组件一无所知。层与层之间通常是不透明的，每一层都具有独立的职责不同层的软件构件可以分布在多台机器上，也可以部署在同一台机器上，形成物理上的多层（N-Tier）层次模型的理念就是将整个任务横向划分为不同级别，而不是纵向C/S出现之后，软件就被分层了：Client端的软件完成前台任务，Server端的软件完成后台任务（一般是DB Server）；Client使用Server端的服务，依赖于Server端。Internet出现之后，软件进一步分层：Client端的软件（浏览器）完成输入输出任务，Web Server上的程序提供业务逻辑处理，后台DB Server完成数据的存取。C/S常被称为传统的两层，B/S称为三层。2、三个基本层次传统的C/S应用程序1.界面窗口程序中包含所有的内容，如输入输出、界面逻辑控制、业务逻辑运算等。2系统架构是两层，应用架构没有分层。经典的三层架构1 表现层：处理用户和信息系统之间的交互。可以是简单的命令行窗口，也可以功能完善的图形用户界面（胖客户端程序），如基于HTML的浏览器界面（瘦客户端程序），也可以是手机界面。2 业务逻辑层：也称为领域层或应用层，是信息系统所有和领域相关的工作。如根据输入数据或已有数据进行计算，可以是类库或Web服务。依赖于数据访问层获取数据或保存数据。3 数据访问层：一般指与数据库的交互，主要责任是数据库记录的存取。如组件中包含专门的数据访问类，或每个表对应一个数据访问类扩展的五层架构1 表现层：等同于三层中的表现层。2 控制层/中介层：是表现层和领域层的中介层，也称应用控制器。主要表示业务逻辑中的工作流，一般针对于用例的事件流控制。此外还负责会话状态、数据的合成或分解等事务。3 领域层：业务逻辑中的领域类的集合，不包含复杂工作流。4 数据映射层：负责将基于对象的领域层数据映射到数据库关系表中的记录。也称为数据持久层，可自行开发或采用持久化框架。5 数据访问层：负责数据库表的增删改查等操作。持久化框架中包含该层组件。MVC架构模式（当前最常用的架构）1模型（Model）：代表数据，使用对象及其属性实现。2控制器（Controller）：是模型与视图的联系纽带，客户的请求由控制器处理，它根据客户的请求调用模型的方法，完成数据更新，然后调用视图的方法将响应结果展示给客户。相应的，模型的更新与修改将通过控制器通知视图，保持视图与模型的一致性3视图（View）：是模型的外在表现形式，视图可以直接访问模型；查询数据信息，当模型中数据发生变化时，它会通知视图刷新界面，显示更新后的数据。MVC模式和三层模式有共同特点（业务逻辑、数据和表示的分离），但不完全遵守分层约定。多层体系结构的优势1客户对数据的访问通过中间层进行了隔离，数据库的安全性提高了。2应用程序分布部署在多个物理节点上成为可能，从而增强了处理大量的用户负载或计算任务的能力，系统可靠性和响应速度得到了提高。3业务逻辑变化后，客户端程序基本不做改动，当组件接口不变时，某一层的改动不会影响其它层，这也意味着更好的重用和可维护性。4页面表现开发和业务逻辑开发分离，有效地利用开发人员的专长和开发技巧，并且能够 提高并行开发 能力。3、软件框架“不要重复发明轮子”架构模式可以复用，当架构模式的复用形式不仅仅停留在逻辑层面（如蓝图、方案），而以物理的二进制组件的方式提供重用时，就产生了框架。软件框架（software framework）是对整个或部分系统可重用的设计和实现。框架可以选择对某种架构模式的基本结构和接口机制进行编程实现，不仅封装该架构模式的基本元素对外提供类库，还封装底层公用的流程控制逻辑，从而直接为应用软件提供了最初的骨架。框架就是一个半成品软件平台，软件框架和应用软件相当于：架构模式/框架/应用程序 => 菜谱菜式/半成品/成品菜；引入软件框架之后，整个开发过程变成了“分三步走”：1决定应用架构2选择实现应用架构的现成框架3基于框架之下编写程序（简单、统一）优点：代码具有相同规范和结构，易于理解和维护；提高效率；更稳定更可靠。局限：囿于框架所限定的“框框”之内构建应用程序，比较死板，缺乏灵活性软件架构与软件结构的区别1 架构是抽象无形的，体现高层全局的决策，就像文章的中心思想和提纲。2 结构是具体有形的，体现决策的贯彻，如同文章的每个段落及细节描述。3 架构包含了结构的初步描述和决策。4 相同架构的系统，具体结构允许有差异。面向对象的软件结构设计、类图根据架构设计类：边界类、实体类、控制类软件设计原则，高内聚、低耦合设计原则：总的来说就是抽象与复用（封装、信息隐藏）；松耦合高内聚：内聚指的是一个类的职责间相关联的紧密程度。如果一个类具有很多紧密相关的职责，而且只完成有限的功能，则这个类就具有高内聚性。低耦合：耦合度是测量一个类连接、了解或依赖其他类的强弱程度。低耦合可以降低依赖性，减小变化带来的影响。高层结构设计包包（Package）是一种逻辑分组手段，可以取UML模型中的任何一种事物，将相关成分聚在一起，以构成更高层的组织单元——包。分包（软件类的分组）有两种原则：共同封闭原则（Common Closure Principle），一个包中的各个类应该是由于相似的原则而改变，即将一组职责相似、但以不同方式实现的类归为一个包中。比如按照层来进行分包就是这种类型。共同复用原则（Common Reuse Principle），一个包中的各个类应该一起被复用，复用其中一个可能需要同时考虑同一个包中的其它协作类。通常和业务功能相关。结构化设计方法模块模块(Module) 一词使用很广泛。通常对应于用一个名字就可以调用的一段程序语句（子程序或函数。模块具有输入和输出、逻辑功能、运行程序、内部数据四种属性。结构图模块：用长方形表示调用：从一个模块指向另一模块的箭头表示前一个模块调用后一个模块。有循环调用和条件调用数据：用带圆圈的小箭头表示从一个模块传递给另一模块的数据（有实义）控制信息：带涂黑圆圈的小箭头表示一个模块传送给另一模块的控制信息模块的联系为了衡量模块的相对独立性，提出了模块间的耦合(Coupling)与模块的内聚(Cohesion)两个标准耦合：模块和模块之间的联系程度内聚：模块内部各元素之间的联系程度设计目标：1模块内的联系越紧越好2模块间的联系越少越好3高内聚低耦合模块间的耦合模块间的耦合：耦合是影响系统复杂程度的一个重要因素。 耦合的三个因素：1联系方式 ，2、来往信息的作用，3、模块间来往信息的数量。 耦合分类如下：数据耦合： 模块间的来往信息可能作为信息使用，也可能作为控制信息的使用，若两个模块间传递的信息只做数据用被合称为数据耦合 标记耦合：如果调用模块将整个数据记录传递给被调模块，而被调模块只使用了部分数据项，则称为标记耦合或特征耦合。控制耦合：一个模块将控制信息传递给另一个模块，以控制被调模块的内部处理逻辑。（可以分解）公共环境耦合：如果两个模块共享同一全局数据，直接存取另一个模块的某些信息，称为公共耦合。也叫直接引用，内容耦合：两个模块之间的内部属性有直接关联，也称病态耦合。（某些GOTO语句）模块的内聚模块的内聚可以分为以下几类：１、偶然内聚(coincidental cohesion)２、逻辑内聚(Logical cohesion)３、时间内聚(temporal cohesion)４、步骤内聚(procedural cohesion)５、通信内聚(communicational cohesion)６、顺序内聚(Sequential cohesion)７、功能内聚(functional_cohesion)：聚合程度是最高。作用范围与控制范围：一个判断的作用范围是所有这样的模块的集合,这些模块类含有依赖于这个判断结果的处理. 一个模块的控制范围，是指它本身集体所有下属模块的集合。这里下属模块包含直接下属模块及下属模块的下属模块。 模块的扇出：是指模块的直属下层模块的个数,模块的扇入：是指有多少个上级模块调用它。面向对象设计方法根据架构设计类：一、边界类 二、实体类、三、控制类 顺序图的基本元素有对象、参与者、生命线、激活框、消息和消息路线。设计原则设计原则：单一职责原则、开放封闭原则、Liskow替换原则、依赖倒置原则、接口隔离的原则。
《信息系统分析与设计》9 - 系统设计概述
《信息系统分析与设计》- 系统设计概述1 系统设计的任务要求通俗地说，设计就是要回答“怎么做”，即明确系统功能，根据实际的技术条件、经济条件和社会条件，确定系统的实施方案，即系统的物理模型。一个逻辑模型，可以提出多个物理模型根据物理模型进行实施，得到最终的物理系统系统设计的目标设计系统之前，先看看评价信息系统的标准，这些标准对任何设计方法都适用：信息系统的功能：是否满足用户的需求系统的效率：响应时间、操作的方便性系统的可靠性：抗干扰能力、故障恢复系统的工作质量：准确性、使用效果系统的可变更性：修改和维护的难易程度系统的经济性：系统收益与支出比与需求相同，设计的重点也在于软件，因为相对软件，硬件方案的复杂度和多样性较小。信息系统的可变更性变化是不变的真理。统计表示：在信息系统的整个生命周期中，系统维护成本占总成本的80%左右。因此，可变更性是衡量信息系统设计的重要指标。良好的结构设计结构简单系统各组成元素分工明确，易于理解元素之间的关系清晰简洁变动灵活谨防软件维护中的“水波效应”（一石激起千层浪）使系统各组成元素内部的改变容易实现，改动对其它部分的影响尽量减少提前考虑将来最易出现的扩展和变更高内聚、低耦合基本设计方法为了设计出结构良好的系统，方法如下：1把系统化分成一部分，其中每一部分的功能简单 明确易于修改;2系统功能单元的划分按层次进行;3每一个功能单元应尽可能封装为独立元素 ;4各个功能单元对外的接口以及相互间的控制和依赖等关系要阐明从分析过渡到设计分析的目标是做正确的事（do the right thing）设计工作就是正确地做事（do the thing right）分析与设计任务和目标不同，但在一些软件开发过程方法（如敏捷方法）中，分析和设计可能没有严格的阶段管理。因为工作内容或模型有较强关联，分析到设计的建模过程某种程度上是一个从粗到精、不断构思和设计、推翻或优化、从抽象到具体的过程。例如分析阶段建立了领域对象模型，完成了对领域对象最本质和核心的分析和抽象，设计阶段还会基于该模型进一步修正和完善（对需求的认识可能不是一步到位的）。系统设计的内容系统设计一般划分为 总体设计 和 详细设计 两部分：总体设计也称为概要设计，任务是设计出系统的主要框架结构，即组成物理系统的主要成分及其关系。总体设计包括以下几个方面的内容：1.系统体系结构（也称架构，architecture）的设计2.系统结构的设计，即具体组成元素及其关系（structure）3.系统对外接口和服务的设计软件结构的演变：粒度越来越大，范围越来越广详细设计各项具体细节，涉及软硬件的各个方面详细设计内容包括：输入设计输出设计人机交互设计（用户界面设计）模块处理过程详细设计/类及用例的详细设计数据库设计事物代码体系设计计算机系统和网络设计系统设计说明书设计完成，提交系统设计书，说明书可以采用两种形式书写：1单册文档，分章节介绍系统架构、总体结构、编码体系、输入/输出、人机交互、数据库、网络等各部分内容。2多册文档，以上各部分单独书写成册，如总体设计报告、用户界面设计报告、数据库设计报告、网络详细设计报告等。
《信息系统分析与设计》-领域对象建模1 面向对象方法概述从面向对象的角度来看，世界就是由对象组成的。任何给定的商业功能都是由一整套共同工作的对象互相协作来完成的。对象不仅可以执行功能，还拥有属性（数据）。计算机世界更好地映射现实世界。对象：对象是行动或思考时作为目标的人或事物广义的讲对象可以是任何人或事物。面向对象方法的发展面向对象编程（OOP）——> 面向对象设计(OOD) ——> 面向对象分析(OOA)面向对象方法的优势（1） 对问题空间的理解更直接，更符合人类思维方式（2） 系统分析和系统设计使用同一模型，各阶段过渡平滑（3） 开发出的信息系统本质上生命力强（4） 易于扩充和维护（5) 与数据模型一致2 识别领域对象用例建模解决了业务管理功能到信息系统功能的映射；领域对象建模解决业务管理对象到信息系统逻辑结构（软件结构模型和数据库结构模型）的映射；对象建模采用的是面向对象分析技术，有关模型包括：类图（class diagram）：对象及其关系，用于描述系统静态结构；状态图（statechart diagram）：对象的状态及转换，用于描述基于事件响应的对象动态行为和状态之间的关系；Q: 什么是领域对象？领域对象就是问题域中有意义的概念类，它们是现实系统中的事物（things）或事件（events）。软件系统中的类一部分来自于领域对象。Wirfs-Brock名词短语策略1 阅读理解需求文档（或用例说明）；2 反复阅读，筛选出名词或名词短语，建立初始对象清单（候选对象）；3 将候选对象分成三类，即显而易见的对象、明显无意义的对象和不确定类别的对象；4 舍弃明显无意义的名词或短语；5 小组讨论不确定类别的对象，直到将它们都合并或调整到其它两类。可根据概念类别来发现问题域中的候选概念，概念类分为：实体类和描述类。实体类: 指的是现实环境中存在的事物或者发生的事情；描述类: 指的是包含其他事物的信息，需要额外的对象描述，独立于对象现有实例。3 识别对象属性属性是描述对象静态特征的一个数据项。组成系统的事物之间是相互制约相互依赖的，对象间有一定的关联结构。如同实体关系图（E-R图）就基本表达了这种关联。UML对于对象关联关系有明确的定义和表示法。关联表示不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。可以使用关联表示对象了解其他对象的程度。PS：关联体现的是对象实例之间的关系，而不表示两个分类之间的关系。比如教师和课程之间是承担关系）保持属性的简单性1 仅定义与系统责任和系统目标有关的属性。2 使用简单数据类型来定义属性。如数字、字符串、日期、布尔、文本等。还包含多种特征或规则的数据，可考虑作为独立的对象类。3 一般不使用可导出的属性。4 分析阶段不为对象关联而定义属性。在确立关联后，在设计阶段通过关联属性来实现。属性的有关说明属性的名称和解释：有些属性只适用于该问题域，是专业术语，晦涩难懂；有些常用词语在特定环境下字面的含义有所修改，为了提高清晰度，需要对这些属性进行定义。属性的数据类型：分析时使用简单类型，如整数、实数、字符串、日期、数组、布尔等，分析阶段因为不考虑技术实现，所以不需要考虑具体语言能支持的数据类型。其它要求：如取值范围、缺省值等。4 识别对象的关联零散孤立的概念类构成不了系统的概貌。组成系统的事物之间是相互制约相互依赖的，对象间有一定的关联结构。如同实体关系图（E-R图）就基本表达了这种关联。UML 对于对象关联关系有明确的定义和表示法。关联表示不同类的对象之间的静态关系，它在一段时间内将多个类的实例连接在一起。可以使用关联表示对象了解其他对象的程度。对象关联通常可以使用“has a”来进行验证。描述关联的要素1、关联名称多数关联是二元的（即只存在于两个类的实例之间），在图中表示为连接两个类符号的实线路径。使用关联名称，应该反映该关系的目的，并且应该是一个动词词组。2、关联角色关联所联系的每一端叫做一个角色角色名称应该是一个名词，能够表达被关联对象在关联中所充当的角色，角色名称紧邻关联线的末端。3、关联的多重性(Multiplicity)定义了一个类A的实例在一段特定的时间内能够和多少个类B的实例发生关联。类似于ER中的关联基数（一对一/一对多/多对多）4、关联的导向性(Navigability)角色的导向性特征表示可以通过关联从源类导向到目标类上。也就是说给定关联一端的对象就能够容易并直接地得到另一端的对象。识别关联的导向可以推迟，与设计实现有关。通常是源对象存储了对目标对象的一些引用。整体-部分关联如果对象a是对象b的一个组成部分，则称b为a的整体对象，a为b的部分对象，二者对应的关联形式称为整体-部分关联（Whole-Part）。可以用 a “is a part of” b进行验证。整体-部分关系建模的这种关联也称为聚集（aggregation），在UML类图中使用连接线和菱形表达，菱形一端的对象是整体对象。整体-部分关联有两种类型：组合聚集(composition aggregation )组合聚集具有很强的归属关系，在特定时刻部分只能是一个组合对象的成员。整体端的重数不会超过 1（即它无法被多个整体对象共享）,关系建立后一般不可变更。关联路径的末端有一个实心菱形，用来表示组合关系。共享聚集 (shared aggregation)描述整体-部分的关系，部分可能同时属于多个整体对象。关联路径的末端有一个空心菱形，用来表示聚集关系。5 识别泛化关系泛化（Generalization）是在多个概念之间识别共性，定义超类（一般概念）和子类（特定概念）关系的活动。如在图书馆系统中，发现图书馆目前还收藏了其它资源，比如影碟（VCD/DVD）、音乐CD、电子书等品种。它们和图书一样可以被任何读者借出，每个对象都有条码和状态。但它们也有自己的特性，比如属性项、借阅期限、逾期惩罚不同，必须区别对 待。1、一般-特殊结构(Generalization-Specialization)如果类A具有类B的全部属性和行为，而且具有自己特有的某些属性或服务，则A叫做B的特殊类，B叫做A的一般类。这种关系也称为一般-特殊关系、泛化-特化关系、继承关系。继承：是指特殊类的对象拥有其一般类的全部属性与服务。特点：可以简化模型，有效地反映问题空间的分类层次。必须确认子类一定是父类的一个特殊类型，即可以用“is-a-kind-of”进行验证注意控制泛化的粒度，额外的泛化增加复杂性2、什么时候需要划分一般-特殊结构1 类的属性或行为不适合该类的全部对象2 属性和行为相似的类，将这些类的共性抽象出来作为超类，各自特性仍旧保留而作为超类的子类。3 不要将一个对象的状态变化设计为多个子类，除非对象的多数行为是由状态来决定3、抽象类如果一般类A的每个实例还必须是它的一个特殊类的成员，那么类A就被称为一个抽象类。4、多继承继承有单继承和多继承。多继承是指一个子类继承了两个父类的属性和行为。5、接口当多种不同类型的对象具有相似行为时，可以将他们的行为进行抽象，定义为接口。接口只是某种行为的契约，接口不含有契约的具体实现机制，实现由类来完成。6 名词解释对象：对象是行动或思考时作为目标的人或事物广义的讲对象可以是任何人或事物。封装：是软化模块化思想的体现，也是面对对象方法的一个重要原则。消息：对象通过对外提供的服务，在系统中发挥作用。 继承：是指特殊类的对象拥有其一般类的全部属性与服务。 资源项可以有三种状态：一初态 二，终态 三复合状态。根据概念类别来发现问题可以按以下 7 种来划分：1人员，2组织， 3物品，4设备，5事件，6规格说明 ，7业务规则或政策。
《信息系统分析与设计》-用例建模1 基于用例的需求分析用例分析是站在最终用户的角度看待系统及其特性，模型简单直接，一经提出便受到软件开发人员的青睐。用例总是和面向对象方法放在一起讨论，并且在面向对象标准建模语言UML中用例也具有中心地位。但严格意义上讲，用例并不是一个面向对象方法论的产物，不包含面向对象思想，只是因为用例概念最初是和面向对象方法一同提出并得到广泛接受而已。需求分析基本步骤1.从系统涉众获取候选需求2.结合系统业务背景理解候选需求3.捕获信息系统功能性需求（用例模型）4.捕获与功能需求相关的非功能性需求或其他技术性要求用例的概念用例创始人雅各布森(Ivar Jacobson)认为：用例（use case）是对于一组动作序列的描述，系统执行这些动作会对特定的参与者（actor）产生可观测的、有价值的结果。阿里斯代尔·科克伯恩（Alistair Cockburn）认为：用例（use case）是各种系统受益人之间的一种行为契约。行为包括对象的活动、动作和对象之间的交互等。每一个用例实际上都代表了一个用户目标，根据三个目标层次（概要层、用户目标层、子功能层）将用例进行分层，从而有效把握用例的粒度。用例和用例模型的意义1、用例是对系统需求（主要是功能需求）的规范化描述，用例模型是面向对象分析的关键输入2、用例图及用例的事件流描述集中体现了系统责任3、通过用例建立交互图。交互图就是用例的具体体现，其实现是以对象和对象间协作为基础的。参与者(Actor)：参与者是系统之外与系统进行交互的任何事物。主要参与者（primary actor）：是从系统中直接获得可度量价值的用户，功能最直接最主要的用户。次要参与者（secondary actor）： 的需求驱动了用例所表示的行为或功能，在用例中起辅助支持作用。2 用例的描述用例图是对系统中的用例的高度概括和直观的表示，但没有细节。应对每个用例进行文字的详细描述，从而准确定义“做什么”，即需求。用例规格说明（模板）Use Case Specification用例名称主要参与者/次要参与者简要描述前置条件后置条件主事件流（主要成功场景/基本路径）备选事件流（扩展路径/替代流程/异常事件流）特殊要求/非功能性需求发生频率用例的前置条件和后置条件前置条件（pre-condition）：表述在系统允许用例开始以前，系统应确保为真的条件。这可为后续的编程人员提供帮助，从而确定在用例的实现代码中哪些条件无须再次检验。如果前置条件不满足，用例无法被启动，比如“预定图书”用例的前置条件是读者已正确登录到系统中。后置条件（guarantee）：或称为成功保证。表述在用例结束时，系统将要保证的限定条件，一般都是在成功完成用例后成立。一旦用例被成功地执行，可能会导致系统内部某些状态的改变，比如成功地“借出图书”会使图书状态改变等。某些用例可能没有前置条件或后置条件，比如“查询书目”，因为该用例执行后不会改变系统状态。用例与事件流（Flow of Activities）用例描述的是一个系统做什么，可以通过用足够清晰的、外部人员很容易理解的文字描述一个事件流，来说明一个用例的行为。事件流的描述包括：用例何时开始和结束用例何时与参与者交互（对话过程）参与者与系统之间有什么对象或信息被交换该行为的主事件流和备选事件流主事件流：主事件流是指能够满足目标的典型的成功路径。不包括条件及分支主成功场景/开心路径/基本路径备选事件流：备选事件流是指除主事件流之外的各种可能失败情况、分支路径或扩展路径。3 建立用例的关系进行用例描述时，往往会有冗余的情况出现，比如多个用例会共享一些子功能。扩展和包含关系就是用例模型中消除冗余的一种手段。但忌讳使用结构化的功能分解将用例分解成一些子用例、子子用例。基本用例是包含常规会发生的最基本功能的用例，它是具有普遍性的，对于任何执行该功能的参与者来讲都是适合的。包含关系经过封装后可以在各种不同的基本用例中复用的行为称为包含用例。基本用例可以控制包含用例，并依赖于（使用）包含用例所得到的结果。包含用例是基本用例存在的必要条件一个基本用例可以有多个包含用例，一个包含用例可以包含在若干基本用例中。包含关系可以嵌套，但超过三层的嵌套是难于理解的。比如“查询书目”用例既可以单独存在，也可以作为“预定图书”的包含用例。扩展关系表达某些可选或只在特定条件下才执行的系统行为的用例，它们是对基本用例的扩展。称为扩展用例。扩展用例是可选的，它是否执行取决于在执行基本用例时所发生的事件（存在扩展点）。扩展用例的缺失不影响对基本用例的理解。泛化关系（不推荐）如果两个或更多用例在行为、结构和目的方面存在共性，可以使用泛化关系。父用例描述这些共有部分，子用例继承父用例并特殊化。
结构化系统分析（流程建模）1.业务流程分析与建模著名管理大师迈克·哈默在其《企业行动纲领》一书中提出“业务流程至上”，利用信息化技术提升企业管理的水平，首要的着眼点是流程！业务流程是企业核心竞争力，信息技术是核心竞争力的加速器系统规划阶段需要进行业务流程分析，强调企业整体业务过程及其优化系统分析阶段需要进行业务流程分析，更关注具体流程的执行细节业务流程分析业务流程就是为达成业务目标而设定的一系列标准化的步骤,可以体现出一件工作“先做什么,后做什么,由谁来做”的关系。企业过程(business process),过程是指一系列逻辑相关并且达到某个预定产出的任务。关注进程、工序、工艺、制作法，强调对全程、全面、粗略的过程描述。业务流(transaction flow,也称事务流)，企业过程落实到操作层面的具体详细的活动和步骤。关注管理程序、手续、步骤，如学生入学注册流程、产品出库流程。业务流程图的画法业务流程图示应有以下基本表达能力：1. 业务流程包含多个业务功能（活动）2.业务功能可能由不同部门负责3.活动有次序4.活动执行过程含有控制逻辑(（如分支、并发、同步汇合等)绘制业务流程图的注意事项：1. 从主要指系统或组织中的主要业务流程入手，他们是系统中起关键作用的部分 ；2.绘图应根据流程方向，尽量呈现由上至下，由左至右的一致性 3.使用在一定范围内通用统一的符号，标记图形，尽可能简单图形中的文字，务必简要明确符合业务人员用语习惯一个活动框应当是一件独立的工作或者事件一个判定框代表一个判定值（真或假），不应表示活动或动作本身。4.流程图的结构应完整, 标明流程名称；5.关注流程起始点与终结点。 一般一个流程有一个起始点，一或多个终结点；6.尽量识别并绘制出流程中用到的表格和文档。2.数据流分析与建模分析的重要任务是识别和表达需求，建立系统的逻辑模型。数据流分析从企业的业务活动中找到数据流（信息流），即分析每个活动的数据输入和数据输出，忽略企业运作中那些与数据无关的活动。数据流分析方法采用结构化分析方法（或HIPO法，hierarchical input process output)；基本思想：把一个系统看成一个整体功能，明确信息的输入与输出，系统为了实现这个功能，内部必然有信息的处理、传递、存储过程。这些处理又可以分看做整体功能，其内部又有信息的处理、传递、存储过程。如此一级一级地剖析，直到所用处理步骤都很具体为止。数据流图(DFD)数据流图DFD：采用一系列分层次的数据流图来描述系统。利用分解和抽象这两个基本手段控制系统的复杂性，把大问题分解成小问题，然后分别解决，这就是分解。分解按照层次进行，先考虑问题最本质的特性，暂时略去具体细节，以后再逐层添加细节，直到最详细的内容。简单来说就是：数据流图描述数据流动、存储、处理的逻辑关系，也称为逻辑数据流图，一般用 DFD 表示。DFD的每一个层次都代表了系统的一个抽象水平高层次DFD中的数据处理可以进一步分解成低层次、更详细的DFD,即自顶向下、逐层分解的方法。数据流图用到四个基本符号□：方框，表示数据的源点或终点，即外部实体〇：圆或椭圆，表示加工；数据处理→：箭头，表示数据流；=：双杠(带一边开口,一边闭合)，表示数据存储；画数据流图的注意事项1.关于层次的划分 2.检查数据流图的正确性3.提高数据流图的易理解性。4.确定系统边界数据流图的优缺点图形元素少，易学易读，容易与用户沟通，有层次性，允许系统分析员由上至下逐步分析系统，不会受因于太多复杂的细节不能描述系统的控制流，潜在的非语法错误不易发现，复核因难，需要有一定的分析设计经验。数据字典数据流图描述了系统的分解，但是没有说明系统中各个成分的含义。数据字典是对DFD的补充描述，用来描述数据流程图中的数据流、数据存储、处理过程和外部实体的详细内容数据流图与数据字典共同构成系统的功能模型，数据字典可以改进通信，规范描述，消除误解。数据字典的各类条目1. 数据元素2. 数据结构3. 数据流4. 数据存储5.处理过程6. 外部实体数据字典的作用1.按各种要求列表；2. 相互参照，便于系统修改；3.由描述内容检索名称。4. 业务规则的表示在数据字典中表达处理过程可使用小说明（或基本说明），可以是自然语言，但针对复杂处理逻辑，可以使用：结构化语言、判定表、判定树。结构化语言三种基本语句：1.祈使语句：指出要做什么，包括一个动词和一个宾语。2.判断语句：判断语句类似结构化程序设计中的判断结构。其一般形式是如果 条件x成立 则 动作A 否则（条件不成立） 动作B3.循环语句：表达在某种条件下，重复执行相同的动作，直到这个条件不成立为止。循环一个班的每一个学生 计算该学生的总成绩判定树如果一个动作的执行不只是依赖一个条件，而是与多个条件有关，那么这项策略的表达就比较复杂，就可以使用判定树来表示。例如：邮政系统中，包裹邮资的计算策略与国别、路程、重量、保值额度等有关，使用自然语言来描述显然不够简洁。判定表如果条件较多、每种条件的取值情况也较多的情况下，可以使用判定表。判定表的优点是可以把各种组合情况一个不漏地表示出来，还能帮助发现遗漏和矛盾的地方三种工具对比 结构式语言判定树判定表直观性一般很好一般用户检查不便方便不便可修改性好一般差逻辑检查好一般很好机器可读性很好差很好机器可编程一般不好很好
《信息系统分析与设计》笔记 5-系统分析概述1.系统分析的任务系统分析员（system analyst，SA）与用户在一起，充分了解用户的要求，并把双方的理解用系统说明书表达出来。系统说明书审核通过之后，将成为系统设计的依据，也是将来验收系统的依据。也称需求分析。系统分析的本质分析的本质就是理解和发现。观察、访谈 → 理解 → 表述发掘批判、革新系统分析的困难系统分析是研制信息系统最重要的阶段，也是最困难的阶段。困难主要来自三个方面：1. 问题空间（problem domain）的理解2. 人与人之间的通讯3. 环境的不断变化2.系统分析的过程和方法分析的重要任务是识别和表达需求，建立系统的逻辑模型。问题分析通过详细调查全面深入理解用户的业务，找出用户所面临的问题，准确把握用户真正的需要，为最终整理出符合用户需要的需求做准备。分析过程如下：1. 明确项目的背景2. 明确项目目标、范围、相关部门和人员3. 找出关键涉众（stakeholder，也称利益相关人员）及待解决的问题。涉众包括系统的用户、项目决策者、受项目影响的第三方等。4. 调查和分析业务流程，建立业务流程模型以描述用户处理业务的过程及过程中数据的流转。系统调查方法调查是识别需求的基础，是建立系统逻辑模型的基础。调查包括：业务处理过程是什么样的？(干什么？)业务过程应该怎样完成？(怎么干？)业务谁负责，完成业务需要什么输入，能输出什么？传统的系统调查方法有：1. 资料收集2. 访谈结构化面谈：有为面谈专门设计的问题非结构化面谈：通常为开放式问题3. 实地观察4. 调查问卷需求引导方法一般用户在开发之初，对所要开发的信息系统应该具有的功能和所能达到的结果并没有清楚的认识，因此，需求调查比现行组织系统调查难度更大。``对用户进行引导和启发，让用户获得信息系统的感性认识，引导他们发现现行组织管理和业务处理中所存在的问题，从而发掘需求和找到解决方案。采用以下需求引导方法：1. 原型法：利用快速开发工具，根据用户的初步需求，构造出信息系统的初步原型。2. 联合应用开发（JAD）会议： JAD（joint application development）是一种类似于头脑风暴的技术，在一个或多个工作会议中将所有利益相关者带到一起，集中讨论和解决最重要的问题。3. 观摩法：在系统开发之初，可以让用户参观同行业或同类型成功的信息系统。需求分析（系统软件需求分析）系统需求是新系统必须完成的功能或其局限性。需求分析就是识别需求的过程。需求有三种类型：功能性需求、技术性需求、领域需求功能性需求定义：系统最主要的需求，表达系统必须完成的所有功能及其必要性和相容性， 以满足企业完成业务活动和管理的需求。 非功能性需求定义：也称为技术性需求，是和环境硬件和软件有关的所有可操作目标。1. 功能性需求：涉及商业应用，是系统必须完成的活动或过程，即系统功能以及相关数据。功能性需求是根据业务过程和业务规则确定的，有些容易获取，有些则是隐含的，需要去发现。2. 技术性需求：技术性需求也称非功能性需求，是和公司的环境、硬件和软件有关的所有质量目标。例如：系统必须能支持100个并发用户；保存订单的时间不能超过0.5秒等等，涉及系统性能、可靠性、安全性等质量特性。通常是一些技术目标。3.领域需求:是由软件系统的应用领域所决定的特有的功能需求，或是对功能的约束。需求分析则是对原业务进行抽象和升华，根据业务和用户需要确定计算机信息系统的“需求”。系统需求是精确和具体的。需求分析方法需求分析的传统方法：1. 面向过程的结构化方法（自顶向下、逐层分解）2. 面向数据的信息工程方法（数据驱动）3. 面向对象方法（对象驱动、UML）目前系统分析的一般做法是综合运用以上方法，最后统一采用UML来建立系统逻辑模型。需求定义需求分析是分析人员与用户反复沟通和谈判的过程。需求定义就是在各方就系统需求达成一致意见后，整理并建立最终的需求模型，详细定义和描述每项需求，确认约束条件及限制，编写需求规格说明。系统分析建模内容1. 流程建模业务流程（业务流程图/UML活动图）数据处理流程（数据流图）2. 用例建模信息系统功能模型（UML用例图）3. 领域对象建模领域对象模型（UML类图、UML状态图）由UML类图可以替代ER数据模型3.系统说明书《系统说明书》是系统分析阶段的成果。该文档主要描述了系统的需求，在软件工程领域也称作《需求规格说明书》（requirement specification）系统说明书的内容1. 引言项目名称、目标、背景、引用资料、术语说明等2. 项目描述项目的主要工作内容现行系统的调查情况功能需求数据需求其他需求3. 实施计划工作任务的分解 → 进度 → 预算系统说明书的审议系统说明书经过审议后，成为下一阶段工作的依据。审议由项目技术人员、企业管理人员、专家等共同完成。系统说明书的品质1. 正确性；2. 完整性；3. 一致性；4. 无二义性；5. 可修改性；6. 可跟踪性
《信息系统分析与设计》-系统规划1.系统规划的特点、任务系统规划阶段的主要任务是：（1）制定信息系统的发展战略；（2）制定信息系统的 总体方案，安排项目开发计划；（3）制定系统建设的资源分配计划系统规划的任务特点：任务特点制定信息系统发展战略高瞻性制定信息系统总体方案全面性制定信息系统开发计划切实性制定信息系统资源分配合理性系统规划的特点：（1）系统规划是面向全局，面向长远的关键问题具有较强的不确定性，结构化程度较低 （2）系统规划是高层次的系统，分析，高层管理人员是工作的主体。（3）系统规划不宜过细 （4）系统规划是企业规划的一部分，并随环境发展而变化。 系统规划应遵循以下原则：（1）支持企业的总目标。（2）整体上着眼于高层管理兼顾各管理层的要求 （3）摆脱信息系统对组织机构的依从性。（4）使系统结构良好的整体性 （5） 便于实施。2.信息系统战略规划信息系统的战略规划包括以下几方面的内容 （1）信息系统的总目标、发展战略与总体结构；（2）对当前信息系统状况的了解 （3）对相关信息技术发展的预测；（4）近期发展的计划3.规划方法1 战略目标集转移法（SST-strategy set transformation）把企业的总战略信息系统战略分别看成信息集合，信息系统战略规划的过程则是将组织战略集转换成与它相关联和一致的信息系统战略集。 关键步骤：(1)描绘各类人员（群体）结构：如经理、雇员等；(2)识别各类人员的目标和要求；(3)识别各类人员在组织中的使命及战略；(4)组织战略集转化为信息系统战略。2 企业系统规划法（BSP-business system planning） *企业系统规划法 BSP：IBM公司70年代提出的一种系统规划方法，适用于信息系统规划。关键步骤：(1)定义管理目标(2)定义管理功能组定义管理功能是 BSP 方法的核心。定义管理功能具体方法如下：识别资源、根据资源的生命周期识别功能、汇总分析。(3)定义数据分类定义数据类有两种基本方法，实体法和功能法。(4)定义信息结构3 关键成功因素法（KSF-key successful factors，或 CSF-critical success factors）通过分析找出企业成功的关键因素，然后再围绕这些关键因素来确定系统的需求，并进行规划。关键步骤：(1)确定组织目标(2)确定关键成功因素(3)确定关键成功因素的性能指标每个因素的可测量性能，性能指标和标准关键性能指标（key performance indicator，KPI）(4)确定信息需求4 价值链分析法（VCA-value chain analysis）每一个企业都是在设计、生产、销售、发送和辅助其产品的过程中进行种种活动的集合体，所有这些活动可以用一个价值链来表明。不同的企业价值链的活动中，只有特定的能创造价值的经营活动，才是价值链上的“战略环节”。战略制定者优先考虑战略环节引入信息技术应用，优化其处理流程，最大地增加其价值基本步骤：(1)识别企业价值链(2)确定关键价值增加环节(3)确定关键价值减少环节(4)明确信息技术对关键价值环节的支持4.可行性分析报告“可行性”是指在企业当前情况下，研制这个信息系统是否有必要，是否具备必要的条件。（可能性、必要性、合理性）可行性分析的内容：技术可行性、经济可行性、社会可行性技术可行性根据现有的技术条件能否达到所提出的要求；所需要的物理资源是否具备能否得到。技术条件包括以下几个方面：硬件：存储量、速度、质量、可靠性等方面软件：各种系统软件的能力、是否已有专用软件技术人员：水平、数量、流动性经济可行性经济可行性主要包含： 资金可得性和经济合理性。社会可行性社会可行性是指：所建立的信息系统能否在该企业实现在当前操作环境下，能够很好地运行 及组织内外是否具有接受和使用新系统条件。可行性分析报告的内容：（1）引言（2）系统建设的背景、必要性（3）拟建系统的侯选方案（4）可行性论 证（5）几个方案的比较 （6）结论(立即开发/改进原系统/不可行)5. 资源的生命周期资源的生命周期：是指一项资源由获得到退出所经历的阶段，一般划分为产生、获得、服务和归宿四个阶段
信息系统建设概论1.信息系统建设的复杂性表现：技术手段复杂内容复杂，目标多样一个组织的管理与业务信息量大、面广，形式多样、来源繁杂，信息内容和处理要求又涉及到广泛的学科和事业领域。一个组织的信息系统必是一个规模庞大，结构复杂，具备多种功能、实现多个目标的大系统一个组织内各类机构和人员的信息需求不尽相同，有些需求可能相互冲突，需求的不确定性和可变性非常大。组织和外部环境之间的数据交换难以控制。投资密度大，效益难以计算信息系统的建设，需要巨额投资，是一种资金密集型的建设项目智力密集型或者知识密集型需用大量人工，是劳动密集型项目效益难以计算成功的含义：在规定的时间内，以规定的预算完成规定的目标。环境复杂多变涉及到组织内部各级机构、管理人员涉及组织面临的外部环境及发展趋势要考虑管理体制、管理思想、管理方法和管理手段的相互匹配、相互促进考虑人的习惯、心理状态及现行的制度、惯例和社会、政治诸因素2.统一建模语言UML​ 统一建模语言UML（unified modeling language）是由单一元模型支持的一组图示法。这些图示法有助于表达与设计软件系统，特别是采用面向对象方法构造的软件系统。UML通过不同的图来描述系统的结构（structure）、行为（behavior）、交互过程（interaction）。UML 2.2中一共定义了14种图（diagram）：系统结构：类图、对象图、包图、构件图、部署图等系统行为：活动图、状态图、用例图交互过程：通信图、顺序图、计时图等3.信息系统的生命周期生命周期的定义：​ 信息系统在使用过程中随着生存环境的变化，需不断维护、修改，当它不再适应的时候就要被淘汰，就要由新系统代替老系统，这种周期循环称为信息系系统的周期。信息系统开发围绕信息系统生命周期来进行，有时也称系统开发生命周期**（SDLC，System Development Life Cycle），体现系统工程的思想。简单来说就是：有产生、发展、成熟，消亡的过程信息系统的生命周期的5个阶段：信息系统的生命周期可以分为系统规划、系统分析、系统设计、系统实施、系统运行和维护等五个阶段系统规划（系统设计任务书）确定信息系统的发展规划；企业业务流程的识别、改革与创新；对建设新系统的需求作出初步研究，确定信息系统的总体结构；确定系统的备选方案，对这些方案进行可行性分析系统分析（系统说明书）详细调查，确定系统的基本目标和逻辑功能要求系统设计（系统设计说明书）根据系统说明书中规定的功能要求，考虑实际条件，具体设计实现逻辑模型的技术方案系统实施（系统测试分析报告）计算机等设备的购置、安装和调试；编写、调试和测试程序；人员培训；数据准备或转换；系统调试与转换系统维护运行情况的记录；必要的修改；评价和总结等4.基于生命周期的开发方法​ 围绕生命周期的开发过程模型：瀑布开发方法、原型开发方法、迭代开发方法、螺旋开发方法、敏捷开法方法；瀑布开发方法应用场合：适用于一些需求已明确并且变化较少的信息系统特点：1 简单易用，容易理解，开发的进程一个顺着一个，2 没有反馈过程，需要严密控制，允许基线和配置早期接收控制；3 一个新的项目不适合这个模型，户直到项目结束才能看到质量如何；4 不允许或者严格限制变更不足：1 需求：客户常常难以表达真正的需求，而这种模型却要求严格的阶段性成果，返工困难，变更代价很大2 风险：客户要等到开发周期的晚期才能看到程序运行的测试版本，这时若发现大的错误，可能引起客户的惊慌，其后果也可能是灾难性的3 效率：因为前后任务的依赖关系，成员不能并行工作，有可能花在等待的时间比开发的时间要长，即所谓的“堵塞状态”原型开发方法应用场合：快速建立起来的可以在计算机上运行的程序，通常选取信息系统中某个关键功能作为原型。特点：1 用户积极参与；2 原型的开发没有严密的阶段性3 短期获得测试版本，降低风险不足：1 用户随意无止境的需求变化，因为用户容易产生误解，认为系统很容易被构造和修改2 如果采用原型基础上继续构造，由于修补过度，软件质量不易于保证3 开发人员为了快速构造原型，可能会采用不合适的操作系统、语言、算法等，造成后期风险，如系统适应性差、维护困难等迭代开发方法先提交一个有限的版本，细节部分逐步增加，即多次迭代后完成系统。迭代开发方法有迭增量迭代和进化迭代两种方法增量迭代应用：1 项目开始，明确了需求的大部分，但是需求可能会发生变化2 对于市场和用户把握不是很准，需要逐步了解3 对于有庞大和复杂功能的系统进行功能改进，本身就需要一步一步实施的。特点：1 以功能递增的方式进行软件开发（可并行化）2 能较快地产生可操作的系统3 在每一步递增中，都可以把用户/开发者的经验结合到不断求精的下一个增量中4 可改善测试效果和降低软件开发总成本。5 这个过程好比搭积木。进化迭代1 进化迭代与增量迭代的区别是在每个迭代周期是对上一次迭代的演化和完善。2 比如可以将一个软件功能的编程划分了多个迭代周期，每个迭代是对该功能的补充和进化。3 这个过程好比滚雪球。螺旋开发方法定义：把软件开发过程定义成不断上升的螺旋周期，每个周期划分为计划、风险分析、实施和评价四个方面。沿螺线自内向外每旋转一圈便开发出更为完善的一个新的软件版本。应用场合：1 单位内部开发的大规模软件项目2 风险是项目的主要制约因素3 可能会发生重大变更4 采用新技术特点：1 风险驱动，可以在生命周期早期强制性的确定项目中存在的风险2 需要开发人员具有相当丰富的风险评估经验和专门知识3 要求用户参与阶段评价，对用户要求较高敏捷开法方法定义：敏捷过程（agile process）是一系列轻量的过程模型的总称，致力于在无过程和过于繁琐的过程中达到一种平衡，强调对需求变化的敏捷响应，以不多的步骤过程获取满意的结果。5.基于开发技术的开发方法软件结构从简单到复杂，走过了从机器指令、语句、模块封装到类封装、再到构件和服务封装的历史发展过程，不同的开发技术和软件结构催生了不同的开发方法。1 结构化方法结构化方法也称为 面向功能/面向过程/面向数据流 的软件开发方法阶段内容结构化分析（Structured Analysis，简称SA）对软件进行需求分析，以数据流图表示结构化设计（Structured Design，简称SD）–进行总体设计，以结构图表示结构化编程（Structured Program，简称SP）–以程序流程图表示容易理解和交流，对于大系统可以从全局逐步展开到局部，整体性较好。结构化方法是其他系统开发方法（如面向对象方法）的基础。结构化方法的不足和局限性：1 开发周期长。 2 早期的结构化方法注重系统功能，兼顾数据结构方面不够。 3 结构化程度较低的系统，在开发初期难于锁定功能要求。2 面向对象开发方法面向对象(object-oriented)方法具有很强的类和对象的概念，因此它就能很自然地直观地模拟人类认识客观世界的方式。由面向对象程序设计(Object Oriented Programming)发展而来。OOP基本思想：1 客观世界的任何事物都是对象；2 对象之间有抽象与具体、群体与个体、整体与部分等几种关系，这些关系构成对象的网络结构。3 抽象的、较大的对象所具有的性质，自然地成为其子类的性质，成不必加以说明，这就是继承性。4 对象之间可以互送消息。优缺点：稳定可靠，有利于维护和重用，并容易实现多层分布式结构，但对前期分析设计人员要求较高，用户理解模型有困难。OOP一般指面向对象程序设计。 面向对象程序设计(Object Oriented Programming)作为一种新方法，其本质是以建立模型体现出来的抽象思维过程和面向对象的方法。3 面向服务开发方法面向服务的体系结构（Service-Oriented Architecture，SOA）以服务为软件组成要素，服务对外定义良好的接口和契约，独立于实现服务的硬件平台、操作系统和编程语言。优缺点：松耦合、自描述、可重用、开放标准。以 XML 为基础，将已有的服务进行重新组合后可以快速建立新的业务流程，要求分析有较强的业务流程的抽象能力。以结构化方法和面向对象方法为基础。
信息、管理与信息系统信息的概念信息的定义信息：信息是经过加工后的数据，它对接收者有用，对决策或行为有现实或潜在的价值。信息流：伴随以上各种活动产生各类信息，信息随以上各种流而流动，信息是企业管理的基础。数据和信息可看作原材料和成品的关系绝对 / 相对客观 / 主观具体 / 抽象从信息系统的角度看，信息具有以下一些基本属性：事实性扩散性传输性共享性增值性不完全性等级性滞后性数据-〉信息-〉知识世界银行推出了《1998年世界发展报告——知识促进发展》：数据是未经组织的数字、词语、声音、图像等；信息是以有意义的形式加以排列和处理的数据（有意义的数据）；知识是用于生产的信息（有意义的信息）,是人类关于自然界、人类社会及思维方式与运动规律的认识、经验的总和。知识 = 6W + 1Q。 know—what、know—why、know—how、know—who、know—when、know—where、know—quantity信息处理器人和计算机都是信息处理器，都有信息的输入、处理和输出功能。人进行信息处理的特点人需要反馈人需要一些多余的信息人们需要信息的压缩人们对信息需求的口味各异人需要非口语的信息输入信息与管理信息是管理的基础，管理的基本职能离不开信息。管理的决策理论学派认为：“管理就是决策”，决策过程就是收集、处理和使用信息的过程。管理活动一般可分为三个层次：高层/战略管理中层/战术管理基层/作业管理不同管理层次使用信息不同，可分为三类：战略信息战术信息业务信息管理是分层次的，不同层次的信息特点不同信息管理​ 对信息的有效管理和充分利用，能降低决策中的不确定性和风险，使各项资源得到最大限度的合理运用，为企业和社会创造更大财富。信息管理的理解有狭义和广义之分。狭义信息管理：认为信息管理就是对信息本身的管理，即采用各种技术方法和手段对信息进行组织、规划、控制、存储和检索等，并达到预定目标。广义信息管理：认为是对信息资源及其相关资源（如信息设备、信息技术、信息人员、信息系统等）进行规划、组织、领导和控制的过程。信息系统信息系统的定义​ 信息系统就是输入数据，通过加工处理，产生信息的系统。信息系统(Information System,IS)简称IS。以计算机为基础的信息系统是结合管理理论和方法，应用信息技术解决管理问题，为管理决策提供支持的系统。信息系统的特点管理理论、系统科学方法论和信息技术交叉形成的综合性应用学科面向管理，但不讨论具体的管理问题使用信息技术，但不致力于计算机科学技术的研究信息系统的功能信息的采集和输入：主要是识别、采集、校验识别信息有三种方法，（1)，由决策者识别 （2)、系统分析员亲自观察识别 （3)、先由系统分析员观察得到基本信息，再向决策人员调查加以修正补充。信息的传输：数据通信的手段（1)，信源即是信息的来源 （2)、编码是指把信息变成信号，（3)、信道就是信息传递的通道，（4)，无论信道质量多么好都可能有杂音或是干扰，这就是噪声。（5)，信号序列通过输出端输出后需要翻译或纯文字图像等，成为接收者需要了解的信息，这就是译码。（6)：信宿即信息的接收者可以是人机器或另一个信息系统信息的存储：介质？在哪？时效？信息的加工：查询、排序、归并、数学模型、人工智能信息的维护：准确、及时、安全、保密信息的使用：技术层面、价值深度信息系统的结构概念结构一般来说，由信息源、信息处理器、信息用户和信息管理者组成信息系统的概念架构。基于管理职能的逻辑结构即从组织的职能来描述系统结构，一个信息系统支持着组织的各种功能子系统，使用子系统可以完成事务处理、作业控制、管理控制、战略规划。一、 市场营销子系统 二、生产管理子系统 三、物资供 应子系统 四、人事管理子系统 五、 财务管理子系统 六、信息管理子系统 七、 高层管理子系统基于计算机实现的物理结构硬件结构分为：集中式结构 和 分布式结构（文件服务器，C/S结构，B/S结构）集中式结构：主机-终端结构：处理能力集中在主机，集中存储、计算；终端用于输入输出，无 CPU；分布式结构：文件服务器系统：程序和数据集中在文件服务器中；客户机根据权限存取服务器中文件，客户机有处理能力C/S 结构（客户/服务器结构）：客户机完成本地运算，可向服务器请求某种服务（如查询数据），服务器相应请求，完成运算后，将结果返回给客户机。B/S 结构（浏览器/服务器结构）：增加 Web 服务器，获取客户端请求，解析处理后生成HTML 文件返回给客户端；客户端配置浏览器软件（如 IE），通过网页方式实现信息的访问信息系统分类按技术发展分类1950－1960年 数据处理系统（EDPS）电子数据处理、业务处理、记录保存、传统的簿记应用1960－1970年 管理信息系统（MIS）管理信息系统、管理报告系统、信息管理系统1970－1980年 决策支持系统（DSS）决策支持系统1980－1990年 战略和终端用户支持系统 主管/经理信息系统(EIS)、主管支持系统（ESS）按管理应用划分企业资源计划（enterprise resource planning，ERP）供应链管理（supply chain management，SCM）客户关系管理（customre relationship management，CRM）电子商务（electronic business，EB）办公自动化系统（office automation system ，OAS）地理信息系统（geographic information system，GIS）内容管理系统 （content management system，CMS）信息系统与组织​ 信息系统在组织中不再仅仅支持事务数据的简单处理，辅助实现管理的自动化，而是成为大多数业务过程中的重要组成部分，成为支持企业战略目标实现的重要工具，在很大程度上改变了企业运作的方式。信息系统的发展趋势渗透性更强、范围更广无处不在的IS创造企业价值技术更深、智能化程度更强模块化定制、个性化云计算人工智能、语义理解
《信息系统分析与设计》笔记 - 1系统思想1.系统的概念​ 系统是由相互联系和相互制约的若干组成部分结合成的、具有特定功能的有机整体。系统是由若干要素组成的，是一个集合体；系统有一定的结构，同一系统的元素之间相互联系、相互作用；元素之间一切联系方式的总和，称为系统的结构（主要的、相对稳定的、有一定规则的联系方式）；系统具有特定功能，凡是系统都有一定的目的性，特别是人造系统。2.系统的分类​ 按系统的复杂程度分类：物理系统、生物系统、人类社会及宇宙系统;​ 按系统的起源分类：自然系统和人工系统 ;​ 按系统的抽象程度分类：实体系统、概念系统、逻辑系统;1）实体系统（物理系统）——最具体的确定存在的系统（系统实施阶段产生）。物理模型表达了具体的物理系统，模型中的元素都可以对应于实体（系统设计阶段产生）。 2）逻辑系统——介于实体系统与概念系统之间，利用人类抽象思维能力，抽取系统本质，描绘了系统的各个侧面（如静态的结构、动态的过程等）。使用逻辑模型表达（系统分析阶段产生），一个逻辑系统可以建立不同的物理模型和实体系统。3）概念系统——最抽象的系统，根据系统目标构思出来的系统雏形，描绘了系统的大致轮廓。使用概念模型表达（系统规划阶段产生）​ 按系统与环境的关系分类：开放系统与封闭系统。开放系统：指与其环境之间有物质、能量或信息交换的系统。 封闭系统：与环境没有任何物质、能量和信息交换的系统。 对系统的开放性的封闭性不能绝对化。系统具有边界，边界划分系统与环境。3.系统的特性系统的特性：整体性、层次性、目的性、稳定性、突变性、自组织性、相似性​ 系统整体性：系统是由若干要素组成的具有一定新功能的有机整体，各个要素一旦组成系统整体，就表现出独立要素所不具备的性质和功能，形成新的系统的质的规定性，从而表现出整体的性质和功能不等于各个要素的性质和功能的简单相加。整体性是系统最重要的特性，是系统论的基本原理，整体性表现在：系统由部件组成，部件之间不是简单累加，而是具有了新的质亚里士多德名言“整体大于部分之和”：1+1>2，与之相反“一个和尚挑水吃，„三个和尚没水吃”整体性以有机关联性为保证（部件的不可分割）划分系统以及子系统就是要从整体性出发，充分考虑各组成元素之间的关联性。比如学校系统教师工资的计算​ 系统的层次性：由于组成系统的诸要素的种种差异，使系统组织在地位和作用、 结构和功能上表现出等级秩序性，形成具有质的差异的系统等级。 层次性表现在：系统组织表现出等级性-系统要素中，存在子系统，子系统的要素中又包含更低一层的子系统从上至下组成金字塔结构，逐层具体化比如企业组织结构、地区划分结构化方法就是考虑到系统的层次性，采取从抽象到具体、逐步求精的方法对系统进行研究​ 系统的目的性：系统在与环境的相互作用下，在一定范围内，其发展变化表现出坚持趋向某种预先确定的状态。​ 系统的稳定性：外界作用下的开放系统有一定的自我稳定能力，能够在一定范围内自我调节，从而保持和恢复原来的有序状态、原有的结构和功能 ​ 系统的突变性：系统通过失稳从一促状态进入另一种状态的一种剧烈变化过程， 它是系统质变的一种基本形式。​ 系统的自组织性：开放系统在系统内外因素的相互作用下，自发组织起来，使 系统从无序到有序，从低级有序到高级有序。 ​ 系统的相似性：系统具有同构和同态的性质，体现在系统结构、存在方式和演 化过程具有共同性。4.系统思想的发展​ 古代朴素的系统思想 > 系统思想的淹没 > 现代系统思想的兴起 > 复杂系统理论热潮5.系统工程​ 以系统的观点和方法为基础，综合地应用各种技术，分析解决复杂而困难的问题的工程方法。​ 霍尔（A.D.Hall）《系统工程方法论》提出：系统工程方法要把系统工程看作一个过程，一种解决实际问题的程序，包括以下6个方面：问题定义目标选择系统综合系统分析最优系统选择实施计划​ 霍尔三维结构，它以时间维、逻辑维、知识维组成的立体空间结构来概括地表示出系统工程的各阶段、各步骤以及所涉及的知识范围。为解决复杂的系统问题提供了一个统一的思想方法。图显示了该结构基本模型。6.软系统方法论硬系统是指具有良结构化（well-structured）的工程系统，问题和目标是确定的，能用明确的数学模型描述，可以使用定量方法计算出系统行为和最优结果。软系统包括社会经济问题、企业管理问题，由于这些问题中涉及到大量人类活动，使得系统的目标难以界定，评价指标不够清楚，过程也变化不定，因此，应用传统的系统工程方法求解不是最适宜的。切克兰德创立了软系统方法论（soft system methodology，SSM）。软系统方法 vs 硬系统方法软系统方法论詹金斯系统方法兰德式系统分析开始：在一个社会系统中感到有一个难以定义的问题情景，渴望改善这种情景开始：要求解决一个相对良好定义的问题，该问题在很大程度上认为是给定的，只要委托者确定所需要的帮助。 通过考察“结构”、“过程”元素及相互关系表达、改善问题情景的相关系统的暂时定义通过规定系统及其目标、它在系统等级体的位置进行分析考察分析决策者的目标，这些目标以需求表达提出相关系统的根定义，并构造相应的概念模型用定量模型和公式设计系统考察分析决策者的目标，这些目标以需求表达运用形式系统模型及其它系统思想改进概念模型运用确定的演绎标准优化设计选择最好满足需求且可行的系统把概念模型与现实世界中的“是什么”相比较，确定现实世界中合乎需求的、可行的变革没有对应阶段：两种实施方法从一开始就知道需要什么变革 实施获得同意的变革实施设计好的系统 7.物理 - 事理 - 人理系统方法论 （WSR）​ WSR： “物理(Wuli)一事理(Shili)一人理(Renli)方法论” 的简称，是中国著名系统科学专家顾基发教授和朱志昌博士于1994年(20 世纪 90 年代)在英国HULL大学提出的。它既是一种方法论，又是一种解决复杂问题的工具。在观察和分析问题时，尤其是观察分析带复杂特性的系统时，WSR体现其独特性，并具有中国传统的哲学思辨，是多种方法的综合统一；根据具体情况，WSR将方法组群条理化、层次化、起到化繁为简之功效；属于定性与定量分析综合集成的东方系统思想。物理：指涉及物质运动的机理，既包括狭义的物理，又包括化学、生物、天文、地理等等，运用自然科学知识回答“是什么”的问题。事理：指做事的道理，主要解决如何去安排，通常运用运筹学和管理科学的知识回答“怎么去做”的问题。人理：指做人的道理，运用人文与社会科学的知识去回答“应当怎么做”和“最好怎么做”的问题。​ 实践准则：系统实践中需要综合考虑“物理”、“事理”和“人理“三个方面，“懂物理、明事理、通人理”应当是我们的实践准则。​ WSR 的 7 个步骤：1.理解意图 2.指定目标 3.调查分析 4.构造策略 5.选择方案 6.协调关系 7.实现构想。