Saltar al contenido principal
LibreTexts Español

19.6: El Arquitecto...

  • Page ID
    136372
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)

    ( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\id}{\mathrm{id}}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\kernel}{\mathrm{null}\,}\)

    \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\)

    \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\)

    \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    \( \newcommand{\vectorA}[1]{\vec{#1}}      % arrow\)

    \( \newcommand{\vectorAt}[1]{\vec{\text{#1}}}      % arrow\)

    \( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vectorC}[1]{\textbf{#1}} \)

    \( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)

    \( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)

    \( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)

    \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    “He llegado a la conclusión de que la arquitectura de software es muy difícil de definir. Se trata de una gama de artefactos que se utilizan para especificar las decisiones estratégicas sobre la estructura y el comportamiento del sistema, las colaboraciones entre los elementos del sistema y el despliegue físico del sistema” (Quatrani, 2003).

    Si bien las secciones anteriores se centraron en los fundamentos sociológicos y técnicos para construir comunidades digitales, esta sección trabaja para abordar cómo estas ideas pueden integrarse en el tejido social de una comunidad digital, su código. Esta sección está dedicada a explorar las herramientas utilizadas por los desarrolladores de software para comunicar las complejas relaciones dentro de las comunidades digitales. Una comprensión básica de estas herramientas puede aumentar el valor y la funcionalidad de estos espacios colaborativos emergentes. Las herramientas pueden proporcionar documentos de trabajo poderosos que fomenten el aporte de los diversos miembros de la comunidad que pueblan estas comunidades digitales.

    El arquitecto del sistema recopila y analiza los requisitos de software y luego documenta la funcionalidad requerida tanto para el usuario final como para la aplicación. En un esfuerzo por estandarizar la comunicación de estas complejas relaciones, los arquitectos de sistemas han comenzado a adoptar técnicas de notación basadas en el lenguaje de modelado unificado (UML).

    19.6.1.png
    Figura\(\PageIndex{1}\): No se trata de... Creado por Shawn Berney (2005)

    UML proporciona una representación abstracta de relaciones complejas. Esta notación puede ser utilizada para extender los esfuerzos de las investigaciones sociales y técnicas al proporcionar un marco de comunicación flexible y poderoso. UML es una compilación de principalmente tres notaciones comunes pero distintas (incluyendo OMT [Rumbaugh], Booch y OOSE [Jacobson]), y ahora es un estándar completamente reconocido y publicado (ISO/IEC 19501:2005) dentro de la Organización Internacional de Normalización (ISO).

    Modelado de sistemas

    La estructuración de la información es fundamental para facilitar interacciones altamente dinámicas y complejas. Para los aprendices guías de balsa, la estructura se proporciona continuamente a través de la supervisión directa Esta instrucción y supervisión proporciona a los aprendices guía valiosos comentarios y conocimientos sobre las prácticas y expectativas de la comunidad. Esta retroalimentación permite a los candidatos a la guía desarrollar y contribuir a la finalización de una experiencia de rafting segura y agradable. Al comunicar claramente cómo los aprendices de guía de balsa pueden contribuir a la comunidad profesional de rafting, los aprendices pueden ofrecer contribuciones valiosas sin imponer a las experiencias de los huéspedes.

    Las empresas de rafting brindan mucho más que guías profesionales; brindan una serie de experiencias cuidadosamente coreografiadas diseñadas para educar y entretener. Los servicios deben funcionar para lograr la experiencia de los huéspedes de la más alta calidad.

    La experiencia alcanzada dentro de una comunidad digital también puede verse como una serie de interacciones coreografiadas y secuenciadas. Estas interacciones están influenciadas tanto por el diseño arquitectónico de la comunidad digital como por los servicios prestados por los gestores de información durante la implementación de la arquitectura del sistema. El desarrollo de herramientas de modelización se han utilizado con éxito para mediar estas complejas relaciones, permitiendo a los individuos comunicar información importante sobre el diseño del sistema, los procesos de implementación del sistema y las secuencias y actividades disponibles para facilitar la participación.

    Diagramas de casos

    “El papel más importante de un modelo de caso de uso es el de la comunicación. Proporciona un vehículo utilizado por el cliente o usuarios finales y los desarrolladores para discutir la funcionalidad y el comportamiento del sistema”. (Quatrani, 2003).

    Describir cómo los usuarios interactuarán con sistemas informáticos de información altamente estructurados es una tarea importante y compleja. Desarrollar infraestructura tecnológica que modele de manera eficiente las prácticas comunitarias requiere una comprensión detallada de cómo interactúan los miembros de la comunidad. Las personas con este conocimiento suelen ser referidas como expertos de dominio. Estos expertos se encargan frecuentemente de tratar de explicar prácticas complejas e informales de gestión de la información. Los diagramas de casos de uso están diseñados para representar visualmente estas prácticas, capturando información que permite a los arquitectos de sistemas e ingenieros de software garantizar que las nuevas soluciones tecnológicas registren y referencien solo información valiosa.

    Diagramas de actividad

    “Estos diagramas representan la dinámica del sistema. Son diagramas de flujo que se utilizan para mostrar el flujo de trabajo de un sistema; es decir, muestran el flujo de control de actividad a actividad en el sistema, qué actividades se pueden realizar en paralelo, y cualquier ruta alternativa a través del flujo... se pueden crear diagramas de actividad para representar el flujo a través de casos de uso o ellos se pueden crear para representar el flujo dentro de un caso de uso particular... Los diagramas de actividad pueden [también] ser creados para mostrar el flujo de trabajo de una operación”. (Quatrani, 2003).

    Una vez que se ha identificado la información requerida, los arquitectos de sistemas comienzan a evaluar el proceso de recolección y publicación de la información para el acceso de la comunidad. Una vez más, los expertos de dominio, aquellos individuos familiarizados con las prácticas comunitarias, juegan un papel vital en la explicación de los requisitos de información de los miembros de la comunidad. En esta etapa de desarrollo del sistema, la documentación proporciona información sobre la participación de la comunidad al identificar las acciones de los miembros de la comunidad. Idealmente, estas acciones se desarrollarán utilizando una serie de componentes modulares y reutilizables.

    Diagramas de secuencia

    “Un diagrama de secuencia muestra las interacciones de objetos dispuestas en secuencia de tiempo. Representa los objetos y clases involucrados en el escenario y la secuencia de mensajes intercambiados entre los objetos necesarios para llevar a cabo la funcionalidad del escenario. Los diagramas de secuencia suelen estar asociados con realizaciones de casos de uso en la Vista Lógica del sistema en desarrollo”. (Quatrani, 2003).

    Una vez identificadas las actividades del programa, los desarrolladores de software trabajan para secuenciar la finalización de estas actividades. Las actividades de secuenciación facilitan la participación de la comunidad al definir oportunidades para involucrarse en metas y objetivos grupales. Al seleccionar cuidadosamente cómo la arquitectura del sistema de información impone restricciones a las interacciones de los miembros de la comunidad, las comunidades digitales pueden crear experiencias cuidadosamente coreografiadas.

    Diagramas de clase

    Una clase es una representación abstracta de una idea (una clase de aprobación por ejemplo). Los diagramas de clases son comúnmente utilizados por los ingenieros de software para proporcionar una representación abstracta de la lógica de programación (las conexiones entre las ideas, por ejemplo, asegurando que se obtenga el estado de aprobación antes de permitir que se produzca la publicación). La lógica de programación se utiliza para implementar una solución tecnológica que refleje el proceso de almacenamiento (grabación y referencia) y recuperación (publicación y facilitación) de información digital. Los diagramas de clases también permiten a los programadores comunicar la capacidad técnica del software para integrar características adicionales o extensiones modulares de terceros, un componente importante de la implementación de una estrategia SOA.

    La aplicación de UML

    Al compartir el proceso utilizado para integrar la nueva infraestructura tecnológica, los profesionales de la comunidad digital pueden comenzar a evaluar selectivamente la arquitectura que se encuentra dentro de varios paquetes de software. Cuando este proceso de evaluación se combina con la consulta comunitaria, se pueden priorizar las iniciativas de desarrollo y definir claramente los requisitos de integración del sistema.

    El proceso de implementación

    Estas herramientas de comunicación se pueden combinar para crear un proceso sólido para administrar el ciclo de vida de la información y proporcionar información sobre el diseño y desarrollo de la infraestructura comunitaria. La capacidad de derivar procesos a partir del modelo de información de negocios (como los diagramas UML) se puede utilizar para mapear patrones de interacción de información y facilitar la adopción de contenido (Hinkelman, Buddenbaum & Zhang, 2006, p. 375). Las estructuras de datos existentes pueden mapearse y transformarse la información para permitir el intercambio de datos entre sistemas de información dispares, un proceso “estratégicamente importante para que las empresas aumenten la eficiencia de la tecnología de la información estén reutilizando e integrando [datos] existentes” (Roth et al, 2006, p. 393).

    Colaboradores


    This page titled 19.6: El Arquitecto... is shared under a CC BY-SA license and was authored, remixed, and/or curated by Shawn Berney (BC Campus @ Commonwealth of Learning) .