Sei sulla pagina 1di 32

Anlisis y Diseo de Sistemas de Informacin II Ing.

Csar Alfredo Saavedra Raya

ASEGURAMIENTO DE LA CALIDAD MEDIANTE INGENIERA DE SOFTWARE

CALIDAD

La calidad ha sido durante mucho tiempo una preocupacin para las empresas, como lo debe ser para los analistas de sistemas en el anlisis y diseo de sistemas de informacin. Es demasiado arriesgado emprender todo el proceso de anlisis y diseo sin usar un enfoque de aseguramiento de la calidad. Los tres enfoques para el aseguramiento de la calidad mediante ingeniera de software son:
1. 2. 3.

Garantizar el aseguramiento de la calidad total diseando sistemas y software con un enfoque modular, descendente (de arriba a abajo); Documentar el software con las herramientas adecuadas, y Probar, mantener y auditar el software El primero es que el usuario del sistema de informacin es el factor individual ms importante en establecer y evaluar su calidad. El segundo es que es mucho menos costoso corregir los problemas en sus fases iniciales que esperar hasta que un problema se manifieste a travs de las quejas o crisis del usuario

Dos propsitos guan el aseguramiento de la calidad.


a) b)

ADMINISTRACIN DE LA CALIDAD TOTAL


La administracin de la calidad total (TQM, por sus siglas en ingls) es esencial a lo largo de todos los pasos del desarrollo de sistemas. Segn Dean y Evans [1994), los principales elementos de la TQM slo son significativos cuando se presentan en un contexto organizacional que favorece un esfuerzo integral por la calidad SEIS SIGMA Originalmente desarrollado por Motorola en la dcada de 1980, Seis Sigma es ms que una metodologa; es una cultura basada en la calidad. La meta de Seis Sigma es eliminar todos los defectos. Esto se aplica a cualquier producto, servicio o proceso Seis Sigma es un enfoque descendente de arriba a abajo. Se requiere que un CEO adopte la filosofa y un ejecutivo funja como campen de proyecto. Un lder de proyecto de Seis Sigma se denomina Black Belt (cinta negra) Las personas escogidas para ser Black Belts pueden provenir de diferentes niveles, pero deben tener experiencia en el proyecto y contar con capacitacin especial. Los Black Belts se certifican despus que han liderado proyectos de manera exitosa. Los miembros del proyecto se denominan Green Belts (cintas verdes). Los Black Belts maestros son los Black Belts que han trabajado en muchos proyectos y estn disponibles como un recurso para los equipos de proyectos. (La metfora de Black Belt viene del sistema de clasificacin de capacidades en las artes marciales. Resalta la importancia de la disciplina en todos los mbitos)

ADMINISTRACIN DE LA CALIDAD TOTAL


1 Definir el Problema 7 Obtener Conclusiones 2 Observar el Problema

SEIS SIGMA
6 Normalizar los Cambios 3 Analizar las causas

5 Estudiar los Resultados

4 Actuar sobre las causas

ADMINISTRACIN DE LA CALIDAD TOTAL


RESPONSABILIDAD DE LA ADMINISTRACIN DE LA CALIDAD TOTAL En trminos prcticos, gran parte de la responsabilidad por la calidad de los sistemas de informacin recae en los usuarios de stos y en los directivos. Para que la TQM se vuelva una realidad en los proyectos de sistemas, deben darse dos condiciones. Primera, debe existir un apoyo organizacional incondicional por parte de los directivos, lo cual es distinto a simplemente respaldar el nuevo proyecto de los directivos REPASO ESTRUCTURADO Una de las acciones de administracin de la calidad ms eficaces que puede emprender el equipo de anlisis de sistemas es hacer repasos estructurados de manera rutinaria. Los repasos estructurados son una forma de usar expertos para monitorear la programacin y el desarrollo general del sistema, sealar los problemas y permitir al programador o analista responsable de dicha parte del sistema hacer los cambios correspondientes. Los repasos estructurados involucran por lo menos a cuatro personas: la persona responsable de la parte del sistema o subsistema que se revisar (un programador o analista), un coordinador del repaso, un programador o analista experto y un experto que toma notas acerca de las sugerencias

ADMINISTRACIN DE LA CALIDAD TOTAL


DISEO Y DESARROLLO DE SISTEMAS Diseos de sistemas ascendente (de abajo a arriba o bottomup).- Este diseo se refiere a identificar los procesos que necesitan computarizarse conforme surgen, analizarlos como sistemas y codificar los procesos o comprar software empaquetado para resolver el problema inmediato. Los problemas que requieren computarizarse normalmente se encuentran en el nivel ms bajo de la organizacin Diseo de sistemas descendente (de arriba abajo o topdown).- Significa ver una descripcin amplia del sistema y despus dividirla en partes ms pequeas o subsistemas. El diseo descendente permite a los analistas de sistemas determinar primero los objetivos organizacionales globales, as como tambin determinar cmo se renen mejor en un sistema global. Despus el analista divide dicho sistema en subsistemas y sus requerimientos

ADMINISTRACIN DE LA CALIDAD TOTAL


DESARROLLO MODULAR Una vez que se toma el enfoque del diseo descendente, el enfoque modular es til en la programacin. Este enfoque implica dividir la programacin en partes lgicas y manejables llamadas mdulos. Este tipo de programacin funciona bien con el diseo descendente porque da nfasis a las interfaces entre los mdulos y no los descuida hasta el final del desarrollo de sistemas. Idealmente, cada mdulo individual debe ser funcionalmente cohesivo de manera que se encargue de realizar una sola funcin Los lineamientos para la programacin modular son:
1. 2. 3. 4.

Mantener cada mdulo de un tamao manejable (incluir a la perfeccin una sola funcin). Poner particular atencin a las interfaces crticas (los datos y variables de control que se pasan a otros mdulos). Minimizar el nmero de mdulos que el usuario debe modificar al hacer los cambios. Mantener las relaciones jerrquicas establecidas en las fases descendentes.

USO DE DIAGRAMAS DE ESTRUCTURA PARA DISEAR SISTEMAS


La herramienta recomendada para disear un sistema modular descendente se denomina diagrama de estructura. Este grfico simplemente es un diagrama que consiste de cuadros rectangulares, los cuales representan los mdulos, y de flechas de conexin. DIBUJO DE UN DIAGRAMA DE ESTRUCTURA Al transformar un diagrama de flujo de datos en un diagrama de estructura, se deben tener en cuenta varias consideraciones adicionales. El diagrama de flujo de datos indicar la secuencia de los mdulos en un diagrama de estructura. Si un proceso proporciona entrada a otro proceso, los mdulos correspondientes se deben desempear en la misma secuencia TIPOS DE MDULOS Los mdulos del diagrama de estructura entran en una de las tres categoras generales:

1. 2. 3.

Control Transformacional (a veces denominado trabajador) Funcional. Al producir un diagrama de estructura que es fcil de desarrollar y modificar, se debe tener cuidado de no mezclar los diferentes tipos de mdulos.

INGENIERA DE SOFTWARE Y DOCUMENTACIN


El software y los procedimientos se documentan de manera que se codifiquen en un formato que se pueda acceder fcilmente. El acceso a esta documentacin es necesario para las nuevas personas que aprenden el sistema y como un recordatorio para aquellos que no usan el programa con frecuencia. La documentacin permite a usuarios, programadores y analistas "ver" el sistema, su software y procedimientos sin tener que interactuar con l. Cierta documentacin proporciona una apreciacin global del propio sistema, mientras que la documentacin de procedimiento detalla lo que se debe hacer para ejecutar el software en el sistema y la documentacin del programa detalla el cdigo del programa que se usa PSEUDOCDIGO En la industria es comn el uso del pseudocdigo, pero la falta de estandarizacin evitar que sea aceptado por todos. Debido a que el pseudocdigo est tan cerca del cdigo de programa, naturalmente es favorecido por programadores y por consiguiente no es favorecido por analistas de negocios. El pseudocdigo con frecuencia se usa para representar la lgica de cada mdulo en un diagrama de estructura.

INGENIERA DE SOFTWARE Y DOCUMENTACIN


MANUALES DE PROCEDIMIENTO Los manuales de procedimiento son documentos organizacionales comunes que la mayora de las personas ha visto. Son el componente en Espaol de la documentacin, aunque tambin podran contener cdigos de programa, diagramas de flujo, etc. Se pretende que los manuales comuniquen a aquellos que los usan. Podran contener comentarios de fondo, los pasos requeridos para lograr diferentes transacciones, instrucciones de cmo recuperarse de los problemas y qu hacer si algo no funciona (solucionar problemas]. Actualmente muchos manuales estn disponibles en lnea, con capacidad de hipertexto que facilita el uso EL MTODO DE FOLKLORE El FOLKLORE es una tcnica de documentacin de sistemas creada para complementar algunas de las tcnicas ya tratadas. Aun con la abundancia de tcnicas disponibles, muchos sistemas se documentan inadecuadamente o no se documentan en absoluto. El FOLKLORE recopila informacin que normalmente se comparte entre los usuarios pero raramente se pone por escrito

INGENIERA DE SOFTWARE Y DOCUMENTACIN


SELECCIN DE UNA TCNICA DE DISEO Y DOCUMENTACIN Las tcnicas discutidas en este captulo son sumamente valiosas como herramientas de diseo, ayudas de memoria, herramientas de productividad y como medios de reducir las dependencias en los miembros de personal clave. Sin embargo, el analista de sistemas se enfrenta con una decisin difcil con respecto a qu mtodo adoptar Lineamientos para ayudar al analista a seleccionar la tcnica adecuada. Escoja una tcnica que:
1. 2. 3. 4.

5.
6.

Es compatible con la documentacin existente. Se entiende por otros en la organizacin. Le permite regresar a trabajar en el sistema despus de que ha estado fuera de l por un periodo. Sea conveniente para el tamao del sistema en que est trabajando Permita un enfoque de diseo estructurado si se considera como ms importante que otros factores. Permita fcil modificacin

COMO PROBAR, MANTENER Y AUDITAR


EL PROCESO DE PROBAR Todos los programas de aplicacin del sistema recin escritos o modificados as como tambin nuevos manuales de procedimiento, nuevo hardware y todas las interfaces del sistema se deben probar completamente. Probar al azar y por tanteo no ser suficiente. Las pruebas se hacen durante todo el proceso de desarrollo de sistemas, no slo al final. Se busca descubrir errores desconocidos hasta ahora, no demostrar la perfeccin de programas, manuales o equipo
a)

b)
c) d)

Pruebas de programas con datos de prueba Prueba de vnculos con datos de prueba Prueba completa de sistemas con datos de prueba Prueba completa de sistemas con datos reales

COMO PROBAR, MANTENER Y AUDITAR


PRCTICAS DE MANTENIMIENTO Reducir los costos de mantenimiento es una consideracin principal, debido a que el mantenimiento de software aislado puede consumir ms de 50 por ciento del presupuesto de procesamiento de datos para un negocio Por lo regular el mantenimiento se realiza para mejorar el software existente en lugar de responder a una crisis o falla del sistema El mantenimiento tambin se hace para actualizar el software en respuesta a la organizacin cambiante CMO AUDITAR Auditar es otra forma de asegurar la calidad de la informacin contenida en el sistema. Ampliamente definido, auditar se refiere a pedirle a un experto, que no est involucrado en crear o usar un sistema, examinar la informacin para determinar su fiabilidad. Ya sea que la informacin se establezca o no para ser fiable, el descubrimiento en su fiabilidad se comunica a otros con el propsito de hacer la informacin del sistema ms til para ellos

IMPLEMENTACIN EXITOSA DEL SISTEMA DE INFORMACIN

La implementacin es el proceso de asegurar que los sistemas de informacin y las redes sean funcionales y despus involucrar a los usuarios bien capacitados en su operacin. En los proyectos grandes de sistemas, el papel principal del analista es vigilar la implementacin, estimando correctamente el tiempo necesario, y despus supervisar la instalacin del equipo para los sistemas de informacin (qu se podra establecer con un enfoque cliente/servidor en una red de rea local], capacitar usuarios y convertir archivos y bases de datos al nuevo sistema Los sistemas distribuidos aprovechan la tecnologa de las telecomunicaciones y de administracin de bases de datos para interconectar a las personas que manipulan algunos de los mismos datos de formas significativas pero diferentes. Conforme se evalan el hardware y software, el analista de sistemas tambin necesita considerar los costos y beneficios de emplear un sistema distribuido para satisfacer los requerimientos del usuario.

IMPLEMENTACIN EXITOSA DEL SISTEMA DE INFORMACIN

Los sistemas distribuidos aprovechan la tecnologa de las telecomunicaciones y de administracin de bases de datos para interconectar a las personas que manipulan algunos de los mismos datos de formas significativas pero diferentes. Conforme se evalan el hardware y software, el analista de sistemas tambin necesita considerar los costos y beneficios de emplear un sistema distribuido para satisfacer los requerimientos del usuario. Una de las formas ms populares de acercarse a los sistemas distribuidos es mediante el uso de un modelo cliente/servidor (C/S). Los tipos estndar de redes organizacionales incluyen la red de rea local [LAN] y la red de rea amplia [WANQ. Usando un enfoque descendente, los analistas pueden usar cinco smbolos para ayudar a dibujar la descomposicin de la red y diagramas de conectividad de hub. El software especializado, denominado groupware, se escribe especficamente para apoyar a grupos o equipos de trabajadores con aplicaciones funcionales. Su propsito es ayudar a los miembros de un grupo a trabajar en conjunto a travs de redes

IMPLEMENTACIN EXITOSA DEL SISTEMA DE INFORMACIN

La capacitacin de usuarios y personal para interactuar con el sistema de informacin es una parte importante de la implementacin, debido a que los usuarios generalmente deben poder ejecutar el sistema sin la intervencin del analista. La conversin tambin es parte del proceso de implementacin. El analista tiene varias estrategias para cambiar del sistema de informacin viejo al nuevo. Las cinco estrategias de conversin son: conversin directa, conversin paralela, conversin por fases o gradual, conversin de prototipo modular y conversin distribuida. La seguridad de datos y sistemas ha cobrado mayor importancia para los analistas que disean ms aplicaciones de comercio electrnico. La seguridad tiene varias facetas fsica, lgica y conductual que deben trabajar en conjunto. Los analistas pueden tomar varias precauciones, tal como software antivirus, filtracin de correo electrnico, filtros URL, firewalls, gateways, redes privadas virtuales, productos de deteccin de intrusin, capa de conexiones seguras, interpretacin electrnica segura y el uso de una infraestructura de clave pblica para mejorar la privacidad, confidencialidad y la seguridad de sistemas, redes, datos, individuos y organizaciones

ANLISIS Y DISEO DE SISTEMAS ORIENTADOS A OBJETOS, USANDO EL LENGUAJE UNIFICADO DE MODELACIN (UML)
La programacin orientada a objetos difiere de la programacin por procedimientos tradicional, pues examina los objetos que son parte de un sistema. Cada objeto es una representacin en computadora de alguna cosa o evento real. En esta seccin se presentan descripciones generales de los principales conceptos orientados a objetos de las clases, la herencia y los objetos. OBJETOS Los objetos son personas, lugares o cosas que son relevantes para el sistema bajo anlisis. Los objetos podran ser clientes, artculos, pedidos, etc. Los objetos tambin podran ser pantallas GUI o reas de texto en la pantalla. CLASES Los objetos se representan y agrupan en clases que son ptimas para reutilizarse y darles mantenimiento. Una clase define el conjunto de atributos y comportamientos compartidos por cada objeto de la clase Cada clase debe tener un nombre que la distinga de todas las dems. Los nombres de clase normalmente son sustantivos o frases cortas y empiezan con una letra mayscula

ANLISIS Y DISEO DE SISTEMAS ORIENTADOS A OBJETOS, USANDO EL LENGUAJE UNIFICADO DE MODELACIN (UML)

HERENCIA Otro concepto importante de los sistemas orientados a objetos es la herencia. Las clases pueden tener hijos; es decir, una clase se puede crear a partir de otra clase. En el UML, la clase original o madre se conoce como clase base. La clase hija se denomina clase derivada. sta se puede crear de tal manera que herede todos los atributos y comportamientos de la clase base. Sin embargo, una clase derivada podra tener atributos y comportamientos adicionales La herencia reduce el trabajo de la programacin usando fcilmente objetos comunes

ANLISIS Y DISEO DE SISTEMAS ORIENTADOS A OBJETOS, USANDO EL LENGUAJE UNIFICADO DE MODELACIN (UML)
Nombre de clase

HERENCIA

Atributos

Mtodos (operaciones)

CLASE

ANLISIS Y DISEO DE SISTEMAS ORIENTADOS A OBJETOS, USANDO EL LENGUAJE UNIFICADO DE MODELACIN (UML)

CONCEPTOS Y DIAGRAMAS DEL LENGUAJE UNIFICADO DE MODELACIN (UML) El conjunto de herramientas de UML incluye diagramas que permiten a las personas visualizar la construccin de un sistema orientado a objetos, similar a la forma en que un conjunto de planos permite a las personas visualizar la construccin de un edificio. Ya sea que usted est trabajando independientemente o con un equipo grande de desarrollo de sistemas, la documentacin que crea con UML proporciona un medio eficaz de comunicacin entre el equipo de desarrollo y el equipo de negocios en un proyecto

ANLISIS Y DISEO DE SISTEMAS ORIENTADOS A OBJETOS, USANDO EL LENGUAJE UNIFICADO DE MODELACIN (UML)
Categora UML Elementos Elementos de UML Elementos estructurales Detalles Especficos de UML Clases Interfaces Colaboraciones Casos de uso Clases activas Componentes Nodos Interacciones Mquinas de estado Paquetes Notas Dependencias Agregaciones Asociaciones Generalizaciones Comunica Extiende Incluye Generaliza Diagramas de Clase Diagramas de componentes Diagramas de despliegue Diagramas de casos de uso Diagramas de secuencia Diagramas de colaboracin Diagramas de estado Diagramas de actividades

Elementos de Comportamiento Elementos de Agrupamiento Elementos de Anotacin Relaciones Relaciones estructurales

Relaciones de comportamiento

Diagramas

Diagramas Estructurales

Diagramas de Comportamiento

ANLISIS Y DISEO DE SISTEMAS ORIENTADOS A OBJETOS, USANDO EL LENGUAJE UNIFICADO DE MODELACIN (UML)
Diagrama de casos de uso
Cada caso de uso podr crear un diagrama de actividades

Los escenarios del caso de uso se podra generar de los diagramas de casos de uso

Diagrama de actividades

Escenario del caso de uso


Los casos de uso y los diagramas de secuencia ayudan a determinar las clases

Identificadores Pasos Condiciones


Cada escenario del caso de uso podra crear un diagrama de secuencia

Diagrama de clases Diagrama de secuencia


1 1..*
1:

Diagrama de colaboracin

2: 3:

1..*

Diagrama de grfico de estados


Cada clase podra tener un diagrama de grfico de estado para ayudar a determinar las operaciones
Los diagramas de secuencia y colaboracin podrian ser intercambiables

ANLISIS Y DISEO DE SISTEMAS ORIENTADOS A OBJETOS, USANDO EL LENGUAJE UNIFICADO DE MODELACIN (UML)

Modelado de casos de uso El UML est basado fundamentalmente en una tcnica de anlisis orientada a objetos conocida como modelado de casos de uso. Un modelo de caso de uso describe lo que hace un sistema sin describir cmo lo hace; es decir, es un modelo lgico del sistema. El modelo de caso de uso refleja la vista del sistema desde la perspectiva de un usuario fuera del sistema (es decir, los requerimientos del sistema). El modelo de caso de uso proporciona medios eficaces de comunicacin entre el equipo del negocio y el equipo de desarrollo. Un modelo de caso de uso divide la funcionalidad del sistema en comportamientos, servicios y respuestas (los casos de uso) que son significativos para los usuarios (actores) del sistema

ANLISIS Y DISEO DE SISTEMAS ORIENTADOS A OBJETOS, USANDO EL LENGUAJE UNIFICADO DE MODELACIN (UML)

Un diagrama de caso de uso contiene el actor y smbolos de caso de uso, junto con lneas de conexin. Un actor puede ser un humano, otro sistema o un dispositivo tal como un teclado, mdem o conexin Web. Los actores pueden iniciar una instancia de un caso de uso. Un actor podra interactuar con uno o ms casos de uso y viceversa Los actores se podran dividir en dos grupos. Los actores principales proporcionan datos o reciben informacin del sistema. Los actores secundarios ayudan a mantener el sistema en ejecucin o proporcionan ayuda Un caso de uso proporciona a los desarrolladores una visin de lo que quieren los usuarios. No contiene detalles tcnicos o de implementacin. Podemos pensar en un caso de uso como una secuencia de transacciones en un sistema. El modelo de caso de uso se basa en las interacciones y relaciones de casos de uso individuales

ANLISIS Y DISEO DE SISTEMAS ORIENTADOS A OBJETOS, USANDO EL LENGUAJE UNIFICADO DE MODELACIN (UML)
SMBOLO DESCRIPCIN

ACTOR CASO DE USO Relaciones Comunica


<<incluir>> Un actor se conecta a un caso de uso usando una lnea sin puntas de flecha. Un caso de uso contiene un comportamiento que es ms comn que otro caso de uso. La flecha apunta al caso de uso comn Un caso de uso diferente maneja las excepciones del caso de uso bsico. La flecha apunta desde el caso de uso extendido hacia el bsico Un elemento" de UML es ms general que otro elemento". La flecha apunta al elemento" general

Incluye
Extiende Generaliza

<<extender>>

ANLISIS Y DISEO DE SISTEMAS ORIENTADOS A OBJETOS, USANDO EL LENGUAJE UNIFICADO DE MODELACIN (UML)

<<include>> Pago de cuotas del estudiante


Estudiante Matricularse en el curso

Matricularse en el curso <<include>>

Relacin Comunica

Relacin Incluye

Arreglar residencia estudiantil

<<extend>>

Estudiante de Tiempo Parcial

Estudiante
Pago de cuotas del estudiante Seguro medico

Relacin Generaliza

Relacin Extiende

ANLISIS Y DISEO DE SISTEMAS ORIENTADOS A OBJETOS, USANDO EL LENGUAJE UNIFICADO DE MODELACIN (UML)

Estudiante

Agregar estudiante <<include>>

Matriculacin

<<include>> Verificar identidad <<include>> <<include>> Matricularse en la clase <<extend>> Oficina de Finanzas

Cambiar informacin del estudiante

ver informacin del estudiante

Comprar libro de texto

Librera

Estudiante

Transferir crditos

Departamento

ANLISIS Y DISEO DE SISTEMAS ORIENTADOS A OBJETOS, USANDO EL LENGUAJE UNIFICADO DE MODELACIN (UML)
DIAGRAMAS DE ACTIVIDADES Los diagramas de actividades muestran las secuencias de actividades de un proceso, incluyendo las actividades secuenciales, las actividades paralelas y las decisiones que se toman. Por lo general, un diagrama de actividades se elabora para un caso de uso y podra reflejar los diferentes escenarios posibles. Un rectngulo con esquinas redondeadas representa una actividad, ya sea manual, como firmar un documento legal; o automatizada, como un mtodo o un programa. Una flecha representa un evento. Los eventos representan cosas que ocurren en un tiempo y lugar determinados. Un diamante representa una decisin (tambin conocida como rama) o una fusin. Las decisiones tienen una flecha que entra en el diamante y varias que salen de l. Se podra incluir una condicin que muestre los valores que puede tomar dicha condicin. Las fusiones muestran varios eventos que se combinan para formar otro evento. Un rectngulo largo y plano representa una barra de sincronizacin. Esta barra se utiliza para representar actividades paralelas, y podra representar un evento entrando a ella y varios eventos saliendo de la misma, lo que se conoce como bifurcacin. Una sincronizacin en la cual varios eventos se fusionan en uno solo se conoce como unin. Hay dos smbolos que muestran el inicio y el final del diagrama. El estado inicial se muestra como un crculo slido. El estado final se muestra como un crculo negro rodeado por un crculo blanco

ANLISIS Y DISEO DE SISTEMAS ORIENTADOS A OBJETOS, USANDO EL LENGUAJE UNIFICADO DE MODELACIN (UML)
New Sw imlane New Sw imlane2

Inicio
Actividad

Carriles

Bifurcacin
Condicin

Actividad

Actividad

Actividad

Fusin

Unin Final

ANLISIS Y DISEO DE SISTEMAS ORIENTADOS A OBJETOS, USANDO EL LENGUAJE UNIFICADO DE MODELACIN (UML)

DIAGRAMAS DE SECUENCIAS Y DE COLABORACIN Un diagrama de interaccin puede ser un diagrama de secuencias o uno de colaboracin, que muestran esencialmente la misma informacin. Estos diagramas, junto con los diagramas de clases, se utilizan en la realizacin de un caso de uso Los diagramas de secuencias pueden ilustrar una sucesin de interacciones entre clases o instancias de objetos en un periodo determinado. Los diagramas de secuencias se utilizan con frecuencia para representar el proceso descrito en los escenarios de caso de uso. En la prctica, los diagramas de secuencias se derivan del anlisis de casos de uso y se emplean en el diseo de sistemas para generar las interacciones, relaciones y mtodos de los objetos del sistema. Las colaboraciones describen las interacciones de dos o ms cosas en el sistema, las cuales desempean en conjunto un comportamiento superior al que puede realizar cualquiera de las cosas por s sola

ANLISIS Y DISEO DE SISTEMAS ORIENTADOS A OBJETOS, USANDO EL LENGUAJE UNIFICADO DE MODELACIN (UML) Diagrama de Secuencia
::Clase Objeto::Clase mtodo(parmetro)
1:

Diagrama de Colaboracin

retorno
::Estudiante 4: ::InterfazUsuario NuevoEstudiante 3:

2: ::Programa

sealAsncrona()

::Dormitorio

ANLISIS Y DISEO DE SISTEMAS ORIENTADOS A OBJETOS, USANDO EL LENGUAJE UNIFICADO DE MODELACIN (UML)

Las metodologas orientadas a objetos se enfocan en descubrir clases, atributos, mtodos y relaciones entre las clases. Puesto que la programacin se realiza al nivel de la clase, la definicin de clases es una de las tareas ms importantes del anlisis orientado a objetos. Los diagramas de clases muestran las caractersticas estticas del sistema y no representan ningn procesamiento en particular. Un diagrama de clases tambin muestra la naturaleza de las relaciones entre las clases