Apuntes Fundamentos de Ingenieria de Software

Recibimos sabidura, legaremos desarrollo
Grupo: 52T
Profesor: Ing. Daniel Jess Rojas Cid
Ingeniera en Sistemas Computacionales
Cd. Lzaro Crdenas, Mich. 12 de agosto de
ndice de contenido
Captulo 1 Fundamentos de ingeniera de software
1.1 Conceptos bsicos ................................................................................................... 1
1. 2 El papel evolutivo del software ............................................................................ 22
1.3 Etapas del desarrollo del software........................................................................ 24
1.4 Clasificacin de la tecnologa en el desarrollo del software ................................. 25
1.5 Definicin e historia de las herramientas CASE .................................................... 27
1.6 Clasificacin de las herramientas CASE................................................................. 30
Captulo 2 Ingeniera de requerimientos
2.1 Tareas de la ingeniera de requisitos..................................................................... 34
2.3 Modelador de requisitos ....................................................................................... 43
Captulo 3 Modelo de anlisis
3.1 Arquitectura de clases........................................................................................... 50
3.2 Identificacin de clases segn estereotipos ......................................................... 52
3.3 Clases .................................................................................................................... 55
3.4 Diagrama de secuencias........................................................................................ 62
3.5 Diccionario de datos ............................................................................................. 68
3.6. Herramientas CASE para el anlisis...................................................................... 71
Captulo 4 Modelo de diseo
4.1. Estrategias de diseo ........................................................................................... 77
4.2 Diseo de objetos ................................................................................................. 79
4.3. Diseo de sistema ................................................................................................ 81
4.4. Revisin del diseo .............................................................................................. 85
4.5. Diagramas de secuencias del Diseo ................................................................... 89
4.6. Herramientas CASE para el diseo ....................................................................... 91
Captulo 5 Modelo de implementacin
5.1 Diagrama de componentes ................................................................................... 95
5.2. Diagrama de despliegue...................................................................................... 97
5.3. Modelos de prueba .............................................................................................. 99
Bibliografa ........................................................................................................... 102
ndice de figuras
Figura 1 Lnea de tiempo del software parte 1 ............................................................... 22
Figura 2 Lnea del tiempo del software parte 2 .............................................................. 23
Figura 3 Tabla de etapas de desarrollo del software ...................................................... 24
Figura 4 Tabla comparativa de los diferentes paradigmas de programacin ................. 26
Figura 5 Tabla de la evolucin de las herramientas CASE............................................... 29
Figura 6 Diagrama de la clasificacin de las herramientas CASE .................................... 31
Figura 7 Mapa mental de la ingeniera de requisitos ..................................................... 34
Figura 8 Ejemplo diagrama de casos de uso ................................................................... 44
Figura 9 Ejemplo de diagrama de actividad ................................................................... 44
Figura 10 Ejemplo de diagrama de carril ........................................................................ 45
Figura 11 Modelos orientados al flujo ............................................................................ 45
Figura 12 Ejemplo de diagrama de flujo ......................................................................... 46
Figura 13 Ejemplo de clase ............................................................................................. 46
Figura 14 Modelo CRC .................................................................................................... 47
Figura 15 Ejemplo de diagrama de estado ..................................................................... 48
Figura 16 Ejemplo de diagrama de secuencia ................................................................ 48
Figura 17 Diagrama de tres dimensiones ....................................................................... 51
Figura 18 Ejemplo de diagrama de clases....................................................................... 55
Figura 19 Elementos de un diagrama de clases.............................................................. 56
Figura 20 Diagrama de clase CajeroAutomatico............................................................. 56
Figura 21 Relaciones entre clases ................................................................................... 57
Figura 22 Ejemplo asociacin ......................................................................................... 58
Figura 23 Ejemplo 2 Asociacin ...................................................................................... 58
Figura 24 Ejemplo 3 Asociacin ...................................................................................... 59
Figura 25 Ejemplo de Cardinalidad ................................................................................. 59
Figura 26 Ejemplo de Navegabilidad .............................................................................. 60
Figura 27 Relacin Unidireccional .................................................................................. 60
Figura 28 Relacin Bidireccional ..................................................................................... 60
Figura 29 Ejemplo Roles.................................................................................................. 61
Figura 30 Ejemplo Rol clasificador .................................................................................. 63
Figura 31 Ejemplo de activacin ..................................................................................... 63
Figura 32 Ejemplo flecha retorno ................................................................................... 64

Figura 33 Flecha que simboliza un mensaje ................................................................... 65
Figura 34 Mensaje reflexivo ............................................................................................ 65
Figura 35 Llamada recursiva ........................................................................................... 65
Figura 36 Creacin y destruccin de objetos.................................................................. 66
Figura 37 Ejemplo de diagrama de secuencia ................................................................ 67
Figura 38 Diccionario de datos ....................................................................................... 70
Figura 39 Diagrama de componentes ............................................................................. 95
Figura 40 Estructura de diagrama de despliegue ........................................................... 97
Figura 41 Diagrama de despliegue ................................................................................. 98
Figura 42 Modelo de implementacin ........................................................................... 99
Captulo 1 Fundamentos de
ingeniera de software
CAPITULO 1
FUNDAMENTOS DE INGENIERA DE SOFTWARE
Captulo 1 Fundamentos de ingeniera de software

1.1 Conceptos bsicos
-AAbstraccin.
Es la capacidad de separar aspectos importantes de detalles. Una
abstraccin define una delimitacin relativa a la perspectiva del observador.
Accin. Es un procedimiento algortmico o computacional.
Acoplamiento. Es la cantidad de relaciones que se establecen entre los mdulos de un

programa.
Algebra Heterognea. Es una coleccin de conjuntos junto a sus operaciones.
Algebra Homognea. Es un solo conjunto y varias operaciones.
Anlisis. Es la parte del proceso de desarrollo de software cuyo propsito principal es

realizar un modelo del dominio del problema. El anlisis hace foco en qu hacer, el
diseo hace foco en cmo hacerlo.
Anlisis Morfolgico. Es un esquema que permite organizar las cosas vivientes de una
manera no formal y no matemtica.
Arquitectura. Consiste en la estructura organizacional de un sistema. Una arquitectura

puede ser descompuesta recursivamente en partes que interactan entre s por medio de
interfaces, relaciones que conectan las partes, y restricciones para ensamblar las partes.
Instituto Tecnolgico de Lzaro Crdenas | I.S.C
CAPITULO 1
Atributo. Es una parte especfica de una clase. Una propiedad de un tipo identificada
mediante un nombre.
Adaptabilidad. Facilidad con la que un sistema o un componente pueden modificarse

para corregir errores, mejorar su rendimiento u otros atributos, o adaptarse a cambios
del entorno.
Anlisis de requisitos. (1) Proceso de estudio de las necesidades del usuario para
conseguir una definicin de los requisitos del sistema o del software.
Aplicacin de software. Software diseado para satisfacer las necesidades de un

usuario.
-B-
Business Case. Es la justificacin del negocio que soporta y compromete el tiempo, los
recursos y las inversiones para la realizacin de un proyecto.
-C-
Ciclo de vida. Periodo de tiempo que comienza con la concepcin del producto de
software y termina cuando el producto est disponible para su uso. Normalmente, el
ciclo de vida del software incluye las fases de concepto, requisitos, diseo,
implementacin,
prueba,
instalacin,
verificacin,
validacin,
operacin
mantenimiento, y, en ocasiones, retirada. Nota: Esta fases pueden superponerse o

realizarse iterativamente.
CAPITULO 1
Calidad de Software. Es la concordancia con los requerimientos funcionales y de

rendimiento
explcitamente
establecidos,
con
los
estndares
de
desarrollo
explcitamente documentados y con las caractersticas implcitas que se esperan de todo

software desarrollado profesionalmente.
Cardinalidad. Es aquello que indica el nmero de elementos en un conjunto o la

cantidad de elementos de un conjunto.
CASE Tools. Es un conjunto de herramientas semiautomatizadas y automatizadas para

la generacin de cdigo automtico.
Casos de Uso. Es aquello que describe la interaccin de los Actores con el sistema para
lograr un objetivo.
Clase de un Objeto. Es aquello que sirve para crear objetos. Una clase es una
implementacin de un tipo.
Clase abstracta (abstract class). Es una clase que no puede ser instanciada
directamente.
Clase asociacin (association class). Es un elemento de modelado que tiene

propiedades tanto de asociacin como de clase. Una clase asociacin puede ser vista
tanto como una asociacin que tambin tiene propiedades de clase, o como una clase
que tambin tiene propiedades de asociacin.
Codificacin. (1) Proceso de descripcin de un programa de ordenador en un lenguaje

de programacin. (2) Transformacin del diseo lgico y dems especificaciones de
diseo en un lenguaje de programacin.
CAPITULO 1
Comit de gestin de configuracin (CGC). Grupo de personas responsable de

evaluar y aprobar cambios propuestos a elementos de configuracin y garantizar la
implementacin de los cambios.
Compatibilidad. (1)Preparacin de dos o ms componentes o sistemas para llevar a

cabo sus funciones mientras comparten el mismo entorno de hardware o software. (2)
Capacidad de dos o ms sistemas o componentes para intercambiar informacin.
Complejidad ciclomtica. Mtrica que evala la complejidad del cdigo. Los sistemas
de software con puntos de excesiva complejidad ciclomtica presentan un cdigo con
mayor dificultad de mantenimiento.
Componente. Una de las partes que forman un sistema. Un componente puede ser
hardware, software, y puede a su vez subdividirse en otros componentes.
CPM. (Critical Path Method) Mtodo para el control y la optimizacin de los costes de
operacin mediante la planificacin adecuada de las actividades que componen un
proyecto. Fue desarrollado en 1957 en los Estados Unidos por un centro de
investigacin de operaciones para la firma Dupont y Remington Rand. Actualmente se
utilizan sus principios en combinacin con los del mtodo PERT en lo que se conoce
como PERT/CPM.
Crisis del software. Trmino acuado en 1968, en la primera conferencia de la NATO

sobre desarrollo de software, con el que se identificaron los problemas que surgan en el
desarrollo de sistemas de software.
Crystal Methods. Metodologa heterodoxa para desarrollo de software, creada por

Alistair. Cockburn, basada en su afirmacin: mucha gente piensa que el desarrollo de
CAPITULO 1
software es una actividad de ingeniera. Esa comparacin es de hecho ms perniciosa

que til, y nos lleva en una direccin equivocada.
-D-
Descripcin del sistema. Documento orientado al cliente que describe las

caractersticas del sistema desde el punto de vista del usuario final. El documento se
utiliza para coordinar conjuntamente los objetivos del sistema del usuario, cliente,
desarrollador e intermediarios. Tambin se denomina: ConOps (Conceptof Operation
std. IEEE 1362). Requisitos del sistema (ISO IEC 12207 1995, 5.1.1.2).
Datamart. Es un subconjunto de un datawarehousing para un tema especfico consiste

en un almacenamiento de informacin multi-tema y es diseado especficamente para la
toma de decisiones.
Dataming. Es un proceso analtico que establece reglas que permiten establecer

relaciones entre los datos que conforman la base de datos. Tambin, permite describir
una variedad de herramientas y estrategias de procesamiento de datos que aumentan la
utilidad de los datos que estn incorporados en las bases de datos.
Datawarehousing. Es un conjunto de datos integrados orientados a una materia, que

varan con el tiempo y que no son transitorios, los cuales soportan el proceso de toma de
decisiones de una administracin.
Diagrama de Actividades. Es un caso especial de diagrama de estados en el que todos,

o la mayora, son estados activos y en el que todas, o la mayora, de las transiciones son
disparadas por la finalizacin de las acciones de los estados.
CAPITULO 1
Diagrama de Casos de Uso. Es el diagrama que muestra la relacin entre los actores y
los casos de uso dentro de un sistema.
Diagrama de Clases. Es el diagrama que muestra una coleccin de elementos del

modelo tales como las clases, tipos y sus contenidos y relaciones.
Diagrama de Colaboraciones. Es un diagrama que muestra interacciones entre objetos

organizadas alrededor de los objetos y sus vinculaciones. A diferencia de un diagrama
de secuencias, un diagrama de colaboraciones muestra las relaciones entre los objetos.
Los diagramas de secuencias y los diagramas de colaboraciones expresan informacin
similar, pero en una forma diferente.
Diagrama de Entidad / Relacin. Es una descripcin conceptual de las estructuras de

datos y sus relaciones.
Diagrama de Flujo de Datos. Es una descripcin informal del sistema de informacin.
Diagrama de Interacciones. Es un trmino genrico que se aplica a diversos tipos de

diagramas que enfatizan la interaccin entre objetos. Incluye: diagrama de
colaboraciones, diagrama de secuencias, diagrama de actividades.
Diagrama de Objetos. Es un diagrama que contiene los objetos y sus relaciones en un

momento dado del tiempo. Un diagrama de objetos puede ser considerado un caso
especial de un diagrama de clases o de un diagrama de colaboraciones.
Diagrama de Secuencia. Es el diagrama que muestra los objetos que participan en la

interaccin y la secuencia de mensajes que intercambian.
CAPITULO 1
Diseo. Es la parte del proceso de desarrollo de software cuyo propsito principal es

decidir cmo se construir el sistema. Durante el diseo se toman decisiones
estratgicas y tcticas para alcanzar los requerimientos funcionales y la calidad
esperada.
Dominio. Es un rea de conocimiento o actividad caracterizada por un conjunto de

conceptos y trminos comprendidos por los practicantes de esa rea.
Diseo de arquitectura. (1) Proceso que define una coleccin de componentes de

software y hardware junto con sus interfaces, para definir el marco de desarrollo de un
sistema
Diseo detallado. (1) Proceso de definicin y ampliacin del diseo preliminar de un

sistema o de un componente hasta un grado de detalle suficiente para llevar a cabo la
implementacin.
Diseo funcional. (1) Proceso de definicin de las relaciones de trabajo entre los
componentes de un sistema.
Diseo preliminar (1) Proceso de anlisis de las alternativas de diseo y definicin de

la arquitectura, componentes, interfaces, estimacin de tiempo y tamao de un sistema o
de un componente.
-E-
Elemento de configuracin. Parte de un desarrollo de software (planes, software,

documentacin de especificacin y diseo, manuales, etc.) tratada como una unidad
independiente en el proceso de gestin de configuracin.
CAPITULO 1
Escalabilidad. Facilidad con la que un sistema o un componente puede modificarse

para aumentar su capacidad funcional o de almacenamiento.
Especificacin de requisitos de software. Documentacin de requisitos fundamentales

(necesarios, esenciales e indispensables) de funcionalidades, rendimiento, restricciones
y atributos del software, y sus interfaces externas. Su acrnimo ingls es SRS.
Extreme Programming. Metodologa heterodoxa de programacin. Es la ms popular

de las denominadas metodologas giles. Surgida a partir de la metodologa de trabajo
empleada Kent Beck, Wark Cunningham y Martin Fowler en el desarrollo del proyecto
C3 para Chrysler. Extreme Programming (XP) se funda en cuatro valores:
comunicacin, simplicidad, feedback y coraje.
-F-
Faceta del modelo. Es una dimensin del modelo que enfatiza cualidades particulares
del metamodelo. Por ejemplo, la faceta estructural del modelo, enfatiza las cualidades
estructurales del modelo.
Faceta estructural del modelo. Es una faceta del modelo que enfatiza la estructura de
los objetos del sistema, incluyendo sus tipos, clases, relaciones, atributos y operaciones.
Faceta funcional del modelo. Es una faceta del modelo que enfatiza el comportamiento
de los objetos de un sistema, incluyendo sus mtodos, interacciones, colaboraciones, e
historia de estados.
Fallo. Es cualquier no concordancia con los requerimientos del software.
CAPITULO 1
Flexibilidad. Facilidad con la que un sistema o un componente puede modificarse para

ser empleado con aplicaciones o en entornos distintos para los que fue construido.
Front End. Es aquella categora de herramienta CASE que permite especificar los
requerimientos de anlisis y diseo lgico.
-G-
Generalidad. Es la amplitud de aplicacin potencial de los componentes del programa.
Gestin de configuracin. Disciplina que aplica la direccin y supervisin tcnica y

administrativa para: identificar y documentar las caractersticas funcionales y fsicas de
un elemento de configuracin, controlar cambios, registrar cambios procesados,
registrar el estado de la implementacin, informar y verificar la conformidad con los
requisitos especificados.
Gestin de procesos. Direccin, control y coordinacin del trabajo realizado para

desarrollar o producir un servicio.
-H-
Herencia. Es la propiedad que permite que una subclase herede los atributos y los
mensajes de una superclase. Es el mecanismo por el cual elementos ms especficos
incorporan la estructura y el comportamiento de elementos ms generales.
Herencia de implementacin. Es la herencia de la implementacin por parte de un

elemento ms especfico. Incluye la herencia de interface.
CAPITULO 1
Herencia de interface. Es la herencia de la interface de un elemento ms general. No

incluye la herencia de implementacin.
Herencia mltiple. Es una variacin semntica de la generalizacin en la cual un tipo

puede tener ms de un supertipo.
Herencia simple. Es una variacin semntica de la generalizacin en la que un tipo

puede tener solo un supertipo.
-I-
Implementacin. Es la definicin de cmo est construido o compuesto algo. Por

ejemplo: una clase es una implementacin de un tipo, un mtodo es una implementacin
de una operacin.
Ingeniera del software. (1) Aplicacin de procesos sistemticos y disciplinados para el

desarrollo, operacin y mantenimiento de software. (2) Es una disciplina para el
desarrollo de software de alta calidad para sistemas basados en computadora.
Instancia. Es un objeto individual de una clase. Un individuo descripto por una clase o
un tipo. Nota de uso: De acuerdo con la interpretacin estricta del metamodelo un
individuo de un tipo es una instancia y un individuo de una clase es un objeto. Es
aceptable, en un contexto menos formal, referirse a un individuo de una clase como un
objeto o una instancia.
Instrumentacin. Es el grado en que el programa muestra su propio funcionamiento e

identifica errores que aparecen.
10
CAPITULO 1
Interaccin. Es una especificacin de comportamiento cuyo fin es lograr un propsito

especfico. Abarca un conjunto de intercambios de mensajes entre un conjunto de
objetos dentro de un contexto particular. Una interaccin puede ilustrarse mediante uno
o ms escenarios.
Interfaz de usuario. Interfaz que permite la comunicacin entre un usuario y un

sistema, o los componentes de un sistema.
-J-
-K-
-L-
Lnea de base. Conjunto de elementos de configuracin, formalmente revisados y

aprobados (para su uso interno o para entregar al cliente), que constituyen la base para
el desarrollo posterior, y que slo puede modificarse a travs de procedimientos de
cambio formales.
-M-
Mantenimiento. (1)Proceso de modificacin de un sistema de software o de un

componente, despus de su puesta en funcionamiento para corregir fallos, mejorar el
rendimiento u otros atributos, o adaptarlo a modificaciones del entorno.
11
CAPITULO 1
Mantenimiento adaptativo. Modificacin de un sistema de software o de un

componente, despus de su puesta en funcionamiento, para adaptarlo a cambios del
entorno.
Mantenimiento correctivo. Modificacin de un sistema de software o de un

componente, despus de su puesta en funcionamiento para corregir fallos.
Mantenimiento perfectivo. Modificacin de un sistema de software o de un

componente, despus de su puesta en funcionamiento para mejorar el rendimiento u
otros atributos.
Manual de programador. Documento que proporciona la informacin necesaria para

desarrollar o modificar el software de un sistema.
Manual de soporte. Documento que contiene la informacin necesaria para mantener

operativo un sistema durante su ciclo de vida.
Manual de usuario. Documento que contiene la informacin necesaria para obtener de

un sistema o de un componente los resultados deseados.
Matriz de trazabilidad. Representacin grfica de las relaciones entre dos o ms

productos del proceso de desarrollo, generalmente identificada en las intersecciones de
lneas verticales y horizontales. Por ejemplo, para representar la relacin entre los
requisitos y el diseo de un componente del software.
Microsoft Solutions Framework. (MSF) Marco para desarrollo de sistemas de

software basado en principios, modelos, disciplinas, conceptos, prcticas y
recomendaciones propias, derivadas de la experiencia de Microsoft. Se autodefine como
12
CAPITULO 1
marco y no como metodologa, porque considera que no hay una nica estructura de
procesos vlida para todos los proyectos. El marco MSF se adapta de forma flexible a
las caractersticas de cada proyecto.
Modelo de ciclo de vida. Representacin del ciclo de vida del software.
Moore (Ley de). Gordon Moore, co-fundador de Intel afirm en una entrevista a la
revista Electronics, que el nmero de transistores por pulgada, implementados en los
circuitos integrados se duplicara cada ao. Algo ms tarde rectific este plazo a 18
meses. Desde entonces hasta la fecha se viene cumpliendo esta progresin de
crecimiento exponencial.
-N-
Nivel de integridad. Grado de dao que puede producir un fallo en un sistema. El

estndar IEEE 1012-1998 define cuatro niveles de integridad para sistemas de software
siendo el grado 1 el propio de sistemas cuyo fallo produce daos de escasa relevancia, y
el 4 el que implica prdidas de vida o graves prdidas econmicas o sociales.
Nodo. Es un objeto fsico existente en tiempo de ejecucin, que representa un recurso

computacional, que generalmente tiene al menos memoria y habitualmente tambin
capacidad computacional. Los objetos de tiempo de ejecucin y componentes pueden
residir en nodos
Notacin. Consiste en una serie de diagramas, y en los elementos visuales y textuales

que los componen.
-OInstituto Tecnolgico de Lzaro Crdenas | I.S.C
13
CAPITULO 1
Objeto. Es un componente del mundo real que tiene una cierta estructura interna y un
determinado comportamiento. Una entidad delimitada precisamente y con identidad,
que encapsula estado y comportamiento. El estado es representado por sus atributos y
relaciones, el comportamiento es representado por sus operaciones y mtodos.
Obtencin. (Aplicado a requisitos). Proceso en el que se implican las partes cliente y

desarrolladora para descubrir, revisar, articular y comprender las necesidades y
limitaciones que el sistema debe ofrecer a los usuarios.
Operacin. Es un servicio que puede ser requerido a un objeto para producir un

comportamiento. Una operacin tiene una signatura, que puede restringir sus parmetros
posibles.
OOP (Object-Oriented Programming) Programacin orientada por objetos.

Mtodo de implementacin de los programas que los organiza como grupos
cooperativos de objetos, cada uno de los cuales representa instancias de una clase, que a
su vez forman parte de una jerarqua a travs de relaciones de herencia.
-P-
PERT. (Program Evaluation and Review Technique) Mtodo para el control de los
tiempos de ejecucin de diversas actividades integrantes de proyectos. Fue desarrollado
en 1957 por la armada de los Estados Unidos.
Polimorfismo. Es cuando distintos objetos de distintas clases reciben un mismo

mensaje.
14
CAPITULO 1
Portabilidad. Es el esfuerzo requerido para transferir el programa desde un hardware

y/o un entorno de sistema de software a otro.
Postcondicin. Es una restriccin que debe ser verdadera al terminar una operacin.
Precondicin. Es una restriccin que debe ser verdadera cuando una operacin es
invocada.
Proceso. Es un hilo de ejecucin que puede ejecutar concurrentemente con otros hilos.
Plan de proyecto. Documento que describe el enfoque tcnico y de gestin que seguir
un proyecto. Generalmente, el plan describe el trabajo a realizar, los recursos
necesarios, los mtodos a utilizar, los procesos a seguir, los programas a cumplir y la
forma en la que se organiza el proyecto.
Producto de software. (1) Conjunto de programas, procedimiento y opcionalmente

documentacin asociada que se entrega al usuario como resultado.
Programa de ordenador. Combinacin de instrucciones informticas y definiciones de

datos que permiten a un ordenador llevar a cabo tareas de control o de manipulacin de
informacin.
Prototipado. Tcnica de desarrollo consistente en la construccin de una versin

preliminar de parte o de todo un sistema, para evaluar su viabilidad, funcionalidad,
tiempos de respuesta, etc.
Prototipo. Versin preliminar de un sistema que sirve de modelo para fases posteriores.
15
CAPITULO 1
Prueba de interfaz. Prueba cuya finalidad es evaluar el correcto intercambio de

informacin y control entre componentes.
Prueba de sistema. Prueba cuya finalidad es evaluar el grado de conformidad con los
requisitos de un sistema completo.
Prueba estructural. Prueba que centra su atencin en la mecnica interna de un sistema

o componente.
Protocolo. Es el conjunto de mensajes a los cuales responde un objeto.
-Q-
-R-
Rapid Application Development. (RAD) Denominacin genrica para tcnicas y

herramientas de desarrollo de software que permiten el desarrollo rpido de
aplicaciones.
Rational Unified Process (RUP). Proceso de Ingeniera del Software que proporciona
un enfoque disciplinado para asignar tareas y responsabilidades en las organizaciones de
desarrollo de software. Se trata de un proceso integrado en un producto, desarrollado y
mantenido por Racional Software, e integrado en su conjunto de herramientas de
desarrollo. Se encuentra disponible a travs de IBM.
16
CAPITULO 1
Redundancia. Presencia de componentes auxiliares en un sistema para realizar

funciones idnticas o similares a las de los componentes principales.
Redundancia activa. Uso de elementos redundantes en operacin simultnea para

prevenir fallos.
Redundancia pasiva. Uso de elementos redundantes que permanecen detenidos hasta

que ocurre un fallo en el elemento principal.
Requerimiento. Es una caracterstica, propiedad o comportamiento deseado para un

sistema.
Requisito de implementacin. Requisito que condiciona la codificacin o la

construccin de un sistema o de un componente.
Requisito de interfaz. Requisito que especifica un elemento externo con el que un

sistema o un componente debe interactuar; o que establece condiciones, formatos,
tiempos u otros factores que deben respetarse en dicha interactuacin.
Requisito de rendimiento. Requisito que impone condiciones sobre un requisito

funcional. Por ejemplo los requisitos que especifican velocidad, precisin o uso de
memoria.
Requisito fsico. Requisito que especifica las caractersticas fsicas que debe presentar
un sistema o un componente de un sistema; por ejemplo, material, longitud o peso.
17
CAPITULO 1
Requisito funcional. Requisito que especifica una funcionalidad que debe realizar un
sistema o un componente.
-S-
Seguridad. Es la disponibilidad de mecanismos que controlen o protejan los programas

o datos.
Sistema. Conjunto de procesos, hardware, software, instalaciones y personas necesarios

para realizar un trabajo o cumplir un objetivo.
Sistema de software. Conjunto de programas de ordenador, procedimientos y opcional.
Sistema de software. Conjunto de programas de ordenador, procedimientos y

opcionalmente la documentacin y datos asociados, necesarios para el funcionamiento
de un sistema.
Sistema intensivo de software. Sistema en el que el principal componente es el
software.
SLIM. (Software Lifecycle Management) Metodologas para estimaciones de duracin,

costes, control de proyectos y gestin de mtricas. Desarrolladas por la comercial QSM.
Software. Los programas de ordenador, procedimientos, y opcionalmente la

documentacin y los datos asociados que forman parte de un sistema.
Software de sistema. Software diseado para facilitar o permitir la operacin y el

mantenimiento de un sistema informtico; por ejemplo los sistemas operativos.
18
CAPITULO 1
SQA. (Software Quality Assurance) Se aplica a los procesos o a las funciones

encaminadas a garantizar que la organizacin realiza el trabajo de desarrollo, operacin
o mantenimiento de software conforme a los procedimientos y mtodos establecidos
para el proyecto.
-T-
TBD Siglas de la expresin inglesa to be determined. Generalmente aplicada a un

requisito para indicar que est pendiente de determinar con el nivel de detalle requerido.
Template. Es aquello que describe un conjunto de clases por medio de parmetros.
Tiempo de Anlisis. Hace referencia a algo que ocurre durante la fase de anlisis del
proceso de desarrollo de software.
Tiempo de Compilacin. Se refiere a algo que sucede durante la compilacin de un

mdulo de software.
Tiempo de Diseo. Hace referencia a algo que ocurre durante una fase de diseo del
proceso de desarrollo de software.
Tiempo de Ejecucin. Es el perodo de tiempo durante el cual un programa ejecuta.
Tolerancia de errores. Consiste en el dao que se produce cuando el programa

encuentra un error.
19
CAPITULO 1
Trazabilidad de requisitos. Evidencia de una asociacin entre un requisito y sus

requisitos origen, su implementacin y verificacin.
-U-
UML "Unified Modeling Language". Es un lenguaje que permite especificar,

construir, visualizar y documentar los elementos que componen un sistema de software
intensivo.
Upper CASE. Es aquella categora de herramienta CASE que abarca las etapas de
anlisis, diseo y especificacin.
Usuarios Amateur. Son las personas que nunca vieron una computadora.
Usuarios Ejecutivos. Son las personas que estn concentradas en los usos estratgicos
de la informacin y estn interesados desde el punto de vista ms global del sistema.
Usuarios Expertos. Son las personas que realmente entienden sobre los sistemas y
tecnologa.
Usuarios Intermedios. Son aquellos que ya se vieron involucrados en uno o ms

proyectos.
Usuarios Operacionales. Son las personas que tienen mayor contacto con el sistema.
Usuarios Supervisores. Son empleados con capacidad de supervisin.
20
CAPITULO 1
-V-
Validacin. Confirmacin mediante examen y aportacin de pruebas objetivas de que

se cumplen los requisitos concretos para un uso determinado.
Verificacin. Confirmacin mediante examen y aportacin de pruebas objetivas de que

se cumplen los requisitos especficos.
Visibilidad. Es una enumeracin cuyos valores (pblico, protegido, privado o

implementacin) denotan cmo, el elemento del modelo al que se refieren, puede ser
observado fuera del espacio de nombres al que pertenece.
-W-
WBS. (Work Breakdown Structure). Mtodo para representar jerrquicamente las partes
de un proyecto, proceso o producto.
-X-
XP. v. Extreme Programming.
-Y-
-Z-
21
CAPITULO 1
1. 2 El papel evolutivo del software

1930
1 Era
1936
Primera teora
del software fue
propuesta por
Alan Turing.
1951
1958
1954
Invencin
del
primer compilador
Inventado
por
Grace
Murray
Hopper, llamado
A-0.
Fortran. Se desarrolla
el
lenguaje
de
programacin de alto
nivel. Fue inventado
por un equipo de
IBM, dirigido por John
Backus.
Aparece
el
lenguaje LISP
diseado
por
John McCarthy.
1960
Se
crea
el
lenguaje COBOL.
Fue
diseado
inspirndose en
el lenguaje FlowMatic de Grace
Hopper y el IBM
COMTRAN
de
Bob Bemer.
1966
2 Era
1964
Creacin del lenguaje

Basic. Fue diseado
por Jonh G. Kermeny
y Thomas E. Kurtz
para permitir a los
estudiantes escribir
programas.
1967
1968
Comienza la crisis del

software. La naturaleza
personalizada
de
muchos programas los
hacia
virtualmente
imposibles de mantener.
Creacin
del
lenguaje Pascal.
Fue desarrollado
por Niklaus Wirth.
1970
En 1970 Winston W. Royce

propuso lo que es ahora
popularmente designado en
el modelo en cascada como
un concepto inicial, un
modelo en el cual l
argumentaba ser definido.
Figura 1 Lnea de tiempo del software parte 1
22
CAPITULO 1
1971
1972
Software
como
producto.
El
establecimiento del
software
ya
se
desarrollaba
para
tener una amplia
distribucin en un
mercado.
1973
3 Era

C
creado
por
Dennis M. Ritchie.
1976
Apple Computer inc.

Empresa
estadounidense de
tecnologa
informtica fundada
por Steve Jobs y
Steve Wozni.
1983
Aparece el lenguaje
de
programacin
C++ Diseado por
Bjarne Stroustrup.
1989
4 Era
1984
Impacto en el
consumo.
La
industria
del
software ya es la
cuna
de
la
economa
del
mundo.
1990

Java diseado por
James Gosling que
trabajaba
para
la
empresa
Sun
Microsystems.
1991
Open
source.
El
software
libre
comienza a ser ms
conocido.
Linux. Linus Torvalds

libera la primera versin
de su ncleo, an muy
primitiva, llamada Linux.
2001
Lenguajes orientados
a objetos. En la poca
2000
se
van
implementando ms
lenguajes
con
programacin
orientada a objetos.
Las
herramientas
CASE. Aparecen en la
poca de los 90s.
Tienen gran auge en el
2000
entre
los
desarrolladores
de
software.
Figura 2 Lnea del tiempo del software parte 2
23
CAPITULO 1
1.3 Etapas del desarrollo del software

La ingeniera de software requiere llevar a cabo numerosas tareas agrupadas en etapas,
al conjunto de estas etapas se le denomina ciclo de vida. Las etapas comunes a casi
todos los modelos de ciclo de vida son las siguientes:
Etapa
Etapa de planificacin
Etapa de anlisis
Etapa de diseo
Etapa de programacin
Etapa de pruebas
Etapa de implementacin
Etapa de mantenimiento
Etapa final EOL (End-of-Line)
Descripcin
En esta etapa el analista luego de un
minucioso y detallado estudio de los
sistemas de una organizacin, detecta un
problema o una necesidad que para su
solucin y/o satisfaccin es necesario
realizar un desarrollo de software.
Es el proceso de investigar un problema
que se quiere resolver. Definir claramente
el Problema que se desea resolver o el
sistema que se desea crear. Identificar los
componentes principales que integrarn el
producto.
Es el proceso de utilizar la informacin
recolectada en la etapa de anlisis al
diseo del producto. La principal tarea de
la etapa de diseo es desarrollar un
modelo o las especificaciones para el
producto o Componentes del Sistema.
Consiste en utilizar los modelos creados
durante la etapa de diseo para crear los
componentes del sistema.
Consiste en asegurar que los componentes
individuales que integran al sistema o
producto, cumplen con los requerimientos
de la especificacin creada durante la
etapa de diseo.
Consiste en poner a disposicin del cliente
el producto.
Consiste en corregir problemas del
producto y re- liberar el producto como
una nueva versin o revisin (producto
mejorado).
El fin del ciclo del producto consiste en
realizar todas las tareas necesarias para
asegurar que los clientes y los empleados
estn conscientes de que el producto ya no
ser vendido ni soportado.
Figura 3 Tabla de etapas de desarrollo del software
24
CAPITULO 1
1.4 Clasificacin de la tecnologa en el desarrollo del software

Programacin estructurada
Concepto
La
programacin
estructurada
es
un
paradigma de programacin
orientado a mejorar la
claridad, calidad y tiempo de
desarrollo de un programa de
computadoras,
utilizando
nicamente subrutinas y tres
estructuras
lgicas:
secuencia,
seleccin
e
iteracin.
Historia
La
programacin
estructurada surgi en la
dcada
de
1960
particularmente del trabajo
Bohm y Jacopini y una
famosa carta, la sentencia
GOTO
considerada
perjudicial, de Edsger Dijkstra
en 1968. Posteriormente fue
reforzado tericamente por
el teorema del programa
estructurado, y por la
aparicin de lenguajes como
ALGOL con ricas estructuras
de control.
Los programas son ms
fciles de entender, pueden
ser
ledos
de
forma
secuencial
y
no
hay
necesidad
de
hacer
engorrosos seguimientos en
saltos de lnea (GOTO) dentro
de los bloques de cdigo para
intentar entender la lgica.
Reduccin de los costos de
mantenimiento.
Anlogamente
a
la
depuracin, durante la fase
de mantenimiento, modificar
o extender los programas
resulta ms fcil.
Reusabilidad
Mantenibilidad
Modificabilidad
Programacin Orientado a
objetos
La programacin Orientada a
Objetos
(POO)
es
un
paradigma de programacin
que usa los objetos en sus
interacciones, para disear
aplicaciones y programas
informticos.
Seis
ideas
bsicas caracterizan a la
programacin O-O: Objetos,
clases,
mensajes,
encapsulacin, herencia y
polimorfismo.
Los
conceptos
de
la
programacin Orientada a
Objetos tiene origen en
simula 67, un lenguaje
diseado
para
hacer
simulaciones, creado por Ole
Johan Dahl y Kristen Nygaard
del centro de cmputo
Noruego en Oslo.
Cuando hemos diseado

adecuadamente las clases, se
pueden usar en distintas
partes del programa y en
numerosos proyectos.
Debido a la sencillez para

abstraer el problema, los
programas orientados a
objetos son ms sencillos de
leer y comprender, pues nos
permite ocultar detalles de
implementacin
dejando
visibles solo aquellos detalles
ms relevantes.
Los programas son ms La facilidad de aadir,
sencillos y ms rpidos de suprimir o modificar nuevos
25
CAPITULO 1

confeccionar.
Fiabilidad
Lenguajes de programacin
objetos nos permite hacer

modificaciones de una forma
muy sencilla.
Al dividir el problema en
partes
ms
pequeas
podemos
probarlas
de
manera independiente y
aislar mucho ms fcilmente
los posibles errores que
puedan surgir.
Reduccin del esfuerzo en las

pruebas y depuracin. El
seguimiento de los fallos o
errores
del
programa
(debugging) se facilita
debido a su estructura ms
sencilla y comprensible, por
lo que los errores se pueden
detectar y corregir ms
fcilmente.
ALGOL, Pascal, PL/I, Ada.
C++, C#, Java, PHP, Python,
Ruby, Visual FoxPro, Visual
Basic 6.0.
Figura 4 Tabla comparativa de los diferentes paradigmas de programacin
26
CAPITULO 1
1.5 Definicin e historia de las herramientas CASE

Definicin
Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas que dan
asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del
Ciclo de Vida de desarrollo de un Software. Como es sabido, los estados en el Ciclo de Vida de
desarrollo de un Software son: Investigacin Preliminar, Anlisis, Diseo, Implementacin e
Instalacin.
CASE se define tambin como:
Conjunto de mtodos, utilidades y tcnicas que facilitan la automatizacin del ciclo de
vida del desarrollo de sistemas de informacin, completamente o en alguna de sus fases.
La sigla genrica para una serie de programas y una filosofa de desarrollo de software
que ayuda a automatizar el ciclo de vida de desarrollo de los sistemas.
Una innovacin en la organizacin, un concepto avanzado en la evolucin de tecnologa
con un potencial efecto profundo en la organizacin. Se puede ver al CASE como la
unin de las herramientas automticas de software y las metodologas de desarrollo de
software formales.
La realizacin de un nuevo software requiere que las tareas sean organizadas y

completadas en forma correcta y eficiente. Las Herramientas CASE fueron
desarrolladas para automatizar esos procesos y facilitar las tareas de coordinacin de los
eventos que necesitan ser mejorados en el ciclo de desarrollo de software.
La mejor razn para la creacin de estas herramientas fue el incremento en la velocidad
de desarrollo de los sistemas. Por esto, las compaas pudieron desarrollar sistemas sin
encarar el problema de tener cambios en las necesidades del negocio, antes de finalizar
el proceso de desarrollo.
Tambin permite a las compaas competir ms efectivamente usando estos sistemas
desarrollados nuevamente para compararlos con sus necesidades de negocio actuales.
En un mercado altamente competitivo, esto puede hacer la diferencia entre el xito y el
fracaso.
27
CAPITULO 1
Historia
Las Herramientas CASE tienen su inicio con el simple procesador de palabras que fue
usado para crear y manipular documentacin. Los setentas vieron la introduccin de
tcnicas grficas y diagramas de flujo de estructuras de datos. Sobre este punto, el
diseo y especificaciones en forma pictrica han sido extremadamente complejos y
consuman mucho tiempo para realizar cambios.
La introduccin de las herramientas CASE para ayudar en este proceso ha permitido
que los diagramas puedan ser fcilmente creados y modificados, mejorando la calidad
de los diseos de software. Los diccionarios de datos, un documento muy usado que
mantiene los detalles de cada tipo de dato y los procesos dentro de un sistema, son el
resultado directo de la llegada del diseo de flujo de datos y anlisis estructural, hecho
posible a travs de las mejoras en las Herramientas CASE.
Pronto se reemplazaron los paquetes grficos por paquetes especializados que habilitan
la edicin, actualizacin e impresin en mltiples versiones de diseo. Eventualmente,
las herramientas grficas integradas con diccionarios de base de datos para producir
poderosos diseos y desarrollar herramientas, podran sostener ciclos completos de
diseo de documentos.
Como un paso final, la verificacin de errores y generadores de casos de pruebas fueron
incluidos para validar el diseo del software. Todos estos procesos pueden saberse
integrados en una simple herramienta CASE que soporta todo el ciclo de desarrollo.
La primera herramienta comercial se remonta a 1982, aunque algunos especialistas
indican que algunos ejemplos de herramientas para diagramacin ya existan.
No fue sino hasta 1985 en que las herramientas CASE se volvieron realmente
importantes en el proceso de desarrollo de software. Los proveedores prometieron a la
Industria que muchas actividades seran beneficiadas por la ayuda de las CASE.
Estos beneficios consistan, por ejemplo, en el aumento en la productividad. El objetivo
en 1985 para muchos vendedores era producir software ms rpidamente.
Las herramientas del CASE seran una familia de mtodos favorablemente estructurados
para planeamiento, anlisis y diseo. Esto llevara a la generacin automtica de cdigo
para desarrollo de software va una especificacin formalmente diseada. Esto traera
como beneficio:
28
CAPITULO 1
Una mejora en la calidad, fiabilidad, utilidad y rendimiento.

El entorno de produccin de documentacin para software mejora la
comunicacin, mantenimiento y actualizacin.
Hace el trabajo de diseo de software ms fcil y agradable.
La promesa futura de reemplazar realmente a los ingenieros de software
especializados.
Reduccin del costo de produccin de software.
Con estos objetivos en mente, la industria destin millones en produccin de
Herramientas CASE.
As como esta enorme suma de dinero fue gastada en Herramientas CASE, hubo
tambin trabajo de investigacin a nivel mundial en diferentes instituciones como
Universidades, Instituciones Gubernamentales y de Defensa. La industria de
Herramientas CASE est creciendo y est tomando cada vez mayor importancia.
Evolucin de las Herramientas CASE
A inicios de los 80s
A mediados de los 80s
Al final de los 80s
A inicios de los 90s
Ayuda en la documentacin por

computadora.
Diagramacin
asistida
por
computadora.
Herramientas de anlisis y diseo.
Diseo automtico de anlisis y
pruebas.
Repositorios
automticos
de
informacin de sistemas.
Generacin automtica de cdigo
desde especificaciones de diseo.
Metodologa Inteligente.
Interface de Usuario reusable como
una metodologa de desarrollo.
Figura 5 Tabla de la evolucin de las herramientas CASE
29
CAPITULO 1
1.6 Clasificacin de las herramientas CASE

Aunque no es fcil y no existe una forma nica de clasificarlas, las herramientas CASE
se pueden clasificar teniendo en cuenta los siguientes parmetros:
Las plataformas que soportan.
Las fases del ciclo de vida del desarrollo de sistemas que cubren.
La arquitectura de las aplicaciones que producen.
Su funcionalidad.
Herramientas
CASE
Se clasifican
en:
Herramientas
integradas, ICASE
Herramientas
de alto nivel,
U-CASE
Herramientas
de bajo nivel,
L-CASE
Abarcan todas
las fases del
ciclo de vida
del desarrollo
de sistemas.
Son llamadas
tambin
workbench.
Orientadas
a
la
automatizacin
y
soporte
de
las
actividades
desarrolladas durante
las primeras fases del
desarrollo: anlisis y
diseo.
Dirigidas a las
ltimas fases del
desarrollo
construccin e
implantacin.
Juegos de
herramientas o
Tools Case
Son el tipo ms
simple
de
herramientas CASE.
Automatizan
una
fase dentro del ciclo
de vida.
30
CAPITULO 1

Clasificando por
funcionalidad
Herramientas de
planificacin de
sistemas de
gestin
Sirven para modelar

los requisitos de
informacin
estratgica de una
organizacin.
Herramientas
de anlisis y
diseo.
Herramientas
de
programacin.
Permiten al desarrollador
crear un modelo del
sistema que se va a
construir y tambin la
evaluacin de la validez y
consistencia
de
este
modelo.
Se engloban aqu los

compiladores, editores y
depuradores de los
lenguajes
de
programacin
convencionales.
Herramientas
de integracin
y prueba.
Sirven de ayuda a la
adquisicin, medicin,
simulacin y prueba de
los equipos lgicos
desarrollados.
Otra clasificacin,
diferencia
las
funciones CASE en
cinco grupos.
Repositorio
El repositorio es
un concepto ms
amplio que el de
diccionario de
datos y soporta a
los
dems
grupos
de
funciones.
Reingeniera
Facilita
la
realizacin de
modificaciones
en la fase ms
adecuada
en
cada caso y su
traslado a los
dems.
Soporte del
ciclo de
vida
El ciclo de vida de
una aplicacin o
de un sistema de
informacin
se
compone de varias
etapas, que van
desde
planificacin de su
desarrollo hasta su
implantacin.
Soporte de
proyecto
Este tipo de
funciones
hace
referencia
al
soporte
de
actividades que
se
producen
durante
el
desarrollo.
Mejora
continua de
calidad
Permiten ejercer
un control intenso
de garanta de
calidad
del
software
desarrollado
desde
las
primeras fases de
su ciclo de vida.
Figura 6 Diagrama de la clasificacin de las herramientas CASE
31
Captulo 2 Ingeniera de requisitos
CAPITULO 2
INGENIERA DE REQUISITOS
Captulo 2 Ingeniera de requerimientos

2.1 Tareas de la ingeniera de requisitos
Actividad 2.1 Elaborar un mapa mental de la ingeniera de requisitos.
Problemas de
alcance
Problemas de
entendimiento
Problemas de
volatilidad
Hay
Ingeniera de
requerimientos
Administracin
de los
requerimientos
Indagacin
Sus tareas
principales son:
Validacin
Negociacin
Concepcin
Especificacin
Elaboracin
Figura 7 Mapa mental de la ingeniera de requisitos
34
CAPITULO 2
Actividad 2.2 Investigar las diferentes tareas que se realizan en la ingeniera de

requerimientos para la documentacin de proyectos de desarrollo.
La ingeniera de requerimientos proporciona el mecanismo apropiado para entender lo
que desea el cliente, analizar las necesidades, evaluar la factibilidad, negociar una
solucin razonable, especificar la solucin sin ambigedades, validar la especificacin y
administrar los requerimientos a medida de que se transforman en un sistema
funcional *Tha97+. Incluye siete tareas diferentes: concepcin, indagacin, elaboracin,
negociacin, especificacin, validacin y administracin. Es importante notar que
algunas de estas tareas ocurren en paralelo y que todas se adaptan a las necesidades
del proyecto.
Concepcin. Cmo inicia un proyecto de software? Existe un solo evento que se
convierte en el catalizador de un nuevo sistema o producto basado en computadora o
la necesidad evoluciona en el tiempo? No hay respuestas definitivas a estas preguntas.
En ciertos casos, una conversacin casual es todo lo que se necesita para desencadenar
un trabajo grande de ingeniera de software. Pero en general, la mayor parte de
proyectos comienzan cuando se identifica una necesidad del negocio o se descubre un
nuevo mercado o servicio potencial. Los participantes de la comunidad del negocio
(por ejemplo, los directivos, personal de mercadotecnia, gerentes de producto, etc.)
definen un caso de negocios para la idea, tratan de identificar el ritmo y profundidad
del mercado, hacen un anlisis de gran visin de la factibilidad e identifican una
descripcin funcional del alcance del proyecto. Toda esta informacin est sujeta a
cambio, pero es suficiente para desencadenar anlisis con la organizacin de ingeniera
de software.
En la concepcin del proyecto, se establece el entendimiento bsico del problema, las
personas que quieren una solucin, la naturaleza de la solucin que se desea, as como
la eficacia de la comunicacin y colaboracin preliminares entre los otros participantes
y el equipo de software.
Indagacin. En verdad que parece muy simple: preguntar al cliente, a los usuarios y a
otras personas cules son los objetivos para el sistema o producto, qu es lo que va a
lograrse, cmo se ajusta el sistema o producto a las necesidades del negocio y,
35
CAPITULO 2
finalmente, cmo va a usarse el sistema o producto en las operaciones cotidianas. Pero

no es simple: es muy difcil.
Christel y Kang *Cri92+ identificaron cierto nmero de problemas que se encuentran
cuando ocurre la indagacin:
Problemas de alcance. La frontera de los sistemas est mal definida o los

clientes o usuarios finales especifican detalles tcnicos innecesarios que
confunden, ms que clarifican, los objetivos generales del sistema.
Problemas de entendimiento. Los clientes o usuarios no estn

completamente seguros de lo que se necesita, comprenden mal las
capacidades y limitaciones de su ambiente de computacin, no entienden
todo el dominio del problema, tienen problemas para comunicar las
necesidades al ingeniero de sistemas, omiten informacin que creen que es
obvia, especifican requerimientos que estn en conflicto con las
necesidades de otros clientes o usuarios, o solicitan requerimientos
ambiguos o que no pueden someterse a prueba.
Problemas de volatilidad. Los requerimientos cambian con el tiempo.
Para superar estos problemas, debe enfocarse la obtencin de requerimientos en

forma organizada.
Elaboracin. La informacin obtenida del cliente durante la concepcin e indagacin se
expande y refina durante la elaboracin. Esta tarea se centra en desarrollar un modelo
refinado de los requerimientos (vanse los captulos 6 y 7) que identifique distintos
aspectos de la funcin del software, su comportamiento e informacin.
La elaboracin est motivada por la creacin y mejora de escenarios de usuario que
describan cmo interactuar el usuario final (y otros actores) con el sistema. Cada
escenario de usuario se enuncia con sintaxis apropiada para extraer clases de anlisis,
que son entidades del dominio del negocio visibles para el usuario final. Se definen los
atributos de cada clase de anlisis y se identifican los servicios4 que requiere cada una
de ellas. Se identifican las relaciones y colaboracin entre clases, y se producen varios
diagramas adicionales.
36
CAPITULO 2
Negociacin. No es raro que los clientes y usuarios pidan ms de lo que puede lograrse
dado lo limitado de los recursos del negocio. Tambin es relativamente comn que
distintos clientes o usuarios propongan requerimientos conflictivos con el argumento
de que su versin es esencial para nuestras necesidades especiales.
Estos conflictos deben reconciliarse por medio de un proceso de negociacin. Se pide a
clientes, usuarios y otros participantes que ordenen sus requerimientos segn su
prioridad y que despus analicen los conflictos. Con el empleo de un enfoque iterativo
que da prioridad a los requerimientos, se evala su costo y riesgo, y se enfrentan los
conflictos internos; algunos requerimientos se eliminan, se combinan o se modifican de
modo que cada parte logre cierto grado de satisfaccin.
Especificacin. En el contexto de los sistemas basados en computadora (y software), el
trmino especificacin tiene diferentes significados para distintas personas. Una
especificacin puede ser un documento escrito, un conjunto de modelos grficos, un
modelo matemtico formal, un conjunto de escenarios de uso, un prototipo o
cualquier combinacin de stos.
Algunos sugieren que para una especificacin debe desarrollarse y utilizarse una
plantilla estndar *Som97+, con el argumento de que esto conduce a requerimientos
presentados en forma consistente y por ello ms comprensible. Sin embargo, en
ocasiones es necesario ser flexible cuando se desarrolla una especificacin. Para
sistemas grandes, el mejor enfoque puede ser un documento escrito que combine
descripciones en un lenguaje natural con modelos grficos.
No obstante, para productos o sistemas pequeos que residan en ambientes bien
entendidos, quiz todo lo que se requiera sea escenarios de uso.
Validacin. La calidad de los productos del trabajo que se generan como consecuencia
de la ingeniera de los requerimientos se evala durante el paso de validacin. La
validacin de los requerimientos analiza la especificacin5 a fin de garantizar que todos
ellos han sido enunciados sin ambigedades; que se detectaron y corrigieron las
inconsistencias, las omisiones y los errores, y que los productos del trabajo se
presentan conforme a los estndares establecidos para el proceso, el proyecto y el
producto.
37
CAPITULO 2
El mecanismo principal de validacin de los requerimientos es la revisin tcnica. El

equipo de revisin que los valida incluye ingenieros de software, clientes, usuarios y
otros participantes, que analizan la especificacin en busca de errores de contenido o
de interpretacin, de aspectos en los que tal vez se requiera hacer aclaraciones, falta
de informacin, inconsistencias (problema notable cuando se hace la ingeniera de
productos o sistemas grandes) y requerimientos en conflicto o irreales (no asequibles).
Administracin de los requerimientos. Los requerimientos para sistemas basados en
computadora cambian, y el deseo de modificarlos persiste durante toda la vida del
sistema. La administracin de los requerimientos es el conjunto de actividades que
ayudan al equipo del proyecto a identificar, controlar y dar seguimiento a los
requerimientos y a sus cambios en cualquier momento del desarrollo del proyecto.
Muchas de estas actividades son idnticas a las tcnicas de administracin de la
configuracin del software (TAS).
38
CAPITULO 2
Actividad 2.4.- Investigar y documentar las distintas tcnicas que se implementan

dentro de las tareas de la ingeniera de requerimientos.
Tcnicas principales
La ingeniera de requisitos puede ser un proceso largo y arduo para el que se requiere
de habilidades psicolgicas. Los nuevos sistemas cambian el entorno y las relaciones
entre la gente, as que es importante identificar a todos los actores involucrados,
considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos
sistemas. Los analistas pueden emplear varias tcnicas para obtener los requisitos del
cliente. Histricamente, esto ha incluido tcnicas tales como las entrevistas, o talleres
con grupos para crear listas de requisitos. Tcnicas ms modernas incluyen los
prototipos, y utilizan casos de uso. Cuando sea necesario, el analista emplear una
combinacin de estos mtodos para establecer los requisitos exactos de las personas
implicadas, para producir un sistema que resuelva las necesidades del negocio.
Entrevistas
Las entrevistas son un mtodo comn. Por lo general no se entrevista a toda la gente
que se relacionar con el sistema, sino a una seleccin de personas que represente a
todos los sectores crticos de la organizacin, con el nfasis puesto en los sectores ms
afectados o que harn un uso ms frecuente del nuevo sistema.
Talleres
Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas
implicadas individuales y que a menudo no se descubren en las entrevistas o quedan
incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden
descubrirse realizando en un ambiente controlado, talleres facilitados por un analista
del negocio, en donde las personas implicadas participan en discusiones para descubrir
requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es til la
seleccin de un secretario dedicado a la documentacin de la discusin, liberando al
analista del negocio para centrarse en el proceso de la definicin de los requisitos y
para dirigir la discusin.
39
CAPITULO 2
Existen dos tcnicas de este tipo que son las ms utilizadas: Brainstorming (Lluvia de
ideas) y JAD (Joint Application Development, Diseo de Aplicacin Conjunta). La
diferencia que existe entre ambas tcnicas es que durante la tormenta de ideas se
tiene como objetivo generar una gran cantidad de ideas, es desestructurada y la
informacin que se obtiene puede ser visual, textual coloquial; mientras que en el
JAD el taller es ordenado, la informacin que se obtiene es visual y su objetivo es
generar requisitos y la interfaz del sistema
Durante una sesin de Lluvia de ideas, todos los participantes pueden aportar distintas
ideas en un ambiente libre de prejuicios. Ningn participante debe juzgar
negativamente la propuesta de otros, sino que se anotan todas las ideas en una pizarra
y sern evaluadas al final de la sesin. El principio bsico es no descartar de manera
apresurada ningn planteo, de modo que existe la posibilidad de que surjan otras ideas
derivadas de la idea original y se generan varios puntos de vista del problema.
Forma de contrato
En lugar de una entrevista, se pueden llenar formularios o contratos indicando los
requisitos. En sistemas muy complejos stos pueden tener centenares de pginas.
Objetivos medibles
Los requisitos formulados por los usuarios se toman como objetivos generales, a largo
plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del
sistema hasta determinar los objetivos crticos del funcionamiento interno que luego
darn forma a los comportamientos apreciables por el usuario. Luego, se establecen
formas de medir el progreso en la construccin, para evaluar en cualquier momento
qu tan avanzado se encuentra el proyecto.
Prototipos y Casos de uso
Un prototipo es una pequea muestra, de funcionalidad limitada, de cmo sera el
producto final una vez terminado. Ayudan a conocer la opinin de los usuarios y
rectificar algunos aspectos antes de llegar al producto terminado.
Un caso de uso es una tcnica para documentar posibles requisitos, graficando la
relacin del sistema con los usuarios u otros sistemas. Dado que el propio sistema
40
CAPITULO 2
aparece como una caja negra, y slo se representa su interaccin con entidades
externas, permite omitir dichos aspectos y determinar los que realmente corresponden
a las entidades externas. El objetivo de esta prctica es mejorar la comunicacin entre
los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para
minimizar cambios hacia el final del proyecto y reducir los costes finales. Esta tcnica se
enfrenta a los siguientes peligros potenciales.
A los directivos, una vez que ven un prototipo, les cuesta comprender que
queda mucho trabajo por hacer para completar el diseo final.
Los diseadores tienden a reutilizar el cdigo de los prototipos por temor a

perder el tiempo al comenzar otra vez.
Los prototipos ayudan principalmente a las decisiones del diseo y de la

interfaz de usuario. Sin embargo, no proporcionan explcitamente cules
son los requisitos.
Los diseadores y los usuarios finales pueden centrarse demasiado en el

diseo de la interfaz de usuario y demasiado poco en producir un sistema
que sirva el proceso del negocio.
Los prototipos pueden ser: diagramas, aplicaciones operativas con funcionalidades

sintetizadas. Los diagramas, en los casos donde se espera que el software final tenga
diseo grfico, se realizan en una variedad de documentos de diseo grficos y a
menudo elimina todo el color del diseo del software (es decir utilizar una gama de
grises). Esto ayuda a prevenir la confusin sobre la apariencia final de la aplicacin.
Especificacin de requisitos del software
Una especificacin de requisitos del software es una descripcin completa del
comportamiento del sistema a desarrollar. Incluye un conjunto de casos de uso que
describen todas las interacciones que se prevn que los usuarios tendrn con el
software. Tambin contiene requisitos no funcionales (o suplementarios). Los
requisitos no funcionales son los requisitos que imponen restricciones al diseo o
funcionamiento del sistema (tal como requisitos de funcionamiento, estndares de
calidad, o requisitos del diseo).
41
CAPITULO 2
Las estrategias recomendadas para la especificacin de los requisitos del software

estn descritas por IEEE 830-1998. Este estndar describe las estructuras posibles,
contenido deseable, y calidades de una especificacin de requisitos del software.
Los requisitos se dividen en tres:
Funcionales: son los que el usuario necesita que efecte el software. Ej: el
sistema debe emitir un comprobante al asentar la entrega de mercadera.
No funcionales: son los "recursos" para que trabaje el sistema de

informacin (redes, tecnologa). Ej: el soporte de almacenamiento a usar
debe ser MySQL.
Empresariales u Organizacionales: son el marco contextual en el cual se

implantar el sistema para conseguir un objetivo macro. Ej: abaratar costos
de expedicin.
Identificacin de las personas involucradas

Debido a que los cambios que introduce un sistema nuevo tienden a afectar a ms de
un tipo de usuario, los analistas de requisitos han de tomar en consideracin a todos
los implicados para que se obtengan y depuren sus requisitos de la forma ms
fidedigna posible. Entre las personas implicadas hay que considerar:
Organizaciones que integran la organizacin del analista que est diseando

el sistema
Organizaciones o sistemas de respaldo
Direccin
Usuarios
42
CAPITULO 2
2.3 Modelador de requisitos

Actividad 2.6.- Investigar las aplicaciones sobre el modelo y sus especificaciones.
La accin de modelar los requerimientos da como resultado uno o ms de los

siguientes tipos de modelo:
Modelos basados en el escenario de los requerimientos desde el punto de

vista de distintos actores del sistema.
Modelos de datos, que ilustran el dominio de informacin del problema.
Modelos orientados a clases, que representan clases orientadas a objetos

(atributos y operaciones) y la manera en la que las clases colaboran para
cumplir con los requerimientos del sistema.
Modelos orientados al flujo, que representan los elementos funcionales del

sistema y la manera como transforman los datos a medida que se avanza a
travs del sistema.
Modelos de comportamiento, que ilustran el modo en el que se comparte el

software como consecuencia de eventos externos.
Estos modelos dan al diseador del software la informacin que se traduce en diseos
de arquitectura, interfaz y componentes. Por ltimo, el modelo de requerimientos (y la
especificacin de requerimientos de software) brinda al desarrollador y al cliente los
medios para evaluar la calidad una vez construido el software.
Modelo basado en escenarios
Este modelo en simples palabras sirve para una interaccin ms amena entre el
sistema y el usuario, por lo tanto el modelo de anlisis con UML comienza con la
creacin de escenarios en la forma de los casos de uso, diagrama de actividad y
diagrama de carril.
Caso de uso: Describe un escenario de un caso especfico en un lenguaje directo desde
el punto de vista de un actor definido.
43
CAPITULO 2
Figura 8 Ejemplo diagrama de casos de uso
Diagrama de actividad: es un modelo muy parecido al caso de uso pero mucho mejor
complementado y proporciona una representacin del flujo de interaccin dentro de
un escenario especfico.
Figura 9 Ejemplo de diagrama de actividad
Diagrama de carril: Consiste en tomar el diagrama actividad y situarlo en filas o en

carriles. En este modelo los actores son fundamentales ya que en el diagrama de carril
se especifica claramente, con un carril, la responsabilidad a cada actor.
44
CAPITULO 2
Figura 10 Ejemplo de diagrama de carril
Modelos orientados al flujo

Tiene una visin del sistema del tipo entrada-proceso-salida. Los objetos de datos
fluyen hacia el interior del software, se transforman mediante elementos de
procesamiento y los objetos de datos resultantes fluyen al exterior del software.
Figura 11 Modelos orientados al flujo
Diagrama de flujo de datos

Propiedades del DFD
1. El nivel 0 del diagrama del flujo debe representar al software
2. La entrada y la salida primaria se deben establecer con cuidado
45
CAPITULO 2
3. La refinacin debe comenzar por el aislamiento de procesos, objetos de datos y

almacenamiento de datos candidatos a ser representados en el siguiente nivel
4. Toda las flechas y burbujas se deben rotular con el nombre
5. Se debe tener la continuidad de flujo al cambiar el nivel
6. La refinacin de burbujas debe hacerse una por una.
Figura 12 Ejemplo de diagrama de flujo
Este diagrama es orientado al tiempo y rendimiento. Cada elemento o evento de

control se puede implementar con valores V o F, 1 0 o tambin otros similares.
Modelos basados en clases
Figura 13 Ejemplo de clase
46
CAPITULO 2
Una clase orientada a objetos encapsula atributos de los datos pero tambin incorpora
las operaciones que manipulan los datos implicados por dichos atributos. Las clases se
manifiestan en la siguiente forma: entidades externas, sucesos o eventos, cosas,
papeles o roles, unidades organizacionales, sitios y estructuras.
Modelo CRC (clase-responsabilidad-colaborador)
Figura 14 Modelo CRC
El modelado de Clase-Responsabilidad-Colaborador (CRC) proporciona un medio

simple para identificar y organizar las clases relevantes para los requisitos del sistema o
producto. Un modelo CRC es una coleccin de tarjetas ndices estndar que
representan clases. El objeto es desarrollar una representacin organizada de las
clases.
Clases: tienen diferentes categoras:
Clases de entidad: llamadas clases de modelo o negocios, se extraen de

manera directa del enunciado del problema.
Clases de frontera: se utilizan para crear la interfaz que el usuario ve y con la

cual interacta cuando se utiliza el software.
Clases de controlador: manejan una unidad de trabajo desde el inicio

hasta el final.
Responsabilidad: son los atributos y las operaciones relevantes para la clase.
Colaboradores: son aquellas clases que se requieren para que una clase
reciba la informacin necesaria para completar una responsabilidad.
Agregacin: son las subclases que forman parte de una clase, se conectan a
travs de una relacin de tipo es parte de.
47
CAPITULO 2
Modelos de comportamiento
El modelo de comportamiento indica la forma en que el software responder a los
eventos o estmulos externos.
Diagrama de estado: representa el comportamiento de las clases cuando el sistema.
Figura 15 Ejemplo de diagrama de estado
Diagrama de Secuencia: representa el comportamiento al describir la forma en que las

clases se mueven de estado a estado.
Figura 16 Ejemplo de diagrama de secuencia
48
CAPITULO 3
MODELO DE ANLISIS

3.1 Arquitectura de clases
El modelo de anlisis tiene como objetivo generar una arquitectura de objetos que
sirva como base para el diseo del sistema. Dependiendo del tipo de aplicacin existen
diversas arquitecturas que se pueden utilizar.
Las arquitecturas se distinguen segn la organizacin de los objetos de acuerdo a su
funcionalidad. Esto es tambin conocido como la dimensin de la arquitectura. Por
ejemplo, si existe un grupo de objetos para el manejo de la funcionalidad de la
aplicacin y otro para interactuar con las entidades externas de la aplicacin, como el
usuario y las bases de datos, entonces se considera que la arquitectura es de dos
dimensiones. Por el contrario, si existe un solo grupo de objetos que maneja de manera
indistinta la funcionalidad junto con la interaccin externa, entonces se considera que
la arquitectura es de una sola dimensin.
Una arquitectura puede incluir cualquier nmero de dimensiones. Algo que depende
del tipo de aplicacin que desee desarrollar. En genera el planteamiento es: si se disea
un sistema con cierto nmero de dimensiones. se obtendr un sistema ms estable y
fcil de extender que con un nmero menor o mayor?. La respuesta depende de que
tan independiente sean los objetos de un eje de funcionalidad con los dems. Si se
cuenta con ejes de funcionalidad completamente ortogonales, algo que es difcil de
lograr, el efecto de cambios en una dimensin no debera afectar a las dems
dimensiones. Sin embargo, si los grupos de objetos no son lo suficientemente
independientes, aun se puede limitar el efecto de los posibles cambios.
En el caso de los sistemas de informacin, una de las arquitecturas ms utilizadas es la
de Modelo, Vista, Control (MCV Model, View, Control). Esta arquitectura se basa
en tres
dimensiones
Vista corresponde
principales: Modelo correspondiente

la presentacin o
interaccin
a
con
la informacin,
el
usuario
y Control correspondiente al comportamiento, como se ilustra en la siguiente figura.
50
CAPITULO 3
MODELO DE ANLISIS
Figura 17 Diagrama de tres dimensiones
La vista o presentacin de la informacin corresponde a las interfaces que se le

presentan al usuario para el manejo de la informacin, donde por lo general pueden
existir mltiples vistas sobre un mismo modelo. Tpicamente la informacin representa
el domino del problema y se almacena en una base de datos. Por otro lado, el control
corresponde a la manipulacin de la informacin a travs de diversas presentaciones.
Aunque existe cierta dependencia entre estas tres dimensiones, se considera que la
manera de presentar la informacin es independiente de la propia informacin y de
cmo se controla esta. Sin embargo cada una de ellas probablemente experimente
cambios a lo largo del ciclo de vida del sistema, donde el control es el ms propenso a
ser modificado, seguido de la vista y, finalmente, del modelo.
En correspondencia con el modelo MVC, la arquitectura para el modelo de anlisis se
basara en tres tipos o estereotipos de objetos correspondientes a las tres dimensiones
anteriores. Es importante notar que la correspondencia con la tres dimensiones
utilizadas durante el modelo de requisitos.
51
CAPITULO 3
MODELO DE ANLISIS
3.2 Identificacin de clases segn estereotipos

La arquitectura de objetos debe considerar los tres tipos de estereotipos de objetos.
Para ello se deben identificar primero las clases borde, las clases entidad y finalmente
las de Control.
En general, los cambios ms comunes a un sistema son los de funcionalidad y bordes.
Los cambios de las interfaces deben afectar solo a los objetos borde. Los cambios a la
funcionalidad son ms difciles de administrar, ya que sta puede abarcar todos los
tipos de objetos.
Bordes
Toda la funcionalidad especificada en las descripciones de los casos de uso que
depende directamente de los aspectos externos del sistema, se ubica en los objetos
borde, pues a travs de ellos se comunican los actores con el sistema. La tarea de una
clase borde es traducir los eventos generados por un actor en eventos comprendidos
por el sistema, y traducir los eventos del sistema en una presentacin comprensible
para el actor.
Las clases borde en otras palabras, describen la comunicacin bidireccional entre el
sistema y los actores.
Las clases borde son bastante fciles de identificar, donde se cuenta con al menos tres
estrategias:
1.
Se pueden identificar con base a los actores.
2.
Se pueden identificar con base en las descripciones de las interfaces del sistema
que acompaan al modelo de requisitos.

3.
Se pueden identificar con base en las descripciones de los casos de uso y extraer
la funcionalidad especfica a los objetos bordes.

Estrategia correspondiente a los actores.
Cada actor necesita su propia clase borde para comunicarse con el sistema. En muchos
casos un actor puede necesitar de varios objetos borde. Es evidente que los objetos
borde no son totalmente independientes de cada uno, ya que, en ciertos casos deben
saber la existencia de los dems.
52
CAPITULO 3
MODELO DE ANLISIS
Entidad
Se utilizan objetos entidad para modelar la informacin que el sistema debe manejar a
corto y largo plazo. La informacin a corto plazo existe durante la ejecucin de un caso
de uso, mientras que la informacin a largo plazo trasciende los caso de uso, por lo que
es necesario guardarla en alguna base de datos o archivos.
Durante la identificacin de objeto entidad, se encontrara que objetos que objetos
similares aparecen en varios casos de uso.
Clases entidad:
Validar Usuario: Este casi de uso requiere validar informacin exclusivamente guardada
en el registro de usuario, lo que se hace en la clase entidad RegistroUsuario, utiliza
tambin por el caso de uso RegistroUsuario.
Ofrecer Servicios: Este caso de uso administra las opciones de servicio y no requiere de
ninguna clase entidad.
Registrar Usuario: Este caso de uso requiere guardar informacin exclusivamente
acerca del usuario, lo que se hace en la clase entidad RegistroUsuario.
Registrar Tarjeta: Este caso de uso requiere guardar informacin exclusivamente acerca
de la tarjeta del usuario lo que hace en la clase entidad RegistroTarjeta.
Consultar Informacin: Este casi de uso requiere de toda la informacin relacionada
con consultas. Se puede tomar las clases del dominio del problema y quitar aquellas
relacionadas con registros y reservaciones.
Hacer reservacin: Este caso de uso requiere de la informacin relacionada con
reservaciones. Se pueden tomar las clases del dominio del problema y quitar aquellas
relacionadas con registros.
Pagar Reservacin: Este caso de uso requiere de la informacin relacionada con
reservaciones. Dado que es una extensin al caso de uso Hacer Reservacin, no es
necesario volver a repetir todas las clases entidad, sino ms bien especificar cualquier
clase adicional.
53
CAPITULO 3
MODELO DE ANLISIS
Control
En la mayora de los casos de uso, existe un comportamiento que no se puede asignar
de forma natural a ninguno de los otros dos tipos de objetos ya vistos. Una posibilidad
es repartir el comportamiento entre los dos tipos de objetos, pero la solucin no es
buena si se considera el aspecto de extensibilidad. Un cambio en el comportamiento
podra afectar varios objetos, dificultando su modificacin. Para evitar estos problemas,
tal comportamiento se asigna a objetos control.
Es difcil lograr un buen balance en la distribucin del comportamiento del caso de uso
entre los objetos entidad, borde y control. Los objetos de control normalmente
proveen a administracin de los dems tipos de objetos.
54
CAPITULO 3
MODELO DE ANLISIS
3.3 Clases
Modelo de Anlisis
Un modelo conceptual explica los conceptos ms significativos en un dominio del
problema, identificando los atributos y las asociaciones
En POO se representa mediante un grupo de diagramas de estructura esttica, en este
caso un diagrama de clase
Diagrama de Clases
Son estticos muestran que elementos interactan pero no que sucede cuando ellos
hacen la interaccin. Los diagramas de clase son importantes no solo para la
visualizacin, especificacin y documentacin del modelo estructural, sino tambin
para la construccin de sistemas ejecutables.
Ejemplo
Figura 18 Ejemplo de diagrama de clases
55
CAPITULO 3
MODELO DE ANLISIS
Elementos de un Diagrama de Clase
Figura 19 Elementos de un diagrama de clases
Clase OO
Nombre
Atributos
Mtodos
Figura 20 Diagrama de clase CajeroAutomatico
56
CAPITULO 3
MODELO DE ANLISIS
Relaciones entre Clases

Las relaciones entre clases representan asociaciones del mundo del problema. Las
relaciones entre las clases son conexiones entre dichas clases.
Figura 21 Relaciones entre clases
Relaciones entre Clases

Existen varios tipos de relaciones:
Asociacin
Agregacin
Composicin
Generalizacin(Herencia)
Dependencia
Las relaciones tienen ciertas caractersticas:
Roles
Cardinalidad
Navegabilidad
Asociaciones
Relaciones entre las clases que finalmente sern tambin relacin de objetos
57
CAPITULO 3
MODELO DE ANLISIS
Figura 22 Ejemplo asociacin
Asociacin
Una relacin entre instancias de dos clases independientes entre ellas
Las dos clases son de diferente naturaleza
Figura 23 Ejemplo 2 Asociacin
Hay una asociacin entre dos clases si una instancia de una clase debe conocer de la
otra para poder ejecutar su trabajo
58
CAPITULO 3
MODELO DE ANLISIS
Figura 24 Ejemplo 3 Asociacin
Cardinalidad
La Cardinalidad o multiplicidad de una relacin es el nmero de posibles instancias de
la clase asociada con una simple instancia de la otra clase.
Las cardinalidades pueden ser:
1 Exactamente una instancia
Sin lmite de instancias
0..1 Cero o una instancia
0..* Sin lmite de instancias incluido 0
1..* Al menos una instancia
Figura 25 Ejemplo de Cardinalidad
59
CAPITULO 3
MODELO DE ANLISIS
Navegabilidad-Direccionalidad
La Asociacin es una conexin que tiene direccionalidad, esto es, las clases
involucradas en la relacin se navegan en determinado sentido.
Figura 26 Ejemplo de Navegabilidad
Una flecha de navegabilidad en una asociacin muestra en cual direccin la asociacin

puede ser recorrida consultada.
Relacin Unidireccional
Figura 27 Relacin Unidireccional
Relacin Bidireccional
Figura 28 Relacin Bidireccional
60
CAPITULO 3
MODELO DE ANLISIS
Roles
Una relacin tiene dos puntos finales, estos pueden tener un nombre de rol para
clarificar la naturaleza de la asociacin.
Un cliente solicita muchas rdenes y una orden estaAsociada a un cliente. Una
persona es empleado de una compaa, una compaa es el empleador de una
persona.
Figura 29 Ejemplo Roles
Una clase es una construccin que se utiliza como un modelo (o plantilla) para
crear objetos de ese tipo. El modelo describe el estado y el comportamiento que todos
los objetos de la clase comparten. Un objeto de una determinada clase se denomina
una instancia de la clase. La clase que contiene (y se utiliz para crear) esa instancia se
puede considerar como del tipo de ese objeto. Por ejemplo, una instancia del objeto de
la clase "Persona" sera del tipo "Persona".
Una clase por lo general representa un sustantivo, como una persona, lugar o
(posiblemente bastante abstracta) cosa - es el modelo de un concepto dentro de un
programa de computadora. Fundamentalmente, encapsula el estado y el
comportamiento del concepto que representa. Encapsula el estado a travs de
marcadores de datos llamados atributos (o variable miembro o variables de instancia),
y encapsula el comportamiento a travs de secciones de cdigo reutilizables
llamados mtodos.
61
CAPITULO 3
MODELO DE ANLISIS
3.4 Diagrama de secuencias

Un diagrama de secuencia muestra: Interaccin de un conjunto de objetos en una
aplicacin a travs del tiempo. Un conjunto de mensajes, dispuestos en una secuencia
temporal. Cada rol en la secuencia como una lnea de vida, es decir: una lnea vertical.
Un diagrama de secuencia representa una interaccin como un grfico bidimensional.
La dimensin vertical: es el eje del tiempo.
La dimensin horizontal muestra los roles de clasificador que representan objetos
individuales en la colaboracin.
Un rol de clasificador
Es la descripcin de un objeto que desempea un determinado papel dentro de una
interaccin, distinto de los otros objetos de la misma clase.
La primera utilizacin de los diagramas de secuencia corresponde a la documentacin
de los casos de uso, se concentra en la descripcin de la interaccin,
La segunda utilizacin corresponde a un uso ms informtico y permite la
representacin precisa de las interacciones entre objetos.
Por lo tanto puede mostrar:
Escenario como la historia individual de la transaccin que detalla los casos de uso,
aclarndolos al nivel de mensajes de los objetos existentes, como tambin
El uso de los mensajes de las clases diseadas en el contexto de una operacin.
Cuando est implementado el comportamiento, Cada mensaje en un diagrama de
secuencia. Corresponde a:
Una operacin en una clase, A un evento disparador, o A una transicin en una
mquina de estados.
Cuando est implementado el comportamiento, cada mensaje en un diagrama de
secuencia corresponde a:
62
CAPITULO 3
MODELO DE ANLISIS
Una operacin en una clase, A un evento disparador, o a una transicin en una

mquina de estados
Figura 30 Ejemplo Rol clasificador
Activacin
Es la ejecucin de un procedimiento, incluyendo el tiempo que espera a los
procedimientos anidados para ejecutarse.
Muestra el periodo de tiempo en el cual el objeto se encuentra desarrollando

alguna operacin, bien sea por s mismo o por medio de delegacin a alguno de
sus atributos.
Se denota como un rectngulo delgado sobre la lnea de vida del objeto.
El diagrama siguiente muestra el caso de un objeto A que activa otro objeto B.
Figura 31 Ejemplo de activacin
63
CAPITULO 3
MODELO DE ANLISIS
Mensaje
El mensaje denota el hecho de aportar informacin de un objeto (u otra instancia) a
otro.
Puede ser una seal o llamadas a una operacin.
La notacin para UML del envo de mensajes entre objetos es con una flecha dirigida,
desde el objeto que emite el mensaje hacia el objeto que lo ejecuta.
Cuando el diagrama de secuencia corresponde a un uso ms informtico,

permite la representacin precisa de las interacciones entre objetos.
En este caso el concepto de mensaje unifica todas las formas de comunicacin

entre objetos, en particular la llamada de procedimiento, el evento discreto, la
seal entre flujos de ejecucin o la interrupcin de hardware.
Retorno de una llamada a procedimiento

La flecha de retorno puede suprimirse, por cuanto queda implcita al final de la
activacin
Figura 32 Ejemplo flecha retorno
La flecha que simboliza un mensaje puede representarse oblicua para materializar las
demoras de transmisin respecto a la dinmica general de la aplicacin.
64
CAPITULO 3
MODELO DE ANLISIS
Figura 33 Flecha que simboliza un mensaje
Un objeto puede enviarse un mensaje a s mismo, o sea un mensaje reflexivo que se

representa de la siguiente forma:
Figura 34 Mensaje reflexivo
Ocurre una llamada recursiva cuando el control vuelve a entrar en una operacin en un
objeto, pero la segunda llamada es una activacin separada de la primera.
Figura 35 Llamada recursiva
65
CAPITULO 3
MODELO DE ANLISIS
Lnea de vida de un objeto

La Lnea de vida de un objeto se representa como una lnea vertical punteada con un
rectngulo de encabezado y con rectngulos a travs de la lnea principal que denotan
la ejecucin de mtodos (activacin).
Creacin y destruccin de objetos
La creacin de objetos se representa haciendo apuntar el mensaje de creacin sobre
un rectngulo que simboliza el objeto creado.
La destruccin se indica por el fin de la lnea de vida y por una letra x, bien a la altura
del mensaje que causa la destruccin, o bien tras el ltimo mensaje enviado por un
objeto que se suicida.
Figura 36 Creacin y destruccin de objetos
Los diagramas de secuencia pueden completarse por indicaciones textuales,

expresadas en forma de texto libre o de pseudocdigo.
El instante de emisin de un mensaje llamado transicin, puede tener nombre en el
diagrama cerca del punto de partida de la flecha que simboliza el mensaje. Este
nombre sirve entonces, de referencia, por ejemplo, para construir restricciones
temporales.
Cuando la propagacin de un mensaje toma un tiempo significativo respecto a la
dinmica del sistema, los instantes de emisin y de recepcin de los mensajes se
materializan por un par (nombre, nombre primo).
66
CAPITULO 3
MODELO DE ANLISIS
Ejemplo del diagrama completo
Figura 37 Ejemplo de diagrama de secuencia
67
CAPITULO 3
MODELO DE ANLISIS
3.5 Diccionario de datos

Los diccionarios de datos son el segundo componente del anlisis del flujo de datos. En
s mismos los diagramas de flujo de datos no describen por completo el objeto de la
investigacin. El diccionario de datos proporciona informacin adicional sobre el
sistema. Esta seccin analiza que es un diccionario de datos, por qu se necesita en el
anlisis de flujo de datos y como desarrollarlo. Se utilizar el ejemplo del sistema de
contabilidad para describir los diccionarios de datos.
Un diccionario de datos es una lista de todos los elementos incluido en el conjunto de
los diagramas de flujo de datos que describen un sistema. Los elementos principales en
un sistema, estudiados en las secciones anteriores, son el flujo de datos, el
almacenamiento de datos y los procesos. El diccionario de datos almacena detalles y
descripciones de estos elementos.
Si los analistas desean conocer cuntos caracteres hay en un dato, con qu otros
nombres se le conocen en el sistema, o en donde se utilizan dentro del sistema deben
ser capaces de encontrar las respuestas en un diccionario de datos desarrollado
apropiadamente.
El diccionario de dato se desarrolla durante el anlisis de flujo de datos y ayuda el
analista involucrado en la determinacin de los requerimientos de sistemas. Sin
embargo, como se ver ms adelante, tambin el contenido del diccionario de datos se
utiliza durante el diseo del sistema.
En informtica, base de datos acerca de la terminologa que se utilizar en un sistema
de informacin. Para comprender mejor el significado de un diccionario de datos,
puede considerarse su contenido como "datos acerca de los datos"; es decir,
descripciones de todos los dems objetos (archivos, programas, informes, sinnimos)
existentes en el sistema. Un diccionario de datos almacena la totalidad de los diversos
esquemas y especificaciones de archivos, as como sus ubicaciones. Si es completo
incluye tambin informacin acerca de qu programas utilizan qu datos, y qu
usuarios estn interesados en unos u otros informes. Por lo general, el diccionario de
datos est integrado en el sistema de informacin que describe.
Descripcin de los Datos en el Diccionario
68
CAPITULO 3
MODELO DE ANLISIS
Cada entrada en el diccionario de dato consiste en un conjunto de detalles que

describen los datos utilizados o producidos en el sistema. Cada artculo se identifica
por un nombre de dato, descripcin, sinnimo y longitud de campo y tiene valores
especficos que se permiten para ste en el sistema estudiado.
Nombre de los Datos
Para distinguir un dato de otro, los analista les asigna nombre significativos que se
utilizan para tener una referencia de cada elemento a travs del proceso total de
desarrollo de sistemas. Por lo tanto, debe tenerse cuidado para seleccionar, en forma
significativa y entendible, los nombres de los datos, por ejemplo la fecha de factura es
ms significativa si se llama FECHA FACTURA que si se le conoce como ABCXXX.
Descripcin de los Datos
Establece brevemente lo que representa el dato en el sistema; por ejemplo, la
descripcin para FECHA-DE-FACTURA indica que es la fecha en la cual se est
preparando la misma (para distinguirla de la fecha en la que se envi por correo o se
recibi.
Las descripciones de datos se deben escribir suponiendo que a gente que los lea no
conoce nada en relacin del sistema. Deben evitarse termino especiales o argot, todas
las palabras deben se entendible para el lector
Alias
Con frecuencia el mismo dato puede conocerse con diferentes nombres, dependiendo
de quin lo utilice. El uso de los alias debe evitar confusin. Un diccionario de dato
significativo incluir todos los alias.
Longitud de campo
Cuando las caractersticas del diseo del sistema se ejecuten ms tarde en el proceso
de desarrollo de los sistemas, ser importante conocer la cantidad de espacio que
necesita para cada dato.
Valores de los datos
69
CAPITULO 3
MODELO DE ANLISIS
En algunos procesos solo se permiten valores de datos especficos. Por ejemplo, en

muchas compaas con frecuencia los nmeros de orden de compra se proporcionan
con un prefijo de una letra para indicar el departamento del origen.
Registro de las descripciones de datos
Dadas que las descripciones se utilizarn en forma repetitiva a travs de una
informacin y despus, durante el diseo, se sugiere un formato fcil para utilizar que
simplifique el registro y los detalles de consulta cuando se necesiten.
Ejemplo de diccionario de datos:
cliente
atributo
Tipo
nombre
char
Longitud Llave Descripcin

50 no
Describe el nombre del cliente
id_tarjeta_credito bigint
15 si
direccin
char
50 no
Describe la identificacin de la tarjeta que posee

el cliente
Describe la ubicacin del cliente
telfono
numeric
13 no
Describe el telfono del cliente
Figura 38 Diccionario de datos
70
CAPITULO 3
MODELO DE ANLISIS
3.6. Herramientas CASE para el anlisis

Historia
En la dcada de los setenta el proyecto ISDOS desarrollo un lenguaje llamado "Problem
Statement Language" (PSL) para la solucin de un problema informtico en un
diccionario automatizado. Era un producto de que analizaba los problemas y
necesidades.
La primera herramienta era para PC llamada "Excelerator" en 1984, la oferta de
herramientas es muy amplia como es el EASYCASE o WINPROJECT.
Tecnologa
La tecnologa CASE es la automatizacin del desarrollo software para mejorar la calidad
del sistema de informacin.
Permitir aplicaciones prcticas de metodologas estructuradas, al ser
realizadas con una herramienta consigue agilizar el trabajo.
Facilitar la realizacin de prototipos y desarrollo conjunto de aplicaciones.
Simplificar el mantenimiento de los programas.
Mejorar y estandarizar la documentacin
Aumentar la portabilidad de las aplicaciones.
Facilitar la reutilizacin de componentes software.
Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante
la utilizacin de grficos.
Componentes de una herramienta CASE
Una herramienta case podemos decir que se compone de:
Un diccionario donde se almacenan los elementos creados por la herramienta,
cuya gestin se realiza mediante el apoyo de un sistema de Gestin de base de
datos (SGBD).
El meta modelo, que constituye el marco para la definicin de tcnicas y
metodologas soportadas por la herramienta. No siempre es visible.
La carga o descarga de datos, permiten cargar el repertorio de la herramienta
CASE con datos provenientes de otros sistemas, o generan a partir de la propia
71
CAPITULO 3
MODELO DE ANLISIS
herramienta esquemas de base de datos, programas, pueden alimentar otros

sistemas. Este elemento proporciona un medio de comunicacin con otras
herramientas.
Una comprobacin de errores que permiten llevar a cabo un anlisis de la
exactitud, integridad y consistencia de los esquemas generados por la
herramienta.
Una interfaz de usuario, que constar de editores de texto y herramientas de
diseo grfico que permitan la utilizacin de un sistema de ventanas, iconos y
mens, con la ayuda del ratn, definir los diagramas, matrices.
Estructura general de una herramienta case
La estructura CASE se basa en lo siguiente:
Un CASE de alto nivel es la herramienta que automatiza o apoya las fases
superiores del ciclo de vida del desarrollo de sistemas como la planificacin de
sistemas, el anlisis de sistemas y el diseo de sistemas.
Un CASE de bajo nivel es la herramienta que automatiza o apoya las fases
inferiores del ciclo de vida como el diseo detallado de sistemas, la
implantacin de sistemas y el soporte de sistemas.
Un CASE cruzado de ciclo de vida se aplica a las herramientas que apoyan
actividades a lo largo de todo el ciclo de vida, se incluyen actividades como la
gestin de proyectos y la estimacin.
Estado actual
En las ltimas dcadas se ha trabajado en el desarrollo de sistemas para encontrar
tcnicas para incrementar la productividad y calidad en el proceso de elaboracin del
software, hoy la herramienta CASE (Computer Aided Software Engineering) a
remplazado el papel y lpiz por el ordenador para la transformacin del desarrollo de
software en un proceso automatizado.
La tecnologa CASE supone la automatizacin del desarrollo de software para elevar la
productividad y la calidad en el desarrollo de sistemas anlogas a lo que suponen las
tcnicas CAD/CAM en este enfoque permite mejorar la calidad del software.
72
CAPITULO 3
MODELO DE ANLISIS
La mejora y la estandarizacin de la documentacin.

Facilitar la reutilizacin de componentes de software
Permitir un desarrollo y un refinamiento de las aplicaciones, mediante la
utilizacin de controles grficos.
Integracin de las herramientas case en el futuro
Esta herramienta evoluciona en tres tipos de integracin.
1.
La integracin de datos dispone de herramientas CASE con diferentes

estructuras de diccionarios para el intercambio de datos.
2.
La integracin de presentacin confiere a todas las herramientas CASE el

mismo aspecto.
3.
La integracin de herramientas CASE son capaces de invocar a otras CASE de

forma automtica.
Clasificacin de las herramientas CASE

Las herramientas no tienen una nica clasificacin y es difcil determinarle en una clase
y pueden ser clasificadas de acuerdo a
-
Las plataformas que soportan.
Las fases del ciclo de vida del desarrollo de sistemas que cubren.
La arquitectura de aplicaciones que producen.
Su funcionalidad.
CASE es una combinacin de herramientas software y de metodologas de desarrollo:
La herramienta permite automatizar el proceso de desarrollo del software
La metodologa define los procesos automatizados
La primera clasificacin del CASE:

TOOLKIT: Es la coleccin de herramientas que permiten automatizar un conjunto de
tareas de las fases del ciclo de vida del sistema informtico, planificacin estratgica,
Anlisis, Diseo y Generacin de programas.
73
CAPITULO 3
MODELO DE ANLISIS
WORKBENCH: Son conjuntos de herramientas que dan soporte a la automatizacin del

proceso de desarrollo del sistema informtico. Permiten cubrir el ciclo de vida
completo. El producto final aportado es un sistema en cdigo ejecutable y su
documentacin.
La segunda clasificacin es teniendo en cuenta el ciclo de vida que automatizan:
UPPER CASE: Requerimientos de Desarrollo Funcional de Planes Corporativos.
MIDDLE CASE: Anlisis y Diseo.
LOWER CASE: Generacin de cdigo, e implantacin.
Caractersticas deseables de una CASE
La herramienta CASE cliente/servidor tiene modelo de datos, generacin de cdigo de
ciclo de vida. Las principales herramientas son Knowledge Wares Application
Development Workbench, TIs, Information Engineering Facility (IEF), y Andersen
consultings Foundation for Cooperative Processing.
Deberes de la herramienta CASE:
La herramienta debe proporcionar facilidades de construccin para separar la
aplicacin entre el cliente, servidor y entre servidores.
La herramienta debe crear cdigos para Windows, OS/2 Macintosh, Unix y
plataformas de servidores conocidas, desplegar la versin correcta del cdigo
en la maquina apropiada.
La herramienta debe reconocer las versiones de cdigos que se ejecuta en los
clientes y servidores y que sean consistentes.
La herramienta debe ser capaz de controlar gran nmero de tipos de objetos
incluyendo, texto, grficos, mapas de bits. Debe mantener versiones de objetos
con niveles arbitrarios de granularidad.
La herramienta debe compilar automticamente cdigo 4GL en el servidor.
La herramienta debe adaptarse a los administradores de recursos que existen
en servidores de red su interaccin con los administradores deber ser
negociable a tiempo de ejecucin.
74
CAPITULO 3
MODELO DE ANLISIS
La herramienta trabajar con software intermedia debe adaptar sus

comunicaciones cliente/servidor al software intermedio la herramienta debe
ajustarse basndose si se est moviendo en una LAN o WAN.
La herramienta debe permitir que los diseadores trabajen simultneamente,
debe gestionar los accesos a la base de datos de diferentes usuarios mediante
bloqueos de acceso a archivos o registros.
La herramienta debe realizar mecanismos para controlar el acceso que
contiene, debe tener contrasea y acceso en algunos niveles para diferentes
usuarios, tambin deben facilitar la realizacin automtica de seguridad y
recuperacin de las mismas as como el almacenamiento de grupos de
informacin determinados.
Deben permitir que los grupos de trabajadores deban trabajar en comn, debe
proporcionar mecanismos para compartir las libreras entre distintos
realizadores y mltiples herramientas
75
CAPITULO 4
MODELO DE DISEO

4.1. Estrategias de diseo
El diseo se define como la bsqueda de una solucin en cualquier campo, sin
embargo las soluciones no llegan de una manera simple, muchas veces realizamos
soluciones complejas a problemas sencillos o en otras ocasiones una gran solucin
conlleva a otro problema.
La cuestin est en cmo abordamos esos retos de diseo. Estudios demuestran que
nos enfocamos en resolver los problemas de manera individual alejndonos cada vez
ms del sistema completo en el que estamos trabajando, es como disear una
ventana sin el edificio, recuerden todo tiene un impacto y en un sistema todo est
relacionado.
As que por otro lado que tal si vemos todo el sistema y as planeamos mejor nuestro
diseo, haciendo que las soluciones de una parte no perjudiquen a la otra, o mejor que
se complementen entre s.
Esto nos ayudara a ver qu lugar social, ambiental y tcnico nuestro producto hace
parte. Se recomienda que tengamos en cuenta: Metas ambiciosas que resuelvan varios
problemas, colaboracin a travs de diferentes disciplinas, establecer parmetros base,
definir la vida til, iniciar desde cero los diseos, usar datos medibles y no asumir
reglas entre otros.
En las siguientes imgenes podemos ver un sencillo pero til flujo de trabajo para
iniciar nuestros diseos o la mejora de ellos.
77
CAPITULO 4
MODELO DE DISEO
Figura 4. 1 Estrategia de diseo
Disear es una tarea que involucra muchos aspectos, disear es divertido as que si
utilizamos las herramientas adecuadas podremos crear productos de una mejor
calidad.
78
CAPITULO 4
MODELO DE DISEO
4.2 Diseo de objetos

Para los sistemas es posible definir un diseo en pirmide con las siguientes cuatro
capas:
Subsistema. Contiene una representacin de cada uno de los subsistemas que
le permiten al software conseguir los requisitos definidos por el cliente e
implementar la infraestructura tcnica que los soporta.
Clases y Objetos. Contiene las jerarquas de clases que permiten crear el
sistema utilizando generalizaciones y especializaciones mejor definidas
incrementalmente. Tambin contiene representaciones de diseo para cada
objeto.
Mensajes. Contiene los detalles que permiten a cada objeto comunicarse con
sus colaboradores. Establece las interfaces externas e internas para el sistema.
Responsabilidades. Contiene las estructuras de datos y el diseo algortmico
para todos los atributos y operaciones de cada objeto.
Todo el programa est construido en base a diferentes componentes (Objetos), todo
objeto del mundo real tiene 2 componentes: caractersticas y comportamiento.
Una clase es una plantilla genrica para un conjunto de objetos de similares
caractersticas.
La herencia bsicamente consiste en que una clase puede heredar sus variables y
mtodos a varias subclases.
Por ejemplo:
Los mensajes son invocaciones a los mtodos de los objetos. Esta es una tcnica de
diseo, la cual se caracteriza por la determinacin y delegacin de responsabilidades.
Anlisis orientado a objetos
El modelo del anlisis orientado a objetos ilustra informacin, funcionamiento y
comportamiento.
El diseo orientado a objetos transforma el modelo del anlisis en un modelo de
diseo que sirve como anteproyecto para la construccin de software.
79
CAPITULO 4
MODELO DE DISEO
Modelos del diseo

Estticos. Estructura de subsistemas y/o clases y sus relaciones.
Dinmicos. Se describen las estructuras que muestran la interaccin entre
objetos. Ejemplos de UML: diagramas de secuencia, diagramas de estado.
Son soluciones simples y elegantes a problemas especficos y comunes del diseo
orientado a objetos. Son soluciones basadas en la experiencia y que se ha demostrado
que funcionan.
Tipos: de creacin, estructurales, de comportamiento.
Los objetos en un diseo orientado a objetos estn relacionados con el problema a
resolver. Un proceso general para el diseo orientado a objetos puede contener las
siguientes etapas:
Comprender y definir el contexto y los modos de utilizacin del sistema.
Disear la arquitectura del sistema.
Identificar los objetos principales del sistema.
Desarrollar los modelos de diseo.
Especificar las interfaces de los objetos.
Todas estas actividades se pueden ver como actividades entrelazadas que influyen
entre s. Los objetos se identifican y las interfaces se especifican completa o
parcialmente en el momento de definir la arquitectura del sistema.
80
CAPITULO 4
MODELO DE DISEO
4.3. Diseo de sistema

Durante el diseo de objetos, se ha desarrollado un diseo detallado con base en la
arquitectura especificada. En general, el diseo de sistemas incluye aspectos como los
siguientes:
Seleccin del lenguaje de programacin a utilizarse.
Incorporacin de bibliotecas (para interfaces grficas, estructuras de datos,

etc.)
Incorporacin de una base de datos.
Incorporacin de archivos en sus diferentes formatos.
Consideraciones
de
procesamiento,
como
concurrencia,
paralelismo,
distribucin y tiempo real.

Estos aspectos pueden variar entre un sistema y otro. Adems, pueden afectar de
manera importante la arquitectura final del sistema. Existen diferentes enfoques para
la incorporacin del ambiente de implementacin a la arquitectura del sistema:
Agregar clases abstractas o interfaces que luego se especializarn segn el

ambiente de implementacin.
Instanciar objetos especializados para la administracin del ambiente de

implementacin
Configurar mltiples versiones del sistema correspondientes a diferentes

plataformas.
Diseo de sistema - Lenguajes de programacin
Es importante sealar que un diseo orientado a objetos no necesariamente se tiene

que implementar mediante un lenguaje orientado a objetos. Sin embargo, es ms
natural hacerlo de esta manera. Esto es debido a que los lenguajes orientados a
objetos tienen un apoyo directo a los conceptos del anlisis orientado a objetos
(encapsulamiento, generalizacin, polimorfismo). Sin embargo, se puede traducir
cualquier concepto o mecanismo orientado a objetos a otros existentes en los
lenguajes no orientados a objetos. El problema con este tipo de lenguajes es su
81
CAPITULO 4
MODELO DE DISEO
conveniencia, mantenimiento y proteccin contra errores. Un lenguaje orientado a

objetos hace que la escritura, mantenimiento y extensin de los programas sea ms
fcil y segura.
Cabe mencionar que no todos los lenguajes de programacin orientados a objetos
implementan de la misma forma los conceptos de la metodologa orientada a
objetos. Aspectos como manejo de encapsulamiento, referencias, herencia mltiple
varan
de
manera
importante
entre
los
lenguajes
de
programacin.
Diseo de sistema Interfaces grficas
Las interfaces grficas tienen como objetivo principal administrar la interaccin entre
el usuario mediante elementos grficos, como son botones, mens y textos. Las
aplicaciones interactivas donde el control del ratn y teclado desempean un papel
importante se conocen como sistemas controlados o dirigidos por eventos. Estos
eventos comprenden: mover el ratn, oprimir uno de sus botones, oprimir una tecla,
etc.
Desarrollar un sistema dirigido por eventos significa que la aplicacin desde un inicio
debe considerar un diseo adecuado. Por ejemplo, en Java se escoge alguna de las
bibliotecas grficas (AWT o Swing) para utilizar el manejo apropiado de interfaces
mediante sus clases (JFrame, Jpanel, JButton). Ms all de estas bibliotecas o clases
tambin se afecta la lgica del diseo, ya que se debe contemplar el momento de
procesar eventos.
Por ejemplo, si se desarrolla un sistema con varias pantallas se puede manejar cada
evento mediante una clase para cada pantalla. Otra solucin es usar un JFrame para
todas las pantallas y declarar una clase que maneje los eventos del JFrame. En el
segundo caso, en lugar de que cada pantalla reciba un evento del usuario, se hace que
los eventos sean recibidos por parte de la clase y las pantallas se vuelven ms pasivas y
fciles de manipular.
Diseo de sistema Bases de datos
82
CAPITULO 4
MODELO DE DISEO
Las bases de datos son fundamentales en los sistemas de informacin. Una decisin
estratgica importante en tal contexto es si debe utilizar bases de datos relacionales u
orientados a objetos.
En general se consideran tres modelos de bases de datos principales:
Modelo relacional: se define una coleccin de tablas donde cada una tiene un
nmero especfico de columnas y un nmero arbitrario de filas. Cada objeto se
representa como una fila en una tabla y donde cada columna corresponde a un
atributo distinto en el objeto.
Modelo relacional extendido: el modelo relacional se extiende mediante

procedimientos, objetos, versiones y otras nuevas capacidades. No hay un solo
modelo relacional extendido, ms bien hay una variedad de ellos, aunque todos
comparten las tablas y consultas bsicas del modelo relacional.
Modelo orientado a objetos: se define un modelo orientado a objetos donde

vara el tipo de encapsulamiento de datos y los procedimientos en el objeto. El
trmino orientado a objetos vara segn cada autor.
Las bases de datos son depsitos de datos guardados en uno o ms archivos. Existen
sistemas de manejo de bases de datos (DBMS) y orientados a objetos (OOBDMS). Las
bases de datos dan apoyo en los siguientes aspectos:
Mltiples usuarios
Mltiples aplicaciones
Seguridad
Integridad
Distribucin de datos
La tarea del diseo se simplifica, creando una tabla correspondiente a cada clase
entidad del dominio del problema y manteniendo las asociaciones entre clases.
Obviamente el diseo de tablas puede optimizarse para un acceso ms eficiente.
83
CAPITULO 4
MODELO DE DISEO
Diseo de sistema Archivos
Aunque es ms efectivo trabajar con bases de datos, es posible utilizar archivos, sobre
todo cuando la especificacin del sistema as lo requiera. En el caso de usar una base
de datos, regularmente una clase se comunica con el DBMS para hacer solicitudes a
cualquier tabla. Sin embargo, en el caso de los archivos, tal manejador no existe por lo
que el proceso se hace manualmente.
84
CAPITULO 4
MODELO DE DISEO
4.4. Revisin del diseo

Cuando el diseo se completa se mantienen reuniones con los clientes para revisarlo
antes de avanzar al desarrollo.
El proceso de revisin se realiza en tres etapas en correspondencia con los pasos del
proceso de diseo:
Revisin del diseo preliminar.
Revisin crtica del diseo.
Revisin del diseo de programas.
Revisin del diseo preliminar

Los clientes y usuarios se renen para validar el diseo conceptual. Se asegura que
todos los aspectos relativos a los requerimientos han sido apropiadamente
contemplados en el diseo.
Durante la revisin se presenta a la audiencia el diseo conceptual. Al hacerlo, se
demuestra que el sistema tiene la estructura requerida, las funciones y las
caractersticas especificadas por los documentos de anlisis.
Todos los participantes, en conjunto, verifican que el diseo propuesto incluya el
hardware necesario, interfaces con otros sistemas, entradas y salidas.
Los clientes aprueban los dilogos y mens, los formatos de los informes y el
tratamiento de defectos propuestos.
Revisin crtica del diseo

Realiza una revisin crtica del diseo, donde se presenta una vista general del diseo
tcnico. Se tratan dos puntos:
Si el diseo implementa todos los requerimientos y si es un diseo de
calidad. Usando diagramas, datos o ambas cosas, se explican las estrategias de
diseo alternativa y como y porque se han tomado las principales decisiones de
diseo.
85
CAPITULO 4
MODELO DE DISEO
Si se identifican problemas mayores el diseo se rehace.
Revisin del diseo de programas

Cuando el diseo tcnico resulta satisfactorio, los diseadores de programas estarn en
posicin de interpretarlo como el conjunto de descripciones de diseo para los
componentes reales, que deben ser codificados y probados.
Despus de completar los diseos de programas, pero antes de comenzar la
codificacin, presentan sus planes. Este proceso se centra en la deteccin de defectos
ms que en su correccin. Adems se est evaluando el diseo no a los diseadores.
El proceso beneficia a todos al encontrar defectos y problemas cuando an son fciles
y poco costosos de corregir.
Documentando el diseo
Una parte de la documentacin est dirigido a clientes y usuarios, en lenguaje natural
para describir que es lo que el sistema har.
La segunda parte usa la terminologa tcnica para escribir la estructura del sistema,
datos y funciones.
Pauta de los informes:
Justificacin racional del diseo: donde se delinean las cuestiones crticas y
compromisos que fueron considerados en la generacin del diseo.
Descripcin de los componentes del sistema: una de las secciones debera
indicar cmo interactan los usuarios con el sistema incluyendo:
o Mens y otros formatos de presentacin en pantalla.
o Interfaces hombre mquina.
o Formatos de los informes.
o Entrada: sobre los datos.
o Salida: sobre los datos.
o Caractersticas funcionales generales.
86
CAPITULO 4
MODELO DE DISEO
o Exigencias de performance.
o Procedimientos de archivos.
o Enfoque del tratamiento de defectos
Por lo general, un conjunto de diagramas o de notaciones formales describe la
organizacin y estructura global del sistema, incluyendo todos los niveles de
abstraccin.
Diseo conceptual o del sistema
Se realiza primero, y le dice al cliente que es lo que har realmente el sistema. Una vez
que sea prueba este diseo, se vuelca el trabajo a un trabajo de diseo ms detallado.
El diseo conceptual describe el sistema en un lenguaje que el cliente pueda
comprender, en lugar de usar trminos tcnicos o jergas de computacin. Un buen
diseo conceptual debera tener las siguientes caractersticas:
Se escribe en el lenguaje del cliente.
No contiene expresiones de jerga tcnica.
Describe claramente las funciones del sistema.
Es independiente de la implementacin.
Est vinculado con los documentos del requerimiento.
Diseo tcnico
Permite que los constructores comprendan el hardware y el software concretos que se
necesitan para resolver el problema del cliente. Es decir este diseo describe:
La configuracin de hardware.
Las necesidades de software.
Las interfaces de comunicacin.
Las entradas y salidas del sistema.
La arquitectura de red.
Y cualquier otro aspecto que incida en la transformacin de los requerimientos en una

solucin. El diseo se describe en un nico documento, pero muchas veces se vuelca
en dos.
87
CAPITULO 4
MODELO DE DISEO
Figura 4. 2 Mapa mental del diseo de sistemas
88
CAPITULO 4
MODELO DE DISEO
4.5. Diagramas de secuencias del Diseo

El diagrama de secuencia es un tipo de diagrama usado para modelar interaccin entre
objetos en un sistema segn UML. En ingls se pueden encontrar como "sequence
diagram", "event-trace diagrams", "event scenarios" o "timing diagrams"
Un diagrama de secuencia muestra la interaccin de un conjunto de objetos en una
aplicacin a travs del tiempo y se modela para cada caso de uso. Mientras que el
diagrama de casos de uso permite el modelado de una vista business del escenario, el
diagrama de secuencia contiene detalles de implementacin del escenario, incluyendo
los objetos y clases que se usan para implementar el escenario y mensajes
intercambiados entre los objetos.
Tpicamente se examina la descripcin de un caso de uso para determinar qu objetos
son necesarios para la implementacin del escenario. Si se dispone de la descripcin
de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar
sobre" esos pasos para descubrir qu objetos son necesarios para que se puedan
seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el
escenario con lneas discontinuas verticales, y los mensajes pasados entre los objetos
como flechas horizontales.
Tipos de mensajes
Existen dos tipos de mensajes: sincrnicos y asincrnicos. Los mensajes sincrnicos se
corresponden con llamadas a mtodos del objeto que recibe el mensaje. El objeto que
enva el mensaje queda bloqueado hasta que termina la llamada. Este tipo de
mensajes se representan con flechas con la cabeza llena. Los mensajes asincrnicos
terminan inmediatamente, y crean un nuevo hilo de ejecucin dentro de la secuencia.
Se representan con flechas con la cabeza abierta.
89
CAPITULO 4
MODELO DE DISEO
Figura 4. 3 Diagrama de secuencia Ejemplo
90
CAPITULO 4
MODELO DE DISEO
4.6. Herramientas CASE para el diseo

Concepto de las herramientas CASE
La herramienta CASE (Computer-Aided Systems Engineering ) cuyo significado en
espaol es ingeniera de sistemas asistida por ordenador, es la aplicacin de tecnologa
informtica a las actividades, las tcnicas y las metodologas propias de desarrollo de
sistemas y al igual que las herramientas CAD (Diseo Asistido por Computadora) o CAM
(Manufactura Asistida por Computadora) su objetivo es acelerar el proceso para el que
han sido diseadas, en el caso de CASE para automatizar o apoyar una o mas fases del
ciclo de vida del desarrollo de sistemas. La primera herramienta CASE como hoy la
conocemos fue Excelerator en 1984, era para PC. Actualmente la oferta de
herramientas CASE es muy amplia y tenemos por ejemplo el EASYCASE o WINPROJECT.
Tecnologa de las herramientas CASE
La tecnologa CASE supone la automatizacin del desarrollo del software,
contribuyendo a mejorar la calidad y la productividad en el desarrollo de sistemas de
informacin. Para mejorar la calidad y la productividad de los sistemas de informacin
a la hora de construir software se plantean los siguientes objetivos:
Permitir la aplicacin prctica de metodologas estructuradas, las cuales al ser

realizadas con una herramienta conseguimos agilizar el trabajo.
Facilitar la realizacin de prototipos y el desarrollo conjunto de aplicaciones.
Simplificar el mantenimiento de los programas.
Mejorar y estandarizar la documentacin.
Facilitar la reutilizacin de componentes software.
Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la

utilizacin de grficos.
Componentes de una herramienta CASE

De una forma esquemtica podemos decir que una herramienta CASE se compone de
los siguientes elementos:
91
CAPITULO 4
MODELO DE DISEO
Repositorio (diccionario) donde se almacenan los elementos definidos o

creados por la herramienta, y cuya gestin se realiza mediante el apoyo de un
Sistema de Gestin de Base de Datos (SGBD) o de un sistema de gestin de
ficheros.
Metamodelo (no siempre visible), que constituye el marco para la definicin de

las tcnicas y metodologas soportadas por la herramienta.
Carga o descarga de datos, son facilidades que permiten cargar el repertorio de

la herramienta CASE con datos provenientes de otros sistemas, o bien generar a
partir de la propia herramienta esquemas de base de datos, programas, etc.
que pueden, a su vez, alimentar otros sistemas. Este elemento proporciona as
un medio de comunicacin con otras herramientas.
Comprobacin de errores, facilidades que permiten llevar a cabo un anlisis de

la exactitud, integridad y consistencia de los esquemas generados por la
herramienta.
Interfaz de usuario, que constar de editores de texto y herramientas de diseo

grfico que permitan, mediante la utilizacin de un sistema de ventanas, iconos
y mens, con la ayuda del ratn, definir los diagramas, matrices, etc. que
incluyen las distintas metodologas.
Estructura general de una herramienta CASE

La estructura CASE se basa en la siguiente terminologa:
CASE de alto nivel son aquellas herramientas que automatizan o apoyan las
fases finales o superiores del ciclo de vida del desarrollo de sistemas como la
planificacin de sistemas, el anlisis de sistemas y el diseo de sistemas.
CASE de bajo nivel son aquellas herramientas que automatizan o apoyan las
fases finales o inferiores del ciclo de vida como el diseo detallado de sistemas,
la implantacin de sistemas y el soporte de sistemas.
CASE cruzado de ciclo de vida se aplica a aquellas herramientas que apoyan

actividades que tienen lugar a lo largo de todo el ciclo de vida, se incluyen
actividades como la gestin de proyectos y la estimacin.
92
CAPITULO 4
MODELO DE DISEO
Futuro de las Herramientas CASE

Las herramientas CASE evolucionan hacia tres tipos de integracin:
1. La integracin de datos permite disponer de herramientas CASE con diferentes
estructuras de diccionarios locales para el intercambio de datos.
2. La integracin de presentacin confiere a todas las herramientas CASE el mismo
aspecto.
3. La integracin de herramientas permite disponer de herramientas CASE capaces
de invocar a otra herramienta CASE de forma automtica.
Ejemplo de herramientas CASE de anlisis:
case/4/0 (microTOOL GmbH)

objectiF (microTOOL GmbH)
ProxyDesigner (ProxySource.com)
Cradle (3SL)
DataManager/ControlManager (Allen Systems Group, Inc.)
GDPro (Advanced Software Technologies, Inc.)
ManagerView (Allen Systems Group, Inc.)
objectIF (Computer Systems for Business International Eastern Europe Ltd.)
PacDesign (CGI Systems, Inc.)
Principia/SSADM (British Aerospace Ltd. Software Tools Group)
StP/UML (Aonix)
Vista (Allen Systems Group, Inc.)
Herramientas CASE de Diseo:
MagicDraw UML (No Magic, Inc.)

MEGA Development (MEGA International)
Object Technology Workbench (OTW Software, Inc.)
Object Technology Workbench (OWiS Software GmbH)
OEW 3.0 for C++ and Java (Innovative Software)
SmartDraw (SmartDraw.com)
StP/UML (Aonix)
Visual Case (Artiso Corp)
Wilde (Wilde Technologies)
vsDesigner (Visual Software, Inc.)
Designer (Mentor Graphics Corp.)
DesignMachine 2.0 (Optima, Inc.)
DesignVision 1.7 (Optima, Inc.)
93
CAPITULO 5
MODELO DE IMPLEMENTACIN

5.1 Diagrama de componentes
Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de
Modelado. Un diagrama de componentes representa cmo un sistema de software es
dividido en componentes y muestra las dependencias entre estos componentes.
Los componentes fsicos incluyen archivos, cabeceras, bibliotecas compartidas,
mdulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el
campo de la arquitectura de software pero pueden ser usados para modelar y
documentar cualquier arquitectura de sistema.
Figura 39 Diagrama de componentes
Es un acercamiento basado en la re utilizacin para definir, implementar, y componer,

componentes dbilmente acoplados en sistemas. Un componente de software
individual es un paquete de software, un servicio web, o un mdulo que encapsula un
conjunto de funciones relacionadas (o de datos). Debido a este principio, con
frecuencia se dice que los componentes son modulares y cohesivos. Estas interfaces
pueden ser vistas como una firma del componente - el cliente no necesita saber sobre
los funcionamientos internos del componente (su Implementacin para hacer uso de
ella. Este principio resulta en componentes referidos como encapsulados Tiene como
objetivo convertir el diseo de datos, Interfaces y arquitectura en una representacin
95
CAPITULO 5
Intermedia que se pueda transformar fcilmente
en cdigo fuente. El nivel de
abstraccin debe ser muy prximo al Cdigo.
Programacin estructurada
Notaciones de diseo
Notaciones grficas
Notaciones tabulares
Lenguaje de diseo de programas
Referencias bibliogrficas
Programacin estructurada es una de las tcnica de diseo procedimental ms

Importantes. Se trata de un conjunto de construcciones con las que Se puede restringir
el diseo procedimental de un Software a un nmero de operaciones predecibles.
Tipos de construcciones estructuradas: secuenciales, Condicionales y repetitivas.
96
CAPITULO 5
5.2. Diagrama de despliegue

El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de
Modelado que se utiliza para modelar el hardware utilizado en las implementaciones
de sistemas y las relaciones entre sus componentes.
Los elementos usados por este tipo de diagrama son nodos (representados como un
prisma), componentes (representados como una caja rectangular con dos
protuberancias del lado izquierdo) y asociaciones.
Figura 40 Estructura de diagrama de despliegue
El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de

Modelado que se utiliza para modelar el hardware utilizado en las implementaciones
de sistemas y las relaciones entre sus componentes.
Los elementos usados por este tipo de diagrama son nodos (representados como un
prisma), componentes (representados como una caja rectangular con dos
protuberancias del lado izquierdo) y asociaciones.
En el UML 2.0 los componentes ya no estn dentro de nodos. En cambio, puede haber
artefactos u otros nodos dentro de un nodo. Este tipo de diagrama debemos tambin
aadir que no van a existir actores para relacionarse con los nodos (no es un diagrama
de casos de uso) si no que las relaciones que pueda haber siempre sern entre los
nodos y por ejemplo con una base de datos.
97
CAPITULO 5
Algunos de los usos que se les da a los diagramas de despliegue son para modelar:
Sistemas empotrados: Un sistema empotrado es una coleccin de hardware

con una gran cantidad de software que interacta con el mundo fsico.
Sistemas cliente-servidor: Los sistemas cliente-servidor son un extremo del

espectro de los sistemas distribuidos y requieren tomar decisiones sobre la
conectividad de red de los clientes a los servidores y sobre la distribucin fsica
de los componentes software del sistema a travs de nodos.
Sistemas completamente distribuidos: En el otro extremo encontramos

aquellos sistemas que son ampliamente o totalmente distribuidos y que
normalmente incluyen varios niveles de servidores. Tales sistemas contienen a
menudo varias versiones de componentes software, alguno de los cuales
pueden incluso migrar de un nodo a otro. El diseo de tales sistemas requiere
tomar decisiones que permitan un cambio continuo de la topologa del sistema.
Figura 41 Diagrama de despliegue
98
CAPITULO 5
5.3. Modelos de prueba

La fase de pruebas del sistema tiene como objetivo verificar el sistema software para
comprobar si este cumple sus requisitos. Dentro de esta fase pueden desarrollarse
varios tipos distintos de pruebas en funcin de los objetivos de las mismas. Algunos
tipos son pruebas funcionales, pruebas de usabilidad, pruebas de rendimiento,
pruebas de seguridad, etc. Este trabajo se centra en pruebas funcionales de
aplicaciones con interfaces grficas. Estas pruebas verifican que el sistema software
ofrece a los actores humanos la funcionalidad recogida en su especificacin.
Este trabajo describe los modelos necesarios para generar de manera sistemtica un
conjunto de pruebas que permitan verificar la implementacin de los requisitos
funcionales de un sistema software.
Figura 42 Modelo de implementacin
Una de las tcnicas ms empleadas para la especificacin funcional de sistemas

software son los casos de uso. Las principales ventajas de los casos de uso son que
ocultan los detalles internos del sistema, son rpidos de construir, fciles de modificar y
entender por los clientes y futuros usuarios del sistema y pueden aplicarse a distintos
99
CAPITULO 5
tipos de sistemas y Actualmente, existe un amplio nmero de propuestas que

describen cmo generar pruebas del sistema a partir de los casos de uso.
Aunque la generacin de pruebas se adapta a la filosofa propuesta por MDA, tal y
como mostraremos a continuacin, ninguna de estas propuestas define su proceso en
base a las tcnicas de MDA. Por este motivo, una de las principales carencias es la falta
de modelos que recojan la informacin necesaria en el proceso de generacin de
pruebas.
Modelos de requisitos
Los nicos modelos de requisitos necesarios son los casos de uso y los requisitos de
almacenamiento, aunque otros modelos, como por ejemplo modelos de interfaces o
modelos de navegacin pueden enriquecer el proceso de prueba. Actualmente existen
varias propuestas de modelos de requisitos.
Modelo de comportamiento
Un gran nmero de tcnicas de requisitos estn basadas en casos de uso definidos en
prosa. Uno de ellos es el modelo Web reutilizado en el punto anterior. Pero no es
sencillo manipular programticamente casos de uso escritos en prosa. Por este motivo,
el primer paso de nuestro proceso sistemtico de generacin de pruebas consiste en
expresar dicha prosa mediante un modelo formal manipulable de manera automtica.
Modelo de datos de prueba
Los casos de uso contienen elementos variables cuyos valores o comportamiento
difiere de una ejecucin de un caso de uso a otra. Algunos ejemplos son la informacin
suministrada por un actor, una opcin seleccionada por un actor, o la informacin
mostrada por el sistema como resultado del caso de uso.
Modelo de interfaz abstracta
Los modelos anteriores nos indican lo que una prueba debe hacer (ejecutar un
escenario posible de un caso de uso), qu informacin hay que suministrarle y qu
informacin nos va a devolver. Sin embargo estos modelos an son demasiado
abstractos y no se pueden convertir en modelos dependientes de la plataforma ni en
100
CAPITULO 5
pruebas ejecutables de manera directa. Por este motivo, a partir de los modelos
anteriores, se obtienen los modelos de interfaz abstracta y de interaccin.
Modelo de interaccin
Una vez que se conocen las interfaces con las que las pruebas interactuarn,
expresadas mediante el modelo de interfaz abstracta, se refina el modelo de
comportamiento para indicar cmo realizar cada uno de los pasos del caso de uso
sobre dicha interfaz.
101
BIBLIOGRAFIA
Bibliografa
Betancourt, A. (2 de Enero de 2013). Blog. Recuperado el 4 de Diciembre de 2013, de
Blog: http://blog.acaddemia.com/estrategias-de-diseno/
Cruz, I. d. (21 de Junio de 2013). Blogspot. Recuperado el 4 de Noviembre de 2013, de
Blogspot: http://unidad5-modeloimplenacionisrael.blogspot.mx/2013/06/modelo-de-implementacion.html
E.K., K. (2005). Anlisis y Diseo de sistemas. Mxico: Prentice Hall.
Hernandez, P. M. (9 de Febrero de 2013). Plantilla Awesome Inc. Recuperado el 16 de
Octubre de 2013, de Plantilla Awesome Inc.: http://unidad4modelodiseno.blogspot.mx/2013/05/43-diseno-de-sistema.html
Pressman, R. (2008). Ingenierpia del Software un enfoque prctico. Madrid, Espaa: Mc
Graw Hill.
Wikimedia Inc. (18 de Noviembre de 2013). Wikipedia. Recuperado el 4 de Diciembre
de 2013, de Fundacin Wikimedia Inc.:
http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_requisitos
102

Apuntes Fundamentos de Ingenieria de Software

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apuntes Fundamentos de Ingenieria de Software

Enviado por

Direitos autorais:

Formatos disponíveis

Recibimos sabidura, legaremos desarrollo

Cd. Lzaro Crdenas, Mich. 12 de agosto de

Figura 32 Ejemplo flecha retorno ................................................................................... 64

FUNDAMENTOS DE INGENIERA DE SOFTWARE

Captulo 1 Fundamentos de ingeniera de software

Es la capacidad de separar aspectos importantes de detalles. Una

abstraccin define una delimitacin relativa a la perspectiva del observador.

Accin. Es un procedimiento algortmico o computacional.

Acoplamiento. Es la cantidad de relaciones que se establecen entre los mdulos de un

Algebra Heterognea. Es una coleccin de conjuntos junto a sus operaciones.

Algebra Homognea. Es un solo conjunto y varias operaciones.

Anlisis. Es la parte del proceso de desarrollo de software cuyo propsito principal es

Arquitectura. Consiste en la estructura organizacional de un sistema. Una arquitectura

Instituto Tecnolgico de Lzaro Crdenas | I.S.C

FUNDAMENTOS DE INGENIERA DE SOFTWARE

Adaptabilidad. Facilidad con la que un sistema o un componente pueden modificarse

Aplicacin de software. Software diseado para satisfacer las necesidades de un

mantenimiento, y, en ocasiones, retirada. Nota: Esta fases pueden superponerse o

Instituto Tecnolgico de Lzaro Crdenas | I.S.C

FUNDAMENTOS DE INGENIERA DE SOFTWARE

Calidad de Software. Es la concordancia con los requerimientos funcionales y de

explcitamente documentados y con las caractersticas implcitas que se esperan de todo

Cardinalidad. Es aquello que indica el nmero de elementos en un conjunto o la

CASE Tools. Es un conjunto de herramientas semiautomatizadas y automatizadas para

Clase asociacin (association class). Es un elemento de modelado que tiene

Codificacin. (1) Proceso de descripcin de un programa de ordenador en un lenguaje

FUNDAMENTOS DE INGENIERA DE SOFTWARE

Comit de gestin de configuracin (CGC). Grupo de personas responsable de

Compatibilidad. (1)Preparacin de dos o ms componentes o sistemas para llevar a

Crisis del software. Trmino acuado en 1968, en la primera conferencia de la NATO

Crystal Methods. Metodologa heterodoxa para desarrollo de software, creada por

FUNDAMENTOS DE INGENIERA DE SOFTWARE

software es una actividad de ingeniera. Esa comparacin es de hecho ms perniciosa

Descripcin del sistema. Documento orientado al cliente que describe las

Datamart. Es un subconjunto de un datawarehousing para un tema especfico consiste

Dataming. Es un proceso analtico que establece reglas que permiten establecer

Datawarehousing. Es un conjunto de datos integrados orientados a una materia, que

Diagrama de Actividades. Es un caso especial de diagrama de estados en el que todos,

Instituto Tecnolgico de Lzaro Crdenas | I.S.C

FUNDAMENTOS DE INGENIERA DE SOFTWARE

Diagrama de Clases. Es el diagrama que muestra una coleccin de elementos del

Diagrama de Colaboraciones. Es un diagrama que muestra interacciones entre objetos

Diagrama de Entidad / Relacin. Es una descripcin conceptual de las estructuras de

Diagrama de Flujo de Datos. Es una descripcin informal del sistema de informacin.

Diagrama de Interacciones. Es un trmino genrico que se aplica a diversos tipos de

Diagrama de Objetos. Es un diagrama que contiene los objetos y sus relaciones en un

Diagrama de Secuencia. Es el diagrama que muestra los objetos que participan en la

Instituto Tecnolgico de Lzaro Crdenas | I.S.C

FUNDAMENTOS DE INGENIERA DE SOFTWARE

Diseo. Es la parte del proceso de desarrollo de software cuyo propsito principal es

Dominio. Es un rea de conocimiento o actividad caracterizada por un conjunto de

Diseo de arquitectura. (1) Proceso que define una coleccin de componentes de

Diseo detallado. (1) Proceso de definicin y ampliacin del diseo preliminar de un

Diseo preliminar (1) Proceso de anlisis de las alternativas de diseo y definicin de

Elemento de configuracin. Parte de un desarrollo de software (planes, software,

FUNDAMENTOS DE INGENIERA DE SOFTWARE

Escalabilidad. Facilidad con la que un sistema o un componente puede modificarse

Especificacin de requisitos de software. Documentacin de requisitos fundamentales

Extreme Programming. Metodologa heterodoxa de programacin. Es la ms popular

Fallo. Es cualquier no concordancia con los requerimientos del software.

Instituto Tecnolgico de Lzaro Crdenas | I.S.C

FUNDAMENTOS DE INGENIERA DE SOFTWARE

Flexibilidad. Facilidad con la que un sistema o un componente puede modificarse para