Based in Denver, CO, Agile Ideation collects the thoughts and experiences of Ed Schaefer. His posts explore agile and devops related topics as he works to maximize team effectiveness and minimize waste through continuous learning, coaching and empowering teams.

UML and "Software Modeling"


1) In your own words, what does it mean to “model” software? 

Modeling software is simply the process of diagramming what the software needs to do and how it should work. This is very top level and fairly abstract. If you know a piece of software needs to facilitate 10 separate tasks, and each of those tasks requires specific inputs, processing of those inputs, and producing some sort of output, modeling allows all of these tasks and processes to be represented without any actual coding being done. This makes it possible to verify that all necessary processes are included, and easily add, remove, reorganize, or modify processes without painstakingly fixing actual code.


2) What value do you see in using a tool, such as UML, to do software modeling? What purpose does it serve?

UML is really no different from any other flowchart, but the benefit is that UML is a standard that can help ensure that modeling is consistent across a project. This also means that an individual working with one development team can move to another team, or even another software development firm, and be caught up more quickly and easily because they already understand the language used to explain the scope and requirements of a project. A very well developed UML can also, theoretically, be tied into a programming language and used to create a generalized framework and 'containers' to eliminate or simplify manual coding. It is important not to rely on UML too much, however; just as it may be impossible for a customer to provide the exact specifications and requirements for a software project before the project has even begin, UML may be useful in providing a generalized framework but not robust or dynamic enough (alternatively too limited) to keep up with changes at the code level.


3) Drawing from a real-life experience, what correlations, to the software modeling process, can you make from a particular non-software planning situation?

I can think of a number of examples.

In college I worked at Blockbuster and they were making some changes to the layout of the store. Before moving all the shelving and movies we diagrammed everything out. This gave us the flexibility to review it and change things before starting instead of increasing the amount of manual labor required to get everything how we wanted it.

Before a movie is made it is storyboarded out. This helps establish the framework for how the movie (or more specifically a scene) should progress, and even gives examples for how the shots should look. It would be very costly to continuously re-shoot to determine the framing for a shot, so this alleviates some of these challenges.

Another very basic example was when I was planning out my home theater system. Knowing what equipment I had and what connections were available I diagrammed the wiring to determine what I needed to purchase and how everything should be hooked up. This was especially helpful when I was installing wiring into the walls so I didn't have to make additional purchases or tear out everything and start over if it didn't meet my requirements.


Use Case Models - Uses Beyond Requirements?

Academic Authority of Information