lunes, 21 de septiembre de 2009
Sistemas de Calidad
jueves, 3 de septiembre de 2009
Requisitos del software
- De datos
- De proceso
Requisitos no funcionales. Definen las cualidades generales que ha de tener el sistema al realizar su función.
- Eficiencia
- Tipos de interface
- Económicos
- Estructurales
- Políticos
- Calidad
Fuente:
Especificación de sistemas software en UML - Ernest Teniente López, Dolors Costal Costa, M. Ribera Sancho Samsó - CPET
Artefacto
Fuente:
Análisis y diseño de sistemas - Julie E. Kendall - Prentice Hall
Alta cohesión y bajo acoplamiento
Los podemos separar, aunque están íntimamente ligados, de hecho si nos esforzamos en aumentar mucho la cohesión de nuestro software, es muy posible que perjudiquemos el acoplamiento aumentándolo, y por el contrario si reducimos mucho el acoplamiento, se verá disminuida la cohesión:
Alta cohesión.
Nos dice que la información que almacena una clase debe de ser coherente y está en la mayor medida de lo posible relacionada con la clase.
- Cohesión Coincidente. El módulo realiza múltiples tareas, sin ninguna relación entre ellas.
- 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.
- Cohesión Temporal. Las tareas llevadas a cabo por un módulo tienen, como única relación el deber ser ejecutadas “al mismo tiempo”.
- 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”.
- Cohesión de Comunicación. Las tareas corresponden a una secuencia de pasos propia del “producto” y todas afectan a los mismos datos.
- 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
- 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.
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.
- Acoplamiento de Contenido. Cuando un módulo referencia directamente el contenido de otro módulo. (En lenguajes de alto nivel es muy raro)
- Acoplamiento Común. Cuando dos módulos acceden (y afectan) a un mismo valor global.
- 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.
Fuente:
Ingenieria del Software, un enfoque práctico - Roger Pressman - Mc-Graw Hill
miércoles, 2 de septiembre de 2009
Beneficios de la tecnología orientada a objetos
Estabilidad. Las clases diseñadas para una reutilización repetida se vuelven estables, de la misma manera que los microprocesadores y otros chips se hacen estables. Las aplicaciones se construyen a partir de chips de software cuando sea posible.
El diseñador piensa en términos del comportamiento de objetos y no en detalles de bajo nivel. El encapsulado oculta los detalles y hace que las clases complejas sean fáciles de utilizar. Las clases son como cajas negras; el investigador utiliza la caja negra y no ve hacia el interior de ésta. Sólo debe entender el comportamiento de la caja negra y cómo comunicarse con ella.
Se construyen clases cada vez más complejas. Se construyen clases a partir de otras clases, las cuales a su vez se integran mediante clases. Así como los bienes manufacturados se fabrican a partir de una serie de materiales de partes y subpartes ya existentes, también el software se crea mediante una serie de materiales de clases ya existentes y probadas. Esto permite construir componentes complejos de software, que a su vez se convierten en bloques de construcción de software más complejo.
Confiabilidad. Es probable que el software construido a partir de clases estables ya probadas tenga menos fallas que el software elaborado a partir de cero.
Nuevos mercados para el software. Las compañías de software deben proporcionar bibliotecas de software para áreas específicas, que se adapten con facilidad a las necesidades de la organización que las utiliza. La era de los paquetes monolíticos viene siendo reemplazada por software que incorpora clases y paquetes encapsulados por muchos proveedores distintos.
Un diseño más rápido. Las aplicaciones se crean a partir de componentes ya existentes. Muchos de los componentes están construidos de modo que se puedan adaptar para un diseño particular. Los componentes se pueden ver, adaptar y ligar entre sí en la pantalla de herramientas del CASE.
Diseño de mayor calidad. Los diseños suelen tener mayor calidad, puesto que se integran a partir de componentes probados, que han sido verificados y pulidos varias veces.
Integridad. Las estructuras de datos sólo se pueden utilizar con métodos específicos. Esto tiene particular importancia en los sistemas cliente-despachador y los sistemas distribuidos, en los que usuarios desconocidos podrían intentar el acceso al sistema.
Programación más sencilla. Los programas se conjuntan a partir de piezas pequeñas, cada una de las cuales, en general, se puede crear fácilmente. El programador crea un método para una clases a la vez. El método cambia el estado de los objetos en formas que suelen ser sencillas cuando se les considera en sí mismas.
Mantenimiento más sencillo. El programador encargado del mantenimiento cambia un método de clase a la vez. Cada clase efectúa sus funciones independientemente de las demás.
Fuente:
Análisis y Diseño Orientado a Objetos - James Martin & James J. Odell - Prentice Hall