SlideShare una empresa de Scribd logo
1 de 23
Descargar para leer sin conexión
Diseño Orientado a objetos
René Guamán-Quinche
Facultad de la Energía, las Industrias y los Recursos Naturales No Renovables
Carrera de Ingeniería en Sistemas/Computación
Octubre, 2021
Loja, Ecuador
2
1. Objetos y clases
2. Un proceso de diseño orientado a objetos
3. Modelos del Diseño
4. Contexto del sistema y modelos de utilización
5. Diseño de arquitectura
Contenido
3
Diseño basado a objetos
Un sistema orientado a objetos está compuesto de objetos que interactúan, los cuales
mantienen ellos mismos su estado local y proveen operaciones sobre su estado
• Análisis orientado a objetos: desarrollo de un modelo orientado a objetos del dominio. Los
objetos reflejan las entidades y operaciones que se asocian con el problema a resolver
• Diseño orientado a objetos: desarrollo de un modelo orientado a objetos de un sistema software
para implementar los requerimientos identificados. Los objetos pueden existir relaciones estrechas
entre algunos objetos del problema y algunos objetos de la solución. El diseñador tiene que
agregar nuevos objetos para transformar los objetos del problema e implementar la solución
• Programación orientada a objetos: se refiere a implementar el diseño de software utilizando un
lenguaje de programación orientado a objetos, como Java
4
Objetos y clases
5
Objetos y clases
Un objeto es una entidad que tiene un estado y un conjunto de
operaciones definidas que operan sobre ese estado. El estado se
representa como un conjunto de atributos del objeto. Las
operaciones asociadas al objeto proveen servicios a otros objetos
(clientes) que solicitan estos servicios cuando se requiere llevar a
cabo algún cálculo
Los objetos se crean conforme a una definición de clases de objetos.
Una definición de clases sirve como una plantilla para crear
objetos. Esta incluye las declaraciones de todos ¡os atributos y
operaciones asociados con un objeto de esa clase.
6
Objetos y clases
Las clases se pueden organizar mediante una
generalización o jerarquía de herencia que muestra las
relaciones entre las clases generales y más específicas
7
Objetos y clases
Objetos concurrentes
• Un objeto solicita un servicio de otro
objeto enviándole un mensaje de «solicitud
de servicio» a ese objeto
• No es necesario que un objeto ejecute estos
mensajes en forma secuencial y que espere
hasta completar un servicio solicitado
El modelo general de interacción de objetos les permite
ejecutarse concurrentemente como procesos en paralelo
8
Un proceso de diseño orientado a objetos
Proceso General:
1. Comprender y definir el contexto y los modos de utilización del sistema
2. Diseñar la arquitectura del sistema
3. Identificar los objetos principales en el sistema
4. Desarrollar los modelos de diseño
5. Especificar las interfaces de los objetos
9
Un proceso de diseño orientado a objetos
Problema
Se requiere un sistema para generar mapas meteorológicos a partir de la recogida pe-
riódica de los datos de estaciones meteorológicas remotas y automáticas y datos de
otras fuentes, como observatorios meteorológicos, globos v satélites. Las estaciones
meteorológicas transmiten sus datos a la computadora del área en respuesta a una pe-
tición de esa máquina.
El sistema de cómputo del área valida los datos recogidos e integra los datos de diver-
sas fuentes. Los dalos integrados se guardan y, utilizando datos de este archivo y una
base de datos de mapas digitalizados. se crea un conjunto local de mapas meteoroló-
gicos. Los mapas se pueden imprimir para su distribución en una impresora de mapas
de propósito especial y pueden ser visualizados en pantalla en diferentes formatos.
10
Un proceso de diseño orientado a objetos
Esta descripción muestra que parte del
sistema completo se refiere a la recogida
de datos, parte a la integración de los
datos de diversas fuentes, parte a archivar
estos datos y parte a crear mapas
meteorológicos
11
Un proceso de diseño orientado a objetos
En la figura anterior se muestran diferentes capas y se incluye el nombre de la capa
en un símbolo de representación de paquetes en UML que se ha denotado como un
subsistema
Un paquete en UML representa una colección de objetos y otros paquetes
12
Contexto del sistema y modelos de utilización
La primera etapa -> proceso de diseño de software
• Comprender las relaciones entre el software y el entorno externo
• Comprender esto ayuda a decidir cómo suministrar la funcionalidad requerida al
sistema
• Cómo estructurar éste para que se comunique efectivamente con su entorno
El contexto del sistema y el modelo de utilización del sistema representan dos modelos
complementarios entre un sistema y su entorno:
1. El contexto del sistema es un modelo estático que describe a los otros sistemas de su
entorno
2. El modelo de utilización del sistema es un modelo dinámico que describe cómo el
sistema interactúa con su entorno
13
Contexto del sistema y modelos de utilización
Se ha extendido este modelo de arquitectura
abstracta para mostrar los componentes de
los subsistemas
Sigue muy abstractos y se han derivado de la
información en la descripción del sistema
El modelo de contexto se produce un
diagrama de bloques sencillo de la
arquitectura del sistema completo.
Se puede extender representando un modelo
del subsistema utilizando paquetes en
UML
14
Diseño de arquitectura
Una vez que se han definido las interacciones entre el sistema de software que se está dise-
ñando y el entorno del sistema, se puede utilizar esta información como base para diseñar la
arquitectura del sistema
Es necesario combinar esto con el conocimiento general de los principios de diseño
arquitectónico y con el conocimiento más detallado del dominio.
Las tres capas en el software de la estación meteorológica son:
1. La capa de interfaz, que comprende todas las comunicaciones con otras partes del sistema y el
suministro de las interfaces extemas del sistema
2. La capa de recogida de datos, que se ocupa de administrar la recogida de datos de los instrumentos
y de resumir los datos meteorológicos antes de la transmisión al sistema de mapas.
3. La capa de instrumentos, que comprende el encapsulamiento de todos los instrumentos utilizados
en la recogida de los datos acerca de las condiciones meteorológicas.
15
Diseño de arquitectura
16
Diseño de arquitectura
Identificación de objetos
• Utilizar un análisis gramatical de la descripción en lenguaje natural del sistema
• Utilizar entidades tangibles (cosas) en el dominio
• Utilizar un enfoque de comportamiento en el cual el diseñador primero comprende el
comportamiento total del Sistema
• Utilizar un análisis basado en escenarios en el cual se identifican y analizan en su momento
varios escenarios de la forma de utilizar el sistema
17
Diseño de arquitectura
Identificación de objetos
18
Modelos del diseño
Los modelos de diseño muestran los objetos o clases en un sistema y, donde sea apropiado, los diferentes
tipos de relaciones entre estas entidades
Dos tipos de modelos de diseño para describir un diseño orientado a objetos:
1. Modelos estáticos que describen la estructura estática del sistema en términos de las clases del sistema y sus
relaciones. Las relaciones importantes que se documentan en esta etapa son de generalización,
utiliza/utilizado-por y de composición
1. Modelos dinámicos que describen la estructura dinámica del sistema y que muestran las interacciones entre
los objetos del sistema (no entre las clases). Las interacciones que se documentan incluyen la secuencia de
servicios solicitados por los objetos y la forma en que el estado del sistema se relaciona con estas
interacciones de objetos
UML provee 12 modelos estáticos y dinámicos que pueden ser utilizados en el documentos de diseño
Modelos del diseño
Algunos modelos
1. 1. Los modelos de subsistemas que muestran las agrupaciones lógicas de objetos en
subsistemas coherentes. Estos se representan utilizando una forma de los diagramas de
clase en el que cada subsistema se muestra como un paquete. Los modelos de subsis-
temas son modelos estáticos.
1. Los modelos de secuencia que muestran la secuencia de interacciones de los objetos.
Estos se representan utilizando una secuencia UML o un diagrama de colaboración.
Los modelos de secuencia son modelos dinámicos
2. Los modelos de máquinas de estado que muestran cómo los objetos individuales cam-
bian su estado en respuesta a los eventos. Esto se representa en UML utilizando dia-
gramas de estado los cuales son modelos dinámicos.
20
Modelos del diseño
Los modelos de diseño muestran los objetos o clases
en un sistema y, donde sea apropiado, los diferentes
tipos de relaciones entre estas entidades
21
Modelos del diseño
22
Cŕeditos
• Transparencias basadas por:
• IAN SOMMERVILLE, Ingeniería de Software, Séptima edición
Networking académico:
Correo electrónico: rguaman@unl.edu.ec
Twitter: @rene5254
SlideShare: https://es.slideshare.net/rene5254
23
Gracias

Más contenido relacionado

La actualidad más candente

Tecnicas de estimacion de software
Tecnicas de estimacion de softwareTecnicas de estimacion de software
Tecnicas de estimacion de softwareAdes27
 
Descomposición modular y estilos de control
Descomposición modular y estilos de controlDescomposición modular y estilos de control
Descomposición modular y estilos de controlJuan Pablo Bustos Thames
 
Diagrama de interaccion(secuencia y colaboracion)
Diagrama de interaccion(secuencia y colaboracion)Diagrama de interaccion(secuencia y colaboracion)
Diagrama de interaccion(secuencia y colaboracion)marianela0393
 
Presentación Modelo de Datos
Presentación Modelo de DatosPresentación Modelo de Datos
Presentación Modelo de DatosEnrique Cabello
 
Modelos de desarrollo del software
Modelos de desarrollo del softwareModelos de desarrollo del software
Modelos de desarrollo del softwareRenny Batista
 
Enfoque estructurado y Enfoque OO - Ingenieria de software
Enfoque estructurado y Enfoque OO  - Ingenieria de softwareEnfoque estructurado y Enfoque OO  - Ingenieria de software
Enfoque estructurado y Enfoque OO - Ingenieria de softwareKola Real
 
Casos de Uso ejercicios
Casos de Uso ejerciciosCasos de Uso ejercicios
Casos de Uso ejerciciosWalter Chacon
 
Analisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A ObjetosAnalisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A Objetosyoiner santiago
 
Sistemas expertos
Sistemas expertosSistemas expertos
Sistemas expertosAngel Reyes
 
Tipos de Requerimientos en Ingeniería de Software
Tipos de Requerimientos en Ingeniería de SoftwareTipos de Requerimientos en Ingeniería de Software
Tipos de Requerimientos en Ingeniería de SoftwareLeo Ruelas Rojas
 
Diagrama componentes
Diagrama componentesDiagrama componentes
Diagrama componentesmarianela0393
 

La actualidad más candente (20)

Tecnicas de estimacion de software
Tecnicas de estimacion de softwareTecnicas de estimacion de software
Tecnicas de estimacion de software
 
Descomposición modular y estilos de control
Descomposición modular y estilos de controlDescomposición modular y estilos de control
Descomposición modular y estilos de control
 
Diseño orientado a objeto
Diseño orientado a objetoDiseño orientado a objeto
Diseño orientado a objeto
 
Diagrama de interaccion(secuencia y colaboracion)
Diagrama de interaccion(secuencia y colaboracion)Diagrama de interaccion(secuencia y colaboracion)
Diagrama de interaccion(secuencia y colaboracion)
 
Modelos de datos y procesos
Modelos de datos y procesosModelos de datos y procesos
Modelos de datos y procesos
 
Use case diagram
Use case diagramUse case diagram
Use case diagram
 
Presentación Modelo de Datos
Presentación Modelo de DatosPresentación Modelo de Datos
Presentación Modelo de Datos
 
Diseño Estructurado
Diseño EstructuradoDiseño Estructurado
Diseño Estructurado
 
Modelos de desarrollo del software
Modelos de desarrollo del softwareModelos de desarrollo del software
Modelos de desarrollo del software
 
Taller de Base de Datos - Unidad 6 SQL procedural
Taller de Base de Datos - Unidad 6 SQL proceduralTaller de Base de Datos - Unidad 6 SQL procedural
Taller de Base de Datos - Unidad 6 SQL procedural
 
Diseño caso de pruebas
Diseño caso de pruebasDiseño caso de pruebas
Diseño caso de pruebas
 
Enfoque estructurado y Enfoque OO - Ingenieria de software
Enfoque estructurado y Enfoque OO  - Ingenieria de softwareEnfoque estructurado y Enfoque OO  - Ingenieria de software
Enfoque estructurado y Enfoque OO - Ingenieria de software
 
Casos de Uso ejercicios
Casos de Uso ejerciciosCasos de Uso ejercicios
Casos de Uso ejercicios
 
Analisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A ObjetosAnalisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A Objetos
 
Sistemas expertos
Sistemas expertosSistemas expertos
Sistemas expertos
 
Tipos de Requerimientos en Ingeniería de Software
Tipos de Requerimientos en Ingeniería de SoftwareTipos de Requerimientos en Ingeniería de Software
Tipos de Requerimientos en Ingeniería de Software
 
10.el diseño en el nivel de componentes
10.el diseño en el nivel de componentes10.el diseño en el nivel de componentes
10.el diseño en el nivel de componentes
 
Diagrama componentes
Diagrama componentesDiagrama componentes
Diagrama componentes
 
PAGINACION Y SEGMENTACION DE MEMORIA
PAGINACION Y SEGMENTACION DE MEMORIAPAGINACION Y SEGMENTACION DE MEMORIA
PAGINACION Y SEGMENTACION DE MEMORIA
 
Modelo 4+1
Modelo 4+1Modelo 4+1
Modelo 4+1
 

Similar a Unidad 2 diseño orientado a objetos

Metodología orientada a objetos (omt). rumbaugh
Metodología orientada a objetos (omt). rumbaughMetodología orientada a objetos (omt). rumbaugh
Metodología orientada a objetos (omt). rumbaughWilfredy Inciarte
 
Tipos de modelo y metodologias
Tipos de modelo y metodologiasTipos de modelo y metodologias
Tipos de modelo y metodologiasJosafat Mtz
 
Metodologã­a orientada-a-objetos-omt.-rumbaugh
Metodologã­a orientada-a-objetos-omt.-rumbaughMetodologã­a orientada-a-objetos-omt.-rumbaugh
Metodologã­a orientada-a-objetos-omt.-rumbaughviisistemas
 
Modelado Orientado a Objetos
Modelado Orientado a ObjetosModelado Orientado a Objetos
Modelado Orientado a ObjetosRafael Miranda
 
Diseño de sistemas - UML - compendio
Diseño de sistemas  -  UML - compendioDiseño de sistemas  -  UML - compendio
Diseño de sistemas - UML - compendioJose Diaz Silva
 
Planificacion de proyecto de software
Planificacion de proyecto de softwarePlanificacion de proyecto de software
Planificacion de proyecto de softwareYORGELIS1608
 
Proceso de analisis de sistema
Proceso de analisis de sistemaProceso de analisis de sistema
Proceso de analisis de sistemaAlexander Tua
 
aplicado al analisis y diseño de REA diseño computacional
aplicado al analisis y diseño de REA diseño computacionalaplicado al analisis y diseño de REA diseño computacional
aplicado al analisis y diseño de REA diseño computacionalAriel Adolfo Rodriguez Hernandez
 

Similar a Unidad 2 diseño orientado a objetos (20)

Metodologia para el proyecto
Metodologia para el proyectoMetodologia para el proyecto
Metodologia para el proyecto
 
Metodología orientada a objetos (omt). rumbaugh
Metodología orientada a objetos (omt). rumbaughMetodología orientada a objetos (omt). rumbaugh
Metodología orientada a objetos (omt). rumbaugh
 
Tipos de modelo y metodologias
Tipos de modelo y metodologiasTipos de modelo y metodologias
Tipos de modelo y metodologias
 
Metodologã­a orientada-a-objetos-omt.-rumbaugh
Metodologã­a orientada-a-objetos-omt.-rumbaughMetodologã­a orientada-a-objetos-omt.-rumbaugh
Metodologã­a orientada-a-objetos-omt.-rumbaugh
 
Modelado Orientado a Objetos
Modelado Orientado a ObjetosModelado Orientado a Objetos
Modelado Orientado a Objetos
 
6070_TRECALDE_00288.ppt
6070_TRECALDE_00288.ppt6070_TRECALDE_00288.ppt
6070_TRECALDE_00288.ppt
 
Diseño de sistemas - UML - compendio
Diseño de sistemas  -  UML - compendioDiseño de sistemas  -  UML - compendio
Diseño de sistemas - UML - compendio
 
Lenguajes de programación: UML
Lenguajes de programación: UMLLenguajes de programación: UML
Lenguajes de programación: UML
 
Metodología OOSE.pdf
Metodología OOSE.pdfMetodología OOSE.pdf
Metodología OOSE.pdf
 
Planificacion de proyecto de software
Planificacion de proyecto de softwarePlanificacion de proyecto de software
Planificacion de proyecto de software
 
Uml albagni camila ibarguen asprilla
Uml albagni camila ibarguen asprillaUml albagni camila ibarguen asprilla
Uml albagni camila ibarguen asprilla
 
Uml
UmlUml
Uml
 
Metodologia uml
Metodologia umlMetodologia uml
Metodologia uml
 
Metodologia uml
Metodologia umlMetodologia uml
Metodologia uml
 
Metodologia UML
Metodologia UMLMetodologia UML
Metodologia UML
 
Uml
UmlUml
Uml
 
7 analisis
7 analisis7 analisis
7 analisis
 
Proceso de analisis de sistema
Proceso de analisis de sistemaProceso de analisis de sistema
Proceso de analisis de sistema
 
7 analisis (caso de uso)
7 analisis  (caso de uso)7 analisis  (caso de uso)
7 analisis (caso de uso)
 
aplicado al analisis y diseño de REA diseño computacional
aplicado al analisis y diseño de REA diseño computacionalaplicado al analisis y diseño de REA diseño computacional
aplicado al analisis y diseño de REA diseño computacional
 

Más de Rene Guaman-Quinche

Paradigma Programación Orientada a Objetos
Paradigma Programación Orientada a ObjetosParadigma Programación Orientada a Objetos
Paradigma Programación Orientada a ObjetosRene Guaman-Quinche
 
Fundamentos ingeniería de requisitos.pdf
Fundamentos ingeniería de requisitos.pdfFundamentos ingeniería de requisitos.pdf
Fundamentos ingeniería de requisitos.pdfRene Guaman-Quinche
 
Arquitectura sw varios niveles.pdf
Arquitectura sw varios niveles.pdfArquitectura sw varios niveles.pdf
Arquitectura sw varios niveles.pdfRene Guaman-Quinche
 
Introducción a los sistemas distribuidos
Introducción a los sistemas distribuidosIntroducción a los sistemas distribuidos
Introducción a los sistemas distribuidosRene Guaman-Quinche
 
Sistema de Archivos Distribuidos
Sistema de Archivos DistribuidosSistema de Archivos Distribuidos
Sistema de Archivos DistribuidosRene Guaman-Quinche
 
Tiempo, causalidad y estado global
Tiempo, causalidad y estado globalTiempo, causalidad y estado global
Tiempo, causalidad y estado globalRene Guaman-Quinche
 
Tiempo, causalidad y estado global Alberto Lafuente Teorìa
Tiempo, causalidad y estado global Alberto Lafuente TeorìaTiempo, causalidad y estado global Alberto Lafuente Teorìa
Tiempo, causalidad y estado global Alberto Lafuente TeorìaRene Guaman-Quinche
 
Tiempo, causalidad y estado global Alberto Lafuente Transparencias
Tiempo, causalidad y estado global Alberto Lafuente TransparenciasTiempo, causalidad y estado global Alberto Lafuente Transparencias
Tiempo, causalidad y estado global Alberto Lafuente TransparenciasRene Guaman-Quinche
 
Comunicacion intra procesos con socket
Comunicacion intra procesos con socketComunicacion intra procesos con socket
Comunicacion intra procesos con socketRene Guaman-Quinche
 

Más de Rene Guaman-Quinche (20)

interfaces.pdf
interfaces.pdfinterfaces.pdf
interfaces.pdf
 
Paradigma Programación Orientada a Objetos
Paradigma Programación Orientada a ObjetosParadigma Programación Orientada a Objetos
Paradigma Programación Orientada a Objetos
 
Fundamentos ingeniería de requisitos.pdf
Fundamentos ingeniería de requisitos.pdfFundamentos ingeniería de requisitos.pdf
Fundamentos ingeniería de requisitos.pdf
 
replicacion heterogenea.pdf
replicacion heterogenea.pdfreplicacion heterogenea.pdf
replicacion heterogenea.pdf
 
Elicitación de requerimientos
Elicitación de requerimientosElicitación de requerimientos
Elicitación de requerimientos
 
Arquitectura sw varios niveles.pdf
Arquitectura sw varios niveles.pdfArquitectura sw varios niveles.pdf
Arquitectura sw varios niveles.pdf
 
Hilos con Posix
Hilos con PosixHilos con Posix
Hilos con Posix
 
Introducción a los sistemas distribuidos
Introducción a los sistemas distribuidosIntroducción a los sistemas distribuidos
Introducción a los sistemas distribuidos
 
Diagramas de secuencia
Diagramas de secuenciaDiagramas de secuencia
Diagramas de secuencia
 
Sistema de Archivos Distribuidos
Sistema de Archivos DistribuidosSistema de Archivos Distribuidos
Sistema de Archivos Distribuidos
 
RPC
RPCRPC
RPC
 
Tiempo, causalidad y estado global
Tiempo, causalidad y estado globalTiempo, causalidad y estado global
Tiempo, causalidad y estado global
 
Tiempo, causalidad y estado global Alberto Lafuente Teorìa
Tiempo, causalidad y estado global Alberto Lafuente TeorìaTiempo, causalidad y estado global Alberto Lafuente Teorìa
Tiempo, causalidad y estado global Alberto Lafuente Teorìa
 
Tiempo, causalidad y estado global Alberto Lafuente Transparencias
Tiempo, causalidad y estado global Alberto Lafuente TransparenciasTiempo, causalidad y estado global Alberto Lafuente Transparencias
Tiempo, causalidad y estado global Alberto Lafuente Transparencias
 
Ciclo de vida software
Ciclo de vida softwareCiclo de vida software
Ciclo de vida software
 
Comunicacion intra procesos con socket
Comunicacion intra procesos con socketComunicacion intra procesos con socket
Comunicacion intra procesos con socket
 
Modelo paso de mensajes
Modelo paso de mensajesModelo paso de mensajes
Modelo paso de mensajes
 
RMI
RMIRMI
RMI
 
Requisitos no Funcionales
Requisitos no FuncionalesRequisitos no Funcionales
Requisitos no Funcionales
 
Requisitos funcionales
Requisitos funcionalesRequisitos funcionales
Requisitos funcionales
 

Unidad 2 diseño orientado a objetos

  • 1. Diseño Orientado a objetos René Guamán-Quinche Facultad de la Energía, las Industrias y los Recursos Naturales No Renovables Carrera de Ingeniería en Sistemas/Computación Octubre, 2021 Loja, Ecuador
  • 2. 2 1. Objetos y clases 2. Un proceso de diseño orientado a objetos 3. Modelos del Diseño 4. Contexto del sistema y modelos de utilización 5. Diseño de arquitectura Contenido
  • 3. 3 Diseño basado a objetos Un sistema orientado a objetos está compuesto de objetos que interactúan, los cuales mantienen ellos mismos su estado local y proveen operaciones sobre su estado • Análisis orientado a objetos: desarrollo de un modelo orientado a objetos del dominio. Los objetos reflejan las entidades y operaciones que se asocian con el problema a resolver • Diseño orientado a objetos: desarrollo de un modelo orientado a objetos de un sistema software para implementar los requerimientos identificados. Los objetos pueden existir relaciones estrechas entre algunos objetos del problema y algunos objetos de la solución. El diseñador tiene que agregar nuevos objetos para transformar los objetos del problema e implementar la solución • Programación orientada a objetos: se refiere a implementar el diseño de software utilizando un lenguaje de programación orientado a objetos, como Java
  • 5. 5 Objetos y clases Un objeto es una entidad que tiene un estado y un conjunto de operaciones definidas que operan sobre ese estado. El estado se representa como un conjunto de atributos del objeto. Las operaciones asociadas al objeto proveen servicios a otros objetos (clientes) que solicitan estos servicios cuando se requiere llevar a cabo algún cálculo Los objetos se crean conforme a una definición de clases de objetos. Una definición de clases sirve como una plantilla para crear objetos. Esta incluye las declaraciones de todos ¡os atributos y operaciones asociados con un objeto de esa clase.
  • 6. 6 Objetos y clases Las clases se pueden organizar mediante una generalización o jerarquía de herencia que muestra las relaciones entre las clases generales y más específicas
  • 7. 7 Objetos y clases Objetos concurrentes • Un objeto solicita un servicio de otro objeto enviándole un mensaje de «solicitud de servicio» a ese objeto • No es necesario que un objeto ejecute estos mensajes en forma secuencial y que espere hasta completar un servicio solicitado El modelo general de interacción de objetos les permite ejecutarse concurrentemente como procesos en paralelo
  • 8. 8 Un proceso de diseño orientado a objetos Proceso General: 1. Comprender y definir el contexto y los modos de utilización del sistema 2. Diseñar la arquitectura del sistema 3. Identificar los objetos principales en el sistema 4. Desarrollar los modelos de diseño 5. Especificar las interfaces de los objetos
  • 9. 9 Un proceso de diseño orientado a objetos Problema Se requiere un sistema para generar mapas meteorológicos a partir de la recogida pe- riódica de los datos de estaciones meteorológicas remotas y automáticas y datos de otras fuentes, como observatorios meteorológicos, globos v satélites. Las estaciones meteorológicas transmiten sus datos a la computadora del área en respuesta a una pe- tición de esa máquina. El sistema de cómputo del área valida los datos recogidos e integra los datos de diver- sas fuentes. Los dalos integrados se guardan y, utilizando datos de este archivo y una base de datos de mapas digitalizados. se crea un conjunto local de mapas meteoroló- gicos. Los mapas se pueden imprimir para su distribución en una impresora de mapas de propósito especial y pueden ser visualizados en pantalla en diferentes formatos.
  • 10. 10 Un proceso de diseño orientado a objetos Esta descripción muestra que parte del sistema completo se refiere a la recogida de datos, parte a la integración de los datos de diversas fuentes, parte a archivar estos datos y parte a crear mapas meteorológicos
  • 11. 11 Un proceso de diseño orientado a objetos En la figura anterior se muestran diferentes capas y se incluye el nombre de la capa en un símbolo de representación de paquetes en UML que se ha denotado como un subsistema Un paquete en UML representa una colección de objetos y otros paquetes
  • 12. 12 Contexto del sistema y modelos de utilización La primera etapa -> proceso de diseño de software • Comprender las relaciones entre el software y el entorno externo • Comprender esto ayuda a decidir cómo suministrar la funcionalidad requerida al sistema • Cómo estructurar éste para que se comunique efectivamente con su entorno El contexto del sistema y el modelo de utilización del sistema representan dos modelos complementarios entre un sistema y su entorno: 1. El contexto del sistema es un modelo estático que describe a los otros sistemas de su entorno 2. El modelo de utilización del sistema es un modelo dinámico que describe cómo el sistema interactúa con su entorno
  • 13. 13 Contexto del sistema y modelos de utilización Se ha extendido este modelo de arquitectura abstracta para mostrar los componentes de los subsistemas Sigue muy abstractos y se han derivado de la información en la descripción del sistema El modelo de contexto se produce un diagrama de bloques sencillo de la arquitectura del sistema completo. Se puede extender representando un modelo del subsistema utilizando paquetes en UML
  • 14. 14 Diseño de arquitectura Una vez que se han definido las interacciones entre el sistema de software que se está dise- ñando y el entorno del sistema, se puede utilizar esta información como base para diseñar la arquitectura del sistema Es necesario combinar esto con el conocimiento general de los principios de diseño arquitectónico y con el conocimiento más detallado del dominio. Las tres capas en el software de la estación meteorológica son: 1. La capa de interfaz, que comprende todas las comunicaciones con otras partes del sistema y el suministro de las interfaces extemas del sistema 2. La capa de recogida de datos, que se ocupa de administrar la recogida de datos de los instrumentos y de resumir los datos meteorológicos antes de la transmisión al sistema de mapas. 3. La capa de instrumentos, que comprende el encapsulamiento de todos los instrumentos utilizados en la recogida de los datos acerca de las condiciones meteorológicas.
  • 16. 16 Diseño de arquitectura Identificación de objetos • Utilizar un análisis gramatical de la descripción en lenguaje natural del sistema • Utilizar entidades tangibles (cosas) en el dominio • Utilizar un enfoque de comportamiento en el cual el diseñador primero comprende el comportamiento total del Sistema • Utilizar un análisis basado en escenarios en el cual se identifican y analizan en su momento varios escenarios de la forma de utilizar el sistema
  • 18. 18 Modelos del diseño Los modelos de diseño muestran los objetos o clases en un sistema y, donde sea apropiado, los diferentes tipos de relaciones entre estas entidades Dos tipos de modelos de diseño para describir un diseño orientado a objetos: 1. Modelos estáticos que describen la estructura estática del sistema en términos de las clases del sistema y sus relaciones. Las relaciones importantes que se documentan en esta etapa son de generalización, utiliza/utilizado-por y de composición 1. Modelos dinámicos que describen la estructura dinámica del sistema y que muestran las interacciones entre los objetos del sistema (no entre las clases). Las interacciones que se documentan incluyen la secuencia de servicios solicitados por los objetos y la forma en que el estado del sistema se relaciona con estas interacciones de objetos UML provee 12 modelos estáticos y dinámicos que pueden ser utilizados en el documentos de diseño
  • 19. Modelos del diseño Algunos modelos 1. 1. Los modelos de subsistemas que muestran las agrupaciones lógicas de objetos en subsistemas coherentes. Estos se representan utilizando una forma de los diagramas de clase en el que cada subsistema se muestra como un paquete. Los modelos de subsis- temas son modelos estáticos. 1. Los modelos de secuencia que muestran la secuencia de interacciones de los objetos. Estos se representan utilizando una secuencia UML o un diagrama de colaboración. Los modelos de secuencia son modelos dinámicos 2. Los modelos de máquinas de estado que muestran cómo los objetos individuales cam- bian su estado en respuesta a los eventos. Esto se representa en UML utilizando dia- gramas de estado los cuales son modelos dinámicos.
  • 20. 20 Modelos del diseño Los modelos de diseño muestran los objetos o clases en un sistema y, donde sea apropiado, los diferentes tipos de relaciones entre estas entidades
  • 22. 22 Cŕeditos • Transparencias basadas por: • IAN SOMMERVILLE, Ingeniería de Software, Séptima edición
  • 23. Networking académico: Correo electrónico: rguaman@unl.edu.ec Twitter: @rene5254 SlideShare: https://es.slideshare.net/rene5254 23 Gracias