Aplica la metodología espiral con programación orientada a objetos

https://www.youtube.com/watch?v=A9U_AVXwWIM

1. Diseño orientado a los objetos

El Diseño Orientado a los Objetos (DOO) crea una representación del problema del
mundo real y la hace corresponder con el ámbito de la solución, que es el software. A
diferencia con otros métodos de diseño, el DOO produce un diseño que interconecta
objetos de datos y operaciones de procesamiento para esos
objetos, de forma que se modula riza la información y el procesamiento, en lugar de aislar
el procesamiento.
Todos los métodos de diseño intentan desarrollar software basándose en:
• Abstracción
• Oculta miento de información
• Modularidad

El DOO proporciona un mecanismo que permite al diseñador consigue estas tres

características sin dificultad. El Análisis Orientado a Objetos, el Diseño Orientado a
Objetos y la Programación Orientada a Objetos comprenden un conjunto de actividades
de la Ingeniería del Software para la construcción de un sistema basado en objetos.

https://youtu.be/s40SFUbW0OE
Objetos, operaciones y mensajes

El funcionamiento del software se consigue al actuar uno o más procesos sobre una
estructura de datos de acuerdo con un procedimiento de invocación. Para conseguir un
DOO, tenemos que establecer un mecanismo para:
• Representar la estructura de datos
• Especificar el proceso
• Realizar el procedimiento de invocación

Objeto: Componente del mundo real que se hace corresponder con el software. En un
Sistema de Información basado en Computador, un objeto es un producto o consumidor
de información, o un elemento de información. Cuando se hace corresponder un objeto
con su realización software, implementamos una estructura de datos y usa serie de
procesos que pueden transformar la estructura de datos. Diseño orientado a los objetos

Operaciones, métodos o servicios: Procesos a los que se le permite transformar

estructuras de datos.

Mensajes: Peticiones que se realizan a los objetos para que realicen alguna de sus
operaciones. Las operaciones contienen construcciones procedimentales y de control,
que se invocan mediante un mensaje.
Al definir un objeto con parte privada y proporcionar mensajes para invocar al
procedimiento adecuado conseguimos el oculta miento de información. De esta forma
dejamos ocultos al resto de los elementos de programa los detalles de implementación
del objeto.

https://youtu.be/IPrvjPyRiCA

Los objetos con sus operaciones proporcionan una modularidad inherente, es decir los
elementos del software (datos y procesos) están agrupados con un mecanismo de
interfaz bien definido, que son los mensajes.
Aspectos de diseño

Meyer sugiere cinco criterios para evaluar la calidad de un método de diseño a partir de
la modularidad. Descomponibilidad: Facilidad con la que un método de diseño ayuda al
diseñador a descomponer un problema en sub problemas más sencillos.
Componibilidad: Grado en el que un método de diseño permite la
reutilizabilidad de módulos. Compresibilidad: Facilidad para comprender un componente
del programa sin tener que hacer referencia a otros módulos. Continuidad: Capacidad de
realizar cambios en un programa y que esos cambios afecten a un número mínimo de
módulos.
Protección: Característica arquitectónica que reduce la propagación de
errores. A partir de estos criterios, Meyer sugiere la derivación de cinco principios de
diseño para arquitecturas modulares: Diseño orientado a los objetos

• Unidades modulares
• Pocas interfaces
• Interfaces pequeñas (acoplamiento débil)
• Interfaces explícitas
• Ocultamiento de información

Para conseguir un acoplamiento débil, se debe minimizar el número de interfaces entre

módulos y minimizar la cantidad de información que se mueve a través de una interfaz.

Siempre que los módulos tengan que comunicarse tiene que hacerlo de forma clara,
mediante interfaces explícitas, y no mediante una zona global de datos, ya que la
comunicación entre módulos no sería fácilmente comprensible para un observador
externo.

El principio de ocultamiento de información se consigue cuando toda la información del

módulo está oculta para el acceso desde el exterior, a menos que la información se defina
explícitamente de forma pública. Si bien estos principios son aplicables a cualquier tipo
de diseño, el método de Diseño Orientado a Objetos consigue alcanzar estos principios
de forma más eficiente que el resto de los enfoques, consiguiendo arquitecturas más
modulares

Pasos del Diseño Orientado a Objetos

1) Definición del problema
2) Desarrollo informal de la forma de procesamiento para la realización del
software
3) Formalización de la forma de procesamiento
a) Identificar los objetos y sus atributos
b) Identificar las operaciones de los objetos
c) Establecer las interfaces que muestren las relaciones entre los objetos y
las operaciones
d) Crear un diseño detallado que proporcione una descripción de la
implementación de los objetos

PROCESO DEL ANÁLISIS Y DISEÑO ORIENTADO A LOS OBJETOS

El resultado del diseño orientado a objetos es una jerarquía de clases. Los elementos
iniciales de un DOO son los propios objetos, y posteriormente, a medida que se van
identificando aspectos comunes, los objetos se van agrupando en clases, que a su vez
serán subclases de clases más abstractas. Los métodos estructurados y sus
correspondientes notaciones definen un sistema como un conjunto secuencial de
módulos ínter dependientes que comparten datos. En cambio, los métodos orientados a
objetos definen un
conjunto de módulos independientes relacionados y con visibilidad limitada entre ellos.
 Pasos del DOO

Esencialmente, el DOO consta de cuatro pasos fundamentales:

a) Identificación y definición de objetos y clases
b) Organización de relaciones entre clases
c) Extracción de estructuras en una jerarquía de clases
d) Construcción de bibliotecas de clases reutilizables
Como en todas las fases de Ingeniería del Software, el DOO es cíclico, es
decir, los diseñadores comienzan definiendo un conjunto de clases, que se
amplían, modifican, ..., y vuelta a empezar.

Identificación y definición de objetos

El principal problema del desarrollo de un sistema orientado a objetos es encontrar los

objetos en la fase de AOO y DOO. El método que utilizaremos para la identificación de
objetos es el propuesto por Booch en 1983, que dio origen al método gramatical. Esta
metodología sugiere que se comience con una descripción textual del sistema deseado
y que el diseñador vea:
• A los nombres como posibles identificadores de las clases de los
objetos
• A los verbos como posibles métodos
La lista resultante de clases (nombres) y métodos (verbos) se utilizará para comenzar el
proceso de diseño.
Conclusiones sobre el método de Booch
Con el método de Booch para encontrar clases es difícil conseguir un resultado de alta
calidad, pues la abstracción de clases que consigamos, depende de una estructuración
inteligente de la descripción del problema en elementos independientes e intuitivamente
correctos. Diseño orientado a los objetos
Directrices para la identificación y definición de
clases y métodos
https://youtu.be/WN2jhFtE_i0

Las metodologías para apoyar el AOO y el DOO se encuentran en sus primeras fases de
desarrollo, pero se han definido una serie de directrices que facilitan la identificación y
definición de clases y métodos.
• Modelar con clases las entidades que ocurren de forma natural en el problema
• Diseñar métodos con una sola finalidad
• Diseñar un método nuevo antes de ampliar uno existente
• Evitar métodos extensos
• Guardar como instancia los datos necesitados por más de un método o por una
subclase
• El diseñador debe trabajar para obtener una biblioteca de clases, y no para él mismo, ni
para desarrollar el sistema actual. Además, para evitar la creación de clases innecesarias
o declaración de clases que no lo sean, una clase debe ofrecer una serie de servicios a
objetos de un tipo determinado.
Una clase se debería crear cuando:
• La nueva clase represente una abstracción significativa del problema
• Es probable que los servicios que proporciona sean utilizados por otras
clases.
• Su comportamiento sea complejo.
• Si se representara como un método de otra clase, pocos usuarios de ésta lo
invocarían.

CÓDIGO DE UN JUEGO DE DADO

 Tema 2 Análisis Orientado Objetos (A.O.O) / (O.O.P)

Los conceptos de la programación orientada a objetos tienen origen en Simula 67, un

lenguaje diseñado en 1967 para hacer simulaciones de eventos discretos, creado por Ole-
Johan Dahl y Kristen Nygaard del Centro de Cómputo Noruego en Oslo. Simula introdujo
la noción de clases e instancias como parte de un paradigma de programación explícito.
Las ideas de Simula 67 influenciaron muchos lenguajes posteriores, incluyendo
Smalltalk, CLOS, Object Pascal, C++…

La programación orientada a objetos fue el estilo de programación dominante a principio

y mediados de los años noventa, en gran parte debido a la influencia de lenguajes como
C++. Su predominio fue consolidado gracias al auge de las interfaces gráficas de usuario,
para las cuales la programación orientada a objetos está particularmente bien adaptada.
En este caso, se habla también de programación dirigida por eventos.

https://youtu.be/k_V8pQSS7-U

En los años 80’s Bjarne Stroustrup de AT&T Labs., amplió el lenguaje C para crear C++
que soporta la programación Orientada a Objetos.
En esta misma década se desarrollaron otros lenguajes Orientados a Objetos como
Objective C, Common Lisp Object System (CIOS), object Pascal, Ada y otros.
Posteriores mejoras en herramientas y lanzamientos comerciales de C++ por distintos
fabricantes, justificaron la mayor atención hacia la programación Orientada a Objetos en
la comunidad de desarrollo de software. El desarrollo técnico del hardware y su
disminución del costo fue el detonante final. Con más computadoras al alcance de más
personas más programadores, más problemas y más algoritmos surgieron.

En 1996 surge un desarrollo llamado JAVA (extensión de C++). Su filosofía es aprovechar

el software existente. Facilitar la adaptación del mismo a otros usos diferentes a los
originales sin necesidad de modificar el código ya existente.
En 1997-98 se desarrollan herramientas ‘CASE’ orientadas a objetos (como el diseño
asistido por computadora).
Del 98 a la fecha se desarrolla la arquitectura de objetos distribuidos RMI, Corba, COM,
DCOM.
Motivación

Durante años, los programadores se han dedicado a construir aplicaciones muy

parecidas que resolvían una y otra vez los mismos problemas. Para conseguir que los
esfuerzos de los programadores puedan ser utilizados por otras personas se creó la POO.
Que es una serie de normas de realizar las cosas de manera que otras personas puedan
utilizarlas y adelantar su trabajo, de manera que consigamos que el código se pueda
reutilizar.
La POO no es difícil, pero es una manera especial de pensar, a veces subjetiva de quien
la programa, de manera que la forma de hacer las cosas puede ser diferente según el
programador. Aunque podamos hacer los programas de formas distintas, no todas ellas
son correctas, lo difícil no es programar orientado a objetos sino programar bien.
Programar bien es importante porque así nos podemos aprovechar de todas las ventajas
de la POO.
Tecnología orientada a objetos

Hoy en día la tecnología orientada a objetos ya no se aplica solamente a los lenguajes de

programación, además se viene aplicando en el análisis y diseño con mucho éxito, al
igual que en las bases de datos. Es que para hacer una buena programación orientada a
objetos hay que desarrollar todo el sistema aplicando esta tecnología, de ahí la
importancia del análisis y el diseño orientado a objetos.
La programación orientada a objetos es una de las formas más populares de programar
y viene teniendo gran acogida en el desarrollo de proyectos de software desde los
últimos años. Esta acogida se debe a sus grandes capacidades y ventajas frente a las
antiguas formas de programar.
Lenguajes de Programación Orientado a objetos

En 1985, E. Stroustrup extendió el lenguaje de programación C a C++, es decir C con

conceptos de clases y objetos, también por esas fechas se creo desde sus bases el
lenguaje EIFFEL.
En 1995 apareció el más reciente lenguaje OO, Java desarrollado por SUN, que hereda
conceptos de C++.
El lenguaje de desarrollo más extendido para aplicaciones Web, el PHP 5, trae todas las
características necesarias para desarrollar software orientado a objetos.
Además de otros lenguajes que fueron evolucionando, como el Pascal a Delphi.
Finalmente también otros lenguajes script como el ActionScript que si bien no es
totalmente orientado a objetos pero sí posee las características.

https://youtu.be/4EbOk9NMkc8

Características de la POO

Existe un acuerdo acerca de qué características contempla la "orientación a objetos".

Las características siguientes son las más importantes:
Abstracción
. El proceso de abstracción permite seleccionar las características relevantes dentro de
un conjunto e identificar comportamientos comunes para definir nuevos tipos de
entidades en el mundo real. La abstracción es clave en el proceso de análisis y diseño
orientado a objetos, ya que mediante ella podemos llegar a armar un conjunto de clases
que permitan modelar la realidad o el problema que se quiere atacar.
Encapsulamiento
Significa reunir todos los elementos que pueden considerarse pertenecientes a una
misma entidad, al mismo nivel de abstracción.
Modularidad
Se denomina "modularidad" a la propiedad que permite subdividir una aplicación en
partes más pequeñas (llamadas módulos), cada una de las cuales debe ser tan
independiente como sea posible de la aplicación en sí y de las restantes partes.
Principio de ocultación
Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone
una "interfaz" a otros objetos que especifica cómo pueden interactuar con los objetos de
la clase. El aislamiento protege a las propiedades de un objeto contra su modificación
por quien no tenga derecho a acceder a ellas; solamente los propios métodos internos
del objeto pueden acceder a su estado.
Polimorfismo
Comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo
nombre; al llamarlos por ese nombre se utilizará el comportamiento correspondiente al
objeto que se esté usando.
Herencia
Las clases no se encuentran aisladas, sino que se relacionan entre sí, formando una
jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de
todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el
encapsulamiento, permitiendo a los objetos ser definidos y creados como tipos
especializados de objetos preexistentes.
Lenguajes orientados a objetos
https://youtu.be/wmECY8XCe4E

Se le llama así a cualquier lenguaje de programación que implemente los conceptos

definidos por la programación orientada a objetos.
Ejemplos de lenguajes orientados a objeto
C++ Objective C
Java Smalltalk
Eiffel Lexico (en castellano)
Ruby Python
OCAML Object Pascal
CLIPS Visual .NET
Java Actionscript
COBOL Perl
C# Visual Basic.NET
PHP

Lenguaje UML

Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema.

Es importante remarcar que UML es un lenguaje de modelado para satisfacer o para
descubrir métodos o procesos
Se utiliza para definir un sistema, para detallar los artefactos en un sistemas y para
documentar y construir.

https://youtu.be/XBrUv-rcsBM

Tema 1 Ingeniería De Software

Lo que hoy conocemos, no existía en el pasado…

En el año 1940, el desarrollado de software que trabajaba en las primeras computadoras

digitales debía transcribir los programas que hubiera desarrollado en el equipo actual si
deseaba transferirlos para utilizarlos en un nuevo equipo.

No es hasta la década el 50 que surge el término «Ingeniería de Software», producto de

la necesidad de los usuarios no des arrolladores de resolver problemas utilizando
computadoras.

https://youtu.be/8UgQNQML_b8

La Ingeniería de Software consiste en el estudio de los principios y metodologías para el

desarrollo y mantenimiento de sistemas de software (Zelkovitz, 1978)
Entre 1960 y 1980
 Nace la «Crisis del Software», término nacido en la primera reunión de la OTAN sobre el
desarrollo de software. La cual consistía, básicamente, en la dificultad de escribir
programas sin errores que fuesen de fácil comprensión y fueran verifica bles Se debía a
la complejidad que representaba en la época la tarea de programar y de que dichos
programas pudiesen adaptarse a las nuevas necesidades de los usuarios.

Momentos de tensión

La ingeniería de software entre los años 1985 y 1987 se ve afectada por una serie de
accidentes que resultaron en la muerte de un estimado de tres personas. «Therac 25»
una máquina de radioterapia de la época, por un conjunto de fallas emitía una sobredosis
masiva de radiación en el paciente, la cual tenía resultados letales. Era el ejemplo claro
de la deficiencia existente en el desarrollo de software, del control de calidad del mismo
y del riesgo que implicaba el control por software en aquel entonces.
Los lenguajes de Programación Trascendentes

Con la ingeniería de software en el año 1950 empieza la aparición de los primeros

lenguajes de programación de «Alto Nivel». Haciendo más fácil la tarea de programar ya
que el algoritmo se expresa de una manera comprensible por el usuario humano, dejando
la tarea de traducir e interpretar dicho algoritmo, en lenguaje de «Bajo Nivel» a la
máquina.
Algunos de los lenguajes más trascendentes son:
 Fortran (desde 1954-1955 hasta la actualidad).
 LISP (desde 1959 hasta la actualidad).
 BASIC (desde 1964, es la base de lenguajes actuales como Visual Basic, VB.NET).
 Pascal (desde 1970, aún se utiliza en tareas específicas y en educación).
 C con clases (desde 1980, es la base de C++, ambos de consideran «Lenguajes de Nivel
Medio».
 Java (desde 1995 hasta la actualidad).
 C# (desde el 2000 hasta la actualidad).

https://youtu.be/rLYiJJwx6Ws
Campo de Aplicación

La Ingeniería de Software es una rama importante de las ciencias de la computación, es

una profesión que está detrás de los desarrollos y las nuevas opciones que aparecen con
mayor rapidez en los mercados actuales, puesto que existe una gran cantidad de
dispositivos que necesitan software para funcionar.
 Computadoras (De escritorio, Laptops, All-in-One, Convertibles, Tablets, etc.)
 Teléfonos Inteligentes (Smartphone, con Distintos «SO». Android, iOS y Windows
Phone, entre los principales).
 Sistemas Embebidos (Sistemas de control, Etc.)
Objetivos de Ingeniería del Software

Diseñar aplicaciones informáticas que se ajusten a las necesidades de las organizaciones.

Dirigir y coordinar el desarrollo de aplicaciones complejas.
Intervenir en todas las fases del ciclo de vida de un producto.
Estimar los costes de un proyecto y determinar los tiempos de desarrollo.
Hacer el seguimiento de costes y plazos.
Dirigir equipos de trabajo de desarrollo software.
Organizar la realización de pruebas que verifiquen el correcto funcionamiento de los
programas y que se ajustan a los requisitos de análisis y diseño.
Diseñar, construir y administrar bases de datos.
Dirigir y asesorar a los programadores durante el desarrollo de aplicaciones.
Introducir procedimientos de calidad en los sistemas, evaluando métricas e indicadores y
controlando la calidad del software producido.
Organizar y supervisar el trabajo de su equipo de los técnicos de mantenimiento y los
ingenieros de sistemas y redes
Las cinco C
Capacidad
Son actividades que influyen a la capacidad de ésta para procesar transacciones con rapidez
y eficiencia.

Los sistemas de información mejoran esta capacidad en tres formas.

* Aumentan la velocidad de procesamiento

*Aumento en el volumen

* Recuperación más rápida de la información

Costo

Es determinar en la forma esperada, de acuerdo con lo presupuestado, Que se debe llevar a

cabo el seguimiento de los costos de mano de obra, bienes y gastos generales.

Reducción de costos:
Son diseños de sistemas que ayudan a disminuir los costos, ya que toman ventaja de las
capacidades de cálculo automático y de recuperación de datos que están incluidos en
procedimientos de programas en computadora.
Control

Son datos ya hechos para que puedan ser guardados en una forma adecuada para su lectura
por medio de una máquina, y para alcanzar en un medio ambiente donde no existen
computadoras.

Esto se puede lograrse por medio de uso de procedimientos de control. Cada paso se lleva a
cabo de la misma manera. Con consistencia y con exactitud: por otra parte se efectúan
todos los pasos para cada lote de transacciones. Y se omiten etapas, especificas para su
desarrollo y no tenga problemas al momento de manipular
Calidad

Es donde el usuario permite interactuar con el sistema ya que el usuario esta inconforme sabré
que mi sistema es malo y no tiene los requerimientos básicos para un buen software
Competitividad
Son sistemas de información computacionales son un arma estratégica, capaz de cambiar la
forma en que la compañía compite en el mercado, en consecuencia éstos sistemas
mejoran la organización y la ayudan a ganar "ventaja competitiva",

Cada software debe cumplir estas expectativas entre las cuales tenemos

1- Mejores precios

2- Servicios exclusivos.

3- Productos diferentes.

La Ingeniería de software abarca cuatro elementos

clave
https://youtu.be/Tk4kysT-GYU

1. Métodos o técnicas: Indican cómo construir técnicamente el software, y abarca una serie
de tareas que incluyen la planificación y estimación de proyectos, el análisis de
requisitos, el diseño de estructuras de datos, programas y procedimientos, la
codificación, las pruebas y el mantenimiento.
2. Herramientas: Son instrumentos o sistemas automatizados para realizar algo de la mejor
manera posible. Esta manera óptima puede significar que la herramienta produce
resultados más exactos, más eficientes, más productivos, o que refuerza la calidad del
producto resultante. Proporcionan un soporte automático o semiautomático para todas
las fases del desarrollo y sistemas que integran las herramientas de cada fase de manera
que sirven para todo el proceso
3. Procedimientos: Son la combinación de las técnicas y las herramientas que en forma
conjunta dan un resultado particular. Los procedimientos indicarán qué herramientas
deberán utilizarse cuando se aplican determinadas técnicas.
4. Paradigmas: Representan un enfoque particular o filosofía para la construcción del
software. No es mejor uno que otro sino que cada uno tiene ventajas y desventajas.
También hay situaciones donde un paradigma resulta más apropiado que otro. Los más
comunes son el desarrollo en cascada, el desarrollo en espiral, el desarrollo por
prototipos, el desarrollo incremental, el desarrollo en V y el desarrollo orientado a
objetos.

Ciclo de Vida Orientado a Objetos VS Tradicionales

El tiempo de desarrollo y uso del software, desde que se detecta la necesidad de construir un sistema
de software hasta que este es retirado se denominan ciclo de vida del software.

Un ciclo de vida usualmente consta de las siguientes etapas: especificación y análisis de requisitos,
diseño del sistema, implementación del software, aplicación y pruebas, entrega y mantenimiento.

Cada etapa consta de diversas tareas; la documentación es una tarea que se realiza en todas las
etapas.

Los ciclos de vida tradicionales más conocidos son:

 Ciclo de vida en cascada
 Ciclo de vida en cascada incremental
 Ciclo de vida en espiral
 Ciclo de vida en espiral Win Win
 Ciclo de vida Prototipo
 Ciclo de vida Recursivo Paralelo
 Ciclo de vida DRA
 Ciclo de vida Evolutivo
 etc.
A continuacion se describe brebemente alguno de estos ciclos de vida.

Ciclo de vida en cascada

El modelo de cascada muestra un proceso donde los desarrolladores han de seguir las siguientes
fases de forma sucesiva:

 Especificación de requisitos
 Diseño del software
 Codificación
 Pruebas (o validación)
 Despliegue (o instalación)
 Mantenimiento
Siguiendo el modelo de cascada de forma estricta, sólo cuando se finaliza una fase, comienza la
otra. En ocasiones se realiza una revisión antes de iniciar la siguiente fase, lo que permite la
posibilidad de cambios (lo que puede incluir un proceso de control formal de cambio). Las revisiones
también se utilizan para asegurar que la fase anterior ha sido totalmente finalizada; los criterios para
completar una fase se conocen frecuentemente con el término inglés "gate" (puerta). Este modelo
desaconseja revisitar y revisar fases que ya se han completado. Esta falta de flexibilidad en un
modelo de cascada puro ha sido fuente de crítica de los defensores de modelos más flexibles.

Ventajas
 La planificación es sencilla.
 La calidad del producto resultante es alta.
 Permite trabajar con personal poco calificado.
 Ayuda a prevenir que se sobrepasen las fechas de entrega y los costes esperados.
 Es mejor que no seguir ningún ciclo de vida.
Inconvenientes
 Es difícil obtener todos los requisitos al comienzo. Lo normal es que el cliente no tenga
perfectamente definidas las especificaciones del sistema, o puede ser que surjan necesidades
imprevistas.
 Si se han cometido errores en una fase es difícil volver atrás. Al cambiar alguna de las etapas
se debe revisar todas las etapas subsiguientes.
 Es comparativamente más lento que los demás y el coste es mayor también.
 Se tarda mucho en disponer del software.
 No se tiene el producto hasta el final, esto quiere decir que:
 Si se comete un error en la fase de análisis no lo descubrimos hasta la entrega, con
el consiguiente gasto inútil de recursos.
 El cliente no verá resultados hasta el final, con lo que puede impacientarse.
 No se tienen indicadores fiables del progreso del trabajo (síndrome del 90%).
 El mantenimiento se realiza en el código fuente
 Impone una estructura de gestión de proyectos

Tipos de proyectos para los que es adecuado

 Aquellos para los que se dispone de todas las especificaciones desde el principio, por
ejemplo, los de reingeniería.
 Se está desarrollando un tipo de producto que no es novedoso.
 Proyectos complejos que se entienden bien desde el principio.
 Como el modelo en cascada ha sido muy popular ha generado algunas variantes.

Ciclo de vida en espiral

La principal características del modelo en espiral es la gestión de riesgos de forma periódica en el

ciclo de desarrollo. Este modelo fue creado en 1988 por Barry Boehm, combinando algunos aspectos
clave de las metodologías del modelo de cascada y del desarrollo rápido de aplicaciones, pero dando
énfasis en un área que para muchos no jugó el papel que requiere en otros modelos: un análisis
iterativo y concienzudo de los riesgos, especialmente en el caso de sistema complejos de gran
escala.

La espiral se visualiza como un proceso que pasa a través de algunas iteraciones con el diagrama
de los cuatro cuadrantes representativos de las siguientes actividades:

 Crear planes con el propósito de identificar los objetivos del software,seleccionados para
implementar el programa y clarificar las restricciones en el desarrollo del software;
 Análisis de riesgos: una evaluación analítica de programas seleccionados, para evaluar
como identificar y eliminar el riesgo;
 La implementación del proyecto: implementación del desarrollo del software y su pertinente
verificación;
Modelo de espiral con énfasis en los riesgos, haciendo hincapié en las condiciones de las opciones
y limitaciones para facilitar la reutilización de software, la calidad del software puede ayudar como
una meta propia en la integración en el desarrollo del producto.

Ventajas
 No necesita una definición completa de los requisitos para empezar a funcionar.
 Al entregar productos desde el final de la primera iteración es más fácil validar los requisitos.
 El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido el tiempo y
recursos invertidos en una iteración (las anteriores iteraciones están bien).
 El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en etapas tempranas
hay tiempo de subsanarlos.

Inconvenientes
 Es difícil evaluar los riesgos.
 Necesita de la participación continua por parte del cliente.
 Cuando se subcontrata hay que producir previamente una especificación completa de lo que
se necesita, y esto lleva tiempo.

Dónde es adecuado
 Sistemas de gran tamaño.
 Proyectos donde sea importante el factor riesgo.
 Cuando no sea posible definir al principio todos los requisitos.

Ciclo de vida Prototipo

Un cliente, a menudo, define un conjunto de objetivos generales para el software, pero no identifica
los requisitos detallados de entrada, proceso o salida. En otros casos, el responsable del desarrollo
del software puede no estar seguro de la eficacia de un algoritmo, de la capacidad de adaptación de
un sistema operativo, o de la forma en que debería tomarse la interacción hombremáquina.

En estas y en otras muchas situaciones, un paradigma de construcción de prototipos puede ofrecer

el mejor enfoque.

 Escuchar al Cliente: El paradigma de construcción de prototipos comienza con la

recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales
para el software, identifican los requisitos conocidos y las áreas del esquema en donde es obligatoria
más definición.
 Construir/Revisar la maqueta: Entonces aparece un «diseño rápido». El diseño rápido se
centra en una representación de esos aspectos del software que serán visibles para el usuario/cliente
(por ejemplo: enfoques de entrada y formatos de salida). El diseño rápido lleva a la construcción de
un prototipo.
 El Cliente Prueba la maqueta: El prototipo lo evalúa el cliente/usuario y se utiliza para
refinar los requisitos del software a desarrollar. La iteración ocurre cuando el prototipo se pone a
punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador
comprenda mejor lo que se necesita hacer.

Ventajas
 Ayuda a identificar los requisitos del software.
 Hace el software amigable al usuario.
 El cliente estará seguro de que el producto final reflejara lo que él desea.

Inconvenientes
 Primera versión de un producto es construido con poca funcionalidad y poca fiabilidad.
 El cliente ve lo que parece ser una versión de trabajo del software, y piensa que el trabajo
esta hecho.
 Puede ser demasiado lento, demasiado grande o torpe en su uso, o las tres a la vez.
 No hay otra alternativa que comenzar de nuevo, aunque nos duela pero es más inteligente,
y construir una versión rediseñada en la que se resuelvan estos problemas

Diferencia entre Prototipo y Producto Final

La diferencia entre prototipo y producto final es que el prototipo es eficiente y el producto final debe
serlo y, que en el prototipo no están todos los detalles y, el producto final debe contenerlos.

Clases de prototipos:

 Vertical: no recoge todas las funciones del sistema final.

 Horizontal: recoge todas las funciones, pero no las desarrolla por completo.

Ciclo de Vida Orientado a Objetos

Esta técnica fue presentada en la década de los 90, tal vez como una de las mejores metodologías a
seguir para la creación de productos software.

Puede considerarse como un modelo pleno a seguir, como así también una alternativa dentro de los
modelos anteriores.

Al igual que la filosofía del paradigma de la programación orientada a objetos, en esta metodología
cada funcionalidad, o requerimiento solicitado por el usuario, es considerado un objeto.

Los ciclos de vida clásicos se centran en el proyecto, el desarrollo orientado a objetos se basa en el
producto, no comprende los procesos como funciones sino que arma módulos basados en
componentes, es decir, cada componente es independiente del otro y se relacionan entre ellos a
través de interfaces, son más modulares y se dividen en miniproyectos lo cual permiten que el código
sea reutilizable.
Es más fácil de mantener porque los cambios están localizados en cada uno de estos componentes.
De esta forma si el cliente tiene nuevos requerimientos es mucho mas fácil agregarlos sin tener que
hacer demasiados cambios en lo que ya se tiene.

Debido a todo esto se considera que el ciclo de vida orientado a objetos es iterativo e incremental.

Los ciclos de vida orientados a objetos son:

 Modelo Fuente.
 Modelo de Agrupamiento.
 Modelo Remolino.
 Modelo PinBall.
A continuacion veremos un tipo de ciclo de vida orientado a objetos mas conocidos, que es además
el más representativo, el modelo fuente.

Modelo fuente
Fue creado por Henderson-Sellers y Edwards en 1990. Es un tipo de ciclo de vida pensado para la
orientación a objetos y posiblemente el más seguido.

Un proyecto se divide en las fases:

1. Planificación del negocio

2. Construcción: Es la más importante y se divide a su vez en otras cinco actividades
 Planificación
 Investigación
 Especificación
 Implementación
 Revisión
3. Entrega
La primera y la tercera fase son independientes de la metodología de desarrollo orientado a objetos.
Además de las tres fases, existen dos periodos:
 Crecimiento: Es el tiempo durante el cual se construye el sistema
 Madurez: Es el periodo de mantenimiento del producto. Cada mejora se planifica igual que
el periodo anterior, es decir, con las fases de Planificación del negocio, Construcción y Entrega.
Cada clase puede tener un ciclo de vida sólo para ella debido a que cada una puede estar en una
fase diferente en un momento cualquiera. La ventaja es que permite un desarrollo solapado e
iterativo. En la figura se muestra un esquema de este tipo de ciclo de vida.
Modelo de Agrupamiento (Clúster)
Propuesto por Bertrand Meyer (Meyer, 1990).

Concepto Clave: Agrupamiento, que es un conjunto de clases relacionadas con un objetivo común.

Clúster: Unidad organizativa básica. Es un grupo de clases relacionadas o, recursivamente,

clústeres relacionados. El clúster es la unidad natural para el desarrollo por parte de un único
desarrollador.

 Evita el efecto todo-nada propio del modelo en cascada.

Tiene un componente secuencial y un componente concurrente.

 Existencia de diferentes subciclos de vida, que pueden solaparse en el tiempo.

 Se aplica al clúster no al sistema completo.
 El miniciclo de vida que gobierna el desarrollo de un clúster está formado por Especificación,
Diseño, Implementación, Verificación/Validación y Generalización.

Enfoque Ascendente.

La ocultación de la información posibilita la forma del modelo de clústeres de ingeniería concurrente.

Modelo Remolino
Definido por James Rumbaugh (Rumbaugh, 1992). Las metodologías de desarrollo no ofrecen una
visión real del ciclo de vida en el desarrollo orientado al objeto. El ciclo de vida de un desarrollo
orientado al objeto es desordenado, involucrando múltiples iteraciones interrelacionadas.

El modelo en cascada asume una sola dimensión de iteración, consistentes en la fase de proceso.

Pueden Identificarse otras dimensiones:

 Amplitud: tamaño del desarrollo, por ejemplo en número de elementos.

 Profundidad: referida al nivel de abstracción o detalle.
 Madurez: grado de complexión, corrección y elegancia.
 Alternativas: Diferentes soluciones a un problema.
 Alcance: Propósitos y objetivos del sistema, ya que los requisitos van cambiando a lo largo
del tiempo.
Las diferentes dimensiones pueden anidarse de varias formas. Ejemplo: profundidad - madurez –
amplitud
Este proceso fractal (mas que lineal), consiste en un desarrollo multiciclo en forma de remolino en
lugar de una cascada, de ahí su nombre.
Modelo PinBall

Propuesto por Ambler (Ambler, 1994). Modelo

muy didáctico señala que el pinball refleja la forma que se desarrolla el software.

 Pelota ====> Proyecto o subproyecto

 Jugador ====> Equipo de desarrollo

Se procede de forma iterativa a encontrar clases, atributos, métodos y relaciones (actividades que
pueden englobarse en la fase de análisis) y definir colaboraciones, herencia, agregación y
subsistemas (actividades de diseño), y por último se pasa a la programación, prueba e
implementación.

Como en el pinball los pasos se pueden dar en cualquier orden y de forma simultánea.

Existen dos estilos a la hora de jugar

 A lo seguro ===> Con tecnologías y métodos probados

 Al límite ===> Con más riesgo (se pueden conseguir beneficios espectaculares)
El autor destaca que al igual que en el juego del pinball, la habilidad es el factor mas importante.

Consideraciones sobre los Ciclos de Vida Orientado a Objetos

 Se eliminan fronteras entre fases debido a la naturaleza iterativa del desarrollo orientado
al objeto.
 Aparece una nueva forma de concebir los lenguajes de programación y su uso
al incorporarse bibliotecas de clases y otros componentes reutilizables.
 Hay un alto grado de iteración y solapamiento, lo que lleva a una forma de trabajo muy
dinámica.
Conclusiones
Los ciclos de vida tradicionales son estructurados lo que hace difícil dividirlos en subsistemas para
ser implementados independientemente, en cambio los ciclos de vida orientado a objetos son
modulares, es decir, se dividen en módulos formados por componentes, donde cada componente es
independiente del otro y se relacionan a través de las interfaces; esta división eventualmente facilita
la construcción del software, puesto que se puede avanzar en distintas partes del proyecto a la vez.

Los Ciclos de vida Orientados a Objetos tienen permiten la reutilización del código, algo con lo que
no cuentan los tradicionales.

Los Ciclos de vida Orientados a Objetos son mas fáciles de mantener porque los cambios están
localizados en cada uno de estos componentes. De esta forma si el cliente tiene nuevos
requerimientos es mucho mas fácil agregarlos sin tener que hacer demasiados cambios en lo que
ya se tiene. En cambio los tradicionales tienen más complicaciones para detectar y corregir los
errores a tiempo, mas aun la modificación o incremento de requerimientos ocasiona crisis en el
proyecto pues no suelen ser muy flexibles al cambio.

Por todo esto es a mi parecer mucho mas conveniente realizar proyectos siguiendo un ciclo de vida
orientado a objetos en lugar de utilizar uno tradicional, o bien también es factible utilizar alguna
variante de los tradicionales con los orientados a objetos obteniendo como resultado un ciclo de vida
hibrido

Referencias
Libros
Ingeniería del Software: Un Enfoque Práctico

Rogger S. Presuman - Quinta Edición

Páginas Web
http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node10.html

http://es.scribd.com/doc/54962509/33/Los-modelos-orientados-al-objeto

http://www.ctr.unican.es/asignaturas/is1/is1-t02-trans.pdf

http://www.buenastareas.com/ensayos/Modelos-De-Desarrollo-De-Sistemas-
Orientados/1193373.html
Unidad 1 Conceptos básicos del modelo orientado a objetos
1.1 Reconocimiento de Objetos y Clases

Un objeto se delimita como una estructura que encapsula atributos (características) y

comportamientos (procedimientos) de una entidad con un papel bien definido. Cada objeto tiene:
- Estado: Conjunto de valores de los atributos en un instante de tiempo dado. El comportamiento
de un objeto puede modificar el estado de este.
- Comportamiento: Relacionado con su funcionalidad y determina las operaciones que este puede
realizar o a las que puede responder ante mensajes enviados por otros objetos.
- Identidad: Es la propiedad que permite a un objeto diferenciarse de otros. Generalmente esta
propiedad es tal, que da nombre al objeto.
Los objetos, concretos y abstractos, están a nuestro alrededor, forman nuestro entorno. Podemos
distinguir cada objeto en base a sus características y comportamientos.
Por ejemplo; en un aula de clases observamos los siguientes objetos: • Alumno • Profesor • Mesa •
Silla • Mesa banco • Pizarrón
Interacción entre objetos: Los objetos no sólo tienen atributos relacionados con su forma física sino
que, además, exhiben comportamientos específicos de su clase.
• Alumno: Estudia, aprende.
• Profesor: Enseña, evalúa.
• Mesa: Ordenada, desordenada.
• Silla: Ocupada, desocupada.
• Mesa banco: Ocupado, desocupado.
• Pizarrón: Pintado, borrado
Observamos que en el aula hay varios objetos alumno, por lo que pensamos en el grupo de
alumnos, al que denominaremos como la clase alumno. De igual manera, cada materia es
impartida por un profesor; el conjunto de profesores forman la clase Profesor. Pudiéramos extender
nuestro análisis al pizarrón, la mesa, la silla,, al conjunto de mesa bancos, etc.
Clases: Es la definición de un objeto. Cuando se programa un objeto y se definen sus
características y funcionalidades, realmente se programa una clase.

https://youtu.be/x4kkhQ-jo5w
1.2 La Abstraccion y el encapsulamiento como un proceso natural

Abstracción: Es un método por el cual abstraemos valga la redundancia, una determinada entidad
de la realidad de sus características y funciones que desempeñan, estos son representados en
clases por medio de atributos y métodos de dicha clase.
Procedimientos: Proporcionó la primera posibilidad de ocultación de información.
Módulos: Es una técnica que proporciona la posibilidad de dividir sus datos y procedimientos en
una parte privada y una parte pública. Proporcionan un método efectivo de ocultación de la
información, pero no permiten realizar instanciación, que es la capacidad de hacer múltiples copias
de las zonas de datos.
TADS: Un tipo abstracto de dato (TAD) es un tipo de dato definido por el programador que se
puede manipular similarmente a los tipos de datos definidos por el sistema.
Un tipo abstracto de dato corresponde a un conjunto (puede ser de tamaño indefinido) de valores
legales de datos y un número de operaciones primitivas que se pueden realizar sobre esos valores.
Para construir un tipo abstracto de dato se debe:
1.- Exponer una definición del tipo.
2.- Hacer disponible un conjunto de operaciones.
3.- Proteger los datos asociados con el tipo.
4.-Permitir instancias múltiples del tipo.

1.3 La Poo y la Complejidad del Software

La programación Orientada a objetos (POO) es una forma especial de programar, más cercana a
como expresaríamos las cosas en la vida real que otros tipos de programación. Con la POO
tenemos que aprender a pensar las cosas de una manera distinta, para escribir nuestros
programas en términos de objetos, propiedades, métodos y otras cosas que veremos rápidamente
para aclarar conceptos y dar una pequeña base que permita ver este tipo de programación.
En la historia de la programación ha habido varias evoluciones sucesivas. Una de las principales
fue la programación estructurada, cuyo principio fundamental era dividir un programa en
subprogramas más pequeños y fáciles de resolver, hasta llegar a niveles de complejidad
elementales, siempre apoyándonos en la idea de ¿qué debe hacer el programa?
Este método de diseño, a pesar de haber dado resultados satisfactorios, tiene limitaciones.
Algunas de ellas son:
• No favorece la reutilización del código. Si en la figura anterior f1 y f2 fueran idénticas, este hecho
seguramente pasaría desapercibido y no se compartiría una única función fn.
• Si dos subprogramas comparten una misma función fn reutilizando así el código que define la
misma, y más adelante queremos modificar fn porque hay un cambio en uno de los subprogramas
que la utilizan, la modificación afectará también al otro subprograma, razón por la que ahora
tendremos que realizar dos funciones.
La programación orientada a objetos puede llevarse a cabo con lenguajes convencionales, pero
esto exige al programador la construcción de los mecanismos de que disponen los lenguajes
orientados a objetos. Por ello, lo más apropiado es utilizar directamente un lenguaje orientado a
objetos, ya que éstos soportan los mecanismos y las características que anteriormente se han
expuesto, tales como objetos, clases, métodos, mensajes, herencia, etc.
La herencia constituye uno de los mecanismos más potentes de la programación orientada a
objetos

1.4 Conceptos del Ciclo de Vida del Software

El ciclo de vida del software en el Proceso Unificado
Las fases del ciclo de vida del software son: concepción, elaboración, construcción y transición.

La concepción: es definir el alcance del proyecto y definir el caso de uso.

La elaboración: es proyectar un plan, definir las características y cimentar la arquitectura.
La construcción: es crear el producto y la transición es transferir el producto a sus usuarios

Según Microsoft 1997, el diseño de software se realiza a tres niveles: conceptual, lógico y físico.

Diseño Conceptual :El diseño conceptual se considera como un análisis de actividades y consiste
en la solución de negocios para el usuario y se expresa con los casos de uso. El diseño lógico es
la solución del equipo de proyecto del negocio y consiste de las siguientes tareas: Identificar los
usuarios y sus roles Obtener datos de los usuarios Evaluar la información Documentar los
escenarios de uso Validar con los usuarios Validar contra la arquitectura de la empresa.

Diseño Lógico: El diseño lógico traduce los escenarios de uso creados en el diseño conceptual en
un conjunto de objetos de negocio y sus servicios. El diseño lógico se convierte en parte en la
especificación funcional que se usa en el diseño físico. El diseño lógico es independiente de la
tecnología. El diseño lógico refina, organiza y detalla la solución de negocios y define formalmente
las reglas y políticas específicas de negocios. El diseño lógico comprende las siguientes tareas:
*Identificar y definir los objetos de negocio y sus servicios
*Definir las interfases
*Identificar las dependencias entre objetos
*Validar contra los escenarios de uso
*Comparar con la arquitectura de la empresa
*Revisar y refinar tanto como sea necesario

Diseño físico: El diseño físico traduce el diseño lógico en una solución implementable y costo-
efectiva o económica. El componente es la unidad de construcción elemental del diseño físico.

Las características de un componente son:

*Se define según cómo interactúa con otros

*Encapsula sus funciones y sus datos
*Es reusable a través de las aplicaciones
*Puede verse como una caja negra
*Puede contener otros componentes

El diseño físico debe involucrar:

*El diseño para distribución – debe minimizarse la cantidad de datos que pasan como parámetros
entre los componentes y éstos deben enviarse de manera segura por la red.
*El diseño para multitarea – debe diseñarse en términos de la administración concurrente de dos o
más tareas distintas por una computadora y el multithreading o múltiples hilos de un mismo
proceso)
*El diseño para uso concurrente – el desempeño de un componente remoto depende de si está
corriendo mientras recibe una solicitud.
*El diseño con el manejo de errores y prueba de eventos: Validando los parámetros- a la entrada
antes de continuar con cualquier proceso. Protegiendo recursos críticos manejar excepciones para
evitar la falla o terminación sin cerrar archivos, liberar objetos sincronizados o memoria.
*Protegiendo datos importantes – contar con una excepción a la mitad de la actuación en las bases
de datos.
*Debugging – crear una versión para limpiar errores.
*Protección integral de transacciones de negocios – los errores deben regresarse al componente
que llama.

El diseño físico comprende las siguientes tareas:

*Definir los componentes

*Refinar el empaquetamiento y distribución de componentes
*Especificar las interfases de los componentes
*Distribuir los componentes en la red
*Distribuir los repositorios físicos de datos
*Examinar la tolerancia a fallas y la recuperación de errores *
*Validar el diseño físico

De las tareas anteriores la más importante es la distribución de los datos que pueden ser
centralizados, una partición, un extracto o una réplica.

La Programación Orientada a Objetos

La Programación Orientada a Objetos (OOP por sus siglas en inglés de Object Oriented
Programming) como paradigma, “es una forma de pensar, una filosofía, de la cual surge una
cultura nueva que incorpora técnicas y metodologías diferentes.
Pero estas técnicas y metodologías, y la cultura misma, provienen del paradigma, no lo hacen. La
POO como paradigma es una postura ontológica: el universo computacional está poblado por
objetos, cada uno responsabilizándose por sí mismo, y comunicándose con los demás por medio
de mensajes”

1.4.1 Especificaciones de requerimientos

El termino requerimiento no se utiliza de forma consistente en la industria del software. En algunos

casos, un requerimiento se visualiza como una declaración abstracta de alto nivel de un servicio
que debe proveer el sistema o como una restricción de éste. Por otro lado, es una definición
matemática detallada y formal de una función del sistema

ANÁLISIS Y NEGOCIACIÓN DE REQUISITOS

Una vez recopilados los requisitos, el producto obtenido configura la base del análisis de requisitos.
Los requisitos se agrupan por categorías y se organizan en subconjuntos, se estudia cada requisito
en relación con el resto, se examinan los requisitos en su consistencia, completitud y ambigüedad,
y se clasifican en base a las necesidades de los clientes/usuarios.
Es corriente en clientes y usuarios solicitar más de lo que puede realizarse, consumiendo recursos
de negocios limitados. También es relativamente común en clientes y usuarios el proponer
requisitos contradictorios, argumentando que se versión es “esencial por necesidades especiales”.

REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES

*Requerimientos funcionales
Son declaraciones de los servicios que proveerá el sistema, de la manera en que éste reaccionará
a entradas particulares. En algunos casos, los requerimientos funcionales de los sistemas también
declaran explícitamente lo que el sistema no debe hacer.
Los requerimientos funcionales de un sistema describen la funcionalidad o los servicios que se
espera que éste provea. Estos dependen del tipo de software y del sistema que se desarrolle y de
los posibles usuarios del software. Cuando se expresan como requerimientos del usuario,
habitualmente se describen de forma general mientras que los requerimientos funcionales del
sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, etc. Muchos
de los problemas de la ingeniería de software provienen de la imprecisión en la especificación de
requerimientos. Para un desarrollador de sistemas es natural dar interpretaciones de un
requerimiento ambiguo con el fin de simplificar su implementación. Sin embargo, a menudo no es
lo que el cliente desea. Se tienen que estipular nuevos requerimientos y se deben hacer cambios al
sistema, retrasando la entrega de éste e incrementando el costo

*Requerimientos no funcionales.
Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de
tiempo, sobre el proceso de desarrollo, estándares, etc.
Son aquellos requerimientos que no se refieren directamente a las funciones específicas que
entrega el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta en
el tiempo y la capacidad de almacenamiento.
De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de
entrada/salida y la representación de datos que se utiliza en la interface del sistema.

REQUERIMIENTOS DEL USUARIO Y DEL SISTEMA

Requerimientos del usuario

Son declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el
sistema provea y de las restricciones bajo las cuales debe operar.
Describen los requerimientos funcionales y no funcionales de tal forma que sean comprensibles
por los usuarios del sistema que no posean un conocimiento técnico detallado. Únicamente
especifican el comportamiento externo del sistema y evitan, tanto como sea posible, las
características de diseño del sistema. Por consiguiente, los requerimientos del usuario no se deben
definir utilizando un modelo de implementación. Deben redactarse utilizando el lenguaje natural,
representaciones y diagramas intuitivos sencillos

LOS REQUERIMIENTOS DEL SISTEMA

Establecen con detalle los servicios y restricciones del sistema. El documento de requerimientos
del sistema, algunas veces denominado especificación funcional, debe ser preciso. Éste sirve
como un contrato entre el comprador del sistema y el desarrollador del software.
Son descripciones más detalladas de los requerimientos del usuario. Sirven como base para definir
el contrato de la especificación del sistema y, por lo tanto, debe ser una especificación completa y
consistente del sistema. Son utilizados por los ingenieros de software como el punto de partida
para el diseño del sistema.
La especificación de requerimientos del sistema incluye diferentes modelos del sistema como el de
objetos o el de flujo de datos.
EL DOCUMENTO DE REQUERIMIENTOS DEL SOFTWARE: Éste es la declaración oficial de qué
es lo que requieren los desarrolladores del sistema. Incluye tanto los requerimientos del usuario
para el sistema como una especificación detallada de los requerimientos del sistema. En algunos
casos, los dos tipos de requerimientos se integran en una única descripción. En otros, los del
usuario se definen en una introducción de la especificación de los del sistema. Si existe un gran
numero de requerimientos, los detalles de los requerimientos del sistema se pueden presentar
como documentos separados.
El documento de requerimientos tiene un conjunto diverso de usuarios que va desde los
administradores principales de la organización, quienes pagan por el sistema, hasta los ingenieros
responsables del software.
Una gran variedad de organizaciones han definido estándares para los documentos de
requerimientos.
El IEEE sugiere la siguiente estructura para los documentos de requerimientos.
1. Introducción • propósito del documento de requerimientos • Alcance del producto • Definiciones,
acrónimos y abreviaturas • Referencias • Resumen del resto del documento
2. Descripción general • Perspectiva del producto • Funciones del producto • características del
usuario • Restricciones generales • Suposiciones y dependencias
3. Requerimientos específicos. Cubren los requerimientos funcionales, no funcionales y de interfaz.
Obviamente, ésta es la parte más sustancial del documento, pero debido a la amplia variabilidad
en la práctica organizacional, no es apropiado definir una estructura estándar para esta sección.
Los requerimientos pueden documentar las interfaces externas, describir la funcionalidad y el
desempeño del sistema, especificar los requerimientos lógicos de la base de datos, las
restricciones de diseño, las propiedades emergentes del sistema y las características de calidad.
4. Apéndices
5. Índice

MODELADO DEL SISTEMA: Es importante evaluar los componentes del sistema y sus relaciones
entre sí, determinar cómo están reflejados los requisitos, y valorar como se ha concebido la
“estética” en el sistema.

VALIDACIÓN DE REQUISITOS: El resultado del trabajo realizado es una consecuencia de la

ingeniería de requisitos (especificación del sistema e información relacionada) y es evaluada su
calidad en la fase de validación. La validación de requisitos examina las especificaciones para
asegurar que todos los requisitos del sistema han sido establecidos sin ambigüedad, sin
inconsistencias, sin omisiones, que los errores detectados hayan sido corregidos, y que el
resultado del trabajo se ajusta a los estándares establecidos para el proceso, el proyecto y el
producto.

GESTIÓN DE REQUISITOS: Es un conjunto de actividades que ayudan al equipo de trabajo a

identificar, controlar y seguir los requisitos y los cambios en cualquier momento.

FACTORES EN LA CALIDAD DEL SOFTWARE: La construcción de software de calidad requiere

el cumplimiento de numerosas características:
*Eficiencia: La eficiencia del software es su capacidad para hacer un buen uso de los recursos que
manipula.
*Transportabilidad (portabilidad): La transportabilidad es la facilidad con la que un software puede
ser transportado sobre diferentes sistemas físicos o lógicos.
*Verificabilidad: La verificabilidad es facilidad de verificación de un software; es su capacidad para
soportar los procedimientos de validación y de aceptar juegos de test o ensayo de programas.
*Integridad: es la capacidad de un software para proteger sus propios componentes contra los
procesos que no tengan derecho de acceso.
*Fácil de utilizar: Un software es fácil de utilizar si se puede comunicar con él de manera cómoda.
*Corrección: Capacidad de los productos software de realizar exactamente las tareas definidas por
su especificación.
*Robustez: Capacidad de los productos software de funcionar incluso en situaciones anormales.
*Extensibilidad: Facilidad que tienen los productos de adaptarse a cambios en su especificación.
Existen dos principios fundamentales para conseguir esto: diseño simple y descentralización.
*Reutilizació: Capacidad de los productos para ser reutilizados, en su totalidad o en parte, en
nuevas aplicaciones.
*Compatibilidad: Facilidad de los productos para ser combinados con otros.

1.4.2 Analisis Orientado a Objetos

Se considera como un análisis de actividades y consiste en la solución de negocios para el usuario

y se expresa con los casos de uso. El diseño lógico es la solución del equipo de proyecto del
negocio y consiste de las siguientes tareas:
Identificar los usuarios y sus roles
Obtener datos de los usuarios
Evaluar la información
Documentar los escenarios de uso
Validar con los usuarios
Validar contra la arquitectura de la empresa

1.4.3 Diseño Orientado a Objetos

Es el proceso de construir un modelo de objetos para la solución. El diseño orientado a objetos es
el proceso de dividir una solución en una cantidad determinada de objetos constituyentes
1.4.4 Programacion Orientada Objetos Conceptos y Caracteristicas
¿Que es la programación orientada a objetos?.
La Programación Orientada a Objetos (POO) es una forma de enfocar la tarea de programación.
Los enfoques de la programación han cambiado drásticamente desde la invención de las
computadoras, la creciente complejidad de los programas, antes se realizaban mediante una
consola las instrucciones máquinas en binario.
Esto funcionaba porque los programas sólo tenían unos pocos cientos de instrucciones. Cuando
crecieron los programas, se invento el lenguaje ensamblador para que el programador pudiera
manejar programas más largos y complejos usando una representación simbólica de las
instrucciones máquina.
Los lenguajes de alto nivel aparecieron para proporcionar al programador más herramientas con
las cuales gestionar esa complejidad. En los años sesenta nace la programación estructurada, este
es el método alentando por varios lenguajes como pascal, y C. Con los lenguajes estructurados fue
posible escribir programas moderadamente complejos de una forma bastante sencilla.
Sin embargo, usando incluso la programación estructurada, cuando los proyectos Alcanzan cierto
tamaño, su complejidad se vuelve demasiado difícil para ser controlada por un programador. La
Programación Orientada a Objetos toma las mejores ideas de la programación estructurada la
combina con nuevos y poderosos conceptos que animan o alientan una nueva visión de la tarea de
la programación.
La Programación Orientada a Objetos permite descomponer fácilmente un problema en subgrupos
de partes relacionadas. Entonces, puede traducir estos subgrupos en unidades autocontenidas
llamadas Objetos

1.5 Elementos Primordiales en el Modelo de Objetos

1.5.1 Abstraccion Objetos
Significa extraer las propiedades esenciales de un objeto que lo distinguen de los demás tipos de
Objetos y proporciona fronteras conceptuales definidas respecto al punto de vista del observador.
Es la capacidad para encapsular y aislar la información de diseño y ejecución.
La abstracción es uno de los medios más importantes, mediante el cual nos enfrentamos con la
complejidad inherente al software. La abstracción es la propiedad que permite representar las
características esenciales de un objeto, sin preocuparse de las restantes características (no
esenciales).
Abstracción es la técnica de quitarle a una idea o a un objeto todos los acompañamientos
innecesarios hasta que los deja en una forma esencial y mínima. Una buena abstracción elimina
todos los detalles poco importantes y le permite enfocarse y concentrarse en los detalles
importantes.

1.5.2 Encapsulamiento Objetos

El encapsulamiento es una característica de la programación orientada a objetos. Cada objeto está
aislado del exterior, es un módulo natural, y la aplicación entera se reduce a un agregado o
rompecabezas de objetos.
El aislamiento protege a los datos asociados a un objeto contra su modificación por quien no tenga
derecho a acceder a ellos, eliminando efectos secundarios e interacciones.
Encapsulamiento Como se puede observar de los diagramas, las variables del objeto se localizan
en el centro o núcleo del objeto. Los métodos rodean y esconden el núcleo del objeto de otros
objetos en el programa.
Al empaquetamiento de las variables de un objeto con la protección de sus métodos se le llama
encapsulamiento.
Típicamente, el encapsulamiento es utilizado para esconder detalles de la puesta en práctica no
importantes de otros objetos. Entonces, los detalles de la puesta en práctica pueden cambiar en
cualquier tiempo sin afectar otras partes del programa.

1.5.3 Modularidad Objetos

La Modularidad es la propiedad que permite subdividir una aplicación en partes más pequeñas
(llamadas módulos), cada una de las cuales debe ser tan independiente como sea posible de la
aplicación en sí y de las restantes partes.
La modularización consiste en dividir un programa en módulos que se puedan compilar por
separado, pero que tienen conexiones con otros módulos. Al igual que la encapsulación, los
lenguajes soportan la Modularidad de diversas formas.
La Modularidad es la propiedad de un sistema que permite su descomposición en un conjunto de
módulos cohesivos y débilmente acoplados. Por supuesto no todos los módulos son iguales: tomar
un programa monolítico y separarlo de forma aleatoria en archivos no es óptimo. Se debe tener en
cuenta los conceptos asociados de dependencia, acoplamiento, cohesión, interfaz, encapsulación
y abstracción. Una vez identificado lo que es un buen módulo, se puede contemplar la reutilización
de un buen módulo como componente.

1.5.4 Jerarquia y Herencia

La Jerarquía es una propiedad que permite la ordenación de las abstracciones. Las dos jerarquías
más importantes de un sistema complejo son: estructura de clases (jerarquía “es-un” (is-a):
generalización/especialización) y estructura de objetos (jerarquía “parte-de” (part-of): agregación).
Las jerarquías de generalización/especialización se conocen como herencia. Básicamente, la
herencia define una relación entre clases, en donde una clase comparte la estructura o
comportamiento definido en una o más clases (herencia simple y herencia múltiple,
respectivamente).

1.5.5 Polimorfismo
La quinta propiedad significativa de los lenguajes de programación orientados a objetos es el
polimorfismo. Es la propiedad que indica, literalmente, la posibilidad de que una entidad tome
muchas formas. En términos prácticos, el polimorfismo permite referirse a objetos de clases
diferentes mediante el mismo elemento de programa y realizar la misma operación de diferentes
formas, según sea el objeto que se referencia en ese momento.
El polimorfismo adquiere su máxima expresión en la derivación o extensión de clases, es decir,
cuando se obtiene una clase a partir de una clase ya existente, mediante la propiedad de
derivación de clases o herencia.

1.6 Historia de los Paradigmas en el Desarrollo del Software

Paradigmas: Representan un enfoque particular o filosofía para la construcción del software. No es

mejor uno que otro sino que cada uno tiene ventajas y desventajas. También hay situaciones
donde un paradigma resulta más apropiado que otro. Los más comunes son el desarrollo en
cascada, el desarrollo en espiral, el desarrollo por prototipos, el desarrollo incremental, el desarrollo
en V y el desarrollo orientado a objetos. También existen modelo híbridos, los cuales combinan
elementos de diferentes modelos según las necesidades existentes.
Espiral

Prototipos

Casacada
Incremental

En v
Orientado a objetos

Hibridos
1.7 Beneficios del Modelo de Objetos y de la Poo sobre otros Paradigmas
En resumen, la programación orientada a objetos beneficia a los desarrolladores debido a que: Los
programas son fáciles de diseñar debido a que los objetos reflejan elementos del mundo real. Las
aplicaciones son más sencillas para los usuarios debido a que los datos innecesarios están
ocultos. Los objetos son unidades autocontenidas. La productividad se incrementa debido a que
puede reutilizar el código. Los sistemas son fáciles de mantener y se adaptan a las cambiantes
necesidades de negocios.
Es más fácil crear nuevos tipos de objetos a partir de los ya existentes.
Simplifica los datos complejos.
Reduce la complejidad de la transacción.
Confiabilidad.
Robustez.
Capacidad de ampliación.
Permite mostrar la magnitud de los lenguajes de programacion basada en objetos.

La POO utiliza jerarquia de clases para la elaboracion del diseño. Crea sistemas mas flexibles, que
en un futuro son modificables. Se aplica en las bases de datos, analisis matematico, animacion,
robotica, composicion de musica, etc
Aplica la metodología de desarrollo rápido de aplicaciones con programación orientada a eventos.

https://elvex.ugr.es/decsai/java/

http://academicos.azc.uam.mx/jfg/pags/tarea_programacion_visual.html

http://www3.uji.es/~belfern/Docencia/Presentaciones/ProgramacionAvanzada/Tema3/programa
cionDirigidaEventos.html#1

https://www.youtube.com/watch?v=HIaKAo-CqnA

Práctica No. 1. Repaso

A partir del archivo de entrada alumnos.txt, realizar un programa en Java que lo procese y
creé dos listas, una con los alumnos que estudian Computación y otra con los alumnos (de
cualquier carrera) cuya edad es mayor o igual a 19 años.

12345,Nombre 1,Primero 1,Segundo 1,Computacion,18

23456,Nombre 2,Primero 2,Segundo 2,Electronica,19
34567,Nombre 3,Primero 3,Segundo 3,Quimica,18
45678,Nombre 4,Primero 4,Segundo 4,Computacion,18
56789,Nombre 5,Primero 5,Segundo 5,Electronica,20
67890,Nombre 6,Primero 6,Segundo 6,Computacion,20
98765,Nombre 7,Primero 7,Segundo 7,Quimica,18
87654,Nombre 8,Primero 8,Segundo 8,Electronica,19
76543,Nombre 9,Primero 9,Segundo 9,Computacion,18
65432,Nombre 10,Primero 10,Segundo 10,Computacion,21
54321,Nombre 11,Primero 11,Segundo 11,Computacion,18
 43210,Nombre 12,Primero 12,Segundo 12,Quimica,22
32109,Nombre 13,Primero 13,Segundo 13,Electronica,22
21098,Nombre 14,Primero 14,Segundo 14,Computacion,18
10987,Nombre 15,Primero 15,Segundo 15,Quimica,18

Tarea No. 1
Rediseño de pantallas

Rediseñar la pantalla de inscripción de uea que utilizan los alumnos para inscribirse a
inicios del trimestre

Fecha de Entrega:
 Eniviar un archivo JPG o PNG por correo con el asunto: Tarea 1 PVOE Nombre Completo
a más tardar el viernes de la 2da semana.

Tarea No. 2
Botones y conversiones

Ejercicio de conversión e inversión de cadenas utilizando una interfaz con botones

Fecha de Entrega:
 Eniviar el proyecto comprimido como ZIP a más tardar el lunes de la 4ta semana.
Tarea No. 3
Radio Buttons y Checkboxes

Realizar una interfaz que contenga los siguientes elementos:

Una caja de texto para el nombre

Una caja de texto para la CURP
Radio buttons para seleccionar el género (Masculino o Femenino)
Un checkbox que al seleccionarlo indicará que se es de la CDMX y al dejarlo vacío, que se
es de otro estado
Una serie de checkboxes para elegir los apoyos deseados: Desempleo, Madre/padre soltero,
3ra edad, Nini
Un botón de Registrar que mostrará en consola los datos introducidos en la interfaz

Fecha de Entrega:
 Eniviar el proyecto comprimido como ZIP a más tardar el lunes de la 6ta semana.
 En asunto colocar TAREA 3 PVOE Nombre completo
 Tarea 4. Elementos de Selección y Objetos
Java Swing
 Descargar Documento
 Descargar Archivo Apoyo
Fecha de Entrega:

 Para una calificación de 10 hasta el martes de la 8va semana

Tarea No. 5 - Tablas
Java Swing
 Descargar Documento
 Descargar Archivo Apoyo

Fecha de Entrega:

 Para una calificación de 10: Hasta el jueves de la 10ma semana

 Para una calificación de 8: Hasta el jueves de la 11va semana

Diseño de Pantallas

Entrega No. 1. Identificación de Funcionalidades y Pantallas

A partir de la Descripción del Problema en los archivos de apoyo,
 Descripción del Problema
Se deben generar los siguientes elementos:

 Identificación de Funcionalidades
 Identificación de Pantallas
Consideraciones:

 No incluir una descripción detallada de los elementos de cada pantalla

 No se incluirán en esta entrega los prototipos de las pantallas
Fecha de Entrega:
 Enviar por correo a más tardar el viernes de la 6ta semana un archivo PDF con la identificación de
Funcionalidades y las pantallas que se hayan identificado para cada funcionalidad.
 No incluir el nombre en el archivo PDF
 En asunto colocar el PANTALLAS 1 Nombre completo del alumno
Entrega No. 2. Diseño de Pantallas
A partir de la Descripción del Problema y las funcionalidades encontradas en la Primera
Entrega, generar los prototipos de pantallas para las siguientes funcionalidades:
 Login
 Registro de Candidatos y sus conocimientos
 Registro de Empresa y vacantes
 Consultar vacantes disponibles de una empresa
 Buscar candidatos para una vacante
Consideraciones:

 Solo se generarán los prototipos

 No considerar forma de navegación o menú, solamente los elementos necesarios para cada
funcionalidad
 No es obligatorio entregar una pantalla por funcionalidad, dependerá el diseño
Fecha de Entrega:
 Enviar por correo a más tardar el viernes de la 10ma semana un archivo ZIP con los diseños en
formato PNG o JPG.
 El nombre del archivo será pantallas_MAT en donde MAT es la matrícula del alumno, en el asunto
colocar: Diseño Pantallas Nombre Completo Alumno
Implementación de Pantallas
Entrega No. 1. Navegación entre pantallas
A partir de las pantallas entregadas en la Entrega No. 2, realizar la implementación para
que se tenga una navegación entre las pantallas diseñadas deacuerdo a las siguientes
características:

 La primer pantalla en aparecer será la de Login (no es necesario realizar una validación)
 Posteriormente se podrá navegar através de pestañas, menú o por botones (a eleacción del
alumno) entre el resto de las ventanas
 Si es necesario agregar una ventana de menú, se puede realizar
Fecha de Entrega:

 Entregar en el cubículo del profesor el día del examen global

Implementación Funcional
Entrega Funcional
A partir de la navegación de pantallas de la entrega de Navegación entre pantallas, se
deberán agregar las siguientes funcionalidades:

 Login: Validación de al menos dos usuarios a través de información en un archivo

 Registro de Empresa y vacantes: La informacion aparecerá en archivos (uno para empresas y otro
para vacantes de la empresa)
 Consultar vacantes disponibles de una empresa: Se mostrarán en pantalla las vacantes registradas
en alguna empresa
Fecha de Entrega:

 Entregar en el cubículo del profesor el día del examen global

http://academicos.azc.uam.mx/jfg/pags/tarea_programacion_visual.html

http://www.jfree.org/jfreechart/download.html