This is Chan Tai Sing

Software Design Patterns: How much do you understand?

2006-04-20T04:56:00.000-07:00

Um.. i think design patterns is the most tough topic to me.But i will try to say something abount it. For me , i understand the adapter pattern and composite pattern among the other pattern coverd on the textbook.

The adapter design pattern'adapts' one interface for a class into one that a client expects. An adapter allows classes to work together that normally could not because of incompatible interfaces by wrapping its own interface around that of an already existing class.

The adapter pattern is useful in situations where an already existing class provides some or all of the services you need but does not use the interface you need. A good real life example is an adapter that converts the interface of a Document Object Model of an XML document into a tree structure that can be displayed.

In object-oriented programming, a Composite is an object designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would a group of them. The operations you can perform on all the composite objects often have a least common denominator relationship. For example, when resizing a single shape to fill the screen, surely you would expect/desire that resizing a group of shapes would have the same effect.

You find that you are using multiple objects in the same way, and often have nearly identical code to handle each of them -- the only differences being that you are manipulating an instance of a 'circle' versus a 'square', for instance. Useful if differentiation doesn't need to exist, and it would be easier to think of them as homogeneous

Software Engineering Certification Programs: What Can You Learn from Them?

2006-04-07T02:58:00.000-07:00

Compare the CSDP body of knowledge with our current Software Engineering course. knowledges areas are not included in your textbook are :

1. Engineering Economics
2. Professional Practices
3. Specialized Software Design Approaches
4. Code Design, Organization, Documentation, Tuning, Defect Identification and Correction.

Why do software projects fail so often?

2006-04-07T02:46:00.000-07:00

Here are the main reason:

Not Enough Time

Often the deadline date is decided prior to the project starting and is non-negotiable. This results in a headlong rush to get started on the assumption that the sooner you begin coding the sooner you'll be finished.

This is almost always the wrong approach. It is vital to spend time to create a good design. Not having a good design leads to ongoing changes throughout the development phase. When this happens time and budget are consumed at a very rapid rate.

Insufficient Budget

Many projects have a "lowest price most successful candidate" policy, or an unrealistically low budget, not based on the true requirements. When this happens everything tends to slow down. Resources are slow to arrive or never arrive, corners are cut and quality suffers.

Poor Communication

There's an old saying, "never assume anything" and this is especially true for software projects. Good communication is vital for project success with the customer, users and especially the development team. Does everyone in the team understand you? Do they know exactly what's expected of them or have you assumed they know? Do they communicate well with each other, with users and with other departments?

Never Reviewing Project Progress

As a project progresses things change and these changes can have a significant impact. It is important to monitor progress on a regular basis so that challenges can be overcome early and stakeholders warned of possible delays and changes to the product.

Inadequate Testing

When the pressure to deliver is on, it is often testing that suffers. All the testing is left until the end of the development cycle and only lip service paid to it. The result is often a product filled with bugs and unhappy customers.

Testing in the Production Environment

It's surprising how many organisations test products in the production environment. This is a high-risk strategy that can lead to security breaches and release without testing that can disrupt the production environment.

Lack of Quality Assurance

Often in the haste to get software delivered quality assurance suffers. Code changes are not documented, the design contains fatal flaws and implementations can be incomplete. These all lead to rework, lost time and ultimately unhappy customers

Not Conforming to Industry Standards

Conforming to industry standards in your software projects can prove effective by ensuring accessibility, portability, usability, robustness and reducing problems now and in the future. Bodies such as International Organisation for Standardisation (ISO) and World Wide Web Consortium (W3C) have developed open standards that when used are hard to challenge.

http://www.projectsmart.co.uk/why_software_projects_fail.html

Software quality: What makes a program code good?

2006-04-07T02:35:00.000-07:00

A good program works flawlessly and has no bugs. But what internal qualities produce such perfection? It's no mystery, we just need some occasional reminding. Whether you code in C/C++, C#, Java, Basic, Perl, COBOL, or ASM, all good programming exhibits the same time-honored qualities: simplicity, readability, modularity, layering, design, efficiency, elegance, and clarity.

Simplicity means you don't do in ten lines what you can do in five. It means you make extra effort to be concise, but not to the point of obfuscation. It means you abhor open coding and functions that span pages. Simplicity—of organization, implementation, design—makes your code more reliable and bug free. There's less to go wrong.

Readability means what it says: that others can read your code. Readability means you bother to write comments, to follow conventions, and pause to name your variables wisely. Like choosing "taxrate" instead of "tr".

Modularity means your program is built like the universe. The world is made of molecules, which are made of atoms, electrons, nucleons, quarks, and (if you believe in them) strings. Likewise, good programs erect large systems from smaller ones, which are built from even smaller building blocks. You can write a text editor with three primitives: move, insert, and delete. And just as atoms combine in novel ways, software components should be reusable.

Layering means that internally, your program resembles a layer cake. The app sits on the framework sits on the OS sits on the hardware. Even within your app, you need layers, like file-document-view-frame. Higher layers call ones below, which raise events back up. (Calls go down; events go up.) Lower layers should never know what higher ones are up to. The essence of an event/callback is to provide blind upward notification. If your doc calls the frame directly, something stinks. Modules and layers are defined by APIs, which delineate their boundaries. Thus, design is critical.

Design means you take time to plan your program before you build it. Thoughts are cheaper than debugging. A good rule of thumb is to spend half your time on design. You need a functional spec (what the programs does) and an internal blueprint. APIs should be codified in writing.

Efficiency means your program is fast and economical. It doesn't hog files, data connections, or anything else. It does what it should, but no more. It loads and departs without fuss. At the function level, you can always optimize later, during testing. But at high levels, you must plan for performance. If the design requires a million trips to the server, expect a dog.

Elegance is like beauty: hard to describe but easy to recognize. Elegance combines simplicity, efficiency, and brilliance, and produces a feeling of pride. Elegance is when you replace a procedure with a table, or realize that you can use recursion—which is almost always elegant:

int factorial(int n)
{
   return n==0 ? 1 : n * factorial(n-1);
}

Clarity is the granddaddy of good programming, the platinum quality all the others serve. Computers make it possible to create systems that are vastly more complex than physical machines. The fundamental challenge of programming is managing complexity. Simplicity, readability, modularity, layering, design, efficiency, and elegance are all time-honored ways to achieve clarity, which is the antidote to complexity.

Clarity of code. Clarity of design. Clarity of purpose. You must understand—really understand—what you're doing at every level. Otherwise you're lost. Bad programs are less often a failure of coding skill than of having a clear goal. That's why design is key. It keeps you honest. If you can't write it down, if you can't explain it to others, you don't really know what you're doing.

There's so much I've left out, but there's one more thing I hesitate to add. Use it sparingly and only in desperation: the clever hack. The clever hack is when you sacrifice your principles to expedience. When you hardcode some condition or make a call up the layer cake—or commit some other embarrassment—because it works and there's no time to do it right. But remember: it must be clever! It's the cleverness that redeems the hack and gives it a kind of perverse elegance. And if the hack doesn't work, don't blame me! Happy programming!

http://msdn.microsoft.com/msdnmag/issues/04/07/EndBracket/

Stuff that lets agile software developers show off what they believe in

2006-04-07T00:52:00.000-07:00

"YAGNI"
Extreme programming speak for You Aren't Going to Need It. XP promotes the idea that you do the simplest thing that works. You don't add additional capability to handle things that you might need in the future until you know that you do need it, because we are lousy at predicting the future and if we never need it we have wasted resources.

You can obviously take this notion to extreme. Some things you should routinely build in for the future especially when they would be awkward to add later. If you come back to complex code to make a minor modification later, there is a more chance you will introduce an error than if you provide the functionality at the start. Further you have to come up to speed again on how it all works before you can safely make your modification.

"Do The Simplest Thing That Could Possibly Work"
Do the simplest thing that could possibly work (DTSTTCPW) means you implement the first idea that comes to mind. This can be scary. Rely on your courage to try out the idea. Remember that failure is an important part of creation. It is unlikely the simplest idea is what you will end up with. However, it's also unlikely you can anticipate what's wrong with your simple solution until you try it out. Let the feedback system guide your implementation. DTSTTCPW is simplicity as in fast and easy.

http://www.extremeperl.org/bk/extreme-programming

What is test-driven development?

2006-04-07T00:38:00.000-07:00

What is test-driven development?

Test-Driven Development (TDD) is a computer programming technique that involves writing test cases first and then implementing the code necessary to pass the tests. The goal of test-driven development is to achieve rapid feedback and implements the "illustrate the main line" approach to constructing a program. This technique is heavily emphasized in Extreme Programming.

Practitioners emphasize that test-driven development is primarily a method of designing software, not just a method of testing. The method is also used for removal of software defects.

Requirements

For test-driven development to work, the system must be flexible enough to allow for automated testing of code, using test cases that return a simple true or false evaluation of correctness. These properties allow for rapid feedback of correctness and design. Unit testing frameworks such as JUnit, NUnit or CPPUnit provide a mechanism for managing and running sets of automated test cases.

Test-Driven Development Cycle

1. Write the test

It begins with writing a test. In order to write a test, the developer must understand the specification and the requirements clearly. This is accomplished through use cases and user stories. The design document covers all the test scenarios and exception conditions.

2. Write the code

The next step is to make the test pass by writing the code. This step forces the programmer to take the perspective of a client by seeing the code through its interfaces. This is the design driven part of test-driven development. As part of test calibration, your code should fail the test meaningfully the first time around.

3. Run the automated tests

The next step is to run the automated test cases and observe if they pass or fail. If they pass, the programmer can be more confident that the code meets the test cases as written. If there are failures, the code did not meet the test cases..

4. Refactor

The final step is the refactoring step and any code clean-up necessary will occur here. The test cases are then re-run and observed.

5. Repeat

The cycle will then repeat itself and start with either adding additional functionality or fixing any errors.

About the UML tools

2005-10-30T01:50:00.000-08:00

After i try out the three different UML tools , i found out the Poseidon For UML is my favorite one. It is because the interface of Poseidon is clear out and simply(i hatesomething that wordy and too colorful).Also it is the most user-friendly tools that it works like a MS office application , you don't need to spend extra time to know how it works. It is so suitable for me!!

But no matter you are using which set of UML tools , you must know the UML standard well in order to draw the diagram. So learn the concept is the most important thing to you and me~

See you next time!

Some Reflection of the basic skills for software engineers

2005-10-02T02:12:00.000-07:00

Hi all~
Finally i just take up my mind to write something on the blog , hope it will not be too late~

From this issue about, i will take up some points that i think (or say i have experienced) to share with everyone.

1.To know how to break down the problem and giving solution is a big issue for the all programmer. Since programming is a kind of problem solving skill, you should able to know the facts inside you program or project in order to solve it. For example what function should be build or should be ignore to do for the program. And you should know the requests and constraints well in order to satisfy the program goal.

2.Have a better time /task management to achevie the goal , don't just do things before deadline. In my experience if you finish your program in a hurry , it will have more bug that you have expect. Then you will spend more time in the debug....So scheduling task and state are important for a good programmer and the crew.

3.Have a better communication between client, your crew and also your boss! To know what's the clinet wants. Keep track to communication with them to prevent misunderstanding problem. knows the problems of your crew in order to have a better working relationship. And you should communication well to your boss to know what's his/her expection.

4.At last , you should have a good programming skill in order to survive ~ Also you should be able to work under pressure!!!

ok~
see you next time

Testing 1 2 3 4

2005-09-21T23:35:00.000-07:00

this post just for test