Hay una fuerza motriz más poderosa que el vapor, la electricidad y la energía atómica: la voluntad. Albert Einstein
miércoles, 24 de noviembre de 2010
Discurso Steve Jobs
lunes, 22 de noviembre de 2010
III. Métricas del software
MÉTRICAS DEL SOFTWARE.
Estas son las relacionadas con el desarrollo del software como funcionalidad, complejidad, eficiencia.
MÉTRICAS TÉCNICAS:
Se centran en las características de software pro ejemplo: la complejidad lógica, el grado de modularidad. Mide la estructura del sistema, el cómo está hecho.
MÉTRICAS DE CALIDAD:
Proporcionan una indicación de cómo se ajusta el software a los requisitos implícitos y explícitos del cliente. Es decir cómo voy a medir para que mi sistema se adapte a los requisitos que me pide el cliente.
MÉTRICAS DE PRODUCTIVIDAD:
Se centran en el rendimiento del proceso de la ingeniería del software. Es decir que tan productivo va a ser el software que voy a diseñar.
MÉTRICAS ORIENTADAS A LA PERSONA. Proporcionan medidas e información sobre la forma que la gente desarrolla el software de computadoras y sobre todo el punto de vista humano de la efectividad de las herramientas y métodos. Son las medidas que voy a hacer de mi personal que va hará el sistema.
MÉTRICAS ORIENTADAS AL TAMAÑO. Es para saber en qué tiempo voy a terminar el software y cuantas personas voy a necesitar. Son medidas directas al software y el proceso por el cual se desarrolla, si una organización de software mantiene registros sencillos, se puede crear una tabla de datos orientados al tamaño como se muestra en la siguiente figura:
CALIDAD DE SOFTWARE:
La calidad del software es una preocupación a la que se dedican muchos esfuerzos. Sin embargo, el software casi nunca es perfecto. Todo proyecto tiene como objetivo producir software de la mejor calidad posible, que cumpla, y si puede supere las expectativas de los usuarios.
Estándares de calidad para hacer desarrollo de software (cumplimiento de aspectos).
Tres normas:
• ISO 9000
• CMM
• ISO IRT 15504(SPICE)
ISO (International Standar Organization)
Pone a disposición de un auditor o certificador los procesos internos, de forma que este indique si cumple o no la normativa al 100%, audita el sistema; Si los resultados son positivos se emite la certificación y cada cierto tiempo se tiene que renovar; La certificación es costosa, a consecuencia de costes que ocasionan la lejanía y el tiempo de duración de proceso (aprox. 6 meses). Se certifica la empresa y la metodología para el desarrollo de la aplicación.
Características:
* Es un modelo internacional, apropiado por casi 140 países.
* ISO Busca normalizar el contenido de sus normas con cada país. En Colombia ISO se traduce en NTC (Norma técnica calidad).
* ISO sugiere un plan de atención de calidad, deja en libertad a las propietarios de las empresas para adaptarse o modificar el plan.
Etapas:
* Control de calidad
* Gestión de calidad
* Calidad total
1. Control de calidad
Determina los puntos de medida (Hitos de control),para verificar las existencia del producto o entregables para el cliente
¿Quien hace el control de calidad?
• Los analistas y desarrolladores del software
• El control de calidad es un producto técnico
Ejemplo: (UP) entregables
Contrato de desarrollo: Documento legal que hace parte integral del análisis de requisitos
• Análisis de requisitos
• Documento Diseño
• Generación de pruebas
2. Gestión de calidad
Proceso mediante el cual se garantiza que las entregables lleguen a un punto y fecha determinados previamente.
• No es un proceso técnico, es administrativo
• ¿Quien hace la gestión de calidad?
• La desarrolla el líder del proyecto (Management)
Ejemplo:(UP)
• Satisfacción del cliente
3. Calidad total (mejora continua)
Es un proceso que determina las condiciones para comprobar la satisfaccion total del cliente en términos de:
• Requisitos: contrato de desarrollo (requisitos de software)
• Proceso: análisis y diseño
• Producto: terminación proceso: Documentos, código, pruebas
¿Quien hace la calidad total?
• Los desarrolladores y los clientes
• es un proceso de alta gerencia
NORMAS CONTRACTUALES
"Hacia los clientes"
Son de obligatorio cumplimiento
ISO 9000_1
ISO 9000_3
msj :: "la norma exige"
NORMAS NO CONTRACTUALES
“Hacia el interior de la organización”
Son patrones de referencia
ISO 90002
msj :: "la norma sugiere"
Capability Maturity Model Integration (CMMI)
Para las compañías un producto o servicio es de calidad cuando satisface las necesidades y expectativas del cliente otorgando a éste seguridad sobre su uso, fiabilidad de sus funciones esperadas y confianza en un producto o servicio sin fallos y duradero según tiempos establecidos y acordados. Debido a la amplitud de temas que engloba el concepto de calidad se ha definido el concepto de Calidad Total, el cual se define como un sistema de gestión organizacional enfocado en la mejora continua del producto o servicio en todo su ciclo de vida, involucrando marketing, compras, diseño, fabricación y entrega.
La Calidad Total contempla dos fases:
1. Control de calidad, basado en técnicas de inspección aplicadas a producción.
2. Aseguramiento de la calidad, que persigue garantizar un nivel continúo de la calidad del Producto o Servicio proporcionado.
Los principios básicos de la Calidad Total son nueve:
1. Consecución de la plena satisfacción de las necesidades y expectativas del cliente (interno y externo).
2. Desarrollo de un proceso de mejora continúa en todos los procesos.
3. Total compromiso de la Dirección.
4. Liderazgo activo de todo el equipo directivo.
5. Participación de todos los miembros de la organización
6. Fomento del trabajo en equipo hacia una gestión de Calidad Total.
7. El proveedor debe estar involucrado en el sistema de Calidad Total de la empresa.
8. Identificación y Gestión de los Procesos Claves de la organización.
9. Toma de decisiones de gestión basada en datos y hechos objetivos.
En este contexto, los modelos de calidad son sistemas basados en estudios experimentales de mejores prácticas que ayudan a una organización a implantar un Sistema de aseguramiento de la calidad. Los modelos de calidad se dividen en modelos de referencia, que indican cuáles son las prácticas pero no cómo se consiguen, y los modelos de implantación que se enfocan en cómo se consiguen aquellas práctica. Aunque existe gran variedad de ambos tipos de modelos se destacan por su eficacia probada los modelos de referencia.
Estas son las relacionadas con el desarrollo del software como funcionalidad, complejidad, eficiencia.
MÉTRICAS TÉCNICAS:
Se centran en las características de software pro ejemplo: la complejidad lógica, el grado de modularidad. Mide la estructura del sistema, el cómo está hecho.
MÉTRICAS DE CALIDAD:
Proporcionan una indicación de cómo se ajusta el software a los requisitos implícitos y explícitos del cliente. Es decir cómo voy a medir para que mi sistema se adapte a los requisitos que me pide el cliente.
MÉTRICAS DE PRODUCTIVIDAD:
Se centran en el rendimiento del proceso de la ingeniería del software. Es decir que tan productivo va a ser el software que voy a diseñar.
MÉTRICAS ORIENTADAS A LA PERSONA. Proporcionan medidas e información sobre la forma que la gente desarrolla el software de computadoras y sobre todo el punto de vista humano de la efectividad de las herramientas y métodos. Son las medidas que voy a hacer de mi personal que va hará el sistema.
MÉTRICAS ORIENTADAS AL TAMAÑO. Es para saber en qué tiempo voy a terminar el software y cuantas personas voy a necesitar. Son medidas directas al software y el proceso por el cual se desarrolla, si una organización de software mantiene registros sencillos, se puede crear una tabla de datos orientados al tamaño como se muestra en la siguiente figura:
CALIDAD DE SOFTWARE:
La calidad del software es una preocupación a la que se dedican muchos esfuerzos. Sin embargo, el software casi nunca es perfecto. Todo proyecto tiene como objetivo producir software de la mejor calidad posible, que cumpla, y si puede supere las expectativas de los usuarios.
Estándares de calidad para hacer desarrollo de software (cumplimiento de aspectos).
Tres normas:
• ISO 9000
• CMM
• ISO IRT 15504(SPICE)
ISO (International Standar Organization)
Pone a disposición de un auditor o certificador los procesos internos, de forma que este indique si cumple o no la normativa al 100%, audita el sistema; Si los resultados son positivos se emite la certificación y cada cierto tiempo se tiene que renovar; La certificación es costosa, a consecuencia de costes que ocasionan la lejanía y el tiempo de duración de proceso (aprox. 6 meses). Se certifica la empresa y la metodología para el desarrollo de la aplicación.
Características:
* Es un modelo internacional, apropiado por casi 140 países.
* ISO Busca normalizar el contenido de sus normas con cada país. En Colombia ISO se traduce en NTC (Norma técnica calidad).
* ISO sugiere un plan de atención de calidad, deja en libertad a las propietarios de las empresas para adaptarse o modificar el plan.
Etapas:
* Control de calidad
* Gestión de calidad
* Calidad total
1. Control de calidad
Determina los puntos de medida (Hitos de control),para verificar las existencia del producto o entregables para el cliente
¿Quien hace el control de calidad?
• Los analistas y desarrolladores del software
• El control de calidad es un producto técnico
Ejemplo: (UP) entregables
Contrato de desarrollo: Documento legal que hace parte integral del análisis de requisitos
• Análisis de requisitos
• Documento Diseño
• Generación de pruebas
2. Gestión de calidad
Proceso mediante el cual se garantiza que las entregables lleguen a un punto y fecha determinados previamente.
• No es un proceso técnico, es administrativo
• ¿Quien hace la gestión de calidad?
• La desarrolla el líder del proyecto (Management)
Ejemplo:(UP)
• Satisfacción del cliente
3. Calidad total (mejora continua)
Es un proceso que determina las condiciones para comprobar la satisfaccion total del cliente en términos de:
• Requisitos: contrato de desarrollo (requisitos de software)
• Proceso: análisis y diseño
• Producto: terminación proceso: Documentos, código, pruebas
¿Quien hace la calidad total?
• Los desarrolladores y los clientes
• es un proceso de alta gerencia
NORMAS CONTRACTUALES
"Hacia los clientes"
Son de obligatorio cumplimiento
ISO 9000_1
ISO 9000_3
msj :: "la norma exige"
NORMAS NO CONTRACTUALES
“Hacia el interior de la organización”
Son patrones de referencia
ISO 90002
msj :: "la norma sugiere"
Capability Maturity Model Integration (CMMI)
Para las compañías un producto o servicio es de calidad cuando satisface las necesidades y expectativas del cliente otorgando a éste seguridad sobre su uso, fiabilidad de sus funciones esperadas y confianza en un producto o servicio sin fallos y duradero según tiempos establecidos y acordados. Debido a la amplitud de temas que engloba el concepto de calidad se ha definido el concepto de Calidad Total, el cual se define como un sistema de gestión organizacional enfocado en la mejora continua del producto o servicio en todo su ciclo de vida, involucrando marketing, compras, diseño, fabricación y entrega.
La Calidad Total contempla dos fases:
1. Control de calidad, basado en técnicas de inspección aplicadas a producción.
2. Aseguramiento de la calidad, que persigue garantizar un nivel continúo de la calidad del Producto o Servicio proporcionado.
Los principios básicos de la Calidad Total son nueve:
1. Consecución de la plena satisfacción de las necesidades y expectativas del cliente (interno y externo).
2. Desarrollo de un proceso de mejora continúa en todos los procesos.
3. Total compromiso de la Dirección.
4. Liderazgo activo de todo el equipo directivo.
5. Participación de todos los miembros de la organización
6. Fomento del trabajo en equipo hacia una gestión de Calidad Total.
7. El proveedor debe estar involucrado en el sistema de Calidad Total de la empresa.
8. Identificación y Gestión de los Procesos Claves de la organización.
9. Toma de decisiones de gestión basada en datos y hechos objetivos.
En este contexto, los modelos de calidad son sistemas basados en estudios experimentales de mejores prácticas que ayudan a una organización a implantar un Sistema de aseguramiento de la calidad. Los modelos de calidad se dividen en modelos de referencia, que indican cuáles son las prácticas pero no cómo se consiguen, y los modelos de implantación que se enfocan en cómo se consiguen aquellas práctica. Aunque existe gran variedad de ambos tipos de modelos se destacan por su eficacia probada los modelos de referencia.
II. Patrones de diseño y plantillas frameworks
PATRONES DE DISEÑO
Definición de patrón: plantilla
“Los patrones de diseño son una estructura de código ya definida que busca solucionar un sin número de problemas comunes en el desarrollo de software.”
Objetivo: ubicar al usuario en el contenido y no el diseño de la plantilla.
Características:
- Las plantillas son de bajo costo, si se relaciona la utilidad con la inversión.
- Se utilizan en diferentes tipos de aplicaciones.
- Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
Patrón orientado a objetos:
Identificación de casos de uso
Definición: El caso de uso describe una funcionalidad parcial del sistema que se va a desarrollar.
Ejemplo: Un sistema POS que recibe pagos en efectivo, con tarjeta y con cheque; y que ademas ...
Modelo conceptual
Abarca las abstracciones del mundo real en términos de claves y objetos.
El Modelo Conceptual ilustra:
• Conceptos (Objetos) en el dominio del problema.
• Es el instrumento (artefacto) más importante de
Crear en el AOO.
• Es la representación de cosas del mundo real y
NO de componentes de software. En él NO se
Definen operaciones.
• Puede representarse mediante un diagrama de
Estructura estático (notación UML).
Características
El modelo conceptual se convierte en el insumo básico del diagrama de clases.
Diagrama de secuencia
Describe espacial y temporal el flujo normal de eventos entre los diferentes conceptos presentes en el sistema.
Definición de clases:
Se especifican las clases presentes en el sistema y se paramearían (métodos y atributos para cada clase).
Patrones de diseño vista-control
Ofrece un número mayor de ventajas con respecto al patrón orientado a objetos.
Tiene tres componentes (capas de desarrollo)
*
Capa vista: en términos de la interfaz de usuario.
*
Capa lógica: se almacena e implementan los objetos de la aplicación, tiene dos presentaciones
Capa conceptos
Ejemplo: Usuario y contraseña
Capa conceptos
Ejemplo: Nombre del usuario y comparar contraseña.
3-Capa de almacenamiento: gestión de archivos, Bases de datos.
Ejemplo: gestión de archivos con los nombres de los usuarios El patrón vista-control sugiere un diseño TOP-DOWN con una importancia centrada en la interfaz de usuario la cual debe ser obtenida a partir de los requisitos del producto software.
Requisitos
Es una necesidad que tiene un usuario o cliente de un producto software
Necesidad se traduce en términos de funciones.
Características:
*
Todos los requisitos no deben dar posibilidad a la ambigüedad
*
Los requisitos deben permitir entender el domino de la aplicaron
*
Los requisitos se deben obtener del cliente o usuario
Diagrama de casos de uso
Actor: fuente o sumidero "Externo" al sistema que interactúa con el desencadenado una serie de eventos interrelacionados.
Atributo del sistema: Son requisitos no funcionales, que son necesidades propias del producto software.
Aplicación
Medio físico (Hardware) memoria, etc.
Tolerancia a fallos.
Metáfora de la interfaz: Describe el estándar utilizado para desarrollar la interfaz.
Técnicas para levantar requisitos:
1-Entrevista.
2-JAD (Joint applications Development).
3-Sketch ans story board.
4-Concept Moping.
5-Brainstorming (lluvia de ideas).
6-Layout.
7-Use case.
8-Patrones.
9-Chek List.
Patrón Arquitectónico de capas
La arquitectura del SI es una descripción de los
Subsistemas y componentes, y las relaciones entre ellos.
• Determina:
• La organización estructural del SI.
• La selección de los elementos estructurales.
• Las interfaces entre ellos.
• El comportamiento de los componentes.
• Un componente es una parte física y reemplazable de un sistema.
Catálogo parcial de patrones arquitectónicos
• Llamada y retorno
• Estilo más usado en los grandes SI
• Descomposición modular jerárquica
• Orientado a objetos
• En capas
• Centrado en los datos
• permite la manipulación compartida de datos
• Repositorio
• Pizarra
• Flujo de datos
• permite la transformación incremental de los datos
• Batch secuencial
• Tubos y filtros
• Modelo – vista – controlador
• para sistemas interactivos
Patrones Grasp (General reponsability assignament software pattern)
En diseño orientado a objetos, GRASP son patrones generales de software para asignación de responsabilidades, es el acrónimo de "General Responsibility Assignment Software Patterns”. Aunque se considera que más que patrones propiamente dichos, son una serie de "buenas prácticas" de aplicación recomendable en el diseño de software.
Patrones de software para asignar responsabilidades
Función:
Definir en las clases de análisis.
1-La clase con mayor jerarquía para implementar en ella los métodos.
Clase patrón
2-Asignar responsabilidades a las clases.
Elementos para definir un patrón Grasp.
Diagrama de paquetes
Diagrama de secuencia
Diagrama de paquetes
Paquete: Agrupación de casos de uso con aspectos similares en su funcionalidad.
Ejemplo:
Diagrama de secuencia
El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML. En inglés se pueden encontrar como "sequence diagram", "event-trace diagrams", "event scenarios" o "timing diagrams"
Patrones Grasp
• Patrón experto.
• Patrón creador.
• Patrón bajo acoplamiento.
• Patrón alta cohesión.
• Patrón controlador.
Patrón experto
Determina en un modelo conceptual (Diagrama de clases) la clase que posee la mayor jerarquía para asignarle una responsabilidad "La responsabilidad que se quiera evaluar y debe ser implementado por un método"
Ventajas del patrón experto
*
Garantizar el encapsulamiento de la información
*
Facilita el bajo acoplamiento en las aplicaciones
Patrón creador
Se utiliza cuando se quiere a partir de una clase con alta jerarquía obtener clases descendiente o instancias a partir de las clases obtenidas.
Tipos de clases:
Clases abstractas (1)
Clases concretas (2)
(1) son las clases que dan origen a otras solamente.
(2) son las clases a partir de las cuales se pueden obtener instancias.
El patrón creador define dos estructuras dentro de la jerarquía
Estructura AKO
Estructura APO
AKO(A King of): una clase de
APO(A Punto of): una parte de
Patrón bajo Acoplamiento
Es la idea de tener las clases lo menos ligadas entre sí que se pueda. De tal forma que en caso de producirse una modificación en alguna de ellas, se tenga la mínima repercusión posible en el resto de clases, potenciando la reutilización, y disminuyendo la dependencia entre las clases
1. Acoplamiento de Contenido: Cuando un módulo referencia directamente el contenido de otro módulo. (En lenguajes de alto nivel es muy raro)
2. Acoplamiento Común: Cuando dos módulos acceden (y afectan) a un mismo valor global.
3. Acoplamiento de Control: Cuando un módulo le envía a otro un elemento de control que determina la lógica de ejecución del mismo.
Patrón alto cohesión
Nos dice que la información que almacena una clase debe de ser coherente y debe estar (en la medida de lo posible) relacionada con la clase.
1. Cohesión Coincidente: El módulo realiza múltiples tareas, sin ninguna relación entre ellas.
2. Cohesión Lógica: El módulo realiza múltiples tareas relacionadas, pero, en tiempo de ejecución, sólo una de ellas será llevada a cabo.
3. Cohesión Temporal: Las tareas llevadas a cabo por un módulo tienen, como única relación las deber ser ejecutadas “al mismo tiempo”.
4. Cohesión de Procedimiento: La única relación que guardan las tareas de un módulo es que corresponden a una secuencia de pasos propia del “producto”.
5. Cohesión de Comunicación: Las tareas corresponden a una secuencia de pasos propia del “producto” y todas afectan a los mismos datos.
6. Cohesión de Información: Las tareas llevadas a cabo por un módulo tienen su propio punto de arranque, su codificación independiente y trabajan sobre los mismos datos. El ejemplo típico: OBJETOS
7. Cohesión Funcional: Cuando el módulo ejecuta una y sólo una tarea, teniendo un único objetivo a cumplir, se dice que tiene Cohesividad Funcional.
Patrón controlador
Es el encargado de definir las estructuras para los patrones experto y creador.
Experto: Diagrama de secuencia.
Creadas: Jerarquía: AKO, APO.
Patrones Gof
Gang-of-Four (“pandilla de los cuatro”) Descritos en el libro Design Patterns(Gama1995) definieron un catálogo con 23 Patrones básicos. Los patrones de diseño (design patterns) son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.
Un patrón de diseño es una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reusable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.
Relación de principales patrones GoF (Gang Of Four)
Patrones creacionales
Abstract Factory (Fábrica abstracta): Permite trabajar con objetos de distintas familias de manera que las familias no se mezclen entre sí y haciendo transparente el tipo de familia concreta que se esté usando.
Builder (Constructor virtual): Abstrae el proceso de creación de un objeto complejo, centralizando dicho proceso en un único punto.
Factory Method (Método de fabricación): Centraliza en una clase constructora la creación de objetos de un subtipo de un tipo determinado, ocultando al usuario la casuística para elegir el subtipo que crear.
Prototype (Prototipo): Crea nuevos objetos clonándolos de una instancia ya existente.
Singleton (Instancia única): Garantiza la existencia de una única instancia para una clase y la creación de un mecanismo de acceso global a dicha instancia.
Patrones estructurales
Adapter (Adaptador): Adapta una interfaz para que pueda ser utilizada por una clase que de otro modo no podría utilizarla.
Bridge (Puente): Desacopla una abstracción de su implementación.
Composite (Objeto compuesto): Permite tratar objetos compuestos como si de un simple se tratase.
Decorator (Envoltorio): Añade funcionalidad a una clase dinámicamente.
Facade (Fachada): Provee de una interfaz unificada simple para acceder a una interfaz o grupo de interfaces de un subsistema.
Flyweight (Peso ligero): Reduce la redundancia cuando gran cantidad de objetos poseen idéntica información.
Proxy: Mantiene un representante de un objeto.
Patrones de comportamiento
Chain of Responsibility (Cadena de responsabilidad): Permite establecer la línea que deben llevar los mensajes para que los objetos realicen la tarea indicada.
Command (Orden): Encapsula una operación en un objeto, permitiendo ejecutar dicha operación sin necesidad de conocer el contenido de la misma.
Interpreter (Intérprete): Dado un lenguaje, define una gramática para dicho lenguaje, así como las herramientas necesarias para interpretarlo.
Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos independientemente de la implementación de estos.
Mediator (Mediador): Define un objeto que coordine la comunicación entre objetos de distintas clases, pero que funcionan como un conjunto.
Memento (Recuerdo): Permite volver a estados anteriores del sistema.
Observer (Observador): Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambie de estado se notifique y actualicen automáticamente todos los objetos que dependen de él.
State (Estado): Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno.
Strategy (Estrategia): Permite disponer de varios métodos para resolver un problema y elegir cuál utilizar en tiempo de ejecución.
Template Method (Método plantilla): Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos, esto permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura.
Visitor (Visitante): Permite definir nuevas operaciones sobre una jerarquía de clases sin modificar las clases sobre las que opera.
Definición de patrón: plantilla
“Los patrones de diseño son una estructura de código ya definida que busca solucionar un sin número de problemas comunes en el desarrollo de software.”
Objetivo: ubicar al usuario en el contenido y no el diseño de la plantilla.
Características:
- Las plantillas son de bajo costo, si se relaciona la utilidad con la inversión.
- Se utilizan en diferentes tipos de aplicaciones.
- Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
Patrón orientado a objetos:
Identificación de casos de uso
Definición: El caso de uso describe una funcionalidad parcial del sistema que se va a desarrollar.
Ejemplo: Un sistema POS que recibe pagos en efectivo, con tarjeta y con cheque; y que ademas ...
Modelo conceptual
Abarca las abstracciones del mundo real en términos de claves y objetos.
El Modelo Conceptual ilustra:
• Conceptos (Objetos) en el dominio del problema.
• Es el instrumento (artefacto) más importante de
Crear en el AOO.
• Es la representación de cosas del mundo real y
NO de componentes de software. En él NO se
Definen operaciones.
• Puede representarse mediante un diagrama de
Estructura estático (notación UML).
Características
El modelo conceptual se convierte en el insumo básico del diagrama de clases.
Diagrama de secuencia
Describe espacial y temporal el flujo normal de eventos entre los diferentes conceptos presentes en el sistema.
Definición de clases:
Se especifican las clases presentes en el sistema y se paramearían (métodos y atributos para cada clase).
Patrones de diseño vista-control
Ofrece un número mayor de ventajas con respecto al patrón orientado a objetos.
Tiene tres componentes (capas de desarrollo)
*
Capa vista: en términos de la interfaz de usuario.
*
Capa lógica: se almacena e implementan los objetos de la aplicación, tiene dos presentaciones
Capa conceptos
Ejemplo: Usuario y contraseña
Capa conceptos
Ejemplo: Nombre del usuario y comparar contraseña.
3-Capa de almacenamiento: gestión de archivos, Bases de datos.
Ejemplo: gestión de archivos con los nombres de los usuarios El patrón vista-control sugiere un diseño TOP-DOWN con una importancia centrada en la interfaz de usuario la cual debe ser obtenida a partir de los requisitos del producto software.
Requisitos
Es una necesidad que tiene un usuario o cliente de un producto software
Necesidad se traduce en términos de funciones.
Características:
*
Todos los requisitos no deben dar posibilidad a la ambigüedad
*
Los requisitos deben permitir entender el domino de la aplicaron
*
Los requisitos se deben obtener del cliente o usuario
Diagrama de casos de uso
Actor: fuente o sumidero "Externo" al sistema que interactúa con el desencadenado una serie de eventos interrelacionados.
Atributo del sistema: Son requisitos no funcionales, que son necesidades propias del producto software.
Aplicación
Medio físico (Hardware) memoria, etc.
Tolerancia a fallos.
Metáfora de la interfaz: Describe el estándar utilizado para desarrollar la interfaz.
Técnicas para levantar requisitos:
1-Entrevista.
2-JAD (Joint applications Development).
3-Sketch ans story board.
4-Concept Moping.
5-Brainstorming (lluvia de ideas).
6-Layout.
7-Use case.
8-Patrones.
9-Chek List.
Patrón Arquitectónico de capas
La arquitectura del SI es una descripción de los
Subsistemas y componentes, y las relaciones entre ellos.
• Determina:
• La organización estructural del SI.
• La selección de los elementos estructurales.
• Las interfaces entre ellos.
• El comportamiento de los componentes.
• Un componente es una parte física y reemplazable de un sistema.
Catálogo parcial de patrones arquitectónicos
• Llamada y retorno
• Estilo más usado en los grandes SI
• Descomposición modular jerárquica
• Orientado a objetos
• En capas
• Centrado en los datos
• permite la manipulación compartida de datos
• Repositorio
• Pizarra
• Flujo de datos
• permite la transformación incremental de los datos
• Batch secuencial
• Tubos y filtros
• Modelo – vista – controlador
• para sistemas interactivos
Patrones Grasp (General reponsability assignament software pattern)
En diseño orientado a objetos, GRASP son patrones generales de software para asignación de responsabilidades, es el acrónimo de "General Responsibility Assignment Software Patterns”. Aunque se considera que más que patrones propiamente dichos, son una serie de "buenas prácticas" de aplicación recomendable en el diseño de software.
Patrones de software para asignar responsabilidades
Función:
Definir en las clases de análisis.
1-La clase con mayor jerarquía para implementar en ella los métodos.
Clase patrón
2-Asignar responsabilidades a las clases.
Elementos para definir un patrón Grasp.
Diagrama de paquetes
Diagrama de secuencia
Diagrama de paquetes
Paquete: Agrupación de casos de uso con aspectos similares en su funcionalidad.
Ejemplo:
Diagrama de secuencia
El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML. En inglés se pueden encontrar como "sequence diagram", "event-trace diagrams", "event scenarios" o "timing diagrams"
Patrones Grasp
• Patrón experto.
• Patrón creador.
• Patrón bajo acoplamiento.
• Patrón alta cohesión.
• Patrón controlador.
Patrón experto
Determina en un modelo conceptual (Diagrama de clases) la clase que posee la mayor jerarquía para asignarle una responsabilidad "La responsabilidad que se quiera evaluar y debe ser implementado por un método"
Ventajas del patrón experto
*
Garantizar el encapsulamiento de la información
*
Facilita el bajo acoplamiento en las aplicaciones
Patrón creador
Se utiliza cuando se quiere a partir de una clase con alta jerarquía obtener clases descendiente o instancias a partir de las clases obtenidas.
Tipos de clases:
Clases abstractas (1)
Clases concretas (2)
(1) son las clases que dan origen a otras solamente.
(2) son las clases a partir de las cuales se pueden obtener instancias.
El patrón creador define dos estructuras dentro de la jerarquía
Estructura AKO
Estructura APO
AKO(A King of): una clase de
APO(A Punto of): una parte de
Patrón bajo Acoplamiento
Es la idea de tener las clases lo menos ligadas entre sí que se pueda. De tal forma que en caso de producirse una modificación en alguna de ellas, se tenga la mínima repercusión posible en el resto de clases, potenciando la reutilización, y disminuyendo la dependencia entre las clases
1. Acoplamiento de Contenido: Cuando un módulo referencia directamente el contenido de otro módulo. (En lenguajes de alto nivel es muy raro)
2. Acoplamiento Común: Cuando dos módulos acceden (y afectan) a un mismo valor global.
3. Acoplamiento de Control: Cuando un módulo le envía a otro un elemento de control que determina la lógica de ejecución del mismo.
Patrón alto cohesión
Nos dice que la información que almacena una clase debe de ser coherente y debe estar (en la medida de lo posible) relacionada con la clase.
1. Cohesión Coincidente: El módulo realiza múltiples tareas, sin ninguna relación entre ellas.
2. Cohesión Lógica: El módulo realiza múltiples tareas relacionadas, pero, en tiempo de ejecución, sólo una de ellas será llevada a cabo.
3. Cohesión Temporal: Las tareas llevadas a cabo por un módulo tienen, como única relación las deber ser ejecutadas “al mismo tiempo”.
4. Cohesión de Procedimiento: La única relación que guardan las tareas de un módulo es que corresponden a una secuencia de pasos propia del “producto”.
5. Cohesión de Comunicación: Las tareas corresponden a una secuencia de pasos propia del “producto” y todas afectan a los mismos datos.
6. Cohesión de Información: Las tareas llevadas a cabo por un módulo tienen su propio punto de arranque, su codificación independiente y trabajan sobre los mismos datos. El ejemplo típico: OBJETOS
7. Cohesión Funcional: Cuando el módulo ejecuta una y sólo una tarea, teniendo un único objetivo a cumplir, se dice que tiene Cohesividad Funcional.
Patrón controlador
Es el encargado de definir las estructuras para los patrones experto y creador.
Experto: Diagrama de secuencia.
Creadas: Jerarquía: AKO, APO.
Patrones Gof
Gang-of-Four (“pandilla de los cuatro”) Descritos en el libro Design Patterns(Gama1995) definieron un catálogo con 23 Patrones básicos. Los patrones de diseño (design patterns) son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.
Un patrón de diseño es una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reusable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.
Relación de principales patrones GoF (Gang Of Four)
Patrones creacionales
Abstract Factory (Fábrica abstracta): Permite trabajar con objetos de distintas familias de manera que las familias no se mezclen entre sí y haciendo transparente el tipo de familia concreta que se esté usando.
Builder (Constructor virtual): Abstrae el proceso de creación de un objeto complejo, centralizando dicho proceso en un único punto.
Factory Method (Método de fabricación): Centraliza en una clase constructora la creación de objetos de un subtipo de un tipo determinado, ocultando al usuario la casuística para elegir el subtipo que crear.
Prototype (Prototipo): Crea nuevos objetos clonándolos de una instancia ya existente.
Singleton (Instancia única): Garantiza la existencia de una única instancia para una clase y la creación de un mecanismo de acceso global a dicha instancia.
Patrones estructurales
Adapter (Adaptador): Adapta una interfaz para que pueda ser utilizada por una clase que de otro modo no podría utilizarla.
Bridge (Puente): Desacopla una abstracción de su implementación.
Composite (Objeto compuesto): Permite tratar objetos compuestos como si de un simple se tratase.
Decorator (Envoltorio): Añade funcionalidad a una clase dinámicamente.
Facade (Fachada): Provee de una interfaz unificada simple para acceder a una interfaz o grupo de interfaces de un subsistema.
Flyweight (Peso ligero): Reduce la redundancia cuando gran cantidad de objetos poseen idéntica información.
Proxy: Mantiene un representante de un objeto.
Patrones de comportamiento
Chain of Responsibility (Cadena de responsabilidad): Permite establecer la línea que deben llevar los mensajes para que los objetos realicen la tarea indicada.
Command (Orden): Encapsula una operación en un objeto, permitiendo ejecutar dicha operación sin necesidad de conocer el contenido de la misma.
Interpreter (Intérprete): Dado un lenguaje, define una gramática para dicho lenguaje, así como las herramientas necesarias para interpretarlo.
Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos independientemente de la implementación de estos.
Mediator (Mediador): Define un objeto que coordine la comunicación entre objetos de distintas clases, pero que funcionan como un conjunto.
Memento (Recuerdo): Permite volver a estados anteriores del sistema.
Observer (Observador): Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambie de estado se notifique y actualicen automáticamente todos los objetos que dependen de él.
State (Estado): Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno.
Strategy (Estrategia): Permite disponer de varios métodos para resolver un problema y elegir cuál utilizar en tiempo de ejecución.
Template Method (Método plantilla): Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos, esto permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura.
Visitor (Visitante): Permite definir nuevas operaciones sobre una jerarquía de clases sin modificar las clases sobre las que opera.
domingo, 21 de noviembre de 2010
I. Conceptos Generales
Las 4p en el proceso de desarrollo
Definición 1: Proyecto, es un esfuerzo temporal que busca movilizar una serie de recursos para obtener un producto, bien o servicio único o claramente diferenciable de otro (PMI)
Definición 2: Temporal, todo proyecto tiene un inicio y un final
Ejemplo:
Inicio: levante o captura de requisitos
Fin: producto que cumple con los requisitos del cliente
Debe existir una línea de tiempo, un horizonte del proyecto
• Movilización: define el esquema que se va a utilizar para alcanzar o conseguir el bien, producto o servicio. En ingeniería de software lo conocemos como proceso o metodología.
• Producto, bien o servicio: son las metas que se pretender alcanzar con la ejecución del proyecto.
Definición 3: Procesos, define los pasos o secuencias lógicas que se deben ejecutar para alcanzar una meta. En el caso de ingeniería de software está definida como:
Características del proceso:
- Debe tener un inicio y un final
- Todos los procesos son cíclicos o repetitivos
- Tienen unos casos establecidos o previamente definidos
- Se pueden apoyar en herramientas que faciliten la automatización
Definición 4: Producto, es una meta que se puede alcanzar
Ejemplo: ¿Qué tiene un producto software?
• Documento: especificación de requisitos.
• Documento: análisis.
• Documento: diseño.
• Código.
• Manual de usuario.
• Documento: de verificación, de pruebas
Definición 5: Personas, son el eje fundamental de los proyectos y a demás de ejecutar el proyecto permiten:
• Determinar los costos de un proyecto: los costos de un proyecto definen el aspecto monetario (económico) pero también el costo en términos de recursos.
• Determinar la viabilidad y factibilidad del proyecto. (ejemplo: los SI –sistemas de información- que ayudan a tomar decisiones)
• Determinar la calidad de los productos, bienes o servicios. Las personas realizan control de calidad, gestión de calidad y procuran una calidad total (Deming)
Clases, objetos e instancias de clases
Definición 6: Clases, es una entidad abstracta que contiene <> información propia, partes y comportamiento.
Notación:
Formato:
Class Nombre
{
Public:
Método_1();
Método_2();
Método_3();
...
Private:
Tipo de variable nombre_variable;
}
Definición 7: instanciación, de una clase es un objeto. Es un proceso mediante el cual a partir de una clase dad se obtiene un objeto particular.
Ejemplo:
Class Alumno
{
Public:
-
-
Private:
-
-
}
En C++ la instanciación se realiza por medio del operador de resolución de ámbito.
--> constructor
Class Alumno::Nombre clase()
{
Parametrizo los métodos de esta clase
...
}
Definición 8: Constructor, el objetivo fundamental del constructo es asignar memoria a un determinado método
Definición 9: Destructor, es el encargado de liberar el espacio de memoria asignado para la clase
Formato: ~nombre_clase
Definición 1: Proyecto, es un esfuerzo temporal que busca movilizar una serie de recursos para obtener un producto, bien o servicio único o claramente diferenciable de otro (PMI)
Definición 2: Temporal, todo proyecto tiene un inicio y un final
Ejemplo:
Inicio: levante o captura de requisitos
Fin: producto que cumple con los requisitos del cliente
Debe existir una línea de tiempo, un horizonte del proyecto
• Movilización: define el esquema que se va a utilizar para alcanzar o conseguir el bien, producto o servicio. En ingeniería de software lo conocemos como proceso o metodología.
• Producto, bien o servicio: son las metas que se pretender alcanzar con la ejecución del proyecto.
Definición 3: Procesos, define los pasos o secuencias lógicas que se deben ejecutar para alcanzar una meta. En el caso de ingeniería de software está definida como:
Características del proceso:
- Debe tener un inicio y un final
- Todos los procesos son cíclicos o repetitivos
- Tienen unos casos establecidos o previamente definidos
- Se pueden apoyar en herramientas que faciliten la automatización
Definición 4: Producto, es una meta que se puede alcanzar
Ejemplo: ¿Qué tiene un producto software?
• Documento: especificación de requisitos.
• Documento: análisis.
• Documento: diseño.
• Código.
• Manual de usuario.
• Documento: de verificación, de pruebas
Definición 5: Personas, son el eje fundamental de los proyectos y a demás de ejecutar el proyecto permiten:
• Determinar los costos de un proyecto: los costos de un proyecto definen el aspecto monetario (económico) pero también el costo en términos de recursos.
• Determinar la viabilidad y factibilidad del proyecto. (ejemplo: los SI –sistemas de información- que ayudan a tomar decisiones)
• Determinar la calidad de los productos, bienes o servicios. Las personas realizan control de calidad, gestión de calidad y procuran una calidad total (Deming)
Clases, objetos e instancias de clases
Definición 6: Clases, es una entidad abstracta que contiene <
Notación:
Formato:
Class Nombre
{
Public:
Método_1();
Método_2();
Método_3();
...
Private:
Tipo de variable nombre_variable;
}
Definición 7: instanciación, de una clase es un objeto. Es un proceso mediante el cual a partir de una clase dad se obtiene un objeto particular.
Ejemplo:
Class Alumno
{
Public:
-
-
Private:
-
-
}
En C++ la instanciación se realiza por medio del operador de resolución de ámbito.
--> constructor
Class Alumno::Nombre clase()
{
Parametrizo los métodos de esta clase
...
}
Definición 8: Constructor, el objetivo fundamental del constructo es asignar memoria a un determinado método
Definición 9: Destructor, es el encargado de liberar el espacio de memoria asignado para la clase
Formato: ~nombre_clase
sábado, 20 de noviembre de 2010
¡Hola Mundo!
Estimados compañeros y lectores
Bienvenidos a este Blog recopilación del curso ingeniería de software, perteneciente al programa de Ingeniería de Sistemas de la Universidad Cooperativa de Colombia seccional Popayán.
En este blog pretendemos crear un espacio de discusión para los diferentes temas que tengan relación con la ingeniería de software (temas descritos en la entrada Contenido del blog).
Esperamos que sea de su agrado e interés por las publicaciones, que serán realizadas con el mayor esmero posible.
miércoles, 17 de noviembre de 2010
Suscribirse a:
Entradas (Atom)