Post on 03-Feb-2023
1
INSTITUTO TECNOLÓGICO
DE LÁZARO CÁRDENAS
CD. Y PUERTO DE LÁZARO CÁRDENAS, MICHOACÁN.
SEP
DGEST SES
Monografía
FUNDAMENTOS DE INGENIERIA DE SOFTWARE
Presenta: Rosa Esperanza Pacheco Ramírez
Tzitziki Erandi Figueroa Robledo Daniel Alejandro Vázquez Márquez
Miguel Ángel Alvar Pantaleón
Numero de control: 11560398 10560628 10560413 10560235
Profesor:
Jesús Daniel Rojas Cid.
Av. Melchor Ocampo # 2555, Col. Cuarto Sector, C.P. 60950, Cd. Lázaro Cárdenas, Michoacán, Teléfono (753) 53 7 19 77, 53 2 10 40, 53 7 53 91, 53 7 53 92 Dirección Ext. 109, Fax. 108
e-mail: direccion@itlac.mx Internet: www.itlazarocardenas.edu.mx.
2
Indice de conceptos ............................................................................................................................................................................................................................................................... 1
1 Fundamentos Ingeniería de software,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,4
1.1 Conceptos básicos………………………………………………………………………..4
1.2 El papel evolutivo del software………………………………………………………….5
1.3 Etapas del desarrollo software……………………………………………………....7
1.4 Clasificación de la tecnología en el desarrollo de software (T.O.O)…………………….9
1.5 Definición e historia de la herramienta case……………………………………………11
1.6 Clasificación de las herramientas case…………………………………………………13
2 Ingeniería de Requisitos…………………………………………………………………15
2.2 Técnicas de la ingeniería de requisitos…………………………………………………25
2.3 Modelado de requisitos……………………………………………………...................28
2.4 Herramientas case para la ingeniería de requisito……………………………………..29
o 2.4.1.-Mapa conceptual Ingeniería de requisitos…………………………………………...31
o 2.4.2.-Tareas de ingeniería de requisitos para la documentación de proyectos…………….33
o 2.4.3.-Documentar un caso de desarrollo para las tareas de requisitos…………………….34
o 2.4.4. Técnicas de la ingeniería de requisitos………………………………………………35
o 2.4.5.-Aplicar las técnicas en el proyecto de investigación………………………………...38
2.4.6. Modelado de requisitos………………………………………………………………38
3 Modelo de análisis………………………………………………………………………40
3.1.- Arquitectura de clases…………………………………………………………………40
3.2.- Identificación de clases según estereotipos…………………………………………...41
3.3Las clases………………………………………………………………………………..43
3.4.- Diagramas de secuencia……………………………………………………………….44
3.5.-Diccionario de clases según módulos…………………………………………………..46
3
Índice de figuras 1 Figura……………………………………………………………………………………………………7
2 Figura…………………………………………………………………………………………...………|0
3 Figura………………………………………………………………………………………………..…11
4 Figura…………………………………………………………………………………………….……14
5 Figura………………………………………………………………………………………………..…|7
6 Figura……………………………………………………………………………………………….…31
7 Figura………………………………………………………………………………….………………32
4
1 Fundamentos Ingeniería de software
1.1 Conceptos básicos
A. Ingeniería: Es la profesión en la que el conocimiento de las ciencias naturales y
matemáticas obtenidas con el estudio, la práctica y la experiencia se aplica con
juicio para desarrollar formas de utilizar de modo económico, los materiales y
fuerzas de la naturaleza para beneficio de la humanidad
B. Software: Es el conjunto de todos los programas que existen dentro de una
computadora. Es el producto del desarrollo que realizan los ingenieros de software
resultado de requerimientos de información.
C. La Ingeniería de Software: Es una disciplina de la Ingeniería que comprende todos
los aspectos de la producción del software desde las etapas iniciales de la
especificación del sistema hasta el mantenimiento de éste después de que se libera.
La Ingeniería de Software incluye: Personas (quién lo hace) proceso (la manera en
que se hace) proyecto (la realización) producto (la aplicación de artefactos).
D. Software de Sistemas: Conjunto de programas escritos para dar servicio a otros
programas. Determinado software de sistemas (por ejemplo, compiladores, editores
y herramientas para administrar archivos) procesa estructuras de información
complejas pero deterministas.
E. Software de aplicación: El software de aplicación consiste en programas
independientes que resuelven una necesidad de negocios específica. Las
aplicaciones en esta área procesan datos empresariales o técnicos de forma que
facilitan las operaciones de negocios o la toma de decisiones técnicas o de gestión.
F. Software científico y de ingeniería: El software científico y de ingeniería, que se
caracterizaba por algoritmos “devoradores de números”, abarca desde la astronomía
hasta la vulcanología, desde el análisis de la tensión automotriz hasta la dinámica
orbital de los transbordadores espaciales, y desde la biología molecular hasta la
manufactura automatizada.
5
G. Software emportado: El software emportado reside dentro de la memoria de sólo
lectura del sistema y con él se implementan y controlan características y funciones
para el usuario final y el sistema mismo.
1.2 El papel evolutivo del software
El software tiene un papel dual. Es producto y canal de distribución de este. Como
producto, ofrece la potencia de cómputo presentada como hardware de una computadora o,
de manera más global por una red de computadoras accesible mediante hardware local y de
acceso físico. Este es un transformador de información; realiza la producción, el manejo, la
adquisición, la modificación, el despliegue o la transmisión de la información que puede ser
tan simple como un solo bit o tan compleja como una presentación multimedia.
El papel del software de computadora ha experimentado un cambio significativo en un
periodo un poco mayor a 50 años. Las mejorías sustanciales en el desempeño del hardware,
los cambios profundos en las arquitecturas de cómputo, los enormes incrementos en las
capacidades de memoria y almacenamiento, y la amplia variedad de opciones de salida y
entrada han propiciado el surgimiento de sistemas más elaborados y complejos basados en
computadoras.
6
PRIMERA ERA (1950 / 1965)
Se trabajaba con la idea de “Codificar y Corregir”.
No existía un planteamiento previo.
No existía documentación de ningún tipo.
Existencia de pocos métodos formales y pocos creyentes en ellos.
Desarrollado a base de prueba y error
SEGUNDO ERA (1965 – 1972)
Se busca simplificar código.
Aparición de Multiprogramación y Sistemas Multiusuarios.
Sistemas de Tiempo Real apoyan la toma de decisiones. Aparición de Software como
producto. (Casas de Software).
Se buscan procedimientos para el desarrollo del Software.
TERCERA ERA (1972 – 1985)
Nuevo Concepto: Sistemas Distribuidos.
Complejidad en los Sistemas de Información.
Aparecen: Redes de área local y global, y Comunicadores Digitales.
Uso de Microprocesadores.
CUARTA ERA (1985 - 1995)
Impacto Colectivo de Software.
Aparecen: Las Redes de Información, Tecnologías Orientadas a Objetos.
Aparecen: Redes Neuronales, Sistemas Expertos y SW de Inteligencia Artificial.
La información como valor preponderante dentro de las Organizaciones.
QUINTA ERA (2000 hasta hoy en día)
Utiliza algunos requisitos de las eras anteriores solo que aumenta la omnipresencia de la
web, la reutilización de información y componentes de software.
Codificar: Transformar mediante las reglas de un código la formulación de un mensaje.
Hardware: Componente físico de la computadora. Por ejemplo: el monitor, la impresora o
el disco rígido. El hardware por sí mismo no hace que una máquina funcione.
Multiprogramación: Se denomina multiprogramación a la técnica que permite que dos o
más procesos ocupen la misma unidad de memoria principal y que sean ejecutados al
"mismo tiempo“
7
1.3 Etapas del desarrollo software
La ingeniería 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:
1. Análisis
2. Diseño
3. Programación
4. Pruebas
5. Implementación
6. Mantenimiento
7. Fin del Ciclo
1 Figura
Etapa de Análisis:
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 integrarán el
producto.
Etapa de Diseño:
Es el proceso de utilizar la información
recolectada en la etapa de análisis al diseño
del producto. La principal tarea de la etapa
de diseño es desarrollar un modelo o las
especificaciones para el producto o
Componentes del Sistema.
8
Etapa de Desarrollo:
Consiste en utilizar los modelos creados
durante la etapa de diseño para crear los
componentes del sistema.
Etapa de Pruebas o Verificación Prueba:
Consiste en asegurar que los componentes
individuales que integran al sistema o
producto, cumplen con los requerimientos
de la especificación creada durante la etapa
de diseño.
Etapa de Implementación o Entrega
Implantación:
Consiste en poner a disposición del cliente
el producto.
Etapa de Mantenimiento:
Consiste en corregir problemas del
producto y re- liberar el producto como una
nueva versión o revisión (producto
mejorado).
9
Etapa final EOL (End-of-Life):
El fin del ciclo del producto consiste en
realizar todas las tareas necesarias para
asegurar que los clientes y los empleados
están conscientes de que el producto ya no
será vendido ni soportado.
1.4 Clasificación de la tecnología en el desarrollo de software (tecnología estructurada
y orientada a objetos).
TECNOLOGÍA DE SOFTWARE
Conjunto integrado de notaciones, herramientas y métodos, basados en unos sólidos
fundamentos, que permiten el desarrollo de un producto software en un contexto
organizativo dado.
TECNOLOGÍAS DE DESARROLLO ESTRUCTURADO
Las tecnologías de desarrollo estructurado son las más convencionales de las empleadas
hoy día. Han surgido de la evolución de las ideas de programación estructurada (hace más
de veinticinco años) hacia las fases iniciales del ciclo de vida.
La idea base de esta tecnología es que es posible estructurar el modelo de un sistema de
software en base a funciones que procesan información que reciben de otras funciones
(o del exterior) y dirigen la información. Procesada a otros módulos funcionales (o
al exterior).El enfoque seguido, por tanto, es el de pensar en las funciones del sistema
necesarias (extraídas de los requisitos del sistema) y luego en los datos que requieren.
10
2 Figura
TECNOLOGÍAS ORIENTADAS A OBJETOS
Las tecnologías de desarrollo estructurado han demostrado sus limitaciones a la hora de
organizar y facilitar la evolución de sistemas de software complejos. La descomposición en
funciones hace difícil al diseñador mantener la relación con los objetos del mundo real
sobre los que se modifican generalmente los requisitos del usuario.
En ellas, un objeto es un conjunto de datos y funciones de manipulación de los mismos
encapsulados en una unidad que es posible tratar como un todo (crear, copiar, destruir,
etc.). Un objeto posee unas operaciones visibles a otros objetos aunque éstos no conocen
cómo están implementadas.
11
3 Figura
1.5 Definición e historia de la herramienta case
HERRAMIENTA CASE
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: Investigación Preliminar, Análisis, Diseño,
Implementación e Instalación.
CASE se define también como:
Conjunto de métodos, utilidades y técnicas que facilitan la automatización del ciclo de vida del
desarrollo de sistemas de información, completamente o en alguna de sus fases.
La sigla genérica para una serie de programas y una filosofía de desarrollo de software que ayuda a
automatizar el ciclo de vida de desarrollo de los sistemas.
Una innovación en la organización, un concepto avanzado en la evolución de tecnología con un
potencial efecto profundo en la organización. Se puede ver al CASE como la unión de las
herramientas automáticas de software y las metodologías de desarrollo de software formales.
12
HISTORIA
Año
1970
Ya en los años 70 un proyecto llamado ISDOS diseñó un lenguaje y
por lo tanto un producto que analizaba la relación existente entre los
requisitos de un problema y las necesidades que éstos generaban, Aunque ésos son los inicios de las
herramientas informáticas que ayudan a crear nuevos proyectos informáticos
Año
1982
La primera herramienta comercial se remonta a 1982, aunque algunos especialistas indican que
algunos ejemplos de herramientas para diagramación ya existían.
Año
1984
La primera herramienta CASE fue Excelerator que salió a la luz en el año 1984 y trabajaba bajo una
plataforma PC.
Año
1985
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 serían beneficiadas por la ayuda de las CASE. Estos beneficios consistían, por ejemplo,
en el aumento en la productividad. El objetivo en 1985 para muchos vendedores era producir software
más rápidamente.
Año
1990
Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época en la que IBM había
conseguido una alianza con la empresa de software AD/Cycle para trabajar con sus mainframes, estos dos
gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de vida del software. Pero poco a poco
los mainframes han ido siendo menos utilizados y actualmente el mercado de las Big CASE ha muerto
completamente abriendo el mercado de diversas herramientas más específicas para cada fase del ciclo de vida
del software.
13
Objetivos
*Mejorar la productividad en el desarrollo y mantenimiento del software.
*Aumentar la calidad del software.
*Reducir el tiempo y costo de desarrollo y mantenimiento de los sistemas informáticos.
*Mejorar la planificación de un proyecto
*Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de
soluciones para los requisitos.
*Automatizar el desarrollo del software, la documentación, la generación de código, las pruebas de
errores y la gestión del proyecto.
*Ayuda a la reutilización del software, portabilidad y estandarización de la documentación
*Gestión global en todas las fases de desarrollo de software con una misma herramienta.
*Facilitar el uso de las distintas metodologías propias de la ingeniería del software.
1.6 Clasificación de las herramientas case
Case: No existe una única clasificación de herramientas CASE y, en ocasiones, es difícil incluirlas
en una clase determinada. Podrían clasificarse atendiendo a:
• 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
Las herramientas CASE, en función de las fases del ciclo de vida abarcadas, se pueden agrupar de
la forma siguiente:
Herramientas integradas, I-CASE (Integrated CASE, CASE
integrado):
Abarcan todas las fases del ciclo de vida del desarrollo de
sistemas. Son llamadas también CASE workbench.
Herramientas de alto nivel, U-CASE (Upper CASE - CASE
superior) o front-end, orientadas a la automatización y
soporte de las actividades desarrolladas durante las primeras
fases del desarrollo:
Análisis y diseño.
Herramientas de bajo nivel, L-CASE (Lower CASE - CASE
inferior) o back-end, dirigidas a las últimas fases del
desarrollo:
Construcción e implantación.
Juegos de herramientas o Tools-Case
Son el tipo más simple de herramientas CASE.
Automatizan una fase dentro del ciclo de vida. Dentro de
este grupo se encontrarían las herramientas de
reingeniería, orientadas a la fase de mantenimiento
15
2 Ingeniería de Requisitos
2.1 Tareas de la ingeniería de requisitos
La ingeniería de requisitos proporciona el mecanismo apropiado para entender lo que el
cliente quiere, analizar las necesidades, evaluar la factibilidad, negociar una solución
razonable, especificar la solución sin ambigüedades, validar la especificación, y administrar
los requisitos conforme éstos se transforman en un sistema operacional.
INICIO
Tiene por objetivo identificar el ámbito general del proyecto. Comienza con una serie de
conversaciones informales entre los participantes del mismo (cliente, usuarios, grupo de
desarrollo).
Esta fase suele estar acompañada de los documentos de definición de la visión global y la
visión de dominio del sistema.
En algunos casos una conversación informal es todo lo que se necesita para precipitar un
esfuerzo importante de ingeniería del software. Pero en general, la mayoría de los proyectos
comienza cuando se identifica una necesidad de negocios o se descubre un nuevo mercado
o servicio potencial.
Al inicio del proyecto los ingenieros de software hacen una serie de preguntas libres de
contexto, el objetivo es establecer una comprensión básica del problema, las personas que
quieren una solución, la naturaleza de la solución que se desea, y la efectividad de la
comunicación preliminar entre el cliente y el desarrollador.
16
OBTENCIÓN
Sugiere a los ingenieros actividades de recopilación de requisitos de manera organizada.
Parece muy simple preguntar al cliente, a los usuarios y otros interesados cuáles son los
objetivos para el sistema o producto, que es lo que se debe lograr, de que forma el producto
satisface las necesidades del negocio y por último como se utilizara el sistema o producto
día a día. Pero no es simple, es muy difícil ya que se identifican una serie de problemas que
ayudan a entender porque es difícil la obtención de requisitos:
Problema de ámbito: El límite del sistema está mal definido o los clientes/usuarios
especifican detalles técnicos innecesarios que pueden confundir, en lugar de
clarificar, los objetivos generales del sistema.
Problemas de comprensión: Los clientes/usuarios no están seguros por completo de
que es lo se necesita, comprenden poco acerca de las capacidades y limitaciones de
sus ambiente de computo, no comprende del todo dominio del problema, tienen
dificultades al comunicar necesidades al ingeniero de sistema, omiten información
que consideran “obvia”, especifican requisitos que chocan con las necesidades de
otros clientes/usuarios, o especifican requisitos ambiguos o inestable.
Problemas de volatilidad: Los problemas cambiara conformé transcurre el tiempo.
Para ayudar a superar estos problemas, los ingenieros de requisitos deben realizar en
forma organizada la actividad de recopilación de requisitos
17
ELABORACIÓN
Los ingenieros de software crean un modelo de análisis con la información obtenida
del cliente en las fases de inicio y obtención. El modelo de análisis define el
dominio de la información, las funciones y el compartimiento del problema.
La información conseguida con el cliente durante el inicio y obtención se expande y
se refina durante la elaboración. Esta actividad de la ingeniería de requisitos se
enfoca en el desarrollo de un modelo técnico refinado de las funciones,
características y restricciones del software.
Actividades de Aprendizaje
Actividades para la obtención de requerimientos.
5 Figura
4.4.1 Identificación de los actores.
Los actores representan entidades externas que interactúan con el sistema. Un actor puede
ser un sistema humano o uno externo. Los actores definen clases funcionales.
Los actores son abstracción de papeles y no
necesariamente tienen una correspondiente directa con personas.
4.4.2 Identificación de escenarios
Un escenario es “una descripción narrativa de lo que la gente hace y experimenta cuando
trata de utilizar sistemas y aplicaciones de computadora”. Un escenario es una descripción
concreta, enfocada e informal de una sola característica del sistema desde el punto de vista
de un solo actor. El uso de escenarios para la obtención de requerimientos es una
desviación conceptual con respecto a las representaciones tradicionales que son genéricas y
abstractas. Las representaciones tradicionales se centran en el sistema y no en el trabajo al
cual da apoyo el sistema. Su enfoque es la suficiencia, consistencia y precisión, mientras
que los escenarios son abiertos e informales.
18
Los escenarios tal como son describen una situación actual. Durante la reingeniería
se comprende al sistema actual observando a los usuarios y describiendo sus
acciones como escenarios
Los escenarios visionarios describen un sistema futuro, ya sea que se le esté
aplicando reingeniería o se esté diseñando a partir de cero. Los escenarios
visionarios pueden verse como un prototipo barato.
Los escenarios de evaluación describen las tareas del usuario contra las que se va a
evaluar el sistema. La colaboración por parte de usuarios y desarrolladores para la
elaboración de los escenarios de evaluación también mejora la definición de la
funcionalidad que se prueba mediante estos escenarios.
Los escenarios de entrenamiento son cursos prácticos que se usan para introducir a
los nuevos usuarios al sistema. Son instrucciones paso a paso para llevar de la mano
al usuario a través de tareas comunes.
19
4.4.3 Identificación de Caso de Uso
Un escenario es una instancia de un caso de uso, esto es, un caso de uso especifica todos los
escenarios posibles para una parte de funcionalidad dada. Un caso de uso es iniciado por un
actor.
Ejemplo de caso de uso: el caso de uso ReportarEmergencia
4.4.3 Refinamiento de los casos de uso
La figura 4-7 es una versión refinada del caso de uso ReportarEmergencia. Ha sido
ampliada para incluir detalles acerca del tipo de incidente que conoce FRIEND e
interacciones detalladas que indican la manera en el que el Despachador da el acuse de
recibo al OficialCampo.
20
4.4.5 Identificación de las Relaciones entre actores y casos de uso
Las relaciones entre actores y casos de uso permiten que los desarrolladores y usuarios
reduzcan la complejidad del modelo e incrementen su comprensibilidad. Usarnos las
relaciones de comunicación entre actores y casos de uso para describir el sistema en capas
de funcionalidad. Usamos relaciones extendidas para separar el flujo común de eventos del
excepcional. Usamos relaciones de inclusión para reducir la redundancia entre casos de uso.
Relaciones de comunicación entre actores y casos de uso
Las relaciones de comunicación entre actores y casos de uso representan el flujo de
información durante el caso de uso. Se debe distinguir entre el actor que inicia el caso de
uso y los demás actores con los que se comunica el caso de uso. Por 10 tanto, el control de
acceso (es decir, cuál actor tiene acceso a cuál funcionalidad de clase) puede representarse
a este nivel. Las relaciones entre actores y casos de uso se identifican cuando se identifican
los casos de uso. La figura 4-8 muestra un ejemplo de relaciones de comunicación en el
caso del sistema FRIEND.
21
Relaciones extendidas entre casos de uso
Un caso de uso extiende otro caso de uso si el caso de uso extendido puede incluir el
comportamiento de la extensión bajo determinadas condiciones. En el ejemplo FRIEND,
suponga que se corta la conexión entre la estación del OficialCampo y la estación del
Despachador mientras el OficialCampo está llenando el formulario (por ejemplo, el
automóvil del OficialCampo entra a un túnel). La estación del OficialCampo necesita
comunicarle al OficialCampo que su formulario no fue entregado y las medidas que debe
tomar.
Relaciones de inclusión entre casos de uso
Las redundancias entre casos de uso pueden factorizarse usando relaciones de inclusión.
Supongamos, por ejemplo, que un Despachador necesita consultar el plano de la ciudad
cuando abre un incidente (por ejemplo, para verificar cuáles áreas tienen riesgo durante un
incendio) y cuando asigna recursos (por ejemplo, para saber cuáles recursos están más
cercanos al incidente). La factorización del comportamiento compartido de casos de uso
tiene muchos beneficios, incluyendo descripciones más cortas y menos redundancias. El
comportamiento sólo deberá factorizarse en casos de uso separados si es compartido entre
dos o más casos de uso. La fragmentación excesiva de la especificación del sistema a través
de una gran cantidad de casos de uso hace que la especificación sea confusa para los
usuarios y clientes.
22
Relaciones extendidas frente a inclusión
Las construcciones de inclusión y extendidas son similares, y al principio puede ser que no
le quede claro al desarrollador cuándo hay que usar cada una de ellas [Jacobson et al.,
1992]. La principal distinción entre estas construcciones es la dirección de la relación. En el
caso de una relación de inclusión, las condiciones bajo las cuales se inicia el caso de uso
están descritas en el caso de uso iniciador como un evento en el flujo de eventos. En el caso
de una relación extendida, las condiciones bajo las cuales se inicia la extensión están
descritas en la extensión como una condición inicial. También, si se describen situaciones
excepcionales adicionales (por ejemplo, una función Ayuda en la estación OficialCarnpo)
el caso de uso ReportarEmergencia tendrá que modificarse y llegará a atiborrar e con
condiciones. En la columna derecha sólo
necesitamos describir las condiciones bajo las cuales se llama al caso de uso. Además, se
pueden añadir situaciones excepcionales adicionales sin modificar el caso de uso básico
(por ejemplo, ReportarEmergencia). La habilidad para extender el sistema sin modificar las
partes existentes es crítica, ya que nos permite asegurarnos que el comportamiento original
queda intacto.
23
4.4.6 Identificación inicial de los objetos de análisis
Uno de los primeros obstáculos que encuentran los desarrolladores y los usuarios cuando
colaboran es la terminología diferente. Se produce una falta de comprensión por usar los
mismos términos en contextos diferentes y con diferente significado. Aunque los
desarrolladores con el
tiempo aprenden la terminología de los usuarios, es probable que vuelvan a encontrar este
problema cuando añadan nuevos desarrolladores al proyecto.
24
Una vez que se han consolidado los casos de uso, los desarrolladores identifican los objetos
participantes en cada caso de uso. Los objetos participantes corresponden a los concepto
principales del dominio de aplicación. Los desarrolladores los identifican, nombran y
describen sin ambigüedad, y los reúnen en un glosario.
Este glosario se incluye en la identificación del sistema y más adelante en los manuales de
usuario. Los desarrolladores mantienen actualizado este glosario conforme evoluciona la
especificación del sistema. Son muchos los beneficios del glosario: los nuevos
desarrolladores quedan expuestos a un conjunto de definiciones consistentes, un solo
término se usa para cada contexto
(en vez de un término del desarrollador y un término del usuario) y cada término tiene un
significado oficial preciso y claro.
4.4.7 Identificación de requerimientos no funcionales
Los requerimientos no funcionales describen aspectos del sistema visibles para el usuario
que no están relacionados en forma directa con el comportamiento funcional del sistema.
Los requerimientos no funcionales abarcan varios asuntos, desde la apariencia de la interfaz
de usuario hasta los requerimientos de tiempo de respuesta y las cuestiones de seguridad.
Los requerimientos no funcionales se definen al mismo tiempo que los funcionales, debido
a que tienen mucho impacto en el desarrollo y costo del sistema.
25
2.2 TÉCNICAS DE LA INGENIERÍA DE REQUISITOS
El proceso de Ingeniería de Requerimientos describe de manera detallada y precisa cada
uno de los aspectos del ciclo de vida de un conjunto de requerimientos. Este proceso
presenta dos grandes ramas: Desarrollo de requerimientos. Administración de
requerimientos.
Que tiene como propósito producir y analizarlos requerimientos de cliente, de producto y
de componente de producto, incluye las siguientes actividades: Recolección, Análisis,
Especificación y Verificación. Recolección: Es el Proceso a través del cual los clientes
(compradores y/o usuarios) y el desarrollador (contratista) de un sistema de software;
descubren, revisan, articulan, y entienden las necesidades de los usuarios del sistema y las
restricciones que se dan sobre el software y el desarrollo del mismo. Algunas de las
técnicas y herramientas más importantes para llevar a cabo la recolección de requerimientos
son: Entrevistas: método para descubrir hechos y opiniones que tienen los posibles usuarios
y otros participantes dentro del sistema que se está desarrollando. A su vez se clasifican en:
Entrevistas cerradas: las preguntas ya están previstas, tienen un orden y una forma de ser
planteadas que no pueden ser modificadas por el entrevistador. Es en realidad un
cuestionario.
Entrevistas abiertas: en las cuales no se preparan preguntas concretas, y, por el contrario, se
discute con el entrevistado las expectativas que este tiene del sistema.
Casos de Uso y/o Escenarios: Los casos de uso describen interacciones entre los usuarios y
el sistema, enfatizando en lo que el usuario necesita del sistema. Los escenarios son
ejemplos de sesiones de interacción entre el sistema y el usuario, donde un solo tipo de
interacción entre los dos participantes es simulada y descrita.
Observación y análisis social: La observación permite a los investigadores observar lo que
los usuarios hacen actualmente en un determinado contexto. Esto permite superar
problemas con los participantes del proyecto que realizan descripciones idealizadas o
demasiado simplificadas de los procesos que se llevan a cabo en sus trabajos.
26
Lluvia de Ideas: Son sesiones donde todos los participantes brindan sus ideas para obtener
una solución a una problemática. Una lluvia de ideas está compuesta de dos fases: la fase
de generación y la fase de evaluación. Durante la generación las ideas son recolectadas y es
importante que no sean criticadas. Durante la evaluación de las ideas, las propuestas de
solución deben ser evaluadas desde diferentes perspectivas.
Prototipos: Es programa de computador que implementa algunos de los requerimientos de
un sistema. Este prototipo puede ser usado para colaborar con la definición de los
requerimientos, o para facilitar la evaluación de alternativas de implementación de un
sistema.
Existen dos grandes tipos de prototipos. Los prototipos no funcionales o desechables
(Throw away), que sirven para entender la dificultad y aclarar los requerimientos; y los
prototipos funcionales o evolutivos (Evolutionary) que permiten construir una
aproximación del sistema de manera que se pueda proveer cierta funcionalidad del sistema
final y usualmente se convierten en parte del mismo. Análisis: Es el proceso de analizar las
necesidades de los clientes y los usuarios para llegar a una definición de los
requerimientos de software.
Dentro de las prácticas principales se encuentra: JAD (Joint Application Development):
Esta práctica se basa en la creación de espacios que permitan celebrar sesiones o reuniones
en donde los participantes y directos interesados dentro del desarrollo del proyecto buscan
obtener o generar conocimiento alrededor del desarrollo que se va a llevar a cabo. En estas
sesiones se trabaja bajo un enfoque común que permite el fácil entendimiento de los temas
expuestos por parte de los invitados a la sesión
Modelos: Esquema teórico, generalmente en forma matemática, de un sistema o de una
realidad compleja, como la evolución económica de un país, que se elabora para facilitar su
comprensión y el estudio de su comportamiento. Existen dos tipos de modelos. - Modelo
conceptual: Es el utilizado en la especificación del sistema, representa los conceptos más
significativos en el dominio del problema…. Nos describe la parte estática del problema, es
27
una fotografía del mundo real. - Modelo de Comportamiento: Utilizado en la parte de
diseño del sistema, define la parte dinámica, es decir, cual debe ser el comportamiento en
cada situación y la forma de proceder.
Los diagramas de secuencia y de estados son parte de este modelo. Especificación: Consiste
en el desarrollo de un documento que de manera clara y precisa contenga y especifique
cada uno de los requerimientos del sistema de software. Verificación: Es el proceso de
asegurar que la especificación de requerimientos de software sea acorde con los
requerimientos del sistema, conforme a los estándares de documentación de la fase de
requerimientos, y que a su vez este documento sea una base sólida para la arquitectura y el
diseño.
Esta actividad representa un punto de control interno y externo; interno, porque se debe
verificar internamente lo que se está haciendo, y externo, porque se debe validar con el
cliente.
Administración de requerimientos: Es un proceso que tiene por objetivo comprender y
controlar los requerimientos. Como todo proceso de administración, inicia con la
planeación a la par de la identificación inicial de requerimientos. Este proceso tiene
diferentes formas que dependen del proceso de desarrollo de software que se esté
empleando, independientemente de esto se deben considerar las siguientes etapas:
1. Requerimientos duraderos y volátiles.
2. Planeación de la administración de requerimientos.
3. Administración del cambio de los requerimientos
28
2.3 MODELADO DE REQUISITOS
En esta sección se estudiaran los requisitos, tanto funcionales como no funcionales, que hay
que cumplir para que el software funcione correctamente. Para ello se hará uso de los
diagramas de caso de uso, que especifica los modos de uso (o requisitos funcionales) que va
a tener el sistema, del diagrama de paquetes, que indica cómo se agrupan los casos de uso
en diferentes subsistemas, y de los diagramas de secuencia, que indican el flujo a seguir en
cada una de las transacciones.
Modelo funcional
En este apartado se muestran, mediante los diferentes casos de uso, los requisitos
funcionales que tiene la aplicación, mostrándose también los diferentes subsistemas de la
aplicación mediante el diagrama de paquetes.
Alta de Asociación Caso de Uso: Alta de Asociación
Usuario anónimo - administrador de la herramienta
Modificación de Asociación
Baja de Asociación
Listar Asociaciones
En primer lugar se incluye los casos de uso que componen cada subsistema, mientras que
el segundo diagrama de paquetes únicamente muestra los distintos subsistemas de la
aplicación y su relación con los actores.
29
2.4 HERRAMIENTAS CASE PARA LA INGENIERÍA DE REQUISITO
Las herramientas para la gestión de requisitos de software se limitaban a editores de texto,
los cuales hacían de esta tarea una labor tediosa y confusa. Actualmente, se cuenta con
múltiples opciones, como las que se mencionan a continuación:
IRQA 43
Herramienta CASE de Ingeniería de Requisitos, diseñada para soportar las actividades
realizadas en el proceso de especificación de sistemas. Ésta facilita y formaliza la
comunicación entre el cliente, el proveedor y los distintos miembros del equipo de
desarrollo.
Facilita la captura, organización y análisis de las condiciones, así como la especificación de
la solución mediante el apoyo metodológico adaptable a cada cliente.
RETO
Esta herramienta propone un modelo de requisitos para capturar los aspectos funcionales
del sistema; básicamente, mediante tres técnicas complementarias entre sí: la definición de
la Misión del Sistema, la construcción del Árbol de Refinamiento de Funciones y el
desarrollo del Modelo de Casos de Uso.
Además, se introduce un Proceso de Análisis que permite traducir el Modelo de Requisitos
en el Modelo Conceptual, manteniendo la trazabilidad entre ambos y propiciando una
representación de la información en el segundo prototipo.
CONTROLA
Herramienta de apoyo al proceso de ingeniería de software en pequeñas empresas. Se creó
gracias a la expansión que tuvo el mercado y a la generación de grandes y pequeñas
empresas, las cuales requieren un instrumento para el desarrollo de sus proyectos.
Ofrece recursos importantes tales como: Administración de requisitos, administración de
casos de uso, administración de casos de prueba y error, planeamiento de liberaciones,
administración de implementaciones, control de dependencia entre Implementaciones,
matriz de rastreabilidad y rastreabilidad de los requisitos.
OSRMT (Open Source Requirements Management Tool)
Herramienta libre para la gestión de requisitos, cuyas principales características son: trabaja
en arquitectura cliente/servidor, desarrollada bajo Java; la versión 1.3 trae un módulo para
30
manejar la trazabilidad y lo introduce para el control de cambios; así mismo, genera la
documentación de los requisitos tratados.
JEREMIA
Se trata exclusivamente de una aplicación cliente exclusivamente, lo cual no permite la
posibilidad de trabajar en equipo. Ésta, ayuda durante el desarrollo del sistema,
especialmente en el seguimiento de cambios de los requisitos a lo largo del ciclo de vida.
Con JEREMIA es posible captar las necesidades, analizarlas y clasificarlas. Implementa un
módulo orientado a la generación de la documentación posible de exportar en formato
DocBook XML, la cual junto con los requisitos, se almacena en una base de datos en
MySQL.
RAMBUTAN
Esta herramienta está basada en XML, realmente consta de un conjunto de aplicaciones
para el usuario final, ayudando a los analistas de sistemas en la recopilación y
categorización de hechos en un documento de especificación de requisitos. Lo curioso es
que tiene un cliente para palm (PDA), el cual se utiliza para recopilar los hechos en el lugar
donde está ubicado el cliente mientras que la aplicación de escritorio recibe la información,
edita y perfecciona.
Ambas aplicaciones permiten al usuario introducir, modificar y visualizar los datos que
componen un documento de especificación de requisitos. Comparada con otras
herramientas de gestión de requisitos, Rambutan ofrece las siguientes ventajas
competitivas: Aplicación cliente para palm (PDAclass), portabilidad entre plataformas, es
independiente de cualquier metodología de especificación de requisitos, y permite
distribución libre. Existen otras herramientas en estudios para la gestión de requisitos. A
continuación se mencionan, algunas de las incluidas en el estudio comparativo presentado
por El Consejo Internacional sobre la Ingeniería de Sistemas (INCOSE)7: CaliberRM,
REM, SMART TRACE, SoftREQ, Analyst Real Team System.
31
6 Figura
2.4.1.-Mapa conceptual Ingeniería de requisitos
33
2.4.2.-Tareas de ingeniería de requisitos para la documentación de proyectos
Los requerimientos en un proyecto no solo comprenden las tareas de captura y manejo de los
cambios a lo largo de todo el proyecto, también comprenden de estas otras tareas:
1. I de refiere a «quienes pueden afectar o son afectados por las actividades de una
empresa»)Se describe una lista de toda la persona interesada en el desarrollo del sistema.
2. Entender las necesidades de los usuarios y clientes necesarias para planear el sistema y sus expectativas.
3. I de Inicialmente los requerimientos provienen En esta actividad los requerimientos se
indican por medio de sentencias. En un escenario de negocio se usa para entender los
requerimientos del negocio.
4. AclaEsta actividad se ejecuta cuando se tiene plena seguridad plena certeza de que los
requerimientos indican las necesidades reales del cliente y quel resto A na Se realiza
cuando los requerimientos se encuentran bien definidos y cumplen con el criterio de un
buen requerimiento.
6. DefistakeholdersDebido a que cada stakeholders tiene una perspectiva diferente del
sistema y sus requerimientos, es importante esforzar un poco drequerimientos usando un
vocabulario adecuado.
7. E sp Cada requerimiento debe expresarse en forma detallada de tal manera que pueda ser
incluido en otros documentos de especificación o en otros proyectos.
8. Pr i Todos los requerimientos tienen niveles diferentes de importancia para los clientes y
usuarios. Unos La priorización de los requnuevas versiones de nuestro psus salidas.
9. D er Esta actividad nos pusuarios que no se adecuado del requerimiento en detalle.
10. Particionar los requerimientos: donde se clasifican los requerimientos en diferentes criterios:
Hardware, software y entrenamiento.
11. Asignar Esta actividad asigna los requerimientos a diferentes subsistemas y
componentes internos.
34
12. Hacer seguiSe desarrolla la capacidad de permitir que un requerimiento satisfecho pueda
ser referenciado dentro del sistema.
13. Manejar Se desarrolla un sistema de control de los requerimientos, necesario para
adicionar, modificar y borrar requerimientos, al igual que la implantación de un
repositorio para estos.
14. Probar y verEn esta actividad se validan los requerimientos, diseños, código, etc... Para
asegurarse que los requerimientos están bien.
15. Validar Finalmente se confirman los requerimientos reales que han sido
implementados.
2.4.3.-Documentar un caso de desarrollo para las tareas de requisitos.
1. I de
2. El cliente cita al programador para exigir las necesidades principales para combatir la problemática de la
empresa o institución, así mismo el programador brinda su servicio, toma el control de ella y expone su
trabajo.
3. I de Los requerimientos son consecuencias de la problemática de la institución como
pueden ser: Mala organización y administración del personal administrativo, el estudiante
invierte tiempo haciendo largas filas para el manejo o uso de los datos requerido, los
alumnos esperan a que su profesor entregue en una lista las calificaciones obtenidas.
Como requerimiento tendríamos la mejora y la eficacia de un mejor control estudiantil.
4. Acla La eficiencia que se le brinda al alumno al momento de hacer un muestreo de su
información por parte del servicio administrativo seria uno de los requerimientos más
necesarios, que beneficiarían también al personal administrativo y docentes de la
institución.An a haciendo un grupo de pruebas, muestras y encuestas se llega a la
conclusión que realmente los requisitos son necesarios para el desarrollo de la institución.
6. DefistakeholdersAlumno: hace uso del internet de manera frecuente, se familiariza con
lo que son las plataformas en linea y así mismo evitara largas filas, tiempo de espera para
poder hacer uso de su información escolar. Administrativo: el uso de la plataforma, le
permitirá el ahorro de espacio en su oficina, y que no tendrá que archivar demasiado
papeleo, trabaja de una manera diferente, haciendo uso independiente del horario de
trabajo.
35
Docente: implementa y administra las calificaciones de una manera más factible, ahorra
de tiempo en ir a Control a Escolar para entregar sus listas de calificaciones.
7. E sp Como requerimiento tendríamos la mejora y la eficacia de un mejor control para los
estudiantes, ya que hoy en día las instituciones educativa manejan diferente niveles de
competencia estudiantil, lo cual indica que sería factible para que el alumnado y docente
estuvieran actualizado, haciendo uso de las nuevas tecnologías que no serían lujosas, si
no necesarias en la actualidad.
8. Pr i como único requerimiento y prioridad seria la actualización en el manejo de control
escolar.
9. D er uno de los detalles o requerimientos que se pudieron observar fue la falta de
evaluación de alumno hacia el docente, ya que esto ayudaría a saber el trabajo, la
disciplina, la forma de evaluación y de impartir clases del maestro evaluado.
10. Particionar los requerimientos: los requerimientos obtenidos y expuestos , hace hincapié , no solo a la
parte del software, sino también del hardware, ya que son necesario ambos para la obtención y resolución
del problema.
2.4.4. Técnicas de la ingeniería de requisitos
El proceso de Ingeniería de Requerimientos describe de manera detallada y precisa cada uno de
los aspectos del ciclo de vida de un conjunto de requerimientos. Este proceso presenta dos
grandes ramas: Desarrollo de requerimientos. Administración de requerimientos.
Que tiene como propósito producir y analizarlos requerimientos de cliente, de producto y de
componente de producto, incluye las siguientes actividades: Recolección, Análisis,
Especificación y Verificación.
Recolección: Es el Proceso a través del cual los clientes (compradores y/o usuarios) y el
desarrollador (contratista) de un sistema de software; descubren, revisan, articulan, y entienden
las necesidades de los usuarios del sistema y las restricciones que se dan sobre el software y el
desarrollo del mismo. Algunas de las técnicas y herramientas más importantes para llevar a cabo
la recolección de requerimientos son: Entrevistas: método para descubrir hechos y opiniones que
tienen los posibles usuarios y otros participantes dentro del sistema que se está desarrollando. A
su vez se clasifican en:
36
Entrevistas cerradas: las preguntas ya están previstas, tienen un orden y una forma de ser
planteadas que no pueden ser modificadas por el entrevistador. Es en realidad un cuestionario.
Entrevistas abiertas: en las cuales no se preparan preguntas concretas, y, por el contrario, se
discute con el entrevistado las expectativas que este tiene del sistema.
Casos de Uso y/o Escenarios: Los casos de uso describen interacciones entre los usuarios y el
sistema, enfatizando en lo que el usuario necesita del sistema. Los escenarios son ejemplos de
sesiones de interacción entre el sistema y el usuario, donde un solo tipo de interacción entre los
dos participantes es simulada y descrita.
Observación y análisis social: La observación permite a los investigadores observar lo que los
usuarios hacen actualmente en un determinado contexto. Esto permite superar problemas con los
participantes del proyecto que realizan descripciones idealizadas o demasiado simplificadas de
los procesos que se llevan a cabo en sus trabajos.
Lluvia de Ideas: Son sesiones donde todos los participantes brindan sus ideas para obtener una
solución a una problemática. Una lluvia de ideas está compuesta de dos fases: la fase de
generación y la fase de evaluación. Durante la generación las ideas son recolectadas y es
importante que no sean criticadas. Durante la evaluación de las ideas, las propuestas de solución
deben ser evaluadas desde diferentes perspectivas.
Prototipos: Es programa de computador que implementa algunos de los requerimientos de un
sistema. Este prototipo puede ser usado para colaborar con la definición de los requerimientos, o
para facilitar la evaluación de alternativas de implementación de un sistema.
Existen dos grandes tipos de prototipos. Los prototipos no funcionales o desechables (Throw
away), que sirven para entender la dificultad y aclarar los requerimientos; y los prototipos
funcionales o evolutivos (Evolutionary) que permiten construir una aproximación del sistema de
manera que se pueda proveer cierta funcionalidad del sistema final y usualmente se convierten en
parte del mismo. Análisis: Es el proceso de analizar las necesidades de los clientes y los
usuarios para llegar a una definición de los requerimientos de software.
37
Dentro de las prácticas principales se encuentra: JAD (Joint Application Development): Esta
práctica se basa en la creación de espacios que permitan celebrar sesiones o reuniones en donde
los participantes y directos interesados dentro del desarrollo del proyecto buscan obtener o
generar conocimiento alrededor del desarrollo que se va a llevar a cabo. En estas sesiones se
trabaja bajo un enfoque común que permite el fácil entendimiento de los temas expuestos por
parte de los invitados a la sesión
Modelos: Esquema teórico, generalmente en forma matemática, de un sistema o de una realidad
compleja, como la evolución económica de un país, que se elabora para facilitar su comprensión
y el estudio de su comportamiento. Existen dos tipos de modelos. - Modelo conceptual: Es el
utilizado en la especificación del sistema, representa los conceptos más significativos en el
dominio del problema…. Nos describe la parte estática del problema, es una fotografía del
mundo real. - Modelo de Comportamiento: Utilizado en la parte de diseño del sistema, define la
parte dinámica, es decir, cuál debe ser el comportamiento en cada situación y la forma de
proceder.
Los diagramas de secuencia y de estados son parte de este modelo. Especificación: Consiste en el
desarrollo de un documento que de manera clara y precisa contenga y especifique cada uno de
los requerimientos del sistema de software. Verificación: Es el proceso de asegurar que la
especificación de requerimientos de software sea acorde con los requerimientos del sistema,
conforme a los estándares de documentación de la fase de requerimientos, y que a su vez este
documento sea una base sólida para la arquitectura y el diseño.
Esta actividad representa un punto de control interno y externo; interno, porque se debe verificar
internamente lo que se está haciendo, y externo, porque se debe validar con el cliente.
Administración de requerimientos: Es un proceso que tiene por objetivo comprender y controlar
los requerimientos. Como todo proceso de administración, inicia con la planeación a la par de la
identificación inicial de requerimientos. Este proceso tiene diferentes formas que dependen del
proceso de desarrollo de software que se esté empleando, independientemente de esto se deben
considerar las siguientes etapas:
1. Requerimientos duraderos y volátiles.
2. Planeación de la administración de requerimientos.
3. Administración del cambio de los requerimientos.
38
2.4.5.-Aplicar las técnicas en el proyecto de investigación.
Recolección método encuestas:
1.- ¿Estas satisfecho con el sistema de control actual?
2.- ¿Estas enterado de los avisos que hace tu Institución?
3.- ¿Te gustaría tener una página web donde puedas ver la información de tu escuela?
4.- ¿Te gustaría hacer uso de las nuevas herramientas tecnológicas?
Análisis:
No se cuenta con un sistema computarizado que maneje los procesos inscripción, muestreo de
horario, avisos por parte de la institución, y calificaciones. ocasionando con ello, retrasos y
errores en el procesamiento de información escolar de los alumnos en la secundaria técnica #110
que se encuentra en municipio de Lázaro Cárdenas Michoacán.
Especificación:
Nuestro proyecto va a ser una buena opción sobre el manejo de información y facilidad de
acceso. Podemos ver que el impacto en la sociedad estudiantil del plantel puede ser importante.
A su vez les ayudará a dar un mejor servicio a los alumnos y personal.
Verificación:
El presente proyecto se justifica técnicamente porque proporciona una herramienta de apoyo para
el control de la información, convirtiéndose así en una importante ayuda para los trabajadores de
la institución.
2.4.6. Modelado de requisitos
En esta sección se estudiaran los requisitos, tanto funcionales como no funcionales, que hay que
cumplir para que el software funcione correctamente. Para ello se hará uso de los diagramas de
caso de uso, que especifica los modos de uso (o requisitos funcionales) que va a tener el sistema,
del diagrama de paquetes, que indica cómo se agrupan los casos de uso en diferentes
subsistemas, y de los diagramas de secuencia, que indican el flujo a seguir en cada una de las
transacciones.
39
3 Modelo de análisis
El modelo de análisis es la primera representación técnica de un sistema. Utiliza una mezcla de
formatos en texto y diagramas para representar los requisitos del software, las funciones y el
comportamiento. De esta manera se hace mucho más fácil de comprender dicha representación,
ya que es posible examinar los requisitos desde diferentes puntos de vista aumentando la
probabilidad de encontrar errores, de que surjan debilidades y de que se descubran descuidos.
Análisis de requisitos
El análisis de requisitos le proporciona al diseñador de software una representación de datos,
función y comportamiento que puede trasladar a diseños arquitectónicos de interfaz. Este, junto
al modelo de análisis, ofrece al desarrollador y al cliente los medios para evaluar la calidad una
vez construido el software.
Objetivos generales del modelo de análisis
El modelo de análisis debe cumplir tres objetivos primarios:
1. Describir los que requiere el cliente
2. Establecer una base para la creación de un diseño de software
3. Definir un conjunto de requisitos que pueda validarse una vez construido el software.
Elementos del modelo de análisis
El modelo de análisis se complementa de cuatro elementos fundamentales. Estos elementos
sirven para clasificar principalmente los diferentes diagramas y otros derivados conocidos en
plataformas como sistemas de información e ingeniería de software entre otros. Además estos
con clasificados en elementos de escenario, elementos de flujo, elementos de clases y elementos
de comportamiento.
40
3.1.- Arquitectura de clases
El modelo de análisis tiene como objetivo generar una arquitectura de objetos que sirva como
base para el diseño posterior del sistema. Como se discutió en la introducción del libro,
dependiendo del tipo de aplicación existen diversas arquitecturas que se pueden utilizar, siendo
de nuestro interés aquellas arquitecturas especialmente diseñadas para el manejo de los sistemas
de información, las cuales involucran ricas interfaces de usuario y accesos a base de datos como
aspectos fundamentales de la arquitectura.
En término de las propias arquitecturas, éstas se distinguen según la organización de la
funcionalidad que ofrecen los objetos dentro de ellas o la dimensión de los objetos. Esta
dimensión corresponde a los diferentes tipos de funcionalidad que manejan los objetos dentro la
arquitectura. Por ejemplo, en el caso de funcionalidad para el manejo de interfaces y base de
datos, si existen tipos distintos de objetos para el manejo de cada una de estas por separado,
entonces se considera que la arquitectura es de dos dimensiones. Por el contrario, si todos los
objetos manejan de manera indistinta los dos tipos de funcionalidades, entonces se considera que
la arquitectura es de una sóla dimensión.
La vista o presentación de la información corresponde a las interfaces que se le presentan al
usuario para el manejo de la información, donde por lo general pueden existir múltiples vistas
sobre un mismo modelo. Típicamente la información representa el dominio del problema y es
almacenada en una base de datos. Por otro lado el control corresponde a la manipulación de la
información a través de sus diversas presentaciones. Y aunque existe cierta dependencia entre
estas tres dimensiones se considera que la manera de presentar la información es independiente
de la propia información y de cómo esta se controla. Sin embargo, cada una de ellas
probablemente experimente cambios a lo largo de la vida del sistema, donde el control es el más
propenso a ser modificado, seguido de la vista y finalmente el modelo.
41
3.2.- Identificación de clases según estereotipos
Para llevar a cabo la transicion del modelo de requisitos al modelo de analisis se deben
identificar los objetos necesarios para implementar todos los casos de uso. 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 mas 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 más dificiles de administrar, ya que ésta puede abarcar todos
los tipos de objetos.
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 traves de
ellso 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 presentacion comperensible para el actor.
Las clases borde en otras palabras , describen la comunicación bidireccional entre el sistema y
los actores.
Las clases borde son bastante fáciles 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
acompañan al modelo de requisitos.
3. Se pueden identificar con base en las descripciones de los casos de uso y extraer la
funcionalidad específica a los objetos bordes.
42
Entidad
Se utilizan objetos entidad para modelar la información que el sistema debe manejar a corto y
largo plazo. La información a corto plazo existe durante la ejecución de un caso de uso, mientras
que la información a largo plazo trasciende los caso de uso, por lo que es necesario guardarla en
alguna base de datos o archivos.
Durante la identificación de objeto entidad, se encontrara que objetos que objetos similares
aparecen en varios casos de uso.
Control
En la mayoría 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 solución no es buena si se considera el
aspecto de extensibilidad. Un cambio en el comportamiento podría afectar varios objetos,
dificultando su modificación. Para evitar estos problemas, tal comportamiento se asigna a objetos
control.
Es difícil lograr un buen balance en la distribución del comportamiento del caso de uso entre los
objetos entidad, borde y control. Los objetos de control normalmente proveen a administración
de los demás tipos de objetos.
43
3.3 Clases
Las clases son declaraciones o abstracciones de objetos, lo que significa, que una clase es la
definición de un objeto. Cuando se programa un objeto y se definen sus características y
funcionalidades, realmente se programa una clase. Una clase es un contenedor de uno o más
datos (variables o propiedades miembro) junto a las operaciones de manipulación de dichos
datos (funciones/métodos). Las clases pueden definirse como estructuras (struct), uniones
(union) o clases (class) pudiendo existir diferencias entre cada una de las definiciones según el
lenguaje. Además las clases son agrupaciones de objetos que describen su comportamiento
Clases Las clases son lo más simple de Java. Todo en Java forma parte de una clase, es una clase
o describe cómo funciona una clase. El conocimiento de las clases es fundamental para poder
entender los programas Java.
Todas las acciones de los programas Java se colocan dentro del bloque de una clase o un objeto.
Todos los métodos se definen dentro del bloque de la clase, Java no soporta funciones o
variables globales. Esto puede despistar a los programadores de C++, que pueden definir
métodos fuera del bloque de la clase, pero esta posibilidad es más un intento de no separarse
mucho y ser compatible con C, que un buen diseño orientado a objetos. Así pues, el esqueleto de
cualquier aplicación Java se basa en la definición de una clase.
Todos los datos básicos, como los enteros, se deben declarar en las clases antes de hacer uso de
ellos. En C la unidad fundamental son los ficheros con código fuente, en Java son las clases. De
hecho son pocas las sentencias que se pueden colocar fuera del bloque de una clase. La palabra
clave import (equivalente al #include) puede colocarse al principio de un fichero, fuera del
bloque de la clase. Sin embargo, el compilador reemplazará esa sentencia con el contenido del
fichero que se indique, que consistirá, como es de suponer, en más clases
44
3.4.- Diagramas de secuencia
Un diagrama de secuencia es una forma de diagrama de interacción que muestra los objetos
como líneas de vida a lo largo de la página y con sus interacciones en el tiempo representadas
como mensajes dibujados como flechas desde la línea de vida origen hasta la línea de vida
destino. Los diagramas de secuencia son buenos para mostrar qué objetos se comunican con qué
otros objetos y qué mensajes disparan esas comunicaciones. Los diagramas de secuencia no están
pensados para mostrar lógicas de procedimientos complejos.
Línea de Vida: Una línea de vida representa un participante individual en un diagrama de
secuencia. Una línea de vida usualmente tiene un rectángulo que contiene el nombre del objeto.
Si el nombre es self entonces eso indica que la línea de vida representa el clasificador que posee
el diagrama de secuencia.
Algunas veces un diagrama de secuencia tendrá una línea de vida con un símbolo del elemento
actor en la parte superior. Este usualmente sería el caso si un diagrama de secuencia es contenido
por un caso de uso. Los elementos entidad, control y límite de los diagramas de robustez también
pueden contener líneas de vida.
Mensajes
Los mensajes se muestran como flechas. Los mensajes pueden ser completos, perdidos o
encontrados; síncronos o asíncronos: llamadas o señales. En el siguiente diagrama, el primer
mensaje es un mensaje síncrono (denotado por una punta de flecha oscura), completo con un
mensaje de retorno implícito; el segundo mensaje es asíncrono (denotado por una punta de flecha
en línea) y el tercero es un mensaje de retorno asíncrono (denotado por una línea punteada).
45
Ocurrencia de ejecución
Un rectángulo fino a lo largo de la línea de vida denota la ocurrencia de ejecución o activación
de un foco de control. En el diagrama anterior hay tres ocurrencias de ejecución. El primero es el
objeto origen que envía dos mensajes y recibe dos respuestas, el segundo es el objeto destino que
recibe un mensaje asíncrono y retorna una respuesta, y el tercero es el objeto destino que recibe
un mensaje asíncrono y retorna una respuesta.
Mensaje Self
Un mensaje self puede representar una llamada recursiva de una operación, o un método
llamando a otro método perteneciente al mismo objeto. Este se muestra como cuando crea un
foco de control anidado en la ocurrencia de ejecución de la línea de vida.
Mensajes perdidos y encontrados
Los mensajes perdidos son aquellos que han sido enviados pero que no han llegado al destino
esperado, o que han llegado a un destino que no se muestra en el diagrama actual. Los mensajes
encontrados son aquellos que llegan de un remitente no conocido, o de un remitente no conocido
en el diagrama actual. Ellos se denotan yendo o llegando desde un elemento de punto final.
46
3.5.-Diccionario de clases según módulos
Es un listado organizado de todos los datos pertinentes al sistema.
Posee definiciones precisas de todos los flujos de datos, elementos y estructuras de datos,
almacenes y entidades, para que tanto el usuario como el analista tengan un conocimiento
completo de ellos.
La segunda herramienta de modelado importante, aunque no tiene la presencia y atractivo gráfico
de los DFD, los diagramas Entidad-Relación o los diagramas de estructuras, es el diccionario de
datos.
El diccionario de datos es un listado organizado de todos los datos pertinentes al sistema, con
definiciones precisas y rigurosas para que tanto el usuario como el analista tengan un
entendimiento común de todas las entradas, salidas, componentes de los almacenes y cálculos
intermedios. El diccionario de datos define los datos haciendo lo siguiente:
– Describe el significado de los flujos y almacenes que se muestran en los DFD.
– Describe la composición de agregados de paquetes de datos que se mueven a lo largo de los
flujos, es decir, paquetes complejos que pueden descomponerse en unidades más elementales.
– Describen la composición de los paquetes de datos en los almacenes.
– Especifica los valores y unidades relevantes de piezas elementales de información en los
flujos de datos y en los almacenes de datos.
– Describe los detalles de las relaciones entre almacenes que se enfatizan en un diagrama de
entidad-relación u otro modelo de datos.