软件工程翻译题--实施UML九项注意

习题参考答案Exercises(Homework): P251.3 What are the four important attributes that all professional software should have? Suggest four other attributes that may sometimes be significant.Answer:Four important attributes are maintainability, dependability, performance and usability. Other attributes that may be significant could be reusability (can it be reused in other applications), distributability (can it be distributed over a network of processors), portability (can it operate on multiple platforms e.g laptop and mobile platforms) and inter-operability (can it work with a wide range of other software systems).Decompositions of the 4 key attributes e.g. dependability decomposes to security, safety, availability, etc. is also a valid answer to this question.2.1Giving reasons for your answer based on the type of system being developed, suggest the most appropriate generic software process model that might be used as a basis for managing the development of the following systems:• A system to control anti-lock braking in a car• A virtual reality system to support software maintenance• A university accounting system that replaces an existing system • An interactive travel planning system that helps users plan journeys with the lowest environmental impactAnswer:1. Anti-lock braking system This is a safety-critical system so requiresa lot of up-front analysis before implementation. It certainly needs a plan-driven approach to development with the requirements carefully analysed. A waterfall model is therefore the most appropriate approach to use, perhaps with formal transformations between the different development stages.2. Virtual reality system This is a system where the requirements will change and there will be an extensive user interface components. Incremental development with, perhaps, some UI prototyping is the most appropriate model. An agile process may be used.3. University accounting system This is a system whose requirements are fairly ell-known and which will be used in an environment in conjunction with lots of other stems such as a research grant management system. Therefore, a reuse-based proach is likely to be appropriate for this.4. Interactive travel planning system System with a complex userinterface but which must be stable and reliable. An incremental development approach is the most appropriate as the system requirements will change as real user experience with the system is gained.2.4Suggest why it is important to make a distinction between developing the user requirements and developing system requirements in the requirements engineering process.Answer:There is a fundamental difference between the user and the system requirements that mean they should be considered separately.1. The user requirements are intended to descri be the system’s functions and features from a user perspective and it is essential that users understand these requirements. They should be expressed in natural language and may not be expressed in great detail, to allow some implementation flexibility. The people involved in the process must be able to understand the user’s environment and application domain.2. The system requirements are much more detailed than the user requirements and are intended to be a precise specification of the system that may be part of a system contract. They may also be used in situations where development is outsourced and the development team need a complete specification of what should be developed. The system requirements are developed after user requirements have been established.Excercises(Homework): P1164.2，*4.44.2Discover ambiguities or omissions in the following statement of requirements for part of a ticket-issuing system:An automated ticket-issuing system sells rail tickets. Users select their destination and input a credit card and a personal identification number.The rail ticket is issued and their credit card account charged. When the user presses the start button, a menu display of potential destinations is activated, along with a message to the user to select a destination. Once a destination has been selected, users are requested to input their credit card.Its validity is checked and the user is then requested to input a personal identifier. When the credit transaction has been validated, the ticket is issued.Answer:Ambiguities and omissions include:●• Can a customer buy several tickets for the same destination togetheror must they be bought one at a time?●• Can customers cancel a request if a mistake has been made?●• How should the system respond if a n invalid card is input?●• What happens if customers try to put their card in before selectinga destination (as they would in ATM machines)?●• Must the user press the start button again if they wish to buy anotherticket to a different destination?●• Shou ld the system only sell tickets between the station where themachine is situated and direct connections or should it include all possible destinations?4.4Write a set of non-functional requirements for the ticket-issuing system, setting out its expected reliability and response time.Answer:Possible non-functional requirements for the ticket issuing system include:1. Between 0600 and 2300 in any one day, the total system down time should not exceed 5 minutes.2. Between 0600 and 2300 in any one day, the recovery time after a system failure should not exceed 2 minutes.3. Between 2300 and 0600 in any one day, the total system down time should not exceed 20 minutes.All these are availability requirements –note that these vary according to the time of day. Failures when most people are traveling are less acceptable than failures when there are few customers.4. After the customer presses a button on the machine, the display should be updated within 0.5 seconds.5. The ticket issuing time after credit card validation has been received should not exceed 10 seconds.6. When validating credit cards, the display should provide a status message for customers indicating that activity is taking place. This tells the customer that the potentially time consuming activity of validation is still in progress and that the system has not simply failed.7. The maximum acceptable failure rate for ticket issue requests is 1: 10000.Excercises(Homework): P143-1445.2，5.5，5.6，5.75.2How might you use a model of a system that already exists? Explain whyit is not always necessary for such a system model to be complete and correct. Would the same be true if you were developing a model of a new system?Answer:You might create and use a model of a system that already exists for the followingreasons:1. To understand and document the architecture and operation of the existingsystem.2. To act as the focus of discussion about possible changes to that system.3. To inform the re-implementation of the system.You do not need a complete model unless the intention is to completely document the operation of the existing system. The aim of the model in such cases is usually to help you work on parts of the system so only these need to be modelled. Furthermore, if the model is used as a discussion focus, you are unlikely to be interested in details and so can ignore parts of the system in the model.This is true, in general, for models of new systems unless a model-based approach to development is taking place in which case a complete model is required. The other circumstances where you may need a complete model is when there is a contractual requirement for such a model to be produced as part of the system documentation.5.5Develop a sequence diagram showing the interactions involved when a student registers for a course in a university. Courses may have limited enrolment, so the registration process must include checks that places are available. Assume that the student accesses an electronic course catalog to find out about available courses.Answer:A relatively simple diagram is all that is needed here. It is best not to be too fussy about things like UML arrow styles as hardly anyone can remember the differences between them.5.6Look carefully at how messages and mailboxes are represented in the email system that you use. Model the object classes that might be used in the system implementation to represent a mailbox and an e-mail message. Answer:5.7Based on your experience with a bank ATM, draw an activity diagram that models the data processing involved when a customer withdraws cash from the machine.Answer:Notice that I have not developed the activities representing other services or failed authentication.Excercises(Homework): P173-1746.1,6.3,6.96.1When describing a system, explain why you may have to design the system architecture before the requirements specification is complete.Answer:The architecture may have to be designed before specifications are written to provide a means of structuring the specification and developing different subsystem specifications concurrently, to allow manufacture of hardware by subcontractors and to provide a model for system costing.6.3Explain why design conflicts might arise when designing an architecture for which both availability and security requirements are the most important non-functional requirements.Answer:Fundamentally, to provide availability, you need to have (a) replicated components in the architecture so that in the event of one component failing, you can switch immediately to a backup component. You also need to have several copies of the data that is being processed. Security requires minimizing the number of copies of the data and, wherever possible, adopting an architecture where each component only knows as much as it needs to, to do its job. This reduces the chance of intrudersaccessing the data.Therefore, there is a fundamental architectural conflict between availability (replication, several copies) and security (specialization, minimal copies). The system architect has to find the best compromise between these fundamentally opposing requirements.6.9Using the basic model of an information system as presented in Figure 6.16, suggest the components that might be part of an information system thatallows users to view information about flights arriving and departing from a particular airport.Answer:Students should consider the levels in the information system and should identify components that might be included at each level. Examples of these componentsmight be:Level 1 (Database level)Flight database; Flight status database; Airport information; Level 2: (Information retrieval level)Status management; Flight management; Search;Level 3: (User interaction level)Authentication; session management; forms processing () Level 4 (User interface)Input checking (Javascript), browserExcercises(Homework): P202-2037.1, 7.37.17.1 Using the structured notation shown in Figure 7.3, specify the weather station use cases for Report status and Reconfigure. You should make reasonable assumptions about the functionality that is required here.Answer:7.37.3 Using the UML graphical notation for object classes, design the following object classes, identifying attributes and operations. Use your own experience to decide on the attributes and operations that should be associated with these objects.• a telephone• a printer for a personal computer• a personal stereo system• a bank account• a library catalogueAnswer:There are many possible designs here and a great deal of complexity can be added to the objects. However, I am only really looking for simple objects which encapsulate the principal requirements of these artefacts. Possible designs are shown in the above diagram.。

一、名词解释：用例：是外部可见的系统单元，这些功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。

泳道:在活动图中，泳道用垂直实线绘出，垂直线分隔的区域就是泳道；组件：组件是定义了良好接口的物理实现单元，是系统中可替换的物理部件.双向工程:双向工程包括正向工程和逆向工程.正向工程就是从模型到代码，而逆向工程则是从代码到模型.正向和逆向工程结合在一起叫双向工程。

对象流：对象流是动作状态或者活动状态与对象之间的依赖关系,表示动作使用对象或者动作对对象的影响。

二、填空题1、UML中的模型元素包括事物和事物之间的联系。

2、Rational Rose包括了统一建模语言、面向对象的软件工程及对象建模技术。

3、时序图包含的4个元素有对象、生命线、消息、激活 .4、协作图以对象图的方式绘制各个参与对象，并且将消息和链平行放置。

5、组件是定义了良好接口的物理实现单元,是系统中可替换的物理部件.6、状态机包含了一个类的对象在其生命期间所有状态的序列以及对象对接收到的事件所产生的反应。

7、包图建模技术包括对成组的元素建模和对体系结构视图建模。

8、内部转换只有一个原状态但是没有目标状态 ,因此转换后并不改变状态本身。

9、分叉可以用来描述并发线程，每个分叉可以有一个输入转换和两个或多个输出转换.10、配置图描述了系统执行处理过程中系统资源元素的配置情况以及软件到这些资源元素的映射.三、1。

简述时序图的建模步骤。

如何识别用例？答：建模步骤：1）设置交互语境；2)确定对象；3）分析消息和条件;4）分析附加约束；5)对建模结果精化和细化2。

Rational Rose中有哪几种视图，各个视图的作用是什么？答：Rational Rose有四种视图：①用例视图:用例视图是被称为参与者的外部用户所能观察到的系统功能的模型图。

用例是系统中的一个功能单元，可以被描述为参与者与系统之间的一次交互作用。

用例模型的用途是列出系统中的用例和参与者,并显示哪个参与者参与了哪个用例的执行. 用例视图是其他视图的核心,它的内容直接驱动其他视图的开发。

填空题第一章(1)统一建模语言UML是绘制软件蓝图的标准工具语言，可以对软件系统产品进行说明、可视化、构造和编制文档。

(2)UML在实际软件项目中，可以用于构造各种类型系统的业务模型和软件模型。

(3)软件的开发模式有瀑布模型、喷泉模型、基于构件的开发模型和XP方法。

(4)面向对象程序的三大要素是多态、封装和继承。

(抽象)(5)瀑布模型的缺点是缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。

第二章(1) 在UML中，静态视图包含有两种视图，分别是类图和对象图。

(2) 规格说明，修饰，拓展划分是UML常用的通用机制。

(3) 够造型，标记型，约束是UML常用的扩展机制。

(4) 用例视图描述了系统的参与者与系统进行交互的功能，是参与者所能观察和使用到的系统功能的模型图。

(5) 状态图是通过对象的各种状态来建立模型来描述对象的随时间变化的动态行为，并且它是独立的对象为中心进行描述。

第三章(1)Rational Rose默认支持的目标语言主要包括 Java、Visual Basic等。

（C++，C#）(2) 部署视图显示的是系统的实际部署情况,它是为了便于理解系统如何在一组处理解节点上的物理分布，而在分析和设计中使用的架构视图。

(3)使用R ational Rose 生成代码的步骤包括选择待转换的目标模型、检查Java语言的语法错误、设置代码生成属性、生成代码。

(4)在用例视图中包括了系统中的所有参与者、用例和用例图，必要时还可以在其中添加顺序图、协作图、活动图和类图等。

(5) 构件视图用来描述系统中的各个实现模块以及它们之间的依赖关系包含模型代码库、执行文件、运行库和其他构件等信息。

第四章(1)对象图的目的在于描述系统中参与交互的各个对象在同一时刻是如何运行的。

(2)链是两个或多个对象之间的独立连接，是关联的实例。

(3)在UML的图形表示中，类是由名字、属性和方法三个部分组成的。

(4)依赖关系使用一个从客户指南提供者的虚箭头来进行表示。

UML课后习题答案第1章UML概述1. 请指出UML的三个主要的特性。

1）UML是一种语言2）UML是用来建模的3）UML是统一的标准2. 请指出三种以上现实生活中的常用模型，并说明它们分别在各自的领域中发挥了什么样的作用。

1）电路图：电子产品设计、生产、维修2）园区沙盘：直观、立体化地展示园区的景观、布局3）地图：导航、指路等3. 请说明蓝图和草图的区别，并简单描述其适用的场景。

蓝图一般是指采用CASE(Computer Aided（or Assisted）Software Engineering)工具绘制的、正式的、规范的UML模型；而草图则通常是指手工绘制的、规范度较低的在纸张的UML模型。

对于局部的、重要性不高的、共享范围较小的UML模型，直接将草图扫描到电脑存档即可；对于全局的、重要性高的、高度共享的，在草图的基础上用CASE工具绘制成为正式的蓝图，并将其纳入统一的模型管理中4. 说明UML适用的建模领域，以及其作用和主要的参与人员。

业务建模，用来加强对业务领域的了解，以领域专家为主，需求分析人员是主力，系统分析员、架构师可参与。

需求模型，用来加强需求了解，便于技术决策，以需求分析人员为主，系统分析员是主力，领域专家提供指导，架构师和资深开发人员参与。

设计模型：包括高层设计模型和详细设计模型。

高层设计模型以架构师为主，系统分析员从需求方面提供支持，资深开发人员从技术实现方面提供支持。

详细设计模型则以资深开发人员为主，架构师提供指导。

实现模型：架构师、资深开发人员（设计人员）；以资深开发人员（设计人员）为主，架构师提供总体指导。

数据库模型：架构师、数据库开发人员、资深开发人员（设计人员）；以数据库开发人员为主，架构师提供指导，资深开发人员（设计人员）予以配合。

第2章UML世界的构成1. UML是由哪三个部分组成的，请分别说明它们的作用。

基本构造块：也就是建模元素，是模型的主体UML规则：也就是支配基本构造块如何放在一起的规则公共机制：运用于整个UML模型中的公共机制、扩展机制2. 请列举出三个以上UML中的事物构造块，并说明适合用来表示“系统向用户提供的功能”的构造块是什么。

实施UML九项注意（英文）In the last quarter of 1997, I taught object-oriented analysis and design with UML to a wide range of developers working on various projects. The projects spanned application domains including retail shelf space management, pharmaceutical clinical trials, cellular telephony, and more. Implementation languages included Visual Basic, C++, Java, DB2, and others. This article discusses several aspects of how well the UML notation, along with my company's use case-driven Unified Object Modeling process (also based on the methods of Booch, Jacobson, and Rumbaugh), met the demands of a diverse set of projects. It provides practical guidance for tailoring your use of UML for various projects.The UML notation is big (maybe too big) and is flexible enough to accommodate the needs of a very wide range of projects. To succeed with UML, you must streamline how you use it. Different projects will need different pieces. Which specific elements of the UML notation you need for your project will depend on its nature (client/server with a mainframe RDBMS vs. real-time embedded, for example) and on the implementation language you will be using. Some detailed C++ design constructs are not needed if you're building in Java or Smalltalk, and you may want to avoid too much use of generalization or inheritance if you're building in Visual Basic. Sometimes, the sheer volume of modeling constructs can be overwhelming, especially to those students who are new to object-oriented analysis and design. However, the good news is that you can model almost anything using UML. There are plenty of modeling constructs to go around.You Still Need a ProcessUML itself is only a notation; to build effective models, you still need a modeling process. There are many modeling approaches you can use with UML; the modeling language itself does not prescribe the process. My company has been successful teaching a slightly modified version of the Objectory process (derived from Ivar Jacobson's Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992) that we developed as a synthesis of Booch/Rumbaugh/Jacobson several years prior to the advent of UML. Our approach places slightly more emphasis on identifying high-level static models (domain models) up front, in parallel with use cases. We then refine the static model iteratively and incrementally refine as we explore the use cases and dynamic models.Whether you prefer using Objectory, Object Modeling Technique, our ICONIX Unified Object Modeling process, or some other approach, it's important to understand that UML is not a process, and that it is critically important to get your project team on the same page process-wise before undertaking a modeling effort. Once again, the size and bulk of UML (and the overwhelming weight of documentation on notation as opposed to process) can make it easy to slip into "analysis paralysis." Focusing the team on an understandable process that is supported by the UML notation can generally get the modeling effort underway.Legacy Methods Are ImportantMany of my students ask whether developing an understanding of Booch, Jacobson, and Rumbaugh's legacy methods is still important. My answer is an emphatic yes. Just as knowing the symbols used for electronic circuit design doesn't eliminate the need to know circuit theory, understanding thenotational aspects of UML doesn't eliminate the need to understand object modeling theory. Since UML represents the synthesis of the works of Jacobson, Booch, and Rumbaugh, the original legacy methods are a rich source of this information.Keep It Simple保持简单Getting a project team to make effective use of UML is tricky. Team members will have varied experience with object-oriented analysis and design and UML. A training workshop is a good way to begin. The workshop needs to be tailored to the specific needs of each project, taking the backgrounds of the various team members into careful consideration. The most critical tailoring decisions will ultimately involve judicious choices of what gets left out of the course agenda, as well as the instructor's ability to adjust on-the-fly during the workshop.One of the most important things to remember when learning UML is that you don't need to use every construct just because it's there. Keep the process as simple as possible. Streamlining a project's documentation set and modeling approach does wonders for generating forward momentum.Modeling with UML is similar to sitting down to an huge plate of food-sometimes, the thought that you can't possibly eat everything on the plate just kills your appetite before you get started. A similar phenomenon can occur with UML modeling. The thought of having to produce a complete set of sequence, collaboration, state, deployment, use case, and class diagrams that comprehensively covers each and every use case of the system with a fully detailed dynamic model can intimidate a team right out of object-oriented analysis and design.The same thought process holds true for determining which constructs are employed within a given modeling technique. Forexample: is it really necessary to employ both USES and EXTENDS on a use case diagram, or can we live with just USES? My experience has been that the more streamlining that gets done, the better the chances of the modeling effort being carried through.Write the User Manual Before You Design the ClassesOne of the old saws of programming is to write the user manual before you write the code. This was good advice when I learned it, and it's still good advice today. In the days of structured methods, and in the early days of object-oriented methods, it was seldom followed. In his use case-driven modeling approach, Jacobson codified this maxim into a series of steps that work for object orientation and can be described using UML. Each step builds upon the previous step in a traceable manner, so that ultimately, management can enforce this approach as a design paradigm and verify that it has been followed at each step in the analysis and design process.The key to understanding the essence of Objectory and use case-driven object modeling at the fundamental level is simple: write the user manual before you design the classes. Keeping this idea in the front of your mind will help guide you as you travel through the maze of UML static and dynamic model notations. Each use case represents a portion of the user manual, and should be written that way if the goal of your use case analysis is to produce an object model.Organize Use Cases into Packages用例打包As you begin to write the user manual for your system one use case at a time, you will immediately run into the need for a high-level organization of use cases. UML lets you organize your use cases into packages. These are represented as tabbed-foldericons. Each package should consist of at least one use case diagram, which will serve as a context diagram under which you can link all the use case descriptions along with the design-level dynamic model views for each use case. Some projects start with a top-level breakdown of one package per top-level menu. While this breakdown does not always represent the final breakdown, it's sometimes a helpful starting place.Use the Objectory StereotypesSince we're driving the entire design process from the use cases, it makes sense to focus strongly on describing them in the "right" way. While it's becoming increasingly popular to employ use cases as an alternative to requirements specifications and for business process modeling, and while these styles of use case modeling have somewhat different guidelines, most projects I've run across still view use cases as a way to get to an object model.Jacobson's original OOSE/Objectory process included a phase called Robustness Analysis, wherein use case descriptions were analyzed to determine a rough first cut at a collaborating set of objects. While doing this analysis, Jacobson proposed classifying the objects identified into Interface Objects, Control Objects, and Entity Objects.This small, quick modeling step produces an amazing set of benefits. It helps people write use cases correctly, identify client/server and model-view-controller design information early, and perhaps most important, identify reusable objects by enabling a quick breadth-first pass across all the use cases. It also fills the void between requirements analysis and detailed design.Unfortunately, for some reason, the notation for Robustness Analysis (three easy-to-draw symbols), only partially survived the transition into UML. The notation still exists, but has beenbanished to a separate document called the Objectory Process Specific Extensions, and tool support is often lacking. I teach Robustness Analysis as an integral part of describing use cases (the diagram becomes a sanity check for the text), and have found that students readily adapt to this object shorthand.Important QuestionsYou can reduce the entire domain of object-oriented analysis and design to two simple questions: First, what are the objects in the system? Second, how is the required system behavior distributed among these objects?While this is somewhat of an over-simplification of a subject that has been the topic of thousands of pages of methodology textbooks, it fundamentally isn't too far off the mark. If you've identified the right set of objects to build, and if you've done a good job of allocating the desired system behavior to the most appropriate set of classes, your project should be in good shape. The tricky part is really the innocent-sounding phrase "done a good job of allocating behavior"; this is where experienced object-oriented designers earn their living.Drive the Static Model from the Dynamic ModelsNo matter which process you decide to use with UML, it's good practice to drive the design of the static model (class diagrams) from the dynamic models, starting from use cases at the high level, and particularly leveraging the UML Sequence Diagram to allocate behavior among your classes. This philosophy, which has its roots in Jacobson's OOSE/Objectory process, was first explained to me around 1993 by a friendly Objectory consultant. As I've continued to teach it as a design style over the last four years, I've grown increasingly convinced of its wisdom and (thus far) universal applicability.The essence of the idea is this: we can start out and get a rough approximation of the core set of objects in a system by following an Object Modeling T echnique-like strategy of identifying "real-world" or "problem domain" objects using techniques such as looking for nouns in the problem statement. Sometimes, we can make intelligent guesses as to when a particular class might be an appropriate container for a specific operation; however, often in the process of object-oriented design, we find that the original guesses that we made when considering the static models in the absence of exploring the use cases were naive.Based on my experience, the reality of object-oriented analysis and design is that the only really good way to approach the (difficult) problem of allocating behavior among a set of classes is to explore the use case at a detailed (message passing/method invocation) level. Whether formally or informally, most senior object-oriented designers I've met arrive at their designs this way. When the approach is informal (not visible), a cloud of mystery sometimes surrounds how a designer arrived at a specific solution from a given set of domain objects and use cases. Often, this cloud of mystery is deepened by oblique explanations using a litany of jargon such as "multiple polymorphic encapsulated interfaces." This tends to limit the amount of useful design review that can be accomplished by team members and leaves the intrepid programmer free to implement as he or she sees fit.In my experience, however, this design approach is best accomplished using a sequence diagram in UML (see "How the UML Models Fit Together" Focus on UML, page SR4, for an example of a sequence diagram), with the original (requirement-level, user manual view) text of the parent use case shown along the left margin, and the actual detailed dynamic behavior, showing each method invocation and the message that invokes it, in the body of the diagram. Showing the detailed design and the requirement-level textual use case description on the same page provides a quick "eyeball" requirements trace, which verifies that, for at least this use case, your design matches the requirements. Simply repeat this for all the use cases of your system, and you have a traceable design.While drawing the sequence diagrams, you'll identify specific operations and assign them to specific objects within your design. You're actually building the static class model, even though you're drawing dynamic model (sequence) diagrams at the same time. The sequence diagram is the vehicle that teaches us how much we don't know when we explore the object model in the abstract.Defer Assigning Operations to ClassesDon't worry too much about specifying which operations go in which classes during the analysis phase of your project. You'll probably get the mapping wrong anyway, except in the most obvious cases (and sometimes even then). Experience teaches that these behavior allocation decisions are best made very carefully, one at a time, as the dynamic models are explored.Keeping this separation in mind (Analysis: what are the objects? Design: how is the behavior allocated?) helps project teams define the boundary between analysis and design. Our original Unified Object Modeling process approach used the Object Modeling T echnique notation at the analysis level, and the Booch notation for design. The Object Modeling Technique was applied during analysis using the Booch method for detailed,design-level models. With UML, these notations have been merged into a single, Object Modeling Technique-flavored class diagram. As the line between analysis and design notations has blurred, project teams often experience difficulty in understanding where the analysis and design boundary is.Even though I teach an iterative and incremental process, a requirements review and a design review must be included at some logical point. If I'm reviewing an analysis model, I'm not particularly concerned whether or not the classes have operations showing (in most cases, I'm just as happy if they don't). I'm looking for a good set of domain classes and a comprehensive use case model. For a design review, however, all operations should be accounted for, and there must be visual traceability between the requirements and the design on the sequence diagrams. The designer must also be able to defend his or her decisions as to why any given operation was placed in a particular class.Simply SuccessfulThe most important things to keep in mind as you apply UML to your project are to keep it simple, write the user manual first (one use case at a time), and get your project team on the same page regarding process. Remember, UML specifies a notation, not a process. The most successful projects I've seen are adopting use case-driven, iterative, and incremental approaches. If you tailor your process to the individual parameters of your project and to the skill set of your team, your UML project will be marked for success.。

UML课后习题答案整理目录第1章面向对象分析与设计引论41.1填空题42.1选择题43.1简答题4第2章统一建模语言UML与建模工具Rational Rose51.1填空题52.1选择题53.1简答题5第3章需求分析与用例模型71.1填空题72.1选择题73.1简答题74.1练习题7第4章系统静态分析与静态模型131.1填空题132.1选择题133.1简答题134.1练习题14第5章系统动态分析与交互模型151.1填空题152.1选择题153.1简答题154.1练习题16第6章系统动态分析与行为模型、191.1填空题192.1选择题193.1简答题204.1练习题21第7章系统设计与实现模型261.1填空题262.1选择题263.1简答题264.1练习题27第8章软件工程引论与统一软件过程RUP281.1填空题282.1选择题283.1简答题28第9章分工情况31第1章面向对象分析与设计引论1.1填空题（1）面向过程程序=算法+数据结构（2）对象（3）属性操作2.1选择题（1）A（2）A3.1简答题（1）面向过程方法和面向对象方法的比较：面向过程方法首先关心的是功能，强调以过程为中心，采用模块化、自顶向下、逐步细分的解决问题的方法，结构清晰、可读性好。

然而，由于用户的需求和软、硬件技术的不断发展变化，经常出现互相矛盾的数据需求，因此分析和设计越来越困难，开发过程前期入手快而后期频繁改动的现象比较常见。

面向对象方法则从所处理的数据入手，以数据为中心来描述系统。

数据相对于功能而言，具有更强的稳定性，这样设计出的系统模型往往能较好地映射问题域模型。

面向对象方法的有效性：面向对象程序设计是一种自下而上的程序设计方法，往往从问题的一部分着手，一点一点地构建出整个程序。

面向对象设计以数据为中心，类作为表现数据的工具，成为划分程序的基本单位。

面向对象是把构成问题的事物分解成各个对象，建立对象的目的不是为了完成一个步骤，而是为了描述某个事物在整个解决问题的步骤中的行为。

用UML建模需要注意的问题用UML建模时，对软件开发过程是有要求的，必须是用例驱动，以架构为中心，迭代和递增的开发，如果软件开发组织的软件开发过程不能满足这三点要求，那么UML的使用效果就会大打折扣，下面详细论述：一、用例驱动用例驱动意味着为系统定义的用例是整个开发过程的基础。

用例在多个核心工作流程中都发挥了作用。

1、用例的概念可用来表示业务流程，我们称这种用例的变体为“业务用例”。

2、用例模型是需求工作流程的输出结果。

在这一早期流程中，需要通过用例来建立用户希望系统完成的任务的模型。

这样，用例构成了一个重要的基本概念，客户和系统开发人员都必须认可这个概念。

3、在分析设计中，用例是在设计模型中实现的。

您需要生成用例实现来说明在设计模型中如何通过对象的交互来执行用例。

此模型根据设计对象来说明所实施系统的各个组成部分，以及这些部分如何通过相互作用来执行用例。

4、在实施阶段，设计模型就是实施的规约。

由于用例是设计模型的基础，所以用例需通过设计类来实施。

5、在测试期间，用例是确定测试用例和测试过程的基础。

也就是说，通过执行每一个用例来核实系统。

6、在项目管理过程中，用例被用来作为计划迭代式开发的基础。

7、在部署工作流程中，它们构成用户手册阐述内容的基础。

用例也可用来确定产品构件如何排列组合。

例如，客户可通过将用例进行某种组合来配置一个系统。

二、以架构为中心构架之所以重要，原因有以下几点：1、它使您可对项目进行并保持理智的控制，应付项目中复杂多变的情况，同时保持系统的完整性。

一个复杂的系统不仅仅是其各组成部分之和，也不光是一连串没有关联关系的、很小的技巧决定。

它必须依靠某种连贯统一的结构来有条理地组织那些部分，并且提供准确的规则，使系统发展过程中，其复杂程度不会膨胀，超越人类的理解力。

通过建立用于讨论设计问题的一套公共参考材料和一个公共词汇表，构架提供了增进交流和理解的手段。

2、它是大规模复用的有效基础。

绘制UML序列图时必须注意的六个问题5篇范文第一篇：绘制UML序列图时必须注意的六个问题本文和大家重点讨论一下UML序列图绘制的相关内容，如何养成良好的绘制UML序列图的习惯呢？通过本文介绍的这些方法可以帮助您养成良好的习惯，同时提高UML序列图的质量和效力。

养成良好的绘制UML序列图的习惯请尝试本文所介绍的技巧来创建有效的UML序列图。

本文改编自TheObjectPrimer2ndEdition的第6章。

有一些方法可以帮助您提高UML序列图的质量和效力。

它们包括：◆和主题问题专家一起验证决策◆使解决方案尽量简单◆为绘制消息和返回值选择一种一致而有效的风格◆将UML序列图分层◆遵循一致的逻辑风格◆牢记UML序列图是动态的1.验证决策在开发图1UML序列图的过程中，我做了一些对其它模型可能有潜在影响的决策。

例如，在对第10步建模时，假设（大致上是个设计决策）费用显示屏幕同时也处理学生对费用是否可接受所进行的验证。

该决策应该由用户界面原型反映出来，并由主题问题专家(SME)进行验证。

您应该和SME（特别是那些对于如何开发类似模型有着深刻见解的富有经验的人）一起执行UML序列图的绘制工作。

2.保持简单在对第2和第3步建模时，我忽然意识到学生可能应该使用口令进入系统。

在向SME提出了这个概念后发觉我错了：姓名和学号组合对于我们的目的来说已经足够唯一，并且学校也不希望增加复杂的口令管理。

这是个很有意思的决策，因为这是学校的一个运作策略，所以可以作为一条商业规则记载到增补规范中。

通过与SME一起检验这个想法，而不是假定我比他们知道得更多，我避免了“镀金”的机会，因而减少了我们小组开发这一系统所需的工作。

3.绘制消息和返回值我更喜欢从左至右地绘制消息，从右至左地绘制返回值，尽管这样对于复杂的对象／类来说不总是非常合适。

我将消息上的标签和返回值对齐到离箭头最近的位置。

我不喜欢在UML序列图上标出返回值，为的是使图尽可能地简化。

ATM建模1、浏览器和框图窗口之间有关系吗？如果有，是怎么样的关系？答：有。

我们可以用浏览器打开一个或几个UML框图。

改变框图中的元素时，Rose自动更新浏览器。

同样用浏览器改变元素时，Rose自动更新相应框图。

这样，Rose就可以保证模型的一致性。

2、用例图中的参与者和用例分别表示什么？答：从用例图中我们可以看到系统干什么，与谁交互。

用例是系统提供的功能（系统“干什么”），参与者是系统与谁交互，参与者可以是人、系统或其他实体。

3、ATM用例图中的箭头从参与者指向用例表示什么?从用例指向参与者又表示什么？答：箭头从参与者到用例表示由参与者启动用例。

箭头从用例到参与者表示用例产生一些参与者要使用的信息。

4、RUP有哪五个工作流程？我们在RUP的哪个工作流程中画用例图？答：RUP（统一软件开发过程）的五个核心工作流程包括：需求捕获、分析、设计、实现和测试。

在需求捕获时画用例图。

5、活动图中的泳道表示什么意思？答：泳道是活动图里的竖段，包含特定人员或组织要进行的所有活动。

可以把活动图分为多个泳道，每个泳道对应每个人员或组织，他们各自的活动都放在各自的泳道中。

6、活动图中的同步棒表示什么意思？答：表示并发控制流的分叉和汇合。

结合图中具体来说，同一段时间内这几个活动同时发生/这几个活动都结束之后才进入下个决策点的判断中。

7、活动图中的初始状态和终止状态分别用什么表示？数目上有什么限制？答：实心圆和牛眼。

初始状态必须有，而且只能有1个。

终止状态可以是0，1或多个。

8、活动图中决策点之后的[ ]里的内容是什么，有什么要求？答：保证条件，用来控制在决策之后采取什么路径。

保证条件应该是互斥的。

9、类由哪几部分组成，分别表示什么意思？答：类图中每个类都是用方框表示的，分成三个部分。

第一部分是类名；第二部分是类包含的属性，属性是类和相关的一些信息；最后一部分包含类的方法，方法是类提供的一些功能。

10、类的属性和方法左边有一些修饰，分别表示什么意思？答：若是一个小锁图标，表示这个属性和方法是private的(UML中用’－’表示)，该属性和方法只在本类中可访问。

UML课后习题答案要点填空题第⼀章第⼆章常⽤的通⽤机制。

的系统功能的模型图。

(5) 并且它是独⽴的对象为中⼼进⾏描述。

第三章(1)Rational Rose默认⽀持的⽬标语⾔主要包括C++，C#）,它是为了便于理解系统如何在⼀组处(3)使⽤R ational Rose库、执⾏⽂件、运⾏库和其他构件等信息。

(3)在UML第五章1（2）包的可见性关键字包括（3三层结构。

（5第六章(1)例图。

(3)(4)第七章(1)在UML时(2)(4)(5)第⼋章表⽰⼀个程序或⼯作流，常⽤于计算机流程和⼯作流程建模。

每⼀组表⽰⼀个特定的类、⼈或部门、他们完成组内的活动。

第九章1.uml的交互图中，强调对象之间关系和消息传递的是（协作图）。

2.（结构图）的作⽤体现在显⽰对象及其交互关系的空间组织结构。

3.在协作图中的（链）是两个或多个对象之间的（连接）关联的实例。

4.uml中，对象⾏为是对象间为完成某⼀⽬的⽽进⾏的⼀系列消息传递，消息序列可⽤（顺序号）和（消息的名称）来表⽰。

5. uml中的协作图强调的是交互对象的整体结构，是按照（空间结构）进⾏布图。

24在uml中的图。

第⼗⼀章1.填空题理实现。

（2）在UML（3（4资源建模。

第⼗⼆章1.填空题的集合。

(2)Rational在每⼀次迭代中以不同的重点和强度重复。

(3)解决⽅案的软件开发⽅式。

(5)Rational选择题第⼀章(1) 对象程序的基本特征是（ABCD）A.抽象B.封装C.继承D.多态(2)类包含的要素有（ABC）A.名字B.属性C.操作D.编号(3)下列关于类与对象的关系说法不正确的是（A）A.有些对象是不能被抽象成类的B.类给出了属于该类的全部对象的抽象定义C.类是对象集合的再抽象D.类是⽤来在内存中开辟⼀个数据区，存储新对象的属性(4)⾯向对象⽅法中的（C）机制给予⼦类可以⾃动的拥有（复制）⽗类全部属性和操作。

B.封装C.继承D.多态(5)建⽴对象的动态模型⼀般包含的步骤有（ABCD）A.准备脚本B.确定事件C.准备事件跟踪表D.构造状态图第⼆章⑴UML中的关系元素包括(ABCD)。