Enviar búsqueda
Cargar
Aoo05
•
Descargar como PPT, PDF
•
0 recomendaciones
•
495 vistas
Johannita Banxiita
Seguir
Datos y análisis
Vista de diapositivas
Denunciar
Compartir
Vista de diapositivas
Denunciar
Compartir
1 de 85
Descargar ahora
Recomendados
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Sergio Sanchez
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso Reales
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso Reales
Sergio Sanchez
Unidad 9 Patrones De DiseñO
Unidad 9 Patrones De DiseñO
Sergio Sanchez
Glosario de terminos
Glosario de terminos
Jose Risso
Diseño orientado a objeto
Diseño orientado a objeto
Universidad Nororiental Gran Mariscal de Ayacucho
Modelos de dominio
Modelos de dominio
Juan Pablo Bustos Thames
Metodologías Para AnáLisis Y DiseñO Orientado A Objetos
Metodologías Para AnáLisis Y DiseñO Orientado A Objetos
hector_h30
Vistas Arquitectonicas Ingenieria de Software
Vistas Arquitectonicas Ingenieria de Software
Roberth Loaiza
Recomendados
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
Sergio Sanchez
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso Reales
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso Reales
Sergio Sanchez
Unidad 9 Patrones De DiseñO
Unidad 9 Patrones De DiseñO
Sergio Sanchez
Glosario de terminos
Glosario de terminos
Jose Risso
Diseño orientado a objeto
Diseño orientado a objeto
Universidad Nororiental Gran Mariscal de Ayacucho
Modelos de dominio
Modelos de dominio
Juan Pablo Bustos Thames
Metodologías Para AnáLisis Y DiseñO Orientado A Objetos
Metodologías Para AnáLisis Y DiseñO Orientado A Objetos
hector_h30
Vistas Arquitectonicas Ingenieria de Software
Vistas Arquitectonicas Ingenieria de Software
Roberth Loaiza
Poa 01
Poa 01
AmistadLealtad
UML. un analisis comparativo para la diagramación de software
UML. un analisis comparativo para la diagramación de software
Yaskelly Yedra
Vista lógica
Vista lógica
thyago1211
Diseno orientado-a-objetos-con-uml-raul-alarcon-grupo-eidos (1)
Diseno orientado-a-objetos-con-uml-raul-alarcon-grupo-eidos (1)
ricrichardr
Uml
Uml
Mauricio Murillo Benitez, PMP©
2 2 estilos arquitectonicos
2 2 estilos arquitectonicos
landeta_p
05 modelo de diseño
05 modelo de diseño
Omar Beltran Celis Mendoza
Pre analisis
Pre analisis
Rony Dionicio Diaz Montano
Entrega De Cartel, Conceptualizacion
Entrega De Cartel, Conceptualizacion
arraia
Chillidappt
Chillidappt
Ambrosete
casa moriyama ryue nishizawa
casa moriyama ryue nishizawa
ignaciogarciasanz
Arquitectura sanaa-fernando-ocampo-analisis-de-plantas propuestas-de-investig...
Arquitectura sanaa-fernando-ocampo-analisis-de-plantas propuestas-de-investig...
Oscar Ignacio
Analisis objetos 10°3
Analisis objetos 10°3
dayana 1D
Lamina Analisis y Concepto
Lamina Analisis y Concepto
Edu Andalón
Elementos Arquitectónicos
Elementos Arquitectónicos
Christianovl
Elementos Y Conceptos ArquitectóNicos Ivonneramoslezama
Elementos Y Conceptos ArquitectóNicos Ivonneramoslezama
guest0f102a7
Morfologia del diseño
Morfologia del diseño
hismenaglz
CONCEPTOS ARQUITECTONICOS
CONCEPTOS ARQUITECTONICOS
Arnr Peña Mogollon
Morfologia I
Morfologia I
Angelica
Elementos formales del diseño
Elementos formales del diseño
Caty Arambula
Conceptualizacion de arquitectura
Conceptualizacion de arquitectura
Luis Robles
Analisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A Objetos
yoiner santiago
Más contenido relacionado
La actualidad más candente
Poa 01
Poa 01
AmistadLealtad
UML. un analisis comparativo para la diagramación de software
UML. un analisis comparativo para la diagramación de software
Yaskelly Yedra
Vista lógica
Vista lógica
thyago1211
Diseno orientado-a-objetos-con-uml-raul-alarcon-grupo-eidos (1)
Diseno orientado-a-objetos-con-uml-raul-alarcon-grupo-eidos (1)
ricrichardr
Uml
Uml
Mauricio Murillo Benitez, PMP©
2 2 estilos arquitectonicos
2 2 estilos arquitectonicos
landeta_p
05 modelo de diseño
05 modelo de diseño
Omar Beltran Celis Mendoza
La actualidad más candente
(7)
Poa 01
Poa 01
UML. un analisis comparativo para la diagramación de software
UML. un analisis comparativo para la diagramación de software
Vista lógica
Vista lógica
Diseno orientado-a-objetos-con-uml-raul-alarcon-grupo-eidos (1)
Diseno orientado-a-objetos-con-uml-raul-alarcon-grupo-eidos (1)
Uml
Uml
2 2 estilos arquitectonicos
2 2 estilos arquitectonicos
05 modelo de diseño
05 modelo de diseño
Destacado
Pre analisis
Pre analisis
Rony Dionicio Diaz Montano
Entrega De Cartel, Conceptualizacion
Entrega De Cartel, Conceptualizacion
arraia
Chillidappt
Chillidappt
Ambrosete
casa moriyama ryue nishizawa
casa moriyama ryue nishizawa
ignaciogarciasanz
Arquitectura sanaa-fernando-ocampo-analisis-de-plantas propuestas-de-investig...
Arquitectura sanaa-fernando-ocampo-analisis-de-plantas propuestas-de-investig...
Oscar Ignacio
Analisis objetos 10°3
Analisis objetos 10°3
dayana 1D
Lamina Analisis y Concepto
Lamina Analisis y Concepto
Edu Andalón
Elementos Arquitectónicos
Elementos Arquitectónicos
Christianovl
Elementos Y Conceptos ArquitectóNicos Ivonneramoslezama
Elementos Y Conceptos ArquitectóNicos Ivonneramoslezama
guest0f102a7
Morfologia del diseño
Morfologia del diseño
hismenaglz
CONCEPTOS ARQUITECTONICOS
CONCEPTOS ARQUITECTONICOS
Arnr Peña Mogollon
Morfologia I
Morfologia I
Angelica
Elementos formales del diseño
Elementos formales del diseño
Caty Arambula
Conceptualizacion de arquitectura
Conceptualizacion de arquitectura
Luis Robles
Analisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A Objetos
yoiner santiago
Conceptos Básicos Arquitectura
Conceptos Básicos Arquitectura
Jose Adalberto Cardona Ortiz
Desarrollo del concepto arquitectónico
Desarrollo del concepto arquitectónico
Omar Sabillon
6.‐ AnáLisis Conceptual
6.‐ AnáLisis Conceptual
arraia
Elementos Que Configuran Las Formas Bidimensionales
Elementos Que Configuran Las Formas Bidimensionales
Marisa Fuster Ribera
Destacado
(19)
Pre analisis
Pre analisis
Entrega De Cartel, Conceptualizacion
Entrega De Cartel, Conceptualizacion
Chillidappt
Chillidappt
casa moriyama ryue nishizawa
casa moriyama ryue nishizawa
Arquitectura sanaa-fernando-ocampo-analisis-de-plantas propuestas-de-investig...
Arquitectura sanaa-fernando-ocampo-analisis-de-plantas propuestas-de-investig...
Analisis objetos 10°3
Analisis objetos 10°3
Lamina Analisis y Concepto
Lamina Analisis y Concepto
Elementos Arquitectónicos
Elementos Arquitectónicos
Elementos Y Conceptos ArquitectóNicos Ivonneramoslezama
Elementos Y Conceptos ArquitectóNicos Ivonneramoslezama
Morfologia del diseño
Morfologia del diseño
CONCEPTOS ARQUITECTONICOS
CONCEPTOS ARQUITECTONICOS
Morfologia I
Morfologia I
Elementos formales del diseño
Elementos formales del diseño
Conceptualizacion de arquitectura
Conceptualizacion de arquitectura
Analisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A Objetos
Conceptos Básicos Arquitectura
Conceptos Básicos Arquitectura
Desarrollo del concepto arquitectónico
Desarrollo del concepto arquitectónico
6.‐ AnáLisis Conceptual
6.‐ AnáLisis Conceptual
Elementos Que Configuran Las Formas Bidimensionales
Elementos Que Configuran Las Formas Bidimensionales
Similar a Aoo05
Slideshare #01
Slideshare #01
wcontra31
Modelos de dominio
Modelos de dominio
Juan Pablo Bustos Thames
DiseñO De Sitemas
DiseñO De Sitemas
lincoln25
Modelo4 1
Modelo4 1
bmarquez543
Modelo4 1
Modelo4 1
bmarquez543
Aplicacion RUP Y UML
Aplicacion RUP Y UML
Esraelita
Desarrollo de aplicaciones con rup y uml
Desarrollo de aplicaciones con rup y uml
Iestp Instituto Superior
Guia_Lab_UML-General_UTP.pdf
Guia_Lab_UML-General_UTP.pdf
LuisFelipeUNI
Introduccion a UML
Introduccion a UML
Juan Antonio
Curso
Curso
narcisa.pacheco
Ingenieria de software
Ingenieria de software
Belen Gonzalez
Unidad 2.1 DiseñO De Sistemas
Unidad 2.1 DiseñO De Sistemas
Sergio Sanchez
Ingenieria de software i
Ingenieria de software i
Trabajos Grupal Ing de Software
Is.exp.329466
Is.exp.329466
Universidad Autonoma de Baja California
Exposicion
Exposicion
MaricelaAguiar
Exposicion
Exposicion
patriciaverdezoto
Metodología orientada a objetos (omt). rumbaugh
Metodología orientada a objetos (omt). rumbaugh
Wilfredy Inciarte
Análisis y diseño orientado a objetos
Análisis y diseño orientado a objetos
Christian Leon
6.modelado de los requerimientos escenarios y clases
6.modelado de los requerimientos escenarios y clases
Ramiro Estigarribia Canese
Software engineeringparte2 (1)
Software engineeringparte2 (1)
Maria Loreto Solorza Acuña
Similar a Aoo05
(20)
Slideshare #01
Slideshare #01
Modelos de dominio
Modelos de dominio
DiseñO De Sitemas
DiseñO De Sitemas
Modelo4 1
Modelo4 1
Modelo4 1
Modelo4 1
Aplicacion RUP Y UML
Aplicacion RUP Y UML
Desarrollo de aplicaciones con rup y uml
Desarrollo de aplicaciones con rup y uml
Guia_Lab_UML-General_UTP.pdf
Guia_Lab_UML-General_UTP.pdf
Introduccion a UML
Introduccion a UML
Curso
Curso
Ingenieria de software
Ingenieria de software
Unidad 2.1 DiseñO De Sistemas
Unidad 2.1 DiseñO De Sistemas
Ingenieria de software i
Ingenieria de software i
Is.exp.329466
Is.exp.329466
Exposicion
Exposicion
Exposicion
Exposicion
Metodología orientada a objetos (omt). rumbaugh
Metodología orientada a objetos (omt). rumbaugh
Análisis y diseño orientado a objetos
Análisis y diseño orientado a objetos
6.modelado de los requerimientos escenarios y clases
6.modelado de los requerimientos escenarios y clases
Software engineeringparte2 (1)
Software engineeringparte2 (1)
Último
Los más ricos administradores de fondo de cobertura (1968-2024).pdf
Los más ricos administradores de fondo de cobertura (1968-2024).pdf
JC Díaz Herrera
Análisis del Modo y Efecto de Fallas AMEF.ppt
Análisis del Modo y Efecto de Fallas AMEF.ppt
ProduvisaCursos
Panorama Sociodemográfico de México 2020: GUANAJUATO
Panorama Sociodemográfico de México 2020: GUANAJUATO
Juan Carlos Fonseca Mata
Presentacion-Prevencion-Incendios-Forestales.pdf
Presentacion-Prevencion-Incendios-Forestales.pdf
DodiAcuaArstica
EPIDEMIO CANCER PULMON resumen nnn.pptx
EPIDEMIO CANCER PULMON resumen nnn.pptx
JEFFERSONMEDRANOCHAV
Novelas Turcas vs Series de EUA en audiencia (2024).pdf
Novelas Turcas vs Series de EUA en audiencia (2024).pdf
JC Díaz Herrera
ETICA EN LA CADENAS la cadena de suministro
ETICA EN LA CADENAS la cadena de suministro
IrisMoreno27
llllllllllllllllllllllllllllllllllllllllllllllllllllllllll
llllllllllllllllllllllllllllllllllllllllllllllllllllllllll
JulietaCarbajalOsis
procedimiento paran la planificación en los centros educativos tipo v(multig...
procedimiento paran la planificación en los centros educativos tipo v(multig...
claudioluna1121
La Guerra Biologica - Emiliano Paico Vilchez.pdf
La Guerra Biologica - Emiliano Paico Vilchez.pdf
josellaqtas
PIB PERÚ datos y análisis de los últimos años
PIB PERÚ datos y análisis de los últimos años
EstefaniaRojas54
Las familias más ricas del sionismo en el siglo XXI.pdf
Las familias más ricas del sionismo en el siglo XXI.pdf
JC Díaz Herrera
Las marcas automotrices con más ventas de vehículos (2024).pdf
Las marcas automotrices con más ventas de vehículos (2024).pdf
JC Díaz Herrera
Tipos de Educacion en diferentes partes del mundo.pptx
Tipos de Educacion en diferentes partes del mundo.pptx
MiguelPerz4
Metodos de esterilizacion _20240418_181249_0000.pdf
Metodos de esterilizacion _20240418_181249_0000.pdf
arteagaara
El Manierismo. El Manierismo
El Manierismo. El Manierismo
fariannys5
decreto 2090 de 2003.pdf actividades de alto riesgo en Colombia
decreto 2090 de 2003.pdf actividades de alto riesgo en Colombia
veronicayarpaz
Posiciones en el IDH global de EUA (1950-2024).pdf
Posiciones en el IDH global de EUA (1950-2024).pdf
JC Díaz Herrera
Evolución de la fortuna de la familia Slim (1994-2024).pdf
Evolución de la fortuna de la familia Slim (1994-2024).pdf
JC Díaz Herrera
Letra de cambio definición y características.ppt
Letra de cambio definición y características.ppt
ssuserbdc329
Último
(20)
Los más ricos administradores de fondo de cobertura (1968-2024).pdf
Los más ricos administradores de fondo de cobertura (1968-2024).pdf
Análisis del Modo y Efecto de Fallas AMEF.ppt
Análisis del Modo y Efecto de Fallas AMEF.ppt
Panorama Sociodemográfico de México 2020: GUANAJUATO
Panorama Sociodemográfico de México 2020: GUANAJUATO
Presentacion-Prevencion-Incendios-Forestales.pdf
Presentacion-Prevencion-Incendios-Forestales.pdf
EPIDEMIO CANCER PULMON resumen nnn.pptx
EPIDEMIO CANCER PULMON resumen nnn.pptx
Novelas Turcas vs Series de EUA en audiencia (2024).pdf
Novelas Turcas vs Series de EUA en audiencia (2024).pdf
ETICA EN LA CADENAS la cadena de suministro
ETICA EN LA CADENAS la cadena de suministro
llllllllllllllllllllllllllllllllllllllllllllllllllllllllll
llllllllllllllllllllllllllllllllllllllllllllllllllllllllll
procedimiento paran la planificación en los centros educativos tipo v(multig...
procedimiento paran la planificación en los centros educativos tipo v(multig...
La Guerra Biologica - Emiliano Paico Vilchez.pdf
La Guerra Biologica - Emiliano Paico Vilchez.pdf
PIB PERÚ datos y análisis de los últimos años
PIB PERÚ datos y análisis de los últimos años
Las familias más ricas del sionismo en el siglo XXI.pdf
Las familias más ricas del sionismo en el siglo XXI.pdf
Las marcas automotrices con más ventas de vehículos (2024).pdf
Las marcas automotrices con más ventas de vehículos (2024).pdf
Tipos de Educacion en diferentes partes del mundo.pptx
Tipos de Educacion en diferentes partes del mundo.pptx
Metodos de esterilizacion _20240418_181249_0000.pdf
Metodos de esterilizacion _20240418_181249_0000.pdf
El Manierismo. El Manierismo
El Manierismo. El Manierismo
decreto 2090 de 2003.pdf actividades de alto riesgo en Colombia
decreto 2090 de 2003.pdf actividades de alto riesgo en Colombia
Posiciones en el IDH global de EUA (1950-2024).pdf
Posiciones en el IDH global de EUA (1950-2024).pdf
Evolución de la fortuna de la familia Slim (1994-2024).pdf
Evolución de la fortuna de la familia Slim (1994-2024).pdf
Letra de cambio definición y características.ppt
Letra de cambio definición y características.ppt
Aoo05
1.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 1 Análisis y Diseño
2.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 2 El análisis se centra en la investigación del problema, no en la manera de definir la solución. Ej. Si se necesita un sistema de biblioteca Cuales son los procesos de la organización que se relacionan con su uso? Qué es análisis?
3.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 3 El diseño pone en relieve una solución lógica: como el sistema cumple con los requerimientos. Ej. De qué manera el sistema capturará y registrará los préstamos de libros? La esencia de estas actividades consiste en situar el dominio del problema y la solución lógica dentro de la perspectiva de los objetos. Qué es diseño?
4.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 4 Durante el análisis se procura identificar y describir objetos – o conceptos – dentro del dominio del problema. Durante el diseño se procura definir objetos lógicos del software Análisis y diseño
5.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 5 Análisis y diseño
6.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 6 Análisis y diseño Para entender los requerimientos se necesita conocer los procesos de dominio y el ambiente externo , o sea los factores externos que participan en el proceso. Dichos procesos se pueden expresar en forma de casos de uso, los cuales son una descripción narrativa del proceso de dominio en un formato estructurado de prosa,
7.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 7 Análisis y diseño; Ejemplo El juego de dados: Caso de uso: juega un juego Participantes: jugador Descripción: Este caso de uso comienza cuando el jugador recoge y hace rodar los dados. Si los puntos suman 7 gana y si suman cualquier otro número, pierde.
8.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 8 Análisis y diseño El modelo conceptual o modelo de análisis es una representación de conceptos u objetos en el dominio del problema, como libro, biblioteca. Debe limitarse el esfuerzo aplicado a la creación de un modelo conceptual preliminar en la fase de planificación y elaboración, por la complejidad que pueden tener. Puede ser elaborado una vez definidos los requerimientos o antes de los ciclos de desarrollo.
9.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 9 Análisis y diseño; Ejemplo
10.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 10 Análisis y diseño; Ejemplo El modelo conceptual muestra los conceptos jugador, dados, juego de dados, sus asociaciones atributos.
11.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 11 Análisis y diseño; Ejemplo El modelo conceptual muestra los conceptos jugador, dados, juego de dados, sus asociaciones atributos.
12.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 12 Análisis y diseño; Ejemplo El Diagrama de colaboración presenta el flujo de mensajes entre instancias y la invocación a los métodos.
13.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 13 Análisis y diseño; Ejemplo Para definir una clase en preciso contestar varias preguntas: Cómo se conectan unos objetos con otros? Cuales son los métodos de una clase? El jugador requiere de un método jugar y el dado requiere de un método lanzar.
14.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 14 Análisis y diseño; Ejemplo El modelo de diseño o diagrama de diseño de clases describe componentes de software.
15.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 15 Análisis y diseño; Ejemplo El modelo de diseño o diagrama de diseño de clases describe componentes de software.
16.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 16 Comparación AD OO y estructurado
17.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 17 Construcción de un modelo conceptual El modelo conceptual explica los conceptos significativos en el dominio del problema, es el artefacto más importante a crear durante el análisis orientado a objetos. (Los casos de uso son importantes pero no son realmente orientados a objetos) La cualidad esencial que debe ofrecer un modelo conceptual es que representa cosas del mundo real, no componentes del software.
18.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 18 Construcción de un modelo conceptual El modelo conceptual es un diagrama de estructura estática, es decir, no define ninguna operación. ELEMENTOS: 1. Conceptos 2. Asociaciones 3. Atributos de los conceptos
19.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 19 Construcción de un modelo conceptual 1. Conceptos Un concepto es una idea, evento u objeto. Formalmente se lo define a partir de: Símbolo: palabras o imágenes que representan un concepto. Intensión: la definición de un concepto Extensión: el conjunto de ejemplos a que se aplica el concepto.
20.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 20 Construcción de un modelo conceptual Ejemplo: Transacción venta. Símbolo: Lo denominamos VENTA Intensión: Representa la transacción de venta, tienen hora y fecha Extensión: conjunto de todas las ventas
21.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 21 Construcción de un modelo conceptual Identificación de conceptos 1. Lista des categorías comunes Objetos físicos o tangibles Especificaciones de diseño o descripciones de cosas Lugares Transacciones Línea de transacciones Papel(rol-cargo) de personas Contenedores de otras cosas Etc, etc, etc
22.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 22 Construcción de un modelo conceptual Identificación de conceptos 2. Identificación de frases nominales Consiste en identificar las frases nominales (sustantivos) en las descripciones textuales del dominio del problema y considerarlas conceptos o atributos. Esta técnica es muy útil cuando se empieza a entender el enfoque de orientación a objetos
23.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 23 Construcción de un modelo conceptual Se recomienda combinar esta técnica con la lista de categorías
24.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 24 Construcción de un modelo conceptual Ejemplo: punto de venta Conceptos: • TPDV, producto, tienda, venta, pago • Catalogo de productos , especificación del producto • Venta línea de productos • Cajero, cliente, gerente
25.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 25 Construcción de un modelo conceptual Asociaciones Es una relación entre dos conceptos que indica alguna conexión significativa entre ellos En lenguaje UML se denominan relaciones estructurales entre objetos de diversos tipos.
26.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 26 Construcción de un modelo conceptual Asociaciones Comience por agregar las asociaciones utilizando la lista de asociaciones comunes:
27.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 27 Construcción de un modelo conceptual Asociaciones - Multiplicidad La multiplicidad define cuantas instancias de tipo A pueden asociarse a una instancia del tipo B en determinado momento.
28.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 28 Construcción de un modelo conceptual Asociaciones – Múltiples entre conceptos Dos conceptos pueden tener varias asociaciones entre ellos.
29.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 29 Construcción de un modelo conceptual Asociaciones – ejemplo
30.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 30 Construcción de un modelo conceptual Modelo conceptual – punto de venta
31.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 31 Construcción de un modelo conceptual Modelo conceptual – atributos Un atributo es un valor lógico de un dato u objeto Pertenece a un concepto Tiene un tipo que define los posibles valores
32.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 32 Construcción de un modelo conceptual Modelo conceptual – atributos – tipos Tipos más comunes (valores puros de datos) Los atributos deberían ser simples o valores puros de datos Si es un valor complejo es mejor expresarlo como asociación.
33.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 33 Construcción de un modelo conceptual Ejemplo Modelo conceptual – atributos
34.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 34 Descripción del comportamiento Durante el análisis, se incluye modelos orientados a describir el comportamiento del sistema. Uno de ellos es el diagrama de secuencia del sistema. Antes de iniciar el diseño lógico de cómo funcionará la aplicación de SW es necesario investigar y definir el comportamiento del sistema como una “caja negra” EL comportamiento del sistema es una descripción de que es lo que hace, sin explicar como lo hace.
35.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 35 Descripción del comportamiento El diagrama de secuencia del sistema muestra en un escenario, los eventos generados por eventos externos, su orden y los eventos externos del sistema Ej. Caso comprar productos
36.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 36 Descripción del comportamiento EVENTOS Y OPERACIONES Evento de un sistema es un hecho externo de entrada que un actor produce en un sistema. Una operación de un sistema es una acción que este ejecuta en respuesta a un evento del sistema Ej, un cajero genera un evento “introducir producto”, causa la ejecución de la operación “introducir producto” Los nombres del evento y la operación generalmente son iguales, La diferencia es que el evento es el estímulo y la operación es la respuesta. (igual que los mensajes y los métodos en las clases y objetos)
37.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 37 Descripción del comportamiento OPERACIONES Para determinar las operaciones del sistema se identifican los eventos. Ej, EfectuarPago(CUP, Cantidad) TerminarVenta() EfectuarPago(monto)
38.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 38 Descripción del comportamiento Diagramas de secuencia del sistema. 1.- determinar actores 2.- Los eventos (y sus operaciones asociadas) deben expresarse en el nivel de propósito. El nombre comúnmente empieza con un verbo (agregar, introducir, terminar, efectuar) ya que recalca que los eventos están orientados a comandos. Seleccionar el nivel mas alto u objetivo para dar el nombre a operaciones: ej: respecto a la operación que captura el pago: IntroducirImporteOfrecido(Monto) deficiente IntroducirPago(monto) mejor EfectuarPago() mejor aún
39.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 39 Modelo de análisis El modelo de análisis está compuesto de: Modelo de casos de uso de análisis (dinámico) Casos de uso de alto nivel o esenciales Diagramas de casos de uso Modelo conceptual (estático) Modelo de comportamiento (dinámico) Diagramas de secuencia del sistema Contratos para las operaciones del sistema Modelo de estado del análisis (dinámico) Diagramas de estado para conceptos y casos de uso
40.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 40 Modelo de análisis El modelo de análisis está compuesto de:
41.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 41 Modelo de análisis Contratos Los contratos contribuyen a definir el comportamiento del sistema El contrato es un documento que describe lo que una operación se propone lograr Se redacta en estilo declarativo, enfatizando lo que se conseguirá y no como se conseguirá Suelen expresarse a partir de los cambios de las precondiciones y post-condiciones. EL contrato de operación del sistema describe cambios de estado del sistema total cuando se llama una de sus operaciones.
42.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 42 Modelo de análisis Elementos de un contrato
43.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 43 Modelo de análisis Ejemplo Contratos de la operación “IntroducirProducto”
44.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 44 Modelo de análisis Ejemplo Contratos de la operación “IntroducirProducto”
45.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 45 Modelo de análisis Diagramas de estado Muestran como los objetos cambian de estado en respuesta a los eventos. Los diagramas de secuencia se utilizan para modelar el comportamiento combinado de un grupo de objetos, pero también son útiles para resumir el comportamiento de un solo objeto como respuesta a los diversos mensajes que puede procesar. Para esto se utiliza un diagrama de estado.
46.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 46 Modelo de análisis Ejemplo Diagramas de estado transmission done calibrate () test ()star tup () shutdown () calibration OK test complete weather summary complete clock collection done Operation repor tWeather () Shutdown Waiting Testing Transmitting Collecting Summarising Calibrating
47.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 47 Diseño Orientado a Objetos DOO comprende el desarrollo de un modelo orientado a objetos de un sistema SW para implementar los requerimientos identificados. Los objetos en un DOO están relacionados con la solución del problema a resolver.
48.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 48 Actividades del proceso DOO Las actividades principales en el proceso de DOO incluyen: Contexto: Define el contexto y modos de uso del sistema; Arquitectura: Diseña la arquitectura del sistema; Objetos: Identifica los objetos principales del sistema; Modelos: Desarrolla los modelos de diseño; Interfaces: Especifique interfaces del objeto.
49.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 49 Modelo de diseño Resumen del diseño
50.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 50 Architecture Una vez que las interacciones entre el sistema y su ambiente se han entendido, se usa esta información por diseñar la arquitectura del sistema. Debe haber normalmente no más de 7 entidades en un modelo arquitectónico.
51.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 51 Weather station architecture Weather station Manages all external communications Collects and summarises weather data Package of instruments for raw data collections « subsystem» Data collection « subsystem» Instruments « subsystem» Interface Una arquitectura por capas es apropiado para la estación de tiempo Capa de la interface por manejar comunicaciones; Capa de colección de datos para los instrumentos gerente; Capa de los instrumentos para los datos colectivos.
52.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 52 Diseño de la Arquitectura Una etapa inicial del proceso de diseño del sistema. Representa el vínculo entre el pliego de condiciones y procesos de diseño. A menudo llevan a cabo paralelamente con algunas actividades de especificación de requerimientos Comprende la identificación de los principales componentes del sistema y sus comunicaciones.
53.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 53 Ventajas de una arquitectura explícita Aporta en: Comunicación con stakeholders La arquitectura puede ser utilizado como un centro de la discusión por las partes interesadas del sistema. Análisis del sistema Significa que el análisis de si el sistema puede cumplir con sus requisitos no funcionales es posible. Reutilización a gran escala La arquitectura puede ser reutilizable en una serie de sistemas.
54.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 54 Architecture and system characteristics La arquitectura del sistema afecta al rendimiento, solidez, grado de distribución y mantenibilidad de un sistema. Rendimiento Identificar las operaciones críticas y minimizar las comunicaciones. Utiliza grandes componentes. Protección Usar una arquitectura en capas, con los elementos críticos en las capas internas para protegerlos. Seguridad Localizar Operaciones críticas para la seguridad en un pequeño número de sub-sistemas o en un subsistema único. Disponibilidad Incluir componentes redundantes y mecanismos de tolerancia a fallos. Mantenibilidad Usar componentes reemplazables.
55.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 55 Estructura del sistema Descomposición del sistema en subsistemas que interactúan. El diseño arquitectónico se expresa en un diagrama de bloques de presentar una visión general de la estructura del sistema. Los modelos más específicos muestran la como los sub-sistemas comparten datos, se distribuyen e interacción con los demás y también pueden ser desarrollados.
56.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 56 Sistema robótico de control de empaquetado Vision system Object identifica tion system Arm contr oller Gripper contr oller Packaging selection system Packing system Conveyor contr oller
57.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 57 Architectural design decisions 1. ¿Hay una arquitectura de la aplicación genérica que puede usarse? 2. ¿Cómo se distribuirá el sistema entre varios procesadores? 3. ¿Qué estilos arquitectónicos son apropiados para el sistema? 4. ¿Qué aproximación se usará para estructurar el sistema? 5. ¿Cómo se descompondrá en los módulos las unidades estructurales del sistema? 6. ¿Qué estrategia debe usarse para controlar el funcionamiento de las unidades del sistema? 7. ¿Cómo se evaluará el diseño arquitectónico? 8. Cómo debería documentarse la arquitectura del sistema?
58.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 58 Estilos de arquitectura El modelo arquitectónico de un sistema puede conformar a modelo arquitectónico genérico o estilo. Un conocimiento de estos estilos puede simplificar el problema de definir arquitecturas del sistema. Sin embargo, mayoría de los sistemas grandes es heterogéneo y no sigue un solo estilo arquitectónico.
59.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 59 Modelo de Arquitectura Documenta un diseño arquitectónico y pueden tener las siguientes perspectivas: 1. Como un Modelo estructural estático que muestra los principales componentes del sistema. 2. Como Modelo del procesos dinámicos que muestra la estructura de los procesos del sistema. 3. Como Modelo de interfaz que define interfaces de los sub-sistema. 4. Las relaciones diseñan como un modelo de flujo de datos entre subsistemas. 5. Modelo de la distribución que muestra cómo los sub-sistemas son distribuídos entre las computadoras.
60.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 60 Diseño de subsistemas En el diseño de Sistemas OO se particiona el modelo de análisis, para definir colecciones congruentes de clases, relaciones y comportamiento. Estos elementos de diseño se definen como subsistema. En general todos los elementos de un subsistema comparten alguna propiedad en común. Y se integran para completar la misma función. Los subsistemas se identifican por los servicios que proveen.
61.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 61 Criterios de Diseño de subsistemas Interfaz definida y reducida con el resto del sistema. Las clases dentro del subsistema deben colaborar solo con otras clases dentro del subsistema (a excepción de las clases de comm) El número debe ser bajo Un subsistema puede ser particionado para reducir complejidad.
62.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 62 Estratificación por capas Cada capa contiene uno o más subsistemas. Cada capa representa un nivel de abtracción diferente para completar la función del sistema El enlace puede ser cliente-servidor o peer- to-peer
63.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 63 Arquitectura de 3 capas Capa de presentación.- interfaz de usuario, ventanas, reportes, etc. Capa de aplicación.- tareas y reglas que rigen el proceso. Capa de base de datos.- mecanismo de almacenamiento.
64.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 64 Arquitectura de 3 capas
65.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 65 Arquitectura Multicapas La capa de aplicaciones se divide: objetos de dominio y servicios. Capa de presentación.- interfaz de usuario Capa de dominio.- servicios de alto nivel (pago, venta) Capa de Servicios.- incluye servicios de bajo nivel. Interfaz de la DB, Generador de reportes, comunicaciones. Capa de base de datos.- procesamiento de datos.
66.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 66 Arquitectura Multicapas
67.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 67 Paquetes UML Un paquete es un conjunto de cualquier tipo de elemento de un modelo: clases, casos de uso, diagramas de colaboración u otros paquetes. El paquete de más alto nivel es el sistema.
68.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 68 Paquetes UML Las capas conforman los paquetes UML de menor nivel. Conformando un diagrama de paquetes de la arquitectura,
69.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 69 Ejemplo arquitectura
70.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 70 Ejemplo arquitectura
71.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 71 Ejemplo arquitectura
72.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 72 Modelo de diseño Continuación del diseño
73.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 73 Modelo de diseño El modelo de diseño muestra los objetos y clases de objetos y las relaciones entre estas entidades. Para esto se incluyen dos tipos de diagramas: estáticos y dinámicos Los modelos estáticos describen la estructura estática del sistema en términos de clases del objeto y relaciones: modelo de arquitectura, modelo de clases, esquema de bases de datos. Los modelos dinámicos describen las interacciones dinámicas entre los objetos: casos de uso reales, contratos, diagramas de interacción y colaboración, diagramas de estado.
74.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 74 Diagramas de interacción y contratos para métodos y operaciones En la práctica, los diseñadores se percatan de que la preparación de los diagramas de interacción es uno de los pasos más lentos. La asignación de responsabilidades y la elaboración de los diagramas de interacción representan uno de los pasos más importantes en la fase de diseño.
75.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 75 Diagramas de interacción y contratos para métodos y operaciones Los diagramas de interacción describen gráficamente la solución –a partir de los objetos en interacción- que satisfacen estas responsabilidades y poscondiciones. En los contratos se incluye una conjetura inicial sobre las responsabilidades y las poscondiciones de las operaciones inicio, introducirProducto, terminarVenta y efectuarPago.
76.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 76 Diagramas de interacción y contratos para métodos y operaciones La calidad de diseño de la interacción de los objetos y la asignación de responsabilidades presentan gran variación. • Las decisiones poco acertadas dan origen a sistemas y componentes frágiles y difíciles de mantener, entender, reutilizar o extender. • Una implementación hábil se funda en los principios cardinales que rigen un buen diseño orientado a objetos.
77.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 77 Diagramas de interacción y contratos para métodos y operaciones • Los diagramas de interacción son algunos de los artefactos más importantes que se preparan en el análisis y diseño orientados a objetos. • Es muy importante asignar acertadamente las responsabilidades al momento de elaborar los diagramas de interacción. • El tiempo y el esfuerzo que se dedican a su elaboración, así como un examen riguroso de la asignación de responsabilidades, deberían absorber parte considerable de la fase de diseño de un proyecto. • UML define algunos patrones, principios y expresiones especializadas codificados que sirven para mejorar la calidad del diseño, llamados PATRONES GRASP
78.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 78 Diagramas de interacción y contratos para métodos y operaciones Los patrones GRASP son parejas de problema solución con un nombre, que codifican buenos principios y sugerencias relacionados frecuentemente con la asignación de responsabilidades. Pregunta: ¿Qué son los patrones GRASP? Respuesta: Los patrones GRASP describen los principios fundamentales de la asignación de responsabilidades a objetos, expresados en forma de patrones. GRASP es un acrónimo que significa General Responsibility Asignment Software Patterns (patrones generales de software para asignar responsabilidades).
79.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 79 Diagramas de interacción y contratos para métodos y operaciones Patrones GRASP • Experto • Creador • Bajo Acoplamiento • Alta Cohesión • Controlador.
80.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 80 Diagramas de interacción y contratos para métodos y operaciones
81.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 81 Diagramas de interacción y contratos para métodos y operaciones
82.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 82 Diagramas de clases Una vez terminados los diagramas de interacción podemos identificar la especificación de las clases de software (y las interfaces) que participan en la solución de software y complementarlas con detalles de diseño, por ejemplo los métodos. Su preparación exige crear antes: • Modelo conceptual: a partir de éste el diseñador agrega detalles a la definición de las clases. • Diagramas de interacción: a partir de ellos el diseñador identifica las clases de software que intervienen en la solución, así como los métodos de las clases.
83.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 83 Diagramas de clases El diagrama de clases de diseño describe gráficamente las especificaciones de las clases de software y de las interfaces en una aplicación. Normalmente contiene la siguiente información: • clases, asociaciones y atributos • interfaces, con sus operaciones y constantes • Métodos • información sobre los tipos de los atributos • Navegabilidad (visibilidad de los atributos) • dependencias.
84.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 84 Diagramas de clases 1. Identifique todas las clases que participan en la solución del software. Para ello analice los diagramas de interacción. 2. Dibújelas en un diagrama de clases. 3. Duplique los atributos provenientes de los conceptos asociados del modelo conceptual. 4. Agregue los nombres de los métodos analizando los diagramas de interacción. 5. Incorpore la información sobre los tipos a los atributos y a los métodos. 6. Agregue las asociaciones necesarias para dar soporte a la visibilidad requerida de los atributos. 7. Agregue flechas de navegabilidad a las asociaciones para indicar la dirección de la visibilidad de los atributos. 8. Agregue las líneas de relaciones de dependencia para indicar la visibilidad no relacionada con los atributos.
85.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 11 Slide 85 Diagramas de clases
Descargar ahora