如何分析一个系统的架构
系统架构(Framework 或Architecture)或软件架构的定义很难明确,仁者见仁智者见智。
在面向对象范畴中,我认为就是通过若干类、抽象类及其接口有机组成的软件系统,其中类起的作用好比建筑物中的砖瓦钢筋水泥楼板,而接口和抽象类中没有实现的方法好比其中的一个个空间,包括大厅,走廊,房间,厨房,卫生间....,架构使用者的任务就是往这些空间中填充东西,也就是实现那些接口和抽象方法,从而可以创建一座定制了的建筑物。
进一步,可以对这个建筑进行修饰使其外观更加漂亮。
当然也可以进行改动,以便结构更加合理。
在《Rational 统一过程实践者指南》(RUP)认为,系统架构为:1. 系统中最重要的组成部分和它们的接口,以及做出的创建、购买或是重用这些组成部分的决定;2.描述这些组成部分在运作时如何交互来实现系统中最重要的脚本;3.实现并测试系统架构的原型,以验证架构是否可行、是否化解了重大风险,以及验证它是否打到了重要的质量指标:性能、可扩展性和成本等。
架构,框架和设计模式的区别
展开全部 设计模式是架构的手段(之一)。
具体一点说,设计模式可以在某些情况帮助架构软件的静态结构。
而架构的范围要大一些,更高层一些,考虑的更多的是非常重要的全局性的design decision。
一般好的(静态)架构可以尽量使变化发生在局部(模块内)而不影响整个系统。
架构上的变化往往成本会非常高。
而且设计模式只有一些是适用于架构的,还有一些只是用于具体的类设计的,剩下的一些则只是克服编程语言的限制而已。
打个不恰当的比方,有点像挡拆和战术的关系。
在合适的情况下用好挡拆可以很好的执行战术, 但战术不只有挡拆, 而且有的战术不需要挡拆, 最重要的是盲目的用挡拆有时候反而会起反作用。
面对客户哔哔时,我们用需求分析架构。
面对整个软件或系统时,我们谈论架构分析。
面对软件模块设计时,我们使用设计模式。
面对模块实现时,我们应用特定编程语言的特性。
软件架构 :一般场景下拥有设计的选择权 设计模式 :选择后特定场景下的最佳实践 软件架构是软件的一种搭建形式,往往规定了软件的模块组成,通信接口(含通信数据结构),组件模型,集成框架等等。
往往规定了具体的细节。
设计模式是一种软件的实现方法,是一种抽象的方法论,是为了更好的实现软件而归纳出来的有效方法。
实现一种软件架构,不同组成部分可能用到不同的设计模式,某一部分也可能可以采用不同的设计模式实现。
...
新系统开发前进行什么分析填空题
需求分析奠定了软件工程和项目管理的基础。
我们在建造软件系统这座大厦的时候,如果需求分析的基础不够坚实和牢固,那么往往会导致软件系统问题百出,甚至被马上丢弃。
在建造软件系统的过程中,如果我们经常习惯地沿用一些不规范的方法,其后果便是产生一条鸿沟──开发者开发的与用户所想得到的软件存在着巨大的“期望差异”。
因此“需求”这个名词的定义不仅仅是从用户角度对系统外部行为的描述,以及从开发人员角度对系统内部特性的描述,其关键的一点是“需求”必须文档化。
需求的类型 软件需求包括三个不同的层次──业务需求、用户需求和功能需求。
除此之外,每个系统还有各种非功能需求。
业务需求(BusinessRequirement)表示组织或客户高层次的目标。
业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。
业务需求描述了组织为什么要开发一个系统,即组织希望达到的目标。
使用前景和范围(vision and scope)文档来记录业务需求,这份文档有时也被称作项目轮廓图或市场需求(project charter 或 market requirement)文档。
用户需求(UserRequirement)描述的是用户的目标,或用户要求系统必须能完成的任务。
用例、场景描述和事件响应表都是表达用户需求的有效途径。
也就是说用户需求描述了用户能使用系统来做些什么。
功能需求(Functional Requirement)规定开发人员必须在产品中实现的软件功能,用户利用这些功能来完成任务,满足业务需求。
功能需求有时也被称作行为需求(behavioral requirement),因为习惯上总是用“应该”对其进行描述:“系统应该发送电子邮件来通知用户已接受其预定”。
功能需求描述是开发人员需要实现什么。
非功能需求(Non-functional Requirement) 定义了软件产品为满足用户业务需求而必须具有的除功能需求以外的特性。
包括系统的完整性(联机帮助、 数据管理、用户管理、软件发布管理、在线升级等)、性能、可靠性、可维护性、可扩充性、对技术和业务的适应性等。
需求分析的任务 1 解决的问题 1) 齐全、准确地找出目标系统全部的功能、性能、限制; 2) 找出全部的输入流、输出流; 3) 找出所有的加工; 4) 产生完整的分层的DFD、数据字典、加工的描述; 5) 补充的意见。
2 综合要求 确定对系统的综合要求,系统功能要求,系统性能要求,运行要求,将来可能提出的要求。
3 任务 图1为需求分析任务图,需求分析阶段要完成的具体明确的最终任务就是形成一份经开发方和用户认可或达成共识的软件需求分析文档(需求规格说明书、修改后的项目开发计划、初步的用户手册、确认测试计划、数据要求说明书)。
这个文档能清晰准确地说明系统将要开发什么,能够规定出详细的技术需求,包括所有面向用户、面向机器和其它软件系统的接口。
可以说需求文档在开发过程中一直起指导作用。
为了更好地完成软件开发第一阶段的需求分析任务,提高质量,需求管理是必不可少的。
需求管理的目的是在客户与开发方之间建立对需求的共同理解,维护需求与其他工作成果的一致性,并控制需求的变更,主要体现在跟踪和控制需求变更管理。
需求管理是开发工作有效进行的保证,是一种很高层次的系统行为,涉及整个开发过程和产品本身。
需求分析的方法 需求分析方法由对软件问题的信息域和功能域的系统分析过程及其表示方法组成,大多数的需求分析方法是由信息驱动的。
信息域具有三种属性: 信息流、信息内容和信息结构。
常用的需求分析方法有:面向数据流的结构化分析方法(SA),面向数据结构的Jackson方法(JSD),面向数据结构的结构化数据系统开发方法(DSSD),面向对象的分析方法(OOA)等。
选择那种方法要根据哪些资源在什么时间对开发人员有效,不能盲目套用。
这里着重阐述面向数据流的结构化分析方法(SA)。
面向数据流的结构化分析方法 面向数据流的结构化分析方法(Structured Analysis,简称SA),是面向数据流进行需求分析的方法,是需求分析使用最多的方法之一。
SA也是一种建模活动,该方法使用简单易读符号,根据软件内部数据传递、变换的关系,自顶向下逐层分解,描绘出满足功能要求的软件模型。
适用于数据处理类型软件的需求分析,这一方法除了简单,容易掌握之外,还能和设计阶段的结构化设计(SD)衔接,从而取得良好的设计结果。
自顶向下逐层分解的分析策略 SA方法的基本手段:“分解”和“抽象”。
这是系统开发技术中控制复杂性的两种手段。
它先将系统“抽象”成一个模型,此模型是有输入和输出并有系统名称的盒子,然后打开这个盒子,对它进行逐层分解,直到能被理解,可以实现为止。
因此分析的策略是自顶向下,逐层加细,由抽象到具体的过程。
如图2。
结构化分析方法使用工具 SA方法利用图形等半形式化的描述方式表达需求,简明易懂,用它们形成需求规格说明书中的主要部分。
描述工具是 1) 数据流图:描述系统由哪几部分组成,各部分之间有什么联系等等。
2) 数据字典:定义了数据流图中每一个图形元素。
3) 描述加工逻辑的结构化语...
软件构架,架构和框架的区别
结构:程序功能实现的逻辑框架是整个或部分系统的可重用设计,表现为一组抽象构件及构件实例间交互的方法;另一方面也可以说框架是可被应用开发者定制的应用骨架。
框架亦可称为应用架构,在特定领域基于体系结构的可重用的设计。
也可以认为框架是体系结构在特定领域下的应用。
框架的例子如MVC。
设计模式 在一定的环境中解决某一问题的方案 构件通常是代码重用,而设计模式是设计重用,框架则介于两者之间,部分代码重用,部分设计重用,有时分析也可重用. 构架是architecture:它是对软件系统的系统组织,是对构成系统的构件的接口,行为模式,协作关系等体系问题的决策总和。
它不仅涉及到结构与行为,而且还涉及到系统的使用,功能,性能,适应性,重用性,可理解性设计模式比框架更为抽象设计模式在碰到具体问题后,才能产生代码;框架已经可以用代码表示设计模式是比框架更小的体系结构元素:框架中可以包括多个设计模式简单点说:结构 <; 设计模式 <; 架构 <;框架 结构+算法=程序(功能代码块) 程序与程序之间进行调整=设计模式 多个设计模式相组合(组件)=架构(系统)