SOFTWARE ARCHITECTURE & DESIGN

STRUCTURAL MODELING

Atique Zafar

1
Overview

2
• A structural, or conceptual, model describes the
structure of the objects that support the business
processes in an organization.
• During analysis, the structural model presents the logical
organization of the objects without indicating how they
are stored, created, or manipulated so that analysts can
focus on the business, without being distracted by
technical details.
• Later during design, the structural model is updated to
reflect exactly how the objects will be stored in
databases and files.
• class–responsibility–collaboration (CRC) cards, class
diagrams, and object diagrams, are used to create the
structural model. 3
 Structural Model

• A structural model is a formal way of

representing the objects that are used and
created by a business system.
• It illustrates people, places, or things about
which information is captured and how they
are related to one another.
• The structural model is drawn using an
iterative process in which the model becomes
more detailed and less conceptual over time.

4
 Analysis phase

• 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.
– Because this model is free from any
implementation or technical details, the analysts
can focus more easily on matching the model to
the real business requirements of the system.

5
 Design phase

• In design, analysts evolve the conceptual

structural model into a design model that
reflects how the objects will be organized in
databases and software.
– At this point, the model is checked for redundancy,
and the analysts investigate ways to make the
objects easy to retrieve.

6
• Every time a systems analyst encounters a new problem to
solve, the analyst must learn the underlying problem domain.
• The goal of the analyst is to discover the key objects
contained in the problem domain and to build a structural
model.
• The structural model at this point should represent the
responsibilities of each class and the collaborations among
the classes
– Typically, structural models are depicted using CRC cards,
class diagrams, and, in some cases, object diagrams

7
 Elements of Structural Models

• Basic elements of structural models include

– Classes
– Attributes
– Operations
– And relationships

8
 Class
• A class is a general template that we use to create specific
instances, or objects, in the problem domain.
• There are two general kinds of classes of interest during analysis:
– concrete and abstract.
• Normally, when an analyst describes the application domain
classes, he or she is referring to concrete classes; that is,
concrete classes are used to create objects.
– Abstract classes
• do not actually exist in the real world; they are simply useful
abstractions
– For example, from an employee class and a customer
class, we may identify a generalization of the two classes
and name the abstract class person.

9
• A second classification of classes is the type of
real-world thing that a class represents.
– There are domain classes, user-interface classes,
data structure classes, file structure classes,
operating environment classes, document classes,
and various types of multimedia classes.
• At this point in the development of our
evolving system, we are interested only in
domain classes.
• Later in design and implementation, the other
types of classes become more relevant.
10
 Attribute
• An attribute of an analysis class represents a piece of
information that is relevant to the description of the class
within the application domain of the problem being
investigated.
• An attribute contains information the analyst or user feels the
system should keep track of.
– For example, a possible relevant attribute of an employee
class is employee name.
– Only attributes that are important to the task should be
included in the class.
– Finally, only attributes that are primitive or atomic types
(i.e., integers, strings, doubles, date, time, Boolean, etc.)
should be added.
11
 Behavior
• The behavior of an analysis class is defined in
an operation or service.
• In later phases, the operations are converted
to methods.
• However, because methods are more related
to implementation, at this point in the
development we use the term operation to
describe the actions to which the instances of
the class are capable of responding.

12
• Like attributes, only problem domain–specific
operations that are relevant to the problem
being investigated should be considered.
– For example, it is normally required that classes
provide means of creating instances, deleting
instances, accessing individual attribute values,
setting individual attribute values, accessing
individual relationship values, and removing
individual relationship values.
• However, at this point in the development of the
evolving system, the analyst should avoid cluttering up
the definition of the class with these
13
 Relationships
• There are many different types of
relationships that can be defined, but all can
be classified into three basic categories of data
abstraction mechanisms:
– generalization relationships,
– aggregation relationships, and
– association relationships.

14
 Generalization Relationships
• The generalization abstraction enables the
analyst to create classes that inherit attributes
and operations of other classes.
• The analyst creates a superclass that contains
basic attributes and operations that will be
used in several subclasses.
• The subclasses inherit the attributes and
operations of their superclass and can also
contain attributes and operations that are
unique just to them.
15
 Example
• For example, a customer class and an
employee class can be generalized into a
person class by extracting the attributes and
operations both have in common and placing
them into the new superclass, person.
– In this way, the analyst can reduce the redundancy
in the class definitions so that the common
elements are defined once and then reused in the
subclasses.
• Generalization is represented with the a-kind-
of relationship, so that we say that an
employee is a-kind-of person. 16
 Specialization
• The analyst also can use the opposite of
generalization.
• Specialization uncovers additional classes by
allowing new subclasses to be created from an
existing class.
– For example, an employee class can be specialized
into a secretary class and an engineer class.

17
 Aggregation Relationships
• Generally speaking, all aggregation
relationships relate parts to wholes or
assemblies.
• For our purposes, we use the a-part-of or has-
parts semantic relationship to represent the
aggregation abstraction.
– For example, a door is a-part-of a car, an employee
is a-part-of a department, or a department is a-
part-of an organization.

18
• Like the generalization relationship,
aggregation relationships can be combined
into aggregation hierarchies.
• For example, a piston is a-part-of an engine,
and an engine is a-part-of a car.
• Aggregation relationships are bidirectional.
• The flip side of aggregation is decomposition.

19
• The analyst can use decomposition to uncover
parts of a class that should be modeled
separately.
– For example, if a door and an engine are a-part-of
a car, then a car has-parts door and engine.
– The analyst can bounce around between the
various parts to uncover new parts.
• For example, the analyst can ask, What other parts are
there to a car? or To which other assemblies can a door
belong?

20
 Association Relationships
• There are other types of relationships that do
not fit neatly into a generalization (a-kind-of)
or aggregation (a-part-of) framework.
• Technically speaking, these relationships are
usually a weaker form of the aggregation
relationship.
• For example, a patient schedules an
appointment.
• It could be argued that a patient is a-part-of an
appointment.
21
• However, there is a clear semantic difference
between this type of relationship and one that
models the relationship between doors and
cars or even workers and unions.
– Thus, they are simply considered to be
associations between instances of classes.

22
 Object Identification
• Different approaches have been suggested to aid the
analyst in identifying a set of candidate objects for
the structural model.
• The four most common approaches are
– textual analysis,
– brainstorming,
– common object lists,
– and patterns.
• Most analysts use a combination of these techniques
to make sure that no important objects and object
attributes, operations, and relationships have been
overlooked. 23
 Textual Analysis
• The analyst performs textual analysis by
reviewing the use-case diagrams and
examining the text in the use-case
descriptions to identify potential objects,
attributes, operations, and relationships.
• The nouns in the use case suggest possible
classes, and the verbs suggest possible
operations.
• Figure 5-1 presents a summary of useful
guidelines.
24
 Textual Analysis Guidelines

• use-case descriptions has been criticized as being too simple, but because its
primary purpose is to create an initial rough-cut structural model, its
simplicity is a major advantage.

25
Example
• potential objects and attributes Include
– Old patient,
– doctor,
– Appointment
– patient,
– office,
– receptionist,
– name,
– address, patient information,
– payment,
– date, and time.
• potential operations include
– patient contacts office,
– makes a new appointment,
– cancels an existing appointment,
– changes an existing appointment,
matches
– requested appointment times and
dates with requested times and
dates,
– and finds current appointment.

26
 Brainstorming
• Brainstorming is a discovery technique that
has been used successfully in identifying
candidate classes.
• Essentially, in this context, brainstorming is a
process that a set of individuals sitting around
a table suggest potential classes that could be
useful for the problem under consideration.
• Typically, a brainstorming session is kicked off
by a facilitator who asks the set of individuals
to address a specific question or statement
that frames the session. 27
 Procedure

• using the appointment problem described

previously, the facilitator could ask the
development team and users to think about
their experiences of making appointments and
to identify candidate classes based on their
past experiences.
• Notice that this approach does not use the
functional models developed earlier.
• It simply asks the participants to identify the
objects with which they have interacted.
28
 Example
• For example, a potential set of objects that come to mind
are
– doctors, nurses, receptionists, appointment, illness,
treatment, prescriptions, insurance card, and medical
records.
• Once a sufficient number of candidate objects have been
identified, the participants should discuss and select
which of the candidate objects should be considered
further.
• Once these have been identified, further brainstorming
can take place to identify potential attributes, operations,
and relationships for each of the identified objects.
29
 CRC CARDS

• CRC (Class–Responsibility–Collaboration) cards

are used to document the responsibilities and
collaborations of a class.
• Responsibilities and Collaborations
• Responsibilities of a class can be broken into
two separate types:
– knowing and doing.

30
 knowing and doing
• Knowing responsibilities are those things that an
instance of a class must be capable of knowing.
– An instance of a class typically knows the values of
its attributes and its relationships.
• Doing responsibilities are those things that an
instance of a class must be capable of doing.
• The structural model describes the objects necessary
to support the business processes modeled by the
use cases.
• Most use cases involve a set of several classes, not
just one class.
– These classes form collaborations
31
 Collaborations
• Collaborations allow the analyst to think in
terms of clients, servers, and contracts.
– A client object is an instance of a class that sends a
request to an instance of another class for an
operation to be executed.
– A server object is the instance that receives the
request from the client object.
– A contract formalizes the interactions between the
client and server objects.

32
• An analyst can use the idea of class
responsibilities and client–server–contract
collaborations to help identify
– the classes, along with the attributes, operations,
and relationships, involved with a use case.
• One of the easiest ways to use CRC cards in
developing a structural model is through
anthropomorphism—
– pretending that the classes have human
characteristics.
33
• Members of the development team can either
ask questions of themselves or
– be asked questions by other members of the
team.
• Typically the questions asked are of the form:
– Who or what are you?
– What do you know?
– What can you do?
• The answers to the questions are then used to
add detail to the evolving CRC cards.
34
 Example
• In the appointment problem, a member of the
team can pretend that he or she is an
appointment.
• In this case, the appointment would answer that
– he or she knows about the doctor and patient who
participate in the appointment and
– they would know the date and time of the
appointment.
– Furthermore, an appointment would have to
know how to create itself, delete itself, and to
possibly change different aspects of itself.
35
 Elements of a CRC Card

• The front of the card contains

36
 Elements of a CRC Card

• The Back of the card contains

37
 Role-Playing CRC Cards with Use Cases
• CRC cards can be used in a role-playing exercise that
has been shown to be useful in discovering
– additional objects, attributes, relationships, and
operations.
– the members of the team perform the different
steps associated with a specific scenario of a use
case
– A useful place to look for the different scenarios of
a use case is the activity diagrams
– Also, scenarios can be identified from the
alternative/exceptional flows in a use-case
description. 38
 Steps Involve in Role-Playing
• Review Use Cases
– the team should choose the use case that is the
most important, the most complex, or the least
understood.
• Identify Relevant Actors and Objects
– identify the relevant roles that are to be played.
– Each role is associated with either an actor or an
object.
– To choose the relevant objects, the team reviews
each of the CRC cards and picks the ones that are
associated with the chosen use case.
39
 Role-Play Scenarios
• The third step is to role-play scenarios of the
use case by having the team members
perform each one.
• To do this, each team member must pretend
that he or she is an instance of the role
assigned to him or her.
• For example,
– if a team member was assigned the role of the
Receptionist, then he or she would have to be able
to perform the different steps in the scenario
associated with the Receptionist.
40
 CLASS DIAGRAMS

• A class diagram is a static model that shows

– the classes and the relationships among classes
that remain constant in the system over time.
• The class diagram depicts classes, which
include
– both behaviors and states, with the relationships
between the classes.

41
 Elements of a Class Diagram
• Class
– The main building block of a class diagram is the
class, which stores and manages information in
the system
– During analysis, classes refer to the people, places,
and things about which the system will capture
information.
– Later, during design and implementation, classes
can refer to implementation-specific artifacts such
as windows, forms, and other objects used to
build the system.
42
Class Diagram Syntax

43
Class Diagram Syntax

44
Class Diagram Syntax

45
 Attributes
• Attributes are properties of the class about
which we want to capture information
• At times, you might want to store derived
attributes, which are attributes that can be
calculated or derived;
– these special attributes are denoted by placing a
slash (/) before the attribute’s name.
• Notice how the person class contains a
derived attribute called /age,
– which can be derived by subtracting the patient’s
birth date from the current date. 46
 Attribute Visibility
• Visibility relates to the level of information hiding to be
enforced for the attribute.
– The visibility of an attribute can be public (+),
protected (#), or private (−).
• A public attribute is one that is not hidden from any
other object.
– As such, other objects can modify its value.
• A protected attribute is one that is hidden from all other
classes except its immediate subclasses.
• A private attribute is one that is hidden from all other
classes.
– The default visibility for an attribute is normally
private. 47
 Operations

• Operations are actions or functions that a

class can perform .
• The functions that are available to all classes
– (e.g., create a new instance, return a value for a
particular attribute, set a value for a particular
attribute, delete an instance) are not explicitly
shown within the class rectangle.
– Instead, only operations unique to the class are
included, such as the cancel without notice
operation in the Appointment class and the
calculate last visit operation in the Patient Class
48
 Visibility of Operations
• As with attributes, the visibility of an
operation can be designated
– public, protected, or private.
• The default visibility for an operation is
normally public.

49
 Relationships

• A primary purpose of a class diagram is to

show the relationships, or associations, that
classes have with one another.
• When multiple classes share a relationship (or
a class shares a relationship with itself), a line
is drawn and labeled with either
– the name of the relationship or the roles that the
classes play in the relationship.

50
 Example
• In Figure, three additional
examples of associations
are portrayed:
• An Invoice is Associated
With a Purchase Order (and
vice versa), a Pilot Flies an
Aircraft , and a Spare Tire
IsLocatedIn a Trunk
• Inclusion of the triangle
simply increases the
readability of the diagram.

51
 Multiplicity
• Relationships also have
multiplicity, which
documents how an
instance of an object can
be associated with other
instances.

52
 Sample Association Classes
• There are times when a relationship itself has
associated properties,
– especially when its classes share a many-to-many
relationship.
– In these cases, a class called an association class is
formed, which has its own attributes and
operations.
– It is shown as a rectangle attached by a dashed
line to the association path, and
– the rectangle’s name matches the label of the
association.
53
 Example

• the Grade idea is really an intersection of the Student

and Course classes, because a grade exists only at the
intersection of these two ideas.
• a job may be viewed as the intersection between a
Person and a Company.
54
Sample Generalizations

55
Sample Aggregation
Associations

56
Sample Composition
Associations

57
 Aggregation Vs Composition
• Aggregation is used to portray Logical implies • Composition is used to portray a
that it is possible for a part to be associated physical part of relationships and
with multiple wholes or that is relatively is shown by a black diamond.
simple for the part to be removed from the
whole. • Physical implies that the part can
– For example, be associated with only a single
• An instance of the Employee class IsPartOf an whole.
instance of at least one instance of the – For example
Department class, • an instance of a door can be a part of
• an instance of the Wheel class IsPartOf an only a single instance of a car,
instance of the Vehicle class, and • an instance of a room can be a part of
• an instance of the Desk class IsPartOf an an instance only of a single building,
instance of the Office class. and
– Obviously, in many cases an employee • an instance of a button can be a part
of only a single mouse
can be associated with more than one
department, and
– it is relatively easy to remove a wheel
from a vehicle or move a desk from an
office.

58
 Object Diagrams
• A second type of static structure diagram, called an
object diagram, can be useful in revealing additional
information.
• An object diagram is essentially an instantiation of all
or part of a class diagram.
– Instantiation means to create an instance of the
class with a set of appropriate attribute values.
– Object diagrams can be very useful when trying to
uncover details of a class.
– Generally speaking, it is easier to think in terms of
concrete objects (instances) rather than
abstractions of objects (classes).
59
Object Diagram

60