软件工程 架构图 软件工程 系统架构图

发布日期：2020-08-18

关于软件工程结构问题

原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来.维护活动包括使用过程中的扩充、修改与完善.伴随以上过程、培训过程等.问题分析获取需求定义，又称软件需求规约.开销合宜是指软件开发、运行的整个开销满足用户要求的程度，包括子系统、实现及文档为用户可用的程度、过程模型及工程方法选取的约束.（2）软件工程过程：生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤.软件工程过程主要包括开发过程、设计、实现、运作过程、维护过程.采用工程的概念，还有管理过程、支持过程软件工程是指导计算机软件开发和维护的工程学科.需求活动包括问题分析和需求分析.它们覆盖了需求.软件工程（SoftWareEngineering）的框架可概括为：目标.详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述、过程和原则、确认以及维护等活动、每一模块的接口定义.这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题，它们形成了对过程.（1）软件工程目标：生产具有正确性、可用性以及开销合宜的产品.正确性指软件产品达到预期功能的程度.可用性指软件基本结构、模块以及相关层次的说明.需求分析生成功能规约.设计活动一般包括概要设计和详细设计.概要设计建立整个软件系统结构.实现活动把设计结果转换为可执行的程序代码.确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求，这就是软件工程 展开

软件工程架构是怎样的？

不得不说的就是规范性的东西，我认为规范是个很重要的东西，当然，规范不只是说大家统一用某种形式命名变量，方法等等，这只是对程序员而言的规范，如果这个划做横向规范的话，那么纵向规范就是面对客户的规范。

对程序员的规范，我不想多说了，注释，变量，方法，文档。

当然未必每个人都做到了这些。

我想说的是对客户的规范问题。

对客户的规范有很多中，比如小细节CS系统中的Ancho怎么设置，Dock怎么设置，如何让页面看起来更加让用户舒心，如何做焦点设置。

大到如何给客户做培训，如何防止用户看到不友好页面，如何简化用户操作等等，这些都是属于规范性范畴。

对于焦点设置，我有深刻体会，前段时间找工作，某网站输入搜索条件以后，按钮回车老是达不到焦点上去，非要我去移下鼠标点击，很不爽。

第一点，对于一个完善的架构，日志处理机制是必须做好的，日志处理不只是简单的说输出完成这么简单。

首先，必须要通过配置控制在什么时候输出，在什么地方输出，如何输出，怎么记录，是记录数据库还是日志文件中。

如何灵活让用户控制日志输出方式。

第二点，对于一个完善的架构，异常处理机制也是一个重点。

异常怎么处理，如何记录，是记录到系统中，还是异常文件，还是数据库异常表，或者发给技术部邮件等等，如何做异常记录，在产生异常以后更容易让用户，技术人员看到异常产生的原因，这个是一个比较重要的模块。

第三点，对于一个完善的架构，配置文件是必须的，有些项目只是简单的对we.confg里加些配置，我认为这根本不够完善，对于配置而言，有很多需要配置的内容，比如系统连接哪种数据库，客户信息，再比如是否记录日志，异常等，是否允许用户注册等等灵活功能的控制完全可以在配置中实现。

第四点，对于一个完善的架构，如何做好权限是很重要的一块内容，比如权限如何控制，怎么处理用户，组，模块，部门等等之间的关系，工作流如何做，如何让权限与工作流做良好匹配，比如某审批人员出差了，如何处理其审批流程等等，虽然这点，我自己也在不断研究，但我想这一块非常重要。

第五点，对于一个完善的架构，流水号生成功能也相当重要，任何一种系统，不管是信息管理系统还是电子商务平台，一定都会要求按一定格式生成某套流水号，流水号也必须有灵活性，这点非常重要。

系统架构图怎么画

一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。

具体地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。

所谓架构元素，也就是组成系统的核心＂砖瓦＂，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。

·建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。

在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行具体设计甚至建造，这些决定就很难更改甚至无法更改。

显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。

计算机软件的历史开始于五十年代，历史非常短暂，而相比之下建筑工程则从石器时代就开始了，人类在几千年的建筑设计实践中积累了大量的经验和教训。

建筑设计基本上包含两点，一是建筑风格，二是建筑模式。

独特的建筑风格和恰当选择的建筑模式，可以使一个独一无二。

下面的照片显示了中美洲古代玛雅建筑，Chichen-Itza大金字塔，九个巨大的石级堆垒而上，九十一级台阶（象征着四季的天数）夺路而出，塔顶的神殿耸入云天。

所有的数字都如日历般严谨，风格雄浑。

难以想象这是石器时代的建筑物。

图1、位于墨西哥Chichen-Itza（在玛雅语中chi意为嘴chen意为井）的古玛雅建筑。

（摄影：作者）软件与人类的关系是架构师必须面对的核心问题，也是自从软件进入历史舞台之后就出现的问题。

与此类似地，自从有了建筑以来，建筑与人类的关系就一直是建筑设计师必须面对的核心问题。

英国首相丘吉尔说，我们构造建筑物，然后建筑物构造我们（We shape our buildings, and afterwards our buildings shape us）。

英国下议院的会议厅较狭窄，无法使所有的下议院议员面向同一个方向入座，而必须分成两侧入座。

丘吉尔认为，议员们入座的时候自然会选择与自己政见相同的人同时入座，而这就是英国政党制的起源。

Party这个词的原意就是＂方＂、＂面＂。

政党起源的要害就是建筑物对人的影响。

在软件设计界曾经有很多人认为功能是最为重要的，形式必须服从功能。

与此类似地，在建筑学界，现代主义建筑流派的开创人之一Louis Sullivan也认为形式应当服从于功能（Forms follows function）。

几乎所有的软件设计理念都可以在浩如烟海的建筑学历史中找到更为遥远的历史回响。

最为闻名的，当然就是模式理论和XP理论。

架构的目标是什么正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？一般而言，软件架构设计要达到如下的目标：·可靠性（Reliable）。

软件系统对于用户的商业经营和治理来说极为重要，因此软件系统必须非常可靠。

·安全行（Secure）。

软件系统所承担的交易的商业价值极高，系统的安全性非常重要。

·可扩展性（Scalable）。

软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。

只有这样，才能适应用户的市场扩展得可能性。

·可定制化（Customizable）。

同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。

·可扩展性（Extensible）。

在新技术出现的时候，一个软件系统应当答应导入新技术，从而对现有系统进行功能和性能的扩展·可维护性（Maintainable）。

软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。

一个易于维护的系统可以有效地降低技术支持的花费·客户体验（Customer Experience）。

软件系统必须易于使用。

·市场时机（Time to Market）。

软件用户要面临同业竞争，软件提供商也要面临同业竞争。

以最快的速度争夺市场先机非常重要。

架构的种类根据我们关注的角度不同，可以将架构分成三种：·逻辑架构、软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等。

比如下面就是笔者亲身经历过的一个软件系统的逻辑架构图 图2、一个逻辑架构的例子从上面这张图中可以看出，此系统被划分成三个逻辑层次，即表象层次，商业层次和数据持久层次。

每一个层次都含有多个逻辑元件。

比如WEB服务器层次中有Html服务元件、session服务元件、安全服务元件、系统治理元件等。

·物理架构、软件元件是怎样放到硬件上的。

比如下面这张物理架构图描述了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。

图3、一个物理架构的例子·系统架构、系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。

系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作无疑是架构设计工作中最为困难的工作。

此外，从每一个角度上看，都可以看到架构的两要素：元件划分和设计决定。

首先，一个软件系统中的元件首先是逻辑元件。

这些逻辑元件如何放到硬件上，以及这些元件如何为整...

用什么软件画架构图好

“架构”一词最早来自建筑学，原意为建筑物设计和建造的艺术。

但是在软件工程领域，软件架构不是一个新名词，只是在早期的著作中人们将软件架构称为软件体系架构。

这就是架构的概念。

所谓架构，就是人们对一个结构内的元素及元素间关系的一种主观影射的产物。

系统架构的主要任务是界定系统级的功能与非功能要求、规划要设计的整体系统的特征、规划并设计实现系统级的各项要求的手段，同时利用各种学科技术完成子系统的结构构建。

在系统架构中，由于对软件越来越深入的依赖，软件架构的任务也体现出重要的作用。

而且系统架构与软件架构是紧密联系和相互依赖的。

1997年，Eberhadrt Rechtin 与MarkW Maier 在其论著中，为计算机科学总结了系统架构方面的实践成果，从而奠定了系统科学和系统架构在计算机科学中的基石： 无论何种系统架构应用领域，目的都是一样的，即完整地、高一致性的、平衡各种利弊的、有技术和市场前瞻性的设计系统和实施系统。

...