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
steps
begin with a detailed analysis of the data. 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
Class 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. 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
the three steps are performed in parallel the diagrams keep being revised 不断修订
making a change or revision in one will trigger corresponding changes in the others. 相互关联的 , 一改俱 改
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
The use case scenarios are written in plain language,
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).
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: 形式化的表示
it is often more useful to
current state and event and predicate => next state 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
The input to the noun extraction step is
analyze use case scenarios / other written descriptions of a system's proposed behavior define a set of candidate objects or classes. 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: 简洁的问题定义
Informal strategy: 描述产品
Define the product briefly, in a single sentence if possible. 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.
So two candidate classes left
Abstract nouns generally do not end up as classes, but they are sometimes modeled as attributes 不作为类，而是作为类的属性 Illumination ： an attribute of a Button class 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.
Noun expresses a concept outside of the problem scope.
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). 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
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
shows the relationships between the objects also referred to as class diagrams in some texts.
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-tomany relationships. If the exact cardinality of the relationship is known in advance (for example, one-tothree) 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?
Note
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. 成对操作 ! 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.