structural modeling. objectives o understand the rules and style guidelines for creating crc cards,...
TRANSCRIPT
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
ntBoss
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
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
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.