Hall of self-destruction (Hopefuly not)

Software Design Patterns: How much do you understand?

2006-04-12T00:58:00.000+08:00

referenced from: http://my.execpc.com/~gopalan/design/structural.html

The Adapter Design Pattern is a type of design pattern that is used for converting the interface of a class into an interface that its clients expect to see. This pattern allows incompatible interfaces to work together.

The Bridge Design Pattern separates an abstract interface from its implementation so that both the interface and its implementation can change without any dependancy between each other.

The Composite Design Pattern is used to compose objects so that they can be represented in part-whole hierarchies in tree-structures. This pattern allows clients to treat individual objects equally.

The Facade Design Pattern is used to provide a high-level interface that makes the subsystem easier to use. It helps create a unified interface to a set of interfaces in the subsystem.

The Proxy Design Pattern is used is used when it is required to use another object as a substitute to control access to this object.

Referenced from: http://en.wikipedia.org/wiki/Observer_pattern

Observer Pattern:

The typical usages of the observer pattern:

Listening for an external event (such as a user action). See Event-driven programming.

Listening for changes of the value of a property of an object. Note that often callbacks called in response of a property value change also change values of some properties, so sometimes causing an event cascade. See this article for a discussion about using observer pattern for watching over changes of properties and updating other properties accordingly.

The observer pattern is also very often associated with the Model-view-controller (MVC) paradigm. In MVC, the observer pattern is used to create a loose coupling between the model and the view. Typically, a modification in the model triggers the notification of model observers which are actually the views.

In computer programming, the strategy pattern is a particular software design pattern, whereby algorithms can be selected on-the-fly at runtime depending on conditions, like strategies in a war situation.

The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application. The strategy pattern is intended to provide a means to define a family of algorithms, encapsulate each one as an object, and make them interchangeable. The strategy pattern lets the algorithms vary independently from clients that use them.

Uses of the Command Pattern:

Command objects are useful for implementing:

Multi-level undo. If all user actions in a program are implemented as command objects, the program can keep a stack of the most recently executed commands. When the user wants to undo a command, the program simply pops the most recent command object and executes its undo() method.

Transactional behavior. Undo is perhaps even more essential when it's called rollback and happens automatically when an operation fails partway through. Installers need this. So do databases. Command objects can also be used to implement two-phase commit.

Progress bars. Suppose a program has a sequence of commands that it executes in order. If each command object has a getEstimatedDuration() method, the program can easily estimate the total duration. It can show a progress bar that meaningfully reflects how close the program is to completing all the tasks.

Wizards. Often a wizard presents several pages of configuration for a single action that happens only when the user clicks the "Finish" button on the last page. In these cases, a natural way to separate user interface code from application code is to implement the wizard using a command object. The command object is created when the wizard is first displayed. Each wizard page stores its GUI changes in the command object, so the object is populated as the user progresses. "Finish" simply triggers a call to execute(). This way, the command class contains no user interface code.

GUI buttons and menu items. In Swing programming, an Action is a command object. In addition to the ability to perform the desired command, an Action may have an associated icon, keyboard shortcut, tooltip text, and so on. A toolbar button or menu item component may be completely initialized using only the Action object.

Thread pools. A typical, general-purpose thread pool class might have a public addTask() method that adds a work item to an internal queue of tasks waiting to be done. It maintains a pool of threads that execute commands from the queue. The items in the queue are command objects. Typically these objects implement a common interface such as java.lang.Runnable that allows the thread pool to execute the command even though the thread pool class itself was written without any knowledge of the specific tasks for which it would be used.

Macro recording. If all user actions are represented by command objects, a program can record a sequence of actions simply by keeping a list of the command objects as they are executed. It can then "play back" the same actions by executing the same command objects again in sequence. If the program embeds a scripting engine, each command object can implement a toScript() method, and user actions can then be easily recorded as scripts.

Abstract Factory Pattern:

The Abstract Factory Pattern provides a way to encapsulate a group of individual factories that have a common theme. In normal usage, the client software would create a concrete implementation of the abstract factory and then use the generic interfaces to create the concrete objects that are part of the theme. The client does not know (nor care) about which concrete objects it gets from each of these internal factories since it uses only the generic interfaces of their products. This pattern separates the details of implementation of a set of objects from its general usage.

Builder Pattern:

The builder pattern is used to enable the creation of a variety of complex objects from one source object. The source object may consist of a variety of parts that contribute individually to the creation of each complex object through a set of common interface calls of the Abstract Builder class.

Comments: I have the general idea of how each pattern works, but have to spend more time to the textbook and web contents to familiarize them.

Why do software projects fail so often?

2006-04-12T00:49:00.000+08:00

Referenced from : http://members.cox.net/johnsuzuki/softfail.htm

The predictable findings from the various projects included (2) :

Many of the runaway projects are (or were) "overly ambitious." It is well known in the field that large projects are problematic.

Most of the projects failed from a multiplicity of causes. There may or may not have been a dominant cause, but there were several problems contributing to many of the runaways.

Management problems were more frequently a dominant cause than technical problems. But see the list of surprising findings below.

Schedule overruns were more common (89 percent) than cost overruns (62 percent).

The surprising findings from the study included (2) :

	Survey respondents thought that there would be more runaways in the government and financial sectors, and fewer in service and manufacturing. But the survey findings found all such sectors equally susceptible.
	Respondents were optimistic about the trend in runaways; 42 percent believed they would decrease in number, while only 8 percent felt they would increase.
	The use of packaged software did not help in reducing the incidence of runaways. Of the runaway projects studied, 47 percent consisted of mixed custom and packaged software; 24 percent were custom software; and 22 percent were packaged software.
	Runaway projects showed their true colors early in the project history. More than half started showing symptoms during system development, and 25 percent showed those symptoms during initial planning.
	In spite of the above, visibility into the existence of a runaway came first of all from the project team (72 percent); only 19 percent were spotted initially at the senior management level.
	Technology is dramatically increasing as a cause of runaways. "Technology new to the organization" was the fourth most common problem in the runaway projects.
	Risk management appears more and more frequently in the software management literature. But 55 percent of the runaway projects had not performed any risk management, and of those 38 percent who did (some respondees did not know whether it was used or not), half of them did not use the risk findings once the project was underway.

To prevent the predictable causes to happen, a good management before the actual work of the project starts is a must, outcomes should be predicted and prepared so that the chance of sudden change to the project can be handled.

What is test-driven development?

2006-04-12T00:40:00.000+08:00

Referenced from: wikipedia

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 programmning.

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

Test-driven development can provide great value to building software better and faster. It offers more than just simple validation of correctness, but can also drive the design of a program. By focusing on the test cases first, one must imagine how the functionality will be used by clients (in this case, the test cases). Therefore, the programmer is only concerned with the interface and not the implementation. This benefit is complementary to Design by contract as approaches it through test cases rather than mathematical assertions..

A TDD cycle wuold look like this:

How Internet email works

2006-04-11T19:53:00.000+08:00

The article reminds me of how HTTP works with DNS.
Both requires query to the DNS to obtain the actual destination address and handled by propriate protocols.

However, it would be nice to know more about the architecture of how email works, as well as the definition of POP3, IMAP4 etc.

Software quality: What makes a program code good?

2006-03-22T01:26:00.000+08:00

Besides running speed, resources requirement, a program code should also be "developer-friendly" in order to be defined as a good program code.

Imagine a source code in a company, which is handled by a whole new team as the former team(the original code author) is gone, having totally no idea for what the code is about and yet fails to understand it by read the source code. It wont be considered as a good program code as it hinders the future process of the company.

Therefore, in my opinion, a good program code should also be easy to understand as well as functioning well and properly.

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

2006-03-22T01:18:00.000+08:00

Born to refactor:
From www.cs.utu.fi/kurssit/Programming-III/Refactoring.pdf

• Two definitions, the object and act of change in software– A change made to the internal structure of software to make iteasier to understand and cheaper to modify without changing itsobservable behavior.– To restructure software by applying a series of refactoringns

– The design of software will decay – as changes aredone the code (and design) loses its originalstructure. The self-documenting property of the codevanishes, the design is not any more readable in thecode.
– Refactoring does the opposite, it creates design in theexisting code.
– Regular refactoring adjusts the design piece by pieceto changing functionality

YAGNI - "You Aint Gonna Need It":
From http://c2.com/cgi/wiki?YouArentGonnaNeedIt

Refers to implementing stuff only you need in a program.

There are two main reasons to practise YagNi:

You save time, because you avoid writing code that you turn out not to need.
Your code is better, because you avoid polluting it with 'guesses' that turn out to be more or less wrong but stick around anyway.

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

2006-03-22T01:11:00.000+08:00

IV. Software Construction
XI. Software Quality

These are the 2 topics which I think is not included in the course.

Software Construction involves skills such as code design & error processing
which doesnt suit the goal of the course in my opinion

Whereas software quality.. I dont really have an idea why it is not included...
A possible reason can to this, it is too complicated for us to handle without a clear knowledge on what we're learning right now.

UML Tools

2005-10-24T17:19:00.000+08:00

So far it's really hard to make a decision for which UML tool is the most suitable one. At the current progress, I'm still unfamiliar with the actual process in building an UML diagram for a real project, so there might be functions in the different UML tools that are overlooked.

However, the Poseidon for UML Community Edition which was used in the tutorial class had a good interface, but somehow I have a belief in my mind that a good interface often means the program is lacking of in depth functions... So.. I probably need more time to determine which UML tool is the best for me.

Essential Software Engineering skills

2005-09-30T12:57:00.000+08:00

So... this is the post to share my opinion on which software engineering skills are the most important. Here we go:

Communication with clients and team crew

This is probably the most crucial step to set up the objectives and task of a project. Without a clear communication with the clients, effort and time can be wasted on tasks which does not fit the requirement of the clients, while bad communication in between team crew, also creates the problem of bad quality of task management.
Analytical mind

To every engineers this is a must in order to provide solutions to problem which may be existed in a project. It also helps to create a task schedule so that the flow of work can become time saving and effective.

And uhh... here's a link to knowledgeisfun.com, which provides an article about software engineering. There're also other nice articles on other topics as well.

	Many of the runaway projects are (or were) "overly ambitious." It is well known in the field that large projects are problematic.
	Most of the projects failed from a multiplicity of causes. There may or may not have been a dominant cause, but there were several problems contributing to many of the runaways.
	Management problems were more frequently a dominant cause than technical problems. But see the list of surprising findings below.
	Schedule overruns were more common (89 percent) than cost overruns (62 percent).