You are on page 1of 63

Fundamentos de Ingeniera de Software [Etapas]

M. en C. Sergio Luis Perez


Perez

UAM C UAJIMALPA , M E XICO, D. F.


Trimestre 13-I

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

1 / 63

Ingeniera de requerimientos

Ingeniera de requerimientos I

Los requerimientos para un producto de software o en general un

sistema son descripciones del servicio que este


debe

proporcionar, as como de sus restricciones de operacion.


Los requerimientos reflejan las necesidades de los clientes.
La ingeniera de requerimientos consiste en identificar, analizar,
documentar y verificar tales servicios y sus restricciones.
para los requerimientos:
Se distinguen dos niveles de abstraccion

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

2 / 63

Ingeniera de requerimientos

Ingeniera de requerimientos II

Requerimientos del usuario


Se escriben en lenguaje natural.
Describen los servicios que esperan los usuarios.

Describen las restricciones de operacion.


Gerentes del cliente
Gerentes de los contratistas
Arquitectos del sistema

Sergio Luis Perez


(UAM C UAJIMALPA)

Usuarios finales del sistema


Ingenieros del cliente

Curso de fundamentos de ing. de software

3 / 63

Ingeniera de requerimientos

Ingeniera de requerimientos III

Requerimientos del sistema


Describen de forma detallada las funciones, los servicios y las

restricciones operacionales del sistema que se implementaran.


Puede formar parte del contrato Cliente Desarrolladores.
Usuarios finales del sistema
Ingenieros del cliente
Arquitectos del sistema
Desarrolladores de software

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

4 / 63

Ingeniera de requerimientos

Ingeniera de requerimientos IV

del requerimiento del usuario


Ejemplo: Definicion
de Pacientes elaborara mensualmente
El Sistema de Administracion
informes administrativos que revelen el costo de los medicamentos
prescritos por cada clnica por mes.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

5 / 63

Ingeniera de requerimientos

Ingeniera de requerimientos V
de los requerimientos del sistema
Ejemplo: Definicion
El ultimo
da de cada mes se redactara un resumen de los

medicamentos prescritos, su costo y las clnicas que los


prescriben.

El sistema elaborara automaticamente


el informe que se
de las 17:30 del mismo da.
imprimira despues
Por cada clnica, se realizara un reporte con los medicamentos
prescritos, el numero
de prescripciones, las dosis y el costo total.

disponibles en diferentes dosis se


Si los medicamentos estan
informes por separado por cada dosis.
haran
los usuarios autorizados en la lista de control tendran

Solo
acceso a los informes.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

6 / 63

Ingeniera de requerimientos

Tipos de requerimientos

Requerimientos funcionales I

Describen los servicios que el sistema debe proveer.


se describe como debe reaccionar el sistema con
Tambien
determinadas entradas y su comportamiento en situaciones
especficas.

Se describen desde funciones generales hasta funciones mas


especficas.
Se deben definir todos los servicios requeridos por el usuario.
La ambiguedad
puede causar muchos problemas a futuro.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

7 / 63

Ingeniera de requerimientos

Tipos de requerimientos

Requerimientos funcionales II

Ejemplos
1

Un usuario podra buscar en todas las clnicas las listas de citas.

El sistema elaborara diariamente, para cada clnica, la lista de


pacientes que se espera asistan ese da.

Cada usuario del sistema debera identificarse con su nombre de

usuario y su contrasena.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

8 / 63

Ingeniera de requerimientos

Tipos de requerimientos

Requerimientos no funcionales I
No se relacionan con los servicios que el sistema proporciona a
sus usuarios.
Describen la fiabilidad del sistema, su seguridad, su tiempo de
respuesta, su disponibilidad, su costo de almacenamiento, entre
otros.
Se derivan de las restricciones presupuestales, polticas de la
interoperabilidad con otros sistemas, regulaciones
organizacion,
sobre privacidad, entre otros.
de seguridad, legislacion
Se pueden generalizar tres tipos de requerimientos no
funcionales:

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

9 / 63

Ingeniera de requerimientos

Tipos de requerimientos

Requerimientos no funcionales II

Requerimientos del producto


Especifican o restringen el comportamiento del software.
Ejemplos:
del sistema
Velocidad de ejecucion
Cantidad de memoria requerida
Tasa aceptable de fallas
Requerimientos de seguridad
Requerimientos de usabilidad

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

10 / 63

Ingeniera de requerimientos

Tipos de requerimientos

Requerimientos no funcionales III

Requerimientos de la organizacion

Se derivan de las polticas y procedimientos en la organizacion


del cliente y del proveedor de software.
Se deviden en tres:

Operacionales. Definen como


se usara el sistema.
del sistema.
Ambientales. Definen el entorno de operacion

De desarrollo. Definen el lenguaje de programacion.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

11 / 63

Ingeniera de requerimientos

Tipos de requerimientos

Requerimientos no funcionales IV

Requerimientos externos
Se derivan de factores externos al sistema y su proceso de
desarrollo.
Se deviden en tres:
Regulatorios. Establecen lo que debe hacer el sistema para ser
aprobado.

Eticos.
Garantizan que el sistema opere conforme a la ley.
Legales. Garantizan que el sistema sera aceptable para los
usuarios y en general para la sociedad.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

12 / 63

Ingeniera de requerimientos

Tipos de requerimientos

Requerimientos no funcionales V
Metricas para los requerimientos no funcionales
Eficiencia

Tamano
Facilidad de uso
Fiabilidad

Robustez
Portabilidad

Sergio Luis Perez


(UAM C UAJIMALPA)

Transacciones/Segundo
Tiempo de respuesta usuario/evento
de pantalla
Tiempo de regeneracion
Memoria necesaria
Espacio de almacenamiento

Tiempo de capacitacion
Tiempo medio para falla
Tasa de ocurrencia de falla
Probabilidad de indisponibilidad
de falla
Tiempo de reinicio despues
Probabilidad de corrupcion de datos
Porcentaje de eventos que causan falla
Sistemas Operativos
Curso de fundamentos de ing. de software

13 / 63

Ingeniera de requerimientos

El documento de requerimientos

El documento de requerimientos I
Describe de manera oficial lo que deben implementar los
desarrolladores del sistema.
Incluye los requeirmientos de usuario y del sistema.
Generalmente tienen acceso a este documento las siguientes
personas:
Clientes del sistema. Especifican los requerimientos y los verifican.
para el
Administradores. Les ayuda a planear una cotizacion
sistema y su proceso de desarrollo.
Ingenieros del sistema. Les ayuda a entender que debe hacer el
sistema.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

14 / 63

Ingeniera de requerimientos

El documento de requerimientos

El documento de requerimientos II
Ingenieros de prueba del sistema. Desrrollan las pruebas de
del sistema.
validacion
Ingenieros de mantenimiento del sistema. Les ayuda a comprender
el sistema.

se describe la estructura que debe poseer el


A continuacion
documento de requerimientos:
Prefacio

de ser de
Se debe describir el historico
de versiones as como la razon

cada version.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

15 / 63

Ingeniera de requerimientos

El documento de requerimientos

El documento de requerimientos III


Indice
Se debe incluir el ndice normal, uno de diagramas, uno de funciones
y en general uno de cada parte representativa del contenido.

Introduccion
Describe la necesidad para haber creado el sistema.
describe de forma general las funciones del sistema.
Tambien

Finalmente describe como


el sistema se ajusta a los objetivos de
la empresa/cliente.
de requerimientos del usuario
Definicion
Se describen los requerimientos funcionales y los no funcionales.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

16 / 63

Ingeniera de requerimientos

El documento de requerimientos

El documento de requerimientos IV
Arquitectura del sistema

Se especifican los modulos


del sistema y sus relaciones.

Se deben describir las funciones de cada modulo.

Se debe especificar cuales


de los componentes son reciclados.
de requerimientos del sistema
Especificacion
En esta parte se detallan tecnicamente los requerimientos funcionales
y los no funcionales.
Modelos del sistema
Se muestran las relaciones entre los componentes del sistema y
su entorno.
Se muestran los modelos de objetos y los de los flujos de datos.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

17 / 63

Ingeniera de requerimientos

El documento de requerimientos

El documento de requerimientos V
del sistema
Evolucion
Se describen las posibles ampliaciones al sistema que quedan a
futuro.

Apendices
Detallan los requerimientos de hardware que definen los

rendimientos mnimo y optimo


del sistema.
detallan los requerimientos de bases de datos y la
Tambien
logica

organizacion
de estas.
Glosario

Define claramente los terminos


tecnicos
usados en el documento.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

18 / 63

Ingeniera de requerimientos

Casos de uso

Casos de uso I

Los casos de uso son una tecnica


que consiste en la obtencion
de requerimientos.
Describen los pasos y/o actividades involucrados en un proceso.
Deben tenerse en cuenta a las personas o entidades que
en cada caso, es decir los actores.
participaran
se describiran
las interacciones/relaciones
En cada caso, tambien
entre el sistema y sus actores en respuesta a un evento.

Existen tres tipos de relaciones basicas:


comunica (<<communicates>>): Establece una relacion

Relacion
entre un actor y un caso de uso.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

19 / 63

Ingeniera de requerimientos

Casos de uso

Casos de uso II
usa (<<uses>>): Establece una dependencia entre dos
Relacion
del comportamiento de un
casos de uso, denotando la inclusion
escenario en otro.
extiende (<<extends>>): Establece una dependencia
Relacion
entre dos casos de uso denotando que un caso de uso es una
de otro.
especializacion

de un Caso de Uso:
Puntos importantes para la definicion
1

Consecutivo.

Ttulo.

Autor.

Fecha de creacion

Fecha de ultima
actualizacion.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

20 / 63

Ingeniera de requerimientos

Casos de uso

Casos de uso III


6

Actores.

Descripcion.

Precondiciones.

Postcondiciones.

10

Flujo normal.

11

Flujos alternos.

12

Frecuencia de uso.

13

Reglas de negocio.

14

Requerimientos especiales

15

Notas.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

21 / 63

Ingeniera de requerimientos

Casos de uso

Casos de uso IV

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

22 / 63

Ingeniera de requerimientos

Casos de uso

Casos de uso V

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

23 / 63

Ingeniera de requerimientos

Casos de uso

Casos de uso VI

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

24 / 63

Ingeniera de requerimientos

Casos de uso

Casos de uso VII


Un diagrama de casos de uso es un diagrama de
comportamiento.
grafica

UML Lenguaje de Modelado Unificado define una notacion


para representar casos de uso llamada modelo de casos de uso.
NO confundir los diagramas de casos de uso con los casos de
uso.
entre los
Los diagramas de secuencias muestran la comunicacion

actores/sistema en terminos
de secuencias de mensajes.
grafica

Estos ultimos
son una descripcion
de la secuencia de

pasos en cada caso de uso.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

25 / 63

Ingeniera de requerimientos

Casos de uso

Casos de uso VIII

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

26 / 63

Ingeniera de requerimientos

Casos de uso

Casos de uso IX

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

27 / 63

Modelado del sistema

Modelado del sistema I

El modelado del sistema es el proceso que se lleva a cabo para


abstractos de un sistema.
hacer disenos
modelos para sistemas existentes
Es posible disenar
-describiendo sus fortalezas y debilidades- y para nuevos
sistemas.
grafica

Generalmente se utiliza algun


como la
tipo de notacion
UML.
UML utiliza al menos 14 tipos de diagramas diferentes.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

28 / 63

Modelado del sistema

Modelado del sistema II


UML surgio en la decada de los 90s y fue desarrollado por Grady
Booch, Ivar Jacobson y Jim Rumbaugh de Rational Software
-comprado por IBM en 2003-.
En 1997 fue adoptado por la OMG Object Management Group y
en el 2000 por ISO International Organization for Standardization.
denominada UML 2.
En 2004 aparecio una nueva version
de UML.
En 2005 la OMG adopta la nueva version
Se puede distinguir entre cuatro tipos de modelos: estructurales,
y de contexto.
de comportamiento, de interaccion

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

29 / 63

Modelado del sistema

Modelos estructurales

Modelos estructurales I

de un sistema en
Un modelo estructural muestra la organizacion

terminos
de sus componentes y las relaciones entre estos.

Se clasifican en estaticos
y dinamicos:

del sistema.
Estaticos:
Muestran la estructura del diseno

del sistema cuando se


Dinamicos:
Muestran la organizacion
ejecuta.

la arquitectura del sistema.


Son creados al momento de disenar

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

30 / 63

Modelado del sistema

Modelos estructurales

Modelos estructurales II

Diagramas estructurales I
Diagramas de clase: describen la estructura de un sistema,
mostrandos las clases que componen al sistema, sus atributos y
las relaciones entres estas.
Diagramas de componentes: describen los componentes
principales del sistema y las dependencias entre estos.
Diagramas de estructuras compuestas: describen la estructura
interna de una clase y las colaboraciones que su estructura hace
posible.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

31 / 63

Modelado del sistema

Modelos estructurales

Modelos estructurales III

Diagramas estructurales II
Diagramas de despliegue: describen el hardware utilizado para

las implementaciones del sistema y los entornos de ejecucion


utilizados sobre tal hardware.
Diagramas de objetos: muestran una vista de la estructura de un
ejemplo que ocurre en determinado momento.
logica

Diagramas de paquetes: muestran una division


del
sistema a un nivel superior que los diagramas de componentes.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

32 / 63

Modelado del sistema

Modelos de comportamiento

Modelos de comportamiento I

Un modelo de comportamiento es un modelo dinamico.


Muestra lo que debe ocurrir cuando un sistema responde ante un
estmulo -datos o eventos-.
Un modelo dirigido por datos muestra la secuencia de acciones
derivadas del procesamiento de la entrada y la respectiva salida.
Un modelo dirigido por un evento se basa en los estados por los

que el sistema puede atravesar y como


un evento puede causar la
entres estados.
transicion

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

33 / 63

Modelado del sistema

Modelos de comportamiento

Modelos de comportamiento II
Diagramas de comportamiento
Diagramas de actividades: describen los flujos del proceso del
negocio paso a paso (diagrama de flujo).
Diagramas de estado: describen los estados por los que puede
atravesar el sistema.
Diagramas de casos de uso: describen la funcionalidad del

sistema en terminos
de sus actores.
se enfocan en el flujo del control y de
Diagramas de interaccion:
los datos de las cosas que estan siendo modeladas en el sistema.

De comunicacion
De secuencia

De resumen de la interaccion
De tiempo

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

34 / 63

Modelado del sistema

Modelos de interaccion

I
Modelos de interaccion
implican todas las posibles
Los modelos de interaccion
interacciones en el sistema.
Ejemplos son:
Entradas de datos proporcionadas por los usuarios hacia el
sistema.
Interacciones entre el software a desarrollar y otras aplicaciones.
Interacciones entre los componentes del propio sistema.

Estan directamente implicados los casos de uso, pues


a diferente nivel de detalle las interacciones en el
presentaran
sistema.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

35 / 63

Modelado del sistema

Modelos de interaccion

II
Modelos de interaccion

Diagramas de interaccion
muestran las interacciones entre
Diagramas de comunicacion:
los diagramas de clases, de secuencias y de casos de uso.
es un resumen de los
Diagrama general de interaccion:

diagramas de comunicacion.
Diagramas de secuencia: muestran como se comunican los

objetos en terminos
de mensajes.
Diagramas de tiempo son diagramas de secuencia pero
basados en las restricciones de tiempo.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

36 / 63

Modelado del sistema

Modelos de contexto

Modelos de contexto I
Un modelo de contexto define la frontera de un sistema.
Se debe de especificar -con ayuda del cliente/usuarios- la nueva
funcionalidad que aportara el sistema creado y la ya existente en
el entorno donde se incorporara el nuevo software.
Un modelo de contexto no necesariamente muestra el tipo de
con los otros sistemas, pero tales relaciones pueden ser:
relacion
De intercambio de datos.
de servicios.
De comparticion

Dentro de los modelos de contexto se encuentran los de contexto


simple.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

37 / 63

Modelado del sistema

Modelos de contexto

Modelos de contexto II
muestra el sistema a
Un modelo de contexto simple solo
desarrollar y los sistemas de su entorno.

de pacientes.
Figura : Sistema de informacion

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

38 / 63

Modelado del sistema

Modelos de contexto

Modelos de contexto III


Un modelo de contexto empresarial describe los procesos
humanos y automatizados que se usan en sistemas particulares.

involuntaria de pacientes.
Figura : Proceso de detencion

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

39 / 63

orientado a objetos
Diseno

orientado a objetos I
Diseno

Un sistema orientado a objetos esta formado por objetos que

poseen un determinado estado y este


permite operaciones sobre
si mismo.
El estado del objeto debe estar encapsulado de modo que no se

pueda acceder directamente a el.

Los objetos son creados dinamicamente


a partir de definiciones
de clase.
es que el cambiar el diseno
de
La ventaja en este tipo de disenos
un objeto o agregarle servicios, no afectara a otros objetos.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

40 / 63

orientado a objetos
Diseno

orientado a objetos II
Diseno
realizar un mapeo entre las entidades del
Es relativamente facil
parte del sistema.
mundo real y los objetos que formaran
orientado a objetos son:
Las etapas en el proceso de un diseno
Comprender y definir el contexto e interfaces del sistema.
la raquitectura del sistema.
Disenar
Identificar los principales objetos del sistema.

Desarrollar los modelos de diseno.


de la interfaz.
Especificacion

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

41 / 63

orientado a objetos
Diseno

Contexto e interacciones del sistema

Contexto e interacciones del sistema I

La primer etapa consiste en comprender las relaciones entre el


a y su entorno.
sistema que se disenar
Se deben delimitar las fronteras del sistema.
Se debe especificar la naturaleza de las relaciones.
1...1 1...n
El enfoque debe ser lo mas abstracto posible.
Aqu es donde se utiliza UML para modelar el contexto y las
interacciones del sistema, as como los casos de uso.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

42 / 63

orientado a objetos
Diseno

Contexto e interacciones del sistema

Contexto e interacciones del sistema II

meteorologica.

Figura : Contexto de un sistema para una estacion

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

43 / 63

orientado a objetos
Diseno

arquitectonico

Diseno

arquitectonico

Diseno
I

Los reultados de la etapa anterior sirven como base para disenar


la arquitectura del sistema.
debe ser combinada con los principios de diseno

Tal informacion

arquitectonico
de software.

Existen cuatro tipos de arquitecturas basicas:


En capas
Cliente servidor

Sergio Luis Perez


(UAM C UAJIMALPA)

De repositorio
De tubera y filtro

Curso de fundamentos de ing. de software

44 / 63

orientado a objetos
Diseno

arquitectonico

Diseno

arquitectonico

Diseno
II
Arquitectura en capas

En una arquitectura en capas los elementos del sistema estan


separados de modo que pueden ser modificados de forma
independiente.
Sin embargo las capas tienen una funcionalidad relacionada.
ser
Las capas inferiores representan a los servicios que podran
utilizados por las capas superiores.
Esta arquitectura se puede utilizar cuando el desarrollo se puede
dividir entre varios equipos de trabajo o cuando existe un
requerimiento de seguridad multinivel.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

45 / 63

orientado a objetos
Diseno

arquitectonico

Diseno

arquitectonico

Diseno
III

Ventajas
o cambio por completo de capas,
Permite la remodelacion
mientras se conserve la interfaz.
de capas que fortalezcan la funcionalidad de
Permite la insercion
la interfaz.
Desventajas

entre capas.
En la practica
es difcil hacer una separacion
El rendimiento suele ser bajo.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

46 / 63

orientado a objetos
Diseno

arquitectonico

Diseno

arquitectonico

Diseno
IV

Figura : Arquitectura en capas

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

47 / 63

orientado a objetos
Diseno

arquitectonico

Diseno

arquitectonico

Diseno
V
Arquitectura de repositorio
Esta arquitectura describe como son compartidos los datos
utilizados por un sistema.
En esta arquitectura los componentes no interactuan

directamente entre s, sino a traves del repositorio de datos.

Esta arquitectura se puede utilizar cuando se desarrollaran


grandes volumenes
que
sistemas que utilizaran
de informacion

deben ser perdurables.


pueden utilizarse en sistemas que seran
activados en el
Tambien
momento que sean agregados datos al repositorio.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

48 / 63

orientado a objetos
Diseno

arquitectonico

Diseno

arquitectonico

Diseno
VI
Ventajas
Los componentes pueden ser independientes y no necesaitan
saber de la existencia de otros.
en un mismo lugar, pueden crearse respaldos
Si los datos estan
con facilidad.
Los cambios hechos en un componente se pueden propagar
a traves
de la actualizacion
de los datos.
hacia los demas
Desventajas
a todo el sistema.
Los problemas en el repositorio afectaran

Es posible que haya ineficiencias en la comunicacion.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

49 / 63

orientado a objetos
Diseno

arquitectonico

Diseno

arquitectonico

Diseno
VII

Figura : Arquitectura de repositorio

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

50 / 63

orientado a objetos
Diseno

arquitectonico

Diseno

arquitectonico

Diseno
VIII

Arquitectura cliente-servidor
La funcionalidad del sistema se organiza en servicios, y cada
servicio es gestionado de forma independiente.
de servidores.
Los clientes acceden a dichos servicios a traves
accedidos
Se puede utilizar cuando los datos o servicios seran

desde diferentes ubicaciones geograficas.


Tambien se sugiere cuando la carga de un sistema es variable,
ser replicados.
pues los servidores podran

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

51 / 63

orientado a objetos
Diseno

arquitectonico

Diseno

arquitectonico

Diseno
IX
Ventajas
de una red.
Los servidores pueden ser distribuidos a traves
disponibles para
Es posible que funcionalidades generales esten
todos los clientes, por lo que no se tienen que realizar
implementaciones separadas.
Desventajas
El rendimiento es impredecible pues dependera de la carga de la
red y de cada sistema.
Si los servidores pertenecen a diferentes propietarios puede
haber problemas administrativos.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

52 / 63

orientado a objetos
Diseno

arquitectonico

Diseno

arquitectonico

Diseno
X

Figura : Arquitectura Cliente-Servidor

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

53 / 63

orientado a objetos
Diseno

arquitectonico

Diseno

arquitectonico

Diseno
XI
Arquitectura de tubera y filtro
En este tipo de arquitectura los datos fluyen de un componente a
otro para su procesamiento.
hacia
Cada componente suele realizar un tipo de transformacion
datos.
Se puede utilizar en actividades de procesamiento de datos,
donde las entradas se procesan en etapas separadas con el
objetivo de generar salidas relacionadas.

Los sistemas embebidos pueden ser disenados


bajo este tipo de
arquitectura.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

54 / 63

orientado a objetos
Diseno

arquitectonico

Diseno

arquitectonico

Diseno
XII
Ventajas
Esta arquitectura puede coincidir con la estructura de muchos
procesos empresariales.
Puede implementarse de forma secuencial o concurrente.
Desventajas
El formato para la transferencia de datos debe acordarse de
antemano.

Puede resultar difcil utilizar nuevos modulos


o realizar cambios
sobre los existentes si es que las estructuras de datos son
incompatibles.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

55 / 63

orientado a objetos
Diseno

arquitectonico

Diseno

arquitectonico

Diseno
XIII

Figura : Arquitectura de tubera y filtro

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

56 / 63

orientado a objetos
Diseno

de clases de objetos
Identificacion

de clases de objetos I
Identificacion
El objetivo es identificar los puntos escenciales sobre los objetos
clara de lo que se debe implementar.
para tener una idea mas
de los casos de uso sera de gran ayuda para
La especificacion
identificar los objetos y las operaciones del sistema.

Como
identificar las clases de objetos en un sistema orientado a
objetos?
-en lenguaje natural- del sistema
En base a la descripcion
considerar: sustantivos objetos y atributos, verbos
operaciones y servicios.
Realizar las definiciones de objetos en base a entidades tangibles
(roles, eventos, ubicaciones, unidades organizacionales).

Realizar un analisis
en base a escenarios.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

57 / 63

orientado a objetos
Diseno

Desarrollo de los modelos de diseno

I
Desarrollo de los modelos de diseno
del sistema revisados
Se realizan los modelos de diseno
previamente:
Estructurales De comportamiento

De interaccion
De contexto
importantes a considerar son:
Los modelos mas
Los estructurales. Objetivo: Representar los agrupamientos

logicos
de objetos en el sistema.
Los de secuencia. Objetivo: Ilustrar las secuencias de
interacciones de objetos.
Los de estados. Objetivo: Mostrar los cambios de estado de los
objetos en respuesta a sus eventos.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

58 / 63

orientado a objetos
Diseno

de la interfaz
Especificacion

de la interfaz I
Especificacion
de los componentes que seran

Una interfaz es una especificacion

utilizados entre los diferentes componentes del diseno.


El desarrollo de interfaces permite el desarrollo de los objetos y
subsistemas en paralelo.
de una interfaz proporciona la especificacion
del detalle
El diseno

de como interacturan los objetos del sistema.


en UML es similar al de las clases normales.
Su especificacion
de interfaz no debe incluir detalles de la representacion

Un diseno
de los datos.

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

59 / 63

orientado a objetos
Diseno

de la interfaz
Especificacion

de la interfaz II
Especificacion

Un mismo objeto puede tener muchas interfaces.


<<interfaz>>
Nombre-interfaz
metodo1 (arg1 , . . . , argn )
..
.
metodom (arg1 , . . . , argn )

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

60 / 63

orientado a objetos
Diseno

de la interfaz
Especificacion

de la interfaz III
Especificacion

Figura : Diagrama de clases con interfaces para un juego de poker


cliente-servidor

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

61 / 63

orientado a objetos
Diseno

de la interfaz
Especificacion

de la interfaz IV
Especificacion

de la interfaz GameInt en Java


Figura : Especificacion

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

62 / 63

orientado a objetos
Diseno

de la interfaz
Especificacion

de la interfaz V
Especificacion

de la clase Game
Figura : Implemetacion

Sergio Luis Perez


(UAM C UAJIMALPA)

Curso de fundamentos de ing. de software

63 / 63