Interesting mail-discussion going on with some colleagues at the moment… can you e.g. adhere to MDA using Simulink or, being an OMG initiative and all, is UML (or UML-like modeling-languages) implied. Personally I don’t think that MDA contains any prescriptive view upon which modeling language to use… but some fit the purpose better than others.
What do you think?
Visar inlägg med etikett UML. Visa alla inlägg
Visar inlägg med etikett UML. Visa alla inlägg
torsdag 25 mars 2010
fredag 4 december 2009
Why just UML?
The more I keep writing about xtUML the less I see any purpose to use UML2 when developing software. Granted that UML2 have a wider application-base to select from but as a concept UML without the stringent method of xtUML doesn’t seem complete anymore.
One problem persists though, which is connected to all graphical modeling and not just xtUML, there are still no applications out there that actually support you making better designs over time. The biggest hurdle in UML is still the fact that You have to make good class-diagrams and there is no perfect formula to what that is. Over time your models will grow large and erode if you aren’t careful.
A simple example of design support: In the "coding industry" an IDE without automated refactoring capabilities or a refactoring browser isn’t really a player even so you can’t find much about commercial modeling tools with such features. Why?
One problem persists though, which is connected to all graphical modeling and not just xtUML, there are still no applications out there that actually support you making better designs over time. The biggest hurdle in UML is still the fact that You have to make good class-diagrams and there is no perfect formula to what that is. Over time your models will grow large and erode if you aren’t careful.
A simple example of design support: In the "coding industry" an IDE without automated refactoring capabilities or a refactoring browser isn’t really a player even so you can’t find much about commercial modeling tools with such features. Why?
torsdag 1 oktober 2009
Architecture for the jilted generation
Riding my bike to work this morning through the pouring rain was excellent. The noise in my head from the Chinese water-torture going on with the rain dripping against my hoodie made me almost as creative as trying to sleep a late night.
The subject that keept me thinking so hard I almost don't remember the actual bike ride was architecture (ok I admit, this probably says a lot about me on a not-so-subconcious level).
How do one become an architect? What are the traits that we associate with the role? If we should post a job opening for architect what would be write? Some might say it is easy but is it really? For a discipline that we still seem to argue a bit about (how to deploy it and what it means) it surely can't be easy to recruit people to do it?
I think there are some interesting questions associated with the architecture role. For a SW-company would you even consider an architect without programming experience? I would guess not, or? What about an embedded-SW company delivering tangible consumer products such as cell phones, rockets or cars? I lean (no pun intened) towards a no but this is not so black&white in reality. What about other non-technical skills? Ever considered requiring pedagogy skills or offer that as training to an architect? Or should that be an innate skill? How about rethorical skills?
If you would hire a rookie straight from the Uni and show him the path towards becoming an architect what would that look like? In real life the system engineer often become the architect but does great system knowledge automatically mean that you are a strategist able to see the bigger picture?
Hm a lot of questions and not so many personal opinions. I'll take a stab at it:
* I think that architect shouldn't automatically imply promotion. It is a role with equal value to the system engineer, the coder, the tester.
* I think architect implies a certain personality, the person that can stand infront of an intersection and convince everyone to turn left.
* I think that an architect, whether it is a system architect or a software architect, should be able to "think programming" (some got it some don't, it is like e.g. philosophy... you can read a lot and learn philosophy but that doesn't mean you think philosophy... and I believe you can think philosophy without reading a lot).
* I think a system architect must have a commercial side being able to connect with product management and the market.
* I think an architect must have a skill-set that ables him/her to vizualise ideas.
So to shape the rookie I might suggest something like this straight of the bat:
- Work a bit where it happens, with the systems engineers and coders.
- Work a bit with testing. Everyone in our business should work with testing at some point.
- Learn e.g. UML
- If the existing architecture is e.g. modular with different concepts try to understand those
- Work a bit with project management
- Try to work a bit with the product management
The subject that keept me thinking so hard I almost don't remember the actual bike ride was architecture (ok I admit, this probably says a lot about me on a not-so-subconcious level).
How do one become an architect? What are the traits that we associate with the role? If we should post a job opening for architect what would be write? Some might say it is easy but is it really? For a discipline that we still seem to argue a bit about (how to deploy it and what it means) it surely can't be easy to recruit people to do it?
I think there are some interesting questions associated with the architecture role. For a SW-company would you even consider an architect without programming experience? I would guess not, or? What about an embedded-SW company delivering tangible consumer products such as cell phones, rockets or cars? I lean (no pun intened) towards a no but this is not so black&white in reality. What about other non-technical skills? Ever considered requiring pedagogy skills or offer that as training to an architect? Or should that be an innate skill? How about rethorical skills?
If you would hire a rookie straight from the Uni and show him the path towards becoming an architect what would that look like? In real life the system engineer often become the architect but does great system knowledge automatically mean that you are a strategist able to see the bigger picture?
Hm a lot of questions and not so many personal opinions. I'll take a stab at it:
* I think that architect shouldn't automatically imply promotion. It is a role with equal value to the system engineer, the coder, the tester.
* I think architect implies a certain personality, the person that can stand infront of an intersection and convince everyone to turn left.
* I think that an architect, whether it is a system architect or a software architect, should be able to "think programming" (some got it some don't, it is like e.g. philosophy... you can read a lot and learn philosophy but that doesn't mean you think philosophy... and I believe you can think philosophy without reading a lot).
* I think a system architect must have a commercial side being able to connect with product management and the market.
* I think an architect must have a skill-set that ables him/her to vizualise ideas.
So to shape the rookie I might suggest something like this straight of the bat:
- Work a bit where it happens, with the systems engineers and coders.
- Work a bit with testing. Everyone in our business should work with testing at some point.
- Learn e.g. UML
- If the existing architecture is e.g. modular with different concepts try to understand those
- Work a bit with project management
- Try to work a bit with the product management
Give this 5-10 years.
Prenumerera på:
Inlägg (Atom)