Ingeniería en Sistemas Computacionales
Análisis y Diseño Orientado a Objetos
Grupo: 5851
1.- Modelos
1.1 Modelo de Estructura de Objetos (OSM)
1.2 Modelado de Procesos de Negocios y Secuencias de Transacciones.
2.- Clases de Java Lang
1.1 Mapeo entre tipo primitivo y
su clase envoltura
Modelo de Estructura de Objetos (OSM)
Conceptos y propósito del modelo de estructura de objetos
El OSM es el modelo fundamental que provee un medio uniforme para modelar el sistema desde la captura de requerimientos en la etapa inicial del análisis hasta la implementación, atravesando todo el ciclo de desarrollo del sistema.
Este modelo identifica :
· las clases de objetos en la aplicación
· 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 análisis y diseño, el OSM es definido en sucesivos niveles incrementales de detalle, hasta que el nivel necesario para la implementación es alcanzado.
Todos los demás modelos capturan detalles que alimentan es modelo.
El desarrollo de OSM es un proceso aditivo, diferenciándose esto del enfoque transformacional característico de otros métodos como el estructurado, donde los DFD del análisis son transformados en diagramas de estructura durante el diseño, con los consiguientes problemas que esto acarrea.
Durante el ciclo de desarrollo se aportan los siguientes elementos al modelo:
· Análisis del Negocio: se reconocen objetos claves del negocio y generan las abstracciones en las clases apropiadas (objetos entidad).
· Análisis de Requerimientos: se identifican asociaciones estructurales entre objetos y nuevas clases (entidad).
· Diseño lógico: Se incorporan todas las clases necesarias para la aplicación incluyendo los objetos de interfaz y de control.
· Diseño Físico: se incorporan todos los detalles remanentes para la implementación física de cada clase de objetos.
Componentes del modelo de estructura de objetos.
El componente básico del OSM es la clase de objetos.
Se distinguen tres tipos de clases:
· Objetos Entidad
· Objetos de Interfaz
· Objetos de Control.
Para cada clase identificada se describen:
· Operaciones
· Atributos
· Restricciones
Adicionalmente el OSM describe las asociaciones entre objetos o clases de objetos. Se distinguen los siguientes tipos de asociaciones:
· Relaciones Estáticas
· Herencia
· Agregación
·
Comunicación por mensajes
Modelado de Procesos de Negocios y Secuencias de Transacciones.
Conceptos y propósito del modelo de p. de negocios y sec. de trans.
Los requerimientos para una aplicación de negocios deben basarse en las actuales actividades del negocio, que la aplicación deberá soportar.
El Modelo de Procesos de Negocios (BPM) es usado durante el análisis del negocio (análisis del sistema actual) y provee un medio para describir el negocio.
El Modelo de Secuencia de Transacciones (TSM) es usado durante el análisis de requerimientos del negocio y provee un medio para describir la funcionalidad requerida de la aplicaciones para soportar los procesos de negocios.
El enfoque en los procesos de negocio durante el análisis del negocio provee el punto de partida para determinar qué se requiere de la aplicación.
Durante el análisis de requerimientos decidimos qué parte de los procesos de negocio deben computarizarse y describimos dichos requerimientos usando una o más secuencias de transacción (determinación de las fronteras de automatización).
Las secuencias de transacciones modelan que es lo que el usuario requiere de la aplicación (su contenido funcional).
Las secuencias de transacciones proveen la navegabilidad desde lo requerimientos del usuario a los objetos y operaciones que implementan dicha funcionalidad.
Las secuencias de transacciones proveen también un medio adecuado para comunicarse con el usuario en un leguaje y nivel de abstracción que él pueda comprender con facilidad.
Como parte del proceso de Diseño Lógico, las secuencias de transacciones son analizadas para identificar como los objetos y sus operaciones proveen la funcionalidad requerida por una secuencia de transacciones.
Posteriormente, durante el proceso de testeo de la aplicación, sirven de base para definir casos de testeos.
Proceso de Negocio
Un proceso de negocios es una colección de actividades que toman uno o más tipos de entrada, y crea una salida de valor para el cliente.
Un proceso de negocios describe desde el comienzo al fin la secuencia de eventos requeridos para producir un resultado de negocio significativo.
El cliente puede ser externo o interno a la organización.
Los procesos de negocio típicamente atraviesan los límites de la organización y de sus departamentos internos, evitando la clásica visión de compartimentos estancos. Por este motivo, cualquier modificación drástica a un proceso de negocio implica un cambio en la estructura organizacional.
Como identificar y definir procesos de negocio?
1. Se identifican los productos/servicios significantes de los que es responsable el negocio y se asocia cada uno de ellos a uno o más 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 servicios.
Secuencia de Transacciones
El concepto de secuencia de transacciones es muy similar al concepto de Caso de Uso introducido por Jacobson en su metodología OOSE y de amplia difusión actualmente.
Una secuencia de transacciones es conceptualmente similar a un proceso de negocio. 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 aplicación que soportará determinados procesos de negocios.
Los procesos de negocio son trasladados en secuencias de transacciones durante el análisis 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 más de un usuario y función y puede extenderse en el tiempo, esto es no tener resolución inmediata.
El proceso de identificar requerimientos del usuario y secuencias de transacciones puede asistirse con la prototipación de interfaces.
Como identificar y definir secuencias de transacciones?
1. Identificación a través de actores
1. Identificar los actores que se comunicarán con el sistema.
2. Para cada actor considerar:
1. Cuales son las principales tareas del actor
2. Qué accesos (lectura o escritura) requiere el actor del sistema
3. Cuando el actor informará al sistema acerca de cambios fuera del sistema
4. Cuando el actor será informado de cambios a través del sistema
2. Identificación a través de eventos
Consiste en identificar a que eventos externos o temporales debe ser capaz de responder el sistema:
2.1 Confeccionar la lista de eventos.
2.2 Asociar una secuencia de transacciones para cada evento identificada.
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:
1. Diagrama de secuencia de transacciones (TSD)
2. Descripción textual
3. Diagrama de Interacción de Objetos (OID)
4.
Diagrama de Flujo de Actividad (AFD)
Clases de Java Lang
MAPEO ENTRE TIPO PRIMITIVO Y SU CLASE ENVOLTURA
La clase envoltura tiene el mismo nombre que el tipo de datos primitivo, (con la primera letra Mayuscula)
|
TIPO PRIMITIVO |
ENVOLTURA |
|
byte |
Byte |
|
short |
Short |
|
int |
Integer |
|
long |
Long |
|
char |
Carácter |
|
float |
Float |
|
double |
Double |
|
bolean |
Boolean |
Para realizar la conversión de tipo primitivo a tipo no primitivo.
String miCadena=”#12345”
Int miEntero=Integer.parserInt(miCadena)
byte_Byte.parseByte(a String)
short_Short.parseShort(a String)
int_Integer.parseInt(a String)
long_Long.parseLong(a String)
float_Float.parseFloat(a String)
double_Double.parseFloat(a String)
boolean_Boolean.parseBoolean(a String)
EXCEPCIÓN: Clase Character no tiene dicho método se tiene que preguntar al String por el carácter con el método charAt Ejemplo:
String Hola=”Hola”;
Char e=Hola.charAt(1);
E=H ß número de posición.
LENGUAJE UML (LENGUAJE DE
MODELADO UNIFICADO)
El
Lenguaje Unificado de Modelado preescribe un conjunto de notaciones y diagramas
estándar para modelar sistemas orientados a objetos, y describe la semántica
esencial de lo que estos diagramas y símbolos significan. Mientras que ha
habido muchas notaciones y métodos usados para el diseño orientado a objetos,
ahora los modeladores sólo tienen que aprender una única notación.
UML se
puede usar para modelar distintos tipos de sistemas: sistemas de software,
sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve
diagramas en los cuales modelar sistemas.
·
Diagramas de
Casos de Uso para modelar los procesos 'business'.
·
Diagramas de
Secuencia para modelar el paso de mensajes entre objetos.
·
Diagramas de
Colaboración para modelar interacciones entre objetos.
·
Diagramas de
Estado para modelar el comportamiento de los objetos en el sistema.
·
Diagramas de
Actividad para modelar el comportamiento de los Casos de Uso, objetos u
operaciones.
·
Diagramas de
Clases para modelar la estructura estática de las clases en el sistema.
·
Diagramas de
Objetos para modelar la estructura estática de los objetos en el sistema.
·
Diagramas de
Componentes para modelar componentes.
·
Diagramas de
Implementación para modelar la distribución del sistema.
UML es una consolidación de muchas de las
notaciones y conceptos más usadas orientados a objetos. Empezó como una
consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson,
creadores de tres de las metodologías orientadas a objetos más populares.
En 1996, el Object Management Group (OMG),
un pilar estándar para la comunidad del diseño orientado a objetos, publicó una
petición con propósito de un metamodelo orientado a objetos de semántica y
notación estándares. UML, en su versión 1.0, fue propuesto como una respuesta a
esta petición en enero de 1997. Hubo otras cinco propuestas rivales. Durante el
transcurso de 1997, los seis promotores de las propuestas, unieron su trabajo y
presentaron al OMG un documento revisado de UML, llamado UML versión 1.1. Este
documento fue aprobado por el OMG en Noviembre de 1997. El OMG llama a este
documento OMG UML versión 1.1. El OMG está actualmente en proceso de mejorar
una edición técnica de esta especificación, prevista su finalización para el 1
de abril de 1999.
UML preescribe una notación estándar y
semánticas esenciales para el modelado de un sistema orientado a objetos.
Previamente, un diseño orientado a objetos podría haber sido modelado con
cualquiera de la docena de metodologías populares, causando a los revisores
tener que aprender las semáticas y notaciones de la metodología empleada antes
que intentar entender el diseño en sí. Ahora con UML, diseñadores diferentes
modelando sistemas diferentes pueden sobradamente entender cada uno los diseños
de los otros.
Aun así, UML no preescribe un
proceso o método estándar para desarrollar un sistema. Hay varias metodologías
existentes; entre las más populares se incluyen las siguientes:
·
Catalysis: Un método orientado a objetos que fusiona
mucho del trabajo reciente en métodos orientados a objetos, y además ofrece técnicas
específicas para modelar componentes distribuidos.
·
Objetory: Un método de Caso de Uso guiado para el
desarrollo, creado por Ivar Jacobson.
·
Shlaer/Mellor: El método para diseñar sistemas de tiempo
real, puesto en marcha por Sally Shlaer y Steven Mellor en dos libros de 1991,
Ciclos de vida de Objetos, modelando el Mundo en Estados y Ciclos de vida de
Objetos, Modelando el mundo en Datos (Prentice Hall). Shlaer/Mellor countinúan
actualizando su método continuamente (la actualización más reciente es el OOA96
report), y recientemente publicaron una guía sobre cómo usar la notación UML
con Shlaer/Mellor.
·
Fusion: Desarrollado en Hewlett Packard a mediados
de los noventa como primer intento de un método de diseño orientado a objetos
estándar. Combina OMT y Booch con tarjetas CRC y métodos formales.
(www.hpl.hp.com/fusion/file/teameps.pdf)
·
OMT: La Técnica de Modelado de Objetos fue
desarrollada por James Rumbaugh y otros, y publicada en el libro de gran
influencia "Diseño y Modelado Orientado a Objetos" (Prentice Hall,
1991). Un método que propone análisis y diseño 'iterative', más centrado en el
lado del análisis.
·
Booch: Parecido al OMT, y también muy popular, la
primera y segunda edición de "Diseño Orientado a Objetos, con
Aplicaciones" (Benjamin Cummings, 1991 y 1994), (Object-Oriented Design,
With Applications), detallan un método ofreciendo también diseño y análisis
'iterative', centrándoso en el lado del diseño.
Además, muchas organizaciones han
desarrollado sus propias metodologías internas, usando diferentes diagramas y
técnicas con orígenes varios. Ejemplos son el método Catalyst por Computer
Sciences Corporation (CSC) o el Worlwide Solution Design and Delivery Method
(WSDDM) por IBM. Estas metodologías difieren, pero generalmente combinan
análisis de flujo de trabajo, captura de los requisitos, y modelado de negocio
con modelado de datos, con modelado de objetos usando varias notaciones (OMT,
Booch, etc), y algunas veces incluyendo técnicas adicionales de modelado de
objetos como Casos de Uso y tarjetas CRC. La mayoría de estas organizaciones
están adoptando e incorporando el UML como la notación orientada a objetos de
sus metodologías.
Algunos modeladores usarán un subconjunto de
UML para modelar 'what they're after', por ejemplo simplemente el diagrama de
clases, o solo los diagramas de clases y de secuencia con Casos de Uso. Otros
usarán una suite más completa, incluyendo los diagramas de estado y actividad
para modelar sistemas de tiempo real, y el diagrama de implementación para
modelar sistemas distribuidos. Aun así, otros no estarán satisfechos con los
diagramas ofrecidos por UML, y necesitarán extender UML con otros diagramas
como modelos relacionales de datos y 'CRC cards'.