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

1. ING. DE SOFTWARE
DIEGO ALVARES
MARZO-2013

2. CONCEPTOS
• ING. DE SOFWARE
• PROCEDIMIENTO DE SOFTWARE
• MEDELADO PROCESAMIENTO DE SW
• MODELADO CICLICO DE VIDA
• METODOLOGIA DE ING. SW
• PRINCIPIO DE ING.

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. 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. 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. 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. PRINCIPIOS DE ING. DE SW
• ABSTRACCIÓN
• ACOPLAMIENTO Y COHESION
• DESCOMPOSICION Y
MODULARIZACION
• ENCAPSULAMIENTO Y
OCULTAMIENTO DE INFORMACIÒN
• REUTILIZACIÓN.

8. ABSTRACCIÓN
• Habilidad para leer la realidad y
transformarla en un modulo util y dar
solución.
• Especifica el problema a resolver

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. 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. 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. REUTILIZACION
• Es adaptar sw o adaptar para volver a
utilizar.
BIBLITECA
ARQUITECTURA DE SW
MODELO A
DESARROLLO
EXISTE
MODELO
NO EXISTE
MODELO

13. REUTILIZACION
• SIRVE PARA AHORRAR TIEMPO Y
TRABAJO Y DINERO.
REUTILIZAR
MODELOS
ANALISIS
DISEÑO
CODIGO
ENTREGA
PRUEBA

14. DIAGRAMAS
• ESTRUCTURALES.
• DINAMICOS.
• UML por perspectivas:
– Estructural=> clases, objetos
– Funcional=>Casos de uso, Actividades
– Dinámica y comportamiento=>Estados
– Implementación=>Despliegue.

15. DE SW ING.
• METODOS DE ANALISIS
– MODELO FUNCIONAL.
– MODELO ESTRUCTURAL.
– MODELO COMPORTAMENTAL.
METODOS DE DISEÑO:
D. ARQUITECTURA
D. DETALLADO

16. ING. DE SOFTWARE
• LEER SWEBOOK, CUERPO DE
CONOCIMIENTO SW.
– ELEMENTOS:
• ING SW
• DISEÑO
• CONSTRUCCION
• PRUEBAS
• MANTENIMIENTO

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. ANALISIS
• MODELO FUNCIONAL:
– REQUISITOS: CASOS DE USO
– TIPOS:
• FUNCIONAL=>ALGO QUE DEBE HACER SW
• CALIDAD=> COMO DESARROLLAR REQ. FUN.
• INFORMACION=> ALMACEN INFO.

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. 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. 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. CASOS DE USO DETALLADO
• IDENTIFICAR CODIGO
• TITULO
• ACTOR
• REQ FUNCIONAL
• PRECONDICIONES
• RELACIONES
• FLUJO DE EVENTOS
• REQ, NO FUNCIONALES

23. CASOS DE USO DETALLADO
• SECUENCIAS POSCONDICIONES.
• DIAGRAMAS DE FLUJO
RD

RD

FLUJO
ALTERNO

24. CASOS DE USO
• CASOS DE USO CAJERO
DINERO
USAR SOBREGIRO
AUTENTIFICAR
extends
autentificar

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. 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. 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. 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. 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. 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. LISTA DE CONCEPTOS
• Concepto algo que se puede definir,
mediante atributos, operaciones y
métodos.
• Ejemplo:
– Taxi
– Servicio
– Tarifa
– Conductor
– Consulta

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. DIAGRAMA CLASES
RELACIONES
TX S
LA RELACION ENTRE DOS CLASES SE DA
SIEMPRE DE IZQUIERDA A DERECHA Y DE
ARRIBA HACIA ABAJO.

34. DIAGRAMA CLASES
RELACIONES
TX
S
CLIE
TF
CD
CON

35. DIAGRAMA CLASES
ELIMINACION CICLOS TX, CLIE, S
TX
S
CLIE
TF
CDCON

36. DIAGRAMA CLASES
RELACIONES
ELIMINACION CICLOS TX, CLIE, S, TF
TX
S
CLIE
TF
CDCON

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. 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. DIAGRAMA CLASES
EPECIALES
• ENTIDAD=> modela información y
comportamiento.
• FRONTERA=> interfaz.
• CONTROL=> Responsabilidad.

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. ARQUITECTURA DE SOFTWARE
Etiqueta Símbolo
Interfaz <<Boundary>>
Frontera
lógica <<Control>>
persistencia <<Entity>>
Capa
Elemento

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. 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. RELACION AGREGACION
• Es cuando la parte puede existir
independientemente del todo.
PC
CPU
MONITOR
TECLADO
MAUSE

45. RELACION COMPOSICION
• Es cuando la parte NO puede existir
independientemente del todo.
PAIS
DEPARTAMENTO
CIUDAD

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. 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. DIAGRAMAS DE SECUENCIA
• I NIVEL
• Interacción del sistema, (Caja Negra)
USUARIO SISTEMA
ACCESO
(Cuenta clave)
Mensaje
Autenticar
usuario
Acceso a (x)

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. 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.