SSD9-Unit4

SSD9: Software Specification, Testing, and SSD9: Software Specification, Testing, and MaintenanceMaintenance

Unit 4. Object-Oriented Analysis (OOA) Unit 4. Object-Oriented Analysis (OOA)

4.14.1 OOA Principles  OOA Principles 4.24.2 OOA Practice 1: Use Case Modeling  OOA Practice 1: Use Case Modeling 4.34.3 OOA Practice 2: Class and Dynamic Modeling  OOA Practice 2: Class and Dynamic Modeling

Assessments Assessments Multiple-Choice Quiz 4

44.1 OOA Principles .1 OOA Principles

4.1.14.1.1 Object-Oriented vs. Structured Analysis Object-Oriented vs. Structured Analysis 4.1.24.1.2 Use Case Modeling Use Case Modeling 4.1.34.1.3 Class Modeling Class Modeling 4.1.44.1.4 Dynamic Modeling Dynamic Modeling

4.14.1.1 Object-Oriented vs. Structured Analysis.1 Object-Oriented vs. Structured Analysis

Background Background Elements of Object-Oriented AnalysisElements of Object-Oriented Analysis

BackgroundBackground

When analyzing a software product to be built, one When analyzing a software product to be built, one can focus oncan focus on the data contained in the application, the actions performed by the application, or both.

Two ways of analysis Two ways of analysis traditional ("structured") analysis techniques

select one emphasis (either data or actions). OO analysis,

both data and actions are given equal emphasis. Since both data and actions are equally important in most

applications So the object-oriented analysis method is considered superior.

traditional action-oriented analysis approachtraditional action-oriented analysis approach

begins with a begins with a data flow diagramdata flow diagram. . Although a data flow diagram refers both to actions Although a data flow diagram refers both to actions

and data, its and data, its primary focus is to identify the sequence(s) of actions

performed by the product does not specify the detailed structure of the data objects that

are passed from action to action. E.gE.g.,., an action-oriented approach to analysis an action-oriented approach to analysis

finite-state machines.

finite-state machines finite-state machines ( p.252 in Textbook )( p.252 in Textbook )

状态转换表 状态转换表 p.252 in Textbookp.252 in Textbook

Data-oriented techniquesData-oriented techniques

Data-oriented techniquesData-oriented techniques begin with a detailed analysis of the data.

stepssteps First ， the structure of the data is determined, Then ， it is used to determine the structure of the actions

performed on the data. When this technique is used, the structure of the When this technique is used, the structure of the

actions always corresponds to the structure of the actions always corresponds to the structure of the data. data.

ExampleExamples of ERDs of ERD

fundamental drawbackfundamental drawback to both of these approaches to both of these approaches

传统分析方法，左右都为难呀 传统分析方法，左右都为难呀 ………… It is often It is often not possiblenot possible to understand to understand the required the required

data structuredata structure unless one considers unless one considers all of the actions all of the actions to be performedto be performed; ;

IIt is generally t is generally not possiblenot possible to decide to decide the structure of the structure of all actionsall actions in the absence of a in the absence of a data analysisdata analysis. .

The The object-oriented analysis techniqueobject-oriented analysis technique addresses addresses these shortcomings by these shortcomings by providing an equal emphasis on

actions (methods) and data (attributes) at each step.

Elements of Object-Oriented AnalysisElements of Object-Oriented Analysis

Object-Oriented Analysis (OOA) is a Object-Oriented Analysis (OOA) is a semi-formalsemi-formal technique. technique. There is no “foolproof method” or strict guideline for

performing an analysis; 也没有精确的实施指南 a set of techniquesa set of techniques must be chosen and applied must be chosen and applied

creatively by the software engineer. creatively by the software engineer. 需要发挥聪明需要发挥聪明才智与创造力！才智与创造力！

实践出真知，同学们加油练！实践出真知，同学们加油练！

OOA can be organized into these phasesOOA can be organized into these phases

Use case modelingUse case modeling determines how the various results are computed by the software

(without regard to their chronological order). presented in a use case diagram and a set of scenario descriptions ( 场

景 / 情形描述 ). This step is largely action oriented.

Class modelingClass modeling determines the set of required classes and their attributes, as well as the

relationships between the classes. presented in a class diagram. This step is purely data oriented.

Dynamic modelingDynamic modeling: : determines the actions performed by each class. presented in a state diagram. This step is purely action oriented.

These steps are not performed in a purely sequential These steps are not performed in a purely sequential mannermanner

The diagrams are The diagrams are interdependent interdependent making a change or revision in one will trigger

corresponding changes in the others. 相互关联的 , 一改俱改

the three steps are the three steps are performed in parallelperformed in parallel the diagrams keethe diagrams keep p being revisedbeing revised 不断修订不断修订

the diagrams are complete and consistent with each other. The completed diagrams (and associated text) The completed diagrams (and associated text)

provide the provide the specificationspecification for the product to be built. for the product to be built.

4.1.2 Use Case Modeling4.1.2 Use Case Modeling

A use case is a generic description of the software A use case is a generic description of the software functionalityfunctionality For each use case, a set of scenarios is written. It is useful to think of these scenarios as instantiations of a

use case.

For exampleFor example

The user can perform two actions: The user can perform two actions: press an elevator button press a floor button.

This diagram is drawn using the Unified Modeling This diagram is drawn using the Unified Modeling Language (UML) representation for use cases.Language (UML) representation for use cases.

Scenarios vs.Scenarios vs. use caseuse case

（多个）（多个）情形是（一个）情形是（一个）用例的特定实例用例的特定实例 特定环境下如何使用，使用情况如何，有何种反应……

A large number of possible scenariosA large number of possible scenarios might occur in might occur in response to the actions in the use case. response to the actions in the use case.

Scenarios are generally grouped into Scenarios are generally grouped into normal scenarios (which model an expected response) abnormal scenarios (which model an unexpected response).

The scenariosThe scenarios are written down as a sequence of steps narrates the various occurrences in the response.

a normal scenario for the elevator use case a normal scenario for the elevator use case ( p.276)( p.276)

an abnormal scenario for the elevator use case (p.277)an abnormal scenario for the elevator use case (p.277)

should study a should study a sufficientsufficient number of scenarios number of scenarios

in order in order to gain a complete understanding of everythingto gain a complete understanding of everything that that might happen in response to a user action. might happen in response to a user action. 尽可能穷尽所以尽可能穷尽所以情形情形

thethe abnormal cases abnormal cases are particular important, which are are particular important, which are often associated with often associated with error conditionserror conditions in the software in the software file not found host not found connection lost

The creation of robust software depends on comprehensive The creation of robust software depends on comprehensive error checkingerror checking andand error handlingerror handling

in order for the software design to in order for the software design to be well informed about be well informed about possible error conditionspossible error conditions, they must be , they must be modeled in the modeled in the use use casecase analysis phase analysis phase. . 预先准备，才有判断出错条件预先准备，才有判断出错条件

steps of use case modelingsteps of use case modeling

includingincluding Identifying user roles Constructing use case diagrams Writing use case scenarios

use case modeling -- Identifying user rolesuse case modeling -- Identifying user roles

considers considers all of the rolesall of the roles that are played in different that are played in different scenarios by scenarios by end users, system administrators, external software (considered as active agents for the

purpose of analysis), etc.

EachEach active role active role must be modeledmust be modeled in the use case in the use case diagram and in the use case scenarios where diagram and in the use case scenarios where applicable. applicable.

use case modeling -- Constructing use case diagramsuse case modeling -- Constructing use case diagrams

enumerates enumerates all of the system's functionsall of the system's functions by drawing by drawing a use case diagram in UML, a use case diagram in UML,

links the user roles (and active agent) to the links the user roles (and active agent) to the behaviors supported by the system. behaviors supported by the system.

use case modeling -- Writing use case scenariosuse case modeling -- Writing use case scenarios

For For eacheach use case, write use case, write a textual descriptiona textual description of the steps the of the steps the software should take in order to achieve the desired resultsoftware should take in order to achieve the desired result taking into account both

normal scenarios (where the interaction proceeds as expected) and abnormal scenarios (where some error occurs, either as a result of an

unexpected user action or some environmental condition).

The use case scenarios are The use case scenarios are written in plain languagewritten in plain language, , from the user's point of view (for an interactive product), or from the administrator's point of view (for a system-level product).

Use case scenarios are Use case scenarios are extremely usefulextremely useful in in eliciting more detailed information about the required software

behaviors in different modes of operation. also serve as an initial basis for the class modeling step in analysis.

4.1.3 Class Modeling 4.1.3 Class Modeling

In the class-modeling phase, the analyst works with In the class-modeling phase, the analyst works with the the use case scenariosuse case scenarios and and use case diagramsuse case diagrams in an in an effort to effort to extract preliminary information about what classes of

software objects should be created in the subsequent design phase.

This involves This involves analyzing the use case scenarios create a class diagram, a form of entity-relationship diagram.

steps of class modelingsteps of class modeling

Noun extraction:Noun extraction: perform a linguistic analysis of the use case scenarios, to

identify nouns that are likely to correspond to object classes in the software product to be constructed.

Create and refine preliminary class list:Create and refine preliminary class list: noun extraction a preliminary list of classes is created refined to eliminate candidate classes which might appear to be

object classes Decide

which are better modeled as attributes which fall outside the scope of the problem to be solved.

Create an object diagram in UML:Create an object diagram in UML: enumerates all of the classes, their attributes, and the

relationships among the classes.

4.1.4 Dynamic Modeling4.1.4 Dynamic Modeling

The goal of dynamic modeling is to The goal of dynamic modeling is to create a state transition diagram (STD) describes the different states the software may enter into

during its operation.

state transition diagram in a graphic formstate transition diagram in a graphic form

In this sense, a state transition diagram is like the In this sense, a state transition diagram is like the finite-state machines (FSM)finite-state machines (FSM) used for state modeling used for state modeling in structured analysis.in structured analysis.

A A state transition diagramstate transition diagram can be formally specified can be formally specified as a set of rules of the form:as a set of rules of the form: 形式化的表示形式化的表示 current state and event and predicate => next state

it is often more useful to it is often more useful to represent the state transition diagram in a graphic form more clearly links the different states and the transitions

between them We use We use (UML). Wha (UML). What and how, go ahead t and how, go ahead ！！

example state transition diagram example state transition diagram

4.2 OOA Practice 1: Use Case Modeling 4.2 OOA Practice 1: Use Case Modeling

4.2.1 Defining User Roles 4.2.1 Defining User Roles 4.2.2 Use Case Diagrams in UML 4.2.2 Use Case Diagrams in UML 4.2.3 Writing Use Case Scenarios 4.2.3 Writing Use Case Scenarios

Assessments Assessments Exercise 3

4.2.1 Defining User Roles4.2.1 Defining User Roles

In designing of an object-oriented software systemIn designing of an object-oriented software system firstly identify all of the different roles played by various

entities during the operation of the software. construct use case scenarios and use case diagrams

typically on the typically on the end user of the softwareend user of the software invoke most of the functionality of the software and interact directly with the software during its operation

别忘了，还有这些人别忘了，还有这些人…………

there are other important roles to consider as well:there are other important roles to consider as well: Installer/maintainer:

software includes modules or routines that support installation and/or regular maintenance,

the role of system installer or system maintainer must be considered

use cases must be defined for the various types of installation or maintenance activities.

"Expert" user vs. "first-time" user: Some products support multiple levels of functionality that are

targeted at different groups of users with varying degrees of education, skill, etc.

a use case must be defined for each functionality where different user categories are supported.

别忘了，还有这些别忘了，还有这些…………

there are other important roles to consider as well:there are other important roles to consider as well: Integrated software:

The other software system can be modeled as a separate role or agent. External systems:

Software systems that provide networked information services interact with a variety of external systems. E.g.,

e-commerce applications must interoperate with remote search engines, database back-end servers, etc.

These external systems are also modeled as separate roles or agents, distinct from the software being analyzed.

analyzing software that is intended to provide integrated services, with all the external client programs modeled as separate roles or agents.

External systems also include the remote sensors ( 传感器 ), data entry devices( 数据录入设备 ), etc. that are part of a real-time control system.

Important : distinguish the different roles before Important : distinguish the different roles before creating the use case diagramcreating the use case diagram

for two reasons:for two reasons: Identifying the different roles and their categories of use

allows the analyst to enumerate fully the different use cases that the software must handle;

A good design depends on clear identification of both users and external systems with which the software must interact.

4.2.2 Use Case Diagrams in UML4.2.2 Use Case Diagrams in UML

process process identifying the different user roles/external software modules Drawing use case diagrams

which identify the primary functionalities of the software in relation to the different user roles.

write detailed use case scenarios

break down the primary functionalities into specific steps. 分解初步的功能到具体的使用细节

We use UML to construct use case diagramsWe use UML to construct use case diagrams

UMLUML is a very comprehensive, modular notation is a very comprehensive, modular notation system that covers many system that covers many software-modeling software-modeling activitiesactivities..

A use case diagram is a simple graphical A use case diagram is a simple graphical representation of the representation of the different user rolesdifferent user roles, and , and the the use casesuse cases (types of software behavior) in which they (types of software behavior) in which they can participate. can participate.

Elements of a use case diagramElements of a use case diagram

Actors:Actors: represented as stick figures associated with particular user roles. A labeled stick figure is drawn to indicate each user role or

external system that has been identified. Use cases: Use cases:

represented as ovals associated with particular primary functionalities (tasks) that

are carried out by the software A labeled oval is drawn to indicate each use case that should

be covered by the system. A straight line drawn between each use case and the actor or

actors.

Elements of a use case diagramElements of a use case diagram

Relations: Relations: define relationships between use cases. 如功能调用，发消

息等 one use case is a coherent sub-part of another task or use

case. a Web-based information system might include three use

cases: Check For Update, Display Page, and Retrieve Page. Both the Check For Update and Display Page use cases might reuse the retrieve-page use case.

The uses relationship is represented as a labeled arrow linking the two use cases, with the arrow pointing toward the use case being reused.

Elements of a use case diagramElements of a use case diagram

System boundary:System boundary: distinguish clearly between the use cases provided by the

system and those provided by the actors (users and external agents) 哪部分是系统该做的

a labeled rectangle is drawn around the use cases provided by the software.

may omitted when the use cases in the diagram are all associated with a particular

software system. must include the system boundary

to model how the same actors interact with different systems, to model how systems themselves relate to one another, as in

the example of a c/s architecture (business logic tier ).

notenote

A single use case (or primary functionality) might be A single use case (or primary functionality) might be associated with many different use case scenariosassociated with many different use case scenarios. . use case represents a single type of use , the use case scenarios enumerate all types of interactions that

might take place when the associated use case is carried out. use case ： saving a file to the local hard drive the use case scenarios ： should describe trying to save a

file when the hard drive is full, canceling a request to save a file to disk, and so on.

4.2.3  Writing Use Case Scenarios4.2.3  Writing Use Case Scenarios

identifying all the different user roles and identifying all the different user roles and drawing a use case diagram for the softwaredrawing a use case diagram for the software

writes a series of use case scenarios for each use writes a series of use case scenarios for each use case. case.

Use Case Use Case ：： what to usewhat to use ？？ Use Case Scenarios : HowUse Case Scenarios : How to use? to use?

Use Case ScenariosUse Case Scenarios

It is important for the analyst to It is important for the analyst to consider all consider all possible normal and abnormal use case scenariospossible normal and abnormal use case scenarios for for a given use case.a given use case.

"normal" use case scenarios"normal" use case scenarios describe the normal flow of events

"abnormal" usage scenarios"abnormal" usage scenarios describe the system's behavior in the face of unexpected

conditions disk-full errors network connection errors bad input data

Written scenarios are very important, Why?Written scenarios are very important, Why?

Written scenarios help verify coverage and Written scenarios help verify coverage and completeness of requirements. completeness of requirements. the process of requirements focuses more on normal

(expected) software behaviors, and does not consider all types of unexpected conditions that might occur.

Before the design phase, not only to identify all possible error conditions, but also to define precisely the desired system behavior when

errors occur. analyst revisit the original requirements specification with

the customer to discuss error conditions not in the original requirements analysis.

Written scenarios are very important, Why?Written scenarios are very important, Why?

Use case modeling depends on detailed scenarios. Use case modeling depends on detailed scenarios. The technique noun extraction used to identify candidate

objects in the object-oriented analysis phase depends on a detailed description of the desired system behavior.

It is not possible to construct a preliminary object diagram using this technique unless detailed scenarios have been constructed. 所以，越详细越好！

notenote

It is important to keep the language of the scenarios It is important to keep the language of the scenarios simple simple andand unambiguous unambiguous, wherever possible. , wherever possible. Simplicity helps to avoid a proliferation of redundant objects

that really only refer to a single object class. review the use case scenarios after they are written to ensure

that all of the steps are unambiguous. If soIf so …… on the part of the software, the step is …… on the part of the software, the step is

ambiguous and ambiguous and must be rewritten must be rewritten !!!!!! a step is described in a way could be interpreted as more than one concrete action

4.3 OOA Practice 2: Class and Dynamic Modeling 4.3 OOA Practice 2: Class and Dynamic Modeling

4.3.1 Noun Extraction and Preliminary Class List 4.3.1 Noun Extraction and Preliminary Class List Refinement Refinement

4.3.2 Object Diagrams in UML 4.3.2 Object Diagrams in UML 4.3.3 State Transition Diagrams in UML 4.3.3 State Transition Diagrams in UML

Assessments Assessments Exercise 4

Noun extraction is the first step in class modelingNoun extraction is the first step in class modeling

Noun extraction Noun extraction class modeling class modeling Noun extraction(Noun extraction( 名词提取法名词提取法 )) is is

analyze use case scenarios / other written descriptions of a system's proposed behavior

define a set of candidate objects or classes. The input to the noun extraction step is The input to the noun extraction step is

either an informal description of the product or the detailed use case scenarios that are created during the use

case modeling phase. The preliminary class listThe preliminary class list

created by the noun extraction techniques, undergoes further refinement （ items that should not be

modeled as objects are eliminated. ）

Schach's Multi-Step Process for Noun ExtractionSchach's Multi-Step Process for Noun Extraction

The steps are listed belowThe steps are listed below （课本中两阶段法！）（课本中两阶段法！） Concise problem definition: 简洁的问题定义

Define the product briefly, in a single sentence if possible. Informal strategy: 描述产品

Express the informal strategy for solving the problem in a single paragraph, including mention of any constraints on the solution.

Formalizing the strategy: 找出名词 Identify the nouns in the informal strategy, excluding those

that lie outside the boundary of the problem. Use these nouns as the candidate classes.

an example of noun extraction using the case of the an example of noun extraction using the case of the elevator controllerelevator controller

The informal strategy is shown here, with the The informal strategy is shown here, with the candidate classes (nouns) underlined candidate classes (nouns) underlined (p.278)(p.278) Buttons in elevators and on the floors control the movement

of n elevators in a building with m floors. Buttons illuminate when pressed to request an elevator to stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed.

We have got We have got eight different nounseight different nouns: : button, elevator, floor, movement, building, illumination,

request, and door.

analysisanalysis

Three of the nouns (Three of the nouns (floorfloor, , buildingbuilding, and , and doordoor) do not need to ) do not need to be explicitly modeled by the solution — they are be explicitly modeled by the solution — they are outside the outside the scope of the problem boundaryscope of the problem boundary. .

Three of the remaining nouns (Three of the remaining nouns (movementmovement, , illuminationillumination, and , and requestrequest) are ) are abstract nounsabstract nouns that that do not correspond to a do not correspond to a physical objectphysical object. . Abstract nouns generally do not end up as classes, but they are

sometimes modeled as attributes 不作为类，而是作为类的属性 Illumination ： an attribute of a Button class

So two candidate classes leftSo two candidate classes left Elevator and Button.

because there are two kinds of buttons (in the elevator and because there are two kinds of buttons (in the elevator and on the floors) on the floors) two subclasses of Button are defined: ElevatorButton and FloorButton.

Noun Extraction from Use Case ScenariosNoun Extraction from Use Case Scenarios

The The multi-step noun extraction processmulti-step noun extraction process described described above above works fairly well for works fairly well for simple software systemssimple software systems that that do not have manydo not have many use cases. use cases. 好用可惜范围有限好用可惜范围有限

For more For more complicated systemscomplicated systems, the informal strategy , the informal strategy for solving the problem may for solving the problem may include several include several paragraphs.paragraphs.

So , itSo , it be more appropriate to be more appropriate to create a use case diagram and detailed use case scenarios perform noun extraction using the use case scenarios

themselves as input.

an example : Knowledge Maintenance Tool (KMT), an example : Knowledge Maintenance Tool (KMT),

The KMT is a graphical user interface that allows The KMT is a graphical user interface that allows knowledge engineers to edit and update the various knowledge engineers to edit and update the various knowledge sources used in machine translation knowledge sources used in machine translation systems (dictionaries, grammars, etc.). systems (dictionaries, grammars, etc.).

A piece of the KMT software documentation A piece of the KMT software documentation describes the normal use case scenario for a describes the normal use case scenario for a grammar update (next page).grammar update (next page).

use case scenariouse case scenario The The Analyzer maintainerAnalyzer maintainer receives a receives a problem reportproblem report about a about a

sentencesentence that does not pass when it should. He invokes the that does not pass when it should. He invokes the KMT, and enters the sentence as a KMT, and enters the sentence as a test casetest case. The sentence is . The sentence is parsed and the maintainer verifies that the parsed and the maintainer verifies that the current resultcurrent result is is not the desired one. The maintainer then selects not the desired one. The maintainer then selects module module tracing optionstracing options within KMT, which turns on tracing of the within KMT, which turns on tracing of the input/outputinput/output of the of the Syntaxifier moduleSyntaxifier module in the Analyzer. The in the Analyzer. The sentence is run again, and this time the sentence is run again, and this time the trace outputtrace output indicates indicates that there is no complete parse. By inspecting the trace that there is no complete parse. By inspecting the trace output (which indicates the output (which indicates the grammar rulesgrammar rules that are tried), that are tried), the maintainer determines that a the maintainer determines that a particular ruleparticular rule which which should have fired did not fire, due to a should have fired did not fire, due to a mistakemistake in the in the rule rule syntaxsyntax. The maintainer invokes the . The maintainer invokes the Edit capabilityEdit capability of KMT of KMT on the particular rule. on the particular rule.

use case scenario(con.)use case scenario(con.) After correcting the rule, the maintainer requests (via KMT) After correcting the rule, the maintainer requests (via KMT)

that the Analyzer reload the that the Analyzer reload the grammargrammar. The sentence is . The sentence is parsed once again, and the parsed once again, and the desired resultdesired result is achieved. The is achieved. The maintainer then refers to the available set of maintainer then refers to the available set of test datatest data for the for the grammar (Syntaxifier), and runs a set of appropriate grammar (Syntaxifier), and runs a set of appropriate regression testsregression tests to make sure that the to make sure that the current fixcurrent fix has not has not caused caused other bugsother bugs in the grammar. Using the KMT interface in the grammar. Using the KMT interface to run to run pre-defined test suitespre-defined test suites, the desired tests are selected , the desired tests are selected and run. Any sentences that fail testing are placed into a and run. Any sentences that fail testing are placed into a new new (temporary) set of test cases(temporary) set of test cases, and the maintainer iterates , and the maintainer iterates through each case using the same set of steps followed for through each case using the same set of steps followed for the first bug. When all the work is finished, the maintainer the first bug. When all the work is finished, the maintainer requests that the current (temporary) copy of the grammar requests that the current (temporary) copy of the grammar be checked back into the be checked back into the file systemfile system as a as a revised versionrevised version of of the original grammar. This new version can be used for the original grammar. This new version can be used for further debugging and revision in a later session. Eventually, further debugging and revision in a later session. Eventually, it will become part of a it will become part of a new frozen versionnew frozen version of the of the entire entire systemsystem for for testing and deliverytesting and delivery..

candidate class refinement is important !candidate class refinement is important !

Many of the nouns that appear in the use case Many of the nouns that appear in the use case scenario are scenario are not candidate class objectsnot candidate class objects, and , and must must be eliminatedbe eliminated

How can we do?How can we do? using three principles

three principles for candidate class refinementthree principles for candidate class refinement

Noun expresses an Noun expresses an abstract conceptabstract concept. . Some nouns refer to abstract concepts that are not directly a part of the

software being constructed (input/output, rule syntax, edit capability, test data, entire system).

Noun expresses a Noun expresses a concept outside of the problem scopeconcept outside of the problem scope. . Some nouns refer to concepts that are outside of the scope of the

problem to be solved; typical examples are those references to the use environment that do not affect the software itself

(problem report, rule syntax, current fix, testing and delivery, Analyzer maintainer).

Noun expresses a Noun expresses a concept that should be a featureconcept that should be a feature ( ( 某事物某事物方面的特性方面的特性 ). ). Some nouns refer to characteristics of data objects that are better

modeled as features (class variables) rather than as first-class objects (module tracing options, trace output, result, and version).

After refinementAfter refinement

We got:We got: Analyzer, module, grammar, rule, sentence, test suite. These objects should be modeled in the class diagram for the KMT tool.

noted that noted that some classes would undergo further refinement when the complete class

list is created by merging the individual class lists that are produced for individual scenarios. 通过分析多个（所有）用例情形得出的类，还有进一步精炼，如归并相关项目等

E.g.,In the KMT example, the classes Analyzer server the classes grammar knowledge base server , knowledge base represent more general type of object.

4.3.2 Object Diagrams in UML4.3.2 Object Diagrams in UML

Elevator ExampleElevator Example KMT ExampleKMT Example

object diagramobject diagram

a candidate class list has been created (bya candidate class list has been created (by noun extraction) noun extraction) draw an draw an object diagramobject diagram

object diagramobject diagram shows the relationships between the objects also referred to as class diagrams in some texts.

A preliminary object diagram shows only the classes and A preliminary object diagram shows only the classes and their relationships; their relationships; By refinement, more detail (the class variables and methods) is added

The final details include The final details include the class variable types, each method (the arguments, argument types, return types)

But often But often not finalizednot finalized until the Design Phase. until the Design Phase. 需要不断的需要不断的迭代！迭代！

Object diagrams In UMLObject diagrams In UML

Classes: Classes: Classes (objects) are represented as labeled rectangles, with three

partitions : one to hold the label, one to hold the class variable (attribute) declarations, one to hold the method (action) declarations.

Inheritance links: Inheritance links: indicated by a line with an arrowhead, drawn from the subclass to the parent class the arrow points toward the parent class.

Object diagrams In UMLObject diagrams In UML

Class relations: Class relations: represented as a line drawn between the two rectangles denoting

the two classes. Each relation is marked with a label indicating the nature of the

relationship. 关系的种类 A relation is also marked with information about the cardinality of

the relation. 关系的基数

cardinality of cardinality of Class relationsClass relations

1 to many1 to many

1 to 11 to 1

Many to manyMany to many

Elevator ExampleElevator Example

Schach said, Schach said, it is often necessary to refine the initial class diagram to add

classes and relationships that more accurately model the real situation

In the elevator example, In the elevator example, a real elevator does not directly accept commands from the

different buttons; an elevator controller handles all the button actions and

issues control commands to the elevators.

A revised class diagram, an ElevatorController class addedA revised class diagram, an ElevatorController class added

KMT ExampleKMT Example

Remember? Remember? thethe process of noun extraction from a process of noun extraction from a use case scenariouse case scenario for the Knowledge Maintenance for the Knowledge Maintenance Tool (KMT). Tool (KMT).

The preliminary object diagram is hereThe preliminary object diagram is here

relationsrelations

In the diagram, All the In the diagram, All the relationsrelations are are generic taxonomic relations, labeled Contains indicates that a given object is associated with one or more

other objects. a server (a program that performs some language-processing

step) contains many modules, each module is associated with many knowledge files, and each knowledge file contains many rules.

This example also shows usThis example also shows us how some of the candidate classes from noun extraction are

actually best modeled as modeled as attributesattributes, not objects traceOptions, version, result, traceOutput.

The example also tell usThe example also tell us

that that some of the some of the methodsmethods associated with some objects are associated with some objects are already known at this timealready known at this time. .

How can we know?How can we know? While the focus of noun extraction is on the objects, it is relatively

straightforward to identify candidate methods by extracting the verbs (action words) from the use case scenario (example, reload, checkIn, checkOut, edit, run, parse).

Although only the checkIn method was implied by the use case scenario, a practitioner familiar with version control will note that every checkIn must be preceded by a checkOut, so this candidate method was added. 成对操作 !

Note Note the method signatures are not fully specified at this time.

Only the method names have been identified Only the method names have been identified the details regarding method arguments and return types will be specified

during the Design Phase.

4.3.3  State Transition Diagrams in UML4.3.3  State Transition Diagrams in UML

Elevator ExampleElevator Example

We have learntWe have learnt

data modelingdata modeling is concerned with identifying all of is concerned with identifying all of the data objects in a softwarethe data objects in a software extracting nouns creating an object diagram

The analysis process also involves The analysis process also involves dynamic modelingdynamic modeling 表达软件如何运行表达软件如何运行，，需要动态建模！需要动态建模！ identifies all of the states, events, and corresponding actions

to be taken by the software. represented in the form of a state transition diagram.

state transition diagrams in UMLstate transition diagrams in UML

States: States: represented as rounded rectangles. Each rectangle has two partitions

one containing the state name (label), and the other containing a set of actions to be taken by the software when the

state is entered. The set of actions associated with a state may be empty, in which case

only the state name (label) appears inside the rounded rectangle.

initial Start state: initial Start state: represented as a solid (black) circle with an unlabeled transition to the first state in the state diagram.

state transition diagrams in UMLstate transition diagrams in UML

Transitions: Transitions: represented as a line with an arrow, from the prior state to the

subsequent state. labeled with a set of predicates ( 谓词 )

determines when the transition should take place. drawn as a set of short phrases in square brackets. All of the predicates must be true for the transition to take

place. If a transition from one state to another occurs as soon as the

prior state‘s actions are complete, 无条件立即转换！ no predicates controlling the transition be drawn as a directed line with no labeling.

Elevator ExampleElevator Example

An example of a UML state diagram for the An example of a UML state diagram for the Elevator Controller scenario (see your textbook fig. Elevator Controller scenario (see your textbook fig. 12. 7 12. 7 ， ， p.281)p.281)

explainexplain

The The start statestart state initializes the system at the Elevator Control initializes the system at the Elevator Control Loop state, which is the main "wait" state of the system. Loop state, which is the main "wait" state of the system.

There are There are no actions associated with the no actions associated with the Elevator Control Elevator Control Loop stateLoop state, so only the state name (label) appears inside the , so only the state name (label) appears inside the rounded rectangle that denotes the state. rounded rectangle that denotes the state.

There are There are six transitionssix transitions from the from the Elevator Control Loop Elevator Control Loop statestate; each transition is labeled with ; each transition is labeled with a set of predicatesa set of predicates that that must be true for the transition to take place. must be true for the transition to take place. if the elevator is stopped and there are requests pending, then the Close

Elevator Doors state is entered.

it is possible for a transition to it is possible for a transition to start and end at the same start and end at the same statestate. .