Introduccin a la Ingeniera de Software.

- Camila Gimnez
Resumen: Ingenieria de Software.............................................................................................3
1- Qu es la ingeniera de software?..................................................................................3
2- Modelado del proceso.....................................................................................................3
3- Planificacin y gerencia de proyecto.............................................................................10
3.1- WBS(Work Breakdown Structure ).........................................................................10
3.1.1- Diagramas WBS...............................................................................................10
4- Estimaciones..................................................................................................................11
4.1- Mtricas de Tamao................................................................................................11
4.1.1- Locs (Lines of Code)........................................................................................11
4.1.2- Punto de Funcion (Capitulo 18.2 de Software Estimation).............................11
4.2- Tecnicas de Estimacion...........................................................................................15
Estimaciones basadas en Proxies...............................................................................15
Juicio de Expertos......................................................................................................16
Estimacin por Analoga............................................................................................16
Mtodos Algortmicos (COCOMO)...........................................................................16
Mtodos basados en Aprendizaje Automatizado........................................................17
5- Requisitos......................................................................................................................17
5.1- Proceso de Requisitos.............................................................................................17
5.2- Definiciones............................................................................................................17
5.3- Obtencion de requerimientos (1er paso de las actividades)....................................18
5.4- Tcnicas para la obtencin de Requisitos...............................................................18
1- Entrevista Individual/Grupal:.................................................................................19
2- Encuesta/Cuestionario............................................................................................19
3- Observacion/Participacion.....................................................................................19
4- Tormenta de ideas:.................................................................................................19
5- Casos de Uso:.........................................................................................................20
6- Prototipos:..............................................................................................................20
Anlisis de requerimientos (2er paso de las actividades)...............................................20
5.5- Redes de Petri (ppts 2)............................................................................................20
5.6- Casos de Uso (ppts 3)..............................................................................................20
Definiciones................................................................................................................21
Forma de encontrar los Casos de uso:........................................................................21
Relaciones entre CU Include...................................................................................22
Relaciones entre CU Extend....................................................................................23
Relaciones entre CU Generalizacion.......................................................................24
5.7- UML (ppts 4)...........................................................................................................25
6- Diseo de la Interfaz de Usuario (IU)...........................................................................28
7- Diseo............................................................................................................................28
8- Diseo del sistema (Arquitectura de Software).............................................................29
8.1 Estilos de Software...................................................................................................29

Introduccin a la Ingeniera de Software.- Camila Gimnez

Introduccin a la Ingeniera de Software.- Camila Gimnez

Resumen: Ingenieria de Software

1-

Qu es la ingeniera de software?
Def: 1) Aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo,
operacin y mantenimiento de software, esto es, la aplicacin de a ingeniera de
software.
2) (IEEE 90) El estudio de enfoques como en 1)

2-

Modelado del proceso

Modelo en Cascada:

Ventajas:
Introdujo el orden en el modelado de procesos de software.
Desventajas:
Error en etapas tardias del proyecto en cuanto a requerimientos es muy caro.
No se utiliza en la vida real.
Variacion: Modelo en cascada con prototipos

Introduccin a la Ingeniera de Software.- Camila Gimnez

Ventajas:
En las estapas tempranas del proyecto se hacen prototipos de forma de validar los
requerimientos y diseo del proyecto.
Errores en etapas tempranas no cuestan tan caros.
Desventajas:
Sigue siendo secuencial, lo cual no es bueno para el paralelismo de tareas.
Modelo en V

Ventajas:
Se saca ventaja de que cada etapa del diseo tiene una contraparte en pruebas. Por lo tanto
se inicializa el testing en las primeras etapas de diseo pudiendo verificar y validar al
comienzo reduciendo el impacto de errores en diseo.
Desventajas:
No contempla la posibilidad de retornar a etapas inmediatamente anteriores??

Introduccin a la Ingeniera de Software.- Camila Gimnez

Modelo de Prototipacion

Especificacion Operacional

Ventajas:

Introduccin a la Ingeniera de Software.- Camila Gimnez

Se valida con el cliente mediante prototipos
Existe retroalimentacin gracias a los prototipos.
Ayuda al desarrollador de software y al cliente a entender de mejor manera cul ser el
resultado de la construccin cuando los requisitos estn satisfechos.
Desventajas:
Si los prototipos no son evolutivos quizas se gasta mucho tiempo en los mismos para luego
descartarlos.
En pos de desarrollar rpidamente el prototipo, el desarrollador suele tomar algunas
decisiones de implementacin poco convenientes
Modelo Transformacional (:O !)

Desarrollo en Fases
*) Con liberaciones parciales

Introduccin a la Ingeniera de Software.- Camila Gimnez

Ventajas:
Se le presenta al cliente liberaciones parciales del producto o de partes de el.
Existe retroalimentacin de los usuarios.
Desventajas:
Gasto de tiempo separar el producto en partes que sean utilizables, no siempre es posible.
Variaciones: con evaluaciones parciales
El producto no es liberado para la produccin, solo se les da a los usuarios en varias etapas
evaluaciones para verificar y validar.
Modelo Incremental Iterativo
Ventajas:
Permite al desarrollador sacar ventaja de lo que se ha aprendido a lo largo del desarrollo
anterior, incrementando, versiones entregables del sistema.
Desventajas:
No sirve para proyectos grandes, retroalimentacin muy lenta.
Modelo Espiral

Ventajas:
Introduce el factor de Riesgo.
Reduce riesgos del proyecto
Incorpora objetivos de calidad
Integra el desarrollo con el mantenimiento.
Desventajas:
Planificar un proyecto con esta metodologa es a menudo imposible, debido a la
incertidumbre en el nmero de iteraciones que sern necesarias.
Genera mucho tiempo en el desarrollo del sistema
7

Introduccin a la Ingeniera de Software.- Camila Gimnez

Modelo costoso
Herramientas y Tcnicas para el Modelado de Procesos
Definiciones Previas:
Un modelo de ciclo de vida de desarrollo de software descriptivo documenta el
proceso pasivamente, desde el punto de vista de un observador. Son muy tiles como
base de conocimiento y mejora de procesos de desarrollo de software.
Un modelo prescriptivo describe el proceso en trmino de los jugadores
involucrados, la secuencia de actividades, y el producto final.
Al modelo descriptivo se lo puede traducir en uno o ms modelos prescriptivos, y a
stos se los pone en accin.

ETVX (Entry task verification exit)

Se tiene personas asignadas a tareas, las tareas a su vez tiene condiciones necesarias para
poder cumplirla y cuando se considera terminada asi como las pruebas necesarias para
considerarla terminada.
Abdel-Hamid
Es un modelo Prescriptivo que muestra la relacion entre factores que pueden resultar
relevantes a la hora de planificar o controlar la ejecucin de un proyecto de software.

Introduccin a la Ingeniera de Software.- Camila Gimnez

Lai
(no hay nada!)
Lleva los siguientes documentos:
Tablas de estado muestran informacin referida a cun completo est un artefacto en
un instante dado
Tablas de estado muestran cmo puede operar el proceso sobre los artefactos
Diagramas de transicin de estado muestran cmo se relacionan unos estados con
otros (mquina de estados compuestos)
Formularios para definir cada tipo de elemento (en los que se especifican las
relaciones)

Introduccin a la Ingeniera de Software.- Camila Gimnez

Planificacin y gerencia de proyecto

3-

3.1- WBS(Work Breakdown Structure )

Definiciones:
Entregable:
Cualquier resultado/item tangible, verificable que tiene q ser producido para
completer un proyecto. El mismo no tiene por que ser un entregable para el cliente,
puede ser solo tener el item terminado.
Hito:
Un Hito es un punto en el tiempo que marca el inicio o el fin de una actividad.

Es una descomposicin jerrquica, orientada al producto entregable, del trabajo

necesario para lograr los objetivos del proyecto y crear los entregables requeridos.
La descomposicin de las tareas se basa en la subdivisin de los productos entregables
en componentes ms pequeos y fciles de manejar.
Objetivo principal: Asegurarse que se tienen todas las actividades necesarias
contempladas, asi como que todas las que estan sean verdaderamente necesarias.
Asiste a los stakeholders del proyecto a tener una clara vision del producto y del
proyecto en general q se va a llevar a cabo.
Los niveles mas altos del WBS reflejan los mayores entregables del proyecto.
No se puede realizar en caso q la planificacin sea gradual

3.1.1- Diagramas WBS

1- Grafo de Actividades (CMP)
Es un modelo que incluye tiempos y presedencias. Los nodos del Grafo son las actividades
del WBS.
A cada nodo se le asocia: Comienzo y fin temprano, Comienzo tardio y fin tardio asi como
la Holgura Total.
Todo esto es a fin de calcular el camino critico y asi ver cuales son las tareas q si se atrasan,
atrasan el proyecto(holgura total=0).
2- Pert
Es como CPM pero la duraciones variables aleatorias de distribucin y se trabaja con el
valor esperado. Se hacen tres estimaciones: optimista, pesimista y mas probable.

10

Introduccin a la Ingeniera de Software.- Camila Gimnez

3- Gantt
Su objetivo es mostrar el tiempo de dedicacin previsto para diferentes tareas o actividades a
lo largo de un tiempo total determinado (tiempo del proyecto).
4-

Estimaciones

Una estimacion es una prediccion, en el ambito del software nos referimos a estimaciones en
cuanto al tiempo y/o costo de un proyecto.
En el software ocurre un fenomeno llamado:
Deseconoma de escala. El Esfuerzo crece exponencialmente con tamao, en proyectos de
diferente tamao no se puede multiplicar por la misma productividad.
4.1- Mtricas de Tamao
4.1.1- Locs (Lines of Code)
Mide el costo del proyecto en lneas de cdigo.
Ventajas:
-Fcil de medir
Desventajas:
-depende del lenguaje
-depende del personal
-el programa debe estar terminado para poder contar.
-diseo, requerimiento y testing no generan locs
4.1.2- Punto de Funcion (Capitulo 18.2 de Software Estimation)
Utilizado para estimar el tamao de un programa en etapas temprano del proyecto.
El punto de Funcion se calcula de la siguiente manera:
PF =

PFSA

Factor de Ajuste

Donde: - PFSA son las transacciones + los datos.

-El factor de ajuste viene dado en tablas
Se asume que la complejidad de un programa se basa en la complejidad de los siguientes
items:

11

Introduccin a la Ingeniera de Software.- Camila Gimnez

Internal Logical Files (ILF): Archivos, data o informacin de control que estn
completamente controlados por el programa. (ej. Una tabla de la base de datos).

External Interface Files (EIF): Archivos controlados por otros programas con el que
nuestro programa en cuestin debe interactuar.
OBS: Un EIF para una aplicacin tiene que ser un ILF para alguna otra.

External Inputs (EI): El usuario final agrega, cambia o borra datos del programa.
Modifica al menos un ILF as como podra alterar el estado del sistema.

External Outputs(EO): proceso en el que datos derivados a partir de uno o ms ILF o

EIF cruzan la frontera de adentro hacia fuera. Puede alterar el estado del sistema as
como un ILF.

External Queries (EQ): Es una consulta que realiza el programa que se hace visible para
el usuario, los datos que cruzan la frontera NO son derivados. Se muestran tal cual est.
NO altera el estado del sistema ni de ningun ILF.

Ventajas de los PF:

Se puede medir sin que exista el cdigo (a partir de la documentacin de
requerimientos y/o diseo)
Son independientes del lenguaje de programacin
Desventajas de los PF:
Medir PF requiere esfuerzo
Variabilidad en mediciones individuales(Medidores expertos)
Criticado por Factores de Ajuste (FA):
- Demod (Dependientes del momento tecnolgico)
- Los FA elegidos son independientes entre si?
- Si uso PF para estimar tamao y luego esfuerzo corro el riesgo
aplicar 2 veces el mismo ajuste

12

Introduccin a la Ingeniera de Software.- Camila Gimnez

Rojo: SI!,
Amarillo: En una columna uno al menos tiene que ser SI!
Azul: NO!
P: posible

EO,EQ,EI son Procesos elementales, esto quiere decir es una minima unidad de actividad
(debe dejar al sistema en un estado consistente)que tiene significado para el usuario.
Frontera de la Aplicacin
Define lo que es externo a la aplicacin
Interfaz entre lo interno y el mundo exterior
Se puede concebir como una membrana que atraviesan los datos procesados por las transacciones
(EI,EO,EQ)
Incide en la cuenta total de PF (Al partir una aplicacin se incrementan los PF totales porque los ILF
se cuentan 1 vez como tales, por lo menos, y tambin se cuentan como EIF )
Se determina a partir de la visin de usuario basada en reas funcionales separadas y NO en
consideraciones tcnicas

Como contar la contribucin de las Transacciones?

Definiciones previas:
Data Element Type (DET): es un campo nico (no repetitivo) reconocible por el usuario
File Type Referenced (FTR): es un tipo de archivo al que se hace referencia en una
transaccin; tiene que ser un ILF o EIF.

13

Introduccin a la Ingeniera de Software.- Camila Gimnez

Pasos:
Identificar transacciones
Asignar a cada una un tipo (EI, EO, EQ)
Identificar la cantidad de DETS de cada transaccin:
Contar un DET por: (NO CONTAR SI NO CRUZA LA FRONTERA!)
cada campo reconocible por el usuario, no repetido, que entra o sale de la
aplicacin.
la posibilidad de que el sistema enve un mensaje fuera de la frontera de la
aplicacin para:
-indicar un error.
-confirmar que el proceso est completo.
-verificar si el proceso debiera continuar.
la posibilidad de especificar una accin, mismo si hay mltiples mtodos para
invocar el mismo proceso lgico
En las GUI:
Radio buttons 1 DET el grupo
Check boxes 1 DET cada opcin
Command buttons La posibilidad de especificar una accin cuenta como un
DET
Combo box 1 DET (adems es una EQ)
Desplegar imagen 1 DET
NO contar:
Mens
Barra de desplazamientos

Identificar la cantidad de FTRS de cada transaccin:

Contar un FTR por:
cada ILF mantenido
cada ILF o EIF ledo durante el proceso del EI
por cada ILF que es ledo Y mantenido.
Asignar a cada una un valor de complejidad (Alta, Media, Baja) en funcin de la
cantidad de DET y FTR para cada transaccin segn las siguientes tablas:
Para EI

1 a 4 DET

5 a 15 DET

16 o ms DET

0 a 1 FTR

Baja

Baja

Media

2 FTRs

Baja

Media

Alta

3 o ms FTRs

Media

Alta

Alta

Para EO/EQ

1 a 5 DET

6 a 19 DET

20 o ms DET

0 a 1 FTR

Baja

Baja

Media

2 a 3 FTRs

Baja

Media

Alta

4 o ms FTRs

Media

Alta

Alta

14

Introduccin a la Ingeniera de Software.- Camila Gimnez

Como contar la contribucin de los Datos?

Definicione Previa:
Record Element Type (RET): es un subconjunto de campos de un archivo, reconocible como
tal por el usuario.
Por ejemplo, puede pasar que dados dos archivos, el usuario perciba solo uno, esto es el caso
que el que (por ejemplo) solo le interese la interseccion.
Pasos:
Identificar Archivos

Una aplicacin puede usar un mismo ILF o EIF en mltiples procesos, pero
el archivo se cuenta una sola vez y no se puede contar como ILF y EIF a la
misma vez.
Si un grupo de datos no fue contado como ILF ni EIF, contar sus DET para el
ILF o EIF que incluye al grupo
No asumir que un archivo fsico, tabla o clase de objetos corresponde a un
archivo lgico desde el punto de vista del usuario
No asumir que todo archivo fsico debe ser contado o incluido como parte de
un ILF o EIF. Pe. Archivos temporales o de trabajo.
Asignar a cada uno un tipo (ILF, EIF)
Identificar la cantidad de RET y DET
Det idem a transacciones
Ret se cuenta 1 por cada archivo que es percibido por el usuario
Asignar a cada uno un valor de complejidad (Alta, Media, Baja) en funcin de la
cantidad de RET y DET

15

Introduccin a la Ingeniera de Software.- Camila Gimnez

4.2- Tecnicas de Estimacion

Estimaciones basadas en Proxies.
En esta tecnica, primero hay que identificar un Proxy, que esta correlacionado con lo que
que queremos estimar, esto es mas facil y accecible que contar. Por ejempplo calcular el
numero de pruebas que vamos a tener que hacer, esta correlacionado con la cantidad de
requisitos que tenemos.
Fuzzy Logic
Se utiliza para estimar el tamao del proyecto en lineas de codigo. Clasificamos cada
feature en Very Small, Small, Medium, Large, y Very Large.
Para cada una de las clasificaciones lo que se hace es, calcular la cantidad de locs por
feature, la cantidad de features, para luego calcular la cantidad de lineas totales.
OBS: Funciona mejor si las estimaciones son calibradas con los datos historicos de la
organizacion.
Nuestro Proxy aca seria la cantidad de features.
Componentes Estandar
Si tenemos varios programas que tienen una arquitectura similar, podemos relevar los
elementos components para hacer una estimacion, para luego computar el numero
promedio de lineas por componente y extrapolarlo a nuestro sistema.
OBS: el Proxy seria la cantidad de componentes.
Juicio de Expertos
Se realiza una estimacion a partir de la experiencia de los participantes del proyecto. Se
puede realizar en etapas tempranas del proyecto. Aplicable a Tamao, Esfuerzo, Costo,
Duracin.
Estimacin por Analoga
La idea principal aqu es comparar el proyecto actual con otro ya concluido y asi usar la
informacin del segundo para dar un estimado del primero.
Se tiene que:
1-Obtener informacin detallada del tamao, costo y resultados del proyecto anterior si esta
desglosada en features mejor.
2-Comparar el tamao del proyecto parte a parte.
3- Dar un estimativo del tamao del nuevo proyecto como un porcentaje del anterior.

16

Introduccin a la Ingeniera de Software.- Camila Gimnez

Mtodos Algortmicos (COCOMO)
Cuando no tenemos datos histricos en nuestra organizacin, podemos estimar utilizando
estos mtodos que se basan en una gran muestra de proyectos de diverso tamao y
complejidad que se pueden obtener de otras organizaciones.
En gral:
E=(a+b*Sc) m (X)
A,B,C son constantes.
S tamao estimado
X vector de ajuste
M multiplicador de de ajuste
COCOMO?

Mtodos basados en Aprendizaje Automatizado

Se estudian proyectos anterior y se intenta aprender de los mismos para poder predecir
costo, duracin, tamao,etc.
Data Mining: Se genera un modelo siguiendo datos historicos y se usa para predecir.

5-

Requisitos

5.1- Proceso de Requisitos

5.2- Definiciones
Requisitos:

17

Introduccin a la Ingeniera de Software.- Camila Gimnez

Descripcin de los servicios que debe brindar un sistema y sus restricciones. Refleja las
necesidades del cliente.
Ingenieria de requisitos:
-Proceso de comunicaciones entre clientes y usuarios de software y los desarrolladores del
mismo
-Proceso de descubrir, analizar, documentar y verificar esos servicios y restricciones.
Requerimientos Funcionales:
Declaraciones de los servicios que debe proporcionar el sistema, como debe reaccionar a las
entradas y en situaciones particulares.
La especificacin de los requerimientos funcionales debe estar completa (todos los servicios
del usuario deben estar definidos) y ser consistente(los requerimientos no deben tener
definiciones contradictorias).
Ejemplos
Se deben ingresar cdula, nombre y telfono de cada cliente
Se quiere 1 listado de los clientes por zona.

Requerimientos No Funcionales:
Restricciones de los servicios o funciones ofrecidos por el sistema, Restringen las elecciones
para construir una solucin. Pueden tambin restringir el proceso que se utiliza para
desarrollar.
Tipos de Requerimientos No Funcionales:
Requerimientos del Producto:
Especifican el comportamiento del producto. Ej. Rendimiento en la rapidez de ejecucin,
portabilidad, usabilidad.
Requerimientos Organizacionales:
Derivan de polticas y procedimientos existentes en la organizacin del cliente y en la
del desarrollador. Ej. Estndares, lenguajes de programacin, requerimientos de
entregas.
Requerimientos externos
Incluye todos los requerimientos que se derivan de factores externos al sistema y de su
proceso de desarrollo. Ej. requerimientos legislativos, interoperabilidad.
Ejemplos
Las consultas deben resolverse en menos de 3 segundos
El lenguaje de programacin debe ser java

5.3- Obtencion de requerimientos (1er paso de las actividades)

Se trabaja en conjunto con los usuarios y clientes.
Existen problemas para entender los requerimientos de los stakeholders:
no saben lo que quieren y necesitan.
expresan los requerimientos con sus propios trminos.
diferentes stakeholders quieren diferentes cosas.
Los requerimientos cambian por culpa del entorno econmico o de negocios.
Qu queremos relevar?

18

Introduccin a la Ingeniera de Software.- Camila Gimnez

Requerimientos del negocio: descripcin del negocio en alto nivel.
Documento de visin: sirve para establecer una visin comn con el cliente y para
difusin del proyecto.
Reglas de negocio: polticas, estndares, leyes
Requerimientos funcionales y no funcionales
Criterios de xito

5.4- Tcnicas para la obtencin de Requisitos

1- Entrevista Individual/Grupal:
El equipo de ingeniera de requerimientos hace preguntas a los stakeholders sobre el sistema
que utilizan y el sistema a desarrollar.
Se debe:
aprender sobre el sistema de antemano
seleccionar a los participantes, avisar con anticipacin
preparar la entrevista
luego de la entrevista, resumir principales requerimientos con la informacin fresca.
enviar memo sobre el resultado
Pros: interactivo y flexible
Contras: Costoso, depende de las habilidades interpersonales.
2- Encuesta/Cuestionario
El objetivo es validar asunciones y obtener datos estadsticos.
Se debe:
determinar que informacin se necesita.
determinar enfoque adecuado
desarrollar cuestionario y probarlo con perfil tpico
Analizar resultados
Pros: fcil para los stakeholders, respuestas annimas
Contras: problemas por no-respuesta, no flexible, esfuerzo de desarrollo.
3- Observacion/Participacion
Se debe:
Determinar informacin necesaria
Comunicar a los involucrados
Considerar perodos normales y atpicos
Planificar las anotaciones
Pros: confiable, rico, empata
Contras: cuando alguien observa, no se trabaja de la misma forma.

19

Introduccin a la Ingeniera de Software.- Camila Gimnez

4- Tormenta de ideas:
La idea es lograr consenso (consentimiento o acuerdo) sobre los requisitos mientras un
secretario saca notas de lo discutido.
Reglas:
No se permite criticar ni debatir
Dejar volar la imaginacin
Generar tantas ideas como sea posible
Mutar y combinar ideas
Se debe:
Juntar a los principales stakeholders, enviar invitaciones y motivarlos.
organizar agenda
Se explican las reglas.
Se establece el objetivo.
Pros: Participan todos los involucrados y permite generar nuevas ideas.
Contras: Costoso.
Obs: Workshop = mbito para las tormentas de ideas

5- Casos de Uso:
Es una buena tcnica para entender y describir requisitos, especifican que es lo que el
sistema tiene que hacer, bueno para requisitos funcionales!
Usar cuando:
Si el sistema est orientado a la funcionalidad, con varios tipos de usuarios
Cuando la implementacin se va a hacer OO y con UML
No usar cuando:
Sistemas sin usuarios y con pocas interfaces
Sistemas dominados primariamente por requisitos no funcionales y restricciones de
diseo.
Pros: Desarrolladores y clientes trabajan juntos,
Generan buenas oportunidades para mostrar interfaces al usuario
6- Prototipos:
Implementacin parcial, permite a los desarrolladores y usuarios, entender mejor los
requisitos y as acotar riesgos
Dos posibilidades:
Prototipo desechable: Se realiza el prototipo de forma de probar que se puede hacer, pero no
se lo sigue utilizando en el proyecto.
Prototipo evolutivo: Es implementado sobre la arquitectura del producto final, el sistema
final se obtiene de evolucionar el prototipo.

20

Introduccin a la Ingeniera de Software.- Camila Gimnez

Anlisis de requerimientos (2er paso de las actividades)
Analizar stakeholders / clientes / usuarios
Crear vistas
Detallar
Negociar prioridades
Buscar requerimientos que faltan
Evaluar factibilidad tcnica - Prototipos
Evaluar riesgos de requerimientos En el Plan

5.5- Redes de Petri (ppts 2)

:O ! no se nada!
5.6- Casos de Uso (ppts 3)
Tcnica para entender y describir requisitos.
Los casos de uso describen como el sistema debe comportarse desde el punto de vista del
usuario
(Ver mas: Tcnicas de Obtencin de Requisitos. Pto 5.)
Definiciones
Caso de Uso: conjunto de escenarios posibles en los cuales un actor (o varios)
interactan con el sistema para el logro de cierto objetivo
Actor: Entidad externa que interacta con el sistema (Actor principal: Sus objetivos
son cumplidos al realizar el caso de uso) El otro actor adems del principal, que viene a
ser el usuario, es el Sistema.
Escenario: Secuencia de acciones e interacciones entre los actores y el sistema, dando
un resultado de valor observable para un actor particular. Es un camino dentro de un
Caso de Uso.
Caso de Uso: Conjunto de escenarios posibles que puede encarar un actor (o varios)
con el sistema para el logro de cierto objetivo
Precondiciones: Establece que cosas deben ser siempre verdaderas antes de comenzar
un caso de uso. No se verifican dentro del caso de uso ya que se asume que son
verdaderas dentro de l.
Poscondiciones: Establece que cosas ocurren al completar el caso de uso, cambios en
el sistema o simplemente cosas que se muestran.
Flujo principal: Describe el escenario del caso de uso de mayor inters para el actor.
Flujos alternativos: son bifurcaciones en el flujo principal.
Requisitos Especiales: Son los requisitos no funcionales, atributos de calidad o
restricciones especficas relacionadas con el caso de uso.
Forma de encontrar los Casos de uso:

Mirar cada uno de los actores del sistema y preguntarse que es lo que buscan cuando usan el
sistema.

Nombre del Caso de Uso: Verbo activo.

21

Introduccin a la Ingeniera de Software.- Camila Gimnez

EJEMPLO
Flujo principal:
1. Cliente inserta una tarjeta bancaria en el lector del CA.
2. El CA lee el cdigo de la tarjeta y verifica que es correcto
3. El CA pide el cdigo de PIN de 4 dgitos
4. EL Cliente ingresa el PIN
5. El CA enva cdigo de Tarjeta y PIN al SC
6. El SC verifica que el PIN sea correcto y contesta: OK
7. El CA despliega las distintas alternativas disponibles: retiro, depsito, consulta
8. El Cliente elige Retiro
9. El CA pide cuenta y monto
10. El Cliente los ingresa
11. CA enva cdigo de Tarjeta, PIN, cuenta y monto al SC
12. El SC contesta: OK
13. El CA dispensa el dinero
14. El CA devuelve la tarjeta
15. El CA imprime el recibo

Flujos Alternativos :
2A. La tarjeta no es vlida
1. El CA devuelve la tarjeta con el mensaje tarjeta no vlida
2. Fin CU
6A. PIN invlido y menos de 3 intentos
El Cliente puede realizar tres intentos para ingresar el PIN vlido. Sino, el CA retiene la tarjeta.
1. El SC contesta indicando PIN invlido
2. El CA muestra el mensaje PIN incorrecto y sigue en punto 3
6B. PIN invlido y 3 intentos
El CA debe retener la tarjeta
1. El SC contesta indicando PIN invlido
2. El CA muestra el mensaje Se le retiene la tarjeta
3. Fin CU
9A. El CA no tiene dinero
1.La opcin Retiro en esta situacin no es una alternativa posible, y el CA despliega la advertencia:
Sin dinero.
2. Fin CU
11A. Monto insuficiente para el cajero
El monto indicado por el cliente no puede obtenerse a partir de los billetes de que dispone el CA
1 El CA despliega el mensaje No se cuenta con ese monto en este cajero
2 Vuelve a 9.
12A. No hay suficiente saldo en la cuenta.
1. CA despliega mensaje Su saldo no permite extraer ese monto
2. El CA devuelve la tarjeta
3. Fin CU
12B. No hay contacto con el Servicio de Cajeros (SC)
1. CA despliega el mensaje sin conexin a la red de cajeros
2 . El CA devuelve la tarjeta
3. Fin CU
12C. Enlace con el computador central se cae durante la transaccin
Hay que asegurar que el SC considera slo los retiros efectivamente realizados
14A. El dinero no es retirado de la bandeja.
1. Si despus de YY segundos el dinero est todava en la bandeja, el CA lo recupera y lo deja en el
depsito de dinero usado
1. Sigue en 14
14B. La tarjeta se tranca al intentar devolverla.
1. CA trata de devolverla durante xx segundos.
2. Si en ese tiempo no puede devolverla, CA avisa a mantenimiento

22

Introduccin a la Ingeniera de Software.- Camila Gimnez

3. Fin CU

Relaciones entre CU Include

Cuando un escenario es comn a varios casos de uso, se puede separar y utilizar la Relacin
incluye para relacionarlos.
El caso de uso a incluir no tiene por que tener sentido por si mismo.
En el diagrama de caso de uso:

En el caso del cajero:

En el Caso de Uso:
Poner en el momento necesario: Se incluye el Caso de Uso a Incluir
En el Ejemplo del caso de uso Retiro:
Flujo principal:
1. Incluye el caso de uso: Identificar Cliente
2. El CA despliega las distintas alternativas disponibles: retiro, depsito, consulta
3. El Cliente elige Retiro
4. El CA pide cuenta y monto
5. El Cliente los ingresa
6. CA enva cdigo de Tarjeta, PIN, cuenta y monto al SC
7. El SC contesta: OK
8. El CA dispensa el dinero
9. El CA devuelve la tarjeta
10. El CA imprime el recibo
Obs: El caso de uso Identificar Cliente lo tendra que definir (el flujo principal son los primeros 6 pasos del
1er Flujo principal anterior, y el alternativo, son 2 A, 6 A, 6 B del 1er FA anterior)

Relaciones entre CU Extend

Es un fragmento de un caso de uso, que agrega comportamiento a otro caso de uso.
Representan una parte de la funcionalidad del caso que no siempre ocurre.

23

Introduccin a la Ingeniera de Software.- Camila Gimnez

En Diagrama de Casos de Uso:

En el caso del cajero:

En el Caso de Uso:
En el caso de uso principal marcar un punto de extensin dndole un nombre.
En el caso de uso de extensin en el flujo principal al comienzo poner: Extensin de Caso
de uso Principal en el punto de extensin.
En el caso del cajero:
Flujo Principal:
1. Incluye
..
8. El Cliente pide dispensar el dinero (Este paso se agreg)

11. El Ca imprime el recibo

Puntos de Extensin:
Retiro de Monedas: En el punto 8 del flujo principal

Relaciones entre CU Generalizacion

Se puede crear un caso de uso abstracto, crear un caso de uso para cada escenario principal y
que estos hereden del caso abstracto
El caso de uso hijo hereda los escenarios, puntos de extensin y relaciones definidos
en el caso de uso padre
El caso de uso hijo puede definir nuevas operaciones, como tambin redefinir o
enriquecer con nuevas secuencias de acciones operaciones ya existentes en el caso de
uso padre

24

Introduccin a la Ingeniera de Software.- Camila Gimnez

En Diagrama de Caso de Uso:
C U Base
Validar Cliente

CU
Hijo

Validar con PIN

CU
Hijo

Validar con Scaner de Retina

5.7- UML (ppts 4)

Modelo Esttico
Refleja la estructura bsica y estable de un sistema software.
Crea una representacin de los principales elementos del dominio del problema
Modelo Dinmico
Crea los diagramas que muestran el comportamiento de un sistema

Para requerimientos utilizamos los siguientes Diagramas UML:

Diagrama de Casos de Uso (Esttico)
Permite visualizar en una forma compacta los casos de uso del sistema y que actores participan
en cada caso de uso, as como las relaciones entre los mismos.
Consta de los siguientes elementos: - Actor
- Caso de uso
- Relaciones (include, extend, generalizacin)

Diagrama de Clases (Esttico)

Muestra las clases e interfaces que componen el sistema, y las relaciones que existen entre ellas.
Diagramas de este tipo: - Modelo de dominio (Conceptual)
- Diagramas de clases de implementacin (muestran todos los mtodos y
atributos necesarios para implementar cada clase)

Diagrama de Actividad (Dinmico)

Se construye para modelar el flujo del control.
No son buenos para describir un comportamiento que involucra cierto nmero de objetos que
colaboran entre ellos.

Elementos:

25

Introduccin a la Ingeniera de Software.- Camila Gimnez

Ejemplo

Diagramas de Mquinas de Estado

Muestra el comportamiento de un objeto representando los estados en que se puede
encontrar y los eventos que le hace pasar de uno a otro. Modela el estado de un caso de
uso.
Estados Actividades
Inicial
Final
Transacciones Acciones
Pueden tener asociadas Guardias
(Condiciones)
Especificacin de Requisitos
Descripciones Estticas
Se especifican entidades y sus atributos, los requisitos se pueden ver como
las relaciones entre las entidades.
No describe cmo cambian las relaciones con el tiempo.
Descripciones Dinmicas
Especifican estados y las transiciones entre estados en el tiempo.
Documento de Requisitos

26

Introduccin a la Ingeniera de Software.- Camila Gimnez

Definicin de Requisitos: lista completa de lo que el cliente espera que el sistema haga, escrita de
forma que el cliente la pueda entender.
Especificacin de Requisitos: reformula la definicin en trminos tcnicos para que los diseadores
puedan comenzar el diseo.
(Caractersticas de una buena especificacin de requisitos)
Debe:
Tener todos los req requeridos por el cliente
No ambiguo
Definicin de respuestas del sw a todo posible datos de entrada
Ser Verificable: Un requerimiento es verificable si existe un proceso finito de costo
accesible para determinar que el sistema lo cumple.
Trazables: El origen de cada requerimiento es claro, y es posible seguirle la pista en
futuros desarrollos o mejora de la documentacin

Validacin de Requisitos
Proceso por el cual se determina si los requisitos relevados son consistentes con las necesidades del
cliente.
Su objetivo es ver si se est construyendo lo que quiere el cliente, es decir, asegurar que se est
construyendo el sistema correcto
Formas (o Tcnicas) de Validacin:
Manuales
Lectura por parte del cliente.
Entrevistas.
Listas de comprobacin.
Automatizadas
Ejecucin de Modelos para verificar funciones y relaciones.
Construccin de Prototipos.
Simulaciones.

Verificacin de Requisitos
Objetivo: Asegurar que se est construyendo el sistema correctamente.
Formas de Verificacin:
revisiones formales (en grupo)
revisiones por pares
listas de comprobacin
modelos
Pruebas Matemticas: Si se us un lenguaje formal, pe. Z.

Administracin de los Requisitos

Los requisitos cambian, debido a:
- Muchos usuarios
- Quienes pagan por el sistema y los usuarios no son las mismas personas
- Cambios en el negocio
- Cambios en la tecnologa
Se hace en paralelo con el Proceso de Requisitos.
Consta de Tres etapas:
Planificacin: Se realiza al comenzar el anlisis de requisitos
Administracin del cambio: Comienza una vez que se tiene una primera versin del
documento de requisitos

27

Introduccin a la Ingeniera de Software.- Camila Gimnez

Trazabilidad: Se mantiene a lo largo del proceso de requisitos (Uso de matrices de

trazabilidad)

Administracin del Cambio

Si se propone un cambio, debe evaluarse por etapas (El grupo encargado a la Adm. De cambio es el
CCC(Comit de Control de Cambios)).
Las mismas son:
1- Especificacin del cambio
2- Evaluar impacto (anlisis del cambio y costo)
3- Reunin con el Cliente, discutir el costo.
4- Implementar Cambio (ver que afectan los documentos ya hechos! )

Diseo de la Interfaz de Usuario (IU)

6-

Aspectos Importantes
Dos aspectos son clave para disear la interfaz de usuario:
a. Forma de interaccin del usuario con el sistema
b. Forma de presentar la informacin al usuario

Una interfaz coherente debe integrar las dos

Presentacin de la Informacin
Una buena gua de diseo es mantener separado el software de presentacin de la propia
informacin
Mensajes de Error
El diseo de los mensajes de error es crtico. Mensajes de error mal diseados pueden
significar que un usuario rechace el sistema
Los mensajes deben ser educados, concisos, consistentes y constructivos
Prototipado de IU
Prototipado que involucra al usuario es la nica forma prctica de disear y desarrollar las
interfaces de usuario grficas

Diseo

7-

Objetivo del Diseo

El diseo de un sistema es correcto si un sistema construido de acuerdo a ese diseo

satisface los requerimientos del sistema
El objetivo del diseo no es encontrar el diseo correcto sino:
Encontrar el mejor diseo posible dentro de las limitaciones impuestas por
los requerimientos,
el ambiente fsico del sistema
y el ambiente social donde el mismo va a operar
las dos cosas ms importantes concernientes a los diseadores es que el diseo sea:
Eficiente
Simple

28

Introduccin a la Ingeniera de Software.- Camila Gimnez

Principios de Diseo
1. Dividir y Conquistar: Dividir un problema complejo en subproblemas mas simples.
2. Abstraccin: Permite al diseador considerar una componente a un cierto nivel de
abstraccin sin preocuparse por los detalles de implementacin de dicha componente
(Se describe el comportamiento exterior sin describir los detalles internos)
3.

Modularidad: Es donde se juntan la abstraccin y la particin

Conceptos de Diseo

Tres conceptos claves para la calidad de un diseo:

1. Bajo Acoplamiento: Captura la fuerza de interconexin entre mdulos
Cunto ms acoplados ms dependientes entre si
(Entonces, ms difcil comprenderlos y modificarlo)
2. Alta Cohesin
3. Principio abierto-cerrado (cumplir con el principio):
- Promover la construccin de sistemas que sean fciles de modificar
- Mdulos abiertos para la extensin (El comportamiento puede ser extendido)
- Mdulos cerrados para la modificacin (La interfaz no debe cambiar y se debe
asegurar que se mantiene el comportamiento)
Frameworks(Marcos de trabajo)
Abstracciones de mayor granularidad que los objetos
Coleccin de clases abstractas y concretas
Es un subsistema reusable y semi-completo
Que puede ser extendido en un subsistema especfico o una aplicacin
Forma de extensin
Escribir clases concretas de clases abstractas del Framework
Escribir mtodos que sern llamados por eventos o estados reconocidos por el
Framework (callbacks)
Tienen asociada una curva de aprendizaje alta

8-

Diseo del sistema (Arquitectura de Software)

29

Introduccin a la Ingeniera de Software.- Camila Gimnez

8.1 Arquitectura de Software

Los sistemas complejos estn compuestos de subsistemas que interactan bajo el

control de 1 diseo de sistema.

La Arq. de Software para 1 sistema se compone de:

- Los subsistemas que componen el sistema
- Las interfaces
- Las reglas de interaccin entre ellos

Ventajas (de disear y documentar explcitamente una arquitectura de software):

- Comunicacin entre stakeholders
- Decisiones tempranas de diseo
- Reso a gran escala

La Arq. de Software afecta la: Performance, Seguridad, Disponibilidad, Mantenibilidad, etc.

El estilo y estructura particular elegido para una aplicacin dependen fuertemente de los
requerimientos no funcionales

El sistema debe ser muy performante y muy mantenible

Patrones de Software
Se agrupan en tres tipos:
Estilos arquitectnicos: Soluciones de organizacin a nivel del sistema
Patrones de diseo: Soluciones a problemas detallados de diseo de software
Idioms: Soluciones tiles para problemas especficos en algn lenguaje de
programacin

8.2 Estilos de Software

Un estilo de Software:
Expresa un esquema de organizacin estructural para sistemas de software.
Provee un conjunto de tipos de elementos predefinidos, especifica sus responsabilidades e incluye
reglas y guas para organizar las relaciones entre ellos.

Shared Data (Datos Compartidos)

Hay un almacenamiento central de datos y un conjunto de componentes que operan sobre
ste.
Si es el consumidor quien busca los datos es un Repositorio.
Bueno para compartir grandes cantidades de datos.
Actividades como respaldos, actualizaciones y seguridad estn centralizados.

Pizarrn (Blackboard)
Se avisa al consumidor de nuevos datos de inters

Cliente-Servidor
Consta de un servidor que se encarga de atender los pedidos de un conjunto de clientes, as como
una red para que los clientes se comuniquen con el servidor.

30

Introduccin a la Ingeniera de Software.- Camila Gimnez

Los clientes conocen a los servidores pero no a otros clientes y los servidores no tienen porqu
conocer a los clientes
Los servidores pueden actuar como clientes de otros servidores pero no requieren servicios de
clientes.

Cliente fino:
El procesamiento de la informacin y la gestin de los datos ocurre en el servidor. El cliente slo
es responsable de ejecutar el software de presentacin.
Procesamiento pesado del lado del servidor. Mucho peso para la red.
Cliente grueso.
El servidor es responsable slo de la gestin de los datos. El cliente ejecuta el procesamiento de
la aplicacin (la lgica de la aplicacin) y la presentacin
Si cambia el software re instalar en todos los clientes
En 2 niveles hay que distribuir las tres capas (presentacin, lgica y datos) en dos sistemas de
computadoras
Pueden surgir problemas de escalabilidad y rendimiento con el cliente fino, o de gestin del
sistema si se usa cliente grueso
Alternativa:
Cliente Servidor en tres niveles:
La presentacin, la lgica y los datos se separan como procesos lgicos diferentes distribuidos
en distintas mquinas.
Es ms escalable que la de 2 niveles
Reduce el trfico en la red en comparacin con cliente fino
La capa de procesamiento de la aplicacin es fcilmente actualizada ya que est localizada
centralmente
Capas Jerrquicas
El sistema se organiza en capas.
Cada una provee un conjunto de servicios a las capas superiores y requiere servicios de las
inferiores.
Modelo estricto: una capa slo utiliza servicios de la inmediata inferior
Modelo relajado: se pueden saltar capas.
Ventajas: Facilita el mantenimiento, la portabilidad, la reutilizacin, etc.
Desventajas: No siempre es fcil distinguir las capas.
Descomposicin Orientada a Objetos
Se descompone el sistema en un conjunto de objetos que se comunican.
Ventajas: Fcil de comprender, modificar y reutilizar.
Desventajas: Problemas si se cambian las interfaces (cambia el comportamiento de los dems
objetos).
Tubos y Filtros (Descomposicin orientada a flujos de funciones)
Se descompone el sistema en mdulos funcionales.
Las transformaciones funcionales procesan sus entradas y producen salidas.
Los datos fluyen de una funcin a otra y se transforman a medida que se mueven a travs de la
secuencia de funciones.
Las transformaciones son representadas como procesos separados.
Los filtros son reutilizables y agregar nuevas transformaciones es sencillo.
Es complicado para sistemas interactivos. Es ineficiente si los filtros repiten chequeos.

Control Centralizado

31

Introduccin a la Ingeniera de Software.- Camila Gimnez

Un sistema se descompone en subsistemas.
El arquitecto debe organizar los subsistemas de acuerdo a algn modelo de control.
Dos estilos de control:
1- Control centralizado: Un subsistema tiene toda la responsabilidad para controlar, iniciar y
detener otros subsistemas. Puede ceder el control pero el mismo siempre vuelve.
2- Control basado en eventos: La info de control no esta embebida en un subsistema nico, cada
subsistema puede responder a eventos originados en el exterior.

Arquitecturas de Sistemas Distribuidos

El procesamiento de la informacin es distribuido entre varias computadoras
Ventajas: - Se comparten recursos.
- Apertura. Normalmente estos sistemas estn diseados con protocolos
estndar.
- Concurrencia.
- Escalabilidad
- Tolerancia a fallas
Desventajas: - Complejidad
- Seguridad
- Difciles de gestionar
- Muy poco predecibles

Cliente-Servidor (Ver arriba)

Objetos Distribuidos
Se compone de objetos que proveen servicios a otros objetos y usan servicios de
otros objetosNo hay distincin entre clientes y servidores.
Pueden ser distribuidos entre distintas computadoras en una red y se comunican a
travs de middleware
Es ms complejo de disear que cliente-servidor

Peer-To-Peer
Sistemas descentralizados donde las computaciones pueden ser realizadas en
cualquier nodo de la red
En principio no hay distincin entre clientes y servidores
El sistema se disea para usar el poder de almacenamiento y procesamiento de
mltiples computadoras en una red
Los protocolos que permiten la comunicacin entre nodos estn embebidos en la
propia aplicacin
Cada nodo debe correr una copia de la aplicacin

Service Oriented Architecture (SOA)

Organizaciones que quieren hacer su informacin accesible a otros programas
pueden hacerlo definiendo y publicando una interface de servicio web.
Un servicio web es una representacin estndar para algn recurso computacional o
de informacin que puede ser usado por otros sistemas.

El servicio es independiente de las aplicaciones que lo usan

32