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

14

4 Figura

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

32

7 Figura

Mapa Mental De Ingenieria 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.