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 (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.
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.
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 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?
1
Information systems analysis
Karolina Muszyńska