Analysis & Design Modeling
COP4331 and EEL4884
OO Processes for Software Development
© Dr. David A. Workman
School of Computer Science
University of Central Florida
February 1, 2009
February 23, 2010
Overview of USP
Requirements
Elicitation
(Definition)
Use Case
Model
Requirements
Elaboaration
(OO-Analysis)
Analysis
Model
The process of defining
and modeling the
Problem Space
Object-Oriented
Design
Design &
Deployment
Models
February 23, 2010
Problem Statement
& User Needs
The process of defining
and modeling the
Solution Space
Object-Oriented
Implementation
(Programming)
(c) Dr. David A. Workman
Mapping design to
Implementation
Space
Code in an
OOPL (Ada95)
(C++)(Java)
Component
Model
2
Overview of USP
Birth
Death
Inception
Itera- Iteration tion
•
•
Elaboration
Iteration
Iteration
Construction
Iteration
Arch. Design
Design Refinement
(Analysis Model)
(Design Model)
…
Iteration
Iteration
Transition
…
Itera- Itera- Iteration tion tion
Inception
Elaboration ( focus on “Do-Ability” )(Architecture + high-fidelity cost est.)
– Develop detailed use cases (80% of use cases).
– Develop a stable architectural view of the system using the Analysis Model, Design
Model, Implementation Model, and Deployment Model.
– Create a baseline system specification (SRS).
– Produce the Software Development Plan (SDP) which describes the next phase.
•
•
Construction
Transition
February 23, 2010
(c) Dr. David A. Workman
3
Requirements Elicitation vs Elaboration (USP)
Use-case Model
Described using the language of the
customer.
External view of the system.
Analysis Model
Described using the language of the
developer.
Internal view of the system.
Structured by Use cases; gives
structure to external view
Structured by sterotypical classes and
packages; gives structure to internal
view
Used primarily as a contract
Used primarily by developers to
between client and developer as to
understand how the system should be
what the system should do.
shaped; that is, designed and
implemented.
May contain redundancies and
Should be complete, precise,
inconsistencies among requirements consistent, and testable.
Captures functionality of the system Outlines how to realize functionality
including architecturally significant within the system; works as the first
functionality.
cut at design.
Defines use cases further analyzed in Defines Use-case realizations, each
the analysis model.
one representing the analysis of a use
case from the Use Case model.
February 23, 2010
(c) Dr. David A. Workman
4
UML Process and Artifacts
2: Requirements
Elaboration
(Analysis &
Specification)
1: Requirements
Elicitation
(Capture)
Use Case
Model
State
Chart
Communication
Diagram
Model
System/Gui
behavior
Model
Use Case
Flow
Model
Use Case
External
behavior
Activity
Diagram
Use Case
Diagram
Software
Requirements
Spec
Analysis
Model
Define System
Boundary;
Identify Actors
And External
Interfaces;
Identify Use Cases Architecture
Diagram
Identify Packages
their Interfaces &
Relationships
February 23, 2010
3: Software
Design
Software
Development
Plan
Partition
Software into
Work packages.
Estimate cost, resources,
Size, and schedule.
Define Internal
View of System
Identify Subsystems
Identify Classes & Objects
Allocate Functional
Responsibilities
Communication
Diagram
Class
Diagram
Model Use Case
Internal behavior
Identify Boundary, Control
Entity Classes and their
Relationships
(c) Dr. David A. Workman
5
Requirements Elaboration
•
Purpose
–
–
–
–
–
–
•
Identify the Analysis classes and/or subsystems whose instances are needed to perform the use case’s flow of
interactions.
Allocate the functional responsibilities of use cases to interacting objects and/or to participating subsystems.
Define functional requirements for operations and encapsulated data of analysis classes and/or subsystems
and their interfaces.
Capture detailed design requirements for each use case.
Prioritize use cases and subsystems for further development
Plan the design and construction activites, estimate size, effort, schedule and cost.
Identify Participating Analysis Classes
For each use case, identify the problem data that enters and leaves the system via that use case. Identify the
problem data that must persist within the system to support other use cases; this is data that must be shared
by use cases related on the Use Case Diagram. Assign boundary classes to handle problem data crossing the
system boundary.
•
Describe Analysis Object Interactions
–
–
–
–
•
Construct communication diagrams containing participating actors, analysis objects, and message
transmissions among them. If necessary, create separate diagrams for distinct sub-flows determined by the
same use case.
A use case should be invoked by a message from an actor to an analysis object.
Messages flowing between objects should be labeled with the action requested of the receiving object; these
messages define the functional responsibilities of the receiving object.
Support the collaboration diagram with narrative to clarify details.
Artifacts of Analysis
–
–
–
–
–
–
Analysis Class Diagrams (UML) – static architectural design
Activity Diagram (UCM) – dynamic flow of use cases or sub- use cases
Communication Diagrams (UML) – design of dynamic interaction flow for each use case
Statecharts/Diagrams (UML) – dynamic behavior of key control objects and subsystems
Use Case Coverage Table – architecture completeness; basis for integration and system testing
Traceability Matrix – ensures all requirements have been allocated to solution elements
February 23, 2010
(c) Dr. David A. Workman
6
Requirements Analysis & Specification
•
Inputs
– Outputs from Requirements Elicitation ( Use Case Model ).
– Technical documents or expertise relevant to problem domain, in general, and to
the Client's problem, in particular.
•
Activities
Refine requirements by eliminating inconsistencies and ambiguities. Formalize
requirements by preparing a System Requirements Specification. Develop an
initial software development plan.
•
Outputs
– Software Requirements Specification (SRS)(Analysis Model)
•
•
•
•
•
•
•
UML Use Case Specifications
UML Activity Diagram for Use Case flow
UML Class Model
UML Communication and Sequence Diagrams
UML State Diagrams
Problem Glossary
Other info.
– Software Development Plan (SDP)
February 23, 2010
(c) Dr. David A. Workman
7
Use Case Coverage Table
UC1
UC2
UCk
UCn-1
UCn
Class-1
Class-2
Data
members
& Methods
Class-m
• Columns are labeled by Use Cases.
• Rows are labeled by Analysis Classes.
• Table entries identify the attributes and operations of a particular class, identified by the row,
needed to support the use case corresponding to the column. The union across the row should
define all the attributes and operations needed for that class to support ALL use cases. The
union down a column should identify all the classes (their attributes and operations) required
to realize a given use case.
February 23, 2010
(c) Dr. David A. Workman
8
Requirements Mapping Table
UC1
UC2
UCk
UCn-1
UCn
Class-1
Functional
Requirements
Class-2
Class-m
• Columns are labeled by Use Cases.
• Rows are labeled by Analysis Classes.
• Table entries identify the Requirements met by a given class (row) relative to a
given use case (column). These requirements should be identified by number as specified
in your Use Case Model. The union of all table entries should yield all functional
requirements. If not, then something is missing.
February 23, 2010
(c) Dr. David A. Workman
9
Software Requirements Specification1
• Title
• TOC
1. Introduction
1.1
1.2
1.3
1.4
1.5
2.
3.
4.
5.
•Purpose of this SRS.
•Intended audience.
•Identify the software product.
•Enumerate what the system will and will not do.
•Describe user classes and benefits to each.
Purpose
Scope
Definitions. Acronyms, and Abbreviations
References
Overview
Overall Description
Specific Requirements
Appendices
Index
This sections defines the
vocabulary of the SRS. It
may reference an appendix.
Reference all documents
and SMEs used to write the SRS.
E.g. Use Case Model and Problem
Statement; Experts in the field.
• Describe the content of the rest of the SRS.
• Describe how the SRS is organized.
NOTES: Info. from the USDP Use Case Model maps into the above outline as follows.
1.2 Scope should summarize the main concepts and details presented in the System Concept and Vision of the UCM.
1.3 corresponds to the Glossary of the UCM.
1
February 23, 2010
(c) Dr. David A. Workman
IEEE Std 830-1998
10
Software Requirements Specification1
• Title
• TOC
1. Introduction
• Present the business case and operational concept of the system.
• Describe how the proposed system fits into the business context.
• Describe external interfaces: system, user, hardware, software, comm.
• Describe constraints: memory, operational, site adaptation.
2. Overall Description
• Summarizes the major functional capabilities.
• Include the Use Case Diagram and supporting
narrative; identify actors and use cases.
• A Data Flow Diagram may be appropriate.
2.1 Product Perspective
2.2 Product Functions
Describes and justifies technical skills and
capabilities of each user class.
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions and Dependencies
3. Specific Requirements
4. Appendices
5. Index
Describes other constraints that will
limit developer’s options; e.g., PL,
target platform, database, network
software and protocols, development
standards requirements.
States assumptions about availability of certain
resources that, if not satisfied, will alter system
requirements and/or effect the design.
1
February 23, 2010
(c) Dr. David A. Workman
IEEE Std 830-1998
11
Software Requirements Specification
Specifies software requirements in sufficient
detail to enable designers to design to satisfy
those requirements and testers to verify
requirements.
3.0 Specific Requirements
3.1 External Interfaces
3.2 Functions
3.3 Performance Requirements
3.4 Logical Database Requirements
3.5 Design Constraints
3.6 Software System Quality Attributes
3.7 Object Oriented Models
3.8 Implementation Issues
4. Appendices
5. Index
February 23, 2010
Every stated requirement
should be externally perceivable by users,
operators, or externally connected systems.
Requirements should include, at a minimum,
a description of every input (stimulus) into the
system, every output (response) from the
system, and all functions performed by the
system in response to an input or in support
of an output.
(a) Requirements should be stated in
conformance with section 4.3 of this standard.
(b) Requirements should be cross-ref’d to their
source.
(c) All requirements should be uniquely
identifiable.
(d) They should be organized to maximize
readability.
(c) Dr. David A. Workman
12
Software Requirements Specification
Should detail description of all inputs and outputs,
but should complement, not duplicate, information
presented in section 5.2.
Examples: ( GUI screens, File formats)
3.0 Specific Requirements
3.1 External Interfaces
Should include detailed specifications of each
use case (analysis view) , including collaboration
and other diagrams useful for this purpose.
3.2 Functions
3.3 Performance Requirements
3.4 Logical Database Requirements
3.5 Design Constraints
3.6 Software System Quality Attributes
3.7 Object Oriented Models
3.8 Additional Comments
•
Index
•
Appendices
February 23, 2010
Should include:
(a) Types of information stored in DB
(b) Data entities and their relationships
(c) Performance requirements
Should include:
(a) Standards compliance
(b) Accounting & Auditing procedures
The main body of requirements organized in
a variety of possible ways.
(a) Architecture Specification
(b) Class Diagram
(c) State and Collaboration Diagrams
(d) Activity Diagram (concurrent/distributed)
(c) Dr. David A. Workman
13
Software Requirements Specification
3.7 Object Oriented Design
3.7.1 Software Architecture
Package Diagram with narrative: decompose the software system into packages or
subsystems; show the dependencies among subsystems; identify key classes and or
subcomponents within
Checkout Station
Grocery Conveyor
POSS
Conveyor
Controller
Shopper
Sales Terminal
Coveyor
Belt
Cash
Drawer
Waiting Line
Clerk
Queue Mgr
February 23, 2010
(c) Dr. David A. Workman
Shopper
Queue
14
Requirements Analysis (USP)
•
Artifacts
– Analysis Classes
Abstractions of one or several classes and/or subsystems in the design. Has the
following characteristics:
• Focuses on functional requirements
• Seldom defines or provides any interface in terms of operations. Behavior is defined
in terms of responsibilities on a more or less informal level.
• Defines attributes, but at an abstract level. Attribute types are conceptual and have
meaning in the problem domain. Attributes found during analysis commonly
become classes in the design and implementation.
• Class relationships are more informal and have less significance compared to design
and implementation.
• Fall into one of three categories: Boundary, Entity, and Control
– Boundary Classes
• Used to model interaction between the system and its actors! The interaction often
involves receiving and presenting information and/or requests. They collect and
encapsulate requirements defining external system interfaces - if these change, only
boundary classes should be effected.
• Boundary classes are often realized by windows, forms, panes, comm ports, etc.
They are characterized by the content and granularity of information that they
exchange at the system interface - not the form and style of the exchange.
February 23, 2010
(c) Dr. David A. Workman
15
Requirements Analysis (USP)
•
Artifacts
– Entity Classes
Used to model information that is long-lived and often persistent. They model
information and behavior of some phenomenon or concept such as an individual, a
real-life object or event.
• Normally derived from a business (or domain) entity class. However, entity classes
differ from their corresponding business counterparts in that they express the
developer's view of how a business entity should be represented in the system; i.e.,
business entities may encapsulate information that is irrelevant to the system.
• Entity object need not be passive.
– Control Classes
Used to represent coordination, sequencing, transactions, and control of other objects
and are often used to encapsulate control (thread) related to a specific use cases.
They are used to encapsulate complex computations or business logic that cannot be
logically associated with an entity class.
• They encapsulate high-level control flow.
• They delegate work to boundary and entity classes where appropriate.
• They do not encapsulate issues related to interactions with actors (boundary classes).
• They do not encapsulate issues related to persistence (entity classes).
February 23, 2010
(c) Dr. David A. Workman
16
Requirements Analysis (USP)
•
Artifacts
– Use-case Realizations
A collaboration within the analysis model that describes how a specific use case is
realized and performed in terms of analysis class instances. A use-case realization
traces directly to a system use case in the requirements model.
A use-case realization includes the following:
• Class diagrams that identify participating analysis classes ( names & responsibilities,
may include important problem attributes )
• Interaction diagrams ( preferably communication diagrams ) that depict the
particular interaction flow among analysis objects engaged in the use-case scenario
notes:
(1) boundary objects need not be specific to a given use case – many use cases may
share the same boundary objects;
(2) entity objects also persist beyond a single use case
(3) control objects frequently created when the use case starts and are destroyed
when the use case ends – but, like boundary objects, control objects may manage
more than one use case
• Flow-of-events analysis is narrative that accompanies the interaction diagram and
explains details about the interaction sequence that may not be obvious from the
diagram. This narrative explains the internal system view of events relating to a use
case.
• Special requirements (non-functional)
February 23, 2010
(c) Dr. David A. Workman
17
Requirements Analysis (USP)
•
Artifacts
– Analysis Package
Name
package
Provides a means of organizing the artifacts of the analysis model into manageable
pieces. Consists of: analysis classes, use-case realizations, and nested analysis
packages.
• Packages generally group related use cases that can share a thread of control,
although they may cross use case boundaries. They encapsulate a coherent set of
related functional requirements.
• Packages are likely to become, or are likely to be distributed among, subsystems in
the top application layers of the design model.
• Packages are typically shared by multiple use-case realizations.
– Architecture Description
An identification and discussion of the architecturally significant artifacts of the
analysis model.
• Packages and their dependencies are architecturally significant
• Key control, entity, and boundary classes are architecturally significant
• Use-case realizations for critical functionality are architecturally significant
Architectural descriptions are best presented in the form of communication diagrams that
depict the architecturally significant packages, analysis classes, and use-case
realizations.
February 23, 2010
(c) Dr. David A. Workman
18
Software Development Plan (SDP)2
• Front Matter (Title, Toc, Lof, Lot)
1. Overview
2
IEEE Std 1058-1998
1.1 Project Summary
1.2 Evolution of Plan
2.
3.
4.
5.
References
Definitions
Project Organization
Managerial Process Plans
5.1
5.2
5.3
5.4
5.5
Start-up Plan
Work Plan
Control Plan
Risk Management Plan
Closeout Plan
6. Technical Process Plan
7. Supporting Plans
February 23, 2010
(c) Dr. David A. Workman
19
Analysis Modeling Process
Inputs:
Customer Requirements Documents
Customer/User Mtng Minutes
Use Case Model
2.0 Start
Analysis
Modeling
Use Case
Coverage Table
Ordered by
Priority
Work Package
Specifications
and Dependencies
Activity Diagram
Defining work
flow for WP
Analysis
February 23, 2010
2.1 Prioritize
Use Cases
See Notes
Below
2.2 Form
Work Pkgs
2.3 Prioritize,
Schedule & Staff
Work Pkgs
(c) Dr. David A. Workman
Next
20
Analysis Modeling Process
See Notes
Below
2.4
Select Next
WP to Analyze
Next
Slide
[more WPs
to Analyze]
2.4.1 Prioritize
Use Cases for
this WP
2.4.2 Select
Highest priority
Use case from
This WP
[more UCs
to Analyze
in this WP]
Analysis
Control Class
Spec.
2.4.3
Define/Assign
Control Object
To this UC
2.4.9
Review/Revise
Use Case
Artifacts
Use Case
Communication
Diagram
2.4.4
Analyze all
UC Interaction
Scenarios
2.4.8
Update System
Class Diagram
Analysis
Class
Diagram
Analysis
Entity Class
Spec.
2.4.7
Update Use Case
Coverage Table
For this UC
Use Case
Coverage
Table
2.4.5
Define/Assign
Entity Objects
To this UC
2.4.6
Define/Assign
Bndry Objects
To this UC
Analysis
Bndry Class
Spec.
Use Case
Interface
Spec.
February 23, 2010
(c) Dr. David A. Workman
21
Analysis vs Design (USP)
Analysis Model
Satisfies functional requirements.
February 23, 2010
Design Model
Satisfies both functional and nonfunctional requirements.
(c) Dr. David A. Workman
23
Design (USP)
•
Purpose
The system is shaped to accommodate all functional and non-functional
requirements. It contributes to a sound and stable architecture and creates a
blueprint for the implementation model.
– Acquire an in-depth understanding of non-functional requirements and
constraints related to: programming languages, component reuse, operating
systems, distribution topology, network and database technologies, user-interface
technology, etc.
– Define and harden the boundaries between subsystems.
•
Artifacts
– Design Model
An object model that describes the physical realization of use cases by focusing on how
functional and non-functional requirements, together with other constraints related
to the implementation environment, impact the system architecture and structure.
• Design classes
• Use-case realizations (design)
• Detailed Interfaces
February 23, 2010
(c) Dr. David A. Workman
24
Design (USP)
•
Artifacts
– Architecture Description
A view of the design model focusing on the following architecturally significant
artifacts:
• Subsystems, interfaces, and their dependencies
• Key classes that trace to key analysis and active classes
• Key use case realizations that are functionally critical and need to be developed early
in the lifecycle. Ones that have coverage across subsystems are particularly
important.
– Deployment Model
An object model that describes the physical distribution of the system in terms of how
functionality is distributed among computational nodes. An essential input to the
activities in design and implementation. It is a manifestation of the mapping
between software architecture and system architecture.
• Nodes that denote computational resources
• Node processes and corresponding functional allocation
• Node relationships and their types (internet, shared memory, ATM link, etc.)
• Network topology(ies)
February 23, 2010
(c) Dr. David A. Workman
25
Designing Classes
•
Step 1: Outlining the Analysis Classes
–
–
–
•
Boundary classes: decide on mode of input; e.g. command, gui, file, db, com
Entity classes: capture and encapsulate persistent problem (user visible) information.
Control classes: introduce to manage and encapsulate the interaction flow defined by use
cases.
Step 2: Allocating Functional Responsibilities
–
–
–
–
–
Input Boundary objects should be responsible for transforming raw input data to instances of
entity classes that will be manipulated by a use case.
Output Boundary objects should be responsible for writing internal data to some external
device; e.g. gui and file objects.
Entity classes should provide boundary methods for parsing their external image received
from some input boundary object. Analogously, boundary methods for writing their image to
some output boundary object. E.g. Extract(), Insert(), Get(), Put()
Each functional step required to complete a use case should be allocated as a responsibility
to some analysis object/class – this means that use cases should be decomposed into a
sequence of triples ( sender, message, receiver ), “sender” denotes an object that requires an
action to be performed by the “receiver” object. “Message” describes the action to be
performed and contains the problem data that may need to be supplied by sender to enable
the receiver to complete the operation; messages typically will be realized by method calls on
the receiver.
Control objects typically should have responsibility for creating objects that it exclusively
manages or controls. Objects that persist beyond a given use case or that must be shared by
use cases, should be passed as parameters to the use case control object, or should be
provided by inspector methods.
February 23, 2010
(c) Dr. David A. Workman
26
Designing a Class
•
Step 3: Defining Attributes
– Control Classes: use case local objects, or objects created by the use case and
shared with other use cases.
– Entity Classes: encapsulated problem data, association and composition
relationships with other classes.
– Boundary Classes: encapsulated boundary objects and control parameters.
•
Step 4: Identifying Associations and Aggregations
The interaction of objects implies some type of relationship - usually association or
aggregation.
– Association: a relationship between class instances suggesting that the instances
involved must interact in some way, or that one provides access to the others.
– Aggregation: a one-to-many Whole-Part relationship (contains-A, holds-A,
manages-A) such as between a container and its containees. Expresses a loose
functional coupling (if any) between the Whole and its Parts. Whole is not
responsible for creating the Parts – they are created by clients of the Whole.
– Composition: a one-to-many Whole-Part relationship (has-A)&(requires-A)
between an aggregate object and its components. Usually the relationship
implies a strong functional coupling between Whole and its Parts – the Whole is
not complete and will not function correctly without its Parts, AND the Whole is
responsible for creating and initializing instances of its Part.
February 23, 2010
(c) Dr. David A. Workman
27
Designing a Class
•
Step 5: Identifying Generalizations
Generalizations are formed by factoring common attributes and operations from an existing collection of related
and similar analysis classes. The gen-spec (is-a) relation is normally realized via the mechanism of
inheritance in the implementation language. If a suitable inheritance mechanism does not exist in the
implementation language, then it can be simulated by defining the "factored superclass" as a part of each
subclass - thus replacing generalization by whole-part.
•
Step 6: Describing Methods
Methods are the realization of operations defined for the class. "... they are not specified during
design. Instead, they are created during implementation using the programming language
directly."
–
However, the designer should :
•
decide what information is required to implement the operation
•
decide how the information is best obtained:
(a) computed from instance attributes (data members)
(b) computed from operation parameters (does caller always have this info?)
(c) computed from data obtained by operations on other objects created as local variables - decide
what classes denote those objects, what operations are needed, and what data must be supplied as
parameters to such operations.
!
–
Observe that these decisions could:
•
create new associations with existing classes
•
create new classes and associations
•
cause redesign of the operation interface and all dependent methods
February 23, 2010
(c) Dr. David A. Workman
28
Designing Classes & Methods
Functional
requirements
generated by all clients
Within the current
design –
Method to be Designed
Inputs: Functional responsibilities from clients (already designed)
Outputs: Desired results or changes to the object to which the method applies,
and perhaps changes to parameters passed to the method.
Extend the Design
> Add new classes
> Add new methods to existing
classes
> Add new calls to existing
methods
February 23, 2010
(c) Dr. David A. Workman
29
Designing a Class
•
Step 7: Describing States
Object (class instance) states should be introduced to realize and enforce constraints on
operation sequences - that is, to realize operation protocols. For example, "open" must be
issued on a file object before "read" or "write" operations can be successfully applied. One
or more attributes may need to be defined to realize the object state.
•
Step 8: Check Completeness
After completing a design pass – that is, after having analyzed all use cases and having reached
the point where you “think” the design is adequate, you should formally verify completeness
by constructing the Use Case Coverage Table and a Requirements Mapping Table. Not only
will these tables help you ensure the completeness of your architectural design, it will be
critically important in testing and integration and in defining incremental releases of the
system.
February 23, 2010
(c) Dr. David A. Workman
30
UML Modeling Concepts
Use Case Model
Analysis Model
Communication Diagram
Design Model
Customer
Int data
Money cash
Customer()
Method1()
Method2()
…
Use Case Diagram
*
Communication Diagram
February 23, 2010
(c) Dr. David A. Workman
31
OO Modeling Concepts in UML
WHOLE-PART (Composition)
Objects relate to one another in a variety of ways, some
relationships are of a physical nature, while others are
of a more logical or conceptual nature. For example:
Whole-Part: In this type of relationship, one or more
objects are parts or components of a more complex
composite object representing the whole.
Relationships of this kind tend to model physical or
geographic relationships involving tangible objects.
For example, an Engine is part of an Automobile.
Whole
Whole-Part is also referred to as the “Has-A(n)”
relation, that is, an Automobile Has-An Engine.
Whole-Part relationships tend to imply a strong
functional interaction (high coupling) between
constituent objects.
Composition is usually implied when the “whole” has
responsibility for creating its “parts” [Texel]
February 23, 2010
(c) Dr. David A. Workman
Part1
Part2
UML Representation
32
OO Modeling Concepts in UML
WHOLE-PART (Aggregation)
Container-Containee: This relationship is
somewhat like the Whole-Part where the
Whole is an object that plays the role of a
“storage container” used to hold and
organize instances of some class of
“containee” objects. Normally, there is a
very little interaction between the Container
and its Containees.
For example, a Bag of Groceries. The Bag
denotes the container and the groceries are
the containees.
This relationship might also be called the
“Holds-A(n)” relation. In contrast to
Composition, seldom are there any
functional dependencies or interactions
between the Container and its Containees.
Containers are normally not responsible for
creating containees.
February 23, 2010
(c) Dr. David A. Workman
Container
*
Containee
UML Representation
33
OO Modeling Concepts in UML
WHOLE-PART (Affiliation )
Organization-Member: Affiliations are almost always
logical in nature. The Organization may represent a
loose collection of Members( people or things )
having a common purpose or interest or other reason
for affiliation.
The Member-Organization relationship might also be
called the “Belongs-To” relation; conversely, the
Organization-Member relationship could be called
the “Includes” relation.
This type of relationship may not be formal enough to
define a class of objects - it is the type of relationship
that can dynamically change its membership; that is,
the type of objects that form the affiliation defined by
this relationship can change with time.
For example, members of a club or email interest
group may have a common background, common
interests, or a common hobby that forms the basis for
their affiliation, but there may not be a need for a
formal organization.
February 23, 2010
(c) Dr. David A. Workman
Organization
*
Member
UML Representation
34
OO Modeling Concepts in UML
ASSOCIATION
This relationship is the most informal of all those mentioned above. This
relationship is used to define an instance connections (Coad/Yourdon) between
objects; that is, a weak relationship between objects necessary to model some
property or “interest” they have in common. Or, objects that have some reason to
interact.
For example, a Customer holds a contract with a Vendor. In this association, the
customer plays the role of Buyer while the Vendor plays the role as Seller. Both
Customer and Vendor are associated with a Contract, but through different
relationships. Also note the multiplicity constraints on these associations.
Customer
Buyer 1
role
Holds contracts with 
association
*
Seller
role
1
Vendor
1
Seller
Buyer
Contract
UML Representation
February 23, 2010
(c) Dr. David A. Workman
35
OO Modeling Concepts in UML
INHERITANCE
Inheritance is a relationship between classes
also known as the GeneralizationSpecialization (Gen-Spec) relation.
A superclass is said to generalize its
subclasses, conversley, a subclass is said to
specialize its superclass. Inheritance
implies the following:
Objects of a subclass inherit all attributes
defined by the superclass, and may define
addtional ones;
Objects of a subclass normally inherit all
services (behavioral characteristics) defined
by the superclass, and may re-define any
subset of them;
Objects of a subclass may define new services
(behavior variation) not provided by the
superclass.
Superclass
Subclass1
Subclass2
UML Representation
February 23, 2010
(c) Dr. David A. Workman
36
UML Class Diagrams
February 23, 2010
(c) Dr. David A. Workman
37
Design Modeling Process
Note1
{C} and A impose
functional reqmts
on M. This step
insures M satisfies
All functional
demands currently
Defined for M.
Note2
{C} must supply
values of all parms
defined for M.
M must deliver
all data expected
By {C}
Note3
Choose algorithms and data
structures for M. Decide on
any existing methods, X::P(),
that must be called by M.
Decide on any new classes and/
or methods, Y::Q(), that must
be called by M. Add these to
the Use Case Coverage Table.
Add M to the Caller list for
each X::P() and Y::Q().
February 23, 2010
3.3 Design
Class A
Use Case
Coverage
Table
3.3.1 Select A
Method, M
from Class A
3.3.2 Identify
All Methods, {C}
that Call M
3.3.3 Using {C} and A
allocate functional
responsibilities
to M (See Note1)
3.3.9
Review/Revise
Design & Test
Plans for A
Return
To Previous
Slide
[ design of A not complete]
Caller
List for
M
3.3.8
Develop Test
Plan for A
Test Plan
for
Class A
Design
Spec for
Class A
Caller
List for
X::P()
3.3.7 Produce
Design
Spec for A
Caller
List for
Y::Q()
M
3.3.4 Design
Interface to M
(See Note2)
(c) Dr. David A. Workman
3.3.5 Design
Body of M
(See Note3)
3.3.6 Design
Test Plan
for M
Test Plan
For M
39