ARQUITECTURA DE SOFTWARE SESIÓN 1

ESCUELA DE CIENCIAS EMPRESARIALES

NÚCLEO DE FORMACIÓN ESPECÍFICA

CARTILLA DE TRABAJO

PRIMERA SESIÓN

ARQUITECTURA DE SOFTWARE

Elaborada por

JORGE RODRIGUEZ INGENIERO DE SISTEMAS

CUADRO 1. CONTROL DEL DOCUMENTO CARTILLA DIDÁCTICA

PARTICIPANTE

S

NOMBRE CARGO DEPENDENCIA FECHA

Autor Jorge

Rodríguez

Docente Sistemas 19/07/2013

Revisión Franky

Carrillo

Coordinador Sistemas 20/07/2013

Aprobación Luis

Eduardo

Rodríguez

CUADRO 2. CONTROL DE ESTADO DE PREPARACIÓN DE LA CARTILLA

EDUCACIÓN A DISTANCIA

VERSIÓN

No.

FECHA DE

FINALIZACIÓN

DE SU

ELABORACIÓN

DESCRIPCIÓN DEL

CAMBIO

SOLICITADO

POR:

01 19/07/2013 Construcción de las

cartillas de Arquitectura

de Software en la

Corporación

Iberoamericana de

Estudios CIES en

función a su cadena de

valor con el fin de

asegurar la calidad de

sus servicios.

NOMBRE: ___________________________________________________ C.C. : ___________________________________________________ CARRERA:___________________________________________________

JORNADA: MARTES Y MIERCOLES ( ) A.M. _____ P.M. _____ JUEVES Y VIERNES ( ) A.M. _____ P.M. _____ SÁBADOS ( ) A.M. _____ P.M. _____ DOMINGOS ( )

NOMBRE DEL PROFESOR: __________________________________ FECHA : __________________________________ CALIFICACIÓN : __________________________________

___________________________ Firma Docente

Sr. Docente: No firme la cartilla sino está debidamente diligenciada en todos sus campos.

DERECHOS DEL ESTUDIANTE EN EL AULA DE CLASE

Exigir el uso de la cartilla

Exigir firma y sello de la cartilla por parte del docente.

Exigir sus notas al final del módulo.

NINGUNA RECLAMACIÓN SERA ACEPTADA SI SU CARTILLA NO ESTÁ DILIGENCIADA EN TODOS SUS CAMPOS, CON FIRMA Y SELLO DEL

TABLA DE CONTENIDO

ARQUITECTURA DE SOFTWARE

MODELO

UML

ACTIVIDADES

ARQUITECTURA DE SOFTWARE

PROPÓSITO GENERAL DEL MÓDULO

Este módulo de Arquitectura de software le prepara para conozca y maneje los conceptos, las aplicaciones y el desarrollo básicos de la teleinformática.

OBJETIVOS

GENERAL

Conocer los elementos, las aplicaciones y el desarrollo de proyectos utilizando como apoyo el lenguaje de modelado, a través de una arquitectura de software bien definida.

ESPECIFICOS

 Realizar la planeación y Diseño de proyectos de software con todos sus

elementos constitutivos.

 Manejar los diferentes conceptos básicos sobre modelado de proyectos

en software.

GUIAS DE TRABAJO

Las guías de trabajo están orientadas a desarrollar cualquier tipo de representación de proyectos de software.

SESIÓN 1.

 Conceptualización básica de arquitectura de software y modelado.

SESIÓN 2.

 Conceptualización para la representación de casos de uso.

SESIÓN 3.

 Ejemplos y ejercicios de casos de uso.

SESIÓN 4.

SESION No. 1

OBJETIVO GENERAL

Conceptualización básica de arquitectura de software y modelado.

OBJETIVOS ESPECÍFICOS

 Identificar los conceptos básicos de arquitectura de software.

 Reconocer los conceptos básicos para la solución de proyectos a través

del modelado.

METODOLOGÍA

El modulo de Arquitectura de Software será desarrollado en cuatro (4) sesiones; cada sesión tendrá una duración de cuatro (4) horas; todas ellas dirigidas por el profesor de la asignatura quien emitirá conceptos y despejará inquietudes a los estudiantes; el alumno deberá consultar e investigar permanentemente, desarrollar las practicas y organizar el portafolio virtual.

Con esta metodología el estudiante tendrá la oportunidad de practicar el 100% los conocimientos aprendidos en clase y poder desarrollar con destreza, además de las prácticas y actividades de la guía cualquier aplicación.

1. ARQUITECTURA DE SOFTWARE

DEFINICIÓN

La arquitectura es el conjunto de decisiones significativas sobre la organización de un sistema de software que define los principios que guían el desarrollo, los componentes principales del sistema, sus responsabilidades y la forma en que se interrelacionan”.

Arquitectura del Software se define en la IEEE Std 1471-2000 como: “La Arquitectura del Software es la organización fundamental de un sistema formada por sus componentes, las relaciones entre ellos y el contexto en el que se implantarán, y los principios que orientan su diseño y evolución”.

Arquitectura de un Software es el proceso por el cual se define una solución para los requisitos técnicos y operacionales del mismo. Este proceso define qué componentes forman el software, cómo se relacionan entre ellos, y cómo mediante su interacción llevan a cabo la funcionalidad especificada, cumpliendo con los criterios previamente establecidos; como seguridad, disponibilidad, eficiencia o usabilidad.

 La Arquitectura representa la base de un sistema software y debe ser construida pensando en satisfacer las necesidades actuales y en proporcionar al software las capacidades necesarias para permitir su mantenimiento y evolución de acuerdo a las necesidades de negocio y a las solicitudes de los clientes.

 La Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema, programa o aplicación y tiene la responsabilidad de:

 Definir los módulos principales

 Definir las responsabilidades de cada uno de estos módulos

 Definir la interacción que existirá entre dichos módulos:

 Control y flujo de datos

 Secuenciación de la información

 Protocolos de interacción y comunicación

 La Arquitectura del Software aporta una visión abstracta de alto nivel, posponiendo el detalle de cada uno de los módulos definidos a pasos posteriores del diseño.

 La Arquitectura debe ser una respuesta no una imposición. Necesitamos soluciones para problemas reales, no inventar problemas para poder empatar con las nuevas soluciones.

EL ARQUITECTO

Se debe contar con un conjunto de habilidades y conocimientos para ejercer el rol de arquitecto: Cada escenario plantea retos, condiciones y necesidades diferentes.

El arquitecto software es el encargado de establecer a qué nivel, con qué estrategia y que herramientas son necesarias para realizar una implementación que satisfaga los requisitos funcionales y no funcionales de los sistemas.

El arquitecto debe ser una persona capaz de identificar las necesidades de los negocios, las habilidades de su equipo de trabajo y la viabilidad de las tecnologías disponibles para el desarrollo del software.

Para mayor información consulte:

http://unpocodejava.wordpress.com/2012/05/28/que-es-un-arquitecto-software/

La arquitectura de software es importante como disciplina debido a que los sistemas de software crecen de forma tal que resulta muy complicado que sean diseñados, especificados y entendidos por un solo individuo. Uno de los aspectos que motivan el estudio en este campo es el factor humano, en términos de aspectos como inspecciones de diseño, comunicación a alto nivel entre los miembros del equipo de desarrollo, reutilización de componentes y comparación a alto nivel de diseños alternativos (Kazman, 1996).

El proceso de recolección, mantenimiento y validación de la información arquitectónica es tedioso y altamente propenso a errores. Estos son precisamente los candidatos a ser cubiertos por una herramienta (Kazman, 1996). El control de revisión, análisis de dependencias y proceso de pruebas son sólo algunos ejemplos de herramientas que automatizan exitosamente las tareas que se repiten constantemente durante el desarrollo.

Son esenciales realizar las siguientes interrogantes para cubrir este punto:

¿En qué entorno se desplegará nuestro software? ¿Cómo se pondrá en producción nuestro software? ¿Cómo utilizarán los usuarios nuestro software?

¿Existen requisitos adicionales que el software debe cumplir? (Por ejemplo: seguridad, rendimiento, concurrencia, configuración, disponibilidad, entre otros)

¿Cuáles serían los cambios sobre la arquitectura propuesta, que impactarían al software durante o después de desplegarse?

Para diseñar la arquitectura de un software es de vital importancia tomar en cuenta los intereses de los distintos agentes que participan. Estos, son los usuarios del software, el propio software y los objetivos del negocio.

Cada uno de ellos establece requisitos y restricciones que deben tomarse en cuenta para el diseño de la arquitectura, los que en algún momento podrían entrar en conflicto.

Para los usuarios es importante que el software responda a la interacción de una forma fluida, mientras que para los objetivos del negocio es importante que el software cueste poco. Los usuarios pueden querer que se implemente primero una funcionalidad útil para su trabajo del día a día, mientras que el software puede tener prioridad en que se implemente la funcionalidad que permita definir su estructura.

He aquí, que el trabajo del arquitecto es delinear los escenarios y requisitos de calidad importantes para cada agente así como los puntos clave que debe cumplir y las acciones o circunstancias que no deben ocurrir.

QUE NO ES UNA ARQUITECTURA

 La arquitectura es sólo un documento

 La arquitectura es la estructura

 La arquitectura es el diseño

 La arquitectura es una ciencia

 La arquitectura es un arte

 La arquitectura es la infraestructura

 <mi tecnología favorita> es arquitectura

 Una buena arquitectura es el trabajo de un solo arquitecto

 La arquitectura puede ser presentada en un solo diagrama

 La arquitectura no se puede medir ni evaluar.

Finalmente, resumamos que la Arquitectura de Software debería poseer las siguientes capacidades:

 Mostrar la estructura del software, pero ocultando los detalles.

 Concebir y diseñar todos los casos de uso.

 Satisfacer en la medida de lo posible los intereses de los agentes.

 Ocuparse de los requisitos funcionales y de calidad.

 Determinar el tipo de software a desarrollar.

 Determinar los estilos arquitecturales que se usarán.

FLUJOS Y ACTIVIDADES DENTRO DE LA ARQUITECTURA

Dentro de la arquitectura se consideran los siguientes flujos y actividades:

ESTRUCTURAS Y VISTAS ARQUITECTÓNICAS

Las estructuras son el conjunto de elementos y relaciones en si mismo implementados en software y hardware (asignaciones).

Las vistas son las representaciones de las estructuras descriptas en un lenguaje que permita un entendimiento del stakeholder (organización afectada) al cual se dirige.

ESTRUCTURAS Y ELEMENTOS

La arquitectura se encuentra compuesta de módulos, componentes y conectores, cumpliendo las siguientes funciones:

ESTRUCTURAS Y ALOCACIONES

Entre las principales vistas de la arquitectura de software se encuentran:

ENTRADAS DE LA ARQUITECTURA DE SOFTWARE

Entre las mínimas entradas que se deben tener en cuenta para la definición de una arquitectura de software se encuentran:

Los requerimientos de software son las características que debe tener el software instalado en una computadora para poder soportar y/o ejecutar una aplicación o un dispositivo específicos. Contrasta con los requerimientos de hardware.

Los requerimientos de software pueden ser:

 Requisitos de sistema operativo.

 Requisitos de aplicaciones específicas instaladas.

 Requisitos de ciertas aplicaciones no instaladas en el mismo sistema.

 Requisitos de determinadas configuraciones en el sistema operativo o en ciertas aplicaciones.

Ejemplo de requerimientos de software:

 Sistema operativo: Windows XP (o superior).

 Debe estar instalado: Flash Player 9 o superior.

 Debe estar instalada la máquina virtual JAVA 1.6 o superior.

Los requerimientos se clasifican en funcionales y no funcionales.

REQUERIMIENTOS FUNCIONALES

Requerimientos funcionales son las capacidades o funcionalidades que son necesitadas por el usuario para completar su trabajo. En otras palabras, lo que el sistema ha de proveer. Estos definen lo que el usuario necesita. Es el que, no el cómo. Los requerimientos son especificados en detalle como:

 Procesos de Negocio

 Casos de Uso

Los casos de uso definen una interacción entre un actor y el sistema, para lograr un objetivo de negocio específico en un lugar y momento especifico.

REQUERIMIENTOS NO FUNCIONALES (ATRIBUTOS DE CALIDAD)

Los atributos de calidad, no funcionales, son los aspectos del sistema, que en general, no afectan directamente a la funcionalidad necesitada, sino que definen la calidad y las características que el sistema debe soportar. Pueden ser determinísticos o probabilísticos, generalmente poseen números.

Estos son:

 Performance

 Availability (Disponibilidad)

 Security (Seguridad)

 Testability (Testeabilidad)

 Modifiability (Modificabilidad)

RESTRICCIONES DE NEGOCIO Y TECNOLOGÍA

Las restricciones de negocio y de tecnología se refieren a decisiones en firme, tomadas antes del comienzo de la fase de diseño de la Arquitectura A nivel de restricciones de tecnología se tiene la utilización de sistemas legados, integración con sistemas existentes, uso mandatario de tecnologías particulares, protocolos o estándares de obligatorio cumplimiento, etc.

A nivel de las restricciones de negocio se encuentra el público objetivo, costo y beneficios esperados, vida útil esperada del sistema, disponibilidad y conocimientos requeridos por el personal que usará el sistema, estrategias de amortización del sistema a construir, etc.

OTROS EJEMPLOS DE RESTRICCIONES

 Restricciones de Negocio

 Tiempo al mercado/Limitaciones de Agenda

 Limitaciones de Presupuesto

 Restricciones Legales

 Restricciones de Regulaciones

 Aspectos logísticos.

 Restricciones de Tecnología

 Plataformas Tecnológicas

 Sistemas Operacionales

 Hardware

 Lenguajes de Programación

La restricción debe ser consignada en el siguiente formato:

MOTIVADORES DE NEGOCIO

Esta sección busca identificar los motivadores de negocio de la organización. Normalmente estos motivadores son encontrados, respondiendo a las preguntas:

 Cómo genera utilidad la organización?

 De dónde provienen las utilidades de la organización?

 Cuáles son los elementos claves del negocio?

En resumen, un motivador de negocio es una descripción corta que define clara y específicamente los resultados deseados de negocio de una organización así como las actividades necesarias para lograrlos. Los motivadores de negocio deben ser: Específicos, Medibles, Agresivos pero viables, Orientados al resultado y limitados en el tiempo. El objetivo es hacer una lista priorizada de motivadores de negocio.

 AYUDA PARA EL USO DEL FORMATO:

El nombre del motivador:

Sigue en general la regla: <verbo> + <elemento a medir> + <área de énfasis>

Ejemplo: Incrementar ventas en las áreas metropolitanas.

La descripción del motivador:

Sigue en general la regla: <Retorno esperado del negocio>+ Mediante+<Actividad planeada de negocio>

Ejemplo: Incrementar ventas en 15 % mediante la apertura de nuevas oficinas.

La medida:

Define en una frase como valorar el impacto en el negocio del motivador. Se organiza por rangos

y se determina para cada rango, la unidad de medida del impacto. Adicionalmente, se definen los valores mínimos y máximos para cada rango de impacto.

Ejemplo:

Medida: Crecimiento de las ventas en áreas metropolitanas medido en millones de pesos.

Ninguna: 0 – 0.9 millones Bajo: 1 millón – 99 millones Moderado: 100 y 499 millones Fuerte: 500 y 899 millones Muy Fuerte: 900 millones o más

La asociación con el negocio define el motivador a que área organizacional pertenece:

Ejemplo:

Definido Por: Gerente de Ventas

Ejecutado Por: Director y Ejecutivos de Ventas

Ubicación en el portafolio: Servicios persona a persona

DIAGRAMA DE ARQUITECTURA

Toda solución técnica debe tener al menos los siguientes elementos:

 Actores o Roles Principales

 Los módulos/componentes principales

 Los Nodos principales

 Repositorios de Datos

 Como fluye la información

 Las zonas de red.

Ejemplo 1:

2. MODELO

El modelo es la representación de un objeto, sistema o idea, de forma diferente al de la entidad misma. El propósito de los modelos es ayudarnos a explicar, entender o mejorar un sistema. Un modelo de un objeto puede ser una réplica exacta de éste o una abstracción de las propiedades dominantes del objeto.

Un modelo se utiliza como ayuda para el pensamiento al organizar y clasificar conceptos confusos e inconsistentes. Al realizar un análisis de sistemas, se crea un modelo del sistema que muestre las entidades, las interrelaciones, etc. La adecuada construcción de un modelo ayuda a organizar, evaluar y examinar la validez de pensamientos.

Al explicar ideas o conceptos complejos, los lenguajes verbales a menudo presentan ambigüedades e imprecisiones. Un modelo es la representación concisa de una situación; por eso representa un medio de comunicación más eficiente y efectivo.

OBJETIVO DEL MODELADO

La empresa de software exitosa es aquélla que produce de una manera consistente software de calidad que satisface las necesidades de sus usuarios y la empresa; para producir software que cumpla su propósito, hay que conocer e involucrar a los usuarios de forma disciplinada con el fin de extraer los requisitos reales del sistema., hay que idear una sólida base arquitectónica que sea flexible al cambio, software rápido, eficiente, hay que tener gente apropiada y el enfoque apropiado, hay que disponer de un proceso de desarrollo sólido que pueda adaptarse a las necesidades cambiantes del problema y la tecnología.

El modelado es una parte central de todas las actividades que conducen a la producción de buen software.

 Construimos modelos para comunicar la estructura y el comportamiento del sistema.

 Construimos modelos para visualizar y controlar la arquitectura del sistema.

 Construimos modelos para comprender mejor el sistema que estamos construyendo.

 Construimos modelos para controlar el riesgo.

IMPORTANCIA DE MODELAR

Un modelo proporciona los planos de un sistema, y estos pueden involucrar planos detallados, así como los generales que ofrecen una visión global del sistema. Un buen modelo incluye aquellos elementos que tienen una gran influencia.

 Objetivos del modelado

 Ayudan a visualizar cómo es ó queremos que sea un sistema

 Permite especificar la estructura o el comportamiento de un sistema

 Proporcionan plantillas que nos guían en la construcción de un sistema

 Documentan las decisiones que hemos adoptado.

NOCIONES DEL MODELADO

 La elección de qué modelos crear tiene una profunda influencia sobre cómo se acomete un problema y cómo se da forma a una solución

Los modelos elegidos en el software, pueden afectar mucho a nuestra visión:

 Si construimos un sistema con la mirada de un desarrollador de bases

de datos, nos centraremos en los modelos entidad-relación.

 Si construimos un sistema con la mirada de un analista estructurado, se

obtendrán modelos centrados en los algoritmos.

 Si construimos un sistema con mirada de un desarrollador orientado a

objetos, se centra en una arquitectura con un mar de clases y patrones de interacciones.

Por lo tanto cada visión del mundo conduce a un tipo de sistema diferente, con diferentes costos y beneficios.

 Cualquier modelo puede ser expresado a diferentes niveles de precisión

Un analista o un usuario final se centrará en el qué; un desarrollador se centrará en el cómo. Tanto uno como otros querrán visualizar un sistema a diferentes niveles de detalle en momentos diferentes.

 Los mejores modelos están ligados a la realidad.

En el software, el talón de Aquiles de las técnicas de análisis estructurado es el hecho de que hay una desconexión básica entre los modelos de análisis y el modelo de diseño de sistema. No poder salvar este abismo hace que el sistema concebido y el sistema construido diverjan con el paso del tiempo.

En los sistemas orientados a objetos, es posible conectar todas las vistas casi independientes de un sistema en un todo semántico.

 Solo un modelo no es suficiente. Cualquier sistema no trivial se aborda mejor a través de un pequeño conjunto de modelos casi independientes.

Dependiendo de la naturaleza del sistema pueden ser más importantes que otros.

MODELADO ORIENTADO A OBJETOS

Hay varias formas de enfocar un modelo en el software. Las dos formas más comunes son la perspectiva orientada a objetos y la perspectiva algorítmica, esta última tiene una visión conduce a los desarrolladores a centrarse en cuestiones de control y de descomposición de algoritmos grandes en otros más pequeños y es algo complejo, mientras la visión orientada o objetos el principal bloque de construcción de todos los sistemas software es objeto o clase, es decir un objeto es una cosa, generalmente extraída del vocabulario del espacio del problema o del espacio de la solución; una clase es una descripción de un conjunto de objetos similares.

2.1 UML

UML son las siglas del Lenguaje Unificado de Modelado (Unified Modeling Language, UML), el cual es un lenguaje estándar para escribir planos de software.

Este lenguaje de modelado puede utilizarse para visualizar, especificar, construir y documentar los artefactos de un sistema que involucra una gran cantidad de software.

 Alcance general de UML

UML es un lenguaje para:

 Visualizar

 Especificar

 Construir

 Documentar

 UML es un lenguaje. Un lenguaje de modelado es un lenguaje cuyo vocabulario y reglas se centran en la representación conceptual y física de un sistema, por lo tanto es un lenguaje estándar para los planos del software.

 UML es un lenguaje para visualizar. Un programador cuando esta modelando tiene que pensar en:

 Primero, la comunicación de esos modelos conceptuales a otros está sujeta a errores a menos que cualquier persona implicada hable del mismo lenguaje.

 Segundo, que el software no puede entender a menos que se construyan modelos que trasciendan el lenguaje de programación textual.

 Tercero, si el desarrollador que escribió el código no dejó

documentación sobre los modelos, esa información se perderá y será parcialmente reproducible a partir de la implementación.

UML no es un simple montón de símbolos gráficos, en cada símbolo hay una semántica definida.

 UML es un lenguaje para construir. En UML, sus modelos pueden conectarse en forma directa a gran variedad de lenguajes de programación, esta correspondencia permite ingeniería directa: la generación de código a partir de un modelo UML en un lenguaje de programación, también se puede reconstruir a partir de una implementación.

 UML es un lenguaje para documentar. Una organización de software que trabaje bien produce:

 Requisitos

 Arquitectura

 Diseño

 Código fuente

 Planificación de proyectos

 Pruebas

 Prototipos

 Versiones

UML cubre la documentación de la arquitectura y proporciona requisitos y pruebas y las actividades de planificación de proyectos.

UTILIZACIÓN DE UML

 UML se puede implementar en:

 Sistemas de información de empresas

 Bancos y servicios financieros

 Telecomunicaciones

 Transporte

 Defensa / industrias aeroespacial

 Comercio

 Electrónica médica

 Ámbito científico

 Servicios distribuidos basados en la Web.

UML UN MODELO PARA CONCEPTOS

Para entender UML, se necesita adquirir un modelo conceptual del lenguaje, y esto se requiere aprender tres elementos principales:

 Los bloques básicos de construcción de UML,

 Las reglas que dictan cómo se pueden combinar estos bloques básicos

BLOQUES DE CONSTRUCCIÓN DE UML

UML tiene tres clases de bloques de construcción:

 Elementos

 Relaciones

 Diagramas

Los elementos son abstracciones que son cuidados de primera clase en un modelo, las relaciones ligan estos elementos entre sí; y los diagramas agrupan colecciones interesantes de elementos

ELEMENTOS ESTRUCTURALES

Son los nombres de los modelos, son parte estática de un modelo y representan cosas que son conceptuales, hay 7:

Primero.- Es una clase es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica; implementa una o más interfaces

Ventana Origen Tamaño Abrir() Cerrar() Mover() Dibujar()

Segundo Una interfaz es una colección de operaciones que especifican un servicio de una clase o componente, esta describe el comportamiento visible externamente de ese elemento, puede representar el comportamiento completo de una clase o componente

Una interfaz define un conjunto de especificaciones de operaciones, pero nunca un conjunto de implementaciones de operaciones.

Tercero, Una colaboración define una interacción y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamiento de sus elementos, tienen dimensión tanto estructural como de comportamiento, estas representan la implementación de patrones que forman un sistema

Una clase puede participar en varias colaboraciones,

Cadena de responsabilidad

secuencias de acciones que produce un resultado observable de interés para un actor en particular, es estructurar los aspectos de comportamiento de un modelo.

Es realizado por una colaboración

Realizar Pedido

Quinto Clase activa, es una clase cuyos objetos tienen uno o más procesos o hilos de ejecución y por lo tanto pueden dar origen a actividades de control, presentan elementos cuyo comportamiento es concurrente con otros.

GestorEventos

Suspender() VaciarCola()

Sexto Un componente es una parte física y reemplazable de un sistema que conforma con un conjunto de interfaces y proporciona la implementación de dicho conjunto. Representa típicamente el empaquetamiento físico de diferentes elementos lógicos, como clases, interfaces y colaboraciones.

Séptimo Es un Nodo, un elemento físico que existe en tiempo de ejecución y representa un recurso computacional que por lo general dispone de algo de memoria y con frecuencia, capa con capacidad de procesamiento.

servidor

Estos elementos son los estructurales básicos que se puede incluir en un modelo UML.

También existen variaciones de estos siete elementos, tales como actores, señales, utilidades, procesos e hilos, y aplicaciones, documentos, archivos, bibliotecas, páginas y tablas.

ELEMENTOS DE COMPORTAMIENTO

Son las partes dinámicas de los modelos, son los verbos y representan comportamiento en el tiempo y el espacio. Hay dos tipos principales de elementos de comportamiento:

 Primero. Una interacción, es un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular, para alcanzar un propósito específico. Una interacción, involucra muchos otros elementos, incluyendo mensajes, secuencias de acción, y enlaces.

 Segundo. Una máquina de estados es un comportamiento que especifica las secuencias de estados por las que pasa un objeto o una interacción durante su vida en respuesta a eventos, junto con sus reacciones a estos eventos.

El comportamiento de una clase individual o una colaboración de clases pueden especificarse con una máquina de estado, e involucra a otros elementos, incluyendo estados, transiciones, eventos, y actividades

Estos dos elementos básicos están conectados normalmente a diversos elementos estructurales, principalmente clases, colaboraciones y objetos.

 Elementos de agrupación. Son las partes organizativas de los modelos, son cajas en las que puede descomponerse un modelo. Un paquete es un mecanismo de propósito general para organizar elementos en los grupos. Los elementos estructurales, los elementos de comportamiento e incluso otros elementos de agrupación pueden incluirse en un paquete., también es puramente conceptual.

Reglas del negocio

Elementos de anotación. Son las partes explicativas de los modelos., pueden aplicar para describir, clarificar y hacer observaciones sobre cualquier elemento de un modelo, la Nota es simplemente un símbolo para mostrar las restricciones y comentarios junto a un elemento o una colección de elementos.

Nota

LAS RELACIONES EN UML

Existen las siguientes relaciones:

 Dependencia. Es una relación semántica entre dos elementos, en la cual un cambio a un elemento independiente puede afectar a la semántica del otro elemento dependiente

Depéndencias

 Asociación. Es una relación estructural que describe un conjunto de enlaces, los cuales son conexiones entre objetos. La agregación es un tipo especial de asociación, en que representa una relación estructural entre un todo y sus partes

0....1 *

patrón empleado

 Generalización. Es una relación de especialización / generalización en la cual los objetos del elemento especializado (hijo) pueden sustituir a los objetos del elemento general (padre). De esta forma, el hijo comparte la estructura y el comportamiento del padre.

Generalizaciones

 Realización. Es una relación semántica entre clasificadores, en donde un clasificador especifica un contrato que otro clasificador garantiza que cumplirá. Se pueden encontrar relaciones de realización en dos sitios: entre interfaces y las clases y componentes que las realizan, entre los casos de uso y las colaboraciones que los realizan.

Realización

DIAGRAMAS DE UML

Un diagrama es la representación gráfica de un conjunto de elementos, visualizado la mayoría de las veces como un grafo conexo de nodos (elementos) y arcos (relaciones). Son 9 los diagramas que incluye UML

Diagrama de clases. Muestra un conjunto de clases, interfaces y colaboraciones, así como sus relaciones, cubren la vista de diseño estático de un sistema, incluyen clases activas cubren la vista de procesos estáticos de un sistema.

Diagrama de objetos. Muestra un conjunto de objetos y sus relaciones representan instantáneas de instancias de los elementos encontrados en los diagramas de clase. Cubren la vista de diseño y proceso estático de un sistema.

Diagrama de casos de uso. Muestra un conjunto de casos de uso y actores y sus relaciones Cubren la vista de casos de uso estática de un sistema.

Los siguientes diagramas son especialmente importantes en el modelado y organización del comportamiento de un sistema.

Diagrama de secuencia. Es un diagrama de interacciones que resalta la ordenación temporal de los mensajes. Es importante mencionar que los diagramas de interacción entre un conjunto de objetos y sus relaciones, incluyendo los mensajes que pueden ser enviados entre ellos.

Diagrama de colaboración. Es un diagrama de interacción que resalta la organización estructural de los objetos que envían y reciben mensajes.

Diagrama de estados (statechart). Muestra una máquina de estados, que consta de estados transiciones, eventos y actividades. Cubren la vista dinámica de un sistema y el comportamiento de una interfaz, una clase o una colaboración y resaltan el comportamiento dirigido por eventos de un objeto.

Diagrama de actividades. Muestra el flujo de actividades dentro de un sistema. Cubren la vista dinámica, son importantes al modelar el funcionamiento del un sistema y resaltan el flujo de control de objetos.

Diagrama de componentes. Muestra la organización y las dependencias entre un conjunto de componentes, cubren la vista de implementación estática, se relacionan con diagramas de clase en que un componente se corresponde con una o más clases, interfaces o colaboraciones.

LOS MECANISMOS DE UML

Los siguientes mecanismos que se aplican de forma consistente a través de todo el lenguaje:

 Especificaciones

 Adornos

 Divisiones comunes

 Mecanismos de Extensibilidad.

 Especificaciones. Las especificaciones, proporcionan una explicación textual de la semántica de ese bloque de construcción; se utiliza para visualizar un sistema, y también para detallar el sistema.

Las especificaciones en UML proporcionan una base semántica que incluye a todos los elementos de todos los modelos de un sistema, y cada elemento está relacionado con otros de manera consistente.

Los diagramas de UML son así simples proyecciones visuales de esa

base y cada diagrama revela un aspecto específico interesante del sistema.

 Adornos. La notación de la clase también revela los aspectos más importantes de una clase a saber: su nombre, atributos y operaciones.

La especificación de una clase puede incluir otros detalles, tales como si es abstracta o la visibilidad de sus atributos y operaciones. Muchos de estos detalles se pueden incluir como adornos gráficos o textuales en la notación rectangular básica de la clase.

Transacción

+ Ejecutar()

+ Rollback()

# prioridad()

Arquitectura

Ciente

Nombre Dirección teléfono

Elisa

La segunda división la tenemos entre interfaz e implementación. Una interfaz declara un contrato, y una implementación representa una realización concreta de ese contrato, responsable de hacer efectiva la forma fidedigna la semántica completa de la interfaz

Asistenteortog.dll

 Mecanismos de Extensibilidad son:

 Estereotipos

 Valores etiquetados

 Restricciones

Estereotipo. Extiende el vocabulario de UML, permitiendo crear nuevos tipos de bloques de construcción que deriven de los existentes pero sean específicos a un problema.

 Restricción. extiende la semántica de un bloque de construcción de UML, permitiendo añadir nuevas reglas o modificar las existentes.

ACTIVIDADES

ACTIVIDAD 1.

Consultar en qué consisten cada una de las vistas principales de la arquitectura de software, documentar en el blog del grupo y socializarlas a través de comentarios entre los blogs todo el curso.

ACTIVIDAD 2.

Plantear un sistema e identificar los requerimientos funcionales y no funcionales, exponer en el blog.

ACTIVIDAD 3.

Para el anterior sistema diligenciar un formato de restricción de negocio y uno de tecnología, así como el formato de motivadores de negocio. Exponer las imágenes en el blog.

ACTIVIDAD 4.

BIBLIOGRAFÍA COMENTADA

Título Editorial Comentarios Autor/es

A UML Pattern Language

Macmillan Technical Publishing

Indianapolis 2000

Desarrolla el concepto de patrón aplicable en todos los artefactos de

UML

Paul Evitts

Applying UML and Patterns

An Introduction to Object-Oriented Analysis and Design

second edition

-Prentice Hall

New Jersey

2001

Una de las mejores introducciones a UML y a la utilización de patrones (la segunda edición largamente esperada

aún mejor)

<<imprescindible>>

<<Novedad>>

Craig Larman

Applying Use Case Driven Object Modeling with UML

Addison Wesley

Boston Massachusetts

2001

Desarrollo de un caso práctico sobre comercio electrónico para mostrar los

distintos elementos que interactúan dentro de un Caso de Uso

<<Novedad>> Dough Rosenberg & Kendall Scott El Lenguaje Unificado de Modelado Addison Wesley Madrid 1999

Libro introductorio sobre la notación

UML escrito por sus creadores Booch Grady

James Rumbaugh Ivar Jacobson El Lenguaje Unificado de Modelado. Manual de

Referencia

Addison Wesley

Madrid

2000

La referencia definitiva sobre la notación UML escrita por sus

creadores James Rumbaugh Ivar Jacobson Grady Booch

El Proceso Unificado de Desarrollo de

Software

Addison Wesley

Madrid

2000

La guía completa del Proceso Unificado escrita por sus creadores