Christ College-Pune Department of Computer Science: Object Oriented Software Engineering

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 55

Christ College- Pune

Department of Computer Science


Object Oriented Software
Engineering
Prof – Kirti Nikam
O O S E

UNIT Object Oriented


1 Concepts, Modeling and
UML
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.
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.

Benefits of Object Oriented Programming:


OOP offers several benefits to both the program designer and the user, which are as
follows: Information-
Modularity Information- Code
Modularity Hiding Code Reuse
Reuse Easy
Easy Debugging
Debugging Communication
Communication
Hiding

Multiple
Multiple
Security
Security Centralized
Centralized Message
Message passing
passing Manageable
Manageable
Instances
Instances
1.1. Object-Oriented Concepts

Benefits of Object Oriented Programming:


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.
1.1. Object-Oriented Concepts

Benefits of Object Oriented Programming:


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.
1.1. Object-Oriented Concepts

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:
Object
Object
Access
Access Class
Class
Control
Control

Data
Data
Interface
Interface Abstraction
Abstraction

Basic
Message
Concepts
Message Encapsulation
Passing Encapsulation
Passing

Methods
Methods Inheritance
Inheritance
Polymorphis
Polymorphis
m
m
1.1. Object-Oriented Concepts

Basic Concepts of Object Oriented Programming:


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.
1.1. Object-Oriented Concepts

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 Access Allowed
Brake
Other Object

Brand: Aston
Speed: 65 mph
Gear: 4th
Color: Silver
Access Denied
1.1. Object-Oriented Concepts

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.
1.1. Object-Oriented Concepts

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.

Example: If you take + operator


2+2=4(addition) in Numeric form
A+B=AB(concatenation) String form

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.
1.1. Object-Oriented Concepts

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.
1.1. Object-Oriented Concepts

D) Characteristics of Object Oriented Programming:


Some basic characteristics of the Object Oriented programming are:
Focus on Data

Follows Bottom
Class Libraries
Up Approach

Class
Generic Classes
Definitions

Polymorphism Objects

Inheritance and Abstraction


Class Hierarchy

Encapsulation
1.1. Object-Oriented Concepts
D) Characteristics of Object Oriented Programming:
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
1.1. Object-Oriented Concepts

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
1. A Model is a simplification of reality.
2. A model is an abstraction of something for the purpose of understanding it before building
it.
3. A model can be defined as “an abstraction of something before it is actually developed”.
4. We built models so that we can better understand the system we are developing through
modeling.
Aims:
1.Model helps us to visualize the system as it is or as we want it to be.
2.Model permit us to verify the structure or behavior of a system.
3.Models document the decision we have made.

Models can represent static or dynamic.


Static Model:
1.Static models are needed to represent the structural or static aspect of the system.
2. Static Model have stability & no change in the data in future.
Ex. UML Class Diagram

Dynamic Model: Dynamic models can be viewed as a collection of procedures or


behaviors that taken together.
Ex. UML Interactive & Activity Diagram
1.2. Model

Introduction to Modeling:
1. Modeling is the designing of software/system applications before coding/developing.
2. Modeling is done at the beginning of the process.

Reasons:
1 Communication
2. Abstraction

1.Communication:
 Users typically cannot understand programming language code.
 Model diagrams can be more understandable and allow users to give developers
feedback on appropriate structure of the system

2. Abstraction:
 Abstraction is representing the essential features of something without including
much detailed information.
1.2. Model

Benefits of Modeling:
1. Clarity:
 We can very easily understand the system being modeled as it provides visualization of
the whole system.
 This allows both the customer and developer to easily find out the drawbacks of the
proposed system before its development.

2. Complexity:
 Models reduce complexity by breaking the complex task into many simple tasks and
separates the unimportant tasks from the important ones.

3.Familarity:
 It is the easy way to communicate about appearance of the product with customer.
 It is used to test a physical entity before building it.

4.Maintenance:
 Modification in model is easier than doing the modification in a real system.

5.Cost:
 The cost of modeling the model is much lower compared to modifying a real system.
1.2. Model

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.
1.3. Object Oriented System Development

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.
1.3. Object Oriented System Development

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 Organizing the Object Operations of


Objects Objects Interaction the Objects

Object
Implementation
1.3. Object Oriented System Development
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.
1.3. Object Oriented System Development

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.
In other way we can say the objects identified in the analysis
phase must be found within design.
It means , we have to transform analysis model into design model
and then in implementation i.e. .source code by using
programming language.
object oriented system can be developed by using object oriented
programming.
1.3. Object Oriented System Development

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) 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 sections given below present a series of informal guidelines that will assist in the
identification of the elements of the object model.
Objects can be:

 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.
1.4. Identifying the Elements of an Object
Model
Identifying Classes and Objects:

The objects can be found as naturally occurring entities in the application


domain.
There is no problem in finding objects while difficulty is in selecting these
objects relevant to the system.
The intension is to find essential objects ,which are important throughout
the system’s lifecycle.
Example:
For Banking application ,typical objects are like Customer, Account, Bank

Real world entities :


Bank
Money
Budget
Credit card etc.
1.4. Identifying the Elements of an Object
Model
Specifying Attributes(with Visibility):

How to identify attributes?


Attributes usually correspond to nouns, adjectives or adverbs.
State only required attributes in the class.
Omit derived attributes. They should be expressed as a method.

Example: In the ATM system example , we will state the attributes of


Account, ATM , BankClient and Transaction classes.
BankClient Transaction
Account ATMMachine firstname transID
address lastname transDate
number pinnumber
balance state transTime
cardnumber transType
accountnumber amount
1.4. Identifying the Elements of an Object
Model
Visibility of Attributes:
Expression:(syntax):
visibility name: type –expression =initial value Example
customer
1. Public
+ name : string
2. Protected -address : string
3. Private # phone : Number

1.Public:
 Public visibility is accessible to all classes.
 To show public visibility ( + ) sign.

2. Protected:
 Protected visibility is accessible to subclasses and operations of the class.
 To show Protected visibility ( # ) sign.

3. Private:
 Private visibility is accessible only operations of the class.
 To show Protected visibility ( - ) sign.
1.4. Identifying the Elements of an Object
Model
Defining Operations:

How to Identify operations(methods)?

Methods are defined as services that the objects must provide.


These services are implemented as the methods for your objects.
Methods are the Events that occur between objects of the class.
An Event is considered to be an action that transmits information.
These actions are the operations that the object must perform.
BankClient Transaction
Example: ATM Machine
ATMMachine firstname transID
Account lastname transDate
number address pinnumber transTime
balance state cardnumber transType
accountnumber Amount
deposit() postBalance
withdraw()
createTrans() verifyPassword()
1.4. Identifying the Elements of an Object
Model
Finalizing the Object Definition:

The intent of Object Oriented Analysis is to define all classes, their


relationships .

To achieve this , following tasks will occur:

Basic user requirements must be communicated between the customer and


software engineer.

Classes must be identified i.e. its attributes and methods are defined.

A class hierarchy is defined.

Object to object relationships should be presented.

Above all the steps reapplied repeatedly till the model is not complete.
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.
What is UML?:

UML stands for Unified Modeling Language.


It is a collection of notations and rules.
UML is used for Object Oriented Problem Solving.
The UML is not a “data modeling” technique, rather it is an “object modeling "technique
i.e. instead of entities, it models “object classes”.
OMG defines UML as ,”a graphical language”

Features:
1. Visualizing: There are things about a software system you can not understand unless
you build models.
2.Specifying: Models that are precise, unambiguous, and complete.
3.Constructing:Allows direct connection to a variety of programming languages.
4.Documenting:The artifacts of a software intensive system.
1.5. Introduction to Unified Modeling
Language(UML)
History of UML:
1.5. Introduction to Unified Modeling
Language (UML)
….Overview of UML….
Advantages of UML:
UML, the unified modeling language, is a standard used to visually describe a program,
specifically an object-oriented program.

Visual Representation

Readability and Re-usability

Standard

Planning Tool

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.
1.5. Introduction to Unified Modeling
Language (UML)
….Overview 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.
1.5. Introduction to Unified Modeling
Language (UML)
….Overview of UML….
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.
1.5. Introduction to Unified Modeling
Language (UML)
…. 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


1.5. Introduction to Unified Modeling
Language (UML)
…. Conceptual Model of UML….
A) UML Building Blocks:
The building blocks of UML are described as follows:
1) Things:
Things are the most important building blocks of UML. Things can be:

Things

Structural Behavioral Grouping Annotational


Things Things Things Things
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.
Class
Attributes
Operations
1.5. Introduction to Unified Modeling
Language (UML)
…. Conceptual Model of UML….
A) UML Building Blocks:
2) Interface:
Interface defines a set of operations which specify the responsibility of a class.

Interface

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.  

Use case
1.5. Introduction to Unified Modeling
Language (UML)
…. Conceptual Model of UML….
A) UML Building Blocks:
5) Component:
Component describes physical part of a system.

Component

6) Node:
A node can be defined as a physical element that exists at run time.

Node
1.5. Introduction to Unified Modeling
Language (UML)
…. Conceptual Model of UML….
A) UML Building Blocks:
1) Things:
Things are the most important building blocks of UML. Things can be:
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.

Message

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.  

State
1.5. Introduction to Unified Modeling
Language (UML)
…. Conceptual Model of UML….
A) UML Building Blocks:
1) Things:
Things are the most important building blocks of UML. Things can be:
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.

Package

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:
note
1.5. Introduction to Unified Modeling
Language (UML)
…. Conceptual Model of UML….
A) UML Building Blocks:
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.
Dependency

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.  
1.5. Introduction to Unified Modeling
Language (UML)
…. Conceptual Model of UML….
A) UML Building Blocks:

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.
1.5. Introduction to Unified Modeling
Language (UML)
…. Conceptual Model of UML….
A) UML Building Blocks:
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
1.5. Introduction to Unified Modeling
Language (UML)
…. Conceptual Model of UML….
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
1.5. Introduction to Unified Modeling
Language (UML)
…. Conceptual Model of UML….
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.

Common Extensibility
Specifications Adornments
Divisions Mechanisms

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.
1.5. Introduction to Unified Modeling
Language (UML)
…. Conceptual Model of UML….
C) Common Mechanisms in the UML:
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.
1.5. Introduction to Unified Modeling
Language (UML)
…. Conceptual Model of UML….
C) Common Mechanisms in the UML:
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).
1.5. Introduction to Unified Modeling
Language (UML)
…. Conceptual Model of UML….
C) Common Mechanisms in the UML:
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
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.
Tagged
b) Tagged Value: Value
A tagged value extends the properties of a UML stereotype,
allowing you to create new information in the stereotype's
specification.
Constraint
1.5. Introduction to Unified Modeling
Language (UML)
…. Conceptual Model of UML….
C) Common Mechanisms in the UML:
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.
1.5. Introduction to Unified Modeling
Language (UML)
…. 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.
1.5. Introduction to Unified Modeling
Language (UML)
Architecture of UML
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.5. Introduction to Unified Modeling
Language (UML)
…. Architecture….
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.
1.5. Introduction to Unified Modeling
Language (UML)
…. Architecture….
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.

You might also like