Tema # 1 CONSIDERACIONES GENERALESvirtual.usalesiana.edu.bo/web/contenido/dossier/22012/1769.pdf ·...

Analisis y Diseño II Ing. Nela Benavides Ignacio

1

Tema # 1 CONSIDERACIONES GENERALES

1.- Concepto de Sistema.- Es un conjunto de elementos, componentes, objetos relacionados entre sí

que persiguen un objetivo común.

2.- Clasificacion de sistemas.- Básicamente se clasifican en sistemas físicos y lógicos. Un sistema

físico es un conjunto de elementos materiales, ocupan un espacio físico, ejemplos: cuerpo humano,

sistema computacional, edificio. Un sistema lógico es abstracto, es conceptual, está formado por ideas,

ejemplo: sistema social, sistema religioso, etc.

3.- Categorización de sistemas.- Según Arbones, Johasen y Jerez los sistemas tienen la siguiente

clasificación:

Estelares galaxias, sistema solar, luna

Físicos Geológicos: ríos, cordilleras, montañas

Moleculares: Orgánicos, átomos

Naturales

Animales

Vivientes Plantas

Humanos

Sistemas sociales: leyes, doctrinas, costumbres

Hechos por el hombre Sistemas de transporte: aereo, terrestre,

Sistemas de comunicación: vía satelite, antenas

En resumen podemos clasificar a los sistemas de la siguiente manera:

a) Sistemas Naturales y hechos por el hombre

b) Sistemas físicos y conceptuales

c) Sistemas estáticos y dinámicos

d) Sistemas abiertos y cerrados

Un sistema estático tiene una estructura sin actividad. Ejemplo: puente, almacen

Un sistema dinámico cambia su estructura con la actividad.

Un sistema abierto es cuando sus actividades son exógenas, cualquier empresa

Un sistema cerrado es cuando no intercambia información con el medio ambiente. Empresa quebrada,

dos reacciones químicas, un automóvil

4.- Componentes básicos de un sistema.- Un sistema debe tener tres elementos: entrada, proceso y

salida.

La entrada se define como el componente impulsor del sistema, es cualquier cosa que ingresa al

sistema

El proceso es la actividad que transforma el insumo o entrada en producto o salida.

La salida es el resultado del proceso, es todo lo que sale o egresa del sistema.


2

Otro componente es la retroalimentación (feed back), que se define como un control que actua como

filtraje dentro del sistema

5.- Otros elementos.- Dentro la teoría de sistemas, interesa también conocer otros elementos como:

a) Entidad.- Sirve para denotar a un objeto de interés de estudio en un sistema, tambien se puede

definir como un subsistema del mismo.

b) Atributo.- Es una cualidad o una propiedad de una entidad

c) Actividad del sistema.- Es todo proceso que provoca cambios en los sistemas (hemeostasis)

d) Medio Ambiente.- Es el medio donde va a interactuar el sistema, a veces cuando ciertas

actividades del sistema producen cambios que no reaccionan en el mismo, se dice que los

cambios que ocurren fuera del sistema ocurren en el medio ambiente del sistema.

e) Estado del sistema.- es la representación de las entidades, atributos y actividades en un instante

específico de tiempo.

6.- Definición de un Sistema de Información.-

Es un conjunto de elementos que interactuan entre sí con el fin de apoyar las actividades de una

empresa.

Es un conjunto de datos, procedimientos y personas

Es una cadena que se filtra en toda la empresa, organización o institución, sirve a todos los

demás elementos.

Es un componente del sistema empresa

SISTEMA EMPRESA

7.- Componentes de un sistema de Información.-

1.- Los datos e información. Son todas las entradas que necesita el S.I. para generar resultados

(información)

ASESORIA

LEGAL GERENCIA

CONTABILIDAD VENTAS ALMACEN

INVESTIGACION ADMINISTRACION

SISTEMAS

PRODUCCION


3

2.- El equipo computacional. Es el HW y SW necesario para que el sistema de información pueda

operar

3.- El recurso humano.Interactua con el sistema el cual está formado por las personas que utilizan y

manejan el sistema.

4.- Los programas que son procesados y producen diferentes resultados según la necesidad.

8.- Objetivos de un S.I.-

Automatizar los procesos operativos de una empresa

Proporcionar información que sirva de apoyo al proceso de toma de decisiones en los tres

niveles

Lograr ventajas competitivas a través de su implantación y uso (estratégico)

9.- Actividades de un Sistema de Información.- Principalmente ejecuta tres actividaes:

Recibe datos de fuentes internas o externas

Actua o procesa datos para producir la información

Produce la información para el usuario

10.- Diseño conceptual de un S.I..-

11.- Análisis de Sistemas.-

Palabra griega que significa: descomposición, unión y composición)

DATOS E

INFORMACION

EQUIPO

COMPUTACIONAL

RECURSO

HUMANO

PROGRAMAS

PROCESO

ENTRADA

DE DATOS

INTERFACE

AUTOMATICAD

E SALIDA

INTERFACE

AUTOMATICA

DE ENTRADA

REPORTE E

INFORME

ALMACENAMIENTO


4

El análisis lógico consiste en la descomposición mental del objeto investigado en sus partes o

componentes y en un método para obtener nuevos conocimientos.

Proceso de clarificación, interpretación de hechos, diagnóstico de problemas, recolección de datos y

empleo de la información para recomendar mejoras al sistema.

Preguntas: Como funciona?

Que hace?

Hay problemas?

Cuales son los procesos manuales y cuales no?

Se puede automatizar

Entender el proceso

Qué pasos o que actividades se realizan?

Podemos concluir diciendo que el análisis es el estudio de un sistema y está asociado a la pregunta

QUE es lo que el sistema debe hacer.

12.- Diseño de Sistemas.-

Es el proceso de planificar, reemplazar o complementar un sistema organizacional existente, pero antes

de llevar a cabo esta planeación es necesario comprender en su totalidad, el viejo sistema y determinar

la mejor forma en que se pueden.

Finalmente el Diseño establece COMO alcanzar el objetivo. Otros autores dividen el diseño de

sistemas en dos fases: el diseño lógico y el diseño físico (implementación).

Dentro de la etapa del diseño de sistemas se consideran las siguientes actividades:

Diseño de salidas (informes, reportes, resúmenes)

Diseño de entradas y control(formularios, formas)

Diseño de interfaces

Diseño de B.D. y archivos

Diseño de Comunicación de datos

13.- Implementación.- Es una actividad que sigue al diseño , se refiere a la generación de códigos de programas realizados en

un determinado lenguaje de programación, para que el sistema se convierta en SW de aplicación.


5

TEMA Nº2

DESARROLLO DE SISTEMAS O.O.

1.- Metodos O.O.

La bibliografía relacionada al paradigma O.O. es variada y aun difusa por cuanto hasta hace cinco años

no existianstandares reconocidos, solo se disponia de algunos principios fundamentales postulados por

diferentes autores.:

Metodo Pressman OMT (Object Modeling Tecnique)

Metodo Coad/Yourdan UML (Unificated Modeling Languaje)

Metodo Martín

Notación Booch

Notación Runbaugh

2.- Sistemas Complejos

En la vida empresarial, cuando queremos desarrollar sistemas, muchas veces se nos presenta problemas

dificiles de resolver Sistemas complejos: Mecanismos ecológicos de la tierra, el sistema nervioso, el

sistema educativo en Bolivia.

Un sistema complejo es cuando el sistema tiene varias variables y cantidades de control. Las

herramientas y metodos tradicionales no son suficientes, ni capaces para administrar la complejidad de

estos nuevos problemas y las situaciones reales exigen ser de alguna manera resueltas. Por otro lado el

mantenimiento de SW existente constituye ser tambien otro problema dificil de resolver, muchas

soluciones propuestas generar aun otros problemas y la situacion no mejora, ni se mantiene, sino que

empeora.

3.- Surgimiento de una técnica

Nuestro mundo real esta rodeado de objetos y cosas para comprender y entender los problemas. Las

personas piensan, analizan y estudian acerca de las cosas a traves de la experiencia la cual determina lo

que aprendemos.

Cuando nosotros pensamos acerca de las cosas como objetos y que ellos estan de alguna forma

relacionados con otros nace el termino O.O.

4.- Un Repaso a los lenguajes O.O.

La P.O.O. nace cubriendo ciertas deficiencias de los lenguajes clasicos, una de las caracteristicas

importantes es la reutilizacion y actualizacion de rutinas, procedimientos modulos de programas.

Asimismo se introduce el termino objeto, encapsulamiento, jerarquia de clases, herencia, polimorfismo.

4.1.- Objeto.- Una buena abstraccion de un ente real que adquiere una cierta autonomia y vida propia

en la computadora, Esta representacion debe tener las mismas caracteristicas del ente real y saber

realizar los mismos conocimientos que el objeto real. Existen objetos fisicos (reales) y logicos

(abstractos).

Un objeto tiene dos aspecto la parte de su comportamiento y la estructura, en el analisis y diseño O.O.

nos interesa el comportamiento del objeto, dicho comportamiento está expresado mediante un conjunto

de estructuras de datos, operaciones y metodos.


6

4.2.- Tipo de objetos (clases). Es una categoria de objeto y el objeto se convierte en una instancia del

tipo de objeto. Ejemplo:

MESAS

Mesa mediana café

Mesa redonda

Mesa pentagonal

El termino clase se utiliza mas que todo en la programación, cada clase define un conjunto de

operaciones permisibles que permiten el acceso y modificación de los datos del objeto.

4.3. Operaciones y métodos. Una operación es una función o transformación que puede ser aplicada a

o por los objetos de una clase, todos los objetos de una misma clase comparten las mismas operaciones.

Los métodos especifican la forma en que se controlan los datos de un objeto, en realidad la

implementación de una operación es un método. Ejemplo:

EMPLEADO COMPAÑÍA

Las operaciones de la clase EMPLEADO son: cobrar sueldo, registrar entrada, trabajar horas extra,

realizar informes, etc.

Las operaciones de la clase COMPAÑÍA son: contratar empleados, firmar convenios, pagar sueldos,

etc.

4.4.- Mensajes.- Para que un objeto haga algo se le enviamos una solicitud, esto hace que se produzca

una operación, la operación hace que se ejecute un método apropiado y de manera opcional produce

una respuesta.

4.5.- Encapsulado.-

Es el resultado o acto de ocultar lso detalles de implantación de un objeto respecto de su usuario, es el

ocultamiento de la información.

4.6.- Herencia.-

Un tipo de objetos puede tener subtipos y cada subtipo podria tener otros subtipos, es decir puede

existir una jerarquia de tipos o clases.. Una subclase hereda la estructura de datos y los metodos, o

algunos metodos de su superclase. Tambien tiene sus metodos e incluso tipos de datos propios.

4.7.- Polimorfismo.-

Se refiere a comportamientos alternos entre subclases. Cuando varias clases heredan atributos y

comportamientos, puede haber casos donde el comportamiento de una subclase deba ser diferente del

de su superclase. Esto significa que un mensaje puede tener diferentes efectos dependiendo de

exactamente que clase de objeto recibe el mensaje.

5.- Analisis y Diseño O.O.-

Analisis : Investigación

Diseño: solución


7

Para crear una aplicación de software hay que describir el problemas y las necesidades o

requerimientos, el Analisis se centra en una investigación del problema, no en la manera de definir una

solución. Por ejemplo si se desea un nuevo sistema para una biblioteca, ¿Cuáles procesos de la

institución se relacionan con su uso?

Para desarrollar una aplicación, también es necesario contar con descripciones detalladas de la solución

lógica y saber como satisface los requerimientos. El diseño pone de relieve una solución lógica, para el

ejemplo de la biblioteca ¿de que manera el sistema capturara y registrara los prestamos de libros?.


8

TEMA Nº3

ANALISIS ORIENTADO A OBJETOS

1.- CONCEPTO.-

Se ocupa de definir las categorias de objetos y la forma en que se asocian. Generalmente nos

preguntamos:

Que tipos de objetos hay?

Cuales son sus relaciones y funciones?

Que subtipos y supertipos son utiles?

Hay algon tipo de objeto compuesto por otros?

Como se organizan los objetos?

2.-IDENTIFICACION DE CLASES ( tipos de objetos)

Varios autores han propuesto varios metodosutiles para la identificacion del objeto y clases. Existen

principalmente dos enfoques:

Enfoque clasico: Propone listas de posibles clases (Brainstorning) tormenta de ideas.

Enfoque probabilistico: Propone el estudio del comportamiento como base para identificar objetos

Existe un metodo informal el cual se denomina la tecnica de las tarjetas CRC (Clases,

responsabilidades y colaboraciones).

3.- DETERMINACION DE REQUERIMIENTOS

La captura de requisitos es el proceso de averiguar normalmente en ciscunstancias difíciles, lo que se

debe construir.

La especificación de requisitos es un documento mas técnico y elaborado de los documentos de

análisis.

Los requerimientos son una descripción de las necesidades o deseos de un producto. La meta primaria

de la fase de requerimientos es identificar y documentar lo que en realidad se necesita, en una forma

que claramente se le comunique al cliente y a los miembros del equipo de desarrollo. El reto consiste

en definirlos de manera inequívoca, de modo que se detecten los riesgos y no se presenten sorpresas al

momento de entregar el producto.

Se recomienda los siguientes artefactos en la fase de requerimientos:

Panorama general

Clientes

Metas

Funciones del sistema

Atributos del sistema

3.1.- Panorama general.-


9

Denominada también presentación general, donde se debe expresar claramente el objeto del proyecto

de sistemas.

3.2.- Clientes

Mencionar el o los clientes o usuarios finales del sistema

3.3.- Metas

Generalmente se una meta se define como algo que se debe alcanzar, son objetivos puntuales que el

sistema lograra en favor de los clientes.

3.4.- Funciones del sistema

Las funciones del sistema son lo que este habrá de hacer, hayque identificarlas y listarlas en grupos

cohesivos y lógicos. Las funciones se clasifican en categorías, las cuales son:

Categoría de la funcion Significado

Evidente Debe realizarse, y el usuario

deberá saber que se ha realizado

Oculta Debe realizarse aunque no es

visible para los usuarios

Superflua Opcionales, su inclusión no

repercute significativamente en

el costo ni otras funciones

Ejemplo: Funciones del sistema en una aplicación de venta de muebles. El objetivo es entender los

detalles del análisis y diseño, no el funcionamiento de una tienda de muebles.

Ref # Funcion Categoria

R1.1 Registra la venta de cada producto

(muebles) en proceso

evidente

R1.2 Calcula el total de la venta actual,

incluye el impuesto, descuentos

Evidente

R1.3 Reduce las cantidades del inventario

cuando se realiza una venta

Oculta

R 1.4 El usuario (cajero) debe introducir

una identificación y contraseña para

utilizar el sistema

Evidente

R 1.5 Codifica y clasifica el producto

(mueble) según corresponda

Oculta

Si es necesario se puede subdividir las funciones y enumerarlas correctamente, tal como se muestra en

el ejemplo.

3.5.- Atributos del sistema

Son cualidades o características del sistema no funcionales. Por ejemplo:

Facilidad de uso

Tolerancia a las fallas

Tiempo de respuesta

Plataforma


10

Calidad

Costo al detalle

Interfaz

4.- Otros artefactos en la fase de requerimientos

Las funciones y los atributos del sistema son los documentos minimos de los

requerimientos, pero también se necesitan otros artefactos importantes para entender el

problema, estos son:

Requerimientos y equipos de enlace: lista de los participantes en la especificación de las

funciones, en la realización de entrevistas, de pruebas, de negociaciones y otras actividades

Suposiciones: Las cosas cuya verdad se supone

Riesgos: las cosas que pueden ocasionar el fracaso o retraso

Dependencias: otras personas, sistemas y productos de los cuales no puede prescindir el

proyecto para su terminación

Casos de Usos: descripciones narrativas de los procesos del dominio


11

TEMA 4

UML (UnifiedModelingLanguage)

ANTECEDENTES.-

Desde que Simula 67 introdujera el concepto de clase y herencia los lenguajes OO han experimentado

una rápida e intensa evolución para acercarse a la realidad que la empresa les reclama. Pero no es hasta

los inicios de la década de los 90 cuando realmente existe un intento serio de normalizar la metodología

OO.

•El Dr. James Rumbaugh en 1991 con Michael Blaha, William Premerlani, Frederick Eddy y William

Lorensen desarrollan "ObjectOrientedModeling and Design" introduciendo OMT

(ObjectModelingTechnique) que él mismo define como "una metodología orientada a objetos para el

desarrollo de software". •El Dr. Ivar Jacobson en 1992 desarrolla el método OOSE (ObjectOrinted

Software Engineer), donde introduce el concepto "use case". •Grady Booch en 1993 crea la

metodología "Booch '93". •J. Rumbaugh y G. Booch en el año 1994 se unen en una empresa común (de

objetivos y de negocio) Rational Software Corporation donde unifican sus dos métodos. •Un año

después y como fruto de dicha unión aparece en octubre del 95 UML 0.8 (UnifiedModelingLanguage).

•A finales de ese mismo año se une al grupo I.

Jacobson.

DR. Ivar Jacobson

Grady Booch

• En junio del 96 los tres padres de UML depositan las especificaciones de UML 0.9 en el

enlace http://www.rational.com/uml de Rational. Este hecho produce una cascada de

adhesiones que en pocos meses, concretamente en enero del 97, va a permitir la creación

de UML 1.0. Por fín se consigue un modelo totalmente unificado

PARTICIPANTES EN UML 1.0


12

Rational Software (Grady Booch, Jim Rumbaugh y Ivar Jacobson)

Digital Equipment

Hewlett-Packard

i-Logix (David Harel)

IBM

ICON Computing (Desmond D’Souza)

Intellicorp and James

Martin & co. (James Odell)

MCI Systemhouse

Microsoft ObjecTime

Platinium Technology

Sterling Software

Taskon

Texas Instruments

Unisys

Microsoft con Active X/COM y Componentes

Oracle con ORDBMS

•En noviembre del 97 UML es aceptado como estándar por OMG (Object Management

Group), después de ser admitidas algunas de sus sugerencias, como el modelado de

negocios. Uno de los requisitos exigidos es que UML no fuese propiedad de nadie. Rational

comercializa una herramienta CASE sin derechos sobre UML.

CONCEPTO DE UML ( UnifiedModelingLanguage)

UML [UML] es un lenguaje para especificar, construir, visualizar y documentar los

artefactos de un sistema de software orientado a objetos (OO). Un artefacto es una

información que es utilizada o producida mediante un proceso de desarrollo de software.

UML se quiere convertir en un lenguaje estándar con el que sea posible modelar todos los

componentes del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener en

cuenta un aspecto importante del modelo: no pretende definir un modelo estándar de

desarrollo, sino únicamente un lenguaje de modelado. Otros métodos de modelaje como

OMT (ObjectModelingTechnique) o Booch sí definen procesos concretos. En UML los

procesos de desarrollo son diferentes según los distintos dominios de trabajo; no puede ser

el mismo el proceso para crear una aplicación en tiempo real, que el proceso de desarrollo

de una aplicación orientada a gestión, por poner un ejemplo.

Las diferencias son muy marcadas y afectan a todas las faces del proceso. El método del

UML recomienda utilizar los procesos que otras metodologías tienen definidos.

Un lenguaje de propósito general para el modelado orientado a objetos

Documento “OMG Unified Modeling Language Specification”

UML combina notaciones provenientes desde:

• Modelado Orientado a Objetos


13

• Modelado de Datos

• Modelado de Componentes

• Modelado de Flujos de Trabajo (Workflows)

OBJETIVOS DELUML

El objetivo es conseguir un modelo unificado, abierto, que siga evolucionando en conjunto

y no por separado tal como estaba ocurriendo hasta ahora, comprensible por el hombre,

utilizable por la máquina y fundamentalmente con la capacidad de unificar las perspectivas

de diferentes sistemas (tanto de software como de negocio).

Como otros objetivos principales de la consecución de un nuevo método que aunara los

mejores aspectos de sus predecesores, sus protagonistas se propusieron lo siguiente:

El método debía ser capaz de modelar no sólo sistemas de software sino otro

tipo de sistemas reales de la empresa, siempre utilizando los conceptos de la

orientación a objetos (OO).

Establecer una notación estándar

Crear un lenguaje para modelado utilizable a la vez por máquinas y por

personas.

Establecer un acoplamiento explícito de los conceptos y los artefactos

ejecutables.

Manejar los problemas típicos de los sistemas complejos de misión crítica.

Lo que se intenta es lograr con esto que los lenguajes que se aplican siguiendo los métodos

más utilizados sigan evolucionando en conjunto y no por separado. Y además, unificar las

perspectivas entre diferentes tipos de sistemas (no sólo software, sino también en el ámbito

de los negocios), al aclarar las fases de desarrollo, los requerimientos de análisis, el diseño,

la implementación y los conceptos internos de la OO.

MODELADO DE OBJETOS

En la especificación del UML podemos comprobar que una de las partes que lo componen

es un metamodelo formal. Un metamodelo es un modelo que define el lenguaje para

expresar otros modelos. Un modelo en OO es una abstracción cerrada semánticamente de

un sistema y un sistema es una colección de unidades conectadas que son organizadas para

realizar un propósito específico. Un sistema puede ser descripto por uno o más modelos,

posiblemente desde distintos puntos de vista.

Una parte del UML define, entonces, una abstracción con significado de un lenguaje para

expresar otros modelos (es decir, otras abstracciones de un sistema, o conjunto de unidades

conectadas que se organizan para conseguir un propósito). Lo que en principio puede

parecer complicado no lo es tanto si pensamos que uno de los objetivos del UML es llegar a

convertirse en una manera de definir modelos, no sólo establecer una forma de modelo, de

esta forma simplemente estamos diciendo que UML, además, define un lenguaje con el que

podemos abstraer cualquier tipo de modelo.


14

UML utiliza parte de este planteamiento obteniendo distintos puntos de vista de la realidad

que modela mediante los distintos tipos de diagramas que posee. Con la creación del UML

se persigue obtener un lenguaje que sea capaz de abstraer cualquier tipo de sistema, sea

informático o no, mediante los diagramas, es decir, mediante representaciones gráficas que

contienen toda la información relevante del sistema. Un diagrama es una representación

gráfica de una colección de elementos del modelo, que habitualmente toma forma de grafo

donde los arcos que conectan sus vértices son las relaciones entre los objetos y los vértices

se corresponden con los elementos del modelo. Los distintos puntos de vista de un sistema

real que se quieren representar para obtener el modelo se dibuja dé forma que se resaltan

los detalles necesarios para entender el sistema.

Modelos y Diagramas

Un modelo captura una vista de un sistema del mundo real. Es una abstracción de dicho

sistema, considerando un cierto propósito. Así, el modelo describe completamente aquellos

aspectos del sistema que son relevantes al propósito del modelo, y a un apropiado nivel de

detalle.

Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan

expresar el producto desde cada una de las perspectivas de interés El código fuente del

sistema es el modelo más detallado del sistema (y además es ejecutable). Sin embargo, se

requieren otros modelos ... Cada modelo es completo desde su punto de vista del sistema,

sin embargo, existen relaciones de trazabilidad entre los diferentes modelos

Diagrama es una representación gráfica de una colección de elementos de modelado, a

menudo dibujada como un grafo conexo de arcos (relaciones) y vértices (otros elementos

del modelo). Un diagrama no es un elemento semántico, un diagrama muestra

representaciones de elementos semánticos del modelo, pero su significado no se ve

afectado por la forma en que son representados. Un diagrama está contenido dentro de un

paquete.

La mayoría de los diagramas de UML y algunos símbolos complejos son grafos que

contienen formas conectadas por rutas. La infomación está sobre todo en la topología, no en

el tamaño o la colocación de los símbolos (hay algunas excepciones como el diagrama de

secuencia con un eje métrico de tiempo). Hay tres clases importantes de relaciones visuales:

conexión (generalmente de líneas a formas de dos dimensiones), contención (de símbolos

por formas cerradas de dos dimensiones), y adhesión visual (un símbolo que está "cerca" de

otro en un diagrama). Estas relaciones geométricas se reasignan a conexiones entre nodos

en un gráfico en la forma analizada de la notación.

NOTACION UML

La notación de UML está pensada para ser dibujada en superficies bidimensionales.

Algunas formas bidimensionales son proyecciones de formas tridimensionales tales como

cubos, pero todavía se representan como íconos en una superficie bidimensional.

Hay cuatro clases de construcciones gráficas que se usan en la notación de UML: íconos,

símbolos bidimensionales, rutas y cadenas.


15

Un ícono es una figura gráfica con un tamaño y forma fijos. No se amplía para contener a

su contenido. Los iconos pueden aparecer dentro de símbolos de área, como terminadores

en las rutas o como símbolos independientes que puedan o no conectar con las rutas.

Los símbolos de dos dimensiones tienen altura y anchura variables, y pueden ampliarse

para permitir otras cosas tales como listas de cadenas o de otros símbolos. Muchos de ellos

están divididos en compartimientos similares o de tipos diferentes. Las rutas se conectan

con los símbolos, el arrastrar o suprimir uno de ellos afecta a su contenido y las rutas

conectadas.

de segmentos de recta o de curva que se unen en sus puntos finales. Conceptualmente una

ruta es una sola entidad topológica, aunque sus segmentos se pueden manipular

gráficamente. unsegemento no debería existir separado de su ruta. Las rutas siempre van

conectdas en ambos extremos.

Las cadenas presentan varias clases de información en una forma "no analizada", UML

asume que cada uso de una cadena en la notación tiene una sintaxis por la cual pueda ser

analizada la información del modelo subyancente. Las cadenas pueden existir como el

contenido de un compartimiento, como elementos en las listas, como etiquetas unidas a los

símbolos o a las rutas, o como elementos independientes en un diagrama.

DIAGRAMAS UML

Los diagramas expresan gráficamente partes de un modelo. UML está compuesto por los

siguientes diagramas:

Diagramas de UML

Diagrama de Casos de Uso

Diagrama de Clases

Diagrama de Objetos

Diagramas de Comportamiento

Diagrama de Estados

Diagrama de Actividad

Diagramas de Interacción

Diagrama de Secuencia

Diagrama de Colaboración

Diagramas de implementación

Diagrama de Componentes

Diagrama de Despliegue

NUEVAS CARACTERÍSTICAS DEL UML

Además de los conceptos extraídos de métodos anteriores, se han añadido otros nuevos que

vienen a suplir carencias antiguas de la metodología de modelado. Estos nuevos conceptos

son los siguientes:

Definición de estereotipos: un estereotipo es una nueva clase de elemento de

modelado que debe basarse en ciertas clases ya existentes en el metamodelo y

constituye un mecanismo de extensión del modelo.

Responsabilidades.


16

Mecanismos de extensibilidad: estereotipos, valores etiquetados y restricciones.

Tareas y procesos.

Distribución y concurrencia (para modelar por ejemplo ActiveX/DCOM y

CORBA).

Patrones/Colaboraciones.

Diagramas de actividad (para reingeniería de proceso de negocios)

Clara separación de tipo, clase e instancia.

Refinamiento (para manejar relaciones entre niveles de abstracción).

Interfaces y componentes.

EL PROCESO DE DESARROLLO

UML no define un proceso concreto que determine las fases de desarrollo de un sistema, las

empresas pueden utilizar UML como el lenguaje para definir sus propios procesos y lo

único que tendrán en común con otras organizaciones que utilicen UML serán los tipos de

diagramas.

Herramientas CASE

Rational Rose es la herramienta CASE que comercializan los desarrolladores de UML y

que soporta de forma completa la especificación del UML 1.1.

Esta herramienta propone la utilización de cuatro tipos de modelo para realizar un diseño

del sistema, utilizando una vista estática y otra dinámica de los modelos del sistema, uno

lógico y otro físico. Permite crear y refinar estas vistas creando de esta forma un modelo

completo que representa el dominio del

problema y el sistema de software.

Desarrollo Iterativo

Rational Rose utiliza un proceso de desarrollo iterativo controlado

(controllediterativeprocessdevelopment), donde el desarrollo se lleva a cabo en una

secuencia de iteraciones. Cada iteración comienza con una primera aproximación del

análisis, diseño e implementación para identificar los riesgos del diseño, los cuales se

utilizan para conducir la iteración, primero se identifican los riesgos y después se prueba la

aplicación para que éstos se hagan mínimos.

Cuando la implementación pasa todas las pruebas que se determinan en el proceso, ésta se

revisa y se añaden los elementos modificados al modelo de análisis y diseño. Una vez que

la actualización del modelo se ha modificado, se realiza la siguiente iteración.

Trabajo en Grupo

Rose permite que haya varias personas trabajando a la vez en el proceso iterativo

controlado, para ello posibilita que cada desarrollador opere en un espacio de trabajo

privado que contiene el modelo completo y tenga un control exclusivo sobre la propagación

de los cambios en ese espacio de trabajo.


17

También es posible descomponer el modelo en unidades controladas e integrarlas con un

sistema para realizar el control de proyectos que permite mantener la integridad de dichas

unidades.

Generador de Código

Se puede generar código en distintos lenguajes de programación a partir de un diseño en

UML.

Ingeniería Inversa

Rational Rose proporciona mecanismos para realizar la denominada Ingeniería Inversa, es

decir, a partir del código de un programa, se puede obtener información sobre su diseño.


18

TEMA 5.

Casos de Uso (Use Case)

Introducción

El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el

sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactuan

(operaciones o casos de uso).

Un diagrama de casos de uso consta de los siguientes elementos:

Actor.

Casos de Uso.

Relaciones de Uso, Herencia y Comunicación.

Elementos

Actor:

Una definición previa, es que un Actor es un rol que un usuario juega con respecto

al sistema. Es importante destacar el uso de la palabra rol, pues con esto se

especifica que un Actor no necesariamente representa a una persona en particular,

sino más bien la labor que realiza frente al sistema.

Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en

que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor

o bien por el Jefe de Local.

Caso de Uso:

Es una operación/tarea específica que se realiza tras una orden de algún agente

externo, sea desde una petición de un actor o bien desde la invocación desde otro

caso de uso.

http://www.dcc.uchile.cl/~psalinas/uml/casosuso.html#actor

http://www.dcc.uchile.cl/~psalinas/uml/casosuso.html#casosuso

http://www.dcc.uchile.cl/~psalinas/uml/casosuso.html#relacion


19

Relaciones:

o Asociación

Es el tipo de relación más básica que indica la invocación desde un actor o

caso de uso a otra operación (caso de uso). Dicha relación se denota con una

flecha simple.

o Dependencia o Instanciación

Es una forma muy particular de relación entre clases, en la cual una clase

depende de otra, es decir, se instancia (se crea). Dicha relación se denota con

una flecha punteada.

o Generalización

Este tipo de relación es uno de los más utilizados, cumple una doble función

dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de

Herencia (<<extends>>).

Este tipo de relación esta orientado exclusivamente para casos de uso (y no

para actores).

extends: Se recomienda utilizar cuando un caso de uso es similar a otro

(características).

uses: Se recomienda utilizar cuando se tiene un conjunto de características

que son similares en más de un caso de uso y no se desea mantener copiada

la descripción de la característica.

De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y

modelamiento de clases, en donde esta la duda clásica de usar o heredar.

Ejemplo:

Como ejemplo esta el caso de una Máquina Recicladora:

Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema

debe controlar y/o aceptar:

Registrar el número de ítemes ingresados.

Imprimir un recibo cuando el usuario lo solicita:

a. Describe lo depositado

b. El valor de cada item

c. Total

El usuario/cliente presiona el botón de comienzo


20

Existe un operador que desea saber lo siguiente:

a. Cuantos ítemes han sido retornados en el día.

b. Al final de cada día el operador solicita un resumen de todo lo depositado en

el día.

El operador debe además poder cambiar:

a. Información asociada a ítemes.

b. Dar una alarma en el caso de que:

i. Item se atora.

ii. No hay más papel.

Como una primera aproximación identificamos a los actores que interactuan con el sistema:

Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la

información de un Item o bien puede Imprimir un informe:

Además podemos notar que un item puede ser una Botella, un Tarro o una Jaba.


21

Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar

algún item por un cliente o bien puede ser realizada a petición de un operador.

Entonces, el diseño completo del diagrama Use Case es:


22


23

TEMA 6

Modelo de Clases

Introducción

Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el

sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento.

Un diagrama de clases esta compuesto por los siguientes elementos:

Clase: atributos, métodos y visibilidad.

Relaciones: Herencia, Composición, Agregación, Asociación y Uso.

Elementos

Clase

Es la unidad básica que encapsula toda la información de un Objeto (un objeto es

una instancia de una clase). A través de ella podemos modelar el entorno en estudio

(una Casa, un Auto, una Cuenta Corriente, etc.).

En UML, una clase es representada por un rectángulo que posee tres divisiones:

En donde:

o Superior: Contiene el nombre de la Clase

o Intermedio: Contiene los atributos (o variables de instancia) que

caracterizan a la Clase (pueden ser private, protected o public).

o Inferior: Contiene los métodos u operaciones, los cuales son la forma como

interactúa el objeto con su entorno (dependiendo de la visibilidad: private,

protected o public).

Ejemplo:

Una Cuenta Corriente que posee como característica:

o Balance

http://www.dcc.uchile.cl/~psalinas/uml/modelo.html#clase

http://www.dcc.uchile.cl/~psalinas/uml/modelo.html#relacion


24

Puede realizar las operaciones de:

o Depositar

o Girar

o y Balance

El diseño asociado es:

Atributos y Métodos:

o Atributos:

Los atributos o características de una Clase pueden ser de tres tipos, los que

definen el grado de comunicación y visibilidad de ellos con el entorno, estos

son:

public (+, ): Indica que el atributo será visible tanto dentro

como fuera de la clase, es decir, es accsesible desde todos lados.

private (-, ): Indica que el atributo sólo será accesible desde

dentro de la clase (sólo sus métodos lo pueden accesar).

protected (#, ): Indica que el atributo no será accesible desde

fuera de la clase, pero si podrá ser accesado por métodos de la clase

además de las subclases que se deriven (ver herencia).

o Métodos:

Los métodos u operaciones de una clase son la forma en como ésta

interactúa con su entorno, éstos pueden tener las características:

public (+, ): Indica que el método será visible tanto dentro como

fuera de la clase, es decir, es accsesible desde todos lados.

private (-, ): Indica que el método sólo será accesible desde

dentro de la clase (sólo otros métodos de la clase lo pueden accesar).


25

protected (#, ): Indica que el método no será accesible desde

fuera de la clase, pero si podrá ser accesado por métodos de la clase

además de métodos de las subclases que se deriven (ver herencia).

Relaciones entre Clases:

Ahora ya definido el concepto de Clase, es necesario explicar como se pueden

interrelacionar dos o más clases (cada uno con características y objetivos

diferentes).

Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la

cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en

cada extremo de la relación y éstas pueden ser:

o uno o muchos: 1..* (1..n)

o 0 o muchos: 0..* (0..n)

o número fijo: m (m denota el número).

o

v. Herencia (Especialización/Generalización):

Indica que una subclase hereda los métodos y atributos especificados por

una Super Clase, por ende la Subclase además de poseer sus propios

métodos y atributos, poseerá las características y atributos visibles de la

Super Clase (public y protected), ejemplo:


26

En la figura se especifica que Auto y Camión heredan de Vehículo, es decir,

Auto posee las Características de Vehículo (Precio, VelMax, etc) además

posee algo particular que es Descapotable, en cambio Camión también

hereda las características de Vehiculo (Precio, VelMax, etc) pero posee

como particularidad propia Acoplado, Tara y Carga.

Cabe destacar que fuera de este entorno, lo único "visible" es el método

Caracteristicas aplicable a instancias de Vehículo, Auto y Camión, pues

tiene definición publica, en cambio atributos como Descapotable no son

visibles por ser privados.

vi. Agregación:

Para modelar objetos complejos, n bastan los tipos de datos básicos que

proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se

requiere componer objetos que son instancias de clases definidas por el

desarrollador de la aplicación, tenemos dos posibilidades:

Por Valor: Es un tipo de relación estática, en donde el tiempo de

vida del objeto incluido esta condicionado por el tiempo de vida del

que lo incluye. Este tipo de relación es comunmente llamada

Composición (el Objeto base se contruye a partir del objeto incluido,

es decir, es "parte/todo").

Por Referencia: Es un tipo de relación dinámica, en donde el tiempo

de vida del objeto incluido es independiente del que lo incluye. Este

tipo de relación es comunmente llamada Agregación (el objeto base

utiliza al incluido para su funcionamiento).

Un Ejemplo es el siguiente:

En donde se destaca que:

Un Almacen posee Clientes y Cuentas (los rombos van en el objeto

que posee las referencias).

Cuando se destruye el Objeto Almacen también son destruidos los

objetos Cuenta asociados, en cambio no son afectados los objetos

Cliente asociados.


27

La composición (por Valor) se destaca por un rombo relleno.

La agregación (por Referencia) se destaca por un rombo

transparente.

La flecha en este tipo de relación indica la navegabilidad del objeto

refereniado. Cuando no existe este tipo de particularidad la flecha se

elimina.

vii. Asociación:

La relación entre clases conocida como Asociación, permite asociar objetos

que colaboran entre si. Cabe destacar que no es una relación fuerte, es decir,

el tiempo de vida de un objeto no depende del otro.

Ejemplo:

Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio

una orden de compra solo puede tener asociado un cliente.

viii. Dependencia o Instanciación (uso):

Representa un tipo de relación muy particular, en la que una clase es

instanciada (su instanciación es dependiente de otro objeto/clase). Se denota

por una flecha punteada.

El uso más particular de este tipo de relación es para denotar la dependencia

que tiene una clase de otra, como por ejemplo una aplicación grafica que

instancia una ventana (la creación del Objeto Ventana esta condicionado a la

instanciación proveniente desde el objeto Aplicacion):

Cabe destacar que el objeto creado (en este caso la Ventana gráfica) no se

almacena dentro del objeto que lo crea (en este caso la Aplicación).

Casos Particulares:

o Clase Abstracta:


28

Una clase abstracta se denota con el nombre de la clase y de los métodos con

letra "itálica". Esto indica que la clase definida no puede ser instanciada

pues posee métodos abstractos (aún no han sido definidos, es decir, sin

implementación). La única forma de utilizarla es definiendo subclases, que

implementan los métodos abstractos definidos.

o Clase parametrizada:

Una clase parametrizada se denota con un subcuadro en el extremo superior

de la clase, en donde se especifican los parámetros que deben ser pasados a

la clase para que esta pueda ser instanciada. El ejemplo más típico es el caso

de un Diccionario en donde una llave o palabra tiene asociado un

significado, pero en este caso las llaves y elementos pueden ser genéricos.

La genericidad puede venir dada de un Template (como en el caso de C++)

o bien de alguna estructura predefinida (especialización a través de clases).


29

TEMA 6

Diagrama de Interacción

Introducción

El diagrama de interacción, representa la forma en como un Cliente (Actor) u Objetos

(Clases) se comunican entre si en petición a un evento. Esto implica recorrer toda la

secuencia de llamadas, de donde se obtienen las responsabilidades claramente.

Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama Estático de Clases o

el de Casos de Uso (son diferentes).

Los diagramas de interaccion se dividen en:

Diagramas de secuencia

Diagramas de colaboracion

Los componentes de un diágrama de interacción son:

Un Objeto o Actor.

Mensaje de un objeto a otro objeto.

Mensaje de un objeto a si mismo.

Elementos

Objeto/Actor:

El rectángulo representa una instancia de un Objeto en particular, y la línea

punteada representa las llamadas a métodos del objeto.

Mensaje a Otro Objeto:

http://www.dcc.uchile.cl/~psalinas/uml/interaccion.html#objeto

http://www.dcc.uchile.cl/~psalinas/uml/interaccion.html#message

http://www.dcc.uchile.cl/~psalinas/uml/interaccion.html#self


30

Se representa por una flecha entre un objeto y otro, representa la llamada de un

método (operación) de un objeto en particular.

Mensaje al Mismo Objeto:

No solo llamadas a métodos de objetos externos pueden realizarse, también es

posible visualizar llamadas a métodos desde el mismo objeto en estudio.

Ejemplo

En el presente ejemplo, tenemos el diagrama de interacción proveniente del siguiente

modelo estatico:

Aquí se representa una aplicación que posee una Ventana gráfica, y ésta a su vez posee

internamente un botón.

Entonces el diagrama de interacción para dicho modelo es:


31

En donde se hacen notar las sucesivas llamadas a Draw() (entre objetos) y la llamada a

Paint() por el objeto Botón.

La vista de interacción describe secuencias de intercambios de mensajes entre los roles que

implementan el comportamiento de un sistema. Un rol clasificador, o simplemente "un rol",


32

es la descripción de un objeto, que desempeña un determinado papel dentro de una

interacción, distinto de los otros objetos de la misma clase. Esta visión proporciona una

vista integral del comportamiento del sistema, es decir, muestra el flujo de control a través

de muchos objetos. La vista de interacción se exhibe en dos diagramas centrados en

distintos aspectos pero complementarios: centrados en los objetos individuales y centrados

en objetos cooperantes.

Los objetos interactúan para realizar colectivamente los servicios ofrecidos por las

aplicaciones. Los diagramas de interacción muestran cómo se comunican los objetos en una

interacción. Existen dos tipos de diagramas de interacción: el Diagrama de Colaboración y

el Diagrama de Secuencia.

El Diagrama de Secuencia es más adecuado para observar la perspectiva cronológica de las

interacciones, muestra la secuencia explícita de mensajes y son mejores para

especificaciones de tiempo real y para escenarios complejos. El Diagrama de Colaboración

ofrece una mejor visión espacial mostrando los enlaces de comunicación entre objetos,

muestra las relaciones entre objetos y son mejores para comprender todos los efectos que

tiene un objeto y para el diseño de procedimientos. El diagrama de Colaboración puede

obtenerse automáticamente a partir del correspondiente diagrama de Secuencia (o

viceversa).

Diagramas de Secuencia:

1.Muestra la secuencia de mensajes entre objetos durante un escenario concreto 2.Cada

objeto viene dado por una barra vertical 3.El tiempo transcurre de arriba abajo 4.Cuando

existe demora entre el envío y la atención se puede indicar usando una línea oblicua

Diagramas de Colaboración:


33

1.Son útiles en la fase exploratoria para identificar objetos. 2.La distribución de los objetos

en el diagrama permite observar adecuadamente la interacción de un objeto con respecto de

los demás 3.La estructura estática viene dada por los enlaces; la dinámica por el envío de

mensajes por los enlaces

Qué es una Colaboración?

Es una descripción de una colección de objetos que interactúan para implementar un cierto

comportamiento dentro de un contexto. Describe una sociedad de objetos cooperantes

unidos para realizar un cierto propósito. Una colaboración contiene ranuras que son

rellenadas por los objetos y enlaces en tiempo de ejecución. Una ranura de colaboración se

llama Rol porque describe el propósito de un objeto o un enlace dentro de la colaboración.

Un rol clasificador representa una descripción de los objetos que pueden participar en una

ejecución de la colaboración, un rol de asociación representa una descripción de los enlaces

que pueden participar en una ejecución de colaboración. Un rol de clasificador es una

asociación que está limitada por tomar parte en la colaboración. Las relaciones entre roles

de clasificador y asociación dentro de una colaboración sólo tienen sentido en ese contexto.

En general fuera de ese contexto no se aplican las mismas relaciones.


34

Una Colaboración tiene un aspecto estructural y un aspecto de comportamiento. El aspecto

estrucutral es similar a una vista estática: contiene un conjunto de roles y relaciones que

definen el contexto para su comprtamiento. El comportamiento es el conjunto de mensajes

intercambiados por los objetos ligados a los roles. Tal conjunto de mensajes en una

colaboración se llama Interacción. Una colaboración puede incluir una o más interacciones.

Qué es una Interacción?

Es el conjunto de mensajes intercambiados por los roles de clasificador a través de los roles

de asociación. Un mensaje es una comunicaión unidireccional entre dos objetos, un flujo de

objeto con la información de un remitente a un receptor. Un mensaje puede tener

parámetros que transporten valores entre objetos. Un mensaje puede ser una señal

(comunicación explícita entre objetos, con nombre y asíncrona) o una llamada (la

invocación síncrona de una operación con un mecanismo para el control, que retorna

posteriormente al remitente). Un patrón de intercambios de mensajes que se realizan para

lograr un propósito específico es lo que se denomina una interacción.

Qué es Patrón?

Un patrón es una colaboración parametrizada, junto con las pautas sobre cuándo utilizarlo.

Un parámetro se puede sustituir por diversos valores, para producir distintas

colaboraciones. Los parámetros señalan generalmente las ranuras para las clases. El uso de

un patrón se representa como una elipse de línea discontinua conectada con cada una de las

clases por una línea discontinua, que se etiqueta con el nombre del rol.


35

TEMA 7

Diagrama de Actividades 1.- Definicion

El Diagrama de Actividad es una especialización del Diagrama de Estado, organizado respecto de las

acciones y usado para especificar:

Un método

Un caso de uso

Un proceso de negocio (Workflow)

Un estado de actividad representa una actividad: un paso en el flujo de trabajo o la ejecución de una

operación. Un grafo de actividades describe grupos secuenciales y concurrentes de actividades. Los

grafos de actividades se muestran en diagramas de actividades. Las actividades se enlazan por

transiciones automáticas. Cuando una actividad termina se desencadena el paso a la siguiente

actividad.

Un diagrama de actividades es provechoso para entender el comportamiento de alto nivel de la

ejecución de un sistema, sin profundizar en los detalles internos de los mensajes. Los parámetros de

entrada y salida de una acción se pueden mostrar usando las relaciones de flujo que conectan la

acción y un estado de flujo de objeto.

Un grafo de actividades contiene estados de actividad que representa la ejecución de una secuencia

en un procedimiento, o el funcionamiento de una actividad en un flujo de trabajo. En vez de esperar

un evento, como en un estado de espera normal, un estado de actividad espera la terminación de su

cómputo. Cuando la actividad termina, entonces la ejecución procede al siguiente estado de actividad

dentro del diagrama. una transición de terminación es activada en un diagrama de actividades cuando

se completa la actividad precedente. Los estados de actividad no tienen transiciones con eventos

explícitos, peor pueden ser abortados por transiciones en estados que los incluyen._

Un grafo de actividades puede contener también estados de acción, que son similares a los de

actividad pero son atómicos y no permiten transiciones mientras están activos. Los estados de acción

se deben utilizar para las operaciones cortas de mantenimiento.

Un diagrama de actividades puede contener bifurcaciones, así como divisiones de control en hilos

concurrentes. los hilos concurrentes representan actividades que se pueden realizar concurrentemente

por los diversos objetos o personas. La concurrencia se representa a partir de la agregación, en la cual

cada objeto tiene su propio hilo. Las actividades concurrentes se pueden realizar simultáneamente o

en cualquier orden. Un diagrama de actividades es como un organigrama tradicional, excepto que

permite el control de concurrencia además del control secuencial.

2.- Notación Un estado de actividad se representa como una caja con los extremos redondeados que contiene una

descripción de actividad. Las transacciones simples de terminación se muestran como flechas. Las

ramas se muestran como condiciones de guarda en transiciones o como diamantes con múltiples

flechas de salida etiquetadas. Una división o una unión de control se representa con múltiples flechas


36

que entran o salen de la barra gruesa de sincronización.

Cuando es necesario incluir eventos externos, la recepción de un evento se puede mostrar como un

disparador en una transición, o como un símbolo especial que denota la espera de una señal.

A menudo es útil organizar las actividades en un modelo según su responsabilidad. Esta clase de

asignación puede mostrarse organizando las actividades en regiones distintas separads por líneas en

el diagrama. Debido a su aspecto, esto es conocido como Calles.

Un diagrma de actividades puede mostrar el flujo de objetos como valores. Para un valor de salida, se

dibuja una flecha con línea discontinua desde la actividad al objeto. Para un valor de entrada, se

dibuja una flecha con línea discontinua desde el objeto a una actividad.


37

Tema 8

Diagramas de Componentes

Los diagramas de componentes describen los elementos físicos del sistema y sus relaciones.

Muestran las opciones de realización incluyendo código fuente, binario y ejecutable. Los

componentes representan todos los tipos de elementos software que entran en la fabricación

de aplicaciones informáticas. Pueden ser simples archivos, paquetes de Ada, bibliotecas

cargadas dinámicamente, etc. Las relaciones de dependencia se utilizan en los diagramas de

componentes para indicar que un componente utiliza los servicios ofrecidos por otro

componente.

Un diagrama de componentes representa las dependencias entre componentes software,

incluyendo componentes de código fuente, componentes del código binario, y componentes

ejecutables. Un módulo de software se puede representar como componente. Algunos

componentes existen en tiempo de compilación, algunos en tiempo de enlace y algunos en

tiempo de ejecución, otros en varias de éstas.

Un componente de sólo compilación es aquel que es significativo únicamente en tiempo de

compilación. Un componente ejecutable es un programa ejecutable.

Un diagrama de componentes tiene sólo una versión con descriptores, no tiene versión con

instancias. Para mostrar las instancias de los componentes se debe usar un diagrama de

despliegue.

Un diagrama de componentes muestra clasificadores de componentes, las clases definidas en

ellos, y las relaciones entre ellas. Los clasificadores de componentes también se pueden anidar

dentro de otros clasificadores de componentes para mostrar relaciones de definición.

Un diagrama que contiene clasificadores de componentes y de nodo se puede utilizar para

mostrar las dependencias del compilador, que se representa como flechas con líneas

discontinuas (dependencias) de un componente cliente a un componente proveedor del que

depende. Los tipos de dependencias son específicos del lenguaje y se pueden representar

como estereotipos de las dependencias.

El diagrama de componente hace parte de la vista física de un sistema, la cual modela la

estructura de implementación de la aplicación por sí misma, su organización en componentes

y su despliegue en nodos de ejecución. Esta vista proporciona la oportunidad de establecer

correspondecias entre las clases y los componentes de implementación y nodos. La vista de

implementación se representa con los diagramas de componentes.


38

Diagramas de Despliegue Los Diagramas de Despliegue muestran la disposición física de los distintos nodos que

componen un sistema y el reparto de los componentes sobre dichos nodos. La vista de despliegue

representa la disposición de las instancias de componentes de ejecución en instacias de nodos

conectados por enlaces de comunicación. Un nodo es un recurso de ejecución tal como un

computador, un dispositivo o memoria. Los estereotipos permiten precisar la naturaleza del

equipo:

Dispositivos

Procesadores

Memoria

Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparse.

Esta vista permite determinar las consecuencias de la distribución y la asignación de recursos.

Las instancias de los nodos pueden contener instancias de ejecución, como instancias de

componentes y objetos. El modelo puede mostrar dependencias entre las instancias y sus

interfaces, y también modelar la migración de entidades entre nodos u otros contenedores.

Esta vista tiene una forma de descriptor y otra de instancia. La forma de instancia muestra la

localización de las instancias de los componentes específicos en instancias específicas del nodo

como parte de una configuración del sistema. La forma de descriptor muestra qué tipo de

componentes pueden subsistir en qué tipos de nodos y qué tipo de nodos se pueden conectar, de

forma similar a una diagrama de clases, esta forma es menos común que la primera.


39

Diagramas de Estado

Muestra el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicación,

junto con los cambios que permiten pasar de un estado a otro.

Los Diagramas de Estado representan autómatas de estados finitos, desde el p.d.v. de los estados

y las transiciones. Son útiles sólo para los objetos con un comportamiento significativo. Cada

objeto está en un estado en cierto instante. El estado está caracterizado parcialmente por los

valores algunos de los atributos del objeto. El estado en el que se encuentra un objeto determina

su comportamiento. Cada objeto sigue el comportamiento descrito en el Diagrama de Estados

asociado a su clase. Los Diagramas de Estados y escenarios son complementarios, los Diagramas

de Estados son autómatas jerárquicos que permiten expresar concurrencia, sincronización y

jerarquías de objetos, son grafos dirigidos y deterministas. La transición entre estados es

instantánea y se debe a la ocurrencia de un evento.

Estado Identifica un periodo de tiempo del objeto (no instantáneo) en el cual el objeto está esperando

alguna operación, tiene cierto estado característico o puede recibir cierto tipo de estímulos. Se

representa mediante un rectángulo con los bordes redondeados, que puede tener tres

compartimientos: uno para el nombre, otro para el valor característico de los atributos del objeto

en ese estado y otro para las acciones que se realizan al entrar, salir o estar en un estado (entry,

exit o do, respectivamente).

Eventos Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. Esta

ocurrencia puede ser una de varias cosas:

Condición que toma el valor de verdadero o falso

Recepción de una señal de otro objeto en el modelo

Recepción de un mensaje

Paso de cierto período de tiempo, después de entrar al estado o de cierta hora y fecha

particular

El nombre de un evento tiene alcance dentro del paquete en el cual está definido, no es local a la

clase que lo nombre.

Envío de mensajes Además de mostrar y transición de estados por medio de eventos, puede representarse el

momento en el cual se envían mensajes a otros objetos. Esto se realiza mediante una línea

punteada dirigida al diagrama de estados del objeto receptor del mensaje.


40

Diagramas de Objetos Objeto es una entidad discreta con límites bien definidos y con identidad, es una unidad atómica

que encapsula estado y comportamiento. La encapsulación en un objeto permite una alta

cohesión y un bajo acoplamiento. el Objeto es reconocido también como una instancia de la clase

a la cual pertenece.

La encapsulación presenta tres ventajas básicas:

1. Se protegen los datos de accesos indebidos

2. El acoplamiento entre las clases se disminuye

3. Favorece la modularidad y el mantenimiento

Un objeto se puede ver desde dos perspectivas relacionadas: como una entidad de un

determinado instante de tiempo que posee un valor específico (Un objeto puede caracterizar una

entidad física -coche-) y como un poseedor de identidad que tiene distintos valores a lo largo del

tiempo (abstracta -ecuación matemática-).

Cada objeto posee su propia identidad exclusiva y se puede hacer referencia a él mediante una

denominación exclusiva que permite accederle. El Modelado de Objetos permite representar el

ciclo de vida de los objetos a través de sus interacciones. En UML, un objeto se representa por

un rectángulo con un nombre subrayado.

Objeto = Identidad + Estado + Comportamiento

El estado está representado por los valores de los atributos.

Un atributo toma un valor en un dominio concreto.

La regla general para la notación de instancias consiste en utilizar el mismo símbolo geométrico

que el descriptor. En la instancia se muestran los posibles valores pero las propiedades

compartidas sólo se pone de manifiesto en el descriptor. La notación canónica es un rectángulo

con tres compartimientos. En el primero va el nombre del objeto, en el segundo sus atributos y

en el tercero sus operaciones. Este último puede ser omitido si así se prefiere.

Oid (ObjectIdentifier)

Cada objeto posee un oid. El oid establece la identidad del objeto y tiene las siguientes

características:

Constituye un identificador único y global para cada objeto dentro del sistema.

Es determinado en el momento de la creación del objeto.

Es independiente de la localización física del objeto, es decir, provee completa

independencia de localización.

Es independiente de las propiedades del objeto, lo cual implica independencia de valor y

de estructura.


41

No cambia durante toda la vida del objeto. Además, un oid no se reutiliza aunque el

objeto deje de existir.

No se tiene ningún control sobre los oids y su manipulación resulta transparente. Sin embargo, es

preciso contar con algún medio para hacer referencia a un objeto utilizando referencias del

dominio (valores de atributos).

Características alrededor de un objeto:

Estado:

El estado evoluciona con el tiempo. Algunos atributos pueden ser constantes, el comportamiento

agrupa las competencias de un objeto y describe las acciones y reacciones de ese objeto. Las

operaciones de un objeto son consecuencia de un estímulo externo representado como mensaje

enviado desde otro objeto.

Persistencia:

La persistencia de los objetos designa la capacidad de un objeto trascender en el espacio/tiempo,

podremos después reconstruirlo, es decir, cogerlo de memoria secundaria para utilizarlo en la

ejecución (materialización del objeto). Los lenguajes OO no proponen soporte adecuado para la

persistencia, la cual debería ser transparente, un objeto existe desde su creación hasta que se

destruya.

Comunicación:

Un sistema informático puede verse como un conjunto de objetos autónomos y concurrentes que

trabajan de manera coordinada en la consecución de un fin específico. El comportamiento global

se basa pues en la comunicación entre los objetos que la componen.

Categorías de objetos:

Activos o Pasivos

Cliente -- Servidores, Agentes

1. Objeto Activo: posee un hilo de ejecución (thread) propio y puede iniciar una actividad.

2. Objeto Pasivo: no puede iniciar una actividad pero puede enviar estímulos una vez que se

le solicita un servicio.

3. Cliente es el objeto que solicita un servicio.

4. Servidor es el objeto que provee el servicio solicitado.

5. Los agentes reúnen las características de clientes y servidores. Son la base del mecanismo

de delegación. Introducen indirección: un cliente puede comunicarse con un servidor que

no conoce directamente.

Mensajes:

La unidad de comunicación entre objetos se llama mensaje. El mensaje es el soporte de una

comunicación que vincula dinámicamente los objetos que fueron separados previamente en el

proceso de descomposición. Adquiere toda su fuerza cuando se asocia al polimorfismo y al

enlace dinámico. Un estímulo causará la invocación de una operación, la creación o destrucción

de un objeto o la aparición de una señal. Un mensaje es la especificación de un estímulo.


42

Tipos de flujo de control:

1. Llamada a procedimiento o flujo de control anidado

2. Flujo de control plano

3. Retorno de una llamada a procedimiento

4. Otras variaciones

5. Esperado (balking)

6. Cronometrado (time-out)

Diagrama de Paquetes

Cualquier sistema grande se debe dividir en unidades más pequeñas, de modo que las personas

puedan trabajar con una cantidad de información limitada, a la vez y de modo que los equipos de

trabajo no interfieran con el trabajo de los otros.

Un paquete es una parte de un modelo. Cada parte del modelo debe pertenecer a un paquete.

Pero para ser funcional, la asignación debe seguir un cierto principio racional, tal como

funcionalidad común, implementación relacionada y punto de vista común. UML no impone una

regla para componer los paquetes.

Los paquetes ofrecen un mecanismo general para la organización de los modelos/subsistemas

agrupando elementos de modelado. Cada paquete corresponde a un submodelo (subsistema) del

modelo (sistema). Los paquetes son unidades de organización jerárquica de uso general de los

modelos de UML. Pueden ser utilizados para el almacenamiento, el control de acceso, la gestión

de la configuración y la construcción de bibliotecas que contengan fragmentos reutilizables del

modelo.

Un paquete puede contener otros paquetes, sin límite de anidamiento pero cada elemento

pertenece a (está definido en) sólo un paquete.

Los paquetes contienen elementos del modelo al más alto nivel, tales como clases y sus

relaciones, máquinas de estado, diagramas de casos de uso, interacciones y colaboraciones;

atributos, operaciones, estados, líneas de vida y mensajes están contenidos en otros elementos y

no aparecen como contenido directo de los paquetes.

Dependencias en los paquetes

Las dependencias que se presentan entre elementos individuales, pero en un sistema de cualquier

tamaño, deben ser vistas en un nivel más alto. Las dependencias entre paquetes resumen

dependencias entre los elementos internos a ellos, es decir, las dependencias del paquete son

derivables a partir de las dependencias entre los elementos individuales.

La presencia de una dependencia entre paquetes implica que existe en un enfoque ascendente

(una declaración de existencia), o que se permite que exista más adelante en un enfoque


43

descendente (una restricción que limita cualquier otra relación), por lo menos un elemento de

relación con el tipo de dependencia indicado entre elementos individuales dentro de los paquetes

correspondientes.

Las dependencias múltiples del mismo tipo entre elementos individuales se agregan a una sola

dependencia entre los paquetes que contienen los elementos. Si las dependencias entre elementos

contienen estereotipos, éste puede ser omitido en la dependencia del paquete, para dar una sola

dependencia de alto nivel.

Una clase de un paquete puede aparecer en otro paquete por la importación a través de una

relación de dependencia entre paquetes. Todas las clases no son necesariamente visibles desde el

exterior del paquete, es decir, un paquete encapsula a la vez que agrupa.

En general, un paquete no puede tener acceso al contenido de otro paquete. Los paquetes son

opacos, a menos que sean abiertos por una dependencia de acceso o de importación. La

dependencia de acceso indica que el contenido del paquete del proveedor puede aparecer en

referencias efectuadas por los elementos del paquete cliente. En general, un paquete puede ver

solamente los elementos de otros paquetes que tienen visibilidad pública. Los elementos con

visibilidad protegida pueden ser vistos únicamente por los paquetes que son descendientes del

paquete contenedor de dichos elementos. Los elementos con visibilidad privada sólo son vistos

por su paquete contenedor y anidados. La visibilidad también se aplica a las clases. El permiso

de acceso y visibilidad son necesarios para hacer referencia a un elemento.

La dependencia de acceso no modifica el espacio de nombres del cliente no crea las referencias

automáticamente, simplemente concede permiso para establecer referencias. La dependencia de

importación se utiliza para agregar nombres al espacio de nombres del paquete del cliente como

sinónimos de los caminos completos.

Los paquetes se dibujan como rectángulos con pestañas (similar al icono "carpeta"), las

dependencias se muestran como flechas con líneas discontinuas. El operador "::" permite

designar una clase definida en un contexto distinto del actual.


44


45


46


47

LECTURAS COMPLEMENTARIAS

1.- Tipos y usos de los Sistemas de Información.

a) Sistemas de procesamiento de transacciones (sistemas transaccionales). Su función

primordial en procesar transacciones a nivel operativo, tales como: pagos, cobros,

pólizas, entradas, salidas, etc.

Ejemplos: Sistema de facturación, sistemas de nóminas, cuentas por cobrar,

contabilidad general, control de inventarios, registro e inscripciones, etc.

b) Sistemas de Soporte a la Toma de decisiones. Son aquellos sistemas que generan

información para la toma de decisiones en los dos niveles superiores de una empresa,

suelen introducirse después de haber implantado un sistema transaccional. Ejemplos:

Sistemas para la compra de materiales, flujo de fondos, proyecciones financieras, modelos

de inventarios, etc. Dentro de estos sistemas están:

Sistemas para la toma de decisiones de grupo

Sistemas expertos de soporte a la toma de decisiones

Sistemas de información para ejecutivos

Sistemas de información administrativos

c) Sistemas estratégicos. Los cuales se desarrollan en las organizaciones con el fin de lograr

ventajas competitivas a través del uso de la tecnología de información. Ejemplo: Sistemas

de planificación de recursos, cajeros automáticos.

Ejemplos:

1.- Sistema de Información de control de personal

Objetivo: Llevar un control automatizado de todos los empleados de un empresa

Actividades:

Captura de datos de un empleado

Crear políticas de créditos de pago y categorías

Cálculos de sueldos

Recepción de facturas

Registro de horas trabajadas, extras, atrasos, etc

Calculo de antigüedad

Reportes de pagos

2.- Sistema de Información contable

Objetivo: proporcionar información acerca de todas las actividades contables de una

empresa

Actividades:

Generar Reportes

Plan de cuentas

Libro diario

Libro Mayor

Facturación


48

PRINCIPALES HERRAMIENTAS Y TECNOLOGIAS

Case Computer-Aided Software Engineering

(Ingeniería del Software Asistido por Computadora)

Las herramientas Case. Software que se utiliza en una o cualquiera de la fases de desarrollo de sistemas de información, incluyendo análisis, diseño y programación. Por ejemplo las herramientas de diagramación ayudan en las fases de análisis y diseño mientras que los generadores de aplicaciones aceleran la fase de programación.

Las herramientas CASE proporcionan métodos automáticos para diseñar y documentar las técnicas tradicionales de Programación Orientada a Objetos.

La meta es proveer un lenguaje para describir un sistema complejo, que sea suficiente para generar todos los programas necesarios.

I-Case Integrate Case

(Cases Integrados)

Un I-Case se refiere a un conjunto de herramientas Case que soportan todas las fases del ciclo de vida incluyendo la generación de código, con un repositorio único y consistente.

Programación Visual

La programación Visual es una forma de case que expresa el diseño de programa con gráfico, color y posiblemente sonido. Los objetos se representan en forma visual y pueden ser concebidos como si fueran máquinas físicas que pasan de un estado a otro.

La programación visual permite a los desarrolladores, ingresar, comprender "pensar con", ejecutar y manipular programas, usando fundamentalmente notaciones gráficas.


49

Máquina de Inferencia

Es un software que hace de hechos y reglas usando técnicas de inferencia lógica. Una máquina de inferencia opera con una colección de reglas acerca de un área del conocimiento. Selecciona las reglas y el encadenamiento hacia adelante (razonamiento orientado a ingreso input), el encadenamiento hacia atrás (razonamiento orientado a metas) o ambos permite a las computadoras hacer deducciones complejas sin un programa de aplicación. Es una técnica principal usada en Inteligencia Artificial.

Generadores de Código

Siempre que sea posible, los programadores deben ser generados automáticamente a partir de diseños de alto nivel, especificaciones o

imágenes en una pantalla de un CASE, El código puede generarse a partir de las tablas de decisión, reglas diagramas de acción, diagramas de eventos, diagramas de transición de estado, representaciones de objetos y sus propiedades y relaciones, etc. Los generadores de código producen códigos libres de errores de sintaxis a partir de diseños de alto nivel, cuadro o especificaciones.

Base de Datos Orientado a Objetos

Una base de datos orientada a objetos es una base de datos inteligente. Soporta los paradigmas orientados a objetos, almacenamientos de métodos y datos, más que simplemente datos. Esta diseñada para ser físicamente eficiente en el almacenamiento de datos complejos. Un repositorio en un base de datos orientada a objetos (aún cuando las herramientas CASE no soporten análisis, diseño y programación orientada a objeto).

Tecnología Cliente/Servidor

Es un software que ejecuta en múltiples computadoras tales como sistemas servidoras LAN, sistemas cooperativos, procesamiento distribuido y computadoras en paralelo. La tecnología cliente/servidor puede describirse como sigue: Un cliente es un módulo de software que solicita una operación. Un servidor es un módulo de software que atiende el requerimiento, cliente/servidor y puede ejecutarse en máquinas separadas dispuestas en casi cualquier configuración.

Lenguajes no Procedurales

Con los Lenguajes Procedurales (tal como Cobol o C), nosotros instruimos al computador cómo debe ejecutar una secuencia de operaciones. Con los Lenguajes No-Procedurales, definimos los resultados requeridos. Un interprete o compilador genera el código.


50

BIBLIOGRAFIA

OBRA AUTOR LUGAR de EDIC EDITORIAL AñO

Análisis y Diseño de SIstemas

James Seen Mexico Limusa 1983

Analisis y Diseño de Sistemas

Kendall & Kendall España Prentice Hall

1998

Ingenieria del Software

Roger Pressman

UML gota a gota Fewler

Direcciones de internet:

www.monografias.com

www.programaciónfacil.com

www.rational.com

www.rincondelprogramador

GLOSARIO TECNICO

CASE – Ingeniería de Software asistido por Computadora

Clase – Conjunto de objetos

UML – Lenguaje Unificado de modelación

Reutilización – volver a utilizar ciertos módulos, procedimientos, funciones

Polimorfismo – varias formas de comportamiento que tienen los objetos

Encapsulamiento – ocultamiento de la información

Estereotipo – etiqueta o marca que se utilizan en la relación de clases

Metodo – Conjunto de pasos para lograr una determinada actividad

Tecnología – Conjunto de técnicas

Paradigma – Forma de pensar o conceptualizar una cosa.

http://www.monografias.com/

http://www.programacinfacil.com/

http://www.rational.com/

http://www.rincondelprogramador/

Tema # 1 CONSIDERACIONES GENERALESvirtual.usalesiana.edu.bo/web/contenido/dossier/22012/1769.pdf ·...

Documents

Transcript of Tema # 1 CONSIDERACIONES GENERALESvirtual.usalesiana.edu.bo/web/contenido/dossier/22012/1769.pdf ·...