Upload
eder-martin-shapiama
View
298
Download
4
Embed Size (px)
Citation preview
Ing. Carlos Avalos Ruiz 1
Tema Nro.1:
Desarrollo de sistemas de información
“Una guía para la automatización de las funciones de la organización para la obtención de ventajas competitivas”
Ing. Carlos Avalos Ruiz 2
Introducción
• El desarrollo de los sistemas de información se basan en ciclo de vida del desarrollo del software.
• La disciplina encargada de proveer los medios necesarios para la construcción de una software es la ingeniería de software.
• Por ende el desarrollo de los sistemas de información están basado en procesos de desarrollo de software que la ingeniería de software propone.
• Para ello existen dos enfoques paradigmáticos: estructurado y orientado a objetos.
Ing. Carlos Avalos Ruiz 3
La Ingeniería de Software (IS)
• La IS es una disciplina que integra métodos, herramientas y procedimientos para el desarrollo del software de computadoras.
• Se han propuesto varios paradigmas, entre ellos podemos mencionar: estructurado,orientado a objetos ,sala limpia, cliente/servidor, reutilización del software, reingeniería del software, software asistido por computa- doras, etc.
• El software se ha convertido en el elemento clave de la evolución de los sistemas y productos informáticos.
Ing. Carlos Avalos Ruiz 4
Paradigma Orientado a Objetos• Con frecuencia se alude a la Orientación a Objetos
como un nuevo paradigma (Paradigma de Objetos) y al término Orientado a Objeto ( OO ) como la aplicación de este paradigma al mundo de la computación.
• El paradigma para los programadores, es la manera como se maneja la complejidad.
• Desde este punto de vista el paradigma es el modelo o la estructura dentro del software solución de un problema.
Ing. Carlos Avalos Ruiz 5
• Superficialmente OO significa la organización del software como una colección de Objetos discretos que incorpora tanto la estructura de datos como su comportamiento.
• Para cada entidad del dominio, hay un objeto que representa ese concepto en el modelo.
• Finalmente, OO modela mirando en alguna parte realidad o dominio que es de interés, y busca las abstracciones claves y las relaciones entre esas abstracciones claves.
Ing. Carlos Avalos Ruiz 6
• La Orientación a Objetos se aplica a otros disciplinas dentro del mundo de la computación, tal como se aprecia en la siguiente ilustración :
Ing. Carlos Avalos Ruiz 7
En resumen la Orientación a Objetos:
Orientadoa
objetos
abstracciónde la realidad
ConceptosObjetosClasesEstructuras -jerárquicasMétodos/ope-raciones/servicios
AbstracciónEncapsulamientoHerenciaPolimorfismoMensajeIdentidadAsociación
en función
y que mediante
permite manejarla complejidad
Ing. Carlos Avalos Ruiz 8
Tecnología Orientada a Objetos
• La Tecnología de Objetos (TO), una de las más recientes técnicas de desarrollo de sistemas y se basa en la OO; cuenta con cuatro bases fundamentales :– Análisis Orientado a Objetos (AOO). – Diseño Orientado a Objetos (DOO). – Programación Orientada a Objetos (POO).– Base de Datos Orientado a Objetos (BDOO).
Ing. Carlos Avalos Ruiz 9
Tecnología orientada a
objetos
Nuevos métodos de
programación.
Nuevos métodos de
análisis
Nuevos métodos de
diseño
Reutilizar el código
Mas calidad
Mas productividad
Menos costo
Situación Actual en la TOO
Ing. Carlos Avalos Ruiz 10
Desarrollo de la Tecnología Orientada a Objetos
• Con el universo de métodos, se ha formado un cos- mo dinámico con el mundo de objeto en el que un método evoluciona en una estrella nítida u otra cesa para ser destacado y llega a ser un gigante rojo antes de desaparecer enteramente.
• De aquí en adelante, una organización debería prime ra comprender completamente qué significa para pen sar desde el punto de vista de objetos.
Ing. Carlos Avalos Ruiz 11
Método, Metodología y Proceso en el desarrollo de software
• Un método es la aplicación particular de una método logia de desarrollo de software pero que no abarca el ciclo de vida de desarrollo de software ni cuenta con herramientas tecnológica de soporte.
• Una metodología es una marco general basado en un paradigma que sirve de base para el desarrollo de software y que abarca todo el ciclo de vida.
• Un proceso de desarrollo de software esta basado en una metodología, abarca todo el ciclo de vida y provee herramientas tecnológica de soporte.
Ing. Carlos Avalos Ruiz 12
¿Problemas en el desarrollo de software?
• Retrasos en los plazos• Proyectos cancelados• Rápido deterioro del sistema instalado• Tasa de defectos o fallos• Requisitos mal comprendidos• Cambios frecuentes en el dominio del problema• Muchas de las interesantes características del software no
proporcionan beneficios al cliente• Buenos programadores se cansan y dejan el equipo
Ing. Carlos Avalos Ruiz 13
El Modelado
• El modelado es una tecnica de ingeniería probada y bien aceptada.
• El modelado no solo es parte de la industria de la construcción.
• Un modelo es una abstracción del sistema, especificando el sistema desde un cierto punto de vista y en un determinado nivel de abstracción.
• Un modelo es una simplificacion de la realidad.
Ing. Carlos Avalos Ruiz 14
¿Por qué las empresas no hacen modelado?
• La mayor parte de las empresas software no realizan ningún modelado.
• El modelado requiere:– aplicar un proceso de desarrollo– formación del equipo en la técnicas– ¿tiempo?
• ¿Se obtienen beneficios con el modelado?
Ing. Carlos Avalos Ruiz 15
¿Por qué modelamos?
• Los modelos :• Ayudan a visualizar como es o queremos que sea el
sistema.• Especifican la estructura o comportamiento de un
sistema• Proporcionan plantilla que nos guian en la
construccion de un sistema.• Documentan las decisiones que hemos adoptado.
Construimos modelos para comprender mejor el sistema que estamos desarrollando.
Ing. Carlos Avalos Ruiz 16
Principio de Modelado
• La elección de que modelos crear tiene una profunda influencia sobre como se define un problema y como se da forma a una solucion.
• Todo modelo puede ser expresado a diferentes nive les de expresion.
• Los mejores modelos están ligados a la realidad.• Un único modelo no es suficiente.• El modelado no es sólo para los grandes sistemas.
Ing. Carlos Avalos Ruiz 17
Sistema de Computo
Procesos del Negocio
Order
Item
Ship via
“El modelado captura la parte escencial de un sistema.” Dr. James Rumbaugh
El Modelado Visual es un modelamiento usando notaciones graficas estandares
Modelado Visual
Ing. Carlos Avalos Ruiz 18
Arquitectura del Software
• La visualización, especificación, construcción y documentación de un sistema con gran cantidad de software requiere que el sistema sea visto desde varias perspectivas.
• La arquitectura de un sistema es quizás el artefacto mas importante que puede emplearse para manejar estos diferentes puntos de vista y controlar el desarrollo iterativo e incremental.
Ing. Carlos Avalos Ruiz 19
• La arquitectura es un conjunto de decisiones significativas sobre:– La organización de un sistema software.– La selección de elementos estructurales y sus
interfaces a través de los cuales se constituye el sistema.
– Su comportamiento, como se especifica en la colaboraciones entre esos elementos.
– La composición de esos elementos estructurales y de comportamiento en subsistemas progresivamente mas grandes.
– El estilo arquitectónico que guía esta organización: los elementos.
Ing. Carlos Avalos Ruiz 20
• estáticos y dinámicos y sus interfases, sus colaboraciones y su composición.
• La arquitectura del software no tiene que ver sola mente con la estructura y el comportamiento, sino también con el uso, la funcionalidad, el rendimiento, la capacidad de adaptación, la reutilización, la capacidad de ser comprendido, las restricciones económicas y de tecnología y los compromisos entre alternativas, así como de los aspectos estáticos.
Ing. Carlos Avalos Ruiz 21
Modelado de la arquitectura de un sistema software
Vista de Diseño Vista de Implementación
Vista de Procesos Vista de Despliegue
Vista de casos de uso
vocabulariofuncionalidad
ensambladogestión conf.
topologíaentregadistribucióninstalación
Funcionamientoescalabilidadrendimiento
comportamiento
Ing. Carlos Avalos Ruiz 22
• La vista de casos de uso de un sistema comprende los casos de uso que describen el comportamiento del sistema tal y como es percibido por los usuarios finales, analistas, y encargados de las pruebas.
• La vista de diseño de un sistema comprende las clases, interfaces y colaboraciones que forman el vocabulario del problema y las solución.
• La vista de procesos de un sistema comprende los hilos y procesos que forman los mecanismos de sincronización y concurrencia del sistema.
Ing. Carlos Avalos Ruiz 23
• La vista de implementación de un sistema compren de los componentes y archivos que se utilizan para ensamblar y hacer disponible el sistema físico.
• La vista de despliegue de un sistema contiene los nodos que forman la topología hardware sobre la que se ejecuta el sistema.
Cada una de estas cinco vistas pueden existir por si misma, de forma que diferentes usuarios pueden centrarse en las cuestiones de la arquitectura del sistema que mas le interese.
Ing. Carlos Avalos Ruiz 24
Por qué es necesaria la arquitectura
• Un sistema software grande y complejo requiere una arquitectura para que los desarrolladores puedan progresa hasta tener una visión común.
• Se necesita una arquitectura para:– Comprender el sistema.– Organizar el desarrollo.– Fomentar la reutilización.– Hacer evolucionar el sistema.
Ing. Carlos Avalos Ruiz 25
Unified Modeling Language (UML)
• UML es un lenguaje estandar para la visualiza cion , especificacion, construccion, y documenta cion de artefactos de un sistema.
• UML combina lo mejor de :– Modelamiento conceptual de datos (Diagrama Entidad
Relacion)– Modelamiento del flujo de actividades.– Modelamiento de Objetos – Modelamiento de Componentes
Ing. Carlos Avalos Ruiz 26
• UML Significa Lenguaje Unificado de Modelado. Un lenguaje de modelado es lenguaje cuyo voca bulario y reglas se centra en la representación conceptual y física de un sis tema.
• UML consiste en Reglas de simbología que se aplican a cualquier tipo de modelo hecho bajo este lenguaje.
• UML es un Lenguaje estandar para escribir planos o modelos de software.
Ing. Carlos Avalos Ruiz 27
• UML tiene una sintaxis y una semántica bien definida. La parte mas visible de UML es su notación gráfica.
• Puede utilizarse con todos los procesos y a lo largo del ciclo de vida del desarrollo de softwa re, y con diferentes tecnologias de implementa cion.
• UML puede utilizarse para: – Visualizar el límite de un sistema y sus fun
ciones importantes.
Ing. Carlos Avalos Ruiz 28
– Ilustrar realizaciones de un sistema.– Representar la estructura estática de un siste
ma .– Modelar el comportamiento de objetos. – Conocer la arquitectura física de la implemen
tación. – Extender su funcionalidad con estereotipos.
• El vocabulario y las reglas de un lenguaje como UML indican como crear y leer modelos bien for mados, pero no dicen “que” ni “cuando” estos mo delos se deben crear.
Ing. Carlos Avalos Ruiz 29
• UML es sólo un lenguaje y por lo tanto estan sólo una parte de un método de desarrollo de Software. UML es independiente del proceso.
• Un proceso bien definido guiará a sus usuarios al decidir qué artefactos producir, qué activida des y qué personal emplear para crearlo y ges tionarlo.
• Un artefacto es una pieza de información que es utilizada o producida por un proceso de desarro llo de software.
Ing. Carlos Avalos Ruiz 30
Antecedentes de UML
• Originalmente desarrollado por Rational, Grady Booch y James Rumbaugh.
• Posteriormente se tiene la contribución de Ivar Jacobson.
• Esta aceptada por OMG (Object Manage ment Group)
• UML se ha publicado en las siguientes versiones: 0.8, 0.9, 0.91, 1.0, 1.1,1.2,1.3.......
Ing. Carlos Avalos Ruiz 31
Los tres amigos (y otros)
• Ivar Jacobson -- Objectory and use cases.• Jim Rumbaugh -- OMT and UML.• Grady Booch -- Booch Method and UML.• Hewlett-Packard, Texas Instruments, Oracle.• Microsoft -- Repository, visual modeling. • Platinum -- OPEN Modeling Language.• IBM/ObjectTime -- OCL/ROOM.
Ing. Carlos Avalos Ruiz 32
ContribucionesMeyer
Before and after conditions
Harel
Statecharts
Gamma, et al
Frameworks and patterns,
HP Fusion
Operation descriptions and message numbering
Embley
Singleton classes andhigh-level view
Wirfs-Brock
ResponsibilitiesOdell
Classification
Shlaer - Mellor
Object lifecycles
Rumbaugh
OMT
Booch
Booch method
Jacobson
OOSE
Ing. Carlos Avalos Ruiz 33
Historia de UML
Booch method OMT
Unified Method 0.8OOPSLA ´95
OOSEOther methods
UML 0.9Web - June ´96
publicfeedback
Final submission to OMG, Sep ‘97
First submission to OMG, Jan ´97
UML 1.1OMG Acceptance, Nov 1997
UML 1.3
UML 1.0UML partners
Ing. Carlos Avalos Ruiz 34
Donde puede utilizarse UML
• UML esta pensado principalmente para sistemas de gran cantidad de software.
• UML es apropiado para modelar desde sistemas de información en empresas hasta aplicaciones distribuidas basadas en Web, e incluso para sistemas empotrados de tiempo real muy exigentes.
• UML no esta limitado al modelado de software, es lo sufientemente expresivo para modelar sistemas que no son software.
Ing. Carlos Avalos Ruiz 35
Classesapplication partitioning
Business ObjectsRelationships
Business Process
Objects
Use Cases
large scale system
ScenariosComponentsMicrosoft
ActiveX/COMMicrosoft
ORDBMSOracle
CORBAOMG
UML: Soporte para el desarrollo de cualquier tipo de aplicaciones
Ing. Carlos Avalos Ruiz 36
Utilidad de UML
• Permite especificar todas las decisiones de análisis, diseño e implementación, construyéndose modelos precisos, no ambiguos y completos.
• UML puede conectarse a lenguajes de programación:– Ingeniería directa e inversa
• Permite documentar todos los artefactos de un proceso de desarrollo (requisitos, arquitectura, pruebas, versiones,..)
Ing. Carlos Avalos Ruiz 37
Metamodelo UML
• ¿Cómo se expresa la semántica del modelo?– Informalmente– Formalmente
• El metamodelo UML define la notación de un modo riguroso, a través de diagramas de la propia notación y con OCL.
Ing. Carlos Avalos Ruiz 38
Metamodelo UML: Ejemplo
Relación
AsociaciónGeneralización
Role de asociación
1
2..*ordered
Ing. Carlos Avalos Ruiz 39
Modelo Conceptual de UML
• Para comprender UML, se necesita adquirir un modelo conceptual del lenguaje, y esto requiere aprender tres elementos principales:– Los bloques de construcción.– Las reglas que dictan como se pueden combinar
estos bloques básicos.– Algunos mecanismos comunes que se pueden
aplicar.
Ing. Carlos Avalos Ruiz 40
UML
Elementos
Estructural
Use caseClases
Clases ActivasInterfaces
ComponentesColaboraciones
Nodos
Comportamiento Agrupación Anotación
Relaciones DiagramasEspecificaciones
AdornosDivisionescomunes
Mecanismosde extensión
InteracciónMaquina de
Estado
PaqueteModelo
SubsistemaFramework
Notas
DependenciaAsociación
GeneralizaciónRealización
Use caseClases
ObjetosSecuencia
ColaboracionesEstado
ActividadComponentes
DespliegueEstereotipos
Valores etiquetadosRestricciones
Bloques de Construcción Reglas
NombresAlcance
VisibilidadIntegridad
MecanismosComunes
Ing. Carlos Avalos Ruiz 41
Elementos del modelo conceptual de UML
• Elementos estructurales: modelan partes estáticas y representan cosas conceptuales y materiales, son: Clases, una interfaz, una colaboración, un use case, componentes y nodos.
• Elementos de comportamiento: son las partes dinámi cas de los modelos, representan comportamiento en el tiempo y el espacio, son: una interacción y una máquina de estados.
Ing. Carlos Avalos Ruiz 42
• Elementos de agrupación: son las partes organizati vas, el elemento de agrupación principal son los pa quetes.
• Elementos de anotación: son las partes explícitas, se usan para describir, clarificar o hacer observaciones, esta es una nota
Ing. Carlos Avalos Ruiz 43
Elementos EstructuralesVentana
origentamaño
abrir()cerrar()mover()dibujar()
clase
IAvisable<<Interface>>
IAvisable
InterfaceValidarTransacción
caso de uso
Gestor Eventos
suspender()
vaciarCola()
clase activa
Gestión Pedidos
colaboración componente
Hola Mundo.class
Servidor
nodo
Ing. Carlos Avalos Ruiz 44
Elementos de ComportamientoInteracción
Conjunto de mensajes intercambiados entre un conjunto de objetos con un propósito particular.
mensajedibujar
Máquina de estadosSecuencia de estados por las que pasa un objeto durantesu vida en respuesta a eventos.
estadoactivado
Ing. Carlos Avalos Ruiz 45
Elementos de Agrupamiento
Modelo del Negocio Paquete
Un paquete incluye un conjunto de elementos de cualquiernaturaleza.
Tiene una naturaleza conceptual.
Ing. Carlos Avalos Ruiz 46
Elementos de Notación
Son las partes explicativas de los modelos UML
NotaRetorna 0 si no existe el valor
Ing. Carlos Avalos Ruiz 47
Relaciones del modelo concpetual de UML
Dependencias
Asociacionespatrón empleado
0..1 *
Generalizaciones
Realización
Ing. Carlos Avalos Ruiz 48
DiagramaUse Case
Diagramade
ColaboracionColaboracion
Diagramade
Componentes
Diagramade
Despliegue
Diagramade
Objetos
Diagramade
Estado
Diagramade
Secuencia
Diagramade
Clases
Diagramade
Actividad
Un modelo es una descripción completa de un sistema desde una perspectiva particular
Modelos
Modelos y Diagramas de UML
Ing. Carlos Avalos Ruiz 49
atributos
operaciones
dependencia
Empresa
generalización
Oficina Principal
1
1..**
0..1
clase
**
miembro
rol
11..*
{subgrupo}asociación
administrador
restricción
multiplicidad
agregación
nombre1..*
sitio
Empleado
Nombre: MaríaIDEmpleado: 2568Cargo: Gerente
obtenerFoto(f:Foto)obtenerSonido()obtenerContacto()obtenerRegistroEmpleados()
Contacto
Dirección: Pizarro 254
RegistroEmpleados
IdImpuestoHistorialempleadosueldo/salario
Departamento
Nombre: Ventas *
Oficina
Dirección : Sucre 360Código: 2358
*
Diagrama de Clases• Muestra un conjunto de clases, interfaces y colabora
ciones con sus relaciones.
Ing. Carlos Avalos Ruiz 50
e: Empresa
objeto anónimo
valor de atributo
enlace
objeto
d1: Departamento
Nombre: “Ventas”
d2: Departamento
Nombre: “RRHH”
d3: Departamento
Nombre: “Ventas a Crédito”
p: Personal
Nombre = “Eddi”IDEmpleado = “4356”Cargo = “Vendedor”
: Contacto
Dirección:“Pio265”
Diagrama de Objetos• Muestra un conjunto de objetos y sus relaciones.
Ing. Carlos Avalos Ruiz 51
Red celular
Usuario
actor
Emitiendollamadas deconferencia
Recepcionandollamadaadicional
Usando horario
Recibiendollamada
Emitiendollamada
Relación extendida
<<extend>>
<<extend>>
use-case
límites del sistema
Telefonía Celularasociación
Diagrama de Use Case• Muestra un conjunto de Casos de Uso (Use Case),
actores y sus relaciones, presenta una descripción de la conducta de un sistema para un usuario en un punto determinado.
Ing. Carlos Avalos Ruiz 52
h : hilo : herramientas
p : par
a1 : ejecutar(3)
ejecutar()
<<create>>
<<destroy>>
pideIdent()
rellamada()
objeto
etiqueta dela secuencia
mensaje
línea de vida
creacion
llamada
recursiónretorno/rspta
destrucción
enfoque de control
interacción
Diagrama de Secuencia• Es un diagrama de interacción que resalta el orden tem
poral de los mensajes, es decir, muestra el dinamismo de la interacción entre objetos, en función al tiempo.
Ing. Carlos Avalos Ruiz 53
Diagrama de Colaboraciones• Es un diagrama de interacción que resalta el orden tem
poral de los mensajes, es decir, muestra el dinamismo de la interacción entre objetos, en función al tiempo.
c:Cliente
:Transacción p:ODBDProxy
1: <<create>>2: grupoAcciones(a,d,o)3: <<destroy>>
<<global>>
2.1: grupoValores(d,3.4)2.2: grupoValores(a,”CO”)
objeto
mensajeenlace
<<local>>
{transitorio}
Diagrama de Colaboración
Ing. Carlos Avalos Ruiz 54
estado inicial
conectado
conectando
Trabajandolisto(3) [señal OK]
Inactivo
encender
apagar/reconectar()
activado/revisar()
apagado
estado final
estado
eventoacción
transición
transición interna
guardar
estado anidado
Máquina de Estado
Diagrama de Estado• Muestra una máquina de estados, que consta de: esta
dos, transiciones, eventos y actividades. Estos diagra mas cubren la vista dinámica del sistema. Son importan tes para modelar el comportamiento de una interfaz, cla se o colaboración.
Ing. Carlos Avalos Ruiz 55
estado inicial
Seleccionar lugar
Comisionar a arquitectos
Desarrollar plan
Ofertar plan
Fin de construcción
Trabajar el plan Negociar el plan()
:Certificado de ocupación[terminado]
ramas de secuencia
[no aceptado][else]
flujo de objeto
estado de actividad con submáquina
estado final
bifurcación concurrente
unión concurrente
estado de la acción
Diagrama de Actividades
• Es un tipo especial de diagrama de estado que muestra el flujo de actividades dentro de un sistema. Son especialmente impor tantes al mode lar el funcionamiento de un sistema pues resaltan el flujo de control entre objetos.
Ing. Carlos Avalos Ruiz 56
hallar.exe
índice.html
hallar.html
accesoBd.dll busca.dll
<<hiperenlace>>
ejecutablepágina web
librería
componente
Diagrama de Componentes
• Muestra la orga nización y las dependencias entre un conjun to de componen tes. Presentan la vista estática de implementación del sistema.
Ing. Carlos Avalos Ruiz 57
<<processor>>servidorprimario
<<processor>>servidor
<<processor>>servidor
<<processor>>servidor
<<network>> red local
<<processor>>servidor de
caché
<<processor>>servidor de
caché nodo
conexión
internet Modem
nodo
Diagrama de Despliegue
• Muestra la configuración de nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos.
Ing. Carlos Avalos Ruiz 58
Mecanismos comunes del modelo conceptual de UML
• Especificaciones– Proporcionan una base semántica para cada
elemento– Los diagramas son proyecciones de esa base
• Adornos– La notación gráfica básica de cada elemento puede
incluir adornos textuales o gráficos para resaltar algunas propiedades de la especificación.
Ing. Carlos Avalos Ruiz 59
• Divisiones Comunes– Dicotomía clasificador
/instancia
Persona
nombre
dirección
teléfonoElena :
Persona
: Persona
Elena
• Divisiones Comunes– Dicotomía interfaz /
implementación
IOrtografía
asistente
Ortográfico.dll
Ing. Carlos Avalos Ruiz 60
Mecanismos de extension del modelo conceptual de UML
• Mecanismos de extensibilidad– Estereotipos
• Extienden el vocabulario de UML, permitiendo añadir nuevos tipos de bloques de construcción.
– Valores etiquetados• Extienden las propiedades de un bloque de
construcción, añadiendo nueva información.
Ing. Carlos Avalos Ruiz 61
– Restricciones• Extiende la semántica de un bloque, añadiendo reglas
o modificando las existentes.
Overflow<<Exception>>
ColaEventos {version 3.2; autor: jgm}
añadir()
quitar()
vaciar()
{ordenado}
estereotipovalor etiquetado
restricción
Ing. Carlos Avalos Ruiz 62
Sistema, modelo, vista, diagrama• Un sistema es aquello que se está desarrollando y
para lo que se crean modelos.• Un subsistema es una parte de un sistema.• Un modelo es una abstracción de un sistema que
ayuda a comprenderlo.• Una vista es una proyección de la estructura y
organización de un modelo del sistema, centrada en algún aspecto.
• Un diagrama es una representación de un conjunto de elementos.
Ing. Carlos Avalos Ruiz 63
Vistas UML en términos de Elementos
Vista de DiseñoVista de Implementación
Vista de Procesos Vista de Despliegue
Vista de casos de uso
clasesinterfacescolaboraciones componentes
nodosclases activas
casos de uso
Ing. Carlos Avalos Ruiz 64
Vistas UML en términos de Diagramas
Vista de DiseñoVista de Implementación
Vista de Procesos Vista de Despliegue
Vista de casos de uso
Diagramas de claseDiagramas de interacciónDiagramas de estado
Diagramas de componentesDiagrama de interacciónDiagramas de estado
Diagramas de despliegueDiagrama de interacciónDiagramas de estado
Diagramas de casos de uso
Diagramas de claseDiagramas de interacciónDiagramas de estado
Ing. Carlos Avalos Ruiz 65
Ejemplo: Hola mundo!
import Java.awt.Graphics;class HolaMundo extends java.applet.Applet {
public void paint (Graphics g) {g.drawString (“¡Hola, Mundo!”,10,10);
}}
HolaMundo
paint()
g.drawString
("Hola, mundo”)
Abstracción de clases para hola mundo
Ing. Carlos Avalos Ruiz 66
Applet
HolaMundo
paint () Graphics
Object
Component
Container
Panel
Applet
HolaMundo
ImageObserver
Clase relacionadasCon Holamundo
Jerarquía de laHerencia deHola mundo
Ing. Carlos Avalos Ruiz 67
java
lang
awt
AppletHolaMundo
Organización de paquetes de Holamundo
Ing. Carlos Avalos Ruiz 68
:Thread :Toolkit target:HolaMundo:ComponentPeer
runrun
handleExpose paint
callbackLoop
Mecanismo para dibujar de Holamundo
Ing. Carlos Avalos Ruiz 69
HolaMundo.classhello.java
hello.html
Componentes de Holamundo
Ing. Carlos Avalos Ruiz 70
Equipo base dedesarrollo
Pero UML no es suficiente
Unified Modeling Language
Developmentprocess
Ing. Carlos Avalos Ruiz 71
Proceso de Desarrollo de Software
• Un proceso de desarrollo de software es un conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software.
Proceso de desarrollo de software
Requisitos delusuario
Sistema software
Ing. Carlos Avalos Ruiz 72
Un Proceso Iterativo e Incremental
• Un proceso de desarrollo de software debe tener una secuencia de hitos claramente articulados para ser eficaz, que proporcionen a los director y al resto del equipo del proyecto los criterios que necesitan para autorizar el paso de una fase a la siguiente dentro del ciclo del producto.
• Un proceso iterativo es aquel que involucra la gestión de un flujo de ejecutables del sistema.
Ing. Carlos Avalos Ruiz 73
• Un proceso incremental es aquel que involucra la continua integración de la arquitectura del sistema para producir esos ejecutables, donde cada nuevo ejecutable incorpora mejoras incrementales sobre los otros.
• En conjunto, un proceso iterativo e incremental esta dirigido por el riesgo, lo que significa que cada nueva versión se encarga de atacar y reducir los riesgos mas significativos para el éxito del proyecto.
Ing. Carlos Avalos Ruiz 74
Lo que es una Iteración
• Una iteración es un miniproyecto (un recorrido mas o menos completo a lo largo de todos los flujos de trabajo fundamenta) que obtiene como resultado una versión interna.
• El resultado de una iteración es un incremento ( un in cremento es la diferencia entre la versión interna de una iteración y la versión interna de la siguiente).
• Los modelos evolucionan con las iteraciones ( construyen los modelos incremento por incremento).
Ing. Carlos Avalos Ruiz 75
Las Iteraciones sobre el ciclo de vida
• Las iteraciones se realizan en cuatro fases.• Cada una de las cuatro fases termina con un hito
principal.– Inicio: Objetivos del ciclo de vida.– Elaboración: arquitectura del ciclo de vida. – Construcción: Funcionalidad operativa inicial.– Transición : versión del producto
Ing. Carlos Avalos Ruiz 76
Ing. Carlos Avalos Ruiz 77
¿Por qué un Desarrollo Iterativo e Incremental?
• Para tomar la rienda de los riesgos críticos y significativos desde el principio.
• Para poner en marcha una arquitectura que guíe el desarrollo del software.
• Para proporcionar un marco de trabajo que gestione de mejor forma los inevitables cambios en los requisitos y en otros aspectos.
Ing. Carlos Avalos Ruiz 78
• Para construir el sistema a lo largo del tiempo en lugar en lugar de hacerlo de una sola vez cerca del final, cuando el cambiar algo se ha vuelto costoso.
• Para proporcionar un proceso de desarrollo a través del cual el personal pueda trabajar de manera mas eficaz.
En resumen: “para obtener un software mejor”
Ing. Carlos Avalos Ruiz 79
Fases del Ciclo de vida
time
Inicio Elaboración Construcción Transición
• Inicial: define el alcance del proyecto y el límite del sistema.
• Elaboración: Plan del proyecto, características, y la línea base de la arquitectura.
• Construcción: Se construye el producto• Transición: entrega del producto al usuario
Ing. Carlos Avalos Ruiz 80
Fases e Iteraciones
Una fase es el intervalo de tiempo entre dos hitos importantes del proceso.Una iteración es una sucesión de actividades con un plan establecido y criterio de evaluación, mientras se va produciendo las versiones del sistema.
ArchIteration
... Dev Iteration
Dev Iteration
... TransIteration
...
Release Release Release Release Release Release Release Release
PrelimIteration
...
Inception Elaboration Construction TransitionElaboration Construction Transition
Ing. Carlos Avalos Ruiz 81
Creando el Proceso Unificado
Functional testingPerformance testingRequirements mgmtConf. and change mgmtBusiness engineeringData engineeringUI design
Rational Unified Process 5.01998
Rational Objectory Process 4.11996-1997
Objectory Process 1.0-3.81987-1995
The Ericsson Approach
The Rational Approach UML
Unified ProcessUnified Software Development Process
Iconix Unified Process
Rationa Unified Process 5.5