Posts Tagged ‘Software Design’

First look at SparxEA

1 Comment »

Yesterday I was on an introduction course on Sparx Enterprice Architect which seems to be a quite competent tool. I like that they have collected all types of modeling, UML, Process, Class and DB into one tool. You can integrate it with versions controls like Subversion and TFS. It really feels like the modulation programs have got a bit further than just the drawing programs like Visio. I use to reverse engineer database diagrams and entity relationships diagrams with Visio and tried that with Sparx EA and it worked fine. The threshold seems to be a bit higher then with Rational Rose or Visio, but often that means it more productive as soon you learned the tool.

One nice function was that it was real easy to export everything to HTML in order to publish the whole model for other that don’t have SparxEA. It’s seems to be a great tool for documenting and modeling complex solutions. I will definitely learn more about SparxEA. Here is a brief introduction if you are curious: http://www.sparxsystems.com.au/resources/demos/eaoverview/index.html

You can try SparxEA for free in 30 days which gives you plenty of time to learn this tool.


Design is about handling Complexity

Comments Off on Design is about handling Complexity

In order to handle complexity, software is designed in layers and modules. When a programmer is worrying about the details design of one module, there are probably hundreds of other detail that he cannot possibly worry about at the same time so in order just have to deal with a few parameters at the time the solution have to be divided in different building blocks that have their own intention. Design is made on a high-level (also known as “solution architecture”) are about dependency management where different aspects is divided, which things have a dependency and where shall different functions be grouped together.

And design is made on a low-level like how will this algorithm be implemented. If high-level of software design is a map of how the solutions is organized it will not be complete until it has been coded and tested. Testing is a fundamental part of the design validation and refinement process. So design is an every ongoing process and can’t be frozen like in a bridge building project. The more complex a solution is the more important it becomes to have a good architecture that helps you tangle with the complexity. You need to be stricter with modulation and coding standards when you need to collaborate with a lot of others.

 

I got a small project why not just code?

Over the years I learned that just start hacking might be quite rewarding, because you feel enthusiastic you like to get down to business direct. This habit might be hard to break, and are often addictive because you get to start with fun things. You can choose to make a minimal design but taking the time plan your work will save you a lot of waste because otherwise you will need to redo things. When you plan it becomes easier to estimate the coding and testing. A plan also helps you address high risk so that these can mitigated as much as possible, for instance by starting work on prototypes to investigate technology that is not well understood. A plan also makes it possible to evaluate the eventual software against important goals as maintainability, robustness, reusability or consistency with the company strategy, before coding starts.

 

How much high-level design (architecture) shall we do?

It’s hard to answer how much planning of solution that shall be done. It depends on each case, but the main drivers are “how well the requirements are documented and understood” and how many people that will involve.

 

 

 

So what can design be, here are some examples:

  • Basic structure, which parts shall be grouped together, so that they can be isolated and controlled by them self.
  • A block-diagram-level structure, broken into smaller components units.
  • An analysis of the dynamics of the system in use (message, data-flow or sequence diagrams).
  • Map relationships between the units.
  • Plan precondition and post conditions.
  • Detail user interface layout.