Revista Singularidad

15
.

description

Áreas de Grado. Ciencias, Implementación, Diseño, Programación, Udo Monagas, Universidad

Transcript of Revista Singularidad

Page 1: Revista Singularidad

.

Page 2: Revista Singularidad

INTRODUCCION ................................................................ ¡Error! Marcador no definido.

DISEÑO .............................................................................. ¡Error! Marcador no definido.

CARACTERÍSTICAS PARA EVALUAR UN DISEÑO ..................................................... 5

IMPORTANCIA DEL DISEÑO ........................................................................................ 6

DISEÑO ARQUITECTÓNICO ........................................................................................ 6

DISEÑO DE DATOS .................................................................................................. 6

Estilos Arquitectónicos ............................................................................................... 7

Arquitectura centrada en datos .............................................................................. 7

Arquitectura de flujo de dato ................................................................................... 7

Arquitectura de Llamada y retorno ......................................................................... 7

Arquitectura de programa/subprograma ................................................................. 7

Arquitectura Orientada a Objetos ........................................................................... 7

Arquitectura estratificada ........................................................................................ 7

Arquetipos .................................................................................................................. 8

Evaluación de los diseños arquitectónicos alternos .................................................... 8

Herramientas de software .......................................................................................... 8

DISEÑO AL NIVEL DE COMPONENTES ...................................................................... 9

¿Qué es un componente? .......................................................................................... 9

Los componentes pueden ser de tres tipos .............................................................. 10

Diseño de componentes basados en clases ............................................................ 10

Cohesión .................................................................................................................. 11

Acoplamiento ........................................................................................................... 12

Herramientas de software ........................................................................................ 12

UML/OCL ................................................................................................................. 12

DISEÑO DE LA INTERFAZ DE USUARIO ................................................................... 13

Existen tres reglas de oro en el diseño de la interfaz de usuario .............................. 13

Herramientas de software ........................................................................................ 14

Referencias Bibliograficas .................................................. ¡Error! Marcador no definido.

Page 3: Revista Singularidad

La ingeniería de software desde

sus comienzos ha sido una rama

con muchos cuestionamientos,

sobre sus basamentos

metodológicos, ha sido un proceso arduo, que por

tratarse de una de las ramas de las ingenierías que más

rápidamente cambia, se pudiera llegar a pensar que ni

siquiera posee algunos, pero la realidad es otra, y de

hecho es una de las ramas más ricas en cuanto a

metodologías se trata, una de ellas, vital diría yo, es el

proceso de diseño de software, es una parte fundamental

en mi opinión para poder desarrollar un software de

calidad y con nivel de ingeniería, este proceso surge en

las primeras instancias de un proyecto de software, antes

de empezar a codificar, un proyecto de tener bien

definido estos lineamientos.

Normalmente entre la comunidad desarrolladora, existe

un concepto que se adapta a esta falta de formalidad al

momento de escribir código, se le llama “software

artesanal”, claro, como todo campo del conocimiento

empezó como una práctica empírica, posteriormente fue

evolucionando a planos más altos.

Revista Singularidad

Director Luis Enrique Rangel. Redacción Manuel Martino Del Molino Consejo Académico Asesor

Yamila Gascón

Nelsy Vivenes

Jonathan Vásquez Editor Responsable: Luis E. Rangel y Manuel Martino Del Molino. Las ideas y opiniones expresadas en esta revista son responsabilidad única y exclusiva de los autores, la revista no se responsabilizara por dichas opiniones. Avenida Universidad Los Guaritos. Maturín, Monagas, Venezuela Teléfono: +58 (0291) 6417755 Correo electrónico: [email protected]

RIF: G-20000052-0

Page 4: Revista Singularidad

El concepto de diseño de software, hoy en día es una rama vital del

desarrollo de software y sistemas, tal es su impacto que actualmente ningún

proyecto de software serio puede iniciar si no se poseen los marcos estructurales

de diseño para la codificación. Siempre y cuando obedeciendo a las reglas de

diseño, orientados al paradigma por donde se trabaje.

Page 5: Revista Singularidad

El diseño es lo que casi

cualquier ingeniero quiere hacer. Es

el sitio donde manda la creatividad,

donde los requisitos del cliente, las

necesidades de negocio y las

consideraciones técnicas se unen en

la formulación de un producto o

sistema. El diseño crea una diferencia

del modelo de análisis (que se enfoca

en la descripción de los datos, las

funciones y el comportamiento

requerido), el modelo de diseño

proporciona detalles acerca de las

estructuras de datos, las

arquitecturas, las interfaces y los

componentes del software que son

necesarios para implementar el

sistema.

CARACTERÍSTICAS PARA

EVALUAR UN DISEÑO

McGlaughlin [MCG91].

Sugiere tres características que

sirven como guía en la evaluación de

un buen diseño;

1. El diseño debe implementar

todos los requisitos explícitos

contenidos en el modelo del

análisis, y debe ajustarse

todos los requisitos implícitos

que desea el cliente.

2. El diseño debe ser una guía

legible y comprensible para

quienes generan código,

quienes realizan pruebas y, en

consecuencia, dan soporte al

software.

3. El diseño debe proporcionar

una imagen completa del

software- dando dirección a los

dominios de datos, funcionales

y de comportamiento desde

una perspectiva de la

implementación.

Page 6: Revista Singularidad

IMPORTANCIA DEL DISEÑO

Es importante porque permite

que un equipo de software evalué la

calidad del software antes de

implementarlo, es decir, en un

momento en el que los errores,

omisiones o inconsistencias son

fáciles de corregir y no resultan caras.

DISEÑO ARQUITECTÓNICO

Representa la estructura de

datos y los componentes necesarios

para construir un sistema

computacional. El diseño

arquitectónico inicia con el diseño de

datos y luego pasa a la derivación de

una o más representaciones de la

estructura arquitectónica del sistema.

La arquitectura de software son las

estructuras del sistema o estructura

que incluyen los componentes del

software, las propiedades visibles

externamente de esos componentes

y las relaciones entre ellos.

DISEÑO DE DATOS

Este proceso traduce los

objetos de datos obtenidos en el

modelo de análisis en estructuras

globales a nivel de componentes de

software.

Estilos arquitectónicos:

1. Un conjunto de componentes que

realizan una función requerida por el

sistema.

2. un conjunto de conectores que

permiten la comunicación,

cooperación y coordinación entre

componentes

3. Restricciones que definen como se

integran los componentes para formar

el sistema.

4. modelos semánticos que permiten

al diseñador del sistema comprender

las propiedades generales de un

sistema.

Page 7: Revista Singularidad

Programa Principal

Sub-Programa Controlador

Sub-Programa de Aplicacion

Sub-Programa de Aplicacion

Sub-Programa Controlador

Sub-Programa de Aplicacion

Sub-Programa de Aplicacion

Sub-Programa de Aplicacion

Sub-Programa de Aplicacion

Estilos Arquitectónicos

Arquitectura centrada en datos

Un almacén de datos se

encuentra en el centro de esta

arquitectura

Arquitectura de flujo de dato

Esta arquitectura se utiliza

cuando los datos de entrada se

empiezan a transformar en datos de

salida mediante una serie de

componentes para el cálculo o

manipulación.

Arquitectura de Llamada y retorno

Esta permite tener una

arquitectura que es relativamente fácil

de modificar y cambiar de tamaño y

existen dos categorías

Arquitectura de programa/subprograma

Arquitectura de llamada a

procedimiento remoto. Es un

programa/subprograma en los cuales

algunos subprogramas están

instalados en un ordenador distinto

Arquitectura Orientada a Objetos

Los componentes de un

sistema encapsulan los datos y las

operaciones que deben aplicarse

para manipular datos la

comunicación se efectúa por colas

de mensajes.

Arquitectura estratificada

Se compone en distintas capas

definidas cada una de ellas realiza

operaciones que se encargan

progresivamente al conjunto de

instrucciones de la máquina.

Ejemplo de una arquitectura de Flujo de Datos

Page 8: Revista Singularidad

Arquetipos

Un arquetipo es una clase o

patrón que representa una

abstracción central importantísima en

el diseño de una arquitectura para el

sistema destino.

Evaluación de los diseños

arquitectónicos alternos

La SEI ha desarrollado un método de

análisis de compensación para la

arquitectura MACA y se realizan las

siguientes actividades de manera

iterativa

1. recopilar escenarios

2. Deducir requisitos, restricciones y

descripción de entornos

3. describir los

Estilos/patrones

arquitectónicos que se han

elegido para dirigir los

escenarios y requisitos.

4. evaluar los atributos de calidad al

considerar cada atributo de manera

aislada

5. identificar la sensibilidad de los

atributos de calidad respecto varios

atributos arquitectónicos para un

estilo arquitectónico específico.

6. Analizar las arquitecturas alternas

empleando análisis de sensibilidad

aplicado al paso 5.

Herramientas de software

Existen un sinfín de

herramientas dedicadas al diseño de

arquitecturas, muchas de ellas

basadas en el lenguaje UML,

estándar actual para la formulación

de todos los diseños y planos del

software.

Enterprise Architect,

desarrollado por Sparx Systems, con

base en Australia, desarrollado en el

Lenguaje C++, se perfila como una

de las herramientas más potentes de

lenguaje de

modelado unificado

hoy en dia.

Page 9: Revista Singularidad

Objectif, desarrollada por

microTOOL GmbH, es una

herramienta de diseño UML que lleva

a arquitecturas (por ejemplo,

Coldfusion, J2EE, fusebox) sensibles

a la ingeniería de software basadas

en componentes.

Umbrello, una herramienta

open source, para la plataforma

GNU/Linux, específicamente para los

entornos de escritorio KDE. Umbrello

maneja gran parte de los diagramas

estándar UML pudiendo crearlos,

además de manualmente,

importándolos a partir de código en

C++, Java, Python, IDL,

Pascal/Delphi, Ada

Rational Rose Modeler,

desarrollada por IBM, es una

herramienta de diseño basado en

UML que soporta todos los aspectos

del diseño arquitectónico

DISEÑO AL NIVEL DE

COMPONENTES

El diseño a nivel de componentes

define las estructuras de datos, los

algoritmos, las características de la

interfaz y los mecanismos de

comunicación asignados a cada

componente de software. Esta fase

permite revisar si los detalles de

diseño son correctos y consistentes

con las representaciones iniciales de

diseño.

¿Qué es un componente?

Es un bloque de construcción

modular par el software de cómputo.

Una parte modular desplegable y

reemplazable de un sistema que

encapsula implementación y expone

un conjunto de interfaces.

Page 10: Revista Singularidad

Los componentes pueden ser

de tres tipos

1. Componente de control que

coordina la invocación de todos los

demás componentes del dominio del

problema.

2. un componente del dominio del

problema que implementa una

función parcial o completa requerida

por el cliente.

3. un componente de infraestructura

responsable de funciones que

soportan el procesamiento requerido

en el dominio del problema.

A continuación se presenta un

ejemplo de un diseño a nivel de

componentes utilizando UML

Diseño de componentes

basados en clases

Cuando se elige un método de

ingeniería de software basado en

componentes el nivel de diseño de

estos se concentra en la elaboración

de clases de análisis y la definición y

afinación de clases de infraestructura.

Hay cuatro principios básicos

basados en el nivel de diseño de

componentes:

1. El principio abierto cerrado PAC un

módulo debe estar abierto para

extensiones pero cerrado para

modificaciones.

Sistema de Administracion de

Trabajo

Leer Datos de Trabajo de impresion

Seleccionar la funcion de manejo

de trabajo

Desarrolar Costo de Trabajo

Calcular Costo de Pagina

Calcular Costo de Papel.

Calcular Costo de Producto

Construir Orden de Trabajo

Enviar Trabajo o Produccion

Revisar Prioridad Pasar Trabajo a

Produccion.

Page 11: Revista Singularidad

2. Principio de sustitución de Liskov

PSL debe tenerse la opción de

sustituir las subclases con sus clases

principales.

3. Principio de la inversión de la

dependencia PID dependa de las

abstracciones no de las

concreciones, mientras un

componentes dependa más de otros

componentes concretos es más difícil

extenderlos.

4. Principio de la segregación de la

interfaz es mejor tener muchas

interfaces específicas del cliente que

una interfaz de propósito general.

Existen distintas líneas generales

que se pueden seguir durante el

diseño de componentes:

1. Los componentes deben definirse

convenciones de asignación de

nombres, los cuales provengan del

dominio del sistema y tener algún

significado para los participantes

2. Interfaces proporcionan

información importante acerca de la

comunicación y colaboración, aun

que al tener muchas se puede crear

confusión en el diagrama UML por lo

que se recomienda entre otras cosas

al tener demasiadas usar círculos en

vez de rectángulos y mostrar solo las

más importantes

3. Las dependencias de izquierda a

derecha y las herencias la clase

principal arriba y derivadas abajo

Cohesión

Implica que un componente o

una clase encapsulan únicamente

atributos y operaciones relacionadas

estrechamente entre sí y con la clase

del propio componente.

Existen distintos tipos de cohesión

Funcional, cuando un módulo realiza

un solo calculo y devuelve el

resultado

De capa, cuando una capa

superior tienen acceso a una inferior

pero no al revés.

De comunicación, todas las

operaciones con acceso a los mismos

datos se definen dentro de una clase.

Secuencial, las

operaciones

están

agrupadas de

manera que

primero permita

la entrada al siguiente y así

sucesivamente.

Page 12: Revista Singularidad

Acoplamiento

Es una medida cualitativa del

grado al que las clases se conectan

entre sí a medida que las clases se

vuelven más interdependientes el

acoplamiento aumenta. Acoplamiento

común, del contenido, de control, de

estampa, de datos, de llamada a

rutina, uso de rutina, uso de tipo, de

incursión o aportación y externo.

Herramientas de software

MIDDLEWARE e ingeniería de

software basadas en componentes.

Uno de los elementos clave que lleva

al éxito o en componentes es la

disponibilidad de meddleware. Esta

es una colección de componentes de

infraestructura que permite que los

componentes de dominio del

programa se comuniquen con otros

en una red o dentro de un sistema

completo.

UML/OCL

ARGOUML, distribuido por

Tigress. org, da soporte a ULM y OCL

completo, e incluye varias

herramientas de ayuda para el

diseño, que van más allá de la

generación de diagramas UML y

expresiones OCL.

DRESDEN OCL TOOLKIT,

desarrollado por Frank Finger en la

Universidad Tecnológico de Dresden,

es un juego de herramientas basadas

en un compilador OCL que abarca

varios módulos que analizan, revisan

el tipo y las restricciones OCL.

OCL PARSER, desarrollado por IBM,

está escrito en Java y está disponible

gratuitamente para comunidad

orientada a objeto con fin de que se

estimule el uso de OCL con

modeladores UML.

Page 13: Revista Singularidad

DISEÑO DE LA INTERFAZ DE

USUARIO

El diseño de la interfaz se concentra

en tres partes

1. Diseño de interfaces entre

componentes

2. Diseño de interfaces entre el

software y otros productores y

consumidores de información que no

son humanos

3. Interfaz entre ser humano y

computadora

La creación de una interfaz entre el

ser humano y la computadora crea un

mecanismo efectivo de comunicación,

la interfaz debe estar construida de la

mejor forma para que motive el uso y

ayude al éxito del sistema de

software.

Existen tres reglas de oro en

el diseño de la interfaz de

usuario

1. Dar el control al usuario. El usuario

desea manejar el sistema y no que

este lo maneje a el de modo que si el

constructor introduce limitaciones que

ayuden a hacer más fácil el trabajo de

construcción puede influir en un

resultado frustrante para el usuario.

Para ello se deben definir:

Modos de interacción de forma

que el usuario no realice

acciones innecesarias o

indeseables

una interacción flexible

incluir opciones de interrumpir

y deshacer

permitir que se personalice la

interacción

ocultar elementos técnicos a

usuario usual.

Diseñar interacción directa con

los objetos que aparecen en la

pantalla

2. Reducir la carga de memoria del

usuario. El sistema debe recordar las

cosas y no el usuario un sistema que

dependa del usuario usualmente

cometerá más errores.

Reducir la demanda de

memoria a corto plazo

Definir valores a corto plazo

que tengan significado

Definir accesos directos

intuitivos

Page 14: Revista Singularidad

El formato visual de la interfaz

debe basarse en una metáfora

tomada de la interfaz

Desglosar la información de

manera progresiva.

3. Lograr que la interfaz sea

consistente, la información en

pantalla debe estar organizada de

acuerdo a un estándar que se

mantenga en todas las

presentaciones de pantalla, los

mecanismos de entrada deben

restringirse a un conjunto limitado que

se utilice durante toda la aplicación.

Herramientas de software

Desarrollo de interfaces de usuario

MACROMEDIA AUTHORWARE,

desarrollado por Macromedia Inc. se

ha diseñado para la creación de

interfaces y entornos de aprendizaje

electrónico.

MOTIF COMMON DESKTOP

ENVIRONMENT, desarrollado por

The Open Group, es una interfaz

gráfica de usuario integrada para

sistemas abiertos de computación de

escritorio. Entrega una interfaz gráfica

simple, estándar, para la

administración de datos, archivos y

aplicaciones.

POWERDESIGNER/POWERBUILDE

R, desarrollo por Sybase, es un

conjunto muy completo de

herramientas CASE, que incluyen

muchos opciones para el diseño y la

construcción de interfaces graficas de

usuario.

Page 15: Revista Singularidad

Referencias Bibliográficas

[Pressman, 2002] Pressman, R. S. “Ingeniería del Software: Un Enfoque Práctico”. 5ª Edición. McGraw-Hill. 2002 [Pressman, 2006] Pressman, R. S. “Ingeniería del Software: Un Enfoque Práctico”. 6ª Edición. McGraw-Hill. 2006

[Rumbaugh J, et als 2000] Rumbaugh, J. Jacobson, I. Booch, G. “Lenguaje unificado de Modelado”. Addison-Wesley. 2000