1. System Analysis and Design
Structural Modeling
This presentation includes notes from System Analysis and Design with UML2.0 by Alan Dennis et al., and from Kostas Kontogiannis

2. Outline Structural Modeling Introduction Class diagrams
Object diagrams

3. What is Structural Modeling?
Structural model: a view of a system that emphasizes the structure of the objects, including their classifiers, relationships, attributes and operations.

4. Purpose of Structural Models
Reduce the “semantic gap” between the real world and the world of software
Create a vocabulary for analysts and users
Represent things, ideas, and concepts of importance in the application domain

5. Classes Templates for creating instances or objects Typical examples:
Concrete
Abstract
Typical examples:
Application domain, user interface, data structure, file structure, operating environment, document, and multimedia classes

6. Attributes
Units of information relevant to the description of the class
Only attributes important to the task should be included

7. Operations Action that instances/objects can take
Focus on relevant problem-specific operations (at this point)

8. Relationships Generalization Aggregation Association
Enables inheritance of attributes and operations
Aggregation
Relates parts to wholes
Association
Miscellaneous relationships between classes

9. CLASS-RESPONSIBILITY-COLLABORATION CARDS

10. Responsibilities and Collaborations
Knowing
Doing
Collaboration
Objects working together to service a request

11. A CRC Card

12. Back of CRC Card

13. From Use Cases to Class Diagrams
A common or improper noun->class
“fieldOfficer”, “patient” , “doctor”
A proper noun or direct reference->object
“Alice”
A collective noun->class made up of instances of another class
“department”
An adjective->an attribute
A doing verb->an operation
A being verb->generalization
A having verb-> aggregation or association
Etc…( Fig 7-6, in System Analysis and Design with UML..)

14. Entity, Boundary and Control
Entity classes represent persistent data in the system
Data available between two sessions
Recurring nouns (“ Incident”)
Real world activities and entities (“Field Officer”, Dispatcher”)
Boundary classes represent the interface with the actors
input buttons and forms (“EmergencyButton”, “ReportEmergencyForm”)
output messages and signals(“AcknowledgeMessage”)
Control classes realize use cases and mediate between the entity and boundary classes
One control object per use case
One control object per actor and use case
“ReportEmergencyControl”
“ManageEmergencyControl”

15. Classes are Classifiers
A classifier is a mechanism for describing structural and behavioral features.
Nine classifiers in UML 2.0
Classes, interfaces, datatypes, signals, components, nodes, use cases, subsystems.
Advanced features
Multiplicity, visibility, signatures, polymorphism

16. Class name Window origin attributes size Open() operations Close()
Move()
Display()
operations

17. Classes with more details
PackageName::Agent
Name: simple, path
Height: Float
Val : Boolean = false
Attribute: all, only some, or none
<<constructor>>
New(p : policy)
<<process>>
Process(o : order) …
Operations: services provided.
Stereotype: group attributes/ops and
put a descriptive prefix.
Responsibilities
Responsibility: obligation of a class.
free-form text.
-- determine risk of an
order
-- handle criteria for
fraud

18. Visibility of attr. & ops.
Public: Any outside classifier can use (+).
Protected: Any descendant of the classifier can use (#).
Private: Only the classifier itself can use (-).
Package: Only visible within the package(~)
Toolbar
# currentSelection: Tool
# toolCount: Integer
+ pickItem(i: integer)
- compact()

19. (Owner) Scope
Instance: Each instance of the classifier holds its own value
for the feature.
Classifier: There is just one value of the feature for all
instances of the classifier.
Frame
instance
Header : FrameHeader
uniqueID : Long
classifier
(“static” in Java)

20. Multiplicity - Specification of the range of allowable cardinalities
an entity may assume. 1
Car
wheels : Wheel[4]
persons: Person[1..5]
Engine: Engine

21. Classes: operation body

22. Showing more details...
Names of abstract classes and operations shown in italics

23. Relationships Window Event Open() Close() HandleEvent() dependency
generalization
association
ConsoleWindow
DialogBox
Control
DisplayPrompt() …

24. Generalization: Alternative notations

25. Generalization: Multiple Classification

26. More about association
Works for
Person
Company
Name an association to describe its nature.
Direction triangle: direction of reading.
employee
employer
Person
Company
Role: face presented to the other class.

27. More about association
Navigability: An arrow may be attached to the end of the path to
indicate that navigation is supported toward the classifier attached
to the arrow.
Works for
Person
Company

28. More about association
Multiplicity: How many objects may be connected across
an instance of an association.
1..* *
Person
Company
employee
employer
Multiplicity at one end  for each object at the other end,
there must be that many objects at the near end.
Exactly one: 1
Zero or one:
Many: 0 .. *
One or more: 1 .. *
Not shown  unspecified or suppressed

29. Aggregation Company whole 1 * Department part
Plain association: peer relationship.
Aggregation: whole/part relationship.
- An object can be shared by other aggregates.
Company
whole 1 *
Department
part

30. More about association
Composition (composite aggregation):
- An object may be a part of ONLY one composite at a time.
- Whole is responsible for the disposition of its parts.
whole
Window 1 *
Frame
part

31. Composition vs Aggregation
Aggregation: does not link the lifetimes of the whole and its parts.
Composition:
Parts with nonfixed multiplicity can be created after the composite itself.  lifetime
Such parts can be explicitly removed before the death of the composite.  lifetime
An object may be a part of only one composite at a time.  strong ownership

32. Alternative notations for composition

33. More about association
Association classes: specify properties of an association.
employer
employee
Person
Company
1..* *
Job
Description
dateHired
Salary

34. Ternary Associations

35. Constraints Constraints add new semantics or change existing rules.
Portfolio
Corporation
{secure}
{or}
BankAccount
Person

36. Constraints and Comments

37. Derived Attributes and Associations

38. More examples of associations

39. More examples of associations

40. Dependencies «permit» ClassA ClassB ClassC «instantiate » «call ClassD
operationZ()
«friend»
Class D E
refine»
ClassC combines
two logical classes

41. Realization - A semantic relationship between classifiers.
- One classifier specifies a contract that another guarantees.
- Realization in two places:
- between interfaces and classes/components that
realize them.
- between use cases and collaborations that realize
them.
- Graphical rendering: cross between generalization and
dependency

42. Relationships: Summary

43. Core Relationships: Summary

44. Interface Defines a set of operation specs
Never defines an implementation (no attributes, no associations, operations not implemented)
Typically attached to a class or component

45. Interfaces: Shorthand Notation
+create()
+login(UserName, Passwd)
+find(StoreId)
+getPOStotals(POSid)
+updateStoreTotals(Id,Sales)
+get(Item)
-storeId: Integer
-POSlist: List
Store
POSterminal
POSterminalHome
<<use>>
StoreHome I I

46. Interfaces: Longhand Notation

47. Class Diagram-Order CDs

48. Class Diagram-Order CDs

49. Instances Concrete manifestation of an abstraction
All objects are instances
Not all instances are objects. (Instance of an association is a “link”)
To indicate an instance, underline its name

50. Instances (named, anonymous, multiple)
t: Transaction
named
myCustomer
:Multimedia::AudioStream
anonymous
multiobject
:keyCode

51. Object state Instance with attribute values myCustomer
Id : SSN = “432 …..”
Active = true
Instance with explicit state
c: Phone
[WaitingForAnswer]

52. Object diagrams
Model the instances of things contained in class diagrams.
Show objects are their relationships at a point in time.
No communication is shown.

53. An object diagram c:Company d1: Dept d2: Dept name = “R&D”
name = “Sales”
Objects, links, notes, constraints
d3: Dept
Name = ….
p: Person
: ContactInfo
Name = “jk”
Address=“200 U Av.”

54. Summary
Class and object diagrams show the underlying structure of an object-oriented system.
CRC cards capture the essential elements of a class.
Relationships capture the collaboration between 2 or more classes( dependency, realization, generalization, associations, aggregation, composition)
Constructing the structural model is an iterative process involving: textual analysis, brainstorming objects, role playing, creating the diagrams, and incorporating useful patterns.