1.2 信息系统
mindmap
root((系统工程与信息系统))
1.系统工程
2.信息系统基础
2.1信息系统生命周期
2.2信息系统建设原则
2.2.1结构法方法
2.2.2面相对象方法
2.2.3面相服务方法
2.2.4其他方法
2.2.4.1形式化方法
2.2.4.2统一过程方法UP
2.2.4.3敏捷方法
2.2.4.4基于架构的开发方法
2.3信息系统开发方法
2.4信息系统的分类
3.企业应用集成EAI
4.企业信息化
5.信息系统战略规划
6.新技术信息系统
系统工程在上个世纪中后期发展起来的一门新兴学科。它最早约产生于20世纪40年代的美国,时至今日,系统工程已经成为现代社会高速发展不可或缺的一部分。
信息系统开发方法
- 原型法
结构化方法,面向对象方法,面向服务方法 都属于原型法
- 结构化方法
结构化方法也称为生命周期法,是一种传统的信息系统开发方法,由结构化分析(Structured Analysis, SA)、结构化设计(Structured Design, SD)和结构化程序设计(Structured Programming,SP)三部分有机组合而成,
- 在结构化分析中,主要进行三个方面的建模:功能建模、行为建模和数据建模。功能建模一般采用数据流图DFD,行为建模一般采用状态转换图,数据建模一般采用ER图

- 结构化设计中, NS盒图、HIPO图、程序流程图均属于结构化设计工具;
- N-S盒图在流程图中完全去掉流程线,全部算法写在一个知形阵内,在框内还可以包含其他框的流程图形式。即由一些基本的框组成一个大的框,这种流程图又称为N-S结构流程图(以两个人的名字的头一个字母组成)。N-S图包括顺序、选择和循环三种基本结构。
- HIPO 图由层次结构图和IPO 图两部分构成,层次图描述整个系统的设计结构以及各类模块之间的关系,IPO图描述某个特定模块内部的处理过程和输入输出关系。HIPO 图一般由一张总的层次化模块结构图和若干张具体模块内部展开的IPO 图组成。其精髓是自顶向下、逐步求精和模块化设计。

- 面相对象方法
- 自底向上
- 符合人类思维习惯
面向对象(Object-Oriented, OO)方法认为,客观世界是由各种"对象"组成的,任何事物都是对象,每一个对象都有自己的运动规律和内部状态,都属于某个对象“类”,是该对象类的一个元素。复杂的对象可由相对简单的各种对象以某种方式而构成,不同对象的组合及相互作用就构成了系统。OO方法是当前的主流开发方法,拥有很多不同的分支体系,主要包括OMT (Object Model Technology,对象建模技术)方法、Coad/Yourdon方法、OOSE(Object-Oriented Software Engineering, 面向对象的软件工程)方法和Booch方法等,而OMT、OOSE和Booch已经统一成为UML (United Model Language,统一建模语言)。
- 面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成;
- 设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。
- 面相服务方法
- 粗粒度,松耦合
- 标准化
- 构件化
面向服务的方法SO方法有三个主要的抽象级别,分别是操作、服务和业务流程。位于最低层的操作代表单个逻辑单元的事物,执行操作通常会导致读、写或修改一个或多个持久性数据。服务的操作类似于对象的方法,它们都有特定的结构化接口,并且返回结构化的响应;位于第二层的服务代表操作的逻辑分组;最高层的业务流程则是为了实现特定业务目标而执行的一组长期运行的动作或活动,包括依据一组业务规则按照有序序列执行的一系列操作。其中操作的排序、选择和执行成为服务或流程的编排,典型的情况是调用已编排的服务来响应业务事件。
- 其他方法
4.1 形式化方法
形式化开发方法是应用数学和逻辑的严格技术,以确保软件或系统设计的正确性和一致性。
4.2 统一过程方法(Unified Process, UP)
统一过程方法是一个迭代和增量的软件开发框架,旨在通过结构化的阶段和多个迭代来逐步细化和完善软件产品。
4.3 敏捷方法
4.4 原型化方法
原型化方法也称为快速原型法,或者简称为原型法。它是一种根据用户初步需求,利用系统开发工具,快速地建立一个系统模型展示给用户,在此基础上与用户交流,最终实现用户需求的信息系统快速开发的方法。原型法的优点主要在于能更有效地确认用户需求。从直观上来看,原型法适用于那些需求不明确的系统开发。事实上,对于分析层面难度大、技术层面难度不大的系统,适合于原型法开发;而对于技术层面的困难远大于其分析层面的系统,则不宜用原型法。
4.5 基于架构的开发方法 (Architecture Based Software Development, ABSD)
基于软件架构的设计ABSD强调由商业、质量和功能需求的组合来驱动软件架构设计。 他强调采用 视角 和 视图 来描述软件架构,采用 用例 和 质量属性场景 来描述需求。ABSD方法是一个自顶向下,递归细化的方法,软件系统的体系结构通过该方法得到细化,直到能产生软件构件和类。
基于架构的软件设计ABSD方法有三个基础,分别是对系统进行功能分解、采用架构风格实现质量属性与商业需求、采用软件模板设计软件结构。
ABSD把整个基于架构的软件过程划分为 架构需求、设计、文档化、复审、实现、演化等6个子过程。
绝大部分的架构都是抽象的,由一些概念上的构件组成。 例如,层的概念在任何程序设计语言中都不存在。因此,要让系统分析师和程序员都实现架构,还必须得把架构进行文档化。
文档是在系统眼花的每一个阶段,系统设计与开发人员的通信媒介,是为验证架构设计和提炼 或 修改这些设计 所预先分析的基础。
架构文档化过程的主要输出结果是 架构需求规格说明 和 测试架构需求的质量设计说明书 这两个文档。
生成需求模型构件的精确的形式化的描述,作为用户和开发者之间的一个协约。
在考虑软件架构时,重要的时从不同的视角(perspective)来检查,这促使软件设计师考虑架构的不同属性。
例如,展示功能组织的静态视角能判断质量特性,展示并发行为的动态视角能判断系统行为特性。选择的特定视角或视图也就是逻辑视图,进程视图,实现视图和配置视图。使用逻辑视图来记录设计元素的功能和概念接口,设计元素的功能定义了它本身在系统的角色,这些角色包括功能,性能等。(配置视图=物理视图=部署视图 其实是同一个东西在不同时期的叫法)
自顶向下开发方法的优点是: 1、可为企业或机构的重要决策和任务实现提供信息。 2、支持企业信息系统的整体性规划,并对系统的各子系统的协调和通信提供保证。3、方法的实践有利于提高企业人员整体观察问题的能力,从而有利于寻找到改进企业组织的途径。自顶向下开发方法的缺点是: 1、对系统分析和设计人员的要求较高。 2、开发周期长,系统复杂,一般属于一种高成本、大投资的工程。 3、对于大系统而言自上而下的规划对于下层系统的实施往往缺乏约束力。 4、从经济角度来看,很难说自顶向下的做法在经济上是合算的。
信息系统的分类
- 业务处理系统
- 管理信息系统
- 决策支持系统
商业智能系统的处理过程包括四个主要阶段:
- 数据预处理通过数据抽取、转换和装载实现企业原始数据的初步整合;
- 建立数据仓库是后续数据处理的基础;
- 数据分析是体现系统智能的关键,主要采用联机分析处理OLAP和数据挖掘技术,前者能够实现数据的上卷、下钻和旋转分析,后者利用隐藏的知识,通过建立分析模型预测企业未来发展趋势;
- 数据展现主要完成数据处理结果的可化。
- 专家系统
- 办公自动化系统
- 企业资源计划
Case 论决策支持系统的开发与应用
Question
决策支持系统(Decision Support Systems,DSS)是以管理科学、运筹学、控制论和行为科学为基础,以计算机技术、仿真技术和信息技术为手段,以人机交互方式进行半结构化和非结构化决策的信息系统。它调用各种信息资源,并提供各种分析工具,为决策者提供分析问题、建立模型、模拟决策过程和方案的环境,帮助决策者提高决策水平和质量。决策支持系统在许多领域得到了广泛的应用,己成为许多行业经营管理中一个不可缺少的现代化支持工具。 请围绕“决策支持系统的开发与应用”论题,依次从以下三个方面进行论述。
- 概要叙述你参与管理和开发的决策支持系统项目以及在其中所担任的主要工作。
- 简要叙述决策支持系统包含的典型组成部件及对应的基本功能。说明在建立决策支持系统时需解决的一般关键问题。
- 说明你所参与管理和开发的决策支持系统的应用场合以及对决策结果的要求,具体阐述在开发过程中所采用的关键技术、实施过程和实际应用的效果。
Answer
- 简要叙述所参与管理和开发的决策支持系统项目,并明确指出在其中承担的主要任务和开展的主要工作。
- 决策支持系统包括如下典型组件:
- (1)接口部分,即输入/输出的界面,是人机交互的窗口。
- (2)模型管理子系统,具有存储、动态建模的功能。目前模型管理的实现是通过模型库系统来完成的。
- (3)知识管理子系统,集中管理决策问题领域的知识(规则和事实),包括知识的获取、表达、管理等功能。
- (4)数据管理子系统,DSS的数据库通常包括在数据仓库中。数据仓库是集成的、面向主题的数据库集合。数据仓库通常从内部和外部数据源中抽取。内部数据主要来自于组织的交易处理系统。外部数据包括行业数据、市场调查数据等。
- (5)用户,用户可看作系统的一部分。DSS的用户主要是企业各层次的管理者和商业分析人员。在建立决策支持系统时,主要有以下几个关键问题:
5.1 建立数据仓库系统数据仓库系统必须为决策支持的分析处理提供以下服务:
- (1)根据主题需要,从OLTP数据库中抽取分析用的数据。为此在抽取过程中要对原始数据进行分类、求和、统计等处理,抽取的过程实际上是数据的再组织
- (2)在抽取过程中,完成数据净化,即去掉不合格的原始数据,必要时还必须对缺损的数据加以补充。
- (3)在改变分析决策的主题时,可以按主题进行数据查询和访问。
- (4)采用多级存储模式,解决数据量巨大及按照主题、粒度划分的数据组织问题。
5.2模型、方法和知识管理系统采用数据仓库和多维数据库技术的数据管理子系统将数据进行整理(预处理)和净化之后,形成可靠的易于进行决策的“数据源”(即数据仓库或多维数据库),这个“数据源”的结构与形式和决策支持系统所采用的模型与知识有关。决策粗略地分为结构化决策支持、非结构化决策支持、半结构化决策支持。一个较好的决策支持系统必须完成这三方面的决策支持。模型、方法和知识的管理是决策支持系统的核心,它对依据问题建立的模型库、方法库和知识库进行管理。
- (1)对模型库、方法库和知识库进行维护。模型、方法和知识管理系统必须有对三库的维护界面;可根据问题的需要对模型、方法和知识库进行增加、删除和修改,并保证三库的一致性: 一是系统运行过程调用每个库时不发生矛盾,特别是对知识库的维护更为复杂; 二是每种模型、方法和知识都能调用到。
- (2)模型、方法和知识管理系统根据用户的要求和数据仓库提供的数据,能有效地选择模型、方法和知识,经系统运行得到相应的结果,并将结果送给交互环境进行输出。智能决策支持系统一般是在模型、方法和知识管理系统的基础上增加专家系统和数据采掘与知识发现技术。智能决策支持系统(Intelligence Decision Support System,IDSS)的主要任务包括:
- (1)分析和识别问题;
- (2)描述决策问题和决策知识;
- (3)形成候选的决策方案(目标、规划、方法和途径等);
- (4)构造决策问题的求解模型(如数学模型、运筹学模型、程序模型、经验模型等);
- (5)建立评价决策问题的各种准则(如价值准则、科学准则、效益准则等);
- (6)多方案、多目标、多准则情况下的比较和优化;
- (7)综合分析,包括决策结果或方案对实际问题可能产生的作用和影响的分析,以及各种环境因素、变量对决策方案或结果的影响程序分析等。
5.3)用户交互环境用户交互环境是决策者或决策部门与决策支持系统打交道的界面,它负责接收用户发出的各种命令,根据这些命令调用不同的子系统,并获得处理结果,最后再将这些结果输出给用户。交互环境的好坏直接影响着用户对系统的使用。一个好的交互环境,其输入应当简单、易学、易用。其输出应当做到内容丰富、形式活泼。3.考生需结合自身参与项目的实际状况,指出其参与管理和开发的决策支持系统的应用行业或领域,选择一个关键问题说明其设计、实现的具体过程、方法以及对实际应用效果的分析。
Warning
Urgent info that needs immediate user attention to avoid problems.
软件体系结构
在软件体系结构的建模和描述中,多视图是一种描述软件体系结构的重要途径,其体现了关注点分离的思想。其中, 4 + 1模型师描述软件体系结构的常用型,在该模型中,“1”指的是统一场景
架构风格
- 仓库系统体系结构风格是一种通过共享数据的方式进行构件间通信的架构模式。在这种架构中,中央数据结构是共享数据存储的核心,用于记录和反映当前数据的状态,所有的操作都围绕它进行。
- 黑板架构风格:黑板架构是一种特殊的仓库体系结构,用于支持多种知识源的协作,但更注重动态推理和解决问题的过程,而不是单纯记录数据状态。适合用于设计求解的正确结果不止一个,求解过程比较复杂,需要通过专家知识和反馈逐步得到正确结果的 系统
- 隐式调用风格
- 规则系统根据外部事件进行响应的场景,以自身状态为基础自动进行处理和动作。属于虚拟机架构的一种。
- 解释器业务功能灵活组合,形成新的业务功能,属于自定义类型的业务,需要采用虚拟机架构。解释器结构风格属于虚拟机架构的一种。
架构设计是一个迭代的过程,在建立软件架构的初期,选择一个合适的架构风格是首要的; 在此基础上,开发人员通过架构模型,可以获得关于软件架构属性的理解,为将来的架构实现与演化过程建立目标
架构风格有哪些?
架构模型有哪些?
什么关系?
软件产品从形成概念开始,经过开发、使用和维护,直到最后退役的全过程成为软件生存周期。一个完整的软件生存周期是以需求为出发点,从提出软件开发计划的那一刻开始,直到软件在实际应用中完全报废为止。软件生存周期的提出了是为了更好地管理、维护和升级软件,其中更大的意义在于管理软件开发的步骤和方法。软件生存周期模型又称软件开发模型(software develop model)或软件过程模型(software process model),它是从某个特定角度提出的软件过程的简化描述。软件生存周期模型主要有瀑布模型、演化模型、原型模型、螺旋模型喷泉模型和基于可重用构件的模型等。瀑布模型是最早使用的软件生存周期模型之一。瀑布模型的特点是因果关系紧密相连,前一个阶段工作的结果是后一个阶段工作的输入。或者说,每一个阶段都是建立在前一个阶段的正确结果之上,前一个阶段的错误和疏漏会隐蔽地带入后一个阶段。这种错误有时甚至可能是灾难性的,因此每一个阶段工作完成后,都要进行审查和确认。演化模型主要针对事先不能完整定义需求的软件开发,是在快速开发一个原型的基础上,根据用户在调用原型的过程中提出的反馈意见和建议,对原型进行改进,获得原型的新版本,重复这一过程,直到演化成最终的软件产品。演化模型的主要优点是,任何功能一经开发就能进入测试,以便验证是否符合产品需求,可以帮助引导出高质量的产品要求。其主要缺点是,如果不控制地让用户接触开发中尚未稳定的功能,可能对开发人员及用户都会产生负面的影响。
