chapter 5: structural modeling

PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 5th EditionCopyright © 2015 John Wiley & Sons, Inc. All rights reserved.

Chapter 5:Structural Modeling

1

Twittie Senivongse (Ed.)


Objectives• Understand the rules and style guidelines for creating CRC cards,

class diagrams, and object diagrams.• Understand object identification approaches using textual

analysis, brainstorming, common object list, patterns (analysis pattern and entity-control-boundary pattern).

• 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 among structural models.• Understand the relationship between structural and functional

models.

2


Introduction� Functional models (Chapter 4) represent system behavior

from an external view� Structural models represent system objects and their

relationships in the domain of the problem:� People� Places� Things

3


Structural Models (1/2)� Drawn using an iterative process

� First in analysis, analysts draw a conceptual model which shows the logical organization of the objects without indicating how the objects are stored, created, or manipulated.

� Later in design, analysts evolve the conceptual structural model into a (technology-centric programming-level) design model that reflects how the objects will be organized in databases, files, and software.

� More and more detail is added in each iteration

� Built upon a vocabulary (things or concepts) in the problem domain to allow effective communication between analysts & users

� Consist of CRC cards, class diagrams, and object diagrams4


Structural Models (2/2)Main goal: to discover the key data contained in the problem domain and to build a structural model of the objects

Problem DomainSolution Domain

StructuralModeling

5


Classes, Attributes, & Operations� Classes•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

6

Box


Classification of Classes1. Two different general kinds of classes of interest during

analysis:

� Concrete class: used to create objects, e.g. Employee, Customer

� Abstract class: useful abstraction, not actually exist in the real world, e.g. Person (as a generalization of Employee and Customer)

2. Type of real world thing that a class represents

� Domain class (our focus at this point)

� User-interface, Data structure, File structure, Operating environment, Document, and Multimedia class

7


Relationships� Describe how classes relate to one another

� Three basic types in UML§ Generalization• Enables inheritance of attributes and operations• Represents relationships that are “a-kind-of”• E.g. Employee is a-kind-of Person

§ Aggregation• Relates parts to wholes or assemblies• Represents relationships that are “a-part-of” or “has-parts”• E.g. Employee is a-part-of Department or Department has-parts Employee

§ Association• Miscellaneous relationships between classes• Usually a weaker form of aggregation• E.g. Appointment is associated-with Patient

8


Structural Modeling� We will focus on

� Class diagram as a graphical model of classes and their relationships

� Object identification approaches – how to identify classes/objects and their relationships in a class diagram

� CRC cards as an alternative to a class diagram for documenting classes and their relationships, and as a complementary approach to creating a class diagram

� Object diagram as a graphical model of instances of classes (or objects) and their relationships

9


Class Diagrams� A static model that shows classes and their relationships to one another� Elements

� Class� Represents a kind of person, place, or thing in the system� Stores and manages information in the system and contains:

� Attribute—characteristic of the class� Operation—activity the class can perform� Visibility indicates the level of information hiding

� + public : visible to all classes� - private : visible only to an instance of the class in which it is defined� # protected : visible only to an instance of the class in which it is defined and its

descendants� Relationship—the association between classes

� Depicted as a line between classes� Multiplicity indicates how many objects of a class are associated with objects of

another class, e.g. 1..1, 0..*

10


Class Diagram Syntax (1/2)

to avoid cluttering, i.e. create or delete an instance and get or set attribute values are omitted.

or destructor. Should focus only on problem domain-specific operations.

Shown with visibility

11


Class Diagram Syntax (2/2)Verb phrase denotes a relationship; a solid triangle 4 shows the direction of the relationship.+ denotes a role.

Attributes and operations of the generalization class are

Possible that a part can be associated with multiple wholes,

inherited by specialization classes.

The part can be associated with only a single whole.

or it is relatively simple for the part to be removed from the whole.

Generalization class

Whole class

Whole class

12


Sample Class Diagram

Class is related to itself, recursive association

Association Class:When the relationship itself has associated properties, a class is formed with a dashed line attached to the association path.

Example of class diagram


Association Classes� Common in many-to-many relationships

� Used when attributes about the relationship between two classes need to be recorded� Illnesses are related to Symptoms; a Treatment class provides an attribute to

describe this relationship (see previous slide)� Students are related to Courses; a Grade class provides an attribute to

describe this relationship

14


Multiplicity

15


Aggregation vs. Composition

� The whole is responsible for the creation and destruction of its parts.

� If the whole were to die, the part would die with it.

� Each part can belong to only one whole.16


Simplifying Class Diagrams� Fully populated class diagrams of real-world system can be difficult to

understand

� Common ways of simplifying class diagrams:1. Show only concrete classes

� If there are many abstract classes, omitting them could make the class diagram difficult to understand.

2. The view mechanism shows a subset of classes� Use case view: show only the classes and relationships relevant to a particular use case� Show only a particular type of relationship: aggregation, association, or generalization� Restrict the information shown with each class, e.g. show only the class name, the class

name and attributes, or the class name and operations.

3. Packages show logical groups of classes (or any elements in UML) see next page

17

PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 5th EditionCopyright © 2015 John Wiley & Sons, Inc. All rights reserved. 18

Package Diagram of the PD layer of the Appointment System


Object Identification� Most system analysts use a combination of the following

four most common approaches to identify candidate objects/classes (and their relationships):

1. Textual analysis

2. Brainstorming

3. Common object list

4. Pattern

19


Textual Analysis (1/4)� Performed on a general problem description, or better, on a use case or

use case description

� Map parts of speech to class model components� Nouns usually suggest classes, objects, or attributes� Verbs usually suggest operations or associations

� Criticized for its simplicity as mechanical noun-to-class or verb-to-operation mapping is not possible

� Not perfect, but coupled with other techniques, it is a good start

� Helps to create a rough first cut to provide an object list though

20

Russell Abbott, Program Design by Informal English Description, Communication of the ACM, 26(11) 1983, pp. 882-894Ian Graham, Migrating to Object Technology. Addison Wesley, 1995

Object Identification


Textual Analysis (2/4)

21

Part of Speech Model Component Example in Text

Proper noun Instance (object) Alice, Ace of hearts

Common noun Class (or attribute) FieldOfficer, PlayingCard, Value

Collective noun Class made up of objects of another class

A team of students

Doing verb Operation Creates, Submits, Shuffles

Being verb Inheritance Is a kind of, Is one of either

Having verb Aggregation/Composition Has, Consists of, Includes

Modal verb Constraint Must be

Adjective Helps identify an attribute A yellow ball (i.e. color)

http://www.cs.fsu.edu/~myers/cop3331/notes/analysis1.html

http://www.cs.fsu.edu/~myers/cop3331/notes/analysis1.html


, Make Payment Arrangements

Potential class / attribute

Potential operation

High

22

patients


Candidate classes

Textual Analysis (4/4)

23

From old (adjective)

Should be an attribute or a class?

Not enough info in this use case description. See other use case descriptions or use other object identification techniques to identify other info of Patient which may be changed.

Is it only a human actor or should it be captured as a class by the system?

Not enough info in this use case description. See other use case descriptions or use other object identification techniques to identify details of Doctor and relationships with other classes.

Office (noun) is not captured in the system.

make ()

Not enough info to specify Appointment’s attributes


Brainstorming� Facilitator asks development team and users to think about

the objects they experience in the problem domain.

� Initial list of classes (objects) is developed.� E.g. Doctor, Nurse, Receptionist, Appointment, Illness,

Treatment, Prescription, Insurance card, Medical record

� Participants then discuss and select which candidate classes should be considered further.

� Attributes, operations and relationships of the identified classes can be assigned in a second round.

24



Common Object Lists� Categories of objects help in creating a list of objects in the business

domain.� Physical or tangible things

� E.g. Book, Desk, Chair, Office equipment

� Incidents: events that occur in the business domain� E.g. Meeting, Flight, Performance, Accident

� Roles: played by people in the business domain� E.g. Doctor, Nurse, Patient, Receptionist

� Interactions: transactions that take place in the business domain� E.g. Appointment transaction, Sales transaction, Ticket reservation,

� Other categories, e.g. places (of bank branches), containers, organizations (faculty, department), business records (product order history), catalogs (product/service catalogs), policies (of car/house/life insurance)

C. Larman, Applying UML and Patterns, Prentice Hall, 199825



Patterns (1/14)� Useful groupings of collaborating classes by experts which

provide solutions to commonly occurring problems (they are reusable)

� Developed patterns provide a starting point for work in similar domains.

� Enabling leveraging of knowledge beyond that of the team members, resulting in more complete and robust models

� Ranging from high-level business-oriented patterns to more low-level design patterns� In the analysis phase, we will see an example of analysis

patterns and entity-control-boundary pattern26



Patterns (2/14)

27

Analysis Patterns

Product

PartyTransaction


Patterns (3/14)

28

Account

An account is similar to a quantity attribute, with an added entry to every change to its value. For example, a bank account needs to record every withdrawal and deposit; an inventory record needs to record each time items are added or removed. The sign on the amount indicates whether the entry is an addition or a subtraction.

1..1 0..*

https://martinfowler.com/apsupp/apchap6.pdf

Analysis Patterns (cont.)



Patterns (4/14)

29

Accounting TransactionIn double entry booking (or even multiple entry booking), every withdrawal must be balanced by a deposit. The accounting transaction is a single movement from one account to another (or others). This is the fundamental idea behind financial accounting, inventory tracking, resource management etc.


1..1 0..*

1..12..2

QuantityQuantity


A transfer from a checking accout to a cash account



Patterns (5/14)Merging analysis patterns

30


Patterns (6/14)

31

Applying analysis patterns to sales order



Applying analysis patterns to clinic appointment scheduling


Martin Fowler, Analysis Patternshttp://uml2.narod.ru/files/docs/13/AnalysisPatterns.pdfUML diagrams for analysis patternshttps://martinfowler.com/apsupp/uml.html


http://uml2.narod.ru/files/docs/13/AnalysisPatterns.pdf

https://martinfowler.com/apsupp/uml.html


Patterns (9/14)Entity-Control-Boundary Pattern

� Identifies classes for some scenario of system behavior

34

http://ndpsoftware.com/OpenUpBasic/openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html

Front-endMarketingCampaignFormwould manage the exchange of information between a user and the system

Back-end BugdetSystem would manage the exchange of information between the system and an external system that manages budgets.

http://ndpsoftware.com/OpenUpBasic/openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html


Patterns (10/14)Entity-Control-Boundary Pattern (cont.)

� Entity� Represents persistent information tracked by the system� Performs behavior organized around some cohesive amount of

data� E.g. Customer class models the data of the customer, behavior

to manage the data, behavior to validate customer information, and perform other business calculations such as “is this customer allowed to purchase product X?”

� E.g. DirectMail models the activity that the system needs to track.

35



� Boundary� Lies on the periphery of a system (or subsystem), but within it.� Some boundary classes will be “front-end” that accept input from

outside the area under design.� Some boundary classes will be “back-end” managing communication

to elements outside the system (or subsystem).� E.g. front-end MarketingCampaignForm would manage the exchange

of information between a user and the system� E.g back-end BugdetSystem would manage the exchange of

information between the system and an external system that manages budgets.

36



� Control� Is just responsible for the flow of the scenario, gluing between other

classes� May provide for behavior not natural in entity and boundary classes� E.g. CreateMarketingCampaignControl would be responsive to certain

front-end boundary classes and collaborate with other entity, control, and back-end boundary classes to support the creation of a marketing campaign.

37

Association permitted between classes Entity Boundary Control

Entity P P

Boundary P

Control P P P



� Finding ECB classes� Do a textual analysis on the use case scenario� After objects/classes are found,

� Identify real world entities or activities that the system needs to keep track of (Entity)

� Identify interface artifacts, data entry to the system, notices or messages responded to actors (Boundary)

� Identify real world procedures that the system needs to keep track of (Control)� Identify one control class per use case, or one control class per actor in

the use case� Life span of control object should last through the use case.

38https://www1.in.tum.de/lehrstuhl_1/files/teaching/ws0607/Software%20Engineering%20I/L6_ObjectModeling.pdf

https://www1.in.tum.de/lehrstuhl_1/files/teaching/ws0607/Software%20Engineering%20I/L6_ObjectModeling.pdf


Patterns (14/14)

40

Entity-Control-Boundary Pattern Example

An old patient can make/ cancel/change an appointment.

Optionally, the old patient may update patient info and payment arrangement.


CRC Cards� Class-Responsibility-Collaboration cards

� Index cards used to document the responsibilities and collaborations of a class� Low-tech but intuitive� Help identify classes, attributes, operations, and relationships involved

with a use case� An alternative, as well as a complementary technique, to use cases and

class diagrams in structural modeling� Responsibilities

� Knowing—what a class must know manifested as attributes� Doing—what a class must do manifested later as operations

� Collaboration� Other classes that a class interacts to fulfill its responsibility

� Request for information � Request to perform a task

� Bound by a contract which formalizes interactions between the client (or requestor) and server (or responder) objects

41



Applying analysis patterns to clinic appointment scheduling


Front-Side of a CRC Card

43


Back-Side of a CRC Card

Participant

, Medical History,

44

Patient


Role-Playing CRC Cards with Use-Cases

� An exercise to help discover additional objects, attributes, relationships & operations

� Team members perform roles associated with the actors and objects previously identified in use-case descriptions

� Utilize activity diagrams to look for different scenarios of each use-case to role-play� Identify an important use-case� Assign roles to team members based on actors and objects in the use-case description� Team members perform each step in a scenario� Discover and fix problems and try again until the scenario reaches a successful conclusion

� E.g. Step 1: The Patient contacts the office regarding an appointment. fDoes the patient make a phone call? And who answers the phone? g Make the step more explicit.

� E.g. Step 3: If the patient information has changed, execute the Update Patient Information use case. fWhat information? g Make the step more explicit.

� Repeat for remaining scenarios of the use-case� Repeat for remaining use-cases

45


Object Diagrams� Instantiation of all or part of a class diagram

� Example: instead of a Doctor class, create an actual doctor, say Dr. Smith

� Format:� Object name: Class name� Place values into each attribute

� Used to discover additional attributes, relationships and/or operations or those that are misplaced� It is easier to think in terms of concrete object (instances) rather

than abstraction of objects (classes)

46


Example Object Diagram

47Í

Í

Having a symptom is the reason for making an appointment with the clinic. Symptom should better be associated with each Appointment, rather than Patient.


7 Steps to Structural Models (1/2)

1. Create CRC Cards� Textual analysis on use case descriptions� Use the guidelines on all flows of events (in the form of Subject-Verb-Direct Object-

Preposition-Indirect Object (SVDPI))

2. Review CRC Cards & identify missing objects, attributes, operations and/or relationships

� Use brainstorming and common object lists

3. Role-play the CRC cards—look for breakdowns & correct; create new cards as necessary

4. Create the class diagram—transfer CRC cards information to class diagram� CRC card g class� Attributes g attributes� Responsibilities g operations� Relationships with collaborators g relationships with other classes� Add visibility and multiplicity

48


7 Steps to Structural Models (2/2)

5. Review the class diagram—remove unnecessary classes, attributes, operations and/or relationships

6. Incorporate patterns—compare patterns and the class diagram to add or remove classes, attributes, operations and/or relationships

7. Review and validate the model—always keep CRC cards, use-case diagrams, use-case descriptions, and class diagram consistent

49

Create an object diagram to complement with the object/instance view of the model.


Verifying & Validating the Model (1/4)

� Analyst presents to developers & users� Walks through the model� Provides explanations & reasoning behind each class

� Rules1. Each CRC card is associated with a class2. Responsibilities on the front of the card are included as operations on the class diagram3. Collaborators on the front of the card imply some type of

relationship on the back of the card4. Attributes on the back of the card are listed as attributes on

the class diagram

50

, Medical History, Patient


Validating & Verifying the Model (2/4)

5. Object type of attributes listed on the back of CRC card and on a class diagram implies association from the class to the class of the object type� Object types of class types are shown as association, e.g. medical history

information is shown as association to the class Medical History, not an attribute of a type Medical History

� But object types of simple types are not shown as association, e.g. amount (double), insurance carrier (text)


Validating & Verifying the Model (3/4)

6. Relationships on the back of the card must be properly depicted on the class diagram� Generalization, aggregation, composition, association� Multiplicity

7. Association classes are used only if there are attributes and operations that describe a relationship between the connecting classes� Otherwise association is used

8. All diagram-specific rules (syntax and semantics) must be enforced, e.g. a class cannot be a subclass of itself

52


Summary� Structural Models

� Class Diagrams

� Object Identification Approaches

� CRC Cards

� Object Diagrams

� Creating CRC Cards, Class Diagrams, and Object Diagrams

54


More on class diagram examples� https://www.uml-diagrams.org/class-diagrams-examples.html

� Online shopping� https://www.uml-diagrams.org/examples/online-shopping-domain-

uml-diagram-example.html?context=cls-examples

� Library management system� https://www.uml-diagrams.org/library-domain-uml-class-diagram-

example.html

� Hospital management system� https://www.uml-diagrams.org/examples/hospital-domain-

diagram.html?context=cls-examples

55

https://www.uml-diagrams.org/class-diagrams-examples.html

https://www.uml-diagrams.org/examples/online-shopping-domain-uml-diagram-example.html?context=cls-examples

https://www.uml-diagrams.org/library-domain-uml-class-diagram-example.html

https://www.uml-diagrams.org/examples/hospital-domain-diagram.html?context=cls-examples

chapter 5: structural modeling

Documents