Programming Environments
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Programming Environments as PDF for free.
More details
- Words: 1,781
- Pages: 9
RUNNING HEADS: Programming Environments
Team-Oriented Programming Environments James Williams University of Phoenix Online February 09, 2009
Team-Oriented Programming Environments Introduction According to Woody (2008), Microsoft Windows Vista consists of 50 million lines of code, Red hat Linux 7.1 has 30 million lines of codes, and Apple’s Mac OS X 10.4 has 86 million lines of code. Such huge and sophisticated programs are far beyond the capabilities of a single programmer and require teams of programmers to develop. These operating systems are indicative of the sophistication and features of most modern applications require the same amount of coordination, control, and cooperation between multiple teams over extended periods of time . . . such is the nature of modern programming efforts. The current trend in application development is projected to increase in complexity as the changing work environments and business marketplace are transformed by innovations, socio-economic, political, and the mobility of the workforce issues confronting businesses today. This increasing complexity creates a need for some means of binding the programming efforts of team members situated in widely dispersed areas into an effective and efficient system. This need is satisfied through the use of team-oriented programming. According to Moore and Deek (2006) the development of a programming environment that is conducive to teamwork on large-scale software systems prior to implementation is as important as schematic diagrams are to building a stereo system from component parts. This paper will examine three different team-oriented programming environments by describing the basic features of each product, examining its strengths, and illustrating the type of environment best suited for each team environment. The three team-oriented programming environments are the Rational Unified Process, UML, and Extreme Programming systems.
Analyses of the Programming Environments Rational Unified Process (RUP) Environment Feiler, Dart, and Downing (1988) report the rational unified process (RUP) environment saw its beginnings in 1985. RUP started with application development and the Ada programming language. This environment was later extended to include the C++ programming language. RUP provides increased productivity to teams of developers working on mission critical applications and can be executed on a wide assortment of computer platforms. The RUP features include syntactic and semantic completion, incremental compilation, integrated configuration management, and version control. The RUP environment also provided tools for iterative development, component-based architecture, program modeling, continuous developer testing, requirements management, and automated testing. RUP runs equally well on mainframe, midsized, and microcomputer systems and contained code generators and code debuggers for Unix and Windows NT operating systems. Feiler, Dart, and Downing (1988) describe the RUP environment as a programming environment centered on a team-based model that included the programmers, sales representatives, and customers. This environment encouraged active in-depth engagement in both pre-sales and post-sales phases of the development and held the programming team accountable for the success of their customers in both the implementation of the application and the customer’s goals for increased revenue expected from the new application. The programming environment, as described by Fieler, Dart, and Downing, has a user interface that appears complicated and daunting with an entirely different keyboard for input. But, these authors assert that the user interface is easy to learn due its uniformity of editing a single programming language for both program code and command invocation, and key strokes
across all levels and modules of the development environment. In addition the information is treated as objects which allows for easy navigation through the development environment. All these features reduce the learning curve and facilitate the ease in which users can learn to operate the development environment and speed their skill development. This common user environment also facilitates large-scale application development using multiple teams of programmers. Further descriptions by Feiler, Dart, and Downey of the user interface include the use of subsystems that are in effect independent code libraries. These subsystems can be compared against the application requirements and semantic compliance during separate compilation processes and worked into the application when needed. This fractionalization of the application into subsystems is conducive for multiple teams working simultaneously on different sections of the application. Unified Modeling Language (UML) Environment Unified Modeling language appeared on the scene in the late 1970s and early 1980s as a means to handle the increasing intricacies of large-scale application development and life cycles for object-oriented and component-based applications. According to Moor and Deek (2006), the Unified Modeling Language (UML) is a standardized language for “specifying, visualizing, constructing, and documenting the intricacies of software systems as well as for the modeling of business processes and other non-software systems.” These authors also state that UML is also a set of best practices and engineering techniques that have proven effective in modeling large, complex software applications. The purpose of the UML environment is to 1) provide a rich visual modeling language that assists in the sharing of program models; 2) support frameworks collaboration, and components; 3) increase the number of specialization instruments that extends core features; 4) provide a common modeling language; 5) foster the growth of the object-
oriented programming language (OOP); 6) provide a language independent platform for program development; and 7) present an official means for furthering research into modeling languages. Feiler Dart, and Downing describe the UML environment as consisting of 12 modeling diagrams that broken down into three categories. The first group is structural diagrams that include class, object, component, and deployment diagrams. The second cluster is the behavior diagrams that include the case, sequence, activity, collaboration, and state diagrams. The last faction is the model management diagrams in which the package, subsystem, and model diagrams reside. The UML environment emphasizes system modeling so that programmers are compelled to build models of solutions to problems and implement a structured methodology to the program design before starting coding. This methodology also provides detailed visual documentation of the solution as a by-product of the design. This visual design method makes the UML programming environment responsible for the detection of the majority of incongruities between specifications, design, source code, and testing while simultaneously providing extensive documentation of the program development. Extreme Programming Environment The Extreme Programming (XP) environment was introduced into the industry in the late 1990s. According to Industrial Logic (2000), the XP environment is collective software development environment that is optimized for efficiency and yield. In this environment programmers are divided into teams of two people and are accompanied by product managers and clients and discuss program solutions and options as needed. Programmers sit in pairs at a computer centrally located in a room while the product managers sit at desks spaced around the room. Programmers ask questions and product managers and clients respond so that
programmers can focus on coding without long delays normally associated with getting the right answers. Wells (2006) describes the XP environment as a “deliberate and disciplined approach to software development” that is a refreshing new way to design and develop applications that maximizes programmer productivity and which is best suited for high risk projects with frequently changing requirements. Using an XP environment to develop the applications for these dynamic projects leads to greater success rates and higher customer satisfaction. In the XP environment programmers at every level of expertise actively participate in the development process and customers are considered to be partners in the program development. Wells further states that the surprising element of the XP environment is the simplicity of its syntax and methodologies. The XP rules are so basic and naïve that the environment appears to be far too simple to be effective and programmers feel awkward when first using the product. Mueller and Tichy (n.d.g.) describe the XP environment as “a lightweight software development process for small teams with vague or rapidly changing requirements.” In this environment external documentation is not a major emphasis and is almost totally absent. The documentation that does exist is in the form of index cards which contain scribbled notes on needed features and the source code itself. Another anomaly from standard program practice is the lack of program specifications. Instead extensive test cases are created as a substitute and produced before any code is written. A third departure from normal coding practice is that the design, implementation, and testing phases are developed simultaneously in small segments. Another departure is the restriction from using a design for change and the lack of formal reviews.
Conclusion Software development tools are multifaceted implements and consist of a large diversity of components that work together in the creation of an application. This paper examined the Rational, UML, and Extreme Programming environments. The outcome of the study determined that each programming environment is an evolution in the development of programming tools and procedures and had its own particular niche in the evolutionary process in meeting the needs of the programming industry for their time. Today the Rational Unified Process environment fits best with large projects that need to be developed by multiple teams using a more structured methodology. The Unified Modeling Language is best suited for large extremely complex programming projects due its graphical object interface and collaborative tools. With its ability to dynamically meet rapidly changing environments, the XP programming environment is the most suitable for the needs of most business communities.
References Davidson, S., Keren, M., Porat, S. and Zodik, G. (n.d.g.). Designing procedural 4GL applications through UML modeling. IBM Haifa Research Lab Matam – Advanced Technology Center, Haifa Israel. Downloaded from http://www.research.ibm.com/ haifa/projects/systems/ple/VisualAge/papers /UMLModelingForVGPaper.pdf on February 1, 2009. Feiler, P.H., Dart, S. A., and Downey, G. (1988). Technical report: Evaluation of the rational environment. Pittsburgh, PA: Software engineering Institute, Carnegie Mellon University. Downloaded 29 January 2009 from www.sei.cmu.edu/pub/documents/ 88.reports/pdf /tr15.88.pdf. Industrial Logic (2000). The XP programming environment. Downloaded from the Industrial Logic website http://www.industriallogic.com/xp/ra/environment.html on 30 January 2009. Moore B. D. and Deek, F. P. (2006). On the design and development of a UML-based visual environment for novice programmers. Journal of Information Technology Education, Vol. 5. 2006. Downloaded from http://jite.org/documents /Vol5/v5p053-076Moor29.pdf on February 1, 2009. Mueller, M. M. and Tichy, W. F. (n.t.g.). Case study: Extreme programming in a university environment; In: CSC5110, Winter 2007-2008, Advanced Topics in Software Engineering. Department of Computer Science and Engineering, The Chinese University of Hong Kong. Downloaded from www.cse.cuhk.edu.hk/ ~csc5110/materials/case-studyextreme-programming.pdf on February 2, 2009.
Reis, S. P., Kennedy, C. M., Woolridge, T., and Krishnamurthi, S. (n.d.g.). Building a constraintbased software environment. Brown University, Department of Computer Science. Downloaded from http://www.cs.brown.edu/~spr/ research/clime/ building.pdf on February 1, 2009. Wells, D. (2006). Extreme programming: A gentle introduction. Extreme Programming Web site. Downloaded from http://extremeprogramming.com on 1 February 2009. Woodie, A. (2008). Will bloat and complexity get the best of Windows? Probably not. The Windows Observer, Volume 5, Number 15 -- April 16, 2008 downloaded from http://www.itjungle.com/two/two041608-story01.html on 28 January 2009.
Team-Oriented Programming Environments James Williams University of Phoenix Online February 09, 2009
Team-Oriented Programming Environments Introduction According to Woody (2008), Microsoft Windows Vista consists of 50 million lines of code, Red hat Linux 7.1 has 30 million lines of codes, and Apple’s Mac OS X 10.4 has 86 million lines of code. Such huge and sophisticated programs are far beyond the capabilities of a single programmer and require teams of programmers to develop. These operating systems are indicative of the sophistication and features of most modern applications require the same amount of coordination, control, and cooperation between multiple teams over extended periods of time . . . such is the nature of modern programming efforts. The current trend in application development is projected to increase in complexity as the changing work environments and business marketplace are transformed by innovations, socio-economic, political, and the mobility of the workforce issues confronting businesses today. This increasing complexity creates a need for some means of binding the programming efforts of team members situated in widely dispersed areas into an effective and efficient system. This need is satisfied through the use of team-oriented programming. According to Moore and Deek (2006) the development of a programming environment that is conducive to teamwork on large-scale software systems prior to implementation is as important as schematic diagrams are to building a stereo system from component parts. This paper will examine three different team-oriented programming environments by describing the basic features of each product, examining its strengths, and illustrating the type of environment best suited for each team environment. The three team-oriented programming environments are the Rational Unified Process, UML, and Extreme Programming systems.
Analyses of the Programming Environments Rational Unified Process (RUP) Environment Feiler, Dart, and Downing (1988) report the rational unified process (RUP) environment saw its beginnings in 1985. RUP started with application development and the Ada programming language. This environment was later extended to include the C++ programming language. RUP provides increased productivity to teams of developers working on mission critical applications and can be executed on a wide assortment of computer platforms. The RUP features include syntactic and semantic completion, incremental compilation, integrated configuration management, and version control. The RUP environment also provided tools for iterative development, component-based architecture, program modeling, continuous developer testing, requirements management, and automated testing. RUP runs equally well on mainframe, midsized, and microcomputer systems and contained code generators and code debuggers for Unix and Windows NT operating systems. Feiler, Dart, and Downing (1988) describe the RUP environment as a programming environment centered on a team-based model that included the programmers, sales representatives, and customers. This environment encouraged active in-depth engagement in both pre-sales and post-sales phases of the development and held the programming team accountable for the success of their customers in both the implementation of the application and the customer’s goals for increased revenue expected from the new application. The programming environment, as described by Fieler, Dart, and Downing, has a user interface that appears complicated and daunting with an entirely different keyboard for input. But, these authors assert that the user interface is easy to learn due its uniformity of editing a single programming language for both program code and command invocation, and key strokes
across all levels and modules of the development environment. In addition the information is treated as objects which allows for easy navigation through the development environment. All these features reduce the learning curve and facilitate the ease in which users can learn to operate the development environment and speed their skill development. This common user environment also facilitates large-scale application development using multiple teams of programmers. Further descriptions by Feiler, Dart, and Downey of the user interface include the use of subsystems that are in effect independent code libraries. These subsystems can be compared against the application requirements and semantic compliance during separate compilation processes and worked into the application when needed. This fractionalization of the application into subsystems is conducive for multiple teams working simultaneously on different sections of the application. Unified Modeling Language (UML) Environment Unified Modeling language appeared on the scene in the late 1970s and early 1980s as a means to handle the increasing intricacies of large-scale application development and life cycles for object-oriented and component-based applications. According to Moor and Deek (2006), the Unified Modeling Language (UML) is a standardized language for “specifying, visualizing, constructing, and documenting the intricacies of software systems as well as for the modeling of business processes and other non-software systems.” These authors also state that UML is also a set of best practices and engineering techniques that have proven effective in modeling large, complex software applications. The purpose of the UML environment is to 1) provide a rich visual modeling language that assists in the sharing of program models; 2) support frameworks collaboration, and components; 3) increase the number of specialization instruments that extends core features; 4) provide a common modeling language; 5) foster the growth of the object-
oriented programming language (OOP); 6) provide a language independent platform for program development; and 7) present an official means for furthering research into modeling languages. Feiler Dart, and Downing describe the UML environment as consisting of 12 modeling diagrams that broken down into three categories. The first group is structural diagrams that include class, object, component, and deployment diagrams. The second cluster is the behavior diagrams that include the case, sequence, activity, collaboration, and state diagrams. The last faction is the model management diagrams in which the package, subsystem, and model diagrams reside. The UML environment emphasizes system modeling so that programmers are compelled to build models of solutions to problems and implement a structured methodology to the program design before starting coding. This methodology also provides detailed visual documentation of the solution as a by-product of the design. This visual design method makes the UML programming environment responsible for the detection of the majority of incongruities between specifications, design, source code, and testing while simultaneously providing extensive documentation of the program development. Extreme Programming Environment The Extreme Programming (XP) environment was introduced into the industry in the late 1990s. According to Industrial Logic (2000), the XP environment is collective software development environment that is optimized for efficiency and yield. In this environment programmers are divided into teams of two people and are accompanied by product managers and clients and discuss program solutions and options as needed. Programmers sit in pairs at a computer centrally located in a room while the product managers sit at desks spaced around the room. Programmers ask questions and product managers and clients respond so that
programmers can focus on coding without long delays normally associated with getting the right answers. Wells (2006) describes the XP environment as a “deliberate and disciplined approach to software development” that is a refreshing new way to design and develop applications that maximizes programmer productivity and which is best suited for high risk projects with frequently changing requirements. Using an XP environment to develop the applications for these dynamic projects leads to greater success rates and higher customer satisfaction. In the XP environment programmers at every level of expertise actively participate in the development process and customers are considered to be partners in the program development. Wells further states that the surprising element of the XP environment is the simplicity of its syntax and methodologies. The XP rules are so basic and naïve that the environment appears to be far too simple to be effective and programmers feel awkward when first using the product. Mueller and Tichy (n.d.g.) describe the XP environment as “a lightweight software development process for small teams with vague or rapidly changing requirements.” In this environment external documentation is not a major emphasis and is almost totally absent. The documentation that does exist is in the form of index cards which contain scribbled notes on needed features and the source code itself. Another anomaly from standard program practice is the lack of program specifications. Instead extensive test cases are created as a substitute and produced before any code is written. A third departure from normal coding practice is that the design, implementation, and testing phases are developed simultaneously in small segments. Another departure is the restriction from using a design for change and the lack of formal reviews.
Conclusion Software development tools are multifaceted implements and consist of a large diversity of components that work together in the creation of an application. This paper examined the Rational, UML, and Extreme Programming environments. The outcome of the study determined that each programming environment is an evolution in the development of programming tools and procedures and had its own particular niche in the evolutionary process in meeting the needs of the programming industry for their time. Today the Rational Unified Process environment fits best with large projects that need to be developed by multiple teams using a more structured methodology. The Unified Modeling Language is best suited for large extremely complex programming projects due its graphical object interface and collaborative tools. With its ability to dynamically meet rapidly changing environments, the XP programming environment is the most suitable for the needs of most business communities.
References Davidson, S., Keren, M., Porat, S. and Zodik, G. (n.d.g.). Designing procedural 4GL applications through UML modeling. IBM Haifa Research Lab Matam – Advanced Technology Center, Haifa Israel. Downloaded from http://www.research.ibm.com/ haifa/projects/systems/ple/VisualAge/papers /UMLModelingForVGPaper.pdf on February 1, 2009. Feiler, P.H., Dart, S. A., and Downey, G. (1988). Technical report: Evaluation of the rational environment. Pittsburgh, PA: Software engineering Institute, Carnegie Mellon University. Downloaded 29 January 2009 from www.sei.cmu.edu/pub/documents/ 88.reports/pdf /tr15.88.pdf. Industrial Logic (2000). The XP programming environment. Downloaded from the Industrial Logic website http://www.industriallogic.com/xp/ra/environment.html on 30 January 2009. Moore B. D. and Deek, F. P. (2006). On the design and development of a UML-based visual environment for novice programmers. Journal of Information Technology Education, Vol. 5. 2006. Downloaded from http://jite.org/documents /Vol5/v5p053-076Moor29.pdf on February 1, 2009. Mueller, M. M. and Tichy, W. F. (n.t.g.). Case study: Extreme programming in a university environment; In: CSC5110, Winter 2007-2008, Advanced Topics in Software Engineering. Department of Computer Science and Engineering, The Chinese University of Hong Kong. Downloaded from www.cse.cuhk.edu.hk/ ~csc5110/materials/case-studyextreme-programming.pdf on February 2, 2009.
Reis, S. P., Kennedy, C. M., Woolridge, T., and Krishnamurthi, S. (n.d.g.). Building a constraintbased software environment. Brown University, Department of Computer Science. Downloaded from http://www.cs.brown.edu/~spr/ research/clime/ building.pdf on February 1, 2009. Wells, D. (2006). Extreme programming: A gentle introduction. Extreme Programming Web site. Downloaded from http://extremeprogramming.com on 1 February 2009. Woodie, A. (2008). Will bloat and complexity get the best of Windows? Probably not. The Windows Observer, Volume 5, Number 15 -- April 16, 2008 downloaded from http://www.itjungle.com/two/two041608-story01.html on 28 January 2009.
Related Documents
Programming Environments
June 2020 8
Powerpc Environments
November 2019 29
Programming
November 2019 39
Programming
November 2019 29
Programming
November 2019 21