用户登录
用户注册

分享至

软件工程 建模 软件工程建模是什么

  • 作者: 人家都说名字起的太长不太容易被记住
  • 来源: 51数据库
  • 2020-04-15

软件工程 建模

软件工程如何分析建模?

结构化分析实质上是一种创建模型的活动。

通过需求分析而建立的模型必须达到下述的三个基本目标。

·描述用户的需求。

·为软件设计工作奠定基础。

·定义一组需求,一旦开发出软件产品之后,就可以用这组需求为标准来验收该产品。

为了达到上述这些目标,在结构化分析过程中导出的分析模型的形式,如图3.1所示。

分析模型的核心是“数据字典”,它描述软件使用或产生的所有数据对象。

围绕着这个核心有三种不同的图:“实体一关系图”描绘数据对象之间的关系,它是用来进行数据建模活动的图形,图中出现的每个数据对象的属性可以在“数据对象描述”中描述。

创建“数据流图”有两个目的:①指出当数据在软件系统中移动时怎样被变换;②描绘变换数据流的功能和子功能。

数据流图是功能建模的基础。

在“处理规格说明”中给出了对出现在数据流图中的每个功能的描述。

“状态转换图”指明了作为外部事件结果的系统行为。

为此,状态转换图描绘了系统的各种行为模式(称为“状态”)和在不同状态间转换的方式。

状态转换图是行为建模的基础。

在“控制规格说明”中包含了有关软件控制的附加信息。

在软件工程一体化中,有哪些面向对象模型?有哪些建模工具?

需求分析是发现、求精、建模、规格说明和复审的过程。

为了发现用户的真正需求,首先应该从宏观角度调查、分析用户所面临的问题,也就是说,需求分析的第一步是尽可能准确地了解用户当前的情况和需要解决的问题。

例如,仅仅知道“用户需要一个计算机辅助设计系统,因为他们的手工设计系统很糟糕”是远远不够的。

除非开发人员准确地知道目前使用的手工系统什么地方很糟糕,否则新开发出的计算机辅助设计系统很可能也同样糟糕。

类似地,如果一个个人计算机制造商打算开发一个新的操作系统,他首先应该做的工作就是评价目前使用的操作系统并准确地分析它不能令人满意的原因。

只有开发人员对用户面临的问题有了清楚的了解之后,才能正确地回答出“什么是新产品必须做到的”这个关键问题。

如果软件是新开发的计算机系统的一个组成部分,则系统工程师所确定的软件职责范围,可以作为软件需求分析的出发点。

分析员对用户提出的初步要求应该反复求精多次细化,才能充分理解用户的需求,得出对目标系统的完整、准确和具体的要求。

为了更好地理解问题,人们常常采用建立模型的方法。

所谓模型,就是为了理解事物而对事物做出的一种抽象,是对事物的一种无歧义的书面描述。

通常,模型由一组图形符号和组织这些符号的规则组成。

在技术层次上,软件工程是从一系列建模活动开始的,这些建模活动导致对要求开发的软件的完整的需求规格说明和全面的设计表示。

结构化分析就是一种建立模型的活动,通常建立数据模型、功能模型和行为模型等三种模型。

除了用分析模型表示软件需求之外,还要写出准确的软件需求规格说明。

模型既是软件没计的基础,也是编写软件规格说明的基础。

在分析软件需求和编写软件规格说明的过程中,软件开发者和软件用户都起着关键的、必不可少的作用。

只有用户才真正知道他们需要什么,用户必须尽量把他们对软件功能和性能的模糊需求准确、具体地描述出来,而开发者则是软件需求的询问者、顾问和实现者。

表面看来,需求分析和规格说明好像是比较简单的工作,实际上完全相反,这是一项相当艰巨复杂的工作。

用户与开发者之间需要通信、沟通的内容非常多,在双方交流信息的过程中很容易出现误解或遗漏,也可能存在二义性。

因此,不仅在整个需求分析过程中应该采用行之有效的通信技术,集中精力过细工作,而且对需求分析的结果(分析模型和规格说明)必须严格审查。

尽管目前存在许多不同的结构化分析方法,但是,所有这些分析方法都遵守下述准则 必须理解和表示问题的信息域,根据这条准则应该建立数据模型。

必须定义软件应完成的功能,这条准则要求建立功能模型。

必须表示作为外部事件结果的软件行为,这条准则要求建立行为模型。

软件工程中的业务建模中的业务主线是有几条

但实际上,构建和部署新的应用程序时往往会进行一定程度的业务改进。

请参见工作流程明细。

通常,这些工作在开始时仅仅是画出组织图,业务建模就成了软件工程项目中的一部分,它主要是在先启阶段执行的,销售支持应用程序或结账应用程序)。

一种有效的做法是:从头到尾进行一次业务建模工作,从而按这些组织的经营方式对它们进行调整,避免一些对于系统来说过于复杂的需求(业务改进)。

但如果无法对组织进行调整,而不考虑该业务的工作流程。

这就称为领域建模业务建模(Business Modeling)是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系,业务建模强调以体系的方式来理解、设计和构架企业信息系统。

根据环境和需求的不同。

在这种情况下,业务建模的目的就不仅仅是要找出对系统的需求,而且还要确定新业务是否可行。

在这种情况下,那么业务建模通常本身就是一个或多个项目,并使您更容易确定应用程序功能的优先级。

场景 #5 - 新业务如果某个组织决定要启动一项全新的业务(业务创建),并将构建信息系统来支持该业务。

场景 #1 - 组织图您可能需要构建组织及其流程的简图。

场景 #3 - 单业务多系统如果您正在构建一个大的系统(即一系列的应用程序),那么一个业务建模工作可能成为数个软件工程项目的输入。

业务模型帮助您找出功能性需求:开发领域模型。

通常,并且也作为构建应用程序系列构架的输入。

详情请参见概念:从业务模型到系统,领域建模是软件工程项目的一部分。

场景 #2 - 领域建模如果您构建应用程序时的主要目的是管理和提供信息(例如,订单管理系统或银行系统),那么您可能选择在业务级别上构建该信息的模型。

场景 #6 - 修改如果某个组织决定要对其经营方式进行彻底修改(业务重建),以便更好地了解对正在构建的应用程序的需求。

在这种情况下,那么就需要进行业务建模工作,通常将业务建模工作本身当做一个项目。

在这种情况下,通常将业务建模工作本身当做一个项目。

场景 #4 - 通用业务模型如果您正在构建一个供多个组织使用的应用程序(例如,其目的并不是对组织进行变更,那么业务建模工作能够帮助您了解并管理这些组织使用该应用程序时存在的差别,它是在项目的先启阶段和精化阶段中执行的,业务建模工作可能有不同的规模。

以下列出了六种这样的场景...

软件工程这个专业如何?

软件工程专业: 主修课程:主干学科:马克思主义理论、大学外语、高等数学、大学物理、物理实验、线性代数、概率论与数理统计、程序设计语言、数据结构、离散数学、操作系统、编译技术、软件工程概论、统一建模语言、软件体系结构、软件需求、软件项目管理该专业除了学习公共基础课外,还将系统学习离散数学、数据结构、算法分析、面向对象程序设计、现代操作系统、数据库原理与实现技术、编译原理、软件工程、软件项目管理、计算机安全等课程,根据学生的兴趣还可以选修一些其它选修课。

实践环节:毕业实习、课程设计、计算机工程实践、生产实习、毕业设计(论文)。

就业方向:本专业学生毕业后可以从事各级各类企事业单位的办公自动化处理、计算机安装与维护、网页制作、计算机网络和专业服务器的维护管理和开发工作、动态商务网站开发与管理、软件测试与开发及计算机相关设备的商品贸易等方面的有关工作。

除考取国内外名牌大学研究生外,主要毕业去向是计算机软件专业公司﹑信息咨询公司﹑以及金融等其它独资、合资企业。

就业前景:中国的软件行业规模不是很大,有些软件企业在软件制作上,也只是采用了一些软件工程的思想,距离大规模的工业化大生产比较还是有一定的差距;原因有管理体制的问题,市场问题,政策问题,也有软件工程理论不全面和不完善的问题。

所以软件工程的研究和应用,以及中国软件行业的进一步发展,都需要一定的既有软件工程的理论基础和研究能力,又有一定的实践经验的软件工程科学技术人员来推动。

软件工程的前途是光明的。

软件服务外包属于智力人才密集型现代服务业。

大量著名外包企业落户宁波。

主要就业去向包括软件外包与服务企业、信息产品与服务企业,担任程序员、软件测试员、项目经理等工作岗位。

就业岗位:Java方向:JAVA初级程序员、JAVA计算程序员 、 JAVA工程师 、J2EE系统工程师等。

.Net方向: .Net程序员网站开发工程师 .Net工程师等。

其它方向: 简单的管理信息系统开发和维护人员 、网页制作和客户端脚本程序编写人员 、初级数据库管理和 维护人员 、数据库开发工程师 、系统分析设计工程 、软件项目配置管理员 、文档编写工程师。

...

软件体系结构的建模是怎样的?

一、软件体系结构和框架的定义软件体系结构的英文单词是“achitectue”.Achitectue的基本词义是建筑、建筑学、建筑风格。

软件体系结构虽然根植于软件工程,但还处于一个研究发展的阶段,迄今为止还没有一个为大家所公认的定义。

《设计模式》中对框架的定义是框架就是一组相互协作的类,对于特定的一类软件,框架构成了一种可重用的设计。

软件框架是项目软件开发过程中提取特定领域软件的共性部分形成的体系结构,不同领域的软件项目有着不同的框架类型。

框架的作用在于:由于提取了特定领域软件的共性部分,因此在此领域内新项目的开发过程中代码不需要从头编写,只需要在框架的基础上进行一些开发和调整便可满足要求;对于开发过程而言,这样做会提高软件的质量,降低成本,缩短开发时间,使开发越做越轻松,效益越做越好,形成一种良性循环。

框架不是现成可用的应用系统。

是一个半成品,需要后来的开发人员进行二次开发,实现具体功能的应用系统。

框架不是“平台”,平台概念比较模糊可以是一种操作系统,一种应用服务器,一种数据库软件,一种通讯中间件等地那个,因此平台在应用平台主要指提供特定服务的系统软件,而框架更侧重了设计,开发过程,或者可以说,框架通过调用平台提供的服务而起的作用。

框架不是工具包或者类库,调用API并不就是在使用框架开发,紧紧使用API是,开发者完成系统的主题部分,并不时地调用类库实现特定任务。

而框架构成了通用的、具有一般性的系统主体部分,二次开发人员只是像做填空一样,根据具体业务,完成特定应用系统中与众不同的特殊部分。

二、框架与架构之间的关系框架不是构架(即软件体系机构)。

体系结构确定了系统整体结构、层次划分,不同部分之间的协作等设计考虑。

框架比架构更具体。

更偏重于技术涉嫌。

确定框架后,软件体系结构也随之确定,而对于同一软件体系结构(比如We开发中的MVC),可以通过多种框架来实现。

三、框架与设计模式之间的关系设计模式和框架在软件设计中是两个不同的研究领域。

设计模式研究的是一个设计问题的解决方法,一个模式可应用于不同的框架和被不同的语言所实现;而框架则是一个应用的体系结构,是一种或多种设计模式和代码的混合体虽然它们有所不同,但却共同致力于使人们的设计可以被重用,在思想上存在着统一性的特点,因而设计模式的思想可以在框架设计中进行应用。

框架和设计模式存在着显著的区别,主要表现在二者提供的内容和致力应用的领域。

1)从应用领域上分,框架给出的是整个应用的体系结构;而设计模式则给出了单一设计问题的解决方案,并且这个方案可在不同的应用程序或者框架中进行应用。

2)从内容上分,设计模式仅是一个单纯的设计,这个设计可被不同语言以不用方式来实现;而框架则是设计和代码的一个混合体,编程者可以用各种方式对框架进行扩展,进而形成完整的不同的应用。

3)以第二条为基础,可以得出设计模式比框架更容易移植:框架一旦设计成形,虽然还没有构成完整的一个应用,但是以其为基础进行应用的开发显然要受制于框架的实现环境;而设计模式是与语言无关的,所以可以在更广泛的异构环境中进行应用。

总之,框架是软件,而设计模式是软件的知识体,提升框架的设计水平。

Feedack#e:软件体系结构(构架)、架构、设计模式之间的关系回复更多评论2005-11-1813:08y非鱼FRAMEWORK和ARCHITECTURE属于不同的设计层次。

DP和FRAMEWORK、ARCHITECTURE分属不同的领域,DP只能和ARCHITECTURALPATTERN相提并论。

#e:软件体系结构(构架)、架构、设计模式之间的关系回复更多评论2005-11-1817:59ypulisheluoARCHITECTURE是描述系统整体的一种结构(CS架构,BS架构,三层架构等),使用框架开发的we系统也是一种体系结构,而架构是系统中的一部分具体实现。

框架的设计也使用了很多设计模式。

设计模式只是一个问题解决域,而框架可以利用设计模式来解决客观存在的问题。

我软件工程的.是参加数学建模好还是电子设计好呢

业务建模(Business Modeling)是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系,业务建模强调以体系的方式来理解、设计和构架企业信息系统。

根据环境和需求的不同,业务建模工作可能有不同的规模。

以下列出了六种这样的场景。

场景 #1 - 组织图您可能需要构建组织及其流程的简图,以便更好地了解对正在构建的应用程序的需求。

在这种情况下,业务建模就成了软件工程项目中的一部分,它主要是在先启阶段执行的。

通常,这些工作在开始时仅仅是画出组织图,其目的并不是对组织进行变更。

但实际上,构建和部署新的应用程序时往往会进行一定程度的业务改进。

场景 #2 - 领域建模如果您构建应用程序时的主要目的是管理和提供信息(例如,订单管理系统或银行系统),那么您可能选择在业务级别上构建该信息的模型,而不考虑该业务的工作流程。

这就称为领域建模。

请参见工作流程明细:开发领域模型。

通常,领域建模是软件工程项目的一部分,它是在项目的先启阶段和精化阶段中执行的。

场景 #3 - 单业务多系统如果您正在构建一个大的系统(即一系列的应用程序),那么一个业务建模工作可能成为数个软件工程项目的输入。

业务模型帮助您找出功能性需求,并且也作为构建应用程序系列构架的输入。

详情请参见概念:从业务模型到系统。

在这种情况下,通常将业务建模工作本身当做一个项目。

场景 #4 - 通用业务模型如果您正在构建一个供多个组织使用的应用程序(例如,销售支持应用程序或结账应用程序)。

一种有效的做法是:从头到尾进行一次业务建模工作,从而按这些组织的经营方式对它们进行调整,避免一些对于系统来说过于复杂的需求(业务改进)。

但如果无法对组织进行调整,那么业务建模工作能够帮助您了解并管理这些组织使用该应用程序时存在的差别,并使您更容易确定应用程序功能的优先级。

场景 #5 - 新业务如果某个组织决定要启动一项全新的业务(业务创建),并将构建信息系统来支持该业务,那么就需要进行业务建模工作。

在这种情况下,业务建模的目的就不仅仅是要找出对系统的需求,而且还要确定新业务是否可行。

在这种情况下,通常将业务建模工作本身当做一个项目。

场景 #6 - 修改如果某个组织决定要对其经营方式进行彻底修改(业务重建),那么业务建模通常本身就是一个或多个项目。

通常,业务重建分数个阶段完成:新业务展望、对现有业务实施逆向工程、对新业务实施正向工程以及启动新业务。

转载请注明出处51数据库 » 软件工程 建模

软件
前端设计
程序设计
Java相关