Conceptotos de Fundamentos de IS
-
Upload
independent -
Category
Documents
-
view
4 -
download
0
Transcript of Conceptotos de Fundamentos de IS
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