2007
Q.1 Explain basic characteristics of the object oriented modeling with examples.
Ans. Object-Oriented Modeling, or OOM, is a modeling paradigm mainly used in computer programming. Prior to the rise of OOM, the dominant paradigm was functional programming, which emphasized the use of discreet reusable code blocks that could stand on their own, take variables, perform a function of them, and return values.
The Object-Oriented paradigm assist the programmer to address the complexity of a problem domain by considering the problem not as a set of functions hat can be performed but primarily as a set of related, interacting Objects. The modeling task then is specifying, for a specific context, those Objects (or the Class the Objects belong to), their respective set of Properties and Methods, shared by all objects members of the Class.
As an example, in a model of a Payroll System, a Company is an Object. An Employee is another Object. Employment is a Relationship or Association. An Employee Class (or Object for simplicity) ahs Attributes like Name, Birthdate, etc. The Association itself may be considered as an Object, having Attributes, or qualifiers like Position, etc. An employee Method may be Promote, Raise, etc.
The Model description or Schema may grow in complexity to require a Notation. Many notations has been proposed, based on different paradigms, diverged, and converged in a more popular one known as UML.
Characteristics of Object Oriented Technology
Identity
Classification
Polymorphism
Inheritance
Identity
The term Object Oriented means that we organize the software as a collection of discrete objects. An object is a software package that contains the related data and the procedures. Although objects can be used for any purpose, they are most frequently used to represent real-world objects such as products, customers and sales orders. The basic idea is to define software objects that can interact with each other just as their real world counterparts do, modeling the way a system works and providing a natural foundation of building system to manage that business.
Classification
In principle, packaging data and procedures together makes perfect sense. In practice, it raises an awkward problem. Suppose we have many objects of the same general type- for example a thousand product objects, each of which could report its current price. Any data these objects contained could easily be unique for each object. Stock number, price, storage dimensions, stock on hand, reorder quantity, and any other values would differ from one product to the next. But the methods for dealing with the data might well be the same. Do we have to copy these methods and duplicate them in every object? Capturing these commodities in a single place. That place is called a class. The class acts as a kind of template for objects of similar nature.
Polymorphism
Polymorphism is used to express the fact that the same message can be sent to many different objects and interpreted in different ways by each object. For example, we could send the message “move” to many different kinds of objects. They would all respond to the same messages, but they might do so in very different ways. The move operation will behave differently for a window and differently for a class piece.
Polymoprhism allows client programs to be written based only on the abstract interfaces of the objects which will be manipulated (interface inheritance). This means that future extension in the form of new types of objects is easy, if the new objects conform to the original interface. In particular, with object-oriented polymorphism, the original client program does not event need to be recompiled (only relinked) on order to make sue of new types exhibiting new (but interface-conformant) behavior.
Inheritance
Inheritance is the sharing of attributes and operations among classes on a hierarchical relationship. A class can be defined as a generalized form and then it specialized in a subclass. Each subclass inherits all the properties of its superclass and adds its own properties in it. For example, a car and a bicycle are subclasses of a class road vehicle, as they both inherits all the qualities of a road vehicle and add their own properties to it. Consider types of bank accounts. Figure below shows how both checkingAccount and SavingsAccount classes inherit from the BankAccoun class.
Q.2 Explain major advantages of object oriented modeling..
Ans. A major factor in the invention of Object-Oriented approach is to remove some of the flaws encountered with the procedural approach.
Some benefits for OO approach are:
Faster Development: OOD has long been touted as leading to faster development. Many of the claims of potentially reduced development time are correct in principle, if a bit overstated.
Reuse of Previous work: This is the benefit cited most commonly in literature, particularly in business periodicals. OOD produces software modules that can be plugged into one another, which allows creation of new programs. However, such reuse does not come easily. It takes planning and investment.
Increased Quality: Increases in quality are largely a by-product of this program reuse. If 90% a new application consists of proven, existing components, then only the remaining 10% of the code has to be tested scratch. That observation implies an order-of-magnitude reduction in defects.
Modular Architecture: Object-oriented systems have a natural structure for modular design: objects, subsystems, framework, and so on. Thus, OOD systems are easier to modify. OOD systems can be altered in fundamental ways without ever breaking up since changes are neatly encapsulated. However, nothing in OOD guarantees or requires that the code produced will web modular. The same level of care in design and implementation is required to produce a modular structure in OOD, as it is for any form of software development.
Client/Server Applications: By their very nature, client/server applications involve transmission of messages back and forth over a network, and the object-message paradigm of OOD meshes well the physical and conceptual architecture of client/server applications.
Better Mapping to the Problem Domain: This is a clear winner for OOD, particularly when the project maps to the real world. Whether objects represent customers, machinery, banks, sensors of pieces of paper, they can provide a clean, self-contained implication which fits naturally into human thought processes.
Q.3 Explain the concept of encapsulation with an example. Also, list the benefits it during implementation.
Ans: Encapsulation is the object model concept of including processing or behavior with the object instances defined by the class. Encapsulation allows code and data to be packaged together. The definition of methods for a class is an integral part of encapsulation. A method is programming code that performs the behavior an object instance can exhibit. Calculating the age of a person would be an example of such behavior. The figure shows a way of looking a encapsulating the age method with an instance object. The code for the age method is “attached” to or encapsulated with the object rather than part of the application.
Ans. A major factor in the invention of Object-Oriented approach is to remove some of the flaws encountered with the procedural approach.
Some benefits for OO approach are:
Faster Development: OOD has long been touted as leading to faster development. Many of the claims of potentially reduced development time are correct in principle, if a bit overstated.
Reuse of Previous work: This is the benefit cited most commonly in literature, particularly in business periodicals. OOD produces software modules that can be plugged into one another, which allows creation of new programs. However, such reuse does not come easily. It takes planning and investment.
Increased Quality: Increases in quality are largely a by-product of this program reuse. If 90% a new application consists of proven, existing components, then only the remaining 10% of the code has to be tested scratch. That observation implies an order-of-magnitude reduction in defects.
Modular Architecture: Object-oriented systems have a natural structure for modular design: objects, subsystems, framework, and so on. Thus, OOD systems are easier to modify. OOD systems can be altered in fundamental ways without ever breaking up since changes are neatly encapsulated. However, nothing in OOD guarantees or requires that the code produced will web modular. The same level of care in design and implementation is required to produce a modular structure in OOD, as it is for any form of software development.
Client/Server Applications: By their very nature, client/server applications involve transmission of messages back and forth over a network, and the object-message paradigm of OOD meshes well the physical and conceptual architecture of client/server applications.
Better Mapping to the Problem Domain: This is a clear winner for OOD, particularly when the project maps to the real world. Whether objects represent customers, machinery, banks, sensors of pieces of paper, they can provide a clean, self-contained implication which fits naturally into human thought processes.
Q.3 Explain the concept of encapsulation with an example. Also, list the benefits it during implementation.
Ans: Encapsulation is the object model concept of including processing or behavior with the object instances defined by the class. Encapsulation allows code and data to be packaged together. The definition of methods for a class is an integral part of encapsulation. A method is programming code that performs the behavior an object instance can exhibit. Calculating the age of a person would be an example of such behavior. The figure shows a way of looking a encapsulating the age method with an instance object. The code for the age method is “attached” to or encapsulated with the object rather than part of the application.
The notation for object model encapsulation is shown below. Methods are shown at the bottom of the class notation.
Code and data were not always packaged together. At one time, for example, it was necessary to define an age calculation in each application or have a library that contained the age calculation routine. Having an age calculation or any routine, replicated in many applications may make it difficult to ensure that a change in the routine was made everywhere that it is used. Using a library improves this situation if use of the library is enforced. Nevertheless, with a library, you can never be sure which routine is supposed to be used with which data. It is entirely possible to execute the right code on the wrong data or the wrong code on the right data.
Object system recognize which methods belong to which data. You cannot execute the right method on the wrong data as you could with library systems. The correct execution of methods is called dispatching, and it is handled by the object system.
Importance and benefits
Encapsulation is critical to building large complex software which can be maintained and extended. Many studies have shown that the greatest cost in software is not the initial development, but the thousands of hours spent in maintaining the software Well encapsulated components are far easier to maintain.
Once software is in place, another great expense is extending its functionally. As you add new features, there is risk that you’ll break existing parts of the application. Again, encapsulation helps to minimize this risk.
In a well designed program, each object should have a single area of responsibility. That object presents an interface which defines the services the object provides.
Your object promises to provide certain services and to provide certain information. You, as author of the object, publish an interface and say, in essence, “Here is how you interact with my object. If you make these function calls, I promise to provide valid information in this format or to take these actions.”
It is common for an object to offer interfaces based on the privileges of the client class. For example, one client might be allowed only a subset of the possible operations on your new object. In addition, an object might offer a second interface to accommodate updates and changes to the object without breaking old client code. That is, older clients use the old interface, but newer clients can use the newer and updated interface.
The two main advantages of encapsulation are:
The data structure that represents the state can be re-implemented without affecting the implementation of the other objects. For example if the state of a point is represented internally with Cartesian coordinates then this might be changed to Polar coordinates without changing the interface of the object, i.e., without changing which messages with which arguments are understood by the object and what the type of the result of these messages will be. The state of the object can be guarded by the methods. The data structure that represents the state of the object may allow certain values that are not considered meaningful, e.g., a percentage ma be represented by an integer that allows numbers larger than 100. The methods that update this integer can then ensure that it never rises above 100. Many languages allow the programmer to bypass encapsulation, or to specify varying degrees of encapsulation for specific object types. In Java, for example, a class might be defined like this:
Class Cow extends Mammal {
public Tail m_tail;
private Horns m_horns;
public void eat(Food f) {
super.eat(f);
chewcud ();
}
private void chewcud ()
}
}
With the Cow type as defined above, some piece of code external to Cow’s implementation would be allowed to access m_tail directly, without going through any of the methods that Cow has chosen to expose as its interface. Such code would not, however, be able to access m_horns. Likewise, the method eat() is exposed as part of the Cow’s interface, so any other object would be able to cause the cow object to eat by calling that method, passing it the offered food item as an argument to the method. External code would not be able to directly cause the cow to call its chewcud ()method (nor would it even know such a method existed; only the cow itself knows or cares that eating involves chewing its cud).
Q.4 What is object modeling? Explain how objects and classes are identified with an example.
Ans: The object model describes the structure of the objects in the system – their identity, their relationship to other objects, their attributes, and their operations. The object model depicts the primary view of how the real world in which the system interacts is divided and the overall decomposition of the system. The object model provides the framework into which the other models are placed.
The object model is represented graphically with object class diagrams containing the object classes and their relationships. Each application-domain concept from the real world that is important to the application should be modeled as an object class. Classes are arranged into hierarchies sharing common structure and behavior and are associated with other classes. Classes define the attributes carried by each object instance and the operations that each object performs or undergoes.
The object class diagram should adhere to OMT’s notation and exploit the capabilities of OMT, such as links and vasodilatations, inheritance (generalization and specialization), and aggregation. The attributes and operations need not be included in this diagram, as they will be described below in the object class specification.
Elements of an Object Model
Object classes with attributes, relations and connections.
Attributes
Relations
Connection
Generalization/specialization
Aggregation
Classes with constraints no their environment
Behavior associated with an object model
Localization
The activity of establishing an object model consists of going through all the elements of an object model.
Objects
The purpose of object modeling is to describe objects. For example, Joe Smith, Simplex company, and the top window are objects. An object is simply something that makes sense in an application context. Objects serves two purposes: they promote understanding of the real world and provide a practical basis for computer implementation. Decomposition fo a problem into objects depends on judgments and the nature of the problem. There is no one correct representation.
All objects have identity and are distinguishable. Two apples with the same color, shape and texture are still individual apples; a person can eat one and then eat the other.
Classes
An object class describes group with similar properties, common behavior, common relationships to other objects, and common semantics, company, animal, process, and window are all object classes. Ach person has an age, IQ, and may work at a job. Ac process has an owner, priority, and list of required resources. Objects and object classes often appear as nouns in problem description.
The object in class share a common semantic purpose, above and beyond the requirement of common attributes and behavior. Each object knows its class.
A simple class diagram is shown below:
Object system recognize which methods belong to which data. You cannot execute the right method on the wrong data as you could with library systems. The correct execution of methods is called dispatching, and it is handled by the object system.
Importance and benefits
Encapsulation is critical to building large complex software which can be maintained and extended. Many studies have shown that the greatest cost in software is not the initial development, but the thousands of hours spent in maintaining the software Well encapsulated components are far easier to maintain.
Once software is in place, another great expense is extending its functionally. As you add new features, there is risk that you’ll break existing parts of the application. Again, encapsulation helps to minimize this risk.
In a well designed program, each object should have a single area of responsibility. That object presents an interface which defines the services the object provides.
Your object promises to provide certain services and to provide certain information. You, as author of the object, publish an interface and say, in essence, “Here is how you interact with my object. If you make these function calls, I promise to provide valid information in this format or to take these actions.”
It is common for an object to offer interfaces based on the privileges of the client class. For example, one client might be allowed only a subset of the possible operations on your new object. In addition, an object might offer a second interface to accommodate updates and changes to the object without breaking old client code. That is, older clients use the old interface, but newer clients can use the newer and updated interface.
The two main advantages of encapsulation are:
The data structure that represents the state can be re-implemented without affecting the implementation of the other objects. For example if the state of a point is represented internally with Cartesian coordinates then this might be changed to Polar coordinates without changing the interface of the object, i.e., without changing which messages with which arguments are understood by the object and what the type of the result of these messages will be. The state of the object can be guarded by the methods. The data structure that represents the state of the object may allow certain values that are not considered meaningful, e.g., a percentage ma be represented by an integer that allows numbers larger than 100. The methods that update this integer can then ensure that it never rises above 100. Many languages allow the programmer to bypass encapsulation, or to specify varying degrees of encapsulation for specific object types. In Java, for example, a class might be defined like this:
Class Cow extends Mammal {
public Tail m_tail;
private Horns m_horns;
public void eat(Food f) {
super.eat(f);
chewcud ();
}
private void chewcud ()
}
}
With the Cow type as defined above, some piece of code external to Cow’s implementation would be allowed to access m_tail directly, without going through any of the methods that Cow has chosen to expose as its interface. Such code would not, however, be able to access m_horns. Likewise, the method eat() is exposed as part of the Cow’s interface, so any other object would be able to cause the cow object to eat by calling that method, passing it the offered food item as an argument to the method. External code would not be able to directly cause the cow to call its chewcud ()method (nor would it even know such a method existed; only the cow itself knows or cares that eating involves chewing its cud).
Q.4 What is object modeling? Explain how objects and classes are identified with an example.
Ans: The object model describes the structure of the objects in the system – their identity, their relationship to other objects, their attributes, and their operations. The object model depicts the primary view of how the real world in which the system interacts is divided and the overall decomposition of the system. The object model provides the framework into which the other models are placed.
The object model is represented graphically with object class diagrams containing the object classes and their relationships. Each application-domain concept from the real world that is important to the application should be modeled as an object class. Classes are arranged into hierarchies sharing common structure and behavior and are associated with other classes. Classes define the attributes carried by each object instance and the operations that each object performs or undergoes.
The object class diagram should adhere to OMT’s notation and exploit the capabilities of OMT, such as links and vasodilatations, inheritance (generalization and specialization), and aggregation. The attributes and operations need not be included in this diagram, as they will be described below in the object class specification.
Elements of an Object Model
Object classes with attributes, relations and connections.
Attributes
Relations
Connection
Generalization/specialization
Aggregation
Classes with constraints no their environment
Behavior associated with an object model
Localization
The activity of establishing an object model consists of going through all the elements of an object model.
Objects
The purpose of object modeling is to describe objects. For example, Joe Smith, Simplex company, and the top window are objects. An object is simply something that makes sense in an application context. Objects serves two purposes: they promote understanding of the real world and provide a practical basis for computer implementation. Decomposition fo a problem into objects depends on judgments and the nature of the problem. There is no one correct representation.
All objects have identity and are distinguishable. Two apples with the same color, shape and texture are still individual apples; a person can eat one and then eat the other.
Classes
An object class describes group with similar properties, common behavior, common relationships to other objects, and common semantics, company, animal, process, and window are all object classes. Ach person has an age, IQ, and may work at a job. Ac process has an owner, priority, and list of required resources. Objects and object classes often appear as nouns in problem description.
The object in class share a common semantic purpose, above and beyond the requirement of common attributes and behavior. Each object knows its class.
A simple class diagram is shown below:
Identifying Objects (and Class)
Identify the nouns( objects) in the problem description.
Identify more objects in your developing problem solution.
From these objects, determine what new types (classes) you need.
Example: Black Jack Program
Cards
A deck
A dealer
Player(s)
Sample Design Questions:
Are the dealer and player instances of the same class? i.e., objects of the same type?
Should there be a separate Hand class?
Q.5 What is state diagram? Differentiate between a simple state diagram and a composite state diagram with an example.
Ans. State diagrams (also called State Chart diagram) are used to help the developer better understand any complex/unusual functionalities or business flows of specialized areas of the system. In short, State diagrams depict the dynamic behavior of the entire system, or a sub-system, or even a single object in a system. This is done with help of Behavioral elements.
Elements of a State diagram
Initial state: This shows the starting point or first activity of the flow. Denoted by a solid circle. This is also called as a “pseudo state,” where the state has no variables describing it further and no activities.
State: Represents the state of object at an instant of time. In a state diagram, there will be multiple of such symbols, one for each state of the Object we are discussing. Denoted by a rectangle with rounded corners and compartments (such as a class with rounded corners to denote an Object).
Transition: An arrow indicating the Object to transition from one state to the other. The actual trigger event and action causing the transition are written beside the arrow, separated by a slash. Transition that occur because the state completed and activity are called “triggerless” transitions. If an event has to occur after the completion of some event or action, the event or action is called the guard condition. The transition takes place after the guard condition. The transition takes place after the guard condition occurs. This guard condition/event/action is depicted by square brackets around the description of the event/action.
History States: A flow may require that the object go to occur is called as an event or action. Every transition need not occur due to the occurrence of an event or action directly related to the state that transitioned from one state to another.
Final State: the end of the state diagram is shown by a bull’s eye symbol also called a final state. A final state is another example of a pseudo state because it does not have any variable or action described.
Simple Set
A simple state is a state that does not have substates, i.e. it has no regions and it has no submachine state machine.
Identify the nouns( objects) in the problem description.
Identify more objects in your developing problem solution.
From these objects, determine what new types (classes) you need.
Example: Black Jack Program
Cards
A deck
A dealer
Player(s)
Sample Design Questions:
Are the dealer and player instances of the same class? i.e., objects of the same type?
Should there be a separate Hand class?
Q.5 What is state diagram? Differentiate between a simple state diagram and a composite state diagram with an example.
Ans. State diagrams (also called State Chart diagram) are used to help the developer better understand any complex/unusual functionalities or business flows of specialized areas of the system. In short, State diagrams depict the dynamic behavior of the entire system, or a sub-system, or even a single object in a system. This is done with help of Behavioral elements.
Elements of a State diagram
Initial state: This shows the starting point or first activity of the flow. Denoted by a solid circle. This is also called as a “pseudo state,” where the state has no variables describing it further and no activities.
State: Represents the state of object at an instant of time. In a state diagram, there will be multiple of such symbols, one for each state of the Object we are discussing. Denoted by a rectangle with rounded corners and compartments (such as a class with rounded corners to denote an Object).
Transition: An arrow indicating the Object to transition from one state to the other. The actual trigger event and action causing the transition are written beside the arrow, separated by a slash. Transition that occur because the state completed and activity are called “triggerless” transitions. If an event has to occur after the completion of some event or action, the event or action is called the guard condition. The transition takes place after the guard condition. The transition takes place after the guard condition occurs. This guard condition/event/action is depicted by square brackets around the description of the event/action.
History States: A flow may require that the object go to occur is called as an event or action. Every transition need not occur due to the occurrence of an event or action directly related to the state that transitioned from one state to another.
Final State: the end of the state diagram is shown by a bull’s eye symbol also called a final state. A final state is another example of a pseudo state because it does not have any variable or action described.
Simple Set
A simple state is a state that does not have substates, i.e. it has no regions and it has no submachine state machine.
Q.6 (a) What is Unidirectional implementations? Explain how it is different from Bi-directional implementation.
Ans. Associations represent relationships between instances of types (a person works for a company, a company has a number of offices…). The interpretation of them varies with the perspective. Conceptually they represent conceptual relationships between the types involved. In specification these are responsibilities for knowing, and will be made explicit by access and update operations. This may mean that a pointer exists between order and customer, but that is hidden by encapsulation. A more implementation interpretation implies the presence of a pointer. Thus it is essential to know what perspective is used to build a model in order to interpret it correctly.
Associations may be bi-directional (Can be navigated in either direction) or unidirectional (can be navigated in one direction only). Conceptually all associations can be thought of a bi-directional, but unidirectional associations are important for specification and implementation models. For coupling. IN implementation models a bi-directional association implies coupled sets of pointers, which many designers find difficult to deal with.
Undirectional one-to-one associations
The simplest type of association to realize is unidirectional one-to-one association between two classes.
With a unidirectional association, you can navigate from one class to another (As indicated by the direction of the arrow) but not vice-versa.
It is conveniently implemented using a reference.
Ans. Associations represent relationships between instances of types (a person works for a company, a company has a number of offices…). The interpretation of them varies with the perspective. Conceptually they represent conceptual relationships between the types involved. In specification these are responsibilities for knowing, and will be made explicit by access and update operations. This may mean that a pointer exists between order and customer, but that is hidden by encapsulation. A more implementation interpretation implies the presence of a pointer. Thus it is essential to know what perspective is used to build a model in order to interpret it correctly.
Associations may be bi-directional (Can be navigated in either direction) or unidirectional (can be navigated in one direction only). Conceptually all associations can be thought of a bi-directional, but unidirectional associations are important for specification and implementation models. For coupling. IN implementation models a bi-directional association implies coupled sets of pointers, which many designers find difficult to deal with.
Undirectional one-to-one associations
The simplest type of association to realize is unidirectional one-to-one association between two classes.
With a unidirectional association, you can navigate from one class to another (As indicated by the direction of the arrow) but not vice-versa.
It is conveniently implemented using a reference.
picture
Bi-directional one-to-one associations
The following diagram indicates a bi-directional association no arrows on any end of the association
The following diagram indicates a bi-directional association no arrows on any end of the association
picture
It indicates that we must be able to navigate from an account to the corresponding customer and vice versa. There are three approaches to bi-directional implementation:
Implement as an attribute in one direction only and perform a search when a backward traversal is required.
Implement as attributes in both directions.
Implement as a distinct association object, independent of either class.
(b) Explain the concept of collaboration with example.
Ans. An object-oriented system is composed of objects. The behavior of the system is achieved through collaboration between these objects, and the state of the objects in it. Collaboration between objects involves then sending messages to each other. The exact semantics of message sending between objects varies depending on what kind of system is being modeled.
Collaboration diagrams (interaction diagrams) illustrate the relationship and interaction between software objects. They require use cases, system operation contracts, and domain model to already (instances). A diagram is created for each system operation that relates t the current development cycle (iteration).
Notation
Object: Objects are instances of classes, and are one of the entity types that can be involved in communications. An Object is drawn as a rectangular box, with the class name inside prefixed with the object name (optional) and a semi-colon.
Object 1
Actor: Actors can also communicate with Objects, so they too can be listed on Collaboration diagrams. An Actor is depicted by a stick figure.
Actor1
Message: Message, modeled as arrows between objects, and labeled with an ordering number, indicate the communications between objects.
Message
Here is an example of an Administrator using a Web Application to manage a user account. Notice how you can follow the process from object to object, according to the outline below:
Find User
1.1 LookUp User
Update User
2.1 Validate user
2.2 Update user
Web App:
User Interface
2.2 Update User
User DB
User Validator
2.1 Validator
1. Find User
2. Update User
1.1 Look UpUser
Implement as an attribute in one direction only and perform a search when a backward traversal is required.
Implement as attributes in both directions.
Implement as a distinct association object, independent of either class.
(b) Explain the concept of collaboration with example.
Ans. An object-oriented system is composed of objects. The behavior of the system is achieved through collaboration between these objects, and the state of the objects in it. Collaboration between objects involves then sending messages to each other. The exact semantics of message sending between objects varies depending on what kind of system is being modeled.
Collaboration diagrams (interaction diagrams) illustrate the relationship and interaction between software objects. They require use cases, system operation contracts, and domain model to already (instances). A diagram is created for each system operation that relates t the current development cycle (iteration).
Notation
Object: Objects are instances of classes, and are one of the entity types that can be involved in communications. An Object is drawn as a rectangular box, with the class name inside prefixed with the object name (optional) and a semi-colon.
Object 1
Actor: Actors can also communicate with Objects, so they too can be listed on Collaboration diagrams. An Actor is depicted by a stick figure.
Actor1
Message: Message, modeled as arrows between objects, and labeled with an ordering number, indicate the communications between objects.
Message
Here is an example of an Administrator using a Web Application to manage a user account. Notice how you can follow the process from object to object, according to the outline below:
Find User
1.1 LookUp User
Update User
2.1 Validate user
2.2 Update user
Web App:
User Interface
2.2 Update User
User DB
User Validator
2.1 Validator
1. Find User
2. Update User
1.1 Look UpUser
No comments:
Post a Comment