Seguridad Informática
Parece ser que la gente no sabe lo que tiene entre sus manos cuando utiliza un computador, sobre todo cuando está usando su portátil y este dispone de una conexión a una red. Y cuando se trata de una red inalámbrica la gente no ve los peligros sobre todo si no se cuenta con una buena protección.
Se puede pensar que soy un poco alarmista con esto de la seguridad en nuestros equipos de computo, pero es que de verdad hay que prestar mucha atención. Hoy por ejemplo estaba en la biblioteca de la universidad, donde hay una red inalámbrica disponible para todo el personal que estudia i/o trabaja en esta; estaba conectado a esta red y me he dado cuenta de que había un montón de portátiles conectados.
Entonces esto me llevó a una reflexión, que en sitios públicos específicos como café internet o bibliotecas las personas no son consientes de lo vulnerables que son; se puede hacer un rastreo entre todos los computadores de la red para ver si había "algo" disponible.
Pues bien, se cuenta con muchos computadores que consiente o inconscientemente comparten cosas con los otros usuarios. Entonces se puede pensar que esto sería una situación normal el poder ver todo el contenido de un PC, y sin ningún esfuerzo se puede acceder al disco duro, y también se puede ver los documentos, información privada, canciones, videos, fotos, etc.
Ya en el campo laboral, la seguridad informática es implementada de manera global, es decir el negocio como tal se encarga de la autenticación, control de acceso, confidencialidad, integridad, disponibilidad y la privacidad.
Y los procesos de negocios, consiste en que cada negocio se acomoda de acuerdo a las políticas internas que maneja, como negocio; es decir, un ejemplo de esto puede ser SAP, en la compañía se cuenta con una línea base de seguridad que lo establece el sistema en conjunto con la compañía, es una línea en la cual se estipulan todos los requerimientos que SAP necesita para que se ejecuten todos los módulos, o sea contar con una antivirus eficiente, un sistema operativo base, una infraestructura que soporte el montaje de este sistema.
Ya la parte de permisos, control de acceso, etc lo establece cada negocio.
lunes, 31 de mayo de 2010
jueves, 18 de febrero de 2010
HISTORIA DE LOS SISTEMAS EXPERTOS (XP)
Sus inicios datan a mediados de los años sesenta. Durante esta década los investigadores Alan Newell y Herbert Simon desarrollaron un programa llamado GPS (General Problem Solver; solucionador general de problemas). Podía trabajar con criptoaritmética, con las torres de Hanoi y con otros problemas similares. Lo que no podía hacer el GPS era resolver problemas del mundo real, tales como un diagnóstico médico.
A partir de 1965, un equipo dirigido por Edward Feigenbaum, comenzó a desarrollar SE utilizando bases de conocimiento definidas minuciosamente. Dos años más tarde se construye DENDRAL, el cual es considerado como el primer SE.
En la década de los ochenta se ponen de moda los SE, numerosas empresas de alta tecnología investigan en este área de la inteligencia artificial, desarrollando SE para su comercialización. Se llega a la conclusión de que el éxito de un SE depende casi exclusivamente de la calidad de su base de conocimiento. El inconveniente es que codificar la pericia de un experto humano puede resultar difícil, largo y laborioso.
Algunos Diagramas UML
(www.omg.org/UML)
Diagramas de Casos de Uso: Este diagrama describe lo que hace un sistema desde el punto de vista de un observador externo, debido a esto, un diagrama de este tipo generalmente es de los más sencillos de interpretar en UML, ya que su razón de ser se concentra en un Que hace el sistema, a diferencia de otros diagramas UML que intentan dar respuesta a un Como logra su comportamiento el sistema.
Un Caso de Uso esta muy relacionado con lo que pudiera ser considerado un escenario en el sistema, esto es, lo que ocurre cuando alguien interactúa con el sistema: "Acude un mesero a colocar la orden, la orden es tomada por el cocinero, y posteriormente se abona a la cuenta del cliente el cargo".
Un Caso de Uso es empleado con más frecuencia en alguna de las siguientes etapas :
•Determinación de Requerimientos:Por lo general nuevos de requerimientos sistema generan nuevos usos-casos, conforme es analizado y diseñado el sistema.
•Comunicación con el Cliente: Debido a la sencillez de este tipo de diagramas, son fáciles de emplear para comunicarse con el cliente final del proyecto.
•Generación de pruebas de Sistemas: A través de los diagramas uso-caso se pueden generar una serie de pruebas de sistema.
En la siguiente sección se describen los diversos elementos que componen este diagrama.
•Actor: Un actor representa quien o que inicia una acción dentro del sistema, en otras palabras, es simplemente un rol que es llevado acabo por una persona o cosa. Un Actor en un diagrama Caso de Uso es representado por una figura en forma de persona.
•Caso de Uso: El caso de uso en sí es representado por un ovalo que describe la funcionalidad a grosso modo que se requiere por el sistema.
•Comunicación: Este elemento representa la relación que existe entre un Caso de Uso y un Actor, dicho elemento es representado simplemente por una línea recta que se extiende de la figura del actor hacia el ovalo del caso de uso.
•Limite de Sistema (System Boundry): Empleado para delimitar los limites del sistema, y representado por un rectángulo con color de fondo distintivo.
•Generalización : Una generalización indica que un caso de uso (ovalo) es un caso especial de otro caso, en otros términos, representa una relación padre-hijo, donde el hijo puede ser suplido directamente por el padre en cualquier momento. Este elemento es representado por una línea con flecha que se extiende del caso de uso hijo hacia el uso caso padre (general).
•Inclusión : Una inclusión es utilizada para indicar que un caso de uso (ovalo) depende de otro caso, dicho de otra manera, significa que la funcionalidad de determinado caso se requiere para realizar las tareas de otro. Este elemento es representado por una línea punteada con flecha y comentario <> que se extiende del caso de uso base hacia el uso caso de inclusión.
•Extensión : Una extensión representa una variación de un caso de uso a otro, aunque similar a una generalización, una extensión representa una dependencia especifica, mientras una generalización no implica que los casos de usos dependen uno del otro. Este elemento es representado por una línea punteada con flecha y comentario <> que origina del caso de uso base hacia el caso de uso de extensión.
Diagramas de Actividades
Un diagrama de Actividad demuestra la serie de actividades que deben ser realizadas en un caso de uso, así como las distintas rutas que pueden irse desencadenando en el caso de uso.
Es importante recalcar que aunque un diagrama de actividad es muy similar en definición a un diagrama de flujo (típicamente asociado en el diseño de Software), estos no son lo mismo. Un diagrama de actividad es utilizado en conjunción de un diagrama caso de uso para auxiliar a los miembros del equipo de desarrollo a entender como es utilizado el sistema y como reacciona en determinados eventos. Lo anterior, en contraste con un diagrama de flujo que ayuda a un programador a desarrollar código a través de una descripción lógica de un proceso. Se pudiera considerar que un diagrama de actividad describe el problema, mientras un diagrama de flujo describe la solución.
En la siguiente sección se describen los diversos elementos que componen este diagrama.
•Inicio: El inicio de un diagrama de actividad es representado por un círculo de color negro sólido.
•Actividad : Una actividad representa la acción que será realizada por el sistema la cual es representada dentro de un ovalo.
•Transición: Una transición ocurre cuando se lleva acabo el cambio de una actividad a otra, la transición es representada simplemente por una línea con una flecha en su terminación para indicar dirección.
•Ramificación (Branch) : Una ramificación ocurre cuando existe la posiblidad que ocurra más de una transición (resultado) al terminar determinada actividad. Este elemento es representado a través de un rombo.
•Unión (Merge) : Una unión ocurre al fusionar dos o más transiciones en una sola transición o actividad.Este elemento también es representado a través de un rombo.
•Expresiones Resguardadas (Guard Expressions) : Una expresió resguardada es utilizada para indicar una descripción explicita acerca de una transición. Este tipo de expresión es reprsentada mediante corchetes ([...] y es colocada sobre la linea de transición.
•Fork : Un fork representa una necesidad de ramificar una transición en más de una posibilidad. Aunque similar a una ramificación (Branch) la diferencia radica en que un fork representa más de una ramificación obligada, esto es, la actividad debe proceder por ambos o más caminos, mientras que una ramificación (Branch) representa una transición u otra para la actividad (como una condicional). Un fork es representado por una línea negra solida, perpendicualar a las líneas de transición .
•Join : Una join ocurre al fusionar dos o más transiciones provenientes de un fork, y es empleado para dichas transiciones en una sola,tal y como ocurria antes de un fork .Un fork es representado por una línea negra solida, perpendicualar a las líneas de transición .
•Fin : El fin de un diagrama de actividad es representado por un círculo, con otro circulo concentrico de color negro sólido.
•Canales (Swimlanes) : En determinadas ocasiones ocurre que un diagrama de actividad se expanda a lo largo de más de un entidad o actor, cuando esto ocurre el diagrama de actividad es particionada en canales (swimlines), donde cada canal representa la entidad o actor que esta llevando acabo la actividad.
Diagramas de Clases
Un diagrama de Clases representa las clases que serán utilizadas dentro del sistema y las relaciones que existen entre ellas.
Los diagramas de Clases por definición son estáticos, esto es, representan que partes interactúan entre sí.
Diagramas de Casos de Uso: Este diagrama describe lo que hace un sistema desde el punto de vista de un observador externo, debido a esto, un diagrama de este tipo generalmente es de los más sencillos de interpretar en UML, ya que su razón de ser se concentra en un Que hace el sistema, a diferencia de otros diagramas UML que intentan dar respuesta a un Como logra su comportamiento el sistema.
Un Caso de Uso esta muy relacionado con lo que pudiera ser considerado un escenario en el sistema, esto es, lo que ocurre cuando alguien interactúa con el sistema: "Acude un mesero a colocar la orden, la orden es tomada por el cocinero, y posteriormente se abona a la cuenta del cliente el cargo".
Un Caso de Uso es empleado con más frecuencia en alguna de las siguientes etapas :
•Determinación de Requerimientos:Por lo general nuevos de requerimientos sistema generan nuevos usos-casos, conforme es analizado y diseñado el sistema.
•Comunicación con el Cliente: Debido a la sencillez de este tipo de diagramas, son fáciles de emplear para comunicarse con el cliente final del proyecto.
•Generación de pruebas de Sistemas: A través de los diagramas uso-caso se pueden generar una serie de pruebas de sistema.
En la siguiente sección se describen los diversos elementos que componen este diagrama.
•Actor: Un actor representa quien o que inicia una acción dentro del sistema, en otras palabras, es simplemente un rol que es llevado acabo por una persona o cosa. Un Actor en un diagrama Caso de Uso es representado por una figura en forma de persona.
•Caso de Uso: El caso de uso en sí es representado por un ovalo que describe la funcionalidad a grosso modo que se requiere por el sistema.
•Comunicación: Este elemento representa la relación que existe entre un Caso de Uso y un Actor, dicho elemento es representado simplemente por una línea recta que se extiende de la figura del actor hacia el ovalo del caso de uso.
•Limite de Sistema (System Boundry): Empleado para delimitar los limites del sistema, y representado por un rectángulo con color de fondo distintivo.
•Generalización : Una generalización indica que un caso de uso (ovalo) es un caso especial de otro caso, en otros términos, representa una relación padre-hijo, donde el hijo puede ser suplido directamente por el padre en cualquier momento. Este elemento es representado por una línea con flecha que se extiende del caso de uso hijo hacia el uso caso padre (general).
•Inclusión : Una inclusión es utilizada para indicar que un caso de uso (ovalo) depende de otro caso, dicho de otra manera, significa que la funcionalidad de determinado caso se requiere para realizar las tareas de otro. Este elemento es representado por una línea punteada con flecha y comentario <
•Extensión : Una extensión representa una variación de un caso de uso a otro, aunque similar a una generalización, una extensión representa una dependencia especifica, mientras una generalización no implica que los casos de usos dependen uno del otro. Este elemento es representado por una línea punteada con flecha y comentario <
Diagramas de Actividades
Un diagrama de Actividad demuestra la serie de actividades que deben ser realizadas en un caso de uso, así como las distintas rutas que pueden irse desencadenando en el caso de uso.
Es importante recalcar que aunque un diagrama de actividad es muy similar en definición a un diagrama de flujo (típicamente asociado en el diseño de Software), estos no son lo mismo. Un diagrama de actividad es utilizado en conjunción de un diagrama caso de uso para auxiliar a los miembros del equipo de desarrollo a entender como es utilizado el sistema y como reacciona en determinados eventos. Lo anterior, en contraste con un diagrama de flujo que ayuda a un programador a desarrollar código a través de una descripción lógica de un proceso. Se pudiera considerar que un diagrama de actividad describe el problema, mientras un diagrama de flujo describe la solución.
En la siguiente sección se describen los diversos elementos que componen este diagrama.
•Inicio: El inicio de un diagrama de actividad es representado por un círculo de color negro sólido.
•Actividad : Una actividad representa la acción que será realizada por el sistema la cual es representada dentro de un ovalo.
•Transición: Una transición ocurre cuando se lleva acabo el cambio de una actividad a otra, la transición es representada simplemente por una línea con una flecha en su terminación para indicar dirección.
•Ramificación (Branch) : Una ramificación ocurre cuando existe la posiblidad que ocurra más de una transición (resultado) al terminar determinada actividad. Este elemento es representado a través de un rombo.
•Unión (Merge) : Una unión ocurre al fusionar dos o más transiciones en una sola transición o actividad.Este elemento también es representado a través de un rombo.
•Expresiones Resguardadas (Guard Expressions) : Una expresió resguardada es utilizada para indicar una descripción explicita acerca de una transición. Este tipo de expresión es reprsentada mediante corchetes ([...] y es colocada sobre la linea de transición.
•Fork : Un fork representa una necesidad de ramificar una transición en más de una posibilidad. Aunque similar a una ramificación (Branch) la diferencia radica en que un fork representa más de una ramificación obligada, esto es, la actividad debe proceder por ambos o más caminos, mientras que una ramificación (Branch) representa una transición u otra para la actividad (como una condicional). Un fork es representado por una línea negra solida, perpendicualar a las líneas de transición .
•Join : Una join ocurre al fusionar dos o más transiciones provenientes de un fork, y es empleado para dichas transiciones en una sola,tal y como ocurria antes de un fork .Un fork es representado por una línea negra solida, perpendicualar a las líneas de transición .
•Fin : El fin de un diagrama de actividad es representado por un círculo, con otro circulo concentrico de color negro sólido.
•Canales (Swimlanes) : En determinadas ocasiones ocurre que un diagrama de actividad se expanda a lo largo de más de un entidad o actor, cuando esto ocurre el diagrama de actividad es particionada en canales (swimlines), donde cada canal representa la entidad o actor que esta llevando acabo la actividad.
Diagramas de Clases
Un diagrama de Clases representa las clases que serán utilizadas dentro del sistema y las relaciones que existen entre ellas.
Los diagramas de Clases por definición son estáticos, esto es, representan que partes interactúan entre sí.
lunes, 15 de febrero de 2010
Lenguaje de Modelado Unificado (UML)
Los tiempos han cambiado y las necesidades también. El trabajo colaborativo, el aumento de los estándares, las grandes cantidades de información, y los infinitos niveles de jerarquía en cualquier organización empezaron a dar vida al viejo Diagrama de Flujo el cual al fin y al cabo sólo era rombos, líneas y rectángulos.
El satisfacer estas necesidades condujo a la creación de un estándar internacional para el año 2005, el Lenguaje de Modelado Unificado, o mejor conocido como UML.
UML son los mismos diagramas de flujo pero llevados a un lenguaje que represente en forma de
código lo que solíamos ver en forma de imágenes. Evidentemente el objetivo de UML es: organizar y representar.
Opinión Personal
En mi opinión personal hay un gran “depende de”, pero vayamos a lo concreto: evidentemente un lápiz y un papel serán mucho más efectivos que un complejo diagrama UML si lo que vas es a planificar.
Pero si hablamos de planificar la estructura, con cientos de módulos que interactúan entre sí, decenas de programadores responsables involucrados, complejos modelos de datos y donde cada dependencia tenga determinado un nivel de acceso a este gran mega diagrama. Entonces sin UML no podrías sobrevivir.En países como USA, Japón y Canadá, es notorio como las demandas de empleo incluyen el dominio de UML dentro de sus requerimientos; y es que hablamos de: trabajar en equipo, reducir el tiempo de desarrollo, reducir los errores y por sobre todo: dejar en claro el mensaje: “esto es lo que el sistema debe hacer.
El satisfacer estas necesidades condujo a la creación de un estándar internacional para el año 2005, el Lenguaje de Modelado Unificado, o mejor conocido como UML.
UML son los mismos diagramas de flujo pero llevados a un lenguaje que represente en forma de
código lo que solíamos ver en forma de imágenes. Evidentemente el objetivo de UML es: organizar y representar.
Opinión Personal
En mi opinión personal hay un gran “depende de”, pero vayamos a lo concreto: evidentemente un lápiz y un papel serán mucho más efectivos que un complejo diagrama UML si lo que vas es a planificar.
Pero si hablamos de planificar la estructura, con cientos de módulos que interactúan entre sí, decenas de programadores responsables involucrados, complejos modelos de datos y donde cada dependencia tenga determinado un nivel de acceso a este gran mega diagrama. Entonces sin UML no podrías sobrevivir.En países como USA, Japón y Canadá, es notorio como las demandas de empleo incluyen el dominio de UML dentro de sus requerimientos; y es que hablamos de: trabajar en equipo, reducir el tiempo de desarrollo, reducir los errores y por sobre todo: dejar en claro el mensaje: “esto es lo que el sistema debe hacer.
Suscribirse a:
Entradas (Atom)
