Unit 1 Content
Unit 1 Content
Unit-1 Content
Lecture - 1
Object Oriented System Design
Systems development is the process of defining, designing, testing, and implementing a new
software application or program. Programming is used as a tool for System Development.
There are mainly two approaches of system / software development, procedural and object-
oriented approach.
Each function has its own local data and common global data, as shown in Fig. 2.
1.2 Limitations of Procedural Approach:
The program code is harder to write when Procedural Programming is employed.
The Procedural code is often not reusable, which may pose the need to recreate the
code if is needed to use in another application
Difficult to relate with real-world objects
The importance is given to the operation rather than the data, which might pose
issues in some data-sensitive cases
The data is exposed to the whole program, making it not so much security friendly
Lecture - 2
2 Object Oriented Approach (OOP)
An OOP method differs from POP in its basic approach itself. All the best features of
structured of OOP is developed by retaining the programming method, in which they have
added number of concepts which makes efficient programming. Object oriented
programming methods have number of features and it makes possible an entirely new way
of approaching a program. This has to be noted that OOP retains all best features of POP
method like functions/sub routines, structure etc.
2.1 Difference between Procedure Oriented and Object-Oriented Approach
Objects form a capsule, which combines the characteristics with behaviour. Objects are
intended to enable programmers to map a real problem and its proposed software solution
on a one-to-one basis.
Lecture - 3
4. Concepts of OOP
The OOPs concepts helps the programmers to analyse the real-world problem and
implement it in terms of programming language.
4.1 Object
An object is anything in the real-world. It exists in the form of physical or abstract. For
example, it may represent a person, animal, bird or anything. For example: Elephant, Lion is
an object.
4.2 Class
Class is a group of similar types of objects, having similar features and behaviour. In the
following Figure different objects exists in the real world and based on the common features
these are categorized into different classes Car, Flower and Person.
Class is used to describe the structure of objects that how the objects will look likes. Class is
also a pattern or template which produces similar kind of objects.
Class has data members (attributes) and behavior shown by object also called functionality.
.
4.3 Encapsulation
Encapsulation is defined as the wrapping up of data under a single unit. It is the mechanism
that binds together code and the data it manipulates. Another way to think about
encapsulation is, it is a protective shield that prevents the data from being accessed by the
code outside this shield.
Examples of Encapsulation:
School bag is one of the most real examples of Encapsulation. School bag can keep
our books, pens, etc.
In network communication, the data is encapsulated in a single unit in the form of
packets. These packets are delivered over the network.
1. My Name and personal information is stored in My Brain, nobody can access this
information directly. For getting this information you need to ask me about it and it
will be up to myself that how much details I would like to share with you.
2. Facebook may have millions of user accounts. Facebook is just like a Class, it has
Private, Public and Protected members. In private, there may be inbox, some
personal photo or video. In public, it may be some post, or user information like
d.o.b, where you live etc and in protected there may be some post that only your
friend can see, and it’s hidden from public.
In object-oriented approach we have objects with their attributes and behaviours that are
hidden from other classes, so we can say that object-oriented programming follows the
principle of information hiding.
The accessibility often plays an important role in information hiding. Here the data element
marks are private element and thus it cannot be accessed by main function or any other
function except the member function display() of class student. To make it accessible in main
function, it should be made a public member.
Advantages of Information Hiding:
1. It ensures exclusive data access and prevents intended or unintended changes in the
data.
2. It helps in reducing system complexity and increase the robustness of the program.
3. It heightens the security against hackers that are unable to access confidential data.
4. It prevents programmers from accidental linkage to incorrect data.
5. Polymorphism
The word “poly” means many and “morphs” means forms, so the word polymorphism
means having many forms. In simple words, we can define polymorphism as the ability of a
message to be displayed in more than one form.
Fig 7 - Polymorphism
6. Generosity:
Generosity is a property in object-oriented technology by which the container class can be
created in which the implementation of any data types is contained. These classes are
popularly known as templates.
Example: Consider the implementation of data structure stack. If we create an integer stack
“stack of integers” then the push and pop operations will handle only integers elements. If
we create a character stack “stack of characters” then the push and pop operations will
handle only characters. But creating so many copies of implementation make the code
complex to maintain. Hence the principal of generosity is used and a template class can be
created. This container class can handle any data type element at run time.
For example: In the given figure, the two parameters of a container class (Generic Lookup
Table) include key and value. In this case key is person name and value is phone number will
yield phone book data and in other cases it can be used as data for other tasks.
Mapping_Fun(key)-> Value
Mapping_Fun(person_name)-> phone_number
Mapping_Fun(ip_address)-> domain_name
Mapping_Fun(aadhaar_number)-> pan_number
Modelling
Modelling is a central part of all activities that lead up to the deployment of good software.
It is required to build quality software. We build models to communicate the desired
structure and behaviour of our system. We build models to visualize and control the system's
architecture. We build models to better understand the system we are building, often
exposing opportunities for simplification and reuse. And we build models to manage risk."
For example, If you want to build a house for your family with same things, is it possible? It
requires detailed planning, some sketches etc. Of Course, architecting a house is best
achieved by a team. It requires detailed modelling, well-defined processes and powerful
tools.
What about a high-rise building? Modeling is no doubt a critical part of any construction
project!
7. Importance of modelling:
Through modelling, we can achieve following aims:
Modelling gives graphical representation of system to be built.
Modelling contributes to a successful software organization.
Modelling is a proven and well accepted engineering technique.
Modelling is not just a part of the building industry. It would be inconceivable to
deploy a new aircraft or an automobile without first building models-from computer
models to physical wind tunnels models to full scale prototypes.
A model is a simplification of reality. A model provides the blueprint of a system.
A model may be structural, emphasizing the organization of the system, or it may be
behavioural, emphasizing the dynamics of the system.
Models are build for better understanding of the system that we are developing:
a. Models help us to visualize a system as it is or as we want it to be.
b. Models permit us to specify the structure or behaviour of a system.
c. Models give us a template that guides us in constructing a system.
d. Models support the decisions we have made.
The larger and more complex the system becomes, the more important modelling becomes,
for one very simple reason:
Every project can benefit from modelling. Modelling can help the development team better
visualize the plan of their system and allow them to develop more rapidly by helping them
build the right thing. The more complex your project, the more likely it is that you will fail or
that you will build the wrong thing if you do on modelling at all.
8. Principles of modelling:
Modelling principles are as follows:
a. The choice of model is important
“The choice of what models to create has a profound influence on how a problem is
attacked and how a solution is shaped”.
Types of Models:
There are 3 types of models in the object oriented modelling and design are:
Class Model, State Model, and Interaction Model.
These are explained as following below.
Class Model:
The class model shows all the classes present in the system. The class model shows the
attributes and the behaviour associated with the objects.
The class diagram is used to show the class model. The class diagram shows the class name
followed by the attributes followed by the functions or the methods that are associated with
the object of the class. Goal in constructing class model is to capture those concepts from
the real world that are important to an application.
State Model:
State model describes those aspects of objects concerned with time and the sequencing of
operations – events that mark changes, states that define the context for events, and the
organization of events and states. Actions and events in a state diagram become operations
on objects in the class model. State diagram describes the state model.
Interaction Model:
Interaction model is used to show the various interactions between objects, how the objects
collaborate to achieve the behaviour of the system as a whole.
Goals of UML
There are a number of goals for developing UML but the most important is to define some
general-purpose modelling language, which all modellers can use and it also needs to be
made simple to understand and use.
• UML diagrams are not only made for developers but also for business users,
common people, and anybody interested to understand the system.
• The system can be a software or non-software system. Thus it must be clear that
UML is not a development method rather it accompanies with processes to make
it a successful system.
Structural Things: Structural things are the nouns of UML models. These are the mostly
static parts of a model, representing elements that are either conceptual or physical. In all,
there are seven kinds of structural things.
1. Class: A class is used to represent set of objects sharing similar properties and
behaviour. It is used to define the properties and operations of an object. A class
whose functionalities are not defined is called an abstract class. Any UML class
diagram notations are generally expressed as below UML class diagrams example,
2. Object: An object is an entity which is used to describe the behaviour and functions
of a system. The class and object have the same notations. The only difference is that
an object name is always underlined in UML.
The UML notation of any object is given below.
5. Use-case: Use-cases are one of the core concepts of object-oriented modelling. They
are used to represent high-level functionalities and how the user will handle the
system.
6. Actor: It is used inside use case diagrams. The Actor notation is used to denote an
entity that interacts with the system. A user is the best example of an actor. The actor
notation in UML is given below.
UML Actor
UML Component
8. Node: A node is used to describe the physical part of a system. A node can be used to
represent a network, server, routers, etc. Its notation is given below.
UML Node
Behavioural Things:
Behavioural things are the dynamic parts of UML models. These are the verbs of a model,
representing behaviour over time and space. In all, there are two primary kinds of
behavioural things.
1. Messages: An interaction is a behaviour that comprises a set of messages exchanged
among a set of objects within a particular context to accomplish a specific purpose.
Graphically, a message is rendered as a directed line, almost always including the
name of its operation display.
Grouping Things: Grouping things are the organizational parts of UML models. These are
the boxes into which a model can be decomposed. There is one primary kind of grouping
thing, namely, packages.
Packages: A package is a general-purpose mechanism for organizing elements into groups.
Graphically, a package is rendered as a tabbed folder, usually including only its name and,
sometimes, its contents.
Annotational Things: Anntational things are the explanatory parts of UML models. These
are the comments you may apply to describe, illuminate, and remark about any element in a
model.
There is one primary kind of annotation thing, called a note. A note is simply a symbol for
rendering constraints and comments attached to an element or a collection of elements.
UML Diagrams
Any real-world system is used by different users. The users can be developers, testers,
business people, analysts, and many more. Hence, before designing a system, the
architecture is made with different perspectives in mind. The most important part is to
visualize the system from the perspective of different viewers. The better we understand the
better we can build the system.
A diagram is the graphical presentation of a set of elements, most often rendered as a
connected graph of vertices (things) and paths (relationships).
• A diagram represents an elided view of the elements that make up a system.
• In theory, a diagram may contain any combination of things and relationships.
❖ The center is the Use Case view which connects all these four. A Use Case
represents the functionality of the system. Hence, other perspectives are connected with
use case.
❖ Design of a system consists of classes, interfaces, and collaboration. UML provides
class diagram, object diagram to support this.
❖ Implementation defines the components assembled together to make a complete
physical system. UML component diagram is used to support the implementation
perspective.
❖ Process defines the flow of the system. Hence, the same elements as used in Design
are also used to support this perspective.
❖ Deployment represents the physical nodes of the system that forms the hardware.
UML deployment diagram is used to support this perspective. The UML includes nine
kinds of diagrams:
1. Class diagram
2. Object diagram
3. Use case diagram
4. Sequence diagram
5. Collaboration diagram
6. State-chart diagram
7. Activity diagram
8. Component diagram
1. Class Diagram – The most widely use UML diagram is the class diagram. It is
the building block of all object-oriented software systems. We use class
diagrams to depict the static structure of a system by showing system’s classes,
their methods and attributes. Class diagrams also help us identify relationship
between different classes or objects.
2. Composite Structure Diagram – We use composite structure diagrams to
represent the internal structure of a class and its interaction points with other
parts of the system. A composite structure diagram represents relationship
between parts and their configuration which determine how the classifier (class,
a component, or a deployment node) behaves. They represent internal structure
of a structured classifier making the use of parts, ports, and connectors. We can
also model collaborations using composite structure diagrams. They are similar
to class diagrams except they represent individual parts in detail as compared to
the entire class.
3. Object Diagram – An Object Diagram can be referred to as a screenshot of the
instances in a system and the relationship that exists between them. Since object
diagrams depict behaviour when objects have been instantiated, we are able to
study the behaviour of the system at a particular instant. An object diagram is
similar to a class diagram except it shows the instances of classes in the system.
We depict actual classifiers and their relationships making the use of class
diagrams. On the other hand, an Object Diagram represents specific instances of
classes and relationships between them at a point of time.
4. Component Diagram – Component diagrams are used to represent the how the
physical components in a system have been organized. We use them for
modelling implementation details. Component Diagrams depict the structural
relationship between software system elements and help us in understanding if
functional requirements have been covered by planned development. Component
Diagrams become essential to use when we design and build complex systems.
Interfaces are used by components of the system to communicate with each
other.
5. Deployment Diagram – Deployment Diagrams are used to represent system
hardware and its software. It tells us what hardware components exist and what
software components run on them. We illustrate system architecture as
distribution of software artifacts over distributed targets. An artifact is the
information that is generated by system software. They are primarily used when
a software is being used, distributed or deployed over multiple machines with
different configurations.
6. Package Diagram – We use Package Diagrams to depict how packages and their
elements have been organized. A package diagram simply shows us the
dependencies between different packages and internal composition of packages.
Packages help us to organise UML diagrams into meaningful groups and make
the diagram easy to understand. They are primarily used to organise class and
use case diagrams.
Behaviour Diagrams –
3. Use Case Diagrams – Use Case Diagrams are used to depict the functionality of
a system or a part of a system. They are widely used to illustrate the functional
requirements of the system and its interaction with external agents (actors). A
use case is basically a diagram representing different scenarios where the system
can be used. A use case diagram gives us a high-level view of what the system or
a part of the system does without going into implementation details.
4. Sequence Diagram – A sequence diagram simply depicts interaction between
objects in a sequential order i.e. the order in which these interactions take place.
We can also use the terms event diagrams or event scenarios to refer to a
sequence diagram. Sequence diagrams describe how and in what order the
objects in a system function. These diagrams are widely used by businessmen
and software developers to document and understand requirements for new and
existing systems.
5. Communication Diagram – A Communication Diagram (known as
Collaboration Diagram in UML 1.x) is used to show sequenced messages
exchanged between objects. A communication diagram focuses primarily on
objects and their relationships. We can represent similar information using
Sequence diagrams. However, communication diagrams represent objects and
links in a free form.
6. Timing Diagram – Timing Diagram are a special form of Sequence diagrams
which are used to depict the behaviour of objects over a time frame. We use
them to show time and duration constraints which govern changes in states and
behaviour of objects.
7. Interaction Overview Diagram – An Interaction Overview Diagram models a
sequence of actions and helps us simplify complex interactions into simpler
occurrences. It is a mixture of activity and sequence diagrams.
UML- Architecture
Software architecture is all about how a software system is built at its highest level. It is
needed to think big from multiple perspectives with quality and design in mind. The software
team is tied to many practical concerns, such as:
• The structure of the development team.
• The needs of the business.
• Development cycle.
• The intent of the structure itself.
Software architecture provides a basic design of a complete software system. It defines the
elements included in the system, the functions each element has, and how each element
relates to one another. In short, it is a big picture or overall structure of the whole system,
how everything works together.
To form an architecture, the software architect will take several factors into consideration:
• What will the system be used for?
• Who will be using the system?
• What quality matters to them?
• Where will the system run?
The architect plans the structure of the system to meet the needs like these. It is essential to
have proper software architecture, mainly for a large software system. Having a clear design
of a complete system as a starting point provides a solid basis for developers to follow.
Each developer will know what needs to be implemented and how things relate to meet the
desired needs efficiently. One of the main advantages of software architecture is that it
provides high productivity to the software team. The software development becomes more
effective as it comes up with an explained structure in place to coordinate work, implement
individual features, or ground discussions on potential issues. With a lucid architecture, it is
easier to know where the key responsibilities are residing in the system and where to make
changes to add new requirements or simply fixing the failures.
In addition, a clear architecture will help to achieve quality in the software with a well-
designed structure using principles like separation of concerns; the system becomes easier to
maintain, reuse, and adapt. The software architecture is useful to people such as software
developers, the project manager, the client, and the end-user. Each one will have different
perspectives to view the system and will bring different agendas to a project. Also, it provides
a collection of several views. It can be best understood as a collection of five views:
1. Use case view
2. Design view
3. Implementation view
4. Process view
5. Development view
Design View
1. It is a view that shows how the functionality is designed inside the system in terms of
static structure and dynamic behavior.
2. It captures the vocabulary of the problem space and solution space.
3. With UML, it represents the static aspects of this view in class and object diagrams,
whereas its dynamic aspects are captured in interaction diagrams, state chart
diagrams, and activity diagrams.
Implementation View
1. It is the view that represents the organization of the core components and files.
2. It primarily addresses the configuration management of the system’s releases.
3. With UML, its static aspects are expressed in component diagrams, and the dynamic
aspects are captured in interaction diagrams, state chart diagrams, and activity
diagrams.
Process View
1. It is the view that demonstrates the concurrency of the system.
2. It incorporates the threads and processes that make concurrent system and
synchronized mechanisms.
3. It primarily addresses the system's scalability, throughput, and performance.
4. Its static and dynamic aspects are expressed the same way as the design view but
focus more on the active classes that represent these threads and processes.
Deployment View
1. It is the view that shows the deployment of the system in terms of physical
architecture.
2. It includes the nodes, which form the system hardware topology where the system
will be executed.
3. It primarily addresses the distribution, delivery, and installation of the parts that build
the physical system.