Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
lo importante será siempre validar con los clientes o usuarios que sus expectativas han sido
alcanzadas y se les esta brindando una herramienta con la cual obtienen beneficio real al usar
dicha herramienta.
Parte de la preparación para la construcción es decidir cuál de las muchas buenas prácticas
disponibles enfatizará. Algunos proyectos usan programación de pares y desarrollo de prueba
en primer lugar, mientras que otros usan desarrollo en solitario e inspecciones formales.
Cualquier combinación de técnicas puede funcionar bien, dependiendo de las circunstancias
específicas del proyecto.
La siguiente lista de verificación resume las prácticas específicas que debe decidir incluir o
excluir conscientemente durante la construcción. Los detalles de estas prácticas están
contenidos a lo largo del libro.
Puntos clave
Existen más prácticas de construcción que las que puede usar en un solo proyecto. Elija
conscientemente las prácticas que mejor se adapten a su proyecto.
Su posición en la ola tecnológica determina qué enfoques serán efectivos, o incluso posibles.
Identifique dónde se encuentra en la ola tecnológica y ajuste sus planes y expectativas en
consecuencia.
Horst Rittel y Melvin Webber definieron un problema "perverso" como uno que podría
definirse claramente solo resolviéndolo o resolviendo parte de él (1973). Esta paradoja implica,
esencialmente, que tiene que "resolver" el problema una vez para definirlo claramente y luego
resolverlo nuevamente para crear una solución que funcione. Este proceso ha sido la
maternidad y el pastel de manzana en el desarrollo de software durante décadas (Peters y
Tripp 1976).
El diseño del software terminado debe verse bien organizado y limpio, pero el proceso
utilizado para desarrollar el diseño no es tan ordenado como el resultado final.
El diseño es descuidado porque tomas muchos pasos en falso y pasas por muchos callejones
sin salida; cometes muchos errores. De hecho, cometer errores es el punto de diseño: es más
barato cometer errores y corregir diseños de lo que sería cometer los mismos errores,
reconocerlos después de la codificación y tener que corregir el código completo. El diseño es
descuidado porque una buena solución suele ser sutilmente diferente de una pobre.
En un mundo ideal, todos los sistemas podrían ejecutarse instantáneamente, consumir cero
espacios de almacenamiento, usar ancho de banda de red cero, nunca contener errores y no
costar nada construir. En el mundo real, una parte clave del trabajo del diseñador es sopesar
las características de diseño de la competencia y lograr un equilibrio entre esas características.
Si una tasa de respuesta rápida es más importante que minimizar el tiempo de desarrollo, un
diseñador elegirá un diseño. Si minimizar el tiempo de desarrollo es más importante, un buen
diseñador creará un diseño diferente.
El diseño no es determinista
Si envía a tres personas para que diseñen el mismo programa, pueden regresar fácilmente con
tres diseños muy diferentes, cada uno de los cuales podría ser perfectamente aceptable.
Puede haber más de una forma de despellejar a un gato, pero por lo general hay docenas de
formas de diseñar un programa de computadora.
Debido a que el diseño no es determinista, las técnicas de diseño tienden a ser heurísticas
("reglas de oro" o "cosas para intentar que a veces funcionan"), en lugar de procesos
repetibles que garantizan resultados predecibles. El diseño implica prueba y error. Una
herramienta o técnica de diseño que funcionó bien en un trabajo o en un aspecto de un
trabajo podría no funcionar tan bien en el próximo proyecto. Ninguna herramienta es
adecuada para todo.
El diseño es emergente
Una forma ordenada de resumir estos atributos de diseño es decir que el diseño es
"emergente". Los diseños no surgen completamente formados directamente del cerebro de
alguien. Evolucionan y mejoran a través de revisiones de diseño, discusiones informales, la
experiencia de escribir el propio código y la experiencia de revisar el código.
Prácticamente todos los sistemas experimentan algún grado de cambios en el diseño durante
su desarrollo inicial, y luego, por lo general, cambian en mayor medida a medida que se
extienden a versiones posteriores. El grado en que el cambio es beneficioso o aceptable
depende de la naturaleza del software que se está construyendo.
ese es el desafío del diseño: crear un buen conjunto de compensaciones con los objetivos en
competencia. Algunas características de la calidad del diseño también son características de un
buen programa: confiabilidad, rendimiento, etc. Otras son características internas del diseño.
Aquí hay una lista de características internas de diseño:
Mínima complejidad El objetivo principal del diseño debe ser minimizar la complejidad por
todas las razones que se acaban de describir. Evita hacer diseños “inteligentes”. Los diseños
inteligentes suelen ser difíciles de entender. En su lugar, haga diseños "simples" y "fáciles de
entender". Si su diseño no le permite ignorar de manera segura la mayoría de las otras partes
del programa cuando está inmerso en una parte específica, el diseño no está haciendo su
trabajo.
Acoplamiento suelto El acoplamiento suelto significa diseñar para que pueda mantener al
mínimo las conexiones entre diferentes partes de un programa. Utilice los principios de buenas
abstracciones en interfaces de clase, encapsulación y ocultación de información para diseñar
clases con la menor cantidad de interconexiones posible. La conexión mínima minimiza el
trabajo durante la integración, las pruebas y el mantenimiento.
Extensibilidad La extensibilidad significa que puede mejorar un sistema sin causar violencia a la
estructura subyacente. Puedes cambiar una pieza de un sistema sin afectar a otras piezas. Los
cambios más probables causan al sistema el menor trauma.
Reusabilidad Reusabilidad significa diseñar el sistema para que pueda reutilizar partes de él en
otros sistemas.
Alta fan-in Alta fan-in se refiere a tener un alto número de clases que usan una clase dada. La
alta participación implica que un sistema ha sido diseñado para hacer un buen uso de las clases
de utilidad en los niveles más bajos del sistema.
When I am working on a problem I never think about beauty. I think only how to solve the
problem. But when I have finished, if the solu- tion is not beautiful, I know it is wrong.
Ventilación de baja a media significa que tener una clase determinada utilice un número de
baja a media de otras clases. Un alto abanico de salida (más de aproximadamente siete) indica
que una clase usa un gran número de otras clases y, por lo tanto, puede ser demasiado
compleja. Los investigadores han descubierto que el principio de baja fan-out es beneficioso ya
sea que esté considerando la cantidad de rutinas llamadas dentro de una rutina o la cantidad
de clases utilizadas dentro de una clase (Card and Glass 1990; Basili, Briand y Melo 1996) .
Portabilidad La portabilidad significa diseñar el sistema para que pueda moverlo fácilmente a
otro entorno.
Inclinación La inclinación significa diseñar el sistema de modo que no tenga partes adicionales
(Wirth 1995, McConnell 1997). Voltaire dijo que un libro se termina no cuando ya no se puede
agregar nada más, sino cuando ya no se puede quitar nada más. En el software, esto es
especialmente cierto porque el código adicional debe ser desarrollado, revisado, probado y
considerado cuando se modifica el otro código. Las versiones futuras del software deben
seguir siendo compatibles con el código adicional. La pregunta fatal es: "Es fácil, entonces,
¿qué lastimaremos al incluirlo?"
Técnicas estándar Cuanto más se base un sistema en piezas exóticas, más intimidante será
para alguien que intenta entenderlo la primera vez. Intente dar a todo el sistema un
sentimiento familiar utilizando enfoques estandarizados y comunes.
Niveles de diseño
El primer nivel es todo el sistema. Algunos programadores saltan directamente desde el nivel
del sistema al diseño de clases, pero generalmente es beneficioso pensar en combinaciones de
clases de mayor nivel, como subsistemas o paquetes.
El diseño en este nivel incluye dividir cada clase en rutinas. El hecho de definir completamente
las rutinas de la clase a menudo resulta en una mejor comprensión de la interfaz de la clase, y
eso causa los cambios correspondientes en la interfaz, es decir, los cambios en el Nivel 3.
Este nivel de descomposición y diseño a menudo se deja en manos del programador individual,
y se necesita en cualquier proyecto que lleve más de unas pocas horas. No necesita hacerse
formalmente, pero al menos debe hacerse mentalmente.
Iterar
El diseño es un proceso iterativo. A medida que recorre los diseños candidatos y prueba
diferentes enfoques, observará las vistas de alto y bajo nivel. El panorama general que obtiene
al trabajar con problemas de alto nivel le ayudará a poner los detalles de bajo nivel en
perspectiva. Los detalles que obtenga al trabajar con problemas de bajo nivel proporcionarán
una base sólida para las decisiones de alto nivel. El tirón y el tirón entre el nivel superior y el
nivel inferior
Divide y conquistaras
El diseño de arriba hacia abajo comienza en un alto nivel de abstracción. Usted define clases
base u otros elementos de diseño no específicos. A medida que desarrolla el diseño, aumenta
el nivel de detalle, identificando clases derivadas, clases colaborativas y otros elementos de
diseño detallados.
El diseño de abajo hacia arriba comienza con aspectos específicos y trabaja hacia
generalidades. Por lo general, comienza identificando objetos concretos y luego generaliza
agregaciones de objetos y clases base a partir de esos detalles.
Algunas personas argumentan con vehemencia que lo mejor es comenzar con generalidades y
trabajar hacia aspectos específicos, y otros argumentan que no se pueden identificar
realmente los principios generales de diseño hasta que haya resuelto los detalles significativos.
Aquí están los argumentos de ambos lados.
La diferencia clave entre las estrategias de arriba hacia abajo y de abajo hacia arriba es que
una es una estrategia de descomposición y la otra es una estrategia de composición. Uno parte
del problema general y lo divide en partes manejables; el otro comienza con piezas manejables
y crea una solución general.
Prototipado experimental
Una técnica general para abordar estas preguntas a bajo costo es el prototipo experimental. La
palabra "prototipado" significa muchas cosas diferentes para diferentes personas (McConnell
1996). En este contexto, la creación de prototipos significa escribir la cantidad mínima absoluta
de código desechable que se necesita para responder a una pregunta de diseño específica.
Un riesgo final de creación de prototipos surge cuando los desarrolladores no tratan el código
como código desechable. Una forma de evitar este problema es crear prototipos en una
tecnología diferente a la del código de producción. Podría crear un prototipo de un diseño Java
en Python o simular una interfaz de usuario en Microsoft PowerPoint. Si crea prototipos
utilizando la tecnología de producción, un estándar práctico que puede ayudar es que los
nombres de clase o de paquete para el código de prototipo se prefijen con prototipo. Eso, al
menos, hace que un programador se lo piense dos veces antes de intentar extender el código
de prototipo (Stephens 2003).
Diseño colaborativo
En el diseño, dos cabezas a menudo son mejores que una, ya sea que esas dos cabezas estén
organizadas formal o informalmente.
A veces, solo se traza el boceto más simple de una arquitectura antes de que comience la
codificación. En otras ocasiones, los equipos crean diseños con un nivel de detalle tal que la
codificación se convierte en un ejercicio principalmente mecánico. ¿Cuánto diseño debes
hacer antes de comenzar a codificar?
Una pregunta relacionada es qué tan formal es hacer el diseño. ¿Necesita diagramas de diseño
formal y pulido, o serían suficientes las instantáneas digitales de algunos dibujos en una
pizarra?
Decidir cuánto diseño hacer antes de comenzar la codificación a gran escala y cuánta
formalidad usar para documentar ese diseño no es una ciencia exacta. Se debe considerar la
experiencia del equipo, la vida útil esperada del sistema, el nivel de confiabilidad deseado y el
tamaño del proyecto y el equipo
El diseño de software es un campo rico con recursos abundantes. El desafío es identificar qué
recursos serán más útiles.
LENGUAJES
'lenguaje de configuración',
Toolkits
TOOLKIT
Para la clasificación de las herramientas CASE no existe una característica que
las divida con exactitud, estas podrían ser clasificadas dependiendo de las
plataformas que las soportan, su funcionalidad, el tipo de arquitectura que
utilicen las aplicaciones en las que se ocupan, el método que se ocupe y el
ciclo de vida que cubran etc.
Toolkit (Juego de herramientas), Tools-CASE, son el tipo de herramientas
CASE más sencillas. Automatizan una fase dentro del ciclo de vida del
software. Dentro de este grupo se encuentran las herramientas de reingeniería,
orientadas a la fase de mantenimiento. Comparten la Base de Datos de soporte
y la interfaz de usuario.
http://www.inei.gob.pe/biblioineipub/bancopub/Inf/Lib5103/Libro.pdf
Algunas de las características que poseen los entornos “toolkit” son:
Son un conjunto de elementos heterogéneos
Son demasiado simples
Requieren elementos adicionales para integrarlas y aplicarlas
Flexibles
Tienen una gran capacidad de ampliarse y adaptarse a las necesidades de los
usuarios.
De forma individual son difíciles de controlar.
Al mismo tiempo diversas compañías utilizaban sus propios procesos y
notaciones únicos para transmitir los resultados del análisis y diseño de
software; y a su vez de tenía el dese de utilizar herramientas que tuvieran
soporte para sus procesos particulares. Evidentemente era necesario contar
con una notación y un proceso estándar.
http://es.slideshare.net/fallonbrewington/toolkit-b
Análisis y Diseño
Permiten al desarrollador crear un modelo del sistema que se va a construir y
también la evaluación de la validez de este modelo. Proporciona un grado de
confianza en la representación del análisis y ayuda e eliminar y a prevenir
errores.
o Analyst/Designer Toolkit de Yourdon
o Exceletor de Index Technology
Diseño de archivos y Bases de Datos
Ayuda a comprender mejor cómo se maneja la información entre las distintas
unidades organizativas. Proporcionan auxilio cuando se diseñan nuevas
estrategias para los sistemas de bases de datos y cuando los métodos y
sistemas no satisfacen las necesidades de la organización.
o Oracle
o Synon
Programación
Se engloban los compiladores, los editores y los depuradores de los lenguajes
de programación convencionales. Normalmente se suelen utilizar en
ordenadores personales o estaciones de trabajo, lo que hace un poco más
difícil su manejo por ser individual.
o APS de Sage Software
o Transforms de Transform Logic
ATK (informática)
Ir a la navegaciónIr a la búsqueda
ATK
Repositorio del código https://git.gnome.org/browse/atk
fuente
Versión 2.28.1
Índice
1Implementaciones
2Desarrollo
3Mantenedores
4Licencia
5Referencias
6Enlaces externos
Implementaciones[editar]
Los ficheros de cabecera de ATK están disponibles libremente para facilitar la labor de
aquellos desarrolladores que quieran proveer de accesibilidad a los elementos de su
interface gráfica de usuario, comúnmente conocidos como widgets.2 Los desarrolladores
que usen un sistema de widgets que implemente los ficheros de cabecera de ATK, como
por ejemplo GTK+, no tienen que preocuparse por hacer sus aplicaciones accessibles ya
que los widgets proporcionados ya son accessibles. Sin embargo, cuando desarrollen sus
propios widgets, tendrán que encargarse de exponer adecuadamente toda la información
de accesibilidad.
GAIL (del inglés GNOME Accessibility Implementation Library) era el nombre de la
implementación de la interface de accesibilidad de ATK para GTK+, el sistema de widgets
de GNOME. Inicialmente, GAIL era un módulo independiente mapeado a GTK+, pero
desde GNOME 3.2 se incluyó GAIL en GTK+, de manera que la implementación de ATK
está desde entonces integrada en el propio GTK+.3
Aparte de GTK+, existen otros sistemas de widgets y aplicaciones que implementan ATK
para ser accesibles, como OpenOffice4/LibreOffice,5 el motor web de Mozilla, Gecko,6
Clutter7 y el port a GTK+ del motor web WebKit, WebKitGTK+.1
Desarrollo[editar]
ATK forma parte del Framework de Accesibilidad de GNOME que fue lanzado en 2001.8
Inicialmente, la mayor parte del desarrollo de ATK se realizó a través de la Oficina del
Programa de Accesibilidad (APO, del inglés Accessibility Program Office) de Sun
Microsystems, Inc. (ahora Oracle) con contribuciones de muchos miembros de la
comunidad. Cuando Oracle adquirió Sun en 2010, se eliminaron puestos de trabajo a
tiempo completo dedicados al desarrollo de componentes de accesibilidad de GNOME,
como el toolkit de accesibilidad ATK o el lector de pantalla Orca.9 Desde entonces, ATK es
siendo mantenido principalmente por la comunidad GNOME.
Mantenedores[editar]
El desarrollo de ATK está liderado por sus mantenedores con la ayuda de la comunidad.
Los mantenedores hasta la fecha han sido:10
Actual:
Bill Haneman
Leon Fan
Li Yuan
Lenguajes de programación.