Sunteți pe pagina 1din 13

CONSIDERACIONES PRÁCTICAS EN LA CONSTRUCCIÓN DEL SOFTWARE

es importante la relación que existe entre la construcción, el análisis y el diseño de las


diferentes funcionalidades, y la importancia de construir software empleando de la mejor
manera las herramientas disponibles así como los principios y métodos asociados a lenguajes,
frameworks y marcos de trabajo, para contar no solo con un buen producto sino con un código
que pueda ser mantenible a través del tiempo.

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.

Independientemente de cómo se haga, los proyectos pequeños se benefician de un diseño


cuidadoso, al igual que los proyectos más grandes, y reconocer el diseño como una actividad
explícita maximiza los beneficios que recibirá de él.

5.1 Desafíos de diseño

La frase “diseño de software” se refiere a la concepción, la invención o el diseño de un


esquema para convertir una especificación para software de computadora en software
operativo. El diseño es la actividad que vincula los requisitos a la codificación y depuración. Un
buen diseño de nivel superior proporciona una estructura que puede contener de manera
segura múltiples diseños de nivel inferior. El buen diseño es útil en proyectos pequeños e
indispensable en proyectos grandes.

El diseño también está marcado por numerosos desafíos.

-El diseño es un problema malo

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 es un proceso descuidado (incluso si produce un resultado ordenado)

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.

El diseño también es descuidado porque es difícil saber cuándo su diseño es "lo


suficientemente bueno". ¿Cuántos detalles son suficientes? ¿Cuánto diseño se debe hacer con
una notación de diseño formal y cuánto se debe dejar en el teclado? Cuando has terminado
Dado que el diseño es abierto, la respuesta más común a esa pregunta es "Cuando estás fuera
de tiempo".

El diseño se trata de compensaciones y prioridades

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 implica restricciones


El punto del diseño es, en parte, crear posibilidades y en parte restringir las posibilidades. Si las
personas tuvieran tiempo, recursos y espacio infinitos para construir estructuras físicas, verías
increíbles edificios en expansión con un espacio para cada zapato y cientos de cuartos. Así es
como el software puede resultar sin restricciones impuestas deliberadamente. Las limitaciones
de los recursos limitados para la construcción de edificios obligan a simplificar la solución que,
en última instancia, mejora la solución. El objetivo en el diseño de software es el mismo.

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.

El diseño es un proceso heurístico

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.

Características deseables de un diseño

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.

Facilidad de mantenimiento La facilidad de mantenimiento significa el diseño para el


programador de mantenimiento. Imagine continuamente las preguntas que un programador
de mantenimiento le haría sobre el código que está escribiendo. Piense en el programador de
mantenimiento como su audiencia y luego diseñe el sistema para que se explique por sí
mismo.

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.

—R. Buckminster Fuller

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?"

Estratificación Estratificación significa tratar de mantener los niveles de descomposición


estratificados para que pueda ver el sistema en cualquier nivel y obtener una vista coherente.

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 diseño es necesario en diferentes niveles de detalle en un sistema de software. Algunas


técnicas de diseño se aplican en todos los niveles y otras solo en uno o dos. La figura 5-2 ilustra
los niveles.

Nivel 1: Sistema de software

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.

Nivel 2: División en subsistemas o paquetes

El principal producto de diseño a este nivel es la identificación de todos los subsistemas


principales. Los subsistemas pueden ser grandes: base de datos, interfaz de usuario, reglas de
negocio, intérprete de comandos, motor de informe, y así sucesivamente. La principal
actividad de diseño a este nivel es decidir cómo dividir el programa en los subsistemas
principales y definir cómo cada subsistema puede utilizar cada uno de los subsistemas. La
división en este nivel suele ser necesaria en cualquier proyecto que lleve más de unas pocas
semanas. Dentro de cada subsistema, se pueden usar diferentes métodos de diseño: elegir el
enfoque que mejor se adapte a cada parte del sistema.

Nivel 3: División en clases

El diseño en este nivel incluye la identificación de todas las clases en el sistema.


Los detalles de las formas en que cada clase interactúa con el resto del sistema también se
especifican a medida que se especifican las clases. En particular, se define la interfaz de la
clase. En general, la principal actividad de diseño en este nivel es asegurarse de que todos los
subsistemas se hayan descompuesto a un nivel de detalle lo suficientemente fino como para
que pueda implementar sus partes como clases individuales.

La división de subsistemas en clases generalmente es necesaria en cualquier proyecto que


demore más de unos pocos días. Si el proyecto es grande, la división es claramente distinta de
la partición del programa del Nivel 2. Si el proyecto es muy pequeño, puede pasar
directamente de la vista de todo el sistema del Nivel 1 a la vista de las clases del Nivel 3.

Clases contra objetos Un concepto clave en el diseño orientado a objetos es la diferenciación


entre objetos y clases. Un objeto es cualquier entidad específica que existe en su programa en
tiempo de ejecución. Una clase es la cosa estática que se ve en la lista de programas. Un objeto
es lo dinámico con valores y atributos específicos que ve cuando ejecuta el programa. Por
ejemplo, puede declarar una persona de clase que tiene atributos de nombre, edad, género,
etc. En el tiempo de ejecución, tendría los objetos nancy, hank, diane, tony, etc., es decir,
instancias específicas de la clase. Si está familiarizado con los términos de la base de datos, es
lo mismo que la distinción entre "esquema" y "instancia". Puede pensar en la clase como el
cortador de cookies y el objeto como la cookie. Este libro usa los términos de manera informal
y generalmente se refiere a clases y objetos de manera más o menos intercambiable.

Nivel 4: División en Rutinas.

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.

Nivel 5: Diseño de Rutina Interna.

El diseño en el nivel de rutina consiste en presentar la funcionalidad detallada de las rutinas


individuales. El diseño consiste en actividades como escribir pseudocódigo, buscar algoritmos
en libros de referencia, decidir cómo organizar los párrafos de un código en una rutina y
escribir código de lenguaje de programación.

5.2 Prácticas de diseño


La sección anterior se centró en las heurísticas relacionadas con los atributos de diseño: cómo
desea que se vea el diseño completado. Esta sección describe las heurísticas de la práctica del
diseño, pasos que puede seguir y que a menudo producen buenos resultados.

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 refinamiento incremental es una herramienta poderosa para administrar la complejidad.


Como Polya recomendó en la resolución de problemas matemáticos, entienda el problema,
elabore un plan, lleve a cabo el plan y luego mire hacia atrás para ver cómo lo hizo (Polya
1957).

Enfoques de diseño descendente y ascendente

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.

La creación de prototipos funciona mal cuando los desarrolladores no son disciplinados al


escribir el mínimo de código necesario para responder una pregunta. La creación de prototipos
también funciona mal cuando la pregunta de diseño no es lo suficientemente 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).

Utilizado con disciplina, la creación de prototipos es la herramienta de trabajo que un


diseñador tiene para combatir la maldad del diseño. Utilizado sin disciplina, la creación de
prototipos añade algo de maldad propia.

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.

Si el objetivo es la garantía de calidad, tiendo a recomendar la práctica de revisión más


estructurada, las inspecciones formales, por los motivos descritos en el Capítulo 21. Pero si el
objetivo es fomentar la creatividad y aumentar el número de alternativas de diseño generadas,
no solo Para encontrar errores, los enfoques menos estructurados funcionan mejor. Después
de que haya decidido un diseño específico, puede ser apropiado cambiar a una inspección más
formal, dependiendo de la naturaleza de su proyecto.

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

5.2 Comentarios sobre metodologías populares

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 Construcción Los lenguajes de construcción incluyen todas las formas de


comunicación por las cuales el ser humano puede implantar una solución ejecutable al
computador. Se pueden dividir en:

 '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

El juego de herramientas como ya se ha mencionado, se enfoca a ciertas fases


del ciclo de vida del software, dependiendo de la metodología que se utilice, sin
embargo estas fases también son básicas y algunos ejemplos de la
implementación de Toolkit en cada fase son:

 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

Licencia GNU Lesser General Public


License

Paquete Debian libatk1.0-0

Paquete Arch Linux atk

Paquete Fedora atk

Paquete Ubuntu libatk1.0-0

Versión 2.28.1

Paquete Gentoo dev-libs/atk

Sitio web oficial

[editar datos en Wikidata]

En informática, ATK ( del inglés Accessibility Toolkit) se refiere a una Interfaz de


programación de aplicaciones (API) para desarrollar aplicaciones accesibles para
plataformas libres y de código abierto, como GNU/Linux o OpenBSD, desarrollada por
el Proyecto GNOME.
Una manera habitual de explicar un framework de accesibilidad es mediante analogía con
la arquitectura cliente-servidor. En este sentido, las tecnologías de apoyo, como
los lectores de pantalla, serían los clientes y las aplicaciones serían los servidores. En esta
arquitectura, tanto los clientes como los servidores necesitan comunicarse entre ellos,
normalmente usando la tecnología de Comunicación entre procesos de la plataforma.
Idealmente, el framework de accesibilidad expone la información de accesibilidad de los
servidores a los clientes de forma transparente.
Normalmente, tanto la parte del cliente como la del servidor usan la misma API, y el
framework de accessibilidad proporciona las implementaciones de la API para ambas
partes. En el caso de GNOME, existe una API para la parte del cliente (AT-SPI) y otra para
la parte del servidor (ATK) debido a razones históricas relacionadas con la tecnlogía de
comunicación entre procesos empleada inicialmente.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:

 Alejandro Piñeiro Iglesias


Anteriores:

 Bill Haneman
 Leon Fan
 Li Yuan

 Lenguajes de programación.

S-ar putea să vă placă și