Está en la página 1de 16
UNIVERSIDADTECNOLOGICA DE LA SELVA Antología Programación de Aplicaciones. Ing. Gloria de Jesús Escobar Guillén
UNIVERSIDADTECNOLOGICA DE LA SELVA Antología Programación de Aplicaciones. Ing. Gloria de Jesús Escobar Guillén

UNIVERSIDADTECNOLOGICA DE LA SELVA

Antología

UNIVERSIDADTECNOLOGICA DE LA SELVA Antología Programación de Aplicaciones. Ing. Gloria de Jesús Escobar Guillén

Programación de Aplicaciones.

Ing. Gloria de Jesús Escobar Guillén

11/12/2014

CONTENIDO

UNIDAD I. PRINCIPIOS BÁSICOS DE LA PROGRAMACIÓN ORIENTADA A

3

UNIDAD II. CONCEPTOS AVANZADOS DE LA PROGRAMACIÓN ORIENTA A

7

UNIDAD

III.

PATRONES DE DISEÑO

9

UNIDAD IV. SEGURIDAD EN EL DESARROLLO DE

11

UNIDAD I. PRINCIPIOS BÁSICOS DE LA PROGRAMACIÓN ORIENTADA A OBJETOS.

1. Unidad Temática

I.

Principios Básicos de la Programación Orientada a Objetos.

2. Horas Prácticas

5

3. Horas Teóricas

5

4. Horas Totales

10

5. Objetivo

El alumno programará aplicaciones Orientadas a Objetos para satisfacer las necesidades básicas de la empresa.

Temas

Saber

Saber hacer

 

Ser

Paradigma

de

POO,

Definir los conceptos de clase, objetos, atributos, métodos y herencia. Reconocer las buenas prácticas de programación.

Formular programas empleando las clases, objetos, atributos, métodos y herencia.

Analítico

Clases

y

Objetos,

Ordenado

Atributos, Métodos Herencia.

y

Sistemático

Objetivo

   

Ético

 

Coherente

Proactivo

Asertivo

Agregación

 

y

Definir los conceptos de Agregación y Asociación.

Emplear el paradigma de POO

Analítico

asociación.

Ordenado

 

en

una

aplicación

Sistemático

solicitada.

Concepto de clase.

 

Una clase define las características y comportamientos comunes de los objetos.

En otras palabras la clase es el molde para la creación de los mismos.

Las clases son declaraciones de objetos, también se podrían definir como abstracciones de objetos.

Una clase es la estructura de un objeto, es decir, la definición de todos los elementos de que está hecho un objeto.

Una clase se compone de dos partes:

o

Atributos

o Métodos

Concepto de objetos.

Los objetos tienen características y comportamientos que están definidas de la clase de donde se instancian.

Los objetos son ejemplares de una clase cualquiera.

Un objeto es, por lo tanto, el "resultado" de una clase.

En realidad, un objeto es una instancia de una clase, por lo que se pueden

intercambiar los términos objeto o instancia (o incluso evento).

Un objeto posee:

o

Estado.

Lo que el objeto sabe

El estado de un objeto es una de las posibles condiciones en que el objeto puede existir.

El estado normalmente cambia en el transcurso del tiempo.

El estado de un objeto es implementado por un conjunto de propiedades (atributos), además de las conexiones que puede tener con otros objetos.

o

Comportamiento

Lo que el objeto puede hacer

El comportamiento de un objeto determina cómo éste actúa y reacciona frente a las peticiones de otros objetos.

Es modelado por un conjunto de mensajes a los que el objeto puede responder (operaciones que puede realizar).

Se implementa mediante métodos.

o

Identidad

Los objetos se distinguen unos de otros.

Concepto de atributos. Las propiedades o atributos son las características de los objetos. Cuando definimos una propiedad normalmente especificamos su nombre y su tipo. Nos podemos hacer a la idea de que las propiedades son algo así como variables donde almacenamos datos relacionados con los objetos.

Concepto de métodos. Son las funcionalidades asociadas a los objetos. Cuando estamos programando las clases las llamamos métodos. Los métodos son como funciones que están asociadas a un objeto.

Concepto de herencia. Tomar características y funcionalidades definidas en otras clases. Ejemplo:

Auto hereda de vehículo motorizado. Como grúa también hereda de vehículo automotor. La herencia sirve para crear objetos que incorporen propiedades y métodos de otros objetos. Así podremos construir unos objetos a partir de otros sin tener que reescribirlo todo.

Asociación Una asociación es una relación semántica entre objetos. Cuando un objeto accede a los atributos y métodos de otro objeto estamos definiendo una asociación entre ellos.

La asociación se podría definir como el momento en que dos objetos se unen para trabajar juntos y así, alcanzar una meta.

Ambos objetos son independientes entre sí. Para validar la asociación, la frase “Usa un”, debe tener sentido:

El ingeniero usa una computadora. El cliente usa tarjeta de crédito.

debe tener sentido: El ingeniero usa una computadora. El cliente usa tarjeta de crédito . Ejemplo

Ejemplo de asociación.

Agregación. La agregación es una relación que define que un objeto es parte de otro

Agregación. La agregación es una relación que define que un objeto es parte de otro objeto. Cuando definimos que un objeto tiene como atributo otro objeto decimos que es una agregación. A través de la agregación se definen objetos compuestos.

En las relaciones de agregación si existe el todo y la parte. Puede ser de tipo composición o contenedor. En la composición la parte no puede existir sin el todo. El catalogo tiene productos. La empresa tiene departamentos.

la parte no puede existir sin el todo. El catalogo tiene productos. La empresa tiene departamentos.

Ejemplo agregación.

la parte no puede existir sin el todo. El catalogo tiene productos. La empresa tiene departamentos.

UNIDAD II. CONCEPTOS AVANZADOS DE LA PROGRAMACIÓN ORIENTA A OBJETOS.

1. Unidad Temática

II.

Conceptos avanzados de la programación orientada a objetos.

2. Horas Prácticas

10

3. Horas Teóricas

5

4. Horas Totales

15

 

El alumno programará aplicaciones Orientadas a Objetos mediante

5. Objetivo

los conceptos avanzados de este paradigma, para integrar la información en los sistemas.

Temas

Saber

Saber hacer

Ser

Polimorfismo.

Identificar

el

concepto

Desarrollar aplicaciones empleando el concepto de Polimorfismo en un programa.

Analítico

de

Polimorfismo

en

el

Ordenado

POO.

Sistemático

 

Objetivo

Ético

Coherente

Proactivo

Planificador

Creativo

Innovador

Clases

Identificar el concepto de clases abstractas en el POO.

Desarrollar aplicaciones empleando el concepto de clases abstractas.

Analítico

Abstractas.

Ordenado

 

Sistemático

 

Objetivo

Ético

Coherente

Proactivo

Planificador

Creativo

Innovador

Temas

Saber

Saber hacer

Ser

Interfaces.

Identificar el concepto de interfaces en el POO.

Programar una aplicación empleando conceptos avanzados de programación Orientada a Objetos.

Analítico

Ordenado

 

Sistemático

 

Objetivo

Coherente

Proactivo

Planificador

Creativo

Innovador

Polimorfismo. La forma en la que podemos tratar una subclase como si fuera una Clase del tipo de su superclase, usando solo los métodos o atributos disponibles para la Clase declarada. Muchas formas. Capacidad que tienen los objetos de comportarse de múltiples formas, programando de manera general en vez de hacerlo de forma específica. Ejemplo polimorfismo. class FiguraGeometrica{

}

class Triangulo extends FiguraGeometrica {

}

public class Principal{

public void metodo(){ /**Puedo crear objetos polimorficos Objeto Triangulo de tipo FiguraGeometrica*/ FiguraGeometrica triangulo=new Triangulo();

}

}

Vemos que FiguraGeometrica es la superclase y Triangulo es la clase hija o subclase, y por medio del polimorfismo podemos crear una instancia de Triangulo de tipo FiguraGeometrica

UNIDAD III. PATRONES DE DISEÑO.

1. Unidad Temática

III.

Patrones de diseño.

2. Horas Prácticas

25

3. Horas Teóricas

15

4. Horas Totales

40

5. Objetivo

El alumno desarrollará aplicaciones utilizando patrones de diseño para optimizar el desempeño de la solución.

Temas

Saber

Saber hacer

Ser

Conceptos básicos de un patrón de diseño.

Identificar

los

 

Analítico

conceptos de un patrón de diseño.

Ordenado

 

Sistemático

 

Objetivo

Patrones de diseño.

Identificar

las

Desarrollar aplicaciones empleando diferentes patrones de diseño.

Analítico

características de los diferentes patrones de diseño existentes:

Ordenado

Sistemático

Objetivo

Singleton.

Coherente

Factory.

 

Proactivo

Proxy.

Planificador

MVC.

Creativo

Innovador

Comprometido

Responsable

Patrones de Diseño. Es un tema importante en el desarrollo de software actual. Busca ayudar a la comunidad de desarrolladores de software a resolver problemas comunes. El uso de patrones ayuda a obtener un software de calidad.

Definición de un patrón.

Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno y describe también el núcleo de la solución al problema, de forma que puede utilizarse un millón de veces sin tener que hacer dos veces lo mismo.

Un patrón de diseño es una descripción de clases y objetos comunicándose entre sí, adaptada para resolver un problema de diseño general en un contexto particular.

Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en el desarrollo de software.

Elementos de un patrón.

Nombre.

o Describe el problema de diseño.

El problema.

o Describe cuando aplicar un patrón.

La solución.

o Describe los elementos que componen el diseño, sus relaciones, responsabilidades y colaboración.

Las consecuencias.

o Determinar cuáles son los costos y beneficios obtenidos.

Clasificación de los patrones.

Patrones Creacionales:

o Inicialización y configuración de objetos.

Patrones Estructurales:

o Separan la interfaz de la implementación. Se ocupan de cómo las clases y objetos se agrupan, para formar estructuras más grandes.

Patrones de Comportamiento:

o

Más que describir objetos o clases, describen la comunicación entre ellos.

 

Creacionales

Estructurales

De comportamiento

Abstracta

Fábrica

Adaptador

Cadena

de

(Abstrac

Factory)

(Adapter).

responsabilidad

ámbito objeto.

Puente (Bridge).

(Chain

of

Método

de

Objeto

responsibility).

Fabricación (Factory

Compuesto

Orden (Command).

Method)

ámbito

(Composite).

Intérprete

clase.

Envoltorio

(Interpreter).

Prototipado

 

(Decorator).

Iterador (Iterator).

(Prototype).

Fachada (Facade).

Mediador (Mediator)

Singleton .

Ligero

Peso

.

MVC

(Model

View

(Flyweight).

Recuerdo (Memento)

Controler).

Apoderado

.

 

(Proxy).

Observador (Observer).

Estado (Server).

Estrategia (Strategy) .

Método plantilla(Template Method).

Visitante (Visitor).

UNIDAD IV. SEGURIDAD EN EL DESARROLLO DE APLICACIONES.

1. Unidad Temática

IV.

Seguridad en el desarrollo de aplicaciones.

2. Horas Prácticas

4

3. Horas Teóricas

6

4. Horas Totales

10

5. Objetivo

El alumno utilizará las mejores prácticas en el campo de la Seguridad de Software para el desarrollo de aplicaciones confiables.

Temas

Saber

Saber hacer

Ser

Seguridad

en

Definir seguridad en informática aplicada a la programación.

 

Ordenado

Informática.

Sistemático

Objetivo

Mejores Prácticas de seguridad del software.

Identificar las mejores

Desarrollar

Analítico

prácticas

en

la

aplicaciones

Ordenado

 

seguridad

del

empleando mejores

Sistemático

software

en

el

prácticas

de

Objetivo

desarrollo

de

seguridad

en

la

Coherente

aplicaciones.

generación

de

Proactivo

aplicaciones

Planificador

confiables.

Creativo

Innovador

Organizado

Responsable

Disciplinado

Comprometido

Ético

Seguridad en el desarrollo de aplicaciones Hablaremos de la seguridad desde el punto de vista del programador, es decir, de aquello que tenemos que tener en cuenta en las etapas de diseño y codificación de los programas.

Describiremos algunos errores de programación habituales que tienen implicaciones desde el punto de vista de la seguridad, daremos ejemplos de cómo se han usado para romper la seguridad de aplicaciones reales y comentaremos técnicas para detectar y corregir estos errores.

Principios de seguridad Se suele decir que los tres objetivos fundamentales de la seguridad informática son:

Confidencialidad:

autorizados.

el

acceso

a

los

activos

del

sistema

está

limitado

a

usuarios

Integridad: los activos del sistema solo pueden ser borrados o modificados por usuarios autorizados.

Disponibilidad: el acceso a los activos en un tiempo razonable está garantizado para usuarios autorizados. Hay que identificar los objetos de seguridad de una aplicación para saber si un diseño o implementación los satisfacen. Commoncriteria o CC(ISO/IEC 15408:1999): estándar internacional para identificar y definir requisitos de seguridad. Se suele emplear para redactar dos tipos de documentos.

Perfil de protección (Protection Profile o PP): es un documento que define las propiedades de seguridad que se desea que tenga un producto; básicamente se trata de un listado de requisitos de seguridad.

Objetivo de seguridad (Security Target o ST): es un documento que describe lo que hace un producto que es relevante desde un punto de vista de la seguridad.

Los CC definen un conjunto de requisitos funcionales de seguridad que puede necesitar una aplicación.

Auditoria de seguridad: permite el registro de eventos (hay que identificar cuáles pueden ser interesantes desde el punto de vista de la seguridad).

No rechazo (Non-repudiation): uso de técnicas para verificar la identidad del emisor y/o receptor de un mensaje.

Soporte criptográfico: si se usa criptografía ¿Qué operaciones la usan? ¿Qué algoritmos y tamaños de clave se usan? ¿Cómo gestionan las claves?

Requisitos funcionales

Protección de datos de usuarios: especificar una política para la gestión de datos de usuario (control de acceso y reglas de flujo de información).

Identificación y autenticación: uso de técnicas de validación de identidad.

Gestión de seguridad: definición de perfiles de usuarios y niveles de acceso asociados.

Privacidad: soporte del anonimato de los usuarios.

Autodefensa: la aplicación debe incluir sistemas de validación de su funcionamiento y fallar de manera segura si esa validación no se cumple.

Utilización de recursos: soporte a la asignación de recursos, tolerancia a fallos.

Control de acceso: soporte de sistema que limiten en número y tipo de sesiones anteriores al usuario para ayudar a la detección de intrusos.

Rutas o canales fiables: existencia de mecanismos que permitan al usuario identificar que acceden a la aplicación real. Desarrollo de aplicaciones seguras

Para desarrolla una aplicación segura debemos tener en cuenta los siguientes aspectos:

1. Control de la entrada: validar todas las entradas.

2. Gestión de memoria: desbordamiento de buffers.

3. Estructura interna de diseño del programa.

4. Llamadas a recursos externos: bibliotecas, scripts, etc.

5.

Control de la salida: formato, restricciones.

6. Problemas de los lenguajes de programación

7. Otros: algoritmos criptográficos, de autentificación.

Control de entrada Hay que validar todas las entradas que vienen de fuentes no fiables. Se debe determinar que es legal y rechazar lo que no lo sea; siempre se debe verificar que algo es legal, la aproximación es contraria (detección de entradas erróneas) puede fallar. El sistema se debe verificar generando entradas erróneas desconocidas. Desbordamientos de buffer

Se producen cuando un atacante puede conseguir escribir datos fuera de los límites de un buffer (generalmente más allá del final), con lo que sobre escribe valores preexistentes.

Si el buffer está en la pila el ataque se llama stack over flow y puede permitir cambiar direcciones de retorno e incluir código para ser ejecutado, que es lo que suelen hacer los exploits de este tipo de errores.

Es posible porque C, C++ o el ensamblador no validan el acceso a los límites de los buffers.

Como evitar desbordamientos de buffer en C/C++

Evitar o usar con mucho cuidado funciones peligrosas como gets, strcpy, strcat, sprintf, scanf.

Trabajar de un modo consistente con funciones que trabajan con buffers de tamaño fijo o dinámico:

C estándar con tamaño fijo: strncpy, strncat.

strlcpy y strlcat (OpenBSD, más fáciles y consistentes que strncpy y strncat).

C estándar con gestión dinámica: malloc.

C++ estándar: std::string.

Estructura y diseño de programas

Seguir principios de la ingeniería del software:

Siempre se debe trabajar con privilegios mínimos.

Simplicidad en el diseño: KISS.

Diseño abierto: no hay que depender de la ocultación.

Mediación completa: todos los accesos se controlan.

Valores por defecto seguros: acceso cerrado.

Separación de privilegios: control acceso multi-nivel.

Mínimo uso de recursos compartidos (p.ej. /tmp).

Facilidad de uso: los usuarios colaboran más.

Interfaz segura: debe ser mínima (simple), dar acceso a las funciones justas y no ser evitable. Siempre se asume que la confianza es mínima.

Separación de control y datos: no se debe soportar el uso de macros almacenadas en los documentos.

Minimización de privilegios: Concesión de privilegios mínimos, se abandonan en cuanto no son necesarios (ej. apertura puertos TCP), se controla su tiempo de validez y se conceden al mínimo número de módulos posible.

FUENTES BIBLIOGRÁFICAS

Autor

Año

Título del Documento

   

Ciudad

País

Editorial

Erich

(2008)

Patrones de Diseño

   

Madrid

España

Addison Wesley

Gamma

   

Garrido,

(2003)

Object-Oriented Programming

 

San

Jose

USA

Charles

River

José M.

(From

Problem

Solving

to

California

Media

JAVA) (Programming Series)

 

James

W.

(2002)

Introduction to Design Patterns in C#.

 

San

Jose

USA

Addison-

Cooper

California

Wesley

   

Professional

Steven

(2004)

Design Patterns in C#

   

San

Jose

USA

Addison-

John

California

Wesley

Metsker

   

Professional

 

REFERENCIAS (INTERNET)

 
 

Fecha de

     

Autor

 

creación

Título del Documento

 

Consultado

 

Referencia

Yasar,

(2008,

Best Practices for software security: An overview.

31 de Marzo de

http://ieeexplore.ie

Preuveneers,

diciembre

2009.

ee.org/xpl/freeabs _all.jsp?isnumber=

Berbers

 

24)

   

4777689&arnumbe

r=4777730&count=

119&index=40