Embed Size (px)
Citation preview
Av. Francisco de Miranda. Torre KPMG. Piso 1, Chacao – Caracas –Venezuela Telf: (58-212) 267.56.70 Caracas Master Fax: (58-212) 263. 27. 31, Maracaibo (58-261) 798.60.32, Valencia (58-241) 823.85.33,
Pto La Cruz (58-281) 909.96.97 www.corporacionsybven.com
Modelos PowerDesigner
Caracas - Venezuela
FO-SYB-014 / Rev. 3 / 07-01-08 2/17
Modelos de PowerDesigner
PowerDesigner le ofrece a los analistas y diseñadores de software herramientas
poderosas para mejorar el proceso de construcción de software. Una de sus
características principales es la gran variedad de modelos, acordes a las necesidades de
cada rol. Entre los tipos de modelos están: Modelos de Datos, de procesos, de UML, de
requerimientos, de Arquitectura Empresarial y de replicación. A continuación se listan
algunos de ellos:
Modelos de Datos.
Conceptual Data Model (CDM): sirve para realizar un esquema o descripción de
alto nivel de la estructura de los datos de un sistema independientemente de la
implementación física de la misma e independiente de los manejadores de bases
de datos Se puede hacer hin.capié en los detalles de diseño porque no se tiene
que preocupar sobre los detalles de implementación.
Physical Data Model (PDM): El PDM es una herramienta de diseño de base de
datos para definir la implementación de las estructuras físicas y queries de datos.
Se utiliza para diseñar la estructura de una base de datos que manejar grandes
cantidades de datos operativos. Por lo general, el análisis físico sigue del análisis
conceptual de modelado de datos. En la etapa física, el diseñador considera los
FO-SYB-014 / Rev. 3 / 07-01-08 3/17
detalles de la implementación física real de los datos en una base de datos. Se
puede utilizar un PDM para diseñar la estructura de Data Warehouse.
SAP Sybase PowerDeisgner soporta la mayoría de las bases de datos relacionales
del mercado, más de 80 RDBMS. Permite realizar desnormalizaciones y
transformaciones hacia esquemas óptimos para aplicaciones tradicionales OLTP o
aplicaciones OLAP Warehouse.
Ofrece tecnologías de generación de SQL DDL e Ingeniería reversa de bases de
datos existentes, y Sincronización directa a cambios con las bases de datos
vinculadas.
Diagrama Multidimensional: es un modelo de actividades de negocio en términos
de cubos y dimensiones. Organiza los datos del negocio en una de estas
categorías. Valores numéricos como el total de ventas y límites de gastos, son
hechos del negocio (cubos). El área cubierta por un negocio, en términos de
geografía, tiempo o productos son las dimensiones del mismo. D
El diagrama multidimensional se utiliza para diseñar una base de datos OLAP. La
información contenida en una base de datos OLAP se organizan para facilitar las
consultas realizadas por diferentes herramientas. Documentan el ambiente DW con
objetos multidimensionales enlazados a tablas físicas y con la posibilidad de
mostrar jerarquías, jerarquías virtuales y mucho más.
FO-SYB-014 / Rev. 3 / 07-01-08 4/17
Modelos de Procesos
Business Process Model (BPM): provee una vista grafica de que hace (o que
debería hacer) la organización y como la información fluye a través de esas
actividades. Un BPM es un modelo conceptual, que proporciona una descripción
final de la lógica de negocio y las reglas desde el punto de un socio de negocios de
vista. Se utiliza un diagrama que muestra las interacciones entre los procesos,
flujos, mensajes y protocolos de colaboración de uno o varios puntos de inicio a
varios puntos finales potenciales.
Modelos UML
Object Oriented Model (OOM)
Diagrama de Clases: es el diagrama principal para el análisis y
diseño. Un diagrama de clases es un diagrama UML que contiene
FO-SYB-014 / Rev. 3 / 07-01-08 5/17
clases, interfaces, paquetes y sus relaciones, y que provee una vista
lógica del sistema de software en su totalidad. Los diagramas de
clases son utilizados durante el proceso de análisis y diseño de los
sistemas, donde se crea el diseño conceptual de la información que
se manejará en el sistema, y los componentes que se encargaran del
funcionamiento y la relación entre uno y otro.
0..*
peripheral
0..1
personalcomputers <<Persistent>>
parallelPeripheral
+
+
+
periphId
periphCodeName
vendorName
: String
: String
: String
+
+
+
+
registerPeriph ()
testPort ()
testPwSupply ()
testMotherBd ()
: void
: void
: void
: void
printer
+
+
laser
printSpeed
: boolean
: int
+ printPage () : void
scanner
+
+
flatBed
resolution
: boolean
: int
+
+
+
+
+
preview ()
registerPeriph ()
testPort ()
testPwSupply ()
testMotherBd ()
: void
: void
: void
: void
: void
Peripheral
+
+
+
+
registerPeriph ()
testPort ()
testPwSupply ()
testMotherBd ()
: void
: void
: void
: void
peripheral tester
+
+
+
test #
testName
testDate
: int
: String
: java.util.Date
+ printReport () : void
Computer
+
+
serial #
ownerName
: String
: String
Diagrama de objetos: es un diagrama UML que describe la
estructura de los elementos de un modelo y no su comportamiento. El
diagrama de Objetos representa las instancias de las clases,
instancias de asociaciones y dependencias entre los mismos. Utilizan
una notación similar a los diagramas de clases y se utilizan para
ilustrar una instancia de una clase en un momento dado. Imagine que
desea dibujar un diagrama de objetos para ilustrar un ejemplo real de
una clase y de sus relaciones. Los diagramas de objetos pueden
ayudar a explicar las clases y su herencia.
Un objeto también se pueden entender como la descripción de un
individuo que forme parte de un grupo.
FO-SYB-014 / Rev. 3 / 07-01-08 6/17
Diagrama de Paquetes: Un paquete es un mecanismo utilizado para
agrupar elementos de UML. Es un diagrama UML que describe la
estructura de paquetes de una aplicación.
Muestra cómo un sistema está dividido en agrupaciones lógicas
mostrando las dependencias entre esas agrupaciones. Dado que
normalmente un paquete está pensado como un directorio, los
diagramas de paquetes suministran una descomposición de la
jerarquía lógica de un sistema
FO-SYB-014 / Rev. 3 / 07-01-08 7/17
Diagrama de Caso de Uso: es un diagrama UML de alto nivel que
permite analizar requerimientos y el comportamiento del sistema. Es
parte del modelo Orientado a Objetos, y modela gráficamente la
funcionalidad del sistema en casos de uso, y como los usuarios
externos, llamados actores, interactúan con ellos.
Con un diagrama de casos de uso, es posible visualizar de inmediato
la funcionalidad del sistema. Detalles adicionales pueden ser
agregados al diagrama si se deben especificar ciertos puntos
relacionados al comportamiento del sistema.
PowerDesigner permite construir este modelo ofreciéndole al usuario
la posibilidad de agregar la especificación de cada caso de uso y
seleccionar las clases que permiten implementarlo, siempre y cuando
se hayan definido en un diagrama de clases.
<<includes>>
<<includes>>
Logon
Logoff
Customer
Ship To Address
Purchase
Display Catalog
List Orders
List Cart
News
Purchase Products
Main Use Case
Shipping
Diagrama de Comunicación: es un diagrama UML de interacción.
Describe una meta particular a través de ciertas interacciones
cronológicas entre los objetos. Los diagramas de comunicación son
similares a los de secuencia, pero ofrecen una visión de conjunto de
las relaciones entre los objetos, en lugar de centrarse en el orden de
los mensajes, a medida que se ejecuta el software.
FO-SYB-014 / Rev. 3 / 07-01-08 8/17
Diagrama de Secuencia: es un diagrama UML de interacción.
Representa la cronología referente a la transferencia.
Es un diagrama UML de interacción. Representa la cronología
referente a la transferencia de mensajes entre objetos del sistema y
sus actores. En un diagrama de secuencia se indicarán los módulos o
clases que forman parte del programa y las llamadas que se hacen
en cada uno de ellos para realizar una tarea determinada.
Se realizan diagramas de secuencia para definir acciones que se
pueden realizar en la aplicación en cuestión. Así, en el caso de una
aplicación para jugar al ajedrez, se podrían realizar diagramas de
secuencia para “jugar una partida” o bien para acciones más
específicas como “mover pieza”.
FO-SYB-014 / Rev. 3 / 07-01-08 9/17
Diagrama de Interacción: Modela el comportamiento dinámico de un
sistema. El diagrama de interacción, representa la forma en cómo un
Cliente (Actor) u Objetos (Clases) se comunican entre sí en petición a
un evento. Esto implica recorrer toda la secuencia de llamadas, de
donde se obtienen las responsabilidades claramente.
Diagrama de Actividad: es un diagrama UML que modela los
aspectos dinámicos de un sistema. Constituye una simplificación del
diagrama “StateChart” o de estado, para modelar los flujos de control
en los procesos organizacionales o computarizados.
Se utiliza para mostrar una visión simplificada de lo que ocurre
durante una operación o proceso, lo que permite describir como un
sistema implementa su funcionalidad.
FO-SYB-014 / Rev. 3 / 07-01-08 10/17
Diagrama de Estado o Statechart Diagram: es un diagrama UML
que describe una “Máquina de Estado” sobre el comportamiento de
un componente o clase. El comportamiento es descrito a través de
cambios en el tiempo o cambios de estado y a través de los eventos
que permiten esa transición. Se necesitan cuando un objeto tiene una
diferente reacción dependiendo de su estado. El patrón de diseño de
estado usa polimorfismo para definir el comportamiento.
Diagrama de Componente: es un diagrama UML que representa las
dependencias entre los componentes de software, incluyendo
componentes de código fuente, componentes de código binario y
componentes ejecutables.
Un diagrama de componentes representa cómo un sistema de
software es dividido en componentes y muestra las dependencias
entre estos componentes.
Los componentes físicos incluyen archivos, cabeceras, bibliotecas
compartidas, módulos, ejecutables, o paquetes. Los diagramas de
Componentes prevalecen en el campo de la arquitectura de
software pero pueden ser usados para modelar y documentar
cualquier arquitectura de sistema.
FO-SYB-014 / Rev. 3 / 07-01-08 11/17
Diagrama de Implementación: es un diagrama UML que
complementa el diagrama de componentes a través de detalles más
precisos sobre la implementación física y la interacción entre los
componentes. Muestran los aspectos físicos del sistema. Incluyen la
estructura del código fuente y la implementación, en tiempo de
implementación.
FO-SYB-014 / Rev. 3 / 07-01-08 12/17
Modelos de Requerimientos
Requirements Model (RQM): describe un proyecto listando y explicando de forma
precisa que acciones deben ser implementadas durante el proceso de desarrollo.
En la práctica es común describir los requerimientos en un documento llamado
Especificación de Requerimientos del Software.
Modelos de Replicación de datos
Information Liquidity Model (ILM): en una herramienta de diseño poderosa que
permite simplificar el diseño y la configuración del motor de replicación y permite
diseñar y documentar las transformaciones de datos (ETL y EII)
FO-SYB-014 / Rev. 3 / 07-01-08 13/17
Modelos de Arquitectura Empresarial.
Organization Chart: una Tabla organizacional representa la estructura de una
organización en un árbol gráfico. Puede ser usado para analizar y mostrar las
relaciones entre las unidades organizacionales (divisiones, grupos, equipos, etc.),
individuos y roles en una organización.
Business Communication Diagram: un Diagrama de Comunicación del Negocio
es usado para analizar y definir las relaciones, flujos y otras conexiones existentes
entre todos los elementos del negocio tanto a internos como externos
(proveedores, clientes, sedes, etc.).
FO-SYB-014 / Rev. 3 / 07-01-08 14/17
Process Map Diagram: un Diagrama de Mapeo de Procesos es usado para
identificar la independencia de la arquitectura del negocio, de la gente y de las
unidades organizacionales y para describir las funciones de negocio a través de la
clasificación de sus procesos. Es una forma fácil de entender los procesos a todo
nivel de la empresa, que representen la situación particular o propia de la
organización, y donde primordialmente se identifican las interrelaciones de los
procesos como mecanismo para mejorar las comunicaciones.
City Planning Diagram: un diagrama de planeación de ciudad ofrece una vista
gráfica del panorama de la arquitectura de su empresa, utilizando la metáfora de la
planificación de la infraestructura de una ciudad para representar a la organización
de los sistemas, aplicaciones, etc en las áreas de arquitectura.
FO-SYB-014 / Rev. 3 / 07-01-08 15/17
Application Architecture Diagram: un Diagrama de Arquitectura de Aplicación
muestra a un alto nivel la arquitectura de la aplicación, permitiendo identificar
aplicaciones, sub-aplicaciones, componentes, bases de datos, servicios, etc. y sus
interacciones.
FO-SYB-014 / Rev. 3 / 07-01-08 16/17
Service Oriented Diagram: un Diagrama Orientado a Servicios le permite asociar
las aplicaciones y otros objetos de la capa de aplicación con servicios de negocio y
otros objetos en la capa de negocio para apoyar un diseño basado en SOA.
Permite la creación de sistemas de información altamente escalables que reflejan
el negocio de la organización, a su vez brinda una forma bien definida de
exposición e invocación de servicios (comúnmente pero no
exclusivamente servicios web), lo cual facilita la interacción entre diferentes
sistemas propios o de terceros.
Technology Infrastructure Diagram: un Diagrama de Infraestructura Tecnológica
muestra a un alto nivel la arquitectura física desplegada en la empresa. Permite
obtener una comprensión de la infraestructura tecnológica existente a través de
una revisión de los sistemas existentes y/o de la red actual de comunicaciones,
Identificar las debilidades y los riesgos inherentes a la infraestructura de la
tecnología actual y las oportunidades que se abordarán en la infraestructura de las
nuevas tecnologías.
FO-SYB-014 / Rev. 3 / 07-01-08 17/17
Modelo Libre
Free Model (FRM): permite crear cualquier tipo de diagrama o tabla en un
ambiente libre de contexto.
