1. Lecture 6: Structural Modeling

2. Objectives
Understand the rules and style guidelines for creating CRC cards, class diagrams, and object diagrams.
Understand the processes used to create CRC cards, class diagrams, and object diagrams.
Be able to create CRC cards, class diagrams, and object diagrams.
Understand the relationship between the structural and use case models.

3. Structural Model
A formal way of representing the objects that are used and created by a business system
People
Places
Things
Drawn using an iterative process
First drawn in a conceptual, business-centric way
Then refined in a technology-centric way describing the actual databases and files

4. Structural Models
Main goal: to discover the key data contained in the problem domain and to build a structural model of the objects
Structural
Modeling
Solution Domain
Problem Domain

5. A Common Language
Structural models create a well-defined vocabulary shared by users and analysts
Classes created during analysis are not the classes that programmers develop during implementation
This refinement comes later
Typical structural models:
CRC cards
Class (and Object) diagrams

6. Classes, Attributes, & Operations
Templates for instances of people, places, or things
Attributes
Properties that describe the state of an instance of a class (an object)
Operations
Actions or functions that a class can perform
Classes, Attributes, & Operations

7. Relationships Describe how classes relate to one another
Three basic types in UML
Generalization
Enables inheritance of attributes and operations
Aggregation
Relates parts to wholes
Association
Miscellaneous relationships between classes

8. Responsibilities & Collaborations
Knowing
Doing
Collaboration
Objects working together to service a request

9. Front-Side of a CRC Card

10. Back-Side of a CRC Card

11. Elements of a Class Diagram

12. Attribute Visibility
Attribute visibility can be specified in the class diagram
Public attributes (+) are visible to all classes
Private attributes (-) are visible only to an instance of the class in which they are defined
Protected attributes (#) are like private attributes, but are also visible to descendant classes
Visibility helps restrict access to the attributes and thus ensure consistency and integrity

13. Operations Constructor Query Update Creates object
Makes information about state available
Update
Changes values of some or all attributes

14. More Elements of Class Diagrams

15. Multiplicities Department Boss Exactly one:
A department has one and only one boss 1 1
Employee
Child
Zero or more:
An employee has zero to many children 1
0..*
Boss
Employee
One or more:
A boss is responsible for one or more employees 1
1..*

16. More Multiplicities Employee Spouse Zero or one:
An employee can be married to 0 or 1 spouse 1
0..1
Employee
Vacation
Specified range:
An employee can take 2 to 4 vacations each year 1
2..4
Employee
Committee
Multiple disjoint ranges:
An employee can be in 1 to 3 or 5 committees 1
1..3, 5

17. Sample Class Diagram

18. Domain Model : visualizing concept

19. Object modeling might support a reduced “semantic gap” in models at different stages.
But an exact 1-1 mapping is not always present or desirable.

20. Not A Diagram of Software Components
Conceptual models represent ideas, things, and objects in the real-world problem domain.
A conceptual model is not a picture of:
Software components.
Classes in an object-oriented programming language.
It illustrates real-world concepts.

21. 4 Steps to Domain Model Make a list of candidate concepts
Create CRC Cards
Create the class diagram (Domain Model)
Review the class diagram

22. Make a list of candidate concepts
STEP 1
Make a list of candidate concepts

23. Strategies to Identify Conceptual Classes
Use a conceptual class category list
Make a list of candidate concepts
Use noun phrase identification
Identify noun ( and noun phrases) in textual descriptions of the problem domain, and consider them as concepts or attributes.
Use Cases are excellent description to draw for this analysis.

24. Object Identification
Textual analysis of use-case information
Creates a rough first cut
Common object list
Incidents
Roles

25. Textual analysis of use-case information
• A Noun
A common or improper noun implies a class of objects.
A proper noun or direct reference implies an instance of a class.
A collective noun implies a class of objects made up of groups of instances of another class.
• An adjective implies an attribute of an object.
• A verb
A verb doing verb implies an operation.
A being verb implies a classification relationship between an object and its class.
A having verb implies an aggregation or association relationship.
A transitive verb implies an operation.
An intransitive verb implies an exception.
A predicate or descriptive verb phrase implies an operation.
• An adverb implies an attribute of a relationship or an operation.

29. Step 2
Create CRC cards

30. Designing with CRC cards
CRC Cards—Classes, Responsibilities, Collaboration Cards.
OO design is about assigning Responsibilities to Classes for how they Collaborate to accomplish a use case
Usually a manual process done in a brainstorming session
3 X 5 note cards
One card per class
Front has responsibilities and collaborations
Back has attributes needed

31. Detailed Design with CRC cards
Design process
Identify class with primary responsibility
Identify other classes that collaborate with primary class (become requests for service to other classes)‏
Identify responsibilities within each class (these become methods)‏

32. CRC Card Notation

33. CRC Card Results

34. Step 3
Create Domain Model

35. Using the CRC card you can identify the following:
Attributes related to each classes.
Association between classes.

40. Association Category A is recorded in B A uses or manages B
A is related to a transaction of B
A communicates with B
A is a transaction related to another transaction B
A is next to B
A is related to B via a transaction
A is recorded in B
A uses or manages B
A is related to a transaction of B
A communicates with B
A is a transaction related to another transaction B
A is next to B
A is related to B via a transaction