OBJECT-ORIENTED ANALYSIS
Object-oriented analysis techniques are used to:
-
study existing objects to see if they can be reused or adapted for new uses,
-
define new or modified objects that will be combined with existing objects into a
useful business computing application.
In the late 80’s and 90’s there were many different object-oriented methods and modeling
techniques used what limited sharing of models across projects (reduced reusability) and
hampered communication between team members and users. In 1997 the goal of creating a
single, standard process for developing object-oriented systems was finally reached. This
widely accepted today standard is called Unified Modeling Language and it is a set of
modeling conventions that is used to specify or describe a software system in terms of objects.
Concepts for object modeling
Object - it is something that is or is capable of being seen, touched, or otherwise sensed, and
about which users store data and associate behavior.
Attributes – this is data that represents characteristics of interest about an object.
Behavior – it refers to those things that the object can do and that correspond to functions that
act on the object’s data (or attributes). Behavior is commonly referred to as a method,
operation or service.
Encapsulation – it is the packaging of several items together into one unit (also referred to as
information biding). Applied to objects, both attributes and behavior of the object are
packaged together. They are considered part of that object. The only way to access or change
an object’s attributes is through that object’s specified behaviors.
Class – it is a set of objects that share the same attributes and behavior. A class is sometimes
referred to as an object class.
Inheritance – it means that methods and/or attributes defined in an object class can be
inherited or reused by another object class.
Generalization/specialization is a technique wherein the attributes and behaviors that are
common to several types of object classes are grouped into their own class, called supertype
1
Information systems analysis
Karolina Muszyńska
(also called generalization class). The attributes and methods of the supertype object class are
then inherited by those object classes (called specialization classes).
Object/class relationship - it is a natural business association that exists between one or more
objects/classes.
Multiplicity – it defines how many instances of one object/class can be associated with one
instance of another object/class.
Aggregation – it is a special kind of relationship, which shows that some objects/classes are
made up of other objects/classes. By identifying aggregation relationships we can partition a
very complex object and assign behaviors and attributes to the individual objects within it.
There are two types of aggregation relationships:
-
composition aggregate relationships among object classes (all part-objects make up
and live in the whole-object)
-
shared aggregation relationships, which implies that parts may be shared by many
wholes.
Objects/classes interact or “communicate” with one another by passing messages.
Message – it is passed when one object invokes one or more of another object’s methods
(behaviors) to request information or some action.
Polymorphism – means “many forms”. Applied to object-oriented techniques it means that the
same named behavior may be completed differently for different objects/classes.
What is important in message sending is that the requesting object knows what service to
request and from which object but it does not have to worry about how a behavior is
accomplished.
UML diagrams
UML offers different groups of diagrams to model a system. Each UML diagram provides the
development team a different perspective of the information system. The various UML
diagrams and their purposes are as follows:
1. Use Case Diagrams – they graphically depict the interactions between the system and
external systems and users. They graphically describe who will use the system and in
what ways the user expects to interact with the system.
2. Class Diagrams – they depict the system’s object structure. They show object classes
that the system is composed of as well as the relationships between those object
classes.
2
Information systems analysis
Karolina Muszyńska
2a. Object Diagrams – they are similar to class diagrams but instead of depicting object
classes they model actual object instances.
3. Sequence Diagrams – they graphically depict how objects interact with each other via
messages in the execution of a use case or operation. They illustrate how messages are
sent and received between objects and in what sequence.
3a. Collaboration Diagrams – they are similar to sequence diagrams but instead of
focusing on timing and sequence of messages they present the interaction between
objects in a network format.
4. State Diagrams – they are used to model the dynamic behavior of a particular object.
They illustrate an object’s life cycle – the various states that an object can assume and
the events that cause the object to transition from one state to another.
5. Activity Diagrams – they are used to graphically depict the sequential flow of
activities of either a business process or a use case.
6. Component Diagrams – they are used to graphically depict the physical architecture of
the system.
7. Deployment Diagrams – they describe the physical architecture of the hardware and
software in the system.
Activities performed in object-oriented analysis
There are four general activities when performing object-oriented analysis and they are:
1. Modeling the functions of the system.
2. Finding and identifying the business objects.
3. Organizing the objects and identifying their relationships.
4. Modeling the behavior of the objects.
Ad. 1 Modeling the functions of the system
The approach that is commonly used to model the functional aspects of the system is called
use case modeling.
Use case modeling is the process of modeling a system’s functions in terms of business
events, who initiated the events, and how the system responds to the events.
Use case is a behaviorally related sequence of steps (a scenario), both automated and manual,
for the purpose of completing a single business task.
Use cases are initiated or triggered by external users or systems called actors.
3
Information systems analysis
Karolina Muszyńska
Actor represents anything that needs to interact with the system to exchange information. An
actor is a user, a role, which could be an external system as well as a person.
In many information systems business events are triggered by calendar or the time on a clock.
A system event that is triggered by time is called a temporal event.
Use cases provide the following benefits:
-
as a basis to help identify objects and their high-level relationships and responsibilities
-
a view of system behavior from an external person’s viewpoint,
-
an effective tool for validating requirements,
-
an effective communication tool,
-
as a basis for a test plan,
-
as a basis for a user’s manual.
Steps involved in use case modeling:
a) identify actors and use cases
b) construct a use case model – a diagram used to graphically depict the system scope
and boundaries, which represents the relationships between the actors and use cases
defined for each business subsystem
c) document the use case course of events – only general information about the business
event (typical and alternative courses), which is called requirements use case
d) define the analysis use cases – more information regarding each use case, which
specifies the systems functionality in detail (but without implementation details);
When the use case contains complex functionality we can simplify it by extracting the
more complex steps into their own use cases, which are called extension use cases; an
extension use case can be invoked only by the use case it is extending.
Sometimes there may be use cases performing steps of identical functionality. They can
be than extracted into their own separate use case called an abstract use case. An abstract
use case represents a form of “reuse” and can be used in any other use case that requires
its functionality.
Ad. 2 Finding and identifying the business objects
Steps involved in identifying and finding business objects for object modeling:
a) find the potential objects – the best way is to review each use case to find nouns that
correspond to business entities or events,
b) select the proposed objects –the list of all potential business objects must be cleaned
up by removing: synonyms, nouns outside the scope of system, nouns that are roles
4
Information systems analysis
Karolina Muszyńska
without unique behavior or are external roles, unclear nouns that need focus and nouns
that are really actions or attributes.
Ad. 3 Organizing the objects and identifying their relationships
A class diagram is used to graphically depict the identified objects and their associations and
relationships. On this diagram we also include multiplicity, associations, generalization/
specialization relationships and aggregation relationships.
Steps in constructing class diagram:
a) identify associations and multiplicity – association between two objects/classes is
what on object/class “needs to know” about the other; to help insure that all possible
relationships are identified we can create an object/class matrix,
b) identify generalization/specialization relationships – we should look for all one-to-one
multiplicity relationships between objects because they may be gen/spec relationships
as well as for objects that have common attributes and behaviors,
c) identify aggregation relationships – we must remember that aggregation relationships
do not imply inheritance (the object, which is the part of another object does not
inherit behavior or attributes from the whole object), but they propagate behavior
(behavior applied to the whole is automatically applied to the parts),
d) prepare the class diagram
Ad. 4 Modeling the behavior of the objects
All object have state, which is the value of its attributes at one point in time. An object
changes state when something happens or when the value of one of its attributes changes.
This change in state is triggered by an event.
A state diagram models the life cycle of a single object. It depicts the different states an
object can have, the events that cause the object to change state over time and the rules that
govern the object’s transition between states.
State diagrams are not required for all objects. Typically a state diagram is constructed only
for those objects that clearly have identifiable states and complex behavior.
Questions:
1. Name and explain all concepts connected with object modeling.
2. Name the main categories of UML diagrams and describe their purpose.
3. What are the four general activities when performing object-oriented analysis?
5
Information systems analysis
Karolina Muszyńska