Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Introduccin
1.1
1.2
Fases y pasos de la metodologa
1.2.1
Flujos dentro de cada ciclo de desarrollo
1.2.2
Fase Inicio
1.2.3
Fase de Elaboracin
1.2.4
Fase Construccin
1.2.5
Fase de Transicin
7
8
8
9
9
9
1.3
Fase Inicio
1.3.1
Obtencin del modelo del negocio
1.3.2
Definicin del alcance de la aplicacin
1.3.2.1 Identificacin de los involucrados
1.3.2.2 Formular el problema a resolver
1.3.2.3 Definicin de las facilidades del software
1.2.3.4 Definir los requisitos no funcionales
1.3.3
Confeccin de un prototipo de interfaz
1.3.4
Definicin de los casos de uso
1.3.4.1 Identificar los actores
1.3.4.2 Identificar los casos de uso
1.3.4.3 Describir los casos de uso
1.3.5
Seleccin de los casos de uso para cada ciclo
1.3.5.1 Identificacin del ncleo central de la aplicacin
1.3.5.2 Identificacin de los casos de uso del ncleo central de la aplicacin y los de cada ciclo
1.3.6
Analisis de factibilidad
1.3.6.1 Anlisis de la factibilidad econmica
1.3.6.2 Anlisis tcnico
1.3.7
Planificacin. Obtencin del cronograma general de la aplicacin
1.3.8
Balance de los artefactos
1.3.9
Revisin y completamiento de la documentacin
1.3.9.1 Obtencin del modelo del negocio
1.3.9.2 Definicin del alcance de la aplicacin
1.3.9.3 Requisitos no funcionales
1.3.9.4 Casos de uso
1.3.9.5 Anlisis de factibilidad
1.3.9.6 Cronograma general de la aplicacin
9
10
10
10
10
10
11
14
14
14
15
15
15
16
16
16
16
17
17
17
17
18
18
18
18
18
18
19
19
19
19
24
29
32
38
39
39
39
Fases
2.1
Flujo o disciplina de requisitos
2.2
Flujo o disciplina de anlisis
2.2.1
Obtencin de los casos de uso detallados
2.2.2
Definicin de las clases preliminares y de las asociaciones
2.2.3
Definicin del diagrama de clases del anlisis
2.2.4
Definicin de los diagramas de secuencia y asignacin de servicios o responsabilidades
2.2.3
Definicin de las operaciones de las clases
2.2.4
Balanceo de los artefactos
2.2.5
Revisin y completamiento de la documentacin
2.2.5.1 Paquetes de los casos de uso
2.3
Flujo o disciplina de diseo
2.1.1
Definicion de la arquitectura
2.1.1.1 Definicin del patrn de arquitectura
43
43
43
47
49
50
50
51
52
53
57
64
64
64
64
65
66
67
67
68
69
70
71
72
73
74
74
75
76
77
78
79
80
81
82
82
82
83
83
84
85
85
89
90
93
93
93
94
95
95
96
96
96
96
96
96
97
99
2.4.4.3
Manual de operacin
99
2.5
Disciplina o flujo de prueba
2.5.1
Prueba de validacin del software
2.5.2
Prueba del sistema
2.5.2.1 Prueba de recuperacin
2.5.2.2 Prueba de seguridad
2.5.2.3 Prueba de resistencia
2.5.2.4 Prueba de rendimiento
2.5.3
Balanceo de artefactos y planificacin del prximo ciclo
101
101
101
101
101
101
102
102
2.6
Fase de Transicin
2.6.1
Preparacin de condiciones
2.6.2
Implantacin o despliegue del sistema
2.6.2.1 Implantacin en Paralelo
2.6.2.2 Implantacin directa
103
103
103
103
103
BIBLIOGRAFA
105
es barato de construir
Entregas
Inicio
Iteracin
Preliminar
Iteraciones
Elaboracin
Construccin
Transicin
internas
externas
Figura 1 Iteraciones por fase recomendado para proyecto mediano. Para proyecto
pequeo la definicin de arquitectura puede hacerse en una sola iteracin.
A continuacin se define los flujos de procesos que incluye un ciclo de desarrollo:
1.2.1 Flujos dentro de cada ciclo de desarrollo
Anlisis: Incluye definir nuevos requisitos: funcionales y no funcionales. Refinar,
completar e incluir nuevos casos de uso. Se utiliza adems los diagramas de
actividad. Definir los diagramas de clases, de interaccin, de transicin de estado
de forma lgica sin incluir los elementos propios de la arquitectura definida ni los
elementos de los requisitos no funcionales. Se desarrolla adems el grafo de
navegacin.
Diseo: Modificar los diagramas de clases y de secuencia. Incluir interfaces a las
clases, paquetes y servicios Web. Incluir los elementos propios de la arquitectura
y de los requisitos no funcionales. Lo anterior tiene en cuenta a los elementos
propios de la aplicacin Web. Se modifica el resultado del analisis con la
aplicacin de patrones de diseo. Definicin de los componentes y su vinculacin
con las clases.
Implementacin: Se realiza la codificacin de lo diseado teniendo en cuenta la
distribucin por componentes. Se utilizan los estndares de codificacin
disponibles.
Prueba: Se realiza las pruebas contra requisitos y casos de uso definidos. Para
ello se utilizan los casos de prueba definidos previamente
1.2.2 Fase Inicio
Los pasos en esta fase son:
Definicin de los requisitos del sistema a nivel general (facilidades) de
manera de poder describir el alcance de la aplicacin.
Definicin de los casos de uso, solo registrar el resumen de cada uno
Estimacin de tiempo esfuerzo y costo mediante COCOMO II [Bohem]
Planificacin. Obtencin del cronograma general de la aplicacin
1.3.5.2
(4)
Leyenda
(1) Indica el Nombre del caso de uso
(2) Lista de los actores que participan
(3) Descripcin en un prrafo del proceso
(4) Nmero de las facilidades asociadas al caso de uso
1.3.9.5 Anlisis de factibilidad
Debe justificarse indicando costo, personal involucrado, esfuerzo requerido y
los beneficios tangibles e intangibles
1.3.9.6 Cronograma general de la aplicacin
Una tabla indicando fases y fechas acorde con el esfuerzo requerido
2 Fases
Las fases de la metodologa tal y como fueron identificadas anteriormente son
Inicio, Elaboracin, Construccin y Transicin. Cada una de las ultimas tres fases
se realiza de forma iterativa e incremental por lo que a continuacin se detallan los
flujos o disciplinas que se efectan en cada iteracin o ciclo. En cada iteracin o
ciclo se puede realizar los siguientes flujos o disciplinas:
Requisitos
Anlisis
Diseo
Implementacin
Prueba
2.1 Flujo o disciplina de requisitos
Se incluyen nuevas facilidades y/o casos de uso de acuerdo a los criterios
recibidos de la prueba del ciclo o iteracin anterior. Se deben someter a gestin de
cambios puesto que las facilidades y casos de uso definidos en inicio fueron
sometidos a gestin de configuracin..
2.2 Flujo o disciplina de anlisis
En el flujo de anlisis orientado a objetos se examinan los requisitos desde la
perspectiva de las clases y los objetos encontrados en el dominio del problema.
Los pasos que se proponen son:
1. Obtencin de los casos de uso detallados
2. Definicin de las clases y de las asociaciones
3. Definicin del diagrama de clases del anlisis
4. Definicin de los diagramas de secuencia
5. Balance de los artefactos
2.2.1 Obtencin de los casos de uso detallados
La obtencin de los casos de uso detallados implica profundizar en el
conocimiento del problema a resolver. Para estructurar mejor los casos de uso se
recomienda dividirlos en partes que se llamaran subsistemas preliminares de
manera que sea mas fcil su entendimiento para ello se utilizan los paquetes.
Definicin de paquetes
La clasificacin de casos de uso por subsistemas preliminares da una agrupacin
de casos de uso en paquetes.
La definicin de los subsistemas preliminares se realiza en base a un anlisis de
la funcionalidad manejada en cada caso de uso. Se agrupan en un mismo
subsistema a aquellos casos de uso que se correspondan con funcionalidades que
manejen la misma informacin o informacin similar.
Un paquete en un mecanismo de propsito general para organizar elementos en
grupos. En los paquetes se agruparan en esta fase los casos de uso, pero en el
diseo se agruparan diagramas de clases y en la construccin componentes de
software etc.
Un paquete se identifica por el smbolo mostrado en la figura 2.
Actor
Caso de uso
Flujo alternativo
Accin del actor
1 <accin 1 de un actor>
2 <accin 2 de un actor>
4 <accin 4 de un actor>
Por supuesto el llegar a ese nivel de detalle implica profundizar con los usuarios y
clientes a travs de tcnicas de recopilacin de informacin, debe adems utilizar
el prototipo luego de realizar el refinamiento de ste de forma sucesiva a medida
que va realizando el detalle de los casos de uso.
A continuacin se muestra un ejemplo de caso de uso detallado para el ejemplo
de transplantes renales:
Caso de Uso
Transplantar un rin
Actores Forense, mdico interno, cirujano, paciente
Resumen
Un rin es analizado por el forense, el cual lo enva a ciruga donde el equipo de
cirujanos solicita a medicina interna que les enve los datos de los posibles
receptores. Admisin se encarga de localizar a los receptores. Los cirujanos
valoran los receptores posibles y operan el paciente seleccionado. Toda la
informacin producto del transplante es guardada en el expediente del paciente y
en el registro de transplantes
Flujo principal
Accin del actor
1 Comienza cuando un rin
producto de un accidente llega a
medicina legal y el forense determina
que puede ser empleado en un
transplante
3 El mdico interno solicita al sistema
los 10 pacientes receptores posibles
para el rin dado
5 En Admisin se recogen
pacientes posibles receptores
los
7 Al iniciarse el transplante se
muestra a los cirujanos el historial
clnico del paciente a operar
9 Al terminar
registran
los
transplante
el
transplante se
resultados
del
Cl ie nteL inea
Pedido
(f ro m Ac to rs )
Clases Entidad
Usada para modelar informacin de larga duracin y usualmente persistentes.
Modela fenmenos o conceptos, es decir, objetos del mundo real o eventos. Los
valores de sus atributos y relaciones son actualizados por un actor con frecuencia.
La representacin grafica se muestra en la figura 6.
Cliente
Retiro
Cuenta
(f rom Actors)
Una clase por cada lugar fsico a recordar. Se refiere a los lugares fsicos
sobre los que el sistema necesita conocimiento. Por ejemplo, en el Sistema
de Control de Transporte se requiere informacin sobre los centros tursticos
incluidos en las programaciones de los viajes (distancia en km, provincia,
etc.). El centro turstico es una clase posible.
Una clase por cada unidad organizativa a recordar. Se refiere a las
unidades organizativas con las que el sistema interacta y sobre las cuales
se requiere tener informacin. Por ejemplo en el sistema de control del
transporte se requiere informacin sobre las subbases de transporte
existentes en el pas, siendo sta una posible clase
Una clase por cada transaccin a recordar. Para las transacciones del
negocio se puede definir clases as como para los detalles de transacciones
que usualmente se tienen. Por ejemplo: Venta es una clase preliminar por
tratarse de una transaccin y DetalleProdVenta es el detalle de la
transaccin Venta, tanto Venta como DetalleProdVenta son ambas clases
preliminares.
Clases de Control
Representa el comportamiento especfico de uno o varios casos de uso (si estn
fuertemente relacionados). Los objetos de estas clases controlan a otras o las
coordinan. Estas clases coordinan la actividad de otros objetos que implementan la
funcionalidad que delegan.
No todos los casos de uso requieren clase controladora. Si el flujo de evento en un
caso de uso esta relacionado solamente con un objeto entidad, una clase Frontera
puede hacer el caso de uso en cooperacin con la clase entidad. Estas clases
desacoplan los objetos de la clase interfaz de los objetos entidad haciendo el
sistema tolerante a cambios del contexto. Por estas razones desacopla el
comportamiento del Caso de uso de los objetos entidad hacindolos mas
reutilizables. La representacin grafica se muestra en la figura 7.
Pedido
Confirmacion de pedido
Cliente en Linea
Gestor de Pedidos
(f rom Actors)
Solicitud de productos
Factura
A es miembro de B
Por ejemplo: Piloto es miembro del Avin
A es subunidad organizativa de B
Por ejemplo: Mantenimiento es una unidad organizativa de Linea Aerea
A usa o dirige B
Por ejemplo: Piloto usa el Avin
A se comunica con B
Por ejemplo: Cliente se comunica con el Vendedor
A se relaciona con una transaccin B
Por ejemplo: Pasajero se relaciona con el Boleto
A es una transaccin que se relaciona con otra transaccin B
Por ejemplo: Boleto y Venta son ambos transacciones
A est contiguo a B
Por ejemplo: Asiento y Asiento
A es propiedad de B
Por ejemplo: Avin es propiedad de Lnea Area
A es anloga a B
Por ejemplo: Avin es anlogo a Aeroplano
A es un tipo de B
Por ejemplo: Avin es un tipo de Vehculo
Definicin de los atributos de las clases
Los atributos deben corresponderse con los necesarios para representar los
objetos del mundo real y no con componentes de software. Por ejemplo la clase
Rin no debe incluir un atributo Formato de impresin, ya que este se
corresponde con una caracterstica del software y no con el concepto Rin del
mundo real.
Reglas para la definicin de los atributos [Larman, 1999]:
1. Debe utilizarse como atributo todas las propiedades que tengan valores simples
asociadas. Ejemplo para la clase Paciente son atributos que se corresponden
con propiedades simples Nombre, edad, sexo, etc.
2. No debe utilizarse atributos complejos. Si se necesita en la definicin de una
clase un objeto como atributo, esto es una indicacin de que se requiere definir
una asociacin. Ejemplo: Paciente requiere tener la informacin del Rin
Donado. No debe utilizar un atributo de tipo Rin Donado sino una asociacin
entre Paciente y Rin Donado.
3. No debe utilizar atributos que sean llaves forneas. Si se necesita en la
definicin de una clase una llave fornea como atributo, esto es una indicacin
de que se requiere definir una asociacin. Ejemplo: Paciente requiere tener el
Cdigo del Mdico que lo atiende. Se debe utilizar una asociacin entre Paciente
y Mdico para garantizar esta informacin.
4. No debe utilizarse atributos no primitivos. No obstante si el concepto
correspondiente al atributo no primitivo no tiene suficiente importancia como para
mantenerlo como una clase independiente, se mantiene como atributo de la
clase. Un atributo no primitivo puede ser un cdigo que tiene varias secciones
diferentes o se asocian a l operaciones como la validacin o posee atributos
asociados a l o tiene una unidad de medida. Ejemplo: Si en la clase Paciente el
atributo Direccin se trata como una cadena de texto y no se asocia con otras
clases de forma independiente y slo se requiere como descripcin de Paciente
se debe tomar como un atributo.
2.2.3 Definicin del diagrama de clases del anlisis
Esta vista del sistema muestra los conceptos bsicos de ste: sus partes y
relaciones. Para ello se utiliza el diagrama de clases de la notacin UML de forma
simplificada. El diagrama de clases es la representacin mediante un grafo de las
clases y las asociaciones que la conectan mediante un grafo. Se utilizan las clases
y asociaciones definidas antes, esto puede hacerse a la vez, definiendo las clases
y asociaciones y atributos sobre el propio diagrama. Lo anterior suministra una
vista esttica del sistema.
En el diagrama de clases del analisis se representan:
Las clases preliminares
Las asociaciones entre stas
La multiplicidad o cardinalidad para cada asociacin
Los nombres para las clases y las asociaciones
Representacin de las clases preliminares
Las clases preliminares se representan mediante rectngulos. Se especifica el
nombre de cada clase. La notacin se muestra en la figura 8. El tipo de clase:
entidad, de control o frontera se indica como estereotipo de la clase y en un CASE
(Computer Aided Software Engineering) puede ser representada mediante iconos
como se represent anteriormente.
Rango
*
1
0..*
1..*
0..1
0..*
<<Interface>>
IClientes
<<Interface>>
ICatalogoCuentas
DevCuentas_SubCategoria()
Crear_Analisis_Subsistemas()
<<control>>
CClientes
Captar_DatosCliente()
Asociar_Cliente_Grupo()
Generar_Grupo()
Asociar_Cliente_Categoria()
Captar_Datos_Categoria()
Asociar_Cuentas_Cliente()
Seleccionar_Cuentas_Cliente()
Buscar_Cliente()
ModificarCliente()
Modificar_Categoria()
Buscar_Asociacion_Grupo()
Buscar_Cuentas_Grupo()
EGrupoCliente
IdGrupo : Single
Codigo : String
Descripcion : String
<<entity>>
EImpuestoCliente
CodImpuesto : String
Descripcion : String
Valor : Double
0..1
1
0..*
<<entity>>
EEmpresa
Nombre : String
Direccion : String
Email : String
Telefonos : String
Fax : String
Correo : String
Pais : String
Descripcion : String
CodigoPostal : String
Ciudad : String
Estado : String
SitioWeb : String
0..*
<<entity>>
EIncobrabilidadCliente
Antiguedad : Single
FechaTope : Date
<<entity>>
ECondPagoCobro
CodTipoPago : String
Dias : Single
Descuento : Byte
<<entity>>
ETipoPagoCobro
CodTipoPago : String
TipoPago : String
<<entity>>
ECategoriaCliente
0..*
<<entity>>
ERepresentante
Nombre : String
Apellidos : String
Cargo : String
1
<<entity>>
ACategoriaClienteProveedor
Codigo : String
Descripcion : String
IdTipoGrupo : Single
TipoGrupo : String
ECliente
1
Crear_Cliente()
Validar_Datos_Cliente()
Buscar_Cliente()
ModificarCliente()
factoryMethod()
AClienteProveedor
Codigo : String
Apellidos : String
Comentarios : String
Nombre : String
Direccion1 : String
Email : String
Telefonos : String
Fax : String
Correo : String
Pais : String
Descripcion : String
CodigoPostal : String
Ciudad : String
Id : Single
Estado : String
SitioWeb : String
Direccion2 : String
factoryMethod()
1..*
<<creates>>
1
AGrupoClienteProveedor
Codigo : String
Nombre : String
IdGrupo : Single
Descripcion : String
1
0..*
<<entity>>
EAnalisisCuentasGrupo
1..*
Crear_Analisis_Grupo()
Buscar_Cuentas_Grupo()
1
0..*
<<entity>>
EAnalisisCuentasCliente
<<entity>>
AAnalisis
Crear_Analisis_Cliente()
Buscar_Cuentas_ Cliente()
: <Actor Name>
: Clase 1
mensaje 1( )
: Clase 2
Objeto 3 : Clase
3
mensaje 2( )
mensaje 3( )
Enfatiza la
secuencia
Ciclo de vida
Foco
1: mensaje 1( )
: Clase 1
: <Actor Name>
3: mensaje 3( )
2: mensaje 2( )
: Clase 2
Objeto 3 : Clase
3
Inscribir_Categori...
Asociar_Cliente_Categoria( )
: C FC lientes
: IClientes
: CClientes
: ECategoriaCliente
Error_Datos_Categ...
Validar_Datos_Categori...
Crear_CategoriaClient...
Asociar_Cliente_Categoria(Clie...
Captar_Datos_Categori...
Inscribir_Categoria( )
Categoria_NoCr...
Asociar_Cliente_Categoria(Cliente)
Asociar_Cliente_Categoria(Clie...
Inscribir_Categori...
Validar_TipoDatos_Categori...
Asociar_ClienteACategori...
: FCategoriaCliente
(1)
(2)
(4)
(5)
Leyenda
(1) Indica el Nombre del caso de uso
(2) Lista de los actores que participan
(3) Resumen del caso de uso. Casi siempre coincide con la descripcin del caso de
uso no expandido
(4) Pasos numerado y secuenciales de las acciones del actor
(5) Pasos numerado y secuenciales de las acciones de respuesta del sistema al
actor. Existe una numeracin nica para actor y sistema.
2.2.5.3 Diagramas de casos de uso
Diagrama de caso de uso
Paquete
(1)
(2)
Leyenda:
(1) Deber ser colocado un nmero de acuerdo al formato siguiente:
DCU- ##
donde DCU significa Diagrama de Casos de Uso; y ##, es un nmero consecutivo
nico de identificacin para el paquete correspondiente al caso de uso.
(2) Deber ser colocada la representacin grfica del diagrama de casos de uso.
2.2.5.4 Diagrama de clases del anlisis
Puede tratarse de uno o varios diagramas
Diagrama de clases (1)
del anlisis
(2)
Leyenda
(1) Nombre del paquete o del caso de uso al que se asocia
(2) Diagrama correspondiente
2.2.5.5 Diccionario de datos
Clase: (1)
Significado: (2)
Nombre
del Descripcin
Tipo
Atributo
(3)
(4)
(5)
Leyenda
(1) incluido en el diagrama
(2) Significado del concepto o mediante una oracin simple o frase nominal
(3) Nombre del atributo asociada a la clase
(4) Significado del atributo
(5) Tipo de datos (caracteres, entero, real, alfabtico)
2.2.5.6
Diagramas de secuencia
Son varios diagramas
Diagrama de Secuencia del sistema
Paquete
(1)
(2)
Leyenda:
(1) Deber ser colocado un nmero de acuerdo al formato siguiente:
DSS- ##
donde DSS significa Diagrama de Secuencia del Sistema; y ##, es un nmero
consecutivo nico de identificacin para el paquete correspondiente.
(2) Deber ser colocada la representacin grfica del diagrama de Secuencia
2.2.5.7 Operaciones
Para cada operacin se describe:
Nombre:
Responsabilidades o mtodos:
Tipo:
Excepciones:
Precondiciones:
Postcondiciones
(1)
(2)
(3)
(4)
(5)
(6)
2.3
Cliente 1
Cliente 2
Cliente 3
Red de
comunicacion
Servido r de
catalogos
Servido r de
videos
Servi dor de
Fotografias
Hipertexto
Browser Cliente
Servidor de
Aplicacion
HTTP
Sistema de
ficheros
Capa Persistente
(BD)
Paginas
dinamicas
Paginas
Estaticas
Red de
trabajo
Web
Server
Server
Appli...
BD
Server
preemptive
HTML Browser
<thread name>
Pagina Web
Java Applet
DOM
HTTP
Invoca operacion()
Servidor de
Aplicacion
Servidor Web
Capa Persistente
(BD)
Red de
trabajo
Web
Server
Server
Appli...
BD
Server
preemptive
HTML Browser
<thread name>
HTTP
Browser Cliente
Servidor Web
Servido r BD
Servidor de
Aplicacion
Paginas Web
Servidor de
objetos remotos
RMI/DCOM
Red de
tra b...
Web Server
Server Application
Cliente
BD
Server
p ree mp tive
HTML Browser most ran do objet os remot os
Servidor de Objetos
rem otos
RMI/DC
OM
2 Enterprise Edition (J2EE) [Booch, 2003]. Las razones de seleccin de una u otra
son ms polticas y comerciales que tcnicas. Cada mini arquitectura da la
posibilidad de implementar un conjunto de patrones de arquitectura.
Estas mini arquitecturas se apoyan en distribuir las componentes de la aplicacin
en capas, siendo usual la existencia de modelos de tres o ms capas en la
actualidad.
Las capas son agrupaciones lgicas de los componentes de software que
constituyen una aplicacin o negocio
1. Ayudan a diferenciar entre la clase de tareas desarrolladas por las
componentes
2. Hacen fcil el diseo de la reusabilidad
Cada capa contiene un nmero de componentes agrupados en subcapas y cada
subcapa realiza un tipo de tarea. Una distribucin por capas seria la propuesta en
la figura 23, la que se corresponde con la de .NET
Usuarios
Servicio
de
llamadas
Presentacin
Negocio
Datos
BD
Servicios
Interfaz Usuario
Interfaz tradicional
Lgica del
negocio
Componentes del
negocio
Interfaz Web
Flujos de proceso del
negocio
Controlador de
interfaz
Acceso a los
datos
Logica de acceso a
los datos
Agentes de
servicios
Componentes de
entidades del negocio
<<subsystem>>
Clientes
<<subsystem>>
WS Producto
<<subsystem>>
Cuenta por
Cobrar
<<subsystem>>
WS Cliente
Interfaz Web
Control del
negocio
Clases del
negocio
Typed Dataset
Acceso a los
datos
Agentes de
Servicios
Cdigo
Cuenta
<<subsystem>>
Caja
<<Interface>>
Fluj o
Pgina en el cliente
Formulario
Pgina en el servidor
<<Client Page>>
Busqueda
<<Client Page>>
Home
<<li nk>>
IdProducto
<<build>>
<<Client Page>>
DetalleProducto
C ronogramaA ula
C alendario
D ia : String
Aula : String
D ia : Integer
Mes : Integer
ao : Integer
cal
ActualizaActividad()
AdicionaEvento()
Elim inaEvento()
EventoReunin
0..*
Tem a : Str in g
FechaInicio : D ate
FechaFin : D ate
H oraInicio : Tim e
H ora Fin : Ti m e
R es um en()
C onflictos ()
AdicionaPart()
Elim in aPart()
P artici pante
0..*
N om bre : String
Tittulo : String
Em ail : String
Telefono : String
R es um en()
DetalleEvento
<<Text> > Tem a : String
<<s elect>> Participantes : String
<<Subm it>> Actual iza : Str in g
<<Subm it>> Elim ina : String
<<Subm it>> N uevo : String
<<C heckbox>> Todos D ias : Boolean
CarritoEnLnea
Item
0..*
ActualizaCarrito
FormCarrito
<<redirect>>
Check out()
SubTotal()
Tax()
Envio()
Total()
<<Server Page>>
ProcesaError
(f rom Clases del dis eo)
{Paramtro=NoError,Descripcion}
ValidarIU-W
ValidacionPaginaVer = "125"
Es-Valida-Pagina = true
Submit-Pagina = false
MiPagina.cs
Validar-ActDisplay()
Validar-Act Es Valida()
Validar -Control-ConexionId()
Validar-DameValor()
Validar-DameValorRecursivo()
<<Include>>
<<Build>>
MiPagina.ASPX
MiPagina.HTML
PorDefecto()
IniciaComponente()
IniciaPagina()
CargaPagina()
<<Submit>>
Principal
Campos Entrados
Valores-Definidos.NET
Mdico
Cirujano
Opera a
Operado
Paciente
PacienteComp
RionDonado
Transplante
Paciente
Poligono
Circulo
Estilo
Rion
0..1
Eliminado: <sp><sp><sp>
<sp><sp><sp><sp>
Su nombre aparece en
letra cursiva
Clase Abstracta
Subclase 1
Subclase 2
Rion
RionDonado
RionDonante
RionPaciente
al espacio y el tiempo. En ste punto hay que clasificar las clases en persistentes o
temporales en dependencia de si es de inters o no para la aplicacin que se
desarrolla, que sus objetos sean almacenados en un medio persistente. La
definicin de clases persistentes permite la obtencin de la base de datos. Si sta
es orientada a objetos no hay que hacer ninguna otra definicin. En caso de que la
base de datos no sea orientada a objetos en fases posteriores del diseo se
incluyen las clases necesarias para la interfaz con el sistema de gestin de base de
datos.
Debe definirse si las clases concurrentes (autnomas) o secuenciales. Deben
definirse las clases genricas (clases que permiten desarrollar los mtodos
teniendo como parmetros a objetos que se corresponden con una jerarqua de
clases de generalizacin-especializacin) as como los parmetros de stas.
Reglas para construir buenas asociaciones generalizacin-especializacin
Despus de construida las jerarqua de generalizacin-especializacin se analiza
de acuerdo a los siguientes criterios:
Modelar una jerarqua es un tipo de.
Asegurar que las clases abstractas no hereden de las reales.
Eliminar las clases abstractas que no agreguen funcionalidad.
Delimitar la herencia mltiple de la agregacin
Evitar generalizaciones anidadas profundas
Modelar una jerarqua es un tipo de
Debe asegurarse que la subclase soporte todas las responsabilidades definidas
para sus superclases. Asegurar esto es una forma de hacer las clases ms
reusables, porque es fcil ver donde una nueva clase debe ser colocada en la
jerarqua.
Cuando el comportamiento de la subclase incluye slo una parte de las
responsabilidades definidas por su superclase, se debe crear una clase abstracta
con todas las responsabilidades comunes a la clase y superclase de la cual
hereda.
Asegurar que las clases abstractas no hereden de las reales
Las clases abstractas se caracterizan por soportar sus responsabilidades
independientemente de su implementacin. Por esta razn no deben heredar de
las reales que dependen de la implementacin. Si una clase abstracta debe
heredar alguna responsabilidad de alguna concreta, se resuelve la contradiccin
creando una nueva clase abstracta de la que hereden las dos anteriores.
Eliminar las clases que no agregan funcionalidad
Las clases abstractas que no definan responsabilidad deben eliminarse.
Delimitar la herencia mltiple de la agregacin
La herencia mltiple puede confundirse con la asociacin de agregacin. Utilizar la
agregacin para representar la herencia mltiple es una mala decisin de diseo.
Una clase 1 hereda de una clase 2 si las instancias de la clase 1 pueden
PacienteNoOperado
PacienteOper
ado
Paciente
Solucin intil
Los objetos cambian
de subtipos en
ejecucin
Estado
*
EstadoNoOpe
rado
EstadoOper
ado
Solucin til
Coleccin
A
Patrn Adaptador
Patrn Composicin
Patrn Decorador
Patrn Fachada
Patrn Proxy
Patrn Comando
Patrn Mediador
Patrn Estado
Patrn Estrategia
Patrn Plantilla
Patrn Transaccin
Patrn Modelo del dominio
Patrn Record set
Patrn Gateway
Patrn Mapper
Patrn Mdulo Tabla
Patrn Objeto de Transferencia de Datos (DTO)
Patrn Assembler
Pago
Monto
Crear()
Autorizar()
PagoEfectivo
PagoCheque
PagoTarjeta
Autorizar()
Autorizar()
Autorizar()
AgenteAlmacenamie nto
Persi stente
guardar()
Figura 45 Ejemplo del patrn Fabrica Abstracta. La venta conserva alta cohesin y
bajo acoplamiento. La clase AgenteAlmacenamientoPersistente es un objeto
genrico y reutilizable
2.3.5.3
Problema
Patrn Indireccin
ServicioAutorizacionCredito
NroTarjeta
Marcar()
Recibir()
Enviar()
Tambien
llamada Proxy
porque
representa un
dispositivo
electromecanico
Subject
Observer
Attach()
Detach()
Notify()
update()
for all O in
Observers
{O->Update()
ConcreteOb server
Con creteSubj ect
GetState()
SeytState()
Return State
Subject
Update()
ObserverState()
ObserverState=Subject>GetrState
Ven ta
MetododePago()
TerminarVenta()
IntroducirProducto()
EfectuarPago()
Pago
fecha
hora
EstaTerminad a
TPDV
Captura
PagadoPor
MontoOfrecido
MontoOfrecido()
Term inarVenta()
Intro ducirProducto()
EfectuarPago()
opname()
pago()
Tota l()
: TPDV
: <Actor Name>
imp:=MetododePago
: Venta
: Pa go
pag:=Pago
imp:=MontoOfrecido
Pago es un
extrano para
TPDV
Viola el
patron
: <Actor Name>
Imp:=MontodePago
: TPDV
Imp:=MontodePago
: Venta
: Pago
Imp :=MontoOfrecido
Solucin
Define una interfaz para crear un objeto, pero permite a las subclases decidir
la clase a crear: creacin diferida a las subclases.
Tambin conocida como Constructor Virtual. Dos abstracciones claves son las
clases Aplicacin y Documento. Ambas clases son abstractas, y clientes, tienen a
subclases para realizar sus implementaciones especificas a la aplicacin. Como la
particular subclase Documento a crear es especifica de la aplicacin, la clase
Aplicacin no puede predecir la subclase de Documento a crear (la clase
Aplicacin solo conoce cuando un nuevo documento debe ser creado, no cual
clase de Documento crear). La figura 51 presenta la estructura de este patrn.
<<Abstract>>
Documento
Abrir()
Cerrar()
Salvar()
Revert()
<<Abstract>>
Aplicacion
CrearDocumento()
NuevoDocumento()
AbrirDocumento()
MiAplicacion
MiDocumento
CrearDocumento()
Documento d
d: crear
Documento
set doc.ad d(d);
d:Abrir
Metodo
Factoria
Return New
Mi Docum ento
Metodo de clase de
singleton
$Instancia()
metodo de clase
TPDV TPDV--Instanci a()
{
if (Insta ncia==NIL )
Instancia=n ew TPDV
Re turn Instancia
}
ElementoGrafico
Editor
marco()
crearManipulador()
return text.getExtension
ElemLinea
ElemTexto
marco()
crearManipulador()
marco()
crearManipulador()
+texto
TextView
getExtension()
Linea
dibujar()
Rectangulo
FiguraCompuesta
dibujar()
dibujar()
add(Figura)
remove(Figura)
getHijo(int)
CompConcreto
Decorator
operacion()
DecoratorConcrA
estadoAdicional
operacion()
operacion()
+componente
componente.operacion
DecoratorConcrB
estadoAdicional
operacion()
comportAdicional()
super.operacion;
comportAdicional
nica forma
Fachada
<<abstract>>
Sujeto
Cliente
(from flyweight)
operacion()
SujetoReal
operacion()
Proxy
+sujeto
sujeto.operacion()
operacion()
Aplicacion2
Menu
add(Document)
MenuItem +command
add(MenuItem)
Command
clicked()
ejecutar()
Cut
command.execute()
Paste
execute()
Document
execute()
+document
open()
close()
cut()
copy()
paste()
document.paste
Widget
+director (from Logical View)
showDialog()
createWidgets()
widgetChanged(Widget)
FontDialogDirector
director.WidgetChanged(this)
changed()
+list
createWidgets()
widgetChanged(Widget)
ListBox
getSelection()
+field
EntryField
setText()
:Cliente
:FontDialogDirector
:ListBox
:EntryField
showDialog
widgetChanged
getSelection
setText
TCPState
+state
open()
close()
acknowledge()
open()
close()
acknowledge()
TCPEstablished
open()
close()
acknowledge()
state.acknowledge()
TCPListen
open()
close()
acknowledge()
TCPClosed
open()
close()
acknowledge()
+state
solicitud()
State
operacion()
StateConcr1
StateConcr2
operacion()
operacion()
state.operacion()
Composicion
+algoJustif
recorrer()
formato()
Justificacion
justificar()
JustificacionSimple
JustificacionTeX
justificar()
justificar()
algoJustif.justificar
Estrategia
+estrategia
InterfaceContexto()
algoritmoInterface()
EstrategiaA
algoritmoInterface()
EstrategiaB
algoritmoInterface()
: <Actor Name>
Un servicio de reconocimiento :
ServicioReconocimiento
Un Data Gateway :
Data GateWay
GetData( )
InsertReconocimientoIngreso( )
: <Actor Name>
: Contrato
: Producto
CalcularRecono(UnContrato)
: EstrategiaReconocimiento
CalcularRec(UnContrato)
:
Reco noci mientoIn greso
New
Record set
Tabla
Colum na
Gateway
Tasa cion
Tasacion
Paquete
Activo
Persona
Get exemptions()
Insert()
Actu ali za()
: Contrato
: <Actor Name>
: Producto
: Reconoci miento de
ingreso
UnCliente
:
CompradorDTO
: Comprador
DameCompradorDTO()
Create
: Contrato
: <Actor Name>
: Producto
: Reconoci miento de
ingreso
DameTitulo
New(The
Data Set)
DamePrimerApellido
DameSegApellido
New(The DataSet)
GetTi poProducto(ProductoID)
Insert
AlbumAssemb
ler
ToXMLElemento()
LeeXML()
Album
Titulo
Artista
Nombre
transita un objeto. Para ello antes hay que clasificar los atributos de las clases,
teniendo en cuenta la forma y las causas por las que toman valor en el tiempo, en:
Atributo esttico: no cambia de valor en el tiempo por lo tanto no puede ser
actualizado. El nico evento que lo afecta es el que provoca la creacin de la
clase que como consecuencia le da valor.
Atributo dinmico: a diferencia de los atributos estticos, los dinmicos se
reconocen porque son afectados por otros eventos que son los que hacen que
cambie de valor.
Atributos derivados: cambian cuando cambian otros atributos. Estos otros
atributos integran la frmula de derivacin y pueden pertenecer o no a la clase a la
que pertenece el atributo derivado. Los SGBD, cuando cambia alguno de los
atributos que forman la frmula, deben automticamente disparar el reclculo del
valor derivado.
En un diagrama de transicin de estado se representan:
Los estados
Los eventos
Las transiciones
Las acciones
Estado: El estado de un objeto es una de las posibles situaciones en la cual un
objeto puede existir y representa una combinacin de todas las propiedades de un
objeto. Las actividades a desarrollar en el estado requieren de un tiempo de
realizacin y pueden tener asociadas restricciones de integridad, que son reglas
que especifican restricciones y requisitos que debe afectar tanto a la estructura
como al comportamiento de los objetos de una clase y deben ser tratados en
mtodos de la clase. Los estados se representan grficamente mediante un
rectngulo con las esquinas redondeadas. Un ejemplo se muestra en la figura 74.
Se incluye un estado inicial para indicar la creacin del objeto y que
automticamente pasa a otro estado, es obligatorio y se representa por un crculo
slido. El estado final indica el fin de vida de un objeto, es opcional, puede existir
mas de uno y se representa por un crculo slido circulado. El estado final se
corresponde con la destruccin del objeto de la clase. En la figura 75 se representa
la notacin. Una actividad es una operacin que toma tiempo completarla, se
asocia a los estados y comienza al entrar en un estado y puede ejecutarse hasta
concluirse o puede ser interrumpida por una transicin entrante. En la figura 76 se
muestra un ejemplo.
Clase: Consulta
AdicionarPaciente
Cancelar
ConsultaAbierta
ConsultaCancelada
Estado
AdicionarPaciente
Creacion
AbrirRegistro/NumPaciente a 0
Creada
ConsultaAbierta
CerrarRegistro[ Numero>=20 ]
ConsultaCompleta
Componente 1
Interface
Dependencia
Componente 2
Producto.dll
Producto
Cotizacion
Producto
Orden.dll
Orden
Direccion del
envio
Linea de Item
Lgica de la aplicacin
Almacenamiento
(1)
(2)
(3)
Leyenda
(1) Identificacin mediante el nombre de la clase
(2) Diagrama correspondiente
2.3.10.3 Definicin de las clases
Nombre: (1)
Atributo
(2)
(2)
Para cada responsabilidad:
Nombre:
Descripcin:
Tipo:
Referencias cruzadas:
Notas
Excepciones:
Precondiciones:
Postcondiciones
Tipo
(3)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
2.4
d.
e.
Deberes y derechos (tanto del usuario como del productor del software)
que deben estar sujetos a acuerdos entre las partes contractuales, los
cuales pueden estar influenciados por la legislacin y por las normas
nacionales e internacionales vigentes.
f.
g.
h.
i.
III. Instalacin.
Este epgrafe procede en caso de que usuario y operador coincidan. Verse al
manual de instalacin.
IV. Iniciacin.
Consta de la siguiente informacin:
a. Comienzo. Pasos iniciales para dar inicio a la utilizacin del software,
por ejemplo el procesamiento de la informacin antes del tratamiennto
automatizado, el procedimiento de carga, etc.
b. Modo de ayuda, descripcin de como se puede obtener ayuda
referente a la utilizacin del software.
c. Documentacin de referencia. Recomendacin en caso necesario de la
consulta de cualquier material impreso que posibilite completar los
conocimientos de los mtodos, algoritmos, etc. utilizados en el
software.
V. Utilizacin.
Slo procede en caso de usuario y operador coincidan.
operacin.
VI. Entrenamiento.
Verse el manual de
Instrucciones precisas sobre como usar las opciones o comandos que brinda el
software.
Para el caso de los comandos debe incluirse:
a. Propsito, orden, sintaxis y posibles parmetros y valores implcitos.
b. Relacin de comandos y su descripcin.
Para el caso de las opciones debe incluirse:
a. Dilogos que se establecen o mensajes informativos.
b. Exposicin de las pantallas de entrada y salida de informacin asociadas a
las diferentes opciones.
III. Tratamiento de los errores.
Forma de manipulacin de todos y cada uno de los errores posibles que puedan
presentarse durante la utilizacin del software.
IV. Recuperacin de los fallos.
Procedimientos para resolver los problemas que puedan presentarse durante la
utilizacin del software y la explicacin de la forma de reiniciar el trabajo.
solicitudes de cambio del usuario los que pueden hacerse como parte del
mantenimiento del sistema.
Bibliografa
[Alvarez, 1995]
[Alvarez, 2000]
[Boar, 1984]
[Boehm, 1981]
[Boehm]
[Booch, 1994]
[Booch, 1997]
[Booch, 2003]
[Booch, 1999]
[Budd, 1994]
[Carming, 1989]
[Coad, 1990]
[Coad, 1991]
[Coleman, 1992]
[Conallen, 2002]
[Connell, 1989]
[Coplien 96]
[Currie, 1998]
[Fowler, 1998]
[Fowler, 2002]
[Gamma]
[Johnson, 1988]
[Kruchten, 1999]
[Larman, 1999]
[Microsoft]
[Miller, 1956]
[Norma 19112]
[OMG]
[Schmauch, 1994] Schmauch, C. H., ISO 9000 for Software Developers, ASQC
Quality Press, Milwaukee, WI., 1994
[Pressman, 2002]
[Rising 98]
[Wirfs, 1990]