Structural Modeling

Structural Modeling

ObjectivesO Understand the rules and style

guidelines for creating CRC cards, class diagrams, and object diagrams.

O Understand the processes used to create CRC cards, class diagrams, and object diagrams.

O Be able to create CRC cards, class diagrams, and object diagrams.

O Understand the relationship between the structural and use case models.

Structural ModelO A formal way of representing the objects

that are used and created by a business systemO PeopleO PlacesO Things

O Drawn using an iterative processO First drawn in a conceptual, business-centric

wayO Then refined in a technology-centric way

describing the actual databases and files

Structural Models

Structural ModelsO 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 LanguageO Structural models create a well-

defined vocabulary shared by users and analystsO Classes created during analysis are

not the classes that programmers develop during implementation

O This refinement comes laterO Typical structural models:

O CRC cardsO Class (and Object) diagrams

Classes, Attributes, & Operations

O ClassesO Templates for

instances of people, places, or things

O AttributesO Properties that

describe the state of an instance of a class (an object)

O OperationsO Actions or

functions that a class can perform

RelationshipsO Describe how classes relate to one

anotherO Three basic types in UML

O Generalization O Enables inheritance of attributes and

operationsO Aggregation

O Relates parts to wholesO Association

O Miscellaneous relationships between classes

CRC Cards

Responsibilities & Collaborations

O ResponsibilitiesO KnowingO Doing

O CollaborationO Objects working together to service a

request

Front-Side of a CRC Card

Back-Side of a CRC Card

Class Diagrams

Elements of a Class Diagram

Attribute VisibilityO Attribute visibility can be specified in the

class diagramO Public attributes (+) are visible to all classesO Private attributes (-) are visible only to an

instance of the class in which they are definedO Protected attributes (#) are like private

attributes, but are also visible to descendant classes

O Visibility helps restrict access to the attributes and thus ensure consistency and integrity

OperationsO Constructor

O Creates objectO Query

O Makes information about state available

O UpdateO Changes values of some or all

attributes

More Elements of Class Diagrams

MultiplicitiesDepartme

nt 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 MultiplicitiesEmployee Spouse

Employee Vacation

Employee Committee

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

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

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

O Conceptual models represent ideas, things, and objects in the real-world problem domain.

O A conceptual model is not a picture of:O Software components. O Classes in an object-oriented

programming language.O It illustrates real-world concepts.

4 Steps to Domain Model

O Make a list of candidate concepts O Create CRC CardsO Create the class diagram (Domain

Model)O Review the class diagram

STEP 1Make a list of candidate concepts

Strategies to Identify Conceptual Classes

O Use a conceptual class category listO Make a list of candidate concepts

O Use noun phrase identificationO Identify noun ( and noun phrases) in

textual descriptions of the problem domain, and consider them as concepts or attributes.

O Use Cases are excellent description to draw for this analysis.

Object IdentificationO Textual analysis of use-case

informationO Creates a rough first cutO Common object listO IncidentsO Roles

Textual analysis of use-case information

O • A NounO A common or improper noun implies a class of objects.O A proper noun or direct reference implies an instance of a class.O A collective noun implies a class of objects made up of groups of

instances of another class.O • An adjective implies an attribute of an object.O • A verb

O A verb doing verb implies an operation.O A being verb implies a classification relationship between an object

and its class.O A having verb implies an aggregation or association relationship.O A transitive verb implies an operation.O An intransitive verb implies an exception.O A predicate or descriptive verb phrase implies an operation.

O • An adverb implies an attribute of a relationship or an operation.

Step 2Create CRC cards

Designing with CRC cards

O CRC Cards—Classes, Responsibilities, Collaboration Cards.

O OO design is about assigning Responsibilities to Classes for how they Collaborate to accomplish a use case

O Usually a manual process done in a brainstorming session O 3 X 5 note cardsO One card per classO Front has responsibilities and collaborationsO Back has attributes needed

33

Detailed Design with CRC cards

O Design processO Identify class with primary

responsibility O Identify other classes that collaborate

with primary class (become requests for service to other classes)

O Identify responsibilities within each class (these become methods)

34

CRC Card Notation

35

CRC Card Results

36

Step 3Create Domain Model

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

Association CategoryO A is recorded in BO A uses or manages BO A is related to a

transaction of BO A communicates with BO A is a transaction

related to another transaction B

O A is next to BO A is related to B via a

transaction

O A is recorded in BO A uses or manages BO A is related to a

transaction of BO A communicates with BO A is a transaction

related to another transaction B

O A is next to BO A is related to B via a

transaction

SummaryO Structural Models

O CRC CardsO Class Diagrams

O Creating CRC cards and domain model

ReferenceO Alan R. Dennis, Barbara Haley

Wixom, and David Tegarden. 2007. Systems Analysis and Design with UML Version 2.0: An Object-Oriented Approach (3rd ed.). John Wiley & Sons, Inc., New York, NY, USA.