INGENIERIA DE SOFTWARE 2012

906 views

Published on

UN RESUMEN DE INGENIERIA DE SISTEMAS ESTO SI ES LO QUE HACE UN INGENIERO DE SISTEMAS ... SISTEMAS ... HACE PROGRAMAS DE SOFTWARE.

Published in: Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
906
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

INGENIERIA DE SOFTWARE 2012

  1. 1. ING. DE SOFTWARE DIEGO ALVARES MARZO-2013
  2. 2. CONCEPTOS • ING. DE SOFWARE • PROCEDIMIENTO DE SOFTWARE • MEDELADO PROCESAMIENTO DE SW • MODELADO CICLICO DE VIDA • METODOLOGIA DE ING. SW • PRINCIPIO DE ING.
  3. 3. PROCESO SOFTWARE ANALISIS PRUBAS Y ENTREGACODIFICACIONDISEÑO Doc. Requisitos Doc. Modelado Código Plan de pruebas y Plan de Entrega M. FUNCIONAL M .ESTRUCTURAL M. COMPORTAMIENTO M. ARQUITECUTRA M. DETALLADO
  4. 4. PROCESO • Tiene: – PROCEDIMIENTOS=>pasos para d/ actividades completas, algoritmos. – METODOS=>forma de abordar un proceso: orientado a objetos oobj (java), orientado a aspectos, oa Asp y procedural c++, orientado a eventos (vb). – HERRAMIENTAS=>facilitan el proceso, CASE, ING. DE SW asistida por computador. Enterprice Architect.
  5. 5. UML • Es el lenguaje de modelado unificado. • CASE, genera código en java. • Interfaz de lenguaje de representación de modelos de sw. • Es un conjunto de símbolos que se integra en diagramas y estos diagramas incluyen mensajes los cuales sirven medio de comunicación de sw. • CREADORES: BOOCH, JACOBSON Y RUMBEUCH, Unificaron los lenguajes de uml, objetory y OMT. .
  6. 6. MODELO CICLO DE VIDA • CICLO DE VIA: es la descripción técnica de un sw desde que nace hasta que muere. f al lo s Tiempo Codificación Desarrollo Entrega uso Muerte
  7. 7. PRINCIPIOS DE ING. DE SW • ABSTRACCIÓN • ACOPLAMIENTO Y COHESION • DESCOMPOSICION Y MODULARIZACION • ENCAPSULAMIENTO Y OCULTAMIENTO DE INFORMACIÒN • REUTILIZACIÓN.
  8. 8. ABSTRACCIÓN • Habilidad para leer la realidad y transformarla en un modulo util y dar solución. • Especifica el problema a resolver
  9. 9. ACOPLAMIENTO Y COHESION • Divide y vencerás. • Soluciones s1,s2,s3. • Módulos de solución. • Descomponer en problemas/Subproblemas. S5 S3 S2 S1
  10. 10. MODULARIZACION • Hacer bloques de solución • Que solucionen un subproblema especifico. • Cada bloque es un modulo. • Mejor -Acoplamiento +cohesion (calidad ) • Acoplamiento es modulo + indepediente posible.
  11. 11. COHESION • ES el Nivel de integración. • Interfaces ínter modulares: son partes de sw que integran los módulos. • Resuelve el problema de REUTILIZACION
  12. 12. REUTILIZACION • Es adaptar sw o adaptar para volver a utilizar. BIBLITECA ARQUITECTURA DE SW MODELO A DESARROLLO EXISTE MODELO NO EXISTE MODELO
  13. 13. REUTILIZACION • SIRVE PARA AHORRAR TIEMPO Y TRABAJO Y DINERO. REUTILIZAR MODELOS ANALISIS DISEÑO CODIGO ENTREGA PRUEBA
  14. 14. DIAGRAMAS • ESTRUCTURALES. • DINAMICOS. • UML por perspectivas: – Estructural=> clases, objetos – Funcional=>Casos de uso, Actividades – Dinámica y comportamiento=>Estados – Implementación=>Despliegue.
  15. 15. DE SW ING. • METODOS DE ANALISIS – MODELO FUNCIONAL. – MODELO ESTRUCTURAL. – MODELO COMPORTAMENTAL. METODOS DE DISEÑO: D. ARQUITECTURA D. DETALLADO
  16. 16. ING. DE SOFTWARE • LEER SWEBOOK, CUERPO DE CONOCIMIENTO SW. – ELEMENTOS: • ING SW • DISEÑO • CONSTRUCCION • PRUEBAS • MANTENIMIENTO
  17. 17. ING DE REQUISISTOS • HAY DOCUMENTO DE REQUISITOS FUNCIONALES, ESTRUCTURALES Y DE ANALISIS • NEGOCIO DE LA EMPRESA. • EJEMPLOS: REQUSISTOS FUNCIONALES, DE CALIDAD, NO FUNCIONALES.
  18. 18. ANALISIS • MODELO FUNCIONAL: – REQUISITOS: CASOS DE USO – TIPOS: • FUNCIONAL=>ALGO QUE DEBE HACER SW • CALIDAD=> COMO DESARROLLAR REQ. FUN. • INFORMACION=> ALMACEN INFO.
  19. 19. ACTORES • Cualquier ente que interactúa con el SW. – Personas, grupo de personas, empresa u otro Sw. • Definir Requisitos: – Cada requisito tiene un Diagrama de Casos de Uso.
  20. 20. CASOS DE USO • SON UN CONJUNTO DE ACCIONES A REALIZAR. • RELCIONES ENTRE CASOS DE USO: ASOCIACION. • MODELO FUNCIONAL: – DETALLAR CASOS DE USO • IDENTIFICAR ELEMENTOS AYUDEN A DESCRIBIR CASOS DE USO.
  21. 21. MODELO FUNCIONAL • ENCONTRAR CASOS DE USO: – INCLUIDO – EXCLUIDO: Relaciones casos de uso. 1. DEFNIR OPERACIONES DEL SISTEMA. (actividades de caso de uso) 2. INTERFAZ DE USUARIO. 3. PRIORIZAR CASOS DE USO.
  22. 22. CASOS DE USO DETALLADO • IDENTIFICAR CODIGO • TITULO • ACTOR • REQ FUNCIONAL • PRECONDICIONES • RELACIONES • FLUJO DE EVENTOS • REQ, NO FUNCIONALES
  23. 23. CASOS DE USO DETALLADO • SECUENCIAS POSCONDICIONES. • DIAGRAMAS DE FLUJO RD  RD  FLUJO ALTERNO
  24. 24. CASOS DE USO • CASOS DE USO CAJERO DINERO USAR SOBREGIRO AUTENTIFICAR extends autentificar
  25. 25. ESCENARIO • Rutas donde se mezclan datos: • Casos de prueba. CASOS DE PRUEBA No Estados FB FA1 FA2 FA3 1 X 2 X X 3 X X 4 X X
  26. 26. ESCENARIO • Rutas donde se mezclan datos: • Casos de prueba. CASO DE PRUEBA ESENARIO CONDICION RESULTADO CP1 ES1 PASO1 CP2 ES2 PASO2 CP3 ES4 PASO2 CP4 ES1 PASO3
  27. 27. PLANTILLA • C 0001 Prestar Servicio • FB 1. Operador abre ventana 2. El sistema ejecuta consultar cliente 3. El sistema ejecuta el CU 06 , Identificar taxi. 4. El operador asigna el taxi. De los contraria registra en lista de espera 5. El sistema ejecuta el CU 06 Registrar Servicio. 6. C001 termina. FLUJO DE EXCEPCION • 1.A Usuario No Admitido – Bloquear acceso, – sistema Reporte log. • 5.A Problemas De Comunicación: – -Lista De Espera
  28. 28. ING DE SW • DOCUMENTOS DE LA ING. DE SW ING DE REQUISITOS ANALISIS Y DISEÑO DOCUMENTO DE REQUISITOS DOCUMENTO DE ANALISIS Y DISEÑO
  29. 29. MODELO ESTRUCTURADO Nombre Atributos Métodos • Modelo Estructural Del Análisis. Define y detalla las partes de SW. • Diagrama UML. • Niveles de Abstracción: – D.C Conceptual. – D.C Diseño. – D.C Implementación.
  30. 30. CLASES Clase es una abstracción general de la realidad (contiene inf.), es diferente a un objeto físico (contiene inf.). NOMBRE NOMBRE ATRIBUTOS METODOS NOMBRE ATRIBUTOS ANALISIS DISEÑO IMPLEMENTACION NOMBRE (OBLIGTORIO) NOMBRE ATRIBUTOS (OBLIGTORIO) NOMBRE ATRIBUTOS METODOS (OBLIGTORIO)
  31. 31. LISTA DE CONCEPTOS • Concepto algo que se puede definir, mediante atributos, operaciones y métodos. • Ejemplo: – Taxi – Servicio – Tarifa – Conductor – Consulta
  32. 32. LISTA DE CONCEPTOS • IDENTIFICACION DE CONCEPTOS RELACIONADOS. TAXI SERVICIO CLIENTE TARIFA CONSULTA CONDUCTOR TAXI X X X - X X SERVICIO X X X X X - CLIENTE X X X - X - TARIFA - X X X - - CONSULTA X X - - X - CONDUCTOR X X - - - X
  33. 33. DIAGRAMA CLASES RELACIONES TX S LA RELACION ENTRE DOS CLASES SE DA SIEMPRE DE IZQUIERDA A DERECHA Y DE ARRIBA HACIA ABAJO.
  34. 34. DIAGRAMA CLASES RELACIONES TX S CLIE TF CD CON
  35. 35. DIAGRAMA CLASES ELIMINACION CICLOS TX, CLIE, S TX S CLIE TF CDCON
  36. 36. DIAGRAMA CLASES RELACIONES ELIMINACION CICLOS TX, CLIE, S, TF TX S CLIE TF CDCON
  37. 37. DIAGRAMA CLASES RELACIONES CARDINALIDAD • Cardinalidad, análisis de relación en términos numéricos. • Se lee para 1 C1 cuantos C2 • Se lee para 1 C2 cuantos C1. • Depende de la Regla del Negocio. TX S CLIE TF CDCON 1...* 1...* 1 1...* 1 1 1 1...* 1...* 1…* [ O OPCIONAL ] ---- [ | OBLIGATORIO QUE EXISTA ]
  38. 38. DIAGRAMA CLASES RELACIONES CARDINALIDAD • O = OPCIONAL • | = OBLIGATORIO QUE EXISTA • En El Documento se muestra los resultados finales. • Si no hay flechas la Relación es Bidireccional. Cliente Vendedor
  39. 39. DIAGRAMA CLASES EPECIALES • ENTIDAD=> modela información y comportamiento. • FRONTERA=> interfaz. • CONTROL=> Responsabilidad.
  40. 40. ARQUITECTURA DE SOFTWARE • Como se organizan las partes de SW y como interactúan. • TIENE 3 CAPAS: – Presentación=> interactua con el entorno, interfaz. – Lógica control=>permite comunicación entre interfaz y persistencia. – Persistencia=>almacenar informacion entidad , Bases de datos. Presentación Lógica Control Persistencia
  41. 41. ARQUITECTURA DE SOFTWARE Etiqueta Símbolo Interfaz <<Boundary>> Frontera lógica <<Control>> persistencia <<Entity>> Capa Elemento
  42. 42. RELACION ENTRE CLASES HERENCIA PERSONA DIRECCION TELEFONO DOCENTE Cedula Liquidar _ salario() ESTUDIANTE Código Matricula() • Una clase puede ser una superclase que contenga a otras clases que comparten atributos.
  43. 43. CARACTERIZACION HERENCIA • Una herencia puede ser Disyunta o No Disyunta. • Disyunta si z € A , z no pertenece ni a ( C,B) • No Disyunta si un objeto puede pertenecer a diferentes clases hermanas. • Completa si todas las clases son subclases de otra. • Incompleta si no es asi. X B w A z C y
  44. 44. RELACION AGREGACION • Es cuando la parte puede existir independientemente del todo. PC CPU MONITOR TECLADO MAUSE
  45. 45. RELACION COMPOSICION • Es cuando la parte NO puede existir independientemente del todo. PAIS DEPARTAMENTO CIUDAD
  46. 46. MODELO DE COMPORTAMIENTO • Integra el Modelo Funcional y el Modelo Estructural. • Que partes desarrolla que funciones. • Representación del Diagrama de Comportamiento. – D. de Secuencia II Nivel. – D. de Comunicaciones. • Estereotipos de clases – Frontera- Interfaz – Control – Entidad
  47. 47. DEFINIR OPERACIÓNES DEL SISTEMA • Se parte de la descripción del flujo de evento para un caso de uso. • Representar acciones interacción usuario- Sistema. • Detallar parámetros involucrados c/d mensaje. • Diagrama de interacción, secuencia de eventos.
  48. 48. DIAGRAMAS DE SECUENCIA • I NIVEL • Interacción del sistema, (Caja Negra) USUARIO SISTEMA ACCESO (Cuenta clave) Mensaje Autenticar usuario Acceso a (x)
  49. 49. DIAGRAMAS DE SECUENCIA II NIVEL (Análisis Y Diseño) Control Entidad ACCESO (Cuenta clave) Mensaje Acceso a (x) USUARIO Interfaz ACCESO (Cuenta clave) Mensaje Acceso a (x) ACCESO (Cuenta clave)
  50. 50. DEFINIR INTERFAZ • Interfaz es una presentación para recibir y presentar los datos. • PRIORIZAR CASOS DE USO. – Dar importancia a cada C.U – Determinar su Jerarquia.

×