SlideShare une entreprise Scribd logo
1  sur  42
Universidad Católica los Ángeles de Chimbote Sistemas de Información II Facultad de Ingeniería Escuela profesional de Ingeniería de sistemas
El  Lenguaje   Unificado  de  Modelado
Notación El Triángulo de Desarrollo de Software Herramienta Visual Proceso
Definición : El  U M L  es un lenguaje gráfico  para la especificación, visualización, construcción y documentación de  modelos orientados a objetos que representan sistemas intensivos en software.     =  U nified   M odeling  L anguage U M L   no es un método sino un lenguaje de modelamiento El   Lenguaje  Unificado  de   Modelado
Objetivo del  U M L ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
U M L toma lo mejor de varios métodos Rumbaugh Jacobson Meyer Harel Wirfs-Brock Fusion Embly Gamma et. al. Shlaer-Mellor Odell Booch Pre y Post condiciones Máquinas de estado Responsabilidades Descripción de operaciones, numeración de mensajes Singleton clases Marcos de trabajo,  patrones, notas  Ciclo de vida de objetos Clasificación
-  Proporciona  a los desarrolladores un lenguaje de   modelamiento ampliamente aceptado y listo para usar. - Integra las mejores prácticas del desarrollo de software. - Permite el intercambio de modelos entre las diferentes   herramientas de software. - Es independiente del lenguaje de programación y de   métodos y procesos particulares de desarrollo de software. - Proporciona sus propios mecanismos de extensión - Agrupa los conceptos de orientación a objetos definiendo   su significado. Características del  U M L
Por qué aprender  U M L ,[object Object],[object Object],[object Object],[object Object],[object Object]
- Los lenguajes de modelado orientados al objeto comenzaron a aparecer a mediados de la década de '70. - El número de lenguajes que  modelaban objetos aumentó de menos de 10 a más de 50 durante el período entre 1989-1994. Breve historia del  U M L -  Muchos de los que utilizaban estos lenguajes no encontraban satisfacción completa en ninguno de ellos, esto motivó la llamada  "Guerra de los Métodos" .
. . . La “Guerra de los Métodos” Exist í an muchos métodos y cada uno tenía un lenguaje de modelado propio. Esto dificultó el aprendizaje, aplicación, construcción, uso de herramientas, etc. Pugna entre los distintos gur ú s que defend í an sus propios métodos y simbologías. Se observa la necesidad de una notación estándar. . . . Breve historia del  U M L
El desarrollo del  U M L  comenzó en finales de 1994 en que Grady Booch y Jim Rumbaugh de Rational Software Corporation, comenzaron su trabajo sobre la unificación de los métodos de Booch y de OMT (Object Modeling Technique). A finales de 1995, Ivar Jacobson y su compañía de Objectory se unieron a Rational y combinaron sus métodos. Booch, Rumbaugh, y Jacobson, definieron el  U M L  0,9 y 0,91 en junio y octubre de 1996. . . . Breve historia del  U M L
. . . Breve historia del  U M L Sep ‘97   U M L  1.1 Ene ‘97   U M L  1.0 Jun ‘96   U M L  0.9 Oct ‘95   Método Unificado 0.8 Microsoft Oracle IBM, HP Etc. Ivar Jacobson se une a  Rational en otoño  ‘95 James Rumbaugh se une  a Rational en Oct ‘94 OMT  Booch Use Case (OOSE) Otros métodos
1997 (Adoptada por OMG) 1998  (revisión editorial sin   cambios significativos) 1999 (revisión menor  p ú blicamente disponible) 2000 (planificada una revisión menor) 2001 (planificada una revisión menor) 2002 (planificada una revisión mayor) Versiones del  U M L <<document>> U M L  1.1 <<document>> U M L  1.2 <<document>> U M L  1.5 <<document>> U M L  1.3 <<document>> U M L  2.0 <<document>> U M L  1.4 <<document>> ISO  Publica especificación
Vistas de un modelo  “ Un modelo es una descripción completa de un sistema desde una perspectiva concreta” Vista lógica Vista de proceso s Vista de despliegue Vista de implementación Vista de  requerimientos Diagrama de Clases Diagrama de Objetos Diagrama de Estado Diagrama de Secuencia Diagrama de Colaboración Diagrama de Actividad Diagrama de Casos de Uso Diagrama de Componentes Diagrama de Despliegue
Modelando con  U M L Use Case Diagrams Use Case Diagrams Diagramas de  Casos de Uso Scenario Diagrams Scenario Diagrams Diagramas de Colaboración State Diagrams State Diagrams Diagramas de Componentes Component Diagrams Component Diagrams Diagramas de Despliegue State Diagrams State Diagrams Diagramas de  Objetos Scenario Diagrams Scenario Diagrams Diagramas de Estados Use Case Diagrams Use Case Diagrams Diagramas de Secuencia State Diagrams State Diagrams Diagramas de Clases Diagramas de Actividad Modelo
Introducción ,[object Object],[object Object],[object Object],[object Object],[object Object],La Crisis del Software
La Crisis del Software ,[object Object],[object Object],[object Object],[object Object],Ejemplos extremos, PERO hay muchos desastres similares en una menor escala Software failures reported by W. Wayt Gibbs in the  September, 1994 issue of Scientific American
La Crisis del Software ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
[object Object],[object Object],[object Object],Base Inestable
Fallas en el Manejo de Riesgos ,[object Object],[object Object],[object Object]
Complejidad de Software ,[object Object],[object Object],[object Object]
Análisis y Diseño Orientado a Objeto s OOD Agregar detalles y  decisiones de diseño Perspectiva del Desarrollador OOA Modelo de desarrollo  de requerimientos Perspectiva del Usuario
Desarrollo Iterativo e Incremental Ing. Oscar Ascón Valdivia [email_address]
Objetivos: Desarrollo Iterativo e Incremental ,[object Object],[object Object],[object Object],[object Object]
¿Qué es un  Desarrollo Iterativo e Incremental? ,[object Object],[object Object],[object Object],[object Object],[object Object]
El Ciclo de Vida del Software ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Inicio Elaboración Construcción Transición tiempo
Fase de Inicio ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Fase de Elaboración  ,[object Object],[object Object],[object Object],[object Object],[object Object]
Fase de Elaboración (cont.) ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Fase de Construcción  ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Fase de Transición ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
¿Qué es una Iteración? ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Iteración arquitect. Iteración de transición Iteración de transición Iteración desarrollo Iteración desarrollo Iteración desarrollo Iteración arquitect. Iteración preliminar
Reducción de Riesgo a través de Iteraciones  Riesgo inicial Campo de acción inicial del proyecto Definir la iteración para consignar el mayor riesgo Planificar y desarrollar la iteración Estimar la iteración  Eliminación  del riesgo Revisión de la Evaluación de riesgo  Revisión del plan del proyecto Iteración N
Proceso de Planificación de una Iteración ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Juntando Todo
Características Esenciales de RUP  ,[object Object],[object Object],[object Object]
Requisitos Capturar,  definir  y  validar los   casos de uso Realizar los  casos de uso Verificar  que  se satisfacen los   casos de uso Proceso dirigido por los Casos de Uso Análisis  & Diseño Implement ación Prueba s Casos de Uso integran el trabajo
[object Object],[object Object],[object Object],Proceso Iterativo e Incremental
[object Object],... Proceso Iterativo e Incremental n veces Análisis Diseño Codific. Pruebas e Integración
[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],... Proceso Iterativo e Incremental
Proceso Centrado en la Arquitectura  ,[object Object],[object Object],[object Object],Inception Elaboration Construction Transition Architecture
Trabajo de investigación ,[object Object],[object Object]

Contenu connexe

Tendances (18)

UML. un analisis comparativo para la diagramación de software
UML.  un analisis comparativo para la diagramación de softwareUML.  un analisis comparativo para la diagramación de software
UML. un analisis comparativo para la diagramación de software
 
Nesii
NesiiNesii
Nesii
 
Ingenieria de software
Ingenieria de softwareIngenieria de software
Ingenieria de software
 
Generacion en los diferentes diagramas de uml
Generacion en los diferentes diagramas de uml Generacion en los diferentes diagramas de uml
Generacion en los diferentes diagramas de uml
 
F004 p006 gfpi guìa de aprendizaje 3-v2
F004 p006 gfpi guìa de aprendizaje 3-v2F004 p006 gfpi guìa de aprendizaje 3-v2
F004 p006 gfpi guìa de aprendizaje 3-v2
 
Tema N° 11 Lenguaje de Representación (UML y URN)
Tema N° 11 Lenguaje de Representación (UML y URN)Tema N° 11 Lenguaje de Representación (UML y URN)
Tema N° 11 Lenguaje de Representación (UML y URN)
 
Uml
UmlUml
Uml
 
F004 p006 gfpi guìa de aprendizaje 3
F004 p006 gfpi guìa de aprendizaje 3F004 p006 gfpi guìa de aprendizaje 3
F004 p006 gfpi guìa de aprendizaje 3
 
Ingeniería de software
Ingeniería de softwareIngeniería de software
Ingeniería de software
 
Estructura de casos de uso
Estructura de casos de usoEstructura de casos de uso
Estructura de casos de uso
 
Miguel mena
Miguel menaMiguel mena
Miguel mena
 
Presentación de software
Presentación de softwarePresentación de software
Presentación de software
 
Características de un programa
Características de un programaCaracterísticas de un programa
Características de un programa
 
UML
UMLUML
UML
 
Exposicion
ExposicionExposicion
Exposicion
 
conceptos de ingenieria de software
conceptos de ingenieria de softwareconceptos de ingenieria de software
conceptos de ingenieria de software
 
Curso Uml 1 Introduccion
Curso Uml   1 IntroduccionCurso Uml   1 Introduccion
Curso Uml 1 Introduccion
 
Computación i mariangel_garcia
Computación i mariangel_garciaComputación i mariangel_garcia
Computación i mariangel_garcia
 

Similaire à Clase

Slideshare #01
Slideshare #01Slideshare #01
Slideshare #01wcontra31
 
Proceso racional unificado(ingenieria del sotfware)
Proceso racional unificado(ingenieria del sotfware)Proceso racional unificado(ingenieria del sotfware)
Proceso racional unificado(ingenieria del sotfware)Ramon Ledezma
 
Microsoft power point uml
Microsoft power point   umlMicrosoft power point   uml
Microsoft power point umlFelipe Valles L
 
Curso ingeniería de software parte i
Curso ingeniería de software parte iCurso ingeniería de software parte i
Curso ingeniería de software parte iparafernalico
 
Trabajo de sistemas de software
Trabajo de sistemas de softwareTrabajo de sistemas de software
Trabajo de sistemas de softwareJhonJairoPerez
 
Metodologias De Analisis Y Diseño De Sistemas
Metodologias De Analisis Y Diseño De SistemasMetodologias De Analisis Y Diseño De Sistemas
Metodologias De Analisis Y Diseño De Sistemasgrupo7inf162
 
ELEMENTOS DE LA CONFIGURACION DE SOFTWARE.ppt
ELEMENTOS DE LA CONFIGURACION DE SOFTWARE.pptELEMENTOS DE LA CONFIGURACION DE SOFTWARE.ppt
ELEMENTOS DE LA CONFIGURACION DE SOFTWARE.pptMarko Zapata
 
Curso Uml 3.1 Modelos De Desarrollo De Software
Curso Uml   3.1 Modelos De Desarrollo De SoftwareCurso Uml   3.1 Modelos De Desarrollo De Software
Curso Uml 3.1 Modelos De Desarrollo De SoftwareEmilio Aviles Avila
 

Similaire à Clase (20)

Sesion1 adsi
Sesion1 adsiSesion1 adsi
Sesion1 adsi
 
UML. Modelado de Datos
UML. Modelado de DatosUML. Modelado de Datos
UML. Modelado de Datos
 
Estructura de casos de uso
Estructura de casos de usoEstructura de casos de uso
Estructura de casos de uso
 
Slideshare #01
Slideshare #01Slideshare #01
Slideshare #01
 
Programacion
ProgramacionProgramacion
Programacion
 
Introduccion a la ingenieria de software
Introduccion a la ingenieria de softwareIntroduccion a la ingenieria de software
Introduccion a la ingenieria de software
 
Desarrollo de aplicaciones con rup y uml
Desarrollo de aplicaciones con rup y umlDesarrollo de aplicaciones con rup y uml
Desarrollo de aplicaciones con rup y uml
 
Tema Introducción IS
Tema Introducción ISTema Introducción IS
Tema Introducción IS
 
Proceso racional unificado(ingenieria del sotfware)
Proceso racional unificado(ingenieria del sotfware)Proceso racional unificado(ingenieria del sotfware)
Proceso racional unificado(ingenieria del sotfware)
 
Modelado, Ingenieria de Software
Modelado, Ingenieria de SoftwareModelado, Ingenieria de Software
Modelado, Ingenieria de Software
 
Microsoft power point uml
Microsoft power point   umlMicrosoft power point   uml
Microsoft power point uml
 
Curso ingeniería de software parte i
Curso ingeniería de software parte iCurso ingeniería de software parte i
Curso ingeniería de software parte i
 
Trabajo de sistemas de software
Trabajo de sistemas de softwareTrabajo de sistemas de software
Trabajo de sistemas de software
 
DiseñO De Sistemas
DiseñO De SistemasDiseñO De Sistemas
DiseñO De Sistemas
 
Diseño de Sistemas
Diseño de SistemasDiseño de Sistemas
Diseño de Sistemas
 
DiseñO De Sistemas
DiseñO De SistemasDiseñO De Sistemas
DiseñO De Sistemas
 
Metodologias De Analisis Y Diseño De Sistemas
Metodologias De Analisis Y Diseño De SistemasMetodologias De Analisis Y Diseño De Sistemas
Metodologias De Analisis Y Diseño De Sistemas
 
Proyecto análisis y Diseño de Sistemas
Proyecto análisis y Diseño de SistemasProyecto análisis y Diseño de Sistemas
Proyecto análisis y Diseño de Sistemas
 
ELEMENTOS DE LA CONFIGURACION DE SOFTWARE.ppt
ELEMENTOS DE LA CONFIGURACION DE SOFTWARE.pptELEMENTOS DE LA CONFIGURACION DE SOFTWARE.ppt
ELEMENTOS DE LA CONFIGURACION DE SOFTWARE.ppt
 
Curso Uml 3.1 Modelos De Desarrollo De Software
Curso Uml   3.1 Modelos De Desarrollo De SoftwareCurso Uml   3.1 Modelos De Desarrollo De Software
Curso Uml 3.1 Modelos De Desarrollo De Software
 

Dernier

MODELO DE INFORME DE INDAGACION CIENTIFICA .docx
MODELO DE INFORME DE INDAGACION CIENTIFICA .docxMODELO DE INFORME DE INDAGACION CIENTIFICA .docx
MODELO DE INFORME DE INDAGACION CIENTIFICA .docxRAMON EUSTAQUIO CARO BAYONA
 
Fichas de Matemática DE SEGUNDO DE SECUNDARIA.pdf
Fichas de Matemática DE SEGUNDO DE SECUNDARIA.pdfFichas de Matemática DE SEGUNDO DE SECUNDARIA.pdf
Fichas de Matemática DE SEGUNDO DE SECUNDARIA.pdfssuser50d1252
 
sesión de aprendizaje 4 E1 Exposición oral.pdf
sesión de aprendizaje 4 E1 Exposición oral.pdfsesión de aprendizaje 4 E1 Exposición oral.pdf
sesión de aprendizaje 4 E1 Exposición oral.pdfpatriciavsquezbecerr
 
Secuencia didáctica.DOÑA CLEMENTINA.2024.docx
Secuencia didáctica.DOÑA CLEMENTINA.2024.docxSecuencia didáctica.DOÑA CLEMENTINA.2024.docx
Secuencia didáctica.DOÑA CLEMENTINA.2024.docxNataliaGonzalez619348
 
periodico mural y sus partes y caracteristicas
periodico mural y sus partes y caracteristicasperiodico mural y sus partes y caracteristicas
periodico mural y sus partes y caracteristicas123yudy
 
TUTORIA II - CIRCULO DORADO UNIVERSIDAD CESAR VALLEJO
TUTORIA II - CIRCULO DORADO UNIVERSIDAD CESAR VALLEJOTUTORIA II - CIRCULO DORADO UNIVERSIDAD CESAR VALLEJO
TUTORIA II - CIRCULO DORADO UNIVERSIDAD CESAR VALLEJOweislaco
 
VOLUMEN 1 COLECCION PRODUCCION BOVINA . SERIE SANIDAD ANIMAL
VOLUMEN 1 COLECCION PRODUCCION BOVINA . SERIE SANIDAD ANIMALVOLUMEN 1 COLECCION PRODUCCION BOVINA . SERIE SANIDAD ANIMAL
VOLUMEN 1 COLECCION PRODUCCION BOVINA . SERIE SANIDAD ANIMALEDUCCUniversidadCatl
 
SIMULACROS Y SIMULACIONES DE SISMO 2024.docx
SIMULACROS Y SIMULACIONES DE SISMO 2024.docxSIMULACROS Y SIMULACIONES DE SISMO 2024.docx
SIMULACROS Y SIMULACIONES DE SISMO 2024.docxLudy Ventocilla Napanga
 
Contextualización y aproximación al objeto de estudio de investigación cualit...
Contextualización y aproximación al objeto de estudio de investigación cualit...Contextualización y aproximación al objeto de estudio de investigación cualit...
Contextualización y aproximación al objeto de estudio de investigación cualit...Angélica Soledad Vega Ramírez
 
EDUCACION FISICA 1° PROGRAMACIÓN ANUAL 2023.docx
EDUCACION FISICA 1°  PROGRAMACIÓN ANUAL 2023.docxEDUCACION FISICA 1°  PROGRAMACIÓN ANUAL 2023.docx
EDUCACION FISICA 1° PROGRAMACIÓN ANUAL 2023.docxLuisAndersonPachasto
 
libro para colorear de Peppa pig, ideal para educación inicial
libro para colorear de Peppa pig, ideal para educación iniciallibro para colorear de Peppa pig, ideal para educación inicial
libro para colorear de Peppa pig, ideal para educación inicialLorenaSanchez350426
 
4º SOY LECTOR PART2- MD EDUCATIVO.p df PARTE
4º SOY LECTOR PART2- MD  EDUCATIVO.p df PARTE4º SOY LECTOR PART2- MD  EDUCATIVO.p df PARTE
4º SOY LECTOR PART2- MD EDUCATIVO.p df PARTESaraNolasco4
 
Fichas de Matemática TERCERO DE SECUNDARIA.pdf
Fichas de Matemática TERCERO DE SECUNDARIA.pdfFichas de Matemática TERCERO DE SECUNDARIA.pdf
Fichas de Matemática TERCERO DE SECUNDARIA.pdfssuser50d1252
 
Manejo del Dengue, generalidades, actualización marzo 2024 minsa
Manejo del Dengue, generalidades, actualización marzo 2024 minsaManejo del Dengue, generalidades, actualización marzo 2024 minsa
Manejo del Dengue, generalidades, actualización marzo 2024 minsaLuis Minaya
 
PROGRAMACION ANUAL DE MATEMATICA 2024.docx
PROGRAMACION ANUAL DE MATEMATICA 2024.docxPROGRAMACION ANUAL DE MATEMATICA 2024.docx
PROGRAMACION ANUAL DE MATEMATICA 2024.docxEribertoPerezRamirez
 
Técnicas de grabado y estampación : procesos y materiales
Técnicas de grabado y estampación : procesos y materialesTécnicas de grabado y estampación : procesos y materiales
Técnicas de grabado y estampación : procesos y materialesRaquel Martín Contreras
 

Dernier (20)

TL/CNL – 2.ª FASE .
TL/CNL – 2.ª FASE                       .TL/CNL – 2.ª FASE                       .
TL/CNL – 2.ª FASE .
 
MODELO DE INFORME DE INDAGACION CIENTIFICA .docx
MODELO DE INFORME DE INDAGACION CIENTIFICA .docxMODELO DE INFORME DE INDAGACION CIENTIFICA .docx
MODELO DE INFORME DE INDAGACION CIENTIFICA .docx
 
Fichas de Matemática DE SEGUNDO DE SECUNDARIA.pdf
Fichas de Matemática DE SEGUNDO DE SECUNDARIA.pdfFichas de Matemática DE SEGUNDO DE SECUNDARIA.pdf
Fichas de Matemática DE SEGUNDO DE SECUNDARIA.pdf
 
sesión de aprendizaje 4 E1 Exposición oral.pdf
sesión de aprendizaje 4 E1 Exposición oral.pdfsesión de aprendizaje 4 E1 Exposición oral.pdf
sesión de aprendizaje 4 E1 Exposición oral.pdf
 
Secuencia didáctica.DOÑA CLEMENTINA.2024.docx
Secuencia didáctica.DOÑA CLEMENTINA.2024.docxSecuencia didáctica.DOÑA CLEMENTINA.2024.docx
Secuencia didáctica.DOÑA CLEMENTINA.2024.docx
 
periodico mural y sus partes y caracteristicas
periodico mural y sus partes y caracteristicasperiodico mural y sus partes y caracteristicas
periodico mural y sus partes y caracteristicas
 
TUTORIA II - CIRCULO DORADO UNIVERSIDAD CESAR VALLEJO
TUTORIA II - CIRCULO DORADO UNIVERSIDAD CESAR VALLEJOTUTORIA II - CIRCULO DORADO UNIVERSIDAD CESAR VALLEJO
TUTORIA II - CIRCULO DORADO UNIVERSIDAD CESAR VALLEJO
 
VOLUMEN 1 COLECCION PRODUCCION BOVINA . SERIE SANIDAD ANIMAL
VOLUMEN 1 COLECCION PRODUCCION BOVINA . SERIE SANIDAD ANIMALVOLUMEN 1 COLECCION PRODUCCION BOVINA . SERIE SANIDAD ANIMAL
VOLUMEN 1 COLECCION PRODUCCION BOVINA . SERIE SANIDAD ANIMAL
 
SIMULACROS Y SIMULACIONES DE SISMO 2024.docx
SIMULACROS Y SIMULACIONES DE SISMO 2024.docxSIMULACROS Y SIMULACIONES DE SISMO 2024.docx
SIMULACROS Y SIMULACIONES DE SISMO 2024.docx
 
Contextualización y aproximación al objeto de estudio de investigación cualit...
Contextualización y aproximación al objeto de estudio de investigación cualit...Contextualización y aproximación al objeto de estudio de investigación cualit...
Contextualización y aproximación al objeto de estudio de investigación cualit...
 
PPTX: La luz brilla en la oscuridad.pptx
PPTX: La luz brilla en la oscuridad.pptxPPTX: La luz brilla en la oscuridad.pptx
PPTX: La luz brilla en la oscuridad.pptx
 
EDUCACION FISICA 1° PROGRAMACIÓN ANUAL 2023.docx
EDUCACION FISICA 1°  PROGRAMACIÓN ANUAL 2023.docxEDUCACION FISICA 1°  PROGRAMACIÓN ANUAL 2023.docx
EDUCACION FISICA 1° PROGRAMACIÓN ANUAL 2023.docx
 
libro para colorear de Peppa pig, ideal para educación inicial
libro para colorear de Peppa pig, ideal para educación iniciallibro para colorear de Peppa pig, ideal para educación inicial
libro para colorear de Peppa pig, ideal para educación inicial
 
4º SOY LECTOR PART2- MD EDUCATIVO.p df PARTE
4º SOY LECTOR PART2- MD  EDUCATIVO.p df PARTE4º SOY LECTOR PART2- MD  EDUCATIVO.p df PARTE
4º SOY LECTOR PART2- MD EDUCATIVO.p df PARTE
 
Fichas de Matemática TERCERO DE SECUNDARIA.pdf
Fichas de Matemática TERCERO DE SECUNDARIA.pdfFichas de Matemática TERCERO DE SECUNDARIA.pdf
Fichas de Matemática TERCERO DE SECUNDARIA.pdf
 
Manejo del Dengue, generalidades, actualización marzo 2024 minsa
Manejo del Dengue, generalidades, actualización marzo 2024 minsaManejo del Dengue, generalidades, actualización marzo 2024 minsa
Manejo del Dengue, generalidades, actualización marzo 2024 minsa
 
PROGRAMACION ANUAL DE MATEMATICA 2024.docx
PROGRAMACION ANUAL DE MATEMATICA 2024.docxPROGRAMACION ANUAL DE MATEMATICA 2024.docx
PROGRAMACION ANUAL DE MATEMATICA 2024.docx
 
Sesión La luz brilla en la oscuridad.pdf
Sesión  La luz brilla en la oscuridad.pdfSesión  La luz brilla en la oscuridad.pdf
Sesión La luz brilla en la oscuridad.pdf
 
Técnicas de grabado y estampación : procesos y materiales
Técnicas de grabado y estampación : procesos y materialesTécnicas de grabado y estampación : procesos y materiales
Técnicas de grabado y estampación : procesos y materiales
 
Earth Day Everyday 2024 54th anniversary
Earth Day Everyday 2024 54th anniversaryEarth Day Everyday 2024 54th anniversary
Earth Day Everyday 2024 54th anniversary
 

Clase

  • 1. Universidad Católica los Ángeles de Chimbote Sistemas de Información II Facultad de Ingeniería Escuela profesional de Ingeniería de sistemas
  • 2. El Lenguaje Unificado de Modelado
  • 3. Notación El Triángulo de Desarrollo de Software Herramienta Visual Proceso
  • 4. Definición : El U M L es un lenguaje gráfico para la especificación, visualización, construcción y documentación de modelos orientados a objetos que representan sistemas intensivos en software. = U nified M odeling L anguage U M L no es un método sino un lenguaje de modelamiento El Lenguaje Unificado de Modelado
  • 5.
  • 6. U M L toma lo mejor de varios métodos Rumbaugh Jacobson Meyer Harel Wirfs-Brock Fusion Embly Gamma et. al. Shlaer-Mellor Odell Booch Pre y Post condiciones Máquinas de estado Responsabilidades Descripción de operaciones, numeración de mensajes Singleton clases Marcos de trabajo, patrones, notas Ciclo de vida de objetos Clasificación
  • 7. - Proporciona a los desarrolladores un lenguaje de modelamiento ampliamente aceptado y listo para usar. - Integra las mejores prácticas del desarrollo de software. - Permite el intercambio de modelos entre las diferentes herramientas de software. - Es independiente del lenguaje de programación y de métodos y procesos particulares de desarrollo de software. - Proporciona sus propios mecanismos de extensión - Agrupa los conceptos de orientación a objetos definiendo su significado. Características del U M L
  • 8.
  • 9. - Los lenguajes de modelado orientados al objeto comenzaron a aparecer a mediados de la década de '70. - El número de lenguajes que modelaban objetos aumentó de menos de 10 a más de 50 durante el período entre 1989-1994. Breve historia del U M L - Muchos de los que utilizaban estos lenguajes no encontraban satisfacción completa en ninguno de ellos, esto motivó la llamada &quot;Guerra de los Métodos&quot; .
  • 10. . . . La “Guerra de los Métodos” Exist í an muchos métodos y cada uno tenía un lenguaje de modelado propio. Esto dificultó el aprendizaje, aplicación, construcción, uso de herramientas, etc. Pugna entre los distintos gur ú s que defend í an sus propios métodos y simbologías. Se observa la necesidad de una notación estándar. . . . Breve historia del U M L
  • 11. El desarrollo del U M L comenzó en finales de 1994 en que Grady Booch y Jim Rumbaugh de Rational Software Corporation, comenzaron su trabajo sobre la unificación de los métodos de Booch y de OMT (Object Modeling Technique). A finales de 1995, Ivar Jacobson y su compañía de Objectory se unieron a Rational y combinaron sus métodos. Booch, Rumbaugh, y Jacobson, definieron el U M L 0,9 y 0,91 en junio y octubre de 1996. . . . Breve historia del U M L
  • 12. . . . Breve historia del U M L Sep ‘97 U M L 1.1 Ene ‘97 U M L 1.0 Jun ‘96 U M L 0.9 Oct ‘95 Método Unificado 0.8 Microsoft Oracle IBM, HP Etc. Ivar Jacobson se une a Rational en otoño ‘95 James Rumbaugh se une a Rational en Oct ‘94 OMT Booch Use Case (OOSE) Otros métodos
  • 13. 1997 (Adoptada por OMG) 1998 (revisión editorial sin cambios significativos) 1999 (revisión menor p ú blicamente disponible) 2000 (planificada una revisión menor) 2001 (planificada una revisión menor) 2002 (planificada una revisión mayor) Versiones del U M L <<document>> U M L 1.1 <<document>> U M L 1.2 <<document>> U M L 1.5 <<document>> U M L 1.3 <<document>> U M L 2.0 <<document>> U M L 1.4 <<document>> ISO Publica especificación
  • 14. Vistas de un modelo “ Un modelo es una descripción completa de un sistema desde una perspectiva concreta” Vista lógica Vista de proceso s Vista de despliegue Vista de implementación Vista de requerimientos Diagrama de Clases Diagrama de Objetos Diagrama de Estado Diagrama de Secuencia Diagrama de Colaboración Diagrama de Actividad Diagrama de Casos de Uso Diagrama de Componentes Diagrama de Despliegue
  • 15. Modelando con U M L Use Case Diagrams Use Case Diagrams Diagramas de Casos de Uso Scenario Diagrams Scenario Diagrams Diagramas de Colaboración State Diagrams State Diagrams Diagramas de Componentes Component Diagrams Component Diagrams Diagramas de Despliegue State Diagrams State Diagrams Diagramas de Objetos Scenario Diagrams Scenario Diagrams Diagramas de Estados Use Case Diagrams Use Case Diagrams Diagramas de Secuencia State Diagrams State Diagrams Diagramas de Clases Diagramas de Actividad Modelo
  • 16.
  • 17.
  • 18.
  • 19.
  • 20.
  • 21.
  • 22. Análisis y Diseño Orientado a Objeto s OOD Agregar detalles y decisiones de diseño Perspectiva del Desarrollador OOA Modelo de desarrollo de requerimientos Perspectiva del Usuario
  • 23. Desarrollo Iterativo e Incremental Ing. Oscar Ascón Valdivia [email_address]
  • 24.
  • 25.
  • 26.
  • 27.
  • 28.
  • 29.
  • 30.
  • 31.
  • 32.
  • 33. Reducción de Riesgo a través de Iteraciones Riesgo inicial Campo de acción inicial del proyecto Definir la iteración para consignar el mayor riesgo Planificar y desarrollar la iteración Estimar la iteración Eliminación del riesgo Revisión de la Evaluación de riesgo Revisión del plan del proyecto Iteración N
  • 34.
  • 36.
  • 37. Requisitos Capturar, definir y validar los casos de uso Realizar los casos de uso Verificar que se satisfacen los casos de uso Proceso dirigido por los Casos de Uso Análisis & Diseño Implement ación Prueba s Casos de Uso integran el trabajo
  • 38.
  • 39.
  • 40.
  • 41.
  • 42.

Notes de l'éditeur

  1. Ing. Oscar Ascón Valdivia
  2. Ing. Oscar Ascón Valdivia
  3. Ing. Oscar Ascón Valdivia
  4. Ing. Oscar Ascón Valdivia
  5. Ing. Oscar Ascón Valdivia
  6. Ing. Oscar Ascón Valdivia
  7. Ing. Oscar Ascón Valdivia
  8. Ing. Oscar Ascón Valdivia
  9. Ing. Oscar Ascón Valdivia
  10. Ing. Oscar Ascón Valdivia
  11. Ing. Oscar Ascón Valdivia
  12. Ing. Oscar Ascón Valdivia Durante 1996, los autores del U M L invitaron a la comunidad de desarrolladores a realizar sus aportes. Mientras tanto, la industria del software quería definir un lenguaje de modelamiento estándar. En junio de 1995, el OMG reunió a todos metodologistas importantes dando lugar al primer acuerdo mundial de buscar estándares de la metodología, bajo la batuta del OMG . Durante 1996, varias organizaciones consideraron U M L como estratégico a su negocio. Racional estableció el consorcio de los socios de U M L para una definición de U M L 1,0 . Entre ellos: Digital Equipment Corp., HP, i-Logix, IntelliCorp, IBM, ICON computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI, y Unisys. Esta versión se sometió al OMG para su aceptación como nuevo estándar en enero de 1997 y se unieron ObjecTime de IBM, Platinium Technology, Ptech, Taskon, Reich Technology y Softeam quienes produjeron la versión 1,1 del U M L la cual fue adoptada como estándar a fines de 1997.
  13. Ing. Oscar Ascón Valdivia
  14. Ing. Oscar Ascón Valdivia VISTA DE REQUERIMIENTOS Es el enlace de las otras vistas Describe aspectos de comportamiento no de construccion Muestra la funcionalidad del sistema como es percibida por los actores externos Utiliza los diagramas de casos de uso y diagramas de actividad VISTA LOGICA Muestra el diseño de la funcionalidad Muestra la estructura (elementos que lo integran) mediante diagramas de clases y objetos Muestra la interaccion de los elementos mediante diagramas de Estado, Secuencia, Colaboracion y Actividad VISTA DE COMPONENTES O IMPLEMENTACION La vista logica era solo una abstraccion La vista de componentes muestran los archivos (ejecutables, fuentes, librerias)en los que se traducen los elementos logicos Muestra la dependencia entre estos elementos Consiste en diagramas de componentes VISTA DE DESPLIEGUE O IMPLANTACION Muestra como el software se despliega en el hardware Indica donde se ubica el software y como se comunican entre si Consiste en diagramas de despliegue VISTA DE PROCESOS O DE CONCURRENCIA combinacion de vista logica, componentes e implantacion Muestra el manejo de la concurrencia de los procesos (comunicacion y sincronizacion, hilos de control, procesos paralelos) Es importante para sistemas distribuidos y de tiempo real Consiste en diagramas de componentes y despliegue, y diagramas de estado, secuencia, colaboracion y actividad.
  15. Ing. Oscar Ascón Valdivia
  16. Ing. Oscar Ascón Valdivia
  17. Ing. Oscar Ascón Valdivia Algo más ... W. Gibbs, &amp;quot;Software&apos;s Chronic Crisis&amp;quot;, cientifico americano, Sept. 1994, pp. 86-95: &amp;quot;[...] a pesar de 50 años de progreso, la industria del software permanece años - tal vez décadas - atrasada con respecto a las disciplinas de ingeniería necesarias para cumplir las demandas de una sociedad en la edad de la información.” http://www.standishgroup.com/chaos.html : “ Las invstigaciones del grupo Standish muestran que 31.1% de los proyectos se cancelarán antes de que se completen. Otros resultados indican que 52.7% de los proyectos costarán 189% de la estimación original. El costo de estas fallas y excesos son sólo la punta del iceberg. Los costos de oportunidades perdidas son inconmensurables, pero podrían llegar a los trillones de dólares. Basta mirar a la ciudad de Denver para darse cuenta del alcanc de este problema. El fracaso en la producción de software confiable para manejar equpaje en el nuevo aeropuerto le está costando a la cuidad US$1.1 millones al día. Basado en esta investigación, The Standish Group estiman que en 1995 compañías y agencias de gobierno de EE.UU. gastarán US$81 billones en proyectos de software cancelados. Y otros US$59 billones en proyectos de software completados, pero que excederán las estimaciones iniciales .&amp;quot;
  18. Ing. Oscar Ascón Valdivia
  19. Ing. Oscar Ascón Valdivia
  20. Ing. Oscar Ascón Valdivia
  21. Ing. Oscar Ascón Valdivia
  22. Ing. Oscar Ascón Valdivia El análisis orientado a objetos es un método de análisis en el cual los requerimientos son expresados en términos de los objetos encontrados en el problema. El análisis se focaliza en el QUE del problema. El diseño orientado a objetos involucra la trasnformación del modelo de análisis en un modelo de diseño refinándolo, agregando detalles y capturando las decisiones de diseño. El diseño agrega el COMO .
  23. Ing. Oscar Ascón Valdivia
  24. Ing. Oscar Ascón Valdivia
  25. Ing. Oscar Ascón Valdivia El proceso que describiremos es genérico: es acomodable a una amplia variedad de dominios de programas y proyectos de distintos tamaños .
  26. Ing. Oscar Ascón Valdivia
  27. Ing. Oscar Ascón Valdivia La fase de comienzo establece la viabilidad de un producto nuevo al punto que los recursos son consignados al proyecto y un plan de proyecto es puesto en su lugar.
  28. Ing. Oscar Ascón Valdivia Aquí el dominio del problema significa el sistema a construir. La elaboración es donde la mayoria de las actividades de análisis son realizadas. El propósito del analisis es entender el problema y el problema debe ser bien entendido antes de entrar en la fase de construcción. La elaboración no puede ser considerada terminada hasta que la fundación de una arquitectura apropiada haya sido establecida de una manera integrada, y haya sido ejecutada exitosamente para probar que lo es para el problema que se tiene entre manos. Note que al comienzo de esta fase, varias exploraciones, folletos del prototipo pueden ser generados para intentar con distintos enfoques a arquitecturas distintas o bien buscando mitigar riesgos específicos. Sin embargo, la elaboarción no estará terminada hasta que la arquitectura haya sido construida, probada, integrada y puesta como linea de base.
  29. Ing. Oscar Ascón Valdivia
  30. Ing. Oscar Ascón Valdivia Durante la elaboración, establecemos el “esqueleto” del sistema. Durante la construcción le ponemos la carne a los huesos.
  31. Ing. Oscar Ascón Valdivia Esta fase puede ser muy simple o muy compleja dependiendo de lo que involucre el producto específico. El nuevo desarrollo de un producto ya existente puede ser muy sencillo. Reemplazar completamente un sistema de rastreo de misiles puede ser muy complejo.
  32. Ing. Oscar Ascón Valdivia La documentación de una iteración prematura significa documentar parte del código -- probablemente no el manual del usuario. Durante las últimas iteraciones la documentación es aplicada hacia el código. La documentación para el usuario también es iterativa -- Ud. no puede hacerla cuando el código ya esta terminado!
  33. Ing. Oscar Ascón Valdivia El riesgo es impredecible; así no todo el riesgo (encontrado) de una iteración es eliminado o reducido. También, pueden aparecer riegos nuevos . Por lo tanto es importante poner al día el plan después de cada iteración.
  34. Ing. Oscar Ascón Valdivia
  35. Ing. Oscar Ascón Valdivia Actividades de análisis y diseño ocurren durante las diferentes fases del ciclo de desarrollo. Aquí el diseño es arquitectura y algunos diseños (nivel bajo) ocurren durante la implementación. Los nombres escogidos para cada fase no provienen de las clásicas actividades de desarrollo tales como análisis y diseño. Los nombres fueron escogidos deliberadamente con el fin de dar énfasis a que estas actividades tienen lugar en grados variados en cada fase e iteración. La figura superior ilustra cómo el énfasis relativo cambia de fase en fase. Note también que el comienzo y fin de las actividades no se igualan a los límites de las fases. El planeamiento tiene lugar en todas las fases. El análisis tiene lugar primeramente en la elaboración de una fase, aunque algún análisis de dominio preliminar pueda ser realizado durante el inicio. El grueso del trabajo de arquitectura es realizado en la fase de elaboración. La implementación incluye pruebas de unidad y ocurre principalmente en las fases de elaboración (elementos arquitectónicos) y construcción. Las actividades de mantenimiento cambian componentes de software después de habes sidos demarcados, i.e., están bajo control de manejo del cambio. De esta manera el mantenimiento comienza de acuerdo a lo establecido en la primera linea base que normalmente ocurre durante la elaboración. Probar y evaluar las actividades demuestra que la linea base del programa se topa con los criterios de evaluación que estan evolucionando y son implementaciones aceptables de la visión del proyecto. El entorno y el manejo de cambio incluyen la integración del entorno de desarrollo y la administración del sistema de manejo de cambio.
  36. El proceso propuesto tiene mucho en común con el modelo de proceso propuesto por Barry Bohem en 1988: “El modelo espiral”. Los cuadrantes de la espiral son: Determinar objetivos, alternativas y restricciones Evaluar alternativas, identificar y resolver riesgos, construir proptotipos Desarrollo y verificación del producto Planificación de las siguientes fases