Está en la página 1de 80

Análisis y Diseño de Sistemas

Ing. Manuel Humberto Valdera García
Sesión 1
Ingeniería de Software
Ingeni erí a de Software
El software se ha incrustado profundamente
en casi todos los aspectos de nuestras vidas y,
como consecuencia, el número de personas
que tienen interés en las características y
funciones que brinda una aplicación
específica ha crecido en forma notable.
Ingeni erí a de Software
Cuando ha de construirse una aplicación
nueva o sistema incrustado, deben
escucharse muchas opiniones. Y en
ocasiones parece que cada una de ellas
tiene una idea un poco distinta de cuáles
características y funciones debiera tener el
software.
Ingeni erí a de Software
Se concluye que debe hacerse un esfuerzo
concertado para entender el problema
antes de desarrollar una aplicación de
software.
Ingeni erí a de Software
• Los requerimientos de la tecnología de la
información que demandan los individuos, negocios
y gobiernos se hacen más complejos con cada año
que pasa. En la actualidad, grandes equipos de
personas crean programas de cómputo que antes
eran elaborados por un solo individuo.
Ingeni erí a de Software
• El software sofisticado, que alguna vez se
implementó en un ambiente de cómputo
predecible y autocontenido, hoy en día se
halla incrustado en el interior de todo, desde
la electrónica de consumo hasta dispositivos
médicos o sistemas de armamento.
Ingeni erí a de Software
• La complejidad de estos nuevos
sistemas y productos basados en
computadora demanda atención
cuidadosa a las interacciones de todos
los elementos del sistema.
Se concluye que el diseño se ha vuelto una
actividad crucial.

Ingeni erí a de Software
• Los individuos, negocios y gobiernos
dependen cada vez más del software
para tomar decisiones estratégicas y
tácticas, así como para sus operaciones y
control cotidianos. Si el software falla,
las personas y empresas grandes pueden
experimentar desde un inconveniente
menor hasta fallas catastróficas.
Se concluye que el software debe tener alta
calidad.
Ingeni erí a de Software
• Estas realidades simples llevan a una
conclusión: debe hacerse ingeniería con el
software en todas sus formas y a través de
todos sus dominios de aplicación. Y esto
conduce a la ingeniería de software.
Ingeni erí a de Software
• Definición: Es el establecimiento y uso de
principios fundamentales de la ingeniería con
objeto de desarrollar en forma económica
software que sea confiable y que trabaje con
eficiencia en máquinas reales.
Ingeni erí a de Software
• Definición: Es la aplicación de un enfoque
sistemático, disciplinado y cuantificable al
desarrollo, operación y mantenimiento de
software; es decir, la aplicación de la ingeniería
al software.
Ingeni erí a de Software
La Ingeniería de software es el establecimiento y uso de principios
robustos de la ingeniería a fin de obtener económicamente software
que sea fiable y que funcione eficientemente sobre máquinas reales.
Ni vel es o capas de l a
Ingeni erí a de Software
La ingeniería de software es una tecnología con varias
capas, como se aprecia en la figura.
Ni vel es o capas de l a
Ingeni erí a de Software
• Cualquier enfoque de ingeniería
(incluso la de software) debe basarse en
un compromiso organizacional con la
calidad. La administración total de la
calidad, en última instancia al
desarrollo de enfoques cada vez más
eficaces de la ingeniería de software. El
fundamento en el que se apoya la
ingeniería de software es el
compromiso con la calidad.
Ni vel es o capas de l a
Ingeni erí a de Software
• El fundamento para la ingeniería de software
es la capa proceso. El proceso de ingeniería
de software es el aglutinante que une las
capas de la tecnología y permite el desarrollo
racional y oportuno del software de cómputo.
El proceso define una estructura que debe
establecerse para la obtención eficaz de
tecnología de ingeniería de software.
Ni vel es o capas de l a
Ingeni erí a de Software
• El proceso de software forma la base para el
control de la administración de proyectos de
software, y establece el contexto en el que se
aplican métodos técnicos, se generan
productos del trabajo (modelos, documentos,
datos, reportes, formatos, etc.), se establecen
puntos de referencia, se asegura la calidad y
se administra el cambio de manera apropiada.
Ni vel es o capas de l a
Ingeni erí a de Software
• Los métodos de la ingeniería de software
proporcionan la experiencia técnica para elaborar
software. Incluyen un conjunto amplio de tareas,
como comunicación, análisis de los
requerimientos, modelación del diseño,
construcción del programa, pruebas y apoyo. Los
métodos de la ingeniería de software se basan en
un conjunto de principios fundamentales que
gobiernan cada área de la tecnología e incluyen
actividades de modelación y otras técnicas
descriptivas.
Ni vel es o capas de l a
Ingeni erí a de Software
 Las herramientas de la ingeniería de software
proporcionan un apoyo automatizado o
semiautomatizado para el proceso y los
métodos. Cuando se integran las herramientas
de modo que la información creada por una
pueda ser utilizada por otra, queda establecido
un sistema llamado ingeniería de software
asistido por computadora que apoya el
desarrollo de software.
Ni vel es o capas de l a
Ingeni erí a de Software
 Las herramientas de la ingeniería de software
proporcionan un apoyo automatizado o
semiautomatizado para el proceso y los
métodos. Cuando se integran las herramientas
de modo que la información creada por una
pueda ser utilizada por otra, queda establecido
un sistema llamado ingeniería de software
asistido por computadora que apoya el
desarrollo de software.
Fas es general es del proces o de
des arrol l o de s of t ware
• Un proceso es un conjunto de actividades,
acciones y tareas que se ejecutan cuando va a
crearse algún producto del trabajo. Una actividad
busca lograr un objetivo amplio (por ejemplo,
comunicación con los participantes) y se desarrolla
sin importar el dominio de la aplicación, tamaño
del proyecto, complejidad del esfuerzo o grado de
rigor con el que se usará la ingeniería de software.
Fas es general es del proces o de
des arrol l o de s of t ware
• Comunicación. Antes de que comience
cualquier trabajo técnico, tiene importancia
crítica comunicarse y colaborar con el
cliente (y con otros participantes). Se busca
entender los objetivos de los participantes
respecto del proyecto, y reunir los
requerimientos que ayuden a definir las
características y funciones del software.
Fases general es del
proceso de desarrol l o
de software
• Planeación. Cualquier viaje complicado se
simplifica si existe un mapa. Un proyecto de
software es un viaje difícil, y la actividad de
planeación crea un “mapa” que guía al equipo
mientras viaja. El mapa —llamado plan del
proyecto de software— define el trabajo de
ingeniería de software al describir las tareas
técnicas por realizar, los riesgos probables, los
recursos que se requieren, los productos del trabajo
que se obtendrán y una programación de las
actividades.
Fases general es del
proceso de desarrol l o
de software
• Modelado. Ya sea usted diseñador de paisaje,
constructor de puentes, ingeniero aeronáutico,
carpintero o arquitecto, a diario trabaja con
modelos. Crea un “bosquejo” del objeto por
hacer a fin de entender el panorama general —
cómo se verá arquitectónicamente, cómo ajustan
entre sí las partes constituyentes y muchas
características más—. Si se requiere, refina el
bosquejo con más y más detalles en un esfuerzo
por comprender mejor el problema y cómo
resolverlo.
Fases general es del
proceso de desarrol l o
de software
• Construcción. Esta actividad combina la
generación de código (ya sea manual o
automatizada) y las pruebas que se requieren para
descubrir errores en éste.

• Despliegue. El software (como entidad completa
o como un incremento parcialmente terminado)
se entrega al consumidor que lo evalúa y que le
da retroalimentación, misma que se basa en dicha
evaluación.
Model o de procesos de
desarrol l o de Software
• Un proceso como la colección de
actividades de trabajo, acciones y tareas
que se realizan cuando va a crearse algún
producto terminado. Cada una de las
actividades, acciones y tareas se encuentra
dentro de una estructura o modelo que
define su relación tanto con el proceso
como entre sí.
Model o de procesos de
desarrol l o de Software
Model o de procesos de
desarrol l o de Software
Model o de procesos de
desarrol l o de Software
Model o de procesos de
desarrol l o de Software
• Modelo de la cascada
Hay veces en las que los requerimientos para cierto
problema se comprenden bien: cuando el trabajo
desde la comunicación hasta el despliegue fluye en
forma razonablemente lineal. Esta situación se
encuentra en ocasiones cuando deben hacerse
adaptaciones o mejoras bien definidas a un sistema
ya existente (por ejemplo, una adaptación para
software de contabilidad que es obligatorio hacer
debido a cambios en las regulaciones
gubernamentales).
Model o de procesos de
desarrol l o de Software
Model o de procesos de
desarrol l o de Software
• Modelo de la cascada
El modelo de la cascada, a veces llamado ciclo de
vida clásico, sugiere un enfoque sistemático y
secuencial para el desarrollo del software, que
comienza con la especificación de los
requerimientos por parte del cliente y avanza a
través de planeación, modelado, construcción y
despliegue, para concluir con el apoyo del software
terminado
Model o de procesos de
desarrol l o de Software
• Modelos de proceso incremental
Hay muchas situaciones en las que los
requerimientos iniciales del software están
razonablemente bien definidos, pero el alcance
general del esfuerzo de desarrollo imposibilita un
proceso lineal. Además, tal vez haya una necesidad
imperiosa de dar rápidamente cierta funcionalidad
limitada de software a los usuarios y aumentarla en
las entregas posteriores de software. En tales casos,
se elige un modelo de proceso diseñado para
producir el software en incrementos.
Model o de procesos de
desarrol l o de Software
Model o de procesos de
desarrol l o de Software
• Modelos de proceso incremental
El modelo de proceso incremental se centra en que
en cada incremento se entrega un producto que ya
opera. Los primeros incrementos son versiones
desnudas del producto final, pero proporcionan
capacidad que sirve al usuario y también le dan una
plataforma de evaluación
Model o de procesos de
desarrol l o de Software
• Modelos de proceso evolutivo
El software, como todos los sistemas complejos,
evoluciona en el tiempo. Es frecuente que los
requerimientos del negocio y del producto cambien
conforme avanza el desarrollo, lo que hace que no
sea realista trazar una trayectoria rectilínea hacia el
producto final; los plazos apretados del mercado
hacen que sea imposible la terminación de un
software perfecto, pero debe lanzarse una versión
limitada a fin de aliviar la presión de la competencia
o del negocio.
Model o de procesos de
desarrol l o de Sof t ware
• Modelos de proceso evolutivo
Hacer prototipos. Es frecuente que un cliente defina
un conjunto de objetivos generales para el software,
pero que no identifique los requerimientos detallados
para las funciones y características.
En otros casos, el desarrollador tal vez no esté seguro
de la eficiencia de un algoritmo, de la adaptabilidad de
un sistema operativo o de la forma que debe adoptar
la interacción entre el humano y la máquina. En estas
situaciones, y muchas otras, el paradigma de hacer
prototipos tal vez ofrezca el mejor enfoque.
Model o de procesos de
desarrol l o de Software
Model o de procesos de
desarrol l o de Software
• El modelo espiral. Propuesto en primer lugar por
Barry Boehm, el modelo espiral es un modelo
evolutivo del proceso del software y se acopla
con la naturaleza iterativa de hacer prototipos con
los aspectos controlados y sistémicos del modelo
de cascada. Tiene el potencial para hacer un
desarrollo rápido de versiones cada vez más
completas.
Model o de procesos de
desarrol l o de Software
Model o de procesos de
desarrol l o de Software
• Modelos concurrentes
El modelo de desarrollo concurrente, en ocasiones
llamado ingeniería concurrente, permite que un
equipo de software represente elementos iterativos y
concurrentes de cualquiera de los modelos de proceso
descritos en este capítulo. Por ejemplo, la actividad
de modelado definida para el modelo espiral se logra
por medio de invocar una o más de las siguientes
acciones de software: hacer prototipos, análisis y
diseño.
Model o de procesos de
desarrol l o de Software
Sesión 2
El paradigma orientado a
objetos, UML y RUP
El RUP
• Rational Unified Process
El Proceso Unificado es un proceso de
software genérico que puede ser utilizado para
una gran cantidad de tipos de sistemas de
software, para diferentes áreas de aplicación,
diferentes tipos de organizaciones, diferentes
niveles de competencia y diferentes tamaños
de proyectos.
Estructura del RUP
RUP y UML
• El Proceso Unificado usa el Lenguaje de
Modelado Unificado (UML) en la
preparación de todos los planos del sistema.
De hecho, UML es una parte integral del
Proceso Unificado, fueron desarrollados a
la par.
Perspecti vas de UML
• UML será el lenguaje de modelado
orientado a objetos estándar predominante
los próximos años.

• Evidencias:
– Herramientas que proveen la notación UML
– “Edición” de libros
– Congresos, cursos, etc.
Perspecti vas de UML
• Evidencias:
–Herramientas que proveen la
notación UML
–“Edición” de libros
–Congresos, cursos, etc.
Model os y Di agramas
• Un modelo captura una vista de un
sistema del mundo real. Es una
abstracción de dicho sistema,
considerando un cierto propósito. Así,
el modelo describe completamente
aquellos aspectos del sistema que son
relevantes al propósito del modelo, y a
un apropiado nivel de detalle.
Model os y Di agramas
• Diagrama: una representación gráfica
de una colección de elementos de
modelado, a menudo dibujada como un
grafo con vértices conectados por
arcos.
Di agramas de UML
 Diagrama de Casos de Uso
 Diagrama de Clases
 Diagrama de Objetos
Diagramas de Comportamiento
 Diagrama de Estados
 Diagrama de Actividad
Diagramas de Interacción
 Diagrama de Secuencia
 Diagrama de Colaboración
Diagramas de implementación
 Diagrama de Componentes
 Diagrama de Despliegue
Di agramas de UML
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
Distribución
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
Los diagramas expresan gráficamente partes de un modelo
Organi zaci ón de
Model os
Propuesta de Rational Unified Process (RUP)
 M. de Casos de Uso del Negocio (Business Use-Case
Model)
 M. de Objetos del Negocio (Business Object Model)
 M. de Casos de Uso (Use-Case Model)
 M. de Análisis (Analysis Model)
 M. de Diseño (Design Model)
 M. de Despliegue (Deployment Model)
 M. de Datos (Data Model)
 M. de Implementación (Implementation Model)
 M. de Pruebas (Test Model)

Paquetes en UML
• Los paquetes ofrecen un mecanismo
general para la organización de los
modelos/subsistemas agrupando
elementos de modelado
• Se representan gráficamente como:
Nombre de
paquete
Paquetes en UML
• Cada paquete corresponde a un submodelo
(subsistema) del modelo (sistema)
• Un paquete puede contener otros paquetes,
sin límite de anidamiento pero cada
elemento pertenece a (está definido en) sólo
un paquete
• Una clase de un paquete puede aparecer en
otro paquete por la importación a través de
una relación de dependencia entre paquetes
Paquetes en UML

UNPSJB - 2005
Di agrama de Casos de
Uso
• Casos de Uso es una técnica para
capturar información de cómo un
sistema o negocio trabaja, o de cómo se
desea que trabaje

• No pertenece estrictamente al enfoque
orientado a objeto, es una técnica para
captura de requisitos
Ingeniería de Software - Clase 6
Di agrama de Casos de
Uso
Supervisor
Verificar Situación del Cliente
Administrativo
Preparar Catálogo
Sistema
Inventario
Tipos de Venta
Ejempl os
UNPSJB - 2005
En el paquete tipos de venta:
Venta Normal
Venta en Rebajas
Venta en Ofertas
Vendedor
Ejempl os
UNPSJB - 2005 Ingeniería de Software - Clase 6 61
Solicitar Nueva Tarjeta
Cliente
Solicitar Préstamo
<<extend>>
[Tarjeta Caducada]
Otro Ejemplo
Ejempl os
Verificar Operación
Reintegro Cuenta Corriente
Cliente
Reintegro Cuenta de Crédito
<<include>>
<<include>>
Di agrama de Secuenci a

UNPSJB - 2005
: Encargado
:WInPréstamos :Socio :Video :Préstamo
prestar(video, socio)
verificar situación socio
verificar situación video
registrar préstamo
entregar recibo
Di agrama de
Col aboraci ón
: Encargado
:WInPréstamos
:Socio
:Video
:Préstamo
1: prestar(video, socio)
2: verificar situación socio
3: verificar situación video
4: registrar préstamo
5: entregar recibo
Di agrama de Cl ases
• El Diagrama de Clases es el
diagrama principal para el análisis
y diseño.

• Un diagrama de clases presenta
las clases del sistema con sus
relaciones estructurales y de
herencia.
UNPSJB - 2005
Di agrama de Cl ases
• La definición de clase incluye
definiciones para atributos y
operaciones.

• El modelo de casos de uso aporta
información para establecer las clases,
objetos, atributos y operaciones.
UNPSJB - 2005
Ejempl os
(Clase y Visibilidad)
Ejempl os
Asociación
Profesor Departamento
1 0..1
director
1
dirige
0..1
Ejempl os (Cl ase
Asoci aci ón)
69
Empresa Empleado
1..* * 1..* *
trabajadores empleador
Cargo
nombre
sueldo
0..1
1..*
superior
subordinado
1..*
0..1
Ejempl os
(General i zaci ón)
Trabajador
Directivo Administrativo Obrero
{ disjunta, completa }
Ejempl os

Avión militar
Avión comercial
Avión de carga Avión de pasajeros
Motor Vendedor de billetes
Avión
1..4
1
1..4
1
Piloto
Reserva
n
1
n
1
Línea aérea
Vuelo
n 1 n 1
1..2
n
1..2
n
n 1 n 1
1
n
1
n
{ disjunta, completa }
{ disjunta, completa }
Di agrama de Estados

con préstamos
sin préstamos
alta baja
prestar devolver[ número_préstamos = 1 ]
prestar
devolver[ número_préstamos > 1 ]
número_préstamos = 0
número_préstamos > 0
Socio
número : int
nombre : char[50]
número_prestamos : int = 0
alta()
baja()
prestar(código_libro : int, fecha : date)
devolver(código_libro : int, fecha : date)
Di agrama de Acti vi dad

Buscar Bebida
Poner café en filtro Añadir agua al depósito Agarrar taza
Poner filtro en máquina
Encender máquina
Café en preparación
Servir café
Agarrar zumo
Beber
[no hay café]
[hay café
[no zumo]
[hay zumo]
/ cafetera.On
indicador de fin
… Otro Ejempl o ( con
swi m l i nes)
Emitir billete
Pasajero
Vendedor Airline
Solicitar pago Reservar plazas
Confirmar
plaza reservada
Pagar pasaje
Informar alternativas
y precios
Verificar
existencia vuelo
Dar detalles vuelo
Solicitar pasaje
Seleccionar vuelo
Di agrama Componentes
Control y Análisis
Comment
Acceso a BD
Comment
Rutinas de Coneccion
Comment
Interf az de Terminal
Comment
Gestión de Cuentas
Comment
Di agrama de Despl i egue
76
Punto de Venta
Servidor Central
Terminal de Consulta
Gestión de Cuentas
Comment
Interfaz de Terminal
Comment
Rutinas de Coneccion
Comment
Rutinas de Coneccion
Comment
Interfaz de Terminal
Comment
Rutinas de Coneccion
Comment
Acceso a BD
Comment
Control y Análisis
Comment
Resumen
• UML define una notación que se expresa como
diagramas sirven para representar
modelos/subsistemas o partes de ellos
• El 80 por ciento de la mayoría de los
problemas pueden modelarse usando alrededor
del 20 por ciento de UML-- Grady Booch

¿Por qué l a Ori entaci ón
a Objetos?
• Proximidad de los conceptos de modelado
respecto de las entidades del mundo real
– Mejora captura y validación de requisitos
– Acerca el “espacio del problema” y el “espacio
de la solución”
• Modelado integrado de propiedades
estáticas y dinámicas del ámbito del
problema
– Facilita construcción, mantenimiento y
reutilización
Probl emas en OO
“...Los conceptos básicos de la OO se conocen
desde hace dos décadas, pero su aceptación
todavía no está tan extendida como los
beneficios que esta tecnología puede sugerir”
“...La mayoría de los usuarios de la OO no
utilizan los conceptos de la OO de forma
purista, como inicialmente se pretendía. Esta
práctica ha sido promovida por muchas
herramientas y lenguajes que intentan utilizar
los conceptos en diversos grados”
79
• Tarea

Hacer un informe explicando las ventajas y
desventajas de los modelos de proceso de
software analizados en clase.