#software engineering and data structures

[lodiwayoflearning]

Not the Right Method

By Felipe Lodi

Seaports are a special segment for IT Professionals to work in, mainly because they look forward to use the latest technologies. More than this, they need that to survive. But being international trading the finality of their business is a contradictory point that commonly these technologies lack their best adoption, therefore they require further methodology than normal.

In a Seaport, every second earlier you can load a Container means a second earlier the vessel will unberth. Several different types of technology are applied on cranes, trucks, in personnel, in the offices and processes need to be tied to the tight predefined schedules.

For nine long years I worked for one of the biggest ports in Brazil. Before getting important assignments, some technical tasks were improving my knowledge in this arena. I could join several projects from kick-off meetings until production, as well some of those projects I could see them “dying” making room for new technologies.

I had the opportunity to create an integrated product to improve many manual existing procedures. To understand the whole concept of this suite of applications I have built, it is important to brief a bit about Seaport Operations.

The unit to be transported on the vessels is called Container. Although any type and size of cargo is also transported overseas, for the sake of this explanation, I will stick with the concept of the “box” Container. (They also have several types, sizes and formats). Every Container has a loading port and a destination port. Inside the Container, different types of goodies may require special care and storing.

And in the end is all about where to store and how to store that will make the difference at the best Seaports in the world. Technology is directly related to that.

As mentioned before, a contradictory point in this case means that a bad choice for methodology might lead the Project to unsuccessful late deliveries or even failing. The main challenge on the beginning was to integrate the needs from the main three teams of the Company: The Documentation Team which had the task of all system imputing dealing with the Customs too. The Organizational Team which had the responsibility to properly store by port of destination, size, type and weight the Containers on the yard. And the Operational Team that had to fetch the pre-organized Containers from the yard and load into the vessels.

During the analysis phase, several interviews took place and the first UML diagrams and Use Cases were introduced. Although the language in those documents was very clear, was quite hard to the focal points to understand as well to get into some sort of common decision.

Many solutions were proposed by me to their typical problems but still, move forward to the design phase was quite a challenge. Thus I changed to the Flowcharts instead. Boxes, conditionals and arrows linking processes were clearer to them and finally the design phase could start.

But I faced a new problem to translate in depth the Flowcharts to the developers in my design documents. A hybrid solution of Use Cases and Flowcharts was customized and attached to the architectural design, the development phase could start.

During the development, changes on current operational procedures often happened. It was very hard to maintain the documentation “alive” even though the parties were very interested on having updates from it. Due to political changes, we were asked to adapt our application to different procedures testing them during the development. As new technologies such as mobiles being used by personnel and inside trucks and cranes were really new to some of them, the test phase took place even before the application had been finished. This has broken all methodology.

Months later I wasn’t able to keep the documentation up to date. I have started to make some sort of reverse engineering on documentation. My routine in joining new analysis meetings to the algorithms was not doing well. Tests in field have brought options to the staff and as far as I could see, the best suitable choices were made though. The development running in several different streams was integrated due to my efforts and knowledge of this particular business.

Then the solution could be used in production. In the end the documentation was updated after the late delivery, manuals were deployed and training has been made to the staff.

This was a real scenario where methodology couldn’t be applied integrally. It has been proven later that lack of decision, mixed phases, streams and improper support from sponsors featured this application as difficult to maintain and perform upgrades.

Some bad results could be noticed in slow and failing operational procedures. Later on the Company has opted by buying a third party solution, as they realized that development in place requires discipline, starting from the Board of Directors.

[lodiwayoflearning]

Skipping Queues and Stacks

By Felipe Lodi

Starting with the analogy made by Glenn where he compares a queue with a structure of a buffer where the tasks to be processed are inserted in a temporary queue at the tail to be forwarded in the order in which they appear at the head, (Brookshear, 2009, p.374) My understanding says that processes are stored in this manner for performance reasons.

In a multitask processing where we have the impression that the tasks are being executed at the same time, this structure helps to keep track of priority, although the queue mentioned above is created as result of a pre evaluated priority list where the items are inserted at any place within the list, in the case of a computer, based on whether or not the task has to hold for another one. When they are in route of execution then they are inserted at the tail of the queue called buffer.

Glenn defines both: “A queue is a list in which the entries are removed only at the end and new entries are inserted only at the tail. An example is a line, or queue, of people waiting to buy tickets at a theater…A stack is a list in which entries are inserted and removed only at the head. An example is a stack of books where physical restrictions dictate that all additions and deletions occur at the top” (Brookshear, 2009)

Trying to imagine this event of hold (or please skip me as I am waiting for a friend) in a queue or even a stack, I could not figure out how it would work as they obey very well defined methods of insertion and deletion. Technically speaking, the right terms would be pushing and popping.

Therefore no room can be made inside queues or stacks for any more important task nor can any task let itself to be skipped. The right data structure to represent priority tasks would be linked lists In this case.

Contiguous memory cells can store the details of the task as well as the pointer to the next task. They don’t need to be physically ordered in memory as they have reference to the task that has the bigger priority. Thus the task that has a null pointer reference is the task to be executed.

Insertions and deletions can occur just changing the pointers of the involved tasks. A high priority task would be physically inserted in column major order with a null pointer to the next task being referenced as pointer to the old high priority task. Skipping (for holdings purposes) would occur in a very similar way just change the pointers.

REFERENCES LIST

Brookshear, J.G., 2009. Operating Systems. In Computer Science an Overview. 10th ed. pp.374, 373.