revista singularidad
Post on 21-Jul-2016
233 Views
Preview:
DESCRIPTION
TRANSCRIPT
.
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.
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: m1bff7e2@alum.udo.edu.ve
RIF: G-20000052-0
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.
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.
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.
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
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.
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.
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.
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.
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.
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
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.
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
top related