Module 5: Object-Oriented Analysis – Static Model

Software Engineering
Computer Science
Academic Year 2023/2024

Gerard Albà Soler

1
Contents
1. Introduction
• What will we learn
2. Domain Model
3. Class Diagrams
- Classes
- Attributes
- Operations
- Class Relationships
4. Object Diagrams
- Constraints
1. Introduction
What will we learn?
• Static or Structural modeling captures the static features of a system.
• Structural model represents the framework for the system and this framework is the place
where all other components exist. Hence, the class diagram, component diagram and
deployment diagrams are part of structural modeling. They all represent the elements and
the mechanism to assemble them.
• The structural model does not describe the dynamic behavior of the system.
• What are we going to see in this section? Modeling Elements in UML! Such as:
ü Class diagrams
ü Objects diagrams
1. Introduction
What will we learn?
• The static model: aspects of the internal structure of the system.
ü Intra-object: attributes and operations of classes.
ü Inter-object: relations between object classes.

• Modelled elements used in this section:

ü UML Class Diagram: static view of the internal structure of the system.
ü UML Object Diagram: snapshot of the system at a particular time.

• OOA/D uses the Analysis done in UML use cases and diagrams to help developers
understand the requirements and to design software. OOAD uses UML diagrams to
represent the different components and interactions of a software system.
1. Introduction
What will we learn?
1. Introduction
What will we learn?
1. Introduction
What will we learn?
OOA/D

Examples
Discovering Static Model
Objects

OOA/D

Object
Domain Model
Diagrams

Class
Diagrams
 1. Introduction
• Book References

ü Object-Oriented Analysis and Design with Applications 3rd ed. G Booch et

al. Ed Addison-Wesley Object Technology Series
ü Applying UML and Patterns 3rd ed. C. Larman. Ed Prentice Hall
ü UML in Practice. P Roques. Ed Wiley
ü UML 2.0. R Miles. Ed O’Reilly
ü UML Unified Modeling Language. Tutorials point SimplyEasyLearning
1. Introduction
UML topic Video tutorial
https://youtu.be/-OWd0tJAK10?si=lC8wS76SQCuxejzK
Introduction UML

https://youtu.be/3LrOpwhsplY?si=Sx5ur8Zbs-8D65r1
OOA/D in UML
https://youtu.be/qoxoX3ZiazI?si=hjMVkshhZ--z-h-s
UML Modeling
https://youtu.be/kNV-NvBuH7M?si=DD5UW_PrxOar-7kW
https://youtu.be/NEmZZX8Xgns?si=ZRHvNPqzTpZzSpjy
Class Diagram https://youtu.be/wkTuCIScFQI?si=8GpNOVVTVYoOCZNU
https://youtu.be/sKqMDsDoeQ8?si=zgkNWfeVMrLnmCFO

https://youtu.be/Rhgg3hSI6I0?si=ASMFoc61a_PCOlLI
Object Diagram
Contents
1. Introduction
• What will we learn
2. Domain Model
3. Class Diagrams
- Classes
- Attributes
- Operations
- Class Relationships
4. Object Diagrams
- Constraints
2. Domain Model
• The quintessential object-oriented analysis step is the decomposition of a domain
into noteworthy concepts or objects.
• A domain model is a visual representation of conceptual classes or real-situation
objects in a domain.
• Domain models have also been called conceptual models, domain object models,
and analysis object models.
• Domain model means a representation of real-situation conceptual classes, not of
software objects. The term does not mean a set of diagrams describing software
classes, the domain layer of a software architecture, or software objects with
responsibilities.
 2. Domain Model
• Domain model means a representation of real-situation conceptual classes, not of software
objects. The term does not mean a set of diagrams describing software classes, the domain
layer of a software architecture, or software objects with responsibilities (like coded in
Pyhton, C++, Java etc).
• The object-oriented developer
will take inspiration from the real
world domain in creating
software clases (Design Model).
• Therefore, the representational
gap between how stakeholders
conceive the domain, and its
representation in software, is
lowered.
 2. Domain Model
• A system’s structure is made up of a collection of pieces often referred to as
objects. Classes describe the different types of objects that your system can have,
and class diagrams show these classes and their relationships.
• Use cases describe the behavior of your system as a set of concerns. Classes
describe the different types of objects that are needed within your system to meet
those concerns.
• Classes form part of the model’s logical view, as described in Module 3 (section 3).
• Let see conceptual Classes and Objects in more detail in the next sections.
Contents
1. Introduction
• What will we learn
2. Domain Model
3. Class Diagrams
- Attributes
- Operations
- Class Relationships
4. Object Diagrams
- Constraints
 3. Class Diagrams
• A UML class diagram is therefore used to show the existence of classes and their
relationships in the logical view of a system.

• During analysis, we use class diagrams to indicate the common roles and
responsibilities of the entities that provide the system’s behavior. During design, we
will use those class diagrams to capture the structure of the classes that form the
system’s architecture.

• The two essential elements of a class diagram are classes and their basic
relationships.
 3. Class Diagrams

• A class is a detailed description of

what a thing (an object) will be.
• It’s basically the template for the
future objects that we will create.
• Describes the data (attributes or
state) and operations (the • The figure shows the icon used to represent a
behavior) that will be shared by class in UML and in a class diagram and an
all instances (objects) of the class. example from a “Gardening System”. The class
icon consists of three compartments, with the
• Many objects can be created from
first occupied by the class name, the second
a class.
by the attributes, and the third by the
operations.
3. Class Diagrams
Class and Objects in UML
3. Class Diagrams
Classes in UML
• A name is required for each class and must be unique to its enclosing namespace.
By convention, the name begins in capital letters, and the space between multiple
words is omitted.
• Again by convention, the first letter of the attribute and operation names is
lowercase, with subsequent words starting in uppercase, and spaces are omitted
just as in the class name. Since the class is the namespace for its attributes and
operations, an attribute name must be unambiguous in the context of the class. So
must an operation name, according to the rules in the chosen implementation
language.
3. Class Diagrams
Classes in UML
• The format of the attribute and operation specifications of a class is shown here:
ü Attribute specification format

ü Operation specification format

• We will discuss the concept of visibility (public, private, protected, or package)

later in an upcoming subsection.
 3. Class Diagrams
Attributes

• Attributes are shared characteristics of all objects created from the same class.
• For each object attributes we get to assign a value.
• Each attribute has a type (the ones found in any programming language (int, boolean…).
• Note from the example figure that in the TemperatureSensor class, the multiplicity of [0..60] on the
measuredTemperature attribute indicates an array of 0 to 60 temperature measurements.
• The default value for an attribute is the value to be given at creation time, if none was provided.
• The property string listed in braces provides additional properties such as {list} shown after the
measuredTemperature attribute. In this case, the keyword list means that the temperature
measurements will be ordered and may be nonunique. This provides the means to see the time
ordering of the measurements and to permit a repetition in measured temperature.
 3. Class Diagrams
Operations

• A class’s operations describe what a class can do but not necessarily how it is going to do it. An
operation is more like a promise or a minimal contract that declares that a class will contain some
behavior that does what the operation says it will do. The collection of all the operations that a class
contains should totally encompass all of the behavior that the class contains.
• Operations are common to all object’s instances of a same class.
• The behaviour is applied on the object for which it is called (the one that executes the operation).
• They have a name, parameters, return type, exceptions and possibly a set of pre and post condition.
• Parameters are used to specify the information provided to an operation to allow it to complete its job.
More than one parameter can be passed to an operation by splitting the parameters with a comma.
• An operation’s signature also contains a return type. A return type is specified after a colon at the end.
 3. Class Diagrams
Visibility
• Visibility notations indicate the
access level of attributes and
methods. Common visibility
notations include:

+ for public (visible to all classes)

- for private (visible only within the class)
# for protected (visible to subclasses)
~ for package or default visibility (visible to
classes in the same package)
 3. Class Diagrams
Public Visibility
• Public visibility is specified using the plus (+) symbol
before the associated attribute or operation.
Declare an attribute or operation public if you want
it to be accesible directly by any other class.

• The collection of attributes and operations that are

declared public on a class create that class’s public
interface.

• The public interface of a class consists of the

attributes and operations that can be accessed and
used by other classes. This means the public
interface is the part of your class that other classes
will depend on the most.
 3. Class Diagrams
Protected Visibility
• Protected attributes and operations are specified using
the hash (#) symbol and are more visible to the rest of
your system than private attributes and operations, but
are less visible than public.
• Declared protected elements on classes can be
accessed by methods that are part of your class and
also by methods that are declared on any class that
inherits from your class.
• Protected elements cannot be accessed by a class that
does not inherit (see Module 2 on OOP) from your class
whether it’s in the same package or not.
• Protected visibility is crucial if you want to allow
specialized classes to access an attribute or operation in
the base class without opening that attribute or
operation to the entire system.
 3. Class Diagrams
Package Visibility

• Package visibility, specified with a tilde (~),

when applied to attributes and operations, sits
in between protected and private. Packages are
the key factor in determining which classes can
see an attribute or operation that is declared
with package visibility.
 3. Class Diagrams
Private Visibility

• Private visibility is the most tightly constrained

type of visibility classification, and it is shown
by adding a minus (-) symbol before the
attribute or operation.

• Only the class that contains the private

element can see or work with the data stored
in a private attribute or make a call to a private
operation.
 3. Class Diagrams
Class Relationships
• Classes can have relationships to one another. A class can be a type of another
class—generalization—or it can contain objects of another class in various ways
depending on how strong the relationship is between the two clases.
• There are several types of relationships in object-oriented modeling, each serving a
specific purpose. Here are some common types of relationships in class diagrams:
 3. Class Diagrams
Association
• An association represents a bi-directional relationship between two classes. It
indicates that instances of one class are connected to instances of another class.
• Associations are depicted in UML Class diagrams as a solid line connecting the
classes, with optional arrows indicating the direction of the relationship.
 3. Class Diagrams
Association
• In a directed association, an arrowhead is
added in UML to the association line to
indicate the direction of the relationship.
The arrow points from the class that
initiates the association to the class that is
being targeted or affected by the
association.
• Directed associations are used when the
association has a specific flow or
directionality, such as indicating which class
is responsible for initiating the association
or which class has a dependency on
another.
 3. Class Diagrams
Association

• Aggregation is a specialized form of

association that represents a “whole-part”
relationship.
• It denotes a stronger relationship where
one class (the whole) contains or is
composed of another class (the part).
• Aggregation is represented by a diamond
shape on the side of the whole class.
• In this kind of relationship, the child class
can exist independently of its parent class.
 3. Class Diagrams
Association

• Composition is a stronger form of

aggregation, indicating a more significant
ownership or dependency relationship.

• In composition, the part class cannot

exist independently of the whole class.

• Composition is represented by a filled

diamond shape on the side of the whole
class.
 3. Class Diagrams
Association

• Generalization (Inheritance) represents

an “is-a” relationship between classes,
where one class (the subclass or child)
inherits the properties and behaviors of
another class (the superclass or parent).

• Inheritance is shown in UML by a solid

line with a closed, hollow arrowhead
pointing from the subclass to the
superclass of the whole class.
 3. Class Diagrams
• The association icon connects two classes and denotes a semantic
connection. Associations are often labeled with noun phrases, such
as Analyzes in the example, denoting the nature of the relationship.
• A class may have an association to itself (called a reflexive
association), such as the collaboration among instances of the
PlanAnalyst class.
• Associations may be further adorned with their multiplicity, using
the syntax in the following examples:
ü 1 Exactly one
ü * Unlimited number (zero or more)
ü 0..* Zero or more
ü 1..* One or more
ü 0..1 Zero or one
ü 3..7 Specified range (from three through seven,
inclusive)
• The multiplicity notation is applied to the target end of an
association and denotes the number of links between each instance
of the source class and instances of the target class.
 3. Class Diagrams
Dependency

• A dependency exists between two

classes when one class relies on another,
but the relationship is not as strong as
association or inheritance.

• It represents a more loosely coupled

connection between clases than
association.

• Dependencies are often depicted as a

dashed arrow.
 3. Class Diagrams
Abstract Class
• A class’s definition contains the details about that class that are important
for the modeling.
• However, if the class were to be used only in part of the system, then
some details can be ignored in. Discarding irrelevant details within a given
context is called abstraction.
• An abstract class is one for which no instances may be created. Because
such classes are so important to engineering good class inheritance trees,
there is a special way to designate an abstract class, as shown in the next
figure.
• We italicize the class name to show that we may haveonly instances of its
subclasses. Similarly, to denote that an operation is abstract, we simply
italicize the operation name; this means that this operation may be
implemented differently by all instances of its subclasses.
• In the example: we have food items that have a specific vitamin content
and caloric equivalent, but there is not a type of food called “food item.”
Hence, the FoodItem class is abstract.
 3. Class Diagrams
Multiplicity
• Sometimes an attribute will represent more than one object. In fact, an attribute could
represent any number of objects of its type (in a language programming, this is like
declaring that an attribute is an array).

• Multiplicity allows you to specify that an attribute actually represents a collection of

objects, and it can be applied to both inline and attributes by association, as shown in the
next example.
 3. Class Diagrams
• In the example, the trackbacks, comments, and authors attributes all represent collections of objects.
ü The * at the end of the trackbacks and comments attributes specifies that they could contain any number of
objects of the Trackback and Comment class, respectively.
ü The authors attribute is a little more constrained since it specifies that it contains between one and five authors.
ü The entries attribute that is introduced using an association between theBlogAccount class and the BlogEntry
class has two multiplicity properties specified at either end of the association. A * at the BlogEntry class end of
the association indicates that any number of BlogEntry objects will be stored in the entries attribute within the
BlogAccount class. The 1 specified at the other end of the association indicates that each BlogEntry object in the
entries attribute is associated with one and only one BlogAccount object.
ü Notice also in the example that the trackbacks, comments, and entries attributes also have extra properties to
describe in even more detail what the multiplicity on the attributes means. The trackbacks attribute represents
any number of objects of the Trackback class, but it also has the unique multiplicity property applied to it. The
unique property dictates that no two Trackback objects within the array should be the same. This is a reasonable
constraint since we don’t want an entry in another blog cross-referencing one of our entries more than once;
otherwise the list of trackbacks will get messy.
Contents
1. Introduction
• What will we learn
2. Domain Model
3. Class Diagrams
- Classes
- Attributes
- Operations
- Class Relationships
4. Object Diagrams
- Constraints
 4. Object Diagrams
Object Diagrams
• Classes are at the heart of any object-oriented system; one of the most popular UML
diagrams is the class diagram. A system’s structure is made up of a collection of pieces often
referred to as objects. A class is a type of something. The class is the blueprint out of which
objects (an instance of the class) can be constructed.
• Object Diagrams represent therefore the system as a set of objects that interact with each
other. Finding and describing the objects or concepts in the problem domain.
• Objects are entities in the application domain (tangible or not).
• Objects are described by:
ü Identity - Memory address
ü Attributes - State of the object
ü Operations - Actions that the object can perform
 4. Object Diagrams
• Object Diagram UML notation:

• We have already discussed that an object diagram is an instance of a class diagram. It implies that an
object diagram consists of instances of things used in a class diagram. So both diagrams are made of
same basic elements but in different form. In class diagram elements are in abstract form to represent
the blue print and in object diagram the elements are in concrete form to represent the real world object.
• To capture a particular system, numbers of class diagrams are limited. However, if we consider object
diagrams then we can have unlimited number of instances, which are unique in nature.
 4. Object Diagrams
Constraints
• Sometimes you will want to restrict the ways in which a class can operate.
• These types of constraints go beyond what can be done with simple UML notation and calls for a
language in its own right: the OCL (Object Constraint Language).
• Invariants:
ü An invariant is a constraint that must always be true; otherwise the system is in an invalid state.
Invariants are defined on class attributes.
• Preconditions:
ü A precondition is a constraint that is defined on a method and is checked before the method
executes. Preconditions are frequently used to validate input parameters to a method.
• Postconditions:
ü A postcondition is also defined on a method and is checked after the method executes.
Postconditions are frequently used to describe how values were changed by a method.
 4. Object Diagrams
Constraints
• Constraints are specified using either the OCL statement in curly brackets next to the class member
or in a separate note, as shown in the next figure