Evolucioacuten

1ordf ERA (1950 ndash 1965) Se trabajaba con la idea de ldquoCodificar y Corregirrdquo No existiacutea un planteamiento previo No existiacutea documentacioacuten de ninguacuten tipo Existencia de pocos meacutetodos formales y pocos creyentes

en ellos Desarrollo a base de prueba y error

2ordf ERA (1965 - 1972) Se busca simplificar coacutedigo Aparicioacuten de Multiprogramacioacuten y Sistemas Multiusuarios Sistemas de Tiempo Real apoyan la toma de decisiones Aparicioacuten de Software como producto (Casas de

Software) INICIO DE LA CRISIS DEL SOFTWARE Se buscan procedimientos para el desarrollo del

Software

3ordf ERA (1972 - 1989) Nuevo Concepto Sistemas Distribuidos Complejidad en los Sistemas de Informacioacuten Aparecen Redes de aacuterea local y global y Comunicadores

Digitales Amplio Uso de Microprocesadores

4ordf ERA (1989 ndash AL PRECENTE) Impacto Colectivo de Software Aparecen Redes de Informacioacuten Tecnologiacuteas Orientadas a

Objetos Aparecen Redes Neuronales Sistemas Expertos y SW de

Inteligencia Artificial La informacioacuten como valor preponderante dentro de las

Organizaciones

RequisitoRequisitos del software propiedades y atributos Propiedades deseables de los requisitos del software

Propiedades que deben tener todos los requisitos para estar bien especificados

Al inspeccionar los requisitos deben cuestionarse estas propiedades

o Utilizar cuestionarios de validacioacuten para inspeccionar requisitos 1113088 Dos tipos o Propiedades globales completitud consistenciao Propiedades individuales tamantildeo claridad comprobabilidad condiciones de error trazabilidad (funcionales no funcionales)

No confundir con los atributos de los requisitos toman un valor distinto en cada caso

o Necesidad prioridad y riesgo

Tamantildeo

Para manejar con mayor facilidad un requisito deberaacute tener un tamantildeo adecuado o ni tan grande que sea inmanejableo ni tan pequentildeo que no valga la pena seguirle la pista por separado

Es posible aplicar los principios de modularidad y anidamiento a los requisitos

Nivel de granularidad la misma cantidad de informacioacuten puede repartirse en un nuacutemero grandepequentildeo de requisitos (grano finogrueso)

Nivel de detalle los requisitos contienen maacutes detalles globalmente maacutes informacioacuten

Completitud Significa que no hay omisiones que comprometan la

integridad de los requisitoso No faltan requisitos (propiedad global)o No faltan detalles en la especificacioacuten de cada requisito (propiedad individual)

Es una propiedad difiacutecil de determinar (tan soacutelo podemos alcanzar una aproximacioacuten) o Contrastar con el cliente

o Comparar con proyectos semejantes Buscar la visioacuten de conjunto detectar huecos o partes

infra-especificadas o Una manera de comprobarlo para cada requisito comprobar que estaacuten presentes los demaacutes requisitos relacionados

La buena organizacioacuten facilita la deteccioacuten de faltas o Ejemplo organizacioacuten por tipos de requisitos

Teacutecnicas estadiacutesticas para estimar el nuacutemero de requisitos auacuten no descubiertoso Ritmo temporal de creacioacutenmodificacioacuten de requisitoso Ajustar la ldquonube de puntosrdquo (tiempo-requisitos conocidos) a una curva

monoacutetona creciente acotada (iquesthipeacuterbola) Consistencia (o coherencia)

Significa que no hay contradicciones entre requisitos (ni acoplamientos-redundancias)

Contradiccioacuten = Ambiguedad pero las ambiguedades difultan detectar contradicciones

Es maacutes difiacutecil de comprobar si el nuacutemero de requisitos crece

Una buena organizacioacuten facilita la deteccioacuten de contradicciones

Ejemplo tabla de referencia cruzadas que ademaacutes facilita la deteccioacuten de requisitos afectados por la modificacioacuten de uno dado (distinta de la tabla de composicioacuten F-NF)

o Conflicto contradiccioacuten no se pueden satisfacer simultaacuteneamenteo Acoplamiento hablan de lo mismo (si cambia uno puede afectar al otro) o Redundancia dicen lo mismo (sobra uno de los dos)o Independencia

En la versioacuten final no puede haber Conflictos ni Redundancias siacute Acoplamientos

Claridad

Significa que no hay ambiguedad en la especificacioacuten de cada requisito

Utilizar un vocabulario controlado y tabla de teacuterminos equivalentes (sinoacutenimos)

Para cualquier labor de escritura o Tenga siempre a mano diccionarios (normal sinoacutenimos estilo idiomas corrector ortograacutefico y sintaacutectico) o Escribir corregir escribir corregir y hacerlo entre varios (uno escribe otro corrige) o Respetar normas ortograacuteficas sintaacutecticas gramaticales estiliacutesticas no es un capricho lo que no estaacute bien escrito no se entiende o Estructurar bien proceder con orden proporcionar las referencias necesarias o Sintetizar resaltar ideas importantes resaltar maacutes lo menos obvio Comprobabilidad

Incluye dos tipos distintos de defectos que se desea descubrir y eliminar o Validacioacuten defectos de interpretacioacuten (do the right thing)o Verificacioacuten defectos de implementacioacuten (do the thingright)

Muchos defectos se pueden descubrir y eliminar mediante pruebas pero salvo que se usen meacutetodos formales las pruebas no garantizan que todos los defectos desaparecen

Atencioacuten las pruebas de verificacioacuten no sirven como pruebas de validacioacuten

Para validar y verificar un requisito es necesario que eacuteste sea comprobable (testable)

Un requisito no comprobable o ambiguo tiene escaso valor y debe ser rechazado

Ejemplos o El sistema mostraraacute la diferencia entre el valor observado y la media mundial (no comprobable) o El sistema mostraraacute la diferencia entre el valor observado y el valor publicado por Naciones Unidas (iquestcuaacutendo todaviacutea esambiguo) o El sistema mostraraacute la diferencia entre el valor observado y el uacuteltimo valor publicado por Naciones Unidas en su paacutegina web

Conviene asegurar que no es ambiguo ni siquiera si se interpretase mal a propoacutesito

Esbozar una prueba especiacutefica que estableceriacutea la satisfaccioacuten

La definicioacuten de pruebas ayuda a clarificar el sentido de cada requisito

Condiciones de error Para estar completa la especificacioacuten del requisito

debe tener en cuenta las condiciones de error es decirqueacute ocurre con el requisito en una situacioacuten con errores

Las condiciones de error son especialmente importantes para realizar las pruebas ya que al probar un requisitose fuerzan condiciones de error y es necesario prever queacute debe ocurrir en estos casos Caso tiacutepico datos de entrada incorrectos

o Ejemplo clasificar un triaacutengulo a partir de las coordenadas de sus tres veacutertices 1113088 No confiar en que no se produciraacuten condiciones de error esto aumenta la dependencia entre moacutedulos (un moacutedulo confiacutea en la deteccioacuten de errores deotro moacutedulo) o Pero recordar que no se debe abusar del manejode errores internos

Redundancia para promover la seguridad Determinar lo que hay que hacer en situaciones no

previstas (prever lo imprevisto) Prevenir posibles errores de programacioacuten en lugares

criacuteticos

Trazabilidad de requisitos funcionales Es la correspondencia entre cada requisito del software

yo uno o maacutes requisitos del usuario u otras fuentes (trazabilidad hacia atraacutes)o una o varias partes del disentildeo o la implementacioacuten (trazabilidad hacia adelante)

La relacioacuten RU-RS es tiacutepicamente uno-a-pocos Todo RU debe ser desarrollado por al menos un RS pero puede haber un RS cuya fuente no sea un RU (PSS-05-03 3 y 47)

o No confundir con el caso de nuevos RU que se descubren durante el desarrollo de los RS y que deberaacuten ser validados por el usuario nueva versioacuten URD o Verdadero RS sin RU todo RS debe tener una buena razoacuten para existir con mayor razoacuten si no existe un RU correspondiente el cliente no querraacute pagar por cosas que no ha encargado

Es necesaria para poder comprobar que la aplicacioacuten satisface los requisitos

Una forma de conseguirla es relacionar cada requisito funcional con una funcioacuten

especiacutefica en el lenguaje destino o Esta teacutecnica es poco generalizable y limitada produce excesivo acoplamiento entre la estructura de los requisitos y la estructura de la implementacioacuten o En OO no es trivial preguntarse queacute clase esresponsable de queacute funcioacuten

Funcioacuten con un solo paraacutemetro F(x) xF( ) Funcioacuten con dos o maacutes paraacutemetros G(x y) xG(y)

yG(x) La transicioacuten Anaacutelisis-Disentildeo no es sencilla ni tiene

por queacute serlo Es muy necesaria para afrontar que los requisitos

cambian y gestionar su evolucioacuten o Si la gestioacuten de la trazabilidad es difiacutecil y lleva demasiado trabajo los desarrolladores tenderaacuten a evitar la actualizacioacuten del documento de requisitos e iraacuten directamentea hacer cambios al coacutedigo en consecuencia el documento de requisitos se hace inuacutetil para las pruebas y la validacioacuten o Si ademaacutes el documento no es fiable por culpa de algunos miembros del equipo menos responsables entonces ni siquiera los maacutes responsables se tomaraacuten la molestia de mantenerlo al diacutea o Por tanto el sistema para hacer corresponder requisitos con disentildeo y coacutedigo debe ser claro y concreto o Ejemplo matrices de trazabilidad de requisitos 1113088 hacia atraacutes hacia delante 1113088 distintas de la tabla de referencias cruzadas entre requisitos para gestionar la consistencia

1113088 Un requisito puede corresponderse con varias partes del coacutedigo (funciones) que a su vez pueden implementar varios requisitos cada una o Por tanto antes de cambiar el coacutedigo para adaptarse a un cambio en un requisito hay que comprobar que otros requisitos no quedan comprometidos o La correspondencia Requisito-Funcioacuten es muchos-a-muchos sino puede ser uno-uno al menos puede intentarse que sea pocos-pocos o El disentildeo juega un papel fundamental en establecer esta correspondencia

Trazabilidad de requisitos no funcionales La correspondencia con elementos del disentildeo y de la

implementacioacuten es mucho maacutes difiacutecil ya que depende en mayor medida de la colaboracioacuten entre varios elementos

La validacioacuten de estos requisitos es maacutes complicada normalmente requiere un mayor nivel de integracioacuten del sistema (no es faacutecil validar NFRS en componentes aislados)

Ejemplo rendimiento o Identificar los elementos que consumen maacutes tiempo o memoriao La mayor parte de los recursos son consumidos por un nuacutemeroreducido de elementos de modo que esta tarea es provechosa para mejorar el rendimiento o Bucles graacuteficos y comunicaciones suelen ser los que maacutes tiempo consumen

ATRIBUTOS Necesidad y prioridad

Para negociar entre funcionalidad planificacioacuten presupuesto y nivel de calidad es conveniente que los requisitos funcionales tengan asignado un nivel de necesidad (tres o cuatro categoriacuteas esencial deseableopcional) asiacute como un nivel de prioridad temporal (dos o tres categoriacuteas alta baja)

La necesidad de un requisito hace referencia al intereacutes de los usuariosclientes en que la aplicacioacuten lo

realice y hasta queacute punto estariacutean dispuestos a pasarsesi eacutel

La prioridad de un requisito hace referencia al orden temporal indica en queacute fase de construccioacuten del sistemase incluiraacute la funcionalidad que realice el requisito

Si el 20 de la aplicacioacuten proporciona el 80 de su valor no maacutes del 20 de los requisitos deberiacutean ser ldquoesencialesrdquo

Riesgo Cada requisito deberiacutea ir acompantildeado de una estimacioacuten

del riesgo que supone realizarlo (relacionado con la dificultad de implementarlo) Ej alto moderado bajo

Seguir la pista con especial atencioacuten a los de mayor riesgo

Para escribir un requisito resumen Enunciado breve del mismo numerado Explicacioacuten detallada Atributos y propiedades tal como se han discutido hasta

aquiacute por ejemplo o Necesidad Prioridad y Riesgoo Condiciones de erroro Pruebas de validacioacuten y verificacioacuten requeridas

Tabla de composicioacuten de requisitos funcionales-no funcionales

Tabla de referencias cruzadas entre requisitos conflicto acoplamiento redundancia

Matrices de trazabilidad hacia requisitos de usuario y hacia disentildeoimplementacioacuten

Usar un formato que permita distintos niveles de visibilidad

o soacutelo enunciadoo soacutelo enunciado y descripcioacuteno enunciado descripcioacuten y propiedades

DiagramaDiagramas de secuencias

El diagrama de secuencia es un tipo de diagrama usado para modelarinteraccioacuten entre objetos en un sistema seguacuten UML

Un diagrama de secuencia muestra la interaccioacuten de un conjunto de objetos en una aplicacioacuten a traveacutes del tiempo y se modela para cada caso de uso Mientras que el diagrama de casos de uso permiteel modelado de una vista business del escenario el diagrama de secuencia contiene detalles de implementacioacuten del escenario incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos

Diagrama de secuencias del disentildeo

La fase de disentildeo (y los modelos UML resultantes) expande y detalla los modelos de anaacutelisis tomando en cuenta todas las implicaciones y restricciones teacutecnicas El propoacutesito del disentildeo es especificar una solucioacuten que trabaje y pueda ser faacutecilmente convertida en coacutedigo fuente y construir una arquitectura simple y faacutecilmente extensible Las clases definidas en el anaacutelisis fueron detalladas y se antildeadieron nuevas clases para manejar aacutereas teacutecnicas como base de datosinterfaz del usuario comunicacioacuten dispositivos etc

Diagrama de secuencia

Los casos de uso deben ser realizados durante esta etapa Para describir el comportamiento dinaacutemico del sistema cualquiera de los diagramas de interaccioacuten del UML pueden ser

utilizados Debido a que Rational Rose no soporta los diagramas de actividad y ofrece soporte limitado para los diagramas de colaboracioacuten (en notacioacuten completa del UML) usaremos diagramas de secuencia

Diagramas de componentes

Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de ModeladoUn diagrama de componentes representa coacutemo un sistema de software es dividido en componentes y muestra las

dependencias entre estos componentes Los componentes fiacutesicosincluyen archivos cabeceras bibliotecas compartidas moacutedulos ejecutables o paquetes Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistemaDebido a que los diagramas de componentes son maacutes parecidos alos diagramas de casos de usos eacutestos son utilizados para modelar la vista estaacutetica y dinaacutemica de un sistema Muestra la organizacioacuten y las dependencias entre un conjunto de componentes No es necesario que un diagrama incluya todos los componentes del sistema normalmente se realizan por partes Cada diagrama describe un apartado del sistemaEn eacutel se situaraacuten libreriacuteas tablas archivos ejecutables y documentos que formen parte del sistemaUno de los usos principales es que puede servir para ver queacute componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema

Diagramas de despliegue

El Diagrama de Despliegue es un tipo de diagrama del LenguajeUnificado de Modelado que se utiliza para modelar la disposicioacuten fiacutesica de los artefactos software en nodos (usualmente plataforma de hardware)Aspectos GeneralesLa mayoriacutea de las veces el modelado de la vista de despliegueimplica modelar la topologiacutea del hardware sobre el que se ejecuta el sistema Aunque UML no es un lenguaje de especificacioacuten hardware de propoacutesito general se ha disentildeado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el softwaredel sistemaUsosAlgunos de los usos que se les da a los diagramas de despliegue son para modelarSistemas empotrados Un sistema empotrado es una coleccioacuten dehardware con una gran cantidad de software que interactuacutea conel mundo fiacutesicoSistemas cliente-servidor Los sistemas cliente-servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribucioacuten fiacutesica de los componentes software del sistema a traveacutes de nodosSistemas completamente distribuidos En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores Tales sistemas contienen a menudo varias versiones de componentes software alguno de los cuales pueden incluso migrar de un nodo a otro El disentildeo de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topologiacutea del sistema

Arquitectura

Arquitectura de software El disentildeo arquitectoacutenico es el proceso a traveacutes del cual se

identifican los subsistemas que componen un sistema de informacioacuten asiacute como los mecanismos de control y comunicacioacuten usados por los mismos

El resultado de este proceso es una descripcioacuten de la arquitectura del software

Disentildeo arquitectoacutenico

Etapa temprana en el proceso de desarrollo de un sistemade informacioacuten

Es el enlace entre la especificacioacuten del sistema y el desarrollo del mismo

Implica identificar los principales componentes del sistema y su mecanismo de comunicacioacuten

Ventajas

Comunicacioacuten entre los interesados Reutilizacioacuten a gran escala Anaacutelisis del sistema (requerimientos no funcionales)

Estructura del sistema

Descompone el sistema en subsistemas que interactuacutean entre si

Se expresa como un diagrama de bloques presentando una visioacuten general del sistema

En caso de que sea necesario se puede aumentar el detalle de alguacuten subsistema importante

Subsistemas

Decisiones arquitectoacutenicas Existe alguacuten ejemplo de arquitectura geneacuterica que pueda

aplicarse Como se distribuiraacute el sistema Alguacuten estilo de arquitectura es aplicable Como se descompondraacute el sistema en moacutedulos Como se controlaran y comunicaran esos moacutedulos

Estilos arquitectoacutenicos

El modelo arquitectoacutenico de un sistema puede basarse en un estilo o modelo geneacuterico de arquitectura

Conocer estos modelos de antemano puede facilitar la tarea de definir la arquitectura de un sistema

Los grandes sistemas son heterogeacuteneos no siguiendo un claro estilo arquitectoacutenico uacutenico

Modelos arquitectoacutenicos Usados para documentar la arquitectura de un sistema Modelos estaacuteticos estructurales Modelos dinaacutemicos de procesos Modelos de interfaces Modelos de datos Modelos de deployment

Coacutedigo

El coacutedigo fuente de un programa informaacutetico (o software) es un conjunto de liacuteneas de texto que son las instrucciones que debe seguir la computadora para ejecutar dicho programa Por tanto en el coacutedigo fuente de un programa estaacute escrito por completo su funcionamientoEl coacutedigo fuente de un programa que estaacute escrito por un programador en alguacuten lenguaje de programacioacuten pero en este primer estado no es directamente ejecutable por la computadora sino que debe ser traducido a otro lenguaje (el lenguaje maacutequina o coacutedigo objeto) que siacute pueda ser ejecutado por el hardware de la computadora Para esta traduccioacuten se usan los llamados compiladores ensambladores inteacuterpretes y otros sistemas de traduccioacutenEl teacutermino coacutedigo fuente tambieacuten se usa para hacer referenciaal coacutedigo fuente de otros elementos del software como por ejemplo el coacutedigo fuente de una paacutegina web que estaacute escrito en el lenguaje de marcado HTML o en Javascript u otros lenguajes de programacioacuten web y que es posteriormente ejecutado por el navegador web para visualizar dicha paacutegina cuando es visitadaEl aacuterea de la informaacutetica que se dedica a la creacioacuten de

programas y por tanto a la creacioacuten de su coacutedigo fuente es la programacioacuten

RequisitoRequisitos del software propiedades y atributos Propiedades deseables de los requisitos del software

Propiedades que deben tener todos los requisitos para estar bien especificados

Al inspeccionar los requisitos deben cuestionarse estas propiedades

o Utilizar cuestionarios de validacioacuten para inspeccionar requisitos 1113088 Dos tipos o Propiedades globales completitud consistenciao Propiedades individuales tamantildeo claridad comprobabilidad condiciones de error trazabilidad (funcionales no funcionales)

No confundir con los atributos de los requisitos toman un valor distinto en cada caso

o Necesidad prioridad y riesgo

Tamantildeo

Para manejar con mayor facilidad un requisito deberaacute tener un tamantildeo adecuado o ni tan grande que sea inmanejableo ni tan pequentildeo que no valga la pena seguirle la pista por separado

Es posible aplicar los principios de modularidad y anidamiento a los requisitos

Nivel de granularidad la misma cantidad de informacioacuten puede repartirse en un nuacutemero grandepequentildeo de requisitos (grano finogrueso)

Nivel de detalle los requisitos contienen maacutes detalles globalmente maacutes informacioacuten

Completitud Significa que no hay omisiones que comprometan la

integridad de los requisitoso No faltan requisitos (propiedad global)o No faltan detalles en la especificacioacuten de cada requisito (propiedad individual)

Es una propiedad difiacutecil de determinar (tan soacutelo podemos alcanzar una aproximacioacuten) o Contrastar con el cliente

o Comparar con proyectos semejantes Buscar la visioacuten de conjunto detectar huecos o partes

infra-especificadas o Una manera de comprobarlo para cada requisito comprobar que estaacuten presentes los demaacutes requisitos relacionados

La buena organizacioacuten facilita la deteccioacuten de faltas o Ejemplo organizacioacuten por tipos de requisitos

Teacutecnicas estadiacutesticas para estimar el nuacutemero de requisitos auacuten no descubiertoso Ritmo temporal de creacioacutenmodificacioacuten de requisitoso Ajustar la ldquonube de puntosrdquo (tiempo-requisitos conocidos) a una curva

monoacutetona creciente acotada (iquesthipeacuterbola) Consistencia (o coherencia)

Significa que no hay contradicciones entre requisitos (ni acoplamientos-redundancias)

Contradiccioacuten = Ambiguedad pero las ambiguedades difultan detectar contradicciones

Es maacutes difiacutecil de comprobar si el nuacutemero de requisitos crece

Una buena organizacioacuten facilita la deteccioacuten de contradicciones

Ejemplo tabla de referencia cruzadas que ademaacutes facilita la deteccioacuten de requisitos afectados por la modificacioacuten de uno dado (distinta de la tabla de composicioacuten F-NF)

o Conflicto contradiccioacuten no se pueden satisfacer simultaacuteneamenteo Acoplamiento hablan de lo mismo (si cambia uno puede afectar al otro) o Redundancia dicen lo mismo (sobra uno de los dos)o Independencia

En la versioacuten final no puede haber Conflictos ni Redundancias siacute Acoplamientos

Claridad

Significa que no hay ambiguedad en la especificacioacuten de cada requisito

Utilizar un vocabulario controlado y tabla de teacuterminos equivalentes (sinoacutenimos)

Para cualquier labor de escritura o Tenga siempre a mano diccionarios (normal sinoacutenimos estilo idiomas corrector ortograacutefico y sintaacutectico) o Escribir corregir escribir corregir y hacerlo entre varios (uno escribe otro corrige) o Respetar normas ortograacuteficas sintaacutecticas gramaticales estiliacutesticas no es un capricho lo que no estaacute bien escrito no se entiende o Estructurar bien proceder con orden proporcionar las referencias necesarias o Sintetizar resaltar ideas importantes resaltar maacutes lo menos obvio Comprobabilidad

Incluye dos tipos distintos de defectos que se desea descubrir y eliminar o Validacioacuten defectos de interpretacioacuten (do the right thing)o Verificacioacuten defectos de implementacioacuten (do the thingright)

Muchos defectos se pueden descubrir y eliminar mediante pruebas pero salvo que se usen meacutetodos formales las pruebas no garantizan que todos los defectos desaparecen

Atencioacuten las pruebas de verificacioacuten no sirven como pruebas de validacioacuten

Para validar y verificar un requisito es necesario que eacuteste sea comprobable (testable)

Un requisito no comprobable o ambiguo tiene escaso valor y debe ser rechazado

Ejemplos o El sistema mostraraacute la diferencia entre el valor observado y la media mundial (no comprobable) o El sistema mostraraacute la diferencia entre el valor observado y el valor publicado por Naciones Unidas (iquestcuaacutendo todaviacutea esambiguo) o El sistema mostraraacute la diferencia entre el valor observado y el uacuteltimo valor publicado por Naciones Unidas en su paacutegina web

Conviene asegurar que no es ambiguo ni siquiera si se interpretase mal a propoacutesito

Esbozar una prueba especiacutefica que estableceriacutea la satisfaccioacuten

La definicioacuten de pruebas ayuda a clarificar el sentido de cada requisito

Condiciones de error Para estar completa la especificacioacuten del requisito

debe tener en cuenta las condiciones de error es decirqueacute ocurre con el requisito en una situacioacuten con errores

Las condiciones de error son especialmente importantes para realizar las pruebas ya que al probar un requisitose fuerzan condiciones de error y es necesario prever queacute debe ocurrir en estos casos Caso tiacutepico datos de entrada incorrectos

o Ejemplo clasificar un triaacutengulo a partir de las coordenadas de sus tres veacutertices 1113088 No confiar en que no se produciraacuten condiciones de error esto aumenta la dependencia entre moacutedulos (un moacutedulo confiacutea en la deteccioacuten de errores deotro moacutedulo) o Pero recordar que no se debe abusar del manejode errores internos

Redundancia para promover la seguridad Determinar lo que hay que hacer en situaciones no

previstas (prever lo imprevisto) Prevenir posibles errores de programacioacuten en lugares

criacuteticos

Trazabilidad de requisitos funcionales Es la correspondencia entre cada requisito del software

yo uno o maacutes requisitos del usuario u otras fuentes (trazabilidad hacia atraacutes)o una o varias partes del disentildeo o la implementacioacuten (trazabilidad hacia adelante)

La relacioacuten RU-RS es tiacutepicamente uno-a-pocos Todo RU debe ser desarrollado por al menos un RS pero puede haber un RS cuya fuente no sea un RU (PSS-05-03 3 y 47)

o No confundir con el caso de nuevos RU que se descubren durante el desarrollo de los RS y que deberaacuten ser validados por el usuario nueva versioacuten URD o Verdadero RS sin RU todo RS debe tener una buena razoacuten para existir con mayor razoacuten si no existe un RU correspondiente el cliente no querraacute pagar por cosas que no ha encargado

Es necesaria para poder comprobar que la aplicacioacuten satisface los requisitos

Una forma de conseguirla es relacionar cada requisito funcional con una funcioacuten

especiacutefica en el lenguaje destino o Esta teacutecnica es poco generalizable y limitada produce excesivo acoplamiento entre la estructura de los requisitos y la estructura de la implementacioacuten o En OO no es trivial preguntarse queacute clase esresponsable de queacute funcioacuten

Funcioacuten con un solo paraacutemetro F(x) xF( ) Funcioacuten con dos o maacutes paraacutemetros G(x y) xG(y)

yG(x) La transicioacuten Anaacutelisis-Disentildeo no es sencilla ni tiene

por queacute serlo Es muy necesaria para afrontar que los requisitos

cambian y gestionar su evolucioacuten o Si la gestioacuten de la trazabilidad es difiacutecil y lleva demasiado trabajo los desarrolladores tenderaacuten a evitar la actualizacioacuten del documento de requisitos e iraacuten directamentea hacer cambios al coacutedigo en consecuencia el documento de requisitos se hace inuacutetil para las pruebas y la validacioacuten o Si ademaacutes el documento no es fiable por culpa de algunos miembros del equipo menos responsables entonces ni siquiera los maacutes responsables se tomaraacuten la molestia de mantenerlo al diacutea o Por tanto el sistema para hacer corresponder requisitos con disentildeo y coacutedigo debe ser claro y concreto o Ejemplo matrices de trazabilidad de requisitos 1113088 hacia atraacutes hacia delante 1113088 distintas de la tabla de referencias cruzadas entre requisitos para gestionar la consistencia

1113088 Un requisito puede corresponderse con varias partes del coacutedigo (funciones) que a su vez pueden implementar varios requisitos cada una o Por tanto antes de cambiar el coacutedigo para adaptarse a un cambio en un requisito hay que comprobar que otros requisitos no quedan comprometidos o La correspondencia Requisito-Funcioacuten es muchos-a-muchos sino puede ser uno-uno al menos puede intentarse que sea pocos-pocos o El disentildeo juega un papel fundamental en establecer esta correspondencia

Trazabilidad de requisitos no funcionales La correspondencia con elementos del disentildeo y de la

implementacioacuten es mucho maacutes difiacutecil ya que depende en mayor medida de la colaboracioacuten entre varios elementos

La validacioacuten de estos requisitos es maacutes complicada normalmente requiere un mayor nivel de integracioacuten del sistema (no es faacutecil validar NFRS en componentes aislados)

Ejemplo rendimiento o Identificar los elementos que consumen maacutes tiempo o memoriao La mayor parte de los recursos son consumidos por un nuacutemeroreducido de elementos de modo que esta tarea es provechosa para mejorar el rendimiento o Bucles graacuteficos y comunicaciones suelen ser los que maacutes tiempo consumen

ATRIBUTOS Necesidad y prioridad

Para negociar entre funcionalidad planificacioacuten presupuesto y nivel de calidad es conveniente que los requisitos funcionales tengan asignado un nivel de necesidad (tres o cuatro categoriacuteas esencial deseableopcional) asiacute como un nivel de prioridad temporal (dos o tres categoriacuteas alta baja)

La necesidad de un requisito hace referencia al intereacutes de los usuariosclientes en que la aplicacioacuten lo

realice y hasta queacute punto estariacutean dispuestos a pasarsesi eacutel

La prioridad de un requisito hace referencia al orden temporal indica en queacute fase de construccioacuten del sistemase incluiraacute la funcionalidad que realice el requisito

Si el 20 de la aplicacioacuten proporciona el 80 de su valor no maacutes del 20 de los requisitos deberiacutean ser ldquoesencialesrdquo

Riesgo Cada requisito deberiacutea ir acompantildeado de una estimacioacuten

del riesgo que supone realizarlo (relacionado con la dificultad de implementarlo) Ej alto moderado bajo

Seguir la pista con especial atencioacuten a los de mayor riesgo

Para escribir un requisito resumen Enunciado breve del mismo numerado Explicacioacuten detallada Atributos y propiedades tal como se han discutido hasta

aquiacute por ejemplo o Necesidad Prioridad y Riesgoo Condiciones de erroro Pruebas de validacioacuten y verificacioacuten requeridas

Tabla de composicioacuten de requisitos funcionales-no funcionales

Tabla de referencias cruzadas entre requisitos conflicto acoplamiento redundancia

Matrices de trazabilidad hacia requisitos de usuario y hacia disentildeoimplementacioacuten

Usar un formato que permita distintos niveles de visibilidad

o soacutelo enunciadoo soacutelo enunciado y descripcioacuteno enunciado descripcioacuten y propiedades

DiagramaDiagramas de secuencias

El diagrama de secuencia es un tipo de diagrama usado para modelarinteraccioacuten entre objetos en un sistema seguacuten UML

Un diagrama de secuencia muestra la interaccioacuten de un conjunto de objetos en una aplicacioacuten a traveacutes del tiempo y se modela para cada caso de uso Mientras que el diagrama de casos de uso permiteel modelado de una vista business del escenario el diagrama de secuencia contiene detalles de implementacioacuten del escenario incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos

Diagrama de secuencias del disentildeo

La fase de disentildeo (y los modelos UML resultantes) expande y detalla los modelos de anaacutelisis tomando en cuenta todas las implicaciones y restricciones teacutecnicas El propoacutesito del disentildeo es especificar una solucioacuten que trabaje y pueda ser faacutecilmente convertida en coacutedigo fuente y construir una arquitectura simple y faacutecilmente extensible Las clases definidas en el anaacutelisis fueron detalladas y se antildeadieron nuevas clases para manejar aacutereas teacutecnicas como base de datosinterfaz del usuario comunicacioacuten dispositivos etc

Diagrama de secuencia

Los casos de uso deben ser realizados durante esta etapa Para describir el comportamiento dinaacutemico del sistema cualquiera de los diagramas de interaccioacuten del UML pueden ser

utilizados Debido a que Rational Rose no soporta los diagramas de actividad y ofrece soporte limitado para los diagramas de colaboracioacuten (en notacioacuten completa del UML) usaremos diagramas de secuencia

Diagramas de componentes

Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de ModeladoUn diagrama de componentes representa coacutemo un sistema de software es dividido en componentes y muestra las

dependencias entre estos componentes Los componentes fiacutesicosincluyen archivos cabeceras bibliotecas compartidas moacutedulos ejecutables o paquetes Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistemaDebido a que los diagramas de componentes son maacutes parecidos alos diagramas de casos de usos eacutestos son utilizados para modelar la vista estaacutetica y dinaacutemica de un sistema Muestra la organizacioacuten y las dependencias entre un conjunto de componentes No es necesario que un diagrama incluya todos los componentes del sistema normalmente se realizan por partes Cada diagrama describe un apartado del sistemaEn eacutel se situaraacuten libreriacuteas tablas archivos ejecutables y documentos que formen parte del sistemaUno de los usos principales es que puede servir para ver queacute componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema

Diagramas de despliegue

El Diagrama de Despliegue es un tipo de diagrama del LenguajeUnificado de Modelado que se utiliza para modelar la disposicioacuten fiacutesica de los artefactos software en nodos (usualmente plataforma de hardware)Aspectos GeneralesLa mayoriacutea de las veces el modelado de la vista de despliegueimplica modelar la topologiacutea del hardware sobre el que se ejecuta el sistema Aunque UML no es un lenguaje de especificacioacuten hardware de propoacutesito general se ha disentildeado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el softwaredel sistemaUsosAlgunos de los usos que se les da a los diagramas de despliegue son para modelarSistemas empotrados Un sistema empotrado es una coleccioacuten dehardware con una gran cantidad de software que interactuacutea conel mundo fiacutesicoSistemas cliente-servidor Los sistemas cliente-servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribucioacuten fiacutesica de los componentes software del sistema a traveacutes de nodosSistemas completamente distribuidos En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores Tales sistemas contienen a menudo varias versiones de componentes software alguno de los cuales pueden incluso migrar de un nodo a otro El disentildeo de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topologiacutea del sistema

Arquitectura

Arquitectura de software El disentildeo arquitectoacutenico es el proceso a traveacutes del cual se

identifican los subsistemas que componen un sistema de informacioacuten asiacute como los mecanismos de control y comunicacioacuten usados por los mismos

El resultado de este proceso es una descripcioacuten de la arquitectura del software

Disentildeo arquitectoacutenico

Etapa temprana en el proceso de desarrollo de un sistemade informacioacuten

Es el enlace entre la especificacioacuten del sistema y el desarrollo del mismo

Implica identificar los principales componentes del sistema y su mecanismo de comunicacioacuten

Ventajas

Comunicacioacuten entre los interesados Reutilizacioacuten a gran escala Anaacutelisis del sistema (requerimientos no funcionales)

Estructura del sistema

Descompone el sistema en subsistemas que interactuacutean entre si

Se expresa como un diagrama de bloques presentando una visioacuten general del sistema

En caso de que sea necesario se puede aumentar el detalle de alguacuten subsistema importante

Subsistemas

Decisiones arquitectoacutenicas Existe alguacuten ejemplo de arquitectura geneacuterica que pueda

aplicarse Como se distribuiraacute el sistema Alguacuten estilo de arquitectura es aplicable Como se descompondraacute el sistema en moacutedulos Como se controlaran y comunicaran esos moacutedulos

Estilos arquitectoacutenicos

El modelo arquitectoacutenico de un sistema puede basarse en un estilo o modelo geneacuterico de arquitectura

Conocer estos modelos de antemano puede facilitar la tarea de definir la arquitectura de un sistema

Los grandes sistemas son heterogeacuteneos no siguiendo un claro estilo arquitectoacutenico uacutenico

Modelos arquitectoacutenicos Usados para documentar la arquitectura de un sistema Modelos estaacuteticos estructurales Modelos dinaacutemicos de procesos Modelos de interfaces Modelos de datos Modelos de deployment

Coacutedigo

El coacutedigo fuente de un programa informaacutetico (o software) es un conjunto de liacuteneas de texto que son las instrucciones que debe seguir la computadora para ejecutar dicho programa Por tanto en el coacutedigo fuente de un programa estaacute escrito por completo su funcionamientoEl coacutedigo fuente de un programa que estaacute escrito por un programador en alguacuten lenguaje de programacioacuten pero en este primer estado no es directamente ejecutable por la computadora sino que debe ser traducido a otro lenguaje (el lenguaje maacutequina o coacutedigo objeto) que siacute pueda ser ejecutado por el hardware de la computadora Para esta traduccioacuten se usan los llamados compiladores ensambladores inteacuterpretes y otros sistemas de traduccioacutenEl teacutermino coacutedigo fuente tambieacuten se usa para hacer referenciaal coacutedigo fuente de otros elementos del software como por ejemplo el coacutedigo fuente de una paacutegina web que estaacute escrito en el lenguaje de marcado HTML o en Javascript u otros lenguajes de programacioacuten web y que es posteriormente ejecutado por el navegador web para visualizar dicha paacutegina cuando es visitadaEl aacuterea de la informaacutetica que se dedica a la creacioacuten de

programas y por tanto a la creacioacuten de su coacutedigo fuente es la programacioacuten

Es una propiedad difiacutecil de determinar (tan soacutelo podemos alcanzar una aproximacioacuten) o Contrastar con el cliente

o Comparar con proyectos semejantes Buscar la visioacuten de conjunto detectar huecos o partes

infra-especificadas o Una manera de comprobarlo para cada requisito comprobar que estaacuten presentes los demaacutes requisitos relacionados

La buena organizacioacuten facilita la deteccioacuten de faltas o Ejemplo organizacioacuten por tipos de requisitos

Teacutecnicas estadiacutesticas para estimar el nuacutemero de requisitos auacuten no descubiertoso Ritmo temporal de creacioacutenmodificacioacuten de requisitoso Ajustar la ldquonube de puntosrdquo (tiempo-requisitos conocidos) a una curva

monoacutetona creciente acotada (iquesthipeacuterbola) Consistencia (o coherencia)

Significa que no hay contradicciones entre requisitos (ni acoplamientos-redundancias)

Contradiccioacuten = Ambiguedad pero las ambiguedades difultan detectar contradicciones

Es maacutes difiacutecil de comprobar si el nuacutemero de requisitos crece

Una buena organizacioacuten facilita la deteccioacuten de contradicciones

Ejemplo tabla de referencia cruzadas que ademaacutes facilita la deteccioacuten de requisitos afectados por la modificacioacuten de uno dado (distinta de la tabla de composicioacuten F-NF)

o Conflicto contradiccioacuten no se pueden satisfacer simultaacuteneamenteo Acoplamiento hablan de lo mismo (si cambia uno puede afectar al otro) o Redundancia dicen lo mismo (sobra uno de los dos)o Independencia

En la versioacuten final no puede haber Conflictos ni Redundancias siacute Acoplamientos

Claridad

Significa que no hay ambiguedad en la especificacioacuten de cada requisito

Utilizar un vocabulario controlado y tabla de teacuterminos equivalentes (sinoacutenimos)

Para cualquier labor de escritura o Tenga siempre a mano diccionarios (normal sinoacutenimos estilo idiomas corrector ortograacutefico y sintaacutectico) o Escribir corregir escribir corregir y hacerlo entre varios (uno escribe otro corrige) o Respetar normas ortograacuteficas sintaacutecticas gramaticales estiliacutesticas no es un capricho lo que no estaacute bien escrito no se entiende o Estructurar bien proceder con orden proporcionar las referencias necesarias o Sintetizar resaltar ideas importantes resaltar maacutes lo menos obvio Comprobabilidad

Incluye dos tipos distintos de defectos que se desea descubrir y eliminar o Validacioacuten defectos de interpretacioacuten (do the right thing)o Verificacioacuten defectos de implementacioacuten (do the thingright)

Muchos defectos se pueden descubrir y eliminar mediante pruebas pero salvo que se usen meacutetodos formales las pruebas no garantizan que todos los defectos desaparecen

Atencioacuten las pruebas de verificacioacuten no sirven como pruebas de validacioacuten

Para validar y verificar un requisito es necesario que eacuteste sea comprobable (testable)

Un requisito no comprobable o ambiguo tiene escaso valor y debe ser rechazado

Ejemplos o El sistema mostraraacute la diferencia entre el valor observado y la media mundial (no comprobable) o El sistema mostraraacute la diferencia entre el valor observado y el valor publicado por Naciones Unidas (iquestcuaacutendo todaviacutea esambiguo) o El sistema mostraraacute la diferencia entre el valor observado y el uacuteltimo valor publicado por Naciones Unidas en su paacutegina web

Conviene asegurar que no es ambiguo ni siquiera si se interpretase mal a propoacutesito

Esbozar una prueba especiacutefica que estableceriacutea la satisfaccioacuten

La definicioacuten de pruebas ayuda a clarificar el sentido de cada requisito

Condiciones de error Para estar completa la especificacioacuten del requisito

debe tener en cuenta las condiciones de error es decirqueacute ocurre con el requisito en una situacioacuten con errores

Las condiciones de error son especialmente importantes para realizar las pruebas ya que al probar un requisitose fuerzan condiciones de error y es necesario prever queacute debe ocurrir en estos casos Caso tiacutepico datos de entrada incorrectos

o Ejemplo clasificar un triaacutengulo a partir de las coordenadas de sus tres veacutertices 1113088 No confiar en que no se produciraacuten condiciones de error esto aumenta la dependencia entre moacutedulos (un moacutedulo confiacutea en la deteccioacuten de errores deotro moacutedulo) o Pero recordar que no se debe abusar del manejode errores internos

Redundancia para promover la seguridad Determinar lo que hay que hacer en situaciones no

previstas (prever lo imprevisto) Prevenir posibles errores de programacioacuten en lugares

criacuteticos

Trazabilidad de requisitos funcionales Es la correspondencia entre cada requisito del software

yo uno o maacutes requisitos del usuario u otras fuentes (trazabilidad hacia atraacutes)o una o varias partes del disentildeo o la implementacioacuten (trazabilidad hacia adelante)

La relacioacuten RU-RS es tiacutepicamente uno-a-pocos Todo RU debe ser desarrollado por al menos un RS pero puede haber un RS cuya fuente no sea un RU (PSS-05-03 3 y 47)

o No confundir con el caso de nuevos RU que se descubren durante el desarrollo de los RS y que deberaacuten ser validados por el usuario nueva versioacuten URD o Verdadero RS sin RU todo RS debe tener una buena razoacuten para existir con mayor razoacuten si no existe un RU correspondiente el cliente no querraacute pagar por cosas que no ha encargado

Es necesaria para poder comprobar que la aplicacioacuten satisface los requisitos

Una forma de conseguirla es relacionar cada requisito funcional con una funcioacuten

especiacutefica en el lenguaje destino o Esta teacutecnica es poco generalizable y limitada produce excesivo acoplamiento entre la estructura de los requisitos y la estructura de la implementacioacuten o En OO no es trivial preguntarse queacute clase esresponsable de queacute funcioacuten

Funcioacuten con un solo paraacutemetro F(x) xF( ) Funcioacuten con dos o maacutes paraacutemetros G(x y) xG(y)

yG(x) La transicioacuten Anaacutelisis-Disentildeo no es sencilla ni tiene

por queacute serlo Es muy necesaria para afrontar que los requisitos

cambian y gestionar su evolucioacuten o Si la gestioacuten de la trazabilidad es difiacutecil y lleva demasiado trabajo los desarrolladores tenderaacuten a evitar la actualizacioacuten del documento de requisitos e iraacuten directamentea hacer cambios al coacutedigo en consecuencia el documento de requisitos se hace inuacutetil para las pruebas y la validacioacuten o Si ademaacutes el documento no es fiable por culpa de algunos miembros del equipo menos responsables entonces ni siquiera los maacutes responsables se tomaraacuten la molestia de mantenerlo al diacutea o Por tanto el sistema para hacer corresponder requisitos con disentildeo y coacutedigo debe ser claro y concreto o Ejemplo matrices de trazabilidad de requisitos 1113088 hacia atraacutes hacia delante 1113088 distintas de la tabla de referencias cruzadas entre requisitos para gestionar la consistencia

1113088 Un requisito puede corresponderse con varias partes del coacutedigo (funciones) que a su vez pueden implementar varios requisitos cada una o Por tanto antes de cambiar el coacutedigo para adaptarse a un cambio en un requisito hay que comprobar que otros requisitos no quedan comprometidos o La correspondencia Requisito-Funcioacuten es muchos-a-muchos sino puede ser uno-uno al menos puede intentarse que sea pocos-pocos o El disentildeo juega un papel fundamental en establecer esta correspondencia

Trazabilidad de requisitos no funcionales La correspondencia con elementos del disentildeo y de la

implementacioacuten es mucho maacutes difiacutecil ya que depende en mayor medida de la colaboracioacuten entre varios elementos

La validacioacuten de estos requisitos es maacutes complicada normalmente requiere un mayor nivel de integracioacuten del sistema (no es faacutecil validar NFRS en componentes aislados)

Ejemplo rendimiento o Identificar los elementos que consumen maacutes tiempo o memoriao La mayor parte de los recursos son consumidos por un nuacutemeroreducido de elementos de modo que esta tarea es provechosa para mejorar el rendimiento o Bucles graacuteficos y comunicaciones suelen ser los que maacutes tiempo consumen

ATRIBUTOS Necesidad y prioridad

Para negociar entre funcionalidad planificacioacuten presupuesto y nivel de calidad es conveniente que los requisitos funcionales tengan asignado un nivel de necesidad (tres o cuatro categoriacuteas esencial deseableopcional) asiacute como un nivel de prioridad temporal (dos o tres categoriacuteas alta baja)

La necesidad de un requisito hace referencia al intereacutes de los usuariosclientes en que la aplicacioacuten lo

realice y hasta queacute punto estariacutean dispuestos a pasarsesi eacutel

La prioridad de un requisito hace referencia al orden temporal indica en queacute fase de construccioacuten del sistemase incluiraacute la funcionalidad que realice el requisito

Si el 20 de la aplicacioacuten proporciona el 80 de su valor no maacutes del 20 de los requisitos deberiacutean ser ldquoesencialesrdquo

Riesgo Cada requisito deberiacutea ir acompantildeado de una estimacioacuten

del riesgo que supone realizarlo (relacionado con la dificultad de implementarlo) Ej alto moderado bajo

Seguir la pista con especial atencioacuten a los de mayor riesgo

Para escribir un requisito resumen Enunciado breve del mismo numerado Explicacioacuten detallada Atributos y propiedades tal como se han discutido hasta

aquiacute por ejemplo o Necesidad Prioridad y Riesgoo Condiciones de erroro Pruebas de validacioacuten y verificacioacuten requeridas

Tabla de composicioacuten de requisitos funcionales-no funcionales

Tabla de referencias cruzadas entre requisitos conflicto acoplamiento redundancia

Matrices de trazabilidad hacia requisitos de usuario y hacia disentildeoimplementacioacuten

Usar un formato que permita distintos niveles de visibilidad

o soacutelo enunciadoo soacutelo enunciado y descripcioacuteno enunciado descripcioacuten y propiedades

DiagramaDiagramas de secuencias

El diagrama de secuencia es un tipo de diagrama usado para modelarinteraccioacuten entre objetos en un sistema seguacuten UML

Un diagrama de secuencia muestra la interaccioacuten de un conjunto de objetos en una aplicacioacuten a traveacutes del tiempo y se modela para cada caso de uso Mientras que el diagrama de casos de uso permiteel modelado de una vista business del escenario el diagrama de secuencia contiene detalles de implementacioacuten del escenario incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos

Diagrama de secuencias del disentildeo

La fase de disentildeo (y los modelos UML resultantes) expande y detalla los modelos de anaacutelisis tomando en cuenta todas las implicaciones y restricciones teacutecnicas El propoacutesito del disentildeo es especificar una solucioacuten que trabaje y pueda ser faacutecilmente convertida en coacutedigo fuente y construir una arquitectura simple y faacutecilmente extensible Las clases definidas en el anaacutelisis fueron detalladas y se antildeadieron nuevas clases para manejar aacutereas teacutecnicas como base de datosinterfaz del usuario comunicacioacuten dispositivos etc

Diagrama de secuencia

Los casos de uso deben ser realizados durante esta etapa Para describir el comportamiento dinaacutemico del sistema cualquiera de los diagramas de interaccioacuten del UML pueden ser

utilizados Debido a que Rational Rose no soporta los diagramas de actividad y ofrece soporte limitado para los diagramas de colaboracioacuten (en notacioacuten completa del UML) usaremos diagramas de secuencia

Diagramas de componentes

Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de ModeladoUn diagrama de componentes representa coacutemo un sistema de software es dividido en componentes y muestra las

dependencias entre estos componentes Los componentes fiacutesicosincluyen archivos cabeceras bibliotecas compartidas moacutedulos ejecutables o paquetes Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistemaDebido a que los diagramas de componentes son maacutes parecidos alos diagramas de casos de usos eacutestos son utilizados para modelar la vista estaacutetica y dinaacutemica de un sistema Muestra la organizacioacuten y las dependencias entre un conjunto de componentes No es necesario que un diagrama incluya todos los componentes del sistema normalmente se realizan por partes Cada diagrama describe un apartado del sistemaEn eacutel se situaraacuten libreriacuteas tablas archivos ejecutables y documentos que formen parte del sistemaUno de los usos principales es que puede servir para ver queacute componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema

Diagramas de despliegue

El Diagrama de Despliegue es un tipo de diagrama del LenguajeUnificado de Modelado que se utiliza para modelar la disposicioacuten fiacutesica de los artefactos software en nodos (usualmente plataforma de hardware)Aspectos GeneralesLa mayoriacutea de las veces el modelado de la vista de despliegueimplica modelar la topologiacutea del hardware sobre el que se ejecuta el sistema Aunque UML no es un lenguaje de especificacioacuten hardware de propoacutesito general se ha disentildeado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el softwaredel sistemaUsosAlgunos de los usos que se les da a los diagramas de despliegue son para modelarSistemas empotrados Un sistema empotrado es una coleccioacuten dehardware con una gran cantidad de software que interactuacutea conel mundo fiacutesicoSistemas cliente-servidor Los sistemas cliente-servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribucioacuten fiacutesica de los componentes software del sistema a traveacutes de nodosSistemas completamente distribuidos En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores Tales sistemas contienen a menudo varias versiones de componentes software alguno de los cuales pueden incluso migrar de un nodo a otro El disentildeo de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topologiacutea del sistema

Arquitectura

Arquitectura de software El disentildeo arquitectoacutenico es el proceso a traveacutes del cual se

identifican los subsistemas que componen un sistema de informacioacuten asiacute como los mecanismos de control y comunicacioacuten usados por los mismos

El resultado de este proceso es una descripcioacuten de la arquitectura del software

Disentildeo arquitectoacutenico

Etapa temprana en el proceso de desarrollo de un sistemade informacioacuten

Es el enlace entre la especificacioacuten del sistema y el desarrollo del mismo

Implica identificar los principales componentes del sistema y su mecanismo de comunicacioacuten

Ventajas

Comunicacioacuten entre los interesados Reutilizacioacuten a gran escala Anaacutelisis del sistema (requerimientos no funcionales)

Estructura del sistema

Descompone el sistema en subsistemas que interactuacutean entre si

Se expresa como un diagrama de bloques presentando una visioacuten general del sistema

En caso de que sea necesario se puede aumentar el detalle de alguacuten subsistema importante

Subsistemas

Decisiones arquitectoacutenicas Existe alguacuten ejemplo de arquitectura geneacuterica que pueda

aplicarse Como se distribuiraacute el sistema Alguacuten estilo de arquitectura es aplicable Como se descompondraacute el sistema en moacutedulos Como se controlaran y comunicaran esos moacutedulos

Estilos arquitectoacutenicos

El modelo arquitectoacutenico de un sistema puede basarse en un estilo o modelo geneacuterico de arquitectura

Conocer estos modelos de antemano puede facilitar la tarea de definir la arquitectura de un sistema

Los grandes sistemas son heterogeacuteneos no siguiendo un claro estilo arquitectoacutenico uacutenico

Modelos arquitectoacutenicos Usados para documentar la arquitectura de un sistema Modelos estaacuteticos estructurales Modelos dinaacutemicos de procesos Modelos de interfaces Modelos de datos Modelos de deployment

Coacutedigo

El coacutedigo fuente de un programa informaacutetico (o software) es un conjunto de liacuteneas de texto que son las instrucciones que debe seguir la computadora para ejecutar dicho programa Por tanto en el coacutedigo fuente de un programa estaacute escrito por completo su funcionamientoEl coacutedigo fuente de un programa que estaacute escrito por un programador en alguacuten lenguaje de programacioacuten pero en este primer estado no es directamente ejecutable por la computadora sino que debe ser traducido a otro lenguaje (el lenguaje maacutequina o coacutedigo objeto) que siacute pueda ser ejecutado por el hardware de la computadora Para esta traduccioacuten se usan los llamados compiladores ensambladores inteacuterpretes y otros sistemas de traduccioacutenEl teacutermino coacutedigo fuente tambieacuten se usa para hacer referenciaal coacutedigo fuente de otros elementos del software como por ejemplo el coacutedigo fuente de una paacutegina web que estaacute escrito en el lenguaje de marcado HTML o en Javascript u otros lenguajes de programacioacuten web y que es posteriormente ejecutado por el navegador web para visualizar dicha paacutegina cuando es visitadaEl aacuterea de la informaacutetica que se dedica a la creacioacuten de

programas y por tanto a la creacioacuten de su coacutedigo fuente es la programacioacuten

Significa que no hay ambiguedad en la especificacioacuten de cada requisito

Utilizar un vocabulario controlado y tabla de teacuterminos equivalentes (sinoacutenimos)

Para cualquier labor de escritura o Tenga siempre a mano diccionarios (normal sinoacutenimos estilo idiomas corrector ortograacutefico y sintaacutectico) o Escribir corregir escribir corregir y hacerlo entre varios (uno escribe otro corrige) o Respetar normas ortograacuteficas sintaacutecticas gramaticales estiliacutesticas no es un capricho lo que no estaacute bien escrito no se entiende o Estructurar bien proceder con orden proporcionar las referencias necesarias o Sintetizar resaltar ideas importantes resaltar maacutes lo menos obvio Comprobabilidad

Incluye dos tipos distintos de defectos que se desea descubrir y eliminar o Validacioacuten defectos de interpretacioacuten (do the right thing)o Verificacioacuten defectos de implementacioacuten (do the thingright)

Muchos defectos se pueden descubrir y eliminar mediante pruebas pero salvo que se usen meacutetodos formales las pruebas no garantizan que todos los defectos desaparecen

Atencioacuten las pruebas de verificacioacuten no sirven como pruebas de validacioacuten

Para validar y verificar un requisito es necesario que eacuteste sea comprobable (testable)

Un requisito no comprobable o ambiguo tiene escaso valor y debe ser rechazado

Ejemplos o El sistema mostraraacute la diferencia entre el valor observado y la media mundial (no comprobable) o El sistema mostraraacute la diferencia entre el valor observado y el valor publicado por Naciones Unidas (iquestcuaacutendo todaviacutea esambiguo) o El sistema mostraraacute la diferencia entre el valor observado y el uacuteltimo valor publicado por Naciones Unidas en su paacutegina web

Conviene asegurar que no es ambiguo ni siquiera si se interpretase mal a propoacutesito

Esbozar una prueba especiacutefica que estableceriacutea la satisfaccioacuten

La definicioacuten de pruebas ayuda a clarificar el sentido de cada requisito

Condiciones de error Para estar completa la especificacioacuten del requisito

debe tener en cuenta las condiciones de error es decirqueacute ocurre con el requisito en una situacioacuten con errores

Las condiciones de error son especialmente importantes para realizar las pruebas ya que al probar un requisitose fuerzan condiciones de error y es necesario prever queacute debe ocurrir en estos casos Caso tiacutepico datos de entrada incorrectos

o Ejemplo clasificar un triaacutengulo a partir de las coordenadas de sus tres veacutertices 1113088 No confiar en que no se produciraacuten condiciones de error esto aumenta la dependencia entre moacutedulos (un moacutedulo confiacutea en la deteccioacuten de errores deotro moacutedulo) o Pero recordar que no se debe abusar del manejode errores internos

Redundancia para promover la seguridad Determinar lo que hay que hacer en situaciones no

previstas (prever lo imprevisto) Prevenir posibles errores de programacioacuten en lugares

criacuteticos

Trazabilidad de requisitos funcionales Es la correspondencia entre cada requisito del software

yo uno o maacutes requisitos del usuario u otras fuentes (trazabilidad hacia atraacutes)o una o varias partes del disentildeo o la implementacioacuten (trazabilidad hacia adelante)

La relacioacuten RU-RS es tiacutepicamente uno-a-pocos Todo RU debe ser desarrollado por al menos un RS pero puede haber un RS cuya fuente no sea un RU (PSS-05-03 3 y 47)

o No confundir con el caso de nuevos RU que se descubren durante el desarrollo de los RS y que deberaacuten ser validados por el usuario nueva versioacuten URD o Verdadero RS sin RU todo RS debe tener una buena razoacuten para existir con mayor razoacuten si no existe un RU correspondiente el cliente no querraacute pagar por cosas que no ha encargado

Es necesaria para poder comprobar que la aplicacioacuten satisface los requisitos

Una forma de conseguirla es relacionar cada requisito funcional con una funcioacuten

especiacutefica en el lenguaje destino o Esta teacutecnica es poco generalizable y limitada produce excesivo acoplamiento entre la estructura de los requisitos y la estructura de la implementacioacuten o En OO no es trivial preguntarse queacute clase esresponsable de queacute funcioacuten

Funcioacuten con un solo paraacutemetro F(x) xF( ) Funcioacuten con dos o maacutes paraacutemetros G(x y) xG(y)

yG(x) La transicioacuten Anaacutelisis-Disentildeo no es sencilla ni tiene

por queacute serlo Es muy necesaria para afrontar que los requisitos

cambian y gestionar su evolucioacuten o Si la gestioacuten de la trazabilidad es difiacutecil y lleva demasiado trabajo los desarrolladores tenderaacuten a evitar la actualizacioacuten del documento de requisitos e iraacuten directamentea hacer cambios al coacutedigo en consecuencia el documento de requisitos se hace inuacutetil para las pruebas y la validacioacuten o Si ademaacutes el documento no es fiable por culpa de algunos miembros del equipo menos responsables entonces ni siquiera los maacutes responsables se tomaraacuten la molestia de mantenerlo al diacutea o Por tanto el sistema para hacer corresponder requisitos con disentildeo y coacutedigo debe ser claro y concreto o Ejemplo matrices de trazabilidad de requisitos 1113088 hacia atraacutes hacia delante 1113088 distintas de la tabla de referencias cruzadas entre requisitos para gestionar la consistencia

1113088 Un requisito puede corresponderse con varias partes del coacutedigo (funciones) que a su vez pueden implementar varios requisitos cada una o Por tanto antes de cambiar el coacutedigo para adaptarse a un cambio en un requisito hay que comprobar que otros requisitos no quedan comprometidos o La correspondencia Requisito-Funcioacuten es muchos-a-muchos sino puede ser uno-uno al menos puede intentarse que sea pocos-pocos o El disentildeo juega un papel fundamental en establecer esta correspondencia

Trazabilidad de requisitos no funcionales La correspondencia con elementos del disentildeo y de la

implementacioacuten es mucho maacutes difiacutecil ya que depende en mayor medida de la colaboracioacuten entre varios elementos

La validacioacuten de estos requisitos es maacutes complicada normalmente requiere un mayor nivel de integracioacuten del sistema (no es faacutecil validar NFRS en componentes aislados)

Ejemplo rendimiento o Identificar los elementos que consumen maacutes tiempo o memoriao La mayor parte de los recursos son consumidos por un nuacutemeroreducido de elementos de modo que esta tarea es provechosa para mejorar el rendimiento o Bucles graacuteficos y comunicaciones suelen ser los que maacutes tiempo consumen

ATRIBUTOS Necesidad y prioridad

Para negociar entre funcionalidad planificacioacuten presupuesto y nivel de calidad es conveniente que los requisitos funcionales tengan asignado un nivel de necesidad (tres o cuatro categoriacuteas esencial deseableopcional) asiacute como un nivel de prioridad temporal (dos o tres categoriacuteas alta baja)

La necesidad de un requisito hace referencia al intereacutes de los usuariosclientes en que la aplicacioacuten lo

realice y hasta queacute punto estariacutean dispuestos a pasarsesi eacutel

La prioridad de un requisito hace referencia al orden temporal indica en queacute fase de construccioacuten del sistemase incluiraacute la funcionalidad que realice el requisito

Si el 20 de la aplicacioacuten proporciona el 80 de su valor no maacutes del 20 de los requisitos deberiacutean ser ldquoesencialesrdquo

Riesgo Cada requisito deberiacutea ir acompantildeado de una estimacioacuten

del riesgo que supone realizarlo (relacionado con la dificultad de implementarlo) Ej alto moderado bajo

Seguir la pista con especial atencioacuten a los de mayor riesgo

Para escribir un requisito resumen Enunciado breve del mismo numerado Explicacioacuten detallada Atributos y propiedades tal como se han discutido hasta

aquiacute por ejemplo o Necesidad Prioridad y Riesgoo Condiciones de erroro Pruebas de validacioacuten y verificacioacuten requeridas

Tabla de composicioacuten de requisitos funcionales-no funcionales

Tabla de referencias cruzadas entre requisitos conflicto acoplamiento redundancia

Matrices de trazabilidad hacia requisitos de usuario y hacia disentildeoimplementacioacuten

Usar un formato que permita distintos niveles de visibilidad

o soacutelo enunciadoo soacutelo enunciado y descripcioacuteno enunciado descripcioacuten y propiedades

DiagramaDiagramas de secuencias

El diagrama de secuencia es un tipo de diagrama usado para modelarinteraccioacuten entre objetos en un sistema seguacuten UML

Un diagrama de secuencia muestra la interaccioacuten de un conjunto de objetos en una aplicacioacuten a traveacutes del tiempo y se modela para cada caso de uso Mientras que el diagrama de casos de uso permiteel modelado de una vista business del escenario el diagrama de secuencia contiene detalles de implementacioacuten del escenario incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos

Diagrama de secuencias del disentildeo

La fase de disentildeo (y los modelos UML resultantes) expande y detalla los modelos de anaacutelisis tomando en cuenta todas las implicaciones y restricciones teacutecnicas El propoacutesito del disentildeo es especificar una solucioacuten que trabaje y pueda ser faacutecilmente convertida en coacutedigo fuente y construir una arquitectura simple y faacutecilmente extensible Las clases definidas en el anaacutelisis fueron detalladas y se antildeadieron nuevas clases para manejar aacutereas teacutecnicas como base de datosinterfaz del usuario comunicacioacuten dispositivos etc

Diagrama de secuencia

Los casos de uso deben ser realizados durante esta etapa Para describir el comportamiento dinaacutemico del sistema cualquiera de los diagramas de interaccioacuten del UML pueden ser

utilizados Debido a que Rational Rose no soporta los diagramas de actividad y ofrece soporte limitado para los diagramas de colaboracioacuten (en notacioacuten completa del UML) usaremos diagramas de secuencia

Diagramas de componentes

Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de ModeladoUn diagrama de componentes representa coacutemo un sistema de software es dividido en componentes y muestra las

dependencias entre estos componentes Los componentes fiacutesicosincluyen archivos cabeceras bibliotecas compartidas moacutedulos ejecutables o paquetes Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistemaDebido a que los diagramas de componentes son maacutes parecidos alos diagramas de casos de usos eacutestos son utilizados para modelar la vista estaacutetica y dinaacutemica de un sistema Muestra la organizacioacuten y las dependencias entre un conjunto de componentes No es necesario que un diagrama incluya todos los componentes del sistema normalmente se realizan por partes Cada diagrama describe un apartado del sistemaEn eacutel se situaraacuten libreriacuteas tablas archivos ejecutables y documentos que formen parte del sistemaUno de los usos principales es que puede servir para ver queacute componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema

Diagramas de despliegue

El Diagrama de Despliegue es un tipo de diagrama del LenguajeUnificado de Modelado que se utiliza para modelar la disposicioacuten fiacutesica de los artefactos software en nodos (usualmente plataforma de hardware)Aspectos GeneralesLa mayoriacutea de las veces el modelado de la vista de despliegueimplica modelar la topologiacutea del hardware sobre el que se ejecuta el sistema Aunque UML no es un lenguaje de especificacioacuten hardware de propoacutesito general se ha disentildeado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el softwaredel sistemaUsosAlgunos de los usos que se les da a los diagramas de despliegue son para modelarSistemas empotrados Un sistema empotrado es una coleccioacuten dehardware con una gran cantidad de software que interactuacutea conel mundo fiacutesicoSistemas cliente-servidor Los sistemas cliente-servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribucioacuten fiacutesica de los componentes software del sistema a traveacutes de nodosSistemas completamente distribuidos En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores Tales sistemas contienen a menudo varias versiones de componentes software alguno de los cuales pueden incluso migrar de un nodo a otro El disentildeo de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topologiacutea del sistema

Arquitectura

Arquitectura de software El disentildeo arquitectoacutenico es el proceso a traveacutes del cual se

identifican los subsistemas que componen un sistema de informacioacuten asiacute como los mecanismos de control y comunicacioacuten usados por los mismos

El resultado de este proceso es una descripcioacuten de la arquitectura del software

Disentildeo arquitectoacutenico

Etapa temprana en el proceso de desarrollo de un sistemade informacioacuten

Es el enlace entre la especificacioacuten del sistema y el desarrollo del mismo

Implica identificar los principales componentes del sistema y su mecanismo de comunicacioacuten

Ventajas

Comunicacioacuten entre los interesados Reutilizacioacuten a gran escala Anaacutelisis del sistema (requerimientos no funcionales)

Estructura del sistema

Descompone el sistema en subsistemas que interactuacutean entre si

Se expresa como un diagrama de bloques presentando una visioacuten general del sistema

En caso de que sea necesario se puede aumentar el detalle de alguacuten subsistema importante

Subsistemas

Decisiones arquitectoacutenicas Existe alguacuten ejemplo de arquitectura geneacuterica que pueda

aplicarse Como se distribuiraacute el sistema Alguacuten estilo de arquitectura es aplicable Como se descompondraacute el sistema en moacutedulos Como se controlaran y comunicaran esos moacutedulos

Estilos arquitectoacutenicos

El modelo arquitectoacutenico de un sistema puede basarse en un estilo o modelo geneacuterico de arquitectura

Conocer estos modelos de antemano puede facilitar la tarea de definir la arquitectura de un sistema

Los grandes sistemas son heterogeacuteneos no siguiendo un claro estilo arquitectoacutenico uacutenico

Modelos arquitectoacutenicos Usados para documentar la arquitectura de un sistema Modelos estaacuteticos estructurales Modelos dinaacutemicos de procesos Modelos de interfaces Modelos de datos Modelos de deployment

Coacutedigo

El coacutedigo fuente de un programa informaacutetico (o software) es un conjunto de liacuteneas de texto que son las instrucciones que debe seguir la computadora para ejecutar dicho programa Por tanto en el coacutedigo fuente de un programa estaacute escrito por completo su funcionamientoEl coacutedigo fuente de un programa que estaacute escrito por un programador en alguacuten lenguaje de programacioacuten pero en este primer estado no es directamente ejecutable por la computadora sino que debe ser traducido a otro lenguaje (el lenguaje maacutequina o coacutedigo objeto) que siacute pueda ser ejecutado por el hardware de la computadora Para esta traduccioacuten se usan los llamados compiladores ensambladores inteacuterpretes y otros sistemas de traduccioacutenEl teacutermino coacutedigo fuente tambieacuten se usa para hacer referenciaal coacutedigo fuente de otros elementos del software como por ejemplo el coacutedigo fuente de una paacutegina web que estaacute escrito en el lenguaje de marcado HTML o en Javascript u otros lenguajes de programacioacuten web y que es posteriormente ejecutado por el navegador web para visualizar dicha paacutegina cuando es visitadaEl aacuterea de la informaacutetica que se dedica a la creacioacuten de

programas y por tanto a la creacioacuten de su coacutedigo fuente es la programacioacuten

Conviene asegurar que no es ambiguo ni siquiera si se interpretase mal a propoacutesito

Esbozar una prueba especiacutefica que estableceriacutea la satisfaccioacuten

La definicioacuten de pruebas ayuda a clarificar el sentido de cada requisito

Condiciones de error Para estar completa la especificacioacuten del requisito

debe tener en cuenta las condiciones de error es decirqueacute ocurre con el requisito en una situacioacuten con errores

Las condiciones de error son especialmente importantes para realizar las pruebas ya que al probar un requisitose fuerzan condiciones de error y es necesario prever queacute debe ocurrir en estos casos Caso tiacutepico datos de entrada incorrectos

o Ejemplo clasificar un triaacutengulo a partir de las coordenadas de sus tres veacutertices 1113088 No confiar en que no se produciraacuten condiciones de error esto aumenta la dependencia entre moacutedulos (un moacutedulo confiacutea en la deteccioacuten de errores deotro moacutedulo) o Pero recordar que no se debe abusar del manejode errores internos

Redundancia para promover la seguridad Determinar lo que hay que hacer en situaciones no

previstas (prever lo imprevisto) Prevenir posibles errores de programacioacuten en lugares

criacuteticos

Trazabilidad de requisitos funcionales Es la correspondencia entre cada requisito del software

yo uno o maacutes requisitos del usuario u otras fuentes (trazabilidad hacia atraacutes)o una o varias partes del disentildeo o la implementacioacuten (trazabilidad hacia adelante)

La relacioacuten RU-RS es tiacutepicamente uno-a-pocos Todo RU debe ser desarrollado por al menos un RS pero puede haber un RS cuya fuente no sea un RU (PSS-05-03 3 y 47)

o No confundir con el caso de nuevos RU que se descubren durante el desarrollo de los RS y que deberaacuten ser validados por el usuario nueva versioacuten URD o Verdadero RS sin RU todo RS debe tener una buena razoacuten para existir con mayor razoacuten si no existe un RU correspondiente el cliente no querraacute pagar por cosas que no ha encargado

Es necesaria para poder comprobar que la aplicacioacuten satisface los requisitos

Una forma de conseguirla es relacionar cada requisito funcional con una funcioacuten

especiacutefica en el lenguaje destino o Esta teacutecnica es poco generalizable y limitada produce excesivo acoplamiento entre la estructura de los requisitos y la estructura de la implementacioacuten o En OO no es trivial preguntarse queacute clase esresponsable de queacute funcioacuten

Funcioacuten con un solo paraacutemetro F(x) xF( ) Funcioacuten con dos o maacutes paraacutemetros G(x y) xG(y)

yG(x) La transicioacuten Anaacutelisis-Disentildeo no es sencilla ni tiene

por queacute serlo Es muy necesaria para afrontar que los requisitos

cambian y gestionar su evolucioacuten o Si la gestioacuten de la trazabilidad es difiacutecil y lleva demasiado trabajo los desarrolladores tenderaacuten a evitar la actualizacioacuten del documento de requisitos e iraacuten directamentea hacer cambios al coacutedigo en consecuencia el documento de requisitos se hace inuacutetil para las pruebas y la validacioacuten o Si ademaacutes el documento no es fiable por culpa de algunos miembros del equipo menos responsables entonces ni siquiera los maacutes responsables se tomaraacuten la molestia de mantenerlo al diacutea o Por tanto el sistema para hacer corresponder requisitos con disentildeo y coacutedigo debe ser claro y concreto o Ejemplo matrices de trazabilidad de requisitos 1113088 hacia atraacutes hacia delante 1113088 distintas de la tabla de referencias cruzadas entre requisitos para gestionar la consistencia

1113088 Un requisito puede corresponderse con varias partes del coacutedigo (funciones) que a su vez pueden implementar varios requisitos cada una o Por tanto antes de cambiar el coacutedigo para adaptarse a un cambio en un requisito hay que comprobar que otros requisitos no quedan comprometidos o La correspondencia Requisito-Funcioacuten es muchos-a-muchos sino puede ser uno-uno al menos puede intentarse que sea pocos-pocos o El disentildeo juega un papel fundamental en establecer esta correspondencia

Trazabilidad de requisitos no funcionales La correspondencia con elementos del disentildeo y de la

implementacioacuten es mucho maacutes difiacutecil ya que depende en mayor medida de la colaboracioacuten entre varios elementos

La validacioacuten de estos requisitos es maacutes complicada normalmente requiere un mayor nivel de integracioacuten del sistema (no es faacutecil validar NFRS en componentes aislados)

Ejemplo rendimiento o Identificar los elementos que consumen maacutes tiempo o memoriao La mayor parte de los recursos son consumidos por un nuacutemeroreducido de elementos de modo que esta tarea es provechosa para mejorar el rendimiento o Bucles graacuteficos y comunicaciones suelen ser los que maacutes tiempo consumen

ATRIBUTOS Necesidad y prioridad

Para negociar entre funcionalidad planificacioacuten presupuesto y nivel de calidad es conveniente que los requisitos funcionales tengan asignado un nivel de necesidad (tres o cuatro categoriacuteas esencial deseableopcional) asiacute como un nivel de prioridad temporal (dos o tres categoriacuteas alta baja)

La necesidad de un requisito hace referencia al intereacutes de los usuariosclientes en que la aplicacioacuten lo

realice y hasta queacute punto estariacutean dispuestos a pasarsesi eacutel

La prioridad de un requisito hace referencia al orden temporal indica en queacute fase de construccioacuten del sistemase incluiraacute la funcionalidad que realice el requisito

Si el 20 de la aplicacioacuten proporciona el 80 de su valor no maacutes del 20 de los requisitos deberiacutean ser ldquoesencialesrdquo

Riesgo Cada requisito deberiacutea ir acompantildeado de una estimacioacuten

del riesgo que supone realizarlo (relacionado con la dificultad de implementarlo) Ej alto moderado bajo

Seguir la pista con especial atencioacuten a los de mayor riesgo

Para escribir un requisito resumen Enunciado breve del mismo numerado Explicacioacuten detallada Atributos y propiedades tal como se han discutido hasta

aquiacute por ejemplo o Necesidad Prioridad y Riesgoo Condiciones de erroro Pruebas de validacioacuten y verificacioacuten requeridas

Tabla de composicioacuten de requisitos funcionales-no funcionales

Tabla de referencias cruzadas entre requisitos conflicto acoplamiento redundancia

Matrices de trazabilidad hacia requisitos de usuario y hacia disentildeoimplementacioacuten

Usar un formato que permita distintos niveles de visibilidad

o soacutelo enunciadoo soacutelo enunciado y descripcioacuteno enunciado descripcioacuten y propiedades

DiagramaDiagramas de secuencias

El diagrama de secuencia es un tipo de diagrama usado para modelarinteraccioacuten entre objetos en un sistema seguacuten UML

Un diagrama de secuencia muestra la interaccioacuten de un conjunto de objetos en una aplicacioacuten a traveacutes del tiempo y se modela para cada caso de uso Mientras que el diagrama de casos de uso permiteel modelado de una vista business del escenario el diagrama de secuencia contiene detalles de implementacioacuten del escenario incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos

Diagrama de secuencias del disentildeo

La fase de disentildeo (y los modelos UML resultantes) expande y detalla los modelos de anaacutelisis tomando en cuenta todas las implicaciones y restricciones teacutecnicas El propoacutesito del disentildeo es especificar una solucioacuten que trabaje y pueda ser faacutecilmente convertida en coacutedigo fuente y construir una arquitectura simple y faacutecilmente extensible Las clases definidas en el anaacutelisis fueron detalladas y se antildeadieron nuevas clases para manejar aacutereas teacutecnicas como base de datosinterfaz del usuario comunicacioacuten dispositivos etc

Diagrama de secuencia

Los casos de uso deben ser realizados durante esta etapa Para describir el comportamiento dinaacutemico del sistema cualquiera de los diagramas de interaccioacuten del UML pueden ser

utilizados Debido a que Rational Rose no soporta los diagramas de actividad y ofrece soporte limitado para los diagramas de colaboracioacuten (en notacioacuten completa del UML) usaremos diagramas de secuencia

Diagramas de componentes

Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de ModeladoUn diagrama de componentes representa coacutemo un sistema de software es dividido en componentes y muestra las

dependencias entre estos componentes Los componentes fiacutesicosincluyen archivos cabeceras bibliotecas compartidas moacutedulos ejecutables o paquetes Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistemaDebido a que los diagramas de componentes son maacutes parecidos alos diagramas de casos de usos eacutestos son utilizados para modelar la vista estaacutetica y dinaacutemica de un sistema Muestra la organizacioacuten y las dependencias entre un conjunto de componentes No es necesario que un diagrama incluya todos los componentes del sistema normalmente se realizan por partes Cada diagrama describe un apartado del sistemaEn eacutel se situaraacuten libreriacuteas tablas archivos ejecutables y documentos que formen parte del sistemaUno de los usos principales es que puede servir para ver queacute componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema

Diagramas de despliegue

El Diagrama de Despliegue es un tipo de diagrama del LenguajeUnificado de Modelado que se utiliza para modelar la disposicioacuten fiacutesica de los artefactos software en nodos (usualmente plataforma de hardware)Aspectos GeneralesLa mayoriacutea de las veces el modelado de la vista de despliegueimplica modelar la topologiacutea del hardware sobre el que se ejecuta el sistema Aunque UML no es un lenguaje de especificacioacuten hardware de propoacutesito general se ha disentildeado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el softwaredel sistemaUsosAlgunos de los usos que se les da a los diagramas de despliegue son para modelarSistemas empotrados Un sistema empotrado es una coleccioacuten dehardware con una gran cantidad de software que interactuacutea conel mundo fiacutesicoSistemas cliente-servidor Los sistemas cliente-servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribucioacuten fiacutesica de los componentes software del sistema a traveacutes de nodosSistemas completamente distribuidos En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores Tales sistemas contienen a menudo varias versiones de componentes software alguno de los cuales pueden incluso migrar de un nodo a otro El disentildeo de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topologiacutea del sistema

Arquitectura

Arquitectura de software El disentildeo arquitectoacutenico es el proceso a traveacutes del cual se

identifican los subsistemas que componen un sistema de informacioacuten asiacute como los mecanismos de control y comunicacioacuten usados por los mismos

El resultado de este proceso es una descripcioacuten de la arquitectura del software

Disentildeo arquitectoacutenico

Etapa temprana en el proceso de desarrollo de un sistemade informacioacuten

Es el enlace entre la especificacioacuten del sistema y el desarrollo del mismo

Implica identificar los principales componentes del sistema y su mecanismo de comunicacioacuten

Ventajas

Comunicacioacuten entre los interesados Reutilizacioacuten a gran escala Anaacutelisis del sistema (requerimientos no funcionales)

Estructura del sistema

Descompone el sistema en subsistemas que interactuacutean entre si

Se expresa como un diagrama de bloques presentando una visioacuten general del sistema

En caso de que sea necesario se puede aumentar el detalle de alguacuten subsistema importante

Subsistemas

Decisiones arquitectoacutenicas Existe alguacuten ejemplo de arquitectura geneacuterica que pueda

aplicarse Como se distribuiraacute el sistema Alguacuten estilo de arquitectura es aplicable Como se descompondraacute el sistema en moacutedulos Como se controlaran y comunicaran esos moacutedulos

Estilos arquitectoacutenicos

El modelo arquitectoacutenico de un sistema puede basarse en un estilo o modelo geneacuterico de arquitectura

Conocer estos modelos de antemano puede facilitar la tarea de definir la arquitectura de un sistema

Los grandes sistemas son heterogeacuteneos no siguiendo un claro estilo arquitectoacutenico uacutenico

Modelos arquitectoacutenicos Usados para documentar la arquitectura de un sistema Modelos estaacuteticos estructurales Modelos dinaacutemicos de procesos Modelos de interfaces Modelos de datos Modelos de deployment

Coacutedigo

El coacutedigo fuente de un programa informaacutetico (o software) es un conjunto de liacuteneas de texto que son las instrucciones que debe seguir la computadora para ejecutar dicho programa Por tanto en el coacutedigo fuente de un programa estaacute escrito por completo su funcionamientoEl coacutedigo fuente de un programa que estaacute escrito por un programador en alguacuten lenguaje de programacioacuten pero en este primer estado no es directamente ejecutable por la computadora sino que debe ser traducido a otro lenguaje (el lenguaje maacutequina o coacutedigo objeto) que siacute pueda ser ejecutado por el hardware de la computadora Para esta traduccioacuten se usan los llamados compiladores ensambladores inteacuterpretes y otros sistemas de traduccioacutenEl teacutermino coacutedigo fuente tambieacuten se usa para hacer referenciaal coacutedigo fuente de otros elementos del software como por ejemplo el coacutedigo fuente de una paacutegina web que estaacute escrito en el lenguaje de marcado HTML o en Javascript u otros lenguajes de programacioacuten web y que es posteriormente ejecutado por el navegador web para visualizar dicha paacutegina cuando es visitadaEl aacuterea de la informaacutetica que se dedica a la creacioacuten de

programas y por tanto a la creacioacuten de su coacutedigo fuente es la programacioacuten

o No confundir con el caso de nuevos RU que se descubren durante el desarrollo de los RS y que deberaacuten ser validados por el usuario nueva versioacuten URD o Verdadero RS sin RU todo RS debe tener una buena razoacuten para existir con mayor razoacuten si no existe un RU correspondiente el cliente no querraacute pagar por cosas que no ha encargado

Es necesaria para poder comprobar que la aplicacioacuten satisface los requisitos

Una forma de conseguirla es relacionar cada requisito funcional con una funcioacuten

especiacutefica en el lenguaje destino o Esta teacutecnica es poco generalizable y limitada produce excesivo acoplamiento entre la estructura de los requisitos y la estructura de la implementacioacuten o En OO no es trivial preguntarse queacute clase esresponsable de queacute funcioacuten

Funcioacuten con un solo paraacutemetro F(x) xF( ) Funcioacuten con dos o maacutes paraacutemetros G(x y) xG(y)

yG(x) La transicioacuten Anaacutelisis-Disentildeo no es sencilla ni tiene

por queacute serlo Es muy necesaria para afrontar que los requisitos

cambian y gestionar su evolucioacuten o Si la gestioacuten de la trazabilidad es difiacutecil y lleva demasiado trabajo los desarrolladores tenderaacuten a evitar la actualizacioacuten del documento de requisitos e iraacuten directamentea hacer cambios al coacutedigo en consecuencia el documento de requisitos se hace inuacutetil para las pruebas y la validacioacuten o Si ademaacutes el documento no es fiable por culpa de algunos miembros del equipo menos responsables entonces ni siquiera los maacutes responsables se tomaraacuten la molestia de mantenerlo al diacutea o Por tanto el sistema para hacer corresponder requisitos con disentildeo y coacutedigo debe ser claro y concreto o Ejemplo matrices de trazabilidad de requisitos 1113088 hacia atraacutes hacia delante 1113088 distintas de la tabla de referencias cruzadas entre requisitos para gestionar la consistencia

1113088 Un requisito puede corresponderse con varias partes del coacutedigo (funciones) que a su vez pueden implementar varios requisitos cada una o Por tanto antes de cambiar el coacutedigo para adaptarse a un cambio en un requisito hay que comprobar que otros requisitos no quedan comprometidos o La correspondencia Requisito-Funcioacuten es muchos-a-muchos sino puede ser uno-uno al menos puede intentarse que sea pocos-pocos o El disentildeo juega un papel fundamental en establecer esta correspondencia

Trazabilidad de requisitos no funcionales La correspondencia con elementos del disentildeo y de la

implementacioacuten es mucho maacutes difiacutecil ya que depende en mayor medida de la colaboracioacuten entre varios elementos

La validacioacuten de estos requisitos es maacutes complicada normalmente requiere un mayor nivel de integracioacuten del sistema (no es faacutecil validar NFRS en componentes aislados)

Ejemplo rendimiento o Identificar los elementos que consumen maacutes tiempo o memoriao La mayor parte de los recursos son consumidos por un nuacutemeroreducido de elementos de modo que esta tarea es provechosa para mejorar el rendimiento o Bucles graacuteficos y comunicaciones suelen ser los que maacutes tiempo consumen

ATRIBUTOS Necesidad y prioridad

Para negociar entre funcionalidad planificacioacuten presupuesto y nivel de calidad es conveniente que los requisitos funcionales tengan asignado un nivel de necesidad (tres o cuatro categoriacuteas esencial deseableopcional) asiacute como un nivel de prioridad temporal (dos o tres categoriacuteas alta baja)

La necesidad de un requisito hace referencia al intereacutes de los usuariosclientes en que la aplicacioacuten lo

realice y hasta queacute punto estariacutean dispuestos a pasarsesi eacutel

La prioridad de un requisito hace referencia al orden temporal indica en queacute fase de construccioacuten del sistemase incluiraacute la funcionalidad que realice el requisito

Si el 20 de la aplicacioacuten proporciona el 80 de su valor no maacutes del 20 de los requisitos deberiacutean ser ldquoesencialesrdquo

Riesgo Cada requisito deberiacutea ir acompantildeado de una estimacioacuten

del riesgo que supone realizarlo (relacionado con la dificultad de implementarlo) Ej alto moderado bajo

Seguir la pista con especial atencioacuten a los de mayor riesgo

Para escribir un requisito resumen Enunciado breve del mismo numerado Explicacioacuten detallada Atributos y propiedades tal como se han discutido hasta

aquiacute por ejemplo o Necesidad Prioridad y Riesgoo Condiciones de erroro Pruebas de validacioacuten y verificacioacuten requeridas

Tabla de composicioacuten de requisitos funcionales-no funcionales

Tabla de referencias cruzadas entre requisitos conflicto acoplamiento redundancia

Matrices de trazabilidad hacia requisitos de usuario y hacia disentildeoimplementacioacuten

Usar un formato que permita distintos niveles de visibilidad

o soacutelo enunciadoo soacutelo enunciado y descripcioacuteno enunciado descripcioacuten y propiedades

DiagramaDiagramas de secuencias

El diagrama de secuencia es un tipo de diagrama usado para modelarinteraccioacuten entre objetos en un sistema seguacuten UML

Un diagrama de secuencia muestra la interaccioacuten de un conjunto de objetos en una aplicacioacuten a traveacutes del tiempo y se modela para cada caso de uso Mientras que el diagrama de casos de uso permiteel modelado de una vista business del escenario el diagrama de secuencia contiene detalles de implementacioacuten del escenario incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos

Diagrama de secuencias del disentildeo

La fase de disentildeo (y los modelos UML resultantes) expande y detalla los modelos de anaacutelisis tomando en cuenta todas las implicaciones y restricciones teacutecnicas El propoacutesito del disentildeo es especificar una solucioacuten que trabaje y pueda ser faacutecilmente convertida en coacutedigo fuente y construir una arquitectura simple y faacutecilmente extensible Las clases definidas en el anaacutelisis fueron detalladas y se antildeadieron nuevas clases para manejar aacutereas teacutecnicas como base de datosinterfaz del usuario comunicacioacuten dispositivos etc

Diagrama de secuencia

Los casos de uso deben ser realizados durante esta etapa Para describir el comportamiento dinaacutemico del sistema cualquiera de los diagramas de interaccioacuten del UML pueden ser

utilizados Debido a que Rational Rose no soporta los diagramas de actividad y ofrece soporte limitado para los diagramas de colaboracioacuten (en notacioacuten completa del UML) usaremos diagramas de secuencia

Diagramas de componentes

Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de ModeladoUn diagrama de componentes representa coacutemo un sistema de software es dividido en componentes y muestra las

dependencias entre estos componentes Los componentes fiacutesicosincluyen archivos cabeceras bibliotecas compartidas moacutedulos ejecutables o paquetes Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistemaDebido a que los diagramas de componentes son maacutes parecidos alos diagramas de casos de usos eacutestos son utilizados para modelar la vista estaacutetica y dinaacutemica de un sistema Muestra la organizacioacuten y las dependencias entre un conjunto de componentes No es necesario que un diagrama incluya todos los componentes del sistema normalmente se realizan por partes Cada diagrama describe un apartado del sistemaEn eacutel se situaraacuten libreriacuteas tablas archivos ejecutables y documentos que formen parte del sistemaUno de los usos principales es que puede servir para ver queacute componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema

Diagramas de despliegue

El Diagrama de Despliegue es un tipo de diagrama del LenguajeUnificado de Modelado que se utiliza para modelar la disposicioacuten fiacutesica de los artefactos software en nodos (usualmente plataforma de hardware)Aspectos GeneralesLa mayoriacutea de las veces el modelado de la vista de despliegueimplica modelar la topologiacutea del hardware sobre el que se ejecuta el sistema Aunque UML no es un lenguaje de especificacioacuten hardware de propoacutesito general se ha disentildeado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el softwaredel sistemaUsosAlgunos de los usos que se les da a los diagramas de despliegue son para modelarSistemas empotrados Un sistema empotrado es una coleccioacuten dehardware con una gran cantidad de software que interactuacutea conel mundo fiacutesicoSistemas cliente-servidor Los sistemas cliente-servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribucioacuten fiacutesica de los componentes software del sistema a traveacutes de nodosSistemas completamente distribuidos En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores Tales sistemas contienen a menudo varias versiones de componentes software alguno de los cuales pueden incluso migrar de un nodo a otro El disentildeo de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topologiacutea del sistema

Arquitectura

Arquitectura de software El disentildeo arquitectoacutenico es el proceso a traveacutes del cual se

identifican los subsistemas que componen un sistema de informacioacuten asiacute como los mecanismos de control y comunicacioacuten usados por los mismos

El resultado de este proceso es una descripcioacuten de la arquitectura del software

Disentildeo arquitectoacutenico

Etapa temprana en el proceso de desarrollo de un sistemade informacioacuten

Es el enlace entre la especificacioacuten del sistema y el desarrollo del mismo

Implica identificar los principales componentes del sistema y su mecanismo de comunicacioacuten

Ventajas

Comunicacioacuten entre los interesados Reutilizacioacuten a gran escala Anaacutelisis del sistema (requerimientos no funcionales)

Estructura del sistema

Descompone el sistema en subsistemas que interactuacutean entre si

Se expresa como un diagrama de bloques presentando una visioacuten general del sistema

En caso de que sea necesario se puede aumentar el detalle de alguacuten subsistema importante

Subsistemas

Decisiones arquitectoacutenicas Existe alguacuten ejemplo de arquitectura geneacuterica que pueda

aplicarse Como se distribuiraacute el sistema Alguacuten estilo de arquitectura es aplicable Como se descompondraacute el sistema en moacutedulos Como se controlaran y comunicaran esos moacutedulos

Estilos arquitectoacutenicos

El modelo arquitectoacutenico de un sistema puede basarse en un estilo o modelo geneacuterico de arquitectura

Conocer estos modelos de antemano puede facilitar la tarea de definir la arquitectura de un sistema

Los grandes sistemas son heterogeacuteneos no siguiendo un claro estilo arquitectoacutenico uacutenico

Modelos arquitectoacutenicos Usados para documentar la arquitectura de un sistema Modelos estaacuteticos estructurales Modelos dinaacutemicos de procesos Modelos de interfaces Modelos de datos Modelos de deployment

Coacutedigo

El coacutedigo fuente de un programa informaacutetico (o software) es un conjunto de liacuteneas de texto que son las instrucciones que debe seguir la computadora para ejecutar dicho programa Por tanto en el coacutedigo fuente de un programa estaacute escrito por completo su funcionamientoEl coacutedigo fuente de un programa que estaacute escrito por un programador en alguacuten lenguaje de programacioacuten pero en este primer estado no es directamente ejecutable por la computadora sino que debe ser traducido a otro lenguaje (el lenguaje maacutequina o coacutedigo objeto) que siacute pueda ser ejecutado por el hardware de la computadora Para esta traduccioacuten se usan los llamados compiladores ensambladores inteacuterpretes y otros sistemas de traduccioacutenEl teacutermino coacutedigo fuente tambieacuten se usa para hacer referenciaal coacutedigo fuente de otros elementos del software como por ejemplo el coacutedigo fuente de una paacutegina web que estaacute escrito en el lenguaje de marcado HTML o en Javascript u otros lenguajes de programacioacuten web y que es posteriormente ejecutado por el navegador web para visualizar dicha paacutegina cuando es visitadaEl aacuterea de la informaacutetica que se dedica a la creacioacuten de

programas y por tanto a la creacioacuten de su coacutedigo fuente es la programacioacuten

1113088 Un requisito puede corresponderse con varias partes del coacutedigo (funciones) que a su vez pueden implementar varios requisitos cada una o Por tanto antes de cambiar el coacutedigo para adaptarse a un cambio en un requisito hay que comprobar que otros requisitos no quedan comprometidos o La correspondencia Requisito-Funcioacuten es muchos-a-muchos sino puede ser uno-uno al menos puede intentarse que sea pocos-pocos o El disentildeo juega un papel fundamental en establecer esta correspondencia

Trazabilidad de requisitos no funcionales La correspondencia con elementos del disentildeo y de la

implementacioacuten es mucho maacutes difiacutecil ya que depende en mayor medida de la colaboracioacuten entre varios elementos

La validacioacuten de estos requisitos es maacutes complicada normalmente requiere un mayor nivel de integracioacuten del sistema (no es faacutecil validar NFRS en componentes aislados)

Ejemplo rendimiento o Identificar los elementos que consumen maacutes tiempo o memoriao La mayor parte de los recursos son consumidos por un nuacutemeroreducido de elementos de modo que esta tarea es provechosa para mejorar el rendimiento o Bucles graacuteficos y comunicaciones suelen ser los que maacutes tiempo consumen

ATRIBUTOS Necesidad y prioridad

Para negociar entre funcionalidad planificacioacuten presupuesto y nivel de calidad es conveniente que los requisitos funcionales tengan asignado un nivel de necesidad (tres o cuatro categoriacuteas esencial deseableopcional) asiacute como un nivel de prioridad temporal (dos o tres categoriacuteas alta baja)

La necesidad de un requisito hace referencia al intereacutes de los usuariosclientes en que la aplicacioacuten lo

realice y hasta queacute punto estariacutean dispuestos a pasarsesi eacutel

La prioridad de un requisito hace referencia al orden temporal indica en queacute fase de construccioacuten del sistemase incluiraacute la funcionalidad que realice el requisito

Si el 20 de la aplicacioacuten proporciona el 80 de su valor no maacutes del 20 de los requisitos deberiacutean ser ldquoesencialesrdquo

Riesgo Cada requisito deberiacutea ir acompantildeado de una estimacioacuten

del riesgo que supone realizarlo (relacionado con la dificultad de implementarlo) Ej alto moderado bajo

Seguir la pista con especial atencioacuten a los de mayor riesgo

Para escribir un requisito resumen Enunciado breve del mismo numerado Explicacioacuten detallada Atributos y propiedades tal como se han discutido hasta

aquiacute por ejemplo o Necesidad Prioridad y Riesgoo Condiciones de erroro Pruebas de validacioacuten y verificacioacuten requeridas

Tabla de composicioacuten de requisitos funcionales-no funcionales

Tabla de referencias cruzadas entre requisitos conflicto acoplamiento redundancia

Matrices de trazabilidad hacia requisitos de usuario y hacia disentildeoimplementacioacuten

Usar un formato que permita distintos niveles de visibilidad

o soacutelo enunciadoo soacutelo enunciado y descripcioacuteno enunciado descripcioacuten y propiedades

DiagramaDiagramas de secuencias

El diagrama de secuencia es un tipo de diagrama usado para modelarinteraccioacuten entre objetos en un sistema seguacuten UML

Un diagrama de secuencia muestra la interaccioacuten de un conjunto de objetos en una aplicacioacuten a traveacutes del tiempo y se modela para cada caso de uso Mientras que el diagrama de casos de uso permiteel modelado de una vista business del escenario el diagrama de secuencia contiene detalles de implementacioacuten del escenario incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos

Diagrama de secuencias del disentildeo

La fase de disentildeo (y los modelos UML resultantes) expande y detalla los modelos de anaacutelisis tomando en cuenta todas las implicaciones y restricciones teacutecnicas El propoacutesito del disentildeo es especificar una solucioacuten que trabaje y pueda ser faacutecilmente convertida en coacutedigo fuente y construir una arquitectura simple y faacutecilmente extensible Las clases definidas en el anaacutelisis fueron detalladas y se antildeadieron nuevas clases para manejar aacutereas teacutecnicas como base de datosinterfaz del usuario comunicacioacuten dispositivos etc

Diagrama de secuencia

Los casos de uso deben ser realizados durante esta etapa Para describir el comportamiento dinaacutemico del sistema cualquiera de los diagramas de interaccioacuten del UML pueden ser

utilizados Debido a que Rational Rose no soporta los diagramas de actividad y ofrece soporte limitado para los diagramas de colaboracioacuten (en notacioacuten completa del UML) usaremos diagramas de secuencia

Diagramas de componentes

Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de ModeladoUn diagrama de componentes representa coacutemo un sistema de software es dividido en componentes y muestra las

dependencias entre estos componentes Los componentes fiacutesicosincluyen archivos cabeceras bibliotecas compartidas moacutedulos ejecutables o paquetes Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistemaDebido a que los diagramas de componentes son maacutes parecidos alos diagramas de casos de usos eacutestos son utilizados para modelar la vista estaacutetica y dinaacutemica de un sistema Muestra la organizacioacuten y las dependencias entre un conjunto de componentes No es necesario que un diagrama incluya todos los componentes del sistema normalmente se realizan por partes Cada diagrama describe un apartado del sistemaEn eacutel se situaraacuten libreriacuteas tablas archivos ejecutables y documentos que formen parte del sistemaUno de los usos principales es que puede servir para ver queacute componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema

Diagramas de despliegue

El Diagrama de Despliegue es un tipo de diagrama del LenguajeUnificado de Modelado que se utiliza para modelar la disposicioacuten fiacutesica de los artefactos software en nodos (usualmente plataforma de hardware)Aspectos GeneralesLa mayoriacutea de las veces el modelado de la vista de despliegueimplica modelar la topologiacutea del hardware sobre el que se ejecuta el sistema Aunque UML no es un lenguaje de especificacioacuten hardware de propoacutesito general se ha disentildeado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el softwaredel sistemaUsosAlgunos de los usos que se les da a los diagramas de despliegue son para modelarSistemas empotrados Un sistema empotrado es una coleccioacuten dehardware con una gran cantidad de software que interactuacutea conel mundo fiacutesicoSistemas cliente-servidor Los sistemas cliente-servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribucioacuten fiacutesica de los componentes software del sistema a traveacutes de nodosSistemas completamente distribuidos En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores Tales sistemas contienen a menudo varias versiones de componentes software alguno de los cuales pueden incluso migrar de un nodo a otro El disentildeo de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topologiacutea del sistema

Arquitectura

Arquitectura de software El disentildeo arquitectoacutenico es el proceso a traveacutes del cual se

identifican los subsistemas que componen un sistema de informacioacuten asiacute como los mecanismos de control y comunicacioacuten usados por los mismos

El resultado de este proceso es una descripcioacuten de la arquitectura del software

Disentildeo arquitectoacutenico

Etapa temprana en el proceso de desarrollo de un sistemade informacioacuten

Es el enlace entre la especificacioacuten del sistema y el desarrollo del mismo

Implica identificar los principales componentes del sistema y su mecanismo de comunicacioacuten

Ventajas

Comunicacioacuten entre los interesados Reutilizacioacuten a gran escala Anaacutelisis del sistema (requerimientos no funcionales)

Estructura del sistema

Descompone el sistema en subsistemas que interactuacutean entre si

Se expresa como un diagrama de bloques presentando una visioacuten general del sistema

En caso de que sea necesario se puede aumentar el detalle de alguacuten subsistema importante

Subsistemas

Decisiones arquitectoacutenicas Existe alguacuten ejemplo de arquitectura geneacuterica que pueda

aplicarse Como se distribuiraacute el sistema Alguacuten estilo de arquitectura es aplicable Como se descompondraacute el sistema en moacutedulos Como se controlaran y comunicaran esos moacutedulos

Estilos arquitectoacutenicos

El modelo arquitectoacutenico de un sistema puede basarse en un estilo o modelo geneacuterico de arquitectura

Conocer estos modelos de antemano puede facilitar la tarea de definir la arquitectura de un sistema

Los grandes sistemas son heterogeacuteneos no siguiendo un claro estilo arquitectoacutenico uacutenico

Modelos arquitectoacutenicos Usados para documentar la arquitectura de un sistema Modelos estaacuteticos estructurales Modelos dinaacutemicos de procesos Modelos de interfaces Modelos de datos Modelos de deployment

Coacutedigo

El coacutedigo fuente de un programa informaacutetico (o software) es un conjunto de liacuteneas de texto que son las instrucciones que debe seguir la computadora para ejecutar dicho programa Por tanto en el coacutedigo fuente de un programa estaacute escrito por completo su funcionamientoEl coacutedigo fuente de un programa que estaacute escrito por un programador en alguacuten lenguaje de programacioacuten pero en este primer estado no es directamente ejecutable por la computadora sino que debe ser traducido a otro lenguaje (el lenguaje maacutequina o coacutedigo objeto) que siacute pueda ser ejecutado por el hardware de la computadora Para esta traduccioacuten se usan los llamados compiladores ensambladores inteacuterpretes y otros sistemas de traduccioacutenEl teacutermino coacutedigo fuente tambieacuten se usa para hacer referenciaal coacutedigo fuente de otros elementos del software como por ejemplo el coacutedigo fuente de una paacutegina web que estaacute escrito en el lenguaje de marcado HTML o en Javascript u otros lenguajes de programacioacuten web y que es posteriormente ejecutado por el navegador web para visualizar dicha paacutegina cuando es visitadaEl aacuterea de la informaacutetica que se dedica a la creacioacuten de

programas y por tanto a la creacioacuten de su coacutedigo fuente es la programacioacuten

realice y hasta queacute punto estariacutean dispuestos a pasarsesi eacutel

La prioridad de un requisito hace referencia al orden temporal indica en queacute fase de construccioacuten del sistemase incluiraacute la funcionalidad que realice el requisito

Si el 20 de la aplicacioacuten proporciona el 80 de su valor no maacutes del 20 de los requisitos deberiacutean ser ldquoesencialesrdquo

Riesgo Cada requisito deberiacutea ir acompantildeado de una estimacioacuten

del riesgo que supone realizarlo (relacionado con la dificultad de implementarlo) Ej alto moderado bajo

Seguir la pista con especial atencioacuten a los de mayor riesgo

Para escribir un requisito resumen Enunciado breve del mismo numerado Explicacioacuten detallada Atributos y propiedades tal como se han discutido hasta

aquiacute por ejemplo o Necesidad Prioridad y Riesgoo Condiciones de erroro Pruebas de validacioacuten y verificacioacuten requeridas

Tabla de composicioacuten de requisitos funcionales-no funcionales

Tabla de referencias cruzadas entre requisitos conflicto acoplamiento redundancia

Matrices de trazabilidad hacia requisitos de usuario y hacia disentildeoimplementacioacuten

Usar un formato que permita distintos niveles de visibilidad

o soacutelo enunciadoo soacutelo enunciado y descripcioacuteno enunciado descripcioacuten y propiedades

DiagramaDiagramas de secuencias

El diagrama de secuencia es un tipo de diagrama usado para modelarinteraccioacuten entre objetos en un sistema seguacuten UML

Un diagrama de secuencia muestra la interaccioacuten de un conjunto de objetos en una aplicacioacuten a traveacutes del tiempo y se modela para cada caso de uso Mientras que el diagrama de casos de uso permiteel modelado de una vista business del escenario el diagrama de secuencia contiene detalles de implementacioacuten del escenario incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos

Diagrama de secuencias del disentildeo

La fase de disentildeo (y los modelos UML resultantes) expande y detalla los modelos de anaacutelisis tomando en cuenta todas las implicaciones y restricciones teacutecnicas El propoacutesito del disentildeo es especificar una solucioacuten que trabaje y pueda ser faacutecilmente convertida en coacutedigo fuente y construir una arquitectura simple y faacutecilmente extensible Las clases definidas en el anaacutelisis fueron detalladas y se antildeadieron nuevas clases para manejar aacutereas teacutecnicas como base de datosinterfaz del usuario comunicacioacuten dispositivos etc

Diagrama de secuencia

Los casos de uso deben ser realizados durante esta etapa Para describir el comportamiento dinaacutemico del sistema cualquiera de los diagramas de interaccioacuten del UML pueden ser

utilizados Debido a que Rational Rose no soporta los diagramas de actividad y ofrece soporte limitado para los diagramas de colaboracioacuten (en notacioacuten completa del UML) usaremos diagramas de secuencia

Diagramas de componentes

Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de ModeladoUn diagrama de componentes representa coacutemo un sistema de software es dividido en componentes y muestra las

dependencias entre estos componentes Los componentes fiacutesicosincluyen archivos cabeceras bibliotecas compartidas moacutedulos ejecutables o paquetes Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistemaDebido a que los diagramas de componentes son maacutes parecidos alos diagramas de casos de usos eacutestos son utilizados para modelar la vista estaacutetica y dinaacutemica de un sistema Muestra la organizacioacuten y las dependencias entre un conjunto de componentes No es necesario que un diagrama incluya todos los componentes del sistema normalmente se realizan por partes Cada diagrama describe un apartado del sistemaEn eacutel se situaraacuten libreriacuteas tablas archivos ejecutables y documentos que formen parte del sistemaUno de los usos principales es que puede servir para ver queacute componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema

Diagramas de despliegue

El Diagrama de Despliegue es un tipo de diagrama del LenguajeUnificado de Modelado que se utiliza para modelar la disposicioacuten fiacutesica de los artefactos software en nodos (usualmente plataforma de hardware)Aspectos GeneralesLa mayoriacutea de las veces el modelado de la vista de despliegueimplica modelar la topologiacutea del hardware sobre el que se ejecuta el sistema Aunque UML no es un lenguaje de especificacioacuten hardware de propoacutesito general se ha disentildeado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el softwaredel sistemaUsosAlgunos de los usos que se les da a los diagramas de despliegue son para modelarSistemas empotrados Un sistema empotrado es una coleccioacuten dehardware con una gran cantidad de software que interactuacutea conel mundo fiacutesicoSistemas cliente-servidor Los sistemas cliente-servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribucioacuten fiacutesica de los componentes software del sistema a traveacutes de nodosSistemas completamente distribuidos En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores Tales sistemas contienen a menudo varias versiones de componentes software alguno de los cuales pueden incluso migrar de un nodo a otro El disentildeo de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topologiacutea del sistema

Arquitectura

Arquitectura de software El disentildeo arquitectoacutenico es el proceso a traveacutes del cual se

identifican los subsistemas que componen un sistema de informacioacuten asiacute como los mecanismos de control y comunicacioacuten usados por los mismos

El resultado de este proceso es una descripcioacuten de la arquitectura del software

Disentildeo arquitectoacutenico

Etapa temprana en el proceso de desarrollo de un sistemade informacioacuten

Es el enlace entre la especificacioacuten del sistema y el desarrollo del mismo

Implica identificar los principales componentes del sistema y su mecanismo de comunicacioacuten

Ventajas

Comunicacioacuten entre los interesados Reutilizacioacuten a gran escala Anaacutelisis del sistema (requerimientos no funcionales)

Estructura del sistema

Descompone el sistema en subsistemas que interactuacutean entre si

Se expresa como un diagrama de bloques presentando una visioacuten general del sistema

En caso de que sea necesario se puede aumentar el detalle de alguacuten subsistema importante

Subsistemas

Decisiones arquitectoacutenicas Existe alguacuten ejemplo de arquitectura geneacuterica que pueda

aplicarse Como se distribuiraacute el sistema Alguacuten estilo de arquitectura es aplicable Como se descompondraacute el sistema en moacutedulos Como se controlaran y comunicaran esos moacutedulos

Estilos arquitectoacutenicos

El modelo arquitectoacutenico de un sistema puede basarse en un estilo o modelo geneacuterico de arquitectura

Conocer estos modelos de antemano puede facilitar la tarea de definir la arquitectura de un sistema

Los grandes sistemas son heterogeacuteneos no siguiendo un claro estilo arquitectoacutenico uacutenico

Modelos arquitectoacutenicos Usados para documentar la arquitectura de un sistema Modelos estaacuteticos estructurales Modelos dinaacutemicos de procesos Modelos de interfaces Modelos de datos Modelos de deployment

Coacutedigo

El coacutedigo fuente de un programa informaacutetico (o software) es un conjunto de liacuteneas de texto que son las instrucciones que debe seguir la computadora para ejecutar dicho programa Por tanto en el coacutedigo fuente de un programa estaacute escrito por completo su funcionamientoEl coacutedigo fuente de un programa que estaacute escrito por un programador en alguacuten lenguaje de programacioacuten pero en este primer estado no es directamente ejecutable por la computadora sino que debe ser traducido a otro lenguaje (el lenguaje maacutequina o coacutedigo objeto) que siacute pueda ser ejecutado por el hardware de la computadora Para esta traduccioacuten se usan los llamados compiladores ensambladores inteacuterpretes y otros sistemas de traduccioacutenEl teacutermino coacutedigo fuente tambieacuten se usa para hacer referenciaal coacutedigo fuente de otros elementos del software como por ejemplo el coacutedigo fuente de una paacutegina web que estaacute escrito en el lenguaje de marcado HTML o en Javascript u otros lenguajes de programacioacuten web y que es posteriormente ejecutado por el navegador web para visualizar dicha paacutegina cuando es visitadaEl aacuterea de la informaacutetica que se dedica a la creacioacuten de

programas y por tanto a la creacioacuten de su coacutedigo fuente es la programacioacuten

El diagrama de secuencia es un tipo de diagrama usado para modelarinteraccioacuten entre objetos en un sistema seguacuten UML

Un diagrama de secuencia muestra la interaccioacuten de un conjunto de objetos en una aplicacioacuten a traveacutes del tiempo y se modela para cada caso de uso Mientras que el diagrama de casos de uso permiteel modelado de una vista business del escenario el diagrama de secuencia contiene detalles de implementacioacuten del escenario incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos

Diagrama de secuencias del disentildeo

La fase de disentildeo (y los modelos UML resultantes) expande y detalla los modelos de anaacutelisis tomando en cuenta todas las implicaciones y restricciones teacutecnicas El propoacutesito del disentildeo es especificar una solucioacuten que trabaje y pueda ser faacutecilmente convertida en coacutedigo fuente y construir una arquitectura simple y faacutecilmente extensible Las clases definidas en el anaacutelisis fueron detalladas y se antildeadieron nuevas clases para manejar aacutereas teacutecnicas como base de datosinterfaz del usuario comunicacioacuten dispositivos etc

Diagrama de secuencia

Los casos de uso deben ser realizados durante esta etapa Para describir el comportamiento dinaacutemico del sistema cualquiera de los diagramas de interaccioacuten del UML pueden ser

utilizados Debido a que Rational Rose no soporta los diagramas de actividad y ofrece soporte limitado para los diagramas de colaboracioacuten (en notacioacuten completa del UML) usaremos diagramas de secuencia

Diagramas de componentes

Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de ModeladoUn diagrama de componentes representa coacutemo un sistema de software es dividido en componentes y muestra las

dependencias entre estos componentes Los componentes fiacutesicosincluyen archivos cabeceras bibliotecas compartidas moacutedulos ejecutables o paquetes Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistemaDebido a que los diagramas de componentes son maacutes parecidos alos diagramas de casos de usos eacutestos son utilizados para modelar la vista estaacutetica y dinaacutemica de un sistema Muestra la organizacioacuten y las dependencias entre un conjunto de componentes No es necesario que un diagrama incluya todos los componentes del sistema normalmente se realizan por partes Cada diagrama describe un apartado del sistemaEn eacutel se situaraacuten libreriacuteas tablas archivos ejecutables y documentos que formen parte del sistemaUno de los usos principales es que puede servir para ver queacute componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema

Diagramas de despliegue

El Diagrama de Despliegue es un tipo de diagrama del LenguajeUnificado de Modelado que se utiliza para modelar la disposicioacuten fiacutesica de los artefactos software en nodos (usualmente plataforma de hardware)Aspectos GeneralesLa mayoriacutea de las veces el modelado de la vista de despliegueimplica modelar la topologiacutea del hardware sobre el que se ejecuta el sistema Aunque UML no es un lenguaje de especificacioacuten hardware de propoacutesito general se ha disentildeado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el softwaredel sistemaUsosAlgunos de los usos que se les da a los diagramas de despliegue son para modelarSistemas empotrados Un sistema empotrado es una coleccioacuten dehardware con una gran cantidad de software que interactuacutea conel mundo fiacutesicoSistemas cliente-servidor Los sistemas cliente-servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribucioacuten fiacutesica de los componentes software del sistema a traveacutes de nodosSistemas completamente distribuidos En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores Tales sistemas contienen a menudo varias versiones de componentes software alguno de los cuales pueden incluso migrar de un nodo a otro El disentildeo de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topologiacutea del sistema

Arquitectura

Arquitectura de software El disentildeo arquitectoacutenico es el proceso a traveacutes del cual se

identifican los subsistemas que componen un sistema de informacioacuten asiacute como los mecanismos de control y comunicacioacuten usados por los mismos

El resultado de este proceso es una descripcioacuten de la arquitectura del software

Disentildeo arquitectoacutenico

Etapa temprana en el proceso de desarrollo de un sistemade informacioacuten

Es el enlace entre la especificacioacuten del sistema y el desarrollo del mismo

Implica identificar los principales componentes del sistema y su mecanismo de comunicacioacuten

Ventajas

Comunicacioacuten entre los interesados Reutilizacioacuten a gran escala Anaacutelisis del sistema (requerimientos no funcionales)

Estructura del sistema

Descompone el sistema en subsistemas que interactuacutean entre si

Se expresa como un diagrama de bloques presentando una visioacuten general del sistema

En caso de que sea necesario se puede aumentar el detalle de alguacuten subsistema importante

Subsistemas

Decisiones arquitectoacutenicas Existe alguacuten ejemplo de arquitectura geneacuterica que pueda

aplicarse Como se distribuiraacute el sistema Alguacuten estilo de arquitectura es aplicable Como se descompondraacute el sistema en moacutedulos Como se controlaran y comunicaran esos moacutedulos

Estilos arquitectoacutenicos

El modelo arquitectoacutenico de un sistema puede basarse en un estilo o modelo geneacuterico de arquitectura

Conocer estos modelos de antemano puede facilitar la tarea de definir la arquitectura de un sistema

Los grandes sistemas son heterogeacuteneos no siguiendo un claro estilo arquitectoacutenico uacutenico

Modelos arquitectoacutenicos Usados para documentar la arquitectura de un sistema Modelos estaacuteticos estructurales Modelos dinaacutemicos de procesos Modelos de interfaces Modelos de datos Modelos de deployment

Coacutedigo

El coacutedigo fuente de un programa informaacutetico (o software) es un conjunto de liacuteneas de texto que son las instrucciones que debe seguir la computadora para ejecutar dicho programa Por tanto en el coacutedigo fuente de un programa estaacute escrito por completo su funcionamientoEl coacutedigo fuente de un programa que estaacute escrito por un programador en alguacuten lenguaje de programacioacuten pero en este primer estado no es directamente ejecutable por la computadora sino que debe ser traducido a otro lenguaje (el lenguaje maacutequina o coacutedigo objeto) que siacute pueda ser ejecutado por el hardware de la computadora Para esta traduccioacuten se usan los llamados compiladores ensambladores inteacuterpretes y otros sistemas de traduccioacutenEl teacutermino coacutedigo fuente tambieacuten se usa para hacer referenciaal coacutedigo fuente de otros elementos del software como por ejemplo el coacutedigo fuente de una paacutegina web que estaacute escrito en el lenguaje de marcado HTML o en Javascript u otros lenguajes de programacioacuten web y que es posteriormente ejecutado por el navegador web para visualizar dicha paacutegina cuando es visitadaEl aacuterea de la informaacutetica que se dedica a la creacioacuten de

programas y por tanto a la creacioacuten de su coacutedigo fuente es la programacioacuten

utilizados Debido a que Rational Rose no soporta los diagramas de actividad y ofrece soporte limitado para los diagramas de colaboracioacuten (en notacioacuten completa del UML) usaremos diagramas de secuencia

Diagramas de componentes

Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de ModeladoUn diagrama de componentes representa coacutemo un sistema de software es dividido en componentes y muestra las

dependencias entre estos componentes Los componentes fiacutesicosincluyen archivos cabeceras bibliotecas compartidas moacutedulos ejecutables o paquetes Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistemaDebido a que los diagramas de componentes son maacutes parecidos alos diagramas de casos de usos eacutestos son utilizados para modelar la vista estaacutetica y dinaacutemica de un sistema Muestra la organizacioacuten y las dependencias entre un conjunto de componentes No es necesario que un diagrama incluya todos los componentes del sistema normalmente se realizan por partes Cada diagrama describe un apartado del sistemaEn eacutel se situaraacuten libreriacuteas tablas archivos ejecutables y documentos que formen parte del sistemaUno de los usos principales es que puede servir para ver queacute componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema

Diagramas de despliegue

El Diagrama de Despliegue es un tipo de diagrama del LenguajeUnificado de Modelado que se utiliza para modelar la disposicioacuten fiacutesica de los artefactos software en nodos (usualmente plataforma de hardware)Aspectos GeneralesLa mayoriacutea de las veces el modelado de la vista de despliegueimplica modelar la topologiacutea del hardware sobre el que se ejecuta el sistema Aunque UML no es un lenguaje de especificacioacuten hardware de propoacutesito general se ha disentildeado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el softwaredel sistemaUsosAlgunos de los usos que se les da a los diagramas de despliegue son para modelarSistemas empotrados Un sistema empotrado es una coleccioacuten dehardware con una gran cantidad de software que interactuacutea conel mundo fiacutesicoSistemas cliente-servidor Los sistemas cliente-servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribucioacuten fiacutesica de los componentes software del sistema a traveacutes de nodosSistemas completamente distribuidos En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores Tales sistemas contienen a menudo varias versiones de componentes software alguno de los cuales pueden incluso migrar de un nodo a otro El disentildeo de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topologiacutea del sistema

Arquitectura

Arquitectura de software El disentildeo arquitectoacutenico es el proceso a traveacutes del cual se

identifican los subsistemas que componen un sistema de informacioacuten asiacute como los mecanismos de control y comunicacioacuten usados por los mismos

El resultado de este proceso es una descripcioacuten de la arquitectura del software

Disentildeo arquitectoacutenico

Etapa temprana en el proceso de desarrollo de un sistemade informacioacuten

Es el enlace entre la especificacioacuten del sistema y el desarrollo del mismo

Implica identificar los principales componentes del sistema y su mecanismo de comunicacioacuten

Ventajas

Comunicacioacuten entre los interesados Reutilizacioacuten a gran escala Anaacutelisis del sistema (requerimientos no funcionales)

Estructura del sistema

Descompone el sistema en subsistemas que interactuacutean entre si

Se expresa como un diagrama de bloques presentando una visioacuten general del sistema

En caso de que sea necesario se puede aumentar el detalle de alguacuten subsistema importante

Subsistemas

Decisiones arquitectoacutenicas Existe alguacuten ejemplo de arquitectura geneacuterica que pueda

aplicarse Como se distribuiraacute el sistema Alguacuten estilo de arquitectura es aplicable Como se descompondraacute el sistema en moacutedulos Como se controlaran y comunicaran esos moacutedulos

Estilos arquitectoacutenicos

El modelo arquitectoacutenico de un sistema puede basarse en un estilo o modelo geneacuterico de arquitectura

Conocer estos modelos de antemano puede facilitar la tarea de definir la arquitectura de un sistema

Los grandes sistemas son heterogeacuteneos no siguiendo un claro estilo arquitectoacutenico uacutenico

Modelos arquitectoacutenicos Usados para documentar la arquitectura de un sistema Modelos estaacuteticos estructurales Modelos dinaacutemicos de procesos Modelos de interfaces Modelos de datos Modelos de deployment

Coacutedigo

El coacutedigo fuente de un programa informaacutetico (o software) es un conjunto de liacuteneas de texto que son las instrucciones que debe seguir la computadora para ejecutar dicho programa Por tanto en el coacutedigo fuente de un programa estaacute escrito por completo su funcionamientoEl coacutedigo fuente de un programa que estaacute escrito por un programador en alguacuten lenguaje de programacioacuten pero en este primer estado no es directamente ejecutable por la computadora sino que debe ser traducido a otro lenguaje (el lenguaje maacutequina o coacutedigo objeto) que siacute pueda ser ejecutado por el hardware de la computadora Para esta traduccioacuten se usan los llamados compiladores ensambladores inteacuterpretes y otros sistemas de traduccioacutenEl teacutermino coacutedigo fuente tambieacuten se usa para hacer referenciaal coacutedigo fuente de otros elementos del software como por ejemplo el coacutedigo fuente de una paacutegina web que estaacute escrito en el lenguaje de marcado HTML o en Javascript u otros lenguajes de programacioacuten web y que es posteriormente ejecutado por el navegador web para visualizar dicha paacutegina cuando es visitadaEl aacuterea de la informaacutetica que se dedica a la creacioacuten de

programas y por tanto a la creacioacuten de su coacutedigo fuente es la programacioacuten

dependencias entre estos componentes Los componentes fiacutesicosincluyen archivos cabeceras bibliotecas compartidas moacutedulos ejecutables o paquetes Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistemaDebido a que los diagramas de componentes son maacutes parecidos alos diagramas de casos de usos eacutestos son utilizados para modelar la vista estaacutetica y dinaacutemica de un sistema Muestra la organizacioacuten y las dependencias entre un conjunto de componentes No es necesario que un diagrama incluya todos los componentes del sistema normalmente se realizan por partes Cada diagrama describe un apartado del sistemaEn eacutel se situaraacuten libreriacuteas tablas archivos ejecutables y documentos que formen parte del sistemaUno de los usos principales es que puede servir para ver queacute componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema

Diagramas de despliegue

El Diagrama de Despliegue es un tipo de diagrama del LenguajeUnificado de Modelado que se utiliza para modelar la disposicioacuten fiacutesica de los artefactos software en nodos (usualmente plataforma de hardware)Aspectos GeneralesLa mayoriacutea de las veces el modelado de la vista de despliegueimplica modelar la topologiacutea del hardware sobre el que se ejecuta el sistema Aunque UML no es un lenguaje de especificacioacuten hardware de propoacutesito general se ha disentildeado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el softwaredel sistemaUsosAlgunos de los usos que se les da a los diagramas de despliegue son para modelarSistemas empotrados Un sistema empotrado es una coleccioacuten dehardware con una gran cantidad de software que interactuacutea conel mundo fiacutesicoSistemas cliente-servidor Los sistemas cliente-servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribucioacuten fiacutesica de los componentes software del sistema a traveacutes de nodosSistemas completamente distribuidos En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores Tales sistemas contienen a menudo varias versiones de componentes software alguno de los cuales pueden incluso migrar de un nodo a otro El disentildeo de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topologiacutea del sistema

Arquitectura

Arquitectura de software El disentildeo arquitectoacutenico es el proceso a traveacutes del cual se

identifican los subsistemas que componen un sistema de informacioacuten asiacute como los mecanismos de control y comunicacioacuten usados por los mismos

El resultado de este proceso es una descripcioacuten de la arquitectura del software

Disentildeo arquitectoacutenico

Etapa temprana en el proceso de desarrollo de un sistemade informacioacuten

Es el enlace entre la especificacioacuten del sistema y el desarrollo del mismo

Implica identificar los principales componentes del sistema y su mecanismo de comunicacioacuten

Ventajas

Comunicacioacuten entre los interesados Reutilizacioacuten a gran escala Anaacutelisis del sistema (requerimientos no funcionales)

Estructura del sistema

Descompone el sistema en subsistemas que interactuacutean entre si

Se expresa como un diagrama de bloques presentando una visioacuten general del sistema

En caso de que sea necesario se puede aumentar el detalle de alguacuten subsistema importante

Subsistemas

Decisiones arquitectoacutenicas Existe alguacuten ejemplo de arquitectura geneacuterica que pueda

aplicarse Como se distribuiraacute el sistema Alguacuten estilo de arquitectura es aplicable Como se descompondraacute el sistema en moacutedulos Como se controlaran y comunicaran esos moacutedulos

Estilos arquitectoacutenicos

El modelo arquitectoacutenico de un sistema puede basarse en un estilo o modelo geneacuterico de arquitectura

Conocer estos modelos de antemano puede facilitar la tarea de definir la arquitectura de un sistema

Los grandes sistemas son heterogeacuteneos no siguiendo un claro estilo arquitectoacutenico uacutenico

Modelos arquitectoacutenicos Usados para documentar la arquitectura de un sistema Modelos estaacuteticos estructurales Modelos dinaacutemicos de procesos Modelos de interfaces Modelos de datos Modelos de deployment

Coacutedigo

El coacutedigo fuente de un programa informaacutetico (o software) es un conjunto de liacuteneas de texto que son las instrucciones que debe seguir la computadora para ejecutar dicho programa Por tanto en el coacutedigo fuente de un programa estaacute escrito por completo su funcionamientoEl coacutedigo fuente de un programa que estaacute escrito por un programador en alguacuten lenguaje de programacioacuten pero en este primer estado no es directamente ejecutable por la computadora sino que debe ser traducido a otro lenguaje (el lenguaje maacutequina o coacutedigo objeto) que siacute pueda ser ejecutado por el hardware de la computadora Para esta traduccioacuten se usan los llamados compiladores ensambladores inteacuterpretes y otros sistemas de traduccioacutenEl teacutermino coacutedigo fuente tambieacuten se usa para hacer referenciaal coacutedigo fuente de otros elementos del software como por ejemplo el coacutedigo fuente de una paacutegina web que estaacute escrito en el lenguaje de marcado HTML o en Javascript u otros lenguajes de programacioacuten web y que es posteriormente ejecutado por el navegador web para visualizar dicha paacutegina cuando es visitadaEl aacuterea de la informaacutetica que se dedica a la creacioacuten de

programas y por tanto a la creacioacuten de su coacutedigo fuente es la programacioacuten

Diagramas de despliegue

El Diagrama de Despliegue es un tipo de diagrama del LenguajeUnificado de Modelado que se utiliza para modelar la disposicioacuten fiacutesica de los artefactos software en nodos (usualmente plataforma de hardware)Aspectos GeneralesLa mayoriacutea de las veces el modelado de la vista de despliegueimplica modelar la topologiacutea del hardware sobre el que se ejecuta el sistema Aunque UML no es un lenguaje de especificacioacuten hardware de propoacutesito general se ha disentildeado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el softwaredel sistemaUsosAlgunos de los usos que se les da a los diagramas de despliegue son para modelarSistemas empotrados Un sistema empotrado es una coleccioacuten dehardware con una gran cantidad de software que interactuacutea conel mundo fiacutesicoSistemas cliente-servidor Los sistemas cliente-servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribucioacuten fiacutesica de los componentes software del sistema a traveacutes de nodosSistemas completamente distribuidos En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores Tales sistemas contienen a menudo varias versiones de componentes software alguno de los cuales pueden incluso migrar de un nodo a otro El disentildeo de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topologiacutea del sistema

Arquitectura

Arquitectura de software El disentildeo arquitectoacutenico es el proceso a traveacutes del cual se

identifican los subsistemas que componen un sistema de informacioacuten asiacute como los mecanismos de control y comunicacioacuten usados por los mismos

El resultado de este proceso es una descripcioacuten de la arquitectura del software

Disentildeo arquitectoacutenico

Etapa temprana en el proceso de desarrollo de un sistemade informacioacuten

Es el enlace entre la especificacioacuten del sistema y el desarrollo del mismo

Implica identificar los principales componentes del sistema y su mecanismo de comunicacioacuten

Ventajas

Comunicacioacuten entre los interesados Reutilizacioacuten a gran escala Anaacutelisis del sistema (requerimientos no funcionales)

Estructura del sistema

Descompone el sistema en subsistemas que interactuacutean entre si

Se expresa como un diagrama de bloques presentando una visioacuten general del sistema

En caso de que sea necesario se puede aumentar el detalle de alguacuten subsistema importante

Subsistemas

Decisiones arquitectoacutenicas Existe alguacuten ejemplo de arquitectura geneacuterica que pueda

aplicarse Como se distribuiraacute el sistema Alguacuten estilo de arquitectura es aplicable Como se descompondraacute el sistema en moacutedulos Como se controlaran y comunicaran esos moacutedulos

Estilos arquitectoacutenicos

El modelo arquitectoacutenico de un sistema puede basarse en un estilo o modelo geneacuterico de arquitectura

Conocer estos modelos de antemano puede facilitar la tarea de definir la arquitectura de un sistema

Los grandes sistemas son heterogeacuteneos no siguiendo un claro estilo arquitectoacutenico uacutenico

Modelos arquitectoacutenicos Usados para documentar la arquitectura de un sistema Modelos estaacuteticos estructurales Modelos dinaacutemicos de procesos Modelos de interfaces Modelos de datos Modelos de deployment

Coacutedigo

El coacutedigo fuente de un programa informaacutetico (o software) es un conjunto de liacuteneas de texto que son las instrucciones que debe seguir la computadora para ejecutar dicho programa Por tanto en el coacutedigo fuente de un programa estaacute escrito por completo su funcionamientoEl coacutedigo fuente de un programa que estaacute escrito por un programador en alguacuten lenguaje de programacioacuten pero en este primer estado no es directamente ejecutable por la computadora sino que debe ser traducido a otro lenguaje (el lenguaje maacutequina o coacutedigo objeto) que siacute pueda ser ejecutado por el hardware de la computadora Para esta traduccioacuten se usan los llamados compiladores ensambladores inteacuterpretes y otros sistemas de traduccioacutenEl teacutermino coacutedigo fuente tambieacuten se usa para hacer referenciaal coacutedigo fuente de otros elementos del software como por ejemplo el coacutedigo fuente de una paacutegina web que estaacute escrito en el lenguaje de marcado HTML o en Javascript u otros lenguajes de programacioacuten web y que es posteriormente ejecutado por el navegador web para visualizar dicha paacutegina cuando es visitadaEl aacuterea de la informaacutetica que se dedica a la creacioacuten de

programas y por tanto a la creacioacuten de su coacutedigo fuente es la programacioacuten

Arquitectura

Arquitectura de software El disentildeo arquitectoacutenico es el proceso a traveacutes del cual se

identifican los subsistemas que componen un sistema de informacioacuten asiacute como los mecanismos de control y comunicacioacuten usados por los mismos

El resultado de este proceso es una descripcioacuten de la arquitectura del software

Disentildeo arquitectoacutenico

Etapa temprana en el proceso de desarrollo de un sistemade informacioacuten

Es el enlace entre la especificacioacuten del sistema y el desarrollo del mismo

Implica identificar los principales componentes del sistema y su mecanismo de comunicacioacuten

Ventajas

Comunicacioacuten entre los interesados Reutilizacioacuten a gran escala Anaacutelisis del sistema (requerimientos no funcionales)

Estructura del sistema

Descompone el sistema en subsistemas que interactuacutean entre si

Se expresa como un diagrama de bloques presentando una visioacuten general del sistema

En caso de que sea necesario se puede aumentar el detalle de alguacuten subsistema importante

Subsistemas

Decisiones arquitectoacutenicas Existe alguacuten ejemplo de arquitectura geneacuterica que pueda

aplicarse Como se distribuiraacute el sistema Alguacuten estilo de arquitectura es aplicable Como se descompondraacute el sistema en moacutedulos Como se controlaran y comunicaran esos moacutedulos

Estilos arquitectoacutenicos

El modelo arquitectoacutenico de un sistema puede basarse en un estilo o modelo geneacuterico de arquitectura

Conocer estos modelos de antemano puede facilitar la tarea de definir la arquitectura de un sistema

Los grandes sistemas son heterogeacuteneos no siguiendo un claro estilo arquitectoacutenico uacutenico

Modelos arquitectoacutenicos Usados para documentar la arquitectura de un sistema Modelos estaacuteticos estructurales Modelos dinaacutemicos de procesos Modelos de interfaces Modelos de datos Modelos de deployment

Coacutedigo

El coacutedigo fuente de un programa informaacutetico (o software) es un conjunto de liacuteneas de texto que son las instrucciones que debe seguir la computadora para ejecutar dicho programa Por tanto en el coacutedigo fuente de un programa estaacute escrito por completo su funcionamientoEl coacutedigo fuente de un programa que estaacute escrito por un programador en alguacuten lenguaje de programacioacuten pero en este primer estado no es directamente ejecutable por la computadora sino que debe ser traducido a otro lenguaje (el lenguaje maacutequina o coacutedigo objeto) que siacute pueda ser ejecutado por el hardware de la computadora Para esta traduccioacuten se usan los llamados compiladores ensambladores inteacuterpretes y otros sistemas de traduccioacutenEl teacutermino coacutedigo fuente tambieacuten se usa para hacer referenciaal coacutedigo fuente de otros elementos del software como por ejemplo el coacutedigo fuente de una paacutegina web que estaacute escrito en el lenguaje de marcado HTML o en Javascript u otros lenguajes de programacioacuten web y que es posteriormente ejecutado por el navegador web para visualizar dicha paacutegina cuando es visitadaEl aacuterea de la informaacutetica que se dedica a la creacioacuten de

programas y por tanto a la creacioacuten de su coacutedigo fuente es la programacioacuten

Ventajas

Comunicacioacuten entre los interesados Reutilizacioacuten a gran escala Anaacutelisis del sistema (requerimientos no funcionales)

Estructura del sistema

Descompone el sistema en subsistemas que interactuacutean entre si

Se expresa como un diagrama de bloques presentando una visioacuten general del sistema

En caso de que sea necesario se puede aumentar el detalle de alguacuten subsistema importante

Subsistemas

Decisiones arquitectoacutenicas Existe alguacuten ejemplo de arquitectura geneacuterica que pueda

aplicarse Como se distribuiraacute el sistema Alguacuten estilo de arquitectura es aplicable Como se descompondraacute el sistema en moacutedulos Como se controlaran y comunicaran esos moacutedulos

Estilos arquitectoacutenicos

El modelo arquitectoacutenico de un sistema puede basarse en un estilo o modelo geneacuterico de arquitectura

Conocer estos modelos de antemano puede facilitar la tarea de definir la arquitectura de un sistema

Los grandes sistemas son heterogeacuteneos no siguiendo un claro estilo arquitectoacutenico uacutenico

Modelos arquitectoacutenicos Usados para documentar la arquitectura de un sistema Modelos estaacuteticos estructurales Modelos dinaacutemicos de procesos Modelos de interfaces Modelos de datos Modelos de deployment

Coacutedigo

El coacutedigo fuente de un programa informaacutetico (o software) es un conjunto de liacuteneas de texto que son las instrucciones que debe seguir la computadora para ejecutar dicho programa Por tanto en el coacutedigo fuente de un programa estaacute escrito por completo su funcionamientoEl coacutedigo fuente de un programa que estaacute escrito por un programador en alguacuten lenguaje de programacioacuten pero en este primer estado no es directamente ejecutable por la computadora sino que debe ser traducido a otro lenguaje (el lenguaje maacutequina o coacutedigo objeto) que siacute pueda ser ejecutado por el hardware de la computadora Para esta traduccioacuten se usan los llamados compiladores ensambladores inteacuterpretes y otros sistemas de traduccioacutenEl teacutermino coacutedigo fuente tambieacuten se usa para hacer referenciaal coacutedigo fuente de otros elementos del software como por ejemplo el coacutedigo fuente de una paacutegina web que estaacute escrito en el lenguaje de marcado HTML o en Javascript u otros lenguajes de programacioacuten web y que es posteriormente ejecutado por el navegador web para visualizar dicha paacutegina cuando es visitadaEl aacuterea de la informaacutetica que se dedica a la creacioacuten de

programas y por tanto a la creacioacuten de su coacutedigo fuente es la programacioacuten

El modelo arquitectoacutenico de un sistema puede basarse en un estilo o modelo geneacuterico de arquitectura

Conocer estos modelos de antemano puede facilitar la tarea de definir la arquitectura de un sistema

Los grandes sistemas son heterogeacuteneos no siguiendo un claro estilo arquitectoacutenico uacutenico

Modelos arquitectoacutenicos Usados para documentar la arquitectura de un sistema Modelos estaacuteticos estructurales Modelos dinaacutemicos de procesos Modelos de interfaces Modelos de datos Modelos de deployment

Coacutedigo

El coacutedigo fuente de un programa informaacutetico (o software) es un conjunto de liacuteneas de texto que son las instrucciones que debe seguir la computadora para ejecutar dicho programa Por tanto en el coacutedigo fuente de un programa estaacute escrito por completo su funcionamientoEl coacutedigo fuente de un programa que estaacute escrito por un programador en alguacuten lenguaje de programacioacuten pero en este primer estado no es directamente ejecutable por la computadora sino que debe ser traducido a otro lenguaje (el lenguaje maacutequina o coacutedigo objeto) que siacute pueda ser ejecutado por el hardware de la computadora Para esta traduccioacuten se usan los llamados compiladores ensambladores inteacuterpretes y otros sistemas de traduccioacutenEl teacutermino coacutedigo fuente tambieacuten se usa para hacer referenciaal coacutedigo fuente de otros elementos del software como por ejemplo el coacutedigo fuente de una paacutegina web que estaacute escrito en el lenguaje de marcado HTML o en Javascript u otros lenguajes de programacioacuten web y que es posteriormente ejecutado por el navegador web para visualizar dicha paacutegina cuando es visitadaEl aacuterea de la informaacutetica que se dedica a la creacioacuten de

programas y por tanto a la creacioacuten de su coacutedigo fuente es la programacioacuten

programas y por tanto a la creacioacuten de su coacutedigo fuente es la programacioacuten