miércoles, 23 de noviembre de 2011
Sistemas Distribuidos
Un sistema distribuido se define como una colección de computadores autónomos conectados por una red, y con el software distribuido adecuado para que el sistema sea visto por los usuarios como una única entidad capaz de proporcionar facilidades de computación. [ Colouris 1994 ]
Los sistemas distribuidos se implementan en diversas plataformas hardware, desde unas pocas estaciones de trabajo conectadas por una red de área local, hasta Internet, una colección de redes de área local y de área extensa interconectados, que en lazan millones de ordenadores.
Las aplicaciones de los sistemas distribuidos varían desde la provisión de capacidad de computo a grupos de usuarios, hasta sistemas bancarios, comunicaciones multimedia y abarcan prácticamente todas las aplicaciones comerciales y técnicas de los ordenadores. Los requisitos de dichas aplicaciones incluyen un alto nivel de fiabilidad, seguridad contra interferencias externas y privacidad de la información que el sistema mantiene. Se deben proveer accesos concurrentes a bases de datos por parte de muchos usuarios, garantizar tiempos de respuesta, proveer puntos de acceso al servicio que están distribuidos geográficamente, potencial para el crecimiento del sistema para acomodar la expansión del negocio y un marco para la integración de sistema usados por diferentes compañías y organizaciones de usuarios.
Características:
• Concurrencia.- Esta característica de los sistemas distribuidos permite que los recursos disponibles en la red puedan ser utilizados simultáneamente por los usuarios y/o agentes que interactúan en la red.
• Carencia de reloj global.- Las coordinaciones para la transferencia de mensajes entre los diferentes componentes para la realización de una tarea, no tienen una temporización general, esta más bien distribuida a los componentes.
• Fallos independientes de los componentes.- Cada componente del sistema puede fallar independientemente, con lo cual los demás pueden continuar ejecutando sus acciones. Esto permite el logro de las tareas con mayor efectividad, pues el sistema en su conjunto continua trabajando.
Los sistemas distribuidos se implementan en diversas plataformas hardware, desde unas pocas estaciones de trabajo conectadas por una red de área local, hasta Internet, una colección de redes de área local y de área extensa interconectados, que en lazan millones de ordenadores.
Las aplicaciones de los sistemas distribuidos varían desde la provisión de capacidad de computo a grupos de usuarios, hasta sistemas bancarios, comunicaciones multimedia y abarcan prácticamente todas las aplicaciones comerciales y técnicas de los ordenadores. Los requisitos de dichas aplicaciones incluyen un alto nivel de fiabilidad, seguridad contra interferencias externas y privacidad de la información que el sistema mantiene. Se deben proveer accesos concurrentes a bases de datos por parte de muchos usuarios, garantizar tiempos de respuesta, proveer puntos de acceso al servicio que están distribuidos geográficamente, potencial para el crecimiento del sistema para acomodar la expansión del negocio y un marco para la integración de sistema usados por diferentes compañías y organizaciones de usuarios.
Características:
• Concurrencia.- Esta característica de los sistemas distribuidos permite que los recursos disponibles en la red puedan ser utilizados simultáneamente por los usuarios y/o agentes que interactúan en la red.
• Carencia de reloj global.- Las coordinaciones para la transferencia de mensajes entre los diferentes componentes para la realización de una tarea, no tienen una temporización general, esta más bien distribuida a los componentes.
• Fallos independientes de los componentes.- Cada componente del sistema puede fallar independientemente, con lo cual los demás pueden continuar ejecutando sus acciones. Esto permite el logro de las tareas con mayor efectividad, pues el sistema en su conjunto continua trabajando.
Antipatron
Un antipatron del diseño es la parte inversa de lo que es un patrón, por lo tanto es un contexto que conduce a una mala solución de un problema presentado. En este contexto se prepara al diseñador para que no trabaje mediante la intuición ya que los antipatrones son documentados para que los compañeros no escojan las malas soluciones, aunque se consideran una buena practica en el diseño de programación debido a que los programadores deben de reconocer los antipatrones e identificarlos a simple vista para evitarlos en el ciclo de formación del software. El concepto se puede aplicar en el área de la ingeniería de una manera general y de una manera u otra en todas las áreas donde se desarrolla el ser humano, aunque no es escuchada con frecuencia fuera del campo de la ingeniería.
El concepto de antipatron tuvo sus orígenes en el libro Design Patterns , donde participo Gang of Four, en este los artistas declararon dichas soluciones como patrones de diseño y describen los antipatrones como la contraparte de los patrones de diseño. Algunos de los antipatrones de gestión son : Responsable ausente , el cual es una situación donde el responsable o el principal coordinador se ausenta en un paradero desconocido, niñito de oro, es una situación donde algunas responsabilidades recaen en manos de miembros del grupo por medio de relaciones personales ,gestor pero no líder es una situación en el que existe un coordinador de cualidades brillantes pero sin don de liderazgo , las estrellas nacientes, es aplicado a personas que tienen un amplio potencial en el desarrollo del trabajo. Otros son recién llegados, ejecutivos sin carácter, arma definitiva, pollo sin cabeza, rodeos improductivos, negociador de jaula de acero, entre otras. Otros antipatrones están dedicados a la gestión de proyectos, el diseño de software, diseño orientado a objetos, programación, gestión de la configuración, entre otras áreas del diseño de la programación.
Al documentarse los antipatrones, además de los patrones de diseño, se dan argumentos a los diseñadores de sistemas para no escoger malos caminos, partiendo de documentación disponible en lugar de simplemente la intuición.
Los antipatrones se consideran una parte importante de una buena práctica de programación. Es decir, un buen programador procurará evitar los antipatrones siempre que sea posible, lo que requiere su reconocimiento e identificación tan pronto como sea posible, dentro del ciclo de vida del software.
El concepto de antipatrón se puede aplicar a la ingeniería en general, e incluso a cualquier tarea realizada por el hombre. Aunque no se escucha con frecuencia fuera del campo ingenieril, la noción está ampliamente extendida.
El concepto de antipatron tuvo sus orígenes en el libro Design Patterns , donde participo Gang of Four, en este los artistas declararon dichas soluciones como patrones de diseño y describen los antipatrones como la contraparte de los patrones de diseño. Algunos de los antipatrones de gestión son : Responsable ausente , el cual es una situación donde el responsable o el principal coordinador se ausenta en un paradero desconocido, niñito de oro, es una situación donde algunas responsabilidades recaen en manos de miembros del grupo por medio de relaciones personales ,gestor pero no líder es una situación en el que existe un coordinador de cualidades brillantes pero sin don de liderazgo , las estrellas nacientes, es aplicado a personas que tienen un amplio potencial en el desarrollo del trabajo. Otros son recién llegados, ejecutivos sin carácter, arma definitiva, pollo sin cabeza, rodeos improductivos, negociador de jaula de acero, entre otras. Otros antipatrones están dedicados a la gestión de proyectos, el diseño de software, diseño orientado a objetos, programación, gestión de la configuración, entre otras áreas del diseño de la programación.
Al documentarse los antipatrones, además de los patrones de diseño, se dan argumentos a los diseñadores de sistemas para no escoger malos caminos, partiendo de documentación disponible en lugar de simplemente la intuición.
Los antipatrones se consideran una parte importante de una buena práctica de programación. Es decir, un buen programador procurará evitar los antipatrones siempre que sea posible, lo que requiere su reconocimiento e identificación tan pronto como sea posible, dentro del ciclo de vida del software.
El concepto de antipatrón se puede aplicar a la ingeniería en general, e incluso a cualquier tarea realizada por el hombre. Aunque no se escucha con frecuencia fuera del campo ingenieril, la noción está ampliamente extendida.
conceptos
UML: es un conjunto de herramientas, que permite modelar (analizar y diseñar) sistemas orientados a objetos.
OMG: El Object Management Group u OMG (de sus siglas en inglés Grupo de Gestión de Objetos) es un consorcio dedicado al cuidado y el establecimiento de diversos estándares de tecnologías orientadas a objetos, tales como UML, XMI, CORBA. Es una organización sin ánimo de lucro que promueve el uso de tecnología orientada a objetos mediante guías y especificaciones para las mismas. El grupo está formado por diversas compañias y organizaciones con distintos privilegios dentro de la misma.
- OOSAD: Object-Oriented Systems Analysis and Design, que los modelos de enfoque de un sistema como un grupo de interacción de objetos . Cada objeto representa una entidad de interés en el sistema que se modela y se caracteriza por su clase, su estado (elementos de datos), y su comportamiento.
OOSE: Object-Oriented Software Engineering (OOSE) es una técnica de diseño de software que se utiliza en el diseño de software de programación orientada a objetos. OOSE es desarrollado por Ivar Jacobson en 1992. OOSE es la primera metodología orientada a objetos de diseño que emplea a los casos de uso en el diseño de software.OOSE es uno de los precursores del Lenguaje de Modelado Unificado (UML), como Booch y OMT.Se incluye un requisitos, un análisis, un diseño, implementación y un modelo de prueba. Los diagramas de interacción son similares a los diagramas de secuencia UML. Diagramas de transición de estado son como los diagramas de estados UML.
.
OOP: La programación orientada a objetos o POO (OOP según sus siglas en inglés) es un paradigma de programación que usa objetos y sus interacciones, para diseñar aplicaciones y programas informáticos. Está basado en varias técnicas, incluyendo herencia, abstracción, polimorfismo y encapsulamiento. Su uso se popularizó a principios de la década de los años 1990. En la actualidad, existe variedad de lenguajes de programación que soportan la orientación a objetos.
OMG: El Object Management Group u OMG (de sus siglas en inglés Grupo de Gestión de Objetos) es un consorcio dedicado al cuidado y el establecimiento de diversos estándares de tecnologías orientadas a objetos, tales como UML, XMI, CORBA. Es una organización sin ánimo de lucro que promueve el uso de tecnología orientada a objetos mediante guías y especificaciones para las mismas. El grupo está formado por diversas compañias y organizaciones con distintos privilegios dentro de la misma.
- OOSAD: Object-Oriented Systems Analysis and Design, que los modelos de enfoque de un sistema como un grupo de interacción de objetos . Cada objeto representa una entidad de interés en el sistema que se modela y se caracteriza por su clase, su estado (elementos de datos), y su comportamiento.
OOSE: Object-Oriented Software Engineering (OOSE) es una técnica de diseño de software que se utiliza en el diseño de software de programación orientada a objetos. OOSE es desarrollado por Ivar Jacobson en 1992. OOSE es la primera metodología orientada a objetos de diseño que emplea a los casos de uso en el diseño de software.OOSE es uno de los precursores del Lenguaje de Modelado Unificado (UML), como Booch y OMT.Se incluye un requisitos, un análisis, un diseño, implementación y un modelo de prueba. Los diagramas de interacción son similares a los diagramas de secuencia UML. Diagramas de transición de estado son como los diagramas de estados UML.
.
OOP: La programación orientada a objetos o POO (OOP según sus siglas en inglés) es un paradigma de programación que usa objetos y sus interacciones, para diseñar aplicaciones y programas informáticos. Está basado en varias técnicas, incluyendo herencia, abstracción, polimorfismo y encapsulamiento. Su uso se popularizó a principios de la década de los años 1990. En la actualidad, existe variedad de lenguajes de programación que soportan la orientación a objetos.
Biblioteca
Caso Biblioteca
• La universidad X tiene un sistema de información que le
maneja el catálogo de biblioteca y los préstamos.
• El usuario ingresa con un nombre (matrícula, # de nómina)
y contraseña (nip asignado por biblioteca).
• Puede buscar dentro del catálogo aquellos libros que le
interesan; se le despliegan los datos bibliográficos (incluida
imagen).
– Considerar que el libro no siempre está disponible: prestado, en
reparación, en encuadernación, apartado, etc.
• También se puede sacar los libros prestados
– Siempre y cuando el usuario no tenga muchas multas.
– Si los libros son de consulta, no se pueden sacar.
– El tiempo de préstamo es diferente si se trata de un alumno de
licenciatura, maestría, doctorado o un maestro.
maneja el catálogo de biblioteca y los préstamos.
• El usuario ingresa con un nombre (matrícula, # de nómina)
y contraseña (nip asignado por biblioteca).
• Puede buscar dentro del catálogo aquellos libros que le
interesan; se le despliegan los datos bibliográficos (incluida
imagen).
– Considerar que el libro no siempre está disponible: prestado, en
reparación, en encuadernación, apartado, etc.
• También se puede sacar los libros prestados
– Siempre y cuando el usuario no tenga muchas multas.
– Si los libros son de consulta, no se pueden sacar.
– El tiempo de préstamo es diferente si se trata de un alumno de
licenciatura, maestría, doctorado o un maestro.
Herencia.
Usuario
Usuario
· Alumno
1. Licenciatura
2. Maestría
3. Doctorado
· Empleado
1. Profesor
· Préstamo
1. Licenciatura
2. Maestría
3. Doctorado
4. Maestro
Realizado por:
Ana Lucia Macias Ortiz
Sofia Carolina Rosas Vazquez
Ana Lucia Macias Ortiz
Sofia Carolina Rosas Vazquez
Diagramas UML
Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.
Herramientas UML
Pero volviendo a la definición de UML como "conjunto de herramientas", si nos imaginamos UML como una caja de herramientas con su martillo, destornillador, alicates, etc. Veamos qué contiene nuestra caja de herramientas:
Diagrama de casos de uso
Diagrama de clases
Diagrama de estados
Diagrama de secuencias
Diagrama de actividades
Diagrama de colaboraciones
Diagrama de componentes
Diagrama de distribución
Pero siguiendo con la analogía, si vamos a colgar un cuadro no usaremos todas las herramientas de nuestra caja, posiblemente sólo usemos el martillo para clavar el clavo.
Lo mismo pasa con UML, una vez que conozcamos las herramientas usaremos en cada momento las más adecuadas a nuestras necesidades. Nos os voy a decir que esto sea fácil, pues hay que saber para qué sirven y qué limitaciones tienen unas y otras para conocer su utilidad. Pero se puede alcanzar este conocimiento con un poco de práctica y sentido común.
¿Qué no es UML?
UML no es un método de desarrollo. No te va a decir cómo pasar del análisis al diseño y de este al código. No son una serie de pasos que te llevan a producir código a partir de unas especificaciones.
UML al no ser un método de desarrollo es independiente del ciclo de desarrollo que vayas a seguir, puede encajar en un tradicional ciclo en cascada, o en un evolutivo ciclo en espiral o incluso en los métodos ágiles de desarrollo.
http://www.ingenierosoftware.com/analisisydiseno/uml.php
http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado
Herramientas UML
Pero volviendo a la definición de UML como "conjunto de herramientas", si nos imaginamos UML como una caja de herramientas con su martillo, destornillador, alicates, etc. Veamos qué contiene nuestra caja de herramientas:
Diagrama de casos de uso
Diagrama de clases
Diagrama de estados
Diagrama de secuencias
Diagrama de actividades
Diagrama de colaboraciones
Diagrama de componentes
Diagrama de distribución
Pero siguiendo con la analogía, si vamos a colgar un cuadro no usaremos todas las herramientas de nuestra caja, posiblemente sólo usemos el martillo para clavar el clavo.
Lo mismo pasa con UML, una vez que conozcamos las herramientas usaremos en cada momento las más adecuadas a nuestras necesidades. Nos os voy a decir que esto sea fácil, pues hay que saber para qué sirven y qué limitaciones tienen unas y otras para conocer su utilidad. Pero se puede alcanzar este conocimiento con un poco de práctica y sentido común.
¿Qué no es UML?
UML no es un método de desarrollo. No te va a decir cómo pasar del análisis al diseño y de este al código. No son una serie de pasos que te llevan a producir código a partir de unas especificaciones.
UML al no ser un método de desarrollo es independiente del ciclo de desarrollo que vayas a seguir, puede encajar en un tradicional ciclo en cascada, o en un evolutivo ciclo en espiral o incluso en los métodos ágiles de desarrollo.
http://www.ingenierosoftware.com/analisisydiseno/uml.php
http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado
Patrones de Diseño
Un patrón describe un problema que ocurre de forma repetida y sin parar… y después describe la base de la solución a ese problema, de una manera tal que uno puede utilizar esta solución un millón de veces.
Un patrón de diseño (en programación orientada a objetos, POO) es una descripción de diversos objetos y clases preparados para resolver un problema de diseño general aplicado a un contexto específico. Un patrón de diseño identifica las instancias y clases que participan en dicho patrón además de sus papeles, sus relaciones y sus responsabilidades para llevar a cabo la tarea a resolver. Cada patrón de diseño se centra en resolver un problema particular en la POO. Describe cuando se puede aplicar, si puede ser aplicado desde el punto de vista de las limitaciones del diseño y las consecuencias tanto positivas como negativas que tiene su utilización.
parámetros que se emplean para describir los patrones de diseño:
Nombre del patrón y clasificación, intención (¿Que hace este patrón?) ,otros nombres por los que también es conocido, motivación (escenario que ilustra su funcionamiento), aplicabilidad (en que escenarios es válido), estructura (representación gráfica de las clases involucradas y diagramas de interacción para ilustrar secuencias de peticiones y colaboraciones entre objetos), participantes (clases, objetos y sus responsabilidades), colaboraciones (como los participantes pueden colaborar en sus responsabilidades), consecuencias (¿Cómo el patrón realiza su cometido?¿Cuales son los compromisos a tener en cuenta al aceptar esta solución?), implementación (dificultades, riesgos, pistas o técnicas a tener en cuenta a la hora de implementar el patrón), ejemplo de código, usos conocidos y patrones relacionados.
http://www.novanebula.net/blog/archives/151-Patrones-de-diseno.html
http://www.minid.net/2006/01/02/patrones-de-diseno/
http://es.wikipedia.org/wiki/Patrón_de_diseño
Un patrón de diseño (en programación orientada a objetos, POO) es una descripción de diversos objetos y clases preparados para resolver un problema de diseño general aplicado a un contexto específico. Un patrón de diseño identifica las instancias y clases que participan en dicho patrón además de sus papeles, sus relaciones y sus responsabilidades para llevar a cabo la tarea a resolver. Cada patrón de diseño se centra en resolver un problema particular en la POO. Describe cuando se puede aplicar, si puede ser aplicado desde el punto de vista de las limitaciones del diseño y las consecuencias tanto positivas como negativas que tiene su utilización.
parámetros que se emplean para describir los patrones de diseño:
Nombre del patrón y clasificación, intención (¿Que hace este patrón?) ,otros nombres por los que también es conocido, motivación (escenario que ilustra su funcionamiento), aplicabilidad (en que escenarios es válido), estructura (representación gráfica de las clases involucradas y diagramas de interacción para ilustrar secuencias de peticiones y colaboraciones entre objetos), participantes (clases, objetos y sus responsabilidades), colaboraciones (como los participantes pueden colaborar en sus responsabilidades), consecuencias (¿Cómo el patrón realiza su cometido?¿Cuales son los compromisos a tener en cuenta al aceptar esta solución?), implementación (dificultades, riesgos, pistas o técnicas a tener en cuenta a la hora de implementar el patrón), ejemplo de código, usos conocidos y patrones relacionados.
http://www.novanebula.net/blog/archives/151-Patrones-de-diseno.html
http://www.minid.net/2006/01/02/patrones-de-diseno/
http://es.wikipedia.org/wiki/Patrón_de_diseño
martes, 15 de noviembre de 2011
jueves, 3 de noviembre de 2011
Patrones de Diseño
Los patrones de diseño que yo pienso que pudieran quedar con mi proyecto son:
- Observador: este seria un patron ya que para ver las puntuaciones finales necesita tener los otros puntajes.
Fábrica Abstracta [Creacional] “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. En mi programa seria al momento de las diferentes tipos de puntajes pero aun asi del mismo tipo
El patrón de diseño State se utiliza cuando el comportamiento de un objeto cambia dependiendo del estado del mismo, este seria para definir los estados de en progreso, nada y acabada.
Herencia en mi proyecto
La herencia de mi proyecto se aplicaría según yo en tres casos especiales:
- Primero en la sección de junta de jefas pues de ahí se crea o se hacen submenús que seria junta de jefas en la mañana y junta de jefas con el material y se eliminase el apartado de junta de jefas se perdería toda
- Luego se notaría en asistencia porque de la asistencia se deriva dependiendo de las insignias que las niñas tienen y de si el eslabón trae o no distintivos
- Y al final sería en Técnica, osea en la construcción porque de ahí se necesitan los demás aspectos como amarres buenos, amarres malos, puntos extras, estética, firmeza
miércoles, 2 de noviembre de 2011
Suscribirse a:
Entradas (Atom)