軟件工程英文教學課件：Ch6 Requirements Modeling Scenarios, Information, and Analysis Classes

1、1Chapter 6Requirements Modeling: Scenarios, Information, and Analysis Classes Software Engineering: A Practitioners Approach, 7/e by Roger S. Pressman2Requirements AnalysisRequirements analysis specifies softwares operational characteristicsindicates softwares interface with other system elements es

2、tablishes constraints that software must meetRequirements analysis allows the software engineer (called an analyst or modeler in this role) to:elaborate(精化) on basic requirements established during earlier requirement engineering tasksbuild models that depict user scenarios, functional activities, p

3、roblem classes and their relationships, system and class behavior, and the flow of data as it is transformed. 3A Bridge44Two analysis modelStructured analysis (SA) Objectoriented analysis (OOA) 功能(用例) 模型 對象/行為模型 屬性、 協(xié)作 操作、 對象/關 系模型 5Elements of Requirements Analysis6Scenario-Based Modeling“Use-cases

4、 are simply an aid to defining what exists outside the system (actors) and what should be performed by the system (use-cases).” Ivar Jacobson(1) What should we write about?（描述什么）(2) How much should we write about it?（描述多少）(3) How detailed should we make our description? （描述多細）(4) How should we organ

5、ize the description?（描述結構） 7What to Write About?Inception and elicitationprovide you with the information youll need to begin writing use cases. Requirements gathering meetings, and other requirements engineering mechanisms are used to define the problem scopespecify overall operational goalsoutline

6、 all known functional requirementsdescribe objects that will be manipulated by systemTo begin developing a set of use cases, list the functions or activities performed by a specific actor.(考慮每一個角色是如何使用系統(tǒng)的)8How Much to Write About?As further conversations with the stakeholders progress, the requireme

7、nts gathering team develops use cases for each of the functions. use case diagrama scenario that describes a “thread of usage” for a systemactors represent roles people or devices play as the system functionsusers can play a number of different roles for a given scenario9Use-Case Diagrama scenario t

8、hat describes a “thread of usage” for a systemactors represent roles people or devices play as the system functionsusers can play a number of different roles for a given scenario2022/7/1810狀態(tài)是對象執(zhí)行了一系列活動的結果。當某個事件發(fā)生后，對象的狀態(tài)將發(fā)生變化，這種變化用狀態(tài)圖來表示。狀態(tài)圖描述了單個對象在其整個生命周期中的行為。狀態(tài)圖由對象的狀態(tài)及狀態(tài)間的遷移構成。它既可用于模擬系統(tǒng)對象按事件發(fā)生順序產生

9、的各種行為，還可描述用例的一個腳本。狀態(tài)是對象屬性值的抽象，有時間上的持續(xù)性，可分為初始狀態(tài)（用實心圓表示）、最終狀態(tài)（用同心圓表示）、中間狀態(tài)等。事件是指定時刻發(fā)生的事情，沒有持續(xù)時間。通常，狀態(tài)和事件是緊密相連的。節(jié)點表示狀態(tài)，帶箭頭的連線表示狀態(tài)的遷移?！癲o/活動”表明進入狀態(tài)后對象執(zhí)行的操作，為可選項。護衛(wèi)條件是一個布爾表達式，其值如果為真，則觸發(fā)狀態(tài)轉移，否則不觸發(fā)。動作和事件的發(fā)生也可觸發(fā)狀態(tài)的轉移。 State Diagram(狀態(tài)圖)11State DiagramReading CommandsSystem status = “ready”Display msg = “ent

10、er cmd”Display status = steadyEntry/subsystems readyDo: poll user input panelDo: read user inputDo: interpret user inputState nameState variablesState activities2022/7/1812狀態(tài)圖的一個實例13Activity DiagramSupplements the use case by providing a graphical representation of the flow of interaction within a s

11、pecific scenario2022/7/1814 Activity Diagram 活動圖用于描述從活動到活動的流。它可用來為系統(tǒng)的動態(tài)方面建模，還可用來描述用例腳本。在活動圖中，一個活動結束后立即進入下一個活動(在狀態(tài)圖中狀態(tài)的變遷可能需要事件的觸發(fā))。 控制流從一個動作或活動狀態(tài)傳遞到下一個動作或活動狀態(tài)稱為躍遷，躍遷可以用簡單的有向線條表示。 分叉表示將單一的控制流分成兩個或多個并發(fā)的控制流，分叉有一個輸入和多個輸出，分叉路徑相關的活動是并行的。 聯(lián)結代表兩個或多個并發(fā)控制流的同步，聯(lián)結有多個輸入和一個輸出，在聯(lián)結上，與各路徑有關的活動是并行的?；顒訄D描述發(fā)生了什么，但沒有說明該活

12、動由誰來完成。泳道決定各個活動由哪個類來完成。 泳道用矩形框表示，屬于某個泳道的活動放在該矩形框中，將對象名放在矩形框的頂部，表示泳道中的活動由誰負責。 2022/7/1815Activity Diagram: Example16Swimlane DiagramsAllows the modeler to represent the flow of activities described by the use-case and at the same time indicate which actor or analysis class has responsibility for the

13、action described by an activity rectangle17Swimlane Diagrams泳道圖18Data Modelingexamines data objects independently of processingfocuses attention on the data domaincreates a model at the customers level of abstractionindicates how data objects relate to one another19What is a Data Object?a representa

14、tion of almost any composite information that must be understood by software. can be an external entity (e.g., anything that produces or consumes information), a thing (e.g., a report or a display), an occurrence (e.g., a telephone call) or event (e.g., an alarm), a role (e.g., salesperson), an orga

15、nizational unit (e.g., accounting department), a place (e.g., a warehouse), or a structure (e.g., a file). The description of data object includes the data object and all of its attributes.A data object encapsulates data onlythere is no reference within a data object to operations that act on the da

16、ta.20Data Objects and AttributesA data object contains a set of attributes that act as an aspect, quality, characteristic, or descriptor of the objectobject: automobileattributes: make model body type price options code21Class DiagramFrom the SafeHome system 類圖是面向對象建模中最常用的圖，也是其它圖（狀態(tài)圖，協(xié)作圖，組件圖等）的基礎，它描

17、述的是類與類之間的靜態(tài)關系。UML中的類圖用一個矩形表示，它由三個區(qū)域構成，分別標注類名、屬性和服務。22What is a Relationship?Data objects are connected to one another in different ways.A connection is established between person and car because the two objects are related.A person owns a carA person is insured to drive(架車保險) a car The relationships

18、 owns and insured to drive define the relevant connections between person and car.Several instances of a relationship can existObjects can be related in many different ways23ERD Notation(0, m)(1, 1)objectobjectrelationship12One common form:(0, m)(1, 1)object1object2relationshipAnother common form:at

19、tribute24Building an ERDLevel 1model all data objects (entities) and their “connections” to one anotherLevel 2model all entities and relationshipsLevel 3model all entities, relationships, and the attributes that provide further depth25The ERD: An Example26Class-Based ModelingClass-based modeling rep

20、resents: objects that the system will manipulate operations (also called methods or services) that will be applied to the objects to effect the manipulation relationships (some hierarchical) between the objectscollaborations that occur between the classes that are defined. The elements of a class-ba

21、sed model include classes and objects, attributes, operations, CRC models, collaboration diagrams and packages. 27Identifying Analysis ClassesExamining the usage scenarios developed as part of the requirements model and perform a grammatical parse Classes are determined by underlining each noun or n

22、oun phrase. If the class (noun) is required to implement a solution, then it is part of the solution space; otherwise, if a class is necessary only to describe a solution, it is part of the problem space. 28Manifestations(表現(xiàn)) of Analysis ClassesAnalysis classes manifest themselves in one of followin

23、g ways:External entities (e.g., other systems, devices, people) that produce or consume information Things (e.g, reports, displays, letters, signals) that are part of the information domain for the problemOccurrences or events (e.g., a property transfer or the completion of a series of robot movemen

24、ts) that occur within the context of system operationActors (e.g., manager, engineer, salesperson) played by people who interact with the systemOrganizational units (e.g., division, group, team) that are relevant to an applicationPlaces (e.g., manufacturing floor or loading dock) that establish the

25、context of the problem and the overall functionStructures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of objects or related classes of objects29Potential ClassesRetained information. The potential class will be useful if information must be remembered so that the system

26、can function.Needed services. The potential class must have a set of identifiable operations that can change the value of its attributes in some way.Multiple attributes. During requirement analysis, the focus should be on major information; a class with a single attribute may be useful during design

27、, but is probably better represented as an attribute of another class during the analysis activity.Common attributes. A set of attributes can be defined for the potential class and these attributes apply to all instances of the class.Common operations. A set of operations can be defined for the pote

28、ntial class and these operations apply to all instances of the class.Essential requirements. External entities that appear in the problem space to the operation of any solution for the system will almost always be defined as classes in the requirements model.30Defining AttributesAttributes describe

29、a class that has been selected for inclusion in the analysis model.build two different classes for professional baseball(棒球) playersFor Playing Statistics software: name, position, batting(擊球) average, fielding(防守) percentage, years played, and games played might be relevantFor Pension(養(yǎng)老金) Fund sof

30、tware: average salary, credit toward full vesting(三金五險), pension plan options chosen, mailing address, and the like.又如：學生可以定義為“學生檔案（反映個人基本情況的屬性）”和“學生成績（反映學習情況的屬性）”兩個不同的類。31Defining OperationsDo a grammatical parse of a processing narrative and look at the verbsOperations can be divided into four cat

31、egories: (1) operations that manipulate data in some way (e.g., adding, deleting, reformatting, selecting)(2) operations that perform a computation(3) operations that inquire about the state of an object (4) operations that monitor an object for the occurrence of a controlling event.32Class TypesEnt

32、ity classes, also called model or business classes, are extracted directly from the statement of the problem (e.g., Sensor). Boundary classes are used to create the interface (e.g., interactive screen or printed reports) that the user sees and interacts with as the software is used. Controller class

33、es manage a “unit of work” from start to finish. That is, controller classes can be designed to manage the creation or update of entity objects; the instantiation(實例) of boundary objects as they obtain information from entity objects; complex communication between sets of objects; validation of data

34、 communicated between objects or between the user and the application. 33CRC ModelsClass-responsibility-collaborator (CRC) modeling Ambler Amb95 describes CRC modeling in the following way:A CRC model is a collection of standard index cards that represent classes. The cards are divided into three se

35、ctions. Along the top of the card you write the name of the class. In the body of the card you list the class responsibilities on the left and the collaborators on the right.34CRC Modeling35ResponsibilitiesEach responsibility should be stated as generally as possibleInformation and behavior related

36、to it should reside within the same classInformation about one thing should be localized with a single class, not distributed across multiple classes. Responsibilities should be shared among related classes, when appropriate. 36CollaborationsClasses fulfill their responsibilities in one of two ways:

37、 A class can use its own operations to manipulate its own attributes, thereby fulfilling a particular responsibility, or a class can collaborate with other classes.Collaborations identify relationships between classesCollaborations are identified by determining whether a class can fulfill each respo

38、nsibility itselfthree different relationships between classes: the is-part-of relationship the has-knowledge-of relationship the depends-upon relationship37Composite Aggregate(聚合關系)代表“整體與部分”的關系38Associations and Multiplicity(多樣性)Two analysis classes are often related to one another in some fashionIn

39、 UML these relationships are called associationsAssociations can be refined by indicating multiplicity代表“一般與特殊”的關系39Dependencies(依賴性)In many instances, a client-server relationship exists between two analysis classes. In such cases, a client-class depends on the server-class in some way and a depend

40、ency relationship is established40PackagesVarious elements of the analysis model (e.g., use-cases, classes) are categorized in a manner that packages them as a grouping(即:將類分組為包)The plus sign preceding the analysis class name in each package indicates that the classes have public visibility and are

41、therefore accessible from other packages.The minus sign indicates that an element is hidden from all other packages.The # symbol indicates that an element is accessible only to packages contained within a given package.Class-Based Modeling - SummaryObjects are extracted from use-casesRelationships among obj