Universidad Central

II-51 Programación Internet

Profesor:
Ing. Mauricio Rivera, Lic

Oficina: 2000-7665
Cel: 8899-4044
e-mail: mrivera@universidadcentral.ac.cr
 Evaluación del Curso

Avance Uno 5%
Avance Dos 5%
Primer Parte Proyecto 10 %
Segunda Parte Proyecto 10 %
Laboratorios 25 %
Trabajos Investigativos 15 %
Proyecto Final (Tercera Parte) 30 %
100% Total
 Programa del Curso

 Orientación a Objetos
 UML (Unified Modeling Languaje)
Modelo Conceptual
Casos de Uso
 HTML5
 JavaScript
 CSS
 PHP
 OTROS

3
 Cronograma del Curso
Semanas Temas Entregables
Semana 1 Tema 1 - Modelo conceptual, Orientación a Buscar Tema de proyecto
objetos, Glosario de términos, Casos de Uso. Laboratorio
Asignación Proyecto

Semana 2 Tema 2 - HTML, Formato Texto, Tablas, Se realiza

Hipervínculos, imágenes Laboratorio
Semana 3 Tema 3 – Formularios, Frames, etc Laboratorio

Semana 4 Tema 4 – CSS Entrega Avance

Estructura el modelo de caja. Laboratorio

Semana 5 Entrega de primera parte del proyecto Entrega Primer Parte

Proyecto.
Semana 6 Tema 5 – CSS Figuras y formas Laboratorio
tridimensionales Sombras
Semana 7 Tema 6 – CSS Validaciones Script Laboratorio
Nuevas etiquetas

Semana 8 Tema 7 – Bootstrap Laboratorio 4

 Cronograma del Curso
Semanas Temas Entregables
Semana 9 Tema 8 – PHP Laboratorio

Semana 10 Entrega Segunda parte proyecto Entrega Segunda parte

proyecto
Semana 11 Tema 9 – JavaScript Sintaxis Laboratorio
Programación, DOM

Semana 12 Tema 10 – HTML5 Canvas, Drag and Drop, Segundo Avance Proyecto
Archivos, Base de Datos , NodeJS Laboratorio

Semana 13 Tema 11 – HTML5 Drag and Drop, Laboratorio

Archivos, Base de Datos, Inicio PHP
Semana 14 Tema 11 – ANGULAR y REACT Laboratorio

Semana 15 Entrega final de proyecto. Entrega Final del proyecto

5
Los temas Investigativos se asignarán según temas que se avancen
 Bibliografía

 Fowler, Martin UML y Patrones. Introducción al análisis y diseño orientado a

objetos. Prentice Hall, México 1999.

 G. Booch, J. Rumbaugh, I. Jacobson. El Lenguaje Unificado de Modelado.

Addison Wesley Iberoamericana, Madrid 1999.

 Ferré, Xavier. Desarrollo Orientado a Objetos con UML. Facultad de

Informática, Universidad Politécnica de Madrid, España 2000.

6
 Que es Orientación a Objetos?

Es una filosofía de Análisis, Diseño, construcción e

Implementación de software y Hardware. De esta
manera requiere de una manera diferente de
abordar los problemas y sus soluciones.

La finalidad de esta filosofía es la de hacer de la

ingeniería de software un proceso más intuitivo
para los programadores, analistas y diseñadores 7
Porque la programación orientación a
objetos

Mejora la captura y validación de requisitos.

Acerca el espacio del problema y el espacio de la solución.

8
Fundamentos de la orientación a objetos

Abstracción
La abstracción es crear un modelo de una realidad específica
Modularidad
Para abordar un problema complejo hay que dividirlos en partes diferentes.
Encapsulamiento
La localización física de las propiedades dentro de una sola abstracción de
caja negra que ocupa su implementación tras un interfaz público.
Jerarquía
Recomendada ordenación en una estructura de árbol.

9
 Conceptos de OO

Clases y Objetos

Una entidad delimitada precisamente y con

identidad, que encapsula estado y
comportamiento.

El estado se representa mediante sus atributos

y relaciones, el comportamiento mediante sus
operaciones, métodos y máquinas de estado. 10
 Conceptos de OO

Un objeto es una instancia de una clase, una

clase es una abstracción de un objeto.

Objeto = Identidad + Comportamiento + Estado

Identidad: Es algo que lo identifica de manera única.

Comportamiento: Es todo lo que un objeto puede realizar.
Estado: Comprende el estado de las variables asociadas al objeto.

Clase = Instanciación + Métodos + Atributos

11
 Objetos
Atributos:

LO • Color

I CU • Ruedas
• Motor

EH • puertas
V Métodos
• Arrancar()
• Frenar()
• Acelerar()
Atributos:
• Manos • Apagar()
• Piernas
• Ojos
Métodos: PERSONA
• Habla()
• Come()
• Corre()

12
 Clase

Son abstracciones de objetos. Es un modelo

de comportamiento de un tipo de objeto que
existirá durante la ejecución de un programa
orientado a objetos.

Una clase es una plantilla o molde que define

los atributos y métodos que tendrán los
objetos de esa clase. 13
 Programación OO

Requiere técnicas nuevas que han dado lugar a nuevas

metodologías y notaciones.

Una de ellas es el UML, se puede complementar con el Rational

Unified Process.

14
 Ventajas de la POO

 Desarrollo mas rápido.

 La creación del código más ordenada e intuitiva gracias a los
objetos.
 El mantenimiento es mejor.
 Reutilización de componentes.
 Aumenta la calidad del software.

15
 Que es UML?

Comenzó en 1994

Fue creado por Booch, Jacobson y Rumbaugh

Es un estándar para escribir los planos de un sistema.

Es un estándar para construir modelos orientados a objetos que

ayuda en la etapa de Análisis y Diseño de un sistema.

Es modelar.
16
 Que es un modelo?
Modelo = Es una simplificación de la realidad.

Principios del modelado:

1. La elección de qué modelos crear tiene una profunda influencia

sobre cómo se acomete un problema y como se da forma a una
solución.
2. Todo modelo puede ser expresado a diferentes niveles de
precisión.
3. Los mejores modelos están ligados a la realidad.
4. Un único modelo no es suficiente. Cualquier sistema no trivial
se aborda mejor a través de un pequeño conjunto de modelos
casi independientes. 17
 Porque Modelamos?

Visualizar
Especificar
Construir
Documentar
18
Donde se puede utilizar UML?

 Bancos
 Comercio
 Electrónica médica
 Telecomunicaciones
 Transporte
 Etc.

19
 UML en las Fases de un Proyecto

I. Fase de Conceptualización y Planeación

Objetivos: Entender el problema
Planear la ejecución

II. Fase de Construcción

Objetivos: Diseñar la solución
Implementar el software

III. Fase de Despliegue de la Aplicación

Objetivos: Certificar el Software
Poner en marcha el software

20
 Modelo Conceptual

Según Fowler: Es una representación de

conceptos en un dominio del problema.

Es descomponer el problema en conceptos u

objetos individuales.

21
 Modelo Conceptual

El diseño de un modelo conceptual tiene

como fin subrayar fuertemente los conceptos
del dominio, no las entidades del software.

Un modelo Conceptual muestra:

 Conceptos
 Asociaciones de conceptos
 Atributos de los conceptos 22
Un Modelo Conceptual de UML

Incluye 3 clases de bloques de construcción:

 Elementos
 Estructurales, Comportamiento, Agrupación y Anotación
 Relaciones
 Dependencia, Asociación, Generalización, Realización
 Diagramas
 Clases, Objetos, Casos de Uso, Secuencia Colaboración,
Estados, Actividades, componentes, Despliegue
23
Tipos Relaciones en UML

24
 Tipos de Relaciones en UML

Dependencia = Relación Semántica entre dos elementos.

Asociación = Un conjunto de enlaces, relación entre dos

conceptos.

Generalidades = Una relación de especialización.

Realización = Relación semántica entre clasificadores.

25
 Diagramas de UML

 Diagramas de Casos de Uso

 Diagramas de Objetos
 Diagramas de Clases
 Diagramas de Secuencia
 Diagramas de Colaboración
 Diagramas de Estado
 Diagramas de Actividades
 Diagramas de Componentes
 Diagramas de Despliegue
26
Como Construir un Modelo Conceptual

 Liste los conceptos idóneos.

 Dibújelos como cajas o Rectángulos.
 Incorpore las asociaciones necesarias para registrar las
relaciones.
 Agregue los atributos necesarios para cumplir con las
necesidades de información.

27
 Estrategias para identificar Conceptos

Es mejor exagerar y realizar un modelo conceptual

con muchos aspectos refinados y no vagamente.

Comúnmente se suelen omitir conceptos durante la

fase inicial y descubrirlos mas tarde. Si pasa esto no
dude en incluirlos en el modelo conceptual.

No excluya conceptos.
28
Modelo Conceptual

29
 Modelo Conceptual

No debe incluir Artefactos de Software o

operaciones.
Error Frecuente:
Es representar algo como atributo cuando debió ser
un concepto.

30
Modelo Conceptual

31
 Modelo Conceptual

Recordemos:
1. Conceptos (No utilizar el atributo como identificador entre
conceptos).
2. Atributos (Valor lógico de un dato de un objeto)
3. Multiplicidad
4. Asociaciones (Es mucho mas importante identificar
conceptos que asociaciones).

32
 Glosario de Términos

 Se utiliza en la primera fase del proyecto y luego

se va refinando poco a poco.
 Se busca con él es aminorar el riesgo de malos
entendidos
 Se especifican los términos utilizados, ya sean
métodos, atributos y otros.

33
 Estructura Glosario de Términos
Término Categoría Descripción
Crear Cliente Caso de Uso Descripción de la
creación de un cliente en
el sistema.
Producto Concepto Un producto para
venderse en la tienda.
Producto.total Atributo Venta total del producto
34
Casos de Usos

35
 Que es un Caso de Uso?

Especifica el comportamiento de un sistema o de una parte

del mismo, y es una descripción de un conjunto de secuencias de
acciones, incluyendo variantes, que ejecuta un sistema para producir
un resultado observable de valor para un actor.

No tiene que especificar cómo se implementa.

Ayudan a que los desarrolladores o usuarios finales del sistema y los

expertos del dominio lleguen a una comprensión común del sistema.
36
 Casos de Uso

Se pueden aplicar en el sistema completo o a partes

como módulos, incluyendo subsistemas e incluso clases
individuales.

Es un documento narrativo que describe la secuencia de

eventos de un actor, que utiliza un sistema para
completar un proceso.

Involucran la interacción de actores y el Sistema.

Compuesto por = Infinitivo Verbal + Complemento

37
 Casos de Uso

Hacer Recibo Comprar Producto

Incluir Recibo Crear Cliente

38
 Casos de Uso

Error Común:
Es la identificación de los casos de uso consiste
en representar los pasos, las operaciones o las
transacciones individuales como casos.

Imprimir el Recibo

39
 Actores

Suelen ser los papeles representados por seres

humanos, pero pueden ser cualquier tipo de
sistema, como un sistema computarizado externo
de bancos.

Cliente

40
 Relaciones entre casos de Uso

Se representan con una flecha entre casos y con un

mensaje entre corchetes <<“ ” >>.

Tipos de Relación:
 << extends >> Se usa cuando se tiene un caso de
uso similar a otro pero que hace un poco mas.
 << uses >> o <<include>> Se una cuando se tiene
una porción de comportamiento que es similar en
mas de un caso de uso y se quiere reutilizar.
41
Ejemplo Diagrama de Caso de Uso

Registrar Cliente
<<uses>>

Crear Cuenta

<<extends>>
Cajero

Crear Cuenta Corriente

42
 Formatos de los casos de Uso

Hay dos tipos:

Formato de Alto nivel: Explicar el proceso que se va a

conseguir con el caso de uso. Brevemente como en
tres enunciados.

Formato Expandido: Describe un proceso más a

fondo que el de alto nivel. Se ve la diferencia en el
curso normal de los eventos. 43
 Formato de Alto nivel

Caso de Uso: “Nombre del Caso”

Actores: “Actores que comienzan el caso”

Tipo: “secundario, primario, opcional”

Descripción: “Breve explicación de lo que realiza.”

44
 Tipos de Caso de Uso

Primario: Representa los procesos mas importantes o

indispensables en el sistema.
Ejemplos:
Registrar Productos (Sistema de Inventario)
Facturar Compras (Sistema de Facturación)

Secundario: Representa los procesos menos importantes o no

tan indispensables en el sistema.
Ejemplos:
Eliminar Productos (Sistema de Inventario)
Anular Factura (Sistema de Facturación)
45
 Tipos de Caso de Uso

Opcional: Representa los procesos que perfectamente no tienen que

abordarse del sistema.

Ejemplos:
Registrar Bodeguero (Sistema de Inventario)
Enviar promedios por Internet (Sistema Académico)

46