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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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?.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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á
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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,
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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:
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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...... ..... ..?
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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:
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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 ventas. Proporciona la capacidad de crear, modificar, eliminar y visualizar los datos
de los itinerarios de las rutas.
Controlar Asignaciones 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 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,
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
E-1: El nombre y/o contraseña introducido por el usuario es inválido. El sistema le
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.-
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.-
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.
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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).
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
55
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.
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:
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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,
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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:
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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
Análisis de Sistemas II Lic. Patricia Palacios
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.
Análisis de Sistemas II Lic. Patricia Palacios
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
Análisis de Sistemas II Lic. Patricia Palacios
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.
Análisis de Sistemas II Lic. Patricia Palacios
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.
Análisis de Sistemas II Lic. Patricia Palacios
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
Análisis de Sistemas II Lic. Patricia Palacios
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.
Análisis de Sistemas II Lic. Patricia Palacios
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
Análisis de Sistemas II Lic. Patricia Palacios
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
Análisis de Sistemas II Lic. Patricia Palacios
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.
Análisis de Sistemas II Lic. Patricia Palacios
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
Análisis de Sistemas II Lic. Patricia Palacios
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
Análisis de Sistemas II Lic. Patricia Palacios
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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:
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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:
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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.
Análisis de Sistemas II Lic. Patricia Palacios Zuleta
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