Development of a Pharmacy Management Application using ..., Exams of Pharmacy

Download Development of a Pharmacy Management Application using ... and more Exams Pharmacy in PDF only on Docsity! 2005:181 CIV MASTER'S THESIS UL Development of a Pharmacy Management Application using the Framework MSTORE Javier Gonzalez Pisano Lulea University of Technology MSc Programmes in Engineering Computer Science and Engineering Department of Computer Science and Electrical Engineering Division of Computer Science 2005:181 CIV - ISSN: 1402-1617 - ISRN: LTU-EX--05/181--SE Development of a Pharmacy Management Application using the framework MSTORE Javier Gonzalez Pisano Lulea University of Technology May 2005 Supervisors: Aquilino Juan De La Fuente (Oviedo University) Kare Synnes (Lulea University of Technology) Abstract in Spanish Introduccion El proyecto que se ha realizado forma parte de un programa de creacién de componentes software desarrollado en la Universidad de Oviedo con el objetivo de facilitar a las PYMES (Pequefias y Medianas empresas) con herramientas software viables que permitan su modernizaci6n, pudiendo asi reducir costes y competir con almacenes con mayores recursos. El programa esta compuesto por varios proyectos: Gestién de Documentos, Gestién de Riesgos 0 el que se va a explicar en este documento: Gestion de Almacenes. Dada la extensién del proyecto se decidiéd a su comienzo dividirlo en dos, delimitando las partes que incluirfa cada uno. Los dos proyectos fueron realizados paralelamente y en colaboracién, y al termino de su desarrollo se juntaron. Este documento explica como se implements una de las partes, la otra parte se puede ver en el documento “Development of a Ironmonger using the framework MSTORE”, realizado por Maria Rodriguez Fernandez. Conceptos relacionados La herramienta software que se quiere implementar va a ser definida en forma de framework [6][25]. Un framework se puede definir como una colaboracién de clases adaptables que definen una soluci6n para un problema dado. Esta colaboracién deberia: ¢ Definir las abstracciones principales y sus interfaces. e Establecer las relaciones entre los objetos. e Adaptar a soluciones particulares usando redefinicién. e Incluir alguna solucidn por defecto. Los patrones de disefio estén muy relacionados con los frameworks orientados a objetos, ya que ambos facilitan la reutilizacién capturando estrategias exitosas de desarrollo software. La mayor diferencia consiste en que los frameworks se centran en disefios concretos, mientras que los patrones constituyen disefios abstractos. Los patrones dicen cémo resolver un problema, mientras que los frameworks proporcionan una solucion para el problema. Esta ampliamente aceptada la conveniencia de documentar frameworks usando patrones [3][14]. El mayor propésito del conjunto de patrones es mostrar como usar un framework, no cémo funciona, pero los patrones pueden mostrar una gran parte del disefio. Cada patrén describe un problema comin en el dominio del problema, y a continuacién se describe como resolverlo. La documentacién de un framework tiene tres propdsitos, y los patrones pueden satisfacer los tres, ya que describen la intencién del framework, cémo usarlo y el disefio detallado de este. JHotDraw[10] es un buen ejemplo del uso de patrones para describir un framework. Se usa para el desarrollo de aplicaciones grdficas en Java, y fue documentado en términos de patrones. En JHotDraw, los patrones guiaron la estructura del disefio. Objetivo Concretando, el objetivo del proyecto es definir un framework para la gesti6n de almacenes que cualquier PYME pueda usar directamente para solucionar sus problemas concretos. El framework debe ser pues lo bastante genérico como para ser usado en distintos tipos de almacenes, teniendo en cuenta los aspectos mds importantes de este tipo de aplicaciones. Se buscard el mayor grado de flexibilidad posible, pero teniendo en cuenta que la captura de todos los aspectos posibles conllevaria un tiempo de desarrollo mucho mayor del estimado para este proyecto. Los aspectos que no se han podido recoger se tendran en cuenta en futuras versiones del mismo. El framework va a utilizar un esquema ya usado en otros frameworks como JHotDraw con beneficios probados. El disefio va a ser dividido en 3 capas con varias caracteristicas: e La primera capa, basada en interfaces, define el comportamiento basico del framework asi como sus interacciones, sin ninguna implementacidn. e La segunda capa, de clases abstractas, incluye la implementacién de cualquier comportamiento que se considere comin a todos los programas de gestién de almacenes, como por ejemplo el manejo basico del stock de los articulos o la distribucién en planta del almacén. e El tercer nivel estaré formado por la implementaci6n concreta de la solucién de un cliente con sus caracteristicas particulares: en el ejemplo el cliente podria usar la distribucién en planta que incluye el segundo nivel o modificarla de acuerdo a sus necesidades. Como el framework trata de ser lo mds genérico posible, la abstraccién de las entidades deberia ser lo mds independiente posible de cualquier detalle de implementacién. La separacion en los dos primeros niveles (interfaces y clases abstractas) facilita la diferenciaci6n del disefio del framework y su implementacién. El tercer nivel también tiene valor, ya que ademas de demostrar que el Framework funciona va a proporcionar algunos ejemplos al programador que quiera usarlo por primera vez. Requisitos Un vistazo a algunos de los programas mas usados de gestién de almacenes [2][7] y en bibliografia basica de gestién de almacenes [1][2][5] muestran los requisitos generales que deberia tener la librerfa. Esta es solo una aproximacién general, se han elaborado listas de requisitos mas detalladas que no se incluyen en esta documentaci6n: e Articulos: o Gestién del stock automatica, gestién de cddigos, modelado de articulos perecederos (con fecha de caducidad y sin fecha de caducidad), articulos gestionados por lotes, rangos, familias, cataélogos, gestién del precio y beneficios, control de unidades deterioradas, productos sustitutivos. e Entradas y salidas de productos: o Gestidn de todo lo relativo a entradas en el almacén: zonas de entrega, productos contrastados con albaranes o distribucion en las estanterias con indicacién de las rutas a usar. vi Desarrollo una farmacia usando MSTORE Tras el disefio de la libreria, se han desarrollado un par de aplicaciones usandola, demostrando asi que funciona con distintos tipos de almacenes y proporcionando ademas ejemplos al programador que quiera usarla por primera vez. En este caso la aplicacién se trata de un programa de gestién del almacén de una farmacia, con las problematicas particulares que éste puede tener. El otro proyecto paralelo se centré en la implementacién de una aplicacién de gesti6n de un almacén para una ferreteria. Se intent6 que ambas aplicaciones usaran partes distintas del framework, de manera que entre ambas le dieran la mayor cobertura posible de cara a probarlo. El resultado es que se ha probado que funciona gran parte, aunque atin hay partes pendientes de implementar o probar. A la hora de disefiar el funcionamiento de la farmacia, se observé que algunas de sus funciones podian ser completadas con el framework sin necesidad de ninguna modificacién en éste, mientras que otras necesitaban modificar el disefio existente o afiadir caracteristicas a las ya existentes. Una vez que se modificaron /ampliaron dichas caracteristicas, muchas de ellas pasaron a formar parte de una segunda version del framework mas completa. Esta es otra ventaja del desarrollo de aplicaciones usando el framework, segtin se implementan mas éstas van afiadiendo nuevas funciones y mejorando las existentes, lo que hace la libreria mas robusta y fiable. En la farmacia una de las mayores modificaciones se deriva de la necesidad de controlar la caducidad de los productos. Si bien el framework original contemplaba que hubiera productos perecederos y no perecederos, era necesario afiadir mecanismos para hacer chequeos acerca de la caducidad, para comprobar al hacer una venta si el producto ha caducado, etc. Los cambios realizados hacen que el framework no pierda genericidad (pues se hicieron con cuidado de seguir dando soporte a productos sin fecha de caducidad) pero gana flexibilidad. Otros cambios no fueron reflejados en el framework por ser detalles muy particulares de la aplicacién. Es el caso de las ventas rapidas, donde manejamos las ventas de una manera diferente a la comin en el resto de los almacenes. De todos modos, en caso de que algtin programador quisiera usar ésta caracteristica podria consultarla en la aplicacién desarrollada. Una amplia coleccién de casos de uso, diagramas de secuencia y algunas de las pantallas de la ién pueden ser vistas en los capitulos pertinentes de la documentacién. ix Tecnologias Aqui podemos ver un resumen con algunas de las tecnologias usadas a lo largo del proceso de desarrollo: Enterprise Architect es la herramienta CASE usada para el disefio del framework y las aplicaciones. El programa permite ingenieria directa e inversa para C# (lenguaje usado en la implementacién), asi como soporte pleno para UML. -NET Framework se us6 en las fases de implementacién y prueba, usando como acabo de mencionar C#. En la documentacién se incluye una pequefia comparativa entre .NET y J2EE, resaltando los puntos fuertes y débiles de ambas plataformas. Tanto el cédigo como la GUI se desarrollaron usando Microsoft Visual Studio .NET. Nhibernate fue la libreria usada para la persistencia de objetos contra una base de datos relacional. La libreria esta en fase de pruebas y dio bastantes problemas, pero se espera que préximamente ofrezca mejores prestaciones. La base de datos usada durante las pruebas fue Microsoft SQL Server. Nunit se us6 para probar las aplicaciones. Se usaron Servicios Web para hacer ptiblicas las principales funciones de las aplicaciones. Conclusiones y futuras ampliaciones Al ser una aplicacién fundamentalmente de desarrollo, no hay demasiadas conclusiones que se puedan sacar. Aqui se exponen algunas de ellas: Los patrones proporcionan un buen modo de describir los frameworks, ya que los usuarios no querrén saber exactamente como funciona, sino en cémo resolver un problema particular. Aunque los patrones y el disefio en 3 capas explicado anteriormente ofrecen te6ricamente muchos beneficios, ha sido dificil comprobarlos, ya que los creadores del framework fuimos los mismos que lo usamos por primera vez, y ya conociamos el modo de uso y funcionamiento de éste. Por tanto es necesario que futuros proyectos sean los que comprueben dichos benefici Usando MSTORE, el tiempo de desarrollo de las aplicaciones se vio decrementado en un tiempo aproximado del 50%, teniendo en cuenta que al escribir las aplicaciones también se realizaron tareas de depuracién del framework. De todos modos para realizar dicha afirmacién también seria necesario que éstas fueran desarrolladas por alguien ajeno al desarrollo de la libreria. Los patrones son una herramienta potente en adicién a un lenguaje orientado a objetos como Java o C#. Las diferencias entre ambas plataformas no son muy notables, en cualquier caso ningtin lenguaje oculta la importancia de un buen disefio. Por otra parte, los siguientes pasos en el desarrollo de MSTORE pasarian por: Reparar los posibles fallos en la implementacién actual, ampliando los servicios web ofrecidos. Desarrollo de mas aplicaciones que exploten las posibilidades de la librerfa y la amplien. Integracién con los programas paralelos desarrollados: gestién de riesgos y de documentos. Realizar pruebas con empresas reales y evaluar puntos fuertes y débiles. Table of Contents OBJETIVO... CHAPTER 1. INTRODUCTIO. 1.1 APPROACH OF THE PROBLEM 1.2 JUSTIFICATION 1.3 OBJECTIVE ..... 1.4 PROJECT SCOPE.. CHAPTER 2. ANALYSIS CHAPTER 3. | PREVIOUS STUDIES 3.1. REQUISITES OF THE SYSTEM 3.2. OBJECT ORIENTED FRAMEWORKS 3.3. JHOTDRAW.. 3.4. CONCLUSION: CHAPTER 4. FRAMEWORK DESIGN: PROBLEMS FOUND AND THEIR SOLUTIONS USING PATTERNS. .+sssesssvsssssssessssescsvevesnsaescssesesssnescenesesnsaesceseseeneaesceneseeneaesees 13 4.1 ARTICLES MANAGEMENT. 4.2 DOCUMENTS 4.3 STOCK MANAGEMENT . 4.4 STORE MANAGEMENT. 4.5 MOVEMENTS 4.6 FRAMEWORK DESIGN AND CONCLUSION CHAPTER 5. APPLICATIONS DEVELOPMENT USING MSTORE FRAMEWORK 33 5.1 COMMON TOPICS IN A STANDARD STORE MANAGEMENT APPLICATION ......:sssessesesseseseeseee 33 5.1.1 Analysis 5.1.2 Design. 5.1.3 Implementation. 5.2 PHARMACY: WORKING WITH PERISHABLE PRODUCTS. 5.2.1 Analysi 5.2.2 Design. 5.2.3 Implementation. CHAPTER 6. USED TECHNOLOGIES 6.1 .NET FRAMEWORK 6.2 NHIBERNATE. s SFSOUN WRN CHAPTER 7. CONCLUSIONS. 7.1 FUTURE PLANS REFERENCES .. APPENDICES..... I. STORAGE SYSTEMS AND PRODUCT LOCATION IN A STORE IL STOCK MANAGEMENT POLICIES xi Figure 48: Add article to entry screen... Figure 49: Set Stock Management Policy parameters screen .. Figure 50: New Output screen .. Figure 51: Pharmacy Web Servic , mainframe . Figure 52: Invocation of one method and result . Figure 71: .NET Framework Architecture... Figure 72: .NET Framework Classes Librar’ Figure 73: Visual Studio .NET appearance Figure 74: Logic behind a Web Service Figure 75: Chaotic Storage.... Figure 76: Dynamic by gravity-FIFO Figure 77: Rack List of Tables Table 1: Actors and Goals .....c.sccsecseeccesssseeseescssesseessesessessseccssssueseessesssseessescasesueecessesueseesceseaneense 33 Table 2: Manage Company Use Case Table 3: Manage Resources Use Case Table 4: Manage Transactions Use Ca Table 5: Manage Merchandise Use Case Table 6: Manage Store Use Case Table 7: Manage Users Use Cas Table 8: Log in Use Case Table 9: Log out Use Case Table 10: Pharmacy: Manage Merchandise Use Case Table 11: Pharmacy: Manage Store Use C: Table 12: Pharmacy: Manage Company Table 13: Pharmacy: Manage Statistics Use Case . Table 14: Pharmacy: Manage Articles Use Case xiv Acknowledgements We would like to express out gratitude to the following people for the support and assistance in developing of this Master Thesis: Our Supervisor in Oviedo (Spain), responsible for the idea and also Director of the entire Project that includes the rest of the modules that will work together for providing to the SMEs a good and complete tool that allow them their modernization and why not, creation of jobs in our small region. This can’t remain as a dream! Our supervisor in Luled (Sweden), thank you for listening to our ideas, reading our long (and sometimes difficult to read) reports, providing a good place to work and showing us that Swedish kindness! Our families, this time a little far from us, but always near in our feelings. Our “family” here, in Luled, which means our friends, who gave us the necessary support after the daily work. And anybody we missed who deservers a mention! Xv Xvi MSTORE Framework - Introduction PROJECT SCOPE LEVEL 0 LEVEL 1 LEVEL 2 o DEVELOPMENT mo OFUTURE WITH MSTORE 1.0 AMPLIATIONS. Figure 1: MStore project scope MSTORE Framework - Analysis Chapter 2. Analysis As it was told before, in a very high level the system should have at least the next elements: e Level 0: Interface-based framework that defines the basic behaviour of the system and its interactions without any concrete implementation. e Level 1: Basic implementation of some behaviour that is considered common to any implementation. For instance the order management politics based in different quantitative methods. e Level 2: Concrete Implementation of a client's solution with his concrete store operating policies etc. First developing level based in abstract classes that implement basic behavior and common to every application Second level of concrete implementation Figure 2: Implementation level of an application using the Framework As the framework is trying to be as generic as possible, the abstraction of the entities must be independent of any implementation detail. The separation in two levels (interfaces and abstract classes) makes easy the differentiation of the framework design and_ its implementation. The 3™ level has also value as it is going to test that the framework works, and it provides some examples to the programmer who wants to use the framework for the first time. MSTORE Framework — Previous Studies o Layout: It provides support for different types of equipment like Corridor Distribution. o Distribution: It is necessary to have some methods for locating free places in the entries, and do the symmetric process in the exits. These methods can be different depending on the zone. For example can be useful to use a FIFO method when the zone works with perishable products. o Physical Distribution: methods for making graphical representation of the store distribution. This will help the user of the future application to have control of the entire layout easily. e¢ Web services: All the main operations should have an interface as a Web Service, so that there should be done an MVC architecture that allows accessing the main application functions with different interfaces, between them the Web Services. ¢ Database management: Object-relational layer (database access broker) that encapsulates the access. In a first iteration, the simplified package diagram of the framework could be as follows: Order Management Movements Articles Product entries & leaving Store Resources Management Figure 4: Framework package diagram, first iteration The design of the framework should take into account all of these points, making the design generic enough to extend them when necessary. The reader could think that the purpose of the project is just the implementation of a standard application management application, but instead of that what is going to be built is a generic design so that the developer can change the parts of it that doesn’t like (or doesn’t fit to his necessities), and adapt in the way he wants, which is much more flexible than a single program. The characteristics and benefits of the frameworks are discussed in next section. MSTORE Framework — Previous Studies 3.2. Object Oriented Frameworks There are many ways to define a framework. One generic definition could be the following: “A framework is a reusable design of a program or a part of a program expressed as a set of classes” [6] For the problem it is tried to solve, this definition looks like more suitable: “A framework is a collaboration of adaptable classes that define a solution for a given problem” Here follows its desired characteristics: e It defines the main abstractions and their interfaces. ¢ It establishes the relationships between the objects. e The framework is adapted to particular solutions using the redefinition. e It should add any default solution. Patterns are very related with the Object Oriented Frameworks since both Patterns and Frameworks facilitate reuse by capturing successful software development strategies. The main difference is that frameworks focus on reusing concrete designs, algorithms, and implementations in a particular programming language. In contrast, patterns focus on reuse of abstract designs. The pattern says HOW solve a problem, while the framework gives a SOLUTION (or even is a solution). Some of the main benefits of Object Oriented Frameworks are explained next: [25] ¢ Modularity: Frameworks make an explicit differentiation between design and implementation using interfaces and abstract classes. The interfaces are stable, while the abstract classes encapsulate volatile implementation changes. It is also easier to calculate the cost of changing some parts of the design and the implementation, reducing the effort required to understand and maintain the software. ¢ Reusability: The interfaces define generic components that can be used to create new applications. As they are already created and validated, developers can use the previous efforts in order to create their own designs. The reusing improves the programmer productivity, as well as the quality, performance and interoperability of the software. ¢ Extensibility: A framework provides explicit hook methods that allow applications to s stable interfaces. Hook methods decouple in a systematic way the stable and behaviours of an application from the variations required by instantiations of an application in a particular context. Since a Framework is software, it is a mixture of the concrete and the abstract. And since frameworks are reusable designs, not just code, they are more abstract than most software, which makes documenting them difficult. Frameworks are designed by experts in a particular domain and then used by non-experts. The principal audience of framework documentation is someone who wants to use the framework to solve typical problems, not someone building a software cathedral. Patterns are well suited for this audience. MSTORE Framework — Previous Studies It is widely accepted the convenience of documenting frameworks with patterns [3] [14]. The main purpose of a set of patterns is to show how to use a framework, not to show how it works, but patterns can also describe a big part of the theory of its design. Each pattern describes a problem that is common in the problem domain of the framework, and then describes how to solve that problem. Each pattern has the same format. The more used format is to first give a description of the problem. This is followed by a detailed discussion of the different ways to solve the problem, with examples from other parts of the framework. The pattern ends with a summary of the solution. Patterns are problem oriented, not solution oriented. Each pattern describes how to solve a small part of the larger design problem. Sometimes the solution is to make a new subclass, sometimes it is to parameterise an object of an existing class, and sometimes it requires connecting several objects together. Documentation for a framework has three purposes, and patterns can help fulfil each of them. It must describe: v The purpose of the framework Y How to use the framework v The detailed design of the framework. Patterns are best suited for teaching how to use a framework, so a set of patterns can meet all three of these purposes for framework documentation. 3.3. JHotDraw JHotDraw [10] is a good example about of using aT _ patterns for the description of a framework. It is a ‘Fe em mem attmcs comin Aamaton imams incon highly customisable GUI framework that simplifies BIATAIBISCICISIS/sieTala) developing drawing applications. It is inspired by - HotDraw, developed by Kent Beck and Andre Winand, and it was developed by Thomas Eggenschwiler and Erich Gamma and presented in | gaps) OOPSLA9Q7. It was created for a seminary as an example of patterns application in frameworks o sel creation, but its ideas can be directly applied to @ comacta Tet professional applications. > Selaeen Figure 5: JavaDraw is a typical application of JHotDraw JHotDraw defines a basic skeleton for a GUI-based editor with tools in a tool palette, different views; user defined graphical figures and support for saving, loading and printing drawings. The framework can be customized using inheritance and combining components. Design Patterns and a programming platform like Java (and, as the reader will see later, NET also) are a very powerful combination, although no language can reduce the design importance. 10 MSTORE Framework — Framework Design Chapter 4. Framework Design: Problems found and their solutions using Patterns The general problem is to face up the management of one multi-store, which is more complex than the reader can think in a first view. But it is also very repetitive in all the stores since they usually have many things in common. It is wanted to make a general Framework called MSTORE that collects all the support, as far as possible, for making a typical store management application. Before to do this it must be raised what problems can be found, which are the possible solutions and, of course, the best solution for that problem. So there will be followed this outline in this report. Design Patterns [9] represent recurring solutions to software development problems within a particular context, and they can help us to resolve our problems. Before starting to read it is useful to know more about Design Patterns and Stores, in the References there can be found several links and books. Frameworks can be understood as a concrete reification of families of design patterns that are targeted for a particular application-domain. Likewise, design patterns can be viewed as more abstract micro-architectural elements of frameworks that document and motivate the semantics of frameworks in an effective way. When patterns are used to structure and document frameworks, nearly every class in the framework plays a well-defined role and collaborates effectively with other classes in the framework. Following chapters explain some of the problems found in the different sections of the framework and the solution given, expressed as a design pattern if that is the choice, but not always the patterns are the best solution, and in that case, there is explained the reason. Before choosing a solution, there are postponed other possible solutions and explained why the selected one is the most suitable. When the solution is obvious, there are just explained the benefits of it. Sometimes the diagram doesn’t fit 100% with the adopted solution (in order to make it more simple), but the examples are trying to reflect it as truly as possible. Some diagrams that need more explanations are also shown in the Framework Development Section. Although the Framework include more packages, in this documentation there will be only commented the most important and in our opinion, more interesting problems in an academic approach. 13 MSTORE Framework — Framework Design 4.1 Articles management PROBLEM 4.1.1; COMPOSED ARTICLE TYPES The framework that is being designed must be adaptable for all kinds of stores that can deal with a long variety of article types. For instance, simple stores will only deal with raw articles, and the merchandise they receive is the same that they are going to sell. A good example could be a simple bookshop store, where the books are received, stored and then sent away in the same shape. More complex stores are susceptible to deal both with simplex and composed articles. For instance, a computer store could want to deal only with single components (keyboards, displays, memories, etc.) or with more complex components that were created in the store (for instance the whole computer). These complex components can share some characteristics with the simple articles or can differ in others (like the price in the example). Anyway it is a good that the complex article knows all the information about the simple articles. The figure 6 illustrates the example. It is also very desirable that can be worked with both the complex and the simple articles in the same way, but adding some mechanism that allows knowing whether an article is simple or composed. One personal computer is an article also, but it is composed by other components such as mouse, keyboard, etc. One keyboard is an article. It is composed by only one simple article. Figure 6: Simple and Composed Articles example Summarizing, it is wanted the next behaviour: v The articles can be simple or many simple articles can compose them. v Itis wanted to considerer simple and composed articles in the same way. v It is wanted to access to the properties of the simple articles from the complex one. v It is wanted to have recursive composition: one complex article composed by more complex articles. SOLUTION: > Composite Pattern The Composite Pattern offers a quite-straightforward solution to the explained problem. The pattern composes objects into tree structures to represent part-whole hierarchies. It lets clients treat individual objects and composition of objects uniformly and makes easy the access from 14 MSTORE Framework — Framework Design the composed class to the simple classes, so it fulfils all the desired requirements of the solution. The key of the pattern is an abstract class that represents both primitive types and their containers (Component, as can be seen in Figure 7). The class declares operations that all Composite objects share, such as operations for accessing and managing its children, and operations that all Leaf objects share (and Composite objects also if necessary). Client Component * -Operation() +Add(in Component) }+Removerin Component) [+GatChildiin index : int) a Leaf ‘Composite dren Operation) yOperation() +Add(in Component) | +Remove(in Component) | +GetChile(in index : int) | | foreach child in children child Operation() Figure 7: Composite Pattern The application to our framework is made in the second level, as there are going to be implemented some of the operations from the Component s. The Figure 8 shows the translation into the framework classes. Not all the operations are reflected in the diagram, only a couple of operations are shown in order to illustrate the problem. Component AArticleType + IncreaseStocl{ ) + DecreaseStocl{ ) + Add (ArticleType) Leq Composite f children ASimpleArtideType AComposeArtideType + IncreaseStock( ) + IncreaseStock( ) + DecreaseStock( ) + DecreaseStock( ) + Add (ArticleType) +4Children( ) Figure 8: Composite Pattern in simple/composed articles problem 15 MSTORE Framework — Framework Design The mission of the Director class is to create the Product. For this purpose, it is going to use a Builder class that is the class in charge of really creating the Product. The Builder interface allows the creation of the different parts of the product. If different kinds of products are wanted, different kinds of builders have to be created. The pattern applied to the problem gives the next solution: eremteDocument uilder suitch(dooumertType Type Pater TICKET: { ‘ule Crest TRle Tent) ule» CrestaProduct (Product st) builder >CrestePay sy (Pay Way fo) H euDoert Director Builder ler» CrestTRleitlelnfo) buleer»CrestaProduct(Producteist) } D eS cetetaces ” ae sues DosumentBuitaler f+ Gate (ObES! : od “+ ereateCheunert (Oboe) vod ce f+ Geaterayiey(cbect) void terface aetertaces _....._& Bayings:uying SellingsSettng Shema aploable for more (conmentn terface rs sipleaen Burdgetbuilder o[ getTcheto Tet f+ getaonyeeD » acget oui Bur J+ eate le (Cbect vot ft Grate oductReconts (List : void [+ crate rayiisy(Cbec!) oid Dveument Bue 4 Geateele(Obpet) void + Grate PmductFecords(it) : vit 4 GeatePayltay(Cbect) : wok! cera Builder toon: Patern citerfacen WholeDooument iterate Documenerart Composite Pattern itera Budget itera Tioket Figure 12: Builder Pattern applied to the Document Types Management problem The Director is the class in charge of creating the document, usually a buying or a selling but it is possible that also another abstraction wants to create a document (it should always derive from the /Transaction interface). The director is going to possess a relation with the builder that is a class inheriting from the /DocumentBuilder interface. Depending on the desired document, the Director will instantiate a different concrete builder. After the creation of the builder, successive calls are made to it in order to create the parts of the document. In this 18 MSTORE Framework — Framework Design preliminary iteration, there is a Composite abstract document and the concrete documents inherit from it. Later it will be probed that this is not the best approach. This solution makes easy the variation of the document internal representation, which is very good for the documents promotion as it is easy to share a common part for some of the documents. It also makes the representation of the document independent from the construction, so the transactions don’t have to worry about how to build the document. It is also easy to create new kinds of documents. SOLUTION 2: Abstract Factory The second solution is based in the Abstract Factory Pattern. The pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes. The pattern achieves that the transactions are independent from how are the documents created, composed and represented. The structure of the pattern can be found in Figure 13. Client AbstractFactory }+CreateProductA() | }CreateProductB() rt AbstractProductA ConcreteFactory1 ConcreteFactory2 a f }+CreateProductA() [+CreateProductAt) i CreateProduci&() | +CreateProductB() ProductA ProductA2 T T T T | me ee ae ee ' ' i i I | | I ai | | ' bo J | 1 i I | I AbstractProductB | 1 | ' i I | | | ' tT ! ProductB1 Product&2 | I K------ “s re ' i ai | Figure 13: Abstract Factory Pattern Structure The AbstractFactory declares an interface for operations that create abstract product objects. The ConcreteFactory classes implement the operations defined by the interface in order to create the products. The client will use the abstract products, but the factories are going to create concrete products that are subclasses of the abstract ones. Applied to the concrete problem, the solution structure would look like the Figure 14: 19 MSTORE Framework — Framework Design interface Document { interface interface interface Header ezTO CUO SOOT) Payliay Schema applicabel for other document types interact interact interfaces wintertaces interfaces interact icseienneg Budgetteader TioketProduotRecords BudgetPraduotRecords TicketPayWay BudgetPayWay K Concrete Product interface interfaces DocumentFactory + GreateHeaden) : vad + GreateFreductRecans) : void + GreatePayitay0 wid Transzotion createDocument? : ocument| i Abstract Factory interface TicketFaotory interact Budgesractory + Greate Header) : vad + Greate FreductRecans) : void + Greate Payltay0 : wie + GreateHeader) : void + GreateFreductRecars) : void + GreatePayllay0 wid - interface interfaces Buyings:séuying Seltings::Selting To perform this operations we make use of the operations located in Buyings:Buying of Sellings:Selling Figure 14: Abstract Factory solution The DocumentFactory is the abstract factory, and it is going to be created a concrete factory for each different document that can be managed. On the other hand, some different parts will compose one document: a header, some records, the payment part, etc... Each of them will be represented by an abstract product, and will create a concrete product for each of the documents. The transaction will be the client, in charge of creating different documents. The pattern makes easy to modify the structure of the document, as it is divided in some parts. It also makes easy to share the common parts between similar documents, and then it is only needed to create the different parts. Thus, the promotion between documents is also easy. However, the pattern introduces an important bad point: it is difficult to support new kind of products, so, even if it can give flexibility, the structure of the different documents is difficult to expand. DECISION This last point is definitive in the choice of the pattern to use. The Abstract Factory looks like a more flexible and powerful option, but it makes hard the addition of new parts in the documents, feature that can not be accepted for the use of the pattern in the framework, so it was decided to use the Builder pattern, which is also a good solution, even while it doesn’t 20 MSTORE Framework — Framework Design independently from clients that use it. The pattern structure, shown in Figure 16, is simple but it makes very easy the reuse of the different strategies. Context strategy Strategy +Contextinterfacer | + Algorithminterface(}| AAA ConcreteStrategyA| |ConcreteStrategyB ConcreteStrategyC + Algorithmintarface()} |+Algorithminterfacel) }+Algorithminterface() Figure 16: Strategy Pattern structure The Context maintains a reference to a Strategy object. The Strategy declares an interface common to all supported algorithms. The Context uses this interface to call the algorithm. The ConcreteStrategy classes implement the algorithm using the Strategy interface. Applied to our concrete problem, the pattern structure looks like in the Figure 17. The application of the pattern is quite straightforward: Updatestodg srategye>ManageStodi( 3 interface oot interface AdicleType " Policy fall the models have a atate zymilar bahaviurie oan use + Update stood : wid a + fittest): woid "Ta TamplateMethod in order + Menage Stock): woid to fix the steps found in it Neat sateay 1 otrateay Pattern concrete sateay cxintertacen intartaoe intartaoe erred intartaoe intartaoes cinkartaoee Qitods! Tide! Sntode! Lotestimatonttode! || StookSreakingitode! EPQMads! PreduceConsurnettods! + niteowiecy wit | [+ aowject) wis | [+ aecowect) wie | [x mittawecy void || + mittoniecy-woid |] + mit@oweon voir | [+ aieonject)- vote + Manage stock) : void | |+ ateragestock? : wid | |+ aterageStockd : voit | |+ aenage Stock? : wie] |+ MenageStook) : void | |+ Manage Stock? :waid | |+ Aenage took : void Figure 17: Strategy solution The ArticleType class takes the Context role, and the Policy interface is the Strategy. The only operation that is going to be performed is the method ManageStock(), called when it is necessary to check if more stock is needed. The concrete strategies are the concrete policies that can be. With this pattern is very easy to add new policies, as well as interchange them when necessary. The article type doesn’t care about the data used by the algorithm, just to init it. It is not going to be developed the solution, but in early stages of the development it was thought the possibility of using the Template Method Pattern. It is not going to be explained in detail, but the pattern defines the skeleton of an algorithm in an operation, deferring some steps to subclasses. In order to decide between patterns, the pattern was applied to the problem (as happened with problem 4.2.1) and the pros and cons were weighted. This time 23 MSTORE Framework — Framework Design they were quite similar (this pattern allows implementing the common parts of the algorithm and leave it up to subclasses the implementation of the behaviour that can vary). The decision this time was made in terms of complexity. After deeper study in the algorithms, it was discovered that they were not so complex as expected, so it didn’t worth to use the Template Method pattern, thought for more complex algorithms. This example shows how sometimes it is better to choose the simplest solution, even while in first iterations it can look like that the complex is the better. 4.4 Store Management In this subsection, there are going to be discussed all the things related with the store, its distribution (layout of the physical store, locate places for new products or locate products in the store), and its movements between different zones or even other stores. As it is difficult to understand all like a whole issue, there must be decomposed in smaller problems: PROBLEM 4.4.1: LAYOUT v It is important to have the company organized. It can be interesting to know information only about some areas, or maybe to fix some parameters (costs...) in some particular areas. So there must offer the possibility of having nested areas. > The company should be distributed depending of the geographic situation, being possible to have hierarchies of areas. And each area will have one or more stores. > And also, each store will have different areas such unloading area or store zone. All of these areas usually have common behaviours, so they should inherit from one superior Zone class. = con li ic Are UNLOADING | ENTRANCE | STORE ORDER EXIT ZONE PREPARATION 6 CL] ®@ ®@ @ CO Delivery co oa note > (Nn CO Y G CT GO Figure 18: Zones ina store 24 MSTORE Framework — Framework Design OLUTION 1: Composite > Composite pattern can be used since each area is composed of stores and the stores are composed of zones, but it is not appropriate to use it, because it is not wanted to treat in the same way stores and zones. > Furthermore, the number of both stores and zones in a store is not usually very large. In a store it is common to have five main zones, with respect to the areas; it depends of how big is the company. SOLUTION 2: State > State Pattern is another choice as there are different zones, and in each zone the merchandise usually has a different state. > But not all the products follows the same route between zones, and they won’t be treat in the same way in each zone, so it is not an easy task to find a pattern for all the merchandis DECISION Design patterns are not always the best solution. It is true that they are good solutions, because they are probed designs, but sometimes, easier solutions can be used. In the next figure can be seen the solution chosen: By itis possible to have geographic ‘areas jerarquies |anlcle type, for do tis t should ook inthe [tones uth available merchandise, tpiealy pit [oars ol Sie Zo Mi - sting ‘interfaces lareaContainar fine) streg Typed steng Bescritiod) sting ‘antartaoee trea ISubaces interface ‘AdiiSubArea (SubAmea) : vead Delete SubAlrea Sub Area} : ve + FareatilAea) + Parent) “Mea 1 WOR i joer sree interfaces: Observer Hee IGecgranhicnres citerface> [+ Attachbserver) = yok! : fF peetosarenene) “oyect # ei aa gee + iD: sting Speen ee y geiabonaticn) ee eee aaa 4 AdiSubre Subd) oll tee ROAST, Uatontsumees volt sed ae Bey tary ne fS cohocriChseren voi T Feeder kt $ pnatet suet) vid ie eae) cate + Delete Suds iSubArea) : wok + AdySubArea @StuArea) : void + Parent(iama) : voad + Teed string + Nemed : sting + ABREYE: vod + Cesciietive() < siriog 4+ Farentiiiea) : vokd + Typed) «sting = + Debts SubArea (iSubAma) : roid + Ch scription) : string + Typed: string Desorption string in all the zones. is PROBLEM: ‘Tha merchandise is moved between different areas into the store building ‘Wie need to know where is a particular article ‘Wio need to know the stock of one type of amtoles in each zone. POSIBLE SOLUTIONS: Factary hethod for the distribution system in the store ‘Observer oan help us te notity the articles movements between zones Composite, State for the Zone structure + Decorator for detining the layaut management types |A2ZonaDistr bution ALoadingZone |.“ Alnputone aStoreZone Aduwparone Waloading2one| Figure 19: Store management 25 MSTORE Framework — Framework Design The Framework provides the main and more common systems for doing that, but with the use of Design Patterns there can be always added more different ways using the inheritance. It is going to be seen, dividing them in two main groups (both inherits from the abstract class ALocator). On one hand the classification for location merchandise: fe} fe} Input Locators: Chaotic Locator: In this storage system, spaces are assigned when merchandise or products are received without taking into account any determined order. But it is possible to fix some rules for the products location (security reasons, route optimisation, environment conditions...). Almost, the dimensions of the hollows must be appropriate for the products received. Tidy Locator: Each product has only a fixed and predetermined place. So the spaces will only keep the products with some particular conditions. The reader can think in other types of input locator as one locator that give us the position in which the manipulation unit fits better. And on the other hand, depending on the intern movements: fe} fe} Output Locators: FIFO Locator: The first product that goes into the store is the first that goes out. It is useful if the store is working with perishable products. LIFO Locator: The last products in going into it will be the first going out. Summarizing, there are the following problems: v The locator must create the appropriate location in agreement with the v v equipment of each zone. It is desirable to have more than one method of merchandise location (depending of factors i.e. if the product is perishable) in each zone. All the locators have similar behaviours, they receive a information about one product (dimensions and type if the locator has to look for a free place, and identification of the product if it is looking for an article type), and they have to reply with the location of the requested store unit, independently on the store unit is a shelf or it is a heap. SOLUTION: > Inheritance: As can be seen in the next diagram, there is an interface ILocator, with the common behaviour and methods of all the locators. Then the implementation of the search methods will be in the bottom of the hierarchy. 28 Unit, int, Hashtable): MSTORE Framework — Framework Design <<interface>> ILocator +GetLocation(IManipulationUnit,Hashtable): IStoreUnit +GetLocations(IManipulatignUnit, int, Hashtable): Stack -string id +GetLocation(IManipulationUnit,Hashtable): IStoreUnit ‘ations (IManipulationUnit, int, Hashtabl ZN <<abstract> > ALocator <<abstract> > AOutputLocator +GetLocation(IManipulationUnit,Hashtable): IStoreUnit +GetLocations(IManipulationUnit, int, Hashtable): Stack ZN <<abstract> > AFIFOLocator <<abstract>> ALIFOLocator, Unit, int, Hashtal Figure 21: Locators So, the result of mixing the two solutions is a specific Zone Distribution for each zone, and in this zone distribution it should specified the Jnput Locator, the Output Locator and the Equipment used: < <abstract>> AZoneDistribution -AlnputLocator inputLocator, -AOutputLocator outputLocator; -AEquipment equipment; +GetStock(ArticleType) +GetLocation(IManipulationUnit):ILocation 29 MSTORE Framework — Framework Design PROBLEM 4.4.3: Physical Distribution v It is wanted to offer some support for making diagrams simulating the store for doing easy the management. v It is desirable to be able to add more units if the store grows up (a store can change its distribution frequently). v All the store units are related with only one figure (depending on the type of store unit, and of course, on the type of equipment used in its zone) v Each type of store unit is related with only one feature. i Dangerous Freeze Shelves O Heap 0-5 degrees Figure 22: Store physical distribution diagram see SOLUTION 1: Decorator > This pattern it is useful if the same unit could have relation with more than one figure, but it is not the case. SOLUTION 2: Factory Method > This is the best solution, as it is known that there are units, with its figure, and types of unit with its feature, and there will be created concrete units and concrete types but there cannot be can’t anticipated which subclasses are going to be instantiate. | L sObserver| sintertasen You can have 3 diagram with the physical xinte races Why sieatDiagrare | distibution of the store. Each stare unit Inferfaces:t20me | cohett, eto) has one figure azociated. This + Brow swoid |----- figure is filled if the store unit is busy. | + Gatlocationpitiols) Oljet fee | Use Factory Method pattem for making the i | appropiate figure (Ghape and feature) for | each store unit eee se aintertaces wine fae {Stonelinit Fee Figure + ieFreedshoolean | Crestor” FactoryMatho -_Product_[+ Fina wore wintertaces wdintertaces iStoretlnifType Eee Feature | creator“ FactoryMethod Product Figure 23: Factory Method pattern solution 30 MSTORE Framework — Applications development using MSTORE Framework Chapter 5. Applications development using MSTORE Framework 5.1 Common topics in a standard store management application Two applications have been developed using MSTORE. Although one of their objectives was demonstrating that the Framework could be used for creating different types of store applications, they have also, as almost all the management programs, some common things, which are going to be analysed first. These operations where thought as common for most kinds of store management applications, so they are generic. More problem-oriented operations are seen in next chapters, where there can be seen the specific problems found when developing the pharmacy and the ironmonger. 5.1.1 Analysis > ACTORS As it is wanted to make the documentation easier to understand, it is going to work with the same types of actors in both applications. In the next table the reader can see the equivalences of each actor in each store, and also their main functions. ACTOR GOAL IRONMONGER PHARMACY System administrator | Configure parameters Configure parameters Add, modify or remove Areas Start up Start up Shut down Shut down Employee Person that is able to work with Person that is able to work with the the management operations management operations Director Orders Decisions Orders Decisions This person can do the operations | This person can do the operations of of the others employees but it is the others employees but it is not not usual usual Manager Resources management Resources management Accountancy Accountancy Process sales Process buying Providers and Clients Statistics Management Providers and Clients Management Worker Move merchandise Process inputs Process inputs Process outputs Process outputs Control sell by dates of the products Table 1: Actors and Goals 33 MSTORE Framework — Applications development using MSTORE Framework > UsE CASES Both applications have some common Use Cases. It is going to be followed the notation Cx in the common ones (where x is the number of the Use Case): USE CASE C1 Manage Company Goal in Context Actors do the main activities in the Company Primary, System administrator Secondary Actors _| Employee (Director, Manager, Worker) DESCRIPTION Step _| Action 1 Manage Resources 2 Manage Transactions 3 Manage Merchandise 4 Manage Store 5 Manage Users SUB- Branching Action VARIATIONS 1-5 User may use Web Services Table 2: Manage Company Use Case ane Manage Resources NS me A Employee Manage Transactions Manager Manage —— Qo Manage Store Worker Admin C > Manage Users Figure 26: Manage Company Use Case Diagram 34 MSTORE Framework — Applications development using MSTORE Framework USE CASE C1.1 Manage Resources Goal in Context Each store manages its own resources. They can be machinery, vehicles, employees, and contacts. Preconditions It is necessary to create, modify, consult or remove a resource The actor can do the action Primary, Admin Secondary Actors | Director DESCRIPTION Step__| Action 1 Choose the type of resource (vehicles, contacts, machinery or employees) 2 Choose the action it is wanted to do with the resource 3 Do the action 4 Close EXTENSIONS Step _| Branching Action 3a The chosen action is Create: - The user introduce Resource characteristics (For example, if the resource is an employee the data is divided in Personal Details, Contact Details, Economic Data and Labour Data) - The user confirm the action “Add Resource” - The system add the new resource 3b The chosen action is Consult Resource information: - The user choose the Resource it is wanted to know more about - The system shows the required information 3c The chosen action is Modify Resource - The user choose the resource that is wanted to modify - The user can modify Resource characteristics (For example, if the resource is an employee it is possible to modify Personal Details, Contact Details, Economic Data and Labour Data) - _ The information is updated 3d The chosen action is Delete employee - The user choose the resource that it is going to be deleted - The user confirm the action -__ The resource is deleted Table 3: Manage Resources Use Case 35 MSTORE Framework — Applications development using MSTORE Framework <<extend>> — <a . Co Create Buying Create Transaction <cextend>> ~C > Greate Selling <<extend>> menor - View Buying [we Transaction a ~C D> X View Selling <<extend>> Manager _ Modify Buyin, pn fy Buying Modify Transaction c<otent= (>) Modify Selling <couns> ©) Delete Buying extends Delete Transaction Delete Selling Figure 28: Manage Transactions Use Case Diagram USE CASE C1.3__| Manage Merchandise Goal in Context Some merchandise is having interaction with a store, in the entrance of the store (entry) or in the exit (output). Preconditions All the articles, the units and the amounts of the merchandise movement are known. It has been created one transaction that can be attached to the merchandise movement (i.e., one buying can be attached to one entry). Primary, Worker Secondary Actors DESCRIPTION Step | Action 1 Choose the action it is wanted to do 2 Do the action 3 Finish EXTENSIONS Step _| Branching Action 2a Register new entry - Choose entry name - Attach buying - Set the store where the entry is registered. - Choose the articles, amounts and units included in the entry. -__ Create the articles included in the entry 38 MSTORE Framework — Applications development using MSTORE Framework 2b View entry information - Choose the entry it is wanted to know more about -__ The system shows the information 2c Modify entry - Modify entry name - Modify attached buying - Modify the store were the entry is registered. - Add new articles, amounts and units. - Create the new articles included in the entry - Compare the entry and the buying. Create unresolved buying if necessary. 2d Delete entry - Choose entry that is going to be delete -__Confirm the action 2e Register new output - Choose output characteristics (name, date, comments). - Attach selling - Set the store where the output is registered. - Choose the articles, amounts and units included in the output. - Select the concrete articles included in the output. - Compare the output and the selling. Create unresolved selling if necessary. 2f View output information 2g Modify output - Modify output characteristics (name, date, comments...). - Modify attached selling - Modify the store were the output is registered. - Add new articles, amounts and units. - Select the new concrete articles included in the output. - Compare the output and the selling. Create unresolved selling if necessary. 2e Delete output. SUB- VARIATIONS Branching Action When comparing the merchandise movement with the transaction, sometimes they differ in some articles. - When dealing with inputs/buys, if there are articles missing, unresolved buys should be created and registered in order to keep this fact. If some articles are surplus, the user should be able to choose between returning the articles and taking them. - When dealing with outputs/sales, if there are articles missing, unresolved buys should be created and registered in order to keep this fact. If some articles are surplus, the user should be able to return the articles to the store. Table 5: Manage Merchandise Use Case 39 MSTORE Framework — Applications development using MSTORE Framework <<extend>> CD Create input Create merchandise movement Create output <<extend>> cone CD a iy input ga Sint OS View merchandise movement View output ol <<extend>> coe) << seay input OO Modify merchandise movement Modify output <<extend>> come CD << ome input Delete on movement Delete Output Figure 29: Manage Merchandise Use Case Diagram It is almost mandatory to have this use case in a store management application; in general, a Company always has one or more store buildings that are divided in zones, or other sub areas. It is possible to abstract the problem and extract the following operations: USE CASE C1.4 Manage Store Goal in Context The store is decomposed in several hierarchical areas that have to be managed Preconditions The administrator must add, modify or delete information about the areas of the company. The actor is authenticated Primary, System Administrator Secondary Actors | Director DESCRIPTION Step _| Action 1 Choose Layout management in the main screen 2 Choose Area parent of the new sub area 3 Choose add, consult, modify, remove or equip 4 Exit the layout management when the configuration is finished 40 MSTORE Framework — Applications development using MSTORE Framework USE CASE C1.5.2 Log out Goal in Context Different types of users can do different operation, so they must leave the session when they finish Preconditions The application is started up and the session is open Primary, All Secondary Actors DESCRIPTION Step _| Action 1 User closes the session 2 The application closes the session safety, keeping all the important information. EXTENSIONS Step | Branching Action Table 9: Log out Use Case 43 MSTORE Framework — Applications development using MSTORE Framework 5.1.2 Design In this section there is going to be clarified some of the design decisions for the more difficult operations, using sequence diagram for explaining the details of the process. None the entire framework is supposed to be explained in this section, only the operation of some concrete parts that could be interesting for the reader because of the solution chose or the nature of the problem. For more information, see the complete framework documentation [12] > SEQUENCE DIAGRAMS SD1 Equipment First, it will be seen more in depth the equipment operation from the Use Case C1.3 where the administrator of the application must configure all the equipment in each zone. Since each zone can have a different type of equipment (mainly with or without corridors), it is used the Factory Method pattern, as it was suggested in the Chapter 4. When the administrator begins the Equip process in a zone, the system consult the type of available locations in that zone, previously selected, and depending on that type, it is called the appropriate factory (CorridorFactory or NoCorridorFactory in the Figure 36), and obtained the corresponded location for the data that the administrator had introduced. With that location it is created a new StoreUnit, which will be aggregated to the zone that is being equipped. oO K zoneZone | |:CordorFaotory|| :NoCoridorFactory || factory:AEaup sGortidor | :NoGonridor | | :StoreUnit Factory Location || “Location Admin ‘equipment=Equipment. get CorridorFactory) | Fl! [equipment-NO_CORRIDOR] _factory=new NoCorridorFactory() ipment=CORRIDOR] factory= factory factory factory. MakeEquip) | 1. [factory is CorridorFactory] location=new CorridorLocation() 2. [factory is NoCorridorFactory] location=new NoCoridorLocation() storeUnit= new StoreUnit(location) 1 adaistoreUrit) | | 7 t | location | | Figure 31: Equipment Sequence Diagram 44 MSTORE Framework — Applications development using MSTORE Framework SD2 New Buying The shop manager actor performs the process of making a new buying. First the manager introduces the basic data for the buying (name, date, store, payment method and provider). Then, the articles included in the buying must be chosen. The articles are always be part of the provider’s catalogue. For each article it is chosen an amount, a price, a unit and a measure. When it is added one article type (observer) to the buying, it is going to be attached to the transaction (that plays a subject role) being included in the observer list. At the end one document type will be attached to the buying. Depending on the election of the document type, the buying will be initiated with a different builder. After selecting the different parts of the buying, it is performed with the method DoBuying( ). The method creates the document for the buying and it implements the Notify method: covers the observers list updating the different article types. In this situation these article types will increase their virtual stock with the amount given by the own buying. Create Buying(name, date, store) SetProvider(provider) SetPaymentMethod(Pay ment method) CY [loop]AddArticles (articles) [loop]RegisterArticleType(ArticleType, ‘amount, measure) Eo Attach(ArticleType) <_| Builder. CreateDocumentthis) <__] PoBuyingtthis) [loop}irreach(ArticleType at in observers) at.update(this) Increase VirtualStock (Buying. GetAmount(t! < Figure 32: New buying sequence diagram The Selling process would be almost the same; the observers automatically are going to decrease their virtual stock with the amount given by the selling. The observer pattern can look like redundant in this example, but this is a key issue in stores management so it is preferred to maintain a complex structure for the stock management. 45 MSTORE Framework — Applications development using MSTORE Framework > CLASS DIAGRAMS All the class diagrams can be seen in the project documentation, available at the project Web Page [12]. Here there are only shown the ones with relevant information as an example. After applying the factory method pattern solution to the problem of the equipment, in both applications, it was obtained a diagram as the next: SS) & vintertaceo, 5 Ade | | pop et fovator MonaDistribstion intestacy ‘ite can rave several zones nthe store and in ezc1 zone ove Sa — Eiaidia_ Watear ein g-mnacines neceain min) ace ae air ee | lensteneos ereesntncne sees a | Exehtypectdsiouton vas ciferert way ofaezete vonage, seubren Lee 4 Sa 4 sours = “pals Fai col pate: he bit odes aie oe ee sites: ——s Icomovinzyenet wth elevator of ech ae, Arpaoet See ‘FEquipmanLozetor t. ‘AstoreLrit, contertattn. 7? arenas: aban > erase: aca Aeition se phny : i - gareronp + gtlacaton iguana): ALcaon | | ervaeba( hans seater oat + getGak( q J+ aflcsionMiipdsinn); Aetin setae? stig tease d b ; k / \ [i N! a —t — |e way [nce cormedbr Chl coen tole secoriotoznar feels ++ geiPee!coalon) Anat 1 plfestosaton) Aloeaton fs gttatacatng saloaicn = + gpibeatiedanpaltoett ¢beatoe |) |. getlacato(Maapuldnntnd) :Alacaizn| |+ getozaoatitenpulefovuni): Aloztoa z an a Co) cenit eee hocorteiocaen] CHTifecorot fe. = hiakeEquip(: void \ = peioe): Sig = vekeEaieC soe ‘itaace Z arena: RAGE: J+ setCada: Sng] ee Poca caesar + gstmelactinnD : Alcan Ue sstretocaen : Avon Le getheeoeatn) acai + getoratoatterpiatonde): Aucaioa| "| getoaton(Menpabtoweit) Atoctor |. setlratortangulatont)-Aloaton Usetalin pha pote Figure 35: Equipment solution —- Factory Method In this diagram the reader can see that there are two types of equipment (remembering that the applications are only for testing the framework), corridor (with corridors, shelves, shelf...) and no corridor (in chaotic heaps) equipment. In the diagram is also combined the solution for the Locators problem, without using patterns. In Figure 36 the reader can see the solution for the transactions applied to the Ironmonger and Pharmacy problem: 48 MSTORE Framework — Applications development using MSTORE Framework interfaces +obse mers [Subject aintertacen lobserver + Attach (Ohsened : void + DetgehgOnservent : wok + Aleaityasueyecty : woe 4+ UbdatedSubiect) : woid Po 7 Subject os, Obsenver Observer Pattern, Notifye for all @ in observers o->Updatetthis) # ‘subject cinterta cen aintertaceo {|$-_ —$>?p__———_ interface s:startiois tyne IConerefesubject S Gitar + Getstzieg : void + Update (Su tyeot) : wold + Setstatoy!: word + Add dartiole Type) : woke + Getamount@aitiole ype) :iat| + Romowo({aricle Type) > void + Inomase Virtual Stoomint) : void + DocreasebiirualStock(it) : wei + GetstoekD :Frt + GetuituatSioek() :int ae ree Update( Subject 3 «interfaces suiteh(s. cetTypeOy Sg ease SELLING: Jaferface s AS eNing inferfaces::IBuying De crease VirtualSte cis. getAmount(thisyy + CreateDocument (Object) + GreateDocument(Qivect) : void ease BUYING: ie See ee Meare ce IncreaseVirual Stocks getAmountthi) + Addticlepticle, a8 -woid] [+ AdzAgicteriou yingCetat) :vakd + GetAmount(Aricte Type) int] + GetdmountiAniote Type) + int t FF each Observer will increase/decrease the amount in a differentwiay "# Figure 36: Transactions: Observer pattern solution The different transactions (buying, selling, entry, output) are going to implement the Subject interface, while the article type implements the Observer interface. Depending on the transaction performed (for instance make a buying), the observer will change its state in a different way (in the example increase the stock). When making a transaction the observers (that are the products) are just updated, and they update themselves in a different way depending on the transaction. This structure makes the process quite automatic, as there can be notified changes in the stock without making assumptions about who are these objects. This diagram changes between Pharmacy and Ironmonger but that changes are not interesting here since it will be explained in the sequence diagrams of the specific sections (SD8). 49 MSTORE Framework — Applications development using MSTORE Framework 5.1.3 Implementation > DESKTOP APPLICATION Almost all the management applications have the resources management quite similar; here it is shown the one for the Ironmonger: Figure 37: Resources management Screen- Choice: New Employee Since different users can do different actions it is necessary to log in the system before being able to do any operation: Figure 38: Log in screen in the Ironmonger Figure 39: Log in Screen in the Pharmacy This pair of windows has different interface, but they do the same operation of the Framework. Some different screens are shown in next sections, since they are quite depending on the specific application. 50 MSTORE Framework — Applications development using MSTORE Framework 2a Register new entry - Choose entry name - Attach buying - Set the store where the entry is registered. - Choose the articles, amounts and units included in the entry. - Choose expiry date (Perishable + Sell-by date, Not Perishable). For perishable articles, when an output is made, the sell-by-date is checked. If it has expired, the article will be located in a fictitious output (with price 0). - Create the articles included in the entry - Compare the entry and the buying 2c Modify entry - Modify entry characteristics (name, date, comments...). - Modify attached buying - Modify the store were the entry is registered. - Choose expiry date (Perishable + Sell-by date, Not Perishable). - Add new articles, amounts and units. - Create the new articles included in the entry - Compare the entry and the buying. Create unresolved buying if necessary. 2e Register new output - Choose output characteristics (name, date, comments...). - Attach selling (optional). If no selling is attached the output is correct. - Set the store where the output is registered. - Choose the articles, amounts and units included in the output. - Select the concrete articles included in the output. - If there is attached selling, compare the output and the selling. Create unresolved selling if necessary. - If there is not selling attached, there will be created a new resolved selling (with the same articles than the output). 2g Modify output - Modify output characteristics (name, date, comments...). - Modify attached selling (the choice of a selling is optional). - Modify the store were the output is registered. - Add new articles, amounts and units. - Select the new concrete articles included in the output. - If there is attached selling, compare the output and the selling. Create unresolved selling if 53 MSTORE Framework — Applications development using MSTORE Framework necessary. - If there is not selling attached, there will be created a new resolved selling (with the articles added in the modification). Table 10: Pharmacy: Manage Merchandise Use Case <<extend>> Create output Create fast output Worker <<extend>> Modify output Modify fast output Figure 41: Modified Manage Merchandise Use Case for the Pharmacy The modifications make much faster the selling process, as it is not necessary the explicit creation of a selling and it is created automatically. It also ensures that the selling and the output will be identical, so there is not need for comparing them and create unresolved buys if something is wrong. Another important variation regards to the perishable articles. In the original Use Case it was suggested that this variation could be done, but it was not implemented in the framework. The task is quite simple: if the article it is being managed is perishable, a sell-by-date will be added to its characteristics. The output registration process will change also. After the location of one article, if the article is perishable it is going to be checked sell by date. If it has expired, there will be created a new output (fictitious, with its respective fictitious selling) where the article is located. The price of the article is cero, as it cannot be sold. After the creation of the fictitious output, another article will be searched again. Here is shown another variation of a use case done for the pharmacy. Again, in bold are marked the new features added to the original use case representing the generic behaviour for all kinds of stores, explained in last section USE CASE C1.4.1 | Manage Store in the Pharmacy Goal in Context The store is decomposed in one or more zones that have to be managed. Each zone has to be equipped 54 MSTORE Framework — Applications development using MSTORE Framework Preconditions The administrator must add, modify or delete information about the areas of the company. The actor is authenticated Primary, System administrator Secondary Actors | Director DESCRIPTION Step | Action 1 Choose Layout management in the main screen 2 Choose Store parent of the new zone 3 Choose add, consult, modify, remove or equip 4 Exit the layout management when the configuration is finished Table 11: Pharmacy: Manage Store Use Case Now, the specific Use Cases for this Pharmacy are shown. The used notation is Px: USE CASE P1 Manage Company Goal in Context Actors do the main activities in the Company Preconditions The application is ready Primary, System administrator Secondary Actors _| Employee, Director DESCRIPTION Step | Action 1 Manage Statistics 2 Manage Articles SUB- Step | Branching Action VARIATIONS 1-2 User may use Web Services Table 12: Pharmacy: Manage Company = ss Manage Statistics 7 ~~ rect Se Worker Manage Articles Figure 42: Specific Use Cases Diagram of the Pharmacy USE CASE P1.1 Manage Statistics Goal in Context It is wanted to see several statistics about different entities related with the store: benefit per article type, benefit per shop, sales per provider, 55 MSTORE Framework — Applications development using MSTORE Framework 5.2.2 Design > SEQUENCE DIAGRAMS The next sequence diagrams illustrate the use cases presented in last section. The explanation can be found within the particular use cases: SD5 Perishable Articles [= | : Worker Create(characteristics, volume) IsPerishable(sellBy Date) Create(Characteristics....articles) RegisterOutput( ) CheckSellBy Datel ) expired New Output(Article,price=0) Figure 45: Create Perishable Article Sequence Diagram SD6 Fast outputs : Worker sQusput Create(name, date, ... store) AttachSelling(null) RegisterOutput(store) <—_ [loop] foreach (articletype in buying.articles) = NanagestorktancleType, amount) foreach(iin articles) Locate(ArticleType) 71) Create(articles, client, ..price) Figure 46: Fast Output Sequence Diagram 58 MSTORE Framework — Applications development using MSTORE Framework 5.2.3 Implementation > DESKTOP APPLICATION The object-oriented design of the framework, using design patterns and 3 layers (interfaces, abstract, and concrete classes) make easy and fast the pharmacy management program development. Anyway, as it was the first program (as well as the ironmonger’s program) developed using the framework, many of the development time was used debugging the framework and adding new functionalities to it. Little code was necessary only for the pharmacy program, and most of it was related with the user interface and the presentation. Some of the main forms can be seen here, for further information consult the project web page (12). Figure 47: Main Screen of the Pharmacy Management application This is the main screen of the Pharmacy. As the reader can see it is necessary to login for being able to do the rest of operations. When the user finishes the work it should log out. These operations are related with the database, as they convert the database tables in objects that can be used within the application. Eee er neces — — ba Nemo “Cade A ‘Gaskell Je raKG UNHEBULVED, ‘Ewing New taut aoa view ou Ass wine Price ost anit bale Tet ico yn Pie Liteeree “Total ce 1 Penatoals h € Boll be date Figure 48: Add article to entry screen 59 frre ston Modi 3 be MSTORE Framework — Applications development using MSTORE Framework Last window shows how the worker can add an article to an entry. This task is done each time the store receives merchandise. With this screen the information introduction is manual, but in a real store it is usual to have bar codes for making this easier. 2 B a (a= il [i= AtcleTypes a Ea New Atticle Type Name _|ASPIRIN- BAYERN Code 2 Pasessian Price Period in Days) Family || Emission Price 003 =| Demand Supply Time (in | Days) OK Figure 49: Set Stock Management Policy parameters screen View le oe Infrmation Management 0 Model * charattrasés | voune ve al ee ere | | Used Mest gam eee " n Bianeg Tete T Is Loadabl : Adquision Pice 1213 ==] ResupelyTimedn fi =] Add Cancel Days) 0,01 = Fi (Management [365 | Cancel Some parameters must be fixed. In Figure 53 it is shown the form for filling them. This task is done when an article type is created or modified. a a Entries — F outa | ENTRY New Fry | New Quant BL New Output j-Atiles Name | Sole fT eel owing tach Selig, T Fastouput | Tote pics fp Bupngtice ep | Difference Lu Cleae ny | See Figure 50: New Output screen Finally it is wanted to show how create an output in the Pharmacy. As the reader can see in the window, it is necessary to fill some information and the articles that compose the output, that are selected from a list. MSTORE Framework — Used Technologies Chapter 6. Used technologies 6.1 .NET Framework 6.1.1 Basic .Net platform architecture: Framework Description & Main Components The .Net Framework [18] [19] is an infrastructure where there is collected a set of languages and services that simplify hugely the applications development. By means of this tool it is offered a highly distributed programming environment that allows the creation ship of solid and easy-to-extend applications. The main components of this environment are: ¢ Compilation languages. e .Net Classes Library. ¢ CLR (Common Language Runtime). .NET Framework Architecture Source code 4 € » Compiler Q 3 4 Microsoft NET Framework Classes Library ‘VB Compiler a com) re Microsoft Intermediate Language (MSIL) ‘Common Language Runtime (CLR) Operative System g Q Figure 53: .NET Framework Architecture . Net Framework supports multiple programming languages, and even though every language has its own characteristics it is possible to develop any application with any of these languages. There are more than 30 .Net adapted languages, from the more know ones (such us C#, Visual Basic or C++) until others like Perl or COBOL. 63 MSTORE Framework — Used Technologies The kernel of the .Net Framework is the CLR: the execution environment where the applications developed in the different languages are loaded, extending the services set offered by the standard operative system Win32. The development tool used compiles the source code of any language into the same code, named intermediate code (MSIL, Microsoft Intermediate Language). The generated code is always the same for every language. This code is transparent to the application development, since the compiler automatically generates it. In a second step, the JIT (Just-In-Time) compiler generates the real machine code that is executed in the platform that the computer owns. In this way some independence from the platform can be achieved. When an application is being programmed, many times it is needed to carry out actions such as file manipulation, data access, system-status knowledge, security implementation, etc. The framework organizes all the system functionality in a hierarchical name space so when programming it is quite easy to find what it is needed. For it, the Framework owns a universal type system, called Common Type System (CTS). This system allows a programmer interact the types included in the Framework (.Net classes library) with the ones created by himself. In this way the user makes the most of the advantages of the object oriented programming, such as predefined class inheritance for the creation of new classes, or the polymorphism to modify or amply existing behaviours. -NET Framework Classes Libra System.Web ‘System. WinForms System.Drawing [Caching | [Security] ([Drawing2d [Printing] Texte System Data System. Xml Figure 54: .NET Framework Classes Library The .Net Framework classes Library includes, between other, three key components: e ASP.NET [17] for the construction of applications and Web Services. ¢ Windows Forms for user interface developing. e ADO.NET for database applications connection. 6.1.2 Visual Studio NET Visual Studio .NET is the integrated development environment (IDE) that is being released in conjunction with the NET framework. It offers many advantages and productivity gains when developing .NET applications both for the Windows desktop and for the Web, including: v Visual development of web pages. v Drag & Drop web form design. v IntelliSense and automatic code completion. 64 aN MSTORE Framework — Used Technologies Integrated debugging. Automated build and compile. Integration with the Visual SourceSafe control program. Fully integrated, dynamic help. It gives support for different languages (Jscript .NET, Visual Basic .NET, C#, ASP.NET...) sharing the same general structure for all of them, so the user doesn’t have to learn a different environment for each different language. Figure 55: Visual Studio NET appearance 6.1.3 Some advantages of the .Net platform Here there are included some of the more important advantages provided by .Net Framework: Managed Code: The CLR makes an automatic code control so that is safe (the application is executed correctly). Multilanguage interoperability: The code can be written in any .Net compatible language as it is always compiled in intermediate code (MSIL). Just-in-Time compilation: The JIT compiler grows the application performance, as the code is specific for each platform. Garbage Collector: Automatic system for the memory management. The CLR detects when the program stops using memory and it frees the memory automatically. Code Access Security: It is possible to apply different security levels to the code. Process such as garbage collection or the management of the code introduce overload factors that affect in the demand of more system requisites. The managed code provides a faster development speed and more security. The bad point is that the resources consume is much bigger, but nowadays, with the current processors this is not a big disadvantage. The code administration level depends on the used language. C# allows the code administration code in a manual way, being by default an administered language. 65 MSTORE Framework — Used Technologies 6.2 NHibernate When using an application, it is usually necessary to store the information it is being used among different executions of the application. If it is translated to an object-oriented developer view, it is needed some way to store the objects that contain useful information so that they can be used in other executions of the program. This is what is usually called persistence. There are several ways to achieve this goal. For instance, Java includes Java Beans Enterprise, that allows making the objects persistent in a transparent way. The objects are saved into files and the next time it is wanted to use them it is an easy task to recover them. However, the user looses the benefits of working with a relational database. . NET includes ADO.NET for database connection. Anyway working with object-oriented software and a relational database can be a thorny task, as the user has to write SQL sentences to get the objects in and out from the database. In order to save development time it is a good idea the use of any tool that makes this work for the programmer. NHibernate [11] [20] is a NET based object persistence library for relational databases. It is based on the Java Hibernate relational persistence tool. It allows the persistence of the NET objects from an underlying relational database. In another words, it achieves the mapping of a data representation from an object model to a relational data model with an SQL-based schema. Instead of generating SQL sentences, the code is only concerned with my objects. NHibernate generates the SQL sentences and locates the information in the different tables and columns (provider transparent persistence). The library is in the beta stage, so it does not warranty that it is free of bugs (and as the researchers have checked, the existing documentation is much poorer than the Java Hibernate’s one). Anyway, after the basics are understood, it helps a lot the task of translating the objects into tables in a relational database. Nowadays, the translation between a .NET class and a table has to be done manually. In a future, NHibernate is going to include tools that help in generating a schema and generate classes from mapping files. Basically, there are 5 steps a user has to follow to make our objects persistent: Step 1: Create the table where the information is going to be stored. Step 2: Create the class is wanted to be made persistent. Step 3: Create a configuration file that allows NHibernate connect to my database. Step 4: Create a mapping file where is telling NHibernate how the class properties should be translated to the database table. Step 5: Use the NHibernate API to make the class persistent. These API has methods to initiate the connection, connect the database, get/save objects from/in the database, update the tables, disconnect the database, and more operations. The researchers’ experience with NHibernate was not very positive, as it was quite hard to find the propped documentation to solve the problems they had. Anyway, as it is based on the Java Hibernate tool (that warranties a good performance) it is expected that these problems will be solved in later versions and the documentation will be improved. 68 MSTORE Framework — Used Technologies 6.3EA Developing an Object-oriented application is much more than developing a class model - lifecycle of system development - business process analysis, use case requirements, dynamic models, component and deployment, system management, non-functional requirements, user interface design, testing, maintenance etc. For this reason there should be chosen the appropriate CASE tool for improving the design of our application. 6.3.1 UML The Unified Modelling Language [16] has quickly become the de-facto standard for building Object-Oriented software. The OMG specification states: "The Unified Modelling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artefacts of a software-intensive system. The UML offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components." The important point to remark here is that UML is a “language” for specifying and not a method or procedure. The UML is used to define a software system; to detail the artefacts in the system, to document and construct. The UML may be used in a variety of ways to support a software development methodology (such as the Rational Unified Process) - but in itself it does not specify that methodology or process. 6.3.2 Features within Enterprise Architect UML Modelling tool The chosen tool was Enterprise Architecture [22], and the following characteristics are the mai reatosfoctiscecion ENTERPRISE v¥ — Comprehensive support for UML 2.0 A RC H IT E CT v¥ — Comprehensive and flexible documentation v Forward and Reverse Code Engineering for C# (used development language), and also for other languages like Java or VB Easy to use Support for testing and maintenance. XML import and export Spell Checker. Support for Glossary. Reasonably price. Although it has not a lot of extras (most of them useless) as Rational Rose or Together, the services that EA provides are enough and its low cost and great functionalities, are the reasons of the choice. LLL 69 MSTORE Framework — Used Technologies 6.4 NUnit Remembering the objectives of this project, in this first version it is going to be implemented only a part of the framework since: - It would be a hard work (almost impossible) to implement a useful, complete and efficient store management Framework in only one interaction and in the given time. - It is better to start developing a part and then make that part bigger and bigger in several versions. So, one of the destinations of the code done in this version is to be reused in other programs. For do this successfully, it is necessary to document the Framework, and also to test all the modules independently, for minimizing the probability of errors when they work together, trying to obtain a bug-free and quality code. It is important to point that the part of the program that should be tested deeper is the one that is included in the Framework (implementation of the methods of the classes that are really going to be reused). It is not so important to test the interface class ince these example applications are not going to be used by real customers. Their objective is to demonstrate some characteristics and advantages of the Framework. There is some testing software that makes this task easier. A unit test is nothing more than the code wrapper around the application code that permits test tools to execute them for fail-pass conditions. In this version it was used NUnit because [21]: v NUnit is a unit-testing framework for all .Net languages, so it is appropriate for C#. v Initially ported from JUnit, the current release, version 2.2, is the fourth major release of this xUnit based unit testing tool for Microsoft .NET. v _ Itis written entirely in C# and has been completely redesigned to take advantage of many .NET language features, for example custom attributes and other reflection related capabilities. NUnit brings xUnit to all NET languages. v _ Itis open source v — Ituses an Attribute based programming model. v It loads test assemblies in separate application domain hence an application can be tested without restarting the NUnit test tools. The NUnit further watches a file/assembly change events and reload it as soon as they are changed. With these features in hand a developer can perform develop and test cycles sides by side 70 MSTORE Framework — Conclusions Chapter 7. Conclusions This document tries to make a complete explanation about the reasons that motivated the creation of MStore Framework, the process of designing and developing its components and structure and finally the real application of it, trying to build some particular examples, with a specific problematic each one. The project was done with a quite important academic motivation, so in the beginnings there were chosen a wide variety of technologies useful to complete the skills acquired during the academic life of the authors and preparing them for future job: .NET platform and C# (in comparison with Java), web services -rising nowadays-, experimenting the advantages of design patterns and frameworks, and going in depth in management applications, largely demanded in companies. Although the project started as a preliminary study, future versions will use the work for developing more usable real-world applications. The size of the project provides work for at least three generations of students continuing it, as was thought from the beginning. Guidelines for the future work will be given later. Anyway there are several conclusions that have been taken from the process, although most of them can be found along the report. Here there are exposed the main ones. v Patterns are a good way to describe frameworks because first-time users of a framework will usually not want to know exactly how it works, but will only be interested in solving a particular problem. The benefits of using patterns and 3-layer design are explained before, but in the scope of this project it is difficult to make this affirmation, since the creators of the framework are the first (and only, by now) users of it. It is expected that future users will enjoy the benefits of the well-structured design, and that most of the adopted solutions will be used in future versions. v The particular applications developed using MStore have seen its development time decreased, since most of the code used in the business logic there was already written in the framework. The design, development and debugging of the framework took four months of work, and the construction of the particular applications took one month and a half. Make predictions about development time reduction using MStore is quite difficult, as some considerations must be taken into account. o When a developer uses a framework for first time, it is assumed that he is going to spend an important percentage of his time understanding its operations and thinking how to apply it to the particular problem he is trying to solve. This fact cannot be contemplated this time, since the developers had previous knowledge about the framework design. For decreasing the learning time, the documentation plays an important role. A good, clear and standard version of the Framework documentation can 73 MSTORE Framework — Conclusions hugely help to the future user of MStore when trying to understand or expand it. o The applications built using the framework have all the benefits of the design patters, so they are easy to read and to maintain. Developing one application with these characteristics from scratch can make much bigger the development time. Taking into account these considerations it can be concluded that development time using the framework will be at least half of the normal development time, assuming that the program has a medium difficulty. If the rate of difficulty increases, the relative time comparing to the one spending without the framework decreases. In our particular study case, the development time for each of the applications was two months (including analysis phase), but as this time is including some debug from the framework, it should be concluded that the development was done in 4 weeks. The development time if MSTORE had not been used wouldn’t be smaller than two months. v On the other hand choosing the technology is also an important decision. Working in a comfortable, easy to use, useful and familiar environment helps the development and reduces the programming time. Also Visual Studio makes much easier the realization of the web services, providing wizards and methods that do the task almost automatically. Related with the language C#, it was easy for the programmers to learn it since it is quite similar to the previously used Java. Knowledge of both platforms gives the programmer a broad vision of the current market. v Although the authors have worked in group before, for them this is the first big application developed in pairs. In early stages of the project it was planned to use a methodology such as Extreme Programming, but finally it was not possible and it was decided to separate the project in two parts, being in charge one of each part. From the experience it can be concluded that work in a group (in a couple this time) can be a hard task, and it is necessary a lot of time organizing the future work and talking with the colleague. Following any methodology could help in this task, but it is fundamental that the programmers are in a good attitude to the partner. 7.1 Future plans By now, it cannot be said yet that MSTORE Framework is a robust and probed support for creating new management applications. A program with this extension needs further research and debugging until it can be used by any end-user. Next versions of MSTORE could add the next features: v Repair possible bugs that can appear in this version. Expand the web services offered and develop consumer programs that explode all its possibilities. v Probe the rest of the Framework programming applications that use as many as possible number of functions. It is expected that these applications will have a medium size, as the framework is not thought to be used by big department stores. Expand the web services offered and develop consumer programs that explode all its possibilities. 74 MSTORE Framework — Conclusions v Integration with other parallel programs that are been developed now, such as risk management or document management. v Thinking in other programs that can complement MSTORE as an accounting one. Publish the program and try it with real users, pondering strong and weak points. 75 MSTORE Framework — References [24] Schmidt, D. C. (1997) OO Application Frameworks. < http://www.cs.wustl.edu/~schmidt/CACM-frameworks.html> [25] Robinson, S., Nagel, C., Skinner, M., Evgen, B., Watson, K. & Glynn, J. (2001). Professional C#. Wrox Press. [26] Vawter, C. & Roman, E. (2001). J2EE vs. Microsoft .NET. The middleware company. <http://www.theserverside.com/resources/article.jsp?1=J2EE-vs-DOTNET> 78 MSTORE Framework — Appendices Appendices I. Storage systems and product location in a Store In first view, it can be differentiated two different types of storage: open air and covered. From the point of view of stored merchandise type and equipment for its manipulation, the storage systems can be grouped in function of three different criterions [1][5]: 1. According with the organization for locating the merchandises. a. Tidy Storage We assign to each product, one only place, fixed and predetermined. Therefore, the spaces, destined to accommodate the different products, adapt themselves to the particular characteristics of those products, and they only accommodate products with those characteristics. Emphasize in a positive form in this system, the facility of control and manipulation of the products. However, the limit in the storage by the foresee spaces can cause under utilise of it, since it is possible that the capacity does not be covered in whole. b. Chaotic Storage or free space In this storage system, we assign spaces when the products or merchandises are tidied up, without keeping any predetermined order. Nevertheless it is common to establish some rules for looking for the location of the products (security reasons, optimisation of routes, environmental conditions, etc.) and the dimensions of the spaces will be the appropriate for the products that they can receive. This method allows a better use of space but it is required sophistic control methods. Figure 57: Chaotic Storage 2. According with input/output flux. a. LIFO Storage The last product that goes into is the first that goes out. 79 MSTORE Framework — Appendices b. FIFO Storage The first product that goes into the store area is the first that a goes out. It is the most appropriate for perishable products or 74 Ee fast caducity. a Figure 58: Dynamic by gravity-FIFO 3. According with the equipment used for optimising the available space. a. Without corridors Storage Between the products there is not any space. Figure 59: Rack b. With corridor Storage Regarding the merchandise location systems, it can be pointed out that it is very important to be able to localize in all the moments any product. Location is the space where the product is accommodated temporally. Each location has to be identifying by a code. Letters or numbers composes this code, and it allows identifying: the location of the merchandise in the shelves, corresponding zone and store used. There are two main Location Systems: 1. Shelves location or lineal location A correlative number has to be assigned to each shelf. Correlatives numbers identifies the deep of that shelf too, with origin in the headboard. The level can be identified with number from the low level to the high level. 2. Corridor location or comb location 80