pertemuan7 - andiwre.itmaranatha.organdiwre.itmaranatha.org/download/in032-rpl1/pertemuan7.pdf ·...

Pertemuan 7Object Oriented Modeling and Design

ReferencesReferences

• Rumbaugh, James et al., Object‐Oriented Modeling and Design, 1991 Prentice Hall Inc USA ISBN 0 13 629841 91991, Prentice‐Hall, Inc., USA, ISBN: 0‐13‐629841‐9

• Coad, Peter and Yourdon, Edward, Object‐Oriented Analysis, 1991, Prentice‐Hall, Inc., USA, ISBN: 0‐13‐630013‐8

• Booch, Grady et al. , Object‐Oriented Analysis and Design with Applications, 3rd edition, 2007, Pearson Education, Inc., USA, ISBN: 0‐201‐89551‐X

• IBM Software Group, Mastering Object‐Oriented Analysis and Design with UML 2.0, Module 2: Concepts of Object Orientation, 20133

Analysis Method (1)Analysis Method (1)

• Analysis means the process of extracting the “needs” of a system, what the system must do to satisfy the client, not how the system will be implemented.

• Analysis approaches:• Analysis approaches:• Functional decomposition = functions + sub‐functions + functional interfacesData flow approach data (&control) flows + data (&control) • Data flow approach = data (&control) flows + data (&control) transformations + data (&control) stores + terminators + process spec + data dictionary

Analysis Method (2)Analysis Method (2)

• Analysis approaches (cont.):• Information modeling = objects + attributes + relationships + supertype/sub‐types + associative objects

• Object‐oriented: classes and objects + inheritance + communication with messages

Object Oriented (1)Object‐Oriented (1)

• The term “object‐oriented” means that software is organized as a collection of discrete objects that incorporate both data structure and behavior.

• Generally object oriented is characterized by four aspects: • Generally object‐oriented is characterized by four aspects: identity, classification, polymorphism, and inheritance.


• Identitymeans that data is quantized into discrete, distinguishable entities called objects.

• Objects can be concrete, such as file in a file system, or conceptual such as scheduling policy in a multiprocessing operating system.

• Classificationmeans that objects with the same data structure (attributes) and behavior (operations) are grouped into a class into a class.

• A class is an abstraction that describes properties important to an application and ignores the rest.


• Each class describes a possibly infinite set of individual objects. • Each object is said to be an instance of its class.• Each instance of the class has its own value for each attribute but shares the attribute names and operations with other instances of th lthe class.

• An object contains an implicit reference to its own class.


• Polymorphismmeans that the same operation may behave differently on different classes.

• An operation is an action or transformation that an object performs or is subject to.

• A specific implementation of an operation by a certain class is called a method.


• Inheritance is the sharing of attributes and operations among classes based on a hierarchical relationship.

• A class can be defined broadly and then refined into successively finer subclasses.

• Each subclass incorporates, or inherits, all of the properties of its superclass and adds its own unique properties.

• The properties of the superclass need not be repeated in each b lsubclass.

Object Oriented Methodology (1)Object‐Oriented Methodology (1)

• Analysis: starting from a statement of the problem, the analyst builds a model of the real‐world situation showing its important properties. The analyst must work with the requestor to understand the problem because problem statements are rarely complete or correct.

• System design: the system designer makes high‐level decisions about the overall architecture During system decisions about the overall architecture. During system design, the target system is organized into subsystems based on both the analysis structure and the proposed architecture.


• Object design: the object designer builds a design model based on the analysis model but containing implementation details. The designer adds details to the design model in accordance with the strategy established during the system design. The focus of object design is the data structures and algorithms needed to implement each class.


• Implementation: the object classes and relationships developed during object design are finally translated into a particular programming language, database, or hardware implementation. Programming should be are relatively minor and mechanical part of the development cycle, because all of the hard decisions should be made during design.

Object Oriented AnalysisObject‐Oriented Analysis

• Object‐oriented analysis: a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain [Booch].

Object Oriented DesignObject‐Oriented Design

• Object‐oriented design: a method of design encompassing the process of object‐oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the system under design [Booch].

Object Oriented ProgrammingObject‐Oriented Programming

• Object‐oriented programming (OOP): a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of hierarchy of classes united via inheritance relationships [Booch].

Object Oriented Methodology versus Functional MethodologyFunctional Methodology

• Functional methodology: emphasis on specifying and decomposing system functionality. Such an approach might seem the most direct way of implementing a desired goal, but the resulting system can be fragile. If the requirements change, a system based on decomposing functionality may require massive restructuring.

• Object oriented approach focuses first on identifying objects • Object‐oriented approach focuses first on identifying objects from the application domain, then fitting procedures around them.

Basic Principles of Object OrientationBasic Principles of Object Orientation

• There are four basic principles of object orientation. They are:

• Abstraction

• Encapsulation Object Orientation

• Modularity

• Hierarchy

actio

n

arch

y

j

sulat

ion

ularity

Abstr

a

Hier

a

Enca

ps

Modu

Example AbstractionExample: Abstraction

• A student is a person enrolled in l t th i itclasses at the university.

• A professor is a person teaching classes at the university.

Student Professor

y

• A course is a class offered by the university.

C Off i ( AM • A course offering is a specific offering for a course, including days of the week and times.

Course Offering (9:00 AM, Monday‐Wednesday‐Friday)Course (e.g., Algebra)

Encapsulation Illustrated (1)Encapsulation Illustrated (1)• Professor Clark needs to be able to teach Professor Clarkto be ab e to teacfour classes in the next semester.

Name: J Clark

Employee ID: 567138

HireDate: 07/25/1991

Status: Tenured

Discipline: FinanceSetMaxLoad(4)

TakeSabbatical()

p

MaxLoad: 4SetMaxLoad(4)

Encapsulation Illustrated (2)Encapsulation Illustrated (2)• The key to encapsulation is an object’s message interface. The object interface ensures that all communication with the object takes place through a set of

d fi d ti D t i id th bj t i l ibl b th bj t’j p g

predefined operations. Data inside the object is only accessible by the object’s operations. No other object can reach inside of the object and change its attribute values.

• For example, Professor Clark needs to have her maximum course load increased from three classes to four classes per semester Another object will make afrom three classes to four classes per semester. Another object will make a request to Professor Clark to set the maximum course load to four.The attribute, MaxLoad, is then changed by the SetMaxLoad() operation.

• Encapsulation is beneficial in this example because the requesting object does not need to know how to change the maximum course load In the future the numberneed to know how to change the maximum course load. In the future, the number of variables that are used to define the maximum course load may be increased, but that does not affect the requesting object. The requesting object depends on the operation interface for the Professor Clark object.

Example Modularity (1)Example: Modularity (1)• For example, break complex systems into smaller ymodules. Billing

System

Course Catalog System

Course Registration System

y

Student Management System

Example Modularity (2)Example: Modularity (2)• Often, the system under development is too complex to understand. To further understanding the system is broken into smaller blocks that are each maintained understanding, the system is broken into smaller blocks that are each maintained independently. Breaking down a system in this way is called modularity. It is critical for understanding a complex system.

• For example the system under development is a Course Registration system The For example, the system under development is a Course Registration system. The system itself is too large and abstract to allow an understanding of the details. Therefore, the development team broke this system into three modular systems, each independent of the others.

• The Billing System

• Course Catalog System

• Student Management SystemStudent Management System

Example Hierarchy (1)Example: Hierarchy (1)Increasingabstraction

Asset

RealEstateBankAccount Security

Decreasing abstraction

Savings Checking Stock Bond

Elements at the same level of the hierarchy should be at the same level

of abstraction.

Example Hierarchy (2)Example: Hierarchy (2)• Hierarchy can be defined as:

A ki d i f b i i lik Ki d A i hi h • Any ranking or ordering of abstractions into a tree‐like structure. Kinds: Aggregation hierarchy, class hierarchy, containment hierarchy, inheritance hierarchy, partition hierarchy, specialization hierarchy, type hierarchy. (Dictionary of Object Technology, Firesmith, Eykholt, 1995)

• Hierarchy organizes items in a particular order or rank (for example, complexity and responsibility). This organization is dependent on perspective. Using a hierarchy to describe p y) g p p p g ydifferences or variations of a particular concept provides for more descriptive and cohesive abstractions and a better allocation of responsibility.

• In any one system, there may be multiple abstraction hierarchies (for example, a financial application may have different types of customers and accounts).

• Hierarchy is not an organizational chart or a functional decomposition.• Hierarchy is a taxonomic organization. The use of hierarchy makes it easy to recognize similarities and differences. For example, botany organizes plants into families. Chemistry organizes elements in a periodic table.

Another Definition about Object‐Oriented Themes (1)Themes (1)

• Abstraction: • Consists of focusing on the essential, inherent aspects of an entity and ignoring its accidental properties. In system development, this means focusing on what an object is and does, before deciding how it sho ld be implemented Use of abstraction preser es the freedom to should be implemented. Use of abstraction preserves the freedom to make decisions as long as possible by avoiding premature commitments to details [Rumbaugh].

• An abstraction denotes the essential characteristics of an object that • An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer [Booch].


• Encapsulation (information hiding): consists of separating the external aspects of an object, which are accessible to other objects, from the internal implementation details of the object, which are hidden from other objects. Encapsulation prevents a program from becoming so interdependent that a small change has massive ripple effects. The implementation of an object can be changed without affecting the applications that use it [Rumbaugh].


• Combining data and behavior: the caller of an operation need not consider how many implementations of a given operation exist. Operator polymorphism shifts the burden of deciding what implementation to use from the calling code to the class hierarchy.


• Hierarchy: a ranking or ordering of abstractions [Rumbaugh].

• Sharing: object‐oriented techniques promote sharing at several different levels. Inheritance of both data structure and behavior allows common structure to be shared among behavior allows common structure to be shared among several similar subclasses without redundancy. The sharing of code using inheritance is one of the main advantages of object oriented languages [Rumbaugh] object‐oriented languages [Rumbaugh].


• Emphasis on object structure, not procedure structure: object‐i t d t h l t if i h t bj t i oriented technology stresses specifying what an object is,

rather than how it is used. The uses of an object depend highly on the details of the application and frequently change during development As requirements evolve the features supplied development. As requirements evolve, the features supplied by an object are much more stable than the ways it is used, hence software systems built on object structure are more stable in the long run. Object‐oriented development places a g j p pgreater emphasis on data structure and a lesser emphasis on procedure structure than traditional functional‐decomposition methodologies.


• Modularity: the property of a system that has been d d i t t f h i d l l l d decomposed into a set of cohesive and loosely coupled modules; consist of dividing a program into modules which can be compiled separately, but which have connections with other modules [Rumbaugh]other modules [Rumbaugh].

• Synergy: identity, classification, polymorphism, and inheritance characterize mainstream object‐oriented l E h f th t b d i i l ti languages. Each of these concepts can be used in isolation, but together they complement each other synergistically[Rumbaugh].

Principles for Managing Complexity (1)Principles for Managing Complexity (1)

• Abstraction: the principle of ignoring those aspects of a bj t th t t l t t th t i d t subject that are not relevant to the current purpose in order to

concentrate more fully on those that are.• Procedural abstraction: the principle that any operation that achieves a well‐defined effect can be treated by its users as a single entity a well defined effect can be treated by its users as a single entity, despite the fact that the operation may actually be achieved by sequence of lower‐level operations.

• Data abstraction: the principle of defining a data type in terms of the ti th t l t bj t f th t ith th t i t th t operations that apply to objects of the type, with the constraint that

the values of such objects can be modified and observed only by the use of the operations.


• Encapsulation (information hiding): a principle, used when d l i ll h h fdeveloping an overall program structure, that each component of a program should encapsulate or hide a single design decision; the interface to each module is defined in such a way as to reveal as little as possible about its inner workingslittle as possible about its inner workings.

• Inheritance: a mechanism for expressing similarity among classes, simplifying definition of classes similar to one(s) previously defined. p y g p yIt portrays generalization and specialization, making common attributes and services explicit within a class hierarchy or lattice.


• Association: the union or connection of ideas.

• Message: any communication, written or oral, sent between persons.

Modeling as a Design TechniqueModeling as a Design Technique

• A model is an abstraction of something for the purpose of understanding it before building it. Because a model omits nonessential details, it is easier to manipulate than the original entity.

• Models serve several purposes:• Testing a physical entity before building it.C i i i h • Communication with customer.

• Visualization.• Reduction of complexity.

Object Modeling Technique (OMT) 1 Object Modeling Technique (OMT) ‐ 1

• The object model: describes the static structure of the objects in a d h i l i hi h bj d l i bjsystem and their relationships. The object model contains object

diagrams. An object diagram is a graph whose nodes are object classes and whose arcs are relationships among classes.

• The dynamic model: describes the aspects of a system that change over time. The dynamic model is used to specify and implement the control aspects of system. The dynamic model contains state p y ydiagrams. A state diagram is a graph whose nodes are states and whose arcs are transitions between states caused by events.

Object Modeling Technique (OMT) 2 Object Modeling Technique (OMT) ‐ 2

• The functional model: describes the data value transformations within a system. The functional model contains data flow diagrams. A data flow diagram represents a computation. A data flow diagram is a graph whose nodes are processes and whose arcs are data flows.

• The three models are orthogonal parts of the description of a complete system and are cross linked complete system and are cross‐linked.

Object ModelObject Model

• An object model captures the static structure of a system by showing the objects in the system, relationships between the objects and the attributes and operations that characterize each class of objects.

• The object model emphasizes on building a system around objects rather than around functionality.

Object (1)

Attributes

Object (1) • Object:

• A concept, abstraction, or thing with crisp boundaries and meaning for the problem at p , , g p g phand [Rumbaugh].

• An abstraction of something in a problem domain, reflecting the capabilities of a system to keep information about it, interact with it, or both; an encapsulation of attribute values and their exclusive services [Coad, Yourdon].

• an entity that has state, behavior, and identity [Booch].• An object is an entity with a well‐defined boundary and identity that encapsulates state

ObjectOperations

An object is an entity with a well defined boundary and identity that encapsulates stateand behavior. State is represented by attributes and relationships. Behavior is represented by operations, methods, and state machines [IBM].

• Objects serve two purposes: • The promote understanding of the real world and;

P id ti l b i f t i l t ti• Provide a practical basis for computer implementation.

• Decomposition of a problem into objects depends on judgment and the nature of the problem; there is no one correct representation.

Object (2) Object (2)

• All objects have identity and are distinguishable. The term identity means that objects are distinguished by their inherent existence and not by descriptive properties that they may have.

• Object instance: object that refer to exactly one thing.

• Object class: object that refer to a group of similar things.j j g p g

Class (1)Class

+ attributeClass (1)• Class:

• An object class describes a group of objects with similar properties (attributes)

+ operation()

• An object class describes a group of objects with similar properties (attributes), common behavior (operations), common relationships to other objects, and common semantics [Rumbaugh].

• A description of one or more objects with a uniform set of attributes and services, including a description of how to create new object in the class [Coad, Yourdon].

• A class is a description of a set of objects that share the same attributes operations A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. An object is an instance of a class.A class is an abstraction in that it 1)Emphasizes relevant characteristics. 2)Suppresses other characteristics.

• Example of object class: person, company, animal, process. Each person has a name, an age, IQname, an age, IQ

• Objects and object classes often appear as nouns in problem descriptions.

Class (2)Class (2)

• The abbreviation class is often used instead of object class.

• Objects in a class have the same attributes and behavior patterns.

• Most objects derive their individuality from differences in their attribute values and relationships to other objects. However, objects with identical attribute values and relationships are j ppossible.

Class (3)Class (3)

• Interfaces of a class [Booch]:• Public: a declaration that is accessible to all clients• Protected: a declaration that is accessible only to the class itself and its subclasses

• Private: a declaration that is accessible only to the class itself• Package: a declaration that is accessible only by classes in the same package

Attribute (1)Attribute (1)

• An attribute is a data value held by the objects in a class.

• Example: name, age, and weight are attributes of person objects.

• Different object instances may have the same or different values for a given attribute.

E h tt ib t i i ithi l ( d t • Each attribute name is unique within a class (as opposed to being unique across all classes). Thus class Person and class Company may each have an attribute called address.

Attribute (2)Attribute (2)

• An attribute should be a pure data value, not an object.

• Unlike objects, pure data values do not have identity.

• For example, all occurrences of the integer “20” are p , gindistinguishable as are all occurrences of the string “Jakarta”

Operations and Methods (1)Operations and Methods (1)

• No object exist in isolation. Behavior is how an object acts and reacts in terms of its state changes and message passingreacts, in terms of its state changes and message passing.

• An operation is a function or transformation that may be applied to or by object in a class.

• All objects in a class share the same operations.

• The same operation may apply to many different classes (polymorphic) that is the same operation takes on different forms (polymorphic), that is the same operation takes on different forms in different classes.

• A method is the implementation of an operation for a class.

Operations and Methods (2)Operations and Methods (2)• When an operation has methods on several classes, it is important that the methods all have the same signature the number and that the methods all have the same signature, the number and types of arguments and the type of result value.

• Most common operations: • Modifier: an operation that alters the state of an objectModifier: an operation that alters the state of an object.• Selector: an operation that accesses the state of an object but does not alter the state.

• Iterator: an operation that permits all parts of an object to be accessed in some well‐defined order.

• Constructor: an operation that creates an object and/or initializes its state.• Destructor: an operation that frees the state of an object and/or destroys the object itself.

Examples of A Class and Objects (1)Examples of A Class and Objects (1)

Class of Employee with attributesp y

Employee Objects of Tom and KatylnEmployee Objects of Tom and Katyln

Examples of A Class and Objects (2)Examples of A Class and Objects (2)Class of Employee with protected attributes and public operationsp p

Protected is indicated by # (its internal representation is hidden from all other outside clients)

Public is indicated by + (it grants all clients the right to retrieve the name, social number, andy g g , ,departmet of an employee)

Examples of A Class and Objects (3)Examples of A Class and Objects (3)

Person

nameage

h j b

File

file namesize in byteslast update

Geometric object

color position

move(delta: Vector)change‐jobchange‐address

p

printmove(delta: Vector)

select (p: Point): Booleanrotate (angle)

Representing Classes in the UMLRepresenting Classes in the UML

• A class is represented using a rectangle with compartments.Professor

‐ name‐ employeeID : UniqueID‐ hireDate

P f J Cl k

‐ hireDate‐ status‐ discipline‐maxLoad

+ submitFinalGrade()Professor J Clark

()+ acceptCourseOffering()+ setMaxLoad()+ takeSabbatical()+ teachClass()

The Relationship Between Classes and Objects (1)Objects (1)

• A class is an abstract definition of an object.

• It defines the structure and behavior of each object in h l

Professor Torpie Professor

the class.• It serves as a template for creating objects. Professor Meijer Professor Allen

• Classes are not collections of objects.

The Relationship Between Classes and Objects (2)Objects (2)• A class is a description of a set of objects that share the same responsibilities, relationships, operations,

attributes, and semantics.

• An object is defined by a class. A class defines a template for the structure and behavior of all its objects. The objects created from a class are also called the instances of the class.

• The class is the static description; the object is a run-time instance of that class.

• Since we model from real-world objects software objects are based on the real-world objects but they exist• Since we model from real-world objects, software objects are based on the real-world objects, but they exist only in the context of the system.

• Starting with real-world objects, abstract out what you do not care about. Then, take these abstractions and categorize, or classify them, based on what you do care about. Classes in the model are the result of this classification process.

• These classes are then used as templates within an executing software system to create software objects. These software objects represent the real-world objects we originally started with.

• Some classes/objects may be defined that do not represent real-world objects. They are there to support the design and are "software only.”

Class RelationshipsClass Relationships

• “The semantic connection between classes” ~ Grady Booch

• Class diagrams may contain the following relationships:Association OR

OR

OR

Aggregation

Composition

GeneralizationGeneralization

Dependency

Realization

What Is Navigability? (1)What Is Navigability? (1)

• Indicates that it is possible to navigate from a associating class to the target class using the association

RegistrationController

CourseOfferingSchedule

What Is Navigability? (2)What Is Navigability? (2)• The navigability property on a role indicates that it is possible to navigate from a associating class to the

target class using the association. This may be implemented in a number of ways: by direct object references, associative arrays hash-tables or any other implementation technique that allows one object to referenceassociative arrays, hash tables, or any other implementation technique that allows one object to reference another.

• Navigability is indicated by an open arrow placed on the target end of the association line next to the target class (the one being navigated to). The default value of the navigability property is true (associations are bi-directional by default).

• In the course registration example, the association between the Schedule and the Course Offering is navigable in both directions. That is, a Schedule must know the Course Offering assigned to the Schedule, and the Course Offering must know the Schedules it has been placed in.

• When no arrowheads are shown, the association is assumed to be navigable in both directions.

• In the case of the association bet een Sched le and Registration Controller the Registration Controller m st• In the case of the association between Schedule and Registration Controller, the Registration Controller must know its Schedules, but the Schedules have no knowledge of the Registration Controllers (or other classes). As a result, the navigability property of the Registration Controller end of the association is turned off.

What Is an Association? (1)What Is an Association? (1)• The semantic relationship between two or more classifiers that specifies connections among their instances

• A structural relationship, specifying that objects of one thing are connected to objects of another

CourseStudent Schedule

What Is an Association? (2)What Is an Association? (2)• An association can be defined as:

• The semantic relationship between two or more classifiers that specifies connections among their instances. In other words, an association is a structural relationship that specifies that objects (instances of classes) are connected to other objects.

• The way that we show relationships between classes is through the use of associations. Associations are represented on class diagrams by a line connecting the associating classesAssociations are represented on class diagrams by a line connecting the associating classes. Data may flow in either direction or in both directions across a link.

• Most associations are simple. That is, they exist between exactly two classes. They are drawn as solid paths connecting pairs of class symbols. Ternary relationships are also possible.

• Sometimes a class has an association to itself This does not always mean that an instance of• Sometimes, a class has an association to itself. This does not always mean that an instance of that class has an association to itself. More often, it means that one instance of the class has associations to other instances of the same class.

• This example shows that a student object is related to a schedule object. The course class demonstrates how a course object can be related to another course object.

What Is Multiplicity? (1)What Is Multiplicity? (1)• Multiplicity is the number of instances one class relates to ONE instance of another classONE instance of another class.

• For each association, there are two multiplicity decisions to make, one for each end of the association.

F h i t f P f C Off i b • For each instance of Professor, many Course Offerings may be taught.

• For each instance of Course Offering, there may be either one or zero Professor as the instructor.

Professor CourseOffering

0..1 0..*

+ instructor

What Is Multiplicity? (2)What Is Multiplicity? (2)• Multiplicity can be defined as:

• The number of instances of one class that relate to one instance of another class.• For each role, you can specify the multiplicity of its class and how many objects of the class can be associated with one object of the other class.

• Multiplicity is indicated by a text expression on the role. The expression is a comma-separated p y y p p plist of integer ranges.

• It is important to remember that multiplicity is referring to instances of classes (objects) and their relationships. In this example, a Course Offering object can have either zero or one Professor object related to it. Conversely, a Professor object can have zero or more Course Offering objects related to itobjects related to it.

• Multiplicity must be defined on both ends of the association.

Multiplicity Indicators UnspecifiedMultiplicity Indicators• Multiplicity is indicated by a text expression on the

role. 1

Unspecified

Exactly One

Zero or More• The expression is a comma-separated list of integer

ranges.

• A range is indicated by an integer (the lower value), two dots, followed by another integer (the upper value).

0..*

*

Zero or More

One or More

Zero or More

)

• A single integer is a valid range, and the symbol “*” indicates "many.” That is, an asterisk “*” indicates an unlimited number of objects.

• The symbol “*” by itself is equivalent to “0..*” That is, it represents an n mber incl ding none This is the

0..1

1..*

Zero or One (optional scalar role)

One or More

Specified Rangeit represents any number, including none. This is the default value.

• An optional scalar role has the multiplicity 0..1.

2..4

2, 4..6

Specified Range

Multiple, Disjoint Ranges

Relationships Among Objects (1)Relationships Among Objects (1)

• An object by itself is intensely uninteresting. Objects contribute to the behavior of a system by collaborating with one another.

• The relationship between any two objects encompasses the • The relationship between any two objects encompasses the assumptions that each makes about the other, including what operations can be performed and what behavior results.


• Two kinds of object relationships: links and aggregation.• A link: is a physical or conceptual connection between object instances. A link is an instance of an association [Rumbaugh]. Message passing between two objects is typically unidirectional, altho gh it ma occasionall be bidirectionalalthough it may occasionally be bidirectional.


• This is an example of a link: FlowController acts as a controller object, DisplayPanel acts as a server object, and Valve acts as a proxy.

Relationships Among Objects (4)Relationships Among Objects (4)• Aggregation:

Whereas links denote peer to peer or client/supplier relationships aggregation • Whereas links denote peer‐to‐peer or client/supplier relationships, aggregation denotes a whole/part hierarchy, with the ability to navigate from the whole (also called the aggregate) to its parts. In this sense, aggregation is a specialized kind of association.

• By implication, an object that is a part of another object has a link to its aggregate.y p , j p j gg g• Across this link, the aggregate may send messages to its parts.• Aggregation may or may not denote physical containment. For example, an

airplane is composed of wings, engines, landing gear, and so on: This is a case of physical containment. On the other hand, the relationship between a shareholder

d hi h h i ti l ti hi th t d t i h i l and his or her shares is an aggregation relationship that does not require physical containment. The shareholder uniquely owns shares, but the shares are by no means a physical part of the shareholder. Rather, this whole/part relationship is more conceptual and therefore less direct than the physical aggregation of the parts that form an airplane.


• This is an example of an aggregation: the object Temperature‐C t ll h li k t th bj t T t R ll t Controller has a link to the object TemperatureRamp as well as to Heater. The object TemperatureController is thus the whole, and Heater is one of its parts.

Kinds of RelationshipsKinds of Relationships

• There are three basic kinds of class relationships:• Generalization/specialization: denoting an “is a” relationship. For instance, a rose is a kind of flower, meaning that a rose is a specialized subclass of the more general class, flower.

• Whole/part: denotes a “part of” relationship. Thus, a petal is not a kind of a flower; it is a part of a flower.

• Association: denotes some semantic dependency among otherwise unrelated classes such as between ladybugs and flowers As another unrelated classes, such as between ladybugs and flowers. As another example, roses and candles are largely independent classes, but they both represent things that we might use to decorate a dinner table.

Associations (1)Associations (1)

• An association describes a group of links with common structure and common semantics. All the links in an association connect objects from the same classes. Associations and links often appear as verbs in a problem statement.

• Example: person (works for) company


• Associations are often implemented in programming languages as pointers from one object to another.

• A pointer is an attribute in one object that contains an explicit reference to another objectreference to another object

• Although associations are modeled as bidirectional, they do not have to be implemented in both directions. p

• Associations can easily be implemented as pointers if they are only traversed in a single direction.


• an association only denotes a semantic dependency and does not state the direction of this dependency (unless otherwise stated, an association implies bidirectional navigation nor does it state the exact way in which one class relates to another.

• However, these semantics are sufficient during the analysis of a problem at which time we need only to identify such a problem, at which time we need only to identify such dependencies.


• Through the creation of associations, we come to capture the ti i t i ti l ti hi th i l d th i participants in a semantic relationship, their roles, and their

cardinality.• Here we show a one‐to‐many association (Arguably, an aggregation would be better ): Each instance of Wheel relates to one Vehicle and would be better.): Each instance of Wheel relates to one Vehicle, and each instance of Vehicle may have many Wheels (noted by the *).


Country

name

City

name

Has‐capital

MultiplicityMultiplicity

• Three common kinds of multiplicity across an association: • One‐to‐one:

• a one‐to‐one relationship between the class Sale and the class CreditCardTransaction: Each sale has exactly one corresponding credit card transaction and each such transaction corresponds to one saletransaction, and each such transaction corresponds to one sale.

• One‐to‐many• Many‐to‐many:

• each instance of the class Customer might initiate a transaction with several • each instance of the class Customer might initiate a transaction with several instances of the class SalesPerson, and each such salesperson might interact with many different customers.

pertemuan7 - andiwre.itmaranatha.organdiwre.itmaranatha.org/download/in032-rpl1/pertemuan7.pdf ·...

Documents