INSTITUTO POLITECNICO NACIONALUNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERÍA

Y CIENCIAS SOCIALES Y ADMINISTRATIVAS

MATERIA: HERRAMIENTAS AUTOMATIZADASTEMA: DESARROLLO ORIENTADO A OBJETOS

Integrantes:Arvizu Vega Luis GenaroGonzález López José EduardoRodríguez Islas NayeliPedraza Hernández Luisa G.

Coordinador:Hernández Calva Jennifer Secuencia: 2NV51

HISTORIA Las ideas básicas de la orientación a objetos nacen a principios de los

años 60 en la universidad de Noruega, su equipo de trabajo y el dr. Nygaard .

La dificultad con las que se encontraron fueron: Que los programas eran muy complejos forzosamente tenían que ser muy modificados.

La solución que idearon fue diseñar el programa paralelamente al objeto físico. Es decir, si el objeto físico tenía cien componentes, el programa también tendría cien módulos, uno por cada pieza. Partiendo el programa de esta manera, había una total correspondencia entre el sistema físico y el sistema informático. Para implementar estas ideas lo que se hizo fue crear un lenguaje para

darle soporte, Simula-67, que continua utilizándose actualmente.

ESTUCTURA

1. Modelado de Requerimientos En esta etapa se especifica la funcionalidad del sistema desde la perspectiva del usuario, esto se hace principalmente con casos de uso. Consiste en 3 partes:  Modelo de caso de uso Descripción de la interfaces Modelo en el dominio del problema

2. Modelado de Análisis

Se especifican todos los objetos lógicos que serán incluidos en el sistema, como están relacionados y agrupados.

 

3. Modelado de Diseño

Se especifica una solución que trabaje y pueda ser fácilmente convertida en código fuente. En este modelo se hace uso de los diagramas de secuencia.  4. Modelado de Implementación En esta etapa es cuando se procede a la ejecución del código fuente que ha sido seleccionado.

5. Modelado de Prueba Se procede a probar el funcionamiento del sistema.

ORIENTACIÓN Separar las cosas para hacer las mas sencillas. Identificar los puntos clave. Dar facilidad de entendimiento con el usuario.

VENTAJAS Reutilización Dominio del problema Comunicación Consistencia Facilita mantenimiento del software Alto aprovechamiento del código.

DESVENTAJAS

Los objetos a menudo requieren una larga documentación. Dificultad al realizar los análisis o requerimientos. En ocasiones se dificultan las pruebas. Perdida de linealidad. Ejecución más lenta.

PASOS PARA IMPLEMENAR LA METODOLOGIA

1) Aquí se debe de tener en cuenta que cada caso de uso representa una funcionalidad del software que vamos a construir

PASO 2: PRIORIZAR LOS CASOS DE USO A TRABAJAR:

En este paso se deben de jerarquizar los casos de uso por importancia es decir, los casos de uso se ponen en una lista colocando los más importantes al inicio y los menos importantes al final.

PASO 3: GENERAR LOS DOCUMENTOS DE CASO DE USO:

Se recomienda que este tipo de documentos sean generados por el “Analista del proyecto” y su estructura debe de ser la siguiente: Descripción breve Precondiciones Flujo básico Flujo alternativo Postcondiciones Interfaz gráfica

PASO 4: GENERAR LOS DIAGRAMAS DE SECUENCIA:

Los diagramas de secuencia permiten ver la forma en que los objetos se comunicaran entre si para cumplir su objetivo.

PASO 5: DISEÑAR EL FRAMEWORK DEL PROYECTO:

Dentro de este punto el Arquitecto de Software diseñara las clases que se usarán en todo el software basándose en los diagramas UML.

PASO 6: CREACION DE LA BASE DE DATOS:

Para la creación y/o diseño de las bases de datos se puede auxiliar o apoyarse de los diagramas UML pero solo se utilizara la capa de datos, en otras palabras, solo se hará uso de las clases de estereotipo Entidad.

PASO 7: CONTRUIR LA MASCARA:

Mientras los pasos 4, 5 y 6 se llevan a cabo, el personal de Diseño del Sistema, puede desarrollar las plantillas para la creación del sistema, es decir, puede comenzar a crear la interfaz del software con el usuario.

PASO 8: PROGRAMAR LAS FUNCIONALIDADES DE LOS CASOS DE USO:

En este punto el equipo de programadores se encargara de desarrollar el código necesario, para que el caso de uso funcione, tal y como se planteó.

PASO 9: PROBAR LOS REQUERIMIENTOS DEL SOFTWARE:

Lo más recomendable es que estas pruebas se hagan por personas que no participaron en la programación (Los programadores), ya que es mucho mejor que otra persona las haga y se cerciore de las anomalías de cualquier índole que pueda presentar el software.

PASO 10: INTEGRAR LOS REQUERIMIENTOS REQUERIDOS:

Para concluir en este punto, se une todo lo que se hizo (los casos de uso, el desarrollo, la programación), para que posteriormente se ponga a disposición de los usuarios.

CONCLUSIONES

Al descomponerse en componentes funcionales, los subprogramas podían servir para construir otros sistemas más grandes y complejos.

Optimiza los tiempos de respuesta a los requerimientos del cliente.

GRACIAS POR SU ATENCIÓN