lecture 6: structural modeling. objectives understand the rules and style guidelines for creating...

Lecture 6:Structural Modeling

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.

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

Structural Models 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

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

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

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

Responsibilities & Collaborations Responsibilities

Knowing Doing

Collaboration Objects working together to service a

request

Front-Side of a CRC Card

Back-Side of a CRC Card

Elements of a Class Diagram

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

Operations Constructor

Creates object Query

Makes information about state available Update

Changes values of some or all attributes

More Elements of Class Diagrams

Multiplicities

Department

Boss

Employee Child

Boss Employee

1 1

1 0..*

1 1..*

Exactly one:A department has one and only one boss

Zero or more:An employee has zero to many children

One or more:A boss is responsible for one or more employees

More Multiplicities

Employee Spouse

Employee Vacation

EmployeeCommitte

e

1 0..1

1 2..4

1 1..3, 5

Zero or one:An employee can be married to 0 or 1 spouse

Specified range:An employee can take 2 to 4 vacations each year

Multiple disjoint ranges:An employee can be in 1 to 3 or 5 committees

Sample Class Diagram

Domain Model : visualizing concept

Book

title

public class Book{ private String title; ...}

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.

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.

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

STEP 1

Make a list of candidate concepts

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.

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

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.

Step 2

Create CRC cards

Designing with CRC cards

30

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

Detailed Design with CRC cards

31

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)

CRC Card Notation

32

CRC Card Results

33

Step 3

Create Domain Model

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

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