Msdn 2003-10-23

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

Preguntas

El “gap” entre analístas del negocio y técnicos

Intervalo

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….

¿Cuándo conviene usar OO?Sistemas más complejos:

– Tecnología: Plataformas Modernas– Negocios: Las crisis requieren cambios

Mucho menos ImportanteMucho más Importante

¿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

¿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)

¿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?

Un objeto representa:

– Entidades Físicas

– Entidades Conceptuales

– Entidades de Software

Camión

Proceso Químico

Lista Enlazada

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”

Principios de la Orientación a Objetos:

– Abstracción

– Encapsulación

– Modularidad

– Jerarquías

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

Intervalo

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.

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

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

Diagramas Estáticos

Múltiples VistasSintáxis y Semántica Precisa

ActivityDiagrams

Modelos

SequenceDiagrams

CollaborationDiagrams

StatechartDiagrams

DeploymentDiagrams

ComponentDiagrams

ObjectDiagrams

ClassDiagrams

Use-CaseDiagrams

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

Repository DocumentList

FileList

mainWnd fileMgr : FileMgr

repositorydocument : Document

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( )

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( )

FileList

add( )delete( )

read( )

read() fill the code..

Openning

Writing

ReadingClosing

add file [ numberOffile==MAX ] / flag OFF

add file

close file

Mucho trabajo…

Demasiados Modelos…

¿Necesito tanto?

Intervalo

Preguntas

Intervalo

Luego veremos:

Preguntas

Intervalo

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

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

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( )

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( )

FileList

add( )delete( ) 1

read( )

read() fill the code..

Openning

Writing

Reading Closing

add file [ numberOffile==MAX ] / flag OFF

add file

close file

ReducciónReducciónDel RiesgoDel RiesgoReducciónReducciónDel RiesgoDel Riesgo

Tiempo

Riesgo

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

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

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

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

Realizado Por

AutomatizadoPor

Intervalo

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

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

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.

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)

¿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

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

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

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

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

Diagramas de Actividad:

Reemplazan al cursograma

Ideales para representar procesos que involucran mucho actores

Más útiles para documentar Casos de Uso del negocio

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

Intervalo

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.

NombredeClase

Encontrando Clases:

– Actores

– Casos de Uso

– Evaluando Escenarios

– Interfaz

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

Principios de la Orientación a Objetos:

– Abstracción

– Encapsulación

– Modularidad

– Jerarquías

NombredeClase

Nombre

Paquete

Recurso para principiantes:

Class Responsability Cards (CRC)

Fichas de Responsabilidades de Clases

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”

Departamento

Empleado

Relaciones:

– Asociación “Conoce A”• Agregación “Tiene Un”

Cuenta Corriente

Relaciones:

– Asociación “Conoce A”• Agregación “Tiene Un”• Composición “Está Compuesto Por”

Puerta

Relaciones:

– Generalización “Es un”

Mamífero

Elefante

Relaciones:

– Generalización “Es un”

– Realización “Se Comporta Como”

DocumentoImprimible

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!!!)

LineItem

- quantity : Integer- number : Integer

+lineItems

- number : Integer+order

Product

- number : Integer- description : String- unitPrice : Double

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

Intervalo

Preguntas

MUCHAS GRACIASPOR SU PRESENCIA

German Del Zotto Quadratica LLC

Msdn 2003-10-23

Documents

Transcript of Msdn 2003-10-23

СП 23-102-2003 Естеств освещ · СНиП 23-01-99*. Строительная климатология СНиП 23-02-2003. Тепловая защита зданий

MSDN Briefing Octubre 2002 ¡Bienvenidos!. ¿Qué es Microsoft MSDN? Programa de actualización tecnológica para analistas, desarrolladores Eventos Web Site.

Mistica 2003 # 23 de 24

Curso de Wpf-msdn

GUIDE DE L’UTILISATEUR - download.microsoft.comdownload.microsoft.com/documents/France/MSDN/2010/MSDNAA/Guide... · MSDN AA signifie Microsoft Developer Network Academic Alliance.

MSDN Webcast: Trabalhando com covariância e contravariância no C# 4

HƯỚNG DẪN SỬ DỤNG TÀI KHOẢN MSDN AA

Informativo Fucapi - Ed.23 - 2003

MSDN - Converting an existing ASP.NET application to Windows Azure

Retour d’expérience GlobeCast : Réduisez votre TCO avec les abonnements MSDN

Manual de Uso MSDN Academic Alliancesitios.ucsc.cl/msdn/wp-content/uploads/sites/95/2018/10/... · 2018. 12. 10. · DreamSpark Premium ... tal cual

DECRETO 23 luglio 2003.

MSDN Webcast · 2020-04-26 · MSDN Webcast: TFS 2008: Mit definierten Buildprozessen und Continuous Integration zu mehr Softwarequalität Visual Studio Team System (Teil 5 von 10)

Santiago, 23 de setiembre de 2003

Pressekonferenz 3. Quartal 2003 23. Oktober 2003.

Giới thiệu & Triển khai chương trình MSDN-aa promotion

MSDN- Abonnementsdownload.microsoft.com/.../MSDN-Abonnement-Administratorhandbuch.pdf · 5 Willkommen für MSDN-Administratoren Als MSDN-Administrator spielen Sie eine wichtige Rolle

Номер 22-23, 2003

СНиП 23-02-2003...2003/02/23 · СП 50.13330.2012 Предисловие Цели и принципы стандартизации в Российской Федерации

23 Mei 2002 23 mei 2003 5 april 2003 5 april 2002