什么是系统架构设计?
“架构”一词最早来自建筑学,原意为建筑物设计和建造的艺术。
但是在软件工程领域,软件架构不是一个新名词,只是在早期的著作中人们将软件架构称为软件体系架构。
这就是架构的概念。
所谓架构,就是人们对一个结构内的元素及元素间关系的一种主观影射的产物。
系统架构的主要任务是界定系统级的功能与非功能要求、规划要设计的整体系统的特征、规划并设计实现系统级的各项要求的手段,同时利用各种学科技术完成子系统的结构构建。
在系统架构中,由于对软件越来越深入的依赖,软件架构的任务也体现出重要的作用。
而且系统架构与软件架构是紧密联系和相互依赖的。
1997年,Eberhadrt Rechtin 与MarkW Maier 在其论著中,为计算机科学总结了系统架构方面的实践成果,从而奠定了系统科学和系统架构在计算机科学中的基石: 无论何种系统架构应用领域,目的都是一样的,即完整地、高一致性的、平衡各种利弊的、有技术和市场前瞻性的设计系统和实施系统。
...
java软件开发的架构设计
软件架构作为一个概念,体现在技术和业务两个方面。
从技术角度来说:软件架构随着技术的革新不断地更新其内容,软件架构建立于当前技术和一些基本原则的基础之上。
先说一些基本原则:分层原则:分层是为了降低软件深度复杂性而使用的关键思想,就像社会有了阶级一样,软件有了层次结构。
模块化原则:模块化是化解软件广度复杂的必然手段,模块化的目的就是让软件分工。
接口实现分离原则随着软件模块化的不断深入改进,面向接口编程而不是面向实现编程可以让复杂度日趋增高的软件降低模块之间的耦合度,从而让各模块更轻松改进。
从这个原则出发,软件也从微观进行了细致的规范化。
还有两个比较小但很重要的原则:细节隐藏原则很显然把复杂问题简化,把难看的细节隐去,能让软件结构更清晰。
其实这个原则使用很普遍,java/c++语言中的封装原则以及设计模式中的Facade(外观)模式就很能体现这个原则的精神。
依赖倒置原则随着软件结构的进一步发展,层与层之间、模块与模块之间的依赖逐渐加深,而层、模块的动态可插拔要求不端增大。
依赖倒置原则可看视为接口实现分离原则的深化,根据此原则的精神,软件进入了工具时代。
这个原则有点类似于知名的好莱坞法则:Don't call us, we'll call you。
以上这些原则奠定了我们的软件架构的价值指标。
但软件架构毕竟是建立在当前技术之上的。
而每一代技术都有架构模式。
过去的不再说了,让我们就来看一下当前流行的技术,以及当前我们能采用的架构。
因为面向对象是当前最流行开发技术,且设计模式的大量使用使面向对象的走向成熟,而数据库是当前最有效的存储结构、web界面是当前最流行的用户接口,所以当前最典型的三层次架构就架构在以上几项技术的基础之上,用数据库作存储层、用面向对象来实现业务层、用web来作为用户接口层。
我们从三层次架构谈起:因为面向对象技术和数据库技术不适配,所以在标准三层次架构的基础上,我们增加了数据持久层,来管理O-R双向映射,但目前一直没有最理想的实现技术。
cmp和entity bean技术因为其实现复杂,功能前景有限,已接近被淘汰的边缘。
JDO及hibernate作为o-r映射的后期之秀,尤其是hibernate,功能相当完备。
推荐作为持久层的首选在业务层,因为当前业务日趋负载,且变动频繁,所以我们必须有足够敏捷的技术来保证我们的适应变化的能力,在标准j2ee系统中session bean负责业务处理,且有不错的性能表现,但采用ejb系统对业务架构模式改变太大,且其复杂而昂贵,业务代码移植性差。
而spring 作为一个bean配置的轻量级架构,漂亮的IOC模式实现,对业务架构影响小,所以推荐作为中间层业务框架。
在用户结构层,虽然servlet/jsp/jstl/javaBean 能够实现MVC架构,但终究过于粗糙。
struts对MVC架构的实现就比较完美,Taperstry也极好地实现MVC架构,且采用基于事件的方式,非常诱人,惜其不够成熟,我们仍旧推荐struts作为用户接口层基础架构。
因为业务层是三层次架构中最有决定意义的,所以让我们回到业务层细致地分析一下,在复杂的业务我们常常需要以下基础服务的一种或几种:事务一致 性服务acid(tool:jta/jts)、并发加锁服务concurrent&&lock、池化管理服务cache、访问控制服务(tool:jaas)、流程控制服务workflow、动态实现服务IOC,串行化消息服务(tool:jms)、负载平衡服务blance等。
如果我们不采用重量级应用服务器(如weblogic,websphere,jboss等)及重量级组件(EJB),我们必须自己实现其中一些服务。
虽然我们大 多情况下,不需要所有这些服务,但实现起来却非易事。
幸运的是我们有大量的开源实现代码,但采用开源代码却常常是件不轻松的事。
随着xml作为结构化信息传输和存储地位日渐重要,一些xml文档操作工具(DOM,Digester,SAX等)的使用愈发重要,而随着 xml schema的java binding工具(jaxb,xmlbean等)工具的成熟,采用xml schema来设计xml文档格式,然后采用java binding来生成java bean 会成为主要编程模式,而这又进一步使数据中心向xml转移,使在中小数据量上,愈发倾向于以xquery为查询语言的xml数据库。
现还有一个趋势, microsoft,ibm等纷纷大量开发中间软件如(microsoft office之infopath),可以直接从xml schema 生成录入页面等非常实用的功能。
还有web service 的广泛应用,都将对软件的架构有非常重大的影响。
至于面向服务架构(SOA)前景如何,三层次架构什么时候走入历史,现还很难定论。
aop的发展也会对软件架构有很深的影响,但在面向对象架构里,无论aspectJ还是jboss-aop抑是aspectWerks、 nanning都有其自身的严重问题:维护性很差,所以说它将很难走远。
也许作为一个很好的思想,它将在web service里大展身手。
rdf,owl作为w3c语义模型的标志性的语言,也很难想象能在当前业务架构发挥太大影响。
但如果真如它所声称那样,广泛地改变着信息的结构。
那么对软件架构也会有深远影响。
简述数据库应用系统的设计步骤
数据库应用系统的开发是一项软件工程。
一般可分为以下几个阶段: 1.规划 2.需求分析 3.概念模型设计 4. 逻辑设计 5.物理设计 6.程序编制及调试 7.运行及维护。
这些阶段的划分目前尚无统一的标准,各阶段间相互联接,而且常常需要回溯修正。
在数据库应用系统的开发过程中,每个阶段的工作成果就是写出相应的文档。
每个阶段都是在上一阶段工作成果的基础上继续进行,整个开发工程是有依据、有组织、有计划、有条不紊地展开工作。
1.规划 规划的主要任务就是作必要性及可行性分析。
在收集整理有关资料的基础上,要确定将建立的数据库应用系统与周边的关系,要对应用系统定位,其规模的大小、所处的地位、应起的作用均须作全面的分析和论证。
明确应用系统的基本功能,划分数据库支持的范围。
分析数据来源、数据采集的方式和范围,研究数据结构的特点,估算数据量的大小,确立数据处理的基本要求和业务的规范标准。
规划人力资源调配。
对参与研制和以后维护系统运作的管理人员、技术人员的技术业务水平提出要求,对最终用户、操作员的素质作出评估。
拟定设备配置方案。
论证计算机、网络和其他设备在时间、空间两方面的处理能力,要有足够的内外存容量,系统的响应速度、网络传输和输入输出能力应满足应用需求并留有余量。
要选择合适的os,dbms和其它软件。
设备配置方案要在使用要求、系统性能、购置成本和维护代价各方面综合权衡。
对系统的开发、运行、维护的成本作出估算。
预测系统效益的期望值。
拟定开发进度计划,还要对现行工作模式如何向新系统过渡作出具体安排。
规划阶段的工作成果是写出详尽的可行性分析报告和数据库应用系统规划书。
内容应包括:系统的定位及其功能、数据资源及数据处理能力、人力资源调配、设备配置方案、开发成本估算、开发进度计划等。
可行性分析报告和数据库应用系统规划书经审定立项后,成为后续开发工作的总纲。
数据库应用系统的开发是一项软件工程,本文介绍了数据库应用系统的开发步骤…… 2.需求分析 需求分析大致可分成三步来完成。
(1) 需求信息的收集, 需求信息的收集一般以机构设置和业务活动为主干线,从高层中层到低层逐步展开 (2) 需求信息的分析整理, 对收集到的信息要做分析整理工作。
数据流图(dfd, data flow diagram)是业务流程及业务中数据联系的形式描述。
图4.1是一个简单的dfd 示例。
数据字典(dd, data dictionary)详细描述系统中的全部数据。
数据字典包含以下几个部分。
· 数据项:是数据的原子单位。
· 数据组项:由若干数据项组成。
· 数据流:表示某一数据加工过程的输入/输出数据。
· 数据存储:是处理过程中要存取的数据。
· 数据加工过程 数据加工过程的描述包括:数据加工过程名、说明、输入、输出、加工处理工作摘要、加工处理频度、加工处理的数据量、响应时间要求等。
数据流图既是需求分析的工具,也是需求分析的成果之一。
数据字典是进行数据收集和数据分析的主要成果。
(3) 需求信息的评审. 开发过程中的每一个阶段都要经过评审,确认任务是否全部完成,避免或纠正工作中出现的错误和疏漏。
聘请项目外的专家参与评审,可保证评审的质量和客观性。
评审可能导致开发过程回溯,甚至会反复多次。
但是,一定要使全部的预期目标都达到才能让需求分析阶段的工作暂告一个段落. 需求分析阶段的工作成果是写出一份既切合实际又具有预见的需求说明书,并且附以一整套详尽的数据流图和数据字典。
3.概念模型设计 概念模型不依赖于具体的计算机系统,他是纯粹反映信息需求的概念结构。
建模是在需求分析结果的基础上展开,常常要对数据进行抽象处理。
常用的数据抽象方法是‘聚集’和‘概括’。
er方法是设计概念模型时常用的方法。
用设计好的er图再附以相应的说明书可作为阶段成果 概念模型设计可分三步完成。
(1) 设计局部概念模型 ① 确定局部概念模型的范围 ② 定义实体 ③ 定义联系 ④ 确定属性 ⑤ 逐一画出所有的局部er图,并附以相应的说明文件数据库应用系统的开发是一项软件工程,本文介绍了数据库应用系统的开发步骤…… (2) 设计全局概念模型 建立全局er图的步骤如下: ① 确定公共实体类型 ② 合并局部er图 ③ 消除不一致因素 ④ 优化全局er图 ⑤ 画出全局er图,并附以相应的说明文件。
(3) 概念模型的评审 概念模型的评审分两部分进行 第一部分是用户评审。
第二部分是开发人员评审。
4.逻辑设计 逻辑设计阶段的主要目标是把概念模型转换为具体计算机上dbms所支持的结构数据模型。
逻辑设计的输入要素包括:概念模式、用户需求、约束条件、选用的dbms的特性。
逻辑设计的输出信息包括:dbms可处理的模式和子模式、应用程序设计指南、物理设计指南。
(1) 设计模式与子模式 关系数据库的模式设计可分四步完成。
① 建立初始关系模式 ② 规范化处理 ③ 模式评价 ④ 修正模式 经过多次的模式评价和模式修正,确定最终的模式和子模式。
写出逻辑数据库结构说明书。
数据库应用系统的开发是一项软件工程,本文介绍了数据库应用系统的开发步骤…… (2) 编写应用程序...
一般做产品结构设计的用什么软件?
如果对你的意思理解准确的话,你需要的应该是架构建模工具,而非绘制UML等架构视图的工具,如果仅仅是后者,用绘图板、PPT完全可以做到,只是没那么方便而已。
目前最流行的架构设计建模工具主要有:1)IBM Rational 建模工具是大量企业都选择的,包括 Rational Software Modeler、Rational Software Architect、Rational Application Developer、Rational Modeling Extensions for .NETRational工具套件非常全面、专业,唯一的缺点是贵。
Rational Rose属于早期的工具,现在已经过时了,被IBM放弃了。
2)EA,也是很多企业都选择的工具,非常简洁、有效3)Visual Studio:建模能力很强大,微软一派选择她很方便其余还有很多小众的工具,企业内部的建模工具,各有优势,就不多说了。
什么是软件基础架构
软件架构 软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。
软件架构是一个系统的草图。
软件架构描述的对象是直接构成系统的抽象组件。
各个组件之间的连接则明确和相对细致地描述组件之间的通讯。
在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。
在面向对象领域中,组件之间的连接通常用接口_(计算机科学)来实现。
软件体系结构是构建计算机软件实践的基础。
与建筑师设定建筑项目的设计原则和目标,作为绘图员画图的基础一样,一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。
软件构架是一个容易理解的概念,多数工程师(尤其是经验不多的工程师)会从直觉上来认识它,但要给出精确的定义很困难。
特别是,很难明确地区分设计和构架:构架属于设计的一方面,它集中于某些具体的特征。
在“软件构架简介”中,David GArlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次:“在计算的算法和数据结构之外,设计并确定系统整体结构成为了新的问题。
结构问题包括总体组织结构和全局控制结构;通信、同步和数据访问的协议;设计元素的功能分配;物理分布;设计元素的组成;定标与性能;备选设计的选择。
”[GS93] 但构架不仅是结构;IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”[IEEE98]。
构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。
它并不仅注重对内部的考虑,而且还在系统的用户环境和开发环境中对系统进行整体考虑,即同时注重对外部的考虑。
在 Rational Unified ProcESs 中,软件系统的构架(在某一给定点)是指系统重要构件的组织或结构,这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。
从和目的、主题、材料和结构的联系上来说,软件架构可以和建筑物的架构相比拟。
一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管理软件产品的高级设计。
软件架构师定义和设计软件的模块化,模块之间的交互,用户界面风格,对外接口方法,创新的设计特性,以及高层事物的对象操作、逻辑和流程。
在设计院做结构设计一般用什么软件?除了CAD
首先要了解架构视图有哪些维度和组成要素: 1. 架构视图 最经典的当属4+1视图: 逻辑视图 开发视图 过程视图 物理视图 场景视图 4+1视图提出后,业界也有其它的观点提出,诸如SEI(模块视图、组建和连接件视图、分配视图)、西门子4种视图(概念、模块、代码、执行视图)、以及RM-ODP(企业视图、信息视图、计算视图、工程师图)等。
常见的视图除了上述4+1视图外还包括:数据视图、安全视图、实现视图等。
2. 了解架构视图的四要素 图示化主要元素和元素之间的关系 具有明确的图例、定义和说明元素 每个元素具备明确的接口和行为规范 设计原理和设计决策的信息 3. 简单说一下几个视图针对的角色和维度: 逻辑视图一般针对客户、用户、业务人员、开发组织,主要从系统的功能元素、以及它们的接口、职责、交互维度入手。
主要元素包括系统、子系统、功能模块、子功能模块、接口等。
开发视图一般针对开发和测试相关人员,主要描述系统如何开发实现;主要元素包括描述系统的分层、分区、框架、系统通用服务、业务通用服务、类和接口、系统平台和大基础框架。
用途是知道开发设计和实现。
物理视图一般针对系统运维人员、集成人员,它是系统逻辑组件到物理节点的映射,节点与节点间的物理网络配置等,主要关注非功能性需求,诸如性能(吞吐量)、可伸缩性、可靠性,可用性等,从而得出相关的物理部署结构图。
4. 写在最后 了解这些,确定了你的受众和切入的维度后,你就可以决定你要用什么样的视图和视图组合来表达你的内容,挑选一个你得心应手的工具去实施就可以了。
在我看来,用白板和团队一起画出来是一件极美的好玩的事情。
...数据库。
现在想自己设计一个小软件,我还需要自学点什么,还有用...
你想做什么软件呢?把软件要实现的功能讲解一下。
以便更好的回答你的问题。
一般而言,做软件需要以下几个方面的知识:1. UI 设计2.数据结构3.算法4.用编程语言描述业务需求。
如果是数据库应用软件,还需要用到数据库编程的知识
大数据架构究竟用哪种框架更为合适
个完整的大数据平台应该提供离线计算、即席查询、实时计算、实时查询这几个方面的功能。
hadoop、spark、storm 无论哪一个,单独不可能完成上面的所有功能。
hadoop+spark+hive是一个很不错的选择.hadoop的HDFS毋庸置疑是分布式文件系统的解决方案,解决存储问题;hadoop mapreduce、hive、spark application、sparkSQL解决的是离线计算和即席查询的问题;spark streaming解决的是实时计算问题;另外,还需要HBase或者Redis等NOSQL技术来解决实时查询的问题。
除了这些,大数据平台中必不可少的需要任务调度系统和数据交换工具;任务调度系统解决所有大数据平台中的任务调度与监控;数据交换工具解决其他数据源与HDFS之间的数据传输,比如:数据库到HDFS、HDFS到数据库等等。
关于大数据平台的架构技术文章,可搜索"lxw的大数据田地",里面有很多。
大数据是什么意思: 麦肯锡全球研究所给出的定义是:一种规模大到在获取、存储、管理、分析方面大大超出了传统数据库软件工具能力范围的数据集合,具有海量的数据规模、快速的数据流转、多样的数据类型和价值密度低四大特征。
大数据技术的战略意义不在于掌握庞大的数据信息,而在于对这些含有意义的数据进行专业化处理。
换而言之,如果把大数据比作一种产业,那么这种产业实现盈利的关键,在于提高对数据的“加工能力”,通过“加工”实现数据的“增值”。
从技术上看,大数据与云计算的关系就像一枚硬币的正反面一样密不可分。
大数据必然无法用单台的计算机进行处理,必须采用分布式架构。
它的特色在于对海量数据进行分布式数据挖掘。
但它必须依托云计算的分布式处理、分布式数据库和云存储、虚拟化技术。
随着云时代的来临,大数据(Big data)也吸引了越来越多的关注。
大数据(Big data)通常用来形容一个公司创造的大量非结构化数据和半结构化数据,这些数据在下载到关系型数据库用于分析时会花费过多时间和金钱。
大数据分析常和云计算联系到一起,因为实时的大型数据集分析需要像MapReduce一样的框架来向数十、数百或甚至数千的电脑分配工作。
大数据需要特殊的技术,以有效地处理大量的容忍经过时间内的数据。
适用于大数据的技术,包括大规模并行处理(MPP)数据库、数据挖掘、分布式文件系统、分布式数据库、云计算平台、互联网和可扩展的存储系统。
...
转载请注明出处51数据库 » 用什么软件做数据库架构设计
徐钦常