Advance system analysis

Understanding the Basics–Object-Oriented

Concepts

1
Understanding the Basics–Object-
Oriented 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
 The grouping of related concepts into one item, such as a class or a component

3
 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
  To redefine attributes and/or methods in subclasses so that they are different
from the definition in the super class
 Persistence
 The storing of objects to permanent storage, for example, files, databases, etc.
 Polymorphism
 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
 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 direct inheritance from only one class
 Subclass
 A class that inherits from another class
 Superclass
 A class from which another class inherits

5
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:
 activity,
 state machine,
 and use case diagrams,
 as well as the four interaction diagrams.
 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
 class,
 composite structure,
 component,
 deployment,
 object,
 and package diagrams.

7
Objects and Classes
 The OO paradigm is based on building systems from
items called objects.
 An object is any person, place, thing, event, concept,
screen, or report
 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,
 Sarah is a customer object. She has a checking account
object from which she bounces rubber-check objects.
 Example In an inventory control system,
 every inventory item is an object, every delivery is an
object, and every customer is an object

8
The Diagrams of UML 2
Activity diagram
Class diagram
Communication diagram
Component diagram
Composite structure diagram
9
Depicts high-level business processes, including data flow, or to
model the complex logic within a system.
Shows a collection of static model elements such as classes and
types, their contents, and their relationships.
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.
Depicts the components, including their interrelationships,
interactions, and public interfaces, that compose an application,
system, or enterprise.
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.
Deployment diagram
Interaction overview diagram
Object diagram
Package diagram
Sequence diagram
State machine diagram
Timing diagram
10
Use Case Diagram
Shows the execution architecture of systems, including nodes, either
hardware or software execution environments, and the middleware
connecting them.
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..
Depicts objects and their relationships at a point in time, typically a
special case of either a class diagram or a communication diagram. See
Shows how model elements are organized into packages as well as the
dependencies between packages
Models sequential logic, in effect the time ordering of messages between
classifiers.
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.
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.
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 ,
 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.

20
 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:
 students take courses
 professors teach courses,
 Not only must you identify what the relationship(s)
are between classes, you must also describe the
relationship
 For example:
 students take seminars. How many seminars can students
take? None, one, or several
 Furthermore, relationships are two-way streets
 not only do students take seminars, but also seminars are
taken by students

28
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
 Role. The role—the
1 One only context that an
0..* Zero or more object takes within
1..* One or more
the association
n Only n (where n > 1)
0..n Zero to n (where n > 1)  Qualifier. A qualifier
1..n One to n (where n > 1) is a value that
UML Multiplicity Indicators
selects an object
from the set of
related objects
across an association

32
 Recursive association or a self association,
according to the figure :
 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

33
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,
 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

34
 Another Example :
 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

35
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
 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

36
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
 For example, the take relationship between
students and courses is persistent
 The teach relationship between professors and
courses is persistent for the same reason

38
 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 student-
editing 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
 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).

44
45