Software design is creative process. Design involves significant mental efforts towards creating new ideas or using existing ones for a purpose. Software does not exist before you design it. You, as a designer, play a role of The God. You make decisions about structure and behaviour of software-to-be-constructed.

Design is more of an invention and less of a discovery. As a creator, you may take guidance from other experienced creators or knowledge-base, but you must never forget that your design is primarily your creation and it is up to you to make final decisions about it during specific project, and be accountable for it as a designer.

And design is done, by definition, before construction. Note that design may be for a system, for a subsystem, for a component, for a class, for a method or for any other element. Sometimes you first construct software, then learn from software construction and then design a better one. Still, this better design will be meaningful only if it is implemented. In the most basic sense, designs are created for implementations. That is where painters are luckier than building architect. Both draw pictures of some sort. But architect’s drawing is called design as it is intended to be implemented. This essential property of design that, it is intended to be implemented, is called feasibility of design. Every design must be feasible to sufficient degree.

Any design can be subjectively judged for quality from judgement of how easily design can be implemented in a context. Obviously, judge’s skill and knowledge about both construction and design comes into picture. This make design evaluation two-folds.

1. Design must be fit for purpose sufficiently in a context or in other words, design must be sufficiently easy (ignore inherent complexities) to use for constuction for a context.
2. Design’s quality attributes may easily become subjective in practical situation of a specific project.

Overall, design is very context-sensitive activity. If you do not understand context of design, then you may end up taking inappropriate design decisions. Let us try to see what kind of contextual information you need to do good design.

Purpose: If you are not purposeful, either you will come up with design which will not serve its purpose or design will not allow constructors to produce software with proper quality attributes. Without purpose, you will not have any yardstick to measure success of design. This usually means your clarity about software developement lifecycle objectives.

Business: Beyond knowing verticals, you should be clear about your customer’s business and his expectations in context of a specific project.

Design Tools and Processes: Beyond knowing modelling platform e.g. UML & tools in combination with methodologies e.g. OOAD, you need to know contextual application to specific project after tweaking generic ideas.

Construction Platform: If you do not have good contextual information about construction platform, you may end up doing less feasible design.

Organization Platform: You will work for yourself or somebody else. Make sure you know ways of working within your organization or your project team or your immediate-colleagues team in such a way that your personal context is aligned with organizational context.

Any other project specific contextual information: This one is toughest, and this is what makes each project unique. This is where your creativity, communication and analytical abilities are tested. No matter what, each project has this and you have to unconver this context.

Summary in nutshell: Design is a contexual process.

You can utilize guidance from articles, knowledgebase, best practices, patterns, frameworks, consltants etc but finally, you have to apply all guidance according to your understanding of your context as a designer. You do not have to apply all generic things as they are. In a hindsight, you must have kept your brain on while you have applied generic ideas to your specific project!

Reasonably fast PC
(compiler, IDE, browser and db server etc to go fast)

As much RAM as possible
(PC should not slow down due to lack of RAM when RAM could be expanded)

Reasonably fast internet connection
(Not to watch movies, but to view self-learning videos etc)

Good keyboard and mouse
(Keys must not be stuck, standard KB design, working mouse clicking etc)

Great chair and table

Peaceful environment

Latest Development support tools
(IDEs, DBs, ORMs, Components, Libraries, etc)

Freedom to wear casuals

Freedom to have tea/coffee etc at table

Consistency: There are many way to describe it
* All nodes see the same data at the same time.
* Once a state is stored in the system, it will report the same state in every subsequent operation until the state is explicitly changed by something outside the system.
* A service that is consistent operates fully or not at all.
* In other way to say, atomic-ness is built-in to service.
Availability:
* The degree to which a system is operable and in a committable state at the start of a mission, when the mission is called for at random
* Node failures do not prevent survivors from continuing to operate
Partition Tolerance:
* The system continues to operate despite arbitrary message loss
* No set of failures less than total network failure is allowed to cause the system to respond incorrectly

In other words, though it is very desirable to have Consistency, Availability and Partition-tolerance in distributed system, unfortunately
no distributed system can achieve all three at the same time!

Pity!

Enjoy.

Here is minor, obvious, excogitated, concocted, devised example.
Imagine your best friend. He is having high temperature.
Would you try to cure him by making him take bath in cold water? Would you?!!

Think, buddy, think! Then act!

Triggers are basically “Side Effects” and too many of them will create complexity of understanding.
Triggers are “hidden” in data definition language (DDL).

Reason 1: Buggy triggers can create issues.

Any buggy code can create issues, but triggers have context to create tricky concurrency ones.
Triggers are fired even when transactions are rolled back. And that means, even if inserted rows rolled back, “after insert” triggers would have fired! If this fired triggers are doing something outside RDBMS (like sending mail), that will be a problem.
In general, triggers must not do anything with external entities if they are not participating in transaction.

Also, triggers must not work on mutating tables. This means if trigger is executed as result of query operating on table X, then trigger must not query table X. Simple reason is that for one query, trigger may be fired many times and each time trigger will see different data in table X. In general, it is difficult to keep entity integrity via triggers.

Advice: Treat triggers as last resort to solve a problem.

Source:oracle.com

1. Framework is concrete.

In other words, framework has physical components – usually files usable during production.
Java and .Net frameworks are set of concrete components like dlls, arjs, exes etc.

GoF Design Patterns are not framework as they are practical design ideas. It is up to you to apply those ideas to context. Design patterns are logical ideas which you convert to concrete software in a project, whereas framework is concrete already.

2. Framework is incomplete.

Framework itself is not usable on its own. Framework does leave some fill-in-the-blanks for its user.

If you deploy Java/.Net framework to a end-user computer, it does not add any usability value unless you write your own code to use Java/.Net and then deploy that code in executable form along with framework.

More powerful is framework, less complex are fill-in-the-blanks and more efforts in learning to use framework.
Frameworks pose trade-off challenge between learning curve and saving-coding-time.

3. Framework drives solution.

Framework dictates how you do fill-in-the-blanks. Framework dictates overall architecture of complete specific solution.

You have to follow ASP.Net rules, if you have to use ASP.Net framework to build a website.

4. Framework helps solving recurring problems.

That just means that framework are very much reusable as they are helpful in many recurring problem contexts. This also implies commercial case for building a framework for set of problem contexts.

5. Framework deal with high-valued problems.

How to add two number is a problem. Solution is a routine in a form of library. But then it is not a framework as problem is not high-valued.

Providing object persistence is high-valued problem and you can build framework for same. Note that value is relative term.

If you look at these properties, it does not make sense to try to solve any specific non-trivial problem without help from a already existing and proven framework!

Pro: really fast, Easy to use, Good for casual browsing
Con: No add-ons like FireFox 3.x

I will still keep using FF3.x…

2. When you get to the point where you really understand your computer, it’s probably obsolete.

3. The first place to look for information is in the section of the manual where you least expect to find it.

4. When the going gets tough, upgrade.

5. For every action, there is an equal and opposite malfunction.

6. To err is human . . . to blame your computer for your mistakes is even more human, it is downright natural.

7. He who laughs last probably made a back-up.

8. If at first you do not succeed, blame your computer.

9. A complex system that does not work is invariably found to have evolved from a simpler system that worked perfectly.

10. The number one cause of computer problems is computer solutions.

1. We are talking about throwing coin up then it comes back. We catch it or let it hit ground and get settled. We are NOT talking about throwing coin sideways. We are NOT talking about throwing coin straight into sandy ground in a way that it does not roll and will have head up.
2. We are talking about throwing coin near a large body with enough gravitational force so that coin actually comes back with enough speed to hit the solid ground and roll. If you throw coin in outer space void of enough gravity, it will not come back.
3. We are NOT talking about ground which is sandy (not solid), where coin can even stand submerged in sand.
4. We are also assuming that we will decide when coin comes at rest within reasonable period of time. Once coin settles, we do not wait till next tsunami to arrive to change position of coin.
5. We are talking about fair coin. Coin is designed in a way that no side is favored to drop up. Is it possible to manufacture such a coin? Not today.
6. We think that GOD (I do not know what ‘GOD’ means) is fair and does not favor any side to drop up.

Put your comments if you can make this list longer…

Have fun.

UML can model your source code, then. So, if we see in details here is ordered set of “Models”. Ordering criteria is amount of abstraction.

UML – Source Code – Binary – Running Software

as you look at this,
1. UML can be used to model any of source code, Binary, running software.
2. Psuedo source code can be used to model Binary
3. Transformation from UML to running software involves CASE tools, UML tools, Compiler, Platform specific tools, Libraries and Software Mechanisms, OS, OS tools.
4. To me, highest difference of abstraction between adjacent things is between Binary and Running software. UML to source code is almost one to one. Source code to Binary is one to many. Binary to Running sofware involves time dimension.
5. To solve Software engineering problems, we need some thing between Binary and Running software – Jave and .Net has tried this by providing runtimes.