SSD9: Software Specification, Testing, and

Maintenance
 Unit 4. Object-Oriented Analysis (OOA)
 4.1 OOA Principles
 4.2 OOA Practice 1: Use Case Modeling
 4.3 OOA Practice 2: Class and Dynamic Modeling

 Assessments
 Multiple-Choice Quiz 4
 4.1 OOA Principles
 4.1.1 Object-Oriented vs. Structured Analysis
 4.1.2 Use Case Modeling
 4.1.3 Class Modeling
 4.1.4 Dynamic Modeling

 4.1.1 Object-Oriented vs. Structured Analysis
 Background
 Elements of Object-Oriented Analysis
 Background
 When analyzing a software product to be built, one
can focus on
 the data contained in the application,
 the actions performed by the application,
 or both.
 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 approach
 begins with a data flow diagram.
 Although a data flow diagram refers both to actions
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.g., an action-oriented approach to analysis
 finite-state machines.
finite-state machines ( p.252 in Textbook )
状态转 换表 p.252 in Textbook
 Data-oriented techniques
 Data-oriented techniques
 begin with a detailed analysis of the data.
 steps
 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
actions always corresponds to the structure of the
data.
Examples of ERD
 fundamental drawback to both of these approaches
 传统分 析方法，左右 都为难呀 ……
 It is often not possible to understand the required
data structure unless one considers all of the actions
to be performed;
 It is generally not possible to decide the structure of
all actions in the absence of a data analysis.
 The object-oriented analysis technique addresses
these shortcomings by
 providing an equal emphasis on
 actions (methods) and
 data (attributes) at each step.
 Elements of Object-Oriented Analysis
 Object-Oriented Analysis (OOA) is a semi-formal
technique.
 There is no “foolproof method” or strict guideline for
performing an analysis; 也没有精确的实施指南
 a set of techniques must be chosen and applied
creatively by the software engineer. 需要发挥聪 明
才智与 创造力！
 实践出 真知，同学们 加油练！
 OOA can be organized into these phases
 Use 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 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 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
manner
 The diagrams are interdependent
 making a change or revision in one will trigger
corresponding changes in the others. 相互关联的 , 一改俱
改
 the three steps are performed in parallel
 the diagrams keep being revised  不断修订
 the diagrams are complete and consistent with each other.
 The completed diagrams (and associated text)
provide the specification for the product to be built.
 4.1.2 Use Case Modeling
 A use case is a generic description of the software
functionality
 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 example
 The user can perform two actions:
 press an elevator button
 press a floor button.

 This diagram is drawn using the Unified Modeling

Language (UML) representation for use cases.
 Scenarios vs. use case
 （多个 ） 情形是（一 个） 用例的 特定实例
 特定环境下如何使用，使用情况如何，有何种反应……
 A large number of possible scenarios might occur in
response to the actions in the use case.
 Scenarios are generally grouped into
 normal scenarios (which model an expected response)
 abnormal scenarios (which model an unexpected response).
 The scenarios
 are written down as a sequence of steps
 narrates the various occurrences in the response.
a normal scenario for the elevator use case ( p.276)
an abnormal scenario for the elevator use case (p.277)
 should study a sufficient number of scenarios
 in order to gain a complete understanding of everything that
might happen in response to a user action. 尽可能穷 尽所
以情形
 the abnormal cases are particular important, which are
often associated with error conditions in the software
 file not found
 host not found
 connection lost
 The creation of robust software depends on comprehensive
error checking and error handling
 in order for the software design to be well informed about
possible error conditions, they must be modeled in the use
case analysis phase. 预先准备，才有判断出错条件
 steps of use case modeling
 including
 Identifying user roles

 Constructing use case diagrams

 Writing use case scenarios

 use case modeling -- Identifying user roles
 considers all of the roles that are played in different
scenarios by
 end users,
 system administrators,
 external software (considered as active agents for the
purpose of analysis),
 etc.
 Each active role must be modeled in the use case
diagram and in the use case scenarios where
applicable.
use case modeling -- Constructing use case diagrams
 enumerates all of the system's functions by drawing
a use case diagram in UML,
 links the user roles (and active agent) to the
behaviors supported by the system.
 use case modeling -- Writing use case scenarios
 For each use case, write a textual description of the steps the
software 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 written 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 extremely useful 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
 In the class-modeling phase, the analyst works with
the use case scenarios and use case diagrams in an
effort to
 extract preliminary information about what classes of
software objects should be created in the subsequent design
phase.
 This involves
 analyzing the use case scenarios
 create a class diagram, a form of entity-relationship diagram.
 steps of class modeling
 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:
 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:

 enumerates all of the classes, their attributes, and the
relationships among the classes.
 4.1.4 Dynamic Modeling
 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 form
 In this sense, a state transition diagram is like the
finite-state machines (FSM) used for state modeling
in structured analysis.
 A state transition diagram can be formally specified
as a set of rules of the form: 形式化的表示
 current state and event and predicate => next state
 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  (UML). What and how, go ahead ！
example state transition diagram
 4.2 OOA Practice 1: Use Case Modeling
 4.2.1 Defining User Roles
 4.2.2 Use Case Diagrams in UML
 4.2.3 Writing Use Case Scenarios

 Assessments
 Exercise 3
 4.2.1 Defining User Roles
 In 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 end 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:
 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:
 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
creating the use case diagram
 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 UML
 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 diagrams
 UML is a very comprehensive, modular notation
system that covers many software-modeling
activities.
 A use case diagram is a simple graphical
representation of the different user roles, and the
use cases (types of software behavior) in which they
can participate.
 Elements of a use case diagram
 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:
 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 diagram
 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 diagram
 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 ).
 note
 A single use case (or primary functionality) might be
associated 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 Scenarios
  identifying all the different user roles and
drawing a use case diagram for the software
  writes a series of use case scenarios for each use
case.

 Use Case ： what to use ？

 Use Case Scenarios : How to use?
 Use Case Scenarios
 It is important for the analyst to consider all
possible normal and abnormal use case scenarios for
a given use case.
 "normal" use case scenarios
 describe the normal flow of events
 "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 help verify coverage and
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?
 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. 所以，越详细越好！
 note
 It is important to keep the language of the scenarios
simple and unambiguous, 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 so …… on the part of the software, the step is
ambiguous and 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.1 Noun Extraction and Preliminary Class List
Refinement
 4.3.2 Object Diagrams in UML
 4.3.3 State Transition Diagrams in UML

 Assessments
 Exercise 4
 Noun extraction is the first step in class modeling
  Noun extraction  class modeling
 Noun extraction( 名词提 取法 ) 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
 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 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 Extraction
 The 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
elevator controller
 The informal strategy is shown here, with the
candidate classes (nouns) underlined (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 eight different nouns:
 button, elevator, floor, movement, building, illumination,
request, and door.
 analysis
 Three of the nouns (floor, building, and door) do not need to
be explicitly modeled by the solution — they are outside the
scope of the problem boundary.
 Three of the remaining nouns (movement, illumination, and
request) are abstract nouns that do not correspond to a
physical 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 left
 Elevator and Button.
 because there are two kinds of buttons (in the elevator and
on the floors)
 two subclasses of Button are defined: ElevatorButton and FloorButton.
 Noun Extraction from Use Case Scenarios
 The multi-step noun extraction process described
above works fairly well for simple software systems
that do not have many use cases. 好用可 惜范围有
限
 For more complicated systems, the informal
strategy for solving the problem may include several
paragraphs.
 So , it 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),
 The KMT is a graphical user interface that allows
knowledge engineers to edit and update the various
knowledge sources used in machine translation
systems (dictionaries, grammars, etc.).
 A piece of the KMT software documentation
describes the normal use case scenario for a
grammar update (next page).
 use case scenario
 The Analyzer maintainer receives a problem report about a
sentence that does not pass when it should. He invokes the
KMT, and enters the sentence as a test case. The sentence is
parsed and the maintainer verifies that the current result is
not the desired one. The maintainer then selects module
tracing options within KMT, which turns on tracing of the
input/output of the Syntaxifier module in the Analyzer. The
sentence is run again, and this time the trace output indicates
that there is no complete parse. By inspecting the trace
output (which indicates the grammar rules that are tried),
the maintainer determines that a particular rule which
should have fired did not fire, due to a mistake in the rule
syntax. The maintainer invokes the Edit capability of KMT
on the particular rule.
 use case scenario(con.)
 After correcting the rule, the maintainer requests (via KMT)
that the Analyzer reload the grammar. The sentence is
parsed once again, and the desired result is achieved. The
maintainer then refers to the available set of test data for the
grammar (Syntaxifier), and runs a set of appropriate
regression tests to make sure that the current fix has not
caused other bugs in the grammar. Using the KMT interface
to run pre-defined test suites, the desired tests are selected
and run. Any sentences that fail testing are placed into a new
(temporary) set of test cases, and the maintainer iterates
through each case using the same set of steps followed for
the first bug. When all the work is finished, the maintainer
requests that the current (temporary) copy of the grammar
be checked back into the file system as a revised version of
the original grammar. This new version can be used for
further debugging and revision in a later session. Eventually,
it will become part of a new frozen version of the entire
system for testing and delivery.
 candidate class refinement is important !
 Many of the nouns that appear in the use case
scenario are not candidate class objects, and must
be eliminated
 How can we do?
 using three principles
 three principles for candidate class refinement
 Noun expresses an abstract 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 concept 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 concept 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 refinement
 We got:
 Analyzer, module, grammar, rule, sentence, test suite.
 These objects should be modeled in the class diagram for the KMT tool.
 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 UML
 Elevator Example
 KMT Example
 object diagram
 a candidate class list has been created (by noun extraction)
 draw an object diagram
 object 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
their relationships;
 By refinement, more detail (the class variables and methods) is added
 The final details include
 the class variable types,
 each method (the arguments, argument types, return types)
 But often not finalized until the Design Phase. 需要不断的
迭代！
 Object diagrams In UML
 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:
 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 UML
 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 Class relations
 if two classes A and B are related by a one-to-many
relation, then a 1 is drawn near the end of the link
nearest to class A, and an N is drawn near the end of the
link nearest to class B.

 Similar notation is used for one-to-one and many-to-

many relationships. If the exact cardinality of the
relationship is known in advance (for example, one-to-
three) then positive integers can be used in place of M
or N. In simplified object diagrams, sometimes the
relation labels are omitted. A link without cardinality
information is assumed to be a one-to-one relation; a
link without a label is assumed to denote a generic
association (for example, a "part-of" relation).
 cardinality of Class relations
 1 to many

 1 to 1

 Many to many
 Elevator Example
 The class diagram is drawn using UML class
diagram notation. Note that two of the class
variables have already been defined, but the rest of
the information regarding variables and methods is
as yet undefined.
 The inheritance relationship is represented by the
arrow drawn to Button from its subclasses.
 The relationships between the Elevator and the two
types of buttons are drawn as named associations:
each association (link) includes a label
(communicates with) and cardinality information.
 The diagram represents the fact that m elevator
buttons communicate with n elevators, a many-to-
Elevator Example
 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,
 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 added
 KMT Example
 Remember? the process of noun extraction from a
use case scenario for the Knowledge Maintenance
Tool (KMT).
 The preliminary object diagram is here
 relations
 In the diagram, All the relations 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 us
 how some of the candidate classes from noun extraction are
actually best modeled as attributes,
attributes not objects
 traceOptions, version, result, traceOutput.
 The example also tell us
 that some of the methods associated with some objects are
already known at this time.
 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
 the method signatures are not fully specified at this time.
 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 UML
 Elevator Example
 We have learnt
 data modeling is concerned with identifying all of
the data objects in a software
 extracting nouns
 creating an object diagram
 The analysis process also involves dynamic
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 UML
 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:
 represented as a solid (black) circle
 with an unlabeled transition to the first state in the state diagram.
 state transition diagrams in UML
 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 Example
 An example of a UML state diagram for the
Elevator Controller scenario (see your textbook fig.
12. 7 ， p.281)
 explain
 The start state initializes the system at the Elevator Control
Loop state, which is the main "wait" state of the system.
 There are no actions associated with the Elevator Control
Loop state, so only the state name (label) appears inside the
rounded rectangle that denotes the state.
 There are six transitions from the Elevator Control Loop
state; each transition is labeled with a set of predicates that
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 start and end at the same
state.