What is a Structural Model?

1
What is a Structural Model?

• A structural model describes the structure of the
  data that supports the business processes in an
  organization.
• It is a static model.
• The primary structural model in the UML is the
  class diagram.
• Structural models
• Reduce the semantic gap between the real world
  and the world of software
• Create a vocabulary for analysts and users
• Represent things, ideas, and concepts of
  importance in the application domain

2
Objects

• Any thing can be viewed as an object.
• Each object in a system has
• state, behavior, identity
• The state of an object is one of the possible
  conditions in which it may exist
• The behavior of an object determines how it
  responds to requests from other objects
• The identity of an object means that each object
  is unique

3
Class

• Each object is an instance of some class
• A class is a template for objects
• Objects cannot be instances of more than one
  class
• A good class captures one and only one
  abstraction it should have one major theme
• The name of a class should be a singular noun,
  that best describes the abstraction

4
Classes

• In the UML, classes are represented as
  compartmentalized rectangles
• The top compartment contains the name
• The middle compartment contains the structure
  (attributes)
• The bottom compartment contains the behavior
  (operations)

5
Class Diagram

• The Class Diagram is a static model that captures
  both processing requirements and data storage
  requirements of the system.
• The class diagram produced during OO analysis is
  a logical model. It shows what classes of objects
  are required without showing how the objects
  might be implemented or how the user might
  interact with them.

6
Documentation

• The documentation should state the purpose of the
  class, not the structure.
• For example, a StudentInformation class could be
  documented as
• Information needed to register and bill students.
  A student is someone who takes classes at the
  University.
• (Not The name, address, and phone number of a
  student.)

7
Entity Classes

• An entity class
• models information and associated behavior that
  is generally long lived
• is typically identified during the analysis phase
• is often called a domain class, since it usually
  deals with an abstractions of a real world entity

8
Boundary Classes

• A boundary class
• handles communication between the system and the
  system environment
• models the system interface
• To identify boundary classes, examine the
  actor/use case scenario pairs.

9
Control Classes

• A control class
• models sequencing behavior specific to one or
  more use cases
• coordinates the events needed to realize the
  behavior specified in the use case
• runs or executes the use case
• is typically application dependent

10
Responsibilities and Collaborations

• A class embodies
• a set of responsibilities that define the
  behavior of the objects in the class
• a set of attributes that define the structure of
  the objects in the class
• Objects collaborate
• they work together to service a request

11
Representing Behavior and Structure

• The responsibilities are carried out by the
  operations (methods, functions) defined for the
  class. Each operation should do only one thing.
• Objects in a class have a value for every
  attribute of the class. These values do not have
  to be unique.

12
Attributes

• Units of information relevant to the description
  of the class
• Only attributes important to the task should be
  included

13
Operations

• Action that instances/objects can take
• Focus on relevant problem-specific operations (at
  this point)

14
Representing Behavior and Structure

• A common convention for attribute and operation
  names consisting of multiple words is to write
  the name without spaces, but capitalize the first
  letter of each word, except the first word
• e.g. memberName, addNewMember.
• Class names consisting of multiple words are
  handled similarly, but the first letter of the
  first word is also capitalized
• e.g. StoreClerk.

15
Relationships

• In order for objects to collaborate, there must
  be an association between these objects.
• A special type of association, where one object
  is a part of another object, is called an
  aggregation relationship.

16
Association Relationships

• An association relationship between classes
  represents a link between the objects in those
  classes.
• The number of objects connected depends upon the
  multiplicity of the association.
• In the UML, association relationships are shown
  as lines connecting the classes.

17
Association Relationships

• The numbers and symbols representing multiplicity
  include a 1 for one and asterisk () for many.

18
Association Relationships

• Additional numbers and symbols are often added to
  indicate optional or mandatory relationships.
• Often these are referred to as minimum and
  maximum multiplicity.

19
Association RelationshipsRational Rose Example
0..
Tenant
rents
1..
1..
Rental property
unitAddress
change Owner Name()
is for
1
1
0..
0..
LeaseAgreement
20
Aggregation Relationship

• Whole-part relationships are usually called
  aggregation relationships.

21
Aggregation Relationships

• An aggregation relationship is a specialized form
  of association in which a whole is related to its
  parts.
• This kind of relationship applies whenever one
  can say is a part of .
• In UML notation, an aggregation relationship is
  an association with a diamond next to the class
  denoting the aggregate.
• The whole is called aggregate class.
• The part is called aggregation class

22
Aggregation RelationshipsRational Rose Example
Tenant
0..
0..
TenantName
1..
1..
Rental property
1
1
UnitAddress
OwnerName
change Owner Name()
1
1
1..
1..
0..
0..
LeaseAgreement
BeginningOccupancy
Lease Term
EndingOccupancy
Term
Deposit
MonthlyRent
0..
0..
RentDueDate
23
Composition Relationship

• A strong form of aggregation relationship is
  sometimes called a composition relationship.
• In a composition relationship, the parts do not
  normally exist without the whole.

24
Aggregation/Composition RelationshipsTogetherSoft
Examples
25
Naming of Relationships

• An association may optionally be named.
• The name is typically an active verb or verb
  phrase that communicates the meaning of the
  relationship.
• Aggregations are not usually named, since the
  relation is always of the type is a part of
• Choose the verb to be meaningful when read from
  left to right or top to bottom.

26
Naming of Relationships(Rational Rose)
27
Role Names

• The end of an association, where it connects to a
  class, is called an association role.
• Instead of association names, role names may be
  used.
• A role name is a noun that denotes the purpose of
  the association.

Renter of Property
Rental property
Tenant
0..
1..
1..
unitAddress
TenantName
OwnerName
change Owner Name()
28
Reflexive Relationships

• A reflexive association or aggregation is an
  association or aggregation relationship among
  objects of the same class.
• Role names, rather than association names are
  typically used for reflexive relationships.

29
Generalization/Specialization Hierarchies
30
Generalization/ Specialization Hierarchies

• Exhaustive subclasses cover all possible objects,
  so the general class, called abstract class, will
  not have any objects.

31
Inheritance

• A subclass inherits all attributes and operations
  from one or more superclasses (parent classes).
• The relationship is a is a kind of
  relationship objects in the subclass are special
  cases of the superclass.
• We can have a hierarchy of classes. Classes at
  the bottom of the hierarchy inherit from all
  ancestor classes.

32
Inheritance

• Subclasses may have additional attributes and
  operations, not defined in an ancestor class.
• Subclasses may also override attributes and
  operations defined in an ancestor class with
  their own versions this is called polymorphism.
• Inheritance and polymorphism are major factors
  for reuse They allow the creation of objects
  from augmented or modified classes.

33
Generalization

• Generalization provides the capability to create
  superclasses that encapsulate structure and
  behavior common to several classes.
• Classes are examined for commonality of
  structure and behavior.
• Be on the lookout for synonyms, since attribute
  and operation names are expressed in natural
  language.

34
Specialization

• Specialization provides the ability to create
  subclasses that represent refinements to the
  superclass typically, structure and behavior
  are added to the subclass, but they may also be
  modified (polymorphism).

35
Single Inheritance versus Multiple Inheritance

• With single inheritance, a class has one chain of
  ancestors
• e.g. a car is a kind of motor vehicle a motor
  vehicle is a kind of vehicle

36
Single Inheritance versus Multiple Inheritance

• With multiple inheritance, a subclass may have
  more than one chain of ancestors
• e.g. an amphibious vehicle is a kind of road
  vehicle a road vehicle is a kind of vehicle an
  amphibious vehicle is a kind of water vehicle a
  water vehicle is a kind of vehicle).
• Multiple inheritance may lead to conflict.

37
Multiple Inheritance
38
Inheritance versus Aggregation

• Inheritance is often misused. For example,
  Student and Staff can be subclasses of Person.
  Problems arise if staff can also be students.
  Using aggregation classes may solve the problem

39
Association Classes
40
Association ClassesAlternate Modeling Approach
41
Steps for Object Identification and Structural
Modeling
1. Identify candidate classes by performing
textual analysis on the use-cases. 2.
Brainstorm additional candidate classes,
attributes, operations, and relationships
by using the common object list approach. 3.
Role-play each use-case. 4. Create the class
diagram. 5. Review the structural model for
missing and/or unnecessary classes, attributes,
operations, and relationships. 6. Incorporate
useful patterns. 7. Review the structural model.
42
Packages

• If the class diagram become large, it will be
  quite difficult to use for an overview of the
  system.
• In such cases it might be necessary to create a
  high-level view of the system, using some kind of
  partitioning or clustering scheme.
• Clustering can be done after the initial model is
  produced to facilitate presentation and further
  work, or beforehand to allow for division of work
  between workgroups from the outset.
• UML calls these clusters packages and provides a
  modeling notation called package diagram.

43
Package Relationships

• If objects in one package communicate with
  objects in another package, then a dependency
  relationship exists between the packages.
• The dependent package is called the client
  package, and the other package is called the
  supplier package.
• The relationship is shown in the UML as a dashed
  arrow, pointing to the supplier package

User Interface
Persistent Objects