UNIVERSIDAD SALESIANA DE BOLIVIA INGENIERIA DE...

Análisis de Sistemas II Lic. Patricia Palacios Zuleta

UNIVERSIDAD SALESIANA DE BOLIVIA

INGENIERIA DE SISTEMAS

DOSSIER

ANALISIS DE SISTEMAS II

DOCENTE LIC. PATRICIA PALACIOS ZULETA PARALELO A2

I - 2011


INDICE Pag. UNIDAD I Instrumentos para la identificación de un Proyecto Introducción.............................................................................................................................. Identificación de las herramientas de usuario........................................................................... Herramientas y técnicas para análisis del problema y análisis de objetivos............................ Planteamiento del problema central y objetivo general del problema...................................... Factibilidad económica del proyecto......................................................................................... UNIDAD II Lenguaje de Modelo Unificado de Desarrollo Guerra de los métodos............................................................................................................. Surgimiento del UML................................................................................................................ Aceptación del lenguaje y estandarización OMG..................................................................... Metas del UML.......................................................................................................................... Desarrollo del software orientado a objetos............................................................................. Uso del UML............................................................................................................................. UNIDAD III Fase de planeación y elaboración Conocimiento de los requerimientos........................................................................................ Caso de Uso: descripción del proceso.................................................................................... Clasificación y programación de los caso uso.......................................................................... Programación de los casos de uso en desarrollo.................................................................... Inicio de un ciclo de desarrollo................................................................................................ UNIDAD IV Construcción de un modelo conceptual Modelo conceptual................................................................................................................... Estrategias para identificar los conceptos................................................................................ Directrices para construir modelos conceptuales..................................................................... Modelo conceptual agregación de asociaciones...................................................................... Modelo conceptual agregación de los atributos........................................................................ Notación de atributos en UML.................................................................................................. Tipos de atributos no primitivos................................................................................................ Modelado de cantidad de atributos..........................................................................................

1 1 3 7 9

10 12 15 16 18 19

22 23 25 25 25

26 27 28 30 32 32 32 33


UNIDAD V Fase de diseño Como crear un diagrama de clases de diseño........................................................................ Comparación entre el modelo conceptual y los diagramas de diseño..................................... Algunos aspectos del diseño de sistemas............................................................................... Arquitectura clásica de tres capas........................................................................................... Arquitectura multicapa orientada objeto................................................................................... Como mostrar la arquitectura con paquetes UML.................................................................... UNIDAD VI Casos de estudio Requerimientos del sistema.................................................................................................... Análisis de requerimiento......................................................................................................... Análisis..................................................................................................................................... Diseño...................................................................................................................................... Implementación........................................................................................................................ Prueba...................................................................................................................................... Despliegue...............................................................................................................................

LECTURAS COMPLEMENTARIAS ANEXOS BIBLIOGRAFIA

35 35 39 39 39 40

41 44 55 59 63 64 64


I OBJETIVOS DE LA MATERIA

GENERAL

Investigar, analizar y estudiar el Lenguaje de Modelaje Unificado (UML) y aplicarlo en el

Análisis y Diseño de un Sistema de Información

ESPECÍFICOS

Verificar la aplicabilidad y bondades del Lenguaje de Modelaje Unificado para el Análisis y

Diseño de Sistemas.

Proporcionar un material de apoyo didáctico, sobre el cual se puedan basar para la

enseñanza del análisis y diseño orientado a objetos.

Actualizar conocimientos de análisis y diseño de sistemas de la metodología estructurada

y la técnica de modelaje de objetos (OMT) al UML.

Soportar el estudio de la metodología con un caso de estudio realizado utilizando nuestros

Conocimientos sobre UML.

Utilizar la herramienta Rational Rose 98, como ejemplo de una Herramienta de Ingeniería

de Software Asistida por Computadora que soporta el Lenguaje de Modelaje UnificadoM o

otras herramientas.

II COMPETENCIA DE LA MATERIA

El objetivo de la asignatura de Análisis de Sistemas II es formar al alumno en el analizar y

estudiar el Lenguaje de Modelaje Unificado (UML) y aplicarlo en el Análisis y Diseño de un

Sistema de Información de programación Orientado a Objetos.

COMPETENCIAS

Al finalizar el contenido de la materia el estudiante debe estar en capacidad de:

1. Verificar la aplicabilidad del Lenguaje de Modelaje Unificado para el Análisis y

Diseño de Sistemas.

2. Dominar con destreza los conocimientos de análisis y diseño de sistemas de la

metodología estructurada y la técnica de modelaje de objetos (OMT) al UML.

3. Utilizar herramientas de Ingeniería de Software Asistida por Computadora que

soporta el Lenguaje de Modelaje Unificado.

4. Desarrollar el Sistema de Control de Rutas utilizando los gestores de Bases de

datos.


1

Introducción

Vivimos en un mundo de objetos. Estos objetos existen en la naturaleza, en entidades hechas

por el hombre, en los negocios y en los productos que usamos. Pueden ser clasificados,

descritos, organizados, combinados, manipulados y creados. Por esto es sorprendente que se

propagan una visión orientada a objetos. Para la creación de software de computadoras, una

abstracción que modela el mundo de forma tal que nos ayuda a entenderlo y gobernarlo mejor.

Las tecnologías de objetos llevan a reutilizar, y la reutilización (de componentes de software) lleva

a un desarrollo de software más rápido y a programas de mejor Calidad. El software orientado a

objetos es mase fácil de mantener debido a que su estructura es inherentemente poco acoplada.

Estos lleva a menores efectos colaterales cuando se deben hacer cambios y provoca menos

frustración en el ingeniero de software y el cliente. Además los sistemas orientados a objetos son

más fáciles de adaptar y más fácilmente escalables (por ejemplo pueden crearse grandes

sistemas ensamblando subsistemas reutilizables).

Identificación de las herramientas de usuario

Las tecnologías de objetos están influenciadas por la reutilización. Considere un ejemplo simple.

El analista de los requisitos para nuevas aplicaciones indican la necesidad de 100 clases. Se

asigna a dos equipos la tarea de construir la aplicación. Cada uno debe diseñar y construir un

producto final y, a su vez, está compuesto de personas con el mismo nivel de habilidad y

experiencia.

El equipo A no tiene acceso a una biblioteca de clases, por lo que debe desarrollar las 100 clases

desde el principio. El equipo B usa una biblioteca de clases. El equipo B usa biblioteca de clases

robusta y encuentra que ya existen 55 clases. Seguro que.

TEMA I INSTRUMENTOS PARA LA IDENTIFICACIÓN DE UN PROYECTO


2

1. El equipo B finalizar el proyecto mucho antes que el A.

2. El coste del producto del equipo B será significativamente más bajo que el coste del

producto del equipo A.

3. La versión que se distribuya del producto producido por el equipo B tendrá menos

defectos que la del producto del equipo A.

El análisis del dominio del software es la identificación, análisis y especificación de requisitos

comunes del dominio de aplicación especifico, normalmente para su reutilización en múltiples

proyectos dentro del mismo dominio es la identificación, análisis y especificación de capacidades

comunes y reutilizables dentro de un dominio de aplicación especifico, en términos de objetos,

clases, submontajes y marcos de trabajo comunes…

Recolección una muestra representativa de aplicaciones en el dominio.-

Para realizar esta tarea, el analista debe asegurar que la aplicación en cuestión tiene elementos

que caen dentro de las categorías ya definidas. Observar que durante las primeras etapas de uso

de las tecnologías de objetos, hay algunas, aplicaciones OO. Debido a esto, el analista de

dominio debe ¨identificar los objetos conceptuales (opuestos a los físicos) en cada aplicación [no

OO]¨.

Analizar cada aplicación dentro de la muestra.-

El analista debe seguir las etapas siguientes.

Identificar objetos candidatos reutilizables.

Indicar las razones que hacen que el objeto haya sido identificado como reutilizable.

Definir adaptaciones al objeto que también puede ser reutilizable.

Estimar el porcentaje de aplicación en el dominio que pueden reutilizar el objeto.

Identificar los objetos por nombre y usar técnicas de gestión de configuración para

controlarlos.

Además una vez que se han definido los objetos, el analista deben estimar que porcentaje de una

aplicación típica pudiera construirse usando los objetos reutilizable.


3

El modelo de análisis servirá como base para el diseño construcción de los objetos del dominio.

Adicionalmente a esta etapa, el analista del dominio también debe crear un conjunto de líneas

maestras para la reutilización, y desarrollar un ejemplo que ilustre como los objetos del dominio

pidiera usarse para crear una aplicación nueva.

Herramientas Y Técnicas Para El Análisis Del Problema Y Análisis De Objetivo

Diagrama de casos de uso.- El modelo de casos de uso inicia en la fase de Inicio con la

identificación de actores y casos de uso principales del sistema. El modelo es luego madurado en

la fase de Elaboración – se añade información más detallada a los casos de uso identificados, y

casos de uso adicionales son añadidos a medida que se necesiten.

Diagrama de clases.- En el UML la clase en asociación añade una restricción más, la cual es

que solamente puede existir una instancia de la clase en asociación entre dos objetos

participantes. Por ejemplo, en una relación entre las clases Persona y Compañía podría haber

una clase en asociación llamada Empleo que contendría los detalles del período de trabajo,

salario, puesto, etc.

Caso de uso

Actor del sistema

Diagrama de clases


4

Diagrama de estados.- Un diagrama de estados en UML, captura una pequeña realidad.

Diagrama de secuencias.- El diagrama de secuencias UML muestra la mecanica de la

interacción con el tiempo.

Diagrama de estados


5

Un diagrama de secuencias captura la interacción que se realiza a través del tiempo, en este

diagrama el tiempo se da de arriba abajo.

Diagrama de actividades.-

Las actividades que ocurren dentro de un caso de uso o dentro del comportamiento de un objeto

se dan, normalmente, en secuencias, como en los once pasos anteriores. En la figura se muestra

la forma en que el diagrama de actividades UML representa los pasos del 4 al 6 de tal secuencia.

Diagrama de secuencias en UML

Diagrama de actividades


6

Diagramas de colaboración.-

Los elementos de un sistema trabajan en conjunto para cumplir con los objetivos del sistema y un

lenguaje de modelo debera contar con una forma de representar esto. En el siguiente ejemplo

agrega un cronometro interno al conjunto de clases que constituyen a una lavadora. Luego de

cierto tiempo, el cronometro detendra el flujo del agua y el tambor comenzara a girar de un lado a

otro.

Diagrama de componentes.-

El diagrama de componentes esta íntimamente relacionado con el sistema informáticos.

El moderno desarrollo de software se realiza mediante componentes, lo que es particularmente

importante en los procesos de desarrollo en equipo.

Diagrama de distribución.-

El diagrama de distribución UML muestra la arquitectura física de un sistema informático. Puede

representar los equipos y dispositivos, mostrar sus interconexiones y el software que se

encontrara en cada maquina. Cada computadora esta representada por un cubo y las

Diagrama de colaboración

Diagrama de componentes


7

interconexiones entre las computadoras están representadas por líneas que conectan a los

cubos.

Planteamiento del problema central y objetivo general del problema

El UML define una colección de notaciones para los diferentes diagramas y elementos de

modelaje que lo componen; por lo tanto el UML por si mismo no es suficiente para desarrollar un

producto de software; es necesario tener un proceso, una guía de como las actividades

deben ser realizadas y secuenciadas con el fin de obtener un resultado. Para este fin

utilizaremos el Proceso Unificado de Rational (Rational Unified Process); un proceso de

análisis y diseño de sistemas iterativo e incremental, con soporte para el UML y que fue

desarrollado también por Booch, Rumbaugh y Jacobson en Rational Corporation. Sin

embargo, es preciso aclarar desde un inicio que los procesos pueden variar de desarrollador en

desarrollador, de proyecto en proyecto y de empresa en empresa, lo que nosotros estamos

buscando es utilizar un proceso que sirva de guía para dar una idea de cómo el UML debe ser

utilizado en ese contexto.

Un modelo es una descripción de alguna cosa. Esta cosa puede existir, estar en la etapa de

desarrollo, o todavía estar en la etapa de planificación. Durante el trabajo de hacer un

modelo (modelaje), los diseñadores de modelos deben investigar los requerimientos

para el producto terminado. Los requerimientos incluyen áreas tales como

funcionalidad, apariencia, desempeño, y confiabilidad. Los diseñadores deben entonces

crear un modelo que describa todos los diferentes aspectos del producto. El modelo es a

Diagrama de distribución


8

menudo descompuesto en una serie de vistas, cada una de las cuales describe un aspecto

específico del producto o sistema bajo construcción. El modelo puede ir a través de una serie

de fases donde cada fase agrega detalles al modelo.

La creación de modelos es un trabajo altamente creativo. No hay una solución final, no

hay una respuesta correcta que sea chequeada al final del trabajo. Los diseñadores de

modelos, a través del trabajo iterativo, aseguran que sus modelos logren los objetivos y los

requerimientos del proyecto bajo construcción. Pero un modelo no es final; típicamente es

cambiado y actualizado a través de un proyecto para reflejar nuevas percepciones y

experiencias de los diseñadores. Durante el modelaje, las mejores soluciones son a menudo

logradas permitiendo un alto grado de lluvia de ideas durante la cual diferentes soluciones y

vistas son modeladas y probadas. Iterando las diferentes posibilidades, los diseñadores

alcanzan un entendimiento más profundo del sistema, y finalmente pueden crear modelos del

sistema que logren los objetivos y los requerimientos del sistema y sus usuarios.

Los modelos son descritos usualmente en un lenguaje visual, lo cual significa que la mayor

parte de la información en los modelos es expresada por símbolos gráficos y conexiones. El

viejo dicho de que “un dibujo habla por mil palabras” es también relevante en el

modelaje. La utilización de una descripción visual es necesaria para comunicar

relaciones complejas; esto también hace que el modelaje práctico trabaje más fácilmente.

No todo es apropiado para una descripción visual, sin embargo, alguna información en los

modelos es mejor expresada en texto ordinario. Los modelos utilizables son:

Seguros: Describen correctamente el sistema a ser construido.

Consistentes: Las diferentes vistas no expresan cosas que estén en conflictos con otras.

Fáciles de comunicar a otros.

Fáciles de cambiar.

Comprensibles: Tan simple como sea posible, pero no los más simples

Factibilidad económica del proyecto.

Al crear el sistema, ¿los beneficios que se obtienen seran suficiente para aceptar los costos?,

¿los costos asociados con la decisión de no crear el sistemas son tan grandes que se deben

aceptar al proyecto?.


9

Un sistema que puede ser desarrollado des de el punto de vista técnico y que además será

utilizado si se llega a instalar, debe ser una buena inversión para la organización. Los beneficios

financieros deben igualar o exceder a los costos. Las cuestiones económicas y financieras

formuladas por los analistas durante la investigación preliminar, tienen el propósito de estimar lo

siguiente.

El costo de lleva a cabo la investigación completa de sistemas.

El costo de hardware y software para la aplicación que se esta considerando.

Beneficios en la forma de reducción de costos o de menos errores costosos.

El costo sin nada sucede (es decir si el proyecto no se lleva a cabo).

Para ser considerado como factible, la propuesta debe pasar todas las pruebas. De lo contrario,

el proyecto no es factible. Por ejemplo, un sistema de registro de personal que sea factible desde

el punto de vista financiero y operacionalmente activo, no es factible si la tecnología necesaria

para su desarrollo aún no existe. Un sistema médico que se puede desarrollar con costos

razonables pero que las enfermeras evitaran por cualquier medio no puede ser juzgado como

operacionalmente factible.


10

La Guerra de los Métodos.-

El Análisis y Diseño Estructurado fue tal vez la primera familia de métodos de desarrollo de

software que fue usada ampliamente. Formalizado durante el inicio de los 70s por Ed Yourdon,

Tom DeMarco, Larry Constantine, Cris Gane, y otros, este método fue muy útil para una amplia

variedad de problemas.Sin embargo, bajo los estándares actuales, los problemas para los cuales

el Análisis y Diseño Estructurado era aplicado son muy simples y de poco alcance. La experiencia

con sistemas más grandes y complejos descubrió limitaciones en este método, particularmente

cuando se desarrollan sistemas con requerimientos inestables. La aparición de lenguajes

basados en objetos y orientados a objetos como Smalltalk, C++ y Ada también descubrió

problemas: el Análisis y Diseño Estructurado era más aplicable a los lenguajes estructurados

como FORTRAN y COBOL.

Hacia finales de la década de los 80s, los lenguajes y procesos se estaban moviendo al

paradigma orientado a objetos. En general las técnicas orientadas a objetos resolvían los

problemas de administración de la complejidad, y eran mucho más apropiados para un proceso

de desarrollo iterativo. Una característica clave de todos los métodos orientados a objetos que

emergieron en esa época fue su enfoque en modelar el vocabulario del problema y el espacio de

la solución en una forma que proporciona un plano más exacto para la construcción del software

y que más exactamente capturara las necesidades reales de los usuarios. El número de métodos

orientados a objetos se incrementó de menos de 10 a más de 50 durante el período entre 1989 y

1994. Muchos usuarios de estos métodos tenían problemas encontrando uno que llenara sus

necesidades completamente, creando así la llamada “guerra de los métodos.” Uno de los

conceptos iniciales detrás del UML era ponerle fin a esta “guerra de los métodos” dentro de la

comunidad orientada a objetos. Aprendiendo de esta experiencia, comenzaron a aparecer nuevas

generaciones de los métodos con unos cuantos métodos emergentes, más notablemente los

siguientes:

. Booch: El método de Grady Booch para el desarrollo orientado a objetos está disponible en una

serie de versiones. Booch definió la noción de que un sistema es analizado en una serie de

TEMA II PRINCIPIOS DE PROGRAMACIÓN ORIENTADA A OBJETOS CON

C++ Y JAVA


11

vistas, donde cada vista es descrita por una serie de diagramas de modelo. La notación del

método de Booch era muy extensiva, y algunos usuarios encontraron algunos de los símbolos

(las infames nubes) muy difíciles de dibujar manualmente. El método también contenía un

proceso por el cual el sistema era analizado por una vista de desarrollo macro y una vista de

desarrollo micro, y estaba basado en un proceso altamente incremental e iterativo.

OMT: La Técnica de Modelaje de Objetos (OMT: Object Modeling Technique) es un

método desarrollado en General Electric donde James Rumbaugh trabajaba previamente.

Es por ello un proceso directamente para pruebas, basado en la especificación de

requerimientos. El sistema es descrito por una serie de modelos: el modelo de objetos, del

modelo dinámico y el modelo funcional, los cuales se complementan unos con los otros

para dar una descripción del sistema. El método OMT también contenía muchas

descripciones prácticas de como hacer el diseño de un sistema, tomando en cuenta la

concurrencia y el mapeo a las bases de datos relacionales.

OOSE/Objectory: Los métodos OOSE y el Objectory fueron construidos desde el mismo

punto de vista básico formado por Ivar Jacobson. El método OOSE es la visión de Ivar

Jacobson de un método orientado a objetos; el método Objectory es utilizado para

construir una serie de sistemas, tan diversos como sistemas de telecomunicaciones para

Ericsson y sistemas financieros para compañías de Wall Street. Ambos métodos están

basados en los casos de uso, los cuales definen los requerimientos iniciales de un sistema

como es visto por un actor externo. Los casos de uso luego son implementados en todas

las fases del desarrollo, con todas las pruebas del sistema, donde ellos son utilizados para

verificar el sistema. El Objectory ha sido también adaptado para la ingeniería del negocio,

donde las ideas son utilizadas para modelar y mejorar los procesos del negocio.

Fusion: El método Fusion viene de Hewlett-Packard. Es llamado un método de segunda

generación, porque está basado en las experiencias de muchos de los métodos iniciales.

El método Fusion ha extendido una serie de ideas previas importantes, incluyendo

técnicas para la especificación de operaciones e interacciones entre los objetos. El

método tiene un número grande de diagramas de modelos.

Coad/Yourdon: El método de Coad/Yourdon, también conocido como OOA/OOD, fue uno

de los primeros métodos utilizados para el análisis y el diseño orientado a objetos. El

método es algo simple y fácil de aprender, y como tal, trabaja bien para introducir a los

principiantes a las ideas y la terminología de la tecnología orientada a objetos. Sin


12

embargo, la notación del método no puede escalar para controlar cualquier cosa más que

sistemas muy limitados. Consecuentemente, el método es raras veces utilizado hoy día.

Cada uno de estos métodos tenía su propia notación (los símbolos utilizados para dibujar los

modelos orientados a objetos), proceso (qué actividades realizar en las diferentes partes del

desarrollo), y herramientas (las herramientas CASE que soporten la notación y los procesos).

Esto hacía la elección del método una decisión muy importante, y a menudo conllevaba a fuertes

discusiones y debates acerca de cuál método era “el mejor,” “el más avanzado,” y “el correcto”

para utilizar en un proyecto específico. En tales discusiones raras veces había una buena

respuesta, porque todos los métodos tenían sus propias fortalezas y debilidades. Los

desarrolladores experimentados a menudo tomaban un método como una base, y luego

prestaban buenas ideas y soluciones de otros. En la práctica, las diferencias entre los métodos no

eran realmente tan significativas, y a medida que pasaba el tiempo y los métodos fueron

desarrollados llegaron a parecerse unos a otros. Esto fue reconocido por varios de

los expertos, los cuales comenzaron a buscar formas de cooperar.

Surgimiento del UML.-

El trabajo en el UML comenzó oficialmente en Octubre de 1994 cuando Rumbaugh se unió a

Booch en Rational. Su objetivo era el de crear un nuevo método, el “Método Unificado,” que uniría

el método de Booch y el método OMT-2. La versión 0.8 del Método Unificado fue liberada en

Octubre de 1995.

Alrededor de la misma fecha Ivar Jacobson – el hombre detrás de los métodos OOSE y Objectory

se unió a ellos y el alcance del UML fue expandido para incorporar OOSE. Rational Software

también compró Objective Systems, la empresa sueca que desarrolló y distribuyó el Objectory.

En este momento, los futuros desarrolladores del UML también se dieron cuenta que su trabajo

estaba dirigido más directamente hacia la creación de un lenguaje de modelaje estándar, y

renombraron su trabajo como “Lenguaje de Modelaje Unificado.” Tener éxito en el

establecimiento de un lenguaje de modelaje estándar era una tarea más simple que hacer la

misma cosa para un proceso, debido a que el proceso difiere sustancialmente entre las diferentes

compañías y culturas. Es dudoso, si del todo posible, crear un proceso estándar que pueda ser

utilizado por todos.


13

Como autores primarios de los métodos Booch, OMT y OOSE, Grady Booch, Jim Rumbaugh e

Ivar Jacobson estaban motivados a crear un lenguaje unificado por tres razones:

¿Qué es el UML?

1. Estos métodos estaban evolucionando claramente hacia cada uno independientemente.

Era lógico seguir la evolución juntos en vez de separados, eliminando el potencial de

diferencias innecesarias que confundirían a los usuarios.

2. Al unificar la semántica y notación, podrían traer cierta estabilidad al mercado orientado a

objetos, permitiendo que los proyectos se asentaran en un lenguaje de modelaje maduro y

permitiendo a los constructores de herramientas enforcarse en producir características

más útiles.

3. Esperaban que su colaboración traería mejoras sobre sus métodos anteriores,

ayudándoles a capturar lecciones aprendidas y solucionar problemas que ninguno de sus

métodos previamente manejaba bien.

Los esfuerzos de Booch, Rumbaugh y Jacobson resultaron en la liberación del UML 0.9 en Junio

de 1996 y 0.91 en Octubre de 1996. Durante 1996, una serie de organizaciones se unieron a

Rational para formar el consorcio de los socios del UML. Estas organizaciones consideraban al

UML como estratégico para sus negocios y contribuyeron con la definición del UML.

Naturalmente, estaban interesadas en tener sus propias áreas de experiencia dentro de la

definición. Estas compañías fueron:

Digital Equipment Corporation, HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse,

Microsoft, Oracle, Texas Instruments, Unisys, y por supuesto Rational.

La retroalimentación de la comunidad de ingeniería de software y de los socios del UML les dio

muchas ideas y sugerencias a incorporar para mejorar el lenguaje. La versión 1.0 del UML salió

en Enero de 1997.

Rational hizo también un arreglo con Microsoft estableciendo que las compañías desarrollarán en

conjunto el mercado de las herramientas de desarrollo empresarial. Esto quiere decir que


14

intercambiarían licencias de tecnologías, de manera que sus productos se integrarán fácilmente

los unos con los otros. Por ejemplo, Rational Rose será una herramienta CASE integrada de la

parte más alta a la parte más baja de los ambientes tales como Microsoft Visual C++ o Visual

Basic. Las compañías codesarrollarán y comercializarán sus soluciones integradas. Rational ha

adquirido Microsoft Visual Test para ampliar sus productos base para soportar otros ambientes

para el proceso de ingeniería del software.

A pesar de que las partes principales del UML están basadas en los métodos de Booch, OMT y

OOSE, estos diseñadores también incluyeron conceptos de otros métodos. Por ejemplo, el

trabajo de David Harel en los diagramas de estado ha sido adoptado en los diagramas de estado

del UML; partes de la notación del método de Fusión para la numeración de las operaciones ha

sido incluida en los diagramas de colaboración; y el trabajo de Gamma-Helm-Johson-Vlissides

sobre los patrones y cómo documentarlos ha inspirado detalles en los diagramas de clases.

Los objetivos del UML, como fueron establecidos por los diseñadores, son:

Modelar sistemas (y no solo software) utilizando conceptos orientados a objetos.

Establecer un acoplamiento explícito tanto a los artefactos conceptuales como los

ejecutables.

Resolver los problemas de escala inherente en sistemas complejos de misión crítica.

Crear un lenguaje de modelaje utilizable por los humanos y las máquinas.

El UML está destinado a ser dominante, el lenguaje de modelaje común utilizado en la industria.

Tiene un amplio rango de uso, está construido sobre técnicas bien establecidas y probadas para

el modelaje de sistemas. Tiene el soporte para la industria necesario para establecer un estándar

en el mundo real.

El UML está bien documentado con metamodelos (un modelo de los elementos del modelo) del

lenguaje, y con una especificación formal de la semántica del lenguaje.

Aceptación del Lenguaje y Estandarización OMG.-

Para establecer el UML, los desarrolladores y Rational se dieron cuenta que el lenguaje tenía que

estar disponible para cualquiera. Por consiguiente, el lenguaje no tiene un propietario y está


15

abierto para todos. Las compañías son libres de utilizarlo con sus propios métodos; los

vendedores de herramientas son libres para crear herramientas CASE para él; y los autores son

motivados a escribir libros sobre él.

Cuando comenzó el trabajo con el UML, éste estaba orientado a establecerse por sí mismo como

el estándar de facto, lo cual significa que a través del uso práctico de muchos desarrolladores se

volvería reconocido como el primer lenguaje de modelaje. Sin embargo cuando el OMG hizo una

petición de un lenguaje de modelaje estándar, los desarrolladores del UML se dieron cuenta que

ellos podrían hacer del UML el estándar aceptado. Esto impuso una mayor demanda de una

definición formal y precisa del UML y mejoró la calidad del lenguaje. Una estandarización formal

es importante para muchas industrias antes de que sean capaces de utilizar una nueva

tecnología, tal como los desarrolladores de los sistemas militares.

En respuesta a la petición de propuestas del OMG, se ofreció el UML 1.0 para su estandarización

en Enero de 1997. Entre Enero y Julio de 1997 el grupo original de socios fue expandido para

incluir virtualmente todos los otros colaboradores y contribuidores de la respuesta original del

OMG, incluyendo Andersen Consulting, Ericsson, ObjecTime Limited, Platinum Technology,

PTech, Reicht Technologies, Softeam, Sterling Software, y Taskon.

Una fuerza de semántica fue formada, dirigida por Cris Kobryn de MCI Systemhouse y

administrada por Ed Edykholt de Rational, para formalizar la especificación del UML y para

integrar el UML con otros esfuerzos de estandarización. La versión revisada UML 1.1 fue ofrecida

al OMG para estandarización en Julio de 1997. En Septiembre de 1997 esta versión fue aceptada

por la Fuerza de Trabajo de Análisis y Diseño del OMG y la Junta de Arquitectura del OMG, y

después de votos por todos los miembros del OMG fue aceptada el 14 de Noviembre de 1997.


16

Metas del UML

Las metas

primarias

en el diseño del

UML fueron:

1. Proporcionar a los usuarios un lenguaje de modelaje visual listo para usarse y expresivo

de tal forma que permita desarrollar e intercambiar modelos con significado. Es importante

que el estándar de análisis y diseño orientado a objetos soporte un lenguaje de modelaje

que pueda ser usado inmediatamente para realizar tareas de modelaje normales y de

propósito general. El UML consolida una conjunto de conceptos principales de modelaje

que son aceptados por muchos métodos actuales y herramientas de modelaje. Estos

conceptos son necesarios en muchas aplicaciones grandes, aunque no todos los

conceptos son necesarios en todas las partes de la aplicación.

2. Proporcionar mecanismos de extensibilidad y especialización para extender los conceptos

centrales. Se espera que el UML sea ajustado a medida que nuevas necesidades sean

descubiertas para nuevos dominios. Al mismo tiempo, no se quiere forzar la redefinición o

reimplementación de los conceptos centrales para cada necesidad. Por lo tanto, se cree

que el mecanismo de extensión debería soportar desviaciones del caso común, en vez de

que se requiera que se implementen los conceptos centrales del análisis y diseño

orientado a objetos. Los conceptos centrales no deben ser cambiados más de lo

necesario. Los usuarios necesitan ser capaces de: 1) construir modelos usando los

conceptos centrales sin mecanismos de extensión para la mayoría de las aplicaciones

normales; 2) añadir nuevos conceptos y notaciones para problemas no resueltos por la

parte central; 3) escoger entre interpretaciones variadas de los conceptos existentes,


17

cuando no hay un consenso claro; y 4) especializar los conceptos, notaciones, y

restricciones para dominios particulares de aplicación.

3. Ser independiente de lenguajes de programación particulares y procesos de desarrollo. El

UML debe y puede soportar todos los lenguajes de programación razonables. También

debe y puede soportar todos los métodos y procesos de construir modelos. El UML puede

soportar múltiples lenguajes de programación y métodos de desarrollo sin dificultad

excesiva.

4. Proporcionar una base formal para entender el lenguaje de modelaje. Debido a que los

usuarios usarán la formalidad para ayudarse a entender el lenguaje, éste debe ser preciso

y aproximable; una falta de cualquiera de estas dos dimensiones dañaría su utilidad.

5. Incentivar el crecimiento del mercado de herramientas orientadas a objetos. Al permitir a

los vendedores soportar un lenguaje de modelaje estándar usado por la mayoría de

usuarios y herramientas la industria se beneficia. Aunque los vendedores pueden añadir

más valor a sus implementaciones de herramientas, permitir la interoperabilidad es

esencial. La interoperabilidad requiere que los modelos sean intercambiables entre

usuarios y herramientas sin pérdida de información. Esto puede ocurrir solamente si las

herramientas acuerdan el formato y significado de todos los conceptos relevantes.

Soportar conceptos de desarrollo de más alto nivel tales como colaboraciones,

estructuras, patrones y componentes. Una semántica claramente definida de estos

conceptos es esencial para cosechar el completo beneficio de la orientación a objetos y la

reutilización. Su definición dentro del contexto de un lenguaje de modelaje es una

contribución única del UML.

6. Integrar las mejores prácticas en la industria. Una motivación clave detrás del desarrollo

del UML ha sido integrar las mejores prácticas en la industria, cubriendo vistas amplias

basadas en niveles de abstracción, dominios, arquitecturas, etapas de ciclo de vida,

tecnologías de implementación, etc. El UML es de hecho una integración de las mejores

prácticas.


18

Desarrollo de Software Orientado a Objetos.-

Como un lenguaje de modelaje orientado a objetos, todos los elementos y diagramas en el UML

están basados en el paradigma de la orientación a objetos. Las definiciones de los conceptos

orientados a objetos son realizadas. Cualquier lector totalmente no familiar con la orientación a

objetos y su terminología debería leer algún texto introductoria. Las vistas primarias de los

autores en la orientación a objetos son:

La orientación a objetos es una tecnología para producir modelos que reflejen un dominio,

tal como un dominio de negocio o un dominio de una máquina, de manera natural

utilizando la terminología del dominio.

Los modelos orientados a objetos, cuando son construidos correctamente son fáciles de

comunicar, cambiar, expandir, validar, y verificar.

Cuando son hechos correctamente, los sistemas construidos utilizando tecnología

orientada a objetos son flexibles de cambiar, tienen arquitecturas bien definidas, y

proporcionan la oportunidad de crear e implementar componentes reutilizables. Los

requerimientos del sistema son fáciles de convertir en código en el sistema.

Los modelos orientados a objetos son implementados convenientemente en software

utilizando lenguajes de programación orientados a objetos. La utilización de lenguajes de

programación que no son orientados a objetos para implementar sistemas orientados a

objetos no es recomendada. Sin embargo es importante darse cuenta que la ingeniería del

software orientada a objetos es mucho más que un par de mecanismos en un lenguaje de

programación.

La orientación a objetos no es solamente una teoría, sino una tecnología bien probada

utilizada en una serie de proyectos y para la construcción de muchos tipos diferentes de

sistemas. El campo todavía carece de estandarización para mostrar el camino para una

industrialización de la tecnología de objetos.

La orientación a objetos requiere un método que integre un proceso de desarrollo y un

lenguaje de programación con técnicas de programación apropiadas y herramientas.


19

Uso del UML.-

El UML es utilizado para modelar sistemas, cuyo rango es muy amplio: muchos tipos diferentes

de sistemas pueden ser descritos. El UML puede ser utilizado también en las diferentes fases del

desarrollo de un sistema, desde la especificación de los requerimientos hasta la prueba del

sistema terminado.

Diferentes tipos de sistemas.-

El objetivo del UML es describir cualquier tipo de sistema, en términos de diagramas orientados a

objetos. Naturalmente, el uso más común es crear modelos de sistemas de software, pero el UML

también es utilizado para describir sistemas mecánicos sin ningún software o la organización de

un negocio. Aquí hay algunos tipos diferentes de sistemas y sus características más comunes.

Sistemas de Información: Almacenan, recuperan, transforman y presentan información a los

usuarios. Manejan grandes cantidades de datos con relaciones complejas, los cuales son

almacenados en bases de datos relacionales o de objetos.

Sistemas Técnicos: Mantienen y controlan equipo técnico tal como procesos de

Telecomunicaciones, procesos de sistemas militares o procesos industriales. Deben

mantener las interfaces especiales del equipo y tienen menos software que los sistemas

de información. Los sistemas técnicos son a menudo sistemas de tiempo real.

Sistemas de Tiempo Real Empotrados: Se ejecutan en un hardware simple empotrado en

cualquier otro equipo tal como un teléfono móvil, un carro, un utensilio del hogar, etc. Esto

es llevado a cabo a través de programación de bajo nivel que requiere soporte de tiempo

real. Estos sistemas a menudo carecen de dispositivos tales como pantalla, disco duro,

etc.

Sistemas Distribuidos: Distribuidos en una serie de máquinas donde los datos son

transferidos fácilmente de una máquina a otra. Requieren de mecanismos de

comunicación sincronizada para asegurar la integridad de los datos y son construidos a

menudo sobre mecanismos de objetos tales como CORBA, COM/DCOM, o Java

Beans/RMI.


20

Software de Sistemas: Definen la infraestructura técnica que utiliza otro software. Los

sistemas operativos, bases de datos, e interfaces de usuario realizan operaciones de bajo

nivel en el hardware, mientras presentan interfaces genéricas para ser utilizadas por otro

software.

Sistemas de Negocios: Describen los objetivos, los recursos (humanos, computadoras,

etc.), las reglas (leyes, estrategias del negocio, políticas, etc.), y el trabajo actual en el

negocio (procesos del negocio).

Es importante enfatizar que la mayoría de los sistemas no encajan limpiamente en una de estas

categorías, pero pertenecen a más de uno de los tipos de sistemas o como una combinación. Por

ejemplo, muchos de los sistemas de información de hoy tienen requerimientos distribuidos y de

tiempo real. El UML tiene la capacidad de modelar todos estos tipos de sistemas. Sistemas de

Información: Almacenan, recuperan, transforman y presentan información a los usuarios. Manejan

grandes cantidades de datos con relaciones complejas, los cuales son almacenados en bases de

datos relacionales o de objetos.

Sistemas Técnicos: Mantienen y controlan equipo técnico tal como procesos de

telecomunicaciones, procesos de sistemas militares o procesos industriales. Deben

mantener las interfaces especiales del equipo y tienen menos software que los sistemas

de información. Los sistemas técnicos son a menudo sistemas de tiempo real.

Sistemas de Tiempo Real Empotrados: Se ejecutan en un hardware simple empotrado en

cualquier otro equipo tal como un teléfono móvil, un carro, un utensilio del hogar, etc. Esto

es llevado a cabo a través de programación de bajo nivel que requiere soporte de tiempo

real. Estos sistemas a menudo carecen de dispositivos tales como pantalla, disco duro,

etc.

Sistemas Distribuidos: Distribuidos en una serie de máquinas donde los datos son

transferidos fácilmente de una máquina a otra. Requieren de mecanismos de

comunicación sincronizada para asegurar la integridad de los datos y son construidos a

menudo sobre mecanismos de objetos tales como CORBA, COM/DCOM, o Java

Beans/RMI.

Software de Sistemas: Definen la infraestructura técnica que utiliza otro software. Los

sistemas operativos, bases de datos, e interfaces de usuario realizan operaciones de bajo


21

nivel en el hardware, mientras presentan interfaces genéricas para ser utilizadas por otro

software.

Sistemas de Negocios: Describen los objetivos, los recursos (humanos, computadoras,

etc.), las reglas (leyes, estrategias del negocio, políticas, etc.), y el trabajo actual en el

negocio (procesos del negocio).

Es importante enfatizar que la mayoría de los sistemas no encajan limpiamente en una de estas

categorías, pero pertenecen a más de uno de los tipos de sistemas o como una combinación. Por

ejemplo, muchos de los sistemas de información de hoy tienen requerimientos distribuidos y de

tiempo real. El UML tiene la capacidad de modelar todos estos tipos de sistemas.


22

Conocimientos de los requerimientos.-

Un proyecto no puede ser exitoso sin una especificación correcta y exhaustiva de los

requerimientos.

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 claramente se lo comunique al cliente y a los miembros

del equipo de desarrollo.

Se recomiendan los siguientes artefactos en la fase de requerimientos:

Panorama general

Clientes

Metas

Funciones del sistema

Atributos del sistema

Presentación general este proyecto tiene por objeto crear un sistema de Terminal para el punto

de venta que se utilizara en las ventas al menudeo.

Clientes.- se refiere a las empresas con las que trabajamos.

Metas.- en términos generales la meta es una mayor automatización del pago en las cajas

registradoras mas correctamente la menta incluye: pago rápido de los clientes, análisis rápido

y exacto de las ventas y control automático del inventario.

TEMA III FASE DE PLANEACION Y ELABORACION


23

Funciones del sistema.- Las funciones del sistema son lo que se habrá de hacer por

ejemplo pagos a crédito.

Con el objetivo de verificar de algún X es de verdad una función del sistema, la siguiente oración deberá tener

sentido “El sistema deberá hacer X”.

Atributos del sistema.- Son cualidades no funcionales.

Categoría de las funciones Las funciones como autorizar pagos a crédito, han de de clasificarse a

fin de establecer prioridades entre ellas e identificar las que de lo contrario pasarían inadvertidas.

Las categorías son:

Funciones básicas

Funciones de pago

Atributos del sistema.- Los atributos del sistema pueden abarcar todas las funciones (por

ejemplo, la plataforma del sistema operativo) o ser específicos de una función o de un grupo de

funciones existen dos tipos de atributos:

Detalles de atributos (Son valores discretos confusos o simbólicos)

Restricción de frontera del atributo (Son condiciones obligatorias de frontera,

generalmente en un rango numérico de los valores de un atributo).

Atributos del sistema en las especificaciones de funciones.-

Conviene describir todos los atributos del sistema que se relacionen claramente con las funciones

dentro de la lista en que se especifican estas últimas. Además, los detalles de los atributos y las

restricciones de frontera pueden catalogarse como obligatorias u opcionales.

Casos de uso: descripción del proceso.-

El caso de uso es un documento narrativo que describe las secuencia de eventos de un actor

(Agente externo) que utiliza un sistemas para completar un proceso.

Existen dos tipos de casos de uso


24

Compra Productos

TPDV

Registra los productos

Entrega el cambio de losproductos comprados

cajeroCliente

Figura; Caso de uso y actores cuando el sistema TPDV es la frontera

Caso de uso de alto nivel

Caso de uso expandido (muestra más detalles que de uno de alto nivel este tipo de casos

suelen ser útiles para alcanzar un conocimiento mas profundo de los procesos y de los

requerimientos).

Diagramas de casos de uso.-

Un diagrama de caso de uso explica gráficamente un conjunto de casos de uso de un sistema los

actores y las relaciones entre estos y los casos de uso. estos últimos muestran en óvalos y los

actores son figuras estilizadas. Hay líneas de comunicaciones entre los casos y los actores y las

flechas indican el flujo de la información.

Los sistemas y sus fronteras.-

Un caso de uso describe la interacción con un sistema. Las fronteras ordinarias del sistema son:

La frontera hardware/ software de un dispositivo.

El departamento de una organización.

La organización entera.

Ejemplo:


25

Clasificación y programación de caso de uso.-

Una vez que se estudia la clasificación y la programación de los casos de uso, estaremos listos

para comenzar el primer ciclo de desarrollo.

Programación de los casos de uso en los ciclos de desarrollo

Los ciclos de desarrollo se organizan en torno a los requerimientos de los casos de uso. En

otras palabras se asigna un ciclo para implementar uno o mas casos de uso o sus versiones

simplificadas cuando el caso de uso integro resulta demasiado complejo para abordarlo en un

ciclo.

Clasificación de los casos de uso.-

Es necesario clasificar los casos de uso y los casos de alto rango han de tratarse al inicio de los

ciclos de desarrollo, el esquema taxonómico puede servirse de una clasificación simple y poco

rigurosa. Alto – medio - bajo.

Inicio del ciclo de desarrollo.-

Suponga que la fase de planeacion y elaboración ha concluido y que los casos de uso han sido

identificados clasificado y programado, pro lo menos en la primera pareja de ciclos. Entonces se

inicia la fase de análisis, en el cual se investiga a fondo los problemas del ciclo actual. En esta

fase una de las primeras actividades cosiste en desarrollar un modelo conceptual tema que se

vera en el siguiente capitulo.


26

Modelo conceptual.-

El paso esencial de un análisis o investigación orientado a objetos es descomponer el problema

en conceptos u objetos individuales: las cosas que sabemos. Un modelo conceptual es una

representación de conceptos en un dominio del problema. En el UML, lo ilustramos con un grupo

de diagramas de estructura estática donde no se define ninguna operación. La designación

conceptual ofrece la ventaja de subrayar fuertemente una concentración en los conceptos del

dominio, no en las entidades del software. Nos muestra:

Conceptos

Asociaciones entre conceptos

Atributos de conceptos

Por ejemplo si vemos un modelo conceptual parcial del dominio de la tienda y las ventas .Se

explica gráficamente que el concepto de Pago y Venta son importantes en este dominio del

problema, que Pago se relaciona con venta en una forma que conviene señalar y que venta tiene

fecha y hora.

Conceptos.-

En términos informales el concepto es una idea, cosa u objeto. Más formal, podemos considerarlo

a partir de su símbolo, intención y extensión.

Símbolo; palabras o imágenes que representan un concepto

Intención; en oposición a extensión, designa el grado de una cualidad

Extensión; el conjunto de ejemplos a que se aplica el concepto.

Consideremos, el concepto del evento de una transacción de compra. Podemos optar por

asignarlo con el símbolo venta. La intención de una Venta puede afirmar que “representa el

evento de una transacción de compra y tiene fecha y hora”. La extensión de la venta son todos

los ejemplos de venta; en otras palabras, el conjunto de todas las ventas.

TEMA IV

CONSTRUCCIÓN DE UN MODELO CONCEPTUAL


27

Ejemplo:

Figura: modelo conceptual parcial

Estrategias para identificar los conceptos.-

Se crea un modelo conceptual de conceptos interesantes o significativos del dominio en cuestión.

Se propone dos estrategias:

Obtención de conceptos a partir de una lista de categorías de conceptos.-

Un modelo conceptual se comienza preparando una lista de conceptos idóneos a partir de la

siguiente lista. Contiene muchas categorías comunes, sin orden de importancia. Los ejemplos se

tomaron de los dominios de la tienda.

Una distinción entre el análisis orientado a objetos y el estructurado: división por conceptos (objetos) y no por funciones.

Producto

Tienda

direccionnombre

pago

monto

TPDV

contenida-en

Registra-venta-de

ventasLineadeProductos

cantidad

venta

fechahora

almacenado-en

aloja

capturada-en

pagada-por


28

Categoría del concepto Ejemplos

Objetos físicos TPDV

Especificaciones ,diseñó o

descripciones de cosas

Especificación del producto

Lugares Tienda

Transacciones Venta

Reglon de elemento de transacciones VentasLineaDeProducto

Papel de las personas Cajero

............................ .......................

...................................................... .............................................................

Obtención de conceptos a partir de la identificación de las frases nominales.-

Consiste en identificar las frases nominales en las descripciones textuales del dominio de un

problema y considerarlas conceptos o atributos idóneos.

Los casos expandidos de uso son una excelente descripción que puede conseguirse con este

análisis. Por ejemplo en el caso de uso Comprar productos, dado en el primer capitulo:

Acción de los actores Respuesta

1. este caso de uso comienza cuando un cliente

llega a una caja de TPDV con productos que

desea comprar.

2. el cajero registra el código universal de

productos (CUP) en cada producto.

3. determinar el precio del producto y a la

transacción de ventas le agrega la

información sobre el producto.

Podemos ver que de las frases nominales subrayadas algunos son conceptos idóneos.

Directrices para construir modelos conceptuales.-

como construir un modelo conceptual.-

Aplique los siguientes pasos para crear un modelo conceptual:

1. liste los conceptos idóneos usando la lista de categorías de conceptos y la identificación de la

frase nominal relacionada con los requerimientos en cuestión.


29

Ejemplo:

TPDV

Producto

Tienda

Venta

Pago

Cajero

Cliente

EspecificacióndeProducto

CatalogodeProductos

2. dibújelos en un modelo conceptual.

Ejemplo:

3. incorporar las asociaciones necesarias para registrar las relaciones para las cuales debe

reservar un espacio en la memoria (tema que se vera en el capitulo posterior).

4. agregue los atributos necesarios para cumplir con las necesidades de información (tema que

se vera en el capitulo posterior).

la asignación de nombres y el modelado de las cosas: cartógrafo.-

La estrategia del cartógrafo se aplica a los mapas y a los modelos conceptuales:

un error que se comete frecuentemente al identificar los conceptos.-

Tal vez el error mas frecuente cuando se crea un modelo conceptual es el representar algo como

atributo, cuando debió haber sido un concepto. Una regla practica para no caer en el es:

TPDV Producto Tienda Venta

Cliente

utilice los nombres existentes en el territorio.

excluya las características irrelevantes.

no agregue cosas que no existan.


30

Ejemplo: Debería destino ser un atributo de vuelo o un concepto aparte aeropuerto?

Dominio: reservaciones en líneas aéreas.

Modelo conceptual agregación de asociaciones.-

Es necesario identificar las asociaciones de los conceptos que se requieren para satisfacer los

requerimientos de información de los casos de uso en cuestión y los que contribuyen a entender

el modelo conceptual.

Criterios de la asociaciones útiles.-

Las asociaciones en UML son “relaciones estructuradas entre los objetos de diversos tipos “.

Notación de las asociaciones.-

Una asociación se representa como línea entre conceptos con el nombre de las asociación. Esta

intrínsecamente by direccional, o seas posible un anexo lógico entre los objetos de un tipo y los

del otro.

Si un mundo real no consideramos algún concepto X como número o texto, probablemente X sea un concepto y no un atributo.

Examine la convencía de incluir las siguientes asociaciones en un modelo

conceptual:

Las asociaciones en que el conocimiento de las relaciones ha de ser

preservado durante algún tiempo.

Las asociaciones provenientes de las Lista de asociaciones comunes.

vuelo

destino

vuelo aeropuerto

nombreo...... ..... ..?


31

Comience

a agregar

las

asociaciones atizando una lista anexa, tomados del dominio en cuestión:

A es una parte física o lógica de B

A esta física o lógicamente contenido en B.

A esta registrado en B.

Multiplicidad.-

La multiplicidad define cuantas instancias de un tipo A pueden asociarse a una instancia del tipo

B en determinado momento.

Modelo conceptual agregación de los atributos.-

Es necesario identificar los atributos de los conceptos que se necesitan para satisfacer los

requerimientos de información de los casos de uso en cuestión.

producto

multiplicidad del pape

1 1..*tienda

almacena

figura: mult iplicidad en una asociacion .

venta actual1

nombre dela asociacion

multiplicidad

"f lecha de direccion de la lectura "

1TPDV

registra

figura: notacion de las asociaciones en el lenguaje UML.


32

Atributos

VentaVenta

Fecha:Horadelinicio:

Figura: Concepto y atributos

Un atributo es un valor lógico de un dato de un objeto.

Notación de atributos en UML.-

Los atributos se mostraran en el capitulo siguiente pero se deben incluir los siguientes atributos

en un modelo conceptual: aquellos en que los requerimientos indican o conllevan la necesidad d

recordar información.

Ejemplo:

Tipos de atributos no primitivos.-

En el modelo conceptual el tipo de un atributo puede expresarse como no primitivo por si mismo.

Aplique la siguiente directriz:

Represente como tipo no primitivo lo que inicialmente puede considerarse un tipo primitivo de

datos, si:

Se compone de secciones independientes.

Normalmente se asocian a las operaciones como el análisis o la validación.

Pose otros atributos

Es una cantidad con una unidad.


33

Especificaciondel producto

CUP Tienda Direccion* 1 * 1

Especificacionde producto

cup: CUP

Tienda

direccion: Direccion

Figura: Si el tipo de atributo es un valor puro de datos puede mostrarse en la seccion de atributos

Ejemplo

En el sistema del punto de venta hay un código del punto universal de producto (CUP),

Dirección y cantidad.

Modelado de cantidad de atributos.-

En términos informales el importe de un pago puede ser representado como un numero. Pero,

en general, este no es un esquema robusto ni flexible porque las unidades de un número a

menudo son importantes. Considere:

Moneda,

Velocidad.

Suponiendo que el software de un punto de venta este destinado al mercado internacional,

abría que conocer la unidad monetaria de los pagos.

La solución consiste en representar cantidad como un concepto distinto, con una unidad

asociada y como se supone las cantidades son valores puros de datos, es aceptable limitarse

a presentarlas en la sección de la casilla destinada a los tipos.

Ejemplo:


34

Pago

monto:Numero ut ilizable,pero noflexible ni robusto

Pago Cantidad

monto:Numero

Unidad

Pago

monto:Cantidadlas cant idades son valorespuros de datos, adecuados

por eso para mostrarlosen la seccion de atributos

mejor

* *1 1

tiene cantidad Esta_en

figura :Modelado de cantidades


35

Como crear un diagrama de clases.-

Aplique las siguientes estrategias para construir un diagrama de clases de diseño.

1. Identifique todas las clases que participan en la solución del software. Para ello analicé

los diagramas de interacción.

2. Dibuje un diagrama de clases.

3. Duplique los atributos provenientes de los conceptos asociados del método conceptual.

4. Agregue los nombres de los métodos analizando los diagramas de interacción.

5. Incorpore la información sobre los tipos de atributos y a los métodos.

6. Agregue las asociaciones necesarias para dar soporte a la visibilidad requerida de los

atributos.

7. Agregue flechas de navegación a las asociaciones para indicar la dirección de la

visibilidad de los atributos.

8. Agregue las líneas de relaciones de dependencia para indicar la visibilidad no relacionada

con los atributos.

Comparación entre el modelo conceptual y los diagramas de clase de diseño.-

En el método conceptual una venta no representa una definición de software mas bien es una

abstracción de un concepto del mundo real acerca del cual queremos afirmar algo. En cambio los

diagramas de clases de diseño expresan para el sistema computarizado la definición de clase

como componentes de software.

TEMA V

FASE DE DISEÑO


36

Modelo Conceptual

TPDVVenta

FechaestaTerminado: Booleanohora

Concepto; abstraccion

1

Captura

1

Diagrama deClases de diseno

TPDV

terminar Venta()introducirProducto()efectuarPago()

Venta

Fechaestaterminada:Booleanohora

hacerLineadeProductos()

Componentes de software

1

captura

1

Figura: Comparacion entre el modelo conceptual y el diagrama de clase del diseno

:TPDV :Ventas

Ventas

fechaestaTerminadahora

hacerLineaProductos()

3: hacerLineaProducto(especif,cant)

Figuar: Nombres de los metodos tomads de los diagramas de colaboracion

Creación de diagrama de clases del diseño

Para indicar los métodos de las clases se analizan los diagramas de colaboración. Por ejemplo, si

el mensaje hacerLineaProductos se envía a una instancia de las clases Venta, entonces esta

deberá definir el método hacerLineadeProductod.


37

TPDV

terminarVenta()introducirProducto()efectuarPago()

Venta

FechaestaTerminadahora

seTermina()hacerLineasProducto()efectuarPago()total()

La clase TPDV problamentetenga un atriibuto que apunta a

un objeto Venta

La Flecha de navegavilidadindica que los objetos TPDV

estan conectadosunidireccionalmentecon los objetos venta

La ausencia de la flechade navegavilidad indica que no existe

conexion de Ventas a TPDV

1

1

Captura

Figura: Descripcion graf ica de la navegavilidad , osea de la visivilidad de los atributos

Incorporación de asociaciones y de navegación.-

Se da el nombre de papel al fin de una asociación; en los diagramas de clases orientados al

diseño podemos adornar el papel con una flecha de navegabilidad. La navegabilidad es una

propiedad del papel e indica la posibilidad de navegar unidireccionalmente en una asociación,

desde el objeto fuente hasta la clase diseño, La navegabilidad; generalmente la visibilidad e los

atributos.

La interpretación usual de una asociación con una flecha de navegabilidad es la visibilidad de los

atributos, desde la clase fuente hasta la clase destino.

El los diagramas de clases orientados al diseño, la mayoría de las asociaciones deberán

comportarse con las flechas necesarias de navegación.

En un diagrama de este tipo, las asociaciones se escogen con un riguroso criterio que este

orientado al software y que se rija por la necesidad de conocer, ¿Cuáles asociaciones se requieren

para satisfacer con los diagramas de interacción de visibilidad y las necesidades constantes de la

memoria?

La visibilidad y las asociaciones requeridas entre las clases se indican con los diagramas de

iteración.


38

CatalogodeProductos

especificaciones

Pagp

monto:Cant idad

1

1

1

1

registros - terminados

1

Pagado - por

1

1

1 1..*

11

1

1..*

1

*

1

1

*

Tienda

direccion; Direccionnombre: Texto

agregarVenta()

TPDV

terminarVenta()introducirProducto()efectuarPago()

Venta

fecha:FechaestaTerminada:Booleanohora : Hora

se Termina(0hacerLineadeProductos()efectuarPago()total()

EspecificacionesdeProducto

descripcion:Textoprecio: Cantidadcup:CUP

VentasLineaProducto

cantidad: Entero

subtotal()

Usa

Alberga

Mira - en

Captura1

Contiene

Contiene

Figura: Asociaciones con simbolos de navegavilidad

Agregación de las relaciones de dependencia

El lenguaje UML incluye una relación general de dependencia, la cual indica que un elemento (de

cualquier tipo de clase, caso de uso y otro) conoce la existencia de otro. Se denomina con una

línea apuntada y con flecha. En el diagrama de clases, la relación de dependencias sirve para

describir la visibilidad entre atributos que no se relacionan con ellos; en otras palabras, la

visibilidad del parámetro global o declarado localmente. En cambio, la visibilidad simple de

atributos se indica con una flecha normal de asociaciones y con una flecha d navegabilidad.

Por ejemplo, el objeto de software TPDV recibe un objeto devuelto del tipo

ESpecificaciondeProductos proveniente del mensaje de especificación que envió a una

CatalogodeProducto. Asi, TPDV tiene una visibilidad de corto plazo localmente declarada en

EspecificacionesdeProducto.


39

Algunos aspectos del diseño de sistemas.-

Los sistemas de información con una interfaz para el usuario (que entre otras cosas incluyen

software de aplicación como los procesadores de palabra) son la categoría mas común de

aplicación.

Arquitectura clásica de tres capas.-

Una arquitectura común de los sistemas de información que abarca una interfaz para el usuario y

el almacenamiento persistente de datos se conoce con el nombre de arquitectura de tres capas.

He aquí una descripción clásica de las capas verticales.

1. Presentación

2. Lógica de aplicación

3. almacenamiento

la calidad tan especial d la arquitectura de tres capas consiste en aislar la lógica de la aplicación y

en convertirla en una capa intermedia bien definida y lógica de software. El la capa de presentación

se realiza relativamente poco proceso de aplicaciones; las ventanas envían a la capa intermedia

peticiones de trabajo. Y este se comunica con la capa de almacenamiento del extremo posterior.

Arquitectura multicapa orientada orientada a objeto.-

Una arquitectura multicapas que se adecue a los sistemas de información orientada o objetos

incluye la división de las responsabilidades que encontramos en arquitectura clásica de tres capas.

Descomposición de la capa de la lógica de las aplicaciones.-

La Capa de la lógica de aplicaciones esta constituida de las siguientes capas.

Objetos del dominio

servicios


40

Concepto de Dominio

Elementos Basico Ventas

Figura: Descomposición de la capa de lógica de aplicaciones en estrato o subcapa más detallas

Como mostrar la arquitectura con paquetes UML.-

El lenguaje UML, ofrece el mecanismo paquete que permite describir los grupos de elementos o

subsistemas un paquete es un conjunto de cualquier tipo de elemento de un modelo: clases, casos

de uso diagramas de colaboración u otros paquetes.

Ejemplo

Figura: Paquetes en el lenguaje UML

TPDVApplet

Pago Venta

interfazdelabasedeDatos

GeneradordeReportes

Concepto del dominio

Servicios

Base de Datos

Logica de aplicacion

Almacena,miento

Presentacio

n


41

Requerimientos del Sistema.-

Una especificación escrita para la primera versión del Sistema de Control de Rutas,

compilada de entrevistas con varios encargados de dicha área en varias empresas podría ser la

siguiente:

Consideremos el caso de cualquier empresa comercializadora que esté interesada en

contar con un Sistema de Control de Rutas que le permita controlar los diferentes gastos en

las rutas de distribución de sus productos, así como los costos asociados a dicha actividad,

los cuales serán descritos más adelante. Supongamos que cada ruta cubre un área

geográfica específica y es el área que es cubierta por un vehículo repartidor específico que

hace las entregas correspondientes a los vendedores finales

(Distribuidores o clientes). Es importante tomar en cuenta que las rutas incluyen varios

elementos de costo, entre los cuales podemos mencionar los costos relacionados con:

vehículos, empleados y gastos indirectos. Esto es importante si consideramos que si existe un

buen control sobre la flota vehicular se podrán tomar decisiones más acertadas para lograr

de ella el máximo rendimiento y una mayor generación de utilidades para la empresa que

desea aumentar su competitividad.

Es de vital importancia considerar los siguientes aspectos:

Vehículos

Entre los datos que podrá manejar el sistema para los vehículos tenemos: descripción,

fecha de compra, costo de compra, factura de compra y cheque con que se pagó,

datos de circulación, vendedor, impuestos. Los vehículos son los equipos utilizados

para transportar al vendedor

TEMA VI CASOS DE ESTUDIO


42

(chofer), su ayudante y el producto a vender.

La flota vehicular de una empresa va a estar en concordancia con el tamaño de la

empresa, así como con otros aspectos, tales como demanda del mercado, tipo de

producto a distribuir y la estrategia planteada por la organización para llevar a cabo sus

operaciones de distribución.

Mantenimientos

Toda empresa que posee una flota vehicular debe tomar en cuenta que debe

llevarse una administración efectiva de los mantenimientos de los vehículos, para lo

cual se calendarizan mantenimientos preventivos y se realizan mantenimientos

correctivos que deben ser puestos en marcha con el objetivo primordial de no sufrir

retrasos en las operaciones de distribución por problemas en las unidades vehiculares.

El sistema deberá almacenar la información sobre los mantenimientos así como sus

elementos de costos.

El calendario preventivo puede manejarse por planes. Un plan puede definirse como un

conjunto de trabajos a realizarle a un vehículo en una unidad de tiempo para

asegurar su buen funcionamiento. Ejemplo de un plan podría ser:

Plan A: Aplicado cada tres

meses Cambio de aceite

Engrase

Chequeo liquido de frenos

Plan B: Aplicado cada seis meses

Cambio de aceite

Engrase

Chequeo de liquido de frenos

Cambio de banda

El sistema deberá registrar todos los gastos asociados a los mantenimientos correctivos

de los vehículos en mal estado. Esto incluye tanto el pago de servicios de taller externos o


43

internos, según sea la disponibilidad del mismo dentro de la organización, así como el pago

de los repuestos que sean requeridos para realizar dichos mantenimientos.

Sustento Vehicular

Se refiere a todos los gastos asociados con la compra de llantas, lavado, revisión de

gas, aire, filtros, impuestos, pintura, etc.

Los gastos accesorios se refieren a aquellos que no son de mantenimiento del

vehículo. Por ejemplo, pago de parqueo, derecho de entrada a mercados, pago de

vigilancia, etc. Estos conceptos deben ser abiertos.

Rutas

El sistema deberá almacenar todos los datos concernientes al supervisor, distancias,

estado de la carretera, situación geográfica y política. También deberá almacenar todos los

gastos directamente atribuibles a las rutas. Hay que tomar en cuenta que una ruta puede

tener diferentes recorridos dependiendo del día de la semana.

Empleados

El sistema registrará los datos de los empleados que trabajan en las rutas, así como

todos los gastos asociados entre los cuales debemos mencionar también los gastos de

nómina y gastos de operación en ruta. Los gastos de operación se refieren a gastos

propios del trabajo en ruta. Por ejemplo, viáticos, hospedaje, llamadas telefónicas, etc. Los

conceptos deben ser abiertos. También deberá llevarse un control completo del historial del

empleado como choques, multas, etc.

Seguros

Además de todas las capacidades antes mencionadas el Sistema de Control de

Rutas deberá ofrecer facilidades para el manejo de pólizas de seguros tanto para los

empleados como para los vehículos.


44

Proveedores

Debe llevarse control de los proveedores de los distintos elementos de gastos del sistema.

Análisis de Requerimientos.-

El análisis de requerimientos consiste en definir los casos de uso para el sistema, los cuales

describen lo que el Sistema de Control de Rutas proporcionará en términos de funcionalidad. El

análisis de casos de uso consistió en leer y analizar las especificaciones, así como discutir el

sistema con los usuarios potenciales (clientes) del sistema.

Actores.-

Los actores del sistema fueron identificados como:

Operador del sistema: es la persona que se encarga de introducir los datos generales del

sistema y de darle mantenimiento.

Gerente Ventas: es la persona que desempeña el cargo de Gerente de Ventas.

Gerente Financiero: es la persona que desempeña el cargo de Gerente Financiero.

Gerente Recursos Humanos: es la persona que desempeña el cargo de Gerente de

Recursos Humanos.

Sistema de Contabilidad: es el Sistema de Contabilidad de la empresa.

Usuario: es un supertipo del cual todos los actores humanos heredan.

Casos de Uso

Basados en los actores, las necesidades planteadas en los requerimientos del sistema

y ciertos requerimientos de implementación fueron identificados los siguientes casos de uso

(con su respectiva descripción):

Controlar Gastos en las Rutas: este caso de uso es iniciado por el gerente financiero o

de ventas. Proporciona la capacidad de crear, modificar, eliminar y visualizar los


45

diferentes gastos en las rutas.

Controlar Recorridos de las Rutas: este caso de uso es iniciado por el gerente

de ventas. Proporciona la capacidad de crear, modificar, eliminar y visualizar los datos

de los recorridos de las rutas.

Mantener Itinerarios de las Rutas: este caso de uso es iniciado por el gerente


de los itinerarios de las rutas.

Controlar Asignaciones de los Vehículos: este caso de uso es iniciado por el gerente


de las asignaciones de los vehículos.

Calendarizar Mantenimientos de los Vehículos: este caso de uso es iniciado por el

gerente de ventas. Proporciona la capacidad de crear, modificar, eliminar y

visualizar los datos de los calendarios de mantenimientos de las rutas.

Mantener Historial del Empleado: este caso de uso es iniciado por el gerente de

ventas. Proporciona la capacidad de crear, modificar, eliminar y visualizar el historial del

empleado.

Reportes: este caso de uso es iniciado por el gerente de ventas, el gerente financiero o

el gerente de recursos humanos y proporciona la capacidad de obtener reportes del

sistema.

Exportar Gastos al Sistema de Contabilidad: este caso de uso es iniciado por el

gerente financiero. Proporciona la capacidad de exportar los gastos registrados en el

sistema al sistema de contabilidad mediante archivos de texto.

Gastos de Rutas: Proporciona la capacidad de crear, modificar, eliminar y visualizar los

diferentes gastos atribuibles directamente a las rutas.

Gastos de Vehículos: Proporciona la capacidad de crear, modificar, eliminar y

visualizar los diferentes gastos misceláneos de los vehículos.

Gastos de Mantenimientos: Proporciona la capacidad de crear, modificar, eliminar y

visualizar los diferentes gastos de mantenimiento de los vehículos.

Gastos de Seguros de Vehículos: Proporciona la capacidad de crear, modificar,

eliminar y visualizar los diferentes gastos de seguros (pólizas) de los vehículos.

Gastos de Empleados: Proporciona la capacidad de crear, modificar, eliminar y

visualizar los diferentes gastos de los empleados.

Gastos de Seguros de Empleados: Proporciona la capacidad de crear, modificar,


46

eliminar y visualizar los diferentes gastos de seguros (pólizas) de los empleados.

Importar Nómina de Empleados: este caso de uso proporciona la capacidad de importar

los gastos en salarios del empleado del sistema de nómina al sistema de control de

rutas mediante un archivo de texto del sistema operativo.

Mantenimiento del Sistema: este caso de uso es iniciado por el operador. Proporciona la

capacidad de crear, modificar, eliminar y visualizar los datos de los catálogos del

sistema y las utilerías del mismo.

Datos de Rutas: Proporciona la capacidad de crear, modificar, eliminar y visualizar los

diferentes datos generales de las rutas de distribución.

Datos de Vehículos: Proporciona la capacidad de crear, modificar, eliminar y

visualizar los diferentes datos generales de los vehículos.

Datos de Empleados: Proporciona la capacidad de crear, modificar, eliminar y

visualizar los diferentes datos generales de los empleados (choferes y ayudantes).

Datos de Clientes: Proporciona la capacidad de crear, modificar, eliminar y

visualizar los diferentes datos generales de los clientes.

Datos de Proveedores: Proporciona la capacidad de crear, modificar, eliminar y

visualizar los diferentes datos generales de los proveedores.

Datos de Productos y/o Servicios: Proporciona la capacidad de crear, modificar,

eliminar y visualizar los diferentes datos generales de los productos y/o servicios de los

gastos.

Datos de Mantenimientos: Proporciona la capacidad de crear, modificar, eliminar y

visualizar los diferentes datos generales de los mantenimientos preventivos.

Nombres de Historiales: Proporciona la capacidad de crear, modificar, eliminar y

visualizar los diferentes datos generales de los nombres de los historiales.

Exportar Base de Datos: Proporciona la capacidad de exportar la base de datos del

sistema a un archivo del sistema operativo.

Ayuda: este caso de uso es iniciado por un usuario. Proporciona la capacidad del

proporcionar ayuda en línea al usuario.

Validar Usuario: este caso de uso es iniciado por un usuario. Proporciona la capacidad de

verificar el usuario y darle o no acceso al sistema.

Reporte de Calendarios de Mantenimiento: Proporciona la capacidad de imprimir un

reporte del calendario de mantenimiento de los vehículos.

Reporte de Itinerarios: Proporciona la capacidad de imprimir un reporte de los


47

itinerarios de las rutas.

Reporte de Historiales: Proporciona la capacidad de imprimir un reporte de los

historiales de los empleados.

Reporte de Recorridos: Proporciona la capacidad de imprimir un reporte de los

recorridos de las rutas.

Reporte de Asignaciones: Proporciona la capacidad de imprimir un reporte de

asignaciones de vehículos.

Reporte de Seguros de Vehículos: Proporciona la capacidad de imprimir un reporte de

pólizas de seguros de vehículos.

Reporte de Seguros de Empleados: Proporciona la capacidad de imprimir un reporte de

pólizas de seguros de empleados.

Reporte de Gastos de Rutas: Proporciona la capacidad de imprimir un reporte

de gastos directamente atribuibles a las rutas.

Reporte de Gastos de Vehículos: Proporciona la capacidad de imprimir un reporte

de gastos misceláneos de los vehículos.

Reporte de Gastos de Mantenimiento: Proporciona la capacidad de imprimir un reporte

de gastos de mantenimiento de los vehículos.

Reporte de Gastos de Empleado: Proporciona la capacidad de imprimir un reporte de

gastos de los empleados.

Reporte de Rutas: Proporciona la capacidad de imprimir un reporte de los datos de las

rutas.

Reporte de Vehículos: Proporciona la capacidad de imprimir un reporte de los

datos de los vehículos.

Reporte de Empleados: Proporciona la capacidad de imprimir un reporte de los

datos de los empleados.

Reporte de Proveedores: Proporciona la capacidad de imprimir un reporte de los

datos de los proveedores.

Reporte de Productos y/o Servicios: Proporciona la capacidad de imprimir un reporte de

los datos de los productos y/o servicios.

Reporte de Clientes: Proporciona la capacidad de imprimir un reporte de los datos de los

clientes. Todos estos casos de uso deben ser implementados a lo largo del desarrollo

del sistema. Son usados durante el análisis para verificar si las clases de dominio

(entidades) apropiadas han sido definidas, y son usados durante el diseño para


48

confirmar que la solución técnica es suficiente para manejar la funcionabilidad

requerida.

También el análisis de requerimientos es documentado en diagramas de casos de uso y con

flujos de eventos para cada caso de uso. Los diagramas de casos de uso se muestran a

continuación.

A continuación presentamos el flujo de eventos para algunos casos de uso. Los flujos de

todos los casos de uso son incluidos en la documentación de cada caso de uso.

Flujo de eventos para el caso de uso: Controlar Gastos de las Rutas.-

Precondiciones.-

Flujo principal.-

Este caso de uso inicia cuando el gerente financiero o de venta ingresa al sistema. El

sistema le pide al usuario su nombre y contraseña. El usuario entra su nombre y

contraseña. El sistema verifica que el nombre y contraseña sean válidas (E-1). El

sistema le pide al usuario que seleccione un gasto de las pestañas del sistema:

Gastos de rutas

Gastos de vehículos

Gastos de mantenimientos

Gastos de seguro de vehículos

Gastos de empleados

Gastos de seguro de empleados

Importar nómina de empleados

El usuario selecciona la opción deseada. El sistema despliega la pantalla de gastos de la

opción seleccionada y le pide al usuario la actividad deseada: AÑADIR, REMOVER,

MODIFICAR, CONSULTAR o SALIR.


49

Subflujos.-

Los subflujos están descritos específicamente para cada tipo de gastos del sistema.

Flujos alternos

E-1: El nombre y/o contraseña introducido por el usuario es inválido. El sistema le

notifica al usuario. El usuario puede introducir un nombre y contraseña válida o salir del

caso de uso.

Flujo de eventos para el caso de uso: Gastos de Rutas,-

Precondiciones.-

Los subflujos AÑADIR de los casos de uso Datos de Rutas y Datos de Producto y/o

Servicios deben de ejecutarse antes que este caso de uso inicie.

Flujo principal.-

Este caso de uso inicia cuando el gerente financiero o de venta ingresa al sistema. El

sistema le pide al usuario su nombre y contraseña. El usuario entra su nombre y su

contraseña. El sistema verifica que el nombre y contraseña sean válida (E-1). El sistema

despliega la pantalla de gastos de rutas y le pide al usuario que seleccione la ruta a

cargar el gasto. El usuario selecciona la ruta deseada (E-2). El sistema le pide al

usuario que seleccione la actividad deseada: AÑADIR, REMOVER, MODIFICAR,

CONSULTAR o SALIR.

Si la actividad es AÑADIR, es S-1: Añadir un gasto de ruta es realizado.

Si la actividad es REMOVER, es S-2: Remover un gasto de ruta es realizado.

Si la actividad es MODIFICAR, es S-3: Modificar un gasto de ruta es realizado.

Si la actividad es CONSULTAR, es S-4: Consultar los gastos de la ruta es


50

realizado. Si la actividad es SALIR, el caso de uso finaliza.

Subflujos.-

S-1: Añadir un gasto de ruta

El sistema solicita el código del producto y/o servicio a cargar como gasto, la fecha y

hora del gasto, la cantidad, el costo de materiales y de mano de obra. El usuario

introduce el código del producto y/o servicio a cargar como gasto (E-3), la fecha y hora del

gasto (E-4), la cantidad (E-5), el costo de materiales (E-6) y de mano de obra (E-7). El

sistema guarda el gasto. El caso de uso inicia de nuevo.

S-2: Remover un gasto de ruta

El sistema solicita al usuario que seleccione el gasto de ruta a remover. El usuario

selecciona el gasto de ruta. El sistema remueve el gasto de ruta. El caso de uso inicia de

nuevo.

S-3: Modificar un gasto de ruta

El sistema solicita la selección del gasto de ruta a modificar. El usuario selecciona el gasto de ruta.

El sistema solicita el código del producto y/o servicio a cargar como gasto, la fecha y hora del

gasto, la cantidad, el costo de materiales y de mano de obra. El usuario introduce el código del

producto y/o servicio a cargar como gasto (E-3), la fecha y hora del gasto (E-4), la cantidad (E-5),

el costo de materiales (E-6) y de mano de obra (E-7). El sistema guarda los cambios del gasto.

El caso de uso inicia de nuevo.

S-4: Consultar los gastos de la ruta.

El sistema solicita el criterio de consulta. El usuario introduce el criterio de consulta (E-

8). El sistema despliega los gastos de rutas encontrados según el criterio de consulta (E-

9). El caso de uso inicia de nuevo.

Flujos alternos



51

notifica al usuario. El usuario puede introducir un nombre y contraseña válida o salir del caso

de uso.

E-2: El usuario ha introducido un código inválido o nulo de ruta. El sistema notifica al

usuario. El usuario puede introducir un código válido de ruta o salir del caso de uso.

E-3: El usuario introduce un código inválido o nulo del producto y/o servicio. El sistema

notifica al usuario. El usuario puede introducir un código válido de producto y/o servicio o

salir del caso de uso.

E-4: El usuario introduce una fecha y hora inválida o nula. El sistema notifica al

usuario. El usuario puede introducir una fecha y hora válida o salir del caso de uso.

E-5: El usuario introduce una cantidad inválida o nula. El sistema notifica al usuario. El

usuario puede introducir una cantidad válida o salir del caso de uso.

E-6: El usuario introduce un costo inválido o nulo de materiales. El sistema notifica al

usuario. El usuario puede introducir un costo válido de materiales o salir del caso de uso.

E-7: El usuario introduce un costo inválido de mano de obra. El sistema notifica al

usuario. El usuario puede introducir un costo válido de mano de obra o salir del caso de uso.

E-8: El usuario ha introducido un criterio inválido de consulta. El sistema notifica al

usuario. El usuario puede introducir un criterio de consulta válido o salir del caso de uso.

E-9: El sistema no pudo recuperar ningún gasto de ruta. El caso de uso inicia de nuevo.

Flujo de eventos para el caso de uso: Datos de Rutas.-

Precondiciones.-


52

Flujo principal.-

Este caso de uso inicia cuando el operador del sistema ingresa al sistema. El sistema le

pide al usuario su nombre y contraseña. El usuario entra su nombre y su contraseña. El

sistema verifica que el nombre y contraseña sean válida (E-1). El sistema despliega la

pantalla de datos de rutas. El sistema le pide al usuario que seleccione la actividad

deseada: AÑADIR, REMOVER, MODIFICAR, CONSULTAR o SALIR.

Si la actividad es AÑADIR, es S-1: Añadir una ruta es realizado.

Si la actividad es REMOVER, es S-2: Remover una ruta es realizado.

Si la actividad es MODIFICAR, es S-3: Modificar una ruta es

realizado. Si la actividad es CONSULTAR, es S-4: Consultar las

rutas es realizado. Si la actividad es SALIR, el caso de uso finaliza.

Subflujos.-

S-1: Añadir una ruta

El sistema solicita el código de la ruta, la descripción, el nombre del supervisor, la

situación geográfica y la situación política. El usuario introducirá el código de la ruta (E-2),

la descripción

(E-3), el nombre del supervisor (E-4), la situación geográfica (E-5) y la situación política (E-

6). El sistema guarda la ruta. El caso de uso inicia de nuevo.

S-2: Remover una ruta

El sistema solicita al usuario el código de la ruta a remover. El usuario introduce el código

de la ruta (E-2). El sistema remueve la ruta. El caso de uso inicia de nuevo.

S-3: Modificar una ruta

El sistema solicita al usuario el código de la ruta a modificar. El usuario introduce el código

de la ruta. El sistema solicita la descripción, el nombre del supervisor, la situación

geográfica y la situación política. El usuario introducirá la descripción (E-3), el nombre del

supervisor (E-4), la situación geográfica (E-5) y la situación política (E-6). El sistema guarda

los cambios de la ruta. El caso de uso inicia de nuevo.


53

S-4: Consultar las rutas

El sistema solicita el criterio de consulta. El usuario introduce el criterio de consulta (E-

7). El sistema despliega las rutas encontradas según el criterio de consulta (E-8). El caso

de uso inicia de nuevo.

Flujos alternos.-


notifica al usuario. El usuario puede introducir un nombre y contraseña válida o salir del

caso de uso.

E-2: El usuario ha introducido un código inválido o nulo de ruta. El sistema notifica al

usuario. El usuario puede introducir un código válido de ruta o salir del caso de uso.

E-3: El usuario ha introducido una descripción inválida o nula. El sistema notifica al

usuario. El usuario puede introducir una descripción válida o salir del caso de uso.

E-4: El usuario introduce un nombre de supervisor inválido o nulo. El sistema notifica al

usuario. El usuario puede introducir un nombre válido o salir del caso de uso.

E-5: El usuario introduce una situación geográfica inválida. El sistema notifica al

usuario. El usuario puede introducir una situación geográfica válida o salir del caso

de uso.

E-6: El usuario introduce una situación política inválida. El sistema notifica al

usuario. El usuario puede introducir una situación política válida o salir del caso

de uso.

E-7: El usuario ha introducido un criterio inválido de consulta. El sistema notifica al

usuario. El usuario puede introducir un criterio válido de consulta o salir del caso de uso.

E-8: El sistema no pudo recuperar ninguna ruta. El caso de uso inicia de nuevo.


54

Flujo de eventos para el caso de uso: Reporte de Rutas.-

Precondiciones

El subflujo AÑADIR del caso de uso Datos de Rutas deben de ejecutarse antes que este

caso de uso inicie.

Flujo principal

Este caso de uso inicia cuando el gerente de finanzas, de venta o de recursos humanos

ingresa al sistema. El sistema le pide al usuario su nombre y contraseña. El usuario entra

su nombre y su contraseña. El sistema verifica que el nombre y contraseña sean válida

(E-1). El sistema pide al usuario seleccionar el reporte de rutas del menú del sistema. El

usuario selecciona el reporte de rutas. El sistema despliega la pantalla de reporte de

rutas y le pide al usuario que seleccione el destino de salida: IMPRESORA, E-MAIL o

CANCELAR.

Si el destino es IMPRESORA, es S-1: Reporte de rutas por impresora es

realizado. Si el destino es E-MAIL es S-2: Reporte de rutas por e-mail es

realizado.

Si la actividad es CANCELAR, el caso de uso finaliza.

Subflujos

S-1: Reporte de rutas por impresora

El sistema da salida al reporte por impresora con los datos de códigos de rutas,

descripciones de rutas, situaciones geográficas y políticas de las rutas (E-2).

S-2: Reporte de rutas por e-mail

El sistema da salida al reporte por correo electrónico con los datos de códigos de

rutas, descripciones de rutas, situaciones geográficas y políticas de las rutas (E-2).


55

Flujos alternos


notifica al usuario. El usuario puede introducir un nombre y contraseña válida o salir del caso

de uso.

E-2: El destino de salida del reporte no esta disponible. El sistema le notifica al usuario. El

usuario puede introducir un destino disponible o salir del caso de uso.

Análisis

El propósito del análisis es capturar y describir todos los requerimientos del sistema y

elaborar un modelo que defina las clases claves del dominio del sistema (qué es manejado en

el sistema). También se quiere proporcionar una explicación clara y permitir una

comunicación fluida entre los desarrolladores (nosotros) y la gente que establece los

requerimientos (usuario o cliente); por lo tanto, el análisis es típicamente conducido en

cooperación con el usuario final.

Para realizarlo, analizamos las especificaciones y los casos de uso y buscamos qué

“conceptos” deben ser manejados por el sistema. Para esto organizamos una sesión de lluvia

de ideas con los clientes para identificar los conceptos claves que deben ser manejados, junto

con las relaciones entre sí.

Clases de Entidad

Las clases de entidad en el Sistema de Control de Rutas son definidas con el estereotipo

<<Entity>>, lo cual indica que los objetos de la clase son parte del dominio del problema y

deben ser almacenadas persistentemente en el sistema. Enfatizamos el hecho de que las

clases de entidad están siendo dibujadas a un nivel alto en esta etapa.

Las clases de entidad identificadas junto con su descripción se muestran a continuación:


56

Ruta: Una ruta es una división geográfica que hace la empresa con el fin de

distribuir sus productos.

Vehículo: Un vehículo es usado por la empresa para la distribución de los productos a los

clientes.

Cliente: Un cliente es cualquier persona o empresa que compra productos de la empresa.

Clases de Frontera

Cuando se analizan los flujos de eventos se vuelve obvio que se necesitan ventanas y

cuadros de diálogos para proporcionar una interfaz a los actores. En el análisis es suficiente

darse cuenta que se necesitan las ventanas y cuadros de diálogos para documentar los

requisitos de interfaz del usuario. Las ventanas las modelamos con el estereotipo

<<Ventana>>. El diseño detallado de la interfaz del usuario no es especificado en este

momento; de nuevo, es una especificación de alto nivel.

También es necesario añadir las interfaces con los sistemas de contabilidad y nómina que son

también clases de frontera con el estereotipo <<ArchivoTexto>>. Esto lo hicimos porque la

interfaz se hace mediante archivos de texto.

Las clases de frontera identificadas para el sistema son: Contabilidad, Nómina,

VentanaRutas, VentanaRecorridos, VentanaItinerarios, VentanaGastosRuta,

Las descripciones de estas clases son todas similares y del tipo: “VentanaRutas:

Proporciona una interfaz para el caso de uso Datos de Rutas”; por eso no las incluimos aquí.

Clases de Control

Durante esta etapa añadimos una clase de control por cada caso de uso para manejar el

flujo de eventos del mismo. Estas clases las definimos con el estereotipo <<Control>>.

Las clases decontrol añadidas son: AdmControlGastos, AdmRecorrido AdmItinerarios,

AdmMantenimientoSist, AdmAsignaciones, AdmCalendarios, AdmMantenimientos,

AdmReportes, AdmSegurosEmpleados,


57

Las descripciones de estas clases son todas similares y del tipo: “AdmControlGastos:

Proporciona lógica de secuenciación para el caso de uso Controlar Gastos en las Rutas”; por

eso no las incluimos aquí.

Paquetes

Para separar las clases de entidad, las clases de frontera y las clases de control, se agrupan

en paquetes llamados respectivamente Objetos del Negocio, Interfaz del Sistema y Utilidades.

Estos paquetes serán detallados en el diseño.

Diagramas de secuencia

Los casos de uso deben ser realizados durante esta etapa. Para describir el comportamiento

dinámico del sistema, cualquiera de los diagramas de interacción del UML pueden ser

utilizados. Debido a que Rational Rose no soporta los diagramas de actividad y ofrece soporte

limitado para los diagramas de colaboración (en notación completa del UML) usaremos

diagramas de secuencia. De nuevo, las operaciones son definidas a un nivel alto y no

son descritas en detalle con signaturas. Las metas principales del análisis son lograr una

comunicación eficiente con el usuario/cliente y lograr un entendimiento de alto nivel del

sistema que se construye; no es una solución de diseño detallado.

Relaciones entre Clases

Las relaciones entre clases son encontradas analizando los requerimientos del sistema (de

una forma muy parecida a las relaciones en los diagramas entidad-relación) y también

mediante los mensajes en los diagramas de secuencia.

En el escenario Añadir Ruta del caso de uso Datos de Rutas podemos observar que hay

comunicación entre las clases VentanaRutas (del paquete interfaz) y Ruta (del paquete

objetos del negocio), por lo que hay que crear una relación de asociación entre ellas.

Operaciones de las Clases


58

Las operaciones de las clases fueron encontradas mapeando los mensajes en los

diagramas de secuencia a operaciones en la clase receptora.

Por ejemplo, en el escenario Añadir Ruta del caso de uso Datos de Ruta podemos observar que

la clase

Ruta recibe dos mensajes. Estos mensajes se convirtieron en operaciones llamadas Crear y

Guardar.

Atributos de las Clases

Los atributos de las clases fueron encontrados en los requerimientos del sistema y en los

flujos de eventos.

Por ejemplo, en los requerimientos del sistema dice: "El sistema deberá almacenar todos

los datos concernientes al supervisor, distancias, estado carretera, situación geográfica y

política" (de las rutas). Por lo tanto se crearon atributos para la clase Ruta llamados Supervisor,

Sit_Geo y Sit_Pol. Se añadió un atributo Id para identificar cada clase y un atributo Ruta_Desc

que contendrá la descripción de cada ruta. También se añadieron los atributos distancia, vía y

estado a la clase DetalleItinerario.

Diagramas de Estados

Algunas de las clases tienen diagramas de estados para mostrar los diferentes estados que

los objetos de dichas clases puedan tener, junto con los eventos que causarán la transición de

estados.


59

Diseño

La fase de diseño (y los modelos UML resultantes) expande y detalla los modelos de análisis

tomando en cuenta todas las implicaciones y restricciones técnicas. El propósito del diseño es

especificar una solución que trabaje y pueda ser fácilmente convertida en código fuente y

construir una arquitectura simple y fácilmente extensible. Las clases definidas en el análisis

fueron detalladas, y se añadieron nuevas clases para manejar áreas técnicas como base de

datos, interfaz del usuario, comunicación, dispositivos, etc.

Una arquitectura bien diseñada es la base para un sistema fácilmente extensible y cambiable.

Durante esta etapa se expandieron los paquetes del sistema, incluyendo sus dependencias

y mecanismos de comunicación. Estos paquetes son detallados, de tal forma que las clases

sean detalladas de forma suficiente para dar especificaciones claras al programador que

las codifica. Los paquetes fueron definidos tomando en cuenta la separación entre áreas

funcionales y áreas técnicas. Un problema clave por resolver en esta definición fue establecer

las reglas para dependencias entre los paquetes, de tal forma que se eviten las

dependencias bidireccionales entre ellos e identificar la necesidad de librerías estándar que

puedan ser usadas y simplifiquen el trabajo.


60

Figura: Paquetes del sistema en la etapa de diseño y sus dependencias

La figura anterior muestra los paquetes del caso de estudio. A continuación se detallan cada

uno de ellos:

Paquete de base de datos

La aplicación debe almacenar sus objetos persistentemente, por lo tanto una capa de base

de datos fue añadida para proporcionar este servicio. La solución desarrollada fue

implementar el almacenamiento mediante la base de datos objeto-relacional Oracle8.

Los detalles sobre el almacenamiento son escondidos de la aplicación, la cual sólo tiene que

llamar operaciones comunes como insert(), update(), delete(), y select(), y así

sucesivamente, en los objetos.

Paquete de objetos del negocio

El paquete de objetos del negocio está basado en el paquete correspondiente en el


61

análisis. Las clases, sus relaciones, y su comportamiento son preservados; sólo que las

clases son descritas con mayor detalle, incluyendo cómo sus relaciones y comportamiento

son implementados.

Las operaciones del análisis han sido detalladas, lo que significa que algunas de ellas

han sido cambiadas. Esto es considerado normal, debido a que el análisis es un dibujo de

las capacidades de cada clase mientras que el diseño es una descripción detallada del

sistema.

A continuación se muestra una sección del diagrama de clases de entidad en la etapa de

diseño:

Figura: Diagrama de Clases de Entidad en la Fase de Diseño

Es importante notar que entre los modelos de análisis y de diseño se realizaron los

siguientes cambios:


62

Se agregaron clases para representar interfaces entre dispositivos como la

impresora y para representar el envío de reportes mediante correo electrónico.

Esta versión del sistema (la primera iteración) no maneja la importación del

sistema de nómina, por que fue dejada para una iteración posterior; por lo tanto no

fue implementada.

Los modelos dinámicos en el modelo de diseño han sido actualizados. De nuevo los

diagramas de secuencia se utilizan para mostrar los modelos dinámicos

Análisis de Sistemas II Lic. Patricia Palacios

Zuleta

63

Figura: Diagrama de secuencia para el escenario Añadir Ruta del caso de uso Datos de Rutas en la Fase de Diseño

Paquete de interfaz del sistema

El paquete de interfaz del sistema está por encima de los otros paquetes. Presenta los

servicios y la información en el sistema a los actores. Este paquete está

basado en las capacidades proporcionadas por Oracle Developer/2000.

Paquete de utilidades

El paquete de utilidades contiene servicios que otros paquetes usan en el sistema,

tales como las clases de control definidas durante el análisis, las cuales han sido

detalladas, combinadas y expandidas durante el diseño.

Implementación Esta es la fase cuando las clases son programadas. Para esto fueron implementadas en

Oracle Developer/2000. Es importante mencionar que como se mencionó anteriormente, no

se programaron todos los casos de uso del sistema porque fueron dejados para una iteración

posterior, específicamente: Importar Nómina de Empleados. También queremos recalcar el

hecho de que Rational Rose no puede generar código para Developer/2000, por lo que el

trabajo fue más arduo. Sin embargo, puede generar código para lenguajes como C++, Java,

Visual Basic y el esquema de base de datos para Oracle8. El diagrama de componentes

muestra los diferentes componentes fuentes, binarios y ejecutables que componen el sistema


Zuleta

64

Pruebas y Despliegue Por supuesto, el sistema tuvo que ser probado. Los casos de uso originales fueron probados

en la aplicación terminada para ver si eran correctamente soportados por la aplicación y

podían ser realizados como se definen en las descripciones de los casos de uso. La

aplicación también fue probada de una manera más informal poniéndola en las manos de

ciertos usuarios especializados en la materia. El despliegue de la aplicación es la entrega

actual. Debido a que el nuestro es un caso de estudio que no fue implementado en ninguna

organización no fue creada ninguna documentación formal del sistema o manuales de

usuario. Sin embargo, el sistema incluye una amplia ayuda en línea de todo el sistema,

incluyendo instrucciones para la instalación y ejecución del mismo en el archivo Leame.htm

en el CD-ROM. Se realizó un diagrama de despliegue de la arquitectura física. Este sistema

puede ser desplegado en cualquier computadora con sistemas operativos Windows 95/98 o

Windows NT 4.0 (con SP3) con acceso a una base de datos Oracle local o remota.


Zuleta

65

ANEXOS

Anexo A: Calidad en los Modelos

¿Cómo sabemos si un modelo es bueno o no? Un lenguaje de modelaje puede brindaros

una sintaxis y semántica pero no puede decirnos si un buen modelo ha sido producido. Esto

abre el tema muy subjetivo de la calidad en los modelos. Lo que es importante cuando

diseñemos modelos es lo que digamos sobre la realidad. Los modelos dan una expresión a

lo que sea que estamos estudiando (realidad, visión, etc.).

En un modelo, es muy importante que la esencia del dominio del problema sea capturada.

En sistemas financieros, estamos modelando facturas pero no la deuda. En la mayoría de

los negocios, la factura no es de importancia real, pero las deudas lo son. Una factura

es solamente una representación de la deuda, por lo que debería ser modelada como tal.

Otro ejemplo son las cuentas bancarias. Durante los años 70 y 80 muchos bancos

modelaron cuentas de bancos, donde los clientes eran parte de las cuentas

(la cuenta era una entidad y el cliente un atributo). El primer problema fue que los bancos

no podían manejar una cuenta con muchos dueños. El segundo problema era que los

bancos no podían conducir trabajo de mercadeo que involucraba clientes sin una cuenta

porque no tenían la dirección.

Por lo tanto, una dimensión de la calidad del modelo debe ser la relevancia del modelo.

Un modelo relevante captura los aspectos importantes de lo que se está estudiando.

Otras dimensiones de la calidad de los modelos son que el modelo debe ser fácil de

comunicar, tener una meta explícita, ser fácil de mantener, ser consistente, y tener

integridad. Modelos diferentes de la misma cosa pero con propósitos o perspectivas

diferentes deben ser integrados.

Sin importar que metodología o lenguaje de modelaje se use, hay otros problemas.

LECTURAS COPLEMENTARIAS


Zuleta

66

Cuando hacemos modelos nos convertimos en parte del negocio, lo que significa que

debemos considerar los efectos de nuestra intervención en el negocio. Es muy

importante manejar todos los aspectos de nuestra intervención como política, cultura,

estructura social, y poder. Si fallamos al hacer eso, podría no ser posible descubrir y

capturar todas las necesidades reales del cliente (note que los requerimientos

informados no son siempre lo mismo que las necesidades del cliente). En particular,

problemas con políticas internas, patrones sociales, estructura informal, y poder que

rodeen a los clientes deben ser tomados en consideración.

Todos los proyectos, pequeños y grandes dependen de la comunicación. La gente se

comunica entre sí. Leen los documentos de los otros y discuten sus contenidos. Por lo tanto

la idea principal detrás de los modelos es la capacidad de comunicarlos. Si creamos

modelos que nadie entiende o lee, no tiene sentido hacerlos del todo. Un modelo es

bueno cuando es posible comunicarlo, cuando alcanza sus propósitos y cuando hemos

capturado la esencia. Un buen modelo toma tiempo para crearse; es normalmente

hecho por un equipo compuesto para un propósito particular. Cuando la gente se asigna a

equipos debe ser hecho con el propósito del equipo en mente. Los equipos para modelar

un sistema de información o de negocios pueden estar compuestos de clientes, expertos

de modelaje, y expertos del dominio del problema.

Un modelo debe tener un propósito explícito que todo el que lo use reconozca. Los modelos

de análisis y diseño pueden ser modelos de los mismos sistemas pero son modelos

diferentes y se enfocan en detalles diferentes. El también necesario tener un propósito

explícito para el modelo para verificarlo y validarlo. Sin un propósito explícito, podríamos

por ejemplo, verificar un modelo de análisis como si fuera de diseño.

Muchos modelos envuelven solamente documentos en el negocio. ¿Entonces, que

sucede cuando el negocio cambia? En la práctica esto es un gran problema. Es necesario

capturar la esencia del negocio y modelar sobre esos conceptos para ser capaz de

manejar los cambios apropiadamente. Se debe modelar el negocio central y después

modelar la representación del negocio principal. Si la esencia es modelada, pequeños

cambios en el negocio pueden ser manejados mediante alteraciones en las clases que

representan el mismo.


Zuleta

67

Los nombres en los elementos del modelo deben ser derivados del dominio del problema;

deben tener un prefijo o sufijo. Es importante que a los elementos se les

asignen nombres relevantes, especialmente a las clases, asociaciones, roles, atributos, y

operaciones. Cuando los elementos tienen nombres del dominio, es más fácil comunicar el

modelo.

Los modelos diferentes de la misma cosa deben ser capaces de ser integrados y

relacionados con los otros. Un aspecto de la coordinación de modelos es la integración. La

integración significa que si un conjunto de modelos tienen el mismo propósito (aunque

puedan tener diferentes perspectivas, ej.: dinámico, funcional, estático) y representan la

misma cosa, debería ser posible juntarlos sin introducir inconsistencias. Las relaciones

entre los modelos en diferentes niveles de abstracción es un aspecto importante. Es una

de las claves para el éxito en la trazabilidad en ingeniería de software. Las relaciones

entre diferentes niveles de abstracción pueden ser visualizadas con relaciones de

refinamiento en el UML. Esto significa que los modelos son coordinados en cada nivel de

abstracción y entre los diferentes niveles de abstracción.

Aún si los modelos que diseñamos pueden ser comunicados, tienen un propósito explícito,

capturan la esencia del negocio, y son coordinados, todavía podemos tener problemas si

los modelos son muy complejos. Los modelos extremadamente complejos pueden ser

difíciles de revisar, verificar, validar, y mantener. A menudo es buena idea iniciar con una

simplificación, y después añadir más detalle usando coordinación de modelos. Cuando el

dominio del problema es complejo, se debe dividir el modelo en más modelos (usando

paquetes) y mediante ese proceso controlar la situación.

Anexo B: Refactorización

¿Le ha ocurrido el principio de entropía del software? Sugiere que los programas inician en

una forma bien diseñada, pero a medida que nuevos trozos de funcionalidad son

añadidos, los programas gradualmente pierden su estructura, transformándose

eventualmente en una masa de espagueti.

Parte de esto es debido a la escala. Se escribe un programa pequeño que hace un

trabajo específico bien. La gente le pide mejorar el programa, y se vuelve más complejo.


Zuleta

68

Aún si trata de controlar el diseño, eso puede ocurrir.

Una de las razones por las que ocurre la entropía del software es que cuando añade una

nueva función a un programa, la construye encima del programa existente, a menudo

en una forma en que el programa no estaba destinado a soportar. En esta situación,

puede rediseñar el programa existente para soportar mejor los cambios o puede trabajar

alrededor de esos cambios en sus adiciones.

Aunque en teoría es mejor rediseñar el programa, esto resulta usualmente en trabajo

extra porque la reescritura de su programa viejo traerá nuevos errores y problemas.

Recuerde el viejo adagio de la ingeniería: “Si no está roto, no lo repare.” Sin embargo, si

no rediseña el programa, las adiciones serán más complejas de lo que deberían ser.

Gradualmente, la complejidad adicional traerá problemas mayores. Por lo tanto, hay un

compromiso:

rediseñar causa dolor a corto plazo para aliviar dolor a largo plazo.

La refactorización es un término usado para describir técnicas que reducen el dolor a

corto plazo de rediseñar. Cuando se refactoriza, no cambia la funcionalidad del programa,

si no su estructura interna para hacerlo más comprensible y manejable.

Los cambios de refactorización son usualmente pequeños: renombrar un método, mover un

atributo de una clase a otra, consolidar dos métodos similares en una superclase. Cada

paso es pequeño, pero un par de horas de realizar estos pasos puede hacer mucho bien a

un programa.

La refactorización es hecha más fácil siguiendo los siguientes principios:

No refactorice un programa y añada funcionalidad a la vez. Imponga una

separación clara entre los dos mientras trabaja. Puede cambiar de uno a otro

en pasos cortos – por ejemplo, media hora refactorizando, y una hora

añadiendo nueva funcionalidad.

Asegúrese que tiene buenas pruebas establecidas antes de refactorizar.

Corra las pruebas tan seguido como sea posible; de esa forma sabrá pronto si


Zuleta

69

los cambios han dañado algo.

Haga pasos cortos y deliberados. Mueva un atributo de una clase a otra.

Fusione dos clases similares en una superclase. La refactorización a

menudo involucra hacer muchos cambios localizados que resultan en un

cambio en larga escala. Si mantiene sus pasos pequeños y prueba después de

cada paso, evitará pruebas prolongadas.

Debe de refactorizar cuando:

Añade funcionalidad al programa y encuentra que el código viejo se pone en el

camino. Cuando eso se vuelve un problema, pare añadiendo la nueva

funcionalidad, y refactorice el código viejo.

Tiene dificultades entendiendo el código. La refactorización es una buena

forma de ayudarle a entender el código y preservar ese entendimiento para el

futuro.

A menudo, deseará refactorizar código que alguien más escribió. Cuando haga esto, hágalo

al lado del autor del código o con alguien que lo entienda. Es difícil escribir código en

una forma que otros puedan entender fácilmente.

La refactorización es una técnica muy subutilizada. Ha comenzado a ser reconocida

principalmente en la comunidad Smalltalk. Sin embargo, puede ser una técnica clave

en mejorar el desarrollo del software. Asegúrese de que conoce cómo hacer

refactorización en una forma disciplinada. Una forma de hacerlo es conseguir un mentor

que le enseñe las técnicas apropiadas.


Zuleta

70

Anexo C: Diseño por Contrato

El diseño por contrato es una técnica desarrollada por Bertrand Meyer. La técnica es

una característica central del lenguaje Eiffel; sin embargo, es una técnica valiosa que

puede ser usada con cualquier lenguaje de programación.

En el corazón del Diseño por Contrato se encuentra la aserción. Una aserción es una

sentencia Boleana que nunca debería ser falsa y, por lo tanto es falsa solamente por un error

en el programa. Típicamente, las aserciones son chequeadas durante la depuración y no

durante la ejecución de los programas. Un programa nunca debe asumir que las aserciones

están siendo chequeadas.

El diseño por contrato usa tres tipos de aserciones: precondiciones, poscondiciones, e

invariantes.

Las precondciones y poscondiciones se aplican a las operaciones. Una poscondición es

una sentencia que cómo se debería ver el mundo después de la ejecución de una

operación. Por ejemplo, si definimos la operación “cuadrado” en un número, la

poscondición tomaría la forma resultado = esto * esto, donde resultado es la salida y esto

es el objeto en la cual la operación fue invocada. La poscondición es una forma útil de

decir lo que se hace sin decir cómo se hace – en otras palabras, de separar la interfaz de la

implementación.

Una precondición es una sentencia de cómo esperamos que sea el mundo antes de

ejecutar la operación. Podríamos definir una precondición para la operación “cuadrado”

como esto >= 0. Esta precondición dice que es un error invocar “cuadrado” en un número

negativo y que las consecuencias de hacerlo son indefinidas.

A primera vista, esto parece una mala idea, porque podríamos poner una verificación en

alguna parte para asegurar que “cuadrado” sea invocado apropiadamente. La pregunta

importante es quien es responsable de hacer esto.

La precondición hace explícito que es el llamador el responsable de la verificación. Sin esta

sentencia de responsabilidades explícita podríamos hacer muy poca verificación (porque


Zuleta

71

ambas partes asumen que la otra es la responsable) o mucha (ambas verifican). Mucha

verificación es algo malo, porque lleva a código duplicado lo cual puede incrementar la

complejidad de un programa. Ser explícito sobre quien es responsable ayuda a reducir esta

complejidad. El peligro de que el llamador se olvide de verificar es reducido por el hecho

de que las aserciones son revisadas durante la depuración y las pruebas.

De estas definiciones de precondición y poscondición se puede ver una definición fuerte del

término exception (excepción), que ocurre cuando una operación es invocada con su

precondición satisfecha, pero no puede regresar con su poscondición satisfecha.

Un invariante es una aserción acerca de una clase. Por ejemplo, una clase Cuenta

puede tener un invariante que dice que balance == suma(entradas.cantidad()). El invariante

es “siempre” verdadero para todas las instancias de la clase. Aquí, “siempre” significa

“cuando el objeto se encuentra disponible para tener una operación invocada en él.”

En esencia, esto significa que el invariante es añadido a las precondiciones y poscondiciones

asociadas con todas las operaciones públicas de la clase dada. El invariante puede llegar

a ser falso durante la ejecución de un método, pero debe ser regresado a su estado

verdadero cuando cualquier otro objeto quiera hacer algo con el receptor.

Las aserciones juegan un papel único en la generalización. Uno de los peligros del

polimorfismo es que se podría redefinir una operación en una subclase que sea

inconsistente con la operación de la

superclase. Las aserciones no permiten esto. Los invariantes y poscondiciones de una

clase se deben aplicar a todas las subclases. Las subclases pueden fortalecer estas

aserciones, pero no debilitarlas. Por otro lado, la precondición no puede ser fortalecida pero si

debilitada.

Esto parece extraño al inicio, pero es importante para permitir enlaces dinámicos. Debe ser

capaz de tratar siempre un objeto de la subclase como si fuera una instancia de la

superclase (polimorfismo). Si una subclase fortaleciera su precondición, entonces una

operación de la superclase podría fallar en la subclase.

Esencialmente, las aserciones pueden solamente incrementar las responsabilidades de la


Zuleta

72

subclase. Las precondiciones son una sentencia de un paso de responsabilidad al

llamador; se incrementan las responsabilidades del receptor debilitando las

precondiciones. En la práctica, esto permite mucho mejor control de la generalización y

ayuda a asegurar que las subclases se comportan apropiadamente.

Idealmente, las aserciones deberían ser incluidas en el código como parte de la

definición de la interfaz. Los compiladores deberían ser capaces de activar la verificación

de las aserciones para la depuración y removerla para el código de producción. Varias

etapas de verificación de aserciones pueden ser usadas. Las precondiciones a menudo

dan las mejores oportunidades para atrapar errores con el menor aumento de

procesamiento.

El diseño por contrato es una técnica útil que debe usar cuando programe. Es de particular

utilidad en construir interfaces claras. Solamente Eiffel soporta aserciones como parte del

lenguaje, pero no es un lenguaje ampliamente usado. Es bastante directo añadir mecanismos

para algunas aserciones en C++ y Smalltalk, pero un poco complejo para Java.

El UML no habla mucho de las aserciones, pero pueden ser usadas sin problema. Los

invariantes son equivalentes a reglas de restricciones en los diagramas de clase, y debe usarlas

tanto como sea posible. Las precondiciones y poscondiciones de las operaciones deben

ser documentadas dentro de la definición de las operaciones.

Anexo D: Comparando el UML con otros lenguajes de modelaje

UML y otros Lenguajes de Modelaje.-

Debería estar claro que el Lenguaje de Modelaje Unificado no es una separación radical del

método de Booch, OMT, o OOSE, sino el sucesor legítimo de los tres. Esto significa que

si hoy usted es un usuario de OMT de Booch o OOSE, su entrenamiento, experiencia, y

herramientas serán preservadas, porque el Lenguaje de Modelaje Unificado es un paso

evolutivo natural. El UML será igualmente fácil de adoptar para los usuarios de muchos otros

métodos, pero sus autores deben decidir por sí mismos si adoptar la notación y los conceptos

del UML bajo sus métodos.


Zuleta

73

El Lenguaje de Modelaje Unificado es más expresivo, más limpio y más uniforme que Booch,

OMT, OOSE y otros métodos. Esto significa que hay valor en cambiarse hacia el UML,

porque permitirá en los proyectos el modelaje de cosas que antes no se podían. Los

usuarios de la mayoría de otros métodos y lenguajes de modelaje ganarán valor

cambiándose al UML, porque elimina las diferencias necesarias en notación y

terminología que oscurecen las similitudes de la mayoría de estas aproximaciones.

Con respecto a otros lenguajes de modelaje visual, incluyendo modelaje entidad relación,

diagramas de flujo BPR, lenguajes conducidos por estados, el UML proporciona

expresividad e integridad mejorada.

Una pregunta frecuente es ¿Por qué el UML no soporta diagramas de flujo de datos? Para

ponerlo de forma simple, los diagramas de flujo de datos y otros tipos de diagramas que no

fueron incluidos en el UML no se adecuan limpiamente a un paradigma consistente orientado

a objetos. Los diagramas de actividades realizan mucho de lo que la gente busca en los

diagramas de flujos de datos, y aún más; los diagramas de actividades son también útiles para

modelar flujo de trabajo. Los autores del UML están claramente promoviendo los diagramas

del UML sobre todas las otras formas para proyectos orientados a objetos, pero no

condenan necesariamente a todos los otros diagramas.

Los usuarios de los métodos existentes experimentarán cambios ligeros en la notación,

pero esto no debe tomar mucho aprendizaje y traerá una clarificación de las semánticas

subyacentes. Si las metas de la unificación han sido alcanzadas, el UML será una elección

obvia cuando se inicien proyectos nuevos, especialmente a medida que la disponibilidad de

libros, herramientas y capacitación aumente. Muchas herramientas de modelaje visual

soportan notaciones existentes, tales como Booch, OMT, OOSE y otras; cuando estas

herramientas añadan soporte para UML los usuarios gozarán los beneficios de cambiar

sus modelos actuales a la notación UML sin pérdida de información.

Los usuarios existentes de cualquier método orientado a objetos pueden esperar una

curva de aprendizaje rápida para alcanzar la misma expresividad que previamente

conocían. Uno puede aprender y usar las bases productivamente. Las técnicas más

avanzadas, como el uso de estereotipos y propiedades requerirá cierto estudio, porque

permiten la elaboración de modelos muy expresivos y precisos, que se necesitan solamente


Zuleta

74

cuando el problema lo requiere.

Los objetivos de la unión de esfuerzos fueron mantener la simplicidad, eliminar elementos

de OMT, Booch, y OOSE que no trabajaban en la práctica, y agregar elementos de otros

métodos que eran más efectivos, e inventar nuevos elementos solamente cuando no estaba

disponible una solución existente. Debido a que los autores del UML estaban en efecto

diseñando un lenguaje (aunque uno gráfico), ellos tenían que lograr un balance apropiado

entre minimización (todo es texto y cajas) y sobreingeniería (tener un icono para cada

elemento concebible). Para ese fin, ellos fueron muy cuidadosos al agregar cosas nuevas,

porque no querían hacer al UML complejo innecesariamente. Sobre la marcha, de

cualquier modo, se encontraron algunas cosas ventajosas de agregar porque habían probado

ser útiles en la práctica en otro lenguaje de modelaje.

Hay varios conceptos nuevos que están incluidos en el UML, incluyendo

mecanismos de extensibilidad: Estereotipos, valores agregados, y restricciones; hilos y

procesos; distribución y concurrencia (por ejemplo para modelar ActiveX/DCOM y

CORBA); patrones/colaboraciones; diagramas de actividades (para el modelaje de procesos

del negocio); refinamiento (manejar relaciones entre los niveles de abstracción); interfaces y

componentes; y lenguaje de restricciones.

Muchas de estas ideas estaban presentes en varios métodos individuales y teorías pero el

UML los reúne en una totalidad coherente. Además de estos cambios mayores, hay

muchas otras mejoras localizadas sobre la semántica y la notación de OMT, Booch, y OOSE.

El UML es una evolución del OMT, Booch, OOSE y varios otros métodos orientados a

objetos, y muchas otras fuentes. Estas fuentes variadas incorporaron muchos elementos

diferentes de muchos autores, incluyendo influencias no orientadas a objetos. La notación

del UML es una mezcla de la sintaxis gráfica de fuentes variadas, con una variedad de

símbolos eliminados (porque eran confusos, superfluos, y poco usados) y con algunos

símbolos nuevos agregados. Las ideas en el UML vienen de la comunidad de ideas

desarrolladas por muchas personas diferentes en el campo de orientación a objetos. Los

desarrolladores del UML no inventaron la mayoría de estas ideas; en vez de ello, su

función fue la de seleccionar e integrar las mejores ideas de la orientación a objetos y las

prácticas de la ciencia de la computación. La genealogía actual de la notación y de la


Zuleta

75

semántica subyacente detallada es complicada, de modo que es discutida aquí solamente

para brindar un contexto, no para representar una historia precisa.

Los Diagramas de Casos de Uso son similares en apariencia a aquellos en OOSE.

Los Diagramas de Clases son una mezcla de los diagrama de clase de OMT, Booch y

de otras metodologías orientadas a objetos. Las extensiones (ej: estereotipos y sus

iconos correspondientes) pueden ser definidos para varios diagramas para soportar otros

estilos de modelaje. Los estereotipos, restricciones y valores agregados son conceptos

añadidos en el UML que no existían previamente en los lenguajes de modelaje mayores.

Los diagramas de estados están basados sustancialmente en los estados de David

Harel con modificaciones menores. El diagrama de actividades, que comparte mucha de

la misma semántica subyacente, es similar a los diagramas de flujo de trabajo desarrollados

por muchas fuentes incluyendo fuentes previas a la orientación a objetos.

Los diagramas de secuencia se encontraban en una variedad de métodos orientados a

objetos bajo una variedad de nombres (interacción, trazo de mensajes y trazo de

eventos) y datan de antes de la orientación a objetos. Los diagramas de colaboración

fueron adaptados de Booch (diagrama de objeto), Fusion (gráfico de interacción de

objetos), y un número de otras fuentes.

Las colaboraciones son entidades de modelaje de primera clase, y a menudo son la

base para los patrones.

Los diagramas de implementación (diagramas de componentes y despliegue) son

derivados de los diagramas de módulo y proceso de Booch, pero son están ahora centrados

en componentes, en vez de en módulos y están mejor interconectados.


76

Los estereotipos son uno de los mecanismos de extensión y extienden la semántica del

metamodelo. Los iconos definidos por el usuario pueden ser asociados con estereotipos dados

para adecuar el UML a procesos específicos.

El Lenguaje de Restricción de Objetos (OCL) es usado por el UML para especificar las

semánticas y es proporcionado como un lenguaje para expresiones durante el modelaje.

OCL es un lenguaje de expresión que tiene sus raíces en el método Syntropy y ha sido

influenciado por lenguajes de expresión en otros métodos como Catalysis. La navegación

informal de OMT tiene el mismo fin, donde OCL es formalizado y más extensivo.

Cada uno de estos conceptos tiene más predecesores y muchas otras influencias. El

UML es el producto de una larga historia en las Ciencias de la Computación e Ingeniería de

Software.

Actualizándose de OMT

Proceso

La Técnica de Modelaje de Objetos (OMT) es un proceso y una notación para desarrollo

orientado a objetos. Un paso de preparación es escribir u obtener la sentencia del

problema y describir los problemas a solucionarse. Cuando la sentencia del problema es

escrita, el OMT proporciona tres pasos primarios para definir y construir un sistema: análisis,

diseño de sistemas, y diseño de objetos. Después de la etapa de diseño de objetos, los

modelos pueden ser implementados con código de programación y, en algunos casos, un

esquema de base de datos.

El primer paso, análisis, es el modelaje de conceptos claves dentro del dominio del

problema. Los conceptos claves son encontrados, o deben ser encontrados, en la sentencia del

problema. El análisis es un plano usado para dos próximos pasos: diseño de sistemas y de

objetos. El análisis proporciona tres modelos/vistas diferentes del sistema: un modelo de

objetos, un modelo dinámico, y un modelo funcional. Los resultados del análisis son

diagramas de modelo de objetos, diagramas de estados, diagramas de flujo de eventos, y

diagramas de flujo de datos. Los pasos en el análisis son:


77

1. Escribir u obtener la sentencia del problema.

2. Construir un modelo de objetos (diagrama de modelo de objetos).

3. Desarrollar un modelo dinámico (diagrama de estados y diagramas de flujo de eventos).

4. Construir un modelo funcional (diagrama de flujo de datos).

5. Verificar, iterar, y refinar los tres modelos (objeto, dinámico y funcional).

En OMT, el diagrama de modelo de objetos y el diagrama de estados corresponden a los

diagramas de clases y de estados en el UML. El diagrama de flujo de datos no tiene diagrama

correspondiente en el UML, pero el diagrama de actividades puede ser usado para tipos

similares de modelos (aunque no exactamente los mismos). Un diagrama de flujo de eventos

corresponde a un diagrama de secuencia en el UML.

Después que la etapa de análisis está completa, el diseño del sistema comienza y se

concentra en la arquitectura global del sistema. Los pasos son:

1. Organizar el sistema en subsistemas. Dividir el modelo en paquetes. El subsistema del UML

hace esto.

2. Identificar la concurrencia presente en los problemas. El UML maneja la concurrencia

con los diagramas de colaboración.

3. Asignar los subsistemas a procesadores y tareas. El diagrama de despliegue y el

diagrama de componentes dentro del UML son usados para modelar procesadores y tareas.

4. Escoger las estrategias básicas para implementar los almacenamientos de datos.

5. Determinar los mecanismos para controlar el acceso a los recursos globales.

6. Implementar control de software.

7. Manejar situaciones de frontera.

8. Establecer prioridades.

Los estereotipos son usados para indicar que algunas clases son usadas para manejar recursos

globales, almacenamiento de datos, y así sucesivamente.

El paso final es el diseño de objetos, donde todos los modelos son completamente

especificados y la base para la programación es creada. Los pasos son:


78

1. Extraer operaciones de los modelos dinámicos y los modelos funcionales. Desde una

perspectiva del UML, las operaciones son identificadas de las interacciones que son o

pueden ser expresadas en diagramas de secuencia (diagramas de flujo de eventos en

OMT), diagramas de colaboración, o diagramas de actividades (los cuales son similares a

los diagramas de flujo de datos dentro del OMT).

2. Diseñar algoritmos para implementar las operaciones.

3. Optimizar las vías hacia los datos.

4. Implementar control de software.

5. Ajustar la estructura de las clases para incrementar la herencia.

6. Diseñar la implementación de asociaciones y agregaciones.

7. Determinar la representación en atributos de tipos, valores por defecto, etc.

8. Agrupar las clases y asociaciones en módulos. El UML hace esto con diagramas de

componentes. Como se puede observar, casi todo lo expresado en la notación de OMT

puede ser expresado en el UML. Sin embargo, algunos de los conceptos que en el OMT no

tienen notación la tienen en el UML, como los componentes y los nodos. Los diagramas de

flujo de datos no son parte del UML, pero se pueden manejar especificaciones similares con

un diagrama de actividades. La diferencia principal entre la notación de OMT y el UML es en

como son ilustradas las interacciones. OMT muestra las interacciones con dos puntos focales:

datos y eventos; el UML muestra las interacciones con tres puntos focales: tiempo

(diagrama de secuencia), espacio (diagrama de colaboración), y trabajo

(diagrama de actividades). OMT tiene un principio por el cual las operaciones son

identificadas y definidas mediante los modelos de interacción (flujo de datos y eventos). Este

principio es mantenido en el UML pero con una perspectiva diferente en la interacción. Sin

embargo, esta diferencia no es significante, pues las descripciones de los flujos de datos son

tomadas con parte del flujo de trabajo descrito en un diagrama de actividades.

Notación

Las siguientes figuras muestran las diferencias básicas entre la notación de OMT y el UML.

Los símbolos de OMT se encuentran a la izquierda y los símbolos correspondientes del UML a la

derecha.


79

Autor Obra Lugar de edición

Editorial Año

Booch Jacbson rumbaungh

Object-Orientd Análisis and design UIT Apllications

United States Addison-Wesley Third Edition

2007

Joseph Schmuller UML en 24 Horas Mexico Prentice Hall 2005 Fowler, MartinScott, kendall

UML GOTA A GOTA

Mexico Prentice Hall 1999

Michael Jesse Chonoles and james A. Schardt

UML 2 for Dummies

United States For Dummies 2003

Dan Pilone, Neil Pitman

UML 2.0 in a Nutshel

United States O’ Reilly 2005

Wendy Boggs, Michael Boggs

Mastering UML with racional Rose

United States Sybex 2002

BIBLIOGRAFIA

UNIVERSIDAD SALESIANA DE BOLIVIA INGENIERIA DE...

Documents

Transcript of UNIVERSIDAD SALESIANA DE BOLIVIA INGENIERIA DE...