domingo, 30 de septiembre de 2012
martes, 11 de septiembre de 2012
CARACTRISTICAS DE LA GUI
Entre las principales características con las que debe contar la GUI son:
- Usable: invitar al uso. Debe integrarse de forma cómoda en el proceso de trabajo de un desarrollador dándole respuestas a situaciones propias dentro de la construcción del interfaz de una aplicación.
- Visual: huir del texto. Por experiencia, una Guía de Estilo no se usa, y esta probabilidad se reduce drásticamente cuando se basa en texto lo que lleva a una desactualización y abandono.
- Educativa: rica en ejemplos aplicables Y RAZONADOS que permitan desarrollar criterios mínimos de usabilidad y estética al personal técnico.
- Actualizada: debe contener ejemplos útiles, actuales y materiales para su aplicación directa disponibles a través de repositorios.
domingo, 9 de septiembre de 2012
1.3.- DIAGRAMACION
Modelos.
Un modelo representa a un
sistema software desde una perspectiva específica. Al igual que la planta y el
alzado de una figura en dibujo técnico nos muestran la misma figura vista desde
distintos ángulos, cada modelo nos permite fijarnos en un aspecto distinto del
sistema. Los modelos de UML que se tratan en esta parte son los siguientes:
• Diagrama de Estructura
Estática.
• Diagrama de Casos de Uso.
• Diagrama de Secuencia.
• Diagrama de Colaboración.
· Diagrama de Estados.
Diagramas
de clases
Los diagramas de clases
proporcionan una perspectiva estática del sistema (representan su diseño estructural),
son los bloques de construcción más importantes de cualquier sistema orientado
a objetos y es una descripción de un conjunto de objetos que comparten los
mismos atributos, operaciones, relaciones y semántica.
Como muestra la Figura 1.7 Esta notación
(UML) permite visualizar una abstracción independientemente de cualquier
lenguaje de programación específico y de forma que permite resaltar las partes
más importantes de una abstracción: su nombre, sus atributos y sus operaciones.
Figura 1.7: Clase
Cada clase ha de tener un
nombre que la distinga de otras clases. El Nombre es una cadena de texto. Ese
nombre sólo se denomina nombre simple. Una clase puede dibujarse mostrando sólo
su nombre.
Un atributo es una propiedad de
una clase identificada con un nombre, que describe un rango de valores que
pueden tomar las instancias de la propiedad.
Una
operación es la implementación de un servicio que puede ser requerido a
cualquier objeto de la clase para que muestre un comportamiento, En otras
palabras, una operación es una abstracción de algo que se puede hacer a un
objeto y que es compartido por todos los objetos de la clase, Una clase puede
tener cualquier número de operaciones o ninguna, en la figura 1.8 muestra el
diagrama completo del dominio conceptual de una aplicación.
1.2.- DESARROLLO ORIENTADO A OBJETOS
Enfoque
de Orientación a Objetos
El
enfoque de orientación a objetos es una forma de observar la realidad. El
enfoque como su nombre lo indica se basa en el concepto de objeto:
Es todo aquello que tiene características que lo hacen único
e indivisible dentro del entorno al que pertenece. Siempre es posible
establecer propiedades o atributos de un objeto, lo mismo que su grado de
respuesta a estímulos externos (comportamientos del objeto). percibimos tal
cual por sus características y su respuesta ante el entorno. Un elemento
notable es que las características de un objeto pueden ser por sí mismas otros
objetos.
La
orientación a objetos promete mejoras de amplio alcance en la forma de diseño,
desarrollo y mantenimiento del software ofreciendo una solución a largo plazo a
los problemas y preocupaciones que han existido desde el comienzo en el
desarrollo de software: la falta de portabilidad del código y reusabilidad,
código que es difícil de modificar, ciclos de desarrollo largos y técnicas de
codificación no intuitivas.
Un
lenguaje orientado a objetos ataca estos problemas. Tiene tres características
básicas:
–
basado en objetos,
–
basado en clases y
–
capaz de tener herencia de clases.
El
elemento fundamental de la OOP es, como su nombre lo indica, el objeto. Podemos
definir un objeto como un conjunto complejo de datos y programas que poseen
estructura y forman parte de una organización.
Esta
definición especifica varias propiedades importantes de los objetos. En primer
lugar, un objeto no es un dato simple, sino que contiene en su interior cierto
número de componentes bien estructurados. En segundo lugar, cada objeto no es
un ente aislado, sino que forma parte de una organización jerárquica o de otro
tipo.
Estructura
de un Objeto
Un
objeto puede considerarse como una especie de cápsula dividida en tres partes:
1.
RELACIONES. Las relaciones permiten que el objeto se inserte en la organización
y están formadas esencialmente por punteros a otros objetos.
2.
PROPIEDADES Las propiedades distinguen un objeto determinado de los restantes
que forman parte de la misma organización y tiene valores que dependen de la
propiedad de que se trate. Las propiedades de un objeto pueden ser heredadas a
sus descendientes en la organización.
3.
METODOS. Los métodos son las operaciones que pueden realizarse sobre el objeto,
que normalmente estarán incorporados en forma de programas (código) que el
objeto es capaz de ejecutar y que también pone a disposición de sus
descendientes a través de la herencia.
Clases e Instancias
Dentro de la definición de objetos hay algunos que serán muy
parecidos ya sea que comparten la misma definición de características. Una
clase es una ayuda notacional en el análisis para establecer las propiedades y
funciones que serán comunes a todos los objetos que se generen a partir de
ella, tal y como lo muestra la figura 1.2.
Figura
1.2 Clase en notación UML
En
la notación de la metodología UML se utiliza un rectángulo con tres divisiones
para definir una clase. En la primera se indica el nombre de la clase, la
segunda contendrá todas las propiedades del objeto y la tercera contiene las
funciones por media de las cuales el objeto responde a estímulos de su entorno.
En
el enfoque orientado a objetos, todos los objetos se generan a partir de
clases. Incluso cuando solo se genere uno, de forma que todo objeto está
asociado a la clase a partir de la que se generó y se dice que dicho objeto es
una instancia de clase que puede usar directamente las características y
funciones asociadas a la clase.
La
clase es un elemento conceptual que permite definir y modelar, el objeto o
instancia de clase es una ejemplificación de clase. Una instancia de clase
tiene valores de atributos y puede invocar sus métodos.
Encapsulamiento
Cuando
interactuamos con un objeto únicamente nos interesa conocer las características
y atributos que nos permiten establecer dicha interacción, es decir el objeto
“publica” ciertas características y métodos, pero encapsula las demás ya que no
es fundamental para el exterior conocerlas para poder interactuar con el
objeto. Únicamente se requiere conocer aquellas que se exhiban como públicas.
Polimorfismo
El polimorfismo se define como la característica de que un
objeto que pide la ejecución de una función a otro objeto no necesita saber la
naturaleza del objeto dueño de la función. El polimorfismo más común lo tenemos
en un operador como el de suma o multiplicación, ya que la operación se realiza
aun cuando los operándoos sean distintos. La implementación del operador tiene
el cuidado de hacer correctamente la operación para el tipo de datos que está
participando como se muestra en la figura 1.3.
Figura
1.3. La clase animal y las subclases león y pajaro. Polimorfismo
Herencia
En la notación UML la relación de herencia entre dos clases
se indica por medio de una flecha hueca que apunta a la clase ascendiente, esto
es porque, en una relación de herencia el padre no se construye teniendo en
cuenta que se pueden derivar de él clases más especializadas. Por otro lado las
clases que son descendientes es importante que sepan quién es su ascendiente
pues de él están tomando propiedades y funciones. Ejemplo de herencia la figura
1.4.
Figura1.4.
Herencia de clase
Las
clases que no generan directamente instancias se denominan abstractas, y
aquellas que generan directamente objetos se les denominan concretas.
Asociaciones estáticas
Permiten
la estructuración de los objetos incorporando reglas del negocio. En su forma
más simple es un vínculo entre dos objetos. Al nivel de análisis se documentan
como vínculos entre clases, sin embargo, es importante recordar que las clases
son definiciones generales de un tipo de objeto, lo que implica que no son
colecciones de objetos y por lo tanto las asociaciones estáticas no son
asociaciones entre conjuntos de objetos como se pueden dar en el modelo Entidad
Relación tradicional.
La
asociación se indica con una línea uniendo a las dos clases. La línea puede
tener una etiqueta que indique la forma en la que se está interpretando la
asociación. Muchas reglas del negocio se refieren a los niveles máximos y
mínimos de vinculación entre distintos objetos de la aplicación. Por ejemplo,
un objeto Cliente solo debe estar asociado a un solo agente de Ventas, aunque
un Agente Vendedor puede estar vinculado a más de un cliente. Este tipo de
información es la multiplicidad o cardinalidad de la asociación y se indica
colocando un rango en los extremos de la asociación.
Existen casos en los que una clase se asocia con más de una
clase, en donde es conveniente no sólo mostrar la multiplicidad, sino también
cómo el analista concibe el vínculo de la clase en cada asociación. En estos
casos se le define un rol a la clase en a cada asociación que participa como se
muestra en la figura 1.5.
Figura
1.5: Asociaciones estáticas
Asociaciones
de agregación o composición.
Un
caso particular de asociación estática, es cuando se encuentra que un objeto no
sólo está asociado con otro, sino que además uno es parte del otro. Este tipo
de situación se le llama asociación de agregación.
La agregación podemos establecerla en dos tipos: por
composición y por agregación simple como se muestra en la figura 1.6. En la
primera, los objetos y la asociación se dieron simultáneamente y cuando
desaparezca un objeto, el otro también desaparecerá, así como la asociación.
Por lo regular se da cuando modelamos un objeto como propiedad de otro objeto.
Figura
1.6 Agregación y composición.
La
agregación simple es la más común y se da cuando tenemos documentos, tales como
facturas, órdenes de entrada de almacén, recibos de pago, etc. Ya que el
documento es el objeto central y tiene una serie de características con cierto
grado de opcionalidad, que hacen no necesiten estar los dos para que la
agregación se dé.
En
UML la agregación se denota con un rombo en el extremo de la asociación en
donde se encuentra la clase a la que se le están agregando objetos. La
agregación por composición se denota con el rombo sólido, mientas que la
agregación simple es con el rombo vacío.
En general es conveniente indicar las asociaciones de
agregación pues sugieren que las operaciones de mantenimiento a esos objetos
tienen que hacerse dentro de una misma transacción, lo cual ayuda a identificar
la complejidad de los modelos de objetos que se están obteniendo. Siempre será
más fácil dar mantenimiento a una familia de objetos que a dos o más familias
de objetos como lo sugieren las asociaciones de agregación.
jueves, 6 de septiembre de 2012
1.1 Arquitectura de 4+1 vistas
|
LA ARQUITECTURA SOFTWARE. EL MODELO 4+1
Algunas
notas breves sobre la arquitectura software y su modelización en 4+1...
La arquitectura software trata el diseño e implementación de la
estructura de alto nivel del software. Es el resultado de ensamblar un cierto
número de elementos arquitectónicos para satisfacer la funcionalidad y
ejecución de los requisitos del sistema; así como los requisitos no
funcionales del mismo: fiabilidad, escalabilidad, portabilidad,
disponibilidad, etc. Perry y Wolf (1992) describen una arquitectura software
como:
Arquitectura Software = {Elementos, Formas,
Fundamento/Restricciones}
Es muy complejo capturar la arquitectura software en un sólo modelo (o
diagrama). Para manejar esta complejidad se representan diferentes aspectos
y características de la arquitectura en múltiples vistas. Una vista es “una
presentación de un modelo, la cual es una descripción completa de un sistema
desde una particular perspectiva” (Kruchten, 1995). El modelo más aceptado a
la hora de establecer las vistas necesarias para describir una arquitectura
software es el modelo 4+1 (Kruchten, 1995).
Este modelo define 4 vistas principlaes:
Vista Lógica (Logical View), modelo de objetos, clases, entidad
– relación, etc.
Y una vista más, la "+1", que se muestra y traza en cada una
de las anteriores y que está formada por las necesidades funcionales que
cubre el sistema, y que en ocasiones identificamos como vista de "casos
de uso". De donde deducimos que según este modelo, la arquitectura es en
realidad evolucionada desde escenarios
El modleo 4+1 aplica la ecuación de Perry y Wolf (1992) de forma
independiente para cada vista, por ejemplo, cada vista puede definir un
conjunto de elementos para su uso (componentes, contenedores y conectores).
Cada vista es descrita usando su particular y más adecuada notación
(por ejemplo, existen diagramas UML que se adapatan más a una vista que
otra). Para cada vista los arquitectos pueden escoger cierto esquilo
arquitectónico (patrón arquitectónico), permitiendo la coexistencia de
múltiples estilos en un sistema.
Y por último, también comentar que el modelo de vistas “4+1”
es “genérico”: otras notaciones y herramientas a parte de UML
pueden usarse, y cualquier método de diseño, especialmente para las
descomposiciones lógicas y de proceso.
Como sucede en otras muchas ocasiones, si bien el modelo no es
una metodología si que "sugiere" un método de trabajo. Parece
lógico que la vista de escenarios o casos de uso sea la de arranque, y que de
ahí se pase a la vista lógica. Desde la vista lógica afrontaremos la de
desarrollo y procesos, una vez que tenemos por ejemplo las clases definiremos
maneras de agruparlas y modos de ejecución. Para con todo concluir en la
vista física. Todo ello, obviamente, con sus correspondientes y típicas
iteraciones.
Se ha ido exponiendo a lo largo de la explicación de cada una de las
vistas su translación a un lenguaje de modelado concreto como UML. Hya que
tener en cuenta que UML nace casi a la vez que el modelo 4+1, por lo que en
un origen no existía una clara relación entre ambos, lo que amenudo produce
confusión al diseñador que en la actualidad quiere modelar una arquitectura
con ambas herramientas. A modo de resumen la translación se presenta en la
siguiente tabla:
D. Garlan
and M. Shaw, "An Introduction to Software Architecture," Advances
in Software Engineering and Knowledge Engineering, Vol. 1, World
Scientific Publishing Co., Singapore, 1993.
Perry D.
E., Wolf A. L., “Foundations for the Study of Software
Architecture,” ACM Software Engineering Notes, 17, 4, October 1992, 40-52.
K.P. Birman
and R. Van Renesse, Reliable Distributed Computing with
the Isis Toolkit, IEEE CS Press, Los
Alamitos, Calif. 1994.
©
Copyright Javier Garzás, all
rights reserved. All material on this site is copyrighted. For articles
attributed to named authors, they are the copyright of the corresponding
authors. Any unattributed articles are copyright Javier Garzás. Please link
freely to this site, but if you want to copy any of the materials you should
contact the authors first.
|
Suscribirse a:
Entradas (Atom)