Presentation is loading. Please wait.

Presentation is loading. Please wait.

An Introduction to Object Modeling

Similar presentations


Presentation on theme: "An Introduction to Object Modeling"— Presentation transcript:

1 An Introduction to Object Modeling
The approach of using object modeling during systems analysis and design is called object-oriented analysis. Object-oriented analysis (OOA) techniques are used to (1) study existing objects to see if they can be reused or adapted for new uses, and to (2) define new or modified objects that will be combined with existing objects into a useful business computing application. The object-oriented approach is centered around a technique referred to as object modeling. Object modeling is a technique for identifying objects within the systems environment, and the relationships between those objects. 286 In earlier chapters you were introduced to activities that called for drawing system models. You learned that system models play an important role in systems development by providing a means for dealing with unstructured problems. This chapter will present object modeling during systems analysis as a technique for defining business requirements for a new system. Object-oriented analysis techniques are best suited to projects that will implement systems using emerging object technologies to construct, manage, and assemble those objects into useful computer applications.

2 System Concepts for Object Modeling
Objects, Attributes, Methods, and Encapsulation The object-oriented approach to system development is based on the concept of objects that exist within a system’s environment. Objects are everywhere Webster’s Dictionary definition of an object. Something that is or is capable of being seen, touched, or otherwise sensed. In object-oriented approaches to systems development the definition of an object is as follows: An object is something that is or is capable of being seen, touched, or otherwise sensed, and about which users store data and associate behavior. There are several concepts that object-oriented analysis is based on. Some of these concepts require a totally new way of thinking about systems and the development process. These concepts have presented a formidable challenge to veteran developers who must relearn how they have traditionally viewed systems. Let’s consider your environment, look around. What are some of the objects present within your environment? Perhaps you see a door, a window, or the room itself. What about this book it’s an object, and so is the very page you are reading. And of course, don’t forget about you, you are an object. Clearly the objects mentioned earlier were those that one would be able to see or touch. But what about objects that you might sense? Perhaps you are waiting on a phone call. That phone call is something that you are sensing. You may be waiting on a meeting. Once again, that meeting is something that you can identify, relate to, and anticipate even though you can’t actually see that meeting. Thus, according to Webster’s Dictionary an anticipated phone call or meeting may be concerned an object. The previous examples pertained to objects that may exist within your immediate environment. Similarly, in object-oriented approach to systems development, it is important to identify those objects that exist within a system’s environment. But in object-oriented approaches, objects are considered as being something much more than simply “something that is or is capable of being seen, touched, or otherwise sensed”.

3 System Concepts for Object Modeling
Objects, Attributes, Methods, and Encapsulation The types of objects may include a person, place, thing, or event. An employee, customer, vendor, and student are examples of person objects. A particular warehouse, regional office, building, and room are examples of place objects. A product, vehicle, equipment, video tape, or a window appearing on a users display monitor are examples of thing objects. An order, payment, invoice, application, registration, and reservation are examples of event objects. 287 There’s three portions to the object definition that need to be examined closely. First, let’s consider the term “something”. That something can be characterized as a type of object much like the objects that we identified within your current environment.

4 System Concepts for Object Modeling
Objects, Attributes, Methods, and Encapsulation In the object-oriented circles, the term “data” refers to what are called attributes. Attributes are the data that represent characteristics of interest about an object. Example attributes for the person object called customer: CUSTOMER NUMBER, FIRST NAME, LAST NAME, HOME ADDRESS, WORK ADDRESS, TYPE OF CUSTOMER, HOME PHONE, WORK PHONE, CREDIT LIMIT, AVAILABLE CREDIT, ACCOUNT BALANCE, and ACCOUNT STATUS. Each individual customer object is referred to as an object instance. An instance (or object instance) of an object consists of the values for the attributes that describe a specific person, place, thing, or event. 287 Considering the “data” portion of the object definition. For example, for each customer the attributes would assume values specific to that customer such as , Lonnie, Bentley, 2626 Darwin Drive, West Lafayette, Indiana, 47906, and so forth. Let’s consider your current environment. Perhaps there’s another person in the room. Each of you represents an instance of a person object. Each of you can be described according to some common attributes such as LAST NAME, SOCIAL SECURITY NUMBER, PHONE NUMBER, and ADDRESS. But each of you can be described in terms of your own last name, social security number, phone number, and address. Object-oriented approaches to systems development is concerned with identifying attributes that are of interest regarding an object. It is important to note that with advances in technology, attributes have evolved to include more than simple data characteristics as represented in the previous example. Today, objects may include newer attribute types, such as a bitmap or a picture sound, or even video.

5 System Concepts for Object Modeling
Objects, Attributes, Methods, and Encapsulation What is the “behavior” of an object. Behavior refers to those things that the object can do and which correspond to functions that act on the object’s data (or attributes). In object-oriented circles, an object’s behavior is commonly referred to as a method or service. An object is solely responsible for carrying out any functions or behaviors that act upon its own data (or attributes). For example, only YOU (an object) may CHANGE (behavior) your LAST NAME and HOME ADDRESS (attributes about you). This represents a substantially different way of viewing objects! When you look at the “door” object within your environment, you may simply see an motionless object that is incapable of thinking much less carrying out some action. In object-oriented approaches to systems development, that door is can be associated with behavior that it is assumed it can be perform. For example, the door can open, it can shut, it can lock, or it can unlock. All of these behaviors are associated with the door and are accomplished by the door and no other object. Let’s consider the phone object. What are some of the behaviors that could be associated with a phone? With advances in technology we actually have phones that are voice activated and can ANSWER, DIAL, HANG UP, and carry out other behaviors that can be associated with a phone. Thus, object-oriented approaches to systems development simply requires an adjustment to how we commonly perceive objects.

6 System Concepts for Object Modeling
Objects, Attributes, Methods, and Encapsulation Encapsulation, an important concept. Encapsulation is the packaging of several items together into one unit. Both attributes and behavior of the object are packaged together. The only way to access an object's attributes is through that object’s behaviors. No other object may perform that object’s behavior. 288 No additional notes provided.

7 System Concepts for Object Modeling
Classes, Generalization, and Specialization An important concept of object modeling is the concept of categorizing objects into classes. A class is a set of objects that share common attributes and behavior. A class is sometimes referred to as an object class. For example, textbook and workbook objects represent thing-objects that have some similar attributes and behavior and could be classified as BOOKs . A class may also have sub-classes of objects. For example, STUDENT and TEACHER object classes could be members of the class PERSON. 288 No additional notes provided.

8 System Concepts for Object Modeling
Classes, Generalization, and Specialization When levels of classes are identified, the concept of inheritance is applied. Inheritance means that methods and/or attributes defined in an object class can be inherited or reused by another object class. The approach that seeks to discover and exploit the commonalties between objects/classes is referred to as generalization/specialization. Generalization/specialization is a technique wherein the attributes and behaviors that are common to several types of an object classes are grouped into their own class, called a supertype. The attributes and methods of the supertype object class are then inherited by those object classes. 288 No additional notes provided.

9 System Concepts for Object Modeling
Classes, Generalization, and Specialization When levels of classes are identified, the concept of inheritance is applied. Inheritance means that methods and/or attributes defined in an object class can be inherited or reused by another object class. In the object class PERSON, STUDENT and TEACHER example, PERSON is referred to as a supertype (or generalization class) whereas STUDENT and TEACHER are referred to as subtypes (or specialization class). A class supertype is an entity whose instances store attributes that are common to one or more class subtypes. A class subtype is an object class whose instances inherit some common attributes from a class supertype, and then add other attributes that are unique to an instances of the subtype. No additional notes provided.

10 System Concepts for Object Modeling
Classes, Generalization, and Specialization The class supertype will have one or more one-to-one relationships to object class subtypes. These relationships are sometimes called “IS A” relationships (or “WAS A”, or “COULD BE A”) because each instance of the supertype “is also an” instance of one or more subtypes. Using OMT notation, classes are represented on an object model as a rectangle. The rectangle is divided into three portions. The top portion contains the name of the class. The middle portion contains the name of the common attributes of interest. The lower portion contains the common behavior (or methods). In object-oriented systems development, objects are categorized according to classes and sub-classes. By identifying classes there are numerous benefits to be realized. For example, consider the fact that a new attribute of interest, called gender, needs to be added to teacher and student objects. Since the attribute is common to both, the attribute could be added once, with the class person implying both objects within its class share that attribute. Looking down the road toward program maintenance, the implication is substantial. Program maintenance is enhanced by the need to simply make modifications in one place.

11 288-290 Figure 8.1 Objects and Classes
In object-oriented development, models depicting objects are often drawn. The figure (a) above depicts the symbol for representing an object using the OMT modeling notation. An object is represented using a rounded rectangle. The attribute values for the object instance are optionally recorded within the symbol. Near the top of the rounded rectangle, the name of class in which the object has been categorized appears within parenthesis. In figure (b) above, the textbook and workbook objects represent thing-objects that have some similar attributes and behavior. For example, similar attributes might be ISBN NUMBER, TYPE OF BOOK, TITLE, COPYRIGHT DATE, etc. Likewise, they have similar behavior, such as being able to OPEN and CLOSE. In figure (c) above, some of the individuals might be classified as STUDENTs and others as TEACHERs. Thus, STUDENT and TEACHER object classes are members of the class PERSON. As depicted in figure (d) above, a class is represented using a rectangle divided into three portions.

12 290 Figure 8.2 Supertype and Subtype Relationships Between Object Classes The figure above illustrates how to depict the supertype, subtype relationship between the PERSON, STUDENT, and TEACHER object classes. All the attributes and behaviors of the PERSON object are inherited by the STUDENT and TEACHER objects. Those attributes and behaviors that are uniquely apply to a STUDENT or TEACHER are recorded directly in the subtype class symbol.

13 System Concepts for Object Modeling
Object/Class Relationships Objects and classes do not exist in isolation. The things they represent interact with, and impact one another to support the business mission. Thus there is an object/class relationship. An object/class relationship is a natural business association that exists between one or more objects/classes. For example, consider the object classes customer and order that may exist in a typical information system and how they interact. a CUSTOMER PLACES zero or more ORDERs an ORDER IS PLACED BY one and only one CUSTOMERs . No additional notes provided.

14 System Concepts for Object Modeling
Object/Class Relationships We graphically illustrate the association(relationship) between two classes as a connecting line. A verb phrase describes the relationship. All relationships are implicitly bi-directional, meaning that they can interpreted in both directions. What is multiplicity? Multiplicity defines the minimum and maximum number of occurrences of one object/class for a single occurrence of the related object/class. Because all relationships are bi-directional, multiplicity must be defined in both directions for every relationship. . No additional notes provided.

15 291 Figure 8.3 Object/Class Relationships and Multiplicity Notations
The figure (a) above graphically illustrates the association between CUSTOMER and ORDER. The connecting line represents a relationship between the classes. The verb phrase describes the relationship. Notice that all relationships are implicitly bi-directional, meaning that they can interpreted in both directions. The figure (a) above also shows the complexity or degree of each relationship. For example, in the above business assertions, we must also answer the following questions: Must there exist an instance of CUSTOMER for each instance of ORDER? Yes! Must there exist an instance of ORDER for each instance of CUSTOMER? No! How many instances of ORDER can exist for each instance of CUSTOMER? Many! How many instances of CUSTOMER can exist for each instance of ORDER? One! The possible OMT graphical notation for multiplicity between classes is shown in the figure (b) above.

16 System Concepts for Object Modeling
Object/Class Relationships What are aggregation class relationships? Sometimes objects/classes are made up of other objects/classes. This type of relationship is called aggregation. It is also sometimes referred to as “whole-part” or “part-of” relationships. For example, the TEXTBOOK object may contain several objects, including: COVER, TABLE OF CONTENTS, CHAPTER, and INDEX objects. The CHAPTER object contains PAGE objects, which in turn contain PARAGRAPH objects, which in turn contain WORD objects, and so forth. 292 . No additional notes provided.

17 System Concepts for Object Modeling
Object/Class Relationships By identifying aggregation relationships we can partition a very complex object and assign behaviors and attributes to the individual objects within it. Multiplicity is also specified for aggregate relationships. 292 . No additional notes provided.

18 292 Figure 8.4 Aggregate Relationships
The figure above depicts the OMT graphical notation for specifying aggregate relationships among object classes. Notice that multiplicity is also specified for aggregate relationships. For example, A BOOK is composed of one and only one COVER, zero or one TABLE OF CONTENTs, one or more CHAPTERs, and zero or one INDEX. Figure 8.4 also depicts multilevel aggregation wherein CHAPTER is consists of one or more PAGES, PAGES consists of zero or more PARAGRAPHS, and so forth.

19 System Concepts for Object Modeling
Messages and Message Sending Objects/Classes interact or "communicate" with one another by passing messages. A message is passed when one object invokes another object's method (behavior) to request information or some action An object sending a message does not need to know how the receiving object is organized internally or how the behavior is to be accomplished, only that it responds to the request in a well-defined way. 293 . Recall the concept of encapsulation wherein an object is a package of attributes and behavior. Only that object can perform its behavior and act upon its data. That, if you want to secure the room that you are sitting in, the door object must carry out the following behaviors: close and lock . Thus, if you (an object) want the room to become secure, must send a message to the door (an object) requesting it to complete those behaviors. Let’s consider out customer and order objects mentioned earlier. A customer object checking the current status of an order, sends a message to an order object by invoking the order object's “display status” behavior (a behavior that acts upon the order status attribute).

20 292 Figure 8.5 Messaging The concept of messaging is illustrated in the figure above . While some object oriented approaches show messaging on their object models, the OMT chooses not to depict messaging. Rather, the OMT approach use a variation upon the data flow diagram to document messaging.

21 System Concepts for Object Modeling
Messages and Message Sending Polymorphism - What is it? Polymorphism means “many forms”. Applied to object-oriented techniques, it means that a behavior may be completed differently for different objects/classes. The requesting object knows the what service (or behavior) to request and from which object. However, the requesting object does not need to worry about how a behavior is accomplished. 293 . Let’s consider the window and door object within your environment. Both objects have a common behavior that they may perform - close. But how a door object carries out that behavior may differ substantially from the way in which a window carries out that behavior. A door “swings shut” windows “slide downward”. Thus, a the behavior close may take on two different forms. Once again, let’s consider the window object. Not all windows would actually accomplish the close behavior in the same way. Some windows objects like door objects, swing shut! Thus, the close behavior takes on different forms for a given object class.

22 The Process of Object Modeling
Performing Object Oriented Analysis (OOA) The purpose of OOA is to gain a better understanding of the system and its functional requirements. OOA requires that we identify the objects, their data attributes, associated behavior, and relationships which support the required business system functionality. We perform object modeling to document the identified objects, the data and behavior they encapsulate, plus their relationships with other objects. Two general activities when performing object oriented analysis: Finding and identifying the business objects. Organizing the objects and identifying their relationships. 294 . No additional notes provided

23 The Process of Object Modeling
Finding And Identifying The Business Objects In trying to identify objects, many methodology experts recommend the technique of searching the requirements document or other associated documentation and underline the nouns which may represent potential objects. This could be a monumental task! There are just too many nouns. One of the more popular and successful approaches for finding and identifying objects, is a technique called Use Case Modeling developed by Dr. Ivar Jacobson. Use Case Modeling is the process of identifying and modeling business events, who initiated them, and how the system responds to them. 294 . No additional notes provided

24 The Process of Object Modeling
Finding And Identifying The Business Objects Use case modeling breaks down the entire scope of system functionality into many smaller statements of system functionality called use cases or business events. A use case a behaviorally related sequence of steps (a scenario), both automated and manual for the purpose of completing a single business task. This smaller format simplifies and makes more efficient the technique of underlining the nouns. It identifies and describes the system functions from the perspective of external users. 294 . No additional notes provided

25 The Process of Object Modeling
Finding And Identifying The Business Objects Use Cases are initiated by users or systems called Actors. An 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. An actor initiates system activity, a use case, for the purpose of completing some business task. An actor represents a role fulfilled by a user interacting with the system and is not meant to portray a single individual or job title. For events that are triggered by time called temporal events, the actor is the system itself. 294 . Let’s use the example of a college student enrolling for the fall semester’s courses. The actor would be the student and the business event or use case, would be enrolling in course. What about events that are triggered by time called temporal events? Who would be the actor? In the case of temporal events, the actor is the system itself. For example, on a nightly basis a report is automatically generated listing which courses have been closed to enrollment (no open seats available) and which courses are still open. Notice that the report automatically gets generated every night, no one has to request that it to be generated. This is a temporal event. The actor for this temporal event is the system itself.

26 The Process of Object Modeling
Finding And Identifying The Business Objects 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 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. . Use cases are used during the entire system development process. During analysis, the use cases are used to model functionality of the proposed system and are the starting point for identifying the objects of the system. During the whole development process, use cases are continually refined in parallel with the process designing the objects. Because use cases contain an enormous amount of system functionality detail, they will be a constant resource for validating and testing the development of the system design. There are many approaches to begin use case modeling to help find and identify potential objects. They include prototyping, user and business analyst interviews, plus countless other fact-finding techniques. Usually it involves a combination of several fact-finding techniques.

27 The Process of Object Modeling
Finding And Identifying The Business Objects Step 1: Identifying Actors and Use Cases. A good place to find potential actors and use cases is by analyzing the context model diagram of the system. If an external party initiates the input, it is considered an actor. Some of the inputs are self explanatory, but others may be misleading, it is always wise to confirm your findings with the system’s business analyst. . No additional notes provided.

28 295-296 Figure 8.6 Member Services System Context Model Diagram
Recall that a system context model illustrates the external parties which interact with the system to provide inputs and receive outputs. In doing so, it identifies the system’s scope and boundaries. The figure above is a context model for the Soundstage Member Services System. Find the external parties which provide inputs to the system. Does the external party initiate the input or is the input a response to a request from the system? If the external party initiates the input, it is considered an actor. Some of the inputs are self explanatory, but others may be misleading, it is always wise to confirm your findings with the system’s business analyst. In the figure above, Club Member is an actor which initiates and provides an input call Promotion order. The sequence of events in which the Member Services System would respond to the club member Submitting a Promotion Order would be considered the use case.

29 296 Figure 8.7 Listing of Actors and Use Cases for Member Services System No additional notes provided.

30 The Process of Object Modeling
Finding And Identifying The Business Objects Step 2: Constructing a Use Case Model A Use Case Model Diagram is used to graphically depict the system scope and boundaries in terms of use cases and actors. The use case model diagram represents the relationships between the actors and use cases defined for each business subsystem. The subsystems represent logical functional areas of business processes. The partitioning of system behavior into subsystems is very important in understanding the system architecture and is very key to defining your development strategy — which use cases will be developed first and by who. 296 . Once all the use cases and actors have been identified, we have defined the total functionality of the entire system.

31 296-297 Figure 8.8 Member Services System Use Case Model Diagram
The use case model diagram for the Member Services System is shown in the figure above. It was created using Popkin Software’s System Architect and represents the relationships between the actors and use cases defined for each business subsystem.

32 The Process of Object Modeling
Finding And Identifying The Business Objects Step 3: Documenting the Use Case Course of Events For each use case identified, use case’s normal course of events must be documented. A use case’s normal course of events is a step by step description starting with the actor initiating the use case until the end of the business event. At this point we only include the major steps which happen the majority of the time (its normal course). Exception conditions or conditional branching logic will be documented in a later step. 296 . No additional notes provided.

33 A B C D E F 296-298 Figure 8.9 Sample Use Case Description
The figure above is a use case description for the Member Services System’s Submit Promotion Order use case. Notice it includes the following items: The name of actor who initiated the use case. A high level description of the use case. A normal event course describing the use case’s major steps, from beginning to end of this interaction with the actor. Pre condition describing the state the system is in before the use case is executed. Post condition describing the state the system is in after the use case is executed. An assumptions section, which includes any non-behavioral issues, such as performance or security, that are associated with the use case, but are difficult to model within the use case’s course of events. D E F

34 The Process of Object Modeling
Finding And Identifying The Business Objects Step 4: Identifying Use Case Dependencies. Some use cases may be dependent on other use cases, with one use case leaving the system in a state that is a precondition for another use case. We use a diagram called the Use Case Dependency Diagram to model dependencies. 297 . For example, a precondition of sending a club promotion is that the promotion must first be created.

35 The Process of Object Modeling
Finding And Identifying The Business Objects Step 4: Identifying Use Case Dependencies. The use case dependency diagram provides the following benefits: A graphical depiction of the system’s events and their states enhances the understanding of system functionality. It helps to identify missing use cases. A use case with a precondition that is not satisfied by the execution of any other use case may indicate a missing use case. Helps facilitate project management by depicting which use cases are more critical (have the most dependencies) and thus need to have a higher priority. 297 . No additional notes provided.

36 297-299 Figure 8.10 Member Services System Use Case Model Diagram
The figure above represents the use case dependency diagram for the Member Services System. The use cases which are dependent on each other are connected with a dashed line labeled depends on. In the above figure, the use case Send Club Promotion has a dependency (pre condition) on either the use case Create New Seasonal Promotion or Create New Monthly Promotion.

37 The Process of Object Modeling
Finding And Identifying The Business Objects Step 5: Documenting the Use Case Alternate Course of Events A use case has one normal event course that was previously defined, and possibly many alternate courses. Alternate courses are deviations or branches, from the normal event course. Alternate courses are documented in a separate use case course. 298 . During the previous steps of use case modeling, we focused on the normal courses of the use cases. This allowed us to concentrate on the system concept without getting bogged down in too many details. At this point the alternate courses and exception conditions in the use cases need to be defined.

38 298-300 Figure 8.11 Sample Use Case Description With Alternate Courses
In the figure above, the use case Submit Promotion Order has several alternate courses. The first alternate course is for step 2 of the normal course. The club member has indicated an address or telephone change on their promotion order. Normally this does occur, that’s why it is documented as an alternate course. The analyst must refine each use case to include such alternate courses.

39 The Process of Object Modeling
Finding And Identifying The Business Objects Step 6: Finding The Potential Objects. This step is accomplished by reviewing each use case to find nouns that correspond to business entities or events. Step 7: Selecting The Proposed Objects. Not all the of the nouns represent good business objects. Remove the nouns that represent: Synonyms Nouns outside the scope of the system Nouns that are roles without unique behavior or are external roles Unclear nouns that need focus Nouns that are really actions or attributes . No additional notes provided.

40 299-301 Figure 8.12 Sample Use Case Description with Nouns Highlighted
The figure above depicts the use case Submit Promotion Order with all the nouns highlighted.

41 299-302 Figure 8.13 Member Services System Potential Object List
Each noun that is found in reviewing the use case is added to a list of potential objects that will be analyzed further.

42 299-302 Figure 8.14 Analyzing The Potential Object List
The figure above shows the process of “cleaning up” our list of candidate objects. An “X” marks the candidates we are discarding and a “check mark” marks the candidates we are keeping as objects. Also listed is the explanation of why we are keeping or discarding the candidate.

43 299-303 Figure 8.15 Member Services System Proposed Object List
The figure above presents the results of our “cleaning up” process, plus we have included other objects we have found on the other use cases.

44 The Process of Object Modeling
Organizing The Objects and Identifying Their Relationships Once the business objects of the system have been identified, it is time to organize those objects and document any major conceptual relationships between the objects. An Object Association Model is used to graphically depict the objects and their relationships. This diagram will also include multiplicity, generalization/specialization relationships and aggregation relationships. 303 . When constructing the diagram, we will use James Rumbaugh’s Object Modeling Technique (OMT), object model notation. Our examples are created with Popkin Software’s System Architect CASE tool.

45 The Process of Object Modeling
Organizing The Objects and Identifying Their Relationships Step 1: Identifying Associations and Multiplicity In this step we need to identify relationships or associations that exists between objects/classes. Recall that a relationship between two objects/classes is what one object/class “needs to know” about the other. Once the relationship have been identified, the multiplicity that governs the relationship must be defined. 303 . It is very important that the analyst not only identify relationships that are obvious or recognized by the users. On way to help ensure that possible relationships are identified is to use a object/class matrix. This matrix lists the objects/class as column headings as well as row headings. The matrix can then be used as a check list to ensure that each object/class appearing on a row is checked against each object/class appearing in a column for possible relationships. The name of the relationship and the multiplicity can be recorded directly in the intersection cell of the matrix.

46 The Process of Object Modeling
Organizing The Objects and Identifying Their Relationships Step 2: Identifying Generalization/Specialization Relationships Generalization/Specialization relationships may be discovered by looking at the object model association diagram. Do any associations exist between two objects that have a one-to-one multiplicity? Can you say the sentence “object X is a object Y” and it be true? Do two or more objects have common attributes and behaviors? Why do we want generalization/specialization relationships? It allows us to take advantage of inheritance which facilitates the reuse of objects and programming code. 303 . Once we have identified the basic associations and their multiplicity, we must determine if any Generalization/Specialization relationships exist. Recall that generalization/specialization relationships also know as classification hierarchies or “is a” relationships, consist of super-objects and sub-objects. The super-object being general in that it contains the common attributes and behaviors of the hierarchy. The sub-objects being specialized in that it contains attributes and behaviors unique to that object, but it inherits the super-object’s attributes and behaviors also.

47 The Process of Object Modeling
Organizing The Objects and Identifying Their Relationships Step 3: Identifying Aggregation Relationships In this step we must determine if any aggregation or composition relationships exist. Aggregation relationships are asymmetric, in that object B is part of Object A but, object A is not part of object B. Aggregation relationships do not imply inheritance, in that object B does not inherit behavior or attributes from object A. Aggregation relationships propagate behavior in that behavior applied to the whole is automatically applied to the parts. 303 . Recall that aggregation is an unique type of association in which one object “is part of” another object. It is often referred to as a whole/part relationship and can be read where as object A contains object B and object B is part of object A. Aggregation relationships propagate behavior in that behavior applied to the whole is automatically applied to the parts. For example ,if I want to send object A to a customer, object B would be sent also.

48 The Process of Object Modeling
Organizing The Objects and Identifying Their Relationships Step 4: Preparing The Object Association Model In this step construct the object association model diagram which depicts how the objects are related to each other and what type the relationships are. 304 . No additional notes provided.

49 304 Figure 8.16 Member Services System Object Association Model
The figure above is an OMT object/class association diagram for the Member Services System. The diagram was constructed using Popkin Software’s System Architect. Notice that the model depicts business objects/classes within the domain of the Soundstage Member Services System. The object class notation on the model does not depict the actual data attributes and behaviors (methods). This is commonly done to prevent the diagram from becoming needlessly cluttered and overwhelming. The model also reflects the object class associations and multiplicity that were identified in step 1, and a couple generalization/specialization relationships that are discovered in step 2. Step 3 did not reveal aggregate relationships among our objects/classes. It would quite easy to imagine a few aggregate relationships. For example, a GAME TITLE may actually consist of a cartridge, a protective case, and instruction booklet. However, this aggregate relationship (and other possible aggregate structures) were determined to be irrelevant to the users they have no need to recognize this aggregate relationships since the game title is acquired from suppliers who provide the entire packet of components.

50 An Introduction to Object Modeling System Concepts for Object Modeling
Summary Introduction An Introduction to Object Modeling System Concepts for Object Modeling The Process of Object Modeling


Download ppt "An Introduction to Object Modeling"

Similar presentations


Ads by Google