系统架构图 入门（什么是架构）

本文目录

• 什么是架构
• 编写软件架构文档说明，第 1 部分: 什么是软件架构，为什么为软件架构编写文档说明非常重要
• 产品入门，如何绘制产品功能结构图和产品信息结构图
• 如何做一个管理系统

什么是架构

　　企业架构就是企业对组织工作任务进行分工、分组和协调合作。各类组织架构如下：
　　直线制 直线制是一种最早也是最简单的组织形式。它的特点是企业各级行政单位从上到下实行垂直领导，下属部门只接受一个上级的指令，各级主管负责人对所属单位的一切问题负责。厂部不另设职能机构（可设职能人员协助主管人工作），一切管理职能基本上都由行政主管自己执行。直线制组织结构的优点是：结构比较简单，责任分明，命令统一。缺点是：它要求行政负责人通晓多种知识和技能，亲自处理各种业务。这在业务比较复杂、企业规模比较大的情况下，把所有管理职能都集中到最高主管一人身上，显然是难以胜任的。因此，直线制只适用于规模较小，生产技术比较简单的企业，对生产技术和经营管理比较复杂的企业并不适宜。 职能结构 职能制组织结构，是各级行政单位除主管负责人外，还相应地设立一些职能机构。如在厂长下面设立职能机构和人员，协助厂长从事职能管理工作。这种结构要求行政主管把相应的管理职责和权力交给相关的职能机构，各职能机构就有权在自己业务范围内向下级行政单位发号施令。因此，下级行政负责人除了接受上级行政主管人指挥外，还必须接受上级各职能机构的领导。 职能制的优点是能适应现代化工业企业生产技术比较复杂，管理工作比较精细的特点；能充分发挥职能机构的专业管理作用，减轻直线领导人员的工作负担.但缺点也很明显：它妨碍了必要的集中领导和统一指挥，形成了多头领导；不利于建立和健全各级行政负责人和职能科室的责任制，在中间管理层往往会出现有功大家抢，有过大家推的现象；另外，在上级行政领导和职能机构的指导和命令发生矛盾时，下级就无所适从，影响工作的正常进行，容易造成纪律松弛，生产管理秩序混乱。由于这种组织结构形式的明显的缺陷，现代企业一般都不采用职能制。 直线－职能制 直线－职能制，也叫生产区域制，或直线参谋制。它是在直线制和职能制的基础上，取长补短，吸取这两种形式的优点而建立起来的。目前，我们绝大多数企业都采用这种组织结构形式。这种组织结构形式是把企业管理机构和人员分为两类，一类是直线领导机构和人员，按命令统一原则对各级组织行使指挥权；另一类是职能机构和人员，按专业化原则，从事组织的各项职能管理工作。直线领导机构和人员在自己的职责范围内有一定的决定权和对所属下级的指挥权，并对自己部门的工作负全部责任。而职能机构和人员，则是直线指挥人员的参谋，不能对直接部门发号施令，只能进行业务指导。 直线－职能制的优点是：既保证了企业管理体系的集中统一，又可以在各级行政负责人的领导下，充分发挥各专业管理机构的作用。其缺点是：职能部门之间的协作和配合性较差，职能部门的许多工作要直接向上层领导报告请示才能处理，这一方面加重了上层领导的工作负担；另一方面也造成办事效率低。为了克服这些缺点，可以设立各种综合委员会，或建立各种会议制度，以协调各方面的工作，起到沟通作用，帮助高层领导出谋划策。 事业部制 事业部制最早是由美国通用汽车公司总裁斯隆于1924年提出的，故有“斯隆模型”之称，也叫“联邦分权化”，是一种高度（层）集权下的分权管理体制。它适用于规模庞大，品种繁多，技术复杂的大型企业，是国外较大的联合公司所采用的一种组织形式，近几年我国一些大型企业集团或公司也引进了这种组织结构形式。? 事业部制是分级管理 、分级核算、自负盈亏的一种形式，即一个公司按地区或按产品类别分成若干个事业部，从产品的设计，原料采购，成本核算，产品制造，一直到产品销售，均由事业部及所属工厂负责，实行单独核算，独立经营，公司总部只保留人事决策，预算控制和监督大权，并通过利润等指标对事业部进行控制。也有的事业部只负责指挥和组织生产，不负责采购和销售，实行生产和供销分立，但这种事业部正在被产品事业部所取代。还有的事业部则按区域来划分。 模拟分权制 这是一种介于直线职能制和事业部制之间的结构形式。 许多大型企业，如连续生产的钢铁、化工企业由于产品品种或生产工艺过程所限，难以分解成几个独立的事业部。又由于企业的规模庞大，以致高层管理者感到采用其他组织形态都不容易管理，这时就出现了模拟分权组织结构形式。所谓模拟，就是要模拟事业部制的独立经营，单独核算，而不是真正的事业部，实际上是一个个“生产单位”。这些生产单位有自己的职能机构，享有尽可能大的自主权，负有“模拟性”的盈亏责任，目的是要调动他们的生产经营积极性，达到改善企业生产经营管理的目的。需要指出的是，各生产单位由于生产上的连续性，很难将它们截然分开，就以连续生产的石油化工为例，甲单位生产出来的"产品"直接就成为乙生产单位的原料，这当中无需停顿和中转。因此，它们之间的经济核算，只能依据企业内部的价格，而不是市场价格，也就是说这些生产单位没有自己独立的外部市场，这也是与事业部的差别所在。 模拟分权制的优点除了调动各生产单位的积极性外，就是解决企业规模过大不易管理的问题。高层管理人员将部分权力分给生产单位，减少了自己的行政事务，从而把精力集中到战略问题上来。其缺点是，不易为模拟的生产单位明确任务，造成考核上的困难；各生产单位领导人不易了解企业的全貌，在信息沟通和决策权力方面也存在着明显的缺陷。 矩阵制 在组织结构上，把既有按职能划分的垂直领导系统，又有按产品（项目）划分的横向领导关系的结构，称为矩阵组织结构。 矩阵制组织是为了改进直线职能制横向联系差，缺乏弹性的缺点而形成的一种组织形式。它的特点表现在围绕某项专门任务成立跨职能部门的专门机构上，例如组成一个专门的产品（项目）小组去从事新产品开发工作，在研究、设计、试验、制造各个不同阶段，由有关部门派人参加，力图做到条块结合，以协调有关部门的活动，保证任务的完成。这种组织结构形式是固定的，人员却是变动的，需要谁，谁就来，任务完成后就可以离开。项目小组和负责人也是临时组织和委任的。任务完成后就解散，有关人员回原单位工作。因此，这种组织结构非常适用于横向协作和攻关项目。 矩阵结构的优点是：机动、灵活，可随项目的开发与结束进行组织或解散；由于这种结构是根据项目组织的，任务清楚，目的明确，各方面有专长的人都是有备而来。因此在新的工作小组里，能沟通、融合，能把自己的工作同整体工作联系在一起，为攻克难关，解决问题而献计献策，由于从各方面抽调来的人员有信任感、荣誉感，使他们增加了责任感，激发了工作热情，促进了项目的实现；它还加强了不同部门之间的配合和信息交流，克服了直线职能结构中各部门互相脱节的现象。 矩阵结构的缺点是：项目负责人的责任大于权力，因为参加项目的人员都来自不同部门，隶属关系仍在原单位，只是为"会战"而来，所以项目负责人对他们管理困难，没有足够的激励手段与惩治手段，这种人员上的双重管理是矩阵结构的先天缺陷；由于项目组成人员来自各个职能部门，当任务完成以后，仍要回原单位，因而容易产生临时观念，对工作有一定影响。? 矩阵结构适用于一些重大攻关项目。企业可用来完成涉及面广的、临时性的、复杂的重大工程项目或管理改革任务。特别适用于以开发与实验为主的单位，例如科学研究，尤其是应用性研究单位等。
　　扁平式结构
　　由彼得圣吉五项修炼的基础上，通过大量的个人学习特别是团队学习，形成的一种能够认识环境、适应环境、进而能够能动的作用于环境的有效组织。 也可以说是通过培养弥漫于整个组织的学习气氛，充分发挥员工的创造性思维能力而建立起来的一种有机的、高度柔性的、扁平的、符合人性的、能持续发展的组织。学习型组织为扁平化的圆锥型组织结构，金字塔式的棱角和等级没有了，管理者与被管理者的界限变得不再清晰，权力分层和等级差别的弱化，使个人或部门在一定程度上有了相对自由的空间，能有效地解决企业内部沟通的问题，因而学习型组织使企业面对市场的变化，不再是机械的和僵化的，而是“动”了起来。不过，随着全球经济一体化和社会分工的趋势化，扁平化组织也会遇到越来越多的问题，在不断的分析问题、解决问题的过程当中，学习型组织“学习”的本质对人的要求将越来越高。
　　智慧型结构
　　也称为C管理模式。《C管理模式》的理论价值：许多初读《C管理模式》的专家和学者则认为，C管理模式立足道、儒、法的中国传统文化，将西方现代企业管理学与中国国学及中医智慧融于一体，其理论结合人的身体机能，提出了“天人合一”、“道法自然”的经营理念和管理哲学。《C管理模式》的政治价值：2009年以来，全球金融风暴持续蔓延，一大批欧美企业纷纷陷入破产倒闭的危机，与此同时，国内企业也愈加感受到全球性经济萧条带来的股股寒意。在此轮国际经济危机中，一些我们曾经耳熟能详、顶礼膜拜的全球知名企业，在一夜之间如巨人般轰然倒下，在剧烈的震撼中，国内众多专家、学者和企业界纷纷对西方现代企业管理模式进行了深刻的反思。C管理模式研究的课题，将引发对资本主义完全的自由市场经济的反思，对现行企业管理模式的反思，并将重新聚焦世界对中国特色社会主义市场经济模式的更多思考，这正是C模式模式的价值所在。

编写软件架构文档说明，第 1 部分: 什么是软件架构，为什么为软件架构编写文档说明非常重要

引言 软件架构是一门学科，开始于 20 世纪 70 年代。面对不断增加的复杂性和开发复杂实时系统的压力，作为主流系统工程和软件开发的基本构造，软件架构应运而生。 与任何其他久经考验的学科一样，软件架构在诞生之初也面临许多挑战。软件架构表示系统的结构和行为方面。在早期为软件架构编写文档说明时，所使用的文本和图解表达常常不足或者不够精确。所需的是某种一致并得到充分理解的伪（或元）语言，以便将对软件架构进行表示和编写文档说明的不同方式统一起来。在学术研究的推动下，在用于开发有效软件架构文档说明的最佳实践和指导原则方面，工程和计算机科学领域已取得了长足的发展。 在本系列中，您将了解如何编写软件架构文档说明。了解编写文档说明的不同方面：系统上下文、体系结构概述、功能体系结构、操作体系结构和体系结构决策。 在这第一篇文章中，了解软件架构是什么，以及为该学科的不同方面编写文档说明的重要性。 回页首软件架构不同的研究人员已解释了软件架构是什么，并且他们对有关如何最好地表示软件系统的体系结构具有不同的观点。其中没有哪一种解释是错误的；每种解释都具有自己的价值。Bass L 等人抓住了软件架构的本质： “程序或计算系统的软件架构是该系统的结构，包括软件组件、那些组件的外部可见的属性，以及那些组件之间的关系” 。 此定义重点关注由粗粒度的构造（软件组件）所构成的体系结构，可以将这些构造看作是体系结构的构建块。每个软件组件或体系结构构建块具有某些外部可见的属性，这是它向其他体系结构构建块公开的属性。软件组件的内部设计和实现细节不是系统的其他部分所关心的内容，系统的其他部分只是将某个特定组件视为一个黑盒。该黑盒具有某些所公开的属性，其他软件组件可以使用这些属性来共同实现业务或 IT 目标。软件架构在恰当的粒度级别标识体系结构构建块。软件架构还标识那些构建块如何彼此相关，并进行文档记录。 与软件工程相关的体系结构涉及到将单个系统分解或划分为一组可迭代地、渐进地和独立地构造的部分。各个部分彼此具有显式的关系。当组合在一起时，各个部分就形成了系统、企业或应用程序的体系结构。 关于体系结构与设计之间的区别，存在一些混淆。正如 Clements P 等人 所指出的，所有体系结构都是设计，但不是所有设计都是体系结构。需要绑定以使系统满足其功能性和非功能性需求和目标的设计本质上是体系结构。体系结构将体系结构构建块视为黑盒，而设计则处理体系结构构建块的配置、自定义和内部工作。体系结构将软件组件与其外部属性绑定在一起。设计通常要比体系结构松散得多，因为它允许以更多的方式遵守组件的外部属性。设计还考虑用于实现组件内部细节的各种方法。 软件架构可以递归地使用。请考虑一个属于某个系统的软件架构组成部分的软件组件 (C1)。软件架构师将该组件及其应该公开的属性、功能和非功能特性及其与其他软件组件的关系交给系统设计人员。设计人员在分析软件组件 C1 之后，决定将该组件分解为更细粒度的组件（C11、C12 和 C13），其中每个组件提供可重用的功能，这些功能将用于实现 C1 的要求属性。设计人员详细设计了 C11、C12、C13 及其接口。此时，对设计人员来说，C11、C12 和 C13 是体系结构构造（或组件）；其中每个构造具有显式定义的外部接口。对设计人员来说，C11、C12 和 C13 是软件组件 C1 的体系结构，并且这些构造需要进一步的改进和设计，以处理它们的内部实现。通过将大型、复杂的系统划分为小型的构成部分并集中于每个部分，可以递归地使用体系结构。 体系结构使用共同满足行为和质量目标的体系结构构建块将系统绑定在一起。参与者必须能够理解体系结构。因此必须为体系结构编写足够的文档说明，下一个部分将对此进行讨论。 回页首编写体系结构文档说明的重要性参与者：体系结构的下游设计和实现用户。为体系结构的定义、维护和增强功能进行投资的人。向参与者传达您正在构建的系统蓝图的关键是为系统体系结构编写文档说明。软件架构通过不同的视图进行表示——功能、操作、决策等等。没有任何单一视图能够表示整个体系结构。并非所有视图都需要表示特定企业或问题领域的系统体系结构。架构师将确定足以表示所需软件架构范畴的视图集。通过编写不同视图的文档说明并捕获每个部分的开发，您可以向开发团队和业务及 IT 参与者传达有关该不断发展的系统的信息。软件架构具有一组其预期要满足的业务和工程目标。体系结构的文档说明可以向参与者传达这些目标将如何实现。 为体系结构的各个方面编写文档说明，有助于架构师弥补用白板描述解决方案（使用框线图方法）与以对下游设计和实现团队有意义的方式表示解决方案之间众所周知的差距。体系结构的框线图留下了大量有待解释的空间。需要揭示的细节通常隐藏并令人混淆地固守在那些框线背后。 文档说明还可以促进创建切合实际并且可以系统开发（例如遵循标准模板）的体系结构构件。作为一门学科，软件架构是非常成熟的。您可以利用最佳实践和指导原则来为每种视图创建标准模板，以表示体系结构的某个部分或范畴。模板可以为架构师提供有关需要实际产生什么结果的训练。并且模板还可以帮助架构师执行强化训练——超越框线图技术。模板以更具体的术语定义体系结构，因此可直接追溯到解决方案预期要满足的业务和 IT 目标。 由于复杂性，典型的系统开发活动可能要花 18 个月左右的时间。人员缩减在设计和开发团队是司空见惯的事情，从而导致疯狂寻找恰当的替换人员。新的团队成员通常阻碍进度，因为他们必须经历一个学习过程才能成为高效的参与者。具有良好文档说明构件的软件架构可以提供： 对新团队成员进行有关解决方案需求教育的完美平台。有关解决方案如何满足业务和工程目标的说明。特定于问题领域的各种解决方案体系结构视图。对个人将处理的视图的重点关注。请考虑一个名为“体系结构决策”的假想构件（后续部分还将对此进行讨论）。此构件确定要解决的问题，并评估备选机制以解决该问题。此构件对为什么选择某种备选机制而不选择其他机制提供了论证。所确定的问题涉及到访问大型机 IBM DB2�0�3 表的机制。对两种备选机制进行了评估：使用 IBM MQSeries�0�3，或者使用 NEON Shadow Direct 适配器（一种供应商适配器）。尽管 MQSeries 具备相关功能并且花费较少，但是后者要稳定得多，并且在制定决策时，后者具有一定的优势。现在设想原架构师在一年后离开了该项目，新的架构师粉墨登场。新的架构师质问该团队为什么不使用 IBM MQSeries 来访问大型机 DB2 表。该团队很快返回到体系结构决策构件，并指出了做出该选择的原因。由于 IBM MQSeries 已在过去一年中经测试证明与另一个解决方案不相上下，并且由于其价格较低，于是对该决策进行了重新审视并做出更改以反映更新后的解决方案。 这个示例说明了为什么对系统软件架构的各个方面编写文档说明，是教育新团队成员和在最少的停机情况下帮助他们入门所必需的。 回页首体系结构的不同视图您已经了解到可以通过不同的视图来表示体系结构，每种视图集中于该体系结构的特定方面或范畴。正如 Bass L 等人 所指出的，视图 是由系统参与者编写和读取的体系结构元素或构造以及它们之间关系的内聚集合。 体系结构的功能 视图描述各个体系结构构建块、构建块之间的关系，以及如何将它们分配到体系结构中的不同层。操作 视图（也称为技术视图）描述各个基础结构和中间件软件组件，这些组件为将要部署的功能体系结构组件提供运行时平台。对应用程序架构师而言，功能视图具有第一位的重要性。对基础结构架构师而言，操作视图是要重点关注的视图。 这两种视图采用不同的方法解决相同的问题，两种视图都需要从概念体系结构推进到物理实现。视图用于强调特定的体系结构范畴，同时有意地抑制其他范畴。 自从20 世纪 90 年代以来，已经存在许多不同的视图集。Perry 和 Wolf 提出，关于构建具有多种视图的体系结构（包括软件架构），存在一些非常有趣的要点。发表软件架构的 4 + 1 视图的 Kruchten 认为存在五种视图，这些视图组合起来可以表示软件架构。下面将描述前四种视图。 视图描述逻辑视图处理静态设计模型流程视图处理设计的动态视图物理视图处理如何将软件组件映射到硬件基础设施开发视图表示软件组件在开发时环境中的静态组织 第五种视图更多的是一种 Litmus Test 视图。它采用一组在体系结构上非常重要的用例（业务场景），并说明如何将四种视图的每一种视图中的体系结构元素集与针对那些元素的体系结构约束和决策结合起来，用于实现那些用例。 由Soni 等人 在Applied Software Architecture 中发表的另一种视图由四种构成软件架构的主要视图组成：视图描述概念体系结构视图从主要设计元素及元素间的关系方面描述系统模块互连体系结构视图描述功能分解和如何在不同的层中安排软件模块执行体系结构视图描述系统的动态结构代码体系结构视图描述如何在开发环境中组织源代码、二进制文件和库 软件架构出版物中描述了许多其他视图，但是介绍所有这些视图超出了本文的范围。对软件架构的不同视图进行仔细分析后表明，不同的研究结果之间存在大量的相似性。我们拥有一个最常用于表示系统软件架构的最优视图集合。 下一个部分将提供一些构件的概述，建议将这些构件用作可在软件开发生命周期的体系结构阶段生成的体系结构文档的最小集。 回页首文档说明对象 可以对软件架构的许多不同视图或方面做文档说明。对于任何中大型软件开发项目，建议您至少为以下体系结构构件集编写文档说明：系统上下文系统上下文对表示为黑盒的整个系统如何与外部实体（系统和最终用户）交互做文档说明。它还定义系统与外部实体之间的信息和控制流。系统上下文用于对系统所在的操作环境进行澄清、确认和编写文档说明。外部系统的性质、其接口以及信息和控制流对体系结构中的技术构件的下游规范有帮助。体系结构概述体系结构概述通过简单的图示表示形式说明体系结构中的主要概念元素和关系。您可以产生包括企业视图和 IT 系统视图的体系结构概述关系图。概述帮助表示组织所需要的业务和 IT 功能。功能体系结构从以下方面描述 IT 系统的结构：IT 系统的软件组件的职责、接口、静态关系和协作来交付组件所需功能的方式。此构件在各个细化阶段中迭代地进行开发。操作体系结构操作体系结构构件表示计算机系统的网络，这些系统支持解决方案的某些性能、可伸缩性和容错等需求。此构件还运行中间件、系统软件和应用程序软件组件。此构件在各个细化阶段中迭代地进行开发。体系结构决策体系结构决策构件提供了对所有在体系结构上相关的决策编写文档说明的单一位置。决策通常涉及到但不限于： 系统的结构。标识中间件组件以支持集成需求。将功能分配到每个体系结构组件（体系结构构建块）。将体系结构构建块分配到体系结构中的各个层。遵守标准。选择技术以实现特定的体系结构构建块或功能组件。 对任何视为在体系结构上与满足业务和工程目标相关的决策编写文档说明。文档说明通常包括： 问题的确定。各种解决方案的评估，包括优点和缺点。选定的解决方案，包括足够的论证和其他将对下游设计和实现有帮助的相关详细信息。 本系列的其余部分将讨论如何对软件架构中的这五个构件编写文档说明。 回页首结束语 软件架构已经存在 30 多年了。过去几十年已见证了软件工程方面的大量工作。软件架构师在设计满足企业的业务、工程和 IT 目标的解决方案中起着中流砥柱的作用。为软件架构编写文档说明是极其重要的。您可以使用文档说明，就某个正在发展的系统与参与者进行交流。文档说明对于使新的团队成员迅速投入工作也是非常有用的，因为新的团队成员可以在实现解决方案时使用体系结构透视图作为上下文和边界前提。 关于什么在性质上是体系结构，什么在性质上不是体系结构，以及应该对系统的哪些方面做文档说明，一直存在大量的混淆。体系结构模板定义并标准化每种类型的构件中的内容，支持采用一致的方法来对软件架构编写文档说明。 在本文中，您了解了作为一门学科的软件架构，并了解了对体系结构的基本元素编写文档说明的重要性。您还阅读了建议作为文档说明最小集的体系结构构件的概述。请继续关注本系列的其他文章，它们将详述如何使用一组指导原则，以及如何对每个构件编写文档说明。参考资料 学习您可以参阅本文在 developerWorks 全球网站上的 英文原文。阅读已发布的软件架构定义的纲要。D. Perry 和 A. Wolf 撰写的“Foundations for the Study of Software Architecture”是关于软件架构的经典文章。阅读P. Kruchten 撰写的“Architectural Blueprints - The "4+1" View Model of Software Architecture”。Applied Software Architecture 提供了用于产生高质量软件设计的实用指导原则和技术。在developerWorks 的 Architecture 架构专区中，获取用以提高您在体系结构方面的技能的各种资源。浏览技术书店，以了解有关这些技术主题及其他技术主题的相关书籍。讨论参与论坛讨论。访问developerWorks Blog，从而加入到 developerWorks 社区中来。关于作者Tilak Mitra 是 IBM 的一名高级认证执行 IT 架构师。他擅长 SOA，在 SOA 的业务策略和方向方面为 IBM 提供帮助。他还是一位 SOA 主题专家，帮助客户进行基于 SOA 的业务转换，并重点关注复杂和大型的企业架构。他目前的工作重点是围绕组合业务服务（Composite Business Services，CBS）构建可重用的资产，这些资产能够在多种平台上运行，例如 IBM、SAP 等的 SOA 堆栈。他生活在阳光明媚的南佛罗里达，闲暇时，他非常喜欢参加板球和乒乓球活动。Tilak 在印度加尔各答的 Presidency 学院获得了物理学学士学位，并且已经在班加罗尔的印度科学学院获得了电子工程学学士和硕士学位。访问 Tilak 的 blog，了解关于 SOA 的更多信息。您可以在 LinkedIn 上查看 Tilak Mitra 的个人简介。 关闭请选择您的昵称：当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。昵称：（长度在 3 至 31 个字符之间）单击提交则表示您同意developerWorks 的条款和条件。 使用条款. 所有提交的信息确保安全。为本文评分评论回页首

产品入门，如何绘制产品功能结构图和产品信息结构图

下面是笔者通过实践和资料整理对这两个结构图进行定义区分，并辅以实际demo分析阐释：

一般在实际工作中，一个产品需求从创意、构想到最终输出给设计、开发，不一定会用到这两种图，视情况选择使用。如要有要求先输出产品方案时，还是建议绘制“产品功能结构图”和“产品信息结构图”，方便直观地让开发人员了解该产品的架构，同时自己参照结构图绘制产品原型时也避免模块和功能的遗漏。

一、产品功能结构图

作用 ：梳理产品架构功能点。

说明 ：我们绘制产品功能结构图一般是在原型绘制前，所以大多不以页面为模块去罗列，而是以功能划分模块，以产品的主要功能及其他围绕主要功能而展开的下级功能点进行罗列。

一般做竞品分析时会倒推已经成型的产品来练手，此时需要反复使用软件，列出其主要功能，涉及的功能细节需要不断测试得出。

在自己构想一个新的产品时，也需要大量使用同类或者有借鉴意义的产品，在绘制功能结构图的过程要结合过往或者同类产品经验罗列功能模块、细化功能点。

功能和信息的概念有时比较模糊，如果想要更清晰的让自己的表达更清晰可以采用“动词+名词”的形式对功能点命名，比如：登录/注册账号；查看/取消收藏等。

操作过程 ：

我们在绘制功能结构图之前，要先梳理主要功能逻辑，下面是笔者参照B站功能模块拆解的主要功能：
在主要功能的基础上添加下级功能和细节点，产品功能结构图就绘制出来啦！

如下图：
二、产品信息结构图

作用： 梳理系统页面的模块功能显示信息，是绘制原型的基础，信息结构图类似数据表结构设计，揭示了需要哪些数据，这些数据需要有怎样的元素组成，才能达到每个功能模块需要展现的内容表达。如果说功能结构图是产品的功能抽象，那么信息结构图则是产品的数据抽象。

说明： 产品信息结构图罗列了产品需要的信息字段，是在我们绘制原型前构想如何布局页面信息的依据。在C端产品中对产品信息页尤其重要，为避免原型绘制时遗漏，此时需要绘制产品信息结构图穷尽页面内容。信息结构图中同一个对象的信息出现在多个页面是非常常见的事情。

例如个人简历，在招聘官使用招聘网站时，姓名、性别、年龄、职位、工作时间等关键信息既会出现在候选人的列表页，也会出现在候选人的详情页，还会出现在搜索结果页等等。

操作过程 ：

结合功能点，对设想的功能进行主页面布局。
根据需求调研、竞品调研报告、结合自己的产品经验确定具体功能模块布局:
总结 ：

1.功能结构图，关键词是功能，是功能的结构化表达；

2.信息结构图，关键词是信息，是信息的结构化表达；

互动作的细节不用体现在产品功能结构图和产品信息架构图中，比如页面布局细节、交互手势、动画效果等，属于交互设计的范畴。

绘制产品结构图时，你就要想象这是你产品的最终形态，每个页面要有哪些功能和数据，类似于开发做的不同静态页面，展现在你面前的就是产品的雏形了。

如何做一个管理系统

不知道你是要做，还是要知道怎么做。
其实这个东西就是走流程的，都有一定的规范。我回答后一种情况，前一种情况，可以再聊。
首先要确定用户需求，做一定的调查和交流工作。
1、系统分析，对系统需求的分析，老系统的分析，以及客户新需求的分析，运行环境的分析和可行性分析等。
2、系统设计，对系统的功能模块、数据存储等进行设计，设计是为了以后开发系统时，能够开发出用户满意的系统。
3、系统实施，就是程序员干的事了，选择正确的语言，然后进行界面搭建和代码编写，把功能实现就好了。
4、系统测试，编写测试用例，保证各个功能都能正确运行。
5、系统转换，就是把你做好的管理系统，拿到客户那里运行，并做一定的修改，为客户配置运行环境，最后的转换要根据客户的情况进行，比如客户老系统和新系统并行，直接使用新系统等等。
至于你如果想开发一个管理系统的话，也不一定要这么麻烦，就是你只要掌握一定的编程能力，然后根据用户需求实现功能就行了。
至于更专业的东西，可以去看看系统分析与设计，UML或者国外的SYSTEM ANAlYSIS。编程那就很多了，不多说了。