I am NOT an Information

Architect!
(But I want to be!)




UML OOAD AGILE DESIGN PATTERNS JAVA     VISUAL PARADIGM LONDON 

Hi, and welcome to a new blog.  My first blog.

We aim to explore the possibilities and limitations of business modelling tools, object-oriented analysis & design, and the UML.

We intend to go through the process of describing a real-life problem and developing a computer model.  This model resolves the business problem, by simulating the problem, as a working software model.

Our goal is  to be able to present a set of diagrams that, eventually, hold enough detail to be able to generate a software model.

Essentially, we are seeking to employ, fairly strictly, a number of tools and techniques to enable the modelling process:

VP UML GOF OOD Java

To varying degrees, I currently believe in all of them, and I hope that this blog might attract positive, perhaps knowledgeable readers, that might contribute to this project's success.

What I am

I am a traditional Analyst Programmer, by trade.  My background is in database development (MS Access!), and I have undertaken computer consultancy to major corporate and public sector clients.

At some point in the 90s, I studied Borland's Delphi.  OOD principles abound in Delphi but, at the time, I didn't really appreciate them.  The job market for Delphi was very small and so, my efforts waned.

In some consultancy work, I tried Ito employ UML to document development, to no great effect.

At that time, I had very little understanding of UML.

My development experience is almost exclusively on the Windows platform.  Over time, I have moved to become a user of Apple products, and this has undoubtedly opened my mind to developing for other platforms.  

What I am NOT

I am not an information architect.

I do not hold any significant experience of Java coding.

I am not an OO programmer.  When I reflect on my vast programming experience, I realize that I have only heard of Object-Oriented methods.  I have never employed any two OO methods together, intentionally.

I am not experienced in Agile development methods.

I have managed IT development projects, and have no formal project-management training or qualification.

Why I've chosen the tools I've chosen

VP - I was exploring the idea of analysing business requirement documents, to extract nouns and verbs, and use a word-cloud for similar reasons.  I thought that VP might do this but, it doesn't.  It does have textual analysis, but it's only about 60% good, and some basic features are poorly implemented.  VP does have code-generation to a number of languages, and a grand array of diagrams, that I've been unable to fully utilize, so far.

VP contains a wealth of features to store, enhance and share information.  As DVious is reapproaching the problem from scratch, it seems sensible to consider utilizing some of these features.  DVious is no longer trying to model a project mentally, as it were.  Having an audience, however small, forces DVious to be more principled about storing and sharing information.

The glossary is one example.  An image is universal, and the glossary has been enhanced, with the addition of graphics.

It might be useful to use VP's Flow-of-Events editor, to provide the model with a text-based sequence guide to interpreting the model.  If, indeed, the FoEE can be used in that way.  At the outset, DVious assumes that very few use case diagrams will be created and so, the FoEE may be of little benefit.

Other tools that we will, or might, utilise

Animacian - This VP tool may enable DVious to animate each iteration in the modelling process, providing little video sequences of the changes being applied.

Prezi - This online presentation suite has literally just come to the attention of DVious.  Might it, or some rival application, enhance the reader experience through the effective use of visual effects?

Java - A project aim is develop a platform-independent model.  However, we have chosen to use Java in order to prove the model, to the extent of producing a working software model.  Ask me another time why I stopped using MS C#, and dumped the whole Windows platform.

Netbeans - has a number of excellent features for the programmer, that work in tandem with VP.  And the price can’t be argued with!

UML - I was drawn to UML whilst studying PRINCE2, for project management.  I thought that UML might be a way of automating PRINCE2 processes, and it is.  It's also a great deal more than that, and, if clients can get with it, provides a largely great shorthand for describing systems and solutions. 

Me + blog + case study + You = Masterclass!

Hardly, but I do hope to pin down some the many website definitions for UML, in general. 

I do hope to ‘discover’ artifacts (you see, I’m learning UML’s language, already!), as a result of iterative, incremental analysis and development.

As important to my needs, I hope to develop and test in the same fashion.  My previous efforts failed to do so.

I hope to use object-diagrams to deliver my model.  Something new to me, I will create diagrams to model the ‘main’ code.  Previously, I have developed class-objects, and hand-written the static-code to manipulate them.

(does anybody strongly dislike this font, for any constructive reason?)

The DVious Approach to Modelling

UML has been chosen as our methodology, the language in which we model the problem, and drive prototyping.  We will produce a number of use case diagrams, and detail the objects that fulfill them. 

The project should be considered complete when it satisfies every use case, derived from the client interview.  Each use case details a requirement, therefore, satisfying the use case should satisfy the client.  The use case details the requirement, but not how to go about satisfying it.

We detail how the use case should be fulfilled by extending it, with a growing hierachy of diagrams.  These diagrams detail both the requirement, and  how to meet it.  

The hierarchy of diagrams will include the identified design patterns and UML diagrams, each asserting our understanding of the business problem, in increasing granularity.  The result is a model that continually evolves to resolve the problem, to the point of completion (so far as the use case goes).

DVious wishes to employ Agile development methods to deliver a working code model.  We should be mindful to move quickly to the point of delivering some  code, as a client of the Agile process might expect. 

Check the date!

This modelling project and blog began in earnest, on Tuesday, May 1, 2012.

I begin by creating a new blank project in Visual Paradigm, Enterprise Edition 9.0, entitled 'Crossroads.VPP'.

The Business Requirement

The client requires us to produce a prototype model of a pedestrian signal-crossing.  The model should demonstrate the interactions between real-world hardware components, and the network that supports them.

The model should simulate a pedestrian signal-crossing.

The Client-Interview

The client is no longer available for interview.  The interview document forms all we know of the business requirement.

It is a two-part document, with two aims:

To outline the pedestrian crossing-procedure; and to

Detail the network hardware and their interactions, as comprise the system.

The Glossary

A number of keywords are already present in the project glossary. 

In UML terms, they represent words that will make up a document of the system.

I used to think that ‘They represent the major domain elements that will be implemented and, can be added to the project model, as required.’

I now believe that they are the fundamental concepts and relationships that should be used to document the system.

The number of glossary terms will increase, as we add more detail to the model. 

The Project Start-point

The project start-point will be the creation of the primary use case.  The use case will be further detailed, using the Flow of Events Editor (FoEE) - Visual Paradigm enables us to set out our thinking, and the assumptions that underpin our plan.

The Primary Use Case

The first use case simply shows that the actor, a pedestrian, activates the crossing.  This, in turn, enables the crossing procedure to commence.

We can make an early comment on the use case diagram.  We have described another use case - The Crossing Procedure.  Here, we attempt to make a distinction between two systems: 

1. The Crossing Procedure, a fully automated system; and the extra effort required to
2. Activate the crossing, an extension that enables human input.  See Decorator Pattern.

First Analysis

A small understanding of design patterns suggests that some early effort should be made, to identify relevant  patterns, early on.

To this end, DVious has produced the artifact, ‘architecture overview’.  We will most likely employ these design patterns in the project.  The order in which these patterns will be developed, is loosely implied.

However, design patterns do provide an abstract and natural starting point for detailing the primary use case. 

Requirement - Complete the Flow-of-Events Editor

DVious has no experience of the FoEE.  We will complete the FoEE for the primary use case, drawing from the client interview to do so.  It is hoped that this document will provide a structure to subsequent analysis.

In order to quickly prove elements of the model to the client, we shall commence by modelling a single Light.  

Requirement - Detail a Light object, that can receive Power, controlled by a Relay.

The Flow-of-Events Editor

Having identified the general design patterns that will represent aspects of the system, we have a requirement to utilize another VP tool - the Flow-of-Events Editor.

DVious has no experience of the FoEE.  We will complete the FoEE for the primary use case, drawing from the client interview to do so.  It is hoped that the FoEE will provide a structure to subsequent analysis.

So, completing the FoEE, might be one of the first tasks to complete.  Or, at least, to start.

The Crossroads document

DVious has used VP’s Project Publisher in VP to summarise all that is known about the system.

This document will detail all UML artifacts (including model elements), as they develop.

Where DVious finds little useful things (such as the Phase, Discipline and Iteration fields, just now discovered), the  model will be updated.


The Crossroads document has been added, as a second post.  DVious is unsure of blogging etiquette, and whether that is how things are done.  Comments, please.