3.

2 The Object-Oriented Approach

Object orientation can be described as the set of disciplines that develop and modernize software that
facilitate the construction of complex systems from components.

The intuitive appeal of object orientation is that it provides concepts and tools with which to model and
represent the real world as closely as possible. These object-oriented concepts and tools are
technologies that allow real-world problems to be expressed easily and naturally.

Object-oriented techniques provide improvements and methodologies for building complex software
systems from modularized and reusable software units. A new approach is needed to build software
today.

This new approach must be able to manipulate both large and small systems and must create reliable
systems that are flexible, maintainable, and able to evolve to meet the needs of change.

Object orientation tries to meet the needs of end users, as well as those of software product developers.

These tasks are performed by modeling the real world. The fundamental support is the object
model.

An object is the instance of a class. A class is the abstract representation of a concept in

the real world, and provides the basis from which we instantiate specific objects. As an
example, you can create a class that defines a client. You can then create a new instance
of the client class to have a usable Client object. Before you can create an object of the
client class, you must create a new instance based on that class.
All objects are made up of three things:
Interface : The Interface is the set of methods, properties, events and attributes that are
declared public in their scope and that can be invoked by programs written to use our
object.
Implementation : The code inside the methods is called Implementation. It is also
sometimes called behavior , since this code is what actually makes the object do useful
work. It is important to understand that client applications can use our object, even if we
change the implementation, as long as we do not change the interface. As long as our
method name, parameter list, and return data type remain unchanged, we can change the
implementation entirely.
State : The state or data of an object is what makes it different from other objects of the same class.
The state is described through Member or Instance variables. Member variables are those declared
such that they are available to all code within the class. Typically, member variables are Private in
scope. Sometimes they are known as instance variables or attributes. Note that properties are not
Member variables, as they are a type of method that functions to retrieve and set values.

3.2.1 Analysis
The analysis model is then extended to describe how actors and the system interact to
manipulate the application domain model. Developers use the analysis model, along with
non-functional requirements, to prepare the system architecture that is developed during
high-level design.
The activities of analysis: the identification of objects, their behavior, their relationships,
their classification and their organization.
The analysis model is composed of three individual models: the functional model,
represented by use cases and scenarios, the analysis object model, represented by class
and object diagrams, and the dynamic model, represented by state charts and diagrams. of
sequence.
Analysis concepts
Particularly we describe: The analysis for the object-oriented approach; Instead of
considering SW from a basic input-process-output perspective like structured methods, it
is based on modeling the system through the objects that are part of it and the static
(inheritance and composition) or dynamic (use among other objects) relationships. The
analysis identifies the classes and objects relatively in the problem domain, the design
provides details about the architecture, interfaces and components, the implementation
transforms the design into code and the tests check both the architecture and the interface
and components. The approach to object-oriented analysis is based on five layers. Those
five layers consist of class/object layer, structure layer, attribute layer, service layer, and
theme layer.
These layers give greater power to representing the complexity of analysis and
design in flexible systems.
1.- Class/Object Layer: This analysis and design layer indicates the classes and objects.
2.- Structure Layer: This layer captures various class and object structures, such as one-
to-many relationships.
3.- Attributes Layer: This layer details the attributes of the classes.
4.- Services Layer: This layer indicates the messages and behaviors of the objects.
5.- Theme Layer: This layer divides the design into implementation units or equipment
assignments.
Analysis of Classes and Objects
Object: It is an abstraction of something in a problem domain that reflects the capabilities
of a system to carry information about it, interact with it, or both. An encapsulation of
attribute values and their unique services.
Class: A description of one or more objects with a set of uniform attributes and services,
including a description of how to create new objects in the class.
In the analysis of classes and Objects, objects and classes are identified as candidates for the
application to be developed. Classes and objects can be obtained by doing a grammatical analysis of
the problem description, highlighting terms that could be represented with objects within the
system.
To represent classes, objects and object classes, the following notation is used
Objects that have occurrence of a class are represented by a shaded box surrounded by the class.
Because objects have occurrences of a class, it is not possible for objects to exist independently of
their class.
3.2.2 Design.
During object design we bridge the gap between application objects and made components,
identifying additional solution objects and refining existing objects.
Object design includes:
 Service specification: Which we precisely describe each class interface.
 Component selection: Which we identify made components and additional solution
objects.
 Restructuring of the object model: In which we transform the object design model to
improve its understandability and extensibility.
 Object model optimization : In which we transform the object design model to address
performance criteria, such as response time or memory utilization.

Object design, like system design, is not algorithmic, sometimes difficult to clearly distinguish from
Object Oriented (OO) analysis and design.

Object Oriented Design

The approach posits that analysis is reasonably independent of technology, whereas
design becomes increasingly oriented toward a particular OO language and development
environment.
OO design activities are grouped into the four main components of the final system: The problem
component, the human interface component, the data management component, and the task
management component , all of which are expanded across the five layers that the OO design has,
the same ones that were previously presented in the OO analysis.

Activity corresponding to unit 3

Contains the correct answer
1.- Is it a set of three elements that facilitate control over the software development
process?
a) Myths b) Tools c) Paradigm

2.- Are they composed of figures connected with arrows? To execute a process, start at the
Start and follow the actions indicated by each figure?
a) Structured approach b) Flowcharts c) Process

3. Named after the first data flow diagram component?

a) Structured approach b) Paradigm c) Process

4. Used to model a collection of data packets at rest. It is denoted by two parallel lines.
a) Data store b) External entity c) data dictionary
5. This layer captures various class and object structures, such as one-to-many
relationships.
a) Attributes Layer b) Services Layer c) Structure Layer
UNIT 4
SOFTWARE PROCESS MODELS
Objective: You will identify the different process models that are applied in software
development.
Each model is a description of a software process that is presented from a particular
perspective. Alternatively, the terms life cycle and life cycle model are sometimes used.
Each model describes a succession of phases and a chain between them. Depending
on the phases and the way in which this chain occurs, we have different process models.
One model is more suitable than another to develop a project depending on a set of its
characteristics. There is a wide variety of different models, among which we have those
described below.
4.1 Waterfall model
The linear model (or waterfall model).
It is the oldest of all Software Engineering models. The linear model presents a sequential
structure (hence the name Cascade Model) made up of six phases or stages:
 System Analysis.

 Analysis of Software Requirements.

 Design.

 Coding.

 Test.

 Maintenance.

The phases include within themselves certain tasks that clearly classify the work to be
done. The development of the phases, as I mentioned before, occurs sequentially. Once the
analysis of both the System and the software requirements demanded by the client has
occurred (phases in which the client's intervention is absolutely necessary), we proceed to
the design phase of the global software architecture.

A carefully crafted design will lead to fast coding. After having translated the program into a
language understandable by the computer, the elements are checked individually and later
homogeneously (all systems at the same time). Once the software is delivered to the client, the
Maintenance phase will include the updates and bug fixes that are necessary in the program.
The spiral model.
The spiral model for software engineering has been developed to cover the best features of
both the classic life cycle and prototyping, while adding a new element: risk analysis. The
model represented by the spiral defines four main activities:

 Planning: Determination of objectives, alternatives and restrictions.

 Risk analysis: Analysis of alternatives and identification/resolution of risks.

 Engineering: “Next level” product development,

 Client evaluation: Valuation of engineering results.

During the first turn around the spiral, objectives, alternatives and restrictions are defined, and risks
are analyzed and identified. If the risk analysis indicates that there is uncertainty in the
requirements, prototyping in the engineering quadrant can be used to assist both the developer
and the customer.

The client evaluates the engineering work (client evaluation quadrant) and suggests
modifications. Based on the client's feedback, the next phase of planning and risk analysis
occurs. At each loop around the spiral, the culmination of the risk analysis results in a “go or
no go” decision.
With each iteration around the spiral (starting at the center and moving outwards),
successive versions of the software are built, each time more complete and, in the end, the
operational system itself.
The spiral model paradigm for software engineering is currently the most realistic approach for
large-scale software and systems development.
4.3 Incremental model.
Description
 Combines elements of the linear model with the prototyping philosophy.

 The first increment is often an essential product (core).

 Based on the evaluation, the next increase is planned and so on.

 It is interactive in nature.

 It is useful when the staff is not enough for full implementation.

Advantages.
 The project can be financed in parts.

 Suitable for large, long-term projects.

 Not as many staff are needed at the beginning as for a full implementation.
4.4 Unified development process.
For several years the traditional waterfall model has been used, demonstrating in practice
that it does not reflect in reality the complexity inherent to the software development
process.
As an alternative solution to this problem, iterative and incremental models were subsequently
defined that work adequately with high levels of risk, and allow software releases to be delivered in
early stages; Such is the case of the Unified Process proposed by IBM, which includes key practices
and aspects related to strategic planning and risk management.

The unified process, known as RUP , is a software model that allows large-scale software
development, through a continuous process of testing and feedback, guaranteeing compliance with
certain quality standards.

Conception phase.
The purpose of this phase is to define and agree on the scope of the project with the
sponsors, identify the potential risks associated with the project, propose a very general
vision of the software architecture and produce the phase plan and the iteration plan.
Preparation phase.
The use cases that allow defining the base architecture of the system are selected and will
be developed in this phase, the specification of the selected use cases is carried out and
the first analysis of the problem domain is carried out, the preliminary solution is designed.
Construction phase.
The purpose of this phase is to complete the functionality of the system. To do this, pending
requirements must be clarified, changes managed according to the evaluations made by
users, and improvements for the project are made.
Transition phase.
The purpose of this phase is to ensure that the software is available to end users, fix bugs and
defects found in acceptance testing, train users, and provide necessary technical support.
4.5 Personal Software Process.
PERSONAL SOFTWARE PROCESS (PSP)
Each developer uses different processes to build software, these may not be efficient or
successful or they may also change daily, but there is a process.
WATTS HUMPHREY says that to change an ineffective process you have to go through four phases
and these require training and instrumentation. PSP
I highlight the personal measure to the planning professional, it also makes the professional
responsible for the planning of the project and the quality of all products.
There are 5 framework activities that are:
1. Planning: Here the requirements are selected and the size and estimation of resources
is developed. These measurements are noted in templates and at the end development
tasks are identified and a project schedule is created.

2. High-level design: External factors are analyzed and prototypes are built when there is
uncertainty.

3. High-level design review: Verification methods are applied to errors discovered in the
design.

4. Development: The design is refined and reviewed and the code is verified and compiled,
and all measurements are saved for work results.

5. Analysis of results: Here the effectiveness of the process is determined, analyzing all
the data available.

The PSP highlights that every engineer has the need to identify errors and understand the
importance and types of errors that are usually made.
Description.
 In 1995 the PSP was proposed by Watts Humphrey, it was initially aimed at students.

 By 1997 with the release of the book "An Introduction to the Personal Software Process"
the PSP was already intended for engineers.

 The PSP is characterized because it is for personal use and is applied to small programs
of less than 10,000 lines of code.

 The PSP serves to produce quality software, where each engineer must work on the need
to perform quality work.

 The PSP seeks to provide a framework for personnel involved in the software
development process.
PSP Goals.
 Achieve a discipline of continuous improvement in the development process.
 Improve the quality of the development process.

 In general, PSP provides quality and productivity.

Disadvantages of applying PSP.

 The time required to know it.

 The emotional cost of maintaining discipline.

Advantages of applying PSP.

 The idea that we gain talent and skill.

 Stimulation by new ideas.

 Take control of one's own work.

 The conviction that it is the best thing to do.

ACTIVITY CORRESPONDING TO UNIT 4

Make a general synoptic table of the software process models.