B. Product Line Annotations with UML-F

Model-Based Development ofEmbedded SystemsFranz Huber, Jan Philipps, Oscar SlotoschValidas AGwww.validas.de{huber,philipps,slotosch}@validas.deAbstractWe describe concepts and processes for model-based development of embedded control systems. Tool support for such an approach is provided by the award-winning AutoFocus/Quest tool set jointly developed by TU München and Validas AG. We outline real-time extensions for the mod-eling languages and show how to use time information for testing. A small case study demon-strates these extensions.IntroductionSoftware development approaches that rely on modeling a system before performing the actual implementation work have a long history in computing. Among the first ones were data(base) modeling approaches using the Entity/Relationship model and similar other techniques. During further development, modeling techniques became increasingly complete, covering not only data aspects, but also structural/topological and behavioral aspects of systems. Typical representatives of such full-scale modeling approaches are structured methods, such as Structured Analysis & Design, or object-oriented methods like the UML [4].Models created in such a modeling language can serve different purposes. They can be regarded as a concise, much more formal version of otherwise informally given system requirements. In this view, they serve as a precise guideline for the developers that perform the actual implemen-tation work, and can furthermore be used as a basis for testing the conformance of the imple-mentation with the requirements.If a modeling language is rich enough to allow the creation of complete models (models that en-compass all aspects of a system on an abstract, implementation-independent level), another pur-pose of such models is obvious: The created models can not only be used to precisely capture the requirements upon the system, but to describe the system in detail, reaching up to a complete description of all aspects of the system. From such a complete description, it is basically possible(although not always feasible or desired in practice) to generate a complete system implementa-tion automatically. An important advantage of such a model-based approach is (programming) language independence: Modeling languages are usually driven by the application domain that they are used in and provide application-oriented abstractions to describe systems (components, data entities, states, state transitions, etc.). In contrast, typical programming languages such as Ada or C are general-purpose languages, providing language elements that reflect the underlying machine model of sequential execution of statements. Using code generation techniques to create implementations, such complete models as described previously can be transformed into imple-mentations in arbitrary programming languages.Models are abstractions of a system and are thus particularly less “cluttered” than an implemen-tation, for instance, in C. Therefore, it is much more promising for models than for implementa-tions to apply validation techniques, such as—covering different levels of formality—prototyping and simulation [7], test case/test sequence generation [12], or model checking [9]. If the elements of a modeling language have been chosen carefully enough to keep the modeling language sim-ple, yet complete, it is feasible to provide a sufficiently streamlined formal semantics that even allows the application of rigid formal validation/verification techniques [5].Subsequently, we introduce such a simple, yet powerful modeling language—the AutoFocus modeling language & framework [8]—and outline some of the validation techniques that can be applied to AutoFocus models. The AutoFocus modeling language has been under development since 1995, specially aimed at the development of embedded systems, and shares some concepts with UML/RT.Model-based Development ConceptsA modeling language—quite similar to a programming language—comprises a set of concepts that are used to describe systems. In case of programming languages, these concepts are typically statements, blocks, procedures, functions, and many more. For the AutoFocus modeling language and toolset, these concepts are based on the idea of a system being made up of a network of communicating components. Usually, the concepts that describe a modeling language are defined in a so-called meta-model (i.e., a model that describes how models in that modeling language can be constructed). A simplified representation of the AutoFocus meta-model is shown in Fig. 1, using the UML class diagram notation as the meta-language.AutoFocus Modeling ConceptsThe core modeling concepts of AutoFocus, i.e., the core elements in the its meta-model are as follows:Components. They are the main building blocks for systems. Components encapsulate data, in-ternal structure, and behavior. Components can communicate with their environment via well-defined interfaces. Components are concurrent: Each one of them runs sequentially; however, in a set of components, each component’s run is independent of the other components’ runs. Com-ponents can be hierarchically structured, i.e., consist of a set of communicating sub-components. Data types. They define the data structures used by components. Data types are constructed from a set of basic types (such as integer or float) and a set of constructors, e.g., for record and variant types.Data. Data elements are encapsulated by a component and provide a means to store persistent state information inside a component. Data elements can be regarded as typed state variables. Ports. They are a component’s means of communicating with its environment. Components read data on input ports and send data on output ports. Ports are named and typed, allowing only spe-cific kinds of values to be sent/received on them.Channels. They connect component ports. Channels are unidirectional, named, and typed, and they define the communication structure (topology) of a system.Control States and Transitions. These elements define the control state space and the flow of control inside a component. Each transition connects two distinct controls states (or one control state with itself, in case of a loop transition) and carries a set of four annotations determining its firing conditions (its “enabledness”):•pre-conditions and post-conditions, which are predicates over the data elements of the component to be fulfilled before and after the transition, respectively, and •input and output patterns, determining which values must be available on the compo-nent’s input ports to fire the transition and which values are then written to the output ports.Fig. 1. Basic Modeling Concepts of A UTO F OCUS: The Meta-ModelThese concepts are sufficient to describe a large class of systems. Developers create the model of an actual system using these concepts; technically speaking (e.g., with a modeling tool for this language in mind), an actual system model is an instance of this meta-model. The complete meta-model, together with a set of additional conditions relating to consistency and completeness of models, describes the set of all possible, well-formed models that can be created.Views and Description TechniquesDevelopers do not create and manipulate models as a whole, but by picking only specific parts of them, which are of interest during particular development activities. These parts, usually closelyrelated with each other, make up the views of the system. For instance, the structural view in A UTO F OCUS considers only elements from the meta-model describing the interface of compo-nents and their interconnection.To manipulate elements of these views we must represent them visually. In A UTO F OCUS we use mainly graphical notations for that purpose; these notations are introduced in more detail by our application example. The notations do not represent self-contained documents; instead they are a mere visualization of a clipping from the complete model. Fig. 2 shows an example for this rela-tionship between a set of related elements from the meta-model (inside the shaded area) and their visual, diagrammatic representation. In this example, structural aspects of the model are covered, and the notation used to visually represent them is called System Structure Diagrams (SSDs for short).b l e O pFig. 2. Structural Parts of the Meta-Model and the Notation representing them Model-based Development ProcessOne of the main difficulties in software engineering is that the requirements of the customer are prone to change while software is being developed. In standard waterfall development process models, which are still regularly used in industry, requirements analysis and testing are located at opposite ends of the development process. Evolutionary development processes, on the other hand, try to alleviate this problem by building the software system incrementally. Requirements are not fixed in an early development phase, but instead converge during several incremental cy-cles with customer interaction after completion of each increment.In this section, we first give a short overview over incremental development processes, and then describe how a process based on executable models is supported by modern CASE tools, such as AutoFocus. Finally, we explain the step from executable models to final code.Incremental DevelopmentBoehm’s spiral model [3] is the most famous incremental process model, although it is more a meta-model of a process than a proper development process model. More helpful for real soft-ware development are the Cleanroom Reference Model (CRM) [11], and so-called agile ap-proaches, most notably Extreme Programming (XP) [2], which is based on classical object-oriented programming languages.We believe that modeling languages fit the demands of an incremental process better than pro-gramming languages: Their higher level of abstraction leads to higher productivity of the devel-opers; their suggestive notations ease interaction with the customer and other developers. Never-theless, models are executable, which results in immediate feedback for the designer and the customer.The idea of incremental model-based development amounts to specifying the model of the system as precisely as possible, so that the model is always executable. In order to handle the complexity of the system, in a first step only a small part of the core functionality of the system is described. The specification is then (together with the customer) validated and verified by simulation, in-spection and reviews, and by formal verification and analysis techniques. Later steps refine this model: More components are added to the model in order to add functionality; the behavioral specifications of the components are elaborated to handle exceptional cases; additional inputs and outputs are added, for instance to ease maintenance of the final product.Besides the modeling activities themselves, the process consists of the following activities:•Simulation: Model executability is the basis of the main validation technique employed in our incremental process [7]. Together with the customer, exemplary system runs are produced that demonstrate the model essentially operates according to the customer’s re-quirements.Simulation is not restricted to interactive step-by-step executions. Using advanced sym-bolic execution techniques based on constraint-logic-programming, it is possible to auto-matically derive simulation runs from abstract test case specifications; a test case specifi-cation typically demands that the model is brought into a certain state (functional tests) or that every transition is executed at least once (structural tests).•Analysis: While simulation is helpful to determine that the system indeed fulfils its re-quirements, there are some questions related to quality assurance that cannot be answered by simulation alone, since simulation gives answers only about single system runs, not about all possible system runs (mathematically, simulation shows existential properties, not universal ones). Some typical questions are whether the model is deterministic (i.e., for each input from the system environment there is at most one possible output specified) and complete (i.e., for each input from the system environment there is at least one possi-ble output specified). The AutoFocus toolset includes analysis tools that help to answer such questions. It also includes verification tools such as model checkers [9], which are used for mathematical proofs of critical system properties. Since such proofs are very ex-pensive (in terms of time, effort and required expertise of the tool user), the use of verifi-cation tools must be carefully judged against the economic risk of system malfunctions.•Refactoring: An obvious problem with any incremental system development process is that the resulting system specification may be cluttered and hard to understand, as itsstructure is determined partly by the order in which the increments occurred. Extreme programming makes use of elaborated refactoring [6] patterns to clean up the system after each increment so that it is both easier to understand and more amenable to further incre-ments. Similar techniques can be used for executable models; however, this is still an ac-tive area of research.To summarize, we advocate a development process that consists of several iterations where at the end of each loop, instead of hand-written code an executable system model is presented to the customer. This approach is similar to Extreme Programming, but focuses on a more abstract modeling of the system rather than its implementation. In contrast with Extreme Programming, however, production of the final code is deferred until the end of the development process. From Models to ProductsOnce the model is considered to be sufficiently correct and detailed, it is used as the basis for the production of the target code. For the target code, too, quality assurance must be performed. As the resulting code is likely not amenable to automatic analysis, the core activity here is testing (see, e.g., [10]). Essentially, there are two approaches:•The target code is produced by hand. This is a typical situation for customer/supplier re-lationships, where the model serves as the software specification of the final product. In this case, the code produced by the supplier must be tested to ensure its conformity with the model. It is possible to automatically derive test sequences for the implementation from simulation runs, in particular from the runs produced by symbolic execution as mentioned above.•The target code is produced by an automatic code generator. While in principle it is pos-sible to mathematically verify code generators, in practice there is still some risk (albeit a very small one) that the code generator produces incorrect code. Thus, even for automati-cally generated code it is prudent to test the code. For avionics systems, rigorous testing is even required: Standards such as DO-178B require, among other points, tests with clear code coverage criteria (MC/DC); it is not sufficient to have coverage only on the models. In both cases, however, additional tests must be performed to ensure that the model is not based on incorrect assumptions about the interaction with the environment, which could lead to timing problems and race conditions. Such tests can be performed by Hardware-in-the-loop approaches. Example: A Digital WatchAs an example of the description techniques of AutoFocus, this section presents parts of a model for a digital watch. The watch has three buttons (T1, T2, T3) that are used to change the display mode (date, time, stopwatch) and to set the current time and date after a battery change. Fig. 3 shows the top-level structure diagram of the watch model.The data types of the channels are defined using Data Type Definitions (DTDs) as follows: data Signal = Present;data Segments = Date(Int,Int,Int,Int,Int,Int)| Time(Int,Int,Int,Int,Int,Int)| Stop(Int,Int,Int,Int,Int,Int);Fig. 3. Top-Level View of the WatchDeeper in the modeling hierarchy, the watch component contains a time component that com-putes the time of day from internally derived signals (hs, zs) that hold the time of day in 1/100s and 1/10s; they are derived from an internal counter. There are other components to keep track of the current date and to model the stopwatch function.The time component (see Fig. 4) is quite complex, because it is also responsible for the adjust-ment of the time by the user. It has separate components to compute the segment digits for the display (Sec1, Sec10, Min1, Min10 and H12); depending on the current display mode they either display the relevant part of the current time, or the current time setting when the watch owner changes the time.Fig. 4. Component Network inside the Time Component of the WatchNote that in the diagram there are two kinds of channel connectors: Delayed channels (marked with a circle) and immediate channels (marked with a diamond). Messages sent through an im-mediate channel are visible to the receiver in the same reaction; messages sent through a delayed channel are visible in the following reaction. There are some subtle methodical issues involved intheir use. Generally, immediate channels should be used for the data flow within an embedded controller. Without immediate channels it would not be possible to switch from 23:59:59 to 00:00:00 within one model reaction, because the overflow-values would be present only in the next time step. On the other hand, for mathematical reasons every communication cycle in the system must contain at least one delayed channel.Fig. 5 shows the behavior of the component Setting as an example for state transition diagram. It describes the way to set the time using the signals T1, T2, T3 and the current mode that is com-puted by another component of the model (the mode signal is also computed from the three but-tons, but it is handled separately for reasons of modularity). For example, incrementing the min-utes display is modeled with the transition T2?P; T3?; IncM1!Present which connects the state Minute1 to itself. The semantics of this transition is as follows: When button T3 is not pressed, but button T2 is, then send the signal Present to the minute segment component.Fig. 5. State Transition Diagram of the Setting ComponentIn addition to input and output statements transitions can be annotated with preconditions (which are predicates over local variables and values read from input channels) and actions (which are assignments to local variables). Together with the DTD specifications, this allow models that are completely independent from the target programming language. This is important for reusing the models for other targets (for example with a different processor and a different instruction set). While the model itself is not very ambitious, its implementation is, since the resources of the watch are severely limited (4bit processor, 2KB of memory). The model is indeed the basis of a watch implementation with an industrial partner, but we did not yet implement a code generator for the assembly language used in the project. Given the rigorous semantics of AutoFocus, which is very close to the description techniques, and the limited size of the watch model, it is still man-ageable to translate the model into assembly language by hand.The code that results from the watch model is not used stand-alone; it is linked with a number of arithmetic and I/O libraries.Extensions for Real-TimeWith the description techniques presented so far, models describe the functionality of the system under development in terms of input/output reactions. For the final implementation, in addition tothe functionality, timing requirements must be considered. They relate system executions with the physical time of the system’s environment. Typical timing requirements are stated as separa-tion requirements (two inputs or outputs must be separated by at least a certain duration), or as proximity requirements (two inputs or outputs must be separated by at most a certain duration). Timing requirements fulfill two purposes: They impose demands on the maximal execution time for an input/output reaction of the system (and thus on the performance of the target hardware), and they state assumptions on the duration of activities of the controlled hardware.Timing requirements can be concisely specified by annotated Message Sequence Charts. Fig. 6 shows a simple timing requirements for the watch: It states that the watch, when switched to date mode by pressing button T3, displays the date for three seconds (rather, any number of display messages are sent to the hardware until exactly 3 seconds have passed) and then returns to time mode. This requirement is a combination of proximity and separation requirement. Further (quite trivial) requirements specify that a second (rather, 1/100s) of model time corresponds to a second of real time.Fig. 6. Timing Requirements in a Message Sequence Chart (MSC) Obviously, the relationship between model time and real time must be verified. Currently, this is done by hand-written test cases, which measure controller execution time and environment re-sponse times. A more automatic scheme will translate time-annotated MSCs like the one above into special time observer components. These components run in parallel to a standard hardware-in-the-loop setup (see Fig. 7) and give verdicts on the satisfaction of timing requirements for notFig. 7.ConclusionThis paper touches only some of the issues of model-based development. While the classical ar-eas of CASE tools (description techniques and code generators) are quite stable in our toolset, the validation and verification tools are still undergoing development and field studies with our part-ners and customers. In particular, the promising field of model-based test case generation is making rapid progress. In order to cover not only the later phases of system design, but also re-quirements analysis, the AutoFocus toolset has been connected to the requirements management tool DOORS [1].Acknowledgment. Peter Braun, Heiko Lötzbeyer, Alexander Pretschner and Dr. Bernhard Schätz, our colleagues from TU München, have contributed greatly to our understanding of model-based development and to the AutoFocus toolset itself.References1. B. Bajraktari: Modellbasiertes Requirements Tracing. Master thesis, TU München, 2001.2.K. Beck: Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999.3. B.W. Boehm: A spiral model for software development and enhancement. Software Engi-neering Notes, 11(4), 1994.4.G. Booch, I. Jacobson, J. Rumbaugh: The Unified Modeling Language User Guide. Addison-Wesley, 1998.5.M. Broy, O. Slotosch: Enriching the Software Development Process by Formal Methods,Proceedings of FM-Trends 98, LNCS 1641.6.M. Fowler: Refactoring. Improving the Design of Existing Code. Addison-Wesley, 1999.7. F. Huber, S. Molterer, A. Rausch, B. Schätz, M. Sihling, O. Slotosch: Tool supported Speci-fication and Simulation of Distributed Systems, Proceedings of International Symposium on Software Engineering for Parallel and Distributed Systems, 1998.8. F. Huber, B. Schätz: Integrated Development of Embedded Systems with AutoFOCUS.Technical Report TUM-I0107, Fakultät für Informatik, TU München, 2001.9.J. Philipps, O. Slotosch: The Quest for Correct Systems: Model Checking of Diagrams andDatatypes, P roceedings of Asia Pacific Software Engineering Conference 1999, 449-458. 10.A. Pretschner, O. Slotosch, H. Lötzbeyer, E. Aiglstorfer, S. Kriebel: Model Based Testing forReal: The Inhouse Card Case Study in Proc. 6th Intl. Workshop on Formal Methods for In-dustrial Critical Systems (FMICS01), Paris, July 2001.11.S. Prowell, C. Trammell, R. Linger, J. Poore: Cleanroom Software Engineering. Addison-Wesley, 1999.12.G. Wimmel, A. Pretschner, O. Slotosch: Specification Based Test Sequence Generation withPropositional Logic, Journal on Software Testing Verification and Reliability (to appear).。

UML课后习题答案UML习题答案第⼀章⾯向对象设计与UML1．填空题（1）基本构造块UML规则公共机制（2）名字属性操作（3）封装继承多态（4）继承（5）瀑布模型喷泉模型基于组件的开发模型XP开发模型2. 选择题（1）C（2）A B C D（3）A B C D（4）A B C（5）A3.简答题（1）类是具有相同或相似结构、操作和约束规则的对象组成的集合，⽽对象是某⼀类的具体化实例，每⼀个类都是具有某些共同特征的对象的抽象。

类与对象的关系就如模具和铸件的关系，类的实例化结果就是对象，⽽对⼀类对象的抽象就是类.类描述了⼀组有相同特性和相同⾏为的对象。

（2）1.UML是⼀种语⾔。

2. UML是⽤来建模的。

3.UML是统⼀的标准。

（3）建模能够帮助我们按照实际情况或按我们需要的形式对系统进⾏可视化；提供⼀种详细说明系统的结构或⾏为的⽅法；给出⼀个指导系统构造的模板；对我们所做出的决策进⾏⽂档化。

在建模时应遵循以下原则：选择要创建什么模型对如何动⼿解决问题和如何形成解决⽅案有着意义深远的影响；每⼀种模型可以在不同的精度级别上表⽰；最好的模型是与现实相联系的；单个模型不充分；对每个重要的系统最好⽤⼀组⼏乎独⽴的模型去处理。

（4）UML和⾯向对象软件开发之间有紧密的关系，可以说是⾯向对象软件开发促使了UML 的产⽣。

但是由于在UML标准化的过程中，吸收了业务建模、⼯作流建模和数据库建模等领域的标准规范，形成了适应性很强的标准。

（5）在软件设计过程中，使⽤UML建模是为了能够更好地理解正在开发的系统。

通过UML 建模，可以达到以下⽬的：有助于按照实际情况或按照所需要的样式对系统进⾏可视化；能够规约系统的结构或⾏为；给出了指导构造系统的模板；对做出的决策进⾏⽂档化。

第⼆章UML通⽤知识点综述1.填空题（1）依赖泛化关联实现（2）视图图模型元素（3）实现视图部署视图（4）构造型标记值约束（5）规格说明修饰通⽤划分2. 选择题（2）C（3）A（4）A B（5）D3.简答题（1）在UML中，定义了四种基本的⾯向对象的事物，分别是结构事物、⾏为事物、分组事物和注释事物等。

13种uml简介、工具及示例UML（Unified Modeling Language）是一种用于软件开发的标准化建模语言，它使用图形表示法来描述软件系统的不同方面。

在软件开发过程中，使用UML可以帮助开发人员更清晰地理解系统的结构和行为，从而更好地进行设计和实现。

UML提供了包括结构模型、行为模型和交互模型在内的多种建模方式，其中每种模型都有各自的符号和语法规则。

通过使用这些模型，开发人员可以将系统分解成不同的部分，然后逐步细化这些部分的设计，以便更好地组织和管理项目。

在UML中，最常用的建模元素包括用例图、类图、时序图、活动图、状态图等。

每种图表都有其特定的用途和表达能力，开发人员可以根据实际需要选择合适的图表进行建模。

除了建模元素外，UML还定义了一系列的建模工具，这些工具可以帮助开发人员更高效地进行建模和分析。

其中一些常用的建模工具包括Enterprise Architect、Rational Rose、StarUML等。

下面将对13种UML简介、工具及示例进行详细介绍：1. 用例图（Use Case Diagram）用例图是UML中描述系统功能和用户交互的基本图表之一。

它用椭圆表示用例，用直线连接用例和参与者，展示了系统外部用户和系统之间的交互。

用例图可以帮助开发人员更清晰地理解系统的功能需求，从而指导系统的设计和实现。

示例：一个简单的在线购物系统的用例图包括用例“浏览商品”、“添加商品到购物车”、“提交订单”等，以及参与者“顾客”和“管理员”。

2. 类图（Class Diagram）类图是UML中描述系统结构和静态关系的基本图表之一。

它用矩形表示类，用线连接类之间的关系，包括关联关系、聚合关系、继承关系等。

类图可以帮助开发人员更清晰地理解系统的对象结构和类之间的关系，从而支持系统的设计和重构。

示例：一个简单的学生信息管理系统的类图包括类“学生”、“课程”、“教师”等，以及它们之间的关系如“选修”、“授课”等。

软件工程_东北大学中国大学mooc课后章节答案期末考试题库2023年1._______ is a discipline whose aim is the production of fault-free software,delivered on time and within budget, that satisfies the client's needs._______是一个学科，其目标是生产出满足客户的需求的、未超出预算的、按时交付的、没有错误的软件。

答案:2.The relationship between whole-class and part-classes is called ______.整体和部分类之间的关系被称为______。

答案:aggregation3.The relationship between super-class and subclasses is called ______.超类和子类之间的关系称为______。

答案:inheritance4.The strategy of inheritance is to use inheritance wherever _______.继承的策略是在_______的情况下使用继承。

答案:appropriate5._____is to encapsulate the attributes and operations in an object, and hides theinternal details of an object as possible. _____是为了在一个对象中封装属性和操作，并尽可能隐藏对象的内部细节。

Data encapsulation6.Two modules are ________ coupled if they have write access to global data.如果两个模块对全局数据具有写访问权限，则是________耦合。

UMLFD（gratfrei）是一个用于描述和分析软件系统的标准建模语言。

它是一种图形化的、非程序化的建模语言，旨在帮助软件开发人员更好地理解和设计复杂的系统。

UMLFD的全称是"Unified Modeling Language for Functional Dposition"，即面向功能分解的统一建模语言。

它是从UML （Unified Modeling Language）演化而来的，专门用于描述和分析软件系统的功能分解结构。

UMLFD的主要特点包括：1. 即可视化工具。

UMLFD提供了一套丰富的图形符号，可以帮助开发人员将系统的功能分解结构清晰地呈现出来。

2. 高度抽象化。

UMLFD的图形符号和标记都是一种高度抽象化的表达方式，可以将复杂的系统结构简化并清晰地呈现出来。

3. 面向对象。

UMLFD采用了面向对象的建模思想，可以轻松地描述系统中的对象、类、接口等概念。

4. 标准化和可扩展性。

UMLFD是一种标准的建模语言，具有良好的可扩展性和灵活性，可以满足不同系统的建模需求。

在软件系统的开发过程中，UMLFD被广泛应用于需求分析、系统设计和架构设计等环节。

通过使用UMLFD，开发人员可以更加清晰地了解系统的功能分解结构，从而更好地指导软件的开发和维护工作。

UMLFD（gratfrei）是一种非常重要的建模工具，它在软件系统的开发过程中发挥着重要作用。

随着软件系统的复杂性不断提高，UMLFD 的价值和作用也将越来越凸显。

希望更多的软件开发人员能够学习和掌握UMLFD，从而更好地应用于实际的软件开发工作中，为软件系统的开发和维护工作提供更好的支持。

UMLFD作为一种标准的建模语言，在软件系统的开发过程中发挥着重要作用。

除了在需求分析、系统设计和架构设计等环节中的应用外，UMLFD还能够帮助开发人员更加清晰地了解系统的功能分解结构，提供更好的支持和指导软件的开发和维护工作。

1. UMLFD在需求分析中的应用在软件系统的开发过程中，需求分析是至关重要的一环。

UML软件建模教程课后习题习题 1一、简答题1、简述模型的作用。

2、软件模型有什么特征？3、软件建模技术有哪些因素？4、软件模型包括哪些方面的内容？5、软件建模工具应该具有哪些基本功能？二、填空题1、模型是对现实的（）和模拟，是对现实系统（）特征的一种抽象、简化和直观的描述。

2、模型具有（）、直观性、（）和抽象性等特征。

3、从抽象程度，可以把模型分为（）、逻辑模型和（）三种类型。

4、较之于其他模型，软件模型具有（）、复杂性和（）等特征。

5、软件模型是软件开发人员交流的（），是软件升级和维护的（）。

6、软件建模技术的要素包括软件建模方法、（）、软件建模语言和（）。

7、从开发阶段看，软件建模有业务模型、（）、分析模型、（）和测试模型。

8、软件语言有软件需求定义语言、（）、软件建模语言、（）、软件程序设计语言等。

9、根据软件建模工具的独立性，把软件建模工具分为（）建模工具和（）建模工具。

10、OMG在（）年吧UML作为软件建模的标准，UML2.0版本是（）年颁布的三、选择题1、对软件模型而言，下面说法错误的是（）。

A.是人员交流的媒介B.是软件的中间形态C.是软件升级和维护的依据D.是软件的标准文档2、下面说法错误的是（）。

A.数据流图是面向功能软件建模方法提供的方法B.用例图是面向对象方法提供的建模方法C.类图是面向对象建模方法提供的建模方法D.ER图是面向数据建模方法提供的建模方法四、思考题1、软件为什么一定要建模？2、谈谈对下面这句话的理解：“软件是一种特殊的事物，它以一种可程式化和可动态复现的方式来反映人头脑中的可计算性意识，并通过这些意识的动态性外化，打到对客观以及人的主观意识的反映。

”习题 2一、简单题1、简述UML的发展过程。

2、作为一种统一建模语言，UML有哪些部分构成？3、元模型理论是UML的基础，元模型分为哪4个层次？4、聚集关系和组合关系有什么区别？5、用例与协作有什么区别？6、模型元素的可见性含义是什么？7、UML的构造型有什么作用？二、填空题1、1995年，G.BOoch和J.Rumbaugh在众多方法基础上提出了（），2005年UML推出了其（）版本。