Manual Analisis y Diseño de Sistemas - v0810

Análisis y Diseño de Sistemas I 2

Presentación…………………………………………………………………………………………..3

Modulo A

Semana 1: Conceptos generales.......................................…………......……...4

Semana 2: Casos de Uso......…........................................................................28

Semana 3: Caso práctico dirigido..................................................…..………38

Semana 4: Diagramas Complementarios......….............…………........….………65

Semana 5: Revisión de conocimiento…….........................................…….....74

Semana 6: Requerimientos……….................……………………………..…...……….92

Semana 7: Diagramas de clases ………………………………...............……………109

Semana 8: Caso Práctico – Aplicación diagrama de clases.…………….………115

Semana 9: Repaso de conocimiento……….....................................…………113

Bibliografía: ……………………………………………………………………………………………


PRESENTACIÓN

Esta guía didáctica es un material de ayuda institucional, perteneciente a las

especialidades de computación, Ingeniería de Software e Ingeniería de Redes y

Comunicaciones tiene por finalidad proporcionar los conocimientos de la

implementación y administración de Base de Datos en su primera parte.

La Organización SISE, líder en la enseñanza tecnológica a nivel superior, promueve

la elaboración de materiales educativos, en concordancia a las exigencias de las

tecnologías de estos tiempos, que permiten la creación de nuevas herramientas de

aprendizaje con el objetivo de facilitar el acceso de los estudiantes a la educación en

el marco del desarrollo tecnológico de la informática de las telecomunicaciones.

Esta guía contiene los conocimientos relacionados con el proceso de Ingeniería de

Software Orientado a Objetos. Se centra en el entendimiento del negocio, la captura

de requisitos y el análisis para desarrollar un sistema informático. En el desarrollo del

curso comprobará que el proceso de construcción de software empleando

metodologías y utilizando el Lenguaje Unificado de Modelado nos conduce al

desarrollo de un software con calidad.

El análisis de un modelo de negocio, permitirán que el alumno aplique todos los

conceptos.

Este material en su primera edición, servirá para ayudar a nuestros estudiantes

SISESINOS.


Arreglos

Contenidos

- Ingeniería de software - RUP - UML

____________________________________________________________________________

INGENIERÍA DE SOFTWARE

El término Ingeniería se define como un conjunto de conocimientos y técnicas que permiten

aplicar el saber científico a la utilización de la materia y de las fuentes de energía. Su aplicación

permite la utilización racional de los materiales y de los recursos naturales mediante

invenciones, construcciones y otras realizaciones provechosas para el hombre.


¿Qué es software de computadora?

El software es un elemento lógico del sistema que se desarrolla, no se estropea y en la

mayoría de casos se construye a medida. El software se define también como el producto que

abarca programas que se ejecutan dentro de una computadora de cualquier tamaño y

arquitectura, documentos que comprenden formularios e impresos y datos que combinan

números y texto, y también incluyen representaciones de información de audio, video e

imágenes.

¿Qué es la ingeniería de software?

La Ingeniería del Software es una disciplina o área de la informática o ciencias de la

computación, que ofrece métodos y técnicas para desarrollar y mantener software de calidad

que resuelven problemas de todo tipo.

Esta disciplina trata con áreas muy diversas de la informática y de las ciencias de la

computación, tales como construcción de sistemas operativos, compiladores o desarrollo de

aplicaciones en Intranet / Internet. Aborda todas las fases del ciclo de vida de desarrollo de

cualquier tipo de sistemas de información y es aplicable a una infinidad de áreas tales como:

negocios, investigación científica, medicina, producción, logística, banca y finanzas, derecho,

etc.

El proceso del software

Es el marco de trabajo de las tareas, que se requieren para construir software de alta calidad.

Un proceso de software, define el enfoque que se toma cuando el software es tratado por la

ingeniería. La ingeniería de software es una tecnología multicapa como se muestra a

continuación:

Cualquier enfoque de ingeniería debe apoyarse sobre un compromiso de organización de

calidad. El fundamento de la ingeniería del software es la capa de proceso. Los métodos de la

ingeniería del software indican cómo construir técnicamente el software. Las herramientas de la

ingeniería del software

Proporcionan un enfoque automático o semi-automático para el proceso y para los métodos,

Ej.: CASE.

ENFOQUE DE CALIDAD

PROCESO

MÉTODOS

HERRAMIENTAS


Las fases genéricas de un proceso de software

Las fases genéricas del proceso del software son tres:

La fase de definición La fase de desarrollo La fase de mantenimiento

La fase de definición

Se centra sobre el qué. El que desarrolla el software intenta identificar qué información ha de

ser procesada, que función y rendimiento se desea, qué comportamiento del sistema, qué inter-

fases van a ser establecidas, qué restricciones de diseño existen y qué criterios de validación

se necesitan para definir un sistema correcto. Por tanto, han de identificarse los requisitos clave

del sistema. Tendrán lugar tres tareas clave:

- La ingeniería de sistemas o de información - La planificación de proyectos de software

- Análisis de requisitos La fase de desarrollo

Se centra en el cómo. Durante el desarrollo, se intenta definir cómo han de diseñarse las

estructuras de datos, cómo ha de implementarse la función dentro de una arquitectura de

software, cómo han de implementarse los detalles procedí mentales, cómo han de

caracterizarse interfaces, cómo ha de traducirse el diseño en un lenguaje de programación y

cómo han de realzarse las pruebas. Las tres tareas específicas técnicas que tendrán lugar son:

- El diseño del software - La generación de código - Las pruebas de software La fase de mantenimiento

Se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones

requeridas a medida que evoluciona el entorno del software y a cambios debidos a las mejoras

producidas por los requisitos cambiantes del cliente. Durante la fase de mantenimiento se

encuentran cuatro tipos de cambios:

- Corrección - Adaptación - Mejora - Prevención

Entre las actividades típicas de esta categoría se incluyen:

- Seguimiento y control del proyecto de software - Revisiones técnicas formales que garanticen de calidad del software - Gestión de configuración del software - Preparación y producción de documentos - Gestión de reutilización y de riesgos


Modelos de proceso de software

Para resolver los problemas reales de una industria, se debe incorporar una estrategia de

desarrollo, que acompañe al proceso, a los métodos, las herramientas y las fases genéricas

tratadas en los puntos anteriores. Esta estrategia a menudo se llama Modelo de Proceso o

Paradigma de Ingeniería del Software. Se seleccionará un modelo de proceso para la

ingeniería del software según la naturaleza del proyecto y de la aplicación.

A continuación se presentan los modelos de procesos para la ingeniería del software:

El Modelo Lineal Secuencial El Modelo de Construcción de Prototipos El Modelo DRA Modelos Evolutivos de Proceso del Software:

o El modelo incremental o El modelo espiral o El modelo de desarrollo concurrente

Desarrollo basado en componentes MODELO LINEAL

MODELO INCREMENTAL

Análisis Diseño Codificación Prueba

A D C P

A D C P

A D C P

Entregable o Incremental 1




MODELO PROTOTIPO


Metodología de desarrollo de software

Es una estrategia de desarrollo que, resuelve problemas reales de la industria del software,

explicando como hay que obtener los distintos productos. La Metodología de desarrollo de

software puede seguir uno o varios modelos de proceso de software. Las metodologías se

clasifican en:

Convencionales Estructurales Orientadas a Objetos

Ágiles.

Metodologías de Desarrollo de Software Orientadas a Objetos

No es sorprendente que se proponga una visión orientada a objetos para la creación de

software de computadora, una abstracción que modela el mundo de forma tal que nos ayuda a

entenderlo y administrarlo mejor.

Entre las metodologías destacan:

- Booch—OOD. - Rumbaugh — OMT. - Catalysis. - CBDIe. - Objectory Process 3.8, 4.0,4.1. - Proceso Unificado 1999. - Rational Unified Process 5.1, 5.1.1. Metodologías ágiles

Las metodologías ágiles forman parte del movimiento de desarrollo ágil de software. Se basan

en la adaptabilidad de cualquier cambio como medio para aumentar las posibilidades de éxito

de un proyecto.

Una metodología ágil es la que tiene como principios que:

• Los individuos y. sus interacciones son más importantes que los procesos y las herramientas. • El software que funciona es más importante que la documentación exhaustiva. • La colaboración con el cliente en lugar de la negociación de contratos. • La respuesta delante del cambio en lugar de seguir un plan cerrado. • Se puede decir que, este movimiento empezó a existir a partir de febrero de 2001, cuando se reunieron los representantes de cada una de estas metodologías y terminaron poniendo en común sus ideas en una declaración conjunta.

Entre las metodologías ágiles destacan:

• Extreme Programming (XP) • Método del Desarrollo Dinámico de Sistemas (DSDM) • Desarrollo conducido por Características (FDD) • ICONIX


Rational Unified Process (RUP)

RUP consiste en un conjunto de actividades necesarias para transformar los requerimientos de

usuario en el sistema de software.

Este proceso de trabajo genérico puede ser especializado para diversos tipos de software de

sistemas, diversas áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles

de competencia y diferentes tamaños de proyectos. Existen tres elementos centrales que

definen a RUP y estos son:

a) El conjunto de filosofías y prácticas que son la base para un desarrollo de software exitoso.

Procesos Esenciales

Topics

1. Vision—Develop a Vision 2. Plan—Manage to the Plan 3. Risks—Mitigate Risks and Track Related Issues 4. Business Case—Examine the Business Case 5. Architecture—Design a Component Architecture 6. Prototype—Incrementally Build and Test the Product 7. Evaluation—Regularly Assess Results 8. Change Requests—Manage and Control Changes 9. User Support—Deploy a Usable Product 10. Process—Adopt a Process that Fits Your Project

b) Un modelo de proceso y una librería de contenidos asociados.

Ambos definen el proceso de ingeniería de software base de RUP. Además, permiten al equipo

responsable de desarrollo crear sus propias configuraciones y convertirlo en una metodología

ágil silo desea.


c) Un meta-modelo de proceso básico

Posee elementos de definición de proceso para describir un proceso de ingeniería de software.

Está basado en el Proceso Unificado.

RUP y su estructura El proceso se describe en dos dimensiones o dos ejes:

El eje horizontal representa tiempo y muestra el aspecto dinámico del proceso, expresado en

términos de ciclos, fases, iteraciones, y metas.

El eje vertical representa el aspecto estático del proceso como está descrito en términos de

actividades, artefactos, trabajadores y flujos de trabajo.

Fases del RUP

Inicio: Define el alcance del proyecto. Elaboración: Se desarrolla el Plan del proyecto, la especificación de características y la

arquitectura base. Construcción: Construye el producto. Transición: Traslada el producto a la comunidad del usuario.


Workflows de RUP

También, conocidos como disciplinas o flujos de trabajo del proceso. Un workflow de RUP es

una secuencia de actividades que producen un resultado de valor observable.

Existen dos grupos que son workflows técnicos y workflows de apoyo.

Organización por Componentes

Flujos de trabajo del proceso

Modelo del Negocio: ¿cuál es el problema? Captura de requisitos: ¿Qué hace el sistema? Análisis: ¿Cómo funciona? Diseño: ¿cómo se construye? implementación: Archivos Pruebas Prueba en Servicio

Iteraciones

Cada fase en RUP puede descomponerse en iteraciones. Una iteración es un ciclo de

desarrollo completo que produce como resultado una entrega de producto ejecutable.


EL LENGUAJE DE MODELAMIENTO UNIFICADO - UML

El Lenguaje de Modelamiento Unificado (UML) es un lenguaje estándar que permite visualizar,

especificar, construir y documentar los artefactos del sistema de software. Este lenguaje puso

fin a la ―guerra de metodologías‖ dentro de la comunidad orientada a objetos. Esta orientación

a objetos fue inicialmente concebida por el lenguaje de programación Simula, pero no fue

popular hasta finales de los 80‘s con el advenimiento de los lenguajes de programación como

C++ y Smalltalk. Cuando la programación orientada a objetos se convirtió en un éxito, la

necesidad de metodologías para soportar el desarrollo de software continuó.

Algunas de las metodologías orientadas a objetos que llegaron a ser populares a comienzos de

los 90‘s son:

- Booch: La metodología de Grady Booch para el desarrollo orientado a objetos está disponible

en un sin número de versiones. Booch definió la noción de que un sistema es analizado como

un conjunto de vistas, en el que cada una es descrita por un determinado número de

diagramas de modelo.

La metodología de Booch, en flotación gráfica, es muy extensa. La metodología también

contiene un proceso mediante el cual un sistema es analizado tanto por un punto de vista de

mayor escala como de menor escala, y está basado en un proceso altamente iterativo e

incrementa.

- OMT: La Técnica de Modelamiento de Objetos (OMT) es una metodología desarrollada en

General Electric donde James Rumbaugh trabajó. El sistema es descrito por un determinado

número de modelos; el modelo de objetos, el modelo dinámico, el modelo funcional y el modelo

de casos de uso, los cuales se complementan entre ellos para dar la descripción completa del

sistema. La metodología OMT también contenía varias descripciones prácticas de cómo hacer

un diseño de sistemas, tomando en cuenta las concurrencias y relaciones con las bases de

datos relacionales.


- OOSE/Objectory: Las metodologías Object Oriented Software Engineering-OOSE y

Objectory, ambas fueron construidas con el mismo punto de vista básico postulado por Ivar

Jacobson. La metodología COSE (1. Jacobson, 1994) es la visión de Jacobson de una

metodología orientada a objetos. La metodología Objectory se utiliza para construir un

sinnúmero de sistemas, tan diversos como los sistemas de telecomunicaciones para Ericsson y

sistemas financieros para las compañías WalI Street. Ambas metodologías están basadas en

casos de uso, las cuales definen los requerimientos iniciales del sistema vistos por un actor

externo. Los casos de uso son luego implementados en todas las fases de desarrollo hasta

probar el sistema en el que son empleados para verificar el sistema. Objectory también ha sido

adaptado por la ingeniería de negocios, en la cual las ideas son empleadas para modelar y

mejorar los procesos de negocios.

- Fusion: Esta metodología proviene de Hewlett—Packard (D. Coleman, 1994). Se conoce con

el nombre de metodología de segunda generación, ya que esta basada en las experiencias de

muchas de las metodologías iniciales. Fusion ha mejorado muchas de las ideas previas e

incluye las técnicas para la especificación de operaciones y la interacción entre objetos. La

metodología tiene un gran número de diagramas de modelos.

- CoadlYourdon: La metodología Coad/Yourdon, también conocida como OOAJOOD, fue uno

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

metodología era bastante simple y fácil de aprender y, como tal, funcionaba bien para iniciar a

los novatos en las ideas y terminologías de la tecnología orientada a objetos. Sin embargo, la

flotación y metodología no podían aumentarse a una escala mayor, sino que funcionaban tan

sólo con sistemas muy limitados. En consecuencia, esta metodología es raramente utilizada

hoy en día.

Cada una de estas metodologías tenían sus propias notaciones (los símbolos usados para

dibujar los modelos orientado a objetos), procesos (qué actividades realizar en las distintas

etapas de desarrollo), y herramientas (las herramientas CASE que soporten la flotación y

proceso). Esto hace que la elección de una metodología sea una decisión bastante importante,

y frecuentemente lleva a discusiones acaloradas y debates sobre qué metodología es la

―mejor‖, ―más avanzada‖, y la ―correcta‖ para utilizarse en un proyecto específico. Y, con este


tipo de discusiones, raramente había una buena respuesta, ya que todas las metodologías

tenían sus propias fortalezas y debilidades. Los desarrolladores con experiencia

frecuentemente tomaban una metodología como base, y luego tomaban ―prestado‖ algunas

ideas y soluciones de otras. En la práctica, la diferencia entre las metodologías no era tan

significativa, y a medida que el tiempo transcurría y las metodologías se desarrollaban, crecían

hasta parecerse entre ellas. Esto fue observado por mucho de los gurus en metodologías,

quienes empezaron a buscar formas de cooperar.

HISTORIA DE UML

Grady Booch y James Rumbaugh, en Rational Rose Corporation, comenzaron su trabajo en

1994. Su meta fue crear una nueva metodología, ―Metodología

Unificada‖, la cual une las metodologías Booch y OMT-2 del cual Rumbaugh fue el

desarrollador principal. En 1995, lvar Jacobson, el hombre detrás de las metodologías OOSE y

Objectory, se les unió. Rational Software también compró

Objetive Systems, la compañía sueca que desarrolló y

distribuyó Objectory. En este punto, los futuros

desarrolladores de UML también se dieron cuenta de que

su trabajo tenía como objetivo crear un lenguaje de

modelamiento estándar, y renombraron su trabajo como

―El Lenguaje Unificado de Modelamiento‖. Tener éxito en

establecer un lenguaje de modelamiento estándar es una

tarea más simple que hacer las mismas cosas para un

proceso, a partir de que un proceso difiere

substancialmente entre distintas compañías y culturas. Es

incierto si es del todo posible crear un proceso estándar

que pueda ser utilizado por todos.

Booch, Rumbaugh, y Jacobson lanzaron un número de

versiones preliminares de UML a la comunidad orientada a objetos. Esto les permitió

retroalimentarse y les dio muchas ideas y sugerencias para incorporarlas y así mejorar el

lenguaje. La versión 1.0 del Lenguaje de Modelamiento Unificado fue lanzada en enero de

1997 y actualmente se encuentra en la versión 2.0

Aunque las principales partes del UML están basadas en las metodologías de Booch, OMT, y

OOSE, estos diseñadores de metodologías también incluyeron conceptos de otras

metodologías. Por ejemplo, el trabajo de David Harel sobre los diagramas de estado ha sido

adoptado en los diagramas de estado de UML; partes de la notación de la metodología Fusion

para numerar operaciones han sido incluidas en los diagramas de colaboración; el trabajo de

Gamma-Helm-Johnson-Vlissides en patrones y cómo documentarlos ha inspirado la

elaboración de detalles en los diagramas de clases.

ESTANDARIZACIÓN OMG Cuando comenzó el trabajo con UML, éste pretendía establecerse por sí mismo como el

estándar de facto, lo cual significa que a través del uso práctico por parte de los

desarrolladores podría ser reconocido como el principal lenguaje de modelamiento. Sin

embargo, cuando OMG requirió un lenguaje de modelamiento UML se dieron cuenta de que

podían hacer de él un una mayor demanda de una definición más formal y estándar, los

desarrolladores de estándar formal. Ello dio lugar a precisa del UML y mejora de la calidad del

lenguaje. Una estandarización formal es importante para muchas de las industrias antes de

aventurarse a usar una nueva tecnología. OMG decidió usar UML como su estándar y está

trabajando en los detalles finales de la especificación. URL: www.omg.org

http://www.omg.org/


LENGUAJE DE MODELAMIENTO Y METODOLOGIA Existen diferencias importantes entre una metodología y un lenguaje de modelamiento. Una

metodología es una forma explícita de estructurar nuestras acciones y pensamientos. Una

metodología le dice al usuario qué hacer, cómo hacerlo, cuándo hacerlo, y por qué hacerlo (el

propósito de una actividad específica). Las metodologías contienen modelos, y estos modelos

se usan para describir algo y para comunicar los resultados de la utilización de una

metodología. La principal diferencia entre una metodología y un lenguaje de modelamiento es

que el lenguaje de modelamiento carece de los procesos o instrucciones para saber qué hacer,

cómo hacerlo, cuándo hacerlo, y por qué hacerlo.

Cuando construimos modelos, también estructuramos nuestros pensamientos. Un modelo es

siempre un modelo de algo y éste tiene un propósito. Si el modelo no tiene un propósito

explícito, causará problemas, ya que nadie sabrá cómo o porqué usarlo. Un modelo se expresa

en un lenguaje de modelamiento. Un lenguaje de modelamiento contiene notaciones, los

símbolos usados en los modelos, y un conjunto de reglas que indican cómo hacerlo. Las reglas

son de sintaxis, semánticas, y pragmáticas.

La sintaxis nos dice cómo deberían lucir los símbolos y cómo se combinan los símbolos en

lenguaje de modelamiento. La sintaxis se compara con las palabras en lenguaje natural; es

importante saber cómo deletrearlas correctamente y cómo juntar distintas palabras para formar

una oración. Las reglas semánticas nos dice qué significa cada símbolo y cómo debería ser

interpretado por sí mismo y, en el contexto de otros símbolos, son comparados con los

significados de las palabras en un lenguaje natural.

Las reglas pragmáticas definen las intenciones de los símbolos a través del cual el propósito de

un modelo es alcanzado y se vuelven entendibles para otros. Esto corresponde en el lenguaje

natural con las reglas de construcción de oraciones las cuales son claras y entendibles. Por

ejemplo, los libros sobre el estilo de escritura se conocen como pragmáticos en dicho sentido.

Para usar bien un lenguaje de modelamiento, es necesario aprender todas estas reglas. La

buena noticia es que UML es mucho más fácil de comprender que un lenguaje natural. La

mayoría de los lenguajes de modelamiento cubre sólo sintaxis y semántica. El pragmatismo es

un poco difícil cuando se trata de describir, ya que no se puede formalizar, tan sólo puede

actuar como guía.

Naturalmente, incluso cuando se domina el lenguaje, no hay garantía de que los modelos

producidos sean buenos. Así como escribir una historia en un lenguaje natural, e lenguaje es

tan solo una herramienta que el autor debe dominar. Más aun depende del autor escribir una

buena historia.

Revisión DE UML El Lenguaje de Modelamiento Unificado tiene un gran campo de acción. Puede ser usado para

el modelamiento de negocios, modelamiento de software en todas las fases de desarrollo y

para todo tipo de sistemas, y modelamiento general de cualquier tipo de construcción que

tenga tanto una estructura estática como un comportamiento dinámico. Para poder alcanzar

estas capacidades, el lenguaje se define para que sea lo suficientemente extenso y genérico

para permitir el modelamiento de tanta diversidad de sistemas, evitando la extrema

especialización y complejidad.

La revisión describe las diferentes partes del UML:


Vistas: Las vistas muestran los distintos aspectos de los sistemas a modelar. Una vista no es

un gráfico, sino una abstracción, la cual consiste en un número de diagramas. Sólo al definir un

determinado número de vistas, que muestran un aspecto en particular del sistema, puede

construirse una figura completa del sistema. Las vistas también vinculan el lenguaje de

modelamiento con el proceso / metodología elegida para el desarrollo.

Diagramas: Los diagramas son los gráficos que describen los contenidos en una vista. UML

tiene nueve tipos de diagramas distintos que se usan en combinación para proveer todas las

vistas del sistema.

Elementos de modelo: Los conceptos usados en los diagramas son elementos de modelo que

representan conceptos orientado a objetos comunes tales como clases, objetos, y mensajes, y

las relaciones entre estos conceptos los cuales incluyen los términos de asociación,

dependencia, y generalización. Un elemento del modelo se usa en varios diagramas diferentes,

pero siempre tiene el mismo significado y símbolo.

Mecanismos generales: Los mecanismos generales proveen comentarios adicionales,

información, o semánticas acerca de un elemento de modelo. También, proveen mecanismos

de extensión para adaptar y extender el UML a un proceso / metodología específica,

organización, o usuario.


VISTAS Modelar un sistema complejo es una tarea extensa. Un gráfico simple no puede capturar toda

la información necesaria para definir un sistema. Un sistema se describe con un número de

aspectos diferentes: funcional (su estructura estática e interacciones dinámicas), no funcional

(requerimientos oportunos, confiabilidad, implementación, etc.), y aspectos organizacionales

(organización del trabajo, elaboración de módulos de código, etc.).

Por lo tanto, un sistema se describe en una serie de vistas, en las que cada una representa una

proyección de la descripción del sistema completo y muestra un aspecto en particular del

sistema.

Cada vista se describe con una serie de diagramas que contienen información que enfatizan un

aspecto en particular del sistema. En parte hay cierta concurrencia, de tal forma que un

diagrama puede realmente ser parte de más de una vista. Observando el sistema desde

diferentes vistas, es posible concentrarse en un aspecto del sistema a la vez. Un diagrama en

una vista en particular debería ser lo suficientemente simple para ser fácilmente comunicado,

más aún que sea coherente con los otros diagramas y vistas, de tal forma que la figura

completa del sistema sea descrita por todas las vistas juntas (a través de sus respectivos

diagramas).

Estas vistas son:

Vista de Casos de Uso: Una vista que muestra la funcionalidad del sistema percibida por

actores externos.

Vista Lógica: Una vista que muestra cómo la funcionalidad es diseñada dentro del sistema en

términos de la estructura estática del sistema y comportamiento dinámico.

Vista de Componentes o Implementación: Una vista que muestra la organización de los

componentes de código.


Vista de Concurrencia o Procesos: Una vista que muestra las concurrencias en el sistema y

encamina los problemas de comunicación y sincronización que están presentes en un sistema

con concurrencias.

Vista de Despliegue o Implantación: Una vista que muestra la implementación del sistema

como una estructura física con computadoras y dispositivos llamados nodos. Cuando se

escoge una herramienta para dibujar los diagramas, hay que asegurarse de que sea fácil la

navegación entre una vista y otra. Además, para poder ver como una función es diseñada para

funcionar dentro de un diagrama, la herramienta debería hacer fácil el cambiar ya sea a la vista

de casos de uso, para ver como la función es descrita por un usuario externo o a la vista de

despliegue para ver como la función es distribuida en la estructura física.

Vista de Casos de Uso

La vista de Casos de Uso describe la funcionalidad que el sistema debería cumplir tal y como

es percibida por actores externos. Un actor interactúa con el sistema: puede ser un usuario o

algún otro sistema. La vista de casos de uso es para los clientes, diseñadores, desarrolladores,

y evaluadores. Está descrito en los diagramas de casos de uso y ocasionalmente en diagramas

de actividades. El uso que se desee del sistema se describe como una serie de casos de uso

en la vista de casos de uso, en el que un caso de uso es una descripción genérica de un uso

del sistema (una función requerida). La vista de casos de uso es céntrica. Esto quiere decir que

sus contenidos encaminan el desarrollo de las otras vistas. El objetivo final del sistema es

proveer la funcionalidad descrita en esta vista (junto con algunas propiedades no funcionales);

más aún, esta vista afecta a las otras. Esta vista es, también, empleada para validar y

finalmente verificar el sistema mediante la comprobación de la vista de casos de uso con los

clientes (se pregunta ―Es esto lo que desea‖) y se contrasta con el sistema no terminado (se

pregunta ―El sistema trabaja tal y como fue especificado‖).


Vista Lógica

La vista lógica describe como la funcionalidad se provee. Es principalmente para diseñadores y

desarrolladores. En contraste con la vista de casos de uso, la vista lógica se enfoca en el

interior del sistema. Describe tanto la estructura estática (clases, objetos, y relaciones) como

las colaboraciones dinámicas que ocurren cuando, entre los objetos, se envían mensajes para

proveer una determinada función. Las propiedades tales como persistencia y concurrencias

también son definidas, así mismo las interfaces y la estructura interna de clases.

La estructura estática se describe en diagramas de objetos y clases. El modelamiento dinámico

se describe en diagramas de actividades, colaboración, secuencia y estado.

Vista de Componentes

La vista de componentes es una descripción de los módulos de implementación y sus

dependencias. Es principalmente para los desarrolladores. Los componentes son diferentes

tipos de módulos de código fuente, binario o ejecutable. Estos se muestran con sus respectivas

estructuras y dependencias. Información adicional acerca de los componentes, tales como

asignación de recursos (responsabilidad para un componente), u otra información

administrativa, como un reporte de progreso para el trabajo de desarrollo, también pueden ser

incluidos.


Vista de Proceso

La vista de proceso tiene que ver con la división del sistema en procesos y procesadores. Este

aspecto, el cual es una propiedad no funcional del sistema, permite un uso de recursos

eficiente, la ejecución en paralelo y la manipulación de eventos asíncronos desde el entorno.

Detrás de la división del sistema, en hilos concurrentes de control ejecutables, la vista debe

también resolver la comunicación y sincronización de estos hilos. La vista de proceso es para

los desarrolladores e integradores del sistema y consiste de diagramas dinámicos (estado,

secuencia, colaboración, y diagramas de actividades).

Vista de Despliegue

Muestra el despliegue físico del sistema, tales como computadoras y dispositivos (nodos) y

como se conectan entre ellos. La vista de despliegue es para los desarrolladores, integradores,

y evaluadores. Se representa con el diagrama de despliegue. Esta vista también incluye una

relación que muestra cómo los componentes son implementados en la arquitectura física; por

ejemplo, qué objetos se ejecutan en sus respectivas computadoras.


DIAGRAMAS Los diagramas son los gráficos que realmente muestran los símbolos del modelo para ilustrar

aspectos o particularidades del sistema. Un modelo de sistema típicamente tiene varios

diagramas de cada tipo. Un diagrama es parte de una vista específica; y cuando es dibujado,

es usualmente asignado a una vista. Algunos tipos de diagrama pueden ser parte de varias

vistas, dependiendo de los contenidos del diagrama.

A continuación, se describirán los conceptos básicos detrás de cada diagrama. Todos los

detalles referentes a los diagramas, su sintaxis, su significado exacto y cómo interactúan se

describirán a lo largo de los capítulos del curso.

Diagrama de Casos de Uso

Un diagrama de casos de uso muestra un número de actores externos y su conexión a los

casos de uso que el sistema provee. Un caso de uso es la descripción de una funcionalidad (un

uso específico del sistema) que el sistema provee. La descripción del caso de uso real, es

normalmente, hecho en un archivo de texto plano como una propiedad de documentación del

símbolo de caso de uso, pero también puede ser descrita usando un diagrama de actividades.

Los casos de uso se describen sólo como son vistos externamente por el actor (el

comportamiento del sistema como el usuario lo percibe) y no describe como la funcionalidad es

provista dentro del sistema. Los casos de uso definen los requerimientos funcionales del

sistema.

Diagrama de Clases

Un diagrama de clases muestra la estructura estática de las clases en el sistema. Las clases

representan las ―cosas‖ que son manipuladas en el sistema. Las clases pueden estar

relacionadas entre ellas en distintas formas: asociada (conectada entre ellas), dependiente

(una clase depende / usa otra clase), especializada (una clase es una especialización de otra

clase) o empaquetada (agrupada como una unidad). Todas estas relaciones se muestran en un

diagrama de clases junto con la estructura interna de las clases en términos de atributos y

operaciones. El diagrama es considerado estático cuando la estructura descrita es siempre

válida en cualquier punto del ciclo de vida del sistema.

Un sistema típicamente tiene un determinado número de diagramas de clases, no todas las

clases se insertan en un único diagrama de clases, y una clase puede participar en varios

diagramas de clases.


Diagrama de Objetos

Un diagrama de objetos es una variante de un diagrama de clases y usa casi una flotación

idéntica. La diferencia entre ambos es que un diagrama de objetos muestra un número de

instancias de objetos de clases en vez de las clases reales. Por lo tanto, un diagrama de

objetos es un ejemplo de un diagrama de clases que muestra una posible imagen del sistema

en ejecución: cómo el sistema se vería en algún punto en el tiempo. Se usa la misma notación

de un diagrama de clases, con dos excepciones: los nombres de los objetos se subrayan y

todas las instancias en una relación se muestran.

Los diagramas de objetos no son tan importantes como los diagramas de clases, pero pueden

ser utilizados para ejemplificar un diagrama de clases complejo mostrando como las instancias

reales y las relaciones se verían. Los diagramas de objetos también se usan como parte de los

diagramas de colaboración, en la que la colaboración dinámica entre un conjunto de objetos se

muestra.

Diagrama de Estados

Un diagrama de estados es típicamente un complemento de la descripción de una clase.

Muestra todos los posibles estados que los objetos de una clase pueden tener, y qué eventos

provocan el cambio de estado. Un evento puede ser otro objeto que le envía un mensaje, por

ejemplo, que un determinado tiempo ha transcurrido, o que alguna condición se ha cumplido.

Un cambio de estado se llama transición. Una transición también puede tener una acción

asociada a ella que específica qué se debería hacer con relación a la transición de estado.

Los diagramas de estado no se hacen para todas las clases, es sólo para aquellas que tengan

un número de estados bien definidos y en donde el comportamiento de la clase es afectado y

cambiado por los distintos estados. Los diagramas de estado también pueden ser hechos para

todo el sistema en su totalidad.


Diagrama de Secuencias

Un diagrama de secuencias muestra una colaboración dinámica entre un número determinado

de objetos, como se muestra en la figura. El aspecto importante de este diagrama es que

muestra una secuencia de mensajes enviados entre objetos. También muestra una interacción

entre objetos, algo que pasará en algún punto específico en la ejecución del sistema. El

diagrama consiste en un determinado número de objetos mostrados con líneas verticales. El

tiempo transcurre en forma descendente en el diagrama el cual muestra el intercambio de

mensajes entre los objetos a medida que el tiempo transcurre en la secuencia o función. Los

mensajes se muestran como líneas con flechas que indican mensajes entre las líneas

verticales de los objetos. Las especificaciones del tiempo y otros comentarios se agregan en un

script a un costado del diagrama.

Diagramas de Colaboración

Un diagrama de colaboración muestra una colaboración dinámica, así como lo hace un

diagrama de secuencia. Frecuentemente queda a criterio del usuario mostrar la colaboración

ya sea en un diagrama de secuencias o como un diagrama de colaboración. Además de

mostrar el intercambio de mensajes (interacción), el diagrama de colaboración muestra a los

objetos y sus relaciones (algunas veces referidas como el contexto). Ya sea que use un

diagrama de secuencias o un diagrama de colaboración, frecuentemente, se puede decidir por

lo siguiente: Si el aspecto más importante de enfatizar es el tiempo o secuencia, escoja el

diagrama de secuencias; en cambio, si importa enfatizar el contexto, escoja el diagrama de

colaboración. La interacción entre los objetos se muestra en ambos diagramas.

Los diagramas de colaboración se muestran como diagramas de objetos, donde un número

determinado de objetos se muestran junto con sus relaciones (al usar la notación del diagrama

de clases / objetos). Las flechas que representan mensajes se dibujan entre los objetos para

mostrar el flujo de mensajes entre los objetos. Los mensajes son rotulados, los cuales entre

otras cosas, muestran el orden en el cual los mensajes son enviados. Esto también puede

mostrar condiciones, iteraciones, valores de retorno, etc. Una vez que un desarrollador esté

familiarizado con la sintaxis de rotular mensajes, puede leer la colaboración, y seguir el flujo de

ejecución y el intercambio de mensajes. Un diagrama de colaboración también puede contener

objetos activos, aquellos que se ejecutan en forma concurrente con otros objetos.


Diagrama de Actividades

Un diagrama de actividades muestra un flujo de secuencias de actividades. El diagrama de

actividades es típicamente utilizado para describir las actividades ejecutadas en una operación,

aunque también puede ser empleado para describir otros flujos de actividades, como un caso

de uso o una interacción. El diagrama de actividades consiste en estados de acciones, el cual

contiene. una especificación de una actividad a ser ejecutada (una acción). Un estado de

acción dejará el estado cuando la acción ha sido realizada (un estado en un diagrama de

estados necesita de un evento explícito antes de dejar el estado). Por lo tanto, el control fluye

entre los estados de acción, los cuales están conectados unos con otros. Las decisiones y

condiciones, así como también la ejecución paralela de estados de acción, también pueden ser

mostradas en el diagrama. El diagrama también puede contener especificaciones de mensajes

que son enviados o recibidos como parte de las acciones realizadas.


Diagrama de Componentes

Un diagrama de componentes muestra la estructura física del código en términos de

componentes de código. Un componente puede ser un componente de código fuente, binario, o

ejecutable. Un componente contiene información sobre las clases lógicas o clases que

implementa: por lo tanto. crea una relación entre la vista lógica y la vista de componentes. La

dependencia entre los componentes se muestra y se hace más fácil analizar cómo otros

componentes se ven afectados por cambios en un componente. Los componentes también se

pueden mostrar con cualquiera de las interfaces que exponen, corno as interfaces OLE/COM;

además, pueden ser agrupadas en paquetes.

Diagrama de Despliegue

El diagrama de despliegue muestra la arquitectura física de hardware y software en el sistema.

Puede mostrar las computadoras y dispositivos reales (nodos) junto con las conexiones que

presentan entre ellos; también, puede mostrar el tipo de conexiones. Dentro de los nodos, los

componentes ejecutables y objetos son ubicados con el fin de mostrar qué unidades de

software se ejecutan en determinados nodos. También puede mostrar las dependencias entre

los componentes.

Como hemos dicho anteriormente, el diagrama de despliegue, mostrado en la vista de

despliegue, describe la arquitectura física actual del sistema. Esto es más que la descripción

funcional en la vista de casos de usos.


Arreglos

Contenidos

- Casos de Uso - Actores / Caso de Uso - Relación entre caso de uso - Modelo de Negocio

____________________________________________________________________________

CASOS DE USO Un modelo de caso de uso es un modelo de como diferentes tipos de usuarios interactúan con

el sistema para resolver un problema. Como tal, este describe las metas de los usuarios, las

interacciones entre los usuarios y el sistema y el comportamiento requerido del sistema para

satisfacer esas metas.

Un modelo de caso de uso consta de un número de elementos del modelo. Los elementos del

modelo más importantes son: casos de uso, actores y las relaciones entre estos.

Un diagrama de caso de uso es usado para mostrar gráficamente un subconjunto del modelo

para simplificar las comunicaciones. Típicamente tendrá varios diagramas de caso de uso

asociados a un modelo dado, cada uno mostrando un subconjunto de los elementos del

modelo relevantes para un propósito particular. El mismo elemento del modelo podría ser

mostrado en varios diagramas de caso de uso, pero cada instancia debe ser consistente. Si se

usan herramientas para administrar el modelo de caso de uso, esta restricción de consistencia

es automatizada tal que cualquier cambio a los elementos del modelo (por ejemplo cambiar el

nombre) será automáticamente reflejado en cada uno de los diagramas de caso de uso que

muestran este elemento.


El modelo de caso de uso podría contener paquetes que son usados para estructurar el

modelo, simplificar el análisis, las comunicaciones, la navegación, el despliegue, el

mantenimiento y la planeación.

Muchos de estos modelos de caso de uso son hechos en texto, con el texto capturado en la

Use-Case Specifications que son asociadas con cada elemento del modelo de casos de uso.

Estas especificaciones describen el flujo de eventos del caso de uso.

El modelo de caso de uso sirve como un hilo unificador entre los desarrolladores del sistema.

Es usado como la primera especificación de los requisitos funcionales para el sistema, como la

base para el análisis y diseño, como una entrada para planear la iteración, como las bases

para definir los casos de prueba y como las bases para la documentación del usuario.

Elementos básicos del modelo El modelo de caso de uso contiene, como mínimo, los siguientes elementos básicos del

modelo.

Actor

Un elemento del modelo para representar cada actor. Las propiedades incluyen los nombres de

los actores y una breve descripción.

Un Actor es una entidad que interactúa con el sistema, por ejemplo:

- Un usuario

- Un sistema externo que requiere sus servicios

- Un sistema externo que provee servicios

Un Actor está fuera de los límites del sistema, no es un objeto del sistema, estos inician y

llevan a cabo los casos de uso.

Un Actor es la abstracción de un Rol, no es una persona. Un usuario puede jugar múltiples

roles, dos personas podrían jugar el mismo rol.

En un caso de uso puede existir roles primarios y secundarios.

Actor Primario = Inicia el caso de uso

Actor Secundario = Participa en el caso de uso.


Caso de Uso

Un elemento del modelo para representar cada caso de uso. Las propiedades incluyen el

nombre y la especificación del caso de uso.

Un caso de uso describe una situación de uso del sistema interactuando con actores. Es

representado por una elipse.

En UML, cada caso de uso debe tener al menos un actor. Esta forma de verlo nos ayudará a

verlo como un todo.

Un caso de uso ofrece una vista estática de las relaciones entre diferentes casos de uso y

actores.

Asociaciones Las asociaciones son usadas para describir las relaciones entre actores y los casos de uso en

los que ellos participan. Estas relaciones son conocidas comúnmente como una "asociación

comunicante".

Los vínculos pueden ser de 02 tipos:

Include y Extend:

Include.- Ocurre cuando se tiene una porción de comportamiento que es similar en mas de un

caso de uso y no se quiere copiar la descripción de tala conducta.

Extend.- Se usa cuando se tiene un caso de uso similar a otro, pero que hace un poco más.


Modelo de Negocio. ¿Porqué modelar negocio antes de modelar sistema?

El sistema a desarrollar manejará información que pertenece al negocio, será utilizado en

organizaciones que ejecutan procesos de negocios cada vez más automatizable, se adaptará

al entorno de la organización que lo utilizará.

Para identificar con facilidad dónde están sus problemas u oportunidades de crecimiento y

mejora. Desde la perspectiva de los sistemas no es posible automatizar procesos que no estén

claramente definidos.

La disciplina Modelamiento del Negocio describe la organización actual y desarrolla la visión de

una nueva. Utilizando esta visión como base, define los procesos, roles y responsabilidades de

la organización en dos partes: un modelo de casos de uso de negocio y un modelo de análisis

de negocio.

Los propósitos del modelo del negocio son:

Entender los problemas actuales de la organización Asegurarse que clientes, usuarios, desarrolladores y otros involucrados tengan igual

entendimiento de la empresa Proveer una vista estática de la estructura de la organización y una vista dinámica

dentro de los procesos de la organización.


Arreglos

Contenidos

- Caso práctico dirigido. - Modelo de Negocio

____________________________________________________________________________

Ejercicio: Caso PECSA:


PERUANA DE ESTACIONES DE SERVICIO S.A.C.

Proyecto de Sistema

Análisis Estratégico

Versión 1.5


HISTORIAL DE REVISIONES

FECHA DESCRIPCIÓN REVISADO POR: RÚBRICA

04-06-10 Javier Napán


Tabla de Contenido

Contenido

1. Información del Negocio

2 Estrategias:

3 Organización:

Modelo de Negocio .

1. Descripción del Negocio:

2. Objetivos de Negocio:

3. Casos de Uso de Negocio:

4. Actores de Negocios:

Modelo de Análisis

1. Entidades de Negocio

2. Realizaciones de Caso de Uso

3. Trabajadores de Negocio

Modelo de Casos de Uso

1. Casos de Uso

2. Especificaciones de Casos de Uso

Modelo de Conceptual .

1. Diagrama de Clases

2. Diagramas de Estado

3. Diagrama de Colaboración .

4. Diagrama de Secuencia


1. Información del Negocio

1.1 Nombre:

Nombre comercial: PECSA (ChevronLubricants)

Razón Social: Peruana De Estaciones S.A.C.

1.2 Giro:

Venta de Combustibles

1.3 Dirección:

Av. Tomás Marzano 4070 - Surco

1.4 Teléfono:

4482770

1.5 StakeHolder:

Patrick Meza Ortega

2. Estrategias:

2.1 Visión del Negocio:

Es una empresa integrada anticipada al futuro y a la competencia

en permanente exploración de nuevas oportunidades,

explotándolas en armonía con el medio ambiente, las

necesidades de nuestros clientes, la satisfacción de nuestros

consumidores, las expectativas de nuestro personal y de nuestros

accionistas.

2.2 Misión del Negocio:

Ser una empresa eficiente especializada en la distribución de

combustible, dirigida a satisfacer las necesidades de nuestros

clientes, brindando un servicio de calidad y un soporte

permanente q impulse sus ventas y enriquezca sus ofertas de

bienes y servicios en beneficio de los consumidores


2.3 Objetivos:

2.3.1 Estratégico:

El planeamiento estratégico de Peruana de

Estaciones de Servicio S.A.C. incluye planes de

desarrollo especificado como Ser una corporación

integrada, líder en proveer soluciones a los

requerimientos de energía de nuestros mercados,

ágil y anticipada al futuro y a la competencia, en

permanente búsqueda de nuevas oportunidades de

negocios, comprometida con la creación de valor

para nuestros clientes, personal, proveedores y

accionistas, en armonía con el medio ambiente y la

responsabilidad social.

2.3.2 Tácticos:

Los objetivos del proceso de abastecimiento son

los siguientes:

Generar correctamente las mediciones de

la cantidad de producto que se almacena

en los tanques de combustible líquido y

gaseoso.

Generar armoniosamente los

requerimientos de producto para

satisfacer la demanda de los

consumidores.

Constatar el correcto abastecimiento de

los productos en las diferentes válvulas de

llenado de los tanques, y corroborar la

cantidad de producto suministrado,

obedeciendo los protocolos de seguridad

establecidos para este proceso.


3. Organización:

3.1 Organigrama Funcional:

Administrador

Coordinador Administrativo

Coordinador Operativo

Jefe de Pista Tarde Jefe de Pista Mañana Jefe de Pista Noche

Representantes de

Servicio

Representantes de

Servicio

Representantes de

Servicio



Proyecto De Sistema

Modelo de Negocio

Versión 1.0




04-06-10 Modelo de Negocio Javier Napan


1. Descripción del Negocio:

Peruana de estaciones SAC, pertenece al Grupo PECSA; esta es una

corporación privada de capitales peruanos conformada por las empresas

Peruanas y se ha consolidado como la marca privada, completamente

peruana, más importante en la distribución y comercialización de

combustibles y derivados de hidrocarburos en el ámbito nacional. Las

actividades de la empresa que conforma el grupo está orientada a

brindar energía a empresas y personas a través de la distribución y

comercialización de gasolina, diesel, gas licuado de petróleo (GLP)

vehicular, gas natural vehicular (GNV) y lubricantes. Los diversos

productos de calidad que comercializa, el servicio diferenciado en

constante búsqueda de la excelencia y la eficiente capacidad de

distribución para llegar a todos los mercados que abastece, le permiten

al Grupo PECSA garantizar una estructura de negocio capaz de

desempeñarse con éxito en un mercado altamente competitivo.


2. Objetivos de Negocio:

El planeamiento estratégico de

Peruana de Estaciones de Servicio

S.A.C. incluye planes de desarrollo

especificado como Ser una

corporación integrada, líder en

proveer soluciones a los

requerimientos de energía de

nuestros mercados, ágil y anticipada

al futuro y a la competencia, en

permanente búsqueda de nuevas

oportunidades de negocios,

comprometida con la creación de

valor para nuestros clientes,

personal, proveedores y accionistas,

en armonía con el medio ambiente y

la responsabilidad social.

Generar correctamente las mediciones de la cantidad de producto que se almacena en los tanques de combustible líquido y gaseoso.

Generar armoniosamente los requerimientos de producto para satisfacer la demanda de los consumidores.

Constatar el correcto abastecimiento de los productos en las diferentes válvulas de llenado de los tanques, y corroborar la cantidad de producto suministrado, obedeciendo los protocolos de seguridad establecidos para este proceso.


3. Casos de Uso de Negocio:

Abastecimiento de Combustible

4. Actores de Negocios:

LVM Inversiones

PGN - Cálida


Arreglos

Contenidos

- Modelo de Análisis de Negocio - Representar estructura y workflow de proceso de negocio

o Diagrama de Actividad ____________________________________________________________________________


Modelo de Análisis de negocio El modelo del análisis de negocio describe la realización de los casos del uso del negocio

modelando la interacción entre los trabajadores del negocio y las entidades de negocio.

El propósito del modelo del análisis de negocio es describir cómo se ejecutan los casos del uso

del negocio.

Elementos del análisis del negocio:

Trabajadores del negocio identificados previamente. Entidades del negocio identificadas previamente. Asociaciones entre los trabajadores del negocio y las entidades del negocio. Diagramas de Realización:

o Diagrama de Clases de Negocio o Diagrama de Actividades de procesos

Trabajador de Negocio.- Un trabajador del negocio o Business Worker es una abstracción de un sistema, de un ser

humano o de un software que represente un rol realizado dentro de realizaciones del caso del

uso del negocio.

Un trabajador del negocio colabora con otros trabajadores del negocio, se notifica de

acontecimientos del negocio y manipula entidades de negocio para realizar sus

responsabilidades.


Son roles (humanos, software o hardware), no personas con nombres propios. Se encuentran dentro del negocio. No siempre un rol está asociado con el nombre de un cargo en la planilla de la

organización. El nombre no debe representar áreas, departamentos o partes de una organización. Cada trabajador debe participar en al menos un caso de uso del negocio. Si no

participa en ningún proceso debe ser eliminado del modelo.

Entidad de Negocio.- Representa un pedazo de la información significativo y persistente que es manipulada por los

agentes del negocio y los trabajadores del negocio.

Proporcionan la base para compartir información (documentos) entre los trabajadores del

negocio que participan en diversas realizaciones del caso del uso del negocio.

Representan una abstracción de la información persistente importante dentro del negocio. Por

ejemplo, el inventario del producto es ciertamente información significativa, pero ésta no es

información persistente.

Identificando una entidad de negocio:

Participa por lo menos en un caso de uso. Pueden ser usadas por diferentes trabajadores del negocio en varios casos de uso del

negocio. Representan documentos, contratos, información solicitada, producto, conocimiento,

etc. Solo debe ser considerada información relevante y persistente al negocio.

Realización de CUN.-

Describe cómo los trabajadores de negocio y las entidades de negocio colaboran para realizar

un caso de uso de negocio particular.

Mientra que un caso de uso de negocio describe qué pasos se debe realizar para entregar

valor a un stakeholder del negocio, una realización del CUN describe cómo estos pasos se

realizan dentro de la organización.

Los CUN se describen de una perspectiva externa, mientras que la realización de casos de uso

del negocio, se describe de una perspectiva interna.

Ejercicio: Caso PECSA



Proyecto De Sistema

Modelo de Análisis de Negocio

Versión 1.0




04-06-10 Modelo Análisis de Negocio Javier Napan


1. Entidades de Negocio

EN_Factura

EN_Guia de remision

EN_Formulario de descarga segura

EN_Historial de medición

EN_Inventario de medicion

EN_Reporte de ventas

EN_Lista de requerimientos

EN_Guia de conversion


2. Realizaciones de Caso de Uso

RCUN_Captura de requerimientos y abstecimiento


3. Trabajadores de Negocio

TN_Jefe de pista

TN_Coordinador administrativo

TN_Coordinador operativo

TN_Administrador

TN_Representante de servicio


Arreglos

Contenidos

- Revisión de conocimientos / Proyectos de análisis

En esta semana, el instructor revisará los proyectos desarrollado por los alumnos, en el que se

debe crear y aplicar los conceptos estudiados.


Arreglos

Contenidos

- Requerimientos

LA CAPTURA DE REQUISITOS El esfuerzo principal en la fase de requisitos es desarrollar un modelo del sistema que se va a

construir. La utilización de los casos de uso es una forma adecuada de crear ese modelo. Esto

es debido a que los requisitos funcionales se estructuran de forma natural mediante casos de

uso.

Los casos de uso proporcionan un medio intuitivo y sistemático para capturar los requisitos

funcionales con un énfasis especial en el valor añadido para cada usuario individual o para

cada sistema externo.

El modelo de casos de uso es construido a través de un proceso iterativo durante el cual las

discusiones entre los desarrolladores del sistema y los clientes (y/o usuarios finales) llevan a

una especificación de requerimientos en la que todos estén de acuerdo.


PROPÓSITOS DE LOS CASOS DE USO Los propósitos principales de los casos de usos son los siguientes:

- Decidir y describir los requerimientos funcionales del sistema, que resultan en un acuerdo

entre el cliente (yo el usuario final) y los desarrolladores de software que están construyendo el

sistema.

- Dar una descripción consistente y clara de lo que debería hacer el sistema, de la forma que el

modelo sea usado a lo largo de todo el proceso de desarrollo cara comunicar a todos los

desarrolladores dichos requerimientos, y proveer las bases para futuros modelamientos de

diseño que provean la funcionalidad requerida.

- Dar una base para ejecutar pruebas de desempeño del sistema que verifique e. sistema. Por

ejemplo, preguntándose, ¿el sistema final realmente ejecuta la funcionalidad inicialmente

requerida?

- Proveer la habilidad de trazar los requerimientos funcionales hacia las clases y operaciones

reales en el sistema.

El trabajo real requerido para crear modelos de casos de uso envuelve definir el sistema,

encontrar los actores y los casos de uso, describir los casos de uso, definir las relaciones entre

los casos de uso y finalmente validar el modelo. Es un formato altamente interactivo que

deberían incluir discusiones con el cliente y la gente que representa a los actores. Los modelos

visuales no pueden proveer toda la información necesaria en un modelo de casos de uso, por

ello se emplean tanto los diagramas de casos de uso y descripciones textuales.

Un número diferente de personas tienen interés en los modelos de casos de uso.

El cliente y/o usuario final está interesado en ellos ya que los modelos de casos de uso

especifican la funcionalidad del sistema y describen como el sistema puede y será utilizado. Es

realmente útil cuando el usuario presenta un rol activo en el modelamiento de casos de uso ya

que los modelos pueden ser adaptados al detalle a los deseos del cliente. Los casos de uso se

describen en lenguaje y terminología del usuario final.

Los desarrolladores necesitan los modelos de casos de uso para entender qué debería hacer el

sistema y proveerles de las bases para futuros trabajos (otros modelos, diseño de la

arquitectura, e implementación).

Los equipos de integración y de pruebas del sistema necesitan los casos de uso para evaluar

al sistema para asegurarse que cumpla con la funcionalidad especificada en los casos de uso.

Finalmente, cualquiera que esté involucrado en las actividades relacionadas a la funcionalidad

del sistema podría tener interés en los modelos de casos de uso. Esto podría incluir a los

equipos de marketing, lentas, soporte y documentación.

El modelo de casos de uso representa la vista de casos de uso del sistema. Esta vista es bien

importante, ya que afecta a todas las vistas del sistema. Tanto la arquitectura física y lógica se

ven influenciadas por los casos de uso, debido a que las funciones especificadas en el modelo

de casos de uso son implementadas en dichas arquitecturas. Una solución es diseñada para

satisfacer estos requerimientos.


El modelo de casos de uso es empleado no solamente para capturar requerimientos de nuevos

sistemas; también es utilizado cuando nuevas generaciones de sistemas son desarrolladas.

Cuando una nueva generación (versión) de un sistema es desarrollada, la nueva funcionalidad

es agregada al modelo de casos de uso existente insertando nuevos actores y casos de uso o

modificando las especificaciones de los actuales casos de uso.


DIAGRAMA DE CASOS DE USO Un modelo de casos de uso se describe en UML como un diagrama de casos de uso. Un

modelo de casos de uso puede ser dividido en una serie de diagramas de casos de uso. Un

diagrama de casos de uso contiene elementos de modelo para el sistema, los actores, los

casos de uso y muestra las distintas relaciones tales como generalización, asociación, Y

dependencia entre estos elementos. La descripción real de los contenidos de los casos de uso

usualmente se da en texto simple. Esta descripción contiene información vital para definir los

requerimientos y funcionalidades reales. Como una alternativa para describir los casos de uso

se usa el diagrama de actividades.

COMPONENTES DE UN MODELO DE CASOS DE USO

Los componentes principales de un modelo de casos de uso son:

Actores Casos de uso Modelo de casos de uso

El actor es cualquier entidad externa que tiene un interés en interactuar con el sistema.

Frecuentemente, es un usuario humano del sistema, pero puede ser algún otro sistema o algún

tipo de dispositivo de hardware que necesite interactuar con el sistema.


Los límites del sistema son definidos por la funcionalidad determinada por el sistema. La

funcionalidad se representa por un determinado número de casos de uso, y cada caso de uso

específica una funcionalidad completa. Cuando la funcionalidad se completa, el caso de uso

debe manejar la función completa, desde su inicialización por un actor externo hasta que éste

ha realizado la funcionalidad requerida. Un caso de uso debe devolver siempre algún valor al

actor, un valor sea cual sea lo que el actor desee del sistema.

En el modelo de casos de uso, el sistema es visto como una ―caja negra‖ que provee casos de

uso. Cómo el sistema lo hace, cómo los casos de uso son implementados y cómo trabajan

internamente no es importante. En realidad, cuando el modelo de casos de uso se hace con

anticipación en el proyecto, los desarrolladores no tienen idea de cómo los casos de uso van a

ser implementados.

Actores Un actor es alguien o algo que interactúa con el sistema. Es algo o alguien que usa el

sistema. Por ‗interactuar con el sistema‖, queremos decir que el actor envía o recibe

mensajes hacia y desde el sistema o intercambia información con el sistema. En pocas

palabras, los actores ejecutan los casos de uso. Nuevamente, un actor puede ser un ser

humano o algún otro sistema (como otra computadora en la cual el sistema es conectado o

algún tipo de dispositivo de hardware que se comunica con el sistema).

Un actor es un tipo (una clase), no una instancia. El actor representa un rol, no a un usuario

individual del sistema. Si John Doe desea un seguro de automóviles de una compañía de

seguros, su rol es de un comprador de seguros o asegurado, que deseamos modelar, más

no John Doe. En realidad, una misma persona podría poseer diferentes actores en el

sistema, dependiendo de su rol en él. Y los roles que una persona podría tener en el

sistema pueden ser restringidos. Por ejemplo, la misma persona puede estar prohibida de

generar y aprobar una factura. Un actor tiene un nombre, y el nombre debería reflejar el rol

del actor. El actor se comunica con el sistema enviando y recibiendo mensajes, los cuales

son similares a aquellos encontrados en la programación orientada a objetos, aunque no

son como los especificados formalmente en un caso de uso. Un caso de uso siempre es

iniciado por un actor al enviarle un mensaje. Algunas veces se le da el nombre de estímulo.

Cuando un caso de uso es ejecutado, el caso de uso podría enviar mensajes a uno o más

actores. Estos mensajes podrían ir también a otros actores a parte de aquel que inició el

caso de uso.

Los actores pueden ser calificados. Un actor principal es aquel que utiliza las funciones

principales del sistema, como la función principal. Por ejemplo, en un sistema de seguros,

un actor principal podría ser aquel que se encarga de manejar el registro y administración

del seguro. Un actor secundario es aquel que utiliza las funciones secundarias del sistema,

aquellas funciones que mantienen el sistema, como la administración de bases de datos,

comunicaciones, backups, y otras tareas de administración. Un ejemplo de actor

secundario podría ser un administrador o algún otro miembro que utilice las funciones en el

sistema para recuperar estadísticas sobre el negocio de la compañía. Ambos tipos de

actores se modelan para asegurar que la funcionalidad completa del sistema sea descrita,

incluso cuando las funciones principales sean aquellas que interesen más al cliente.

Los actores también se pueden definir como activos y pasivos. Un actor activo es aquel

que inicializa un caso de uso, mientras que un actor pasivo nunca inicializa un caso de uso,

pero solo participa en uno o más casos de uso.


Encontrar a los Actores

Al identificar a los actores, establecemos a aquellas entidades interesadas en usar e

interactuar con el sistema. Luego es posible estar en la posición del actor para tratar de

identificar Tos requerimientos del actor en el sistema y qué casos de uso necesita el actor.

Los actores se pueden identificar respondiendo una serie de preguntas:

- ¿Quién usará la funcionalidad principal del sistema (actores principales)?

- ¿Quién necesitará apoyo del sistema para hacer sus tareas diarias?

- ¿Quién necesitará mantener, administrar, el sistema funcionando? (actores secundarios)

- ¿Qué dispositivos de hardware necesita manejar el sistema?

- ¿Con qué otros sistemas necesita interactuar el sistema? Esto se puede dividir en

sistemas que inician el contacto con el sistema y los sistemas que el sistema contactará.

Los sistemas incluyen otros sistemas informáticos así como también otras aplicaciones en

la computadora en la que residirá el sistema.

- ¿Quién o qué tiene interés en los resultados (el valor) que el sistema produce?

Cuando se busca a los usuarios del sistema, no sólo considere a quienes se sentarán

frente a la pantalla de la computadora. Recuerde, el usuario puede ser cualquiera o

cualquier cosa que directa o indirectamente interactúe con el sistema y utilice los servicios

del sistema para alcanzar algo. Tenga presente que el modelamiento de casos de uso se

hace para modelar un sistema; por lo tanto los actores usualmente son los clientes de

dicho negocio. En ese sentido no sólo son usuarios de computadoras.

Una manera de encontrar diferentes actores es llevar a cabo un estudio de los usuarios del

sistema actual (un manual del sistema o un sistema existente) y preguntar cuáles son los

distintos roles que desempeñan cuando realizan su trabajo diario con el sistema. El mismo

usuario podría interpretarse en distintos roles en diferentes oportunidades, dependiendo de

qué funciones en el sistema estén actualmente en uso.

Repitiendo, un actor es un rol (una clase), no una instancia individual. Sin embargo, dando

ejemplos de un par de instancias de un actor, se puede validar si realmente el actor existe.

Un actor debe tener alguna asociación con uno o más casos de uso. Aunque el actor no

podría iniciar un caso de uso, el actor en algún punto del tiempo se comunicará con uno. El

actor recibe un nombre que refleje su rol en el sistema.

Actores en UML

Tenga presente que los actores en UML son clases con el estereotipo de «actor», y que el

nombre de la clase es el nombre del actor (reflejando el nombre del actor), una clase actor

puede tener tantos atributos como compartimientos así como también una propiedad de

documentación que describe al actor. Una clase actor tiene un icono de estereotipo

estándar.


La relaciones entre Actores

Si se tiene presente que los actores son clases, pueden tener las mismas relaciones que

presenta una clase. En los diagramas de casos de uso, sólo las relaciones de

generalización se emplean para describir el comportamiento común entre un determinado

número de actores.

Generalización

Cuando existen varios actores o roles que desempeñan un rol más generalizado, esto se

describe como una generalización. Esto ocurre cuando el comportamiento del rol en

general se describe como actor padre. Los actores especializados heredan el

comportamiento del actor padre, extendiéndose el comportamiento. La generalización entre

actores se muestra con una línea con un triangulo vacío en el extremo de la superclase

más general. Esta es la misma notación empleada para la generalización entre cualquiera

de las clases en UML.


Casos de Uso

Un caso de uso representa una funcionalidad completa como es percibida por un actor. Un

caso de uso en UML se define como una secuencias de acciones que un sistema ejecuta,

el cual arroja un resultado observable para un actor en particular. Las acciones pueden

involucrar la comunicación con un determinado número de actores (usuarios y otros

sistemas) así como también realizar cálculos y trabajos dentro del sistema. Las

características de un caso de uso son:

- Un caso de uso la mayor parte de veces es siempre iniciado por un actor. Un caso de uso

es siempre ejecutado en nombre del actor. El actor debe directa o indirectamente ordenar

al sistema que se ejecute el caso de uso.

- Un caso de uso provee valor para aun actor: Un caso de uso debe entregar algún tipo de

valor tangible para el usuario.

- Un caso de uso es completo: Un caso de uso debe ser una descripción completa. Un

error común es dividir un caso de uso en casos de usos más pequeños que luego implican

llamar a más funciones en un lenguaje de programación. Un caso de uso no está completo

hasta que el valor final se produzca.

Los casos de uso se conectan con los usuarios a través de asociaciones, los cuales

algunas veces son referidos como asociaciones de comunicación. Las asociaciones

muestran con qué actores se comunican los casos de uso, incluyendo al actor que inicializa

la ejecución del caso de uso. La asociación es normalmente una relación de uno-a-uno sin

dirección. Esto significa que una instancia de actor se comunica con una instancia de caso

de uso, y que ambos se pueden comunicar en ambas direcciones. Un caso de uso recibe el

nombre acorde al caso de uso que ejecute, como Registro de Actualización, y es

frecuentemente una frase en vez de una etiqueta con una sola palabra.

Un caso describe la funcionalidad como un todo e incluye posibles alternativas, errores, y

excepciones que puedan ocurrir durante la ejecución del caso de uso. Se llama escenario a

una instancia de un caso de uso y esto representa el uso real del sistema (una ruta de

ejecución específica a través del sistema). Por ejemplo, una instancia de escenario del

caso de uso Contratar Seguro podría ser ‗John Doe contacta al sistema por teléfono y

adquiere un seguro para automóviles para el Toyota Corolla que acaba de comprar‖.


Encontrando Casos de Uso

El proceso para encontrar casos de uso empieza con el actor previamente definido. Para

cada uno de los actores identificados, pregúntese lo siguiente:

- ¿Qué funciones requiere el actor del sistema? ¿Qué necesita hacer el usuario?

- ¿Necesita el usuario leer, crear, destruir, modificar, o almacenar algún tipo de información

en el sistema?

- ¿Necesita el actor ser notificado sobre algún evento en el sistema, o el actor necesita

notificar algo al sistema? ¿Qué representan estos eventos en términos de funcionalidad?

- ¿Podría el trabajo diario del actor ser simplificado o ser más eficiente a través de nuevas

funciones en el sistema (típicamente funciones que actualmente no estén automatizadas

en el sistema)?

Casos de Uso en UML

Un caso de uso se representa en UML como una elipse, la cual contiene el nombre del

caso de uso o lleva el nombre del caso de uso debajo de él. Un caso de uso es

normalmente ubicado dentro de los límites del sistema y puede ser conectado al actor

como una asociación o como una asociación de comunicación que muestra como el caso

de uso y el actor interactúan.

Relaciones entre casos de uso

Existen tres tipos de relaciones entre casos de uso: extend, include y generalización.

Relación extend: Una relación donde un caso de uso se deriva de otro caso de uso

agregando acciones a un caso de uso general. El caso de uso extendido podría incluir el

comportamiento a partir del caso de uso de donde se extiende llamado caso de uso base

dependiendo de las condiciones de la extensión.

Relación include: Una relación donde un caso de uso emplea otro caso de uso, indica que

al ser parte del caso de uso base, el comportamiento del caso de uso incluido también se

llevará a cabo.

Relación de generalización: Cuando un caso de uso padre es especializado en uno o más

casos de uso hijos que representan formas más específicas del caso de uso padre.

Relación Extend .- Se utiliza para demostrar que una parte del caso de uso es

opcional, de esta manera se separa el comportamiento opcional del

comportamiento obligatorio en su modelo. También se le conoce como

comportamiento añadido.

Para demostrar que un subflujo es ejecutado sólo bajo ciertas condiciones como un

trigger o alarma. Los segmentos de comportamiento que son insertados como

puntos de extensión en el caso de uso base, dependerán de la interacción con los

actores durante la ejecución del caso de uso base. La extensión es condicional, lo

que quiere decir que su ejecución es dependiente de lo que suceda mientras se

ejecuta el caso de uso base. Para llegar al caso de uso extendido el único camino

es a través del caso de uso base. Una relación extend entre casos de uso se


muestra con una flecha punteada señalando al caso de uso del cual es extendido

con el estereotipo «extend».

Relación lnclude.- Cuando un número de casos de uso tienen un comportamiento

en común, este comportamiento puede ser modelado en un único caso de uso que

es empleado por otros casos de uso. Cuando un caso de uso base utiliza a uno

incluido significa que este último debe ser utilizado en su totalidad. El caso de uso

incluido devuelve la respuesta a una solicitud. El caso de uso incluido es un tipo de

caso de uso abstracto.

Una relación include se muestra a través de una flecha punteada señalando al

caso de uso que está siendo utilizado con el estereotipo«include».

Relación de Generalización.- Es utilizada cuando se encuentra que dos o más

casos de uso tienen comportamiento, estructura y propósito común. Para

representar esto se plasma la parte común en un nuevo caso de uso que será

especializado por los casos de uso hijos. Ni el caso de uso padre ni los casos de

uso hijo son abstractos, a pesar que la mayor parte de veces el caso de uso padre

es abstracto.


Plantilla de Especificaciones de Casos de Uso

La descripción del caso de uso es normalmente mediante un texto de descripción. Esto es

una especificación consistente y simple sobre cómo los actores y los casos de uso (el

sistema) interactúan. Se concentra en el comportamiento externo del sistema e ignora

cómo las cosas se ejecutan realmente dentro del sistema. El lenguaje y terminología

empleada en la descripción es la misma empleada por el usuario/cliente del sistema.

La descripción del texto debería incluir:

Objetivos para el caso de uso: ¿Cuáles son los objetivos principales para este caso de

uso? ¿Qué está tratando de alcanzar? Los casos de uso son orientados a objetivos.

¿Cómo el caso de uso es iniciado?: ¿Qué actor inicia la ejecución del caso de uso, y en

qué situaciones?

El flujo de mensajes entre os actores y los casos de uso: ¿Qué mensajes o eventos el caso

de uso y el actor intercambian para notificarse el uno a otro. actualizarse o recuperar

información, y apoyarse entre ellos con decisiones? ¿Qué debería describir el flujo principal

de mensajes entre el sistema y los actores, y qué entidades en el sistema son empleadas o

modificadas?

Flujo alterno en el caso de uso: Un caso de uso puede tener ejecuciones alternas

dependiendo de las condiciones o excepciones. Menciónelas, pero tenga cuidado de no

describirlas con mucho detalle ya que podrían ―ocultar‖ el flujo principal de las acciones en

el caso general. El manejo específico de errores se describen como escenarios.

¿Cómo el caso de uso termina dándole un valor al actor?. Se da cuando el caso de uso se

considera como terminado y el valor es entregado al actor.

Recuerde que la descripción identifica lo que se haga como importante para el usuario

externo, no cómo las cosas se hacen dentro del sistema. El texto debería ser claro y

consistente de tal forma que el usuario pueda entenderlo y validarlo (aceptar que

representa lo que desea del sistema). Evite oraciones complicadas que son difíciles de

interpretar y fácil de malinterpretar.

Como complemento para la descripción de un caso de uso que contiene la descripción

completa y general se emplean un número de escenarios reales para ilustrar qué sucedería

cuando el caso de uso es inicializado. La descripción del escenario ilustra un caso

específico, con ambos, actores y casos de uso, involucrados como instancias reales. Los

usuarios pueden entender mejor un caso de uso complejo cuando un escenario más

práctico describe el comportamiento del sistema. Pero note, que una descripción de un

escenario es un complemento, no un sustituto para la descripción del caso de uso.

Después de describir los casos de uso, una actividad específica revela si las relaciones

previamente definidas son correctas. Mientras no se describan todos los casos de uso los

desarrolladores no tendrán el conocimiento completo para identificar relaciones adecuadas,

de otra manera sería peligroso intentarlo.

Se presenta la plantilla de especificaciones de caso de uso:

Ejemplo:

Modelo de Caso de uso: CASO REPSOL



Proyecto De Sistema

Modelo de Caso de Uso

Versión 1.0




04-06-10 Modelo caso de uso Javier Napan


1. Casos de Uso


2. Especificaciones de Casos de Uso


Arreglos

Contenidos

- Diagrama de clases ____________________________________________________________________________

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

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

Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los

sistemas, donde se crea el diseño conceptual de la información que se manejará en el

sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y

otro.

Representación de: - Requerimientos en entidades y actuaciones. - La arquitectura

conceptual de un dominio - Soluciones de diseño en una arquitectura - Componentes de

software orientados a objetos


Un diagrama de clases esta compuesto por los siguientes elementos:

Clase: atributos, métodos y visibilidad. Relaciones: Herencia, Composición, Agregación, Asociación y Uso.

Elementos

Clase

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

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

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

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

En donde:

Superior: Contiene el nombre de la Clase Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase

(pueden ser private, protected o public). Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa

el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).


Ejemplo:

Una Cuenta Corriente que posee como característica: Balance Puede realizar las operaciones de : Depositar y Balance El diseño asociado es:

Atributos y Métodos:

Atributos:

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

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

public (+,): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.

private (-,): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar).

protected (#,): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver herencia).

Métodos:

Los métodos u operaciones de una clase son la forma en como ésta interactúa con su

entorno, éstos pueden tener las características:

public (+,): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.

private (-,): Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la clase lo pueden accesar).

protected (#,): Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de métodos de las subclases que se deriven (ver herencia).


Relaciones entre Clases:

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

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

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

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

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

uno o muchos: 1..* (1..n) 0 o muchos: 0..* (0..n) número fijo: m (m denota el número).

Herencia (Especialización/Generalización):

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

Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá

las características y atributos visibles de la Super Clase (public y protected), ejemplo:

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

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

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

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

particularidad propia Acoplado, Tara y Carga.

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

Características aplicable a instancias de Vehículo, Auto y Camión, pues tiene

definición pública, en cambio atributos como Descapotable no son visibles por

ser privados.


Agregación:

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

lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer

objetos que son instancias de clases definidas por el desarrollador de la aplicación,

tenemos dos posibilidades:

Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es comunmente llamada Composición (el Objeto base se construye a partir del objeto incluido, es decir, es "parte/todo").

Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comunmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento).

Ejemplo:

En donde se destaca que:

Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que posee

las referencias).

Cuando se destruye el Objeto Almacén también son destruidos los objetos

Cuenta asociados, en cambio no son afectados los objetos Cliente asociados.

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

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

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

referenciado. Cuando no existe este tipo de particularidad la flecha se elimina.


Asociación:

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

entre si. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un

objeto no depende del otro.

Ejemplo:

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

orden de compra solo puede tener asociado un cliente.

Dependencia o Instanciación (uso):

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

instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.

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

clase de otra, como por ejemplo una aplicación grafica que instancia una ventana (la

creación del Objeto Ventana esta condicionado a la instanciación proveniente desde el

objeto Aplicación):

Ejemplo:

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

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


Casos Particulares:

Clase Abstracta:

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

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

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

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

implementan los métodos abstractos definidos.

Clase parametrizada:

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

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

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

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

pero en este caso las llaves y elementos pueden ser genéricos. La genericidad

puede venir dada de un Template (como en el caso de C++) o bien de alguna

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

En el ejemplo no se especificaron los atributos del Diccionario, pues ellos

dependerán exclusivamente de la implementación que se le quiera dar.


Arreglos

Contenidos

- Modelo Conceptual - Análisis y Tecnología orientada a objetos. - Aplicación.

____________________________________________________________________________

UML Y LA PERSISTENCIA

En esta sesión se trabajará con las clases persistentes y se resaltará la diferencia entre el

modelamiento de una base de datos tradicional y el diseño de una base de datos con UML.

Mientras que el modelamiento de base de datos sólo enfoca la descripción de la base de datos,

el diseño de las base de datos con UML avanza a lo largo de todo el proceso de construcción

de software, es decir, desde el proceso del negocio, captura de requisitos, análisis, diseño,

construcción hasta la implantación y pruebas.

Para llevar a cabo este diseño, se identificarán las clases persistentes a partir de las

especificaciones de los casos de uso y las entidades de negocio. Finalmente, todas las clases

las integraremos en un modelo conceptual.


MODELO CONCEPTUAL

Un modelo conceptual explica los conceptos significativos en un dominio del problema. Es el

artefacto más importante a crear durante el análisis orientado a objetos. Identificar muchos

objetos o conceptos constituye la esencia del análisis orientado a objetos, y el esfuerzo se

compensa con los resultados conseguidos durante la fase de diseño e implementación.

La identificación de conceptos forma parte de una investigación del dominio del problema. El

lenguaje UML contiene la flotación en diagramas de estructura estática que explican

gráficamente los modelos conceptuales.

El paso esencial de un análisis o investigación orientada 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, se ilustra con un

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

La designación de modelo conceptual ofrece la ventaja de subrayar fuertemente una

concentración en los conceptos del dominio, no en las entidades del software.

Puede mostrarnos:

Conceptos Conceptos entre conceptos Atributos de conceptos.

Por ejemplo, en la figura vemos un modelo conceptual parcial del dominio de la tienda y las

ventas. 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. Por ahora no son importantes los detalles de la notación.

Conocimiento de la nomenclatura del dominio

Además de descomponer el espacio del problema en unidades comprensibles (conceptos), la

creación de un modelo conceptual contribuye a esclarecer la terminología o nomenclatura del

dominio. Podemos verlo como un modelo que comunica (a los interesados como pueden serlo

los desarrolladores) cuáles son los términos importantes y cómo se relacionan entre sí.

Los modelos conceptuales no son modelos de diseño de software

Un modelo conceptual es una descripción del dominio de un problema real. No es una

descripción del diseño del software, como una clase de Java o de C++. Por ello, los siguientes

elementos NO son adecuados en él:


Los artefactos del software, como una ventana o una base de datos Las responsabilidades o métodos.

Conceptos

En términos informales el concepto es una idea, cosa u objeto. En un lenguaje 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: la definición del concepto. Extensión: el conjunto de ejemplos a que se aplica el concepto.

Se considera, por ejemplo, el concepto del evento de una transacción de compra. Podemos

optar por designarlo 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

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

Cuando se crea un modelo conceptual, por lo regular la vista del símbolo y de la

Intención de un concepto es el aspecto de mayor interés práctico.

Los modelos conceptuales y la descomposición

Los problemas del software a veces son complejos. La descomposición — divide y vencerás-

es una estrategia que suele utilizarse para resolver la complejidad porque divide el espacio del

problema en unidades comprensibles. En el análisis estructurado, la dimensión de la

descomposición se realiza mediante procesos o funciones. En cambio, en el análisis orientado

a objetos, se lleva a cabo, fundamentalmente con conceptos.

Una distinción fundamental entre el análisis orientado a objetos y el análisis estructurado es la

división por conceptos (objetos) y no por funciones.

Por tanto, una tarea primordial de la fase de análisis consiste en identificar varios conceptos en

el dominio del problema y documentar los resultados en un modelo conceptual.

Conceptos en el dominio del punto de venta

Por ejemplo, en el dominio del problema real de comprar productos en una tienda o en una

terminal de punto de venta (TPDV) intervienen los conceptos de Tienda. TPDV y una Venta.

Por lo tanto, el modelo conceptual puede incluir una Tienda, TPDV y una Venta.


Estrategias para identificar los conceptos

Nuestra meta es crear un modelo conceptual de conceptos interesantes o significativos del

dominio en cuestión. En este caso, ello significa conceptos relacionados con la Compra de

productos. La tarea fundamental será, pues, identificar los conceptos; se proponen dos

estrategias.

La siguiente es una directriz de gran utilidad en la identificación de conceptos:

Es mejor exagerar y especificar un modelo conceptual con muchos conceptos refinados que

no especificarlo cabalmente

No piense que un modelo conceptual es más adecuado si tiene menos conceptos.

Generalmente suele suceder lo contrario.

Es frecuente omitir conceptos durante la fase inicial de identificación y descubrirlos más tarde

cuando se examinen los atributos o asociaciones o durante la fase de diseño. Cuando se

detecten, habrá que incorporarlos al modelo conceptual.

No se excluya un concepto simplemente porque los requerimientos no indiquen una necesidad

evidente que permita recordar la información acerca de ella (criterio común de la construcción

de modelos de datos para diseñar una base de datos relacional, pero no pertinente a la

creación de modelos conceptuales) o porque el concepto carezca de atributos. Es

perfectamente válido tener conceptos sin atributos o conceptos con un papel puramente de

comportamientos en el dominio en vez de un papel informal.

Obtención de conceptos a partir de una lista de categorías de conceptos. La creación de un modelo conceptual se comienza preparando una lista de conceptos idóneos

a partir de la siguiente lista. Contiene muchas categorías comunes que vale la pena tener en

cuenta, sin que importe el orden de importancia. Los ejemplos se tomaron de los dominios de

la tienda y de las reservaciones de líneas aéreas.

Categoría del concepto Ejemplos

Objetos físicos o tangibles TPDV, Avión

Especificaciones, diseño o descripciones de

cosas

EspecificaciónProducto, Descripción de Vuelo

Lugares Tienda, Aeropuerto

Transacciones Venta, PagoReservación

Línea o rengión de elemento de

transacciones

VentasLíneadeProducto

Papel de las personas Cajero, Piloto

Contenedores de otras cosas Tienda, Cesto, Avión

Cosas dentro de un contenedor Producto Pasajero


Otros sistemas de cómputo o

electromecánicos externos al sistema

SistemaAutorizacióndeTarjetadeCrédito,

ControldeTráficoAéreo

Conceptos de nombres abstractos Hambre Acrofobia

Organizaciones DepartamentosdeVentas, ObjetoLineaAérea

Eventos Venta, Robo, Junta Vuelo Accidente,

Aterrizaje

Procesos (a menudo no están representados

como conceptos, pero pueden estarlo)

VentaUnProducto, ReservaciónAsiento

Reglas y políticas PolíticasdeReembolso,

PoliticasdeCancelaciones

Catálogos DepartamentosdeVentas, ObjetoLineaAérea

Obtención de conceptos a partir de identificación, de frases nominales

Otra técnica muy útil (por su simplicidad) consiste en identificar las frases nominales en las

descripciones textuales del dominio de un problema y considerarlas conceptos o atributos

idóneos.

Este método hay que utilizarlo con mucha prudencia. No es posible encontrar mecánicamente

correspondencias entre sustantivo y concepto, y además las palabras del lenguaje natural son

ambiguas.

Pese a ello, esta técnica es fuente de inspiración. Las especificaciones de los casos de uso son

un excelente punto de partida para identificar las frases nominales Por ejemplo, puede usarse

el caso de uso Comprar Productos.

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. Si hay más de

un producto, el Cajero puede introducir también la cantidad.

3. El Sistema determina el precio del producto y a la transacción de ventas le agrega la

información sobre el producto. Se muestran la descripción y el precio del producto actual.

Algunas de las frases nominales anteriores son conceptos idóneos, algunas pueden ser

atributos de conceptos.

Una debilidad de este enfoque es la precisión del lenguaje natural; varias frases nominales

pueden designar el mismo concepto o atributo entre otras ambigüedades que pueden

presentarse. Pese a ello, no dudamos en recomendar usarlo en combinación con el método de

Lista de categoría de conceptos.


Conceptos idóneos para el dominio del punto de venta A partir de la lista de categoría de conceptos y del análisis de frases nominales, generamos

una lista de conceptos adecuados para incluirlos en la aplicación del punto de

venta: La lista está sujeta a la restricción de los requerimientos y simplificaciones que se

consideren en el momento.

TPDV EspecificacióndeProducto

Producto VentasLíneadeProductos

Tienda Cajero

Venta Cliente

Pago Gerente

Objetos del informe: ¿Se incluye el recibo en el modelo?

El recibo es un registro de una venta y de un pago, así como un concepto relativamente

prominente en el dominio de ventas; ¿debe, pues, mostrarse en el modelo? En seguida se

mencionan algunos factores que han de tenerse presentes:

El recibo es un informe de una venta. En general, no conviene incluirlo en un modelo conceptual, ya que toda su información proviene de otras fuentes. Este es un buen motivo para excluirlo

El recibo cumple un papel especial respecto a las reglas de la empresa: al portador le confiere el derecho de devolver los productos adquiridos. Esta es una razón para incorporarlo al modelo.

El recibo se excluirá, porque las devoluciones se productos no se incluyen en este ciclo de

desarrollo. Se justificará su inclusión durante el ciclo que aborde la Devolución de productos.

El modelo conceptual del punto de venta (solo conceptos)

La lista anterior de los nombres de conceptos puede representarse gráficamente en la notación

del diagrama de estructura estática de UML, a fin de mostrar la génesis del modelo conceptual


Directrices para construir modelos conceptuales

Cómo construir un modelo conceptual

Aplique los siguientes pasos para crear un modelo conceptual:

Para construir 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.

2. Dibújelos en un modelo conceptual.

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

reservar un espacio en la memoria (tema que se expondrá en un capítulo posterior).

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

que se tratará en un capítulo posterior.

La asignación de nombres y el modelado de las cosas: el cartógrafo

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

Prepare un modelo conceptual inspirándose en la metodología del cartógrafo:

Utilice los nombres existentes en el territorio. Excluya las características irrelevantes. No agregue cosas que no existan.

El modelo conceptual es una especie de mapa de conceptos o cosas de un dominio. Este

enfoque pone de relieve el papel analítico de un modelo conceptual y sugiere lo siguiente:

• Los cartógrafos se sirven de nombres del territorio — no cambian los nombres de ciudades en

sus mapas. En el caso de un modelo conceptual, ello significa utilizar el vocabulario del

dominio cuando se asignan nombres a los conceptos y a los atributos. Por ejemplo, al

desarrollar el modelo de una biblioteca, al cliente se le designará con los nombres que utilice el

personal: visitante, lector u otro semejante.

• Un cartógrafo elimina cosas en el mapa en caso de que no las juzgue pertinentes para el

propósito que persigue, así no es necesario que muestre la topografía ni las poblaciones. De

modo análogo, un modelo conceptual puede excluir en el dominio del problema los conceptos

que no se relacionen con los requerimientos. Por ejemplo, podemos omitir Pluma o Bolsa de

Papel en nuestro modelo conceptual (con el conjunto actual de requerimientos), por no tener

una función importante que sea obvia.


• Un cartógrafo no muestra cosa que no existan. Por ejemplo, una montaña inexistente. En

forma parecida, el modelo conceptual ha de excluir las cosas que no se encuentren en el

dominio del problema en cuestión

1.8.3 Un error que se comete frecuentemente al identificar los conceptos

Tal vez el error más frecuente cuando se crea un modelo conceptual es el de representar algo

como atributo, cuando debió haber sido un concepto. Una regla práctica para no caer en él es:

Si en el mundo real no consideramos algún concepto X como número o texto probablemente X

sea un concepto y no un atributo.

Por ejemplo, pongamos el caso del dominio de las reservaciones en líneas aéreas.,Debería

Destino ser un atributo de Vuelo o un concepto aparte Aeropuerto?

En el mundo real, un aeropuerto de destino no se considera número ni texto: es una cosa

masiva que ocupa espacio. Por tanto, Aeropuerto debería ser un concepto.

En caso de duda, convierta el atributo en un concepto independiente

Conceptos similares: comparación entre TPDV y Registro

Antaño, mucho antes del advenimiento de las terminales instaladas en el punto de venta, una

tienda llevaba un registro: un libro donde se asentaba las ventas y los pagos. Con el tiempo,

fue automatizado en un registro mecánico de efectivo. Hoy esa terminal desempeña el papel

del registro.

Un registro es una cosa que asienta las ventas y los pagos, pero también lo es la terminal

instalada en el punto de ventas. No obstante, el término registro parece tener un significado

más abstracto y denota una implementación menos orientada que TPDV. Pues bien, ¿en el

modelo conceptual deberíamos utilizar el símbolo Registro en vez de TPDV?

Primero, una regla práctica consiste en que un modelo conceptual no es absolutamente

correcto ni erróneo, sino de mayor o menor utilidad; es una herramienta de la comunicación.

Conforme al principio del cartógrafo, TPDV es un término usual en el territorio, por lo cual es un

símbolo útil desde el punto de vista del conocimiento y la comunicación. Registro es atractivo y

útil, según la meta de crear modelos que representen abstracciones y que no dependan de la

implementación.

Ambas opciones tienen sus bondades. En este caso de estudio hemos escogido TPDV.


Construcción de un modelo del mundo irreal

Algunos sistemas de software están destinados a dominios que presentan muy poca

semejanza con los dominios naturales o con los de las empresas. Un ejemplo lo constituye el

software de las telecomunicaciones. Todavía es posible crear un modelo conceptual en esos

dominios, pero se requiere un alto grado de abstracción y abandonar los diseños comunes.

Enumeramos algunos conceptos adecuados que se relacionan con un intercambio de

telecomunicaciones: Mensaje, Conexión, Diálogo, Ruta, Protocolo.

Especificación o descripción de conceptos

Suponga lo siguiente:

La instancia de Elemento representa una entidad física de una tienda.

Puede ser incluso un número serial.

Un Elemento tiene una descripción, precio y código universal de producto, los cuales no están

registrados en ninguna otra parte.

Todos los que trabajan en ¡a tienda sufren amnesia

Cada vez que se vende un elemento físico, en ―terreno del software‖ se elimina una instancia

del software correspondiente a Elemento.

Con estas suposiciones, preguntamos: ¿qué sucede en el siguiente escenario?

Existe gran demanda de una nueva hamburguesa: ObjetoHamburguesa. La tienda vende todas

sus existencias, lo cual significa que todas las instancias de Elemento de ObjetoHamburguesa

se cancelan en la memoria de la computadora.

Ahora bien, ésta es la esencia del problema: si alguien pregunta: ―,Cuánto cuesta el

ObjetoHamburguesa?, nadie podrá contestarle porque la memoria de su precio se anexó a las

instancias inventariadas, que fueron eliminándose conforme se vendían

Nótese, asimismo, que el modelo actual si se implementa en el software tal como se describe,

posee datos duplicados y maneja ineficientemente el espacio, porque la descripción, el precio y

el código universal de producto se duplican en cada instancia de Elemento del mismo producto.

Necesidad de las especificaciones

El problema anterior demuestra la necesidad de un concepto de objetos que son

especificaciones o descripciones de otras cosas. Para resolver el problema del Elemento lo que

se necesita es una EspecificaciónProducto (o Especificación Elemento,

DescripciónProducto,...) concepto que registra la información sobre los elementos. Una

EspecificaciónProducto no representa un Elemento, sino una descripción acerca de ellos.

Nótese que, aunque todos los elementos inventariados se vendan y se eliminen sus instancias

correspondientes de software, se conserva la EspecificaciónProducto.


La descripción o especificación de objetos se relacionan bastante con aquella que describen.

En un modelo conceptual, se acostumbra estipular que una EspecificaciónX describe una X

Especificaciones de otras cosas. La EspecificacióndeProducto puede

describir muchos Productos

La necesidad de especificar los conceptos es frecuente en los dominios de ventas y productos.

También lo es en la manufactura, donde se requiere una descripción de lo manufacturado que

se distingue del elemento manufacturado. El tiempo y el espacio han sido incluidos al explicar

la causa de la especificación de conceptos, por ser muy comunes; no se trata de un concepto

poco usual de la construcción de modelos.

¿Cuándo se requiere especificar los conceptos?

Las siguientes directrices indican cuando emplear las especificaciones.

Incorpore una especificación o descripción de conceptos (por ejemplo EspecificaciónProducto)

cuando:

La eliminación de las instancias de las cosas que describen Elemento, por ejemplo, da por resultado una pérdida de la información que ha de conservarse, debido a (a asociación incorrecta de la información con lo eliminado.

Reduce información redundante o duplicada

Otro ejemplo de especificación

He aquí un último ejemplo Imagine que una compañía aérea sufre al accidente fatal de uno de

sus aviones. Suponga que todos los vuelos quedan cancelados por seis meses, mientras se

lleva a cabo la investigación. Suponga además que. cuando se cancelan los vuelos, sus

correspondientes objetos de software Vuelo se eliminan en la memoria de la computadora. Así,

todos los objetos Vuelo quedan eliminados tras el accidente.

Si el único registro del aeropuerto al cual se dirige un vuelo está en las instancias Vuelo, que

representan vuelos específicos en determinado día y hora, ya no habrá un registro de qué rutas

tiene la línea aérea.

.Para resolver este problema, se requiere una DescripcióndeVuelo (o EspecificacióndeVuelo)

que describa un vuelo y su ruta, aún cuando no esté programado un vuelo determinado.


Aplicación:

Caso: REPSOL (Modelo Conceptual)



Proyecto De Sistema

Modelo de Conceptual

Versión 1.0




04-06-10 Modelo conceptual Javier Napan


1. Diagrama de Clases


2. Diagramas de Estado

CLS_Administrador

evaluando inventario

de medicion

generando lista de

requeriminetos

enviando lista de

requerimientos

recibiendo inventario

de medicion


CLS_Coordinador_Administrativo

recibiendo inventario

de medicion

entregando inventario

de medicion

revisando inventario

de medicion


CLS_Coordinador_Operativo

generando inventario

de medicion

revisando historial

de medicion

comparando con el

reporte de ventas

recibiendo historial

de medicion


CLS_Jefe_Pista

realizando

medicion diaria

generando historial

de medicion

consultando guia de

conversion

completando historial

de medicion

entregando historial

de medicion

recibiendo

factura y guia

realizando la

primera medicion

generando formulario de

descarga segura

revisando la calidad

de los combustibles

revisando el

contenedor del camion

realizando la

medicion final

completando formulario

de descarga segura

anulado

abastecimiento

firmando

factura y guia


CLS_Factura

recibiendo

firmando

consultando

entregando


CLS_Formulario_Descarga_Segura

generando

completando

enviando

recibiendo

firmando

CLS_Guia_Conversion

consultando


CLS_Guia_Remision

entregando

recibiendo

consultando

firmando


CLS_Historial_Medicion

generando

completando

enviando

recibiendo


CLS_Inventario_medicion

generando

revisando

anulando

CLS_Lista_requerimientos

genenerando

enviando

recibiendo


CLS_Proveedor

entregando

factura

entregando guia de

remision

abasteciendo

firmando formulario de

descarga segura

recibiendo lista de

requerimientos

CLS_Reporte_ventas

consultando

comparando


3. Diagrama de Colaboración


4. Diagrama de Secuencia


Arreglos

Contenidos

- Repaso de contenido - Integración de conocimientos. - Sustentación de proyectos.

____________________________________________________________________________

Manual Analisis y Diseño de Sistemas - v0810

Documents

Transcript of Manual Analisis y Diseño de Sistemas - v0810