Archive for Software Eng

Personal and Team Software Process (PSP,TSP)

Posted in Software Eng with tags on January 22, 2007 by wsjoung

In software engineering area, there are many software development methods. Waterfall, spiral model which are very traditional methods and many of Agile methods including XP. But all those methods are focused on the project itself. what if there are couple of teams which work independently in the same project. or what if there are couple of people who work independently.

PSP, TSP are good to try to measuring time and quality and team-based work planning and tracking.

In anycase, it also have a good fit to small size of projects.

The Team Software Process (TSP) and the Personal Software Process (PSP)
Pathways to Process Maturity

Advertisements

spin model checker

Posted in Software Eng with tags , on November 17, 2006 by wsjoung

Dining philosophers problem is a typical example of dead-lock situation, in this case, we already know that in this dining philosophers model, there exists a dead-lock problem. But most of practical cases, it is pretty hard to figure out dead-lock problem.

Spin can make us test a model before we implement that model.

the following is Promela code which describe dining philosophers problem.
then we can simulate it with spin.

  • spin file.prom — simulate the system (one randomly selected run)
  • spin -a file.prom — generate a verifier (in pan.c)
  • gcc pan.c — compile the verifier
  • a. out — run the verifier (exhaustive searching of all possible runs)
  • spin -t -p file.prom — make the simulator follow the failure trace if the verifier found an error. without ‘-p’ it only prints the final state; with ‘-p’ te whole state trce is printed (can be long!)
  • gcc -DNP pan.c — compile the verifier for liveness (need “progress” labels in your promela code)
[ diningphil.prom ]

#define   N 4
byte Fork[N];
#define Think( I )  printf( "Think %dn", I )
#define Eat( I )    printf( "Eat %dn", I )

proctype Philosopher( byte I ) {
do
:: Think( I ) ;
atomic { (Fork[I] > 0);       Fork[I]-- } ;
atomic { (Fork[(I+1)%N] > 0); Fork[(I+1)%N]-- } ;
progress:
Eat( I ) ;
Fork[I]++;
Fork[(I+1)%N]++;
od
}

init {
byte   ind ;
assert( N > 2 ) ;
atomic {
ind = 0;
do
:: (ind >= N) ->
break;
:: else ->
Fork[ind] = 1;
ind++;
od;
ind = 0;
do
:: (ind >= N) ->
break;
:: else ->
run Philosopher( ind );
ind++;
od;
}
}

The Java Modeling Language (JML)

Posted in Software Eng with tags , , on November 17, 2006 by wsjoung

JML makes it possible to specify the behavior of java modules. it combines the design by contract approach and the model-based specification approach. In another words, we can use JML to make strong the interface of java classes and easily checking return values.

Design by Contract with JML
Gary T. Leavens and Yoonsik Cheon (Jan 11, 2006)

There are two important check point, properties which are right before starting a method and properties which are right after finished a method including return value. We can catch those properties with requires clauses and ensures clauses.

//@ requires x >= 0.0;
/*@ ensures JMLDouble.approximatelyEqualTo(x, \result * \result, eps); @*/
public static double sqrt (double x) {
/* some codes. */
}

a requires clauses to specify the client’s obligation and an ensures clauses to specify the implementor’s obligation. A method’s precondition which is specified requires clauses says what must be true to call it. And, a method’s postcondition which is specified ensures clauses says what must be true when it terminates. Otherwise it throws an exception.

We also can define some contracts for not only methods but entire class.

/*@ public invariant !name.equals(“”)
@ && weight >= 0;
@*/

an invariant is a property that should hold in all client-visible states. It must be true when control is not inside the object’s methods. That is, invariant must hold at the end of each constructor’s execution, and at the beginning and end of all methods.

Formal documentation is another benefit of using JML. It makes more easier to read method’s behaviors.

Engineering of Component Based Systems

Posted in Software Eng with tags , on November 17, 2006 by wsjoung

What’s components first?

  • Unit of independent deployment
  • Unit of third-party composition
  • No persistent state

Many people use the terms “components” and “object” interchangably. most of case there is no problem but, sometimes it is. obviously, a component is likely to come to life through objects and therefore would normally consist of one or more classes or immutable prototype objects. However, there is no need for a component to contain classes only, or even to contain classes at all.

First time when the people invented subroutines they just want to conserve memory. but, programmers soon observed that they could insert subroutines extracted from their previous programs, or even written by other programmers. now we understand that we can build a program by composition of those independent units of programs.

Component-based software development (CBSD) is changing the way large software systems are developed. CBSD shifts the emphasis from programming software to composing software systems. “Buy, don’t build”.

An architectural approach to building systems that are positioned to take advantage of the CBSD approach is the layered system. but we should keep in mind whatever approach is taken will have a profound effect on the integrability of a component-based system.

The benefit of CBSD is

  • Reduced development time
  • Increased reliability of systems
  • Increased flexibility

The pitfalls:

  • If the primary supplier goes out of business or stops making the component will other step in to fill the gap?
  • What happens if the vendor stops supporting the current version of the component, and the new versions are incompatible with the old?
  • If the system demands high reliability or high availability, how can the consumer be sure that the component will allow the satisfaction of those requirements?

Rather than the classic waterfall approach to software development, systems are designed by examining existing components to see how they meet the system requirements.

cbsd.gif

The key to the engineering of component-based systems is to understand what trade-offs are being made.

  • System requirements vs. available components
  • System architecture vs. component interfaces

A pre-condition for successful integration of components is that their interfaces are known.
Each of the following might be considered part of a component interface:

  • Application programming interface (API)
  • Required development and integration tools
  • Secondary storage requirements (run-time), processor requirements (performance) and network requirements (capacity)
  • Required software services (operating system, or from other components)
  • Embedded design assumption, such as the use of specific polling techniques
  • Exception detection and processing

From subroutines to subsystems: component-based software development
Engineering of component-based systems