Mostrando entradas con la etiqueta Diseñando Software. Mostrar todas las entradas
Mostrando entradas con la etiqueta Diseñando Software. Mostrar todas las entradas

jueves, 30 de octubre de 2014

Buenas, en la entrada de hoy hablaremos sobre el diagrama de actividades, también conocido como diagrama de flujo, es probable que usted ya lo conozca, es uno de los diagramas preferidos de la gente, aunque en lo personal concidero que para sistemas grandes este diagrama no aporta mucho, complica las cosas salvo que se lo haga muy generalizado.



El diagrama de flujos o actividades es una representación gráfica del proceso que realiza el programa, tiene una cierta cantidad de simbolos que representan situaciones posibles.
Este diagrama representa paso a paso el proceso que lleva a cabo el programa o la tarea en si a realizar.

Simbología
El diagrama comienza y finaliza con un ovalo o elipse que indica el comienzo y el final del diagrama.
Luego podemos apreciar ractángulos que representan una actividad o procedimiento.
El rombo representa una desición, una pregunta en particular y la bifurcación hacia dos posibles caminos.
El círculo representa un enlace de actividades con otras dentro de un procedimiento, el circulo puede conciderarse como un conector.
Luego se encuentran los triangulos, un triangulo boca arriba representa guardar un documento de forma temporal, mientras que el triangulo boca a bajo se refiere a guardar un documento de forma definitiva.

Hay distintos tipos de diagramas de flujo, podemos apreciar formatos verticales, horizontales o panorámicos, dependiendo de la forma en la que se establezca la disposición y el camino del diagrama.

Podemos apreciar a continuación el diagrama de flujo para un bucle For.

Un saludo y espero les haya gustado la entrada del día de hoy, pueden ver los diagramas anteriores como el diagrama de clases y el de casos de uso aquí.

miércoles, 22 de octubre de 2014

Bienvenidos lectores! hoy les traigo un paper en formato pdf relacionado con calidad en desarrollo de software, la idea de este pdf es agrupar algunas de mis entradas (quizá las más importantes) relacionadas con el hilo "El arte de programar".

Éste pdf reúne varias cosas, conceptos muy importantes a tener en cuenta, y por supuesto desde el punto de vista del software como actividad económica, agrupando las razones por las que aplicar cada criterio tanto así como una visión industrial de lo que todos conocemos como programación.

Programación como actividad económica, una visión del software como un trabajo.
Criterios de calidad, los criterios generales para medir cuándo un código es de calidad.
Calidad y balance, cuando corresponde aplicar los criterios y por qué.
Dificultades de aplicar calidad, existiendo la calidad por qué no es tan sencillo aplicarla y hay tan poco código de calidad abierto al público.
Por supuesto incluye una descripción detallada de cada criterio de calidad en particular, además una explicación extra para cada uno, y lecturas complementarias.

Recomendamos leer todo el hilo del Arte de programar (véase indice) si te gustó el pdf.

También comentamos que el próximo pdf estará relacionado con el proceso de normalización y ya se encuentra en el laboratorio de corrección de documentos, esperando los ultimos ajustes para ser publicado.


Para cerrar la entrada nos gustaría que opinara sobre ¿qué tema te gustaría que publicaramos nuevas entradas?, envía tu sugerencia a alexander171294@gmail.com, o a nuestro twitter @std_io, también puedes comentarlo en ésta entrada.

Un saludo para todos los lectores!

martes, 21 de octubre de 2014

Buenas lectores, hoy hablaremos de UML (Lenguaje Unificado de Modelado) en particular sobre el diagrama de clases. UML se divide en tres grandes grupos de diagrama (Estructura, Comportamiento, Interacción) y veremos cada diagrama de cada grupo a lo largo de las futuras entradas. En particular recomiendo leer la entrada introductoria al tema aquí.

En primera instancia tengo que aclarar que es uno de los diagramas que más me gustan y uno de los pocos que realmente utilizo, no es precisamente el primero a realizar, pero es bueno que conozcan su existencia desde el principio.

El diagrama de clases representa las clases que tendrá nuestro sistema (siempre y cuando el sistema sea orientado a objetos), creando una visión simple y sencilla de las distintas clases del sistema, podemos apreciar en la siguiente imagen extraída de wikipedia como se ve un diagrama de clases.


 Cada clase se ve representada por un recuadro el cual en su cabecera debe estar su nombre en un recuadro interno, luego en el siguiente recuadro interno se encuentra la lista de atributos de la clase, (propiedades) los cuales deben su nombre estar precedido por un + o - dependiendo si son públicos o privados, en los anteriores casos la primer letra debe estar en mayusculas, luego sigue la lista de funciones en un recuadro interno nuevo, también deben ser precedidos por un + o - dependiendo si son publicos o privados, el +/-nombre_funcion() debe tener ese formato, se deben agrupar aquellas funciones publicas por un lado y privadas por el otro escribiendo primero los púlbicos y luego los privados, lo mismo ocurre con las propiedades. De esta forma se representan las distintas clases.



Ahora veremos las relaciones que hay entre las clases y como se representan, usaremos la imagen de arriba para especificar de que hablamos.

Las clases pueden tener relaciones simples como lo vemos entre la clase universidad y trabajador, al lado de la tabla trabajador hay un 1 lo que significa que esa clase esta relacionada de forma que solo 1 de esas pueda estar relacionada con una universidad, de modo que un trabajador pueda estar relacionado con una sola universidad y no más de una. En cambio el asterisco al costado de universidad indica que en esa relación la universidad en si puede tener 0, 1 o la cantidad que sea de trabajadores, también se podría escribir 1..* lo que significaría que podría tener 1 o más trabajadores, 0..1 por lo que podría tener ninguno o un solo trabajador, etc. Para relaciones simples la dirección se indica con una flecha sobre la linea de relación.

La siguiente relación que veremos es la que indica una flecha vacía (sin relleno) como se puede apreciar entre trabajador y persona, y estudiante y persona, ambas indican una flecha hacia persona, esta relacion representa "es un" quiere decir, trabajador es una persona, estudiante es una persona, o entre doctor y trabajador, doctor es un trabajador, en este caso la dirección está indicada por la flecha vacía, también puede significar "es un tipo de".

Luego tenemos la relación "tiene un" conocida como agregación, está representada por un diamante vacío, en el diagrama podemos ver como trabajador tiene un departamento.

 Luego para continuar tenemos composición, es una relación que representa el todo/parte, podemos ver entonces como funciona en la relación departamento/universidad, todos los departamentos pertenecen a una universidad.

La flecha con la linea punteada, es una relación de dependencia donde una clase depende de la otra, como por ejemplo en la imagen doctor depende de departamento.

Eso es todo para esta entrada y espero les haya gustado, un saludo!

sábado, 22 de marzo de 2014

Para continuar con la series de entradas que iniciamos hace un tiempo del hilo de El Arte de Programar, donde hablamos de criterios de calidad, y de programación en general, hoy vamos a hablar de Ocultamiento de Información


El principio de ocultamiento de información puede ser establecido de manera informal de la siguiente manera: Toda la información acerca de un modulo debería ser privada al él, a menos que específicamente sea declarada pública.

martes, 18 de marzo de 2014

Buenas tardes a todos los lectores, ayer estaba yo en un curso en la UNICEN (Universidad del centro sede Tandil), y para mi sorpresa empezaron a discutirme que una multiplicación consumía menor tiempo de ejecución que una división.
Claro esta, e imagino que el lector comprende que no haría nunca una entrada para hablar precisamente de eso, por lo que voy a basar mi entrada en la persecutoria que tienen algunos en relación al "consumo" o mejor conocido como Eficiencia, dando algunos motivos para dejar de lado esta postura.


Vamos a hablar en la entrada de hoy precisamente del Criterio de calidad numero 6, Eficicencia.

lunes, 17 de marzo de 2014

Buenas tardes queridos lectores!!! imagino que extrañaban mis entradas sobre todo aquellas del hilo El Arte De Programar, se que hace rato no escribo y como ya me han dicho mis publicaciones se extrañan.
Se que a mas de uno le cuesta comprender muchas veces lo que escribo pero bueno, nadie dijo que sea fácil.



Hoy hablaremos sobre la abstracción, una palabra que junto con su significado desempeñan un papel muy importante a la hora de captar conceptos importantes en la programación.

miércoles, 4 de diciembre de 2013

Buenas tardes, en ésta entrada seguiremos el tema de Modularidad previamente iniciado en entradas anteriores, para poder cumplir con modularidad, es necesario cumplir ciertos criterios básicos que definen cuando una entidad de soft puede llegar a ser modular.


lunes, 2 de diciembre de 2013

Buenos días, en esta entrada hablaremos de un tema poco común de hablar y muy escuchado.
Muchos adjudican que hacen mantenimiento de software pero la mayoría en realidad usa ésta excusa para cobrar dinero, en realidad el mantenimiento de software si existe, y pocos lo tienen en cuenta.

Frecuentemente las discusiones acerca del software y la calidad del mismo solo involucran la fase de desarrollo. Pero el cuadro real es más amplio. La parte pocas veces tratada de la profesión, y casi nunca tratada en los cursos introductorios de programación es el mantenimiento .
Es una estimación amplia mente aceptada que casi el 70% de los costos del software se aplican al mantenimiento. Ninguna discusión acerca de calidad del software puede ser satisfactoria si se subestima este aspecto.

viernes, 29 de noviembre de 2013

Buenas tardes a todos, hoy traigo un PDF que resume y aclara un poco algunas de mis entradas hechas hasta este momento, es la introducción a PCM y PCMB.


En esta entrada finalizaremos con el último de los factores de calidad, tengase en cuenta, que en realidad no terminamos de hablar del tema de calidad, y ese tipo de cosas, asique pueden esperar nuevas entradas aún jejeje.

Éste criterio engloba algunos de los factores menos importantes pero que no hay que dejar de lado, tales como
Portabilidad, Verificabilidad, Integridad, Facilidad de uso.

sábado, 23 de noviembre de 2013

Buenas tardes, últimamente habrán visto mis ideas del desarrollo de componentes, muchos que no saben de lo que hablo y por qué vale la pena dirán que estoy haciendo cosas inútiles, por otra parte otros que si conocen componentes y modelos de componentes dirán que soy un estúpido por tratar de implementarlo en php.


Ambos tienen razón sobre mis ideas, pero siempre dije que php, desde un principio, no puede crear ni utilizar eficientemente un modelo de componentes, no porque los autores del lenguaje fueran ignoranetes, sino porque el objetivo de dicho lenguaje es otro. En otras palabras tengo tiempo y me tomo la idea como un juego, un juego que a la larga, quizá para mis clientes que exigen trabajos específicamente en php, resulte más varato el desarrollo de sus pedidos, aunque realmente estas ideas no son viables a nivel industria.

viernes, 15 de noviembre de 2013

Yo había mensionado que mi modelo de componentes para php aún era cutre, simple, le faltaba pulir mucho, y sigo trabajando día a día en el modelo, hoy traigo un gran cambio de estructura que implementa varios nuevos conceptos.

De la versión anterior a la actual:

- Menor dependencia del componente para con el contexto, vease por ejemplo el constructor es remplazado por un método constructor, para que el contexto no necesite obligatoriamente instanciar directamente el objeto, sino que hay un método constructor que se encarga de ello, algo así como lo que ustedes podrían pensar viendo Singleton (pero no tan así, singleton tiene otros objetivos, pero es para que se ubiquen.)
- Mecanismo de intercomunicación entre el componente y el contexto.

lunes, 11 de noviembre de 2013

Hola a todos los lectores, en ésta entrada explicaré las reglas básicas a la hora de desarrollar un componente,
Les recuerdo que como minimo deben tener buenos conocimientos de Programación Orientada a Objetos, sobre le patrón MVC y otras cosas que serán explicadas luego.
Cuando adquieran esos conocimientos podrían empezar a plantearse el desarrollo de un componente.

Hablaremos entonces sobre Components ComponentLibrary division.

Como dije en una entrada anterior, los componentes se dividen en 3 partes, en ésta entrada explicaremos la tercera división (ComponentLibrary) y su razón de existir.
Buenas, en ésta entrada explicaré las reglas básicas a la hora de desarrollar un componente,
Les recuerdo que como minimo deben tener buenos conocimientos de Programación Orientada a Objetos, sobre le patrón MVC y otras cosas que serán explicadas luego.
Cuando adquieran esos conocimientos podrían empezar a plantearse el desarrollo de un componente.

Hablaremos entonces sobre Components Interface division.

Como dije en una entrada anterior, los componentes se dividen en 3 partes, en ésta entrada explicaremos la segunda división (Interface) y su razón de existir.

sábado, 2 de noviembre de 2013

Buenas, en ésta entrada explicaré las reglas básicas a la hora de desarrollar un componente,
Les recuerdo que como minimo deben tener buenos conocimientos de Programación Orientada a Objetos, sobre le patrón MVC y otras cosas que serán explicadas luego.
Cuando adquieran esos conocimientos podrían empezar a plantearse el desarrollo de un componente.

Hablaremos entonces sobre Components Component division.

viernes, 1 de noviembre de 2013

Buenas tardes, siguiendo con mi linea de ideales de PHP Component Model, voy a hablar sobre las reglas básicas de PCM, pero antes tengo que hacer una breve reseña de la estructura general de PCM.

Hablaremos sobre los componentes, y sobre PCM y sus dos divisiones.
Esto incluye también una breve reseña de ComponentLibrarySystem.

pero antes mi texto de siempre :P

jueves, 31 de octubre de 2013

Hola, hoy presentaré una introducción a PHP Component Model, donde explayaré varias cosas, entre otras:

- ¿Cuál es la idea?
- ¿Cómo se implementa?
- Consideraciones Generales.

pero primero mi explicación de siempre:

miércoles, 30 de octubre de 2013

Buenas, hoy voy a seguir con mi idea de PHP Component Model, y voy a explicar un poco como va a estar formado el código báse y la estructura para que vallan entendiendo un poco cómo funciona.

Hablaremos sobre PCMBase.
Hablaremos sobre los requisitos de PCMBase.
y más...


martes, 29 de octubre de 2013

Buenas tardes, hoy abro una nueva sección en el blog, si ya se que hace rato no publico nada, y también soy consiente de que les debo un par de publicaciones.
Pero estuve bastante ocupado pintando mi casa, y mientras pasaba horas pintando mi casa para en el verano alquilarle a los turistas, pude madurar un par de conceptos e ideas que tenía en mente en php, además de encontrar soluciones varias a ciertos problemas y dudas que me surgían de la forma en la cual estaba programando, todos sabrán que desde hace un tiempo estoy tratando de crear código que sea altamente reusable o mejor dicho, que realmente sea reusable en php.

Desde que creé el Property en PHP (y luego creé una serie de clases para reusar luego), estuve pensando en la mejor manera de hacer código robusto y reusable en php.

Llegué a la conclusión que por las limitaciones del lenguaje, y su ideología no es posible llegar a hacer código realmente reusable, no obstante, en mi opinión se puede crear código más cercano a esta meta, y para ello estoy generando una idea sobre un modelo de componentes para php (si, como el ComponentObjectModel de microsoft).

En esta entrada daré a conocer detalles sobre el PHP Component Model y los objetivos de este proyecto.


jueves, 26 de septiembre de 2013



Hola, buenas tardes, bienvenidos a otra publicación diaria de mi blog, la idea de ésta publicación es seguir el hilo de "Diseñando Software", en la publicación del día de hoy realizaré un resumen de los conceptos generales y de los diagramas que conforman UML.

Pero antes de comenzar y como siempre voy a comentarles...

Subscribete al RSS Follow me on Twitter!