Software Configuration Management Naming Convention Version control Submitted

Software Configuration Management Naming Convention & Version control Submitted by, Karthikeyan N, [ME]-CSE Anna University , Trichy.

Corner stones in software development process: � Development of High Level Languages; � Introducing the Subroutine Concept; � Structured Programming and its Evolution to OO Programming; � Naming Conventions; � Software Engineering (CASE tools). 12/4/2020 Assoc. Prof. Stoyan Bonev 2

Corner stones in software development process: � Structured Programming and its Evolution to OOP; Bohm and Jacopini introduced and proved the structured theorem in programming. Sequence Selection Repetition E. Dijkstra established principles of structured programming. 12/4/2020 Assoc. Prof. Stoyan Bonev 3

Structured Programming � Each computer program may compose using Sequence, Selection and Repetition constructs. � Each program unit should have one entry point and one exit point. � SP is known as a “goto-less” programming. ◦ A program that can be read from top to bottom is much easier to understand than a program that requires the reader to jump from one statement to some nonadjacent statement in order to follow the execution order. 12/4/2020 Assoc. Prof. Stoyan Bonev 4

Corner stones in software development process: � Naming Conventions: ◦ Mnemonic Identifiers easily spelled in English ◦ Hungarian Notation – special prefixes ◦ Camel Notation – names begin with a lowercase letter. Multiword names (“my button”) are written with no spaces and no underscores and with each word after the first capitalized (my. Button) ◦ Pascal Notation – just like Camel notation except that the first letter is also uppercase (My. Button, File. Size, Left. Corner, Freezing. Point). 12/4/2020 Assoc. Prof. Stoyan Bonev 5

Microsoft suggests: � Variables be written with Camel notation; � Constants be written with Pascal notation; � Member variables and methods are named using Camel notation, while classes are named using Pascal notation. ◦ Reference: Learning Visual Basic. NET by Jesse Liberty, O’Reilly Publ. 12/4/2020 Assoc. Prof. Stoyan Bonev 6

Pankaj Jalote: naming conventions � Package names should be in lower case (mypackage, edu. iitk. maths) � Type names should be nouns and start with uppercase (Day, Date. Of. Birth, …) � Var names should be nouns in lowercase; vars with large scope should have long names; loop iterators should be i, j, k, … � Const names should be all caps � Method names should be verbs starting with lower case (e. g. get. Value()) � Prefix is should be used for boolean methods 12/4/2020 Assoc. Prof. Stoyan Bonev 7

Corner stones in software development process: � Software Engineering (CASE tools). Software development life cycle and importance of the design stage UML as a formal notational tool in OOA and OOD 12/4/2020 Assoc. Prof. Stoyan Bonev 8

Programming styles: � Procedure oriented (imperative) programming (Visual Basic, C/C++/C#, Java) ALGORITHMS + DATA STRUCTURES = PROGRAMS � Logic programming (Prolog – PROgramming in LOGic) RULES + FACTS = PROGRAMS � Functional programming (LISP - LISt Programming) PROGRAMS = FUNCTIONS COMPOSITION 12/4/2020 Assoc. Prof. Stoyan Bonev 9

Software Configuration Management � Practice of handling changes systematically � Three components ◦ Build control ◦ Version control ◦ Change control

Traditional Version Control � Common methods of maintaining versons ◦ Copy versions into separate directories �backup �old/old �backup. Feb. 7. 1988 ◦ Copy versions onto separate disks/diskettes and label the disk Problems with traditional approach � Inefficient use of storage � Inefficient for storage and retrieval � Inefficient for comparing changes across versions

Common approaches for working in teams � Each person maintains a copy of the system � Every one works on the same copy of the system � A combination of the two Conflicts when working in teams � Multiple programmers may simultaneously modify ◦ different copies of the same files ◦ same file ◦ inconsistent versions of the files

Version Control Requirements Provide methods to save the state of a “configuration” at various snapshots in time � Provide methods to revert configuration to an earlier state � Version Control Capabilities Version control procedure or tool should provide capabilities to: ◦ identify (name) ◦ time/date stamp ◦ store and retrieve ◦ compare multiple versions of ◦ individual components, or ◦ complete configuration, or ◦ some combination thereof �

Version control tools � Individual file level control ◦ SCCS ◦ RCS � Directory level control ◦ CVS ◦ Razor

Configuration identification � Configuration item ◦ Primitive components whose versions need be controlled � Baseline ◦ State of all configuration items at some particular time ◦ Baselines are typically defined at completion of certain phases �Functional baseline �Design baseline �Product baseline � All changes made after a baseline has been defined must be controlled (I. e. , approved, recorded, etc. )

Identifying versions: Numbering � Convention for naming versions. � Numbering convention: ◦ Associate two numbers RR. VV �RR is major release �VV is version �Such as � 1. 0, 1. 1, 1. 2, 2. 0, 2. 1. . � Each configuration item has its own version number � Different configuration item within a configuration may have different version number

Identifying versions: Symbolic � A symbolic name may be assigned to a version number ◦ 2. 2 = design-baseline ◦ 3. 0 = fully-tested � The “current state” of all configuration items may be given the same symbolic name � Symbolic names may be used to identify the state of the whole system at a given time

Version and access control Key issues in CM Done primarily on source code through source code control systems, which also provide access control Allows older versions to be preserved and hence can undo changes Examples: CVS – Original open source system (1986) Subversion – Open source CVS replacement (1999) Microsoft Visual Source. Safe (VSS) – targeted for smaller dev projects IBM Rational Clear. Case – Industrial strength solution 18

Version and Access Control � When programmer developing code – is in private area � When code is made available to others, it goes in an access- controlled library � For making changes to an item in library, it has to be checked out � Changes made by checking-in the item – versioning is automatically done � Final system is built from the library Other Processes 19

Version/Access Control � Generally both version and access control done through CM tools � Tools limit access to specified people - formal check in, check out procedures � Automatic versioning done when a changed file is checked-in � Check-in, check-out control may ◦ be restricted to a few people in a project ◦ Require successful compile/build cycle Other Processes 20

Summary: Version Control � VC encompasses the tasks involved in managing multiple versions of a (multi-component) system being developed by multiple programmers � There are several tools available that can automate various VC tasks � The VC tools place the source code in a “repository” and provide mechanisms to add, checking, and checkout items from the repository Other Processes 21

Collecting the materials through the following link http: //www. powershow. com/view 1/86 ad 4 ZDc 1 Z/Software_Configuration_Management_Version_Control_po werpoint_ppt_presentation https: //www. google. co. in/url? sa=t&rct=j&q=&esrc=s&source=we b&cd=1&cad=rja&uact=8&ved=0 CBs. QFj. AA&url=http%3 A%2 F%2 Fwww. ccs. neu. edu%2 Fhome%2 Flieber%2 Fcom 3205%2 Ff 02%2 Fl ectures%2 Fsommerville%2 Fch 29. ppt&ei=_l_1 U 86 EGoedyg. TO 9 YD IDg&usg=AFQj. CNGChm. YFmu 40 apk. Ydv. JGLLLMcl 630 Q&sig 2=bw. P Uo 1 bw. N 5 UJti. K 9 e. Bspb. Q&bvm=bv. 73231344, d. a. Ww 22