信息系统分析与设计汇.ppt

信息系统分析与设计 信息管理与信息系统系 孙海 戴伟辉 课程内容特征 与信息工程软件工程区别 现代网络技术环境的影响 与MIS的关系 课程的实践环节 …… 教学目的 培养系统分析员？ 培养系统设计师? 教学方式 课堂教授 小组开发及同步分析 演示 外聘专家讲座 案例分析 本课程的难点 新方法、工具、技术层出不穷，如何适应？ 需求获取难题 设计经验学习 对变化的反应 与系统相关的一些概念 1) 系統分解 ( Decomposition ) 系統分解的例子 : CD walkman 与系统相关的一些概念 2) 模块化 (Modularity): 分解系統 , 以重新设计、组装、复用 3) 耦合(Coupling):系統内单元或模块之间的关联性 高度关連 ( Tightly Coupled ) vs. 低度关連 4) 內聚性(Cohesion): 每一個元件執行單一功能 主要内容 信息系统开发的过程、方法、模型、工具和技术 事物/事件与需求分析 系统分析 系统设计 模型 工具 技术 开发方法阶段划分 事物与系统需求 UML模型 类图 有三个视角：（概念【本质观点】、规格化【接口，type】、实现）。如果你正在分析就画概念模型；在开发软件时专注于规格模型；只有在你要阐明一种特别的实现技术时才采用实现模型。用类图会引来的最大危险是：你很容易就会陷入实现细节的泥潭中不能自拔。要避免这种情况可以用概念或者规格视角。如果你遇到这些问题，那你就会深深体会到CRC卡是非常有用的。 将接口（类型）和实现（类）分开来是很重要的。在你画图的时候，只从一个视角入手；当你看图的时候，注意让自己搞清楚它是从哪个视角出发的。 接口继承（子类型）和实现继承（子类）的区别 状态转移图 描述单个类的不同状态，复杂系统多类则采用交互、活动模型。 瞬间的过程（也就是说不可中断的）可以绑定到转移或或状态的进口或出口那里，这样称为动作（action） 长的（可以被中断）过程被绑定到状态，称为活动。 还可以有并发状态图，让对象有多于一个图去描述其行为。 活动图 活动图着重描述活动和大的过程，它们可能与方法或成员函数及其活动序列相对应，也可能不对应。 领域专家可能会使用活动图作为表达场景的合适工具。例如，如果用户需要描述订单处理工作流，用活动图呢;为了让程序员看得更明白，设计阶段可能要转换成顺序图; 工程师可能喜欢状态图，操作人员喜欢对象流活动图; 现代方法特点 用例驱动 风险驱动 基于迭代 基于体系结构（4＋1） 多view,每个模型代表系统一个方面 IS ‘s view Zichman Traditional view（3） data process logic data flow Data Oriented Process Oriented …. 开发模式 产品开发 配置 实施 项目开发 信息系统功能部件需求光谱 信息系统构建方式 迭代 迭代开发模式 传统上的项目组织是顺序通过每个工作流，每个工作流只有一次，----瀑布生命周期 迭代的增量的软件开发模型 用例 技术并非系统开发中的主要问题。最为重要的是怎样处理需求--- 如何得到正确的需求，以及如何正确的获得需求。系统越大越复杂，需求问题就越成为风险最高的因素。 软件的需求可以分三类：功能需求、非功能需求、设计约束。 通过用例这种需求技术，需求就可以按照“目标－路径－步骤－约束”四个层次组织起来。 用例的核心问题 1）一个用例是一项需求还是只是一个故事？ 2）场景是否只是用例的另一个名字？ 3）用例的结构是正式的、非正式的、还是半正式的？ 4）用例是否有关联结构，还是只是堆在一起？ 第一条也是最重要的一条线索是用例描述了一个actor 试图使用系统达到一个目标。即，如果我们指定其中一个actor 作为主要actor，所有动作都与actor 达到他/她/它自己感兴趣的目标有关。 第二条线索是目标有时会失败。 因此，一个用例的结构分为两部分：每件事都顺利进行时的事件序列，随后是各种目标和子目标失败时的不同小事件序列的描述。 流程 IS 分类 OA 系统本身不包含任何过程知识，尽管处理的信息可能包含业务知识，但系统不对业务知识做任何处理 事务处理系统 DBMS+XML(EDI) 趋势：WFMS(具备过程知识） 知识管理系统 文本搜索、案例推理、数据仓库等（注重知识的获取与分配，这些知识可以被知识工作者及管理者使用），他们处理显式的知识 决策支持系统 人机交互（1、以数学模型为基础；2、基于推理系统（ES) 控制系