Activity Diagram

1. Activity diagrams are the object oriented equivalent of flow charts and data flow diagrams from structured development
2. Activity diagrams describe the workflow behavior of a system
3. The process flows in the system are captured in the activity diagram
4. Activity diagram illustrates the dynamic nature of a system by modeling the flow of control from activity to activity

• An activity diagram contains activity states. An activity state represents the execution of a statement in a procedure or the performance of an activity in a workflow
• An activity state waits for the completion of its computation. When the activity completes then execution proceeds to the next activity state within the diagram
• When to use Activity Diagrams?
1.  a complex operation
2.  a complex business rule
3.  a single use case
4.  several use cases
5.  a business process
6.  software processes

element of activity diagram

Transition

A transition is a relationship between two states that indicates when event occurs that the object will move to another state.

For example when the "off hook" event occurs, the phone goes from the idle state to the active state.

Event

An event is a significant or noteworthy occurrence

For example a phone is taken of the hook

The event which trigger a state change can be added to the transition lines on a state diagram. The action which actually moves the object into the new state can also be specified. There are referred to as trigger events and actions. If an event occurs without an explicit trigger, such as would occur if a state completes an activity then moves to the next state, it is referred to as a trigger-less transition

State

A state is the condition of an object at an instance of time.

For example a phone is in an idle state it is taken off the hook

A state representation can be divided into three sections

• state name
• this is supplied regardless of whether the state representation is subdivided or not
• state variable
• three commonly used state variable are entry, exit and do. A good example of an object that has state variables is a fax machine
• activities
• these represent action that can be carried out during the state

State Transition Diagram

One way to characterize change in a system is to say that its objects change their state in response to events and to time

• e.g. When you throw a switch, a light changes its state from off to on
• e.g. The update_mark method changes the state of the student subject object

A state diagram shows the various states of a single object

• There must be a separate transition diagram for each object class
• It helps analysts, designers and developer understand the behavior of the objects in the system,
• State diagrams ensure that they won't have to guess about what the object is supposed to do

When do we care about States?

1. A class has a complex life cycle
2. Properties of the class may be updated at multiple points in the life cycle
3. When one class is dependent on the existence or behavior of other classes
4. When the behavior of a class depends on what previously happened

We can definitely say that state transition diagram show class state and the events that cause them to transition between states.

• An event happens at a specific time and place
• Events cause a change of state for the object as the transition "fires"

Each time on object changes state, some of its attributes must change

• There must be a method in the object class to change the attributes
• Often there is a boundary or interface class ( a display screen or web form) for the actor to enter the attributes and trigger the Event

State Diagram Definition

A state diagram will represent the changes that can occur in an object. Objects can change their state in response to events and time

Representing Class Responsibility

• It is possible to further define a class definition in the UML through the specification of the class's specific responsibilities
• The responsibility of a class is a description of what the class has to do
• The description of the class's responsibility is placed inside the class rectangle underneath the class's behaviors
• The purpose of including this description is to include enough information so that the class is described unambiguously

Representing Objects

• When an object is instantiated from a class definition it will contain a specific value for each of its attributes
• In the UML, an object name should start with a lowercase letter and be separated from its class name with a single colon
• The name of the object bis also underlined to emphasis the fact that it is an object

Representing Behavior

• A class behavior defines something the class can do or that can be done with the class
• Behavior names should follow the same conventions used for attribute names except that a pair of parenthesis is included after the name
• The parameter name and types as well as the return type for each behavior can be specified
• These pieces of information concerning a behavior make up the behavior's signature

Representing Attributes

• A class may have zero or more attributes
• Attributes represent the properties or important pieces of data that each object of the class must hold
• Attribute names in the UML should begin with a lowercase letter
• If an attribute name consists of more than one word then the words should be combined together capitalizing the first letter of each new word
• The list of a class's attributes is separated from the class name by a solid line.

Packages

• The UML also uses the concept of packages to organize the various elements on a diagram
• if a class belongs to a package it can impact on the way the class is named

Representing CLASSES

• A rectangle symbol is used to represent a class in the UML
• The name given to a class should start with a capital letter
• If the name of the class consists of more than one word then each word should be combined into one capitalizing the first letter of each new word

Visualizing Classes

• The UML uses a specific notation for representing classes in its diagrams
• This notation defines how a class is represented in terms of its:
• Class name
• attribute
• behaviors
• responsibilities
• cibstraints
• It also define how notes can be attached to classes on a UML diagram

Aggregation

• An aggregation is formed when an object contains one or more other objects
• An example might be a computer system which contains a CPU object a hard disk object a keyboard object etc
• One special form of aggregation is referred to as composition
• Composition is found where the components of an object only exist within the one composite object
• For example a finger belong to just one hand. Therefore it can be said that the hand finger relationship is a composite relationship

Associatrions

• An association is where objects are related to each other in some fashion
• For example a human object that watches a television object is associated to that television object
• In this situation, the association might be called turn on as the association begins when the human turns the TV on. This association is unidirectional
• Other associations such as marriage are bi-directional
• In some cases an object may be associated with another object in more than way.
• It is possible for a class of objects to be associated with one or more other classes
• Multiplicity is the specification of how many objects in one class relate to a single object of an associated class
• For example one lecturer teaches the students in this class, however many students are taught by this one lecturer

Message Sending

• In the majority of object oriented software systems a number of objects will work together to carry out the functionality of the system
• The objects in the system do this by sending messages to each other
• Think of a television and its remote control. The remote is an object which can be used to send a message to the television object to turn itself on. It can also send a message to the television object to turn itself off etc
• Think about the interface the TV object presents to the remote. Is it the same interface that is presented to someone using the TV without  a remote?

Polymorphism

• Sometimes a certain behavior is called the same thins in a number of different classes
• For example you can open a door, open a window, open a book, open a fridge etc
• In each of these cases, the behavior is called the same thing (open) but carries out a different set of actions.
• Polymorphism(which mean 'many forms') allows a single statement to invoke a variety of different behaviors. The system knows which behavior is the right one to carry out even though the same statement is used each time.

Inheritance

• A class is typically developed to represent a group or category of objects
• An object is an instance of a class
• When an object is created(instantiated) it is given both the attributes and behaviors that are defined in that objects class
• In addition to this, attributes and behaviors can be inherited from other classes
• In fact inheritance hierarchies can be formed allowing classes to be developed by simply specializing existing classes
• As an example, think of kitchen appliances such as a toaster, fridge, juicer, mixer and stove
• Each of these groups of objects can be modeled with a class definition, however each of these groups of objects also belongs to a broader group called appliances
• By defining an appliance class as a generalized class each specialized class can be provided with a base if implementation
• This can reduce development time by promoting software reuse

Encapsulation

• The concept of encapsulation follows on where the discussion of abstraction left off
• A typical object will encapsulate both it's attributes and behaviors
• This not only means that the attributes and behaviors of the object are bound together into a capsule but also on an object can lock away its implementation detail from outside access
• The object takes care of its inner working without outside interference
• Imagine if people could easily mess around with the insides of a Microwave oven. It could easily be a recipe for disaster. Instead the inner working of the Microwave are encapsulated.

Abstraction

• Different problems require different amounts of data.
• For a particular problem, some data may be relevant whilst other data may not
• Abstraction is concerned with analyzing a real world situation or object and filtering out all the data or characteristics which are not important
• Consider a street directory. It only contains the important data needed to serve the directory's purpose. It does not contain unimportant data such as the number blades of grass in each street
• When modeling real world objects only the important characteristics need to be incorporated into the model.
• The concept of abstraction can also be applied when using existing objects in an object oriented system
• The details of how the object is implemented are not important for being able to use that object
• For example think of television set. Do you need to know the inner working of the TV in order to use it? No the detail of the TV's inside have been abstracted way.

Object Orientation

• In recent times, object oriented software development has become the method of choice
• When a system is represented as a set of objects
• These objects can be easily expanded to add to system functionality or new objects can be developed and plugged into the system
• New systems can use components previously developed to reduce their development time
• This contrasts with structured software development where such extensible and reuse is not as easy
• Object Oriented Concepts
• In order to be able to effectively design object oriented computer programs a number of key concepts need to be understood
• Abstraction
• Encapsulation
• Inheritance
• Polymorphism
• Message Sending
• Associations
• Aggregation

Key parts of a sequence diagram

• participant: an object or entity that acts in the sequence diagram
• sequence diagram starts with an unattached "found message" arrow
• message: communication between participant objects
• the axes in a sequence diagram:
• Horizontal: which object / participant is acting
• Vertical: time (down -> forward in time)

UML sequence diagram

• Sequence diagram: an "interaction diagram" that models a single scenario executing in the system
• prehaps 2nd most used UML diagram
• Relation of UML diagrams to other exercises:
• use cases -> sequence diagram

Use Case Modelling

• Use Case Modelling is a very popular technique to find out user requirement
• Use cases describe the system from the user's point of view
• A use case defines the interactions between external actors and the system under consideration to accomplish a goal
• It describe the interaction between one or more actors and the system itself represented as a sequence of simple steps
• There are main formats used to express use cases: High-Level format and Expand format
• A High-Level use case describes a process very briefly. This format is typically useful during the early stages of a development project.
• An Expanded use case describes a process in more detail than a high level description. An expanded use case description includes a step by step description includes a step by step description of the typical course of events for the use case. It is sometimes useful during requirements gathering and analysis.
• A use case defines a sequence of actions performed by a system that yields and observable result of value to an actor
• A use case is always initiated by an actor
• A use case provides value to an actor
• A use case is complete

The Actor

An actor is usually drawn as a named stick figure, or alternatively as a class rectangle with the keyword

• What is an actor?
• Not part of the system
• Represents roles a user can play
• Represents human a machine or another system
• Activity exchange information with the system
• A give or a recipient
• Who will use the system?
• Who will maintain the system?
• What hardware does the system support or interact with?
• What other systems are needed for this system to work?
• Who will supply, use, or remove information?
• Who create it?
• Who displays or uses it?
• Who delete it?
• For each actor, ask the following questions
• What are the primary tasks the actor wants the system to perform>
• Will the actor create, store, change, remove, or read data in the system?
• Will the actor need to inform the system about sudden, external changes?
• Will the actor perform a system startup or termination?

Why so many diagrams?

• Not all the diagrams discussed must appear in every model produced using the UML
• The variety of UNL diagrams allows a system to be represented from a number of views
• This is important as most systems will have a number of stakeholders who will view the system differently
• In order to accurately  define the requirements of the system it is important to examine the system from a variety of these points of view
• A more detailed examination of these diagrams will be carried our in future lessons

Activity Diagram

• The activities that occur within an object's behaviour usually occur in sequence
• An activity diagram is designed to be a simplified look at what happens during a peocess or behavior

Sequence Diagram

• Class Diagrams and Object Diagrams present static information
• in a functioning system however objects interact with each other over time
• A UML Sequence Diagram is used to show the details od these object interactions over time
• Consider a washing machine system which consists of a number of objects including a water pipe, washing machine, drum and drain
• What is the sequence of a actions performed once the clothes are added and a wash cycke started

• Use Cases suggest how actors interact with the system that will ultimately to implemented in software
• During this interaction, an actor will generate events to the system, requesting a particular operation in response
• It is often desirable to isolate and document the operations that an actor requests of a system
• A system sequence diagram is a drawing that shows for a particular use case scenario, the events, external actors generate their order and inter system events all against time.

Representing objects

• squares with object type optionally proceeded by object name and colon
• write object's name if it clarifies the diagram
• object's "life line: represented by dashed vertical line

Messages between objects

• message indicated by horizontal arrow to other objects
• write message name and arguments above arrow
• dashed arrow back indicates return messages

Lifetime of object

• creation: arrow with new written above it
• notice that an object created after the start of the scenario appears lower than the other
• deletion an X at bottom of object's life line
• Java does not explicitly delete objects, they fall out of scope and are garbage collected

Indicating method calls

• activation: think box over object's life line drawn when object's method is on the stack
• either that object is running its code, or it is on the stack waiting for another object's method to finish

State Diagram

• At any given time, object will be in a particular state
• For example at different times a person object may be an infant child, teenager or adult
• A state diagram in the UML show's the differing states that an object can be in

Object Diagram

• An object is an instance of a class
• Every object has its own copy of the attributes defined in the class an can perform the behaviurs defined in the class
• For example if a television class has defined then an object of that class might have values for its attributes as follows:
• size = 34
• serial number = 123459876
• production date = 10/06/01
• An object is represented in the UML in the following fashion
• A rectangle is used with an underlined name
• The name of the object is on the left of a colon
• The name of the class from which the object is produced is specified on the right fo the colon

Class Diagram

• Think of the many objects around you in the real world
• The majority of these objects will have attributes and behavoirs
• A class diagram consists of a number of these class representation connected by lines which show the relationship between the classes

Use Case Diagram

• A use case describes a systems behaviour from the user's point of view
• Use cases are often used to help defined the systems requirements
• Use cases make use stick figures that represents a system user or ther system
• In use cases, system users are referred to as actors
• An elliptical symbol is used to represent the actual use case

The UML

• UML stands for Unified Modelling Language
• The UML is primarily a graphical notation used for modelling systems using object oriented concepts
• The UML is emerging as an industry standard for object oriented modelling
• In additional to this the UML is recognized as the standard language for use with OO Analysis & Design by the Object Management Group (OMG)
• The UML consists of a number of graphical elements that are combined to form diagram
• The UML language specifies rules for combining these graphical elements
• The purpose of producing these diagrams is to represent multiple views of the system
• This set of views is collectively referred to as a model of the system
• UML enables the software developer to understand certain concepts of the system more clearly.
• When understanding programming languages, the results are precise but too much detail is needed to gain the results
• When using UML the developer can gain a certain amount of precision and avoid getting lost in detail
• That does not mean that the detail is avoided, rather that the UML can highlight the important detail

DFD COMPONENTS

SOURCE

• Performs processes excluded from the scope of the system being modeled
• Sometimes referred to as Agents

TYPE OF SOURCES

• Internal sources
• Office, department, employee within the company
• External sources
• Office, department, employee outside the company
• Another system
• Include only if the modeled system communicates directly with the programs of the other system

NAMING / LOCATING SOURCES

• Name should be based on the title of the person or entity
• Register, Supplier, Marketing, IS
• Should be located on the perimeter of the page
• May be duplicated sparingly to avoid crossing lines

DATA FLOWS

• The input of data to a process
• Represent the minimum essential data the dependence or coupling between processes

DATA FLOW GUIDELINES

• Must begin at a source, must end at a sink or at a source
• should be given unique names
• name should be some identifying noun
• order, payment, complaint

DATA STORES

• A repository for data that are temporarily or permanently recorded within the system
• An "inventory" of data
• Common link between data and process models 
• Commonly referred ti as sink

Data Flow Diagram

• A process modeling tool that depicts
• the flow of data through a system
• the work or processing performed by the system
• When to use DFDs?
• Help you to understand the system
• Make a complex process clear
• Communicate your understanding
• Find the data used in the system
• Show the flow of data within a system and its transformation
• DFDs store:
• where data begins
• how data gets transformed through processes
• where data finishes
•  DFDs do not store:
• how the process occurs
• who does it
• Data Flow Diagrams are only concerned with DATA

DATA VS PROCESS MODELS

• Data model
• A technique for organizing and documenting a system;s data (Entry Relationship Diagram)
• Process model
• A technique for organizing and documenting a system's processes, input, outputs and data stores ( Data Flow Diagram)

DFD - Modelling is decomposition

• Break the system down into smaller parts until you fully understand each part
• The main problem of modelling techniques is that they might be inexact and open to interpretation.

The Requirement Engineering Process

• Feasibility
• Find out if the current user needs be satisfied given the available technology and budget?
• Requirements Analysis
• Find out what system stakeholders require from the system
• Requirement definition
• Define the requirements in a form understandable to the customer
• Requirement specification
• Define the requirements in a form understandable to the customer

Requirement definition / specification

• requirement definition
• A statement in natural language plus diagrams of the services the system provides and its operatinoal constraints. Written for customers.
• requirement specification
• A structured document setting out detailed descriptions of the system services
• software specification
• A detailed software description which can serve as a basis for a design or implementation. Written for developers
• Requirement readers

Basic Non functionality

• The quality we desire of a problem solution other than those concerning its functionality are called non functional requirements
• Non functional requirements cannot be modeled
• safety
• security
• reliability
• resilience
• robustness
• test-ability
• adaptability
• modularity
• complexity
• portability
• usability
• efficiency

Basic Functionality

• A functional requirement usually has corresponding behavioral and performance condition
• Functional requirements can always be modelled

Requirement engineering

• The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed
• Row requirements need to be categorized in:
• Functional requirements describe system services functions\
• Non functional requirements is a constraints on the system or on the development process
• It may range from a high level abstract statement of a service or of a system constraint to a detailed mathematical functional specification
• This is inevitable as requirements may serve a dual function
• May be the basis for a bid for a contract - therefore must be open to interpretation
• May be the basis for the contract itself therefore must be defined in detail
• both these statements may be called requirement

Software Development Life Cycle

OO vs Structured Analysis & Design

• Almost all software products are complex
• Dividing a large problem into smaller more manageable pieces is a common strategy used to deal with complex programming problems.
• Before the advent of OO Analysis & Design the most popular technique was Structured Analysis & Design
• This technique focused on breaking the problem into functions or processes.
• OO Analysis & Design focuses on breaking the problem into object rather than functions or processes.

What is Design?

• Once the problem and requirements have been defined, it is necessary to plan and determine how the software application will be implemented.
• Design focuses on specifying how the solution will be implemented.

What is Analysis?

• To create a useful software product, firstly a description of the problem or requirement is required.
• Analysis focuses on investigation and definition of the problem, rather than on how the solution will be defined.
• For example if a new library catalog system is to be developed, analysis would focus on defining the business processes related to its use.

OOA and Design

• Being able to produce a well designed object oriented system is an important skill to master. The old saying "owning a hammer does not make one an architect: is especially true for object oriented development.
• Knowing an object oriented language such as Java is not sufficient alone for the production of object oriented systems.
• During OO Analysis there is a focus on finding and describing the objects and/or concepts in the problem domain.
• During OO Design there is a focus on defining the objects that will ultimately be implemented in an OO programming language.

Flow Charts

• A Flow chart is graphical representation of an algorithm or part of an algorithm
• Flow charts are drawn using certain special purpose symbols such as rectangles, diamond and ovals
• These symbols are connected by arrows called flow lines.
• When drawing a flow chart that represents a full algorithm, the terminal symbol is used to represent the START and END of the program algorithm
• When drawing a flow chart that represent just a portion of the overall algorithm, the START and END symbols are replaced by the CONNECTOR symbol
• Flow Chart Symbols

Pseudo-code

• Pseudo-code is a tool that can be used to express algorithms more precisely
• Pseudo-code is a combination of programming code and ordinary English
• Pseudo-code allows algorithms to be specified precisely without having to worry about programming language syntax
• There is currently no firmly established standard for Pseudo Code
• Pseudo-code is not actually executed on a computer, it simply provides a means for programmers to "Think out" their programs before they implement them
• A carefully prepared pseudo code program can be easily converted to a programming language such as C++ or Java.
• HOW TO WRITE PSEUDO CODE?
• Any algorithm will eventually need to have its instructions performed by a computer
• For this reason the keywords used in Pseudo code are based on the main functions fo a computer.
• Rules for Pseudo-code
• INPUT
• READ get input from a file
• GET    get input from the keyboard
• ARITHMETIC / CALCULATIONS
• +_ * / ( ) =
• OUTPUT
• PRINT output to a printer
• WRITE output to a file
• DISPLAY output to a monitor
• STORE
• SET total_price to 0
• total_price = cost_price + tax
• COMPARE
• IF student is part time THEN ADD 1 to part time ELSE ADD 1 to full time ENDIF
• REPETITION
• DOWHILE student_total < 50 READ student_record ADD 1 to student_total ENDDO
• WHILE student_total < 50 READ student_record ADD 1 to student_total ENDWHILE
• Examples

Algorithm tools

• Pseudo-code and Flow charts can be useful tools that help develop describe algorithms
• Pseudo-code is a tool that is used to describe detailed algorithms before translation into a programming language.
• A flow chart is a graphical method of designing structured computer programs

Algorithms

• Just about any computing problem can be solved by executing a series of actions in a specific order.
• An algorithm is a procedure for solving problem in terms of 
1. the action to be performed
2. the order in which these actions are to be executed
• Effective planning and design make computer programming a much more time effective and efficient process
• Algorithms allow us to plan and design our computer programs
• Producing a computer program without planning and designing is like tyr to find an address without a map.
• Algorithms are developed by breaking a problem in small logic steps and them placing each of those steps in the correct order.
• Think about all the actions you need to perform to drive to the shops
• write them all down
• then place each of the actions you have written down in the correct order
• you have just developed a basic algorithm
• 
  

Definitions

• Data flow diagram
• A two dimensional diagram that explains how data is processed and transferred in a system. The graphic identifies each source od data and how it interacts with other data source to reach a common output
• Data models
• It is the formalisation and documentation of existing processes and events that occur during application software design and development. Data modelling techniques and tools capture and translate complex system design into easily understood representations of the data flows and processes.
• Modular programming
• It is the formalisation and documentation of existing processes and events that occur during application software design and development. Data modelling technique and tools capture and translate complex system design into easily understood representations of the data flows and processes.
• Structured programming
• It is the process of subdividing a computer program into separate sub-programs,
• Structured system design
• It is a set of standard for application design. It uses a formal methodical approach to the analysis and design information system.

The DIfference

• Structured Approach
• Provides the computer with step by step instructions and the programmer has to specify every little procedural detail.
• Unfortunately, most people have difficulty thinking in terms of procedural details, particularly when the procedure is complex.
• To make it easier to create logically correct programs programmers devised the structured programming methods which limits the programmer to three types of structures to minimize logical errors and to make errors easier to find and correct
• Sequence of instruction
• A choice whether one set of instructions is carried out to another set of instructions is carried out
• Repetition of a set of instructions
• As programs became more complex, additional methods and rules were created.
• Modular programming
• Structured system design
• Object Oriented Approach
• Views a computer system as a collection of interacting objects
• Defining what the user requires means defining all of the types of objects that are part of the user's work environment.
• Design a computer system and how the interact.
• Wire framing and specification technique documenting complex business logic and interaction. This allows the designer to decompose a screen in a manner that reduce complexity.

Defining the problem

• Before spending time trying to solve a programming problem, it is essential that your first understand the problem to be solved.
• read, read, read
• ask questions
• clarify anything you are not sure of
• try writing the problem in your own words
• produce an input processing output chart
• Designing a solution
• Once the problem is understood, the next step is to design a solution for the problem
• This usually involves breaking the problem into smaller pieces and producing an algorithm for each piece.
• An algorithm is a step by step process that needs to be followed in order to solve a problem.
• Testing the design
• Once the solution has been designed, it is important to check that the deigned solution actually solves the problem
• This involves performing a desk check of each algorithm.
• A desk check may involve using test input data and working through each algorithm using this test input.
• Implementing the solution
• Testing the solution
• Once the solution has been written the new program needs to be tested
• A bank of test input should be used to test every conceivable input into the program
• The test result should be recorded and appropriately documented.
• Documenting the solution
• Of extreme importance is the proper documentation of program you produce
• Program documentation may consist of source code comments user manuals, installation guides etc
• Proper documentation is important because it assists other people in understanding and using your program.

Computer Functions

The four main function of a computer system are:

• Input devices
• The following are some common devices used for computer input.
• keyboard
• mouse
• scanner
• microphone
• Devices such as the ones above are often referred to as peripherals.
• Storage
• Computer input is stored in a computers memory.
• Most computers have two types of storage. Primary storage and Secondary storage.
• Processing
• Once data has been input into a computer and stored that data can then be processed.
• In modern computers the processing is usually done by the Central Processing Unit.
• Output
• Without some form of output, computers would not be much use to humans
• The following are some common output devices
• monitors
• printers
• speakers
• plotters
• Structured Program Design
• Armed with our knowledge of four basic computer functions, how do we design computer programs to make a computer do something useful?
• Structured Design Process

Computer System

• Computer Systems consist of two main areas. Computer Hardware and Computer Software.
• Computer Software refers to the programs that make computers perform useful tasks.
• Without software, computers are just piles of plastic and metal.
• Computer Software
• Operating System
• Application Programs
• Applications are programs that are written to perform a specific set of functions or tasks.
• Applications are run on top of a computer systems operating system.
• Structured Programming
• Until the 1990;s structured programming was the most popular method for developing computer programs.
• Structured programming was developed in the 1960;s in an attempt to overcome problems of software development efficiency.
• Structured programming designates breaking a problem into small pieces and then completing each piece of the problem in the logical order
• Divide and Conquer
• Object Oriented Programming
• Object oriented design and programming is concerned with breaking a problem into objects and then modelling each object with a program.
• Object oriented programming has many benefits including easier error checking and software re-use. 

Programming languages

The Language of Computers

• Computers use a language of 1's and 0's based on the binary number system
• Computers use a language of 1's and 0's because their operation is based on devices that operate best in a two state mode
• This computer language is often referred to as machine language.

The Language of Humans

• Human do not use a language of 1's and 0's for everyday verbal communication
• Human speak in what is know as natural language

How Human communicate with computers?

• In the early days of computer programming, programmers had to learn the combinations of 1's and 0's that represented commands to the computer.
• Since those days programming languages have been developed to bridge the gap between human language and computer language.
• Programming language symbolically represent the 1's and 0's that computer understand.
• For example a single statement in C++ can represent many machine language instruction.

High level and low level programming languages

• Low level programming languages are languages which are closer to the actual machine language that computers understand
• High level programming languages are languages which are closer to the natural speak that human use.

Programming Language