Anlisis y Diseo de Sistemas Informticos III

Sesiones 1 y 2

AyDSI3

Agenda del da
Objetivos/Informaciones de la materia El Paradigma OO Desarrollo Iterativo y el Proceso Unificado

AyDSI3

Objetivo de la Materia
Profundizar la utilizacin de herramientas, procedimientos y mtodos formales de especificacin de sistemas informticos, mediante el desarrollo terico-prctico de una nueva metodologa para las actividades de anlisis y diseo de sistemas de informacin del ciclo de vida del software.

AyDSI3

Metodologa
Se propone una metodologa participativa en la que el Instructor acta como facilitador para dirigir el desarrollo de las clases, en las cuales se otorgar un alto valor a la participacin activa de los alumnos

AyDSI3

Evaluacin
3 Exmenes Parciales y un examen final
1er. Parcial
Trabajo Prctico Principal (10%) Examen (90%)

2do. Parcial
Trabajo Prctico Principal (20%) Examen (80%)

3er. Parcial
Trabajo Prctico Principal (30%) Examen (70%)

Examen Final
Trabajo Prctico Principal (40%) Examen (60%)

Calificacin Final = suma del 50% del promedio de los tres exmenes parciales ms el 50% de la calificacin del Examen Final

AyDSI3

Trabajo Prctico Principal

SI Tuvieron Tcnicas de Relevamiento o AyDSI2
Pueden usar el mismo trabajo prctico

SINO
Presentan propuesta de trabajo a realizar sujeto a aprobacin del profesor (incluyendo Desc. de Alcance)

FINSI

El enunciado del trabajo lo encontrarn en el ecampus. Presentacin impresa acumulativa, por computadora, de manera pulcra usando CASE especificado.
6

AyDSI3

Bibliografa Bsica
LARMAN, Craig;
UML y Patrones. Una introduccin al anlisis y diseo orientado a objetos y al proceso unificado (2da edicin); PRENTICE HALL, 2003. Costo en Librera UAA No tienen Costo en ETP Gs. 272.000.(Tel. 496-778, Dir.: Blas Garay 106 esq. Ind. Nacional)

AyDSI3 El paradigma 00 Orientacin a objetos

OO no es una estrategia de diseo. El paradigma de orientacin a objetos es ms amplio y abarca un enfoque general para conceptualizar, disear y programar los sistemas de software.

Estrategias Estrategias
Las estrategias OO cubren tanto los requisitos como el anlisis, diseo y programacin. Anlisis Orientado a Objetos (OOA) Diseo Orientado a Objetos (OOD) Programacin Orientada a Objetos (OOP)

Mtodos Mtodos
Las metodologas ms importantes de anlisis y diseo de sistemas, orientado a objetos, han terminado confluyendo en lo que es el UML (www.uml.org), bajo el respaldo del Object Management Group (www.omg.org). Algunas de las principales metodologas, pioneras que han terminado confluyendo en el UML son: Object-Oriented Design (OOD), Booch. Object Modeling Technique (OMT), Rumbaugh. Object Oriented Analysis (OOA), Coad/Yourdon. Hierarchical Object Oriented Design (HOOD), ESA. Object Oriented Structured Design (OOSD), Wasserman. Object Oriented Systems Analysis (OOSA), Shaler y Mellor. Responsibility Driven Design (RDD), Wirfs-Brock, entre otros.

AyDSI3 El paradigma 00 Orientacin a objetos

Enfoque OO Enfoque OO
Este paradigma centra su foco en el concepto Objeto. Objeto es aquello que tiene estado (propiedades ms valores), comportamiento (acciones y reacciones a mensajes) e identidad (propiedad que lo distingue de los dems objetos). La estructura y comportamiento de objetos similares estn definidos en su clase comn; los trminos instancia y objeto son intercambiables. Una clase es un conjunto de objetos que comparten una estructura y comportamiento comn. La diferencia entre un objeto y una clase es que un objeto es una entidad concreta que existe en tiempo y espacio, mientras que una clase representa una abstraccin, la "esencia" de un objeto, tal como son. De aqu que un objeto no es una clase, sin embargo, una clase puede ser un objeto.

Beneficios del enfoque OO Beneficios del enfoque OO

Los beneficios sealados por Booch en 1986 son: Potencia, el uso del modelo OO ayuda a explotar el poder expresivo de los lenguajes de programacin basados u orientados a objetos, como Smalltalk, Object Pascal, C++, CLOS, Ada, Java, C# Reutilizacin, el uso del modelo OO favorece la reutilizacin, no solo del software, sino de diseos completos. Mantenibilidad, produce sistemas que estn construidos en formas intermedias estables y por ello son ms resistentes al cambio en especificaciones y tecnologa.

AyDSI3 El paradigma 00 Orientacin a objetos

Enfoque OO Enfoque OO
Este paradigma centra su foco en el concepto Objeto. Objeto es aquello que tiene estado (propiedades ms valores), comportamiento (acciones y reacciones a mensajes) e identidad (propiedad que lo distingue de los dems objetos). La estructura y comportamiento de objetos similares estn definidos en su clase comn; los trminos instancia y objeto son intercambiables. Una clase es un conjunto de objetos que comparten una estructura y comportamiento comn. La diferencia entre un objeto y una clase es que un objeto es una entidad concreta que existe en tiempo y espacio, mientras que una clase representa una abstraccin, la "esencia" de un objeto, tal como son. De aqu que un objeto no es una clase, sin embargo, una clase puede ser un objeto.

Beneficios del enfoque OO Beneficios del enfoque OO

Los beneficios sealados por Booch en 1986 son: Potencia, el uso del modelo OO ayuda a explotar el poder expresivo de los lenguajes de programacin basados u orientados a objetos, como Smalltalk, Object Pascal, C++, CLOS, Ada, Java, C# Reutilizacin, el uso del modelo OO favorece la reutilizacin, no solo del software, sino de diseos completos. Mantenibilidad, produce sistemas que estn construidos en formas intermedias estables y por ello son ms resistentes al cambio en especificaciones y tecnologa.

10

AyDSI3

El Paradigma OO
objetos

Dominio del problema

11

AyDSI3

Conceptos Claves OO
clases y jerarquas de clases

instancias Herencia Abstracin y ocultamiento

objetos

atributos mtodos encapsulacin polimorfismo

mensajes
12

AyDSI3 El paradigma 00 Orientacin a objetos

Principios del modelo OO Principios del modelo OO
Fundamentales: Abstraccin, encapsulacin, modularidad y jerarqua. Booch afirma que un modelo en el que no est presente alguno de estos principios NO es un modelo OO. Complementarios: Tipificacin, concurrencia y persistencia Abstraccin. Simplificacin en la descripcin o especificacin de un sistema consistente en enfatizar algunos detalles o propiedades del sistema, con detrimento o supresin de otros. Encapsulacin. Ocultacin de los detalles de un objeto que no contribuyen a sus caractersticas esenciales. Modularidad. Propiedad de un sistema que ha sido descompuesto en un conjunto de mdulos coherentes e independientes. Jerarqua o herencia. Orden de las abstracciones organizado por niveles. Tipificacin. Definicin precisa de un objeto de forma tal que objetos de diferentes tipos no puedan ser intercambiados o, a lo sumo, pueden intercambiarse de manera muy restringida. Concurrencia . Propiedad que distingue un objeto que est activo de uno que no lo est. Persistencia. Propiedad de un objeto por la cual su existencia trasciende al tiempo (es decir, el objeto continua existiendo despus de que su creador ha dejado de existir) y/o al espacio (es decir, la localizacin del objeto se mueve del espacio de direccin en que fue creado).

13

AyDSI3

Clases
El pensamiento orientado a objetos comienza con la definicin de clases tambin definidos como:
Plantilla (template) descripcin generalizada patrones Prototipos (blueprint) ... describiendo colecciones de items similares

Los metaclases (tambin llamados superclases) son colecciones de clases Solo cuando una clase de objeto es definida, una especfica instancia de la clase (subclase) puede ser definida
14

AyDSI3

Construyendo una Clase

Nombre de clase Atributos: operaciones

atributos: operaciones:

15

AyDSI3

Qu es una Clase?
ocurrencias o eventos Cosas Entidad externa roles Unidades organizacionales lugares estructuras

Nombre de clase atributos:

operaciones:

16

AyDSI3

Encapsulacin/Ocultamiento
El objeto encapsula los datos y la lgica de procedimiento requerida para manipular el dato

mtodo #1

mtodo #2 Dato

mtodo #6

mtodo #5

mtodo #4

Logrando ocultamiento de la informacin (information hiding)

17

AyDSI3

Jerarquas de Clase
Muebles (superclase)

Mesa

Silla

Escritorio

sillesa"

Sub-clases de la Superclase Muebles

instancias de silla 18

AyDSI3

Mtodos (a.k.a. Operaciones, Servicios)

Procedimiento ejecutable que es encapsulado en una clase y es diseada para operar con uno o mas atributos que son definidos como parte de la clase. El mtodo es invocado por medio del paso de mensajes.

19

AyDSI3

Mensajes
Objeto Emisor Atributos:

Objeto Receptor Atributos: Operaciones:

Operaciones:

mensaje: [Emisor, valor(es) retornados]

mensaje: [Receptor, operaciones, parmetros]

20

10

AyDSI3

Nuestra realidad

Dilbert

21

AyDSI3

Cmo lidiar con ella?

P: Cul es la idea o tcnica de Ingeniera de Software mas excitante o promisoria? R: Yo no creo que las ideas mas promisorias estn en el horizonte. Ellas ya estn aqu, y han estado por aos, pero no estn siendo usadas adecuadamente. David L. Parnas
(Pionero de IS, desarroll el concepto de Diseo de Mdulos, cimiento del OOP)

22

11

AyDSI3

Cmo lidiar con ella?

23

AyDSI3

Cmo lidiar con ella?

24

12

AyDSI3

Cmo lidiar con ella?

El desarrollo de Software tiene una construccin predecible Cascada Grandes especificaciones minuciosas Planeamiento Predictivo

El desarrollo de Software es el desarrollo de un nuevo producto Iterativo Especificaciones evolutivas Planeamiento adaptable

25

AyDSI3

UML y Patrones en A/DOO

Tener un martillo no hace un Arquitecto En OO, conocer un lenguaje orientado a objetos (como Java) es necesario pero insuficiente, tambin es preciso conocer como pensar en objetos Entre una buena idea y un software que funcione cumpliendo sus requerimientos, hay mucho mas que programacin El Anlisis y el Diseo proveen un plano (blueprints) del software, ilustrado por un lenguaje de modelado, como el Unified Modeling Language (UML) El plano sirve como herramienta por medio del cual nos comunicamos con otros Una habilidad clave y fundamental es la asignacin cuidadosa de responsabilidades a los componentes de Soft. 26

13

AyDSI3

OOA - Object-Oriented Analysis

Es la investigacin del problema (independientemente de como se defina la solucin) Durante el anlisis OO, se pone especial nfasis en encontrar y describir los objetos (o conceptos) en el dominio del problema Por ejemplo, son objetos en un sistema de informacin de librera, el libro, biblioteca y socio El nfasis es en la investigacin del problema y sus requisitos (ms que una solucin) Se resume en: HACER LO CORRECTO
27

AyDSI3

OOD-Object-Oriented Design
Enfatiza una solucin conceptual que satisface los requerimientos (no en su implementacin) Necesita definir objetos de software y como ellos colaboran para cumplir los requisitos Por ejemplo, en el sistema de informacin de librera, el objeto de software libro puede tener un atributo Ttulo y un mtodo Obtener captulo El Diseo es implementado en un lenguaje de programacin En el ejemplo, vamos a tener una clase Libro en Java 28 Se resume en: HACERLO CORRECTAMENTE

14

AyDSI3

AOO Y DOO

Libro Concepto de Dominio Titulo

visualizacin del Concepto del Dominio

representacin en un lenguaje orientado a objetos

public class Libro { private String ttulo; public Capitulo getCapitulo(int) {...} }

29

AyDSI3

El Lenguaje de Modelado Unificado (UML)

El UML es un lenguaje visual para especificar, construir y documentar los artefactos de un sistema (OMG 2003). En este sentido UML es muy general. Pero el UML define perfiles que permiten su especializacin para dominios particulares (como la diagramacin de EJB con el perfil UML EJB).

30

15

AyDSI3

3 Formas de aplicar UML

M. Fowler nos ensea que el UML puede ser utilizado de tres formas:
UML as Sketch: Diagramacin informal e incompleta (a mano o en pizarrones) creados para explorar las partes difciles del espacio del problema o el espacio de la solucin. UML as Blueprint: Diagramas diseados con detalle relativo usados para (1) ingeniera inversa que permita visualizar y entender mejor cdigo existente o (2) para generacin de cdigo (ingeniera directa). UML as Programming language: especificaciones completas de un sistema software en UML. Se genera automticamente cdigo ejecutable que no es visto o modificado por los desarrolladores. Uno trabaja solamente en el lenguaje de programacin UML.

31

AyDSI3 UML y el pensamiento de la bala de plata Error fundamental: creer que hay una herramienta o tcnica de software que hace una diferencia dramtica en productividad, cerodefectos, confiabilidad o simplicidad.

Herramientas no compensan la ignorancia en diseo

Leer No Silver Bullet, Death by UML Fever y What UML Is and Isnt.

32

16

AyDSI3

3 Perspectivas para aplicar UML

La misma notacin de UML se puede utilizar desde al menos- 3 perspectivas:
Conceptual: los diagramas se interpretan describiendo cosas en el mundo real (el espacio del problema). Especificacin (software): los diagramas describen abstracciones software o componentes con especificaciones e interfaces; pero no se comprometen a una implementacin particular (Java o C# por ejemplo). Implementacin (software): los diagramas describen implementaciones software en una tecnologa particular (Java o C# por ejemplo).

33

AyDSI3

Perspectivas diferentes en UML

DiceGame 1 Includes 2 Die faceValue Conceptual Perspective (domain model) Raw UML class diagram notation used to visualize real-world concepts.

DiceGame die1 : Die die2 : Die play() 2

Die faceValue : int getFaceValue() : int roll()

Specification or Implementation Perspective (design class diagram) Raw UML class diagram notation used to visualize software elements.

34

17

AyDSI3

Ligas oficiales del UML

www.omg.org www.uml.org

35

AyDSI3

El Proceso Unificado (The Unified Process - UP)

El proceso es un conjunto semi-ordenado de pasos pensados para alcanzar una meta En la ingeniera de Software, la meta es desarrollar un producto de software eficiente y predecible que cumpla las necesidades del negocio El proceso de desarrollo de software describe un enfoque para la construccin, desarrollo y mantenimiento de software El proceso Unificado (UP) es un proceso para construir sistemas orientados a objetos La meta del UP es posibilitar la produccin de software de alta calidad que cumpla las necesidades de los usuarios dentro cronogramas y presupuestos predecibles

36

18

AyDSI3

El Proceso Unificado (The Unified Process - UP)

Para sistemas simples, podra ser factible secuencialmente definir todo el problema, disee toda la solucin, construir el software, y despus probar el producto Para sistemas complejos y sofisticados, este enfoque lineal no es realista El UP promueve el desarrollo iterativo.

37

AyDSI3

Desarrollo Iterativo
El Desarrollo est organizado en una serie de mini-proyectos cortos de duracin fija llamados iteraciones. El resultado de cada iteracin es un sistema incompleto que puede ser probado, integrado y ejecutado Una iteracin representa un ciclo de vida completo: que incluye sus propias actividades de anlisis de requisitos, diseo, implementacin y pruebas La retroalimentacin cclica y la adaptacin son los elementos principales principales que llevan 38 hacia un sistema adecuado

19

AyDSI3

Desarrollo Iterativo
[iteracin N] Requerimientos Anlisis - Diseo- Implementacin - Pruebas

[iteracin N+1] Requerimientos Anlisis - Diseo- Implementacin - Pruebas

Feedback de iteracin N nos lleva a refinar y adaptar los Requisitos y Diseo de la iteracin N+1.

El sistema crece incrementalmente

39

AyDSI3

Aceptando los cambios

Las personas involucradas (Stakeholders) usualmente tienen requerimientos de cambios Cada iteracin conlleva la eleccin de un pequeo conjunto de requisitos y, rpidamente disear, implementar y probar Esto conduce a un rpido feedback, y a la oportunidad de modificar o adaptar la comprensin de los requisitos o el diseo

40

20

AyDSI3

Fases del UP (Unified Process)

Inicio Elaboracin Construccin Transicin

tiempo

Un proyecto UP organiza el trabajo y las iteraciones en cuatro fases fundamentales: Inicio (Inception) Visin aproximada, anlsis del negocio, alcance, estimaciones del proyecto Elaboracin (Elaboration) Visin refinada, especificacin de caractersticas Construccin (Construction) Construccin del producto Transicin (Transition) - Transicin del producto dentro de la comunidad del usuario final
41

AyDSI3

Iteraciones e Hitos (Milestones)

Inicio Elaboracin Construccin Transicin

Iteracin Preliminar

Iter. #1 Iter.

Iter. #2 Iter.

Hito

Release

release final de production

Cada fase e iteracin tiene algn enfoque de mitigacin de riesgo, y concluye con un hito bien definido La revisiones de hitos proporcionan un punto en el tiempo para saber que tan bien fueron cumplidas las metas y donde el proyecto debe ser reestructurado de alguna forma para continuar El final de cada iteracin es una pequea versin o release, un sub-conjunto estable y ejecutable del producto final

42

21

AyDSI3

Las Disciplinas del UP

Fases Disciplinas de Proceso
Modelado del Negocio Requerimientos Anlisis & Diseo Implementacin Prueba Despliegue
Inicio Elaboracin Construccin Transicin

Disciplinas de Soporte
Adm Configuracin Gestin Proy, Entorno
Iteraciones Iter. Preliminares #1 Iter. #2 Iter. #n Iter. Iter. #n+1 #n+2 Iter. #m Iter. #m+1

Iteraciones

43

AyDSI3

Las Disciplinas del UP

Fases Disciplinas de Proceso
Modelado del Negocio Requerimientos Anlisis & Diseo Implementacin Prueba Despliegue
Inicio Elaboracin Construccin Transicin

Cada iteracin abarca todas las disciplinas.

Disciplinas de Soporte
Adm Configuracin Gestin Proy, Entorno
Iteraciones Iter. Preliminares #1 Iter. #2 Iter. #n Iter. Iter. #n+1 #n+2 Iter. #m Iter. #m+1

Iteraciones

44

22

AyDSI3

Las Disciplinas del UP

Fases Disciplinas de Proceso
Modelado del Negocio Requerimientos Anlisis & Diseo Implementacin Prueba Despliegue
Inicio Elaboracin Construccin Transicin

Inters de este curso

Disciplinas de Soporte
Adm Configuracin Gestin Proy, Entorno
Iteraciones Iter. Preliminares #1 Iter. #2 Iter. #n Iter. Iter. #n+1 #n+2 Iter. #m Iter. #m+1

Iteraciones

45

AyDSI3

Anlisis evolutivo de requisitos

1 2 3 4 5 ... 20 requirements workshops Imagine this will ultimately be a 20iteration project. In evolutionary iterative development, the requirements evolve over a set of the early iterations, through a series of requirements workshops (for example). Perhaps after four iterations and workshops, 90% of the requirements are defined and refined. Nevertheless, only 10% of the software is built.

requirements

requirements

software

software

90%

90%

50% 20% 2% Iteration 1 30% 5% Iteration 2 a 3-week iteration 8% Iteration 3 10% Iteration 4 20% Iteration 5

week 1 M T W Th F

week 2 M T W Th F

week 3 M T W Th F

kickoff meeting clarifying iteration goals with the team. 1 hour

team agile modeling & design, UML whiteboard sketching. 5 hours

start coding & testing

de-scope iteration goals if too much work

final check-in and codefreeze for the iteration baseline Use-case modeling during the workshop

demo and 2-day requirements workshop

next iteration planning meeting; 2 hours

Most OOA/D and applying UML during this period

46

23

AyDSI3

Ventajas del Proceso Iterativo

Reduce riesgos
Riesgos son identificados tempranamente, el progreso es fcil de ver

Se obtiene una arquitectura robusta

La arquitectura puede ser evaluada y mejora en forma temprana

Maneja requerimientos evolutivos

Usuarios proveen feedback del sistema operacional Respuesta al feedback es un cambio incremental

Permite cambios
El sistema puede adaptarse a los problemas

Se logra rpido aprendizaje

Todos obtienen un conocimiento de los diferentes flujos de trabajo en forma temprana
47

AyDSI3

Lecturas de inters
Iterative and Incremental Development: A brief history. Modelo de espiral de Bohem. No silver bullet. Understanding and controlling software costs. Product Development practices that work.

48

24

AyDSI3

Fin

49

25