Modeling software is an expensive activity. Building software models can be expensive for a multitude of reasons. The most obvious being the time lost for unsuccessful designs. Software models take time to put together. Unless you are sketching, the goal being to not spend a lot of time on them. Contrast this with a failed initial software implementation with no up-front modeling. There is a high probability of reusable software components that may be salvaged from the failure. Developers tend to become fixated on functional software. If something that at least somewhat functional comes out of a disaster, it will still help with morale.
So, if detailed modeling has no place in up-front software development, does it have any place in software development? Creating a detailed model of an existing software system may prove valuable. The key to modeling existing software systems is to pin-point exactly where the design has gone wrong. This is nearly impossible to spot during initial development. Especially under time constraints when the priority of design takes a back seat in favor of a functional system.
The obvious drawback to up-front modeling in software development is that promotes a waterfall approach. The waterfall approach doesn't work as well as an iterative and incremental approach, if at all. This doesn't mean you shouldn't be spending any time modeling, it means any up-front models created should be treated as informal at best. Perhaps it makes more sense to not even call them models because that suggests a level of formality we want to stay away from initially. Simple diagrams treated as sketches are a good practice to follow early on.
Formal models of software systems created after the system in question has been deployed in a real environment can prove valuable. The reason for this being that you have a functional system that is relatively stable. This is because after a system has been deployed for a while, hundreds if not thousands, of smaller bugs have been eliminated. These are the types of bugs that a software model isn't likely to solve in a timely manor. With the smaller issues mostly removed, we are free to tackle larger design issues that aren't easily solved with code.
One of the first things you might want to model are the dependencies between the packages and modules that make up the system. I've tried this before and was amazed at the problems I was able to see before even trying to model inheritance between classes. When you have several dependency lines crossing one another, it just looks bad. This is often a reflection of a sub-optimal design. The poorly painted picture provides quite the motivation to fix these issues. The same goes for class hierarchies. The relationships among the elements in the system, not just inheritance, are worth modeling. The value of modeling the details of each element isn't as high. Encapsulation also applies to software models to a certain degree.
Showing posts with label modeling. Show all posts
Showing posts with label modeling. Show all posts
Sunday, May 2, 2010
Friday, April 23, 2010
Designing Code
Designing code is one of the most essential jobs of a programmer. That is, programmers do more than just design code. They also write it, document it, and read it. Hence, the term writing code. You never hear a programmer say they're going to spend some time designing code. It is writing code that matters. You could design software for several months and it wouldn't make a world of difference in the mind of a programmer. If no code has been written, no progress has been made.
This is where programmers actually are designing, while they are writing code. When they are sitting there with an editor open, they can see what needs to happen in order to solve the problem at hand. In fact, it is even easier for programmers to debug existing code rather than start from scratch and right something completely new. There is something about code that enables us to see structural and behavioral design and that serves as a reference in our mind.
But every programmer has a different logical representation of the system at hand in their own mind. Two perfectly acceptable solutions to a given problem may be completely incorrect to two opposing programmers. How can this be? Even in the same programming language, two wildly differing solutions are available to solve the same problem. The problem is that in software development, the problem at hand is never just the problem given to us. There are too many environments in the computer universe in which software may run.
These problems given to programmers to solve are only the half of it. The stakeholders really don't care that system X doesn't support interpreter Y and therefore cannot use language feature Z. Programmers will find a way around these limitations. But the problem is that unless you are the programmer doing the implementation, you really can't wrap your head around the full details of implementing a full solution. It really comes down to the fundamental software development concept of having a separation of concerns. Stakeholders in software development projects don't necessarily need to know all the low-level implementation details. They just need to be aware that they exist.
This isn't always the case with stakeholders. Imagine you had an environment in which to implement their solution aligned with what the stakeholders sometimes envision; you write the code to solve their problem and there are no implementation surprises. In a scenario like that, writing code to directly solve their problem is a feasible approach. But that will most definitely not happen any time soon, if ever. So in the mean time, we are stuck dealing with implementation details that fall outside the scope of the business problem.
When programmers write code, they have two tightly-coupled problems. There is the problem of making the software do what it was intended to do, the business problem. There is also the problem of the the other, unforeseen implementation details, the implementation problem. When we begin to write code for the business problem, the implementation problem doesn't really exist yet. How can it? These are unanticipated problems. They don't come into being until you can see them. This makes sense to a certain extent because if you start thinking about potential implementation problems too much before some design activities have started, no code would ever be written.
So what is the real benefit to separating these two problems, if any? It doesn't seem very obvious what the exact benefit of separating the business problem from the implementation details is at first. But one problem with not doing so is apparent. Since implementation detail problems do not really exist until the code is being written, they often affect the business problem implementation once they come about. That is, if a programmer spends time designing some ideal code for the business problem, depending on how specific that design is, an implementation detail problem could put the whole design in jeopardy.
Since code is so tightly coupled with the implementation of a running system, a good way to represent the business problem is with a model. A model is not part of the running system but it is an artifact of the process used to create the running system. UML models are a good way to represent any given software system. They can show almost any level of detail one might be interested in seeing. There is, however, a similar problem with models. You have the ability to start getting into implementation details.
This goes to show that modeling your code before actually writing it isn't a magic way to fix your code design. The common problem with creating models is that they tend to evolve too quickly without writing any code. If the level of specificity in your model gets too high, you've not only taken a waterfall approach but you're also taking a risky path by assuming there will not be any seemingly small implementation issues. Models are a good way to start off the business domain model as long as they are general enough. The level of specificity cannot be too high before code is written. Even then, it doesn't need to delve into too much detail just for the sake of it. Model details are better left out until they become a requirement.
Now lets take a step back and think about this for a moment. We now have a business problem that we're going to solve with software. In order to build this software, we need to write code that will implement the solution to the business problem. We know that there are going to be changes because our computing environments are disparate enough that we has humans cannot predict exactly how our code will behave. In order to help distance our business problem from any potential implementation problems, we build a high-level model of the business problem.
We should now be all set to start coding and hope for the best, right? Starting to code is definitely the right answer. Hoping for the best suggests an uncontrolled level of uncertainty. This can be at least somewhat controlled by expecting unexpected implementation details. Remember that your code and your model will always change throughout iterations of the project. The model you build will also have some overlap with the implementation. This is necessary unless the stakeholders are only expecting a model of the software and not the software itself.
Once these implementation detail issues do exist, is it worth modeling these issues? Only if it is separated from the business problem within the model somehow. It might even make more sense to create a completely separate model for implementation details. But only if it adds value. Modeling the nuances of implementing software isn't an exact science because chances are, these same details will become irrelevant in five years.
To sum this all up, remember that there is value in upfront code design centered around the business problem at hand. This doesn't necessarily mean modeling, it could be as straightforward as prototyping a command line interface simply for the purpose of testing how well the abstractions in your domain work. Modeling does offer a visual design aspect that often cannot be gleaned from code itself.
This is where programmers actually are designing, while they are writing code. When they are sitting there with an editor open, they can see what needs to happen in order to solve the problem at hand. In fact, it is even easier for programmers to debug existing code rather than start from scratch and right something completely new. There is something about code that enables us to see structural and behavioral design and that serves as a reference in our mind.
But every programmer has a different logical representation of the system at hand in their own mind. Two perfectly acceptable solutions to a given problem may be completely incorrect to two opposing programmers. How can this be? Even in the same programming language, two wildly differing solutions are available to solve the same problem. The problem is that in software development, the problem at hand is never just the problem given to us. There are too many environments in the computer universe in which software may run.
These problems given to programmers to solve are only the half of it. The stakeholders really don't care that system X doesn't support interpreter Y and therefore cannot use language feature Z. Programmers will find a way around these limitations. But the problem is that unless you are the programmer doing the implementation, you really can't wrap your head around the full details of implementing a full solution. It really comes down to the fundamental software development concept of having a separation of concerns. Stakeholders in software development projects don't necessarily need to know all the low-level implementation details. They just need to be aware that they exist.
This isn't always the case with stakeholders. Imagine you had an environment in which to implement their solution aligned with what the stakeholders sometimes envision; you write the code to solve their problem and there are no implementation surprises. In a scenario like that, writing code to directly solve their problem is a feasible approach. But that will most definitely not happen any time soon, if ever. So in the mean time, we are stuck dealing with implementation details that fall outside the scope of the business problem.
When programmers write code, they have two tightly-coupled problems. There is the problem of making the software do what it was intended to do, the business problem. There is also the problem of the the other, unforeseen implementation details, the implementation problem. When we begin to write code for the business problem, the implementation problem doesn't really exist yet. How can it? These are unanticipated problems. They don't come into being until you can see them. This makes sense to a certain extent because if you start thinking about potential implementation problems too much before some design activities have started, no code would ever be written.
So what is the real benefit to separating these two problems, if any? It doesn't seem very obvious what the exact benefit of separating the business problem from the implementation details is at first. But one problem with not doing so is apparent. Since implementation detail problems do not really exist until the code is being written, they often affect the business problem implementation once they come about. That is, if a programmer spends time designing some ideal code for the business problem, depending on how specific that design is, an implementation detail problem could put the whole design in jeopardy.
Since code is so tightly coupled with the implementation of a running system, a good way to represent the business problem is with a model. A model is not part of the running system but it is an artifact of the process used to create the running system. UML models are a good way to represent any given software system. They can show almost any level of detail one might be interested in seeing. There is, however, a similar problem with models. You have the ability to start getting into implementation details.
This goes to show that modeling your code before actually writing it isn't a magic way to fix your code design. The common problem with creating models is that they tend to evolve too quickly without writing any code. If the level of specificity in your model gets too high, you've not only taken a waterfall approach but you're also taking a risky path by assuming there will not be any seemingly small implementation issues. Models are a good way to start off the business domain model as long as they are general enough. The level of specificity cannot be too high before code is written. Even then, it doesn't need to delve into too much detail just for the sake of it. Model details are better left out until they become a requirement.
Now lets take a step back and think about this for a moment. We now have a business problem that we're going to solve with software. In order to build this software, we need to write code that will implement the solution to the business problem. We know that there are going to be changes because our computing environments are disparate enough that we has humans cannot predict exactly how our code will behave. In order to help distance our business problem from any potential implementation problems, we build a high-level model of the business problem.
We should now be all set to start coding and hope for the best, right? Starting to code is definitely the right answer. Hoping for the best suggests an uncontrolled level of uncertainty. This can be at least somewhat controlled by expecting unexpected implementation details. Remember that your code and your model will always change throughout iterations of the project. The model you build will also have some overlap with the implementation. This is necessary unless the stakeholders are only expecting a model of the software and not the software itself.
Once these implementation detail issues do exist, is it worth modeling these issues? Only if it is separated from the business problem within the model somehow. It might even make more sense to create a completely separate model for implementation details. But only if it adds value. Modeling the nuances of implementing software isn't an exact science because chances are, these same details will become irrelevant in five years.
To sum this all up, remember that there is value in upfront code design centered around the business problem at hand. This doesn't necessarily mean modeling, it could be as straightforward as prototyping a command line interface simply for the purpose of testing how well the abstractions in your domain work. Modeling does offer a visual design aspect that often cannot be gleaned from code itself.
Labels:
code
,
design
,
modeling
,
programming
,
uml
Tuesday, January 26, 2010
Gaphor 0.15.0 Beta
Gaphor, the UML modeling tool written in Python, has a new release available. The 0.15.0 beta release has many enhancements and features but there are two notable fixes that make this beta release a worthwhile upgrade from the latest stable release.
The latest stable Gaphor release introduced an element editor dialog. This dialog was a nice enhancement because it freed up more space for the diagram canvas. However, it was painful to use if you have multiple desktop windows open. Trying to switch between windows was a hassle. This has been fixed by making the element editor a modal dialog that is part of the main Gaphor window.
Another huge improvement was made in the element editor dialog. It can now be re-sized. This doesn't sound like a big deal but if you wanted to work with a large class that has dozens of attributes and methods, you simply could not do it. Now you can.
The latest stable Gaphor release introduced an element editor dialog. This dialog was a nice enhancement because it freed up more space for the diagram canvas. However, it was painful to use if you have multiple desktop windows open. Trying to switch between windows was a hassle. This has been fixed by making the element editor a modal dialog that is part of the main Gaphor window.
Another huge improvement was made in the element editor dialog. It can now be re-sized. This doesn't sound like a big deal but if you wanted to work with a large class that has dozens of attributes and methods, you simply could not do it. Now you can.
Labels:
gaphor
,
improvement
,
modeling
,
python
,
uml
Saturday, January 9, 2010
Fear Of Modeling
Does the idea that there is a general fear of modeling software sound like a real problem? Or, is it simply a matter of practicality? In most circumstances, modeling software, either during implementation or before, isn't beneficial to the project. Practicality aside, there are many large software projects in existence today haven't had requirement of any formal modeling in order to succeed. This doesn't mean that these development teams responsible for these projects have a fear of modeling. It means that they were able to approach the problem at hand tackle in a timely, and predictable manor.
So what does cause a fear of modeling? There are far too many reasons that organizations as well as individual developers don't model the software they are building to give here. There are, however, some very generic reasons that most software goes without a model. The chief reason being a generalized fear of modeling. Not just the act of modeling itself, which is often a very enjoyable experience. This fear of modeling arises due to a number of inter-connected factors.
The technology exists today to model just about anything, including software. Impossibility has nothing to with the problem. Further, there are many professional developers who have at least a fundamental grasp of modeling standards. These models, using standardized notation or not, can be illustrated using old, legacy technology, pen and paper. Shocking.
If the project is slightly more important than something you might contribute to on the side, such as an open source project, it is probably a better idea to construct any software models with software. It is easier to communicate with others using these models. Particularly, it is very helpful to provide a repository that stores all models for a given project. Nothing is lost, neither good nor bad. We can still learn from bad models.
Getting back to the fear that is involved whenever modeling software in various development cultures. Is the fear of modeling restricted to those team members intricately entwined with the code? Absolutely not. Any activities that are executed by a team affect every team member. In other words, modeling software that is about to be implemented requires both time and effort. And and here is the mythical part, the produced models aren't usable by paying customers and aren't worth doing. In some cases, the argument that software models aren't worth doing do to timing and resource constraints holds some merit. Consider an getting a patch out to an already deployed system. In this scenario, getting the design right is hardly more important than keeping the customer.
Is it possible to convince managers that modeling the software you, as a team are building has value? Of course it is. What really helps here is being able to produce high-level, non-technical, big-picture models of the system in question. If managers feel that they can better understand what is being built, they can better relate to why other modeling activities help developers better understand the system. And that means your boss is more likely to view software models as a valid product artifact.
Developers are obviously the main beneficiary of software models. The purpose of a software model is to better understand a software system. That is it. There are endless ways in which a developer can better understand a system but when they do, it results in a better product. Developer's fear of modeling often stems from an emphasis on producing a large, complete, and correct model before implementation has begun. It is true that you should start modeling before you start coding but don't get carried away. You'll often get a sense of when it is time to test out an idea, in code, while modeling. Don't resist the urge to code while modeling and don't abandon the model once coding has started.
What should software development teams be using to model software with? The UML offers a coherent set of standardized software modeling constructs. The UML in and of itself can be a source for fear of software modeling. A common misconception of the UML is that the entire set of modeling elements should be used for any given project. This couldn't be further from the truth. Use only what you need. The other elements are there if, and only if, you need them. I would recommend that each development team member have a basic understanding of commonly used UML elements. Everyone can jot down ideas, pass them around, using a standardized notation. More advanced users can then merge ideas into more formal models if, and only if, they are needed.
Modeling is not importing a set of classes that have already been written as specific programming language instructions into some modeling software in order to produce a class diagram. While this can provide some useful insight into older systems that have already been implemented, doing this with newer systems misses the mechanical act of constructing a conceptual illustration. Modeling can have some hidden, subtle benefits.
Software modeling can be be hugely beneficial more many reasons. Although there is the illusion of lost productivity due to building models, these fears can be put to rest by putting software models to work. They aren't going to jump up and prove their own worth.
So what does cause a fear of modeling? There are far too many reasons that organizations as well as individual developers don't model the software they are building to give here. There are, however, some very generic reasons that most software goes without a model. The chief reason being a generalized fear of modeling. Not just the act of modeling itself, which is often a very enjoyable experience. This fear of modeling arises due to a number of inter-connected factors.
The technology exists today to model just about anything, including software. Impossibility has nothing to with the problem. Further, there are many professional developers who have at least a fundamental grasp of modeling standards. These models, using standardized notation or not, can be illustrated using old, legacy technology, pen and paper. Shocking.
If the project is slightly more important than something you might contribute to on the side, such as an open source project, it is probably a better idea to construct any software models with software. It is easier to communicate with others using these models. Particularly, it is very helpful to provide a repository that stores all models for a given project. Nothing is lost, neither good nor bad. We can still learn from bad models.
Getting back to the fear that is involved whenever modeling software in various development cultures. Is the fear of modeling restricted to those team members intricately entwined with the code? Absolutely not. Any activities that are executed by a team affect every team member. In other words, modeling software that is about to be implemented requires both time and effort. And and here is the mythical part, the produced models aren't usable by paying customers and aren't worth doing. In some cases, the argument that software models aren't worth doing do to timing and resource constraints holds some merit. Consider an getting a patch out to an already deployed system. In this scenario, getting the design right is hardly more important than keeping the customer.
Is it possible to convince managers that modeling the software you, as a team are building has value? Of course it is. What really helps here is being able to produce high-level, non-technical, big-picture models of the system in question. If managers feel that they can better understand what is being built, they can better relate to why other modeling activities help developers better understand the system. And that means your boss is more likely to view software models as a valid product artifact.
Developers are obviously the main beneficiary of software models. The purpose of a software model is to better understand a software system. That is it. There are endless ways in which a developer can better understand a system but when they do, it results in a better product. Developer's fear of modeling often stems from an emphasis on producing a large, complete, and correct model before implementation has begun. It is true that you should start modeling before you start coding but don't get carried away. You'll often get a sense of when it is time to test out an idea, in code, while modeling. Don't resist the urge to code while modeling and don't abandon the model once coding has started.
What should software development teams be using to model software with? The UML offers a coherent set of standardized software modeling constructs. The UML in and of itself can be a source for fear of software modeling. A common misconception of the UML is that the entire set of modeling elements should be used for any given project. This couldn't be further from the truth. Use only what you need. The other elements are there if, and only if, you need them. I would recommend that each development team member have a basic understanding of commonly used UML elements. Everyone can jot down ideas, pass them around, using a standardized notation. More advanced users can then merge ideas into more formal models if, and only if, they are needed.
Modeling is not importing a set of classes that have already been written as specific programming language instructions into some modeling software in order to produce a class diagram. While this can provide some useful insight into older systems that have already been implemented, doing this with newer systems misses the mechanical act of constructing a conceptual illustration. Modeling can have some hidden, subtle benefits.
Software modeling can be be hugely beneficial more many reasons. Although there is the illusion of lost productivity due to building models, these fears can be put to rest by putting software models to work. They aren't going to jump up and prove their own worth.
Labels:
development
,
fear
,
modeling
,
software
,
uml
Wednesday, October 21, 2009
ArgoUML Proof Of Concept
It has been a while in the making but the ArgoUML modeling tool has made available a development version of the 0.30.0 release. What is interesting here is that this development release, 0.29.1, will provide limited UML 2 support. Up until now there has only been UML 1.4 support in ArgoUML.
The ArgoUML software package has been around for quite some time and is relatively stable. The major roadblock for large scale ArgoUML adoption has been the lack of UML 2 support. The problem is that UML 2 has been the standard for many years now. The newer modeling constructs are gaining in popularity and if a tool doesn't support them, it is difficult to justify using it even if it has a great user interface with many other features.
The development version of ArgoUML that provides limited UML 2 support can be downloaded and used. It should not, however, be used in a production environment as is the case with any development release of any software. The model subsystem to use is specified by command-line arguments. No word on whether the UML 1.4 model will still be supported when ArgoUML 0.30.0 is released.
The ArgoUML software package has been around for quite some time and is relatively stable. The major roadblock for large scale ArgoUML adoption has been the lack of UML 2 support. The problem is that UML 2 has been the standard for many years now. The newer modeling constructs are gaining in popularity and if a tool doesn't support them, it is difficult to justify using it even if it has a great user interface with many other features.
The development version of ArgoUML that provides limited UML 2 support can be downloaded and used. It should not, however, be used in a production environment as is the case with any development release of any software. The model subsystem to use is specified by command-line arguments. No word on whether the UML 1.4 model will still be supported when ArgoUML 0.30.0 is released.
Labels:
argouml
,
modeling
,
proofofconcept
,
support
,
uml
Subscribe to:
Posts
(
Atom
)