Etapas

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)
2 / 63
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
3 / 63
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)
4 / 63
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)
5 / 63
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)
6 / 63
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)
7 / 63
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)
8 / 63
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)
9 / 63
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)
10 / 63
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)
11 / 63
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)
12 / 63
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
13 / 63
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)
14 / 63
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)
15 / 63
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)
16 / 63
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)
17 / 63
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)
18 / 63
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)
19 / 63
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)
20 / 63
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)
21 / 63
Casos de uso
Casos de uso IV
Sergio Luis Perez

(UAM C UAJIMALPA)
22 / 63
Casos de uso
Casos de uso V
Sergio Luis Perez

(UAM C UAJIMALPA)
23 / 63
Casos de uso
Casos de uso VI
Sergio Luis Perez

(UAM C UAJIMALPA)
24 / 63
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)
25 / 63
Casos de uso
Casos de uso VIII
Sergio Luis Perez

(UAM C UAJIMALPA)
26 / 63
Casos de uso
Casos de uso IX
Sergio Luis Perez

(UAM C UAJIMALPA)
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)
28 / 63
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)
29 / 63
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)
30 / 63
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)
31 / 63
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)
32 / 63
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)
33 / 63
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)
34 / 63
Modelos de interaccion
I
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)
35 / 63
II
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)
36 / 63
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)
37 / 63
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)
38 / 63
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)
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)
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)
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)
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)
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
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)
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)
46 / 63
orientado a objetos
Diseno
arquitectonico
Diseno
arquitectonico
Diseno
IV
Figura : Arquitectura en capas
Sergio Luis Perez

(UAM C UAJIMALPA)
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)
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)
49 / 63
orientado a objetos
Diseno
arquitectonico
Diseno
arquitectonico
Diseno
VII
Figura : Arquitectura de repositorio
Sergio Luis Perez

(UAM C UAJIMALPA)
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)
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)
52 / 63
orientado a objetos
Diseno
arquitectonico
Diseno
arquitectonico
Diseno
X
Figura : Arquitectura Cliente-Servidor
Sergio Luis Perez

(UAM C UAJIMALPA)
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)
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)
55 / 63
orientado a objetos
Diseno
arquitectonico
Diseno
arquitectonico
Diseno
XIII
Figura : Arquitectura de tubera y filtro
Sergio Luis Perez

(UAM C UAJIMALPA)
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)
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)
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)
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)
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)
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)
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)
63 / 63

Etapas

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Etapas

Загружено:

Авторское право:

Доступные форматы

Fundamentos de Ingeniera de Software [Etapas]

M. en C. Sergio Luis Perez

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

Sergio Luis Perez

Curso de fundamentos de ing. de software

Los requerimientos para un producto de software o en general un

sistema son descripciones del servicio que este

proporcionar, as como de sus restricciones de operacion.

Sergio Luis Perez

Curso de fundamentos de ing. de software

Requerimientos del usuario

Describen las restricciones de operacion.

Sergio Luis Perez

Usuarios finales del sistema

Curso de fundamentos de ing. de software

Ingeniera de requerimientos III

Requerimientos del sistema

restricciones operacionales del sistema que se implementaran.

Sergio Luis Perez

Curso de fundamentos de ing. de software

del requerimiento del usuario

Sergio Luis Perez

Curso de fundamentos de ing. de software

medicamentos prescritos, su costo y las clnicas que los

El sistema elaborara automaticamente

disponibles en diferentes dosis se

Sergio Luis Perez

Curso de fundamentos de ing. de software

Describen los servicios que el sistema debe proveer.

Se describen desde funciones generales hasta funciones mas

Sergio Luis Perez

Curso de fundamentos de ing. de software

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

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

Cada usuario del sistema debera identificarse con su nombre de

Sergio Luis Perez

Curso de fundamentos de ing. de software

Sergio Luis Perez

Curso de fundamentos de ing. de software

Requerimientos del producto

Sergio Luis Perez

Curso de fundamentos de ing. de software

Requerimientos no funcionales III

Se derivan de las polticas y procedimientos en la organizacion

Operacionales. Definen como

De desarrollo. Definen el lenguaje de programacion.

Sergio Luis Perez

Curso de fundamentos de ing. de software

Sergio Luis Perez

Curso de fundamentos de ing. de software

Sergio Luis Perez

Sergio Luis Perez

Curso de fundamentos de ing. de software

se describe la estructura que debe poseer el

Sergio Luis Perez

Curso de fundamentos de ing. de software

El documento de requerimientos III

Finalmente describe como

Sergio Luis Perez

Curso de fundamentos de ing. de software

Se especifican los modulos

Se deben describir las funciones de cada modulo.

Se debe especificar cuales

Sergio Luis Perez