Unit 1 OOSE

Object Oriented Concepts,
Modeling and UML
Success Publication
O S
O E
UNIT
1
1.1 Object-Oriented Concepts
1.2 Model
1.3 Object Oriented System Development
1.4 Identifying the Elements of an Object Model
1.5 Introduction to Unified Modeling Language (UML)

Introduction
 Conventional using high-level languages such as COBOL, FORTRAN and C, is commonly
known as procedure oriented programming (POP). In the procedure-oriented approach,
the problem is viewed as a sequence of things to be done such as reading, calculating and
printing.
 In addition, number of functions is written to accomplish these tasks. The primary focus is
on functions. The major motivating factor in the invention of object-oriented approach is
to remove some of the flaws encountered in the procedural approach.
 OOP treats data as a critical element in the program development and does not allow it to
flow freely around the system.
 It ties data more closely to the functions that operate on it, and protects it from accidental
modification from outside functions. OOP allows decomposition of a problem into a
number of entities called objects and then builds data and functions around these objects.

1.1. Object-Oriented Concepts
Object-oriented programming (OOP) is a programming paradigm that represents concepts as
"objects" that have data fields (attributes that describe the object) and associated procedures
known as methods.
A) What is Object Orientation?
Object Orientation is a bottom up approach of solving real world problem where individual
objects are combined or assembled to provide the solutions of the underlying problem. In
object, orientation instead of writing subroutines the programmer can assemble the object
and generate the desired result. An object is a physical instance of the class that has the
attributes defined in class and it can execute the methods defined in the class.
B) Benefits of Object Oriented Programming:
OOP offers several benefits to both the program designer and the user, which are as
follows:

1) Modularity:
The source code for a class can be written and maintained independently of the source
code for other classes. Once created, an object can be easily passed around inside the
system.
2) Information-Hiding:
By interacting only with an object's methods, the details of its internal implementation
remain hidden from the outside world.
3) Code Reuse:
If a class already exists, user can use objects from that class in program. This allows
programmers to implement/test/debug complex, task-specific objects, which can then
use in own code.
4) Easy Debugging:
If a particular object turns out to be a problem, user can simply remove it from
application and plug in a different object as its replacement. This is analogous to fixing
mechanical problems in the real world. If a bolt breaks, not the entire machine.
5) Communication:
Programmer can build programs from the standard working modules that communicate
with one another, rather than having to start writing the code from scratch. This leads to
saving of development time and higher productivity.

6) Security:
The principle of data hiding helps the programmer to build secure programs that cannot
be invaded by code in other parts of the program.
7) Multiple Instances:
It is possible to have multiple instances of an object to co-exist without any interference.
8) Centralized:
The data centered design approach enables us to capture more details of a model in
implementable form.
9) Message passing:
Message passing techniques for communication between objects makes the interface
descriptions with external systems much simpler.
10)Manageable:
Software complexity can be easily managed.

C) Basic Concepts of Object Oriented Programming:
It is necessary to understand some of the concepts used extensively in object-oriented
programming. The principle concepts of OOP’s are as follows:

1) Object:
In computer science, an object is a location in memory having a value and referenced by
an identifier. An object can be a variable, function, or data structure. With the later
introduction of object-oriented programming, the same word, "object," refers to a
particular instance of a class.
2) Class:
In object-oriented programming, a class is a construct that is used to define a
distinct type. The class is instantiated into instances of itself – referred to as class
instances, class objects, instance objects or simply object.
3) Data Abstraction:
Abstraction is the process by which data
and programs are defined with
a representation similar in form to its meaning
(semantics), while hiding away
the implementation details. Abstraction tries to
reduce and factor out details so that
the programmer can focus on a few concepts at a
time.

4) Encapsulation:
Encapsulation is one of the fundamentals of OOP (object-oriented programming).
Encapsulation is used to hide the values or state of a structured data object inside a
class, preventing unauthorized parties direct access to them. Publicly accessible
methods are generally provided in the class (so-called getters and setters) to access the
values, and other client classes call these methods to retrieve and modify the values
within the object.
My Car
Accelerate
Change Car
Brake
Brand: Aston
Speed: 65 mph
Gear: 4th
Color: Silver
Other Object
Access Allowed
Access Denied

5) Inheritance:
Object oriented programming supports the concept of hierarchical classification. The
principle behind this sort of division is that each derived class shares common
characteristics with the class from which it is derived. In OOP, the concept of inheritance
provides the idea of reusability. Inheritance is the process by which objects of one class
acquire the properties of objects of another class.

6) Polymorphism:
Polymorphism, a Greek term, means the ability to take more than one form. An
operation may exhibit different behaviors in different instances. The behavior depends
upon the types of data used in the operation.
Polymorphism plays an important role in allowing objects having different internal
structures to share the same external interface. This means that a general awareness
class of operations may be accessed in the same manner even through specific actions.

7) Methods:
Methods are similar to functions, they belongs to classes or objects and usually
expresses the verbs of the objects/class.
8) Message Passing:
Message passing is a form of communication used in object oriented programming
and inter-process communication. In this model, processes, or objects can send and
receive messages to other processes. By waiting for messages, processes can
also synchronize.
9) Interface:
An interface is a contract between a class and the outside world. When a class
implements an interface, it promises to provide the behavior published by that
interface. Implementing an interface allows a class to become more formal about the
behavior it promises to provide.
10)Access Control:
Class Rules:
 There can only be one public class per source code file.
 The name of the public class must match the name of the file.
 If the class is part of a package, this must be the first line of code.
 Import declarations must be between package details and the class declaration.
 Import and package statements apply to all classes within the source code file.

D) Characteristics of Object Oriented Programming:
Some basic characteristics of the Object Oriented programming are:
Focus on Data
Follows Bottom
Up Approach
Class
Definitions
Objects
Abstraction
Encapsulation
Inheritance and
Class Hierarchy
Polymorphism
Generic Classes
Class Libraries

1) Focus on Data:
OOP emphasis on data rather than procedure; Data is the basic element object oriented
programming.
2) Follows Bottom Up Approach:
It follows bottom up design in program design. In a bottom-up approach, the individual
base elements of the system (i.e. data) are first specified in great detail. These elements
are then linked together to form larger subsystems.
3) Class Definitions:
Basic building blocks OOP and a single entity, which has data and operations on data
together.
4) Objects:
The instances of a class which are used in real functionality its variables and operations.
5) Abstraction:
Specifying what to do but not how to do, flexible features for having overall view of an
object’s functionality

6) Encapsulation:
Encapsulation means binding data and operations of data together in a single unit. A
class adhere this feature.
7) Inheritance and Class Hierarchy:
Reusability and extension of existing classes.
8) Polymorphism:
Multiple definitions for a single name - functions with same name with different
functionality; saves time in investing many function names Operator and Function
overloading.
9) Generic Classes:
Generic Classes contains definitions for unspecified data. They are known as container
classes. They are flexible and reusable.
10)Class Libraries:
Class libraries contains built-in classes i.e. class which is already implemented and stored
somewhere. It is just use by different users.

1.2. Model
We use models when we think about problems and when we talk to each other, and when we
construct mechanisms and when we try to understand phenomena and when we teach. In
short, we use models all the time. That means: models have never been invented, they have
been around (at least) since humans started to exist.
A) Introduction to Modeling:
a) Concept of Model:
The term “model" is derived from the Latin word modulus, which means measure, rule,
pattern, example to be followed. Obvious examples are toy railways and dolls, maps,
architectural models of buildings. In software engineering, we have process models,
design patterns, class diagrams. Other models are less obvious, like project plans,
specifications and designs, metrics, and minutes of project meetings.
b) Role of Modeling in Engineering:
The role of modeling in engineering is similar. Models help in developing artifacts by
providing information about the consequences of building those artifacts before they
are actually made. Such information may be highly formal (like the theory of mechanics.
as it is applied in the construction of bridges. or the theory of computational complexity
which is used in the analysis of algorithms) or rather informal (like a rough drawing of a
machine, or a textual specification of a software system). Interface definitions are
models too; they are particularly important for the spreading of technology.

1.2. Model
c) The Model Criteria:
In order to distinguish models from other artefacts, we need criteria. According to
Stachowiak, any candidate must meet three criteria, or otherwise it is not a model:
1) Mapping Criterion:
There is an original object or phenomenon that is mapped to
the model. In the sequel, this original object or phenomenon is
referred to as "the original".
2) Reduction Criterion:
Not all the properties of the original are mapped on to the
model, but the model is somehow reduced. On the other hand,
the model must mirror at least some properties of the original.
3) Pragmatic Criterion:
The model can replace the original for some purpose, i.e. the
model is useful.
Mapping
Criterion
Reduction
Criterion
Pragmatic
Criterion

1.2. Model
d) Principles of Modeling:
The use of modeling has a rich history in all the engineering disciplines. That experience
suggests four basic principles of modeling.
‘No single model or view is sufficient. Every nontrivial system is best approached
through a small set of nearly independent models with multiple viewpoints’
‘The best models are connected to reality’
‘Every model may be expressed at different levels of precision’
‘The choice of what models to create has a profound influence on how a problem is
attacked and how a solution is shaped’

1.2. Model
1) ‘The choice of what models to create has a profound influence on how a problem is
attacked and how a solution is shaped’:
In other words, choose your models well. The right models will brilliantly illuminate
the most wicked development problems, offering insight that you simply could not
gain otherwise; the wrong models will mislead you, causing you to focus on irrelevant
issues. Setting aside software for a moment, suppose you are trying to tackle a
problem in quantum physics. Certain problems, such as the interaction of photons in
space-time, are full of wonderfully hairy mathematics.
2) ‘Every model may be expressed at different levels of precision’:
If you are building a high rise, sometimes you need a 30,000-foot view for instance,
to help your investors visualize its look and feel. Other times, you need to get down
to the level of the studsfor instance, when there's a tricky pipe run or an unusual
structural element. The same is true with software models. Sometimes a quick and
simple executable model of the user interface is exactly what you need; at other
times you have to get down and dirty with the bits, such as when you are specifying
cross-system interfaces or wrestling with networking bottlenecks.

1.2. Model
3) ‘The best models are connected to reality’:
A physical model of a building that doesn't respond in the same way as do real
materials has only limited value; a mathematical model of an aircraft that assumes
only ideal conditions and perfect manufacturing can mask some potentially fatal
characteristics of the real aircraft.
4) ‘No single model or view is sufficient. Every nontrivial system is best approached
through a small set of nearly independent models with multiple viewpoints’:
If you are constructing a building, there is no single set of blueprints that reveal all its
details. At the very least, you'll need floor plans, elevations, electrical plans, heating
plans, and plumbing plans. And within any kind of model, you need multiple views to
capture the breadth of the system, such as blueprints of different floors.

1.2. Model
B) Object Oriented Modeling:
Object-oriented modeling is a way of constructing visual models based on real-world
objects. Modeling helps in understanding the problems, developing proper documents and
producing well-designed programs. Modeling produces well-understood requirements,
robust designs and high quality maintainable systems. The models must depict the various
views of the system and these models must be verified to check whether they capture the
customer‘s requirements. After they represent the required details, these models may be
transformed into source code. Due to the increase in object-oriented techniques and
complexity of the software, various challenges are faced by the system designers. Modeling
helps to visualize, organize, document and understand complex relationships, and to
produce well-designed systems.

1.3. Object Oriented System Development
The definition of a good system varies in certain respects between different applications. In
some, it is performance that is important and in others perhaps user-friendliness. It can, in
fact, depend on the structure of the system, for instance, whether it is distributed or
centralized. What is common to all (larger) systems is that they will need to be modified.
A) Function / Data Methods:
The existing methods for system development can basically be divided into function/data
methods and object-oriented methods. By function/data methods we mean those methods
that treat functions and/ or data as being more or less separate. Object-oriented methods
view functions and data as highly integrated. These paradigms are shown schematically in
Figure 1.7.

A) Function / Data Methods:
1) Mechanism of Function / Data Methods:
Function/data methods distinguish between functions and data, where functions, in
principle, are active and have behavior, and data is a passive holder of information
which is affected by functions.
2) Problems of Using Function / Data Methods:
Following are the major problems of using function / data methods:
a) Difficult to Maintain:
A system developed using a function/data method often becomes difficult to
maintain. A major problem with function/data methods is that, in principle, all
functions must know how the data is stored, that is, its data structure. It is often the
case that different types of data have slightly different data formats, which means
that we often need condition clauses to verify the data type.
b) Unstable:
Furthermore, to change a data structure, we must modify all the functions relating to
the structure. Systems developed using such methods often become quite unstable;
a slight modification will generate major consequences. In the same way, the
instability of the development process will become unnecessarily lasting, as any
modifications made will create consequences in other areas.

B) Object-Oriented Analysis:
The purpose of object-oriented analysis, as with all other analysis, is to obtain an
understanding of the application: an understanding depending only on the system’s
functional requirements.
a) Difference Between Object-Oriented Analysis and Function/Data Analysis:
The difference between object-oriented analysis and function/data analysis is the means
of expression. While function/data analysis methods commence by considering the
system’s behavior and/or data separately, object-oriented analysis combines them and
regards them as integrated objects.
b) Activities of Object Oriented Analysis:
Object-oriented analysis contains the following activities:
Finding the
Objects
Organizing the
Objects
Object
Interaction
Operations of
the Objects
Object
Implementation

B) Object-Oriented Analysis:
b) Activities of Object Oriented Analysis:
1) Finding the Objects:
The objects can be found as naturally occurring entities in the application domain. An
object becomes typically a noun which exists in the domain and, because of this, it is
often a good start to learn the terminology for the problem domain.
2) Organizing the Objects:
There are a number of criteria to use for the classification and organization of objects
and classes of objects. One classification starts by considering how similar classes of
objects are to each other.
3) Object Interaction:
In order to obtain a picture of how the object fits into the system, we can describe
different scenarios or use cases in which the object takes part and communicates
with other objects.
4) Operations of the Objects:
The object’s operations come naturally when we consider an object’s interface. The
operations can also be identified directly from the application, when we consider
what can be done with the items we model.
5) Object Implementation:
Finally, the object should be defined internally, which includes defining the
information that each object must hold.

C) Object Oriented Construction:
Object-oriented construction means that the analysis model is designed and implemented
in source code. This source code is executed in the target environment, which often means
that the ideal model produced by the analysis model must be molded to fit into the
implementation environment.
a) Goal of Object Oriented Construction:
The goal of OO Construction is that the objects identified during the analysis should also
be found within the design. We call this traceability. We must therefore have
straightforward rules for transforming the analysis model into a design model and the
programming language. The objects may be implemented using previously developed
source code. We call such parts components. Such components are often simpler to
create in an object-oriented environment, owing to the integration of functions and
data.
b) Paradigm Shift:
The opposite procedure, to go from object-oriented analysis to traditional programming,
also incurs a paradigm shift. However, this causes less of a problem as, even for non-
object-oriented languages, we can structure the system to be object-oriented.
Additionally, we can program in an object-oriented style, even for other languages.
Hence object-orientation is also a style of programming and not only the name of a
programming language family having language constructs such as inheritance,

D) Object Oriented Testing:
The testing of a system which has been developed with an object-oriented method does
not differ considerably from the testing of a system developed by any other method. In
both cases, we verify the system, namely check that we have correctly designed the system
in accordance with a specification.
a) Integration testing:
The program testing begins at the lowest level, with unit testing, and progresses to
integration testing, where the units are tested together to see that they interact
correctly. Finally, testing of the entire system is done. Traditionally, integration testing is
usually a 'big bang' event and is very critical during system development.
b) Testing of Inheritance Hierarchies:
Testing of inheritance hierarchies requires a more exhaustive testing method; you must
be aware of how the system will appear in operation. For instance, it is not always true
that if you- test an operation higher up in an inheritance hierarchy a test is not required
lower down.
c) Regression and Automated Testing:
Regression and automated testing therefore often play a larger role in the testing of
systems developed using an object-oriented technique. Here one must, though, be
careful about which test data is used. If you override operations in a descendant, the
test data developed earlier may not be adequate for the new operation.

1.4. Identifying the Elements of an Object Model
The elements of an object model-classes and objects, attributes, operations, and messages-
were each defined and discussed in the preceding section. But how do we identifying these
elements for an actual problem? The sections given below present a series of informal
guidelines that will assist in the identification of the elements of the object model.
….Identifying Classes and Objects….
If we look around a room, there is a set of physical objects that can be easily identified,
classified, and defined (in terms of attributes and operations). But when we "look around" the
problem space of a software application, the objects may be more difficult to comprehend.
A) Categorization of Object:
 External entities (e.g., other systems, devices, people) that produce or consume
information to be used by a computer-based system.
 Things (e.g., reports, displays, letters, signals) that are part of the information domain
for the problem.
 Occurrences or events (e.g., a property transfer or the completion of a series of robot
movements) that occur within the context of system operation.
 Roles (e.g., manager, engineer, salesperson) played by people who interact with the
system.
 Organizational units (e.g., division, group, team) that is relevant to an application.
 Places (e.g., manufacturing floor or loading dock) that establish the context of the
problem and the overall function of the system.

B) Selection Characteristics:
Coad and Yourdon suggest six selection characteristics that should be used as an analyst
considers each potential object for inclusion in the analysis model:
Retained
Information
Needed
Services
Multiple
Attributes
Common
Attributes
Common
Operations
Essential
Requirements

B) Selection Characteristics:
1) Retained Information:
The potential object will be useful during analysis only if information about it must be
remembered so that the system can function.
2) Needed Services:
The potential object must have a set of identifiable operations that can change the value
of its attributes in some way.
3) Multiple Attributes:
During requirement analysis, the focus should be on "major" information; an object with
a single attribute may.
4) Common Attributes:
A set of attributes can be defined for the potential object and these attributes apply to
all occurrences of the object.
5) Common Operations:
A set of operations can be defined for the potential object and these operations apply to
all occurrences of the object.
6) Essential Requirements:
External entities that appear in the problem space and produce or consume information
essential to the operation of any solution for the system will almost always be defined.

…. Specifying Attributes ….
Attributes describe an object that has been selected for inclusion in the analysis model. In
essence, it is the attributes that define the object-that clarify what is meant by the object in
the context of the problem space.
To illustrate, we consider (above example) the system object defined for XYZ. Homeowner can
configure the security system to reflect sensor information, alarm response information,
activation/deactivation information, identification information, and so forth.
Using the content description notation defined for the data dictionary, we can represent these
composite data items in the following manner:
 sensor information = sensor type + sensor number + alarm threshold
 alarm response information = delay time + telephone number + alarm type
 activation/deactivation information = master password + number of allowable tries +
temporary password
 identification information = system ID + verification phone number + system status
Each of the data items to the right of the equal sign could be further defined to an elementary
level, but for our purposes, they constitute a reasonable list of attributes for the system object.

…. Defining Operations ….
Operations define the behavior of an object and change the object’s attributes in some way.
More specifically, an operation changes one or more attribute values that are contained within
the object. Therefore, an operation must have "knowledge" of the nature of the objects
attributes and must be implemented in a manner that enables it to manipulate the data
structures that have been derived from the attributes.
For example:
From the XYZ processing narrative, we see that "sensor
is assigned a number and type" or that "a master
password is programmed for arming and disarming the
system." These two phrases indicate a number of
things:
 That can assign operation is relevant for the sensor
object.
 That a program operation will be applied to the
system object.
 That arm and disarm are operations that apply to
system (also that system status may ultimately be
defined (using data dictionary notation) as

…. Finalizing the Object Definition ….
The definition of operations is the last step in completing the specification of an object.
Operations were culled from a grammatical parse of the processing narrative for the system.
Additional operations may be determined by considering the "life history" of an object and the
messages that are passed among objects defined for the system.
A) Life History of An Object:
The generic life history of an object can be defined by recognizing that the object must be
created, modified, manipulated or read in other ways, and possibly deleted. For the system
object, this can be expanded to reflect known activities that occur during its life (in this
case, during the time that XYZ is operational). Some of the operations can be ascertained
from likely communication between objects.
For example:
Sensor event will send a message to system to display the event location and number;
control panel will send system a reset message to update system status; the audible alarm
will send a query message; the control panel will send a modify message to change one or
more attributes without reconfiguring the entire system object; sensor event will also send
a message to call the phone number(s) contained in the object. Other messages can be
considered and operations derived. The resulting object definition is shown in figure.

1.5. Introduction to Unified Modeling Language (UML)
UML is a standard language for specifying, visualizing, constructing, and documenting the
artifacts of software systems. UML was created by Object Management Group and UML 1.0
specification draft was proposed to the OMG in January 1997.
….Overview of UML….
UML stands for Unified Modeling Language.
 UML is different from the other common programming languages like C++, Java, COBOL etc.
 UML is a pictorial language used to make software blue prints.
So UML can be described as a general purpose visual modeling language to visualize, specify,
construct and document software system. Although UML is generally used to model software
systems but it is not limited within this boundary. It is also used to model non software
systems as well like process flow in a manufacturing unit etc.
A) Goals of UML:
A picture is worth a thousand words, this absolutely fits while discussing about UML. Object
oriented concepts were introduced much earlier than UML. So at that time there were no
standard methodologies to organize and consolidate the object oriented development. At
that point of time UML came into picture.
There are a number of goals for developing UML but the most important is to define
some general purpose modeling language which all modelers can use and also it needs to
be made simple to understand and use.

B) Advantages of UML:
UML, the unified modeling language, is a standard used to visually describe a program,
specifically an object-oriented program.
1) Visual Representation:
A UML diagram is a visual representation of the relationships between classes and
entities in a computer program. A class is an object in programming that organizes
similar variables and functions in one location. To understand a program, it is essential
to understand what each class object does, the information it stores and how it relates
to other classes in the program.
Planning Tool
Standard
Readability and Re-usability
Visual Representation

B) Advantages of UML:
2) Readability and Re-usability:
A UML diagram is beneficial in that it is very readable. The diagram is meant to be
understood by any type of programmer and helps to explain relationships in a program
in a straightforward manner. Traditionally, to understand a program, a programmer
would read the code directly.
3) Standard:
UML is the current standard for programming in object-oriented programming
languages. When creating classes and other objects with relationships between each
other, UML is what is used to visually describe these relationships. Because it is used as
a standard, it is widely understood and well known.
4) Planning Tool:
UML helps to plan a program before the programming takes place. In some tools used to
model UML, the tool will generate code based on the classes set up in the model. This
can help reduce overhead during the implementation stage of any program.

C) Applications of UML:
The UML is intended primarily for software-intensive systems. It has been used effectively
for such domains as
 Enterprise information systems
 Banking and financial services
 Telecommunications
 Transportation
 Defense/aerospace
 Retail
 Medical electronics
 Scientific
 Distributed Web-based services
The UML is not limited to modeling software. In fact, it is expressive enough to model non
software systems, such as workflow in the legal system, the structure and behavior of a
patient healthcare system, software engineering in aircraft combat systems, and the design
of hardware.

…. Conceptual Model of UML….
As UML describes the real time systems it is very important to make a conceptual model and
then proceed gradually. Conceptual model of UML can be mastered by learning the following
three major elements:
 UML building blocks
 Rules to connect the building blocks
 Common mechanisms of UML
A) UML Building Blocks:
The building blocks of UML are described as follows:
Things Relationship UML Diagrams

The building blocks of UML are described as follows:
1) Things:
Things are the most important building blocks of UML. Things can be:
a) Structural Things:
The Structural things define the static part of the model. They represent physical and
conceptual elements. Following are the brief descriptions of the structural things.
1) Class:
Class represents set of objects having similar responsibilities.
Things
Structural Things
Behavioral
Things
Grouping Things
Annotational
Things
Class
Attributes
Operations

1) Things:
2) Interface:
Interface defines a set of operations which specify the responsibility of a class.
3) Collaboration:
Collaboration defines interaction between elements.
4) Use Case:
Use case represents a set of actions performed by a system for a specific goal.
Interface
Use case

1) Things:
5) Component:
Component describes physical part of a system.
6) Node:
A node can be defined as a physical element that exists at run time.
Component
Node

1) Things:
b) Behavioral Things:
A behavioral thing consists of the dynamic parts of UML models. Following are the
behavioral things:
1) Interaction:
Interaction is defined as a behavior that consists of a group of messages
exchanged among elements to accomplish a specific task.
2) State Machine:
State machine is useful when the state of an object in its life cycle is important. It
defines the sequence of states an object goes through in response to events.
Events are external factors responsible for state change.
Message
State

1) Things:
c) Grouping Things:
Grouping things can be defined as a mechanism to group elements of a UML model
together. There is only one grouping thing available:
1) Package:
Package is the only one grouping thing available for gathering structural and
behavioral things.
d) Annotational Things:
Annotational things can be defined as a mechanism to capture remarks, descriptions,
and comments of UML model elements. Note is the only one Annotational thing
available.
1) Note:
Package
note

2) Relationship:
Relationship is another most important building block of UML. It shows how elements
are associated with each other and this association describes the functionality of an
application. There are four kinds of relationships available.
a) Dependency:
Dependency is a relationship between two things in which change in one element
also affects the other one.
b) Association:
Association is basically a set of links that connects elements of an UML model. It also
describes how many objects are taking part in that relationship.
Dependency

2) Relationship:
c) Generalization:
Generalization can be defined as a relationship which connects a specialized element
with a generalized element. It basically describes inheritance relationship in the
world of objects.
d) Realization:
Realization can be defined as a relationship in which two elements are connected.
One element describes some responsibility which is not implemented and the other
one implements them. This relationship exists in case of interfaces.

3) UML Diagrams:
UML diagrams are the ultimate output of the entire discussion. All the elements,
relationships are used to make a complete UML diagram and the diagram represents a
system. The visual effect of the UML diagram is the most important part of the entire
process. All the other elements are used to make it a complete one. UML includes the
following nine diagrams
 Class diagram
 Object diagram
 Use case diagram
 Sequence diagram
 Collaboration diagram
 Activity diagram
 State-chart diagram
 Deployment diagram
 Component diagram

B) Rules of the UML:
The UML's building blocks can't simply be thrown together in a random fashion. Like any
language, the UML has a number of rules that specify what a well-formed model should
look like. A well-formed model is one that is semantically self-consistent and in harmony
with all its related models. The UML has syntactic and semantic rules for
a) Names:
What you can call things, relationships, and diagrams.
b) Scope:
The context that gives specific meaning to a name.
c) Visibility:
How those names can be seen and used by others.
d) Integrity:
How things properly and consistently relate to one another.
e) Execution:
What it means to run or simulate a dynamic model

C) Common Mechanisms in the UML:
A building is made simpler and more harmonious by the conformance to a pattern of
common features. A house may be built in the Victorian or French country style largely by
using certain architectural patterns that define those styles. The same is true of the UML.
1) Specifications:
The UML is more than just a graphical language. Rather, behind every part of its
graphical notation there is a specification that provides a textual statement of the syntax
and semantics of that building block. For example, behind a class icon is a specification
that provides the full set of attributes, operations (including their full signatures), and
behaviors that the class embodies; visually, that class icon might only show a small part
of this specification.
Specifications Adornments
Common
Divisions
Extensibility
Mechanisms

2) Adornments:
Most elements in the UML have a unique and direct graphical notation that provides a
visual representation of the most important aspects of the element.
For example, the notation for a class is intentionally designed to be easy to draw,
because classes are the most common element found in modeling object-oriented
systems. The class notation also exposes the most important aspects of a class, namely
its name, attributes, and operations.
Every element in the UML's notation starts with a basic symbol, to which can be added a
variety of adornments specific to that symbol.

3) Common Divisions:
In modeling object-oriented systems, the world often gets divided in several ways. First,
there is the division of class and object. A class is an abstraction; an object is one
concrete manifestation of that abstraction. In the UML, you can model classes as well as
objects, as shown in Figure 1.8. Graphically, the UML distinguishes an object by using the
same symbol as its class and then simply underlying the object's name.
In this figure, there is one class, named Customer, together with three objects: Jan
(which is marked explicitly as being a Customer object), :Customer (an anonymous
Customer object), and Elyse (which in its specification is marked as being a kind of
Customer object, although it's not shown explicitly here).

4) Extensibility Mechanisms:
The UML provides a standard language for writing software blueprints, but it is not
possible for one closed language to ever be sufficient to express all possible nuances of
all models across all domains across all time. For this reason, the UML is opened-ended,
making it possible for you to extend the language in controlled ways. The UML's
extensibility mechanisms include:
Stereotype
Tagged
Value
Constraint
a) Stereotype:
A stereotype extends the vocabulary of the UML, allowing you to
create new kinds of building blocks that are derived from existing
ones but that are specific to your problem.
b) Tagged Value:
A tagged value extends the properties of a UML stereotype,
allowing you to create new information in the stereotype's
specification.

4) Extensibility Mechanisms:
c) Constraint:
A constraint extends the semantics of a UML building block, allowing you to add new
rules or modify existing ones.
Collectively, these three extensibility mechanisms allow you to shape and grow the
UML to your project's needs. These mechanisms also let the UML adapt to new
software technology, such as the likely emergence of more powerful distributed
programming languages.

…. Architecture….
Visualizing, specifying, constructing, and documenting a software-intensive system demands
that the system be viewed from a number of perspectives. Different stakeholders end users,
analysts, developers, system integrators, testers, technical writers, and project managers each
bring different agendas to a project, and each looks at that system in different ways at
different times over the project's life.
Architecture is the set of significant decisions about
 The organization of a software system.
 The selection of the structural elements and their interfaces by which the system is
composed.
 Their behavior, as specified in the collaborations among those elements.
 The composition of these structural and behavioral elements into progressively larger
subsystems.
 The architectural style that guides this organization: the static and dynamic elements and
their interfaces, their collaborations, and their composition.

As Figure below illustrates, the architecture of a software-intensive system can best be
described by five interlocking views. Each view is a projection into the organization and
structure of the system, focused on a particular aspect of that system.

1) Use Case View:
The use case view of a system encompasses the use cases that describe the behavior of the
system as seen by its end users, analysts, and testers. This view doesn't really specify the
organization of a software system.
2) Design View:
The design view of a system encompasses the classes, interfaces, and collaborations that
form the vocabulary of the problem and its solution. This view primarily supports the
functional requirements of the system, meaning the services that the system should
provide to its end users.
3) Interaction View:
The interaction view of a system shows the flow of control among its various parts,
including possible concurrency and synchronization mechanisms. This view primarily
addresses the performance, scalability, and throughput of the system.
4) Implementation View:
The implementation view of a system encompasses the artifacts that are used to assemble
and release the physical system. This view primarily addresses the configuration
management of the system's releases, made up of somewhat independent files that can be
assembled in various ways to produce a running system.

5) Deployment View:
The deployment view of a system encompasses the nodes that form the system's hardware
topology on which the system executes. This view primarily addresses the distribution,
delivery, and installation of the parts that make up the physical system.

Unit 1 OOSE

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Unit 1 OOSE

Semelhante a Unit 1 OOSE (20)

Último

Último (20)

Unit 1 OOSE