a Objetos
Texto Preparado para los Alumnos del CFT Simn Bolvar
Revisado - 2012
Diseo Orientado a Objetos
En Tecnologa Orientado a Objetos (TO) a los conceptos se les llama objetos, en consecuencia, los OBJETOS son
MODELOS de entes del mundo real. Los percibimos porque tienen lmites que los esperan de su medio ambiente y de
los dems (IDENTIDAD). Se encuentran en un ESTADO especfico en el mundo.
Un objeto puede ser concreto (material)o abstracto (inmaterial), simple o complejo; pero siempre estar compuesto de
DATOS y OPERACIONES.
Continuando con el desarrollo de la estructura del pensamiento, encontraremos que aproximadamente a partir de los siete
aos, en la denominada etapa de las operaciones concretas, el ser humano aprende a CLASIFICAR (separar y agrupar
objetos de acuerdo a caractersticas y comportamientos comunes) y ORDENAR (establecer criterios de jerarqua que
permitan la organizacin).
La clasificacin es un medio por el cual organizamos el conocimiento.
Clasificar y ordenar es una consecuencia de la capacidad de interiorizar esquemas representativos (MODELOS), los
cuales permiten: por un lado, reconocer si un concepto (OBJETO) tiene o no las caractersticas de dicho esquema; y por
otro, incorporarlo o no en el conjunto de los que comparten ese mismo esquema (CLASE). Posteriormente organizamos
jerrquicamente en clases y superclases, construyendo en forma progresiva las grandes CLASIFICACIONES y las
OPERACIONES DE ORDEN.
Despus de los doce aos, en la etapa de las Operaciones combinatorias de la inteligencia (Pensamiento formal), el
hombre construye SISTEMAS y an TEORIAS como producto del raciocinio de Hiptesis (propuestas de solucin a
interrogantes o problemas), y de la representacin en dimensiones simultneas.
Un Sistema es un conjunto de componentes (conceptos y modelos, y an de otros sistemas) que interactan, en distintos
planos, entre s para alcanzar objetivos especficos. Cada Sistema construido es una manera de solucionar los diferentes
problemas que enfrenta el hombre a lo largo de su existencia, por ejemplo el Lenguaje, uno de los sistemas ms
elaborados, permite satisfacer la necesidad vital de la comunicacin.
En sntesis, construimos CONCEPTOS, MODELOS y SISTEMAS. Esta es la forma en que los seres humanos captamos
el mundo real y operamos en l. La tecnologa de Objetos intenta simular este hecho y sus fundamentos se sostienen en l.
Fundamentos de la Tecnologa de Objetos.
1. Simulacin. Representacin directa de elementos que "maneja" el usuario en el mundo real.
Consiste en recrear el mundo real. No se trata de construir "modelos ideales", sino de representarlo directamente. Por ello,
en este enfoque, primero se identifican las caractersticas de los elementos del mundo real, los que se organizan en las
denominadas ESTRUCTURAS DE DATOS. Luego se captan los comportamientos u operaciones, los cuales se imitan
o simulan mediante pequeos programas (procedimientos) a los que en adelante denominaremos METODOS. Y as como
en la vida real conceptualizamos en una sola unidad (datos y comportamiento), en TO simulamos este hecho colocando en
una especie de "cpsula" las estructuras de datos y los mtodos, a esta unidad denominamos OBJETO.
Tambin se simula la manera en que los entes del mundo real se comunican entre s, envindose seales o "mensajes" a
los que responden con una conducta o comportamiento especfico, de la misma manera se simulan las clasificaciones,
ordenamiento, organizacin, e incluso la herencia de los seres vivos.
En sntesis, se trata de actuar de la misma manera en que los humanos, a los que en informtica, en general, se nos
denomina usuarios, " manejamos" y operamos el mundo real.
2. Encapsulamiento. Utilizacin del concepto de "Caja Negra" a una potencia mucho mayor. Empaquetar datos y
operaciones
en forma conjunta se llama ENCAPSULACION.
La encapsulacin es el resultado (o acto) de ocultar, al usuario, los detalles de la implementacin de un objeto. El objeto
oculta sus datos a otros objetos y slo permite accesar a sus datos va sus propios mtodos mediante mensajes especficos,
es decir, se crea una " Caja Negra" que solo el constructor del objeto conoce. A esto se llama ocultamiento de informacin.
La encapsulacin protege los datos de un objeto de la corrupcin. Si todos los programas pudieran accesar a los datos
(como actualmente sucede con la tecnologa estructurada), fcilmente puede corromperse o perderse. La encapsulacin
protege los datos del objeto del uso arbitrario y no intencionado. As la creacin est protegida y la competencia
garantizada.
La encapsulacin tiene dos beneficios primordiales:
1. Modularidad. El cdigo de un objeto puede ser escrito y se puede mantener independiente del cdigo de otros objetos.
Un objeto se puede mover de sistema en sistema, se puede quitar, modificar y volver a colocar sin alterar el s is tema
general.
2. Esconder la informacin ( Information Hiding ). Un objeto tiene una interfaz con la que otros objetos se pueden
comunicar, pero puede mantener informacin privada para s misma que puede cambiar en cualquier momento, sin afectar
a los objetos que dependen de sta.
3. Reutilizacin. Capacidad de reutilizar cdigo sin alterarlo, programando solo lo adicional o diferente. Base de la
Herencia
Durante la vida de un sistema, las estructuras de datos se mantienen relativamente estables, mientras que las operaciones
sobre dichas estructuras cambian, dependiendo de situaciones. Por ello en el Anlisis y Diseo Orientado a Objetos, se da
nfasis primordial a los DATOS y al COMPORTAMIENTO de los objetos y tipos de objetos (modelos).Los datos, como
son relativamente estables, pueden ser utilizados muchas veces, modificando nicamente aquello que sea necesario para
tal o cual
Prof.: Oscar Nez M.
Principios Fundamentales.
Los objetos son las cosas fsicas y conceptuales que encontramos en el universo alrededor de nosotros. Hardware,
software, documentos, seres humanos, los conceptos son todos los ejemplos de los objetos.
Un objeto es algo real o abstracto acerca del cual almacenamos datos y mtodos que manipulan dichos datos.
Es una persona, lugar o cosa. Ejemplo: Una manzana. Todos los objetos tienen un estado y un comportamiento. Esto es
muy importante. Para el ejemplo de la manzana, la manzana (hablando de una manzana normal de color rojo) recin
bajada de un rbo l, est completa, es dura y de color rojo. Este es su estado. Uno sabe que si se muerde la manzana va a
sonar un "crunch", y esto se puede interpretar como un comportamiento. Despus de haberla mordido la manzana cambi
de estado. Los objetos pueden tener ms de un comportamiento y ms de un estado.
Una clase es un grupo de objetos con propiedades (atributos) similares, comportamiento comn (operaciones), relaciones
comunes entre objetos, y semntica comn.
Un grupo de objetos con las mismas caractersticas. Una clase contiene:
Una descripcin de las variables internas de los objetos de la clase.
Las operaciones que se pueden aplicar al objeto de la clase.
En este ejemplo vamos a analizar la clase Msica de Colombia es la clase padre de las clases hija Vallenato y Salsa. En
otras palabras las clases Vallenato y Salsa son derivadas de la clase Msica de Colombia. Ellas heredan todas las
propiedades de su padre. Las clases derivadas pueden adicionar, cambiar u ocultar los miembros pblicos de la clase padre
usando las reglas de la herencia. Cuidado... los miembros privados no pueden ser accesados por otras clases.
Clase padre Msica de Colombia
Atributos: Tipo de ritmo, tipo de instrumentos, msicos. Mtodos: bailada, cantada, tomada.
Clase hija Vallenato (hereda las propiedades de la clase padre) Atributos: Tipo de ritmo, tipo de instrumentos,
msicos.
Mtodos: bailada, cantada. El nuevo mtodo incluye el tocar un instrumento tomada.
Clase hija Salsa (hereda las propiedades de las clase padre) Atributos: Tipo de ritmo, tipo de instrumentos, msicos.
Mtodos: Bailada, cantada, tomada.
Prof.: Oscar Nez M. 3
1) Objeto.
2) Clases
Ejemplo.
Diseo Orientado a Objetos
3) Estructura de Objetos.
El modelo orientado a objetos se basa en encapsular cdigo y datos en una nica unidad, llamada objeto. La interfaz entre
un objeto y el resto del sistema se define mediante un conjunto de mensajes.
El motivo de este enfoque puede ilustrarse considerando una base de datos de documentos en la que los documentos se
preparan usando uno entre varios paquetes software con formateador de texto. Para imprimir un documento debe
ejecutarse el formateador correcto en el documento. Bajo un enfoque orientado a objetos, cada documento es un objeto
que contiene el texto de un documento y el cdigo que opera sobre el objeto. Todos los objetos del tipo documento
responden al mensaje Imprimir, pero lo hacen de forma diferente. Cada documento responde ejecutando el cdigo
formateador adecuado. Encapsulando dentro del objeto documento la informacin acerca de cmo imprimirlo, se puede
tener todos los documentos con la misma interfaz externa al us uario (aplicacin).
En general, un objeto tiene asociado:
Un conjunto de atributos que contienen datos acerca del objeto. A su vez, cada valor de un atributo es un objeto.
Un conjunto de mensajes a los que el objeto responde.
Un conjunto (puede ser unitario) de mtodos, que es un procedimiento o trozo de cdigo para implementar la respuesta a
cada mensaje. Un mtodo devuelve un valor (otro objeto) como respuesta al mensaje.
Puesto que la nica interfaz externa de un objeto es el conjunto de mensajes al que responde, es posible modificar la
definicin de mtodos y atributos sin afectar a otros objetos.
Tambin es posible sustituir un atributo por un mtodo que calcule un valor.
Ejemplo:
Un objeto documento puede contener un atributo de tamao que contenga el nmero de bytes de texto en el documento, o
bien un mtodo de tamao que calcule el tamao del documento leyndolo y contando el nmero de bytes.
"La capacidad de modificar la definicin de un objeto, sin afectar a l resto del sistema, est considerada como una de las
mayores ventajas del Modelo de Programacin Orientada a Objetos".
4) Jerarqua de Clases.
Normalmente en la realidad a modelar existen muchos objetos similares. Por similar se quiere decir que tienen una
naturaleza parecida, por lo que son candidatos a poseer atributos, mtodos y responder a mensajes comunes en un
contexto orientado a objetos (VIC).
Para el caso de los objetos similares, sera un trabajo intil definir cada uno de ellos por separado. Por t anto, se agrupan
para que conformen una clase. A cada uno de estos objetos se le llama instancia de clase. Todos los objetos de una clase
comparten una definicin comn, aunque difieran en los valores asignados a los atributos.
Ejemplo:
En un banco, son objetos los clientes, las cuentas y los prstamos. Una clase incluye:
Un atributo con valores en un conjunto cuyo valor es el conjunto de todos los objetos que son instancias de la clase.
Implementacin de un mtodo para el mensaje nuevo, el cual crea una nueva instancia de la clase.
Un esquema orientado a los objetos, normalmente requiere un gran nmero de clases. Sin embargo, a menudo se da el
caso que varias clases son similares. Para permitir la representacin directa de similitudes entre clases, se utiliza una
jerarqua de especializacin, como aquella utilizada por el modelo MER extendido.
Prof.: Oscar Nez M.
Denotaremos las clases por medio de rectngulos con lnea doble, mientras que las instancias de las mismas u objetos, se
representarn por rectngulos. El semicrculo denota la relacin ES_UN, o ESPECIA LIZACION de, que se utiliza para
construir la jerarqua de clases (VIC).
5) Operaciones.
Una accin que es afectada por, o requerida por un objeto. Las operaciones pueden ser selectoras, constructivas, o
iterativas . Una operacin es contenida en la interfaz del objeto y tiene sus detalles descritos en un mtodo
correspondiente. Las operaciones pueden ser compuestas, es decir, integrada por otras operaciones. Sin embargo no es
alentada, la encapsulacin de operaciones compuestas dentro de la interfaz a un objeto.
6) Mens aje.
Los objetos se comunican unos con otros mediante mensajes. El mensaje es enviado por un objeto emisor y recibido por
un objeto destino o receptor. Un mensaje invoca una o ms operaciones en el objeto receptor.
7) Herencia.
Principio por el cual una clase se puede derivar de otra clase ya existente, heredando las caractersticas del padre.
Relacin entre clases de objetos que permite incluir (re-usar) los atributos y operaciones definidas en otra clase ms
general de la cual se hereda o deriva. Es compartir atributos y operaciones entre clases tomando como base una relacin
jerrquica. En trminos generales se puede definir una clase que despus se ir refinando sucesivamente para producir
subclases. Todas las subclases poseen o heredan, todas y cada una de las propiedades de su superclase y aaden, adems,
sus propiedades exclusivas. No es necesario repetir las propiedades de las superclases en cada subclase.
Ejemplo:
Tengo el objeto fruta, con algunas propiedades inherentes a la fruta. Luego tengo el objeto manzana, que es hijo de fruta y
por lo tanto hereda las propiedades de la fruta, pero puede tener otras propiedades propias de la manzana. Este es un
ejemplo sencillo pero ms o menos ilustra lo que se trata de explicar. El hijo hereda las caractersticas del padre, pero tiene
otras propias y mejora o empeora, algunas caractersticas del pap.
Ejemplo:
Retornando al caso del banco, podemos observar que como atributos para la clase persona se tiene ruc, nombre, direccin
y telfono. A su vez los empleados tienen un sueldo, y los clientes una tasa de crdito.
Prof.: Oscar Nez M.
9) Identidad.
Los datos estn cuantificados en entidades discretas y distinguibles denominadas objetos (PE. una televisin, una
bicicleta, un rbol). Los objetos pueden ser concretos, como un archivo en un sistema de archivos, o bien conceptuales
como la poltica de planificacin en un sistema operativo con multiprocesos. Cada objeto posee su propia identidad
inherente. En otras palabras: dos objetos sern distintos aun cuando los valores de todos sus atributos (tales como el
nombre y el tamao) sean idnticos.
Prof.: Oscar Nez M.
informacin, pero a diferencia de los sistemas como los relacinales, aunque modifiquemos el nombre de un objeto
persona, ste seguir siendo el mismo objeto.
10) Clasificacin.
Significa que los objetos con la misma estructura de datos (atributos) y comportamiento (operaciones) se renen para
formar una clase. La seleccin de clases es arbitraria y depende de la aplicacin.
Ejemplo.
Objetos: Bicicleta de montaa, Bicicleta de carreras, Bicicleta de nios. Clase: Bicicleta.
Atributos: Tamao del cuadro, tamao de rueda, material, marca, velocidad Operaciones: mover, reparar, cambiar
velocidad
Objetos: Triangulo, Cuadrado, Octgono. Clase: Polgonos.
Atributos: vrtices, color del borde, color del interior Operaciones: dibujar, borrar, mover
11) Abs traccin.
Consiste en representar las caractersticas esenciales de un objeto, sin preocuparse de las restantes caractersticas (no
esenciales). Una abstraccin se centra en la vista externa de un objeto, de modo que sirva para separar el comportamiento
esencial de un objeto, de su implementacin. Definir una abstraccin significa describir una entidad del mundo real, no
importa lo compleja que pueda ser, y a continuacin utilizar esta descripcin en un programa. Una clase se puede definir
como una descripcin abstracta de un grupo de objetos, cada uno de los cuales se diferencia por su estado especfico y por
la posibilidad de realizar una serie de operaciones.
12) Encapsulamiento.
Mecanismo que permite ocultar los detalles de implementacin de un objeto. Permite empaquetar en una unidad los datos
y las funciones que operan sobre dichos datos.
Consiste en la combinacin de datos e instrucciones en un nuevo tipo de datos denominado clase. Facilita la
descomposicin modular. En la prctica, una clase estar formada por dos partes: Una interfaz mediante la cual se
acceder a la funcionalidad de los objetos y Una representacin de la abstraccin utilizando las facilidades del lenguaje.
Es una buena norma el realizar el acceso a los datos del objeto utilizando los mtodos de la interfaz. Los lenguajes OO
permiten especificar en el objeto elementos que no sern visibles desde el exterior del mismo pero que son necesarios para
su representacin. A esta caracters tica se le conoce con el nombre de Ocultamiento de Informacin.
Acceso
..-
1
Mtodos,1
I- Datos
13) Agregacin.
Composicin de un objeto por otros. Es una relacin ms dbil que la que existe entre el atributo y el objeto al cual
pertenece, y ms fuerte que una asociacin.
14) Concurrencia.
Propiedad que distingue un objeto activo de otro inactivo.
Prof.: Oscar Nez M.
y^ ^ \
El encapsulamiento oculta los detalles y hace fcil el uso de clases complejas. Las clases son semejantes a las cajas
negras. El desarrollador utiliza la caja negra sin mirar su interior. El tiene un entendimiento del comportamiento de la caja
negra y cmo comunicarse con ella.
Cons truccin de Objetos de complejidad Creciente
Los objetos se construyen fuera de los objetos. Una buena manera de fabricar es construir tomando una lista de materiales
de partes y subpartes existentes. Esto posibilita construir componentes de software complejos y los mismos se utilizarn
para construir otros bloques de software ms complejos.
Confiabilidad
EL software construido a partir de una librera de clases estables, es probable que se encuentre libre de errores, respecto a
construir software desde el inicio. Cada mtodo en una clase es en s mismo simple y diseado para ser confiable.
Prof.: Oscar Nez M.
Las clases emplean requerimientos y respuestas de forma. Esto permite que ellos sean utilizados con mltiples sistemas
operativos, DBMS, manejadores de redes, interfaces grficas para usuarios, etc.
Interoperatividad
Software de diferentes vendedores pueden trabajar juntos. Un vendedor puede utilizar clase de otros vendedores. La
interoperatividad de software de diferentes vendedores es uno de los objetivos ms importantes de los estndares de la
OO. Software desarrollados independientemente en lugares separados, deberan ser capaces de trabajar juntos y
presentarse como una unidad simple al usuario.
Computaci n Cliente / S ervidor
En el sistema Cliente / Servidor, las clases en el software cliente deberan enviar sus requerimientos a las clases de
software servidor y recibir respuestas. Una clase servidor puede ser utilizada por muchos clientes. Esto puede accesar al
software nicamente a travs de los mtodos (as los datos se protegen de corrupciones).
Computacin masivamente Distribuida
Redes alrededor del mundo emplearn directorios de software de objetos accesibles. El diseo orientado al objeto, es la
clave para la computacin masivamente distribuda. Las clases en una mquina interactuarn con cualquier otra, sin
necesidad de saber dnde residen. Ellas envan y reciben mensajes en formatos estndares.
Computaci n Paralela
La velocidad de las maquinas., pueden ser ampliamente mejoradas mediante la instalacin de computadoras en paralelo.
Se pueden tener procesamientos simultneos y concurrentes en mltiples chips de procesadores (eventualmente, un chip
puede tener muchos procesadores). Objetos en diferentes procesadores se ejecutarn simultneamente, cada uno de ellos
actuando independientemente.
Alto Nivel de Automatizacin de Bases de datos
Las estructuras en Base de Datos OO, estn ligadas a mtodos que toman acciones automticas. Una Base de Datos OO,
tiene su inteligencia construida en la forma de mtodos, mientras que otras bases de datos no.
Performance de Mquinas
La Bases de Datos Orientada a Objetos han demostrado una mayor performance que las bases de datos relacionales para
ciertas aplicaciones con estructuras de datos ms complejas. Las bases de datos OO, la computacion concurrente y el
diseo OO prometen mayores saltos en la performance de las mquinas LAN'S basadas en sistemas Cliente/Servidor.
Emplearn servidores de Base de Datos concurrentes y orientadas al objeto.
Migracin
Existiendo o no aplicaciones orientadas a objetos, ellos pueden ser preservados convenientemente con una cobertura OO,
comunicndose entre ellos mediante mensajes estndares OO.
Mejores herramientas CAS E
Las herramientas Case utilizarn tcnicas grficas para disear las clases y sus interacciones, y para utilizar objetos
existentes adaptados en nuevas aplicaciones. Las herramientas deberan facilitar el modelamiento en trminos de eventos,
trig gers (iniciadores), estado de los objetos, etc. Las herramientas de los CASE OO generan cdigos tan pronto como una
clase sea definida y permitir al diseador probar y utilizar el mtodo creado. Las herramientas debern ser diseadas para
estimular la mxima creatividad y continuo refinamiento del diseo durante la construccin.
Industriales de Libreras de Clases
Las compaas de software comercializarn libreras para diferentes reas de aplicacin. Las libreras de clases
independientes de las aplicaciones, sern tambin importantes y stas sern proporcionadas como facilidades de
herramientas
CASE (VIC).
Libreras de Clases Corporativas
Las corporaciones, crearn sus propias libreras de clases que reflejen sus estndares internos y requirimientos de
aplicacin. La identificacin TOP-DOWN de los OBJETOS del negocio, es un aspecto importante de la ingeniera de la
Informacin.
Prof.: Oscar Nez M.
documento. Hay que tener en cuenta que el estndar UML no define un proceso de desarrollo especfico, tan solo se trata
de una notacin.
Desde principios de los 90, los artculos publicados en el Journal of Object Oriented Programming (JOOP) por James
Odell, James Rumbaugh, Grady Booch, Desmond d'Souza, Bertrand Meyer, Steve Cook, John Daniels, Sally
Shlaer y Stephen J. Mellor entre otros, han sido una constante fuente de conocimiento. Publicaciones pioneras como el
Object Oriented Technology, A Manager's Guide de David A. Taylor, en su primera edicin de 1990 y en la segunda
ampliada de 1998, han tenido una gran influencia en como abordar la presentacin didctica. Tambin los libros de Peter
Coad et al, Object Oriented Analysis, Design and Programming, Object Models y Java Modeling Color with UML, han
sido de una ayuda extraordinaria. La obra enciclopdica The Unified Modeling Language: Reference Manual de
Rumbaugh & Jacobson & Booch, es un punto de referencia constante. Sin duda, uno de los autores ms influyentes ha
sido Martin Fowler. Su primer libro Analysis Patterns continua siendo una referencia clave. Posteriormente, la primera
edicin de UML Distilled en 1997 y su ltima edicin ampliada en 2000, se ha convertido en el libro de cabecera de UML.
Otro clsico por la excelencia de su trabajo es Applying UML and Patterns de Craig Larman que en su segunda edicin
aparecida en verano de 2001 se ha superado a si mismo. Tambin recientes y con muy buen material que ha sido
incorporado a la gua, tenemos los libros de Wendy & Michael Boggs, Mastering UML with Rational Rose, de Alistair
Cockburn, Writing Effective Use Cases; de Scott W. Ambler, The Object Primer segunda edicin; y de John Chessman
& John Daniels, UML Components, una de las novedades ms interesantes de 2001.
MAINSTREAM OBJECTS
Combina una sntesis de las principales tcnicas y enfoques OO.
Prof.: Oscar Nez M.
Modelo de Estructura de
(Esttico)
Objetos (OSM)
Objetos Interface.
Representan los objetos tcnicos requeridos para vincular la aplicacin con el entorno. Representan el vnculo a travs del
cual el sistema recibe o suministra datos e informacin al entorno. Tpicamente incluyen interfaces con el usuario
(pantallas, reportes, etc.) e interfaces con otras aplicaciones. Se representan en el diagrama de estructura de objetos con el
siguiente smbolo:
Interface Nombre Clase
Objetos de Control.
Contienen comportamiento que no pertenece naturalmente ni a Objetos Entidad ni de Interfaz. Son normalmente objetos
transitorios, como ser un controlador de reportes. Se representan en el diagrama de estructura de objetos con el siguiente
smbolo:
Nombre Clase
9
Modelo de Estructura de Objetos (OSM) UML: Diagrama de Clases (Class Diagram)
El OSM es el modelo fundamental que provee un medio uniforme par modelar el sistema desde la captura de
requerimientos en la etapa inicial del anlisis hasta la implementacin, atravesando todo el ciclo de desarrollo del sistema.
Es te modelo identifica:
Las clases de objetos en la aplicacin.
Como las clases de objetos se asocian unas con otras.
Como se comunican los objetos.
Los detalles de cada clase de objetos, incluyendo atributos y operaciones.
Durante el proceso de anlisis y diseo, el OSM es definido en sucesivos niveles incrementales de detalle, hasta que el
nivel necesario para la implementacin es alcanzado.
Todos los dems modelos capturan detalles que alimentan este modelo.
El desarrollo de OSM es un proceso aditivo, diferencindose del enfoque transformacional caracterstico de otros mtodos
como el estructurado, donde los DFD son transformados en diagramas de estructura, con los consiguientes problemas que
esto acarrea.
Diseo Orientado a Objetos
2.
Caractersticas de las Clases de Objetos.
Operaciones.
Una operacin define un servicio ofrecido por un objeto junto con la informacin que debe suministrarse cuando es
invocado (nombre, argumentos de entrada y/o salida). Tambin puede contener una especificacin de mtodo, el cual
especifica una implementacin para la operacin.
Durante la etapa de Anlisis o Diseo Lgico pueden utilizarse tpicamente texto libre o pseudocdigo. Durante el Diseo
Fsico dichas especificaciones son trasladadas a un lenguaje de programacin especfico, como por ejemplo: C++, Java,
Visual Basic, etc.
Algunas operaciones pueden asumirse que existen para cada clase de objetos sin identificarlas formalmente. Estas son
llamadas operaciones implcitas. Las operaciones implcitas ms importantes son: Crear, Destruir, Leer y Actualizar. Una
operacin implcita debe ser formalmente definida cuando sus pre y post condiciones no sean triviales.
La identificacin y especificacin de operaciones es una tarea clave durante el Diseo Lgico.
Atributos.
Son valores de datos asociados a los objetos de una clase a la cual describen. Estn fuertemente asociados con la clase de
objetos que los contienen, de tal forma que no tienen existencia independiente o identidad de objeto. La decisin de
cuando un tem debe considerarse como atributo o como clase vara de sistema en sistema, dependiendo de su semntica
en el dominio del problema, es decir, lo que en un sistema se modela como atributo en otro puede modelarse como una
clase.
Cada atributo identificado debe ser atmico en el sentido de que debe ser tratado como una unidad, es decir, puede ser un
valor simple o un grupo de valores tratados siempre como una unidad (PE. Direccin). Debe notarse que las clases no se
modelan en formas normales. La decisin sobre la estructura de datos a utilizar se difiere hasta el Diseo Fsico.
Los atributos pueden basarse en definiciones de tipos de atributos, lo cual provee una definicin estndar sobre formato,
longitud y dominio de valores para atributos del mismo tipo.
Restricciones.
Las restricciones pueden especificarse sobre los valores que un atributo puede tomar. La implementacin de las
restricciones puede realizarse de diferentes formas:
10
Nombre Clase
a,*
U*
10
PE.
d) Comunicacin por Mensajes.
Las asociaciones por comunicacin pueden utilizarse para mostrar que objetos de una clase se comunican con objetos de
otra clase o de la misma. Una asociacin por comunicacin corresponde al conjunto de mensajes que son enviados por los
objeto s de una clase a los objetos de otra clase o de la misma. Tpicamente, la asociacin por comunicacin es la nica
asociacin existente entre objetos de los tres diferentes tipos.
En el OSM, la asociacin por comunicacin se representa de la siguiente manera:
Emisor
Riicr-ptor
7
4. Consideraciones: Tcnicas avanzadas de OSM.
Visibilidad Define que objetos puede acceder y utilizar los atributos y operaciones de un objeto dado. Pblico: todos.
11
11
En donde:
o Superior: Contiene el nombre de la Clase
o Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected
o public).
o Inferior: Contiene los mtodos u operaciones, los cuales son la forma como interacta el objeto con su entorno
(dependiendo de la visibilidad: private, protected o public).
Ejemplo:
Una Cuenta Corriente que posee como caracterstica:
o Balance Puede realizar las operaciones de:
o Depositar
o Girar
o y Balance El diseo asociado es:
Cuenta ^balance: nt
*ciepostar(monto : nt): void *grar(monto : int): boolean balanceo : r|t
ATRIBUTOS Y MTODOS:
1. Atributos:
Los atributos o caractersticas de una Clase pueden ser de tres tipos, los que definen el grado de comunicacin y
visibilidad de ellos con el entorno, estos son:
public (+, ^)' Indica que el atributo ser visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos
lados.
private (-, ^Nr/ Indica que el atributo slo ser accesible desde dentro de la clase (slo sus mtodos lo pueden accesar).
protected (#, ^^y. Indica que el atributo no ser accesible desde fuera de la clase, pero si podr ser accesado por
mtodos de la clase adems de las subclases que se deriven (ver herencia).
2. Mtodos:
Prof.: Oscar Nez M.
12
AGREGACIN:
Para modelar objetos complejos, n bastan los tipos de datos bsicos que proveen los lenguajes: enteros, reales y secuencias
de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la
aplicacin, tenemos dos posibilidades:
Por Valor: Es un tipo de relacin esttica, en donde el tiempo de vida del objeto incluido esta condicionado por el
tiempo de vida del que lo incluye. Este tipo de relacin es comunmente llamada Composicin (el Objeto base se contruye
a partir del objeto incluido, es decir, es "parte/todo").
12
---------->
Representa un tipo de relacin muy particular, en la que una clase es instanciada (su instanciacin es dependiente de otro
objeto/clase). Se denota por una flecha punteada.
El uso ms particular de este tipo de relacin es para denotar la dependencia que tiene una clase de otra, como por ejemplo
una aplicacin grafica que instancia una ventana (la creacin del Objeto Ventana esta condicionado a la instanciacin
proveniente desde el objeto Aplicacin):
Aplicacin
.....------>
Ventana
Cabe destacar que el objeto creado (en este caso la Ventana grfica) no se almacena dentro del objeto que lo crea (en este
caso la Aplicacin).
CASOS PARTICULARES:
Clas e Abs tracta:
Empleado
2^
Operario
Gerente
13
Una clase parametrizada se denota con un subcuadro en el extremo superior de la clase, en donde se especifican los
parmetros que deben ser pasados a la clase para que esta pueda ser instanciada. El ejemplo ms tpico es el caso de un
Diccionario en donde una llave o palabra tiene asociado un significado, pero en este caso las llaves y elementos pueden
ser genricos. La genericidad puede venir dada de un Template (como en el caso de C++) o bien de alguna estructura
predefinida (especializacin a travs de clases).
En el ejemplo no se especificaron los atributos del Diccionario, pues ellos dependern exclusivamente de la
implementacin que se le quiera dar.
Prof.: Oscar Nez M.
13
Salidas Menores
Cmo identificar y definir PN?.
1. Se identifican los productos y/o servicios significativos, de los que es responsable el negocio y se asocia cada uno de
ellos a uno o ms procesos de negocios.
2. Se identifican las entradas y eventos disparadores que inician cada proceso de negocio y se da un nombre a cada PN.
3. Cada PN se describe especificando las actividades de alto nivel que se requieren para producir los productos y/o
servicios.
Secuencia de Transacciones (ST).
El concepto de secuencia de transacciones es muy similar al concepto de "Casos de Uso" (UML), introducido por
Jacobson en su metodologa OOSE y de amplia difusin actualmente.
Una secuencia de transacciones es conceptualmente similar a un proceso de negocios, la diferencia radica en su alcance.
El proceso de negocio se utiliza para comprender y modelar el funcionamiento de la empresa (negocio). Las secuencias de
transacciones se utilizan para modelar los requerimientos funcionales de la aplicacin que soportar determinados
procesos de negocios.
Los procesos de negocio son trasladados en secuencias de transacciones durante el anlisis de requerimientos. El alcance
de una secuencia de transacciones es el mismo de un proceso de negocios o de un subproceso muy significativo. Una
secuencia de transacciones puede implicar ms de un usuario y funcin y puede extenderse en el tiempo, esto es no tener
resolucin inmediata.
Prof.: Oscar Nez M.
14
nombre
(^^ombre^^
Evento
C/
Evento
-*Q
CasoUsol
-----
\
Comunicacin entre Actor y ST's.
Borde del Sistema
-
1
Descripcin Textual.
1. Abs tracto. Breve descripcin del proceso de negocios o secuencia de transacciones.
2. Contexto del Negocio. Especifica:
a) el resultado de la ST o PN (productos y/o servicios)
b) el cliente de la ST o PN
c) el valor que gana el cliente con la ST o PN
d) el evento que inicia la ST o PN
e) entradas requeridas por la ST o PN
f) descripcin de alto nivel de la ST o PN
g) requerimientos especiales que controlan la ejecucin de la ST o PN 2) Camino estndar y alternativo.
El camino estndar es una descripcin secuencial de todas las actividades que deben realizarse para alcanzar el resultado.
Par una ST describe las actividades de los actores y que debe hacer la aplicacin en orden de servir dichas actividades.
Para un PN describe las actividades de alto nivel del proceso y quin las realiza
Prof.: Oscar Nez M.
14
El proceso de identificar requerimientos del usuario y secuencias de transacciones puede asistirse con la prototipacin de
interfaces.
Cmo identificar y definir ST?
1. Identificacin a travs de actores.
Identificar los actores que se comunicarn con el sistema, luego para cada actor considerar:
a) Cules son las principales tareas del actor?
b) Qu accesos (lectura o escritura) requiere el actor del sistema?
c) Cundo el actor informar al sistema acerca de cambios fuera del sistema?
d) Cundo el actor ser informado de cambios a travs del sistema?
2. Identificacin a travs de eventos.
Consiste en identificar a qu eventos externos o temporales, debe ser capaz de responder el sistema, para ello:
a) Confeccionar la lista de eventos
b) Asociar una secuencia de transacciones para cada evento identificado
Componentes y Herramientas de Modelado de Procesos de Negocios y Secuencias de Transacciones.
Para modelar y documentar procesos de negocios y secuencias de transacciones se utilizan los mismos diagramas y
documentos, los cuales son:
1) Diagrama de Secuencia de Transacciones (TSD)
Diseo Orientado a Objetos
Los caminos alternativos se describen separadamente pero pertenecen a la misma ST o PN. Describen casos inusuales de
procesamiento y manejos de excepciones o errores. Esta separacin se realiza para facilitar el modelado y lectura de los
caminos estndar.
Para modelar y diagramar los caminos estndar y alternativos, respectivamente, se utilizan los Diagramas de Interaccin
de Objetos (OID) y los Diagramas de Flujo de Actividad (AFD).
3) Actores.
En el BPM representan los profesionales del negocio y sistemas de computacin involucrados en producir un producto o s
ervicio.
En el TSM representan agentes externos que interactan con la aplicacin. Pueden representar usuarios humanos o
interfaces con otros sistemas.
Cada actor es usado para modelar un rol, el cual puede ser desempeado por un usuario individual o grupo de usuarios.
4) Observacin.
Subdivis in de procesos de negocios.
Los PN pueden ser subdivididos en subprocesos. Las dos formas principales para realizar esto son:
Especializacin. Es la especializacin del PN en distintos tipos que producen el mismo resultado pero tienen diferentes
conjuntos de actividades.
Particionamiento. Es el particionamiento del PN a lo largo del eje de tiempo en una secuencia de subprocesos.
>
Es el tipo de relacin ms bsica que indica la invocacin desde un actor o caso de uso a otra operacin (caso de uso).
Dicha relacin se denota con una flecha simple.
Prof.: Oscar Nez M.
15
.........->
Es una forma muy particular de relacin entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea).
Dicha relacin se denota con una flecha punteada.
Generalizacin
Este tipo de relacin es uno de los ms utilizados, cumple una doble funcin dependiendo de su estereotipo, que puede ser
de Uso (<<uses>>) o de Herencia (<<extends>>).
Este tipo de relacin esta orientado exclusivamente para casos de uso (y no para actores).
Extends
Se recomienda utilizar cuando un caso de uso es similar a otro (caractersticas).
Us es
Se recomienda utilizar cuando se tiene un conjunto de caractersticas que son similares en ms de un caso de uso y no se
desea mantener copiada la descripcin de la caracterstica.
De lo anterior cabe mencionar que tiene el mismo paradigma en diseo y modelamiento de clases, en donde esta la duda
clsica de usar o heredar.
Prof.: Oscar Nez M.
15
como se la ve en el modelo de proceso de negocio) y se determina que objetos participan para implementar la
funcionalidad requerida del sistema.
Diagrama de interaccin de objetos (OID) para un proceso de negocios (PN).
Actor 1
Actor 2 Actor 3 Sistem a 1
Evento 1
-H
Evento 5
HHEvento 2
-H
Evento 4
Evento 3
-H
Elementos:
1. Actores en la parte superior del diagrama. Pueden ser humanos o sistemas vistos como cajas negras
2. Una lnea vertical asociada a cada actor
3. Requerimientos o eventos enviados por un actor a otro. Se representan por flechas. Se utiliza una sola flecha para
representar el estmulo y la respuesta implcita.
4. Etiquetas en el margen izquierdo representando links a actividades de un diagrama de flujo de actividades.
1
2
16
-H
K-H
H-H
-H
-H
2
3
Elementos:
1. Barra vertical a la izquierda representa el lmite del sistema.
2. Se acompaa con la descripcin narrativa de la secuencia de transacciones a la izquierda de esta.
3. Una flecha proveniente desde el lmite representa un requerimiento externo generado por un actor. Es conveniente que
los requerimientos/respuestas de este tipo se representen por flechas individuales.
4. Operaciones: se representan por rectngulos alargados sobre los ejes correspondientes a los objetos que las realizan.
Permite visualizar que mensajes dispara una operacin. La longitud de la barra no representa duracin.
5. Actividades: bloques de eventos que siempre ocurren en una determinada secuencia. Dichas actividades que pueden
ocurrir en paralelo, condicional o iterativamente, pueden modelarse con un diagrama de flujo de actividad asociado.
Cas os es peciales .
1. Invocacin de operaciones "in-self". A menudo una operacin de un objeto invoca a otra operacin de la misma clase.
Esto puede representarse de la siguiente forma:
-H
J
2. Mltiples objetos de una misma clase. Se representa la clase ms de una vez.
Prof.: Oscar Nez M.
16
-H
---
Diagrama de Interaccin.
El diagrama de interaccin, representa la forma en como un Cliente (Actor) u Objetos (Clases) se comunican entre si en
peticin a un evento. Esto implica recorrer toda la secuencia de llamadas, de donde se obtienen las responsabilidades
claramente.
Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama Esttico de Clases o el de Casos de Uso (son
diferentes).
Los componentes de un digrama de interaccin son:
Un Objeto o Actor.
Mensaje de un objeto a otro objeto.
Mens aje de un objeto a si mismo.
Elementos
OBJETO/ACTOR:
El rectngulo representa una instancia de un Objeto en particular, y la lnea punteada representa las llamadas a mtodos
del objeto.
MENSAJE A OTRO OBJETO:
Se representa por una flecha entre un objeto y otro, representa la llamada de un mtodo (operacin) de un objeto en
particular.
MENSAJE AL MISMO OBJETO:
No solo llamadas a mtodos de objetos externos pueden realizarse, tambin es posible visualizar llamadas a mtodos
desde el mismo objeto en estudio.
Prof.: Oscar Nez M.
17
7
Obs ervacin.
Un AFD puede incluir actividades que no estn en un camino estndar pero que aparezcan en un camino alternativo.
Pueden existir actividades sin interacciones asociadas que se utilizan para clarificar la lgica del flujo.
Puede utilizarse un AFD sin OID asociado simplemente para describir la lgica del flujo en un camino
estndar/alternativo.
Generalmente, un OID es utilizado para modelar cada secuencia de transacciones. Es posible ms de un OID por
secuencia de transacciones y se describen a continuacin dos enfoques alternativos.
o Usando AFD para modelar operaciones.
Los AFD pueden ser utilizados en combinacin con los OID. En un AFD cada bloque normalmente representa un grupo
de eventos que ocurren siempre en la misma secuencia. Otra opcin es mostrar un bloque en un AFD para representar
cada posible estmulo externo para una secuencia de transacciones. Tal estmulo externo (u operacin del sistema) puede
ocurrir a menudo en secuencias aleatorias o en secuencias alternativas. Un OID puede desarrollarse para cada uno de tales
bloques u operaciones del sistema.
Sin embargo, se recomienda utilizar un OID simple para toda la secuencia de transacciones siempre que sea posible,
debido a que esto brinda una visin general para todo el proceso requerido.
o OID's, ST's y Escenarios.
Generalmente se desarrolla un solo OID por cada secuencia de transacciones. Este diagrama muestra un caso general
omitiendo caminos alternativos inusuales. No muestra un escenario de ejecucin que pueda ocurrir en una ocasin
especfica. En casos complicados, puede ser til desarrollar OID's alternativos representando los caminos alternativos.
Prof.: Oscar Nez M.
17
Las transiciones de estados de un objeto son causadas por la recepcin de un evento interno o externo al sistema. El estado
que asume un objeto luego de recibir un evento depende del estado actual, del evento recibido, y opcionalmente del valor
de una condicin de guarda. Cuando un objeto recibe un evento ejecuta una accin (que corresponde con una operacin)
asociada con un a transicin. Al fin o durante la ejecucin de dicha accin, el objeto produce el cambio de estado. Puede d
arse que el estado final sea el mismo que el inicial.
Utilizacin del modelo de ciclo de vida de objetos.
Siempre que se agrega una nueva clase al OSM es importante examinar si se presentan estados significativos para los
objetos de la misma. Si es asi puede utilizarse el modelo de ciclo de vida en orden de comprender correctamente el ciclo
de vida de dichos objetos. El modelo de ciclo de vida es til en las etapas de anlisis del negocio y de requerimientos, para
obtener una clara comprensin de los objetos claves descubiertas y de los caminos estndar y alternativos involucrados.
Herramientas de modelado. Diagrama de ciclo de vida de objetos.
La herramienta que se utiliza para modelar el ciclo de vida de objetos es el diagrama de ciclo de vida de objetos (OLD).
Un OLD se aplica slo a una clase de objetos.
El OLD representa:
Cmo los objetos son creados.
Cmo los objetos son destruidos.
Cmo los objetos cambian a travs del tiempo.
Qu estados tpicamente asume un objeto.
Qu eventos causan cambios de estado.
Qu acciones realiza un objeto cuando recibe un evento que produce un cambio de estado.
Componentes del OLD.
Punto de entrada. Instante previo a la creacin de un objeto. Punto de salida. Momento en el que deja de existir un objeto.
Estado. Conjunto de valores de los atributos de un objeto en un instante de tiempo.
Transicin o cambio de estado.
IEvento [condicin de guarda! Accin
Prof.: Oscar Nez M.
18
18
Bsicamente, las clases de objetos que tienen un alto grado de interdependencia y sirven a un propsito comn, deben
asignarse al mismo subsistema. Usualmente, jerarquas de herencia y agregacin, deben ser asignadas completamente a un
subsistema.
Debe notarse que si existen objetos que son requeridos por diferentes subsistemas, entonces dichos objetos no deben
asignarse a un subsistema.
Servicios
Un subsistema provee sus servicios va una interface, la cual es un conjunto de operaciones que los clientes de un
subsistema pueden utilizar. Son tiles estas operaciones en servicios. Cada servicio agrupa operaciones relacionadas que
tienen un propsito comn.
Los servicios provistos por un subsistema a otro, o a actores, pueden identificarse determinando que comunicaciones son
posibles entre subsistemas, y agrupar estas en servicios. Es conveniente que esto se realice durante ci diseo lgico,
cuando las operaciones han sido definidas.
Los subsistemas pueden vincularse en relaciones cliente-servidor o partner to partner (compaero a compaero). En este
ltimo caso, un subsistema puede ser cliente y servidor a la vez.
Particiones verticales y horizontales
Un sistema puede ser particionado horizontalmente (en capas) o verticalmente. Las particiones verticales son usadas para
subdividir la funcionalidad de la aplicacin, mientras que las particiones horizontales son particularmente tiles para aislar
las aplicaciones de capas de software de menor nivel como ser sistemas operativos, bases de datos o hardware. Este
enfoque por capas (layers) asegura la portabilidad de una aplicacin.
En el siguiente ejemplo el dominio de problema se divide en cuatro particiones verticales. El componente de
administracin de datos es una particin horizontal, la cual existe para aislar a la aplicacin del software de base de datos
utilizada.
Subsistema de
Subsistema de
Subsistema de
Subsistema de
reportes
seminario
registracin
memos
Componente de Administracin de Datos
Prof.: Oscar Nez M.
19
O
Bordes del sistema: se representan con un rectngulo en lnea gruesa. Los actores se dibujan fuera del rectngulo, y los s
ubs is temas dentro.
nombre
19
Diseo Lgico: aqu es donde los desarrolladores del sistema identifican los componentes de software y hardware
necesarios para satisfacer los requerimientos, como as tambin especifican las relaciones arquitecturales entre dichos
componentes. El diseo lgico debe evitar detalles tcnicos especficos requeridos para mapear el diseo en un entorno de
implementacin especfico.
Diseo Fsico: aqu es donde se toman decisiones tcnicas considerando arquitecturas de hardware especificas, sistemas
de bases de datos, lenguajes de programacin, utilizacin de paquetes de middleware o herramientas Case, etc. Aqu
tambin se toman decisiones con respecto a caractersticas de implementacin como ser arquitectura cliente/servidor,
distribucin de objetos, etc.
4. Construccin
Desarrollo: aqu es donde un diseo fsico es implementado en un lenguaje de programacin, o entorno especifico de
desarrollo.
Prueba: se realizan test del software para validar su correcto funcionamiento y detectar fallas que deban ser depuradas.
Documentacin: desarrollo de: documentacin tcnica sobre la aplicacin, manuales de usuario, manuales de
procedimiento, etc.
5. Aprobacin (Implantacin)
6. Operacin y Mantenimiento
Prof.: Oscar Nez M.
20
21
22
Anlisis de Requerimientos.
El proceso de anlisis de requerimientos debe producir una definicin clara de los requerimientos para el nuevo sistema
desde la cual puedan trabajar los desarrolladores y contra la cual puedan validarse los resultados.
Durante el anlisis del negocio se producen un modelo de la forma en que actualmente funciona la empresa. Durante el
anlisis de requerimientos, se modela cmo la empresa operar utilizando el nuevo sistema.
Un objetivo adicional del anlisis de requerimientos es proveer a los profesionales del negocio de la oportunidad de
cambiar la manera en que actualmente funciona la empresa.
El punto de partida del anlisis de requerimientos depende del contexto en el cual una aplicacin es desarrollada. Cuando
el dominio del negocio para la aplicacin es pequeo y bien comprendido, entonces la fase de anlisis del negocio es muy
breve. El anlisis de requerimientos parte de los modelos del anlisis del negocio que contienen muy poco detalle. En este
caso es casi como partir desde cero.
Cuando se ha realizado un anlisis del negocio extenso, entonces los modelos obtenidos constituyen la base sobre la cual,
se contina trabajando realizando los agregados y extensiones pertinentes.
Actividades del Anlisis de Requerimientos.
Durante el anlisis de requerimientos se llevan a cabo las siguientes actividades:
1. Definicin de secuencias de transacciones basadas en los procesos de negocio.
2. Expansin o definicin del modelo de estructura de objetos para objetos entidad.
3. Dibujo de diagramas de ciclo de vida para objetos entidad.
4. Particionamiento del espacio del problema.
El proceso de produccin de la especificacin de requerimientos comprende dos corrientes principales:
El anlisis de la funcionalidad requerida del nuevo sistema. Esto se documenta utilizando secuencias de transaccin.
El anlisis de la estructura de objetos entidad para soportar dicha funcionalidad. Esto es documentado utilizando el
modelo de objetos.
Estas dos actividades pueden realizarse en paralelo, y no existe un criterio estricto sobre que modelo debe desarrollarse
antes.
Para sistemas "intensivos en datos", el modelado de las relaciones de objetos y atributos es particularmente importante.
Para sistemas "algortmicamente intensivos" o en proyectos de "reingeniera de negocios", el modelado de la
funcionalidad, representado por secuencias de transaccin en combinacin con un modelo de objetos, puede ser ms
importante.
a) Definicin de Secuencia de Transacciones.
El modelado de secuencia de transacciones incluye los siguientes pasos:
1. Identificacin de las secuencias de transacciones requeridas.
2. Definicin del contexto del negocio.
3. Descripcin del camino estndar.
4. Descripcin de caminos alternativos. Identificacin de s ecuencias de trans acciones. Identificacin a travs de
actores.
Identificar los actores que se comunicarn con el sistema. Los actores pueden ser personas humanas o interfaces con
otros sistemas.
Para cada actor identificado considerar que es lo que el actor realizar con el sistema, utilizando secuencias de
transacciones para describir esto. Es til considerar:
o Cuales son las principales tareas del actor.
o Qu accesos (lectura o escritura) requiere el actor del sistema.
23
23
En los puntos donde los actores inician o se comunican son secuencias de transacciones, existe a menudo intercambio de
datos. El actor suministra datos al sistema, o el sistema brinda datos al actor.
Es importante identificar que datos son pasados. Estos datos pueden ser descritos utilizando clases de objetos interface
(que se corresponde con pantallas, ventanas, reportes). Es necesario identificar clase de objetos interfaces cuyos datos son
suministrados a los actores o recibidos desde ellos.
El proceso de definicin de interfaces puede asistirse con el modelado de prototipos. Sin embargo, debe aclararse que el
modelado final de los objetos interfaces debe posponerse hasta la etapa de diseo lgico.
b) Expandiendo el Modelo de Estructura de Objetos.
El principal objetivo del modelado de estructura de objetos en esta fase es producir un modelo completo de objetos
entidad. Dependiendo en cuan detallado fue el anlisis del negocio, puede que solo sea necesario expandir y refinar el
modelo de estructura de objetos.
Pasos en el modelado de estructura de objetos para el anlisis de requerimientos.
1. Determinar los objetos entidad candidatos y agregarlos al modelo.
2. Agregar relaciones estticas entre objetos entidad.
3. Completar la definicin bsica para cada objeto entidad:
Definiendo el conjunto bsico de atributos.
Definiendo atributos de identificacin.
Definiendo restricciones.
Identificando operaciones donde se requieran.
4. Agregar estructuras de herencia para los objetos entidad.
5. Agregar estructuras de agregacin para los objetos entidad.
6. Refinar las relaciones estticas tomando en cuenta las estructuras de herencia y agregacin.
c) Definicin de ciclos de vida de Objetos.
Cada vez que se agrega una nueva clase al modelo de estructura de objetos, debe examinarse si no es necesario dibujar un
diagrama de ciclo de vida para dicha clase.
d) Uso de Diagramas de Modelo Global.
Los diagramas de modelado global tienen dos usos durante el anlisis de requerimientos, ambos vinculados con el manejo
de la complejidad:
Particionamiento del espacio del problema para sistemas muy grandes.
Representacin de requerimientos del sistema a un nivel general (como el diagrama de contexto).
Prof.: Oscar Nez M.
24
Diseo Lgico.
El propsito del diseo lgico es producir un modelo de diseo completo para el sistema, relativamente libre de
restricciones detalladas de implementacin.
Relaciones entre el diseo lgico y el fsico.
El objetivo del diseo lgico es producir un diseo que requiera pequeos cambios durante el diseo fsico para ser
implementado. El objetivo de esto es obtener un modelo de implementacin "portable" a diferentes escenarios de
implementaci n (estilos de interfaces, lenguajes, dbms, sistemas operativos, hardware, etc.).
Sin embargo, se recomienda que antes de empezar el diseo lgico se tomen ciertas decisiones estratgicas incluyendo:
Sistemas de computacin a utilizar.
Bases de datos.
Interface de usuario.
Lenguaje de programacin.
Librera de clases a utilizar.
Trabajos planeados para ejecutar en modo batch.
Criterios de performance.
Estrategias con respecto al manejo de errores, administracin de memoria (garbage collection).
Requerimientos de distribucin esperados.
Actividades realizadas durante el diseo lgico.
Las siguientes actividades se llevan a cabo durante el diseo lgico:
Identificacin de objetos interface y de control.
Identificacin de operaciones.
Uso de diagramas de interaccin de objetos para validar el diseo.
Refinado del modelo de estructura de objetos.
Refinado del modelo de ciclo de vida de objetos.
Definicin de subsistemas.
Muchas actividades del diseo lgico toman las secuencias de transacciones como punto de partida. El anlisis de las
secuencias de transacciones es utilizado para identificar que objetos de interfaz y de control deben agregarse al modelo de
objetos. Dibujando diagramas de interaccin de objetos individuales para cada secuencia de transacciones se asiste en la
identificacin de operaciones de las clases de objetos.
Identificacin de Objetos de Interface y de Control.
Cmo identificar objetos interfaz.
Los objetos interfaz pueden identificarse siguiendo los siguientes pasos:
1. Asignar un objeto interfaz central por cada combinacin secuencia de transaccin / actor / dispositivo. P.E. un
supervisor de bodega puede utilizar una interface GUI (Graphical User Interface, interface grfica de usuario) de pantalla
para controlar movimientos de stock y una impresora para imprimir detalles de movimientos. Para estas actividades se
pueden identificar dos objetos interfaz.
2. Para una interfaz GUI, asignar un objeto interfaz por ventana. Los objetos interface se comunican con el objeto
interface central identificado en el punto anterior. No es conveniente identificar objetos interfaz para cada componente
individual de la ventana (botones, listas, etc.), ya que esto es manejado normalmente por los constructores de interfaces
(p.e. Visual Basic).
3. Para otro tipo de dispositivos, puede ser til identificar un objeto interface central, el cual maneja el tipo particular de
salida, y definir objetos interfaz adicionales para variantes especficas. P.E. puede definirse un objeto interfaz central para
manejar los requerimientos de impresin, con objetos interfaz asociados para tipos individuales de impresoras (de matriz
de puntos, de inyeccin o lser, etc.)
4. Objetos interfaz pueden modelar protocolos de comunicacin por capas como el modelo ISO. Un objeto interfaz se
define por cada capa, el cual se comunica solo con objetos de la capa superior e inferior inmediata.
Prof.: Oscar Nez M.
25
25
Una operacin es un proceso que se puede requerir como una unidad a un objeto. Una misma operacin puede estar
disponible para objetos de diferentes clases.
Una misma operacin define un servicio que es ofrecido. Esta definicin incluye una descripcin de la semntica de la
operacin, y una descripcin de la sintaxis (como debe ser invocado el servicio). La semntica central de una operacin
debe ser siempre la misma independientemente de la clase de objeto que la implemente. La sintaxis indica la informacin
que debe suministrarse en orden de invocar la operacin, esto es el nombre y sus parmetros de entrada/salida.
Un mtodo es una implementacin de una operacin para una clase especfica, y puede variar para cada clase.
Notacin de punto.
Tanto para especificar atributos como operaciones durante el diseo lgico puede utilizarse la "notacin de punto".
Objeto.atributo u Objeto.operacin
Ejemplo:
DocumentoAutor Especifica el atributo autor del objeto documento
Auto.Conductor.Nombre Especifica el nombre de la persona que conduce el auto. Aqu Conductor identifica la relacin
entre las clases Auto y Persona.
Cmo identificar operaciones.
Existen tres posibles maneras de identificar operaciones:
1. Considerando el rol y responsabilidades de cada clase de objetos, usando los enfoques basados en el anlisis de las
secuencias de transacciones o en el enfoque de "lista de compras".
2. Identificando las interacciones de objetos requeridas para soportar cada secuencia de transacciones, con la asistencia de
los diagramas de interaccin de objetos.
3. Analizando los ciclos de vida de objetos y determinando las operaciones que ellos implican.
Los tres enfoques son valiosos y pueden ser utilizados en combinacin. Cualquiera sea el enfoque utilizado, los puntos
clave a considerar son:
Cmo puede una funcionalidad dividirse entre operaciones?
Qu clase de objeto es responsable de una determinada operacin?
1. Considerando roles y responsabilidades para cada clase de objetos
Acorde con Wirfs-Brock, cada clase de objetos debe tener un rol o funcin simple y coherente claramente definido. En
soporte de dicho rol, un objeto toma ciertas responsabilidades y comportamiento que es lgico que otros objetos esperen
de l. Las operaciones que un objeto tiene le permiten cumplir con sus responsabilidades.
Las responsabilidades y por lo tanto las operaciones, son identificadas analizando los requerimientos del sistema
representados en las secuencias de transacciones.
Habiendo identificado los primeros objetos entidad, interface, y control, podemos ahora considerar cada secuencia de
transacciones en orden de identificar que operaciones deben asignarse a cada clase de objetos.
Para realizar esto es conveniente utilizar un diagrama de estructura de objetos que contenga las clases relevantes a la
secuencia de transacciones que se analiza.
Prof.: Oscar Nez M.
26
de vida no revelan todas las operaciones, ya que en estos diagramas normalmente solo se modelan los eventos que
producen cambios de estado.
Especificacin de la semntica y sintaxis de las operaciones.
Debe definirse la semntica de cada operacin identificada. El nombre, la sintaxis, y la semntica deben proveer toda la
informacin que un usuario de la operacin necesito para decidir cuando utilizarla o no.
La especificacin de la semntica puede expresarse en forma de texto, tablas de decisin, pseudocdigo, etc. Deben
especificarse las precondiciones y postcondiciones de las operaciones como parte de la definicin.
Tambin debe especificarse la sintaxis de la operacin, los argumentos de entrada/salida requeridos. Puede definirse el
tipo y dominio de cada argumento, como as tambin si es opcional o mandatario.
Operaciones de clase.
Una operacin puede ser definida como operacin de clase. Una operacin de clase es una operacin que es invocada por
la clase misma no por las instancias. Tales operaciones pueden por ejemplo retornar informacin estadstica sobre los
objetos instanciados de dicha clase (promedios, totales, etc.). Un objeto particular puede ser creado durante el diseo
fsico si el lenguaje utilizado no soporta operaciones de clase.
Herencia de operaciones.
Operaciones concretas, abstractas y templados.
Prof.: Oscar Nez M.
27
27
Diseo Fsico.
El propsito del diseo fsico es agregar los detalles tcnicos dependientes de la plataforma, requeridos para construir el
sistema a partir del diseo lgico.
Las principales actividades del diseo fsico son:
1. Establecimiento de la arquitectura del sistema.
2. Implementacin de las clases del dominio del problema del sistema.
3. Construccin de la interface de usuario.
4. Diseo e implementacin del componente de administracin de datos.
5. Diseo de la integracin con sistemas existentes (legacy systems)
Arquitectura del sistema.
La arquitectura del sistema es la organizacin general del sistema en componentes (o subsistemas).
Como se ha mencionado, es til y comn dividir sistemas grandes y complejos en susbsistemas para facilitar su desarrollo.
Pero adems es til dividir un sistema de cualquier tamao en subsistemas basados en consideraciones arquitecturales que
son especficamente relevantes durante la fase de diseo fsico de la aplicacin.
Un sistema puede particionarse vertical y horizontalmente (en capas). Las particiones verticales son utilizadas para
subdividir la funcionalidad de la funcionalidad. En tanto que las particiones horizontales son utilizadas particularmente
para aislar dependencias del sistema operativo, bases de datos, o hardware. La subdivisin en capas horizontales asiste en
el salvaguardo de la portabilidad del sistema.
Las particiones verticales deben estar dbilmente acopladas y trabajar en configuracin cliente/servidor o peer-to-peer. Las
capas horizontales estn en una relacin cliente-servidor, donde las capas ms bajas (servidores) suministran servicios a
las capas superiores (clientes).
La arquitectura del sistema puede diagramarse utilizando diagramas de visin general (diagrama global del sistema). Estos
diagramas muestran subsistemas y los servicios que se proveen mutuamente.
El presente enfoque de desarrollo orientado a objetos recomienda la siguiente arquitectura de seis componentes:
Componente Dominio de Problema (PDC)
Representa la parte del sistema que corresponde con el dominio del problema (mundo real). Consiste de todos los objetos
entidad y de control identificados durante las fases previas.
Componente de Interaccin Humana (HIC)
Consiste de todos los objetos requeridos para la implementacin de la interface de usuario. Se corresponde con los objetos
intefaz con usuarios humanos identificados durante las fases previas.
Componente de Interfaces Externas (EIC)
Consiste de todos los objetos intefaz con usuarios no humanos, como ser sistemas externos, dispositivos, impresoras,
etc.
Componente de Administracin de Datos (DMC)
Provee la infraestructura para el almacenamiento y recuperacin de los objetos persistentes en algn medio de
almacenamiento.
Componente de Administracin de Tareas (TMC)
Se encarga de administrar concurrencia cuando es necesaria. La utilizacin de este componente es muy rara en sistemas
administrativos, siendo de utilidad solo en algunos sistemas en tiempo real.
Componente de Servicio de Utilidades (USC)
Prof.: Oscar Nez M.
28
28
Para cada objeto persistente debe identificarse un identificador unvoco (Object ID; Clave Primaria). La aplicacin misma
es responsable de la generacin y administracin de este Object ID. Para la generacin de este Object ID pueden utilizarse
atributos de identificacin definidos durante el diseo lgico.
Los atributos compuestos deben separarse en sus componentes atmicos.
Las relaciones estticas entre clases pueden realizarse a travs de la implementacin de claves forneas. En general, se
tiene tres alternativas para el mapeo de relaciones:
1. Cualquier relacin (cualquiera sea su cardinalidad) puede siempre mapearse como una tabla separada en la cual cada
fila contiene un par de Object ID y se corresponde con una instancia de la relacin.
2. Relaciones uno-a-muchos o uno-a-uno, pueden mapearse incluyendo claves forneas en una de las tablas relacionadas.
3. Para relaciones uno-a-uno existe una tercera alternativa que consiste en combinar las tablas relacionadas en una sola.
Para el mapeo de agregaciones, se aplican las mismas reglas que para las relaciones estticas, ya que en realidad son un
caso particular de las mismas.
Para el mapeo de jerarquas de herencia existen tres alternativas:
1. Cada clase de la jerarqua es mapeada a una tabla separada. Todas comparten un mismo Object ID, y tienen una
columna para cada atributo propio de la clase.
2. Cada clase no abstracta en la jerarqua es mapeada a una tabla separada que contiene una columna adicional para cada
atributo heredado.
3. Todas las clases en la jerarqua son mapeadas a una nica tabla agregndose columnas para todos los atributos de la
jerarqua.
29
29