Download Understanding the Impact of Climate Change on Agriculture - Prof. Doug Niehaus and more Study notes Software Engineering in PDF only on Docsity!
EECS 448 1 Dr. Douglas Niehaus © 2009
Object Oriented Analysis
Chapter 12
EECS 448
Dr. Douglas Niehaus
EECS 448 2 Dr. Douglas Niehaus © 2009
Overview
Object-oriented analysis is a semi-formal approach to
requirements analysis used as part of the Object-
oriented paradigm
Well over 60 techniques have been proposed that
are all basically equivalent
Today, the Unified Process is almost always the
choice of those choosing to do OO SW production
Jacobson, Booch, Rumbaugh, 1999
Major advances were made in OO paradigm
between 1990 and 1995
Usually takes 15 years for general acceptance
Millenium Bug (Y2K) concerns accelerated this
Needed to revamp SW, used current leading edge
Analysis Work-Flow
Analysis WF of the Unified Process has two aims
Obtain a deeper understanding of requirements
Describe those requirements in a way that makes
it easier to create an OO product design and
implementation that is easy to understand and
maintain
Unified Process is case driven
During the analysis WF the use cases of the
product are described in terms of product class
use and interaction
Deepening understanding of requirements and
product may suggest additional use cases or
adjustments to existing use cases
Analysis Work-Flow
Unified Process defines three types of classes
Entity : models information that is long-live, often
including persistence across product instances
E.g. Painting Class in Art Gallery product
Boundary : models interaction of software product
and its actors
Actors are humans or other SW products that
act independently and interact with product
Associated with some form of I/O
E.g. Purchases Report Class
Control: models decision making parts of product,
embodying computations and other algorithms
E.g. Compute Masterpiece Price Class
EECS 448 5 Dr. Douglas Niehaus © 2009
Analysis Work-Flow
UML defines symbolic notation for these classes
These are stereotypes, extensions of UML for
expressing particular concepts
Additional constructs like these can be created to
model a specific system accurately
Figure 12.
Perfectly fine symbols and standardization can
help but making your own choices would be OK
EECS 448 6 Dr. Douglas Niehaus © 2009
Analysis Work-Flow
During the analysis WF, use cases are described in
terms of the classes defined for the product
Classes are a vocabulary for describing the
product components being tested by seeing how
well it permits describing the use cases
Difficulty describing a use case means either
Use case is badly defined or described
Class decomposition needs refinement
Unified process does not specify a method for
extracting product classes
Some general advice can be helpful, but practice that
comes with experience is probably the most
important component as it develops SWE's intuition
Extracting Entity Classes
Functional Modelling: Work through specific
scenarios representing each of the use cases
Entity Class Modelling: Define entity classes and
their attributes.
Determine relationships and interactions among
entity classes
Create a Class Diagram showing inheritance
relationships
Dynamic Modelling: List operations performed by
each entity and what operations on an entity will be
used by outside elements (actors, boundary, control)
Statecharts are a popular representation for this
Iterative process interleaving modelling types
Extracting Entity Classes
Word type extraction from a written use case
Book mentions this but not as extensively as I
think is best
Nouns are often class candidates
Entity, Boundary, Control
Adjectives often denote class attributes or
subclasses depending on which qualification better
serves OO descriptions of use cases
Verbs often denote class methods invoked, although
they can also sometimes best be described by
independent subroutines
Adverbs often denote method parameters that affect
method behavior, but they can also denote multiple
related methods
EECS 448 13 Dr. Douglas Niehaus © 2009
Elevator Example
Entity Class Modelling
Create set of entity classes and their attributes
No methods yet
Two approaches to Entity Class identification
Identify them from the use cases (nouns)
Study normal and exceptional cases
Identify components playing roles
CRC Cards
Effective when SWE have domain experience
Short-cuts contemplation based on experience
Floor buttons, Elevator buttons, elevators, doors,
timers extracted from scenario
EECS 448 14 Dr. Douglas Niehaus © 2009
Elevator Example
Large number of scenarios may initially suggest a
large number of classes
Refining a candidate vocabulary by applying it to
many scenarios and looking for commonality
Adding a candidate class is easier than removing
one
Apparently different classes can sometimes be
consolidated by adding an attribute variable to
emphasize large set of common semantics and
minor set of different semantics
Noun extraction
Describe product in a paragraph
Identify nouns
Elevator Example
Noun classification
Exclude those outside problem/product
boundaries
Can be useful to change typeface of candidate noun/
entity classes in description
Floor, building, door can be ignored
Assumes elevator door is controlled locally?
Elevator door related to timer which may be
centrally or locally determined
Button and elevator are obvious candidates
Floor buttons and elevator buttons could be related
in class hierarchy
Elevator Example
Candidate Hierarchy
Abstract Button class
inherited from Elevator
and Floor buttons
Elevator class and its
relations
M buttons within each
elevator instance
N elevators
2m-2 floor buttons
Only 1 on bottom
and top floors
EECS 448 17 Dr. Douglas Niehaus © 2009
Elevator Example
Button Class
All buttons have Illuminated attribute
Other attributes might include entity the button
sends messages to
Elevator and Floor sub-class relation denoted with
lines and open triangle
Elevator Class
Attribute “doors open” tracks door state
Might also have state variable describing floor
At least for floor indicator
Might also be in controller class
Clearly a controller is needed
Coordinating the set of all elevators as well as
each individually
EECS 448 18 Dr. Douglas Niehaus © 2009
Elevator Example
Inserting controller more realistic
Changes class relations
Buttons do not communicate
directly to the elevator
Controller in between
Controller sends messages to
elevator, floor and elevator
buttons, elevator floor indicator
Notice 1-to-many and many-to-
relations between controller and
elevators
More complex to model and
program
Class-Responsibility-Collaboration (CRC) Cards
Utilized by some groups to describe product classes
For each class
Name
Function/Duties in product
List of other classes with which it collaborates
Those it invokes
Those it is invoked by (can be left implicit)
Extensions
Identify class attributes
Specific set of methods invoked and by whom
Post-It notes moved around on a board
On-line diagram wold work well too
Class-Responsibility-Collaboration (CRC) Cards
CASE tool support exists
General Drawing tools
Drawing Templates UML/CRC format
System Architect
Strengths of CRC
When used by a group it promotes member
interaction which can highlight missing or incorrect
class components or class set members
Relationships among classes are tested and
refined by discussion vis a vis use cases
Role playing by group members as classes
Good way to train your intuition
EECS 448 25 Dr. Douglas Niehaus © 2009
Test Work-Flow
CRC collaborations
determined by examining
class diagrams
First iteration of CRC for
Elevator Control Class
Can highlight badly placed
responsibilities
Turning buttons on and
off vs. sending signals
Classes can be overlooked
Elevator Door
Iterations change class
hierarchy and relations
EECS 448 26 Dr. Douglas Niehaus © 2009
Test Work-Flow
Use case diagrams may need adjustment or addition
and certainly must be re-examined
Statechart(s) extended to include new classes
Scenarios updated to include new entities, their use
by actors and their interactions with each other
Figure 12.11, page 391, second iteration of
Normal scenario extended to include controller
messages to elevator doors and buttons, etc
Even with the greatest care, when you get to the OO
design WF, adjustments to the OO analysis WF may
be necessary
Revision to the set of artifacts
Refined Analysis Products
Refined Analysis Products
EECS 448 29 Dr. Douglas Niehaus © 2009
Extracting Boundary & Control Classes
Boundary classes are linked to concrete components
and tend to be a bit easier to extract
Each I/O screen, printed report, GUI component
Granularity of the classes intended to maximize
“clarity” of the use-case descriptions
GUI components as small as a single button or as
large as an entire screen full of widgets might
correspond to a Boundary class
Set of information and how it related to OO
analysis is the determining factor
Classes might be used to represent individual users
Preferences or state within and interaction
scenario
EECS 448 30 Dr. Douglas Niehaus © 2009
Initial Functional Model
Functional model of an application concentrates on
generating scenarios from the use-cases
Use-case diagram illustrates interactions among
users and components of the product, as well as
among product components
Art Dealer SW product
Dealer is the only user
Customer is an actor
Both buyer and seller roles
Buying and Selling use cases
Art dealer can use product in 4 ways, so there are
4 use cases
Initial Functional Model
Initial Functional Model
Scenarios depict component interactions
Variations of use cases such as buying a painting
Numbering of relevant sentences enhances
readability while permitting description of additional
information
Multiple scenarios can be combined into a single
use-case diagram
Normal and exception scenarios are both important
Can be combined into extended scenarios
Scenarios are important to functional modelling and
to the dynamic modelling as well
EECS 448 37 Dr. Douglas Niehaus © 2009
Initial Class Diagram
Studying the use cases can lead to additional insight
Masterwork has all attributes of masterpiece, but
needs additional information as well
EECS 448 38 Dr. Douglas Niehaus © 2009
Initial Class Diagram
Need to distinguish gallery painting and painting
auctioned worldwide add new classes
Need to compare gallery paintings to similar
paintings auctioned worldwide to determine prices
Auctioned painting is a painting but has nothing to
do with many aspects of paintings owned by
gallery
Fashionability class
A painting of Other Painting class uses aninstance
of fashionability for that artist to compute
maximum price
Initial Class Diagram
Initial Class Diagram
Attributes of each class are added
Top level global class can contain attributes for the
application as a whole
Often good for holding invocation options in a
wide range of applications
Associated with starting execution of product as a
whole
Other classes represent types of paintings and
associated attributes and operations
Version leaving out attributes but using stereotypes
of each is also a useful view
EECS 448 41 Dr. Douglas Niehaus © 2009
Initial Class Diagram
EECS 448 42 Dr. Douglas Niehaus © 2009
Initial Class Diagram
Initial Dynamic Model
Dynamic modelling is the third step in extracting
entity classes
Statechart is a compact representation of dynamic
behavior over several use case scenarios
Statechart
Starting (solid) and Ending states (solid circled)
Arrows depict permitted transitions
Start leads to event loop
Note correspondence to GUI event loop
gtk.main()
Major states note name and narrative
Buying, Selling, Report, Fashionability
Initial Dynamic Model
EECS 448 49 Dr. Douglas Niehaus © 2009
Control Class Extraction
Non-trivial computation modelled by control class or
Control class methods grouping sets of related
computations in some applications
Might be methods of entity classes, IMHO
Art Dealer has four computations
Masterpiece Price
Masterwork Price
Other Painting Price
Trends Calculation
Four initial control classes
Computer Masterpiece Price, Computer
Masterwork Price, Computer Other Painting Price,
and Computer Future Trends
EECS 448 50 Dr. Douglas Niehaus © 2009
Refining the Use Cases
As a set of classes is defined, it needs to be checked
against existing requirements and use-cases
Often reveals a need for refinement
Checking the candidate Art Dealer classes against
the proposed classes indicates that Buying a
Painting and Producing a Report use-cases should
be refined
Buying a Painting becomes
Buy a Masterpiece
Buy a Masterwork
Buy Other Painting
Each painting type has a different class with different
information and so buying each is slightly different
Refining the Use Cases
Producing a Report use case becomes
Produce a Purchase Report
Produce a Sales Report
Produce a Future Trends Report
Key point is that the set of use cases should use all
the major product components at least once
Compilers exist that include instrumentation in
emitted code to record and report the “branch
coverage” of a set of software test cases
Aim is to give a quantitative measure for how
completely the software functions have been
exercised
Assumes correspondence of functions and code
conditional branches which is often tenuous
Refining the Use Cases
Third iteration of the
product use-cases is more
complex
Specification of each use
case and set of scenarios
obviously contains more
detail than the diagram
Buying separate painting
types does not require a
separate interface for each
Attribute or sub-
component of main
purchase choice
EECS 448 53 Dr. Douglas Niehaus © 2009
Refining the Use Cases
Implications of refined use cases for other UML
diagrams describing Art Dealer business model
Splits the original Buy a Painting case into three
separate use cases, each representing a set of
scenarios
Art Dealer must supply/choose the classification of
the painting to permit the SW to choose the
correct class and associated software
GTK entry/combo box does this
Permits entering a choice as text or selection
from a pull-down list
Splits the Produce a Report case into three as well
EECS 448 54 Dr. Douglas Niehaus © 2009
Refining the Use Cases
Buying a Masterpiece use-case example
Refining the Use Cases
Use Case Realization
Use cases describe interaction among actor(s) and
the software product
Utilized at the beginning of software life cycle in
the requirements work-flow
Details are added as each case is refined and as
new use cases are added
Refinement includes a description of the classes
used as part of each case, as classes are defined
During analysis and design work-flows
Use cases guide design and implementation
because they must be supported by specific software
components which implement specified semantics
During the implementation workflow
EECS 448 61 Dr. Douglas Niehaus © 2009
Use Case Realization
Use case scenario elements are realized as a set of
actions among collaboration diagram objects
EECS 448 62 Dr. Douglas Niehaus © 2009
Use Case Realization
Sequence diagram represents (almost) same set of
information as the collaboration diagram
Developers can choose to use one or both
Sequence Diagram
Uses vertical lines for time-lines of each object
Lifeline of an object: section of time line from
object creation to object deletion
Activation box: narrow rectangle on lifeline
showing when object was active
Sequence diagrams are thus capable of showing
concurrent execution in multi-threaded systems
Important in other applications, not relevant in 448
project and examples
Use Case Realization
Sequence diagrams can take more room
Use whichever communicates most clearly
Use Case Realization
Strengths of a sequence diagram
Shows the flow of information unambiguously
Ordering of messages is clear
Shows that every transfer of information in one
direction is followed by a transfer in the other
Possibly just a method invocation return code
Sequence diagram tends to be better at describing
the transfer of information
Focus for much of the time in the Analysis WF
Collaboration diagrams tend to permit
concentrating on the classes better
correspondence of Class and Collaboration
Diagrams is useful
EECS 448 65 Dr. Douglas Niehaus © 2009
Use Case Realization
Buy Other Painting use case
Similar in structure to other cases, but different
classes are used and low level set of events is
different in collaboration or sequence diagrams
EECS 448 66 Dr. Douglas Niehaus © 2009
Use Case Realization
Other use cases are quite simple and so their class
diagrams and collaboration/sequence diagrams re
basically trivial too
At some point you may elect no to create them
Prudent when it saves time
Painful when it overlooks important details
Judgement is involved and both types of
mistake are common
Use Case Realization
Future Trends Report slightly less trivial
Incremental Improvement
Several incremental improvement steps have
increased the information content of the class
diagram reflecting the set of product classes
Entity, Boundary and Control class extraction
Interrelationships among classes
Inheritance
Use
Information in various class diagrams combined
First use case information is included
Then, class inheritance relations can be added and
any additional classes
EECS 448 73 Dr. Douglas Niehaus © 2009
Test Work-Flow
Analysis WF of the art dealer product can be
checked in two ways
Classes and their relations can be checked by
taking another view of situation using CRC cards
All artifacts of Analysis WF can be inspected
By all group members individually or together
By SQA alone or with development
By customer
All checking is still inspection rather that execution
because no software exists, generally
RP might exist but it addresses limited issues
Proof-of-concept code may exist but it
demonstrates capabilities and test assumptions
Not product features
EECS 448 74 Dr. Douglas Niehaus © 2009
Specs Document in Unified Process
Unified process is use case driven
Use cases and artifacts derived from them contain
all information appearing in tradition specs doc
Generally convey more information more
accurately to customer
Collection of artifacts for complete product
constitutes contract between client and developer(s)
Traditional specifications document usually played
contractual role
Interaction diagrams reflecting classes that realize
use case scenarios are shown to client
Replaces some of RP uses
RP better for GUI, diagrams could be used
Specs Document in Unified Process
Why 448 will build a RP
Proof-of-Concept for GUI SW related to widget
use, look and fell, etc
Possible to draw a diagram that is hard to build
Screen shot of interface implemented using
PyGTK (or PyQT) can, by definition be built
Helps professor avoid crash-and-burn scenario
where some group cannot finish because they do
not start learning about GUI code early enough
More on Actors and Use Cases
A use case illustrates interaction among software
components and actors
Actors can be humans or SW outside the product
boundary, outside what you develop
Finding actors and use cases can be subtle
Consider every role played by individuals
interacting with the SW
Actors extracted from list of roles
Sometimes different actors, sometimes just
slightly different behavior or options by an
existing actor
Mortgage example: first apply (applicant role) and if
approved borrow (borrower) – could be 2 actors or
two roles for 1 actor depending on SW design
EECS 448 77 Dr. Douglas Niehaus © 2009
More on Actors and Use Cases
Unified process terminology uses term “worker” to
refer to a particular role
Poor choice, but in this case applicant and
borrower would be different workers
Makes more sense to me as 2 roles for single
actor although software may make taking a view
as two (related) actors better
In many business cases finding the roles often easy
Construct use case business model
Roles are all types of interactions with business
Find subset of use case diagram that models the
software product and its users
Actors in this subset are the product actors
EECS 448 78 Dr. Douglas Niehaus © 2009
More on Actors and Use Cases
Having identified relevant actors finding use cases
fairly easy
Each role will involve one or more use cases
Start with each actor and enumerate scenarios
involving each of their roles
Categorize according to application semantics
and how you are choosing to explain them to
everyone
Clients, developers, users, etc.
Flexibility in defining these things is helpful
Too rigid definition of actors, roles, etc. can lead to
peculiar results
Object Oriented Analysis Summary
Iterate
Perform Functional Modelling
Perform Entity-Class Modelling
Perform Dynamic Modelling
Until a consistent and complete set of entity classes
have been extracted
Then, Extract Boundary and Control Classes
Refine use cases in reaction to data of all kinds
Additional situations
Gaps in ability to explain
Changes in classes
Perform use case realization
CASE Tools for OO Analysis WF
Several CASE tools have been developed to support
OO analysis
Essentially a drawing tools for performing
modelling steps
Simpler to modify on-line diagrams vs hand-drawn
Support for graphical aspects of OO analysis
Some tools also draw CRC cards
Changes to underlying model can be reflected
automatically in all related diagrams
Some CASE tools support a considerable portion of
OO software life-cycle
Currently, most tools support UML
e.g. Rose and Together
ArgoUML is an Open-Source CASE tool
