Jan 1, 2010

Inheritance using Hibernate

9 comments

Introduction

Hibernate is an open source java package. It helps us to work with relational database. It provides a solution to map database tables to a class. You will feel that database contains plain Java objects. It allows you to concentrate on the objects and features of your application without worrying about the storing and finding the data. Thus hibernate relieves the developer from 95 percent of common data related programming tasks.

Hibernate is a Free Software.

Hibernate lets you develop persistent classes with the following object oriented features: -

  • Association (Gives the relationship between Objects. Association identifies that one object is required by another object to perform its task)
  • Inheritance (Portrays generalization and specification among classes)
  • Polymorphism (overloading in object oriented concept)
  • Composition
  • Java collections framework (like Set, Bag, List etc)

In this article we will see how to use inheritance using hibernate.

Inheritance

Inheritance is an object oriented mechanism which portrays generalization and specification. It expresses similarity among classes. It is a parent child relationship with generalized class at the top and specialized classes below.

For example, Person is a generalized class and Teacher and Student are specialized classes or subclasses of Person. i.e. Teacher and Student can have properties of Person as well as their specific properties.

image

Inheritance Mapping

In hibernate there are three different ways by which inheritance can be represented.

  • Table per class hierarchy
  • Table per subclass
  • Table per concrete class

Table per class hierarchy

In this approach the entire hierarchy is mapped to a single table. I.e. All attributes of all the classes are available in a single table as its columns. A discriminator is used to distinguish different classes.

Considering the example of Student, Teacher and Person, we will be using a single table as below with a discriminator (Person_Type) to distinguish the type of Person

image 

PERSON table consists of all attributes of Person, Teacher and Students as its columns.

Mapping of Table per class hierarchy:

Person.hbm.xml

<hibernate-mapping>
    <class name=”Person” table=”PERSON”>
        <id name=”id” column=”ID”>
            <generator class=”increment”/>
        </id>
        <discriminator column=”PERSON_TYPE” type=”string”/>
        <property name= “name” column=”NAME”/>
    </class>
</hibernate-mapping>


Person table contains a column ‘Person_type’. This column is mapped using the <discriminator> XML element.


Discriminator is not a property of any java class, it is a column shared between database and Hibernate. Hibernate using this column to instantiate the appropriate class and populate it accordingly.



Student.hbm.xml
===============

<hibernate-mapping>
    <subclass name=”Student” extends=Person” discriminator-value=”Student”>
        <property name= “branch” column=”BRANCH”/>
    </subclass>
</hibernate-mapping>

Teacher.hbm.xml
===============

<hibernate-mapping>
    <subclass name=”Teacher” extends=Person” discriminator-value=”Teacher”>
        <property name= “department” column=”DEPARTMENT”/>
    </subclass>
</hibernate-mapping>

<subclass> XML element is used to map the concrete classes, Student and Teacher.


<subclass> element consists of the attributes extends and discriminator-value.


Advantage: This approach is simple and efficient as all data are available in a single table and no joining of tables is required.


Disadvantage: Disadvantage in this mapping strategy is that columns declared by the subclasses cannot have NOT NULL constraints.


Table per concrete class


In this approach separate class elements are required for each class.


Considering the example of Student, Teacher, Person we will use two different tables:


image


Mapping using <union-subclass>


<union-subclass> element is used for each subclass in mapping file.


<class name="Person">
    <id name="id" type="long" column="ID">
        <generator class="sequence"/>
    </id>
    <property name="name" column="NAME"/>
    <union-subclass name="Student" table="STUDENT">
        <property name="branch" column="BRANCH"/>
    </union-subclass>
    <union-subclass name="Teacher" table="TEACHER ">
        <property name="branch" column="BRANCH"/>
    </union-subclass>
</class>


The limitation of this approach is that if a property is mapped on the super class, the column name must be the same on all subclass tables.


Table per subclass



In this approach also, separate tables are required for different classes, but will have only specific attributes of subclasses instead of the inherited properties as in table per concrete class.



Considering the example of Student, Teacher, Person we will use three different tables:



image



<joined-subclass> element is used for each subclass in mapping file A table per subclass mapping looks like this:



<class name="Person" table="PERSON">
    <id name="id” column="ID">
        <generator class="native"/>
    </id>
    <property name="name" column="NAME"/>
    <joined-subclass name="Teacher" table="TEACHER">
        <key column="ID"/>
        <property name="department" column="DEPARTMENT"/>
    </joined-subclass>
    <joined-subclass name="Student" table="STUDENT">
        <key column="ID"/>
        <property name="branch" column="BRANCH"/>
    </joined-subclass>
</class>


In this case there are three tables. The subclasses will have primary key with the super class.



Conclusion



In this document we have seen three different approaches to represent inheritance using hibernate.




  • Table per class hierarchy

  • Table per subclass

  • Table per concrete class



Reference




Changing the user characteristic in AIX from command prompt

No comments

Generally in AIX based server ‘smit’ (System Management Interface Tool) tool is used for showing and changing the characteristic of root user. But sometimes in remote access (e.g. Split IP/VNC/VPN) it is not very easy to use smit (System Management Interface Tool) tool remotely. Below are the some useful commands that can be used for seeing and changing the characteristics of root password.

  • To check the various parameters of root password below is the command :
# lsuser -f root

   e.g.

   # lsuser -f root
   root:
        id=0
        pgrp=system
        groups=system,bin,sys,security,cron,audit
        home=/home/root
        shell=/bin/fash
        login=true
        su=true
        rlogin=true
        daemon=true
        admin=true
        sugroups=ALL
        admgroups=
        tpath=nosak
        ttys=ALL
        expires=0
        auth1=SYSTEM
        auth2=NONE
        umask=22
        registry=files
        SYSTEM=compat
        logintimes=
        loginretries=0
        pwdwarntime=7
        account_locked=false
        minage=0
        maxage=4
        maxexpired=-1
        minalpha=1
        minother=1
        mindiff=0
        maxrepeats=0
        minlen=6
        histexpire=0
        histsize=0
        pwdchecks=
        dictionlist=
        dce_export=false
        fsize=2097151
        cpu=-1
        data=262144
        stack=65536
        core=2097151
        rss=65536
        nofiles=2000
        usrenv=TMOUT=600,TIMEOUT=10
        time_last_login=1259300096
        time_last_unsuccessful_login=1259269654
        tty_last_login=/dev/pts/0
        tty_last_unsuccessful_login=/dev/pts/0
        host_last_login=47.129.231.121
        host_last_unsuccessful_login=47.130.48.72
        unsuccessful_login_count=0
        roles=



  • To disable password aging, we can change ‘maxage’ parameter for root password to ‘0’ using command prompt.



# chuser maxage=0 root



  • To allow immediate re-use of a password, we can change ‘NUMBER OF PASSWORDS before reuse’ and ‘WEEKS before password reuse’ parameter for root password to ‘0’ using command prompt.



# chuser histexpire=0 root 
# chuser histsize=0 root



  • Some more parameters generally used to change using chuser command.



a) To enable user smith to access this system remotely, type:

     #chuser rlogin=true smith

b) To change the expiration date for the davis user account to 8 a.m., 1         
            May, 1995, type:

    #chuser expires=0501080095 davis

c) To add davis to the groups finance and accounting, type:

    #chuser groups=finance, accounting Davis 

d) To change the user davis, who was created with the LDAP load module,     
            to not be allowed remote access, type:

    #chuser -R LDAP rlogin=false davis


Conclusion



This command is very useful to change the user parameter from command line. This command should grant execute (x) access only to the root user and the security group. This command should be installed as a program in the trusted computing base (TCB). The command should be owned by the root user with the setuid (SUID) bit set.



Reference



Changing the user characteristic in AIX from command prompt

No comments

Generally in AIX based server ‘smit’ (System Management Interface Tool) tool is used for showing and changing the characteristic of root user. But sometimes in remote access (e.g. Split IP/VNC/VPN) it is not very easy to use smit (System Management Interface Tool) tool remotely. Below are the some useful commands that can be used for seeing and changing the characteristics of root password.

  • To check the various parameters of root password below is the command :
# lsuser -f root

   e.g.

   # lsuser -f root
   root:
        id=0
        pgrp=system
        groups=system,bin,sys,security,cron,audit
        home=/home/root
        shell=/bin/fash
        login=true
        su=true
        rlogin=true
        daemon=true
        admin=true
        sugroups=ALL
        admgroups=
        tpath=nosak
        ttys=ALL
        expires=0
        auth1=SYSTEM
        auth2=NONE
        umask=22
        registry=files
        SYSTEM=compat
        logintimes=
        loginretries=0
        pwdwarntime=7
        account_locked=false
        minage=0
        maxage=4
        maxexpired=-1
        minalpha=1
        minother=1
        mindiff=0
        maxrepeats=0
        minlen=6
        histexpire=0
        histsize=0
        pwdchecks=
        dictionlist=
        dce_export=false
        fsize=2097151
        cpu=-1
        data=262144
        stack=65536
        core=2097151
        rss=65536
        nofiles=2000
        usrenv=TMOUT=600,TIMEOUT=10
        time_last_login=1259300096
        time_last_unsuccessful_login=1259269654
        tty_last_login=/dev/pts/0
        tty_last_unsuccessful_login=/dev/pts/0
        host_last_login=47.129.231.121
        host_last_unsuccessful_login=47.130.48.72
        unsuccessful_login_count=0
        roles=



  • To disable password aging, we can change ‘maxage’ parameter for root password to ‘0’ using command prompt.



# chuser maxage=0 root



  • To allow immediate re-use of a password, we can change ‘NUMBER OF PASSWORDS before reuse’ and ‘WEEKS before password reuse’ parameter for root password to ‘0’ using command prompt.



# chuser histexpire=0 root 
# chuser histsize=0 root



  • Some more parameters generally used to change using chuser command.



a) To enable user smith to access this system remotely, type:

     #chuser rlogin=true smith

b) To change the expiration date for the davis user account to 8 a.m., 1         
            May, 1995, type:

    #chuser expires=0501080095 davis

c) To add davis to the groups finance and accounting, type:

    #chuser groups=finance, accounting Davis 

d) To change the user davis, who was created with the LDAP load module,     
            to not be allowed remote access, type:

    #chuser -R LDAP rlogin=false davis


Conclusion



This command is very useful to change the user parameter from command line. This command should grant execute (x) access only to the root user and the security group. This command should be installed as a program in the trusted computing base (TCB). The command should be owned by the root user with the setuid (SUID) bit set.



Reference



Configuration Management

1 comment

Software configuration management (SCM) is responsible to establish and maintain the integrity of the products of the software project throughout the software life cycle. This includes identifying configuration items, controlling changes and recording and reporting the change implementation status. SCM is the task of tracking and controlling changes in the software. Configuration management practices include revision control and the establishment of baselines.

IEEE – A discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item, and control changes to those characteristics, report change processing and implementation status, and verify compliance with specified requirements.

The software configuration management has four key components:

  • Version Control

Version control is simply the automated act of tracking the changes of a particular file over time. This is typically accomplished by maintaining one copy of the file in a repository, then tracking the changes to that file (rather than maintaining multiple copies of the file itself).

  • Build Management

Whether you choose to use automated tools to build your applications or still use a manual process, a software configuration management system helps you manage your process and results.

  • Release Management

Release management is closely tied to build management. Release management includes the deployment process as well as the update of related metadata that goes into tracking a given version of a software application. The primary purpose of a release is to make the application available to its end users.

  • Process Control

Process control is like an umbrella across the three key concepts already discussed. It is the combination of the business processes defined for your team and the implementation of these processes within your configuration management tool.

clip_image002[4]

UML Diagram:--

clip_image004

Activities Performed under SCM

Configuration identification - Identifying configurations, configuration items and baselines.

  • Possible Configuration Items (CIs)
    • System Specification
    • Project Plan
    • Requirements Spec
      • Analysis Models
      • Prototypes
      • Use Cases
  • Design Specs
    • Data Design/Schema
    • Architectural design
    • Interface Design Spec
    • Module Design Spec
    • Catalogs & Classes
  • Source Codes
  • Libraries
  • Test Specifications
    • Test Plan and Procedures
    • Test Cases
  • Installation & User Manual
  • Executables
  • Standards
  • Checklists
  • Tools
  • Baseline
    • An aggregation of CIs that have been formally reviewed and agreed upon, and taken into control at a single point of time. One or more software configuration items that have been formally reviewed and agreed upon and serve as a basis for further development.
    • Baseline acts as points of reversibility in the development life cycle.
    • Possible Baseline Points
    • Contract
    • Functional Specifications
    • Design
    • Code & Unit Test
    • Integration Test
    • System Test

Configuration control - Implementing a controlled change process. This is usually achieved by setting up a change control board whose primary function is to approve or reject all change requests that are sent against any baseline.

  • Change is logged.
  • Evaluation of request - Impact, Risk, Priority.
  • Change Control Board - Decision Authority.
    • PM approves the change request.
    • TM involvement for effort changes due to a CR.
  • Draw implementation plan.
  • “Check-out” CI’s - to dynamic folder of the user.
  • Make the change, Review the change.
  • “Check-in” CIs.
  • Establish baseline.

Configuration status accounting - Recording and reporting all the necessary information on the status of the development process.

  • Status of change requests, defect reports
  • Version status of various Configuration items
  • Status of Configuration items in various baselines.

Configuration status accounting needs to be done at the end of identified phase or milestones after ensuring that baseline record is updated to reflect the latest version numbers of the configuration items.

Configuration auditing - Ensuring that configurations contain all their intended parts and are sound with respect to their specifying documents, including requirements, architectural specifications and user manuals.

  • Verifying that Configuration Management Process has been followed
  • Adherence to Configuration Management Plan
  • Contents of baselines - Intermediate and Release
  • Change Management Process
  • Control of changes to base lined items
  • Defect logging and tracking

Build management - Managing the process and tools used for builds.

Process management - Ensuring adherence to the organization's development process.

Environment management - Managing the software and hardware that host our system.

Teamwork - Facilitate team interactions related to the process.

Defect tracking - Making sure every defect has traceability back to the source.

image

SCM Life Cycle model

clip_image009[4]

SCM plan divides the entire software life cycle into following phases to address and define the process and activities to be followed for reaching a milestone with history, traceability and reproducibility.

  • Setting up workspace
  • Development and defect fixing
  • Code delivery and Daily Builds
  • Initial Base lining
  • IR Configuration Audit & Accounting
  • Internal Release (IR)
  • Testing and defect fixing
  • Final Base lining
  • Configuration Audit & Accounting
  • External Release (ER)

Setting up workspace

Workspace is nothing but an independent work area of a developer to view, modify, build and test the source files without impacting another person’s work by providing enough isolation and privacy. The workspace is setup by developers with the assistance from SCM team.

  • Creating a Workspace (Project/Private) folder for each task or user respectively depends on what kind of isolation is required for development work.
  • Set up config_spec required for development work
  • The check out and check in as follows
  • Map your local workspace / folder directory path to SCM tool you are using.
  • Selecting element versions from the starting baseline.

An element version will be pulled out into Workspace branch and will be checked out from there, when user issues a checkout

Development and Defect Fixing

This is the phase where developers do real coding work. This coding can be for accomplishing a task like feature or defect fix.

  • Developers start their work in a Project using their local development.
  • Once Project/ files are ready with development /enhancements or defect fixes, developers ensure to check in their changes with a brief comment on the comment section.
  • Project/ files are merged into a respective folder on VSS with auto incremented.

Code Delivery & Daily Builds

Phase where completed work is delivered and integrated (merged) in a common area.

  • Developer does a ‘merge out’ operation to merge LATEST versions of development folder from VSS to their local development. This is a mandatory step before developer delivers his/her changes.
  • After ‘merge out’, developer must do a build and minimum level of testing to validate the integrity of the merge.
  • After validating ‘merge out’ data, developer does a ‘merge in’ from local development to VSS.

Initial Base lining

SCM team baselines the integrated and build validated code and releases the software to test team along with build configuration

  • Developer / lead hands over Release Main branch code to SCM team and provides config_spec to migrate ST and IT folder.
  • SCM team creates a baseline complying with labeling standards.
  • SCM and development lead will coordinate to migrate the code testing servers.

IR Configuration Audit & Accounting

Configuration Audit & Accounting is mandatory, because it gathers product statistics and preserves product history and traceability. It also validates the completeness of the product and consistency of its components by ensuring that they are in an appropriate state. Here it is done to validate the code to be given to test team for testing the product.

Internal Release

Internal release is the code release to test team basically for final testing and defect fixing of the product to qualify it for releasing to customer.

Testing and defect fixing

Phase where the product is tested vigorously, defects are found and fixed.

  • Defect found during testing are logged into defect tracking system.
  • Once defect fixing is done, lead will send a note to SCM team to migrate the code.

Final Baseline

In this phase test team hands over the tested and qualified code to SCM team, who creates a final baseline on this code. This baseline is used for the code release to customer.

  • Test team informs test completion to SCM team and hands over list of defects found in testing phase.
  • SCM team does following:
    • Creates a Full External Release Baseline complying with labeling standards.
    • Collects list of versions and verifies if they are modified for fixing defects. Reports the conflicts to test team and get them cleared.
    • Verifies that testing defects are closed in defect tracking system.
    • Creates final release baseline.
    • Locks final release baseline, and code will be freeze, If changes made after code freeze require higher management approval to migrate the code.

Configuration Audit & Accounting

clip_image011

Configuration audit and analytics can help align the configuration of servers and other assets, contribute to proper capacity planning, validate the configuration of environments designed for business continuity, facilitate migrations from physical to virtual environments, and improve application lifecycles across an environment.

  • In-process audits – verify the consistency of the design as it evolves through the development process
  • Functional audits – verify that functionality and performance are consistent with requirements defined in the SRS
  • Physical audits – verify that the as-built version of software and documentation are internally consistent and ready for delivery
  • Quality system audits – independent assessment of the compliance to the software QA plan

Configuration status accounting is an activity of CM that is concerned with the recording and reporting of information required to effectively manage the configuration of a system or product. Configuration status accounting activities collect data that can be used to measure various aspects of program effectiveness and to assess product completeness and quality. The five (5) primary types of configuration status accounting reports identified for the AHRQ program are listed below and discussed in the following sections:

  • CI Reporting.
  • CR Reports.
  • System Build Reports.
  • Audit Reports.
  • CM Metric Reports

External Release

External release is the release of final tested and qualified product to customer. This release goes through every step of formal release process

Benefits of SCM

1. Organizes tasks and activities that maintain the integrity of the software.

2. Helps manage assets.

3. Provides ability to track changes made during sequential or parallel development.

4. Ensures correct configurations of software.

5. Provides the ability to trace the process from requirement to product.

6. Limits legal liability by recording all data.

7. Helps reduce the life cycle cost of maintaining software which can exceed the initial cost of development.

SCM Summary

  • Change is inevitable
  • Defined procedures are required to manage change without preventing change
  • Software presents many challenges from a control, management, and tracking perspective
  • Knowing what you have and how you got there is very important
  • Being able to recreate exactly what is delivered to customers is essential

Some Common SCM Tools

  • SCCS, RCS (UNIX)
  • Clear Case, Summit, CMVC (Rational)
  • Visual SourceSafe (Microsoft)
  • CVS, Bugzilla (open source and free software)
  • Razor (Tower)
  • Bugbase (Archimedes Software)
  • Many other tools with CM capabilities (e.g. Requisite Pro and Rational Rose)

General information - SCM Tools

Software 
Maintainer 
Development status 
Repository model 
Concurrency model 
License 
Platforms supported 
Cost 
AccuRev [5]
AccuRev, Inc.
actively developed
Client-server
Merge or lock
Proprietary
Any Java Platform (Unix-like, Windows, Mac OS X)
$1495 (enterprise) for each license, free 5-user 30 day trial licenses available
Bazaar[6]
Canonical Ltd.
actively developed
Distributed[1]
Merge
GPL
Unix-like, Windows, Mac OS X
Free
BitKeeper[7]
BitMover Inc.
actively developed
Distributed
Merge
Proprietary
Unix-like, Windows, Mac OS X
Quoted on an individual basis.
ClearCase[8]
IBM Rational
actively developed
Client-server
Merge or lock[2]
Proprietary
Unix-like, Windows, AIX, HP UX, i5/OS, OS/390, z/OS,
$4600 per floating license (held for 30-minutes minimum per user)
Code Co-op[9]
Reliable Software
actively developed
Distributed
Merge
Proprietary
Windows
$150 per seat
Codendi[10]
Xerox
platform actively developed with CVS & Subversion
Client-server
Merge or lock
GPL
Linux Red Hat Enterprise 5.x
Free- Commercial support subscription available
Codeville[11]
Ross Cohen
actively developed
Distributed
Merge
BSD
Unix-like, Windows, Mac OS X
Free
CVS[12]
The CVS Team [13]
maintained but new features not added
Client-server
Merge
GPL
Unix-like, Windows, Mac OS X
Free
CVSNT[14]
March Hare Software[15] and community members.
maintained and new features under development
Client-server
Merge or lock
GPL or proprietary
Unix-like, Windows, Mac OS X, i5/OS
Free or commercial
darcs[16]
David Roundy
actively developed
Distributed
Merge
GPL
Unix-like, Windows, Mac OS X
Free
Fossil[17]
D. Richard Hipp
actively developed
Distributed
Merge
GPL
POSIX, Windows, Mac OS X, Other
Free
Git[18]
Junio Hamano
actively developed
Distributed
Merge
GPL
POSIX, Windows, Mac OS X
Free
GNU arch[19]
Andy Tai
maintained but new features not added
Distributed
Merge
GPL
Unix-like, Windows, Mac OS X
Free
IC Manage[20]
IC Manage Inc.
actively developed
Client-server
Merge or lock
Proprietary
Unix-like, Windows, Mac OS X
Commercial
LibreSource Synchronizer[21]
Artenum[22]
maintained and new features under development
Client-server
Merge
GPL[3]
Unix-like, Windows, Mac OS X
Free
Mercurial[23]
Matt Mackall
actively developed
Distributed
Merge
GPL
Unix-like, Windows, Mac OS X
Free
MKS[24]
MKS Inc
actively developed
Client-server
Merge or lock
Proprietary
Unix-like, Windows
 
Monotone[25]
Nathaniel Smith, Graydon Hoare
actively developed
Distributed
Merge
GPL
Unix-like, Windows, Mac OS X
Free
Perforce[26]
Perforce Software Inc.
actively developed
Client-server
Merge or lock
Proprietary
Unix-like, Windows, Mac OS X
Free for up to 2 users, and for OSS development; else $900 per seat, with volume discounts [27]
PlasticSCM[28]
Codice Software[29]
actively developed
Client-server/Distributed
Merge
Proprietary
Unix-like, Windows, Mac OS X
$500 per seat, with volume discounts, free 5-user 30 day trial licenses available [30]
StarTeam[31]
Borland (Micro Focus)
actively developed
Client-server
Merge or lock
Proprietary
Windows and Cross-platform via Java based client
$7500 per concurrent, $2500 per fixed user.
Subversion (SVN)[32]
CollabNet, Inc.[33]
actively developed
Client-server[4]
Merge or lock[5]
Apache/BSD style
Unix-like, Windows, Mac OS X
Free (Commercial support/services available)
SVK[34]
Best Practical[35]
maintenance through 2010, no new features[6]
Distributed
Merge
Artistic/GPL
Unix-like, Windows, Mac OS X
Free
Team Foundation Server[36]
Microsoft
actively developed
Client-server
Merge or lock
Proprietary
Server: Windows Server 2003; Clients: Windows and Web included
Licensed through MSDN subscription or through direct buy for $2800 [37]
Telelogic Synergy[38]
Telelogic (IBM)
actively developed
Client-server and Distributed
Merge or lock
Proprietary
Linux, Windows, Unix-like
Contact Telelogic [39]
Vault[40]
SourceGear LLC[41]
actively developed
Client-server
Merge or lock
Proprietary
Unix-like, Linux, Windows
$300 per user
Visual SourceSafe[42]
Microsoft
serious bug fixes only
Shared Folder
Merge or lock
Proprietary
Windows
~$500 per license or single license included with each MSDN subscription.
Software
Maintainer
Development status
Repository model
Concurrency model
License
Platforms supported
Cost


Source Control Server and Client



Source Control Server –It is software that really does the software tracking and storage of files. You must install the server software in a secure computer in your office. This will be the machine where the files and multiple versions of them are stored. So it is important that this machine is protected from direct access of any of the members in your team



Source control Client - Users perform all actions through the client software. The client software will communicate with the server software to execute the user tasks. All files will be stored and retrieved to this machine using the Source Control client software. Each member of the team should install the client software in their machines. The client software will send and receive files with the server software. So, the team members do not need direct access to the server computer.



INTRODUCTION



Microsoft Visual source safe – Source Control System



Microsoft Visual SourceSafe also called ‘VSS’ is a file-system-based source control tool from Microsoft. Microsoft Visual SourceSafe is a file-level version control system that permits many types of organizations to work on several project versions at the same time. This capability is particularly beneficial in a software development environment, where it is used in maintaining parallel code versions. However, the product can also be used to maintain files for any other type of team...



At a minimum, Visual SourceSafe does the following:




  • Helps protect your team from accidental file loss.


  • Allows back-tracking to earlier versions of a file.


  • Supports branching, sharing, merging, and management of file releases.


  • Tracks versions of entire projects.


  • Tracks modular code (one file that is reused, or shared, by multiple projects).





Powerful Operations



Add Files, Create Project, Delete Files or Projects, Get Latest Version, Check Out, Check In, Undo Check Out, Move, Deploy, Share, Branch, View, Edit, Show Difference, Set Working Folder, Refresh File List, Refresh Project Tree, Stop Current Operation, Show Properties, Show History, Label, Pin, Rename, Change Password, Cloak Project.



Summary



Source control system helps



1. Keep backup of your source code or documents.

2. Maintain all versions of your files so that you can retrieve any of the old versions of the file easily without searching all over your hard drive.


3. Track which person changed what and when.


4. Control who changes the file to avoid more than one person changing the file at the same time.


5. At any point of time, any of the team members can get the latest version of all files from one single location, without the need to ask each member for the latest files.


6. Track progress - project manager or team leader can monitor the file change activity in source control systems to find out how much work each person has done on each day.

Configuration Management

1 comment

Software configuration management (SCM) is responsible to establish and maintain the integrity of the products of the software project throughout the software life cycle. This includes identifying configuration items, controlling changes and recording and reporting the change implementation status. SCM is the task of tracking and controlling changes in the software. Configuration management practices include revision control and the establishment of baselines.

IEEE – A discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item, and control changes to those characteristics, report change processing and implementation status, and verify compliance with specified requirements.

The software configuration management has four key components:

  • Version Control

Version control is simply the automated act of tracking the changes of a particular file over time. This is typically accomplished by maintaining one copy of the file in a repository, then tracking the changes to that file (rather than maintaining multiple copies of the file itself).

  • Build Management

Whether you choose to use automated tools to build your applications or still use a manual process, a software configuration management system helps you manage your process and results.

  • Release Management

Release management is closely tied to build management. Release management includes the deployment process as well as the update of related metadata that goes into tracking a given version of a software application. The primary purpose of a release is to make the application available to its end users.

  • Process Control

Process control is like an umbrella across the three key concepts already discussed. It is the combination of the business processes defined for your team and the implementation of these processes within your configuration management tool.

clip_image002[4]

UML Diagram:--

clip_image004

Activities Performed under SCM

Configuration identification - Identifying configurations, configuration items and baselines.

  • Possible Configuration Items (CIs)
    • System Specification
    • Project Plan
    • Requirements Spec
      • Analysis Models
      • Prototypes
      • Use Cases
  • Design Specs
    • Data Design/Schema
    • Architectural design
    • Interface Design Spec
    • Module Design Spec
    • Catalogs & Classes
  • Source Codes
  • Libraries
  • Test Specifications
    • Test Plan and Procedures
    • Test Cases
  • Installation & User Manual
  • Executables
  • Standards
  • Checklists
  • Tools
  • Baseline
    • An aggregation of CIs that have been formally reviewed and agreed upon, and taken into control at a single point of time. One or more software configuration items that have been formally reviewed and agreed upon and serve as a basis for further development.
    • Baseline acts as points of reversibility in the development life cycle.
    • Possible Baseline Points
    • Contract
    • Functional Specifications
    • Design
    • Code & Unit Test
    • Integration Test
    • System Test

Configuration control - Implementing a controlled change process. This is usually achieved by setting up a change control board whose primary function is to approve or reject all change requests that are sent against any baseline.

  • Change is logged.
  • Evaluation of request - Impact, Risk, Priority.
  • Change Control Board - Decision Authority.
    • PM approves the change request.
    • TM involvement for effort changes due to a CR.
  • Draw implementation plan.
  • “Check-out” CI’s - to dynamic folder of the user.
  • Make the change, Review the change.
  • “Check-in” CIs.
  • Establish baseline.

Configuration status accounting - Recording and reporting all the necessary information on the status of the development process.

  • Status of change requests, defect reports
  • Version status of various Configuration items
  • Status of Configuration items in various baselines.

Configuration status accounting needs to be done at the end of identified phase or milestones after ensuring that baseline record is updated to reflect the latest version numbers of the configuration items.

Configuration auditing - Ensuring that configurations contain all their intended parts and are sound with respect to their specifying documents, including requirements, architectural specifications and user manuals.

  • Verifying that Configuration Management Process has been followed
  • Adherence to Configuration Management Plan
  • Contents of baselines - Intermediate and Release
  • Change Management Process
  • Control of changes to base lined items
  • Defect logging and tracking

Build management - Managing the process and tools used for builds.

Process management - Ensuring adherence to the organization's development process.

Environment management - Managing the software and hardware that host our system.

Teamwork - Facilitate team interactions related to the process.

Defect tracking - Making sure every defect has traceability back to the source.

image

SCM Life Cycle model

clip_image009[4]

SCM plan divides the entire software life cycle into following phases to address and define the process and activities to be followed for reaching a milestone with history, traceability and reproducibility.

  • Setting up workspace
  • Development and defect fixing
  • Code delivery and Daily Builds
  • Initial Base lining
  • IR Configuration Audit & Accounting
  • Internal Release (IR)
  • Testing and defect fixing
  • Final Base lining
  • Configuration Audit & Accounting
  • External Release (ER)

Setting up workspace

Workspace is nothing but an independent work area of a developer to view, modify, build and test the source files without impacting another person’s work by providing enough isolation and privacy. The workspace is setup by developers with the assistance from SCM team.

  • Creating a Workspace (Project/Private) folder for each task or user respectively depends on what kind of isolation is required for development work.
  • Set up config_spec required for development work
  • The check out and check in as follows
  • Map your local workspace / folder directory path to SCM tool you are using.
  • Selecting element versions from the starting baseline.

An element version will be pulled out into Workspace branch and will be checked out from there, when user issues a checkout

Development and Defect Fixing

This is the phase where developers do real coding work. This coding can be for accomplishing a task like feature or defect fix.

  • Developers start their work in a Project using their local development.
  • Once Project/ files are ready with development /enhancements or defect fixes, developers ensure to check in their changes with a brief comment on the comment section.
  • Project/ files are merged into a respective folder on VSS with auto incremented.

Code Delivery & Daily Builds

Phase where completed work is delivered and integrated (merged) in a common area.

  • Developer does a ‘merge out’ operation to merge LATEST versions of development folder from VSS to their local development. This is a mandatory step before developer delivers his/her changes.
  • After ‘merge out’, developer must do a build and minimum level of testing to validate the integrity of the merge.
  • After validating ‘merge out’ data, developer does a ‘merge in’ from local development to VSS.

Initial Base lining

SCM team baselines the integrated and build validated code and releases the software to test team along with build configuration

  • Developer / lead hands over Release Main branch code to SCM team and provides config_spec to migrate ST and IT folder.
  • SCM team creates a baseline complying with labeling standards.
  • SCM and development lead will coordinate to migrate the code testing servers.

IR Configuration Audit & Accounting

Configuration Audit & Accounting is mandatory, because it gathers product statistics and preserves product history and traceability. It also validates the completeness of the product and consistency of its components by ensuring that they are in an appropriate state. Here it is done to validate the code to be given to test team for testing the product.

Internal Release

Internal release is the code release to test team basically for final testing and defect fixing of the product to qualify it for releasing to customer.

Testing and defect fixing

Phase where the product is tested vigorously, defects are found and fixed.

  • Defect found during testing are logged into defect tracking system.
  • Once defect fixing is done, lead will send a note to SCM team to migrate the code.

Final Baseline

In this phase test team hands over the tested and qualified code to SCM team, who creates a final baseline on this code. This baseline is used for the code release to customer.

  • Test team informs test completion to SCM team and hands over list of defects found in testing phase.
  • SCM team does following:
    • Creates a Full External Release Baseline complying with labeling standards.
    • Collects list of versions and verifies if they are modified for fixing defects. Reports the conflicts to test team and get them cleared.
    • Verifies that testing defects are closed in defect tracking system.
    • Creates final release baseline.
    • Locks final release baseline, and code will be freeze, If changes made after code freeze require higher management approval to migrate the code.

Configuration Audit & Accounting

clip_image011

Configuration audit and analytics can help align the configuration of servers and other assets, contribute to proper capacity planning, validate the configuration of environments designed for business continuity, facilitate migrations from physical to virtual environments, and improve application lifecycles across an environment.

  • In-process audits – verify the consistency of the design as it evolves through the development process
  • Functional audits – verify that functionality and performance are consistent with requirements defined in the SRS
  • Physical audits – verify that the as-built version of software and documentation are internally consistent and ready for delivery
  • Quality system audits – independent assessment of the compliance to the software QA plan

Configuration status accounting is an activity of CM that is concerned with the recording and reporting of information required to effectively manage the configuration of a system or product. Configuration status accounting activities collect data that can be used to measure various aspects of program effectiveness and to assess product completeness and quality. The five (5) primary types of configuration status accounting reports identified for the AHRQ program are listed below and discussed in the following sections:

  • CI Reporting.
  • CR Reports.
  • System Build Reports.
  • Audit Reports.
  • CM Metric Reports

External Release

External release is the release of final tested and qualified product to customer. This release goes through every step of formal release process

Benefits of SCM

1. Organizes tasks and activities that maintain the integrity of the software.

2. Helps manage assets.

3. Provides ability to track changes made during sequential or parallel development.

4. Ensures correct configurations of software.

5. Provides the ability to trace the process from requirement to product.

6. Limits legal liability by recording all data.

7. Helps reduce the life cycle cost of maintaining software which can exceed the initial cost of development.

SCM Summary

  • Change is inevitable
  • Defined procedures are required to manage change without preventing change
  • Software presents many challenges from a control, management, and tracking perspective
  • Knowing what you have and how you got there is very important
  • Being able to recreate exactly what is delivered to customers is essential

Some Common SCM Tools

  • SCCS, RCS (UNIX)
  • Clear Case, Summit, CMVC (Rational)
  • Visual SourceSafe (Microsoft)
  • CVS, Bugzilla (open source and free software)
  • Razor (Tower)
  • Bugbase (Archimedes Software)
  • Many other tools with CM capabilities (e.g. Requisite Pro and Rational Rose)

General information - SCM Tools

Software 
Maintainer 
Development status 
Repository model 
Concurrency model 
License 
Platforms supported 
Cost 
AccuRev [5]
AccuRev, Inc.
actively developed
Client-server
Merge or lock
Proprietary
Any Java Platform (Unix-like, Windows, Mac OS X)
$1495 (enterprise) for each license, free 5-user 30 day trial licenses available
Bazaar[6]
Canonical Ltd.
actively developed
Distributed[1]
Merge
GPL
Unix-like, Windows, Mac OS X
Free
BitKeeper[7]
BitMover Inc.
actively developed
Distributed
Merge
Proprietary
Unix-like, Windows, Mac OS X
Quoted on an individual basis.
ClearCase[8]
IBM Rational
actively developed
Client-server
Merge or lock[2]
Proprietary
Unix-like, Windows, AIX, HP UX, i5/OS, OS/390, z/OS,
$4600 per floating license (held for 30-minutes minimum per user)
Code Co-op[9]
Reliable Software
actively developed
Distributed
Merge
Proprietary
Windows
$150 per seat
Codendi[10]
Xerox
platform actively developed with CVS & Subversion
Client-server
Merge or lock
GPL
Linux Red Hat Enterprise 5.x
Free- Commercial support subscription available
Codeville[11]
Ross Cohen
actively developed
Distributed
Merge
BSD
Unix-like, Windows, Mac OS X
Free
CVS[12]
The CVS Team [13]
maintained but new features not added
Client-server
Merge
GPL
Unix-like, Windows, Mac OS X
Free
CVSNT[14]
March Hare Software[15] and community members.
maintained and new features under development
Client-server
Merge or lock
GPL or proprietary
Unix-like, Windows, Mac OS X, i5/OS
Free or commercial
darcs[16]
David Roundy
actively developed
Distributed
Merge
GPL
Unix-like, Windows, Mac OS X
Free
Fossil[17]
D. Richard Hipp
actively developed
Distributed
Merge
GPL
POSIX, Windows, Mac OS X, Other
Free
Git[18]
Junio Hamano
actively developed
Distributed
Merge
GPL
POSIX, Windows, Mac OS X
Free
GNU arch[19]
Andy Tai
maintained but new features not added
Distributed
Merge
GPL
Unix-like, Windows, Mac OS X
Free
IC Manage[20]
IC Manage Inc.
actively developed
Client-server
Merge or lock
Proprietary
Unix-like, Windows, Mac OS X
Commercial
LibreSource Synchronizer[21]
Artenum[22]
maintained and new features under development
Client-server
Merge
GPL[3]
Unix-like, Windows, Mac OS X
Free
Mercurial[23]
Matt Mackall
actively developed
Distributed
Merge
GPL
Unix-like, Windows, Mac OS X
Free
MKS[24]
MKS Inc
actively developed
Client-server
Merge or lock
Proprietary
Unix-like, Windows
 
Monotone[25]
Nathaniel Smith, Graydon Hoare
actively developed
Distributed
Merge
GPL
Unix-like, Windows, Mac OS X
Free
Perforce[26]
Perforce Software Inc.
actively developed
Client-server
Merge or lock
Proprietary
Unix-like, Windows, Mac OS X
Free for up to 2 users, and for OSS development; else $900 per seat, with volume discounts [27]
PlasticSCM[28]
Codice Software[29]
actively developed
Client-server/Distributed
Merge
Proprietary
Unix-like, Windows, Mac OS X
$500 per seat, with volume discounts, free 5-user 30 day trial licenses available [30]
StarTeam[31]
Borland (Micro Focus)
actively developed
Client-server
Merge or lock
Proprietary
Windows and Cross-platform via Java based client
$7500 per concurrent, $2500 per fixed user.
Subversion (SVN)[32]
CollabNet, Inc.[33]
actively developed
Client-server[4]
Merge or lock[5]
Apache/BSD style
Unix-like, Windows, Mac OS X
Free (Commercial support/services available)
SVK[34]
Best Practical[35]
maintenance through 2010, no new features[6]
Distributed
Merge
Artistic/GPL
Unix-like, Windows, Mac OS X
Free
Team Foundation Server[36]
Microsoft
actively developed
Client-server
Merge or lock
Proprietary
Server: Windows Server 2003; Clients: Windows and Web included
Licensed through MSDN subscription or through direct buy for $2800 [37]
Telelogic Synergy[38]
Telelogic (IBM)
actively developed
Client-server and Distributed
Merge or lock
Proprietary
Linux, Windows, Unix-like
Contact Telelogic [39]
Vault[40]
SourceGear LLC[41]
actively developed
Client-server
Merge or lock
Proprietary
Unix-like, Linux, Windows
$300 per user
Visual SourceSafe[42]
Microsoft
serious bug fixes only
Shared Folder
Merge or lock
Proprietary
Windows
~$500 per license or single license included with each MSDN subscription.
Software
Maintainer
Development status
Repository model
Concurrency model
License
Platforms supported
Cost


Source Control Server and Client



Source Control Server –It is software that really does the software tracking and storage of files. You must install the server software in a secure computer in your office. This will be the machine where the files and multiple versions of them are stored. So it is important that this machine is protected from direct access of any of the members in your team



Source control Client - Users perform all actions through the client software. The client software will communicate with the server software to execute the user tasks. All files will be stored and retrieved to this machine using the Source Control client software. Each member of the team should install the client software in their machines. The client software will send and receive files with the server software. So, the team members do not need direct access to the server computer.



INTRODUCTION



Microsoft Visual source safe – Source Control System



Microsoft Visual SourceSafe also called ‘VSS’ is a file-system-based source control tool from Microsoft. Microsoft Visual SourceSafe is a file-level version control system that permits many types of organizations to work on several project versions at the same time. This capability is particularly beneficial in a software development environment, where it is used in maintaining parallel code versions. However, the product can also be used to maintain files for any other type of team...



At a minimum, Visual SourceSafe does the following:




  • Helps protect your team from accidental file loss.


  • Allows back-tracking to earlier versions of a file.


  • Supports branching, sharing, merging, and management of file releases.


  • Tracks versions of entire projects.


  • Tracks modular code (one file that is reused, or shared, by multiple projects).





Powerful Operations



Add Files, Create Project, Delete Files or Projects, Get Latest Version, Check Out, Check In, Undo Check Out, Move, Deploy, Share, Branch, View, Edit, Show Difference, Set Working Folder, Refresh File List, Refresh Project Tree, Stop Current Operation, Show Properties, Show History, Label, Pin, Rename, Change Password, Cloak Project.



Summary



Source control system helps



1. Keep backup of your source code or documents.

2. Maintain all versions of your files so that you can retrieve any of the old versions of the file easily without searching all over your hard drive.


3. Track which person changed what and when.


4. Control who changes the file to avoid more than one person changing the file at the same time.


5. At any point of time, any of the team members can get the latest version of all files from one single location, without the need to ask each member for the latest files.


6. Track progress - project manager or team leader can monitor the file change activity in source control systems to find out how much work each person has done on each day.

Subscribe to: Posts (Atom)

Text Widget

Copyright © Vinay's Blog | Powered by Blogger

Design by | Blogger Theme by