1st Unit Complete notes topic wise

Modelling

Importance of modelling
A model is an abstraction of something for the purpose of understanding it
before building it. Because a model omits nonessential details, it is easier to
manipulate than the original entity.
The following can be seen as the importance of modelling :

 Testing a physical entity before building it. Both physical models

and computer models are usually cheaper than building a complete
system and enable early correction of flaws.
 Communication with customers. Architects and product designers
build models to show their customers. Mock-ups are demonstration
products that imitate some or all of the external behaviour of a system.
 Visualization. Storyboards of movies, television shows, and
advertisements let writers see how their ideas flow. They can modify
awkward transitions, dangling ends, and unnecessary segments before
detailed writing begins.
 Reduction of complexity. Perhaps the main reason for modelling,
which incorporates all the previous reasons, is to deal with systems that
are too complex to understand directly. The human mind can cope with
only a limited amount of information at one time. Models reduce
complexity by separating out a small number of important things to deal
with at a time.

Principles of modelling
The first principle of modelling:
The choice of what models to create has a profound influence on how a
problem is attacked and how a solution is shaped.
Choose your models well The right models will highlight the most nasty
development problems. Wrong models will mislead you, causing you to focus
on irrelevant issues.
The second principle of modelling:
Every model may be expressed at different levels of precision.
Sometimes, a quick and simple executable model of the user interface is
exactly what you need. At other times, you have to get down to complex
details such as cross-system interfaces or networking issues etc.
In any case, the best kinds of models are those that let you choose your
degree of detail, depending on who is viewing it. An analyst or an end-user will
want to focus on issues of what and a developer will want to focus on issues
of how.
The third principle of modelling:
The best models are connected to reality
In software, the gap between the analysis model and the system’s design
model must be less. Failing to bridge this gap causes the system to diverge
over time. In object-oriented systems, it is possible to connect all the nearly
independent views of a system into one whole.
The fourth principle of modelling:
No single model is sufficient. Every non-trivial system is best approached
through a small set of nearly independent models.
In the case of a building, you can study electrical plans in isolation, but you
can also see their mapping to the floor plan and perhaps even their interaction
with the routing of pipes in the plumbing plan.
 Conceptual model of the UML

A conceptual model of the language underlines the three major elements:

 The Building Blocks

 The Rules
 Some Common Mechanisms
Building Blocks:
The vocabulary of the UML encompasses three kinds of building blocks:
Things:
Things are the abstractions that are first-class citizens in a model;
relationships tie these things together; diagrams group interesting collections
of things.
There are 4 kinds of things in the UML:

1. Structural things
2. Behavioral things
3. Grouping things
4. Annotational things
These things are the basic object-oriented building blocks of the UML. You
use them to write well-formed models.
Relationships:
There are 4 kinds of relationships in the UML:

1. Dependency
2. Association
3. Generalization
4. Realization

These relationships are the basic relational building blocks of the UML.
Diagrams:
It is the graphical presentation of a set of elements. It is rendered as a
connected graph of vertices (things) and arcs (relationships)

1. Class diagram
2. Object diagram
3. Use case diagram
4. Sequence diagram
5. Collaboration diagram
6. Statechart diagram
7. Activity diagram
8. Component diagram
9. Deployment diagram

Rules:
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 semantic rules for:
Names – What you can call things, relationships, and diagrams.
Scope – The context that gives specific meaning to a name.
Visibility – How those names can be seen and used by others.
Integrity – How things properly and consistently relate to one another.
Execution – What it means to run or simulate a dynamic model.
Common Mechanisms:
The UML is made simpler by the four common mechanisms. They are as
follows:
1. Specifications
2. Adornments
3. Common divisions
4. Extensibility mechanisms

The four pillars for OOP

Encapsulation/ information hiding

Encapsulation (also information hiding) separates the external aspects of
an object, that are accessible to other objects, from the internal
implementation details, that are hidden from other
objects. Encapsulation prevents portions of a program from becoming so
interdependent that a small change has massive ripple effects.
Objects restrict the visibility of their resources (attributes and methods) to
other users. Every object has an interface, which determines how other
objects can interact with it. The implementation of the object is encapsulated,
that is, invisible outside the object itself. Consider a real-life example of
encapsulation, in a company, there are different sections like the accounts
section, finance section, sales section etc.

Polymorphism:
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.
A person at the same time can have different characteristics. Like a man at
the same time is a father, a husband, an employee. So the same person
possesses different behaviour in different situations. This is called
polymorphism. An operation may exhibit different behaviours in different
instances. The behaviour depends upon the types of data used in the
operation.

Inheritance:
The capability of a class to derive properties and characteristics from another
class is called Inheritance. Inheritance is one of the most important features of
Object-Oriented Programming.

 Sub Class: The class that inherits properties from another class is
called Sub-class or Derived Class.
 Super Class:The class whose properties are inherited by sub-class is
called Base Class or Superclass.
 Reusability: Inheritance supports the concept of “reusability”, i.e. when
we want to create a new class and there is already a class that includes
some of the code that we want, we can derive our new class from the
existing class. By doing this, we are reusing the fields and methods of
the existing class
Abstraction:
Data abstraction is one of the most essential and important features of
object-oriented programming in C++. Abstraction means displaying only
essential information and hiding the details. Data abstraction refers to
providing only essential information about the data to the outside world, hiding
the background details or implementation.

Introduction to UML

Unified Modeling Language (UML) is a general-purpose modelling language.

The main aim of UML is to define a standard way to visualize the way a
system has been designed.
UML is linked with object-oriented design and analysis. UML makes the
use of elements and forms associations between them to form diagrams.
Diagrams in UML can be broadly classified as:

 Structural Diagrams – Capture static aspects or structure of a system.

Structural Diagrams includes Component Diagrams, Object Diagrams,
Class Diagrams and Deployment Diagrams.
 Behaviour Diagrams – Capture dynamic aspects or behaviour of the
system. Behaviour diagrams include: Use Case Diagrams, State
Diagrams, Activity Diagrams and Interaction Diagrams.

Object-Oriented Concepts Used in UML –

1. Class – A class defines the blueprint i.e. structure and functions of an
object.
2. Objects – Objects help us to decompose large systems and help us to
modularize our system. Modularity helps to divide our system into
understandable components so that we can build our system piece by
piece. An object is the fundamental unit (building block) of a system
which is used to depict an entity.
3. Inheritance – Inheritance is a mechanism by which child classes inherit
the properties of their parent classes.
4. Abstraction – Mechanism by which implementation details are hidden
from the user.
5. Encapsulation – Binding data together and protecting it from the outer
world is referred to as encapsulation.
6. Polymorphism – Mechanism by which functions or entities are able to
exist in different forms.

Diagrams in UML

A Diagram is the graphical presentation of a set of elements, most often

rendered as a
connected graph of vertices (things) and arcs (relationships). In theory, a
diagram may
contain any combination of things and relationships
For this reason, the UML includes nine such 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
9. Deployment diagram

Introduction:

The meaning of Object Orientation

The object-oriented approach focuses on objects that represent abstract or
concrete things in the real world. These objects are first defined by their
character and their properties, which are represented by their internal
structure and their attributes (data). The behaviour of these objects is
described by methods (functions).
Below are some of the advantages of object-oriented programming:

 Complex software systems become easier to understand since object-

oriented structuring provides a closer representation of reality than other
programming techniques.
 In a well-designed object-oriented system, it should be possible to
implement changes at class level, without having to make alterations at
other points in the system. This reduces the overall amount of
maintenance required.
 Using polymorphism and inheritance, object-oriented programming
allows you to reuse individual components.
  In an object-oriented system, the amount of work involved in revising
and maintaining the system is reduced, since many problems can be
detected and corrected in the design phase.

Characteristics of an Object-Oriented approach

Object identity
Object Identity means that data is quantized into discrete, distinguishable
entities called objects.
Object
Objects are instances of classes. They contain data and provide services.
The data forms the attributes of the object.
The services are known as methods (also known as operations or functions).
Typically, methods operate on private data (the attributes, or state of the
object), which is only visible to the methods of the object. Thus the attributes
of an object cannot be changed directly by the user, but only by the methods
of the object. This guarantees the internal consistency of the object.
The object can be of two types: concrete and conceptual.
Architecture
A system's architecture is perhaps the most important artefact that can be
used to manage
these different viewpoints and so control the iterative and incremental
development of a
system throughout its life cycle.
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 behaviour, as specified in the collaborations among those
elements
 The composition of these structural and behavioural elements into
progressively larger subsystems
The architectural style that guides this organization: the static and
dynamic elementsband their interfaces, their collaborations, and their
composition.
Software architecture is not only concerned with structure and behaviour but
also with usage, functionality, performance, resilience, reuse,
comprehensibility, economic and technology constraints and trade-offs, and
aesthetic concerns.
Use case view
The use case view of a system encompasses the use cases that describe the
behaviour of the system as seen by its end-users, analysts, and testers.
With the UML, the static aspects of this view are captured in use case
diagrams The dynamic aspects of this view are captured in interaction
diagrams, state chart diagrams, and activity diagrams.
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.
Process View
The process view of a system encompasses the threads and processes that
form the system's concurrency and synchronization mechanisms.
This view primarily addresses the performance, scalability, and throughput of
the system
Implementation View
The implementation view of a system encompasses the components and files
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 components and files that can be
assembled in various ways to produce a running system.
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.