A service or a server needs to be shutdown properly. If the server is terminated in abrupt manner, there could be integrity lost.

For instance, a client has sent a request to create a record. Just after the request has been created and before the client is notified the result, the server is shutdown and it cannot return anything to the client. When the client receives nothing back from the server, it will assume request was not processed and it will try again after the server is restarted. In that scenario, duplicate record could be created or client will get failed inserting again. But client will take it as failure and could keep trying again and again. This is not desirable.

And before the server is shutdown, it has to do some in-house cleaning such as closing the connection or logging the status. For that reason, a server should always have a function to stop properly.

The stop function should

• block or not accept all the incoming requests first
• close all the connections
• persist the status

To achieve this, an interface named “Service” is created and all the services/handlers implement it.

User interface class has a list of all the service as a member variable. When a user click “shutdown” from the menu, GUI class will do something like

for(Service service : services){
     service.stop();
}

The figure below depicts a UML sequence diagram of the behavior of a simulator during the execution of a user defined scenario. Before the code has been written and tested, one can interpret this diagram as a set of interrelated behavioral requirements imposed on the software. After the code has been written, it can be considered a design artifact that reflects what the code does at a higher level of abstraction than the code itself.

Interpretations like this give credence to Alan Davis’s brilliant quote:

One man’s requirement is another man’s design

Here’s a question. Do you think that specifying the behavior requirements in the diagram would have been best conveyed via a user story or a use case description?

Hoy tuvieron lugar las Alm’09 sessions de Microsoft en Madrid, nuevamente en el Palacio de Congresos donde recientemente se desarrollaron las jornadas Ficod 09; y mi lugar preferido para asistir a conferencias. En estas ponencias se pueden ver los avances que tendrá el nuevo Visual Studio en materia de herramientas de diseño de alto nivel, y que facilitarán integrar en forma centralizada la documentación para distribuir al equipo de desarrollo, fácilmente accesible y correctamente versionada.  Los siguientes videos muestran las posibilidades que se explicaron:

Sesión: El Rol del Arquitecto en el día a día con Visual Studio 2010 – Bruno Capuano (Avanade)

Sesión: Diseño de Arquitectura Top-Down con UML – Roberto Gonzalez (Renacimiento)

(tiny)

Simple and nice to use UML Tool free of charge, see here.

Under gårdagen hade vi en övning med UML diagram och idag var det dags att skapa eget UML diagram för vårt spelprojekt. Detvar dock väldigt svårt att komma fram till vilka klasser vi kommer att behöva samt hur de ska vara ihopkopplade. Men efter ett tag så fick vi ändå iordning något som såg hyfsat ut, dock tror jag det kommer bli endel ändringar i UML diagrammet efter vi har börjat programmera på spelet, för inte förrens då kommer vi kunna få en helt klar bild över hur många och vilka klasser som kommer behövas.

Vid nästa tillfälle är det nu dags att börja koda på spelet.

Arbetad tid: 2h

Idag spenderade vi en timme på att diskutera klasser och arv. Vi installerade Dia Diagram Editor för att börja skissa lite på klass-strukturen.

Please send all resumes to rrabines@topsource.com

Must be: Citizen, Green Card or EAD

Location: Miramar, FL
Salary: High on Experience
Status: DIRECT HIRE

The Java Application Architect will work across teams to design, develop, and deploy business driven solutions consistent with the Enterprise Architecture strategy. The candidate will drive the evolution of a Service Oriented Architecture (SOA) by developing SOA based solutions spanning all layers of the SOA software stack, including but not limited to, service enablement of legacy systems, Enterprise Service Bus (ESB) based integration, Business Process Management (BPM), and SOA Management & Governance. The Jave Application Architect will be a middleware and integration expert chartered with developing mission-critical enterprise software solutions, for enterprise modernization and integration projects. This technical leadership position will require a deep understanding of modern SOA standards, integration patterns, and Web technologies. This person will also be required to map and model business processes, as well as manage integrated project schedules. The Java Application Architect will develop a deep understand of both the business architecture and technical architecture.

Requirements:

-     BS or higher in Computer Science, Computer Engineering, or Electrical Engineering
-     At least 10 years developing object oriented enterprise software solutions in Java
-     At least 12 years applying OOA/D techniques to architect and implement software solutions
-     At least 6 years using J2EE Application Servers and Java enterprise application frameworks
-     At least 4 years as a lead SOA architect working on enterprise integration projects
-     Experience with the full software development life-cycle and various software methodologies such as RUP and Agile approaches
-     Skilled at modeling with UML, as well as requirements capture and business process mapping
-     At least 4 years hands-on experience on enterprise modernization and integration projects employing ESB based SOA solutions
-     Extensive hands-on experience at all layers of the SOA solutions stack, including but not limited to: ESB, BPM, Business Rules, Workflow, SOA Governance & Management, Security & Identity Management, and Portal Development
-     Web Services and Standards Expert
-     Have used/implemented JMS, Message Oriented Middleware, Event Driven Architectures, & Complex Event Processing solutions
-     Project experience with service enabling legacy systems, assembling composite service enabled applications, and applying a wide-range of enterprise integration patterns
-     Experience creating a data services and management architecture for enterprise information integration, developing information models, XML and database schemas
-     Strong SQL skills and experience with one or more database systems
-     Knowledge/experience with various operating systems: Linux, Windows, and/or AS 400
-     First-hand experience developing SOA solutions for CRM, ERP, SCM, and/or e-commerce systems
-     The ability to effectively estimate work effort, create integrated project schedules, and function as a PM
-     Excellent verbal and written communication skills with the ability to create documentation and present to a varied audience

Responsibilities:

-     Provide leadership toward the evolution of an SOA based Enterprise Architecture
-     Design and develop SOA solutions and act as the lead architect on multiple enterprise projects, with hands-on development and management responsibilities
-     Provide expert knowledge on integration projects to the business and technical teams
-     Formulate standards, guidelines, methodologies and best practices for enterprise integration across the IT enterprise portfolio.
-     Work with various service delivery teams providing input for strategic initiatives that may require integration with internal systems and/or external solutions
-     Ensure IT governance and SOA best practices are being applied across the organization
-     Continue to monitor technology development and solution opportunities that support the overarching Enterprise Architecture Strategy
-     Lead and mentor more junior team members, as well as educate the broader IT organization
-     Evaluate products and vendor solutions against well defined evaluation criteria and make recommendations to the business

Aunque el Proyecto Fin de Carrera de una Ingeniería Técnica no suele ser de grandes dimensiones siempre es bueno adquirir buenas costumbres desde el principio.

Como ya escribí en esta entrada anterior, fijar los objetivos y una planificación, son buenos hábitos a la hora de desarrollar proyectos.

Cuando el proyecto se trata de software, buenos hábitos son: Organización con UML, Código Limpio y Claro, y Documentación.

UML (Lenguaje Unificado de Modelado) es una de las formas más conocidas de organizar el software en base a procesos, métodos, funciones, etc.

La idea es utilizar diagramas para representar un problema y su solución, de esta forma creamos una especie de mapa del software donde tenemos cómo funciona o como queremos que funciones paso a paso. Crear archivos UML de tu programa te puede ayudar a no perderte en él, a poder mejorarlo después de un largo abandono, o incluso hace más fácil obtener ayuda de otras personas.

Un programa multiplataforma (GNU/Linux, Windows y Mac) para trabajar con diagramas UML es Dia.

AutoDia es un programa que lee el código fuente de tu programa y crea archivos listos para ser editados con Dia, siendo un complemento muy útil para Dia.

La documentación es importante para un programa informático, ya no sólo para saber cómo funciona, sino para saber cómo se usa. Los programas con interfaz gráfica suelen ser fáciles de usar y no necesitan apenas explicación, pero a veces, dependiendo de la aplicación los iconos no dejan tan claro cual es su función y necesitamos recurrir a la ayuda. Más aún en los programas que no tienen interfaz gráfica (programas en consola) ya que no sabemos qué parámetros debemos pasarle, ni la forma.

Un programa que nos permite consultar esto en GNU/Linux es el comando man. Por ejemplo, al escribir en consola: man openoffice nos saldrá la documentación de cómo usarlo, y nos dice que para usarlo por consola el comando es ooffice, que es una suite ofimática, autores, etc.

Gracias a Doxygen podemos crear páginas man para nuestro programa, además de documentación en HTML o en PDF. En el siguiente blog podéis ver cómo configurar Doxygen.

If you are a developer you’ve seen the Use Case Diagram before and you were able to understand how the system works even without knowing about what use case diagram is or how to create it. That’s exactly the purpose of it. It ensures the requirements of the client is met. It helps to show the client, in an easy to understand diagrammatic representation, on how the system to be developed is going to work.

Use Case Diagrams are only a part of the UML (Unified Modeling Language)

Now you can learn to create Use Case Diagram in this series of video tutorials I found on web. The tool used in these video tutorial is “Visual Paradigm for UML“. There is a free community edition of the tool available for download too.

If you pick up any reference article or book on requirements engineering, I think you’ll find that most “experts” in the field don’t obsess over “shalls”. They know that there’s much more to communicating requirements than writing down tidy, useless, fragmented, one line “shall” statements. If you don’t believe me, then come out of your warm little cocoon and explore for yourself. Here are just a few references:

http://www.amazon.com/Process-System-Architecture-Requirements-Engineering/dp/0932633412/ref=sr_1_3?ie=UTF8&s=books&qid=1257672507&sr=1-3

http://www.amazon.com/Structured-Development-Real-Time-Systems-Introduction/dp/0138547874/ref=pd_rhf_shvl_1

http://www.amazon.com/Software-Requirements-Second-Pro-Best-Practices/dp/0735618798/ref=sr_1_1?ie=UTF8&s=books&qid=1257635918&sr=1-1

http://www.amazon.com/Mastering-Requirements-Process-Suzanne-Robertson/dp/0321419499/ref=sr_1_1?ie=UTF8&s=books&qid=1257635979&sr=1-1

With the growing complexity of software-intensive systems that need to be developed for an org to remain sustainable and relevant, the so-called  venerable “shall” is becoming more and more dinosaurish. Obviously, there will always be a place for “shalls” in the development process, but only at the most superficial and highest level of “requirements specification”; which is virtually useless to the hardware, software, network, and test engineers who have to build the system (while you watch from the sidelines and “wait” until the wrong monstrosity gets built so you can look good criticizing it for being wrong).

So, what are some alternatives to pulling useless one dimensional “shalls” out of your arse? How about mixing and matching some communication tools from this diversified, two dimensional menu:

• UML Class diagrams
• UML Use Case diagrams
• UML Deployment diagrams
• UML Activity diagrams
• UML State Machine diagrams
• UML Sequence diagrams
• Use Case Descriptions
• User Stories
• IDEF0 diagrams
• Data Flow Diagrams
• Control Flow Diagrams
• Entity-Relationship diagrams
• SysML Block Definition diagrams
• SysML Internal Block Definition diagrams
• SysML Requirements diagrams
• SysML Parametric diagrams

Get over it, add a second dimension to your view, move into this century, and learn something new. If not for your company, then for yourself. As the saying goes, “what worked well in the past might not work well in the future”.

I am using an AS3 framework at the moment which allows you to create custom Value Objects. A colleague here pointed me in the direction of a UML generator that can take all the pain out of writing VO classes with multiple getters and setters. All you do is generate your uml page with the classes, variables and methods you want, press generate and then BOOM – it spits out all the stub code for you. I found a good blog post about how to set this up on digitaldogbyte.com, link follows:-

http://www.digitaldogbyte.com/?p=3

I just finished (100% of course <-LOL!) my latest software development project. The purpose of this post is to describe what I had to do, what outputs I produced during the effort, and to obtain your feedback – good or bad.

The figure below shows a simple high level design view of an existing real-time, software-intensive, revenue generating product that is comprised of hundreds of thousands of lines of source code. Due to evolving customer requirements, a major redesign and enhancement of the application layer functionality that resides in the Channel 3 Target Extractor is required.

The figure below shows the high level static structure of the “Enhanced Channel 3 Target Extractor” test harness that was designed and developed to test and verify that the enhanced channel 3 target extractor works correctly. Note that the number of high level conceptual test infrastructure classes is 4 compared to the lone, single product class whose functionality will be migrated into the product code base.

The figure below shows a post-project summary in terms of: the development process I used, the process reviews I held, the metrics I collected, and the output artifacts that I produced. Summarizing my project performance via  the often used, simple-minded metric that old school managers love to use; lines of code per day, yields the paltry number of 22.

Since my average “velocity” was a measly 22 lines of code per day, do you think I underperformed on this project? What should that number be? Do you summarize your software development projects similar to this? Do you just produce source code and unit tests as your tangible output? Do you have any idea what your performance was on the last project you completed? What do you think I did wrong? Should I have just produced source code as my output and none of the other 6 “document” outputs? Should I have skipped steps 1 through 4 in my development process because they are non-agile “documentation” steps? Do you think I followed a pure waterfall process? What say you?

]]> http://expanz.wordpress.com/2009/11/11/the-journey/ Wed, 11 Nov 2009 02:15:10 +0000 Matt Clarke http://expanz.wordpress.com/2009/11/11/the-journey/

towards a world class rapid application development / deplyment platform…

Prospects, customers, users, developers, designers, disbelievers oftern ask me, “how the heck did you guys build your platform and what was the thinking and the processbehing it’s evolution?”

This post is an attempt to try and answer that question;

Fundamentally, the expanz team believe the software development world needs to adopt a paradigm shift similar to the manufacturing world’s transition from a factory model to an assembly line model.

The gains in quality and reductions in development cost and effort would outweigh those in the manufacturing world as no physical materials are actually consumed during production – everything is abstract.

When object oriented technology was first invented, this was its promise, but I think you’d agree OO has miserably failed to deliver on that promise.

The risk with our approach was that the assembly line was simply unachievable as many large companies have spent considerable effort and money towards achieving this goal, although indirectly. There are several known and unknown (don’t you what you don’t know) issues, such as performance, missing platform/language features etc that could prevent the software assembly line from becoming reality.

Attempting something this radical would require a non standard and carefully monitored process.

Plenty of unknowns and risks… Would performance be good enough?

We decided to have a crack and are glad we did.

The solution of course must be scalable. We threw away the stateless model (I can hear you sceptics down my broadband connection) and embraced a stateful application server model, for both ease of end user development and more importantly performance. We built a [stateless] web service facade, a load balancer that only load balances on login (session creation) and an application server to house our code. Off to a nice start…

The core design patterns were envisaged and used in a lightweight walkthrough. Next, code was filled out and simple apps were built, starting with a non-persistent calculator.

Then we added persistence and complex persistence – relationships. This was an absolutely crucial phase of development. To achieve a true assembly line pattern, we could not use explicit collections. There was no way a class could ‘ask’ a child (a many in a 1-many relation) to iterate through itself in a reusable way if held a declared collection of that class. We had to design it so that all relationships were implemented as a single declared instance. This was probably the key single breakthrough that allowed us to continue towards our goal. Every object/class had to satisfy both single instance and set operation requirements.

Since progress was good and all theory still held up, we decided to upscale our experiment as far as we could. We decided to build an ERP system – yes, we are gluttons for punishment.

This would prove our platform, from a utility, performance and code reduction perspective (we achieve code normalisation), as ERP systems are generally considered rigid. We could, through an assembly line paradigm, provide complete customisation at very low cost/effort to an ERP customer – exact fit ERP, now there is a foreign concept.

As development of our assembly line paradigm continued, another opportunity emerged.

Due to the embodiment of the best practice rule of complete separation of the presentation layer from the functional layer (e.g. abstraction), it was hypothesised that multiple client designs and technologies could simultaneously access a single server without any server modifications.

This would mean that a Windows form, a browser form, a Flash form and even a mobile phone could all access the same [server] functionality at virtually zero development effort – only the cost of designing the UI.

We set about abstracting the communications protocol into a set of interfaces, and implemented those for Windows Forms and WPF, those being two technologies we were familiar with and both based on c#. Apart from a steep learning curve for some of the WPF features we required (and a general lack of available expertise) it was ultimately successful.

Next target was a mobile device, as this would be useful in the ERP system for warehouse operations. The MS .NET Compact Framework (CF) has matured to the point where it was only a few days of effort to port the full Windows Forms plumbing to the CF. We rapidly enhanced the set of Interfaces we designed earlier to cope with device-specific hardware such as cameras and barcode/RFID readers.

Finally, to overcome deployment issues (the latest .NET installed on a client PC was a caveat) we decided to embrace the Adobe Flex/Flash technology. We found some local expertise which was commissioned to adapt the standard algorithms and interfaces into ActionScript – the Adobe language. We ultimately had the need to put this into production (after some simple prototypes) for a property inspection and reporting automation system we built on top of the ERP.

We also required a handheld (mobile) device to do barcode scanning and printing for EDI orders (as a full production quality module) which was successfully developed and deployed into large Australian supermarkets and retailers.

All the while, no server code changes were required for any platform-specific technology…

(original post)

The UML (Unified Modeling Language) has a number of extremely useful system tools, essential for any architect or information systems professional needs of application documenting requirements. “States machines” diagrams are part of its behavior modeling, and those who have more evolved from early versions up to the current version of UML 2.2 (-2/2/2009).

However, in the field of the administration-oriented applications generally based on electronic documents that change States primarily by interaction with users; a Machine States Diagram exceeds the possibilities of modeling and using a subset of items is enough to give a valuable contribution on designs. So let me define these basic guidelines of diagrams construction we can call “States diagrams” to differentiate them from his big brother “States machines chart”.

To do this we use the following basic elements, whose definition are exactly the same UML 2.2, and to which I refer to not extend this article:

• Initial state: black circle.
• Final State: concentric circle.
• Status: edges rounded rectangle.
• Transition: Unidirectional arrow.

The rules for chart it are detailed below:

Diagrama de Estados tipo

• A diagram applies only to an electronic document and absolutely contains all States which can passing.
• There is only an initial state and only one final by diagram and they are only “virtual”. This means that they do not correspond to real States themselves but are qualifiers of States directly attached to them .
• A State which only leave arrows fall outside any, are initial and are always connected to the initial state node(State 1 in the example) .
• A State which only reach arrows but doesn’t leave any, are final and are always connected to the final State node(State 3 and 4 State in the example) .
• Arrows are always drawing vertical and/or horizontal, avoiding the diagonal; provided that do not hard the reading of the diagram.
• Arrows that reach a State will do so by the top and the emerging will from the bottom; trying to prevent lateral fittings if no obstacle the reading of the diagram.
• States will always have a synthetic and representative name.
• Transitions can lead a name but it is not strictly necessary.

These elements and rules are very elemental, but this simplicity is its power; and that I will be explaining in successive post.

(tiny)

Documentation rest/sphinx

Guido Van Rossum

- http://neopythonic.blogspot.com/2009/11/python-in-scientific-world.html (‘...After the meeting, Fernando showed me a little about how NumPy is maintained. They have elaborate docstrings that are marked up with a (very light) variant of Sphynx, and they let the user community edit the docstrings through a structured wiki-like setup. Such changes are then presented to the developers for review, and can be incorporated into the code base with minimal effort.

Saludos o/

Bueno comenzaré el primer articulo de mi blog con un trabajo universitario que hice hace poco, el tema del trabajo es sobre la Herramienta CASE conocida con el nombre de Umbrello UML Modeller.
Bueno, aqui les dejo mi trabajo.

@thomasrecloux @ThibaudVibes pour moi l’#uml, sur les projets agiles, doit devenir un langage pour communiquer avant tout et non pour concevoir (ingénierie)… sauf pour le modèle statique (et plus particulièrement les classes persistantes).
Mais toute la partie du langage UML traitant de la “dynamique” applicative doit être oubliée, sauf encore une fois pour illustrer et communiquer sur un problème particulier.
Je mettrais une exception à tout cela : si on se base sur les modèles pour générer du code ; la ok… et encore sur la partie diagramme de classe uniquement. Mais bon n’est ce pas utopique encore une fois, de faire du MDA ? je me pose la question, avec les DSL peut être pas… en tous cas si UML il y a dans l’avenir, ce sera avec le MDA… mais c’est un autre débat!
En tous cas je suis curieux de retour d’expérience de projets agile utilisant pleinement UML.

The figure below is a “bent” UML (Unified Modeling Language) class diagram of a standard corpo CCH (Command and Control Hierarchy). Association connectors were left off because the diagram would be a mess and the only really important relationships are the adjacent step-by-step vertical connections. Each box represents a “classifier”, which is a blueprint for stamping out objects that behave according to the classifier blueprint. The top compartment contains the classifier name, the second compartment contains its attributes, and the third compartment houses the classifier’s behaviors. Except for the DIC Product Development Team, the attributes of all other classifiers were elided away because the intent was to focus on the standard cookie-cutter behaviors of each object in the “system”. Of course, the org you work for is not an instantiation of this system, right?

Please send all resumes to rrabines@topsource.com

Must be: Citizen, Green Card or EAD

Location: Miami, FL
Salary: High on Experience
Status: DIRECT HIRE

The Java Application Architect will work across teams to design, develop, and deploy business driven solutions consistent with the Enterprise Architecture strategy. The candidate will drive the evolution of a Service Oriented Architecture (SOA) by developing SOA based solutions spanning all layers of the SOA software stack, including but not limited to, service enablement of legacy systems, Enterprise Service Bus (ESB) based integration, Business Process Management (BPM), and SOA Management & Governance. The Jave Application Architect will be a middleware and integration expert chartered with developing mission-critical enterprise software solutions, for enterprise modernization and integration projects. This technical leadership position will require a deep understanding of modern SOA standards, integration patterns, and Web technologies. This person will also be required to map and model business processes, as well as manage integrated project schedules. The Java Application Architect will develop a deep understand of both the business architecture and technical architecture.

Requirements:

-     BS or higher in Computer Science, Computer Engineering, or Electrical Engineering
-     At least 10 years developing object oriented enterprise software solutions in Java
-     At least 12 years applying OOA/D techniques to architect and implement software solutions
-     At least 6 years using J2EE Application Servers and Java enterprise application frameworks
-     At least 4 years as a lead SOA architect working on enterprise integration projects
-     Experience with the full software development life-cycle and various software methodologies such as RUP and Agile approaches
-     Skilled at modeling with UML, as well as requirements capture and business process mapping
-     At least 4 years hands-on experience on enterprise modernization and integration projects employing ESB based SOA solutions
-     Extensive hands-on experience at all layers of the SOA solutions stack, including but not limited to: ESB, BPM, Business Rules, Workflow, SOA Governance & Management, Security & Identity Management, and Portal Development
-     Web Services and Standards Expert
-     Have used/implemented JMS, Message Oriented Middleware, Event Driven Architectures, & Complex Event Processing solutions
-     Project experience with service enabling legacy systems, assembling composite service enabled applications, and applying a wide-range of enterprise integration patterns
-     Experience creating a data services and management architecture for enterprise information integration, developing information models, XML and database schemas
-     Strong SQL skills and experience with one or more database systems
-     Knowledge/experience with various operating systems: Linux, Windows, and/or AS 400
-     First-hand experience developing SOA solutions for CRM, ERP, SCM, and/or e-commerce systems
-     The ability to effectively estimate work effort, create integrated project schedules, and function as a PM
-     Excellent verbal and written communication skills with the ability to create documentation and present to a varied audience

Responsibilities:

-     Provide leadership toward the evolution of an SOA based Enterprise Architecture
-     Design and develop SOA solutions and act as the lead architect on multiple enterprise projects, with hands-on development and management responsibilities
-     Provide expert knowledge on integration projects to the business and technical teams
-     Formulate standards, guidelines, methodologies and best practices for enterprise integration across the IT enterprise portfolio.
-     Work with various service delivery teams providing input for strategic initiatives that may require integration with internal systems and/or external solutions
-     Ensure IT governance and SOA best practices are being applied across the organization
-     Continue to monitor technology development and solution opportunities that support the overarching Enterprise Architecture Strategy
-     Lead and mentor more junior team members, as well as educate the broader IT organization
-     Evaluate products and vendor solutions against well defined evaluation criteria and make recommendations to the business