What are the things we can do using Linux that we can't do with MS Windows?

I have thought about this subject this recently.
I don't have just one answer. I compiled a list of things I thought of and emailed it to myself...
Then I thought I would post it to the blog for future reference.
Feel free to add to the list or post any commands!
There is also a forums thread on the same topic, that I remembered as I complied my thoughts, so I stole some of the ideas posted there so this one is not a very creative post in my own ;)

1. Upgrade to the newest version legally and without paying money
2. Have the latest version of the operating system run faster than the previous version on the same hardware
3. Easily install and run different graphical interfaces if I don't like the default setup
4. Install twenty programs with one command
5. Have the system automatically update all my installed programs for me.
6. Install the same copy of my OS (Pardus) on multiple computers without worrying about license restrictions or activation keys
7. Give away copies of the operating system and other programs that run on it without breaking any laws, governmental or ethical or moral, because it was all intended to be used this way
8. Have full control over my computer hardware and know that there are no secret back doors in my software, put there by malicious software companies or governments
9. Run without using a virus scanner, adware/spyware protection, and not reboot my computer for months, even when I do keep up with all of the latest security updates
10. Run my computer without needing to defragment my hard drive, ever
11. Try out software, decide I don't like it, uninstall it, and know that it didn't leave little bits of stuff in a registry that can build up and slow down my machine
12. Make a major mistake that requires a complete reinstallation and be able to do it in less than an hour, because I put all of my data on a separate partition from the operating system and program files
13. Boot into a desktop with flash and effects as cool as Windows Vista on a three year old computer...in less than 40 seconds, including the time it takes me to type my username and password to login
14. Customize anything I want, legally, including my favorite programs. I can even track down the software developers to ask them questions, contribute ideas, and get involved in the actual design/software writing process if I want to
15. Have 4+ word processor windows open working on papers, listen to music, play with flashy desktop effects, have contact with a largely happy community and have firefox, instant messaging, and email clients all open at the same time, without ever having had to beg someone for a code to make my os work, and without the system running so slow it is useless
16. Use the command "dpkg --get-selections > pkg.list" to make a full, detailed list of all software I have installed, backup my /etc and /home directories on a separate partition, and you are able to recover your system any time, easily
17. Run multiple desktops simultaneously, or even allow multiple users to log in and use the computer simultaneously
18. Resize a hard disk partition without having to delete it and without losing the data on it
19. Use the same hardware for more than 5 years before it really needs to be replaced...I have some hardware that is nearly 10 years old, running Linux, and still useful
20. Browse the web while the OS is being installed!
21. Use almost any hardware and have a driver for it included with the operating system...eliminating the need to scour the internet to find the hardware manufacturer's website to locate one
22. Get the source code for almost anything, including the OS kernel and most of my applications

I could go on, but that's long enough, you may let the steps ascend :)

How to Recognise a Good Software Developer

How do you recognise good programmers if you’re a business guy in IT sector?

It’s not as easy as it sounds. CV experience is only of limited use here, because great programmers don’t always have the “official” experience to demonstrate that they’re great. In fact, a lot of that CV experience can be misleading. Yet there are a number of subtle cues that you can get, even from the CV, to figure out whether someone’s a great programmer.

I consider myself to be a pretty good programmer. At the same time, I’ve spent a fair amount of time on the business side of the fence, filtering technical CVs for projects, interviewing people, etc. Thanks to this, I think I have a bit of experience in recognising good programmers, and I want to share it in this article, in the hope that it may help other “business guys” to recognise good programmers. And, who knows, perhaps some programmers who have the potential to be good but haven’t really exploited this can also read this and realise what they need to do to become good (although, as I’ll argue, that’s definitely not accessible to all programmers!).

In his article The 18 mistakes that kill startups, Paul Graham makes the following point, i'd like to give some interesting parts of my research:

“… what killed most of the startups in the e-commerce business back in the 90s, it was bad programmers. A lot of those companies were started by business guys who thought the way startups worked was that you had some clever idea and then hired programmers to implement it. That’s actually much harder than it sounds—almost impossibly hard in fact—because business guys can’t tell which are the good programmers. They don’t even get a shot at the best ones, because no one really good wants a job implementing the vision of a business guy.

In practice what happens is that the business guys choose people they think are good programmers (it says here on his resume that he’s a Microsoft Certified Developer) but who aren’t. Then they’re mystified to find that their startup lumbers along like a World War II bomber while their competitors scream past like jet fighters. This kind of startup is in the same position as a big company, but without the advantages.

So how do you pick good programmers if you’re not a programmer? I don’t think there’s an answer. I was about to say you’d have to find a good programmer to help you hire people. But if you can’t recognize good programmers, how would you even do that?”

I disagree with Mr Graham on this one. I think there are a number of very strong indicators of a “good programmer” (and, conversely, strong indicators of a “not-so-good programmer”) that even a business guy can recognise. I’ll summarise some key indicators and counter-indicators in a list at the end of the article.

#1 : Passion

In my corporate experience, I met a kind of technical guy I’d never met before: the career programmer. This is a person who’s doing IT because they think it’s a good career. They don’t do any programming in their spare time. They’re shocked when they find out I have a LAN and 3 computers at home. They just do it at work. They don’t learn new stuff unless sent on a training program (or motivated by the need to get a job that requires that technology). They do “programming” as a day job. They don’t really want to talk about it outside of work. When they do, they talk with a distinctive lack of enthusiasm. Basically, they lack passion.

I believe that good developers are always passionate about programming. Good developers would do some programming even if they weren’t being paid for it. Good programmers will have a tendency to talk your ear off about some technical detail of what they’re working on (but while clearly believing, sincerely, that what they’re talking about is really worth talking about). Some people might see that as maladapted social skills (which it is), but if you want to recognise a good developer, this passion for what they’re doing at the expense of social smoothness is a very strong indicator. Can you get this guy to excitedly chat up a technology that he’s using, for a whole half hour, without losing steam? Then you might be onto a winner.

#2 : Self-teaching and love of learning

Programming is the ultimate moving target. Not a year goes by without some new technology robbing an old, established standard blind and changing half the development universe. This is not to say that all good programmers pick up these changes and ride the bleeding edge. However, there’s a class of programmers that will never, ever pick up a new technology unless forced to, because they don’t like learning new stuff. These programmers will typically have learnt programming at university, and expect to get by on whatever skills they picked up there, plus whatever courses their company is willing to send them on.

If you’re thinking of hiring someone as a programmer, and he ever utters the words “I can work with that, just send me on a training course for a week and I’ll be good at it”, don’t hire that guy. A good programmer doesn’t need a training course to learn a new technology. In fact, the great programmer will be the one talking your ear off about a new technology that you haven’t even heard of, explaining to you why you must use it in your business, even if none of your staff knows how to use it. Even if it’s a technology he doesn’t know how to use yet.

#3 : Intelligence

Some business people assume that lack of social tact and lack of intelligence are the same. Actually, intelligence has several facets, and emotional/social intelligence is only one of them. Good programmers aren’t dumb. Ever. In fact, good programmers are usually amongst the smartest people you know. Many of them will actually have pretty good social skills too. The cliché of the programmer who’s incapable of having a conversation is just that - a cliché. I’ve been to a few meetings of the London Ruby User Group and I can say that with only a very few exceptions, most people there are smart, talkative, sociable, have varied interests, etc. You wouldn’t look at them chattering away in the pub and think “what a bunch of geeks!” - at least until you approach a group and realise they’re talking about the best way to design a RESTful application with a heavy UI frontend.

This doesn’t mean that they’ll all feel comfortable in every social context. But it does mean that if the context is comfortable and non-threatening enough, you’ll be able to have as great a conversation with them as you would with the most “socially enabled” people (perhaps better, since most good programmers I know like their conversation to revolve around actually useful topics, rather than just inane banter).

Don’t ever hire a dumb person thinking they’re a good developer. They’re not. If you can’t have a great conversation with them in a relaxed social context, they’re very likely not a good programmer. On the other hand, anyone who’s clearly very smart at the very least has a strong potential to be a good or great programmer.

#4 : Hidden experience

This is correlated with the “Passion” point, but it is such a strong indicator that I’d like to emphasise it with its own point.

I started programming when I was about 9, on a Commodore 64. I then migrated onto the PC, did some Pascal. When I was 14 I wrote a raycasting engine in C and Assembler, spent a large amount of time playing with cool graphic effects that you could get your computer to do by messing directly with the video card. This was what I call my “coccoon stage”. When I entered that stage, I was a mediocre programmer, and lacked the confidence to do anything really complicated. When I finished it, I had gained that confidence. I knew that I could code pretty much anything so long as I put my mind to it.

Has that ever appeared on my CV? Nope.

I strongly believe that most good programmers will have a hidden iceberg or two like this that doesn’t appear on their CV or profile. Something they think isn’t really relevant, because it’s not “proper experience”, but which actually represents an awesome accomplishment. A good question to ask a potential “good programmer” in an interview would be “can you tell me about a personal project - even or especially one that’s completely irrelevant - that you did in your spare time, and that’s not on your CV?” If they can’t (unless their CV is 20 pages long), they’re probably not a good programmer. Even a programmer with an exhaustive CV will have some significant projects that are missing from there.

#5 : Variety of technologies

This one’s pretty simple. Because of the love of learning and toying with new technologies that comes with the package of being a “good programmer”, it’s inevitable that any “good programmer” over the age of 22 will be fluent in a dozen different technologies. They can’t help it. Learning a new technology is one of the most fun things a programmer with any passion can do. So they’ll do it all the time, and accumulate a portfolio of things they’ve “played around with”. They may not be experts at all of them, but all decent programmers will be fluent in a large inventory of unrelated technologies.

That “unrelated” bit is the subtle twist. Every half-decent java programmer will be able to list a set of technologies like “Java, J2EE, Ant, XML, SQL, Hibernate, Spring, Struts, EJB, Shell scripting”, etc.. But those are all part of the same technology stack, all directly related to each other. This is possibly hard to recognise for non-programmers, but it is possible to tell whether their technology stack is varied by talking to them about it, and asking them how the different technologies they know relate to each other. Over-specialisation in a single technology stack is an indicator of a not-so-good programmer.

Finally, if some of those technologies are at the bleeding edge, that’s a good positive indicator. For instance, today (November 2007), knowledge of Merb, Flex, RSpec, HAML, UJS, and many others… Please note that these are fairly closely related technologies, so in a couple of years, someone who knows all these will be equivalent to someone familiar with the Java stack listed in the previous paragraph.

Update: As a clarification to this point, there’s in fact two indicators here: variety and bleeding edge. Those are separate indicators. A good variety of technologies across a period of time is a positive indicator, whether or not the technologies are bleeding edge. And bleeding edge technologies are a positive indicator, whether or not there’s a variety of them.

#6 : Formal qualifications

This is more a of non-indicator than a counter-indicator. The key point to outline here is that formal qualifications don’t mean squat when you’re trying to recognise a good programmer. Many good programmers will have a degree in Computer Science. Many won’t. Certifications, like MCSE or SCJP or the like, don’t mean anything either. These are designed to be accessible and desirable to all. The only thing they indicate is a certain level of knowledge of a technology. They’re safeguards that allow technology recruitment people in large corporations to know “ok, this guy knows java, he’s got a certification to prove it” without having to interview them.

If you’re hiring for a small business, or you need really smart developers for a crack team that will implement agile development in your enterprise, you should disregard most formal qualifications as noise. They really don’t tell you very much about whether the programmer is good. Similarly, disregard age. Some programmers are awesome at 18. Others are awesome at 40. You can’t base your decisions about programmer quality on age (though you might decide to hire people around a certain age to have a better fit in the company; please do note that age discrimination is illegal in most countries!).

As a final note to this, in my experience most average or poor programmers start programming at university, for their Computer Science course. Most good programmers started programming long before, and the degree was just a natural continuation of their hobby. If your potential programmer didn’t do any programming before university, and all his experience starts when she got her first job, she’s probably not a good programmer.

Disclaimer

None of the indicators above or below are sure-fire indicators. You will find great programmers who break some of those moulds. However, my view is, you’ll rarely find a great programmer that breaks all of them. Similarly, you may find poor programmers that meet (or appear to meet) some of these criteria. But I do strongly believe that the more of these criteria a programmer meets, the more likely they are to be one of those elusive “good programmers” that, as a business guy, you need to partner with.

The criteria in bullets

So, in summary, here are some indicators and counter-indicators that should help you recognise a good programmer.

Positive indicators:

• Passionate about technology
• Programs as a hobby
• Will talk your ear off on a technical subject if encouraged
• Significant (and often numerous) personal side-projects over the years
• Learns new technologies on his/her own
• Opinionated about which technologies are better for various usages
• Very uncomfortable about the idea of working with a technology he doesn’t believe to be “right”
• Clearly smart, can have great conversations on a variety of topics
• Started programming long before university/work
• Has some hidden “icebergs”, large personal projects under the CV radar
• Knowledge of a large variety of unrelated technologies (may not be on CV)

Negative indicators:

• Programming is a day job
• Don’t really want to “talk shop”, even when encouraged to
• Learns new technologies in company-sponsored courses
• Happy to work with whatever technology you’ve picked, “all technologies are good”
• Doesn’t seem too smart
• Started programming at university
• All programming experience is on the CV
• Focused mainly on one or two technology stacks (e.g. everything to do with developing a java application), with no experience outside of it

I hope these help. Let me know below if you have any comments, or anything to add to them!

A Summary of an Experience From a developer expert in 10 different programming languages! = Mhtare

This post is the short guide of the Prashant N Mhatre who supports teams about stock markets and in some bugs about database management systems as an advisor. I hope it would be very helpfull for new programming language learners..

"Since I’ve working knowledge of a bunch of programming languages but job demands to learn a new language frequently in a short time. Instead of reading hundreds manual/book pages, I quickly read 10-15 pages of tutorial or primer. (As you know google is the best search engine to look for such stuff). I keep printed copy of the language syntax reference card handy. (There are many reference cards available over internet. Type in ’language to learn’ + ’reference card’ in google.)

First of all, get familiar with Compiler, compiler option, editor shortcuts or integrated development environment (IDE). Start with a simple ’Hello World’ program. Compile it. Use basic functionalities of debugger like setting break points, printing variable values, moving to the next or specific position, stopping debugger etc.

To grasp basics of a new language quickly, here are the exercises I use. Remember some programs may not good for beginners.

(1) Display series of numbers (1,2,3,4, 5....etc) in an infinite loop. The program should quit if someone hits a specific key (Say ESCAPE key).

(2) Fibonacci series, swapping two variables, finding maximum/minimum among a list of numbers.

(3) Accepting series of numbers, strings from keyboard and sorting them ascending, descending order.

(4) Reynolds number is calculated using formula (D*v*rho)/mu Where D = Diameter, V= velocity, rho = density mu = viscosity Write a program that will accept all values in appropriate units (Don’t worry about unit conversion) If number is <>

(5) Modify the above program such that it will ask for ’Do you want to calculate again (y/n), if you say ’y’, it’ll again ask the parameters. If ’n’, it’ll exit. (Do while loop)

While running the program give value mu = 0. See what happens. Does it give ’DIVIDE BY ZERO’ error? Does it give ’Segmentation fault..core dump?’. How to handle this situation. Is there something built in the language itself? (Exception Handling)

(6) Scientific calculator supporting addition, subtraction, multiplication, division, square-root, square, cube, sin, cos, tan, Factorial, inverse, modulus

(7) Printing output in different formats (say rounding up to 5 decimal places, truncating after 4 decimal places, padding zeros to the right and left, right and left justification)(Input output operations)

(8) Open a text file and convert it into HTML file. (File operations/Strings)

(9) Time and Date : Get system time and convert it in different formats ’DD-MON-YYYY’, ’mm-dd-yyyy’, ’dd/mm/yy’ etc.

(10) Create files with date and time stamp appended to the name

(11) Input is HTML table, Remove all tags and put data in a comma/tab separated file.

(12) Extract uppercase words from a file, extract unique words

(13) Implement word wrapping feature (Observe how word wrap works in windows ’notepad’)

(14) Adding/removing items in the beginning, middle and end of the array.

(15) Are these features supported by your language: Operator overloading, virtual functions, references, pointers etc.

Is there something called ’namespace / package / module’ supported by your language? (Name mangling)"

Goodluck everybody, email me for any problems rarely..

Development Cycle in an IT Company: Internet Management Software - Important Section under Business Alignment

Development process that the guys in this team followed in the last project was completely a focusable one, our new software doesn't just appear on the shelves by magic. That program shrink-wrapped inside the box along with the indecipherable manual and 12-paragraph disclaimer notice actually came to you by way of an elaborate path, through the most rigid quality control on the planet. Here, shared for the first time with the general public, are the inside details of the program development cycle.

1. Programmers in the team produces code he believes is bug-free.
2. Product is tested. 20 bugs are found.
3. Programmer fixes 10 of the bugs and explains to the testing department that the other 10 aren't really bugs.
4. Testing department finds that five of the fixes didn't work and discovers 15 new bugs.
5. See 3.
6. See 4.
7. See 5.
8. See 6.
9. See 7.
10. See 8.
11. Due to marketing pressure and an extremely pre-mature product announcement based on overly-optimistic programming schedule, the product is released.
12. Users find 137 new bugs.
13. Original programmer, having cashed his royalty check, is nowhere to be found.
14. Newly-assembled programming team fixes almost all of the 137 bugs, but introduce 456 new ones.
15. Original programmer sends underpaid testing department a postcard from Fiji. Entire testing department quits.
16. Company is bought in a hostile takeover by competitor using profits from their latest release, which had 783 bugs.
17. New CEO is brought in by board of directors. He hires programmer to redo program from scratch.
18. Programmer produces code he believes is bug-free....

Note: Rather than thinking the good jobs are made by Europeans or Americans, we should just belive that a better can easliy be reached..

UML ile Yazılım Modelleme - Software Modeling with Unified Modeling Language

Daha onceki projelerde kullandığım ve Imagine Cup 2008 - HCA Software Design Projesi kapsamında yapmayı planladığımız "UML ile Yazılım Modellenmesi" hakkında genel bilgilendirme amacı güden bir yazıdır..

Modelleme kanıtlanmış ve kabul edilmiş bir mühendislik tekniğidir. Model sayesinde karmaşık bir gerçeği daha basit bir dille ifade etme şansımız olur; böylece modellediğimiz gerçeği daha iyi anlayabilir, hataları yolun başında görebiliriz. Aynı gerçekler yazılım için de geçeridir, özellikle büyük ve karmaşık yazılımlar için modelleme, büyük bir bina için mimari planın (blueprint) gerekliliği kadar vazgeçilmez bir olgudur.

Yazılım modellenmesi sayesinde sistem gereksinimlerini ve sistem davranışlarını daha iyi anlarız ve hata riskimiz azalır. Yazılım yaşam döngüsü içinde hatalar ne kadar erken saptanırsa düzeltme maliyeti de o kadar az olur. Çok karmaşık sistemler için bitmiş bir kodda 1 satırlık bir değişiklik yapmanın maliyeti zaman ve risk açısından çok yüksektir. Bu sebeple sistemi doğru anladığımızdan emin olmamız gerekir, bunu da ancak modelleme sayesinde yapabiliriz.

Büyük yazılım projelerinde proje yöneticileri, müşteriler, çözümleyiciler, tasarımcılar, programcılar, testçiler ve teknik yazarlardan herbirinin eğitim düzeylerinin ve alt yapılarının farklı olması kaçınılmazdır, biz burada yazılım kısmı olarak 2 yada 3 kişi olarak çalışacağız ki yukarıdaki bu birçok alanı içine alıcak işler yapıcak bu kısım. Roller farklı olunca bir ekibin elemanlarının birbirleri ile iletişiminin önemi de ortaya çıkar. Çözümleyicilerin aylar süren görüşmeler sonunda elde ettikleri bütün bilgileri yazılı olarak tasarımcıya veya teyid alabilmek için müşteriye verdiğini düşününebiliyor musunuz? Oysaki sistem, çözümleyici tarafından müşteriye, tasarımcıya veya testçiye hepsinin anladıkları ortak bir dille modellenirse, çok karmaşık anlatımlar basitleşebilir ve iletişim metin ile desteklenen çeşitli diyagramlar ile maksimum düzeyde tutulabilir. Böylece müşteri sistem gereksinimleri raporunu okurken veya teknik yazarlar kullanıcı kılavuzu yazarken veya test senaryoları hazırlanırken bu ortak dilden faydalanılmış olur.

Tasarımcı, çözümleyicinin hazırladığı bazı diyagramları detaylandırıp teknik açıdan kodlamanın yolunu açabilir. Bütün bunlar projelerde yazılım kalitesini artırmanın yanı sıra, proje ekibindeki eleman değişikliğinde yeni elemanların sistemi kolayca kavrayamamasından kaynaklanacak zaman kaybını, yani maliyeti de düşürecektir.

Her yazılımın modellenmesi için mükemmel olan tek bir yöntem yoktur. Bir şirket için mükemmel olan bir modelleme yöntemi diğeri için berbat olabilir. Yapılan işin niteliğine göre farklı diyagramlara ihtiyaç duyulacaktır. Modellemede önemli olan yazılım sektöründeki herkesin ortak bir dili kullanmasıdır olmalıdır. Doğal olarak da her tür ihtiyaca cevap verebilir nitelikte bir modelleme diline ihtiyaç vardır. Müziği düşünecek olalım, 8 notayı bir araya getirerek muhteşem bir eser yaratabiliriz. Yarattığımız eseri ister flüt ile çalarız ister piyanoyla, çaldığı müzik aleti ne olursa olsun orkestranın her elemanı aynı dili anlamaktadır. Sonuçta müzik, nota dediğimiz sembollerin çeşitli şekillerde bir araya gelerek bir bütünü oluşturması ve dünyanın her köşesinde anlaşılabilir bir dilde ifade edilmesidir. Müziğin güzelliği ise besteyi yapanın yeteneğiyle sınırlıdır. Yazılım sektörü için de yazılımın parçalarını ifade edecek modelleme dili müziğin notaları gibidir. Sistemin mükemmelliği, sistemi tasarlayanların yetenekleriyle, bilgi ve tecrubeleriyle ilgilidir.

UML'ye gelince, Unified Modelling Language yazılım mühendisliğinde nesne tabanlı sistemleri modellemede kullanılan açık standart olmuş bir görsel modelleme dilidir. Büyük ve karmaşık sistemleri modellemede başarısı kanıtlanmış mühendislik tecrübeleriyle oluşmuştur. UML'nin yazılım mühendisliğindeki yerini anlayabilmek için tarihçesine söyle bir bakalım:

1989-1994 yılları yazılım mühendisliğinde Metod savaşları olarak bilinen dönemdir. Bu dönemde 50'den fazla modelleme dili paralel bir şekilde aynı şeyleri farklı yöntemlerle ifade ediyorlardı. Herbiri bazı sistemler için mükemmelken, bazıları için işe yaramaz durumdaydı ve hemen hemen hepsi yazılım yaşam döngüsünün bazı adımlarını tanımlamakta yetersiz kalıyordu. 90'lı yılların ortalarına doğru en çok tercih edilen 3 yöntem ön plana çıktı: Booch, OMT (Object Modelling Technology) ve OOSE (Object Oriented Software Engineering). Bunlardan Booch, tasarım ve gerçekleştirim konusunda mükemmeldi. OMT analiz ve veri yoğunluğu çok yüksek olan sistemlere uyuyordu. OOSE ise Use-Case adı verilen bir modelleme yöntemi ile tüm sistemin davranışını kolayca anlamayı sağlayan güçlü bir teknik içeriyordu.

1994 yılında OMT'nin yaratıcısı Jim Rumbaugh, Rational firmasının çatısı altında Booch metodunun yaratıcısı Grady Booch ile birlikte çalışmaya başladı. Daha sonra 1995'de onlara OOSE'nin yaratıcısı Ivar Jacobson da katıldı. 3 Amigolar olarak bilinen bu grup kendi yöntemlerinin olumlu taraflarını birleştirerek, komple bir yazılım projesinde sistemi modellemede kullanılabilecek eksiksiz bir modelleme dili geliştirmeye başladılar. Microsoft, Oracle, HP gibi büyük firmaların da katıldığı bir UML konsorsiyumu kuruldu ve bu şirketler UML'yi modellemelerinde kullanmaya başladılar. Nihayet 1997'de OMG (Object Management Group, kar gütmeyen, bilgisayar endüstrisi standartlarını oluşturan bir organizasyon ) UML'yi sahiplendi ve açık standart olarak geliştirmeye başladı. Doğal olarak UML herhangi bir şirkete veya kişiye ait bir modelleme dili değildir. UML şu an Rational, MS Visio, Together Soft,.. vb birçok modelleme aracı tarafından sunulmaktadır., bizde bu ortamlardan biri ile tasarım aşamasındaki en büyük adımımızı atacağız.

Yazılımın yaşam döngüsü içinde farklı görev gruplarının projeye ve sisteme farklı bakışları vardır. Müşteriyi hangi işin hangi sırayla yapılacağı, sisteme neler verip sistemden neler alacağı veya işler arası ilişkiler ilgilendirirken bir fonksiyonun detayları ilgilendirmemektedir, Çözümleyici açısından bir nesnenin özellikleri, fonksiyonları ve alacağı parametreler yeterli iken tasarımcı açısından parametrelerin veri tipleri veya fonksiyonun ne kadar bir sürede cevap üretmesi gerektiği, bir nesnenin ne zaman etkin olacagi, yaşam süresi gibi bilgiler de önemli olmaktadır. Teknik yazar ise sistemin nasıl davranacağı ve ürünün işleyişi ile ilgilenmektedir. Bu sebeplerle UML çeşitli bakış açılarını ifade eden diyagramlar içermektedir. Projeye dahil olan herkesin faydalanacağı bir veya daha fazla diyagram vardır. Yazılım geliştirme işinde rol alan kişileri özetleyecek olursak: Çözümleyiciler, tasarımcılar, programcılar, testçiler, kalite sorumluları, müşteriler / kullanıcılar, teknik yazarlar. Bunlardan her biri sistemin değişik yönleriyle farklı bakış açılarıyla ve farklı detayda ilgilenirlerken farklı UML diyagramlarından faydalanırlar.

Sistem gereksinimlerinin anlatılmasında Use-Case diyagramlar kullanılır. Bu diyagram sistemin çok basit bir şekilde modellenmesini ve işlerin detayının (senaryonun) metin olarak anlatılmasını içerir, sistemin işleyişini anlattığı için de yukarda listelenen rollerden hepsinin sıklıkla başvuracağı bir diyagramdır.

Kavramsal (conceptual) model dediğimiz Class diyagramları, gereksinimlerin müşteriye özetlenmesinde kullanılabildiği gibi, asıl olarak tasarımda kullanılmaktadır. Class diyagramları, bazı detayları saklanmış şekilde müşteri-çözümleyici iletişimini desteklerken, detaylı haliyle de tasarımcıya ve programcıya hitap etmektedir. Class diyagramların tasarımı ilgilendiren kısmı oldukça kapsamlıdır, nesne tabanlı sistemlerin doğru tasarlanması tamamen tasarımcının tecrübe ve bilgisi ile ilgilidir, bu sebeple tasarlanacak class diyagramlarında, inheritance (türetme), abstract class'lar, class hiyerarşileri, kullanılacak design pattern'lar gibi detayların düşünülmesi gerekmektedir. Bu noktada UML'nin "doğru tasarım nasıl yapılır?" sorusuna cevap vermediğini sadece bir modelleme dili olduğunu tekrar belirtmek gerekir. Sistemin performansı veya gelecekte yüzleşeceğimiz güncelleme ve bakım sorunları, yazılan kodun başka projelerde veya ek modüllerde yeniden kullanılabilir olması (code reuse) gibi detaylar tasarımcı açısından çok önemli olmalıdır. Nesne tabanlı sistemlerde doğru tasarım yöntemleri başlı başına incelenmesi gereken bir konudur.

Colloboration Diyagram dediğimiz nesneler arası etkileşim ve işbirliği diyagramları, nesneler arası akan verileri ve bunların zamana bağlı numaralanmış akış sırasını ifade eden diyagramlardır. Sequence Diyagram ise işbirliği diyagramının ifade ettiği şeyin aynısını bir zaman çizgisi üzerinde farklı bir gösterimle ifade etmektedir. Bu iki diyagram (colloboration ve sequence diyagramlar) biri hazırlanınca diğeri otomatik üretilebilen diyagramlardır.

State Diyagramları (Durum Diyagramları) ise nesnelerin durum değişikliklerini ifade etmekte kullanılırlar, trafik ışıklarının renkler arası geçişi gibi, bir nesneye ilişkin durum değişiklikleri bu diyagramlar ile ifade edilir.

Package Diyagramları (Paket Diyagramları) büyük yazılımlarda sistemi oluşturan alt yazılımlar veya etkileşimde bulunulan yan sistemler olduğu durumda bu paketler arası etkileşimi gösteren kısaca sistem mimarisinin paket yönünü özetleyen kavramsal bir diyagramdır.

Component Diyagramları (Bileşen Diyagramları) ise Paket diyagramlarının fiziksel anlatımıdır. Basitçe paketler yerine, paket içinde yer alan .dll, exe gibi dosyaları ve bunlar arası etkileşimin gösterildiği bir diyagramdır. Paket diyagramlar sistemin analizi ve tasarımı aşamasında kullanılabilirken Bileşen diyagramları programlama bittikten sonra sistemi tarif eder niteliktedir.

Deployment Diyagramları (Dağıtım Diyagramları) yazılımın nasıl dağıtılacağının planlandığı aşamada yardımcı olurlar. Yazılımın kurulacağı bilgisayarların konfigürasyonu, ağ ve yazıcı bağlantıları gibi detayları kapsamaktadır.

Yukarda kısaca anlatılan diyagramlar sayesinde büyük bir yazılımın yaşam döngüsü içinde her adımı kapsayan, ve sisteme çeşitli gözlerden bakış açısı sunan bir modelleme tekniği olarak UML günümüzün nesne tabanlı bir yazılım projesinin paydaşlarını konuşturan en kapsamlı ve en basit ortak dildir düşüncesini taşıyorum.