Advance System Analysis L2
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Advance System Analysis L2 as PDF for free.
More details
- Words: 3,203
- Pages: 45
Advance system analysis Understanding the Basics–Object-Oriented Concepts
1
Understanding the Basics–ObjectOriented Concepts Brief Overview of OO Concepts OO Concepts from a Structured Point of View The Diagrams of UML 2 Objects and Classes Attributes And Operations/Methods Abstraction, Encapsulation, And Information Hiding Inheritance Persistence Relationships Collaboration Coupling Cohesion Polymorphism Interfaces Components Patterns
2
Brief Overview of OO Concepts Abstract class
A class that does not have objects instantiated from it
Aggregation
Relationships between two classes or components defined as "is part of"
Association
A relationship between two classes or objects
Attribute
Something a class knows (data/information)
Class
A software abstraction of similar objects, a template from which objects are created
Collaboration
Classes work together (collaborate) to fulfill their responsibilities
Component
A cohesive unit of functionality that can be independently developed, delivered, and composed with other components to build a larger unit
Composition
A strong form of aggregation in which the "whole" is completely responsible for its parts and each "part" object is only associated to one "whole" object
Encapsulation
3
The grouping of related concepts into one item, such as a class or a component
Inheritance
Relationships defined as "is a" and "is like"
Instance
An object that is an example of a particular class
Instantiate
To create objects from class definitions
Interface
A collection of one or more operation signatures that defines a cohesive set of behaviors
Method
A process implemented by a class that performs an action of value (similar to a function in structured programming)
Multiple inheritance
The direct inheritance from more than one class
Object
A person, place, thing, event, concept, screen, or report, based on a class definition
Override
4
Persistence
The direct inheritance from only one class
Subclass
In UML 2, a named value, for example, attributes and associations, including composition, denoting a characteristic of an element (such as a class or component). In C# the combination of an attribute with its getter and setter.
Single inheritance
The ability of different objects to respond to the same message in different ways, enabling objects to interact with one another without knowing their exact type
Property
The storing of objects to permanent storage, for example, files, databases, etc.
Polymorphism
To redefine attributes and/or methods in subclasses so that they are different from the definition in the super class
A class that inherits from another class
Superclass
5
A class from which another class inherits
OO Concepts from a Structured Point of View
Class. A class is a software abstraction of an object,
Object. An object is a software construct that mirrors a concept in the real world, e.g., a person, place, thing, event, concept, screen, or report.
Attribute. An attribute is equivalent to a data element in a record. From a programming point of view, it also makes sense to think of an attribute as a local variable applicable only to a single object.
Method. A method can be thought of as either a function or procedure. Methods access and modify the attributes of an object. Better yet, methods can do a whole bunch of stuff that has nothing to do with attributes
6
The Diagrams of UML 2 Thirteen diagrams of UML 2.x , There are three classifications of UML diagrams:
Behavior diagrams. This is a type of diagram that depicts behavioral features of a system or business process. Includes:
Interaction diagrams. This is a subset of behavior diagrams that emphasize object interactions. This includes :
communication, interaction overview, sequence, and timing diagrams.
Structure diagrams. This is a type of diagram that depicts the static elements of a specification that are irrespective of time. This includes
7
activity, state machine, and use case diagrams, as well as the four interaction diagrams.
class, composite structure, component, deployment, object, and package diagrams.
Objects and Classes
The OO paradigm is based on building systems from items called objects.
Example a university system,
Sarah is a student object, she attends several seminar objects, and she is working on a degree object.
Example In a banking system,
An object is any person, place, thing, event, concept, screen, or report
Sarah is a customer object. She has a checking account object from which she bounces rubber-check objects.
Example In an inventory control system,
8
every inventory item is an object, every delivery is an object, and every customer is an object
The Diagrams of UML 2 Activity diagram
Depicts high-level business processes, including data flow, or to model the complex logic within a system.
Class diagram
Shows a collection of static model elements such as classes and types, their contents, and their relationships.
Communication diagram
Shows instances of classes, their interrelationships, and the message flow between them, and typically focuses on the structural organization of objects that send and receive messages; called a collaboration diagram in UML 1.x.
Component diagram
Depicts the components, including their interrelationships, interactions, and public interfaces, that compose an application, system, or enterprise.
Composite structure diagram
Depicts the internal structure of a classifier (such as a class, component, or use case), including the interaction points of the classifier to other parts of the system.
9
Deployment diagram
Shows the execution architecture of systems, including nodes, either hardware or software execution environments, and the middleware connecting them.
Interaction overview diagram
A variant of an activity diagram, which overviews the control flow within a system or business process ,whereby each node/ activity within the diagram can represent another interaction diagram..
Object diagram
Depicts objects and their relationships at a point in time, typically a special case of either a class diagram or a communication diagram. See
Package diagram
Shows how model elements are organized into packages as well as the dependencies between packages
Sequence diagram
Models sequential logic, in effect the time ordering of messages between classifiers.
State machine diagram
Describes the states an object or interaction may be in, as well as the transitions between states; formerly referred to as a state diagram, state chart diagram, or a state-transition diagram.
Timing diagram
Depicts the change in state or condition of a classifier instance or role over time, and typically used to show the change in state of an object over time in response to external events.
10 Use Case Diagram
Shows use cases, actors, and their relationships.
The figure shows how we have student objects and how we model the class Student
It also shows the standard notations to model a class using the UML
Class names are typically singular nouns, The name of a class should be one or two words
like Student, Professor, and Course, not Students, People Who Teach Seminars
When object-oriented software is running, objects are instantiated (created/defined) from classes. We say an object is an instance of a class and we instantiate those objects from classes. 11
Attributes And Operations/Methods
Classes have responsibilities, the things they know and do
Attributes are the things classes know; methods are the things classes do
The object-oriented paradigm is based on the concepts that systems should be built out of objects, and that objects have both data and functionality.
Attributes define the data, while methods define the functionality
12
Figure 1
13
Figure 2
14
Figure 1 you see two different types of objects: a student and a seminar. Both objects know and do certain things, and you want to make sure you record this in your models Figure 2 I am using the three-section class notation in this case: the top section for the name, the middle section to list the attributes, and the bottom section to list the methods
15
Depicts two types of attributes:
instance attributes, which are applicable to a single object, and static attributes, which are applicable to all instances of a single class
Static attributes are underlined, instance attributes are not.
For example, name is an instance attribute of the class Student. Each individual student has a name; for example, one student may have the name "Smith, John,“
On the other hand, nextStudentNumber is a static attribute (also referred to as a class attribute) that is applicable to the class Student, not specifically to individual instances. This attribute is used to store the value of the next student number to be assigned to a student:
16
Similarly, there is the concept of instance methods and static/class methods
instance methods operate on a single instance, whereas static methods operate potentially on all instances of a single class
you see that Student has instance methods called enrollInSeminar and dropSeminar,
It also has the static method findBy- Name, which supports the behavior of searching for students whose names meet specified search criteria, a method that operates on all instances of the class.
17
Abstraction, Encapsulation, And Information Hiding
Abstraction
To deal with that complexity we form abstractions of the things in it. For example, consider the abstraction of a person. From the point of view of a university, it needs to know the person's name, address, telephone number, social security number, and educational background
OO systems abstract is the act of defining the interface to something
classed marked as abstract (the name is in italics; in previous versions of the UML you could also indicate with the constraint {abstract})
18
Encapsulation
object-oriented world, you modularize systems into classes, which, in turn, are modularized into methods and attributes.
We say that we encapsulate behavior into a class or we encapsulate functionality into a method.
People often say encapsulation is the act of painting the box black: you are defining how something is going to be done, but you are not telling the rest of the world how you are going to do it. In other words you are hiding the details of the implementation of an item from the users of that item 19
Inheritance
Two or more classes often share the same attributes and/or the same methods. Because you do not want to have to write the same code repeatedly, you want a mechanism that takes advantage of these similarities.
Inheritance is that mechanism. Inheritance models "is a", "is kind of", and "is like" relationships, enabling you to reuse existing data and code easily.
For example ,
20
students have names, addresses, and telephone numbers, and they drive vehicles. At the same time, professors also have names, addresses, and telephone numbers, and they drive vehicles. Without a doubt, you could develop the classes for student and professor and get them both running.
This is exactly what inheritance is all about. With inheritance, you define a new class that encapsulates the similarities between students and professors. This new class would have the attributes name, address, and phoneNumber, and the method driveVehicle. Because you need to name all our classes, you need to ask yourself what this collection of data and functionality describes. In this case, I think the name Person is fitting.
21
Modeling Inheritance
depicts the UML modeling notation for inheritance, a line with a closed arrowhead. The way you would read the diagram is "B inherits from A." In other words, B is a direct subclass of A and A is the direct superclass of B
22
presents how you would model the Person inheritance class hierarchy, often simply called a class hierarchy
23
Single and Multiple Inheritance
When a class inherits from only one other class, we call this single inheritance When a class inherits from two or more other classes, we call this multiple inheritance Not all languages support multiple inheritance. C++ is one of the few languages that does Multiple Inheritance Rarely Occurs in the Real World
24
25
Abstract and Concrete Classes
Vehicle is abstract Airplane and car are concrete class The main difference between abstract classes and concrete classes is that objects are instantiated (created) from concrete classes, but not from abstract classes.
26
Persistence
Persistence focuses on the issue of how to make objects available for future use of your software In other words, how to save objects to permanent storage transient object is an object you do not need to save it in a permanent storage
27
Relationships
In the real world, objects have relationships with other objects. The relationships between objects are important because they help us to define how they interact with each other For example:
Not only must you identify what the relationship(s) are between classes, you must also describe the relationship For example:
students take courses professors teach courses,
students take seminars. How many seminars can students take? None, one, or several
Furthermore, relationships are two-way streets
28
not only do students take seminars, but also seminars are taken by students
Associations
An association is a persistent relationship between two or more classes or objects When you model associations in UML class diagrams, you show them as a thin line connecting two classes, as you see :
29
30
Directionality. The open arrowheads indicate the directionality of the association
unidirectional: it can be traversed in one direction only. bi-directional When there is either zero or two arrowheads the association
Label. The label, which is optional, is typically one or two words describing the association Multiplicity. The multiplicity of the association is labeled on either end of the line, one multiplicity indicator for each direction
31
Indicator Meaning 0..1 Zero or one 1 One only 0..* Zero or more 1..* One or more n Only n (where n > 1) 0..n Zero to n (where n > 1) 1..n One to n (where n > 1) UML Multiplicity Indicators
32
Role. The role—the context that an object takes within the association Qualifier. A qualifier is a value that selects an object from the set of related objects across an association
Recursive association or a self association, according to the figure :
33
A perfect example of this is the manages association that the Employee class has with itself The way you read this association is that any given employee may have several other employees he or she manages, and that one other employee may, in turn, manage them
How Associations Are Implemented
Associations are maintained through the combination of attributes and methods The attributes store the information necessary to maintain the relationship and methods keep the attributes current. For example,
34
the Student class have an attribute called takes, perhaps an array, which is used to keep track of the Seminar objects the student is currently taking The Student class might also have methods such as addSeminar and removeSeminar to add and remove seminar objects into the array The Seminar class would have a corresponding attribute called students and methods called addStudent and removeStudent to maintain the association in the opposite direction
Another Example :
35
In Fig. 2., the unidirectional association holds between Employee and Position would be easier to implement because you only need to traverse it in one direction: from Employee to Position. Therefore, Employee would have an attribute called position and methods, called something like setPosition() and getPosition(), to maintain the association There would be nothing added to Position because there is no need for position objects to collaborate with employee objects; therefore, there is no added code to maintain the association in that direction
Aggregation and Composition
Aggregation
represents "is part of" relationships
For example, an airplane is made up of a fuselage, wings, engines, landing gear A project team consists of two or more employees
Composition is a strong form of aggregation in which the "whole" is completely responsible for its parts and each "part" object is only associated to the one whole object
36
For example, at any given time, an engine is part of one and only one airplane composition is depicted in both UML 1.x and UML 2.x as a filled diamond aggregation was depicted in UML 1.x as a hollow diamond
37
Dependencies
Two types of object relationships exist: persistent and transitory. The main difference is persistent associations must be saved, whereas transitory relationships are only temporary in nature and, thus, are not saved Persistent relationships are those that are permanent or, at least semipermanent, in nature
38
For example, the take relationship between students and courses is persistent The teach relationship between professors and courses is persistent for the same reason
Transitory associations are temporary in nature. They are not saved to permanent storage Transitory relationships usually involve at least one transitory object, such as a screen or report. you see there is a dependency relationship— modeled as a dashed line with an open arrowhead—between the classes Student and Student Editing Screen, representing the transitory relationship between a studentediting screen object as it updates the student object.
39
The editing screen obtains the current information from the student object, displays it in editing mode, and then updates the student object with the new information once it is finished. The transitory relationship between the editing screen object and the student object exists as long as the student information is displayed on the screen. Once the screen is closed, the relationship no longer exists (the screen likely does not exist either) and the transient objects are most likely destroyed.
40
Collaboration
Collaboration occurs between objects when one object asks another for information or to do something Objects collaborate with one another by sending each other messages A message is either a request to do something or a request for information Messages are modeled in UML sequence diagrams and UML communication diagrams
41
Sequence diagram
42
Communication Diagram
43
Polymorphism
An individual object may be one of several types
For example, a John Smith object may be a student, a registrar, or even a professor
for example ,Polymorphism at the University
44
example of polymorphism by exploring the design of how the university handles the hiring of new staff a standard process for hiring staff at the university: once a person is hired, she is added to the university pension plan and an employee card is created for her. When a professor is hired at the university, the same process is followed, with the addition of a parking space assigned to her (if there is no parking space, the professor is added to the waiting list).
45
1
Understanding the Basics–ObjectOriented Concepts Brief Overview of OO Concepts OO Concepts from a Structured Point of View The Diagrams of UML 2 Objects and Classes Attributes And Operations/Methods Abstraction, Encapsulation, And Information Hiding Inheritance Persistence Relationships Collaboration Coupling Cohesion Polymorphism Interfaces Components Patterns
2
Brief Overview of OO Concepts Abstract class
A class that does not have objects instantiated from it
Aggregation
Relationships between two classes or components defined as "is part of"
Association
A relationship between two classes or objects
Attribute
Something a class knows (data/information)
Class
A software abstraction of similar objects, a template from which objects are created
Collaboration
Classes work together (collaborate) to fulfill their responsibilities
Component
A cohesive unit of functionality that can be independently developed, delivered, and composed with other components to build a larger unit
Composition
A strong form of aggregation in which the "whole" is completely responsible for its parts and each "part" object is only associated to one "whole" object
Encapsulation
3
The grouping of related concepts into one item, such as a class or a component
Inheritance
Relationships defined as "is a" and "is like"
Instance
An object that is an example of a particular class
Instantiate
To create objects from class definitions
Interface
A collection of one or more operation signatures that defines a cohesive set of behaviors
Method
A process implemented by a class that performs an action of value (similar to a function in structured programming)
Multiple inheritance
The direct inheritance from more than one class
Object
A person, place, thing, event, concept, screen, or report, based on a class definition
Override
4
Persistence
The direct inheritance from only one class
Subclass
In UML 2, a named value, for example, attributes and associations, including composition, denoting a characteristic of an element (such as a class or component). In C# the combination of an attribute with its getter and setter.
Single inheritance
The ability of different objects to respond to the same message in different ways, enabling objects to interact with one another without knowing their exact type
Property
The storing of objects to permanent storage, for example, files, databases, etc.
Polymorphism
To redefine attributes and/or methods in subclasses so that they are different from the definition in the super class
A class that inherits from another class
Superclass
5
A class from which another class inherits
OO Concepts from a Structured Point of View
Class. A class is a software abstraction of an object,
Object. An object is a software construct that mirrors a concept in the real world, e.g., a person, place, thing, event, concept, screen, or report.
Attribute. An attribute is equivalent to a data element in a record. From a programming point of view, it also makes sense to think of an attribute as a local variable applicable only to a single object.
Method. A method can be thought of as either a function or procedure. Methods access and modify the attributes of an object. Better yet, methods can do a whole bunch of stuff that has nothing to do with attributes
6
The Diagrams of UML 2 Thirteen diagrams of UML 2.x , There are three classifications of UML diagrams:
Behavior diagrams. This is a type of diagram that depicts behavioral features of a system or business process. Includes:
Interaction diagrams. This is a subset of behavior diagrams that emphasize object interactions. This includes :
communication, interaction overview, sequence, and timing diagrams.
Structure diagrams. This is a type of diagram that depicts the static elements of a specification that are irrespective of time. This includes
7
activity, state machine, and use case diagrams, as well as the four interaction diagrams.
class, composite structure, component, deployment, object, and package diagrams.
Objects and Classes
The OO paradigm is based on building systems from items called objects.
Example a university system,
Sarah is a student object, she attends several seminar objects, and she is working on a degree object.
Example In a banking system,
An object is any person, place, thing, event, concept, screen, or report
Sarah is a customer object. She has a checking account object from which she bounces rubber-check objects.
Example In an inventory control system,
8
every inventory item is an object, every delivery is an object, and every customer is an object
The Diagrams of UML 2 Activity diagram
Depicts high-level business processes, including data flow, or to model the complex logic within a system.
Class diagram
Shows a collection of static model elements such as classes and types, their contents, and their relationships.
Communication diagram
Shows instances of classes, their interrelationships, and the message flow between them, and typically focuses on the structural organization of objects that send and receive messages; called a collaboration diagram in UML 1.x.
Component diagram
Depicts the components, including their interrelationships, interactions, and public interfaces, that compose an application, system, or enterprise.
Composite structure diagram
Depicts the internal structure of a classifier (such as a class, component, or use case), including the interaction points of the classifier to other parts of the system.
9
Deployment diagram
Shows the execution architecture of systems, including nodes, either hardware or software execution environments, and the middleware connecting them.
Interaction overview diagram
A variant of an activity diagram, which overviews the control flow within a system or business process ,whereby each node/ activity within the diagram can represent another interaction diagram..
Object diagram
Depicts objects and their relationships at a point in time, typically a special case of either a class diagram or a communication diagram. See
Package diagram
Shows how model elements are organized into packages as well as the dependencies between packages
Sequence diagram
Models sequential logic, in effect the time ordering of messages between classifiers.
State machine diagram
Describes the states an object or interaction may be in, as well as the transitions between states; formerly referred to as a state diagram, state chart diagram, or a state-transition diagram.
Timing diagram
Depicts the change in state or condition of a classifier instance or role over time, and typically used to show the change in state of an object over time in response to external events.
10 Use Case Diagram
Shows use cases, actors, and their relationships.
The figure shows how we have student objects and how we model the class Student
It also shows the standard notations to model a class using the UML
Class names are typically singular nouns, The name of a class should be one or two words
like Student, Professor, and Course, not Students, People Who Teach Seminars
When object-oriented software is running, objects are instantiated (created/defined) from classes. We say an object is an instance of a class and we instantiate those objects from classes. 11
Attributes And Operations/Methods
Classes have responsibilities, the things they know and do
Attributes are the things classes know; methods are the things classes do
The object-oriented paradigm is based on the concepts that systems should be built out of objects, and that objects have both data and functionality.
Attributes define the data, while methods define the functionality
12
Figure 1
13
Figure 2
14
Figure 1 you see two different types of objects: a student and a seminar. Both objects know and do certain things, and you want to make sure you record this in your models Figure 2 I am using the three-section class notation in this case: the top section for the name, the middle section to list the attributes, and the bottom section to list the methods
15
Depicts two types of attributes:
instance attributes, which are applicable to a single object, and static attributes, which are applicable to all instances of a single class
Static attributes are underlined, instance attributes are not.
For example, name is an instance attribute of the class Student. Each individual student has a name; for example, one student may have the name "Smith, John,“
On the other hand, nextStudentNumber is a static attribute (also referred to as a class attribute) that is applicable to the class Student, not specifically to individual instances. This attribute is used to store the value of the next student number to be assigned to a student:
16
Similarly, there is the concept of instance methods and static/class methods
instance methods operate on a single instance, whereas static methods operate potentially on all instances of a single class
you see that Student has instance methods called enrollInSeminar and dropSeminar,
It also has the static method findBy- Name, which supports the behavior of searching for students whose names meet specified search criteria, a method that operates on all instances of the class.
17
Abstraction, Encapsulation, And Information Hiding
Abstraction
To deal with that complexity we form abstractions of the things in it. For example, consider the abstraction of a person. From the point of view of a university, it needs to know the person's name, address, telephone number, social security number, and educational background
OO systems abstract is the act of defining the interface to something
classed marked as abstract (the name is in italics; in previous versions of the UML you could also indicate with the constraint {abstract})
18
Encapsulation
object-oriented world, you modularize systems into classes, which, in turn, are modularized into methods and attributes.
We say that we encapsulate behavior into a class or we encapsulate functionality into a method.
People often say encapsulation is the act of painting the box black: you are defining how something is going to be done, but you are not telling the rest of the world how you are going to do it. In other words you are hiding the details of the implementation of an item from the users of that item 19
Inheritance
Two or more classes often share the same attributes and/or the same methods. Because you do not want to have to write the same code repeatedly, you want a mechanism that takes advantage of these similarities.
Inheritance is that mechanism. Inheritance models "is a", "is kind of", and "is like" relationships, enabling you to reuse existing data and code easily.
For example ,
20
students have names, addresses, and telephone numbers, and they drive vehicles. At the same time, professors also have names, addresses, and telephone numbers, and they drive vehicles. Without a doubt, you could develop the classes for student and professor and get them both running.
This is exactly what inheritance is all about. With inheritance, you define a new class that encapsulates the similarities between students and professors. This new class would have the attributes name, address, and phoneNumber, and the method driveVehicle. Because you need to name all our classes, you need to ask yourself what this collection of data and functionality describes. In this case, I think the name Person is fitting.
21
Modeling Inheritance
depicts the UML modeling notation for inheritance, a line with a closed arrowhead. The way you would read the diagram is "B inherits from A." In other words, B is a direct subclass of A and A is the direct superclass of B
22
presents how you would model the Person inheritance class hierarchy, often simply called a class hierarchy
23
Single and Multiple Inheritance
When a class inherits from only one other class, we call this single inheritance When a class inherits from two or more other classes, we call this multiple inheritance Not all languages support multiple inheritance. C++ is one of the few languages that does Multiple Inheritance Rarely Occurs in the Real World
24
25
Abstract and Concrete Classes
Vehicle is abstract Airplane and car are concrete class The main difference between abstract classes and concrete classes is that objects are instantiated (created) from concrete classes, but not from abstract classes.
26
Persistence
Persistence focuses on the issue of how to make objects available for future use of your software In other words, how to save objects to permanent storage transient object is an object you do not need to save it in a permanent storage
27
Relationships
In the real world, objects have relationships with other objects. The relationships between objects are important because they help us to define how they interact with each other For example:
Not only must you identify what the relationship(s) are between classes, you must also describe the relationship For example:
students take courses professors teach courses,
students take seminars. How many seminars can students take? None, one, or several
Furthermore, relationships are two-way streets
28
not only do students take seminars, but also seminars are taken by students
Associations
An association is a persistent relationship between two or more classes or objects When you model associations in UML class diagrams, you show them as a thin line connecting two classes, as you see :
29
30
Directionality. The open arrowheads indicate the directionality of the association
unidirectional: it can be traversed in one direction only. bi-directional When there is either zero or two arrowheads the association
Label. The label, which is optional, is typically one or two words describing the association Multiplicity. The multiplicity of the association is labeled on either end of the line, one multiplicity indicator for each direction
31
Indicator Meaning 0..1 Zero or one 1 One only 0..* Zero or more 1..* One or more n Only n (where n > 1) 0..n Zero to n (where n > 1) 1..n One to n (where n > 1) UML Multiplicity Indicators
32
Role. The role—the context that an object takes within the association Qualifier. A qualifier is a value that selects an object from the set of related objects across an association
Recursive association or a self association, according to the figure :
33
A perfect example of this is the manages association that the Employee class has with itself The way you read this association is that any given employee may have several other employees he or she manages, and that one other employee may, in turn, manage them
How Associations Are Implemented
Associations are maintained through the combination of attributes and methods The attributes store the information necessary to maintain the relationship and methods keep the attributes current. For example,
34
the Student class have an attribute called takes, perhaps an array, which is used to keep track of the Seminar objects the student is currently taking The Student class might also have methods such as addSeminar and removeSeminar to add and remove seminar objects into the array The Seminar class would have a corresponding attribute called students and methods called addStudent and removeStudent to maintain the association in the opposite direction
Another Example :
35
In Fig. 2., the unidirectional association holds between Employee and Position would be easier to implement because you only need to traverse it in one direction: from Employee to Position. Therefore, Employee would have an attribute called position and methods, called something like setPosition() and getPosition(), to maintain the association There would be nothing added to Position because there is no need for position objects to collaborate with employee objects; therefore, there is no added code to maintain the association in that direction
Aggregation and Composition
Aggregation
represents "is part of" relationships
For example, an airplane is made up of a fuselage, wings, engines, landing gear A project team consists of two or more employees
Composition is a strong form of aggregation in which the "whole" is completely responsible for its parts and each "part" object is only associated to the one whole object
36
For example, at any given time, an engine is part of one and only one airplane composition is depicted in both UML 1.x and UML 2.x as a filled diamond aggregation was depicted in UML 1.x as a hollow diamond
37
Dependencies
Two types of object relationships exist: persistent and transitory. The main difference is persistent associations must be saved, whereas transitory relationships are only temporary in nature and, thus, are not saved Persistent relationships are those that are permanent or, at least semipermanent, in nature
38
For example, the take relationship between students and courses is persistent The teach relationship between professors and courses is persistent for the same reason
Transitory associations are temporary in nature. They are not saved to permanent storage Transitory relationships usually involve at least one transitory object, such as a screen or report. you see there is a dependency relationship— modeled as a dashed line with an open arrowhead—between the classes Student and Student Editing Screen, representing the transitory relationship between a studentediting screen object as it updates the student object.
39
The editing screen obtains the current information from the student object, displays it in editing mode, and then updates the student object with the new information once it is finished. The transitory relationship between the editing screen object and the student object exists as long as the student information is displayed on the screen. Once the screen is closed, the relationship no longer exists (the screen likely does not exist either) and the transient objects are most likely destroyed.
40
Collaboration
Collaboration occurs between objects when one object asks another for information or to do something Objects collaborate with one another by sending each other messages A message is either a request to do something or a request for information Messages are modeled in UML sequence diagrams and UML communication diagrams
41
Sequence diagram
42
Communication Diagram
43
Polymorphism
An individual object may be one of several types
For example, a John Smith object may be a student, a registrar, or even a professor
for example ,Polymorphism at the University
44
example of polymorphism by exploring the design of how the university handles the hiring of new staff a standard process for hiring staff at the university: once a person is hired, she is added to the university pension plan and an employee card is created for her. When a professor is hired at the university, the same process is followed, with the addition of a parking space assigned to her (if there is no parking space, the professor is added to the waiting list).
45
Related Documents
Advance System Analysis L2
June 2020 5
Advance System Analysis L1
June 2020 10
Advance System Analysis L5
June 2020 4
Charging System L2
June 2020 4