Capitulo 1 - Introducción Al Análisis y Diseño

8/17/2019 Capitulo 1 - Introducción Al Análisis y Diseño

http://slidepdf.com/reader/full/capitulo-1-introduccion-al-analisis-y-diseno 1/22

Programa UML 2.4.1 for Developer- Enterprise Arc hi tect

In tro ducc ión al Anális is y

Diseño Or ien tado a Ob jetos

Al finalizar el capítulo, el alumno podrá:

Analizar los conceptos fundamentales del modelado orientado a objetos.

Reconocer el ciclo de vida del análisis y diseño, orientado a objetos.

Temas:

1. Crisis del software.

2. El modelado.

3. Conceptos iniciales.

4. Buenas prácticas.



Intro du cci ón al Análisi s y Diseño Orient ado a Obj etos 2

1. Crisis del software

1.1. Introducción

La crisis del software es un término empleado cuando el software que seconstruye, no solamente no satisface los requerimientos ni las necesidades pedidos

por el cliente, sino que además, excede los presupuestos y los horarios de tiempospreviamente establecidos.

Ejemplos de cris is de software:

- El departamento de vehículos motorizados de California gastó sobre $43 millones dedólares en un sistema para fundir los sistemas de conductores y registro de vehículos.Sin embargo, el sistema fue abandonado sin ni siquiera haber sido usado.

- Un fallido esfuerzo de $165 millones de dólares de American Airlines, de vincular susoftware de reserva de pasajes con el sistema de reservaciones de Marriott, Hilton yBudget.

Arthur Andersen reportó que más de $300 mil millones al año son gastados enactividades de software comercial en los Estados Unidos y sólo el 8% resulta ensoftware que es distribuido y que funciona.

1.2. Síntomas

Baja calidad del producto de software. Tiempo y presupuesto inicial excedido. Confiabilidad cuestionable. Altos requerimientos de personal para desarrollo y mantenimiento.




1.3. Razones para la crisis del software

a. Base inestable

Los requerimientos del negocio son ciclos de desarrollo más cortos, por ello,necesitan ser ubicados más rápido y más efectivamente. Los usuarios esperanmás, en términos de flexibilidad.Generalmente, los requerimientos iniciales están mal definidos o no están bienespecificados en su totalidad.

b. Fallas en el manejo del riesgo

El ciclo de vida de cascada retrasa la identificación de problemas. No haypruebas de que el sistema funcionará hasta que está cerca de ser terminado.El resultado es de máximo riesgo.

c. La complejidad del software

Todo software construido es el producto al que se llega al tratar de solucionarrequerimientos que pueden ser sencillos o complejos. Sumado a esto, elsoftware se construye en lenguajes de programación que pueden ser tambiénsencillos o complejos.

A más complejidad en los requerimientos y más difícil sean las herramientasque se utilicen en la construcción del software, más complejo se haceadministrarlo y hacerle el control de calidad necesario. Además, si no se cuentacon un buen diseño y análisis de los componentes de software, es casiimposible hacerle cambios o mantenimientos futuros.

1.4. Soluciones

Se basan en las fases de análisis y diseño del software; en la construcción de unmodelo sencillo, fácil de entender, compatible con muchas herramientas deprogramación y fácil de mantener.

Asimismo, se apoyan del uso del UML como lenguaje de modelamiento en todas lasfases de construcción de software.




2. El modelado

2.1. Introducción

En los principios de la computación, los programadores no realizaban análisis muyprofundos sobre el problema por resolver, con frecuencia comenzaban a escribir elprograma desde el principio y el código necesario se escribía conforme se requería,aunque esto agregaba un aura de aventura y atrevimiento al proceso, en laactualidad, es inapropiado en los negocios de alto riesgo.

Hoy en día es necesario contar con un plan bien diseñado y analizado, un clientetiene que comprender qué es lo que hará un equipo de desarrolladores, ademástiene que ser capaz de señalar cambios si no se han captado claramente susnecesidades.

El UML proporciona organización al proceso de diseño, de tal manera que losanalistas, clientes, desarrolladores y otras personas lo comprendan, conformeaumenta la complejidad en los sistemas informáticos.




2.2. Importancia de Modelar

Cuando se elabora un plan de diseño para un cliente, tal diseño debe ser elresultado de un cuidadoso análisis de las necesidades del cliente, tratando dereducir el periodo de desarrollo. Cuando los plazos se encuentran muy cercauno del otro es absolutamente necesario contar con un diseño sólido.

Las adquisiciones corporativas, demandan de un diseño sólido; cuando unaempresa adquiere de otra, los proyectos ya desarrollados o en desarrollo, quehan sido bien diseñados, ello facilitará la conversión, ya que si el diseño essólido los cambios se implementarán sin problemas.

2.3. Modelamiento

La forma en que las personas comprenden y procesan la realidad, se realiza através de conceptos que adquieren (modelamiento).

Un concepto es una idea o noción de algo aplicado a las cosas u objetos en formaconsciente. Por convención, ideas o conceptos poseídos de manera privada sellaman Concepciones, pero en cuanto la comprensión es compartida por variaspersonas se convierte en un Concepto. De esta manera, se aplican conceptos a

objetos de la realidad y se descartan conceptos que ya no se aplican.

Un modelo es la descripción de alguna cosa, que puede existir, estar en la etapa dedesarrollo o todavía, estar en la etapa de planificación. Por ejemplo, los esquemasgráficos son modelo de alguna cosa.

Durante la etapa del modelado, los diseñadores de modelos deben investigar losrequerimientos para el producto terminado. Los requerimientos incluyen áreas comofuncionalidad, apariencia, desempeño y confiabilidad. Por ello, los diseñadoresdeben crear un modelo que describa los diferentes aspectos del producto. Elmodelo puede ir a través de una serie de fases, donde cada fase agrega másdetalles al modelo.




La creación de modelos es un trabajo altamente creativo; no hay solución final, nohay una respuesta correcta que sea chequeada al final del trabajo.

Las características del modelo:

Seguros. Consistentes. Fáciles de comunicar a otros. Fáciles de cambiar. Comprensibles.

2.4. Métodos para el modelamiento

No-formales

Semi-formales

Formales

1

2

3

No-formales, usando lenguaje natural.

Semi-formales, notaciones (en parte gráficas) con ciertas reglas y cuyasconstrucciones tienen una semántica regularmente precisa.

Formales, usando una notación gráfica o textual, basada en un sistema formal(soporte matemático).

Los métodos formales permiten determinar y expresar con mayor rigor, laspropiedades del software. Sin embargo, aún no son ampliamente utilizados.

Las principales mejoras, al utilizar métodos formales en el modelamiento son:

- Mayor rigor en la especificación.

- Mejores condiciones para realizar la verificación y validación en forma más

exhaustiva.- Mejores condiciones para automatización de procesos de generación automática

de prototipos y/o código final.




3. Conceptos Iniciales

3.1. Objeto

Concepto: es la unidad atómica que puede caracterizar una entidad física(coche) o concepto (ecuación matemática), e integra estado y

comportamiento.

Los objetos representan cosas simples, reales o imaginarias, por ello, casitodo puede ser considerado un Objeto (dinero, helicóptero, parabólica,perros, etc.). No obstante, algunas cosas no son objetos sino atributos,valores o características de objetos, es decir, no todos son objetos (color,tamaño, velocidad, etc.)

Objeto = todo lo que rodea un entorno; puede ser concreto como abstracto.Objeto = cumple un ROL dentro de los sistemas de la organización.Objeto = conocer cómo realizar un trabajo y recordar la información.

Características: el término objeto en sistemas, representa una unidad desoftware con las siguientes características:

- Identidad.- Comportamiento.- Estado (Información).

Esta unidad de software es la representación computacional de una entidadexistente o no, de la realidad que se desea modelar.

OBJETO = IDENTIDAD + COMPORTAMIENTO + ESTADO




a) Identidad: cada objeto tiene una identidad única, incluso si su estado esidéntico al de otro objeto.

Cada objeto posee un identificador, el cual establece la identidad del objeto.

Además:

- Constituye un identificador único y global para cada objeto dentro del

sistema.- Es determinado en el momento de la creación del objeto.- Es independiente de la localización física del objeto, es decir, provee

completa independencia de localización.- Es independiente de las propiedades del objeto, lo cual implica

independencia de valor y de estructura.

b) Comportamiento (Responsabilidades): determina cómo actúa un objeto ycómo reacciona frente a las peticiones de otros objetos.El comportamiento de un objeto es modelado por un conjunto de mensajesa los que puede responder (las operaciones que el objeto puede realizar).

La totalidad de las tareas que el sistema debe realizar, son llevadas a cabo

por una enorme cantidad de objetos cooperantes. Esa asignación de tareasse realiza al momento del diseño OO. Las responsabilidades de un objetose realizan por medio de sus “métodos”. (Método = código ejecutable)

c) Estado: es una de las posibles condiciones en que el objeto puede existir,ya que el estado cambia en el transcurso del tiempo.

Además, el estado de un objeto es implementado por un conjunto depropiedades (atributos), con los valores de las propiedades, además de lasconexiones que deben tener con otros objetos. El estado evoluciona con eltiempo pero algunos atributos pueden ser constantes.

Objeto: Profesor Clark

Nombre Jorge Clark

Carné Seguro 56258965521

Fecha Ingreso 22 de agosto 2005

Estado Adjunto




d) Comunicación entre objetos: un sistema informático puede verse como unconjunto de objetos autónomos y concurrentes que trabajan de maneracoordinada en la consecución de un fin específico. De esta manera, elcomportamiento global se basa en la comunicación entre los objetos que lacomponen. El estudio de las formas de comunicación entre objetos es

primordial en el modelo de objetos.

Los objetos interactúan para realizar las funciones de la aplicación. Según lanaturaleza de las interacciones es posible describir el comportamiento delos objetos.

e) Categorías de comportamiento

- Actores: objetos en el origen de una interacción.- Servidores: no son nunca el origen de una interacción, sino los

receptores de los mensajes.

f) Concepto de mensaje

La unidad de comunicación entre objetos se llama mensaje. Para queexista un comportamiento (operación) es necesario que exista un mensaje.

Un mensaje es el soporte de una comunicación que vincula dinámicamentelos objetos que fueron separados, previamente, en el proceso dedescomposición. Además, permite la interacción de manera flexible yasegura la delegación de tareas.

La única forma de alterar el estado interno de un objeto es por medio delenvío de un mensaje. Dicho mensaje se resuelve por la ejecución de unmétodo del objeto receptor.




Laboratorio Nº 1

Objetivo:

Identificar los objetos del enunciado presentado, comparando cada elemento yverificando que tenga las características estudiadas.

Duración:

20 minutos

Descripción:De forma individual y según el enunciado, se identifican los objetos.

Enunciado:Solicite el enunciado a su instructor.

Notas:




3.2. Orientación a objetos

Puede describirse como el conjunto de disciplinas que desarrollan y modelizansoftware, los que a su vez, facilita la construcción de sistemas complejos a partir decomponentes.

La orientación a objetos es una técnica para el “modelado de sistemas” ; el análisis ydiseño estructurado. Fue tal vez, la primera familia de métodos de desarrollo desoftware usada ampliamente; sin embargo, bajo los estándares actuales, losproblemas para los cuales, el análisis y diseño estructurado eran aplicados son muysimples y de poco alcance. La experiencia con sistemas más grandes y complejosdescubrió limitaciones con este método, particularmente, cuando se desarrollasistemas con requerimientos inestables.

Utilizando la orientación a objetos, se modelan sistemas como objetos queinteractúan. Un modelo diseñado utilizando las técnicas de orientación a objetos esmás fácil de comprender.

El objetivo del AOO es modelar el mundo real, de forma que pueda ser entendido.Es necesario abstraer las características importantes del problema en primer lugar,dejando los detalles para más adelante, así el modelo puede ser relacionado“directamente” con el sistema real.

Las metodologías de análisis y diseño con orientación a objetos constituyen, hoy endía, la mejor opción para diseñar y construir sistemas robustos, flexibles yconfiables, en corto tiempo, aún para las aplicaciones más complejas.

Fortalezas de la Tecnología de objetos

Es un sólo paradigma. Presenta un sólo lenguaje usado por los usuarios, analistas, diseñadores e

implementadores. Facilidades de arquitectura y reuso de código. Los modelos reflejan mejor el mundo real. Mayor precisión describiendo datos corporativos y procesos. Descomposición basada en divisiones naturales. Fácil de entender y mantener. Estabilidad, un pequeño cambio en los requerimientos no significa cambios

masivos en el sistema en desarrollo.




3.3. Principios del software orientado a objetos

a) Abstracción: es la representación de las características esenciales de unobjeto, así como, de su comportamiento.

Definir una abstracción significa describir una entidad del mundo real, noimportando lo compleja que pueda ser, representando sus características ycomportamiento.

El desarrollo del software produce un modelo que puede ser ejecutado por unacomputadora. El elemento clave de la programación orientada a objetos es laclase, la cual puede ser definida como una descripción abstracta de un grupode objetos, cada uno de los cuales se diferencia por su estado específico y porla posibilidad de realizar una serie de operaciones.

b) Encapsulamiento: permite asegurar que el contenido de la información de unobjeto se encuentre oculto al mundo exterior. El objeto “X” no conoce lo que

hace el objeto “ Y” y viceversa. La encapsulación también conocida comoocultación de la información es entonces, el proceso de ocultar todos lossecretos de un objeto que no contribuyen a sus características esenciales.

c) Principio cliente-servidor: se basa en la interacción de entre dos entidades:el cliente y el servidor.El cliente hace solicitudes al servidor para que éste realice servicios. Además,en el enfoque orientado a objetos ambos, cliente y servidor, son clases uobjetos.

d) Jerarquía: es una propiedad que permite una ordenación de las abstracciones.Las dos jerarquías más importantes de un sistema complejo son:

Estructura de clases, jerarquía <<es un>> conocida como herencia ogeneralización.

Estructura de objetos, jerarquía <<parte de>> o también conocida comoagregación.

e) Polimorfismo: indica la posibilidad que una entidad tome muchas formas.Permite referirse a objetos de clases diferentes, mediante el mismo elementode programa y realizar la misma operación de diferentes formas, según sea elobjeto que se referencia en ese momento.

f) Modularidad: permite subdividir una aplicación en partes más pequeñasconocidas como módulos. Donde cada módulo es tan independiente como seaposible.




g) Persistencia: describe la capacidad de un objeto de trascender en el tiempo yespacio. Este objeto conserva su estado en un sistema de almacenamientopermanente.

3.4. Clases

ConceptoUna clase es una descripción de un grupo de objetos con propiedades encomún (atributos), comportamiento similar (operaciones), la misma manerade relacionarse entre objetos (asociaciones y agregados) y una semántica encomún.

Nombramiento de clasesEl nombre de la clase debe ser el sustantivo singular que mejor caracterice laabstracción. La dificultad al nombrar la clase revela una pobre definición de laabstracción. Los nombres deben provenir directamente del vocabulario deldominio.

Ejemplo de guía de estilo:

- Las clases son nombradas usando sustantivos singulares.- Los nombres de las clases comienzan con letra mayúscula.- No se usa el subrayado.- Los nombres compuestos por múltiples palabras se ponen juntos y la

primera letra de cada palabra se escribe con mayúscula.

Por ejemplo: Estudiante, Profesor, SistemaDePago

Notación de clases en UML

+consulta_grado()

+graba_sueldo()

-Apellidos

-Nombres

-Grado Academico

Profesor




Representación GráficaEn UML, una clase es representada usando un compartimiento rectangularcompuesto de tres secciones:

- La primera sección contiene el nombre de la clase.

- La segunda sección muestra la estructura (atributos).

- La tercera sección muestra el comportamiento (operaciones).




Laboratorio Nº 2

Objetivo:

Identificar las clases del enunciado presentado, reconociendo la diferencia con losobjetos, identificando y verificando las características estudiadas.

Duración:20 minutos

Descripción:De forma individual y según el enunciado, se identifican las clases.

Enunciado:Solicite el enunciado a su instructor.

Notas:




4. Buenas Prácticas

4.1. Las 6 mejores prácticas

RUP pretende implementar las mejores prácticas actuales en Ingeniería deSoftware, las cuales son propuestas, comercialmente probadas de desarrollo, que al

ser usadas en forma combinada, atacan la raíz de las causas de las fallas,eliminando los síntomas, así como, permitiendo el desarrollo y mantenimiento desoftware de calidad de manera predictiva y reiterativa.

a. Desarrollar software iterativamente.

Se basa en el desarrollo del software dando varios release o versiones iterativas alusuario, donde cada iteración resulta en un release ejecutable.

Beneficios:

Los desentendimientos importantes se evidencian tempranamente.

Se alienta el feedback del usuario. Se focaliza en los temas más críticos, sin distracciones. Se hace testing continuo e iterativo: evaluación objetiva.

Se previenen inconsistencias entre requerimientos, diseños eimplementaciones, pues se detectan tempranamente.

Carga de trabajo mejor repartida en el tiempo. El equipo puede analizar las lecciones aprendidas en las primeras iteraciones. Integración progresiva en lugar de Big Bang. Evidencias concretas a los sponsors. Se facilita la reutilización. Arquitectura más robusta.




b. Administrar los requerimientos

Es un enfoque sistemático que involucra: obtener, organizar y documentar lafuncionalidad, así como, restricciones requeridas a un sistema, Analizar los

cambios solicitados, además de evaluar impactos, registrar, y documentar lasalternativas y decisiones tomadas.

Los requerimientos deben ser adecuadamente capturados y comunicados a travésde Casos de Uso (aquí se usa diagramas de casos de uso UML)

Beneficios:

Las comunicaciones están basadas en requerimientos bien definidos. Los requerimientos pueden ser priorizados, filtrados y monitoreados. Es posible realizar evaluaciones objetivas acerca del éxito de un proyecto.

Las inconsistencias se detectan fácilmente.

Modelo de DiseñoModelo de Implementación Modelo de Test

verificaRealización influenciados por

Modelo de Casos de Uso

c. Utilizar arquitecturas basadas en componentes

La arquitectura de software representa el conjunto de decisiones significativassobre la organización de un sistema de software, tales como:

Selección de los elementos estructurales y sus interfaces, por los cuales elsistema está compuesto.

Comportamiento especificado como colaboraciones entre los elementos. Composición en subsistemas de los elementos estructurales y de

comportamiento. Estilo de arquitectura que guía a la organización.




Para desarrollar, orientado a componentes, se debe:

Definir arquitecturas muy modulares e identificar, aislar, diseñar, desarrollar yprobar componentes bien formados.

Desarrollar componentes para ser reutilizados. Formar la base de reusó de laorganización.

Industria de infraestructura de componentes

COM+ - Microsoft Component Object Model CORBA - Common Object Request Broker Architecture - OMG JavaBeans – SUN Bajo HTTP Webservices.

d. Modelar software visualmente

Una notación como UML permite elevar el nivel de abstracción, pudiendoadministrar más fácilmente los requerimientos, dando un lenguaje de diseño mássencillo y administrable.

Un modelo es una vista simplificada de un sistema. Esto muestra la esencia de unsistema desde una particular perspectiva y esconde los detalles no esenciales.

Los modelos pueden ayudar en los siguientes puntos:

Ayudar a comprender sistemas complejos.

Explorar y comparar una alternativa de diseño a bajo costo. Formar una fundación para implementación. Capturar requerimientos exactos. Comunicación de decisiones inequívocamente.




e. Verificar la calidad del software

La actividad fundamental de esta práctica es el Testing: evaluar continuamente lacalidad de un sistema con respecto a funcionalidad, confiabilidad y performance.

Beneficios:

La evaluación del estado del proyecto es objetiva, se evalúan resultados detest.

Se exponen inconsistencias en requerimientos, diseños e implementaciones. Se focaliza en las áreas de riesgo más alto. Los defectos se identifican en forma temprana. Existen herramientas automatizadas para el testing de funcionalidad,

confiabilidad y performance.

f. Controlar los cambios al software

Se debe controlar, registrar y monitorear los cambios para posibilitar el desarrolloiterativo y evitar el caos en la ejecución de un proyecto.Establecer “workspaces” seguros para cada desarrollador. Además de automatizarla integración y la administración de construcciones.

Beneficios:

Las solicitudes de cambios formales facilitan la claridad de comunicación. Los espacios de trabajo aislados reducen la interferencia entre los miembros

del equipo que trabajan en paralelo.




Las estadísticas de cantidad de cambios proveen buenas métricas paraevaluar objetivamente el estado del proyecto.

La propagación del cambio es evaluable y controlable.

Los cambios pueden ser mantenidos en sistemas automáticos.

4.2. Consecuencias de no aplicar las buenas prácticas

BajaCalidad delsoftware

a. Detección del fracaso en un proyecto

No cumplen sus objetivos. Se exceden considerablemente en el tiempo. Se exceden de su presupuesto.

No se comprendieron las necesidades del usuario. No se previó el impacto de los requerimientos de cambios. Se descubrieron muy tarde falencias graves en el proyecto. Hay módulos que no se pueden integrar. Administración de requerimientos insuficiente. Comunicación ambigua e imprecisa. Arquitectura frágil. Complejidad excesiva. Inconsistencias no detectadas entre requerimientos, diseño y

programación. Testing insuficiente. Evaluación subjetiva del avance del proyecto.

Enfrentamiento tardío de riesgos (desarrollo en cascada). Bajo nivel de automatización.




b. Síntomas de problemas en el desarrollo de software

Inadecuado entendimiento de las necesidades de los usuarios. Incapacidad de absorber cambios en los requerimientos. Módulos que no calzan entre si.

Software difícil de mantener o expandir. Tardía detección de errores. Baja calidad del software. Inaceptable performance del software. Incapacidad de reconstruir quién cambió qué, cuándo, dónde y porqué. Procedimiento de liberación y distribución poco confiable.

Figura. Las Mejores Prácticas enfrentan las Causas




Laboratorio Nº 3

Objetivos:

Reconoce las 6 mejores prácticas Identifica cómo se aplican las 6 mejores prácticas en el desarrollo de un proyecto.

Duración:20 minutos

Enunciado:Solicite el enunciado a su instructor

Notas:

Documents

Capitulo 1 - Introducción Al Análisis y Diseño