Saltar al contenido

Diagrama de clases mvc

Diagrama de interacción Mvc

De vez en cuando, cuando algo te impacta, realmente lo recuerdas; se destaca en tu mente como un momento “Aha”. Uno de esos momentos para mí fue cuando vi un diagrama particular “Modelo/Vista/Controlador” (MVC), y se me encendió la bombilla. Este diagrama hizo que el patrón MVC fuera muy sencillo, y nunca lo he olvidado.

Al dibujar los diagramas UML, los autores utilizan estos símbolos en lugar de los símbolos UML genéricos -una práctica que aprendí por primera vez al utilizar Rational Rose hace muchos años- y realmente ayuda a mejorar la legibilidad y la utilidad de los diagramas UML.

El segundo diagrama MVC fue el que realmente me encendió la bombilla. La columna de la izquierda de este diagrama MVC muestra las operaciones que están permitidas según las reglas MVC, y la columna de los derechos muestra los comportamientos “malos” – métodos de comunicación en sus clases que no deberían ocurrir. Aquí está el diagrama:

He descubierto que cada vez que empiezo a tomar un atajo, y hacer algo como conectar a los objetos View juntos en mis programas, una pequeña alarma empieza a sonar en mi cerebro, y esa alarma está directamente relacionada con este diagrama y estas reglas.

Mvc java ejemplo

Koch, N., Transformations Techniques in the Model-Driven Development Process of UWE, Proceeding of the 2nd International Workshop Model-Driven Web Engineering, Palo Alto (Página: 3 Año de publicación: 2006 ISBN: 1-59593- 435-9).

Bezivin, J., Hammoudi, S., Lopes, D., Jouault, F., Applying MDA approach for web service platform, In EDOC’04 preceedings of the 8th IEEE International Entreprise Distributed Object Computing Conference, pages 58-70, 2004.

Bezivin, J., Busse, S., Leicher, A., Suss, J.G, Platform Independent Model Transformation Based on TRIPLE, In Middleware’04: Proceedings of the 5th ACM/IFIP/USENIX International Conference on Middleware, pages 493- 511,2004.

T. D. Ndie, C. Tangha1, F. E. Ekwoge, MDA (Model- Driven Architecture) as a Software Industrialization Pattern: An Approach for a Pragmatic Software Factories, Journal of Software Engineering & Applications, páginas 561-571, 2010.

Distante, D., Rossi, G., Canfora, G., Modeling Business Processes in Web Applications: An Analysis Framework, en Proceedings of the 22nd Annual ACM Symposium on Applied Computing (página: 1677, año de publicación: 2007, ISBN: 1-59593-480-4).

Patrón Mvc

El reciente crecimiento de las tecnologías centradas en la interfaz de usuario ha reavivado el interés por los patrones de diseño de la capa de presentación. Se cree que uno de los patrones más citados, el Modelo-Vista-Controlador (MVC), fue diseñado por Trygve Reenskaug, un ingeniero informático noruego, mientras trabajaba en Smalltalk-80 en 1979 [1]. Posteriormente fue descrito en profundidad en el influyente libro “Design Patterns: Elements of Reusable Object-Oriented Software” [2], también conocido como el libro “Gang of Four”, en 1994. Dos años más tarde, Mike Potel, de Taligent (IBM), publicó su artículo “Model-View-Presenter (MVP) – The Taligent Programming Model for C++ and Java” [3], en el que pretendía solucionar las carencias del MVC. Desde entonces, tanto MVP como MVC han sido ampliamente adoptados por Microsoft en sus marcos Composite Application Blocks (CAB) y ASP.NET MVC.

Estos patrones y su parentesco volvieron a estar de actualidad en 2004, cuando Martin Fowler los analizó en sus artículos. Sugirió dividirlos en otros patrones más pequeños (Controlador Supervisor y Vista Pasiva), y desveló su solución a este problema en su artículo “Presentation Model (PM)” [6]. Con el lanzamiento de Windows Presentation Foundation (WPF), el nuevo término, Model-View-ViewModel, ha entrado en escena. Mencionado por primera vez por el arquitecto de WPF, John Gossman, en su blog en 2005 [7], fue descrito posteriormente por Josh Smith en el artículo de MSDN “WPF Apps with the Model-View-ViewModel Design Pattern” [8]. MVVM fue construido alrededor de la arquitectura de WPF, y encapsula elementos de los patrones de diseño MVC, MVP y PM.

Diagrama Mvc

El diseño de Open Journal Systems 2.x está fuertemente estructurado para su mantenimiento, flexibilidad y robustez. Por esta razón, puede parecer complejo cuando se aborda por primera vez. Quienes estén familiarizados con la tecnología Enterprise Java Beans de Sun o con el patrón Modelo-Vista-Controlador (MVC) notarán muchas similitudes.

Al igual que en una estructura MVC, el almacenamiento y la representación de datos, la presentación de la interfaz de usuario y el control están separados en diferentes capas. A continuación se exponen las principales categorías, ordenadas aproximadamente de “front-end” a “back-end”:

Como el sistema hace uso de la herencia y tiene convenciones de nomenclatura de clases consistentes, generalmente es fácil saber a qué categoría pertenece una clase en particular. Por ejemplo, una clase de Objeto de Acceso a Datos siempre hereda de la clase DAO, tiene un nombre de clase de la forma [Algo]DAO, y tiene un nombre de archivo de la forma [Algo]DAO.inc.php.

Los comentarios están cerrados, pero los trackbacks y pingbacks están abiertos.