Upload
german-del-zotto
View
144
Download
2
Embed Size (px)
Citation preview
Introducción al Análisis y Diseño Orientado a Objetos
German Del Zotto Quadratica LLC
:Archivo:Archivador
:Expediente
1: existeExpediente(id)
2: getId()
AgendaSoftware, una industria con historia…El “gap” entre analístas de negocio y técnicos Introducción al mundo OOUML no es metodologíaPreguntas
Intervalo
Varias metodologías para desarrollar software– Requerimientos, Arquitectura, Modelado Visual, Iteraciones,
Calidad, CambiosAnálisis y Diseño OO
– Casos de Usos, Interacción, Actividades– Clases, Estados
Preguntas
Evolución del Desarrollo Automotriz
Año 1975: Año 2003:
Evolución del Desarrollo de Software
Año 1975:
CPUs de poca potencia+
Poca RAM+
Poco Almacenamiento+
Poca Metodología+
Poca Conectividad+
Lenguajes Primitivos
Clientes Insatisfechos
Año 2003:
Toda la potencia que uno quiera+
Más RAM que la necesaria+
Se almacena hasta lo que no se usa+
Metodologías para todos los gustos+
Conectividad barata en todos lados+
Lenguajes Poderosisimos
Clientes Insatisfechos
Evolución de la Orientación a Objetos
1967: Aparece Simula-671980: Se consolidan Smalltalk, C++,
Eiffel, CLOS1985: Múltiples Metodologías OO1992: Objectory – Ivar Jacobson1994: Nace UML1997: UML nombrado Standard del OMG
La ingeniería como aporte a las industrias
AgendaSoftware, una industria con historia…El “gap” entre analístas del negocio y técnicos Introducción al mundo OOUML no es metodologíaPreguntas
Intervalo
Varias metodologías para desarrollar software– Requerimientos, Arquitectura, Modelado Visual, Iteraciones,
Calidad, CambiosAnálisis y Diseño OO
– Casos de Usos, Interacción, Actividades– Clases, Estados
Preguntas
El “gap” entre analístas del negocio y técnicos
El “gap” entre analístas del negocio y técnicos
El “gap” entre analístas del negocio y técnicos
El “gap” entre analístas del negocio y técnicos
El “gap” entre analístas del negocio y técnicos
AgendaSoftware, una industria con historia…El “gap” entre analístas del negocio y técnicos Introducción al mundo OOUML no es metodologíaPreguntas
Intervalo
Varias metodologías para desarrollar software– Requerimientos, Arquitectura, Modelado Visual, Iteraciones,
Calidad, CambiosAnálisis y Diseño OO
– Casos de Usos, Interacción, Actividades– Clases, Estados
Preguntas
Introducción al mundo OO
¿Porque OO?Se parece más al mundo
¿Qué es un Objeto?Todo es un Objeto ¡¿~?!
¿Es lo mismo de siempre con otro nombre?Pensar en Objetos….
Introducción al mundo OO
¿Cuándo conviene usar OO?Sistemas más complejos:
– Tecnología: Plataformas Modernas– Negocios: Las crisis requieren cambios
Mucho menos ImportanteMucho más Importante
Introducción al mundo OO
¿Cuándo conviene usar OO?Sistemas más complicados:
– Integración de productos– Ambientes heterogéneos
¿Cuándo conviene usar OO?Sistemas Distribuidos:
– Requieren abstracción de las comunicaciones
Introducción al mundo OO
Introducción al mundo OO
¿Se puede no usar OO?Las empresas ahora sí aceptan a OOLas nuevas plataformas no dejan opciónSe perdería la oportunidad de:
– Desarrollar más rápido (ver todo el ciclo de desarrollo!!!)
– Reducir costos (si se busca, y logra ‘Reusar’)– Mejoras a la Arquitectura (Escalable,
Adaptable)
Introducción al mundo OO
¿Qué es un Objeto?Es una pieza de software. Son utilizados para construir un modelo que represente una situación del mundo real.
¿Qué es una Clase?Es un “molde” que define el comportamiento y estructura común que se observa en objetos de un mismo tipo.
¿Qué es una Relación?Es un recurso utilizado para describir la forma en que se relalacionan los objetos.
¿Qué es un Mensaje?Es el medio por el cual se comunican los objetos entre si.
unObjeto: Clase
ClaseotroObjeto: ClasecuantoMedis?
Introducción al mundo OO
Un objeto representa:
– Entidades Físicas
– Entidades Conceptuales
– Entidades de Software
Camión
Proceso Químico
Lista Enlazada
Introducción al mundo OO
Un objeto, visión conceptual:
ESTADO– Lo que el objeto sabe
COMPORTAMIENTO– Lo que el objeto hace
IDENTIDAD– Cada objeto es único e identificable, más allá de su
estado
Fecha de Nacimiento: 1978Lugar de Nacimiento: ArgentinaEstudios: Secundarios
Edad?EsExtranjero?OtorgarTitulo
“Matildo Evaristo del Prado Echagüe”
Introducción al mundo OO
Principios de la Orientación a Objetos:
– Abstracción
– Encapsulación
– Modularidad
– Jerarquías
Introducción al mundo OO
Objetos para los desarrolladores….
¿Cómo beneficia al “Cliente Insatisfecho”?
Análisis Estructurado / Programación OO:– “Una cabaña hecha de bloques de hielo es un iglú”– Si quiero construir una cabaña necesito:
• Madera• Planos• Serruchos y Martillos• Clavos• “la Carpintería como oficio”• CARPINTEROS!!!
•Objetos / Una Plataforma•Arquitectura•Herramientas de Desarrollo•Patrones•Metodología•Profesionales Idóneos
RECORDATORIO
CLASE: definición abstracta de un objeto
INSTANCIA: un objeto es una instancia de una clase
OBJETO: palabra demasiado utilizada
AgendaSoftware, una industria con historia…El “gap” entre analístas del negocio y técnicos Introducción al mundo OOUML no es metodologíaPreguntas
Intervalo
Varias metodologías para desarrollar software– Requerimientos, Arquitectura, Modelado Visual, Iteraciones,
Calidad, CambiosAnálisis y Diseño OO
– Casos de Usos, Interacción, Actividades– Clases, Estados
Preguntas
UML no es metodología
Lenguaje Unificado de Modelado
Unified (UNIFICADO):– El aporte de muchos métodos y notaciones– El concepto de Ciclo de Vida de Desarrollo (completo)– Para un amplio conjunto de dominios de aplicación– Más alla de implementaciones, plataformas y lenguajes– Para todo tipo de proceso de desarrollo
– Internamente autodefinido como un metamodelo
Modeling (MODELADO):– Los modelos son utilizados en todas las ingenierías
Language (LENGUAJE):– Si hay gente, requieren comunicarse, si se tienen que comunicar se
tienen que entender, necesitan un lenguaje.
UML no es metodología
Cada problema requiere una solución acorde
Los modelos simplifican la visión de
la realidad
Modelo de DespliegueModelo de Procesos
Modelo de Diseño
UML no es metodología
Un solo modelo no es suficiente
Vista de Procesos Vista de Despliegue
Vista Lógica Vista de Implementación
Programadores
Software management
Performance
escalabilidad
throughput
Integrador de Sistemas
Topología del Sistema
instalación
comunicación
Administrador de Sistemas
Analístas / Diseñadores
Estructur
View de Casos de Uso
Cliente / Usuario
Funcionalidad
UML no es metodología
Diagramas Estáticos
Múltiples VistasSintáxis y Semántica Precisa
ActivityDiagrams
Modelos
SequenceDiagrams
CollaborationDiagrams
StatechartDiagrams
DeploymentDiagrams
ComponentDiagrams
ObjectDiagrams
ClassDiagrams
Use-CaseDiagrams
UML no es metodología
user : Clerk
mainWnd : MainWnd
fileMgr : FileMgr
repository : Repositorydocument : Document
gFile : GrpFile
9: sortByName ( )
L1: Doc view request ( )
2: fetchDoc( )
5: readDoc ( )
7: readFile ( )
3: create ( )
6: fillDocument ( )
4: create ( )
8: fillFile ( )
Window95
¹®¼°ü¸® Ŭ¶óÀ̾ðÆ®.EXE
WindowsNT
¹®¼°ü¸® ¿£Áø.EXE
WindowsNT
Windows95
Solaris
ÀÀ¿ë¼¹ö.EXE
AlphaUNIX
IBM Mainframe
µ¥ÀÌŸº£À̽º¼¹ö
Windows95
¹®¼°ü¸® ¾ÖÇø´
Document
FileManager
GraphicFile
File
Repository DocumentList
FileList
user
mainWnd fileMgr : FileMgr
repositorydocument : Document
gFile
1: Doc view req uest ( )
2: fetchDoc( )
3: create ( )
4: create ( )
5: readDoc ( )
6: fi llDocument ( )
7: readFile ( )
8: fi llFile ( )
9: sortByName ( )
ƯÁ¤¹®¼¿¡ ́ ëÇÑ º̧ ±â̧ ¦ »ç¿ëÀÚ°¡ ¿äûÇÑ´Ù.
ÈÀÏ°ü̧ ®ÀÚ´Â Àоî¿Â ¹®¼ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼ °´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù.
È¸é °́ ü´Â ÀоîµéÀÎ °´Ã¼µé¿¡ ´ëÇØ ÀÌ̧ §º°·Î Á¤·ÄÀ» ½ÃÄÑ È¸é¿¡ º̧ ¿©ÁØ´Ù.
Actor A
Use Case 1
Use Case 2
Actor B
Use Case 3
GrpFile
read( )open( )create( )fillFile( )
rep
Repository
name : char * = 0
readDoc( )readFile( )
(from Persistence)
FileMgr
fetchDoc( )sortByName( )
DocumentList
add( )delete( )
Document
name : intdocid : intnumField : int
get( )open( )close( )read( )sortFileList( )create( )fillDocument( )
fList
1
FileList
add( )delete( )
1
File
read( )
read() fill the code..
Openning
Writing
ReadingClosing
add file [ numberOffile==MAX ] / flag OFF
add file
close file
close file
Mucho trabajo…
Demasiados Modelos…
¿Necesito tanto?
AgendaSoftware, una industria con historia…El “gap” entre analístas del negocio y técnicos Introducción al mundo OOUML no es metodologíaPreguntas
Intervalo
Varias metodologías para desarrollar software– Requerimientos, Arquitectura, Modelado Visual, Iteraciones,
Calidad, CambiosAnálisis y Diseño OO
– Casos de Usos, Interacción, Actividades– Clases, Estados
Preguntas
Preguntas
Intervalo
Luego veremos:
Varias metodologías para desarrollar software– Requerimientos, Arquitectura, Modelado Visual, Iteraciones,
Calidad, CambiosAnálisis y Diseño OO
– Casos de Usos, Interacción, Actividades– Clases, Estados
Preguntas
AgendaSoftware, una industria con historia…El “gap” entre analístas del negocio y técnicos Introducción al mundo OOUML no es metodologíaPreguntas
Intervalo
Varias metodologías para desarrollar software– Requerimientos, Arquitectura, Modelado Visual, Iteraciones,
Calidad, CambiosAnálisis y Diseño OO
– Casos de Usos, Interacción, Actividades– Clases, Estados
Preguntas
Varias metodologías para desarrollar software
Requerimientos
Arquitectura
Modelado Visual
Iteraciones
Calidad
Cambios
Problema
Ámbito de laSolucón
AmbitodelProblemaNecesi-
cidades
Funcionalidad / Características
Casos de Uso yRequierimiento
s
Procedimientos de Testing Diseño Docs del
Usuario
ElElSistemaSistema
Trazabilidad
SoftwareSoftwarede Basede Base
MiddlewareMiddleware
Específico delEspecífico delNegocioNegocio
Específico deEspecífico deLa AplicaciónLa Aplicación
user : Clerk
mainWnd : MainWnd
fileMgr : FileMgr
repository : Repositorydocument : Document
gFile : GrpFile
9: sortByName ( )
L1: Doc view request ( )
2: fetchDoc( )
5: readDoc ( )7: readFile ( )
3: create ( )6: fillDocument ( )
4: create ( )8: fillFile ( )
Window95
¹®¼°ü¸® Ŭ¶óÀ̾ðÆ®.EXE
WindowsNT
¹®¼°ü¸® ¿£Áø.EXE
WindowsNT
Windows95
Solaris
ÀÀ¿ë¼¹ö.EXE AlphaUNIX
IBM Mainframe
µ¥ÀÌŸº£À̽º¼¹ö
Windows95
¹®¼°ü¸® ¾ÖÇø´
Document
FileManager
GraphicFileFile
RepositoryDocumentList
FileList
usermainWndfileMgr :
FileMgrrepositorydocument :
Document
gFile
1: Doc view req uest ( )
2: fetchDoc( )
3: create ( )
4: create ( )
5: readDoc ( )
6: fi llDocument ( )
7: readFile ( )
8: fi llFile ( )
9: sortByName ( )
ƯÁ¤¹®¼¿¡ ́ ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äûÇÑ´Ù.
ÈÀÏ°ü¸®ÀÚ´Â Àоî¿Â ¹®¼ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼ °́ ü¿¡ ¼³Á¤À» ¿äûÇÑ´Ù.
È¸é °´Ã¼´Â ÀоîµéÀÎ °́ üµé¿¡ ́ ëÇØ À̸§º°·Î Á¤·ÄÀ» ½ÃÄÑ È¸é¿¡ º¸¿©ÁØ´Ù.
Actor AUse Case 1
Use Case 2
Actor B
Use Case 3
GrpFile
read( )open( )create( )fillFile( )
rep
Repository
name : char * = 0
readDoc( )readFile( )
(from Persistence)
FileMgr
fetchDoc( )sortByName( )
DocumentList
add( )delete( )
Document
name : intdocid : intnumField : int
get( )open( )close( )read( )sortFileList( )create( )fillDocument( )
fList
1
FileList
add( )delete( ) 1
File
read( )
read() fill the code..
Openning
Writing
Reading Closing
add file [ numberOffile==MAX ] / flag OFF
add file
close file
close file
ReducciónReducciónDel RiesgoDel RiesgoReducciónReducciónDel RiesgoDel Riesgo
Tiempo
Riesgo
Costo
Tiempo
ALERTREPORT
AdministraciónAmbiente
Proceso deIntegración
DesarrolloParalelo
AdministraciónBuilds
No se cumplió con las necesidades del cliente
Requerimientos inestables
Los módulos no se integran
Dificultoso de mantener
Se descubre tardiamente
Baja Calidad
Performance baja
Discusiones entre desarrolladores
Build-&-release contínuos
Requerimientos insuficientes
Comunicación ambigua
Arquitecturas quebradizas
Complejidad abrumadora
Inconsistencias no detectadas
Testing deficiente
Evaluación subjetiva
Desarrollo en cascada
Cambios no controladas
Automatización insuficiente
Síntomas Causas Reales
Varias metodologías para desarrollar software
Desarrollo Iterativo
Administración de Requerimientos
Arquitectura basada en componentes
Modelar Visualmente (UML)
Verificación Contínua de Calidad
Administrar los Cambios
Desarrollo Iterativo
Administración de Requerimientos
Arquitectura basada en componentes
Modelar Visualmente (UML)
Verificación Contínua de Calidad
Administrar los Cambios
Varias metodologías para desarrollar software
Validad decisiones de diseño enforma temprana
Manejar la complejidad del diseñoy la implementaciónincrementalmente
Mediciones temprana y frecuentesde la calidad
Evolución incremental de losBaselines
Asegurarse que los usuariosestén involucrados cuando losrequerimientos evolucionan
Varias metodologías para desarrollar software
OK
OK
Fail
Realizado porImplementado
porVerificado por
Modelo de Implementación
Modelo de TestModelo deDiseño
Modelo de Casos de Uso
Modelos
TestImplementación
Analisis &Diseño
Requerimientos
Modelo de Casosde Uso del Negocio
Modelado del Negocio
Modelo de Objetos delNegocio
BBB
B
Realizado Por
AutomatizadoPor
AgendaSoftware, una industria con historia…El “gap” entre analístas del negocio y técnicos Introducción al mundo OOUML no es metodologíaPreguntas
Intervalo
Varias metodologías para desarrollar software– Requerimientos, Arquitectura, Modelado Visual, Iteraciones,
Calidad, CambiosAnálisis y Diseño OO
– Casos de Usos, Interacción, Actividades– Clases, Estados
Preguntas
Análisis y Diseño OO
EspecificaciónSuplementaria Diagramas de
Secuencia
Diagramas de Colaboracion
Programa deCarreras
Ver Calificaciones
Anotarse en Materias
Calificar Alumnos
Postularse para Enseñar Materias
Estudiante
Profesor
Sistema Contable
Mantener Información deAlumnos
Mantener Información deProfesores
Login
Cerrar Inscripciones
Secretario
Actores:Interactúan con el sistema, no son parte del mismo
Casos de Uso:
Capturan la funcionalidad del sistemaEl Usuario tiene que poder entenderlos
Especificación deCasos de Uso
Diagrama de Casos de Uso
Casos de Uso
Análisis y Diseño OO
Pero…. ¿Qué es un Caso de Uso?
Que NO es un Caso de Uso:
No es un procesoNo es lo que hace el sistema
“Un caso de uso es cierta funcionalidad, observable externamente, que el sistema provee a los actores”
Deben ser simples, concisos y los tienen que
entender prácticamente
todos los involucrados en el
proyecto.
Deben ser simples, concisos y los tienen que
entender prácticamente
todos los involucrados en el
proyecto.
Análisis y Diseño OO
Los Casos de Uso no Cambian excepto que cambie el alcance del sistema o la forma del negocio
No se descomponen o explotan los Casos de Uso
No existe un Caso de Uso llamado “Guardar en la Base de Datos”
No existe un Caso de Uso llamado “Calcular Totales”
Un sistema no tiene más de 30 Casos de Uso (muy grande)
Análisis y Diseño OO
¿Cómo obtener los Casos de Uso?
Observando lo que hacen los Actores
Observando lo que necesitan los Actores
¿Cómo Documentarlos?
En un Modelo de Casos de UsoDiagramas de Casos de Uso
Especificaciones de Casos de UsoEspecificaciones UC
Modelo de Casos de Uso
ActoresCasos de Uso
Análisis y Diseño OO
Cada Caso de Uso:
Tiene una secuencia de transacciones normal y básica
Puede tener varias secuencias de transacciones alternativas
Generalmente tiene varias secuencias de transacciones excepcionales, las cuales manejan situaciones de error
También puede tener pre y post condiciones bien definidas
Análisis y Diseño OO
Escenarios:
Es una instancia de un Caso de Uso
Se pueden relevar fácilmente con los usuarios
Son comprobables
Sirven para generar los casos de prueba
John : Estudiante
FormularioRegistro
Cursos Disponibles
Formulario Programa
1: ingresar id
2: validar id
3: ingresar semestre actual
4: crear un nuevo programa
5: mostrar
6: obtener cursos
Análisis y Diseño OO
Diagramas de Secuencia:
Permiten observar la interacción entre los objetos del sistema
Representan a Escenarios, el usuario debería comprenderlos
Pueden generarse con más o menos nivel de abstracción
Se refinan cuando se avanza con el diseño
John : Estudiante
FormularioRegistro
Cursos Disponibles
Formulario Programa
1: ingresar id
2: validar id
3: ingresar semestre actual
4: crear un nuevo programa
5: mostrar
6: obtener cursos
Análisis y Diseño OO
Diagramas de Colaboración:
Tienen la misma información que un diagrama de secuencia
Sirven para ver las relaciones entre clases
El usuario seguramente no los podrá comprender
John : Student
registration form
schedule formavailable classes
1: enter id
2: validate id
3: enter current semester
4: create new schedule5: display
6: get courses
Análisis y Diseño OO
Diagramas de Actividad:
Reemplazan al cursograma
Ideales para representar procesos que involucran mucho actores
Más útiles para documentar Casos de Uso del negocio
Análisis y Diseño OO
Resumen
Examine los requerimientos para encontrar Actores
Identifique Casos de Usos y especifíquelos
Describa Escenarios para los Casos de Uso
Genere Diagramas de Interacción para los Escenarios
Vuelva a Empezar!!!
Recuerde
El Análisis y Diseño no es BottomUp ni TopDown
Análisis y Diseño OO
AgendaSoftware, una industria con historia…El “gap” entre analístas del negocio y técnicos Introducción al mundo OOUML no es metodologíaPreguntas
Intervalo
Varias metodologías para desarrollar software– Requerimientos, Arquitectura, Modelado Visual, Iteraciones,
Calidad, CambiosAnálisis y Diseño OO
– Casos de Usos, Interacción, Actividades– Clases, Estados
Preguntas
¿Qué es una clase?
Es una descripción para un conjuntos de Objetos que comparten las mismas responsabilidades, relaciones, operaciones, atributos y semántica.
Análisis y Diseño OO
NombredeClase
Encontrando Clases:
– Actores
– Casos de Uso
– Evaluando Escenarios
– Interfaz
Análisis y Diseño OO
Criterios a tener en cuenta:
– CohesiónDeben estar empaquetadas convenientemente
– AcoplamientoNo deben depender mutuamente
– Dominio del ProblemaDeben ser significantes para lo que estamos diseñando
– Sentido común!!!
Evite las clases superpoderosas
Análisis y Diseño OO
Principios de la Orientación a Objetos:
– Abstracción
– Encapsulación
– Modularidad
– Jerarquías
Análisis y Diseño OO
NombredeClase
Nombre
Paquete
Recurso para principiantes:
Class Responsability Cards (CRC)
Fichas de Responsabilidades de Clases
Análisis y Diseño OO
Nombre de la clase Curso
Responsabilidades Colaboradores
Agregar un estudiante
Saber donde es dado el curso
Saber cuando el curso es dado
Estudiante
Saber los prerequisitos
Servicios entregados
Conocimiento interno
Relaciones:
– Asociación “Conoce A”
Análisis y Diseño OO
Departamento
Empleado
Relaciones:
– Asociación “Conoce A”• Agregación “Tiene Un”
Análisis y Diseño OO
Banco
Cuenta Corriente
Relaciones:
– Asociación “Conoce A”• Agregación “Tiene Un”• Composición “Está Compuesto Por”
Análisis y Diseño OO
Auto
Puerta
Relaciones:
– Asociación “Conoce A”• Agregación “Tiene Un”• Composición “Está Compuesto Por”
– Generalización “Es un”
Análisis y Diseño OO
Mamífero
Elefante
Relaciones:
– Asociación “Conoce A”• Agregación “Tiene Un”• Composición “Está Compuesto Por”
– Generalización “Es un”
– Realización “Se Comporta Como”
Análisis y Diseño OO
DocumentoImprimible
Carta
Diagramas de Clases:
Deben mostrar Relaciones entre clases para una cierta visión del problema
No ayudan los diagramas con Todas las clases del sistema (pero impresionan!!!)
Análisis y Diseño OO
LineItem
- quantity : Integer- number : Integer
1..*
+lineItems
1..*
Order
- number : Integer+order
Product
- number : Integer- description : String- unitPrice : Double
11
Software Product
- version : Double
Hardware Product
- assembly : String
Diagramas de Clases:
Muestran la estructura estática del sistemaUn diagrama de clases por paqueteDiagramas de clases especiales para mostrar
algo específicoDiagramas conceptuales para mostrar
estructuras que son comunes a todo el sistema
Análisis y Diseño OO
AgendaSoftware, una industria con historia…El “gap” entre analístas del negocio y técnicos Introducción al mundo OOUML no es metodologíaPreguntas
Intervalo
Varias metodologías para desarrollar software– Requerimientos, Arquitectura, Modelado Visual, Iteraciones,
Calidad, CambiosAnálisis y Diseño OO
– Casos de Usos, Interacción, Actividades– Clases, Estados
Preguntas
Preguntas
MUCHAS GRACIASPOR SU PRESENCIA
German Del Zotto Quadratica LLC